Internet Security Systems: RealSecure

by Paul Grosse - June 2000


The need to have an online presence 24 hours each and every day of the year in order to pursue corporate goals for e-commerce and e-business leaves corporate firewalls open to attack from anywhere on the planet. In order to be of any use, a firewall must let through some traffic, therefore hackers using legitimate channels can break into networks and go unnoticed - one example being the encrypted traffic of a hijacked VPN session from a weakly secured remote station which passes, by design, unhindered through a firewall.

In addition to this, a firewall gives no protection at all from malicious attacks that originate from within a network. As though that was not enough, a great deal of damage is done to networks each year by non-malicious or curious users making innocent observations or changes to the systems that they are authorised to use.

Fortunately, a great deal of this type of activity follows known patterns and it is possible to identify it in real time and take appropriate action. As part of ISS's SAFEsuite, RealSecure provides an intrusion detection system that monitors suspicious behaviour, making changes to the system in real time, such as terminating sessions or changing the firewall, so that further attacks are precluded.


Like any sensibly designed intrusion detection system, RealSecure is comprised of a number of types of components, each element performing a strategically clear function: Network Sensors monitoring traffic; OS Sensors monitoring the servers; and, a Console, managing the response to intrusions.

Network Sensor

Large networks (or collision domains) are divided up into smaller ones by firewalls, routers, bridges and switches, each usually installed to improve network performance or increase network security. The RealSecure network sensors run on dedicated machines, only operating within each local collision domain - common places to locate network sensors being: on each segment that contains a vital network or information resource; in the demilitarised zone (DMZ) of a firewall so that the firewall may be monitored; and, just inside the firewall, on the intranet so that successful penetrations of the firewall are detected. Other likely locations include: the network backbone so that interdepartmental traffic is monitored; immediately behind a WAN router, a WAP server or a modem pool in order to protect against unauthorised access from the telephone network; and, in the wiring closet so that different segments can be connected as dictated by network activity.

In order to monitor a particular collision domain's traffic, each Network Sensor requires a Network Interface Card (NIC) capable of working in promiscuous mode, that is to say that the NIC is capable of monitoring all traffic on the local network, whereas an NIC operating normally only picks up traffic that is addressed specifically to it. However, although an NIC that is operating in promiscuous mode can see all traffic that is on a network, it has no IP address, does not have any IP services available and is relatively difficult to see from the network. This leads to an interesting situation whereby the network sensor can have two NICs, one in promiscuous mode and one that is connected to an internal, secured network, complete with full TCP/IP protocol stack thus creating a secured channel for the network sensor to communicate with the Console.

RealSecure Network Sensors work by comparing the traffic on the network against a set of rules defined in a number of policies. These policies cover the vast majority of cases but should it be appropriate, a policy can be copied - the original cannot be edited - and modified accordingly. The attack signature database is updated by the ISS XForce research and development team, the list purported to be the most comprehensive in the industry. The policies include the ability to decode SAMBA/CIFS protocols for Microsoft Windows networking.

Some other unauthorised activities are: When one user attempts to copy a password list file (.pwl) from a shared volume on a Microsoft Windows 95 system; Remote registry access attempts; Null sessions; Attempts to read from or write to protected shares; SAMBA buffer overflow attack; and, decodes of NetBIOS session grant, reject or request. It can also filter and monitor any TCP/IP protocol, interpreting HTTP, E-mail, FTP, Remote login, Chat and so on. It stops denial of service attacks such as WinNuke, SYN Flood and LAND, Unauthorised access attempts such as Back Orifice access and Brute Force login, Pre-Atack probes such as SATAN scans stealth scans and attempts to connect to non-existent services. Further to this, attempts to install backdoor programs such as rootkit or BackOrifice2000, attempts to modify data or web content and attempts to stop services or or kill programs are themselves stopped.

When RealSecure does detect suspicious activity, it communicates the information to up to 50 consoles - authenticating itself to the console by using public key cryptography. In addition to this, it can initiate E-mail notification, SNMP (Simple Network Management Protocol) Trap; and there is an option to view the active session. Further to this, a summary of the event is logged and the raw network data can be logged. As raw data logging will consume any bandwidth that the network has to offer, if the data is sent to a large number of consoles, this may constitute a denial of service attack in its own right, therefore the number of consoles that a sensor communicates to should be limited.

