Getting the Most Out of Your IDS

To realize the true potential of an intrusion detection system, you need to do several things both before and after installation.

Proper System Configuration

If you just install an IDS and turn it loose with a default configuration, you will be quickly deluged with thousands of false positive alerts. While you can fine-tune your system after the fact, you will save a lot of time and effort by taking the time to carefully configure it beforehand. Don't just accept the default settings; customize these for your LAN.

Most intrusion detection systems group alerts into categories. Take a look at each group to see if it is relevant to your network. If there is a group of UNIX-based signatures but you don't have any UNIX systems on your network, you can probably safely turn off that whole batch of alerts. Some have policy-type alerts looking for things like instant messaging use or peer-to-peer software use. If you already have systems that filter these types of activities or you allow these activities, go ahead and deactivate them. You should go over the alert groups in detail. While you may want most Windows-based alerts, there will be some that are either irrelevant to your network or will cause false positives.

You can also exempt some hosts from examination. If your personal machine constantly does SNMP polls across your network or you are constantly logging in as administrator, it might generate more alerts than it is worth protecting. While this does lower the level of protection provided and might leave a critical machine unprotected, it may make your IDS more effective and be worth the risk. Taking a few hours up front to carefully configure your system before you activate it could save you a lot of time and frustration in the future. If you are going to the trouble and expense of running an IDS, it is worth taking the time to do it right.

IDS Tuning

Once it is up and running, even a meticulously configured IDS will start to generate alerts. Early on, if you take the time to analyze them and start to deactivate the rules that don't matter for your network, you can quickly lower the number of false positives your IDS is outputting. It will also give you insight as to how your network is working and what kind of traffic is going over it, which is helpful for any network manager. Plan some time each week to modify your IDS settings. Some systems make it relatively easy to mark an alert as false positive while others make you jump through some hoops. On average it takes a few months before an IDS is tuned to the point that it puts out useful alerts on actionable activity—and that's with a fairly dedicated fine-tuning effort.

IDS Analysis Tools

Intrusion detection systems typically offer administrators several different methods of being notified of an alert. At its most basic level, the alerts can simply be sent to a log file for later review. This is not really recommended, as it requires the administrator to be vigilant about reviewing the logs. If it is not monitored on a daily basis, then days or weeks can go by before discovering intrusion attempts. The other alternative is to send an e-mail or page the appropriate person whenever an alert is generated. However, even on a well-tuned system, it can become overwhelming to be receiving pages several times a day. Additionally, the e-mail alerts would not be in a format in which they can be compared to past alerts or analyzed in any way. The best way to handle IDS alerts is to port them immediately into a database to allow deeper analysis. There is an open source tool for intrusion detection systems called Analysis Console for Intrusion Detection (ACID). This tool is covered in more detail in Chapter 8.

Now that you know how Intrusion Detection Systems work, let's build one and put it to work.

Snort is Martin Roesch's baby, though it has grown far beyond his authorship and now counts some 30 plus developers in its core team, not including those writing rules and other parts of the software. As you can see from the lists above, there are many resources available for Snort. And these are just the free online resources. There are also several full-length books on the subject. This section, while not doing true justice to the subject, covers the basics and gets you up and running with Snort.

Snort is mostly a signature-based IDS, although with the addition of the Spade module Snort can now do anomalous activity detection. There are also add-on modules such as Inline Snort that allow Snort to act upon any alerts automatically.

Unique Features of Snort

Installing Snort

As a prerequisite, you need the libpcap package installed. If you've loaded any of the previous packages from Chapters 4–6, you will already have libpcap installed. If not, you can download it from www.tcpdump.org.
Once you have those libraries loaded, simply take the file off the CD-ROM that accompanies this book or download the latest version from the Web site.
When it is on your machine, unzip it and issue the compile commands:
```
./configure

make

make install
```

Running Snort

Snort is run from the command line. You can run Snort in three different modes: packet sniffer, packet logger, and IDS mode. Most people run it in the latter to get the IDS benefits, but there are uses for the first two.

Packet Sniffer Mode

In this mode, Snort acts just like a sniffer, showing you the unfiltered contents on the wire. Of course, if all you needed was a sniffer, you could just use Tcpdump or Ethereal. However, packet sniffer mode is good for making sure that everything is working correctly and Snort is seeing packets. Table 7.1 lists switches you can use when running Snort in this mode. You must include at least the -v command when using the packet sniffer mode, or else Snort defaults to running in one of the other modes (packet logging or intrusion detection) and expects other options.

Table 7.1. Packet Sniffer Mode Options
Options	Descriptions
-v	Prints the packet headers of TCP/IP packets on the Ethernet to the screen.
-d	Same as above but also displays the application layer data.
-e	Same as above but also prints the data link layer.

