Eight Steps to A Working Intrusion Detection System - The SANS Institute. Preface and instructions for STEP package below.
c5ef09a05b624cf24f402d106c617ed5d51e6367dcdc6865c914b8b9d139331e<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=windows-1252">
<META NAME="Generator" CONTENT="Microsoft Word 97">
<TITLE>Eight Steps to A Working Intrusion Detection System</TITLE>
</HEAD>
<BODY LINK="#0000ff" VLINK="#800080">
<FONT FACE="Arial" SIZE=2><P>Copyright, 1998. The SANS Institute.</P>
<P>This draft is for review purposes only and may not be copied or forwarded without prior permission of the SANS Institute. </P>
</FONT><U><FONT FACE="Arial"><P ALIGN="CENTER">Building a Network Monitoring and Analysis Capability</P>
</U><P ALIGN="CENTER">Step by Step</P>
</FONT><FONT FACE="Arial" SIZE=2><P ALIGN="CENTER">Version 1.1.5 980701</P>
<P>As more organizations rely on the internet for both communications and electronic commerce, system administrators, CIOs and business executives increasingly share a common worry. Their joint concern is that malicious people may be using the internet to launch attacks on their computers and that those attacks could do great damage to their organization.</P><DIR>
<DIR>
<P>A small number of organizations have gone from wondering whether anyone was trying to attack their systems, to knowing for a fact that people were, how often, and what vulnerabilities were being tapped. They have built network monitoring and analysis systems.</P></DIR>
</DIR>
<P>With that knowledge the organizations have been able to tune their firewalls and system protection strategies based on information, instead of on guesses. </P>
<P>The early adopters of intrusion detection systems crafted their own unique tools, but now some of the pioneers in intrusion detection are joining forces to perfect a library of public domain, or freely available tools to protect sites. This toolset, called "cider" (for Cooperative Intrusion Detection Evaluation and Response), automates the process of information gathering and traffic analysis based intrusion detection. Tools are of little value if people can't use them. The purpose of this booklet is to provide the instructions, examples and background information so that every organization with reasonable Unix experience can install and operate a network monitoring and analysis capability.</P>
<P>A step system (short for step-by-step intrusion detection using tcpdump) can be built using freely-available software and existing hardware or hardware that can be purchased for less than $10,000. All cider components come with source code and tutorials on what they do and how to set them up and what the results mean. Because of this, an organization will find this approach complements and enhances the impact of commercially available intrusion detection systems. </P>
<P> </P>
<B><P>A note from Vicki Irwin, Stephen Northcutt and Bill Ralph, designers of the step system </P>
</B><P> </P>
<P>Most intrusion detection systems, whether network or host based, "push" alerts when they detect an event. Two common methods for doing this are sending e-mail to the system administrator, alerting a pager, or beeping to the screen. We have such systems and use them in times of serious attacks. However, in day to day use these systems had some serious drawbacks. Many of the alerts turned out to be false alarms. Many others turned out to be of little consequence, simple exploit scripts that we were well defended against. The beeping, or alerting became annoying to the point we found we were ignoring the alerts. Our organization has not funded computer incident response personnel to be ready to evaluate and respond to every detect twenty four hours a day, seven days a week. We rely on firewalls, system protections and other countermeasures. </P>
<P>Our primary requirement is to detect as many attacks as possible, as easily and efficiently as possible, report the attacks to CIRTs, and analyze the attacks to tune our defenses. This is the design philosophy behind step. We can "pull" the detects using a web browser whenever we have time and examine the kinds of probes and attacks directed against the organization. The web display is simple to use and we have been able to train people in its use quickly. One person can monitor multiple sites, in fact we monitor over ten sites. There are a lot of ways step needs to be improved and we are interested in your suggestions and software contributions so that step can detect more and be faster and easier to implement and use.</P>
<P>We use a second analysis system that will be the subject of a future cider project to mop up the things that we miss. Organizations with critical protection needs can deploy a step sensor and the second order analysis system in conjunction with commercial real time intrusion detection systems as a very effective combination.</P>
<B><P>Overview of the Step architecture</P>
</B><P>Step is based on tcpdump from the Department of Energy and support software provided by Naval Surface Warfare Center Dahlgren and greatly enhanced by the SANS community. </P>
<P> The data collection capability of step is based on libpcap. This software package developed by the Network Research Group at Lawrence Berkeley Laboratory, provides an interface for application programs such as NFR and Step to read data collected by the network interface on Unix systems. Though it is possible to instruct libpcap to gather more information from each packet, it is common for libpcap to collect the first 96 bytes of a packet. This means cider application programs concentrate their analysis on the headers of the collected packet instead of its content. This approach to intrusion detection is called traffic analysis.</P>
<P> </P>
<B><P>Traffic Analysis based intrusion detection compared to Content Analysis.</B> </P>
<P>The strength of a traffic analysis approach is that it is possible to examine and record every packet that passes by on the network. In certain situations such as educational institutions where privacy is a critical concern, a traffic analysis approach may be the only reasonable approach to network monitoring. The weakness of this approach is that some attacks can only be detected by content analysis. Another approach to intrusion detection is to examine the contents of packets for certain strings that indicate an attack, this is a content, or string based approach. The strength of the content based approach is that it is able to collect all of the data of a connection once an attack string is detected. The weakness of this approach is that it is virtually impossible to analyze and record all of the traffic on a network, therefore many services, or ports are filtered out making the system blind to attacks using these ports or services. </P>
<P> </P><DIR>
<DIR>
<P> </P></DIR>
</DIR>
<P> <B>Overview of Step Sensor and Analysis System</P><DIR>
<DIR>
</B><P>The sensor is (usually) located outside your firewall and between your firewall and your internet connection, an area often called the DMZ. One of the design features of the step sensor is that it has no knowledge of what it is looking for, it simply collects all packets. This way, if it should ever be compromised (systems outside of your firewall should be considered high risk) the attacker will have get any idea of what your organization is filtering for. We recommend that you install a small hub, to support the sensor. This way if you ever need to plug in an additional sensor such as a sniffer to support your incident response team it is easy to do so. </P>
<P>The analysis station is located inside your firewall. Its job is to download and evaluate the data collected by the sensor. It uses filters to collect events of interest (such as probable attacks). This information will then be displayed on a web page.</P>
<P>The information that is displayed on the web page is the result of tcpdump filters matching conditions that we are looking for in the data. This booklet contains a large number of example filters to help you flag the events in your data that you are interested in. Some patterns cannot be detected using the tcpdump filter language. Also, some attacks that are low and slow (such as a scan that uses one packet per day) probably will not be detected with a one hour interval. An analysis toolkit written in perl has been developed to handle these kinds of problems and will be thesubject of a future cider project "Traffic Analysis Techniques for Network Data".</P>
<P>The computers may be any Unix systems that can compile libpcap and tcpdump. You will need root access on these systems. You will also need a recent version of Perl, gzip, the Apache web server and secure shell installed on the analysis system (the sensor needs gzip and secure shell). </P><DIR>
<DIR>
<P>Intrusion detection requires a very large amount of disk space. More than half of your cost may be tied up in mass storage. Our reference system uses a twenty-three gigabyte (Seagate Elite 23) on the sensor and two twenty-three gigabyte Seagate Elite 23s on the analysis station. Any large disk drive compatible with your Unix systems should work. </P></DIR>
</DIR>
<P> </P></DIR>
</DIR>
<P> </P><DIR>
<DIR>
<P> </P></DIR>
<B><P>Step 1: Acquiring the software for the Step System</P><DIR>
</B><P>The software is available at no cost from the Lawrence Berkeley Research Laboratory the Naval Surface Warfare Center, and the SANS Institute.</P>
<P>Action 1.1. 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></P>
<FONT FACE="Arial" SIZE=2><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. </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 step 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</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>
<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 step 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> </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></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.sh, start_logger.sh and stop_logger.sh.</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 step tar file. The files in the sensor directory are needed to build the sensor. Copy these files to the sensor's /usr/local/bin 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 step programs expect secure shell to be present for secure file transfer. +++ What about time synchronization? +++ 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!</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. </P>
<P>Cron requires a particular format; the line we added to our cron file is below:</P>
<B><P>0 * * * * /usr/local/bin/tcpdump.driver.sh > /dev/null 2>&1</P>
</B><P>This entry tells cron to execute a shell script named tcpdump.driver.sh at the zero minute of every hour.</P>
<P>Action 3.5 Review the activities of tcpdump.driver.sh. This is the program, run every hour by cron, that sets up some variables, calls one shell script to stop the current tcpdump, run and then calls another shell script to start tcpdump again.</P>
<P>Stop_logger.sh is the shell script that stops the old tcpdump file and starts a new one every hour. Experience shows that one hour is a long time to run tcpdump. Now that we have stopped the logger, we must start it again. This is what start_logger.sh does.</P>
<P>The other program, Cleanup.pl, runs on the analysis station rather than the sensor. It is called by cron and its job is to keep the sensor’s disk from filling up by deleting older tcpdump files. We store three days worth of data on the sensor, but this is configurable.</P>
<P>Action 3.6 Test the tcpdump.driver.sh 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.</P>
<P>And 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 firewall to allow secure shell initiated from the analysis station inside the firewall to copy the data from the sensor to the analysis station. No other system except the sensor should be allowed to access the analysis station through the firewall.</P>
<P>Action 4.2 Edit cron to call fetchem.pl</P>
<P>Here is a cron example</P>
<B><P>7 * * * * /usr/local/bin/fetchem.pl > /dev/null 2>&1</P>
</B><P>Fetchem.pl's job is to pull from the sensor machine the raw tcpdump file, store it in a descriptive directory, and run it through tcpdump again with a filter file called "bad_events" which will detect those events you suspect may be intrusion attempts. The output from this tcpdump filter run is written to a file that happens to be within the domain 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>Action 4.3 Install libpcap, tcpdump and tcpslice on the analysis station.</P>
<P>Action 4.4 Create a test bad_events file. Section 5 discusses filters including a complex filter called bad_events. For test purposes you may want to temporarily use a simple inclusive filter for testing. A file named bad_events with the following contents:</FONT><B><FONT FACE="Courier New" SIZE=2> </P>
<P>tcp and (tcp[13] & 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 tcpheader. 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).</P></DIR>
</DIR>
<P>============</P>
<P>(Begin Sidebar … To run alongside paragraph above)</P>
<B><U><P>TCP CODE BITS </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 interactively and see whether the files are correctly being copied from the sensor into the /LOG directory.</P></DIR>
</DIR>
<P>Step 5. Use tcpdump and its filters </P>
<P>This section is a step-by-step guide for learning the language you will use to control tcpdump's filtering activities. The man page for tcpdump is an excellent resource. To get the most out of your system you will want to be able to customize your filters. </P>
<P>Tcpdump can operate in two modes: raw packet collection and packet filtering. The sensor merely reads the raw packets from the network and saves them into a file. The analysis station reads the packet files and applies filters to look for specific patterns. Lets take a look at examples of simple filters that we have found to be useful. Simple filters can be strung together with "and", "or" and so forth to make a more complex filter. We will also have an example of a complex filter.</P>
<B><P>NOTE: </B>This is a good point to advise readers that a beginning intrusion detection analyst should be very slow to panic! IMAP, PORTMAP and so forth are common attacks, but are also commonly used services. Take some time to learn how your site does business network wise. Of course, once you start looking, it is probable that you will detect some attempted attacks.</P>
<P>Example 5.1: Simple filter to detect telnets.</P><DIR>
<DIR>
<P>Since the files are so large, especially on busy networks, the files are kept compressed. So the first thing we will do in constructing our filter is call GNU Unzip. Here is the whole command:</P>
</FONT><B><FONT FACE="Courier New" SIZE=2><P>$ gunzip -c yourlogfile.gz | tcpdump -r - "tcp and dst port 23"</P>
</B></FONT><FONT FACE="Arial" SIZE=2><P>tcpdump -r - tells tcpdump to read from a file instead of a network interface and the trailing dash means standard input (the output of gunziping the logfile). Our filter is in quotes. For the remainder of these filter examples, we will provide only the filter itself rather than the whole command line.</P></DIR>
</DIR>
<P>Example 5.2 A filter for IMAP.</P><DIR>
<DIR>
<P>The following filter scans packets looking for tcp SYN and FIN packets sent to destination port 143, the IMAP service. IMAP is a very common attack. </P>
</FONT><B><FONT FACE="Courier New" SIZE=2><P>tcp and (tcp[13] & 3 != 0) and (dst port 143)</P>
</B></FONT><FONT FACE="Arial" SIZE=2><P>This filter above is pretty simple. The term "dst port" refers to the destination port. Most Unix computers have a file called /etc/services which provide names for these numeric ports. For instance email (smtp) is TCP port 25, telnet is TCP port 23 and so forth. IMAP as we mentioned earlier is port 143.</P></DIR>
</DIR>
<P>============</P>
<P>(Begin Sidebar … Please run alongside filter above)</P>
<B><U><P>More about SYN and FIN</P>
</B></U><P>Many sites block IMAP (TCP Port 143) because a vulnerability in this service was one of the most successful attack exploits ever. If the service is blocked all that will be detected is the connection request, a packet with the SYN flag set. Recently a new variety of IMAP exploit script has been detected in which the packets have both the SYN and FIN flags set. The purpose of this may be to avoid completing the TCP three way handshake and therefor possibly avoid detection. By masking tcp[13] with & 3 != 0 you get both the SYN and FIN, if you use & 2 != 0 you will only get SYN.</P>
<P>(End Sidebar)</P>
<P>============</P>
<P> </P><DIR>
<DIR>
<P>If the filter finds the target pattern in a data file, tcpdump will display the results. Let’s begin to look at some sample output!</P>
<P>First here is our file-naming format.</P>
<P>98 = The year, 1998, we aren’t doing date mathematics so 2000 isn’t an issue</P>
<P>01 = The month, January</P>
<P>21 = The day</P>
<P>16 = The hour in military time. Remember, we chose to roll the files over hourly. </P>
<P>In the files created by the filters there will be a lot of lines with a lot of information. As we continue to work through the examples in the book, this format will become very familiar. The primary fields are listed below :</P>
</FONT><B><FONT FACE="Courier New" SIZE=2><P>Time Sourcehost.sourceport > Desthost.destport</P></DIR>
</DIR>
</B></FONT><FONT FACE="Arial" SIZE=2><P>Here is an example from a file named </FONT><FONT FACE="Courier New" SIZE=2>98012116.txt:</P><DIR>
<DIR>
<B><P>16:33:14.296403 linux.zsagvari.c3.hu.35486 > 204.34.256.1.imap: S 0:0(0) win 512</P>
</B><P> </P></DIR>
</DIR>
</FONT><FONT FACE="Arial" SIZE=2><P>Example 5.3 ICMP filter</P>
<P>Here is another simple filter from the tcpdump man page to look for all ICMP packets that are not echo requests/replies (i.e., not ping packets).</P><DIR>
<DIR>
</FONT><B><FONT FACE="Courier New" SIZE=2><P>icmp[0] != 8 and icmp[0] != 0</P>
</B></FONT><FONT FACE="Arial" SIZE=2><P>ICMP message types are not listed in /etc/services. However you may find a helpful file in /usr/include/netinet/ip_icmp.h that defines the names of the ICMP message numbers. ICMP, the Internet Control Message Protocol, is not exploited to break in to your site’s computer systems. However, it is being used, for numerous denial of service attacks. ICMP was designed as a network health indicator and if you were to suddenly see a lot of "TIMEXs" Time exceeded, or UNREACH, (net, host, protocol … unreachable), SOURCEQUENCH this could indicate network problems.</P>
<P>NOTE: Time exceeded and port unreachable messages are also a potential result of running the traceroute program from one of your site's host computers. Traceroute sends out packets to probe for the identities of all the routers along a network path and gathers the data it needs from there ICMP messages.</P></DIR>
</DIR>
<P>Example 5.4 Construct a filter to detect broadcasts:</P><DIR>
<DIR>
</FONT><B><FONT FACE="Courier New" SIZE=2><P>ip and ip[19] = 0xff</P>
</B></FONT><FONT FACE="Arial" SIZE=2><P>One of the classic attacks with ICMP, in which very large ping packets are fragmented, is often combined with a broadcast. After all, why go for a system when you can go for a subnet? Also many automated scanners send probes to broadcast addresses, this filter will detect these as well. A filter like the one above will detect the broadcast ICMPs, or any other broadcasts. Here is sample output from a filter match for ICMP:</P>
</FONT><FONT FACE="Courier New" SIZE=2><P>16:00:03.828071 fraggg.org > 128.256.15.255: (frag 27392:548@1480)</P>
<P>16:00:03.896593 fraggg.org > 128.256.1.255: (frag 21248:548@1480)</P>
<P>16:00:06.118729 fraggg.org > 128.256.15.255: icmp: echo request (frag </P>
<P>52480:1480@0+)</P>
<P>16:00:06.250349 fraggg.org > 128.256.15.255: (frag 52480:548@1480)</P>
</FONT><FONT FACE="Arial" SIZE=2><P>(Fraggg.org could well be spoofed. When you send an ICMP echo request (ping) to a subnet broadcast address e.g.172.16.1.255, all the systems on 172.16.1 are supposed to answer the computer that "pinged" them. If many subnet addresses are pinged and the source address is spoofed, the ensuing flood of ICMP echo replies can flood fraggg.org's internet connection.)</P>
<P>============</P>
<P>(Begin Sidebar … Please run alongside material above)</P>
<B><P>Directed broadcast.</P>
</B><P>If you see this type of broadcast on your network, it is likely that your router, or your internet service provider's router, is configured to allow the "directed broadcast" option. We recommend that you change the router configuration to disable this. For further information please see: </FONT><A HREF="http://www.quadrunner.com/~chuegen/smurf.txt">http://www.quadrunner.com/~chuegen/smurf.txt</A></P>
<FONT FACE="Arial" SIZE=2><P>(End Sidebar)</P>
<P>============</P></DIR>
</DIR>
<P>Example 5.5 Land attack filter</P>
<P>Speaking of denial of service, it turns out that some computer systems will freeze if they receive a packet in which the source address is spoofed to be the same as the destination address. Here is a filter to detect this:</P><DIR>
<DIR>
</FONT><B><FONT FACE="Courier New" SIZE=2><P>ip and ip[12:4] = ip[16:4]</P></DIR>
</DIR>
</B></FONT><FONT FACE="Arial" SIZE=2><P>Example 5.6 A filter designed to detect SNMP</P><DIR>
<DIR>
</FONT><B><FONT FACE="Courier New" SIZE=2><P>(udp port 161 or udp port 162) and not src net 172.17</P>
</B></FONT><FONT FACE="Arial" SIZE=2><P>SNMP was developed for network management. However, adversaries of your organization can use SNMP to collect a lot of information about your networks and computer systems. Network appliances, such as routers, hubs and bridges, devices often have SNMP agents built in but, in addition, many other devices, such as print servers and X terminals, have built-in SNMP agents. These devices use a "community string" to control access. Many SNMP agents default to a community string called public, which means just that.</P></DIR>
</DIR>
<P>Example 5.7 A filter to watch for the r-utilities:</P><DIR>
<DIR>
</FONT><B><FONT FACE="Courier New" SIZE=2><P>ip and ( tcp dst port 512 or tcp dst port 513 or tcp dst port 514 )</P>
</B></FONT><FONT FACE="Arial" SIZE=2><P>The r-utilities, rlogin, rshell and so forth, allow two trusted systems to exchange files and commands without authentication. Ideally, systems that need to do this type of trusted exchange across the internet will change to secure shell or some other more secure mechanism. Two problems arise with the use of r-utilities: (1) /etc/hosts.equiv and (2) individual user’s .rhosts files. If a system has a "+ +" in its host.equiv, that means it trusts all users from all systems. Needless to say, it is wise to look out for packets with r-utilities from unknown sites.</P></DIR>
</DIR>
<P>Example 5.8 A filter to detect access to portmapper:</P><DIR>
<DIR>
</FONT><B><FONT FACE="Courier New" SIZE=2><P>ip and dst port 111</P>
</B></FONT><FONT FACE="Arial" SIZE=2><P>My /etc/services file calls this sunrpc. RPCs tend to connect to portmapper at either TCP or UDP 111 to find other services. This is a very old (and effective) gateway to a series of attacks. In late 1997, we started to see an increase in portmap attempts.</P>
</FONT><FONT FACE="Courier New" SIZE=2><P>From 98012403.txt:</P>
<P>03:20:42.579548 netgate.srn.com.829 > ns2.nnnn.navy.mil.sunrpc: S </P>
<P>3648872793:3648872793(0) win 512 <mss 1460></P>
<P>03:20:45.547040 netgate.srn.com.829 > ns2.nswc.navy.mil.sunrpc: S </P>
<P>3648872793:3648872793(0) win 31744 <mss 1460></P>
<P>03:20:51.549055 netgate.srn.com.829 > ns2.nswc.navy.mil.sunrpc: <B>S</B> </P>
</FONT><FONT FACE="Arial" SIZE=2><P>Note the ‘<B>S</B>’, or SYN packet flag. A firewall screens the DNS server ns2.nswc.navy.mil so that the sunrpc attempt never actually reaches it.</FONT><FONT FACE="Courier New" SIZE=2> </P></DIR>
</DIR>
</FONT><FONT FACE="Arial" SIZE=2><P>Example 5.9 An NFS filter</P>
<P>NFS is a good service to keep an eye on, and here is a filter to do it:</P><DIR>
<DIR>
</FONT><B><FONT FACE="Courier New" SIZE=2><P>ip and udp port 2049</P>
</B><P>05:17:50.562188 j.K.EDU.885 > dorad.nnnn.navy.mil.nfs: 40 null</P>
<P>17:52.553265 j.K.EDU.885 > dorad.nnnn.navy.mil.nfs: 40 null</P>
<P>05:17:56.551772 j.K.EDU.885 > dorad.nnnn.navy.mil.nfs: 40 null</P>
</FONT><FONT FACE="Arial" SIZE=2><P>Not all "hits" are intrusion attempts. Our assessment of the data series above is that it shows the results from an automated process with a typographical error that happens to be dorad's internet address. Also NFS can run on TCP so you might wish to modify the filter to say:</P>
</FONT><B><FONT FACE="Courier New" SIZE=2><P>ip and udp port 2049 or ((tcp[13] & 2 != 0) and (dst port 2049))</P>
<P>or</P>
<P>ip and udp port 2049 or tcp[2:2] = 2049</P>
</B></FONT><FONT FACE="Arial" SIZE=2><P>NOTE: 2049 may be NFS and it may be used for something else. Don't panic the first time you run this! </P></DIR>
</DIR>
<P>Example 5.10 A NetBIOS filter.</P>
<P>Microsoft Workgroup for Windows, Windows 95, Windows NT and SAMBA all use a protocol called NetBIOS to communicate over the internet. This protocol uses ports 137, 138, 139 of both TCP and UDP. Let’s build this filter one part at a time:</P><DIR>
<DIR>
</FONT><B><FONT FACE="Courier New" SIZE=2><P>ip and </P>
</B></FONT><FONT FACE="Arial" SIZE=2><P>Will match both TCP and UDP Now we need to match the port numbers: 137, 138, 139</P>
</FONT><B><FONT FACE="Courier New" SIZE=2><P>port 137 or port 138 or port 139</P>
</B></FONT><FONT FACE="Arial" SIZE=2><P>Add parentheses for the precedence challenged</P>
</FONT><B><FONT FACE="Courier New" SIZE=2><P>ip and (port 137 or port 138 or port 139)</P>
</B></FONT><FONT FACE="Arial" SIZE=2><P> </P>
<P>If the destination is NetBIOS nameservice (port 137) and source port is not 137 the connecting computer is probably SAMBA, under most circumstances you probably don't care, but if you do:</P>
<P> </P>
</FONT><B><FONT FACE="Courier New" SIZE=2><P>ip and dst port 137 and not src port 137</P>
</B></FONT><FONT FACE="Arial" SIZE=2><P> </P></DIR>
</DIR>
<P>Example 5.11 An X11 filter. X11 is a protocol that allows one to run a program on one Unix host and display the results in a window on a separate Unix workstation. If configured incorrectly, it is possible for an attacker to obtain a screen dump of what is currently shown on your workstation, monitor all of your keystrokes, and even insert their own keystrokes into some software that you may be running. X11 uses TCP port 6000 and sometimes the nearby higher ports. An example filter for this would be:</P>
<P> </P>
<P> </FONT><B><FONT FACE="Courier New" SIZE=2>tcp and (port 6000 or port 6001 or port 6002)</P>
<P> </P>
</B></FONT><FONT FACE="Arial" SIZE=2><P>or, perhaps it would be better to write it this way:</P>
<P> </FONT><B><FONT FACE="Courier New" SIZE=2>tcp and (tcp[13] & 2 != 0) and (dst port 6000 or dst port 6001 or dst port 6002)</P>
</B></FONT><FONT FACE="Arial" SIZE=2><P>Example 5.12 An IRC filter.</P>
<P>IRC is a real-time chat system that runs over the Internet usually using TCP port 6667. When a Unix system is compromised by an attacker, it is very common for the attacker to install an IRC server on that computer -- sometimes they will then use the server to chat with their cohorts about other attacks. So, even if your organization makes absolutely no use of IRC, it is useful to monitor for it since it can be a warning sign of a compromised machine. A filter for this would be</P>
<P> </P>
<P> </FONT><B><FONT FACE="Courier New" SIZE=2>tcp and port 6667</P>
</B></FONT><FONT FACE="Arial" SIZE=2><P> </P>
<P>Example 5.13 An NNTP filter.</P>
<P> </P>
<P>NNTP is the protocol used for exchanging the messages that appear in Usenet newsgroups. If you have an NNTP server on your network that communicates with an external server (often the NNTP server of your Internet provider) you will undoubtedly see a huge amount of traffic for its TCP port number, 119. If you do not exchange messages with the outside world via NNTP, you still may see occasional packets, possibly from attackers that want to break into your server, but possibly also from attackers seeking sensitive information from your private internal newsgroups.</P>
<P> A filter for NNTP would be</P>
<P> </P>
<P> </FONT><B><FONT FACE="Courier New" SIZE=2>tcp and port 119</P>
</B></FONT><FONT FACE="Arial" SIZE=2><P> </P>
<P> Example 5.14 A filter to detect fragments.</P>
<P> </P>
<P>Fragmentation is sometimes used to evade intrusion detection systems. Excessive fragmentation can also indicate problems with network configuration. NOTE: sites that do NFS over the internet probably do not want to run this filter as NFS likes large data chunks.</P>
<P> A filter to detect fragments would be</P>
<P> </P>
<P> </FONT><B><FONT FACE="Courier New" SIZE=2>ip[6:2] & 0x2000 != 0</P>
</B></FONT><FONT FACE="Arial" SIZE=2><P> </P>
<P> </P>
<P>Example 5.15 A filter to detect socks.</P>
<P> </P>
<P>Socks runs on TCP port 1080. We have detected several probes to 1080. One CERT advises that there are exploits that allow an attacker to establish a connection to port 1080 and then bounce out from the system to attack or probe another computer. This way the attack would look like it comes from your network. It is important to detect SYN attempts to 1080 since it is a commonly used port for FTP and HTTP port counting.</P>
<P> A filter to detect socks would be</P>
<P> </P>
<P> </FONT><B><FONT FACE="Courier New" SIZE=2>tcp and (tcp[13] & 2 != 0) and (dst port 1080)</P>
</B></FONT><FONT FACE="Arial" SIZE=2><P> </P>
<P> </P>
<P>Example 5.16 Construct a bad_events filter. </P>
<P>Sophisticated filters can be constructed to scan for any set of events you want to detect. For example, here’s a portion of a script called "bad_events" that is used to detect any packets that could indicate suspicious activity that might warrant further attention. This filter might be an excellent start towards implementing an intrusion detection capability at your site.</P>
<P>If you find the filter syntax to be a bit tricky, you’ll need access to a book called <U>Internetworking with TCP/IP Volume I</U> by Douglas E. Comer, before you can do anything really fancy. The book will be a good investment for your organization. <U>TCP/IP Illustrated, Volume 1</U> by Richard Stevens is another excellent resource which gives examples using tcpdump output. In fact someone probably already has these, so try to borrow one until your copy comes in.</P><DIR>
<DIR>
</FONT><B><FONT FACE="Courier New" SIZE=2><P>(tcp and (tcp[13] & 3 != 0) and</P>
<P>((dst port 143) or</P>
<P>(dst port 111) or</P>
<P>(tcp[13] & 3 != 0 and tcp[13] & 0x10 = 0 and dst net 172.16 and dst port 1080) or</P>
<P>(dst port 512 or dst port 513 or dst port 514) or</P>
<P>((ip[19] = 0xff) and not (net 172.16/16 or net 192.168/16)) or</P>
<P>(ip[12:4] = ip[16:4]))) </P>
<P>or</P>
<P>(not tcp and not igrp and not dst port 520 and</P>
<P>((dst port 111) or</P>
<P>(udp port 2049) or</P>
<P>((ip[19] = 0xff) and not (net 172.16/16 or net 192.168/16)) or</P>
<P>(ip[12:4] = ip[16:4])))</P>
</B></FONT><FONT FACE="Arial" SIZE=2><P> </P>
<P> </P>
<P> </P></DIR>
</DIR>
<P>Step 6. Display the information for maximum analytical value</P>
<P>Let’s consider what you have done so far. You have set up the sensor in the DMZ. You have collected data; yes, a lot of data. You have examined this data with filters.</P>
<P>Sadly, when the files get very large, it takes increasingly large amounts of time to parse the files with filters. And when tasks take time and effort, many people just quit doing those tasks. For this reason, how we display the information is every bit as important as what we filter for.</P>
<P>One of the advantages to the Step architecture is that a single analysis station can support multiple sensors (make sure you stagger the file downloads in the cron files so that you aren't filtering the sensor data from multiple sensors at the same time).</P>
<P>Action 6.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 bad_events filter 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> </P>
<P>Action 6.2 Using a "bad_events" filter 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 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. As we discussed in the filter section, 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] & 2 != 0) and dst net 192.168 and dst port < 1024)</P>
</B></FONT><FONT FACE="Arial" SIZE=2><P>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] & 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 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 6.3 Beginning intrusion detection</P>
<P> </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>
<P> </P>
<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> $ one_day_pat.pl -d 980520 -l NNNN -p 'host srn.badguy.org'</P>
<P> </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. Remember, only the events</P>
<P> matched by the pattern will be displayed on the web page. From</P>
<P> time to time, you will want to try experimental filters to see</P>
<P> what you can detect.</P>
<P> </P>
<P> What are some common attacks to detect, you might ask? It is</P>
<P> sometimes difficult to tell, however, some attacks are quite</P>
<P> noticeable. For example, an attacker might try a subnet, host,</P>
<P> or port scan in order to map parts of your network. This type </P>
<P> of attack can be observed by noting the changes in subnet, host, </P>
<P> or port portion of the destination IP address. A port scan may</P>
<P> look something like this: </P>
<P> </P>
<P>12:00:01.276556 srn.badguy.org > 128.256.15.42.21: S 3201421942:3201421942(0) win 512 <mss 1460) </P>
<P>12:00:01.277237 srn.badguy.org > 128.256.15.42.22: S 1720311009:1720311009(0) win 512 <mss 1460) 12:00:01.294142 srn.badguy.org > 128.256.15.42.23: S 1104712552:1104712552(0) win 512 <mss 1460) </P>
<P>12:00:01.315076 srn.badguy.org > 128.256.15.42.24: S 3049097370:3049097370(0) win 512 <mss 1460) </P>
<P>12:00:01.371799 srn.badguy.org > 128.256.15.42.25: S 58837740:58837740(0) win 512 <mss 1460) </P>
<P>12:00:01.372513 srn.badguy.org > 128.256.15.42.26: S 1186269549:1186269549(0) win 512 <mss 1460) </P>
<P>12:00:01.373306 srn.badguy.org > 128.256.15.42.27: S 2264340599:2264340599(0) win 512 <mss 1460) </P>
<P> </P>
<P> This attack is easy to notice since the scan proceeds step by</P>
<P> step with an increment in the destination IP address port number </P>
<P> for each call. However, attacks may not be this easy to spot. </P>
<P> Attackers may use different host names, attempt to collect</P>
<P> information at different time intervals, change their method of</P>
<P> attack, etc. in order to try to avoid detection. It is useful to</P>
<P> know which subnets, hosts, and ports are important to your work,</P>
<P> and pay careful attention to users attempting to access these </P>
<P> systems. For instance, attackers attempting to connect to ports </P>
<P> such as FTP, TELNET, DOMAIN, SUNRPC, NETBIOS, IMAP, and other</P>
<P> important ports that you implement should be observed and reported.</P>
<P> Lets look at the following example: </P>
<P> </P>
<P>12:00:01.614233 srn.badguy.org.0 > 128.256.15.0.53: SF 2617442304:2617442304(0) win 512</P>
<P>12:00:01.629325 srn.badguy.org.0 > 128.256.15.1.53: SF 2617442304:2617442304(0) win 512</P>
<P>12:00:01.653388 srn.badguy.org.0 > 128.256.15.2.53: SF 2617442304:2617442304(0) win 512</P>
<P>12:00:01.670736 srn.badguy.org.0 > 128.256.15.3.53: SF 2617442304:2617442304(0) win 512</P>
<P>12:00:01.692327 srn.badguy.org.0 > 128.256.15.4.53: SF 2617442304:2617442304(0) win 512</P>
<P>12:00:01.711127 srn.badguy.org.0 > 128.256.15.5.53: SF 2617442304:2617442304(0) win 512</P>
<P>12:00:01.729200 srn.badguy.org.0 > 128.256.15.6.53: SF 2617442304:2617442304(0) win 512</P>
<P>12:00:01.749778 srn.badguy.org.0 > 128.256.15.7.53: SF 2617442304:2617442304(0) win 512</P>
<P>12:00:01.769174 srn.badguy.org.0 > 128.256.15.8.53: SF 2617442304:2617442304(0) win 512</P>
<P> </P>
<P> The first thing you may notice is that the attacker is sending </P>
<P> packets to incrementing hosts on the subnet 128.256.15.x. He is </P>
<P> attempting to connect to the DOMAIN port (TCP port 53) on each of</P>
<P> these hosts. In this case, the attacker is trying to find dns zones. </P>
<P> Also notice the attacker is sending packets with both the SYN and FIN</P>
<P> flags set. Please refer to Example 5.2 for more information about</P>
<P> this type of packet. This is an attack to report, even if the attacker</P>
<P> is not getting through your firewall. The fact that an attacker is attempting</P>
<P> to find information or weaknesses is enough cause to file a report. You </P>
<P> can never be too safe. Another attack to report might look something like</P>
<P> this:</P>
<P> </P>
</FONT><FONT FACE="Arial" SIZE=1><P>12:00:43.55 srn.badguy.org.13902 > 128.256.1.1.23: S 3494448575:3494448575(0) win 512 <mss 1460></P>
<P>12:00:43.55 128.256.1.1.23 > srn.badguy.org.13902: S 1160640001:1160640001(0) ack 3494448576 win 32768 <mss 1460> (DF)</P>
<P>12:00:43.63 srn.badguy.org.13903 > 128.256.1.105.23: S 3466349419:3466349419(0) win 512 <mss 1460></P>
<P>12:00:43.63 128.256.1.105.23 > srn.badguy.org.13903: S 2737045410:2737045410(0) ack 3466349420 win 8760 <mss 1460> (DF)</P>
<P>12:00:45.74 128.256.1.1.23 > srn.badguy.org.13902: S 1160640001:1160640001(0) ack 3494448576 win 32768 <mss 1460> (DF)</P>
<P>12:00:46.54 srn.badguy.org.13902 > 128.256.1.1.23: S 3494448575:3494448575(0) win 32120 <mss 1460></P>
<P>12:00:46.54 128.256.1.1.23 > srn.badguy.org.13902: S 1160640001:1160640001(0) ack 3494448576 win 32768 <mss 1460> (DF)</P>
<P>12:00:46.63 srn.badguy.org.13903 > 128.256.1.105.23: S 3466349419:3466349419(0) win 32120 <mss 1460></P>
<P>12:00:46.63 128.256.1.105.23 > srn.badguy.org.13903: S 2737045410:2737045410(0) ack 3466349420 win 8760 <mss 1460> (DF)</P>
<P>12:00:46.91 128.256.1.105.23 > srn.badguy.org.13903: S 2737045410:2737045410(0) ack 3466349420 win 8760 <mss 1460> (DF)</P>
<P>12:00:48.54 srn.badguy.org.14429 > 128.256.1.1.143: S 810840681:810840681(0) win 512 <mss 1460></P>
<P>12:00:48.63 srn.badguy.org.14430 > 128.256.1.105.143: S 183573626:183573626(0) win 512 <mss 1460></P>
<P>12:00:51.54 srn.badguy.org.14429 > 128.256.1.1.143: S 810840681:810840681(0) win 32120 <mss 1460></P>
<P>12:00:51.63 srn.badguy.org.14430 > 128.256.1.105.143: S 183573626:183573626(0) win 32120 <mss 1460></P>
<P>12:00:53.48 128.256.1.105.23 > srn.badguy.org.13903: S 2737045410:2737045410(0) ack 3466349420 win 8760 <mss 1460> (DF)</P>
<P>12:00:55.74 128.256.1.1.23 > srn.badguy.org.13902: S 1160640001:1160640001(0) ack 3494448576 win 32768 <mss 1460> (DF)</P>
<P>12:01:06.61 128.256.1.105.23 > srn.badguy.org.13903: S 2737045410:2737045410(0) ack 3466349420 win 8760 <mss 1460> (DF)</P>
</FONT><FONT FACE="Arial" SIZE=2><P> </P>
<P> In this case, the attacker is trying to find out if connections are possible through </P>
<P> the firewall to TCP ports 23 and 143, TELNET and IMAP respectively. Observe the packets </P>
<P> returned by the attacker's target addresses. These packets indicate to the attacker</P>
<P> that the target hosts support connection to port 23, TELNET, since the returned</P>
<P> packets are sent to the attacker from port 23. Since no packets are returned from</P>
<P> port 143, the target hosts do not support connection to the IMAP port. </P>
</FONT><FONT FACE="Courier New" SIZE=2><P> </P>
</FONT><FONT FACE="Arial" SIZE=2><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 you may see during intrusion detection. Although</P>
<P> you may have a lot of data to finger through, 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> </P></DIR>
</DIR>
<P>Action 6.4 Responding to a detect - So what if you find something?</P>
<P> </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> </P>
<P>$ one_day_pat.pl -d 980520 -l NNNN -p 'host srn.badguy.org' > host.time &</P>
<P> </P>
<P>Then you can run</P>
<P> </P>
<P>$ tail -f host.time</P>
<P> </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> </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) for faster results. The following command will accomplish this:</P>
<P> </P>
<P>$ tcpdump -r 98051512 'host 192.168.1.1' > host.time &</P>
<P> </P>
<P>$ tail -f host.time</P>
<P> </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, except that this is an</P>
<P>indicator the packets are getting through your firewall. Otherwise, if you</P>
<P>do see replies, you probably want to alert your organization's computer</P>
<P>incident response team. Again, it is also a good idea to set up some sort of reporting </P>
<P>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</P>
<P>incident handling team or how to respond to incidents, see SANS Computer</P>
<P>Incident Handling Step-by-Step.</P>
<P> </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> </P>
<P>$ ssh -l root sensor</P>
<P> </P>
<P># df</P>
<P> </P>
<P># cd /LOG</P>
<P> </P>
<P># mkdir host.date; cd host.date</P>
<P> </P>
<P># tcpdump -n 'net 192.168.1' > time &</P>
<P> </P>
<P>#tail -f time &</P>
<P> </P>
<P>This way you will have information to provide the incident handling team.</P>
<P> </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> </P>
<P>Enhancing your Intrusion Detection Capability</P>
<P> </P>
<P>Step 7. Implement more advanced analytical capabilities.</P>
<P> </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> </P>
<P>Example 7.1 A filter to detect all non-smtp or domain accesses to your mail</P>
<P>and name server (DNS) hosts:</P>
<P> </P>
<P>ip and (host mailhost.your.org or</P>
<P> </P>
<P>host nameserver.your.org)</P>
<P> </P>
<P>and not (dst port smtp or dst port domain)</P>
<P> </P>
<P>At most sites, the systems that draw the most attacks are your DNS and</P>
<P>e-mail servers. They become prime targets because their IP addresses are</P>
<P>well advertised and because, if an attacker can gain control of these</P>
<P>systems, the attacker can probably control your whole site fairly soon</P>
<P>thereafter. In the case of these core hosts, don't just watch incoming</P>
<P>traffic. You should also be concerned if your nameserver or mailserver</P>
<P>starts establishing connections with outside hosts. This could be a sign</P>
<P>that your system has been compromised.</P>
<P> </P>
<P>Example 7.2 A bad hosts filter.</P>
<P> </P>
<P>After you detect an attack from a host, you will want to add it to a bad</P>
<P>hosts list. Working through the SANS Institute, you may be able to find</P>
<P>organizations that are in similar, or complementary lines of work as yours,</P>
<P>and with whom you can share attack information.</P>
<P> </P>
<P>Here is a filter that can help you do this, of course you have to add your</P>
<P>own bad hosts.</P>
<P> </P>
<P>ip and (host bad.guy.org or host 192.168.1.200 or</P>
<P> </P>
<P>net 192.168.4 or net 176.16.41 or net 10.1</P>
<P> </P>
<P>)</P>
<P> </P>
<P>Action 7.3 Reduce the data volume</P>
<P> </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> </P>
<P> first we use filters to separate the data by protocol.</P>
<P> </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> </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> </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> </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> </P>
<P> $ tcpslice *.9802* > tcpdump.980202</P>
<P> </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> </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> </P>
<P> $ tcpdump -r tcpdump.980202 udp > udp.980202</P>
<P> </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> </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> </P>
<P> $ tcpdump -r tcpdump.980202 (not udp and not tcp and not icmp and</P>
<P> not igrp and not igmp) > other.980202</P>
<P> </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> </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> </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> </P>
<P> </P>
<P> </P>
</FONT><P> </P></BODY>
</HTML>
© 2022 Packet Storm. All rights reserved.
%7Cutmcsr%3D(direct)%7Cutmcmd%3D(none)){kind=small}
Follow us on Twitter
Follow us on Facebook
Subscribe to an RSS Feed