In response to an attack that has been detected by a network sensor, the connection may be killed (TCP reset), the firewall may be reconfigured (Lucent and Checkpoint), or any user defined action may be initiated.

OS Sensor

The OS Sensor runs as a process on the server that is being monitored. Every time a new log-file entry is generated by the operating system, OS Sensor reads it, and compares it against the signatures currently in force. If a match is found, it initiates the appropriate response.

OS Sensor compliments the functionality of Network Sensor by confirming the success or failure of an attack and revealing systems specific event data such as user name and file name during an unauthorised access attempt. However, the OS Sensor does not rely entirely on the application logs, using additional kernel-level audit data thus precluding the success of attempts to fool, spoof or bypass it.

Further to this, OS Sensor is able to detect local attacks and abuses that would normally be missed by the Network Sensor. Examples of this type of attack are: someone who has access to the console, continually trying out passwords; a valid users using hacking programs to add themselves to the administrator's group; and, someone trying to open a file without the necessary authorisation. All of these are detected by the OS Sensor.

The OS Sensor should be deployed on: Important Microsoft Windows NT or UNIX servers; Host systems with critical data; Microsoft Windows NT Domain Servers or UNIX NIS servers; and on hosts for remote UNIX monitoring. In this way, activities on hosts that contain vital applications and data files, such as attempted unauthorised access to these resources or attempts to reconfigure user account information and so on can be detected and stopped. UNIX hosts that cannot run an OS Sensor locally can be monitored by forwarding the host's syslog files to a Microsoft Windows NT agent or by using the remote log monitoring feature built into the UNIX subsystem on a host running the OS Sensor. However, when syslogs are forwarded or read remotely, the syslog information is sent in clear text therefore the communication must be secured physically so that it cannot be intercepted by an intruder using a switch.

When suspicious activity is detected, like the Network Sensor, an alarm is sent to the Console, initiating an E-mail Notification and SNMP (Simple Network Management Protocol) Trap. Again a Summary is logged and in this case the system may: Terminate user Login; Disable the user account; or perform a user defined action.


The Console and the Sensors communicate with each other; the console defining the policy for each sensor - Network Sensor security events, connection events, user-defined filters and user defined events; and, OS Sensor security events, syslog events, suspect connection events and user-defined events.

There are a number of predefined policies that can be applied to an active sensor or, if appropriate, custom policies may be created. In order to do the latter, an existing policy is selected, copied and then the parameters are edited. In this way, the existing policy is not changed and if a sufficiently similar policy is selected to start with, few of the parameters need to be customised.

Working Together

Communications between the Console and the Sensors is always initiated by the Console and then authentication is secured by public key cryptography. Once a secure tunnel has been established between the Console and each Sensor, reliability, privacy and integrity are secured. All communications between the Console and the Sensors: are encrypted; are verified using cryptographic checksums; use only TCP (no UDP); and, all TCP ports are user configurable so that existing firewall tunnels may be used.

Traffic from the sensors to the Console includes: Event messages - an indication that something of interest has happened; Raw session data if the action associated with the event is to view the session (these first two occurring in real time); and, Database and log file information which is sent to the Console on demand. Traffic in the other direction includes Start, stop and pause commands; Changes to sensor configuration; software and signature updates and so on.

RealSecure may be customised to suit a particular situation in a number of ways. Firstly, actions that RealSecure takes on the detection of an event may be changed to: Terminating the attack automatically; Terminating the user session; Disabling the user account; Reconfiguring a Checkpoint Firewall-1 firewall so that it rejects traffic from the attack source address; Sending a secure, real-time alarm to the Lucent Managed Firewall Security Management Server; Logging the event; Viewing the raw data; Running a user-specified program; or, Sending out various alarms.

