8 steps to a working Linux Intrusion Detection System (SHADOW)

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD><TITLE>Eight Steps to A Working Intrusion Detection System</TITLE> <META content="text/html; charset=windows-1252" http-equiv=Content-Type> <META content="MSHTML 5.00.2919.6307" name=GENERATOR></HEAD> <BODY link=#0000ff vLink=#800080> <DIR>

Section 3: Installing SHADOW
Step 1: Acquiring the software for the SHADOW System

<DIR>

The software is available at no cost from the Lawrence Berkeley Research Laboratory and the Naval Surface Warfare Center Dahlgren Division.

Action 1.1. (optional) Download tcpdump and related software from: <A href="ftp://ftp.ee.lbl.gov/">ftp://ftp.ee.lbl.gov</A>. These files are also included in the SHADOW code located in the accessories directory.

The main program will be labeled tcpdump.tar.Z. Make sure you also get libpcap, (libpcap.tar.Z), since that is how the Unix system gets the network information from its kernel. You will also want tcpslice (tcpslice.tar.Z). These software packages have been made available by the Network Research Group at the Lawrence Berkeley Laboratory. Both the sensor and the analysis station require tcpdump and libpcap.

Action 1.2 Acquire secure shell. A copy of the most recent release is also included in the SHADOW code accessories directory.

If you are not already using secure shell, visit the "getting started with secure shell" home page at <A href="http://ns.uoregon.edu/pgpssh/sshstart.html">http://ns.uoregon.edu/pgpssh/sshstart.html</A> to obtain the software.

Action 1.3 Obtain the Shadow code. The remaining intrusion detection software is available at:

http://www.nswc.navy.mil/ISSEC/CID/step.tar.gz

Action 1.3 Download and build Apache. A copy of the most recent release is also included in the Shadow code accessories directory.

The Apache web server code is included in many Unix distributions, but it is probably a good idea to download the latest code from the Apache software distribution.

<A href="http://www.apache.org/">http://www.apache.org</A>

</DIR></DIR>

=======

IMPORTANT NOTE: Appendix A has Red Hat 5.1 installation instructions for either a sensor or analysis system.  If you need greater detail than provided in step’s 2 – 4 you may wish to consult Appendix A.

======

<DIR>

Step 2. Build the sensor.

The first system to build is the hardware/software facility that will serve as the sensor.

<DIR>

Action 2.1 Obtain a computer running Unix. Tcpdump compiles on multiple Unix systems, if the network you are protecting doesn't have a great deal of traffic, older "obsolete" workstations may be ideal. One group responsible for protecting multiple sites was able to collect a large number of Sun sparc II "pizza boxes". They fit nicely in the equipment racks and were able to handle up to full T1 speeds quite well. However if you have a high traffic network you should consider using FreeBSD or BSDI Unix. FreeBSD is considered the fastest, or most efficient, free platform for a Shadow sensor due to FreeBSD's implementation of BPF (Berkeley Packet Filter). You should have at least 32MB of RAM and 9 GB of disk space. The machine should be dedicated to running the intrusion detection software.

Action 2.2 Partition a large disk.

Since the primary purpose of the system is to collect data you want the /LOG partition to be as large as possible.

Action 2.3 Build libpcap.

We start with libpcap. The Unix command to unpack the software is:
$ uncompress libpcap.tar.Z

The result of this operation should be a file called libpcap.tar. Next, type:
$ tar xf libpcap.tar

Unpack all the files that came in the software distribution and place them in the directory you are working in. Then compile libpcap. Read the documentation that came with the software. The highpoints are to run configure and make.

Action 2.4 Compile tcpdump. Follow the same steps as in Action 2.3 to uncompress, extract the tar file, configure and make to build tcpdump.

Action 2.5 Compile tcpslice. Follow the same steps as in Action 2.3 to uncompress, extract the tar file, configure and make to build tcpslice.

</DIR></DIR>

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.pl, start_logger.pl and stop_logger.pl.

Action 3.1 Partition a large disk. Since the primary purpose of the system is to collect data you want the /LOG partition to be as large as possible.

Action 3.2 Unpack the Shadow tar file. The files in the sensor directory are needed to build the sensor. Copy these files to the sensor's /usr/local/logger directory.

Action 3.3 Secure the sensor. The sensor will be located outside the firewall and the sensor programs run as root. Disable all network services except secure shell. The Shadow programs expect secure shell to be present for secure file transfer. The latest version of secure shell is included in the accessories subdirectory of the Shadow distribution. Make sure all available security patches for your system are installed. If you are unsure about what security patches are needed, a good reference site to check is <A href="http://www.iss.net/xforce/">http://www.iss.net/xforce/</A>. The sensor should only be reachable by the analysis system and perhaps a backup trusted system! The sensor operating system should have the minimal possible information about the internal network. Check /etc/hosts, /etc/hosts.equiv, /etc/networks, /.rhosts yellow pages and any other files that might have configuration information about your network.

