One of the key countermeasures against network compromise is an intrusion detection system (IDS). A well-configured IDS is a critical element in information system security. Given ample time to probe defenses and find holes in a system, a hacker will find a way to compromise the network, even against the best perimeter defenses. Therefore, no security posture is complete without a way to detect and respond to hacker activity. This is what an IDS offers.
In this chapter, we offer techniques for evading an IDS during penetration testing and explain when they should be used. Based on these techniques, we present a few leading practices for properly configuring an IDS to detect intrusion attempts. Further, we briefly present information on common IDSs currently available.
Generally, IDSs are deployed with multiple sensors in various locations on the network reporting to a central management console through which IDS alerts can be seen and the sensors can be managed. An IDS sensor monitors traffic running across its interface into the network and looks for traffic patterns that match particular rules and signatures within the tool's rule set. When a particular rule is matched, an alert is sent to the management console. In addition to alerts, you can configure an IDS to send pages, e-mails, and other notification actions.
A rule set contains rules that identify unusual or unwanted behavior as well as traffic signatures representative of known attacks and exploits. A rule can identify one or more options or thresholds, such as protocol, source and/or destination domain, IP address and/or port, and quantity of occurrence (there are variations in this among the different IDS products). For example, attempts by a user to access root-level files can cause alerts. An alert triggered by three consecutive failed login attempts is a classic example of a rule designed to alert an administrator of unusual activity. Also, rules can be developed to send alerts about certain events only if they involve a particular source or destination (determined by domains, IP addresses, ports, and so on). For example, zone transfer queries against a domain name server from a machine other than a domain name server may raise enough suspicion to trigger an alert.
A signature is code representing the traffic patterns associated with particular attacks. For example, the Tribe Flood Network 2000 (TFN2K) distributed denial-of-service tool, which floods its target with various TCP, UDP, and/or ICMP packets, uses the same value in the header length field of the header of each TCP packet it transmits. Further, each packet ends in a string of 'A's (hex 0x41). These recognizable characteristics can form the signature for this attack. When the IDS sensor identifies packets matching this signature, it can signal an alert for TFN2K and can be configured to take further action, such as sending an automatic e-mail or a page. Further action is also possible, such as executing a script and forcing a connection to be dropped at the firewall.
IDSs can be either network-based or host-based. As their names suggest, a network-based IDS monitors traffic over the network and generally looks for traffic that is evidence of network-based attacks. SYN flood denial-of-service attacks and port scanning are two examples. A host-based IDS, on the other hand, monitors and protects a single host and looks for evidence of unusual activity on or against that host. You can configure host-based IDSs to monitor and alert for traffic signatures such as an unusual number of login attempts to single or multiple users' accounts, login at an unusual time, or attempted access to file(s) in a directory to which the user does not have access privileges.
These two kinds of IDSs are generally located in different places on the network. In either case, you must locate the IDS sensors in positions where they can view all the traffic of concern. The sensor for a network-based IDS (NIDS) is generally placed on segments that contain critical servers. NIDSs may also be deployed behind the firewall or on the main router or switch for the network. A host-based IDS (HIDS) more commonly is found on hosts that are of particular interest or are more likely to be targets of attack, such as a DMZ Web server or a back-end database server. Figure 19-1 shows a sample architecture for an IDS using both network- and host-based sensors.
There is some degree of overlap in the two types of IDSs in terms of the signatures they contain. For example, both may be configured to detect a surge of ICMP packets running across their sensors. In fact, the IDS industry is moving toward developing products that merge both IDS types into a common management console.
We organize our penetration-testing efforts around a goal of compromising the network without detection. It is important to examine the effectiveness of the IDS and the responsiveness of those monitoring it in order to assess the overall security posture of a network.
Hopefully the target of the test detects the attack and logs the relevant actions. In such a case, even if a hacker does deface a Web site, his or her actions and source IP address may be recorded, the original Web site can more quickly be restored, and the option for prosecuting the hacker remains. It should be noted that successful prosecution of hacker activity can be very difficult, especially if the intruder has sanitized or deleted the relevant log files or the administrator took inappropriate action when assessing the attack and inadvertently destroyed critical evidence.
To circumvent an IDS you need to find holes in its rules, signatures, and/or thresholds. Though it is unlikely to have complete information on the rule set of an existing IDS, many hackers and security consultants do have an understanding of the common IDS rule set, including typical threshold values. They develop their penetration strategy around bypassing the common IDS configuration.
While several IDS vendors are moving to offer integrated network and host-based IDS solutions, network-based IDSs are more common than host-based ones. The techniques we mention are generally geared toward avoiding detection by a network-based IDS; however, they do apply to both.
Here are five points to keep in mind as you attempt to avoid detection by an IDS.
Be patient. As mentioned above, there is a collection of events that trigger an alert only if they occur multiple times over a certain, relatively small, time period. Many times these thresholds are set high to minimize a false positive rate, and you can use that to your advantage. By keeping a slow pace of activity on your port scans, brute force attempts, and other attacks, you may avoid raising a red flag.
If we are manually attempting to access a login account, we generally make two password guessing attempts at a time on the same account, then move to another user account if unsuccessful. After a sufficient time period, we can return to make two additional attempts on each user account. Since we are making limited password attempts, we cannot use brute force techniques and must instead rely on intelligent guessing by using common default passwords, such as “test,” “password,” and “p@ssw0rd.”
Similarly, SNMP queries can go undetected if we space them out over time. By spacing these queries by a few minutes we may exceed the typical time limit for an IDS detection window.
Be quiet. Limited traffic against a target network from an outside (and unknown) source may get by the sensors of an IDS. It is likely that a high volume of traffic of any kind from an unknown source will generate an alert on a network that does not expect such traffic.
Go manual. When attempting to avoid detection, we do not run commercial vulnerability scanners, which fairly quickly run through a large collection of tests and exploits—such scanners are noisy. Vulnerability scanners are designed to find security holes, not to avoid detection. If an IDS cannot detect a vulnerability scanner, it is probably misconfigured and can't detect much of anything else either. Commercial scanners certainly have their place in the security consultant's tool kit. But they should not be used when you are trying to avoid detection. An IDS cannot be evaded using these tools.
In place of such tools, we do things manually as much as possible. This goes hand in hand with both of the above suggestions. Manually trying just a few telnet passwords at a time forces us to be patient and allows us to minimize the noise we make. If we stick to one or two login attempts per user name over a five-minute interval, we may avoid setting off an IDS.
Use untraceable and/or multiple IP addresses. If at all possible, try to use an IP address that is not tied directly to you. We have seen hackers use spoofed IP addresses. With a fake IP address, even if your activities generate a long list of alerts, if the target is not able to trace the activity back to you, they will be less able to respond effectively. In addition, by using multiple phony IP addresses as decoys, you may be able to confuse the target and IDS into thinking the attack is a false positive alert.
Unfortunately, we are not always able to use fake IP addresses during our penetration-testing engagements. We generally have to inform our clients where our activity will be coming from so that they will recognize that such activity is not an actual hacking attempt. Also, the organization may track the phony IP address to a legitimate company and accuse it of trying to attack their network. This could lead to confusion and legal problems. Therefore, if you do spoof an address, choose the address carefully. Finally, address spoofing mainly works for attacks that do not require a response. If a response is required, you must use redirection either at the target router or at the spoofed IP address.
Use IP fragmentation. IP fragmentation can make it more difficult for IDSs to flag potentially dangerous traffic since the signatures are broken up into multiple packets. While several IDSs do have flags that indicate traffic has been broken into multiple packets, selecting these flags can generally lead to a great deal of false positives. Web traffic, for instance, is often broken up into multiple packets.
IP fragmentation can be done through various tools, such as Nmap, which can fragment its scans, as well as Fragrouter (a tool developed by Anzen Computing, which has been purchased by NFR). Fragrouter is a software tool that acts as a router and can fragment all outbound traffic.
Depending on the activity, these guidelines may not always be easy to follow. Furthermore, the time factor associated with penetration-testing engagements may not allow you to be patient. This is especially true with activities such as brute force login access attempts, which simply run through a large number of potential passwords in a short amount of time.
A caveat: If the target is running an IDS on a fast processor in promiscuous mode and if it is configured correctly, it will probably catch everything you do, including Nmap FIN scans. In such cases, we use decoy addresses as much as we can and try to redirect or bounce our attacks off other hosts if possible. In most cases, we just proceed with our testing. We try to identify a vulnerability as quickly as possible, exploit it, capture the flag files (if that is the goal), and get out. Often an IDS catches something, sets off its on-screen red alert, sends a page, and so on, and still the administrator takes no action. The unpreparedness of security administrators is not something we like to count on, but it happens more often than one would guess and does in fact contribute to many of the compromises and intrusions that occur today.
The guidelines described above also pertain to port scanning. SYN, FIN, null, and XMAS scans offer more obscurity than general port scanning, however, as a tradeoff, the more obscurity they provide, the more time consuming and less accurate they may be. A SYN scan seems to best balance obscurity and effectiveness in port scanning.
Nmap performs all of these types of scans and offers several additional options to help you go undetected. (Nmap is discussed in detail in Chapter 13.) Here we highlight features that can aid in performing port scans undetected. For example, you can use the timing capabilities(with the -T option) to set the interval between successive packets sent out. This allows you to probe fewer ports in a given monitoring window. The computer industry is always trying to make things go faster. If you just slow down your testing activities, you reduce your risk of being detected.
In addition, using the -P0 option with Nmap generally reduces the amount of noise generated since it will not ping hosts before conducting the port scan. Ping packets are often detected by an IDS; avoiding them will help keep your activity unnoticed. Be aware that this will cause you to port scan every host in your host list, even those that are not live or responsive to pings, causing the scan to take more time.
You can counter this by scanning only a few machines and ports at a time. Avoid running a port scan on all 65535 ports at once. There is nothing wrong with scanning all ports if you feel there may be a higher-numbered port open. In fact, toward the end of the test, we recommend scanning all ports to find any you may have missed. However, in order to help remain undetected, port scans should be done more surgically, a few at a time. We scan no more than 100 ports per host when we are attempting to avoid detection, and we recommend scanning ports in a random order (with the -r option).
Nmap's decoy capabilities allow you to use fake IP addresses, which can help to distribute any attention given to the scanning to a collection of IP addresses rather than just your own. It may also confuse security administrators into thinking they are experiencing the preliminary stages of a distributed denial-of-service attack. As for the IP addresses to select as decoys, remember to use only addresses for which you have permission. Using random IP addresses as decoys can lead to some potentially embarrassing and confusing incidents.
We have seen hackers successfully take this decoy option a step further by using IP addresses that could be legitimate sources of port scans that the system administrator will have to investigate. When doing this, hackers do not spoof source addresses such as whitehouse.com or yahoo.com. These Web addresses are not likely to be involved in scanning a target host. Therefore, a security administrator would be able to eliminate them, reducing the effectiveness of the decoy. It is more effective to use IP addresses that ISPs own and dynamically assign to their dial-up customers. Dial-up customers are a potential source of Nmap port scans. Be aware that ISPs record the IP addresses they assigns to users. The ISP and its customers will likely not get in any trouble because they did not do the port scan, but it can cause them a lot of grief along with time and money spent in proving their innocence. As professional security consultants, we do not resort to this step since it may inconvenience others, but it is something that we have seen hackers do.
To further augment the effectiveness of Nmap's stealth capabilities, Nmap scans can be fragmented with the -f option. Using this approach makes the scans take a great deal of time, so you must carefully weigh the added benefit against the significantly increased time requirements. We do employ this approach for at least a portion of our scanning to gauge the target's ability to detect port scans.
Using this same approach, you can also perform SNMP queries slowly so as to avoid detection. Since SNMP is often used to perform network management, SNMP_GET queries do not always trigger alerts. Therefore a few SNMP_GET commands at a time can fly under an IDS's radar. Of course, you should make sure SNMP is running before making any queries.
There are techniques we do not like to perform during our tests, but since we have seen them used in the real world, they are worth mentioning.
If you take down the host machine of the IDS sensor with a denial-of-service or buffer overflow attack, the IDS will not be able to identify what you are doing. However, this doesn't mean you are in the free and clear. While that sensor may not be able to detect future commands or exploits you run, many IDSs register a “Down Sensor” red alert for being unable to communicate with the victim sensor. Though this is not the same as the IDS identifying you by your host IP address, it should draw the attention of the security administrators, and they may investigate the situation while rebooting the machine. Denial of service against an IDS sensor is a risk, but there are ways to defend against it. System administrators can configure IDS sensors to be in stealth mode to avoid detection. In other words, the sensor can be placed in promiscuous mode and be managed out of band on a separate network interface card (NIC). The IDS may also be resistant to denial-of-service attacks to help ensure this type of attack would not be successful.
If you are not able to knock out the IDS sensor entirely, you can use the sensor itself to overload the system administrator who may be monitoring the system. This can be done by simply launching several (fake) attacks at the sensor, causing it to send a high number of alerts to the management console. The system administrators may then take these alerts to be false positives, given their unusually high number, and then disregard further alerts from the sensor.
Another aggressive technique to cover your tracks is to hack onto the machine where IDS logs are being stored and corrupt or delete the logs. Without the logs, there may be no record of an intrusion. This, however, poses its own difficulties. The logs are likely to be protected or stored on an out-of-band server. The permissions settings on log files may not allow any operations from users on remote hosts. The logs may be written to a machine not reachable over the Internet. This is another reason for out-of-band management and for storage of IDS logs on a separate server to guard against this scenario.
Just as we discussed a list of pointers for ways to avoid being detected by an IDS, there are also two things that we have seen that are almost sure to be detected.
Attacking services that aren't there. Be careful to find out the exact name and version of each service you are attempting to exploit. Each connection you make to a remote machine may be logged, so limit the number of connections to only those necessary. Go through all the preliminary steps, check to see which services are running, verify known bugs with the version of all running services, and finally try to exploit them. For example, first scan port 25 to see if the target is running sendmail. Once you are sure and you've find the version, then go ahead and try an exploit to which that version may be vulnerable.
Launching exploits at random. In our labs we see a great deal of random attacks. Several times we have found users trying to run exploits designed for operating systems that we don't have, such as IRIX or SCO UNIX. Remember, penetration testing is like a surgical strike, not a nuclear missile attack. Choose the tests you can run wisely and only after having gathered sufficient information.
We have mentioned ways to sidestep an IDS. In this section, we present the general criteria to consider when evaluating an IDS for purchase. Consider that if you are able to monitor every bit of traffic and analyze it, nothing will get by you. However, for large networks, this is not possible. Therefore, you are going to have to let some traffic get through without inspecting it. No matter how effective an IDS is, there is the chance that a hacker will get around it. What you need to do is limit that chance as much as possible. In this regard, simply by having an IDS installed on a network does not by itself make the network any more secure. It must be the right IDS for the network and properly configured to be effective.
Our approach is to examine a network to understand the kind and quantity of traffic that is likely to travel on it. You don't want this normal traffic to generate alerts. If you can understand the network traffic patterns, you can create rules specifically designed to omit normal traffic and allow you to capture the rest—which hopefully will include all hacker activity.
Keep the following 15 criteria in mind when designing an effective IDS.
Performs real-time monitoring. Most modern IDSs have this capability.
Can monitor all common types of traffic. The IDS should be able to monitor all commonly used protocols that may run on your network, such as telnet, FTP, RPC, DNS, SMTP, and so on. If your network is designed for a less common or proprietary network protocol, you may need to obtain an IDS that can be configured to understand and monitor that protocol.
Provides meaningful alerts and responses to events. The alerting capability should also include the ability to send an alert to the management console and a page or an e-mail to the security administrator. An X-window pop-up message on the administrator's machine is a good start. Additionally, an IDS's ability to make temporary changes to a firewall's rule set, terminate suspect sessions, or execute commands or scripts in response to detected network traffic can be very helpful for actively defending the network. This is a new area for IDSs, and not all available products can perform these types of activities.
Features a large and continually updated signature database. You will want an IDS with a large database of signatures and one that updates the signatures frequently to keep up with new attacks. An outdated IDS may be ineffective against more recent exploits. Updating the signature database is the vendor's responsibility, but you need to ensure the vendor will do this. These updates should still allow users as much flexibility as possible in creating their own rules. In other words, any customized or specially crafted rules should not be deleted when the signature database is updated.
Has the capability to log events. An IDS should be able to log captured activity, such as the alerts it generates and the actions it takes, as well as events it witnesses, such as successful connections. While there may not be an interest in logging all successful connections, such as telnet, FTP, SSH, and so on, the IDS should provide the option for performing session capture and playback or at a minimum the ability to capture the session handshake/logon portions.
Along these lines, the IDS should be able to examine packet headers of the various types of traffic it captured. As a bonus, if the IDS can allow the administrator to perform trend identification and traffic analysis, it can be helpful for developing a very efficient rule set over time.
If the IDS has the ability to write log files to separate machines, this may be even better since log files are often targets for hackers who want to cover their tracks.
Is fault tolerant. An IDS should not lose stored information if the host system crashes. This is important since some hackers may attempt to crash the host system in an effort to circumvent the IDS or corrupt the log files to remove evidence of their activities. Along these lines, the IDS should be able to monitor the sensors at all times and should trigger alerts if the sensor is down or is being inundated with network traffic. This can function as an early warning of a denial-of-service attack.
Can generate clear and useful reports. The IDS should be able to generate effective, easy-to-read, user-configurable reports. These reports should contain details (for example, a listing of attacks, source and destination IP addresses and ports, definitions of attack rules or signatures involved and recommended fixes, and so on) that can allow an administrator to view the data and explain it to others within the organization. Further, the ability to report on specific sessions, connections, and traffic from a particular IP address or domain is valuable. The format of the report (text document, comma-separated values, and so on) should also be configurable.
A reporting capability is not a reflection of an IDS's technical and functional usefulness, but a good reporting capability will go a long way in justifying to management the need for and use of an IDS. Further, it can present an overall view of the possible attacks being launched against your network, which can help identify areas of weakness and places where additional security measures should be taken.
Combines the network-based and host-based approaches. While there is overlap in the network- and host-based IDSs, they are aimed at protecting different assets, and therefore an overall system should combine both approaches. These sensors should report to a common management console so an administrator can view the entire network at once (or at least the portion for which that administrator is responsible).
Is able to process the quantity of traffic to which it will be exposed. The IDS needs to have the necessary technical resources (such as memory and processor speed) at its disposal in order to effectively monitor the network. Often, if the level of traffic grows beyond the IDS capability, it will simply let traffic pass without comparing it to its signature database—in which case, it will not be providing any security at all.
Is placed in the appropriate location on the network. Following the last point, the IDS sensors must be located where they will be able to see the traffic of interest in order to provide optimum network security. Finding the right place involves understanding which servers and segments of the network are critical, in terms of both business need and likelihood of attack. Network sensors should be placed inside choke points protecting such segments. Host-based sensors should be placed on the critical hosts or servers.
We are often asked, “Why not place network sensors in front of choke points so that the traffic and all alerts can be compared between the sensors in front of and behind the choke point?” Sensors in front of choke points tend to become overwhelmed with network traffic and flood administrators with alerts, more than they can ever follow up. By configuring the IDS to ignore false positives (alerts caused by normal or legitimate network traffic), you lose the benefits of comparing traffic in front of and behind the choke point.
A better scenario is to configure the filtering router or firewall that is the choke point to block and log unauthorized activity; the IDS behind it can then be used to catch anything that comes through. In this scenario, the administrator tends to get fewer alerts and is more likely to be able to follow up on them.
When placing an IDS sensor on a network segment with a very well-defined and limited type of traffic expected, such as a DMZ for a Web server expecting only HTTP traffic, system administrators may be tempted to configure an IDS to trigger on any other kind of traffic at all. The logic is that since other traffic is not anticipated, any occurrence of other traffic should generate an alert since it may be indicative of an attack. This may be true to some extent, and a sensor on such a network can have a broader rule set than usual. However, as a general rule, we do not recommend this since several IDSs do not function well at all if placed under too much load. Often, having to compare even a moderate amount of traffic with a very comprehensive set of signatures becomes too much of a processor load. Before such a sensor is configured, the processing capability of the IDS (and host on which it runs) must be evaluated.
For a network-based IDS, it is important to place the sensor in a location on the networks where it can view all the traffic on the wire. Switched networks, where traffic is directed only to its destination host, require a switch capable of spanning the ports or mirroring traffic onto a selected switch port or the use of VLANs so that the sensor can access the traffic it needs to monitor.
Features secure communication between sensors and the management console. Communication between a sensor and the management console should be secured through an encrypted tunnel, out-of-band management, or some other means. The IDS should support strong authentication between sensor and console with digital certificates or another secure method. If a hacker can compromise your IDS and gain administrator rights on a sensor or console, you are in deep trouble.
Is configured properly. An IDS is only as good as its configuration. An IDS straight out of the box is not usually very effective. You need to perform a large amount of configuration and fine-tuning to reduce the rates of false positives and false negatives. If the IDS is not properly configured to eliminate false positives, it will bury an administrator in so many false alerts that he or she may not be able to adequately follow up on them. In such cases, the IDS is not providing any network security at all.
Developing a good rule set for an IDS is definitely an iterative process. You will need to create a rule set and examine the IDS data for a period of time, modify the rule set to reduce false positives and false negatives, and go through the process numerous times. In truth, the IDS rule set will have to be updated periodically throughout the life of the system.
Also, the IDS should be able to escalate alerts based on the recurrence of events. For example, a single failed FTP session authentication should cause a low-level alert, three failed connection attempts to the same user account within a minute should be a mid-level alert, and ten attempts should be a red alert indicating a possible brute force attempt.
Is implemented in accordance with procedures that enforce proper monitoring and response to alerts. Once an alert is generated, there must be a proactive response to ensure that it is an attack, not a false positive, and to then respond to any real attacks. If proper response procedures are not developed an administrator may take incorrect action and waste resources, miss a legitimate attack, or damage forensics data.
Is implemented in a layered approach with firewalls and/or filtering routers. A firewall and an IDS act as a good one-two punch for securing networks.
Is regularly tested to verify the system is working as required. We recommend placing the IDS on regular testing cycles to verify its effectiveness.
In addition to the above, there are other issues that are worth mentioning but are beyond the scope of this book. Before selecting an IDS, it is important to consider its interoperability with previously existing technology. The labor needs with respect to implementation and ongoing maintenance of an IDS should be considered. Having a system that you are not able to fully understand or use is of little value. We have also not discussed the cost factor since cost often depends on the number of licenses purchased, the size of the deployment, and any service agreement reached with the vendor. All of these issues are important and must be considered before dedicating any resources and making a purchase.
Also, it is not the intention of this section to suggest or promote any one IDS over another. We simply present a set of criteria that can be used to assist in a purchase decision.
There are several IDSs currently available, both commercial and freeware. We discuss those listed in Table 19-1
URL: www.iss.net
Client OS: Windows NT/2000
Description: RealSecure, a commercial IDS produced by ISS, is currently the market leader for NT-based IDSs. In fact, it is the most popular IDS on the market as of the printing of this book. It has a straightforward, GUI-led installation process and a fairly comprehensive collection of IDS rules, which you can config ure by specifying the protocol, source and destination IP addresses, and ports to monitor. The current version of RealSecure has the capability of integrating network- and host-based IDS sensors to one management console. The management console lists all active and currently monitored sensors and individual windows for the low-, medium-, and high-priority alerts. It has another window in which alerts can be displayed in multiple ways, such as by severity, violated rule, server, or client involved.
Table 19-1. Commercial and Freeware Intrusion Detection Systems
| Software | Vendor | Web Site | Base OS |
|---|---|---|---|
| RealSecure | ISS | www.iss.net | Windows or UNIX |
| NetProwler | Symantec | www.symantec.com | Windows |
| Secure Intrusion Detection | Cisco | www.cisco.com | UNIX |
| eTrust Intrusion Detection | Computer Associates | www.cai.com | Windows |
| Network Flight Recorder | NFR | www.nfr.com | UNIX |
| Dragon | Enterasys Networks | www.enterasys.com/ids | UNIX |
| Snort | — | www.snort.org | UNIX |
RealSecure, when properly configured, can be an effective IDS. Its GUI allows you to modify the rule set and create your own rules. It also has documentation on each of the predefined rules. It has adequate reporting capability and is fault tolerant. Communication between the sensors and console is encrypted. It can also perform the basic responses to generate an alert, log the event, and send an e-mail or page to the system administrator. Further, it can be integrated with Check Point's FireWall-1 to temporarily close ports or drop certain connections.
RealSecure does have its drawbacks. It does not record or display packets that trigger an alert nor does it have a session playback capability. It does not have traffic analysis functionality built into it. Further, RealSecure has been known to drop packets when placed under heavy load.
URL: www.symantec.com
Client OS: Windows NT/2000
Description: Symantec also takes the approach of combining network- and host-based IDSs. The network-based product is called NetProwler and the host-based one is named Intruder Alert. Symantec has developed a patent-pending way to compare traffic to known signatures called Stateful Dynamic Signature Inspection (SDSI).
URL: www.cisco.com
Client OS: HP/UX and Solaris
Description: Secure Intrusion Detection was formerly known as NetRanger and was originally developed by The Wheel Group (before being purchased by Cisco Systems). It has a manager/sensor architecture in which the manager, called the Director, runs on an HP-UX or Solaris box and communicates with the sensor through a Web browser GUI interface. The sensor is a Cisco appliance. Secure Intrusion Detection, like the others, comes with its set of attack signatures and allows users to define their own signatures as well. However, Secure Intrusion Detection does not allow administrators to view the predefined signatures. This product can also be an effective IDS when properly configured. As a differentiator, this product can reassemble protocol packet (TCP/IP, UDP/IP) fragments. It has adequate reporting capabilities and event response capabilities, including alerts to the management console, e-mail or page to an administrator, and execution of a script or termination of a session when it sees a particular defined event.
The program does have its drawbacks as well, such as not allowing new rule creation on the fly and an inability to perform traffic analysis or session playback. While it issues an alert for a down sensor, it does not issue an alert if the sensor is becoming overloaded with traffic.
URL: www.cai.com
Client OS: Windows 9x/NT/2000
Description: The eTrust Intrusion Detection product by Computer Associates was previously known as Sessionwall-3 before its original maker, Abirnet, was purchased by Computer Associates. This product doubles as a network sniffer. (In fact, there are those who consider it primarily a sniffer rather than a network-based IDS.) eTrust Intrusion Detection is a part of a large suite of security products marketed by Computer Associates under the eTrust label. It is preconfigured with a limited number of rules; it doesn't allow administrators to view those rules, but it does allow users to develop their own rules specifying the protocol, source and destination IP address and port to monitor. As for responses, it can generate an alert to the console, but a script must be configured to send an e-mail to an administrator. It can be programmed to kick off a script if certain events occur and to block Web sites by URL.
eTrust is GUI operated, and the GUI presents a great deal of information, including a listing of all the hosts whose traffic it is monitoring and all the events that have occurred.
The events can be organized by the rule broken, by the service, or by the server or client involved. Also, there is a window in which the rule-violating packets can be displayed. This window can also graphically display (for example, with pie charts) the kinds of traffic generating alerts and their percentages of the whole.
Aside from this, the product doesn't have any significant traffic analysis functionality but does have session playback capabilities. It does at least capture a portion of the sessions that trigger an alert and present that portion of the data in ASCII, EBSIDIC, or HEX format.
eTrust will not send an alert if the sensor stops working for any reason, but it will provide a warning if it is becoming overloaded with traffic. If overloaded, eTrust becomes unstable and shuts down. eTrust has only limited reporting capabilities but does present fixes for known attack signatures. This product is available individually or as a part of a suite of security products, including integrated anti-virus capabilities.
URL: www.nfr.com
Client OS: Various UNIX OSs
Description: Network Flight Recorder (NFR), whose maker is also called NFR, is a market leader for UNIX-based IDSs. NFR also comes with a fairly comprehensive rule set and allows users to design their own rules through its GUI.
NFR can generate reports, but some reporting functionality is left to be desired. It can also perform the basic responses to generate an alert, log the event, and send an e-mail or page to the system administrator. It does, by contrast with RealSecure, have traffic analysis functionality built in, allowing administrators to perform trend identification, protocol monitoring, and network analysis.
There are drawbacks, as with any other IDS product. Since it is intended for the UNIX environment, it is harder to bring into an NT shop. A UNIX host would be needed as well as an administrator capable of managing it. And as is generally typical of programs that are based in UNIX as opposed to those based in the Windows GUI world, it is slightly more challenging to learn and administer.
NFR also does not record and display packets that trigger an alert nor does it have a session playback capability. NFR does not provide an alert if its sensor is being flooded by traffic, and traffic between the sensor and console is not encrypted.
Client OS: Linux, OpenBSD, FreeBSD, Solaris Sparc, Solaris x86, HP/UX, Windows NT 4.0/2000 (Dragon Squire only)
Description: The Dragon IDS has a network-based component called the Dragon Sensor and a host-based component called the Dragon Squire. These can be managed simultaneously by the Dragon Server. Dragon is a fairly sophisticated IDS in that it allows users to configure their own attack signatures in addition to the comprehensive collection of signatures the program provides. It also attempts to ascertain the success or failure of potential attacks after an alert has been set off. The maker also claims that this IDS is immune to IP fragmentation attacks.
The Dragon Squire product can peruse log files and collect SNMP information to detect possible attacks against host systems. It can be configured to monitor various logs, including logs received via SNMP or syslog, or logs of network devices such as the firewall. The Dragon Squire can also keep track of file information, including the last access time, file size, and its MD5 checksum. This can be used to help detect file tampering and Trojaned files.
URL: www.snort.org
Client OS: Linux, OpenBSD, FreeBSD, NetBSD, Solaris, SunOS 4.1.x, HP/UX, AIX, IRIX, Tru64, Mac OS, Win32
Description: Snort is a freeware IDS that is primarily for the UNIX operating system, but a Win32 build is also available. This IDS can perform protocol analysis and logging of traffic on the network. Snort is a bit more complicated than the traditional IDS; however, it is quite user configurable. Its alerting capabilities include traditional alerts on screen or through syslog, a UNIX socket, or even a Windows Pop-up message. The language in which its rule set is written is flexible and allows for the creation of additional rules. The detection engine (through which the traffic is compared to the IDS rule set) features a modular architecture allowing users to build on Snort's base functionality.
Snort on a fast host machine running in promiscuous mode is capable of catching most attacks. However, it may be unlikely that large organizations (with thousands of hosts) will have the ability to collect, much less analyze, every bit of traffic coming across their networks. Snort gives them this option and can be an effective IDS, especially for budget-conscious organizations.