Secondly, the OS Sensor allows the administrator to define a specific keyword or regular expression that, when found in the syslog file or in the kernel-level audit data, will trigger a specified event. Thirdly, connection events may be defined so that a particular combination of protocol, source and destination IP addresses and source and destination ports triggers an event; Fourthly RealSecure predefined attack signatures may be modified so that they more accurately reflect the circumstances of your network; Then, the filtering logic may be instructed to ignore certain types of traffic so that legacy programs that trigger false positives can be taken out of the detection system; and, Lastly, virtually any response option can be created, allowing the automatic running of any program that can be run from the command line.


Network Sensor:

Microsoft Windows NT system

Solaris SPARC system

Fast Ethernet Adapters:

Token Ring Adapters:

FDDI Adapters:

OS Sensor

The OS sensor is a lightweight application, typically using 5MB RAM and less than 1 percent of the CPU.

Microsoft Windows NT system

Solaris SPARC system

IBM AIX system

HP-UX Operating System


Microsoft Windows NT system


Price upon application


Intruder Detection Systems such as RealSecure are an excellent security tool, complimenting firewalls, anti-virus products and content security. However, no matter how expertly written any of these product may be, they all have vulnerabilities that can be exploited. Like firewalls, that are continuously under new types of attack, also suffering from incorrect configuration, anti-virus products that are only as good as their last update or heuristic programming and content security products that are completely blind to steganography, intrusion detection systems rely upon correct configuration, vigilant administrators and good support. Fortunately, ISS does supply good support and administrators can take care but, as with the other security products mentioned, complacency should be avoided at all costs and an appropriate balance should be struck between false positives and false negatives.

One configuration of RealSecure is to have a Network Sensor with a promiscuous NIC in the DMZ segment and the other NIC on the internal segment, inside the firewall. In this way, the traffic on the DMZ may be monitored for suspicious activity and communications to the console need not travel through the firewall between the DMZ and the internal network, therefore freeing up some bandwidth - the NIC in the DMZ, by not having an IP address of TCP/IP protocol stack, is not capable of routing packets past the firewall. In addition to this, with any properly designed tri-homed firewall, the DMZ is protected from both the internal and the external networks by a fully functional firewall therefore, should the NIC in the DMZ become addressable for some reason, anyone wishing to break into the internal network from the unprotected, external network would still have to break through full firewall protection. Even so, physical access to the network sensor machine in the DMZ or any machine that can configure the functionality of the normally promiscuous NIC in the DMZ, should be secured to prevent such a reconfiguration.

There is an upper limit of 50 sensors that a console can handle although normal implementations would have between 10 and 20 sensors monitored by one console. However, one sensor may communicate with up to 50 consoles and in this case, although it is possible to implement such a network, if a significant number of the consoles elect to view the session of a particular event, then up to 50 copies of the offending packets may be sent out in real-time thus creating an unintentional denial of service attack, implemented by the intrusion detection system itself.

RealSecure collects a great deal of information as it is passed across the network, from user names and passwords to e-mail and FTP content. In order to prevent it from becoming a golden key to your company's resources, there are steps that should be taken to prevent this from occurring such as scanning to make sure that the system is working correctly, using the Network Sensors on dedicated machines that have everything except TCP/IP disabled and so on. As with data-warehousing, there are problems associated with collecting large quantities of data in one place, although in the case of intrusion detection systems, this may be of more immediate value to the hacker.

The Sensors are highly configurable - extra signatures being added and others adjusted. If a situation arises whereby a necessary program on the network causes a great number of false positives, the system can be adjusted simply so that traffic meeting a specification - a protocol or group of protocols using a specific combination of source and destination ports and IP addresses - is ignored, thus allowing the smooth running of that application. However, great care must be taken when disabling such monitoring, because the open door may not be what it seems. One way of getting someone to turn an alarm off it to set it off continually and if there is not sufficient time to sort out the problem, the alarm is left off. Some people steal cars this way - it would make sense to check out any program that required this action.

On Microsoft Windows NT hosts, encryption functions make use of the Microsoft Cryptographic API. Unfortunately, US government restrictions apply and symmetric key encryption is limited to 40 bit for export whilst companies that exist entirely within the US can adopt 128 bit encryption for their entire company. A similar situation exists with UNIX hosts where elliptic curve encryption is limited to 113 bits for export whilst 139 bit is employed for US and Canadian domestic use - 40 bit DES for export and 168 bit DES or 3DES for US domestic use. International companies wishing to use a standard throughout the organisation will either have to put up with weak encryption or look somewhere else.