Action 3.4 Configure cron. The Unix scheduling system, named cron, automatically runs programs, often shell or perl scripts, at a certain time. A file sensor_crontab is included in the SHADOW distribution tar ball. Its contents:

17 23 * * * /usr/local/bin/msntp -r time-a.nist.gov
18 23 * * * /sbin/hwclock --systohc
0 * * * * /usr/local/logger/tcpdump.driver.pl > /dev/null 2>&1

The first entry instructs cron to run a program msntp at 17:23 each day. Msntp is a simple NTP (Network Time Protocol) utility that allows time synchronization of the local machine with a reliable NTP timeserver, without all the complexity of a full NTP implementation. The msntp-1.5 tar ball is included in the accessories subdirectory of the SHADOW distribution. The second entry of the crontab is Linux specific. It sets the hardware clock of the machine to the value of the Linux system time, which was previously synchronized with a reliable time source. Non Linux systems may not require this entry. The final entry tells cron to execute a Perl script named tcpdump.driver.pl at the zero minute of every hour.

Action 3.5 Review the activities of tcpdump.driver.pl. This is the program, run every hour by cron, that sets up some variables, calls one Perl script to stop the current tcpdump process and calls another Perl script to start tcpdump again.

Stop_logger.pl is the Perl script that stops the currently running tcpdump process. At that point, the previous hour's tcpdump records have been written to a file named with the date and hour of its creation. Experience shows that one hour is a long time to run tcpdump. Now that we have stopped the logger, we must start it again with a new hourly file. This is what start_logger.pl does.

Action 3.6 Test the tcpdump.driver.pl script. Run the script from the command line. Check the process table (ps ax on linux, ps -ax on SUNOS, ps -ef on ATT variants of Unix). Check to see if tcpdump is running. Go to the /LOG directory and check to see whether the log file is there and growing. If it is, you are probably in good shape. Another file in the distribution, sensor_init.sh can be moved to /etc/rc.d/init.d under Linux to automatically restart the tcpdump process at system boot. This file is an example of the file necessary under the System V initialization method for automatically starting a process. BSD based systems will require equivalent modification of the rc.local initialization script.

Action 3.7 Final legal review. Deploying a sensor should only be done with approval from your organization’s legal staff. All the computer systems will need warning banners and all users should be notified before the system is placed in operation. An SOP detailing appropriate and inappropriate uses of the data is recommended.

That is all there is to it. A spare Unix platform, tcpdump, a large disk and a couple shell scripts and you have an intrusion detection sensor.

</DIR></DIR>

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

Action 4.1 Configure the system.

</DIR></DIR>

Install the operating system, and latest system security patches. Logically position the analyzer inside the site firewall with the sensor located outside the firewall.

