Seven Steps to A Working Intrusion Detection System

Using tcpdump

As more organizations rely on the internet for both communications and electronic commerce, system administrators, CIOs and business executives increasingly share a common worry. Their joint concern is that malicious people may be using the internet to launch attacks on their computers and that those attacks could do great damage to their organization.

With that knowledge the organizations have been able to tune their firewalls and system protection strategies based on information, instead of on guesses.

The early adopters of intrusion detection systems crafted their own unique tools, but now some of the pioneers in intrusion detection are joining forces to perfect a common library of public domain tools to automate the process Their goal is nothing less than a new "cops for the network." (cops is a widely-used public-domain utility that helps identify system vulnerabilities.) Their new tool, called "cid" (for cooperative intrusion detection), automates the process of information gathering and traffic analysis for intrusion detection.

A cid-based intrusion detection capability can be deployed using freely-available software and existing hardware or hardware that can be purchased for less than $10,000. And cid complements and enhances the impact of commercially available intrusion detection systems.

Overview of the cid architecture

A cid system is based on two computers: one for the sensor and one for the analysis station. In this design, both systems are UNIX-based.

Step 3. Configuring the Sensor

In this section, we describe the actions necessary to install programs that support tcpdump and allow it to run. They include cron, tcpdump.driver.sh, start_logger.sh and stop_logger.sh.

Step 4. Set up the Analysis Station

In this section we describe methods for getting the data from the sensor to the analysis station securely

Step 5. Use tcpdump and its filters

This section is a step-by-step guide for learning the language you will use to control tcpdump's filtering activities. To get the most out of your system you will want to be able to customize your filters.

Tcpdump can operate in two modes: raw packet collection and packet filtering. The sensor merely reads the raw packets from the network and saves them into a file. The analysis station reads the packet files and applies filters to look for specific patterns. Lets take a look at examples of simple filters that we have found to be useful. Simple filters can be strung together with "and", "or" and so forth to make a more complex filter. We will also have an example of a complex filter.

NOTE: This is a good point to advise readers that a beginning intrusion detection analyst should be very slow to panic! IMAP, PORTMAP and so forth are common attacks, but are also commonly used services. Take some time to learn how your site does business network wise. Of course, once you start looking, it is probable that you will detect some attempted attacks.

Example 5.1: Simple filter to detect telnets.

Example 5.2 A filter for IMAP.

Example 5.3 ICMP filter

Here is another simple filter from the tcpdump man page to look for all ICMP packets that are not echo requests/replies (i.e., not ping packets).

Example 5.4 Construct a filter to detect broadcasts:

Example 5.5 Land attack filter

Speaking of denial of service, it turns out that some computer systems will freeze if they receive a packet in which the source address is spoofed to be the same as the destination address. Here is a filter to detect this:

Example 5.6 A filter designed to detect SNMP

Example 5.7 A filter to watch for the r-utilities:

Example 5.8 A filter to detect access to portmapper:

Example 5.9 An NFS filter

NFS is a good service to keep an eye on, and here is a filter to do it:

Example 5.10 A NetBIOS filter.

Microsoft Workgroup for Windows, Windows 95, Windows NT and SAMBA all use a protocol called NetBIOS to communicate over the internet. This protocol uses ports 137, 138, 139 of both TCP and UDP. Let’s build this filter one part at a time:

Example 5.11 Construct a bad_events filter.

Sophisticated filters can be constructed to scan for any set of events you want to detect. For example, here’s a portion of a script called "bad_events" that is used to detect any packets that could indicate suspicious activity that might warrant further attention. This filter might be an excellent start towards implementing an intrusion detection capability at your site.

If you find the filter syntax to be a bit tricky, you’ll need access to a book called Internetworking with TCP/IP Volume I by Douglas E. Comer, before you can do anything really fancy. The book will be a good investment for your organization. In fact someone probably already has it, so try to borrow one until your copy comes in.

Step 6. Display the information for maximum analytical value

Let’s consider what you have done so far. You have set up the sensor in the DMZ. You have collected data; yes, a lot of data. You have examined this data with filters.

Sadly, when the files get very large, it takes increasingly large amounts of time to parse the files with filters. And when tasks take time and effort, many people just quit doing those tasks. For this reason, how we display the information is every bit as important as what we filter for.

Step 7. Implement more advanced analytical capabilities.

There is a lot more to intrusion detection than looking for a few bad events. So how can we improve the capability of our system?

Example 7.1 A filter to detect all non-smtp or domain accesses to your mail and name server (DNS) hosts:

Example 7.2 A bad hosts filter.

After you detect an attack from a host, you will want to add it to a bad hosts list. Working through the SANS Institute, you may be able to find organizations that are in similar, or complementary lines of work as yours, and with whom you can share attack information.

Here a is filter that can help you do this, of course you have to add your own bad hosts.

Action 7.3 Reduce the data volume

We have found there is a practical limit to the analysis that can be performed with filters. Also, tcpdump collects a LOT of data. In order to perform more advanced analysis, it is necessary to reduce the data. We do this in two steps.

Our first step is to convert from hourly to daily files. We do this because, in comparing historical information, delays are created by the overhead involved in opening and closing hourly files. Here’s how we do conversion an dreduction.

Next, we extract the various protocols we are interested in as part of the data reduction. At our site the primary protocols in use are: TCP, UDP, ICMP, IGMP and IGRP. To extract UDP into an ascii file for further processing:

Then we run a simple test on the data, from time to time we find some interesting IP traffic that is not one of the protocols.

While it is important to know how to do all these things, it does get monotonous so we have included consolidate.pl to take all the hourly files and produce daily files from them.

Finally, in order to compare results over time, we convert the protocol files to bcp format using translate.pl. Another advantage of converting files to this format is that its universal format allows us to integrate data from different kinds of sensors.