19.1 IDS Examples

This section describes some different IDSs, including logfile monitors, integrity monitors , signature scanners , and anomaly detectors.

19.1.1 Host IDSs

Host-based network IDSs may be loosely categorized into log monitors, integrity checkers, and kernel modules. The following section will briefly describe each, with examples.

19.1.1.1 Logfile monitors

The simplest of IDSs, logfile monitors , attempt to detect intrusions by parsing system event logs. For example, a basic logfile monitor might grep (search) an Apache access.log file for characteristic /cgi-bin/ requests . This technology is limited in that it only detects logged events, which attackers can easily alter. In addition, such a system misses low-level system events, since event logging is a relatively high-level operation. For example, such a host IDS will likely miss an attacker reading a confidential file such as /etc/passwd . This will happen unless you mark the file as such and the intrusion detection system has the ability to monitor read operations.

Logfile monitors are a prime example of host-based IDSs, since they primarily lend themselves to monitoring only one machine. However, it is entirely possible to have a host IDS monitor multiple host logs, aggregated to a logging server. The host-based deployment offers some advantages over monitoring with built-in system tools, since host IDSs often have a secure audit transfer channel to a central server, unlike the regular syslog. Also, they allow aggregation of logs that cannot normally be combined on a single machine (such as Windows event logs).

In contrast, network-based IDSs typically scan the network at the packet level, directly off the wire, like sniffers. Network IDSs can coordinate data across multiple hosts . As we will see in this chapter, each type is advantageous in different situations.

