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

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<!-- saved from url=(0045)http://www.nswc.navy.mil/ISSEC/CID/part3.html -->
<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><B><FONT face=Arial size=2>
<P>Section 3: Installing SHADOW</P>
<P>Step 1: Acquiring the software for the SHADOW System</P>
<DIR></B>
<P>The software is available at no cost from the Lawrence Berkeley Research 
Laboratory and the Naval Surface Warfare Center Dahlgren Division.</P>
<P>Action 1.1. (optional) Download tcpdump and related software from: </FONT><A 
href="ftp://ftp.ee.lbl.gov/"><FONT face=Arial 
size=2>ftp://ftp.ee.lbl.gov</FONT></A>. <FONT face=Arial size=2>These files are 
also included in the SHADOW code located in the accessories directory. </P>
<P>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.</P>
<P>Action 1.2 Acquire secure shell. A copy of the most recent release is also 
included in the SHADOW code accessories directory.</P>
<P>If you are not already using secure shell, visit the "getting started with 
secure shell" home page at </FONT><A 
href="http://ns.uoregon.edu/pgpssh/sshstart.html"><FONT 
size=2>http://ns.uoregon.edu/pgpssh/sshstart.html</FONT></A><FONT face=Arial 
size=2> to obtain the software. </P>
<P>Action 1.3 Obtain the Shadow code. The remaining intrusion detection software 
is available at:</P>
<P>http://www.nswc.navy.mil/ISSEC/CID/step.tar.gz</P>
<P>Action 1.3 Download and build Apache. A copy of the most recent release is 
also included in the Shadow code accessories directory.</P>
<P>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.</P></FONT>
<P><A href="http://www.apache.org/"><FONT 
size=2>http://www.apache.org</FONT></A></P></DIR></DIR>
<P>=======</P><FONT face=Arial><PRE>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.</PRE></FONT>
<P>======</P>
<DIR><FONT face=Arial size=2>
<P>Step 2. Build the sensor. </P>
<P>The first system to build is the hardware/software facility that will serve 
as the sensor. </P>
<DIR>
<P>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.</P>
<P>&nbsp;</P>
<P>Action 2.2 Partition a large disk. </P>
<P>Since the primary purpose of the system is to collect data you want the /LOG 
partition to be as large as possible.</P>
<P>Action 2.3 Build libpcap. </P>
<P>We start with libpcap. The Unix command to unpack the software is:<BR><B>$ 
uncompress libpcap.tar.Z</P></B>
<P>The result of this operation should be a file called libpcap.tar. Next, type: 
<BR><B>$ tar xf libpcap.tar</P></B>
<P>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.</P>
<P>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.</P>
<P>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.</P></DIR></DIR>
<P>Step 3. Configuring the Sensor </P>
<P>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.</P>
<DIR>
<DIR>
<P>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.</P>
<P>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.</P>
<P>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 </FONT><A 
href="http://www.iss.net/xforce/">http://www.iss.net/xforce/</A><FONT face=Arial 
size=2>. 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. </P>
<P>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:</P></FONT><B><FONT face="Courier New" size=1>
<P>17 23 * * * /usr/local/bin/msntp -r time-a.nist.gov<BR>18 23 * * * 
/sbin/hwclock --systohc<BR>0 * * * * /usr/local/logger/tcpdump.driver.pl &gt; 
/dev/null 2&gt;&amp;1</P></B></FONT><FONT face=Arial size=2>
<P>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.</P>
<P>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.</P>
<P>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.</P>
<P>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.</P>
<P>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.</P>
<P>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.</P></DIR></DIR>
<P>Step 4. Set up the Analysis Station </P>
<P>In this section we describe methods for getting the data from the sensor to 
the analysis station securely</P>
<DIR>
<DIR>
<P>Action 4.1 Configure the system. </P></DIR></DIR>
<OL start=0>
  <OL start=0>
    <OL start=0>
      <LI>Install the operating system, and latest system security patches. 
      Logically position the analyzer inside the site firewall with the sensor 
      located outside the firewall.</LI></OL></OL></OL>