RealSecure plugs a large gap in the security of a network, filling in with monitoring the network for suspicious behaviour that does companies a lot of damage both financially and intellectually. Many sites are hacked every day, some from the inside. Those that do have their web pages hacked not only lose business as a result, but have their home pages displayed on websites dedicated to exposing inadequate security - Intrusion Detection is therefore a must have.

Internet Security Systems Inc.'s product portfolio - scanners, Intrusion Detection, Security Management Applications, Managed Security Services; Consulting and Education, fits in well with the increase in the security requirements of the business over the next decade and on and by concentrating on one area of the market whilst maintaining and improving its integration with other key areas, ISS appears to be reasonably assured of its steady growth.

Company Profile

In 1994, two years after inventing a technology that had the ability to identify and recommend corrective action for network security problems, Christopher Klaus founded Internet Security Systems selling the company's first product, Internet Scanner, from its first office in Norcross, Georgia, teaming up with Thomas E. Noonan (now CEO) in the following year. Since then, the company has centred its attention on sophisticated Internet security products, developing a portfolio of software and services.

In March 1998, ISS made a successful initial public offering of common stock which is traded publicly on NASDAQ under the symbol ISSX. The company now employs more than 1,000 people in 17 countries and has just reported its 20th consecutive quarter of growth, representing an annual revenue of $116 million for 1999, an increase of 104 percent over its revenue of $57 million for 1998. In August 1999, the company acquired Nertix Inc., a Managed Security Service provider (MSS), thus expanding its customer reach into the MSS market. ISS is now has its headquarters in Atlanta, Georgia, with international offices in Belgium and Japan with further offices in Australia; Brazil; Canada; Egypt; France; Germany; Italy; Netherlands; Spain; Sweden; Switzerland; and the UK.

The company's product portfolio includes: SAFEsuite Security Assessment - Interent Scanner, System Scanner and Database Scanner; SAFEsuite Intrusion Detection and Response - RealSecure; SAFEsuite Security Management Applications - SAFEsuite Decisions; Managed Security Services; ISS Consulting and Educational Offerings.

ISS has a number of strategic partners that include: Ameritech; BellSouth; Bull; Check Point Software; Compaq Computer Corporation; Deloitte and Touche; Embratel; IBM; iXL; KPMG; Lucent Technologies; Marsh; Microsoft; Nortel Networks; PWC; SUN; and, Trend Micro.

In 1999, ISS was named a "Top 50 most dynamic company" by Forbes magazine and a "Top 50 Public Company" by Red herring magazine. USA Today described it as one of the industry's most important business to business Internet companies and a "top 50 E-Business Stock". In August 2000, the company was named one of the fasted 100 growing companies by Individual Investor magazine. Other awards and recognition includes: Network Computing's Well-Connected 2000 Awards; Secure Computing's Academy Award - Best Network Security Product; Network Magazine's Product of the Year; and, CMP Magazine's Security Product of the Year.

ISS has more than 6,000 customers which includes 68 percent of Fortune 50 companies and 21 percent of the 25 largest US commercial banks. It also serves the ten largest telecommunications companies and more then 35 government agencies. Some other important customers include: Citibank; Metropolitan Life; Microsoft; Quest; Swiss Bank; the US Army; and,

In the US:
Internet Security Systems Inc.
6600 Peachtree-Dunwoody Road NE
300 Embassy Row
Suite 500
Georgia 30328
Tel: +1 678 443 6000
Toll free 888 901 7477
Fax: +1 678 443 6478

In the UK:
Internet Security Systems
UK and Ireland London Office
Walbrook House
23 Walbrook
United Kingdom
Tel: +44 (0)20 7626 7070
Fax: +44 (0)20 7626 1114

Copyright (c) 2000 P. A. Grosse. All Rights Reserved.

Back to the Internet Security Index

Back to the Index