Unpack the Shadow tar file into the /usr/local directory. /usr/local/logger/accessories contains the software tar balls for prerequisite software. Each is installed by gunzipping, untarring, configuring, making, and installing as per "normal" GNU software practices. Each subdirectory has a README file with instructions for building the package. The prerequisites are: Secure Shell (SSH), libpcap, tcpdump, tpcslice, Apache, and msntp.
Copy /usr/local/logger/httpd/cgi-bin/* to /usr/local/etc/httpd/cgi-bin and /usr/local/logger/httpd/images/* to /usr/local/etc/httpd/images making directories as necessary. These are the Apache cgi files and images.
Copy /usr/local/logger/httpd/conf/* to /etc/httpd/conf. These are the Apache configuration files. If Apache expects them in a different location, move them accordingly.
Make directories: /LOG for the raw tcpdump files, and /home/httpd/html/tcpdump_results for the Apache (web server) files. These files should be owned by the user whose processes will fetch the raw files and run the SHADOW scripts, probably not root for safety.

Action 4.2 Configure the analyzer. Inside the sites subdirectory of the SHADOW distribution is a file called GENERIC.ph, which is a Perl header file used for configuring the SHADOW analyzer. The contents of GENERIC.ph are:

# Variables needed by the analyzer scripts. Tailor this file

# to define the paths for different sensor sites.

#

$CID_PATH = "/usr/local/logger";

$ENV{PATH} = "/bin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:$CID_PATH";

#

use POSIX qw(strftime);

use Time::Local;

#

$SITE="SITE1";

@SITE_IP=("172.16.31", "192.168");

$SENSOR="sensor01.goodguys.com";

$WEB_SERVER="www.goodguys.com";

$SENSOR_DIR="/LOG";

$ANALYZER_DIR="/LOG/$SITE";

$OUTPUT_WEB_DIR="/home/httpd/html/tcpdump_results/$SITE";

$URL_OUTPUT_DIR="/tcpdump_results/$SITE";

$FILTER_DIR="$CID_PATH/filters/$SITE";

$SCAN_THRESHHOLD = "5";

$LEVEL2_HOST="second.goodguys.com";

$LOG_FILE = "/tmp/${0}";

#

# Set the time for consolidate.pl to 3 days and 15 minutes ago.

#

$CONSOLIDATE_TIME=time-3*24*60*60-15*60;

#

# Set the date for cleanup.pl to 2 days + 15 minutes ago.

#

$CLEAN_DATE=strftime("%y%m%d", localtime(time-2*24*60*60-15*60))

</DIR></DIR>

Each of the variables in this file should be configured to fit the site at which the SHADOW system is being installed. The definitions of each term are as follows:

</DIR></DIR>

$CID_PATH: the location of the installed SHADOW software: default: /usr/local/logger.
$SITE: the name of the site, used as a subdirectory for storing both raw tcpdump files and output html files. The site name is a required parameter on the various SHADOW scripts.
$SITE_IP: IP addresses with the purview of the site. Not used yet.
$SENSOR: the official name of the sensor that this analyzer is to fetch data from.
$WEB_SERVER: the official name of the computer running a web server to display the analyzer data. (Currently the official name of the analyzer.)
$SENSOR_DIR and $ANALYZER_DIR directories on the sensor and analyzer in which the raw tcpdump files are stored.
$OUTPUT_WEB_DIR and $URL_OUTPUT_DIR absolute and relative paths for the location of the analyzer output html files.
$FILTER_DIR: the path to the location of tcpdump filters for this site, default filters subdirectory of SHADOW distribution.
$SCAN_THRESHHOLD: the number of different systems within your site that can be scanned by an outsider before being flagged as a scanner on the analyzer output.
$LEVEL2_HOST: the name of a system to which the data is shipped for secondary analysis. (Not currently used.)
$LOG_FILE: the name of a file that contains debugging information for the SHADOW scripts. (Currently set to the name of the script.log in the /tmp directory.)
$CONSOLIDATE_TIME: the amount of time after which the hourly raw tcpdump files are consolidated into daily files by the consolidate.pl script.
$CLEAN_DATE: the amount of time after which the hourly raw tcpdump files are removed from the sensor’s disks.

In the filters subdirectory of the SHADOW distribution is a subdirectory TEMPLATE. Inside that subdirectory is a set of tcpdump filter templates with some documentation. Make a new subdirectory /usr/local/logger/filters/NASTY assuming NASTY (National Advanced System Technology Yahoos) is your site name. Copy the files from /usr/local/logger/filters/TEMPLATE and edit each to tailor it to your site. All the 192.168 and 172.16 IP addresses should be changed to reflect the IP addresses of machines at your site. As an example of tcpdump filters, the following line is included in /usr/local/logger/filters/TEMPLATE/tcp.filter.

tcp and
…
((tcp[13] & 2 != 0))

The first tcp in the example above means match TCP packets (as opposed to UDP, ICMP, IGRP, IGMP etc). The "tcp[13]" refers to the 13^th byte of the tcp header. This is the location of the TCP "CODE BITs" field. The "& 2 != 0" is how we mask this field to test for SYN. So what this does is causes all the TCP packets with SYN set to be written to a file. Several reviewers felt that just SYN and FIN packets could be used to "define" TCP connections. This could be accomplished by: tcp and (tcp[13] & 3 != 0).

</DIR></DIR>

============

(Begin Sidebar … To run alongside paragraph above)

TCP CODE BITS

Often called flags, the six bits in this field are used to interpret how to handle a TCP packet. They are:

URG Urgent pointer field is valid

ACK Acknowledgement field

PSH Push requested

RST Reset (break) connection

SYN Synchronize (start) connection

FIN Finished, all done

(End Sidebar)

============

Action 4.5 Test fetchem.pl. Run fetchem.pl interactively and see whether the files are correctly being copied from the sensor into the /LOG directory. Verify that output html files are being written into the /home/httpd/html/tcpdump_results/{SITE}/ directory structure. By adding the parameter "-debug" to the fetchem.pl call, debugging information is written to the /tmp/fetchem.log file. The script should be run as a regular user. Common problems are file and directory permissions.

Action 4.6 Edit cron to call fetchem.pl

The file analyzer_crontab in the SHADOW distribution is a template for the crontab to be run on the analyzer:

# Crontab for a tcpdump Analyzer. Insure system clock is consistent.
# If this is not on the internet, need a standard time source.
#
# These three entries must be done as root.
#
17 23 * * * /usr/local/bin/msntp -r time-a.nist.gov
18 23 * * * /sbin/hwclock --systohc
#
# The following entries need not be done as root.
#
5 * * * * /usr/local/logger/fetchem.pl -l SITE -n LOGGER
17 1 * * * /usr/local/logger/cleanup.pl -n LOGGER
25 0 * * * /usr/local/logger/consolidate.pl -l SITE

</DIR></DIR>

Fetchem.pl's job is to pull the raw tcpdump file from the sensor machine, store it in a date descriptive directory on the analyzer, and run it through tcpdump again with a set of filter files which will detect those events you suspect may be intrusion attempts. The output from this run is written to a file within the document directory of an http web server. Consequently, pointing a web browser to this domain allows an analyst to quickly review any findings of the tcpdump filter run. We will describe the format and usage of tcpdump filters in the next section.

</DIR></DIR>

Step 5 Test and Setup the display system

Action 5.1 Introduction to the display system

Fetchem.pl writes the information from filter matches into html format into a directory that is served by the web server. People responsible for watching the network simply use their web browser to see what is going on. The web files with events flagged by the events filters are chained by forward and back arrows, so the analyst can go from hour to hour easily.

</DIR></DIR>

Some additional notes on display of information:

Dir-it is the program that creates and updates the home page which is an index to all the data. This was written by Robert Niles and we have included it in the source distribution.

There are many web servers available. The one that we have used for displaying intrusion detection information for several years is called the Apache web server. It is available from http://www.apache.org.

Action 5.2 Using tcpdump filters to survey your network

Intrusions are detected exactly one way. By one technique or another they are isolated from the traffic stream and found to be interesting (abnormal), non-business related traffic. The "gimmes" in intrusion detection for a traffic analysis approach, are the services that could not possibly be part of your organization's normal business related traffic. In 1997 the IMAP attack was a very successful exploit. What if your site did not support an IMAP service and yet you kept seeing incoming packets to TCP port 143? So then, we need to determine what services we do support so that we can flag attempts to other services as suspect. How do we do this?

A great way to start is to locate your organization's firewall policy. This way you can determine the things your organization has decided to allow. Remember the great axiom of firewall policy: That which is not specifically allowed is prohibited. Therefore all TCP and UDP ports below 1024 that are not allowed should be flagged with the bad events filter. All TCP ports above 1024 that are not allowed can be flagged if there is a SYN packet to that port and all UDP ports above 1024 to ports that are not allowed should be flagged.

If your organization does not have a firewall, or the firewall is extremely permissive you will need to write a set of filters that will let you examine all traffic and the determine statistically which ports are normal business traffic and then monitor for exceptions. For TCP:

((tcp and (tcp[13] & 2 != 0) and dst net 192.168 and tcp[2:2] < 1024)

This filter will list all SYN packets, or attempts to open a connection to a port below 1024 for the destination network 192.168 (Please put your network here). If you want to get all incoming connections, simply modify the filter to say:

((tcp and (tcp[13] & 2 != 0) and dst net 192.168)

=============

(Begin Sidebar … Please run alongside the two paragraphs above)

TCP and UDP services can be divided into two categories, below 1024 and above. The reasons for this are rapidly becoming historical. On Unix systems, root level access was required to operate a service below port 1024. The idea was that such a service could be trusted since anyone with root access was presumably trustworthy. Further, the ports below are fairly well defined and used appropriately, that is TCP port 25 is very likely to be sendmail, 23 telnet and so on. Above 1024 it gets pretty dicey. For instance TCP 1080 may be for socks, but if you want to detect a probe on socks you will need to look for a SYN packet (active open) to TCP 1080, otherwise you will detect a lot of perfectly normal FTP and HTTP file transfers.

(End Sidebar)

=============

</DIR></DIR>

Action 5.3 Beginning intrusion detection

Now that you have completed surveying your network traffic

and created a bad_events filter to satisfy your needs, you can

begin using this tool for intrusion detection. The software will

place the files in a directory arranged by hour. As you click on

each hour, you will see the events that were flagged during that

time period. If you want further information on a particular event,

you may want to run one of the analysis scripts supplied with your

software. For example, one of the most common and useful tools is

the "one_day_pat.pl". You can execute the "one_day_pat.pl",

providing it a date and a pattern, and it will check all the hourly

files for the pattern over the entire day specified and output this

information appropriately.

NOTE: one_day_pat.pl can be run through the web gui or from a command prompt shell. If you run it from the web interface the date (-d) and the sensor or logger (-l) information is filled in for you. If you choose to run one_day_pat.pl from the command prompt you will need to supply these command line options, or the software will make a guess as to what you want which may or may no be correct. There is one additional option that can be provided –n will avoid name lookups which can be much faster.

</DIR></DIR>

For instance, if you check the hourly files and see an entry

concerning srn.badguy.org and want more information about

the actions involving srn.badguy.org for the day, try:

$ one_day_pat.pl -d 980520 -l NNNN -p 'host srn.badguy.org'

and all traffic for that day to or from srn.badguy.org will be

displayed. This script is also helpful to test for events that

are not in your bad_events pattern.

NOTE: The web page only displays the events

matched by the bad_events filter or the additional perl scripts

will be displayed. From time to time, we recommend that you try experimental filters to see

what you can detect. Networks are dynamic and it is critical to constantly monitor for change.

It is very important to observe what you see often and

be able to detect the smallest deviance from the ordinary.

The examples given above are only a few of the many types of

Attacks or probes you may see as you track your network data. Although

you may have a lot of data to examine, you must

be careful to observe the indications of an attack and be able

to spot such an instance even if it is hiding in the middle of

a huge amount of data. Again, this is where the "one_day_pat.pl"

may become quite useful. Remember, attackers are persistent and

always trying new methods to gain access to your systems, therefore

it is vital that you be aware of anything unusual.

</DIR></DIR>

Action 5.4 Responding to a detect - So what if you find something?

If you are checking your hourly files and find something that looks

suspicious, but not really scary, the next logical step is to run

"one_day_pat.pl" as described above to get more information. It is important

to keep an accurate audit trail of everything that you discover in case the

information is needed later to support recovery, or even prosecution. A

better way to run "one_day_pat.pl" is to collect its results into a file.

This can be done as follows:

$ one_day_pat.pl -d 980520 -l NNNN -p 'host srn.badguy.org' > host.time &

Then you can run

$ tail -f host.time

to view the results as they are created. The advantage of adopting this

approach is that you will have a record of every action that you took.

One helpful option you may want to include when using "one_day_pat.pl" is

the -n option. This option causes the results to be displayed as only IP

addresses, without wasting time matching IP addresses with names. If you

are only concerned with IP addresses, this option may be useful to you.

If you are in a hurry, because what you saw on your screen was fairly scary,

then you may want to run tcpdump directly on the hourly file (without name

lookups using -n) for faster results. The following command will accomplish this:

$ tcpdump -n -r 98051512 'host 192.168.1.1' > host.time &

$ tail -f host.time

Whether you run one_day_pat.pl or tcpdump directly on

an hourly file, now you can examine the data and decide whether you have a

problem. There are several things you may want to notice. If the packets

are only incoming without replies, then your firewall and system protections

may be holding. If there are replies to the sending host, but they are ICMP and

they say "port unreachable", then again you may be OK. Not great, but OK, this is an

indicator that either the packets are getting through your firewall, or the external interface of your firewall has knowledge of your internal network. If you see other replies, you probably want to alert your organization's computer incident response team. Again, it is also a good idea to set up some sort of reporting system in which the details of an incident are recorded for future use, you

never know when this information will be useful, whether it be evidence for

prosecution or a record for comparison with future incidents. NOTE: for further

information on how to establish an incident handling team or how to respond to incidents, see SANS Computer Incident Handling Step-by-Step.

Many sensors have enough power that you can run an additional session of

tcpdump with a filter to watch the attacker. NOTE: there have been cases

where an attack has come from several systems on a network, so you may want

to collect information on the entire net. The following command sequence

helps to illustrate this:

$ ssh -l root sensor

# df

# cd /LOG

# mkdir host.date; cd host.date

# tcpdump -n 'net 192.168.1' > time &

#tail -f time &

This way you will have information to provide the incident handling team.

NOTE: we strongly advise that you try this before an incident. It is

recommended that you establish a secure shell key relationship with your

incident handling team in advance of an incident so that you can transfer

incident information in an encrypted manner to protect against any potential

network sniffers.

Enhancing your Intrusion Detection Capability

Step 6. 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?

Action 6.1 Sort the data for display and resolve hostnames from IP addresses

In order to display the traffic dumped by the filters you have constructed it is preferable to sort the traffic in some meaningful way. Tcpdump will present the traffic to you as it occurred in time. If one is looking for scans or single line connections amidst a torrent of denial-of-service ping broadcasts (for example), the traffic must be sorted and grouped intelligently to make subtleties stand out. Our current solution is to group the connections by source IP address and insert a blank line in the display between groups of connections originating from the same source. In this way scans become immediately obvious, and very noisy / overwhelming attack connections can be clustered together and set aside so that the analyst can see the more subtle connection attempts.

The first requirement to do this is to run tcpdump with the -n option set. This option setting tells tcpdump not to resolve the hostnames, but rather to leave the IP addresses in dot notation. The resulting traffic may then be parsed and sorted according to source IP (and then by time). As the traffic is written to the output, we simply check for duplicate lines in the sorted data and throw them away, and when the source IP changes we insert a blank line. This script is sort_by_source_ip_then_time in the SHADOW distribution and is fully integrated into the fetchem.pl script.

However, being human, we would prefer to read host names as opposed to IP addresses. Thus we may run another script that will take our sorted output and resolve the host names from the IP addresses and re-insert them as tcpdump would have. A short perl snippet that does the name resolution is given below.

#! /usr/local/bin/perl

$ip = $ARGV[0];

@octets = split(/\./, $ip);

$binary_ip = pack "c4", $octets[0], $octets[2], $octets[1], $octets[3];

@hostinfo = gethostbyaddr($binary_ip, 2);

$hostname = $hostinfo[0];

print $ip, " ",$hostname,"\n";

This snippet should be executed with a single command line argument that is the IP address in standard 255.255.255.255 type notation. The resulting hostname is printed to the screen provided the DNS server is able to resolve the IP address. The integrated version of this script is included in the SHADOW distributions as resolve_hostnames.pl.

Action 6.2 Looking for host scans independent of protocol or attack type

One way to detect unusual activity on a network is to search for source IP addresses that are attempting to connect with many destination hosts over a given time period. We can find such hosts of interest independent of any particular protocol or attack type; in fact, looking for scans in this manner is a good way to detect new attack patterns.

For example, we have recently been observing scans of our network using tcp reset packets. It is both time-consuming and uninteresting to monitor all reset packets sent to all hosts on a network as this is a normal occurrence in tcp communication. However, these connections become more interesting when one observes a single host from the outside world sending reset packets to many machines on your network when no other dialogue has taken place. The best way to screen for these connections is to look for inbound reset connections where no other traffic between the source and destination hosts has occurred. However, such a program will have difficulty executing fast enough to perform hour-by-hour analysis and the attack type will be limited to resets only. The next best thing in terms of detecting this attack is to screen for one-to-many correlations between source and destination IP addresses; and this is a great thing to do to find new probing or mapping techniques. Another application that readily comes to mind is in finding scans that are embedded in a great deal of normal traffic. For example, monitoring all udp 53 (domain name server) and udp 137 (netbios name service) connections would be at worst impossible and at best overwhelming on large networks. However, sites are commonly scanned on these ports where hackers are looking for nameservers or machines running netbios. A scan-finder as discussed above is able to extract these scans out of the noise.

The next question is how does one write a program to do such a thing that does not take infinite time to execute. For example, we might write a program to make a list of all the source IP addresses that are sending connections to our protected network (tcp, udp, icmp,… everything). Then for each source IP in the list we would make another list of all the destination hosts that are connected to from the source. Using this scheme, each time a new connection is considered, we must search the list of source IPs to see if the source has been added to the list already. Then, if the source host is already listed, we must search the corresponding list of destination IPs to find if the current destination host has already been recorded. In the beginning, while the lists are short, this process proceeds quickly. But, as the list of source addresses grows the search becomes slower; similarly, in the case of a large network scan, the list of destination addresses (corresponding to a given host) grows very large thus slowing the search.

Our solution to this problem is given at the website.

The basic idea is the following:

First we filter the raw data using tcp dump. We grab all inbound traffic except tcp connections having source port 80. We consider only inbound connections in order to reduce the amount of traffic that we have to process. We exclude tcp connections having source port 80 to avoid mistaking the connections back from a commonly accessed webserver for a scan. The tcpdump filter is simple:

(not src net 192.168) and not (tcp and src port 80)

This filter is then run with the -n and -t options set on tcpdump. The -n option tells tcpdump not to resolve the IP addresses into hostnames and the -t option suppresses the timestamp in the printed output. The result is piped to a file which is then sent to a sort routine. The sort command used is sort -u. On most unix systems this will sort the connections according to source IP address and throw away duplicate connections. We are able to sort by source IP address because we have thrown away the timestamp and hence the source IP is the first thing on the data line. Further, since we have ignored the timestamp, connections between hosts that are identical except for when they occurred will not be considered, since we are using the -u (for unique) option on the sort. In this way, we are able to exploit the efficient coding of the sort routine (which is much faster than perl) and reduce the data further by throwing away duplicate connections.

The final step is then to have a perl program that takes the filtered sorted unique output and determine which source hosts contacted many destination hosts. Because we have sorted the data according to source IP address we are able to sidestep searching for the source IP in the list we construct each time a new data line is considered.

The final challenge then is to provide for the case where many, many (read thousands) of destination hosts are contacted by a single source IP. To handle this case we attempted to reduce the search space by using an embedded hash table structure. Under this scheme, for a given source IP, we search for the first octet of the destination IP in a hash that only consists of previously found first octet numbers (max number of elements is 256), then once the first octet is found it points to another hash containing recorded second octet numbers (corresponding to the first octet). The hash of second octet numbers is searched (again max search space is 256 elements) and a match here points to a hash of third octet numbers and so on. The final value of the fourth octet hash is the number of times this destination host was accessed by this source. This code is included in the SHADOW distribution as the script find_scan.pl.

Action 6.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.

first we use filters to separate the data by protocol.

Then, we further reduce the data to a common format that we use to

store information from any sensor.

The reduced data is comma delimited so it can easily be imported

into databases or spreadsheets and contains the following fields:

date, time, src, srcport, dst, dstport, protocol. We refer to this

format as bcp, since it is Bulk CoPied from all analysis stations

to a huge database for storage, or historical analysis.

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 and

reduction.

Use tcpslice to concatenate hourly files into daily files. We can

put a whole day's worth of files together using tcpslice. From our

/LOG/date, the directory holding the day's data we could type:

$ tcpslice *.9802* > tcpdump.980202

tcpslice would cat all the hourly files into a daily file

tcpdump.980202, the daily file for February 02, 1998.

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:

$ tcpdump -r tcpdump.980202 udp > udp.980202

We repeat this operation for protocol we are interested in keeping

for long term analysis. We run some cursory tests for ICMP looking

for routing updates that are from external addresses, but do not

archive IGRP or IGMP. We do reduce and archive, UDP, TCP, and

ICMP.

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.

$ tcpdump -r tcpdump.980202 (not udp and not tcp and not icmp and

not igrp and not igmp) > other.980202

If other is not an empty file then it would pay to invest some

time tracking down the source and destination addresses to sort

out what is going on. There are a variety of services including

hardware encryption units that use IP datagrams of various types

in order to communicate.

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.

Appendix A

Building an Intrusion Detection System using RedHat Linux 5.1 and Gateway 2000 Pentiums

This documentation shows how we built an intrusion detection system (sensor and analysis station) using RedHat Linux 5.1 as our Unix operating system.

We came across several complications that took a little bit of research, experimentation, and perseverance to overcome. We have included tips where we could, however, every site and system is different and will have its own unique idiosyncrasies.

The following is a list of Hardware and Software that we used:

HW: SW:

Pentium II 350 MHZ RedHat Linux 5.1

128MB RAM RedHat Linux Patches

9GB SCSI Hard Drive CID Code

STB Velocity 128bit 8MB Video Card Libpcap

Generic Multi-Sync Monitor Tcpdump

Tcpslice

Secure Shell

Note: The Hardware was ordered from Gateway with Win95 pre-loaded.

Step 1: Information Gathering

Make a list of Hardware specifications. You will need this information later for Linux configuration.
Boot machine under Windows and check and record IRQ settings for all hardware peripherals.
You may run into IRQ conflicts as Windows allows for IRQ sharing, however Linux does not.
If you do happen to find a shared IRQ, the only solution is to physically move the network card or the SCSI card to another slot.

Step 2: RedHat Linux 5.1 Installation

Note: Refer to the RedHat Linux manual for further information.

Boot machine with RedHat Linux 5.1 boot disk.
Go through initial steps and select install from CDROM (if you are going to install from CD).
Partition Disk. (Our disk contained 9GB of space. For different amounts of space, you will have to partition your disk appropriately)

Select Disk Druid.
Delete existing partition(s).
For the sensor, make 3 partitions using the add option as follows:

mount point size type

127MB Linux Swap

/ 2000MB Linux Native

/LOG Rest of disk Linux Native

</DIR></DIR>

For the analysis station make 5 partitions using the add option as follows:

mount point size type

127MB Linux Swap

/ 2000MB Linux Native

/LOG 5059MB Linux Native

/tmp 512MB Linux Native

/usr/local 1000MB Linux Native

Note: The Linux Boot partition can’t be > 2GB (2000MB). Also, you might need to play with the sizes to make them fit.

</DIR></DIR>

Once done with disk partitions, select OK to move on.

In the next steps, you can select an option to check for bad blocks. Select this option on the swap partition only as the other partitions are too big and will take too much time.
Select the components that you will need. This will depend on your site’s particular needs. For the sensor, choose very few components. The sensor is outside your firewall, so you don’t need to provide hackers with more utilities than you need.
Select type of mouse.
Select video card.
Select monitor and don’t probe.
Select Video memory (8MB).
Select no clockchip setting.
Select Video modes: 8bit 16bit 24bit

<DIR>

(x)1280x1024 (x)1280x1024 (x)1280x1024

</DIR>

Configure LAN settings:

Enter IP, Netmask, Primary Name Server, Default Gateway, Hostname, Domain Name, Secondary Name Server, Tertiary Name Server

Format Machine time.
Select services to start initially. (Depends on site)
Create Boot disk. This should complete the initial RedHat Linux installation. You now have a working Linux operating system, however improvements need to be made as follows.
Download and install latest patches.

Download patches from: http://www.redhat.com to directory /usr/local/archives/rpm (You will probably need to create this directory.)
The glint patch is needed before the Package Manager in X Windows can be used.
From /usr/local/archives/rpm enter: rpm -Uvh glint*
From the X Windows Control Panel, select Package Manager.
Select configure and enter path to look for packages (/usr/local/archives/rpm).
Select Available to see which packages are not installed.
Select packages to install or upgrade.

To use the screensaver and Xlock functions in X Windows, the following packages need to be installed (These can likely be found on the RedHat Linux CDROM):

xscreensaver*
fortune-mod*
xlockmore*

Reboot
Build Custom Kernel:

Instructions are also in the RedHat Linux Manual.
Make sure the kernel-headers* and kernel-source* rpm files are upgraded and installed, and perform the next commands as root:
cd /usr/src/linux
make mrproper
make xconfig

Select options based on what your requirements are.

make dep
make clean
make boot
make modules
rm -rf /lib/modules/2.0.34-0.6-old (2.0.34xx may be different depending on the version of RedHat Linux you are using)
mv /lib/modules/2.0.34-0.6 /lib/modules/2.0.34-0.6-old
make modules_install
mv /boot/vmlinuz-2.0.34-0.6 /boot/vmlinuz-2.0.34-0.6.old
cp /usr/src/linux/arch/i386/boot/zImage /boot/vmlinuz-2.0.34-0.6
edit /etc/lilo.conf - enter kernel data
/sbin/lilo
reboot
The machine should boot up in the new customized kernel. If you want a choice of booting up in the new kernel or the old kernel press the Tab button when the machine gets to the Lilo: prompt.
It is recommended that you set options for your machine to ignore incoming ICMP packets, except from specified sources. In order to do this, the following commands should be entered as root:

ipwadm -I -a allow -P icmp -s 192.168.1.0/24 -W eth0 (Instead of 192.168.1.0/24, enter the source(s) from which you will accept ICMP packets)
ipwadm -I -a deny -P icmp -s 0.0.0.0/0 -W eth0

Linux Installation is now complete.

Step 3: Application Installation

SHADOW code, libpcap, tcpdumb, tcpslice, and SSH should have been downloaded to /usr/local/archives/tar (You will probably need to create this directory).
SHADOW code installation:

mkdir /usr/local/logger
Move SHADOW code to this directory.
untar enter: tar xvfz cid*

Logger code installation:

uncompress libpcap*
tar xf libpcap*
cd libpcap-0.4a6
./configure
make
make install
make install-man (you will probably need to mkdir /usr/local/include and mkdir /usr/local/include/net)
make install-incl (only for libpcap)
repeat steps 1 - 7 for tcpdump and tcpslice.

Secure Shell installation:

mkdir /usr/local/archives/tar/tmp
Move SSH files to this directory.
From /usr/local/archives/tar/tmp enter: tar xvfz ssh-1.2.25_linux.install.tar.gz
sh -x install _ linux.sh

Step 4: Configure Sensor and Analysis Station

Configure Sensor

Run pwconv to incorporate SHADOW passwords (you might need to run this after every password change.)
Disable all inetd.conf services.
Create directories as you need them.

Configure SHADOW code for your site.

crontab

Configure SSH for your site.

Configure Analysis Station

Run pwconv to incorporate SHADOW passwords (you might need to run this after every password change.)
Disable all inetd.conf services.
Create directories as you need them.
Configure SHADOW code for your site.
Configure SSH for your site.

Test fetchem
Edit and install crontab for your site.
To use the analyzer, point your browser to: http://your.analysis.station

Congratulations! You now have a working Intrusion Detection System.

</BODY></HTML>

8 steps to a working Linux Intrusion Detection System (SHADOW)

Navigation menu

Search