Going on the Defensive: Intrusion-Detection Systems
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
An intrusion-detection system (IDS) attempts to automate the recognition of hacker attack and penetration. Although the technology has not yet shown that it can produce a statistically significant return on investment, IDSs continue to grow in popularity. However, as the use of IDSs grow, attacks against them grow as well.
In this article, we review existing IDS technologies and will show you how to attack them. The purpose is to help you understand inherent weaknesses of IDSs so that you can implement the technology more appropriately in your layered security policy. In addition, we show how threats against IDSs are forcing their evolution into host-based, strict anomaly detectors.
Types of IDSs
IDS systems come in multiple flavors, ranging in complex enterprise-size systems to smaller single-host sizes. Regardless of the level of complexity, IDSs all share the same general operational characteristics. This section breaks down the different types of IDSs available and discusses their methods of operation.
Log File Monitors
The simplest form of an IDS is a log file monitor, which attempt to detect intrusions by parsing system event logs. For example, a basic log file monitor might grep (search) an Apache access.log file for characteristic /cgi-bin/ requests. This technology is limited, in that it detects only logged events, which attackers can easily alter. In addition, such a system will miss low-level system events because event logging is a relatively high-level operation. Example 1 illustrates the log of a real CGI scan against a Web server.
Example 1: Sample Log Generated by cgi-scan Attack Script
127.0.0.1 - - [14/Aug/2002:09:48:14 -0400] [ccc] "HEAD /cgi-bin/test-cgi HTTP/1.0" 404 0 127.0.0.1 - - [14/Aug/2002:09:48:14 -0400] [ccc] "HEAD /cgi-bin/nph-test-cgi HTTP/1.0" 404 0 127.0.0.1 - - [14/Aug/2002:09:48:14 -0400] [ccc] "HEAD /cgi-bin/phf HTTP/1.0" 404 0 127.0.0.1 - - [14/Aug/2002:09:48:14 -0400] [ccc] "HEAD /cgi-bin/phf.pp HTTP/1.0" 404 0 127.0.0.1 - - [14/Aug/2002:09:48:14 -0400] [ccc] "HEAD /cgi-bin/phf.cgi HTTP/1.0" 404 0 127.0.0.1 - - [14/Aug/2002:09:48:14 -0400] [ccc] "HEAD /cgi-bin/websendmail HTTP/1.0" 404 0
Log file monitors are a prime example of host-based IDSs because they primarily lend themselves to monitoring a computer system at the host level. In other words, a host-based IDS detects changes to file systems, log files, and applications on each computer. Typically, a central IDS server then receives updates from each host as changes occur (see Figure 1).
In contrast, network-based IDSs typically scan the network at the packet level, much like a sniffer. This allows the IDS to monitor all the data passing over a network, and it can detect hacker activity by comparing the data to a set of rules. By doing this, the IDS does not need to interact with every computer on the network—only those that are sniffing data. In addition, a network-based IDS can have multiple logging systems spread out over the entire network to comprehensively monitor all legs.
)
Figure 1 Network-based IDS vs. host-based IDS.
One well-known log file monitor is Swatch, short for Simple WATCHer. Whereas most log analysis software scans the logs periodically (at best), Swatch can actively scan log entries in real time, which also results in real time alerts.
To install Swatch, first download the latest version. Then run the following:
perl Makefile.PL make make test make install make realclean
After Swatch is installed, you might also have to download and install Perl modules that are required for it.
Swatch uses regular expressions to find lines of interest. When Swatch finds a line that matches a pattern, it prints it to the screen, e-mails an alert, or takes a user-defined action.
The following is an excerpt from a sample Swatch configuration script:
watchfor /[dD]enied|/DEN.*ED/ echo bold bell 3 mail exec "/etc/call_pager 5551234 08"
In this example, Swatch looks for a line that contains the words denied or Denied, or anything that starts with DEN and ends with ED. When it finds a line that contains one of the three search strings, it echoes the line in bold on to the terminal and makes a bell sound (^G) three times. Then Swatch e-mails the user that is running Swatch (usually root) with the alert and executes the /etc/call_pager program with the given options.
Integrity Monitors
An integrity monitor watches key system structures for change. For example, a basic integrity monitor uses system files or registry keys as "bait" to track changes by an intruder. Although they have limited functionality, integrity monitors can add an additional layer of protection to other forms of intrusion detection.
The most popular integrity monitor is Tripwire, available for both Windows and UNIX. It can monitor a number of attributes, including the following:
File additions, deletions, or modifications
File flags (hidden, read-only, archive, and so on)
Last access time
Last write time
Create time
File size
Hash checking
Tripwire can be customized to your network's individual characteristics. In fact, you can use Tripwire to monitor any change to your system. Thus, it can be a powerful tool in your IDS arsenal.
Signature Scanners
Like traditional hex-signature virus scanners, the majority of IDSs attempt to detect attacks based on a database of known attack signatures. When a hacker attempts a known exploit, the IDS attempts to match the exploit against its database. For example, Snort is a freeware signature-based IDS that runs on both UNIX and Windows.
Because it is open source, Snort has the potential to grow its signature database faster than any proprietary tool. Snort consists of a packet decoder, a detection engine, and a logging and alerting subsystem. Snort is a stateful IDS, which means that it can reassemble and track fragmented TCP attacks.
A classic example of a signature that IDSs detect involves CGI scripts. A hacker's exploit-scanning tools usually include a CGI scanner that probes the target Web server for known CGI bugs. For example, the well-known phf exploit allowed an attacker to return any file instead of the proper HTML. To detect a phf attack, a network IDS scanner would search packets for part of the following string:
GET /cgi-bin/phf?
When this string is detected, the IDS would react according to its preprogrammed instructions. Because this is a basic CGI scanner query, the danger level is medium, at most. However, if the IDS detected the following string:
cgi-bin/phf?Qalias=x%0a/bin/cat%20/etc/passwd
...and it resulted in a log entry as follows:
GET /cgi-bin/phf?Qalias x%0a/bin/cat%20/etc/passwd HTTP/1.0" 200 267
...then the problem just got more serious. Now, instead of an attack from a nosy script kiddie, you have a Web server that is vulnerable to the phf exploit. By looking at the log file, you can see that the phf query returned a successful 200, which means that the passwd file was just written to the hacker's screen.
Anomaly Detectors
Anomaly detection involves establishing a baseline of "normal" system or network activity and then sounding an alert when a deviation occurs. Because network traffic is constantly changing, such a design lends itself more to host-based IDS than network IDS. Anomaly detection provides high sensitivity but low specificity. Thus, it is most useful on absolutely critical (yet fairly static) machines in your network, such as a Web server. In such a situation, when the anomaly detector reports any change from baseline activity, it requires human investigation. Thus, this high sensitivity comes with an accordingly high price in terms of human input.