One well-known logfile monitor is swatch (http://www.oit.ucsb.edu/~eta/swatch/), short for "Simple Watcher." Whereas most log analysis software only scans logs periodically, swatch actively scans log entries and reports alerts in real time. Other tools, such as logwatch (included with Red Hat Linux), are better suited for out-of-the-box operation. However, although swatch comes with a relatively steep learning curve, it offers flexibility and configurability not found in other tools.

The following describes the swatch installation. This tool is fairly stable, so these directions are not likely to change in the future. Before installing swatch, you may have to download and install Perl modules that are required for swatch. To install the modules, first download the latest version of swatch, then run the following:

 perl Makefile.PL make make test make install make realclean 

swatch uses regular expressions to find lines of interest. Once swatch finds a line that matches a pattern, it takes an action, such as printing it to the screen, emailing an alert, or taking 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 word "denied", " Denied ", or anything that starts with "den" and ends with "ed". When swatch finds a line that contains one of the these strings, it echoes the line in bold to the terminal and makes a bell sound (^G) three times. Then, swatch emails the user running swatch (who should have permission to access the monitored logfiles ”this often limits the choice to root) with the alert and executes the /etc/call_pager program with the given options.

Logfile monitors can justly be considered intrusion detection systems, albeit a special kind. Logs contain a lot of information not directly related to intrusions (just as network traffic sniffed by the network IDS does). Logs may be considered a vast pool of information ”some normal (authorized user connected, daemon reconfigured, etc.), some suspicious (connection from remote IP address, strange root access, etc.), and some malicious (such as the RPC buffer overflow logged by the crashing rpc.statd). Sifting through all the information is only a little easier than sniffing traffic looking for web attacks or malformed packets.

If every application had a nice security log where all "bad" events were recorded and categorized, log analyzers would not be considered intrusion detection systems. In fact, if an event were to show up in this magical log, it would be an intrusion. In real life, however, pattern searches in logs are often just as valuable ”if not more so ”as looking for patterns on the wire.

In fact, analyzing system logs together with network IDS logs is a useful feature in a log analyzer. The log analyzer sees more than just the wire and creates a meta-IDS functionality. For example, management solutions such as netForensics enable cross-device log analysis, normalization and correlation (rule-based log pattern matching), and statistical (algorithmic) event analysis.

19.1.1.2 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 are limited, integrity monitors can add an additional layer of protection to other forms of intrusion detection.

The most popular integrity monitor is Tripwire (http://www.tripwire.com). Tripwire is available for Windows and Unix, and it can monitor a number of attributes, including the following:

• File additions, deletions, or modifications

• File flags (i.e., hidden, read-only, archive, etc.)

• Last access time

• Last write time

• Change time

• File size

• Hash checking

Tripwire's capabilities vary on Unix and Windows due to differing filesystem attributes. Tripwire can be customized to your network's individual characteristics, and multiple Tripwire agents can securely centralize the data. In fact, you can use Tripwire to monitor any change to your system. Thus, it can be a powerful tool in your IDS arsenal. Many other tools (most are free and open source) are written to accomplish the same task. For example, AIDE (http://www.cs.tut.fi/~rammer/aide.html) is a well-known Tripwire clone.

The key to using integrity checkers for intrusion detection is recording a "known safe" baseline. Establishing such a baseline can only be accomplished before the system is connected to the network. Not having a "known safe" state severely limits the utility of such tools, since the attacker might have already introduced her changes to the system before the integrity-checking tool was run the first time.

While most such tools require a baseline pre-attack state, some use their own knowledge of what constitutes malicious . An example is the chkrootkit tool (available at http://www.chkrootkit.org). It looks for multiple generic intrusion clues, which are often present on the compromised system.

Integrity checkers provide maximum value if some simple guidelines are met. First and foremost, they should be deployed on a clean system, so they have no chance of recording a broken or compromised state as normal. For example, Tripwire should be installed on a system from the original vendor media with all the needed applications deployed, before it is connected to a production network.

Also, storing "known good" databases of recorded parameters on read-only media, such as CDROMs, is a very good idea. Knowing that there is one true copy for comparison helps greatly during incident resolution. Despite all of these precautions , however, hackers still might be able to disable such systems.

19.1.2 Network IDSs

Network IDSs may be categorized into signature-based and anomaly-based systems. Unlike the former, more well-defined category, the latter are a mix of different technologies and approaches. Additionally, hybrid NIDSs aim to bridge the gap by using some of the tricks employed by each of the above types of NIDSs. In fact, most modern commercial NIDSs use some of the anomaly-based techniques to enhance the main signature-based engines. Examples included ISS RealSecure, Cisco IDS, and Enterasys Dragon.

19.1.2.1 Signature matchers

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 (http://www.Snort.org), 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 signatures are used in everything from commercial firewalls to middleware such as Hogwash. 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.

Some readers might be more used to a concept of stateful and stateless firewalls rather than network intrusion detection systems. However, the principle is the same. Stateless firewalls (and NIDSs) deal with individual packets in isolation, while stateful ones consider the state of the actual connection. The simplest example is as follows : if an attack is split across multiple packets, it will be missed by the stateless IDS (since the overall malicious patterns will never be seen in one packet). It will, however, be picked up by a stateful one, which attempts to match the pattern not in any single packet, but rather in the flow of the whole connection.

However, even stateful NIDSs can be evaded. We provide some examples of this later in the chapter.

A classic example of a signature that an IDSs detects involves web attacks, such as on vulnerable 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 document. This attack will use a poorly written CGI script to access the files outside the allowed web server directory. To detect a phf attack, a network IDS scanner would search packets for part of the following string:

 GET /cgi-bin/phf? 

Network IDSs will look at existing signatures, trying to match the above string detected in a network packet. For example, the following Snort signature will match with the above:

 alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"WEB-CGI phf  access";flow:to_server,established; uricontent:"/phf"; nocase; reference:bugtraq,629;  reference:arachnids,128; reference:cve,CVE-1999-0067; classtype:web-application- activity; sid:886; rev:8;) 

and the alert will be sent.

We provide a full Snort NIDS deployment example later in this chapter.

19.1.2.2 Anomaly detectors

Anomaly detection involves establishing a baseline of "normal" system or network activity, and then sounding an alert when a deviation occurs. Since network traffic is constantly changing, such a design lends itself more to host-based IDSs, rather than network IDS. However, some networks ( especially some in the military and the intelligence community) might be extremely uniform. In contrast, the activity on a large university shell server might be incredibly diverse, so that the network is much more chaotic . It should also be noted that sometimes people try to separate the anomaly-based NIDSs into traffic anomalies (deviations from a known traffic profile) and protocol anomalies (deviations from network protocol standards).

As we will see later in this chapter, anomaly detection provides high sensitivity but low specificity. Later, we will discuss where such a tool would be most useful.