Snort
Ron McCarty My columns have recently covered design issues of networking including DNS, caching, and intrusion detection, so a break from the design consideration to a “how-to” is in order. In “Intrusion Detection Strategies and Design Considerations” (Sys Admin, September 1999), I covered intrusion detection issues, and now I will examine Snort, a freely available intrusion detection system. Snort Background I came across Snort while reading security-focus.com (http://www.security-focus.com/), which is the current home of the bugtraq mailing list. Snort is written by Martin Roesch and is available at:
http://www.clark.net/~roesch/security.html One of Snort's features is its ease of installation. Snort's documentation often refers to Snort as a “Light Weight Intrusion Detection for Networks”, which may turn off some administrators seeking hard hitting commercial products. Do not be fooled by the “light weight”. Light weight does describe the product in many ways -- Snort can be downloaded in seconds on quick links, and Snort can be configured and running within minutes, using some of its very thorough “canned” rules. Snort's author does mention that Snort's language is not as thorough as the N language provided with Network Flight Recorder (http://www.nfr.com), however, it's simplicity is quickly mastered. Snort is the type of program that can be easily deployed in a distributed method throughout an organization on inexpensive Intel boxes or older workstations. Remember that Intel boxes or older workstations may not perform adequately on busy networks. Snort's technology can also be easily adapted to network appliances and integrated with lightweight UNIX-like distributions such as Trinux:
http://www.trinux.orgor the Linux Router Project:
http:// http://www.linuxrouter.org/ It is also the type of product that switch vendors will likely use or emulate to provide distributed intrusion detection to enterprise computing. Snort Architecture Figure 1 shows a simple but adequate view of the architecture of Snort. All three components emphasize speed or simplification. Roesch covers the components on his Web site (http://www.clark.net/~roesch/lisapaper.txt), so I will briefly cover the components and some issues for practical implementations. The packet decoder is responsible for layer two and up decoding. The decoder recognizes Ethernet and serial (SLIP, PPP) protocols. Token Ring, currently not supported, is a necessity for many organizations. Snort's detection engine is responsible for applying the rules to the data structures created by the packet decoder. The engine uses a two-dimensional linked list that speeds processing by allowing rules that share common root attributes (for example, the same source and destination address within the rule set) to be referenced within one column of the two-dimensional linked list. For a detailed explanation, see http://www.clark.net/~roesch/lisapaper.txt. Snort provides both logging and alert features. Logging and alerts can impact system performance, so there are various methods supported that I cover after the installation in the Logging and Alerts section. As illustrated in Figure 1, any features not directly supported may be based upon logging and alerts. (The source code is available for in-line customization, but many administrators may prefer to deploy “official” releases.) Installation and Configuration The following steps have been tested on RedHat 6 and 6.1. You need libpcap before installing Snort. libpcap is available at:
ftp://ftp.ee.lbl.gov/libpcap.tar.Z or in rpm format at:
ftp://ftp.redhat.com/pub/redhat/redhat-6.1/i386/RedHat/RPMS/libpcap-0.4-16.i386.rpm for RedHat systems. You also need to be logged in as root. You can download Snort at:
http://www.clark.net/~roesch/security.html#Download into the appropriate directory (/usr/local/) in our examples.
Expand the Snort distribution: cd /usr/local gunzip snort-1.3.1.tar.gz tar xvf snort-1.3.1.tar Change directories:
cd snort-1.3.1 Examine the README and NEWS files for any recent updates. The INSTALL file gives both a quick overview and a more thorough overview of the installation process. To proceed:
./configure (This is where the error message will show up if you don't have libpcap installed, but wanted to try installation anyway.)
make make install Assuming all goes well, the Snort executable will be created and placed in /usr/local/bin/. The rules distributed with Snort will remain in the /usr/local/snort-1.3.1/ directory. Snort requires that the network interface card be placed in promiscuous mode, which requires root access on most systems. Typically, intrusion detection systems are not installed on multi-user systems. If you run Snort on a multi-user system, you may tighten down the directory and file access rights on the /usr/local/snort-1.3.1 and the log directory (covered later). Snort comes with six existing rule bases called Snort libraries. The naming convention used by the author for Snort rules is name-lib. The six libraries are:
• backdoor-lib -- The backdoor-lib currently identifies 100+ backdoor attempts. A backdoor is an attack against a host that allows an intruder to access the host (and the network). Backdoors can be difficult to track down in environments without intrusion detection systems since the host is likely internal and not limited by security policy. The two most famous backdoor incidents that come to mind are Back Orifice (http://xforce.iss.net/alerts/advise5.php3) and the backdoor created by the Trojan infected version of TCP Wrappers (http://www.cert.org/advisories/CA-99-01-Trojan- \ TCP-Wrappers.html). • misc-lib -- misc-lib contains a 16 rules that are not easily classified into the other sets. • overflow-lib -- The overflow-lib contains six rules. (The author asks for more contributions as a comment in the library.) The overflow-lib definitely could use some assistance. Buffer overflows are inherently more dangerous on UNIX systems than other operating systems and must quickly be fixed on the host, but identification of overflow attempts is very important in intrusion detection. (OpenBSD testers could really help out here. They have invested quite a bit of time identifying, testing, and fixing overflow problems.) • scan-lib -- scan-lib offers limited identification of port scans. Snort's current implementation only identifies stealth scans -- those scans that set TCP flags (such as SYN or FIN), often used attempting to pass through firewalls. Snort does not currently have a mechanism that recognizes a sequential TCP port scan. The author reports Version 2 of the program should have better port scan recognition capability. (A rule to report attempted connection to ports not running on a particular network or host can, however, be defined for a specific network deployment. This solution is management intensive in changing environments, but may be worth considering on a DMZ or ExtraNet network.) • web-lib -- The web-lib like the overflow-lib has potential for large growth. Currently, web-lib has more than 60 rules. The rule set contains rules for CGI-related attacks, as well as IIS attacks. • snort-lib -- snort-lib contains all the rules from the other libraries.
Now you can modify a library to match your current environment. The first thing to do is replace the addresses used in the rules with the addresses that you use in your environment. For example, the scan-lib rule base uses 10.1.1.0/24 as the network addresses for comparison. Assuming your network is 10.0.0.0/8, you can use the following to change the rule base:
sed -e 's/10.1.1.0\/24/10.0.0.0\/8/' scan-lib >scan-lib.new mv -f scan-lib.new scan-lib Look at the included rule bases and notice that the rules are logging. You can tell Snort where to log using the -l parameter. If you do not specify the log directory, Snort will assume /var/log/snort. To create the directory:
mkdir /var/log/snort Start Snort using the scan-lib set up previously:
snort -c /usr/local/snort-1.3.1/scan-lib An easy way to test the scan-lib rule base is to run nmap on a remote host against the intrusion detection system. nmap can be downloaded (http://www.insecure.org/nmap/index.html#download) if you do not have the port scanner. Assuming Snort is running on 10.0.0.1, use:
nmap -sT 10.0.0.1 After the scan is complete, two items have been created in the log directory -- a directory files in the log directory containing the IP address of the attacked host, and the alert file. Type:
cat /var/log/snort/alert Something similar to the following will appear (depending on the port scanner and version running):
11/14-19:49:10.842594 192.168.1.1:45505 -> 10.0.0.1:80 TCP TTL:39 TOS:0x0 ID:27935 ****A* Seq: 0x65200003 Ack: 0x0 Win: 0x1000 [**] NMAP TCP ping! [**] 11/14-19:49:10.842750 192.168.1.1:45505 -> 10.0.0.1:80 TCP TTL:39 TOS:0x0 ID:27935 ****A* Seq: 0x65200003 Ack: 0x0 Win: 0x1000 [**] NMAP TCP ping! [**] 11/14-19:49:10.842594 192.168.1.1:45505 -> 10.0.0.1:80 TCP TTL:39 TOS:0x0 ID:27935 ****A* Seq: 0x65200003 Ack: 0x0 Win: 0x1000 [**] NMAP TCP ping! [**] 11/14-19:49:10.842750 192.168.1.1:45505 -> 10.0.0.1:80 TCP TTL:39 TOS:0x0 ID:27935 ****A* Seq: 0x65200003 Ack: 0x0 Win: 0x1000 [**] WinGate 1080 Attempt [**] 11/14-19:49:11.035811 192.168.1.1:1549 -> 10.0.0.1:1080 TCP TTL:64 TOS:0x0 ID:8755 DF S***** Seq: 0x1D048A2E Ack: 0x0 Win: 0x7D78 TCP Options => MSS: 1460 Opt 4:TS: 166392 0 NOP WS: 0 [**] WinGate 1080 Attempt [**] 11/14-19:49:11.035958 192.168.1.1:1549 -> 10.0.0.1:1080 TCP TTL:64 TOS:0x0 ID:8755 DF S***** Seq: 0x1D048A2E Ack: 0x0 Win: 0x7D78 TCP Options => MSS: 1460 Opt 4:TS: 166392 0 NOP WS: 0 The following host-specific directory was created:
ls /var/log/snort/192.168.1.1 And this gives:
TCP:1549-1080 TCP:4041-1080 TCP:45505-80 TCP:56298-80 The file names are based upon the transport protocol (TCP, in this case), the source port, followed by the destination port. All of the alerts shown in the /var/log/snort/alert log are also logged in the appropriate host directory. The alerts include logging, but logging does not include an alert. Logging and Alerts Snort supports three levels of logging: decoded (human readable as shown above), tcpdump format for speed, and no logging at all. The decoded format does not require any special command parameters (as seen in the above example). To use the tcpdump format, use the -b parameter. To not log, but leave alerts active, use the -N parameter. Alerts can also be recorded in various formats. The standard alert configuration is the alert file in the /var/log/snort/alert file as previously illustrated. The alerts can also be logged to the syslog facility using the -s parameter. Alerts can also be sent to a Windows computer using the -M and the IP address of the remote Windows computer -- assuming the intrusion detection system has smbclient (http://www.samba.org/) installed. Snort's Strengths and Weaknesses One of Snort's assets is the speed at which administrators can install and deploy the system. Although rule configuration is beyond the scope of this article, custom rules are easily created and well documented by the author of Snort at http://www.clark.net/~roesch/snort_rules.html. Anyone that has configured RADIUS filters for Ascend equipment or Cisco access lists can immediately create rules, but previous configuration experience is not required. Snort lends itself to a distributed intrusion detection model. However, customization for log rotation, statistics reporting, and general management must be created in-house. Larger organizations may require “canned” installations of the OS, some scripting for statistics reporting, and a log file utility or script to manage alerts and logging. Deployment of new rules may also need automating. IP fragmentation is a reality of today's Internet. Snort does not yet fully support reassembly of fragmented packets, but reassembly is promised in the next release. Token Ring support is definitely a must-have for many. Snort is a good fit in small- and medium-sized organizations that cannot afford a commercial system but have a real need for intrusion detection. Snort is also a very good supplement for commercial systems within all organizations. I'm sure Snort will also make it into many university computer science labs. With the appropriate “niceties” such as a Web front end, central management station with centralized off-line storage, and an alert API (all within the capabilities of many Sys Admin readers) Snort could become an enterprise solution.
About the Author
Ronald McCarty received his bachelor's degree in Computer and Information Systems at the University of Maryland's international campus at Schwaebisch Gmuend, Germany. After completing his degree, Ronald McCarty started his network career as network administrator at the Schwaebisch Gmuend campus. Ronald McCarty currently works for Software Spectrum, Inc. as a network engineer in the IT&S Network Services Project's team. He spends his free time with his two best friends in the world: his daughter, Janice, and his wife, Claudia. Ron can be reached at: mccarty@my-own-domain.to.
|