<OL type=a>
  <OL type=a>
    <LI>Unpack the Shadow tar file into the <I>/usr/local</I> directory. 
    <I>/usr/local/logger/accessories</I> 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. 
    <LI>Copy /<I>usr/local/logger/httpd/cgi-bin/*</I> to 
    <I>/usr/local/etc/httpd/cgi-bi</I>n and<I> 
    /usr/local/logger/httpd/images/*</I> to <I>/usr/local/etc/httpd/images</I> 
    making directories as necessary. These are the Apache cgi files and images. 
    <LI>Copy <I>/usr/local/logger/httpd/conf/*</I> to <I>/etc/httpd/conf</I>. 
    These are the Apache configuration files. If Apache expects them in a 
    different location, move them accordingly. 
    <LI>Make directories: <I>/LOG</I> for the raw tcpdump files, and 
    <I>/home/httpd/html/tcpdump_results</I> 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.
    <OL type=A>
      <OL start=0>
        <LI>Configure Secure Shell to allow password-less communication between 
        the analyzer station and the sensor. The scripts will run automatically 
        from a cron job every hour under a user id. The scripts cannot halt to 
        await interactive input of a password on the analyzer station. This step 
        requires running <I>ssh-keygen</I> on the analyzer, sending the public 
        key to the sensor, and/or setting up the sensor via <I>.shosts</I>, 
        <I>/etc/hosts.allow</I>, and <I>/etc/shosts.equiv</I>. We want the 
        sensor to trust communications from the analyzer, but not vice 
        versa.</LI></OL></OL></LI></OL></OL>
<DIR>
<DIR>
<P>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:</P>
<P></FONT><FONT face="Courier New" size=1># Variables needed by the analyzer 
scripts. Tailor this file</P>
<DIR>
<DIR>
<P># to define the paths for different sensor sites.</P>
<P>#</P>
<P>$CID_PATH = "/usr/local/logger";</P>
<P>$ENV{PATH} = 
"/bin:/usr/bin:/usr/sbin:/usr/local/bin:/usr/local/sbin:$CID_PATH";</P>
<P>#</P>
<P>use POSIX qw(strftime);</P>
<P>use Time::Local;</P>
<P>#</P>
<P>$SITE="SITE1";</P>
<P>@SITE_IP=("172.16.31", "192.168");</P>
<P>$SENSOR="sensor01.goodguys.com";</P>
<P>$WEB_SERVER="www.goodguys.com";</P>
<P>$SENSOR_DIR="/LOG";</P>
<P>$ANALYZER_DIR="/LOG/$SITE";</P>
<P>$OUTPUT_WEB_DIR="/home/httpd/html/tcpdump_results/$SITE";</P>
<P>$URL_OUTPUT_DIR="/tcpdump_results/$SITE";</P>
<P>$FILTER_DIR="$CID_PATH/filters/$SITE";</P>
<P>$SCAN_THRESHHOLD = "5";</P>
<P>$LEVEL2_HOST="second.goodguys.com";</P>
<P>$LOG_FILE = "/tmp/${0}";</P>
<P>#</P>
<P># Set the time for consolidate.pl to 3 days and 15 minutes ago.</P>
<P>#</P>
<P>$CONSOLIDATE_TIME=time-3*24*60*60-15*60;</P>
<P>#</P>
<P># Set the date for cleanup.pl to 2 days + 15 minutes ago.</P>
<P>#</P>
<P>$CLEAN_DATE=strftime("%y%m%d", 
localtime(time-2*24*60*60-15*60))</P></FONT><TT>
<P>&nbsp;</P></DIR></DIR></TT><FONT face=Arial size=2>
<P>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:</P></DIR></DIR>
<UL>
  <DIR>
  <DIR>
  <UL>
    <LI>$CID_PATH: the location of the installed SHADOW software: default: 
    <I>/usr/local/logger</I>. 
    <LI>$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. 
    <LI>$SITE_IP: IP addresses with the purview of the site. Not used yet. 
    <LI>$SENSOR: the official name of the sensor that this analyzer is to fetch 
    data from. 
    <LI>$WEB_SERVER: the official name of the computer running a web server to 
    display the analyzer data. (Currently the official name of the analyzer.) 
    <LI>$SENSOR_DIR and $ANALYZER_DIR directories on the sensor and analyzer in 
    which the raw tcpdump files are stored. 
    <LI>$OUTPUT_WEB_DIR and $URL_OUTPUT_DIR absolute and relative paths for the 
    location of the analyzer output html files. 
    <LI>$FILTER_DIR: the path to the location of tcpdump filters for this site, 
    default filters subdirectory of SHADOW distribution. 
    <LI>$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. 
    <LI>$LEVEL2_HOST: the name of a system to which the data is shipped for 
    secondary analysis. (Not currently used.) 
    <LI>$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 
    <I>/tmp</I> directory.) 
    <LI>$CONSOLIDATE_TIME: the amount of time after which the hourly raw tcpdump 
    files are consolidated into daily files by the consolidate.pl script. 
    <LI>$CLEAN_DATE: the amount of time after which the hourly raw tcpdump files 
    are removed from the sensor’s disks.</LI></UL></DIR></DIR></UL>
<DIR>
<DIR>
<P>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 
<I>/usr/local/logger/filters/NASTY</I> assuming NASTY (National Advanced System 
Technology Yahoos) is your site name. Copy the files from 
<I>/usr/local/logger/filters/TEMPLATE</I> 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 
<I>/usr/local/logger/filters/TEMPLATE/tcp.filter</I>.</P></FONT><B><FONT 
face="Courier New" size=2>
<P>tcp and <BR></FONT><FONT face="Courier New" size=5>…<BR></FONT><FONT 
face="Courier New" size=2>((tcp[13] &amp; 2 != 0))</P></B></FONT><FONT 
face=Arial size=2>
<P>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<SUP>th</SUP> byte of 
the tcp header. This is the location of the TCP "CODE BITs" field. The "&amp; 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] &amp; 3 != 0).</P></DIR></DIR>
<P>============</P>
<P>(Begin Sidebar … To run alongside paragraph above)</P><B><U>
<P>TCP CODE BITS&nbsp;</P></B></U>
<P>Often called flags, the six bits in this field are used to interpret how to 
handle a TCP packet. They are:</P>
<P>URG Urgent pointer field is valid</P>
<P>ACK Acknowledgement field</P>
<P>PSH Push requested</P>
<P>RST Reset (break) connection</P>
<P>SYN Synchronize (start) connection</P>
<P>FIN Finished, all done</P>
<P>(End Sidebar)</P>
<P>============</P>
<DIR>
<DIR>
<P>Action 4.5 Test fetchem.pl. Run fetchem.pl interactively and see whether the 
files are correctly being copied from the sensor into the <I>/LOG</I> directory. 
Verify that output html files are being written into the 
<I>/home/httpd/html/tcpdump_results/{SITE}/ </I>directory structure. By adding 
the parameter "-debug" to the fetchem.pl call, debugging information is written 
to the <I>/tmp/fetchem.log</I> file. The script should be run as a regular user. 
Common problems are file and directory permissions.</P>
<P>Action 4.6 Edit cron to call fetchem.pl</P>
<P>The file analyzer_crontab in the SHADOW distribution is a template for the 
crontab to be run on the analyzer:</P>
<DIR>
<DIR></FONT><B><FONT face="Courier New" size=1>
<P># Crontab for a tcpdump Analyzer. Insure system clock is consistent.</P>
<P># If this is not on the internet, need a standard time source.</P>
<P>#</P>
<P># These three entries must be done as root.</P>
<P>#</P>
<P>17 23 * * * /usr/local/bin/msntp -r time-a.nist.gov</P>
<P>18 23 * * * /sbin/hwclock --systohc</P>
<P>#</P>
<P># The following entries need not be done as root.</P>
<P>#</P>
<P>5 * * * * /usr/local/logger/fetchem.pl -l SITE -n LOGGER</P>
<P>17 1 * * * /usr/local/logger/cleanup.pl -n LOGGER</P>
<P>25 0 * * * /usr/local/logger/consolidate.pl -l 
SITE</P></DIR></DIR></B></FONT><FONT face=Arial size=2>
<P>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.</P>
<P>&nbsp;</P></DIR></DIR></FONT><FONT face=Arial>
<DL>
  <DT>Step 5 Test and Setup the display system </DT></DL></FONT><FONT face=Arial 
size=2>
<P>Action 5.1 Introduction to the display system</P>
<DIR>
<DIR>
<P>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.</P></DIR></DIR>
<P>Some additional notes on display of information:</P>
<P>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.</P>
<P>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. </P>
<P>&nbsp;</P>
<P>Action 5.2 Using tcpdump filters to survey your network</P>
<DIR>
<DIR>
<P>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?</P>
<P>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.</P>
<P>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:</P></FONT><B><FONT face="Courier New" 
size=2>
<P>((tcp and (tcp[13] &amp; 2 != 0) and dst net 192.168 and tcp[2:2] &lt; 
1024)</P></B></FONT><FONT face=Arial size=2>
<P>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:</P></FONT><B><FONT face="Courier New" size=2>
<P>((tcp and (tcp[13] &amp; 2 != 0) and dst net 192.168)</P></B></FONT><FONT 
face=Arial size=2>
<P>=============</P>
<P>(Begin Sidebar … Please run alongside the two paragraphs above)</P>
<P>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.</P>
<P>(End Sidebar)</P>
<P>=============</P></DIR></DIR>
<P>Action 5.3 Beginning intrusion detection</P>
<P>&nbsp;</P>
<P>Now that you have completed surveying your network traffic</P>
<P>and created a bad_events filter to satisfy your needs, you can</P>
<P>begin using this tool for intrusion detection. The software will</P>
<P>place the files in a directory arranged by hour. As you click on</P>
<P>each hour, you will see the events that were flagged during that </P>
<P>time period. If you want further information on a particular event,</P>
<P>you may want to run one of the analysis scripts supplied with your</P>
<P>software. For example, one of the most common and useful tools is</P>
<P>the "one_day_pat.pl". You can execute the "one_day_pat.pl",</P>
<P>providing it a date and a pattern, and it will check all the hourly</P>
<P>files for the pattern over the entire day specified and output this</P>
<P>information appropriately.</P>
<DIR>
<DIR>
<P>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.</P>
<P>&nbsp;</P></DIR></DIR>
<P>For instance, if you check the hourly files and see an entry</P>
<P>concerning srn.badguy.org and want more information about </P>
<P>the actions involving srn.badguy.org for the day, try:</P>
<P></P>
<P></FONT><B><FONT face="Courier New" size=2>$ one_day_pat.pl -d 980520 -l NNNN 
-p 'host srn.badguy.org'</P></B></FONT><FONT face=Arial size=2>
<P>&nbsp;</P>
<P>and all traffic for that day to or from srn.badguy.org will be</P>
<P>displayed. This script is also helpful to test for events that</P>
<P>are not in your bad_events pattern. </P>
<P>NOTE: The web page only displays the events</P>
<P>matched by the bad_events filter or the additional perl scripts </P>
<P>will be displayed. From time to time, we recommend that you try experimental 
filters to see</P>
<P>what you can detect. Networks are dynamic and it is critical to constantly 
monitor for change.</P>
<P>&nbsp;</P>
<P></P></FONT>
<P>&nbsp;</P><FONT face=Arial size=2>
<P>&nbsp;</P>
<P>It is very important to observe what you see often and</P>
<P>be able to detect the smallest deviance from the ordinary. </P>
<P>The examples given above are only a few of the many types of</P>
<P>Attacks or probes you may see as you track your network data. Although</P>
<P>you may have a lot of data to examine, you must</P>
<P>be careful to observe the indications of an attack and be able</P>
<P>to spot such an instance even if it is hiding in the middle of</P>
<P>a huge amount of data. Again, this is where the "one_day_pat.pl"</P>
<P>may become quite useful. Remember, attackers are persistent and </P>
<P>always trying new methods to gain access to your systems, therefore </P>
<DIR>
<DIR>
<P>it is vital that you be aware of anything unusual. </P>
<P>&nbsp;</P></DIR></DIR>
<P>Action 5.4 Responding to a detect - So what if you find something?</P>
<P>&nbsp;</P>
<P>If you are checking your hourly files and find something that looks</P>
<P>suspicious, but not really scary, the next logical step is to run</P>
<P>"one_day_pat.pl" as described above to get more information. It is 
important</P>
<P>to keep an accurate audit trail of everything that you discover in case 
the</P>
<P>information is needed later to support recovery, or even prosecution. A</P>
<P>better way to run "one_day_pat.pl" is to collect its results into a file.</P>
<P>This can be done as follows:</P>
<P>&nbsp;</P>
<P>$ one_day_pat.pl -d 980520 -l NNNN -p 'host srn.badguy.org' &gt; host.time 
&amp;</P>
<P>&nbsp;</P>
<P>Then you can run</P>
<P>&nbsp;</P>
<P>$ tail -f host.time</P>
<P>&nbsp;</P>
<P>to view the results as they are created. The advantage of adopting this</P>
<P>approach is that you will have a record of every action that you took.</P>
<P>One helpful option you may want to include when using "one_day_pat.pl" is 
</P>
<P>the -n option. This option causes the results to be displayed as only IP</P>
<P>addresses, without wasting time matching IP addresses with names. If you</P>
<P>are only concerned with IP addresses, this option may be useful to you.</P>
<P>&nbsp;</P>
<P>If you are in a hurry, because what you saw on your screen was fairly 
scary,</P>
<P>then you may want to run tcpdump directly on the hourly file (without 
name</P>
<P>lookups using -n) for faster results. The following command will accomplish 
this:</P>
<P>&nbsp;</P>
<P>$ tcpdump -n -r 98051512 'host 192.168.1.1' &gt; host.time &amp;</P>
<P>&nbsp;</P>
<P>$ tail -f host.time</P>
<P>&nbsp;</P>
<P>Whether you run one_day_pat.pl or tcpdump directly on</P>
<P>an hourly file, now you can examine the data and decide whether you have 
a</P>
<P>problem. There are several things you may want to notice. If the packets</P>
<P>are only incoming without replies, then your firewall and system 
protections</P>
<P>may be holding. If there are replies to the sending host, but they are ICMP 
and</P>
<P>they say "port unreachable", then again you may be OK. Not great, but OK, 
this is an</P>
<P>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 </P>
<P>never know when this information will be useful, whether it be evidence for 
</P>
<P>prosecution or a record for comparison with future incidents. NOTE: for 
further </P>
<P>information on how to establish an incident handling team or how to respond 
to incidents, see SANS Computer Incident Handling Step-by-Step.</P>
<P>&nbsp;</P>
<P>Many sensors have enough power that you can run an additional session of</P>
<P>tcpdump with a filter to watch the attacker. NOTE: there have been cases</P>
<P>where an attack has come from several systems on a network, so you may 
want</P>
<P>to collect information on the entire net. The following command sequence</P>
<P>helps to illustrate this:</P>
<P>&nbsp;</P>
<P>$ ssh -l root sensor</P>
<P>&nbsp;</P>
<P># df</P>
<P>&nbsp;</P>
<P># cd /LOG</P>
<P>&nbsp;</P>
<P># mkdir host.date; cd host.date</P>
<P>&nbsp;</P>
<P># tcpdump -n 'net 192.168.1' &gt; time &amp;</P>
<P>&nbsp;</P>
<P>#tail -f time &amp;</P>
<P>&nbsp;</P>
<P>This way you will have information to provide the incident handling team.</P>
<P>&nbsp;</P>
<P>NOTE: we strongly advise that you try this before an incident. It is</P>
<P>recommended that you establish a secure shell key relationship with your</P>
<P>incident handling team in advance of an incident so that you can transfer</P>
<P>incident information in an encrypted manner to protect against any 
potential</P>
<P>network sniffers.</P>
<P>&nbsp;</P>
<P>Enhancing your Intrusion Detection Capability</P>
<P>&nbsp;</P>
<P>Step 6. Implement more advanced analytical capabilities.</P>
<P>&nbsp;</P>
<P>There is a lot more to intrusion detection than looking for a few bad</P>
<P>events. So how can we improve the capability of our system?</P>
<P>&nbsp;</P>
<P>&nbsp;</P>
<P>Action 6.1 Sort the data for display and resolve hostnames from IP 
addresses</P>
<P>&nbsp;</P>
<P>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.</P>
<P>&nbsp;</P>
<P>The first requirement to do this is to run tcpdump with the <B>-n</B> 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.</P>
<P>&nbsp;</P>
<P>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.</P>
<P>&nbsp;</P>
<P></FONT><FONT face="Courier New" size=1>#! /usr/local/bin/perl</P>
<P>$ip = $ARGV[0];</P>
<P>@octets = split(/\./, $ip);</P>
<P>$binary_ip = pack "c4", $octets[0], $octets[2], $octets[1], $octets[3];</P>
<P>@hostinfo = gethostbyaddr($binary_ip, 2);</P>
<P>$hostname = $hostinfo[0];</P>
<P>print $ip, " ",$hostname,"\n";</P></FONT><FONT face=Arial size=2>
<P>&nbsp;</P>
<P>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.</P>
<P>&nbsp;</P>
<P>Action 6.2 Looking for host scans independent of protocol or attack type</P>
<P>&nbsp;</P>
<P>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. </P>
<P>&nbsp;</P>
<P>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.</P>
<P>&nbsp;</P>
<P>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.</P>
<P>Our solution to this problem is given at the website. </P>
<P>&nbsp;</P>
<P>The basic idea is the following:</P>
<P>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:</P>
<P>&nbsp;</P><B>
<P>(not src net 192.168) and not (tcp and src port 80)</P></B>
<P>&nbsp;</P>
<P>This filter is then run with the <B>-n</B> and <B>-t</B> options set on 
tcpdump. The <B>-n</B> option tells tcpdump not to resolve the IP addresses into 
hostnames and the <B>-t</B> 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 <B>sort -u</B>. 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. </P>
<P>&nbsp;</P>
<P>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. </P>
<P>&nbsp;</P>
<P>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. </P>
<P>&nbsp;</P>
<P>&nbsp;</P>
<P>Action 6.3 Reduce the data volume</P>
<P>&nbsp;</P>
<P>We have found there is a practical limit to the analysis that can be</P>
<P>performed with filters. Also, tcpdump collects a LOT of data. In order to</P>
<P>perform more advanced analysis, it is necessary to reduce the data. We do</P>
<P>this in two steps.</P>
<P>&nbsp;</P>
<P>first we use filters to separate the data by protocol.</P>
<P>&nbsp;</P>
<P>Then, we further reduce the data to a common format that we use to</P>
<P>store information from any sensor.</P>
<P>&nbsp;</P>
<P>The reduced data is comma delimited so it can easily be imported</P>
<P>into databases or spreadsheets and contains the following fields:</P>
<P>date, time, src, srcport, dst, dstport, protocol. We refer to this</P>
<P>format as bcp, since it is Bulk CoPied from all analysis stations</P>
<P>to a huge database for storage, or historical analysis.</P>
<P>&nbsp;</P>
<P>Our first step is to convert from hourly to daily files. We do this 
because,</P>
<P>in comparing historical information, delays are created by the overhead</P>
<P>involved in opening and closing hourly files. Here's how we do conversion 
and</P>
<P>reduction.</P>
<P>&nbsp;</P>
<P>Use tcpslice to concatenate hourly files into daily files. We can</P>
<P>put a whole day's worth of files together using tcpslice. From our</P>
<P>/LOG/date, the directory holding the day's data we could type:</P>
<P>&nbsp;</P>
<P>$ tcpslice *.9802* &gt; tcpdump.980202</P>
<P>&nbsp;</P>
<P>tcpslice would cat all the hourly files into a daily file</P>
<P>tcpdump.980202, the daily file for February 02, 1998.</P>
<P>&nbsp;</P>
<P>Next, we extract the various protocols we are interested in as part of 
the</P>
<P>data reduction. At our site the primary protocols in use are: TCP, UDP,</P>
<P>ICMP, IGMP and IGRP. To extract UDP into an ascii file for further</P>
<P>processing:</P>
<P>&nbsp;</P>
<P>$ tcpdump -r tcpdump.980202 udp &gt; udp.980202</P>
<P>&nbsp;</P>
<P>We repeat this operation for protocol we are interested in keeping</P>
<P>for long term analysis. We run some cursory tests for ICMP looking</P>
<P>for routing updates that are from external addresses, but do not</P>
<P>archive IGRP or IGMP. We do reduce and archive, UDP, TCP, and</P>
<P>ICMP.</P>
<P>&nbsp;</P>
<P>Then we run a simple test on the data, from time to time we find some</P>
<P>interesting IP traffic that is not one of the protocols.</P>
<P>&nbsp;</P>
<P>$ tcpdump -r tcpdump.980202 (not udp and not tcp and not icmp and</P>
<P>not igrp and not igmp) &gt; other.980202</P>
<P>&nbsp;</P>
<P>If other is not an empty file then it would pay to invest some</P>
<P>time tracking down the source and destination addresses to sort</P>
<P>out what is going on. There are a variety of services including</P>
<P>hardware encryption units that use IP datagrams of various types</P>
<P>in order to communicate.</P>
<P>&nbsp;</P>
<P>While it is important to know how to do all these things, it does get</P>
<P>monotonous, so we have included consolidate.pl to take all the hourly 
files</P>
<P>and produce daily files from them.</P>
<P>&nbsp;</P>
<P>Finally, in order to compare results over time, we convert the protocol</P>
<P>files to bcp format using translate.pl. Another advantage of converting</P>
<P>files to this format is that its universal format allows us to integrate</P>
<P>data from different kinds of sensors.</P>
<P>&nbsp;</P>
<P>&nbsp;</P>
<P>&nbsp;</P>
<P>&nbsp;</P>
<P align=center>Appendix A</P>
<P>&nbsp;</P>
<P align=center>Building an Intrusion Detection System using RedHat Linux 5.1 
and Gateway 2000 Pentiums</P>
<P align=center>&nbsp;</P>
<P>This documentation shows how we built an intrusion detection system (sensor 
and analysis station) using RedHat Linux 5.1 as our Unix operating system.</P>
<P>&nbsp;</P>
<P>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.</P>
<P>&nbsp;</P>
<P>The following is a list of Hardware and Software that we used:</P>
<P>&nbsp;</P>
<P>HW: SW:</P>
<P>Pentium II 350 MHZ RedHat Linux 5.1</P>
<P>128MB RAM RedHat Linux Patches</P>
<P>9GB SCSI Hard Drive CID Code</P>
<P>STB Velocity 128bit 8MB Video Card Libpcap</P>
<P>Generic Multi-Sync Monitor Tcpdump</P>
<P>Tcpslice</P>
<P>Secure Shell</P>
<P>&nbsp;</P>
<P>Note: The Hardware was ordered from Gateway with Win95 pre-loaded.</P>
<P>&nbsp;</P>
<P>Step 1: Information Gathering</P>
<OL type=A>
  <LI>Make a list of Hardware specifications. You will need this information 
  later for Linux configuration. 
  <LI>Boot machine under Windows and check and record IRQ settings for all 
  hardware peripherals. 
  <LI>You may run into IRQ conflicts as Windows allows for IRQ sharing, however 
  Linux does not. 
  <LI>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.</LI></OL>
<P>&nbsp;</P>
<P>Step 2: RedHat Linux 5.1 Installation</P>
<P>&nbsp;</P>
<P>Note: Refer to the RedHat Linux manual for further information.</P>
<P>&nbsp;</P>
<OL type=A>
  <LI>Boot machine with RedHat Linux 5.1 boot disk. 
  <LI>Go through initial steps and select install from CDROM (if you are going 
  to install from CD). 
  <LI>Partition Disk. (Our disk contained 9GB of space. For different amounts of 
  space, you will have to partition your disk appropriately)</LI></OL>
<OL>
  <OL>
    <LI>Select Disk Druid. 
    <LI>Delete existing partition(s). 
    <LI>For the sensor, make 3 partitions using the add option as 
  follows:</LI></OL></OL>
<DIR>
<DIR>
<P>mount point size type</P>
<P>127MB Linux Swap</P>
<P>/ 2000MB Linux Native</P>
<P>/LOG Rest of disk Linux Native</P>
<P>&nbsp;</P></DIR></DIR>
<OL start=4>
  <OL>
    <LI>For the analysis station make 5 partitions using the add option as 
    follows:</LI></OL></OL>
<DIR>
<DIR>
<P>mount point size type</P>
<P>127MB Linux Swap</P>
<P>/ 2000MB Linux Native</P>
<P>/LOG 5059MB Linux Native</P>
<P>/tmp 512MB Linux Native</P>
<P>/usr/local 1000MB Linux Native</P>
<P>&nbsp;</P>
<P>Note: The Linux Boot partition can’t be &gt; 2GB (2000MB). Also, you might 
need to play with the sizes to make them fit.</P>
<P>&nbsp;</P></DIR></DIR>
<OL start=5>
  <OL>
    <LI>Once done with disk partitions, select OK to move on.</LI></OL></OL>
<OL start=4 type=A>
  <LI>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. 
  <LI value=1>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. 
  <LI>Select type of mouse. 
  <LI>Select video card. 
  <LI>Select monitor and don’t probe. 
  <LI>Select Video memory (8MB). 
  <LI>Select no clockchip setting. 
  <LI>Select Video modes: 8bit 16bit 24bit</LI></OL>
<DIR>
<P>(x)1280x1024 (x)1280x1024 (x)1280x1024</P></DIR>
<OL start=12 type=A>
  <LI>Configure LAN settings:</LI></OL>
<OL>
  <OL>
    <LI>Enter IP, Netmask, Primary Name Server, Default Gateway, Hostname, 
    Domain Name, Secondary Name Server, Tertiary Name Server</LI></OL></OL>
<OL start=13 type=A>
  <LI>Format Machine time. 
  <LI value=1>Select services to start initially. (Depends on site) 
  <LI>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. 
  <LI>Download and install latest patches.</LI></OL>
<OL>
  <OL>
    <LI>Download patches from: http://www.redhat.com to directory 
    /usr/local/archives/rpm (You will probably need to create this directory.) 
    <LI>The glint patch is needed before the Package Manager in X Windows can be 
    used. 
    <LI>From /usr/local/archives/rpm enter: rpm -Uvh glint* 
    <LI>From the X Windows Control Panel, select Package Manager. 
    <LI>Select configure and enter path to look for packages 
    (/usr/local/archives/rpm). 
    <LI>Select Available to see which packages are not installed. 
    <LI>Select packages to install or upgrade.</LI></OL></OL>
<OL start=17 type=A>
  <LI>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):</LI></OL>
<OL>
  <OL>
    <LI>xscreensaver* 
    <LI>fortune-mod* 
    <LI>xlockmore*</LI></OL></OL>
<OL start=18 type=A>
  <LI>Reboot 
  <LI value=1>Build Custom Kernel:</LI></OL>
<OL>
  <OL>
    <LI>Instructions are also in the RedHat Linux Manual. 
    <LI>Make sure the kernel-headers* and kernel-source* rpm files are upgraded 
    and installed, and perform the next commands as root: 
    <LI>cd /usr/src/linux 
    <LI>make mrproper 
    <LI>make xconfig</LI></OL></OL>
<UL type=SQUARE>
  <DIR>
  <DIR>
  <UL type=SQUARE>
    <LI>Select options based on what your requirements 
are.</LI></UL></DIR></DIR></UL>
<OL start=6>
  <OL>
    <LI>make dep 
    <LI>make clean 
    <LI>make boot 
    <LI>make modules 
    <LI>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) 
    <LI>mv /lib/modules/2.0.34-0.6 /lib/modules/2.0.34-0.6-old 
    <LI>make modules_install 
    <LI>mv /boot/vmlinuz-2.0.34-0.6 /boot/vmlinuz-2.0.34-0.6.old 
    <LI>cp /usr/src/linux/arch/i386/boot/zImage /boot/vmlinuz-2.0.34-0.6 
    <LI>edit /etc/lilo.conf - enter kernel data 
    <LI>/sbin/lilo 
    <LI>reboot 
    <LI>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. 
    <LI>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:</LI></OL></OL>
<UL>
  <DIR>
  <DIR>
  <UL>
    <LI>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) 

    <LI>ipwadm -I -a deny -P icmp -s 0.0.0.0/0 -W eth0</LI></UL></DIR></DIR></UL>
<OL>
  <OL>
    <LI>Linux Installation is now complete.</LI></OL></OL>
<P>&nbsp;</P>
<P>Step 3: Application Installation</P>
<P>&nbsp;</P>
<OL type=A>
  <LI>SHADOW code, libpcap, tcpdumb, tcpslice, and SSH should have been 
  downloaded to /usr/local/archives/tar (You will probably need to create this 
  directory). 
  <LI>SHADOW code installation:</LI></OL>
<OL>
  <OL>
    <LI>mkdir /usr/local/logger 
    <LI>Move SHADOW code to this directory. 
    <LI>untar enter: tar xvfz cid*</LI></OL></OL>
<OL type=A>
  <LI>Logger code installation:</LI></OL>
<OL>
  <OL>
    <LI>uncompress libpcap* 
    <LI>tar xf libpcap* 
    <LI>cd libpcap-0.4a6 
    <LI>./configure 
    <LI>make 
    <LI>make install 
    <LI>make install-man (you will probably need to mkdir /usr/local/include and 
    mkdir /usr/local/include/net) 
    <LI>make install-incl (only for libpcap) 
    <LI>repeat steps 1 - 7 for tcpdump and tcpslice.</LI></OL></OL>
<OL type=A>
  <LI>Secure Shell installation:</LI></OL>
<OL>
  <OL>
    <LI>mkdir /usr/local/archives/tar/tmp 
    <LI>Move SSH files to this directory. 
    <LI>From /usr/local/archives/tar/tmp enter: tar xvfz 
    ssh-1.2.25_linux.install.tar.gz 
    <LI>sh -x install _ linux.sh</LI></OL></OL>
<P>&nbsp;</P>
<P>Step 4: Configure Sensor and Analysis Station</P>
<OL type=A>
  <LI>Configure Sensor</LI></OL>
<OL>
  <OL>
    <LI>Run pwconv to incorporate SHADOW passwords (you might need to run this 
    after every password change.) 
    <LI>Disable all inetd.conf services. 
    <LI>Create directories as you need them.</LI></OL></OL>
<OL start=4>
  <OL>
    <LI>Configure SHADOW code for your site.</LI></OL></OL>
<UL type=SQUARE>
  <DIR>
  <DIR>
  <UL type=SQUARE>
    <LI>crontab</LI></UL></DIR></DIR></UL>
<OL>
  <OL>
    <LI>Configure SSH for your site.</LI></OL></OL>
<OL start=2 type=A>
  <LI>Configure Analysis Station</LI></OL>
<OL>
  <OL>
    <LI>Run pwconv to incorporate SHADOW passwords (you might need to run this 
    after every password change.) 
    <LI>Disable all inetd.conf services. 
    <LI>Create directories as you need them. 
    <LI value=4>Configure SHADOW code for your site. 
    <LI>Configure SSH for your site.</LI></OL></OL>
<OL start=3 type=A>
  <LI>Test fetchem 
  <LI value=1>Edit and install crontab for your site. 
  <LI>To use the analyzer, point your browser to: 
  http://your.analysis.station</LI></OL>
<P>&nbsp;</P>
<P>Congratulations! You now have a working Intrusion Detection 
System.</P></FONT></BODY></HTML>