at a command prompt. You will see output similar to the sniffers used in the previous chapter. Press Control+C to exit and you will see a summary of the packet sniffing session.

Hardware Requirement for Your NIDS

There are a couple of things to take into consideration when selecting the hardware to run your NIDS on. Because detection systems tend to be fairly processor- and disk-intensive, it is strongly recommended that you run the NIDS on a box dedicated solely to that purpose. However, being Linux-based, it still doesn't require much hardware compared to what an equivalent Windows machine would need. This assumes you are not running X-Windows, which can take a considerable amount of processor power and is not really needed for the Snort IDS.

To run Snort, you should have a 500MHz Intel processor, although I have run Snort boxes reliably on 266MHz PCs. If you are storing log files locally, you will also want at least several gigabytes of available hard drive space. A 100Mbps network card should be used to eliminate any bottlenecks if you are going to be sniffing on a 100Mbps network. The authors of Snort claim that the code will handle up to a saturated 100Mbps segment without dropping any packets, and I haven't seen anything to rebut these claims. However, if your network is that busy, you should probably up the hardware requirements a little to perhaps a 1GHz processor. Either way, these requirements should be easy to meet with all but the oldest machines.

Packet Logging Mode

This is similar to packet sniffer mode, but it lets you log sniffed packets to disk for future use and analysis, like the logging functionality found in the sniffers described previously. To run snort in packet logging mode, simply run it with the same command as packet sniffer mode (-v, -d, and/or -e) but add an additional switch, -l logpath, where you replace logpath with the path you want Snort to log the packets to. For example:

This will create log files in the /var/log/snort directory. Make sure the directory you specify has been created or the program will not load properly. Snort logs packets by IP address and creates a separate directory for each IP logged. If you are logging traffic on a large local network with a lot of addresses, this can quickly get out of hand. Therefore you can use another setting to tell Snort to log packets relative to the home network you are on. You do this with the -h homenet command, where homenet is the IP address ranges in slash notation of your local network. This makes Snort put them in directories based on the nonlocal IP address in the packet, so you can see nonnative traffic easier. If both the destination and the source hosts are local, Snort puts it in the directory with the higher port number, ostensibly to pick the connecting host over a server host. If there is a tie, then Snort defaults to using the source address as the directory to put the packet data in. This may not seem important now, but when you are logging intrusion alerts, it is important to easily tell where the alert flagged traffic is coming from.

You can also use the -b option to log all the data into a single binary file suitable for reading later with a packet sniffer such as Ethereal or Tcpdump. When logging this way, you don't need to specify your home network when using the –b switch, since it will be logging files sequentially into one big file. This method is a lot faster for logging busy networks or slower machines. It also facilitates analysis with more complex tools, which is necessary if you are going to be looking at a large amount of network capture data.

Intrusion Detection Mode

This mode uses Snort to log packets that are suspicious or warrant some further attention. You need only one additional switch to the statement above to put Snort into this mode. This is the -c configfile switch, which tells Snort to use a configuration file to govern what packets it logs. The config file determines all the settings for Snort and is a very important file. Snort comes with a default config file, but you will want to make some changes to it before running it to reflect your environment. So by typing

you will be running Snort in IDS mode using the default snort.conf configuration file. Be sure that the config file exists in the specified directory (/etc/snort/snort.conf) or change the path to reflect its location on your system.

Notice that I didn't use the -v switch for running Snort in IDS mode. When trying to compare all packets with signatures, forcing Snort to also write alerts to the screen may cause it to drop some packets, especially on busier networks. You can also leave off the -e switch to improve performance if you don't need to log the data link layers. If you leave off the –l switch, Snort will default to using /var/log/snort as its logging directory. Again, make sure that the directory exists or Snort won't start. You could also use the –b switch if you wanted to log to a binary file for analysis with a separate program later. The command for running Snort in IDS mode now looks like this:

Snort Alert Modes

Now that you are logging alert packets, you need to decide how much detail you want and what format you want the alert data in. Table 7.2 lists options you can use from the command line using the -A switch.

Table 7.2. Snort Alert Mode Options
Options	Descriptions
-A full	Full alert information including application data. This is the default alert mode and will be used when nothing is specified.
-A fast	Fast mode. Logs only the packet header information and the alert type. This is useful on very fast networks, but if you need more forensic information, you should use the `full` switch.
-A unsock	Sends the alert to a UNIX socket number that another program can be listening on.
-A none	Turns the alerts off.

There are also the syslog, smb, and database output options, but these don't use the -A switch from the command line. They use separate output modules and offer a wider variety of output options. These must be configured at compile time with switches added to the configure statement.