-
Introduction
Computer Intrusions are on the rise. Whether it's script kids trying to deface a web page or a calculated attacker trying to steal credit card information, sites must equip themselves to not only ward off attacks, but know if these attacks are taking place. This is where Intrusion Detection Systems (IDS) come into play. In a nutshell, an IDS is a system that sits on a network and watches for anomalies. A basic IDS watches either all of the traffic or a sampling of the traffic going through the wire. It compares this traffic to a database of fingerprints or signatures of known attacks. If an attack is detected the IDS can take multiple actions depending on the configurable response to the attack. These actions can be anything from paging the administrator to dropping the route of the attacker. More complex IDS's will also recognize anomalies in the patterns of system users. As an example, Bob always logs in from the machine named 'defiant' from the hours of 9 to 5. Suddenly Bob begins to log in from the machine named 'regret' from the hours of 1 am to 3 am on Saturdays. A robust IDS would flag this as suspect.
Naturally a system of this nature can have it shortcomings. Like a virus scanner, the IDS is only effective against attacks it knows about or has signatures for. A clever attacker could slightly modify an attack and alter the signature of the attack and sneak past the watching eyes of the IDS.
This paper will focus on the installation and basic use of Snort, a freely available and popular IDS that runs on Linux, *BSD, Solaris / SunOS, HP-UX, AIX, IRIX, and MAC OS X. Snort was even recently ported to Win32. Part II of this article will cover more advanced features such as reporting and writing customized rule sets.
Snort is an easy to use, lightweight IDS written by Marty Roesch that is capable of performing real-time traffic analysis and packet logging on IP networks. Some of the other features of Snort are:
- Protocol Analysis
- Content searching / matching
- Real-time alerting capability
- Can read in a TCPDump trace and run against a rule set
- Flexible rules language to describe traffic that it should collect or pass
Snort is also being constantly updated with new features.
-
Prerequisites
Installing an IDS on an insecure system is akin to installing a high-tech burglar alarm on your house but leaving all the doors and windows open. Ensure that the system you will be installing the IDS on is as secure as possible. Also, since IDS's traditionally have quite a bit of overhead, it is usually a good idea to dedicate a machine to running the IDS system.
Depending on what type of reporting capabilities you wish to take advantage of you might wish to install a web server and an SMTP package on the IDS system. (More on this in Part II).
The following two articles provide a good foundation for securing Linux machines:
-
Testbed
These instructions have been tested with the following:
- Slackware 4.x
- Solaris 7 sparc and Intel
- FreeBSD 4.0
-
Gathering the Required Software
- Snort www.snort.org
This paper is based on the most recent version of Snort, v1.6.6.2
- libpcap ftp://ftp.ee.lbl.gov/libpcap.tar.Z
Snort requires lipbcap for packet capture. BSD derivatives typically include libpcap; Linux typically does not
After downloading the required software packages store them in /usr/local
-
Installation
- Step 1 - Install libpcap (skip to Step 2 if you already have libpcap installed)
# gzip -d -c libpcap.tar.Z | tar xvf -
# cd libpcap-0.4/
# ./configure
# make
# make install
# make install-incl
# make install-man
- Step 2 - install Snort
# gzip -d -c snort-1.6.2.2.tar.gz | tar xvf -
# cd snort-1.6.2.2/
# ./configure
# make
# make install
-
Using Snort
To see how snort can be used to read packets off the wire try the following command:
#snort -v
-*> Snort! <*-
Version 1.6.2.2
By Martin Roesch (roesch@clark.net, www.clark.net/~roesch)
07/11-20:33:59.675507 192.168.1.10:3436 -> 192.168.1.1:53
UDP TTL:64 TOS:0x0 ID:22707
Len: 36
07/11-20:33:59.916825 192.168.1.1.436 -> 192.168.1.10:3436
UDP TTL:57 TOS:0x0 ID:1177
Len: 91
07/11-20:33:59.917642 192.168.1.10:3437 -> 192.168.1.153
UDP TTL:64 TOS:0x0 ID:22708
Len: 47
07/11-20:34:00.078208 192.168.1.1:53 -> 192.168.1.10:3437
UDP TTL:57 TOS:0x0 ID:1367
Len: 109
^C
Exiting...
======================================
Snort received 72 packets.
Packet loss statistics are unavailable under Linux. Sorry!
Breakdown by protocol:
TCP: 0 (0.000%)
UDP: 4 (5.556%)
ICMP: 0 (0.000%)
ARP: 66 (91.667%)
IPv6: 0 (0.000%)
IPX: 0 (0.000%)
OTHER: 0 (0.000%)
======================================
Lets examine the first packet we grabbed off the wire:
07/11-20:33:59.675507 192.168.1.10:3436 -> 192.168.1.1:53
|---------a---------| |---b---| |-c-| |---d---| |-e-|
UDP TTL:64 TOS:0x0 ID:22707
|f| |-g-| |--h--| |--i--|
Len: 36
|--j--|
- date/time stamp
- source ip address
- source port
- destination ip address
- destination port
- protocol
- time to live
- type of service
- packet identification
- length of packet
We can see from the transfer above that the client made a DNS request to the server.
Notice snort even generates a nice table of statistics. Unfortunately, snort cannot provide packet loss statistics under Linux but is able to do so under both FreeBSD and Solaris.
-
Running snort with a Rule set
The real power of snort lies in its ability to read in a rule set, observe the traffic going across the wire, and detect if any of the traffic matches any of the rules. Rules can be created that watch for pings, scans, backdoor attempts, cgi-attempts, and many other common methods attackers use to gain control of a target machine. Alerts can be logged to a file specified from the command line or even sent through syslog and appended to your system messages. This can all be run as a background process.
Rule sets can be written by hand. Often people use one of the freely available rule sets available on the snort homepage at http://www.snort.org/snort-files.htm. A custom interface is able to create rules to suit your taste "on the fly" at http://www.snort.org/Database/rules.asp.
To keep things simple for the time being we will generate a simple rule and examine the contents of that rule set. The following rule set was automatically generated to respond to ICMP requests.
#---------------------------------------------
# http://www.snort.org Snort 1.6 Ruleset
# Current Database Updated -- 07/12/2000
#Contact: Jim Forster - jforster@rapidnet.com
#---------------------------------------------
preprocessor http_decode: 80 443 8080
preprocessor minfrag: 128
preprocessor portscan: 192.168.1.1/24 3 5 /var/log/snort_portscan.log
# ^^^^^^^^^^^ ^ ^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^
# | | | |
#Your IP address or Network here+ | | |
# | | |
#Ammount of ports being connected-----+ | |
# in this | |
#Interval (in seconds)------------------+ |
# |
#Log file (path/name)----------------------------------+
preprocessor portscan-ignorehosts: 192.168.1.4
#---------------------------------------------
#---------------------------------------------
# CHANGE THE NEXT LINE TO REFLECT YOUR NETWORK
# (Single system = your ip/32)
var HOME_NET 192.168.1.1/24
#---------------------------------------------
alert icmp !$HOME_NET any -> $HOME_NET any (msg:"IDS166 - PING Seer
Windows"; content:"|88042020202020202020202020202020|";itype:8;depth:32;)
alert icmp !$HOME_NET any -> $HOME_NET any (msg:"IDS152 - PING BSD";
content: "|08 09 0a 0b 0c 0d 0e 0f 10 11 12 13 14 15 16 17|"; itype: 8;
depth: 32;)
alert icmp !$HOME_NET any -> $HOME_NET any (msg:"IDS153 - PING Cisco
Type.x"; content:"|abcdabcdabcdabcdabcdabcdabcdabcd|";itype:8;depth:32;)
alert icmp !$HOME_NET any -> $HOME_NET any (msg:"IDS154 - PING CyberKit 2.2
Windows"; content:"|aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa|";itype:8;depth:32;)
alert icmp !$HOME_NET any -> $HOME_NET any (msg:"IDS155 - PING Delphi-Piette
Windows"; content:"|50696e67696e672066726f6d2044656c|";itype:8;depth:32;)
alert icmp !$HOME_NET any -> $HOME_NET any (msg:"IDS156 - PING Flowpoint
2200DSL Router"; content:"|0102 0304 0506 0708 090a 0b0c 0d0e
0f10|";itype:8;depth:32;)
-- SNIP --
snort requires each rule to be on one line. Lines have been broken up in the sample above for easier readability.
The first part of the rule set (the header) deals with preprocessor directives, hosts to ignore scans from, and setting the ip address of the host machine.
Preprocessor directives: Give snort added functionality by allowing programmers to use modular plug-ins with snort easily. An example is the preprocessor directive for detecting port scans. By entering an IP address or network address, setting thresholds for amount of ports being connected to in a certain amount of seconds, and specifying a logging directory, snort will watch for connection attempts that meet that criteria and log accordingly. If you are using this directive you should also take advantage of the portscan-ignorehosts preprocessor directive. Place any IP address on this line separated by a space that snort should ignore scans from. Some servers such as DNS may trip the port scan detector so it may be desirable to ignore them. On the other hand if you already have software in place that detects port scans, this preprocessor directive can be commented out.
Preprocessor httpd_decode is used to process HTTP URI strings and convert them to ASCII strings. This is so the content analysis strings used in rule sets can be compared to the string.
Preprocessor minifrag watches for packets meeting a specified size threshold. Fragmented packets are often used by attackers to elude detection.
HOME_NET: This directive specifies the IP address/CIDR block for snort to watch.
Following these items are the rules themselves. snort requires each rule to be on an unbroken line. The rules are broken above for clarity. Part II of this paper will focus on how these rules work. In the meantime glance over the rule set, it is actually fairly easy to figure out what each rule does.
Now we can actually run snort with this rule set and see how it works:
# snort -d -h 192.168.1.1/24 -l ./log -c ping.rules -s -i eth0 -D
-d dumps the application layer
-h home network
-l log location
-c rule set name
-s log alerts to syslog
-i interface to listen on
-D run snort as a background process (daemon mode)
The first time you run snort with a rule set it may be a good idea to leave the -D switch off so you can ensure snort loads with no errors. Most of the other options above are fairly self explanatory with the exception of the log feature. Although we specified on the command line for snort to send alert messages to syslog, some additional logging is performed. The directory you specify on the command line will contain a subdirectory for each host that was detected as violating a rule and the actions they took to trigger the alert. Using the example ping rule set the following is an example of what would be found in /var/adm/messages if snort detected an alert:
Jul 12 19:18:22 strife snort[370]: IDS152 - PING BSD: 192.168.1.10 -> 192.168.1.1
Jul 12 19:18:23 strife snort[370]: IDS152 - PING BSD: 192.168.1.10 -> 192.168.1.1
Jul 12 19:18:24 strife snort[370]: IDS152 - PING BSD: 192.168.1.10 -> 192.168.1.1
Jul 12 19:18:25 strife snort[370]: IDS152 - PING BSD: 192.168.1.10 -> 192.168.1.1
Note: To find more information on attack such as that shown above you can go to http://dev.whitehats.com/ids/ids.html and do a search for the IDS number displayed. In this case, do a search for IDS152.
Now if we look in our log file, snort should have created a subdirectory containing information about the host that pinged us.
# ls log
192.168.1.10
# cd log/192.168.1.10
# ls
ICMP_ECHO
# more ICMP_ECHO
[**] IDS152 - PING BSD [**]
07/12-19:18:22.311702 192.168.1.10.200 -> 192.168.1.1
ICMP TTL:49 TOS:0x0 ID:17933
ID:48507 Seq:0 ECHO
06 28 6D 39 5A C8 04 00 08 09 0A 0B 0C 0D 0E 0F .(m9Z...........
10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F ................
20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F !"#$%&'()*+,-./
30 31 32 33 34 35 36 37 01234567
[**] IDS152 - PING BSD [**]
07/12-19:18:23.310086 192.168.1.10:200 -> 192.168.1.1
ICMP TTL:49 TOS:0x0 ID:18002
ID:48507 Seq:256 ECHO
07 28 6D 39 F1 BA 04 00 08 09 0A 0B 0C 0D 0E 0F .(m9............
10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E 1F ................
20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F !"#$%&'()*+,-./
30 31 32 33 34 35 36 37 01234567
-- SNIP --
So the additional log file that is created contains the actual packet capture of the offending event.
-
Conclusion
This has been a brief overview of using snort to both read packets off the wire and running snort with a rule set to detect attacks. Experiment with the different rule sets available on www.snort.org. Try some of the attacks the rule sets are watching for against the machine snort is running on to ensure it is properly detecting them.
In Part II of this article we will dig a little deeper into snort including monitoring the log files, taking action to attacks, generating reports, and creating custom rule sets.