Snort

Many IDSs, some commercial, some in the public domain, are currently available. Of all the IDSs, few have generated as much enthusiasm within the user community as has Snort, a public domain tool. Originally developed by Marty Roesch, Snort has, in many respects, become synonymous with new IDS capabilities. Many individuals have contributed code that has provided new functions and enhancements. Snort is now the most widely deployed IDS of all. This chapter covers the basics of Snort, its IDS components and functions, Snort rules, Snort output, special hardware and software requirements, some of the enhancements in Snort 2.0, and the advantages and limitations of this tool.

About Snort

Snort (see http://www.snort.org) is a rule-based IDS. Snort uses signatures to identify types of attacks that occur but, unlike a pure signature-based IDS, Snort does not stop there. It also uses and provides considerable additional contextual information, including how attacks have transpired and what the origin of each attack appears to be (thus leading to its being classified as a “rule-based” IDS). In version 2.0, the current version, it provides extensive protocol analysis, as well as other more sophisticated detection capabilities. This tool runs on a variety of operating systems (OSs), including Windows NT and 2000, Unix (Solaris, HP-UX, IRIX, OpenBSD, NetBSD, Free BSD, and Mac OS X), Linux, and even on PowerPCs. Although mainly known and deployed as a NIDS, Snort can serve as a HIDS if it is configured to analyze only traffic to and from an individual host. Its detection engine depends on a rudimentary language that serves as a basis for recognizing input patterns that characterize attacks. Snort deploys rules for decoding data within packets as well as packet headers, helping it recognize data-driven attacks, such as buffer overflow and improperly encoded web server chuck attacks. This IDS also provides quick and easy access to raw packet data to support inspecting network traffic more closely or reporting Snort’s findings. You can download Snort from http://www.snort.org/dl.

Tip

Although this chapter is intended to provide a working knowledge and a birds-eye view of Snort, a single chapter cannot do justice to the many details related to it. Obtaining a book on Snort, such as Brian Caswell’s Snort 2.0: Intrusion Detection (published by Syngress Press) is the best course of action for someone who wants to thoroughly understand the in’s and out’s of Snort.

Snort was originally developed not to be an end-all IDS but, rather, as a simple and flexible supplement to be run in parallel with other IDSs. The goals of Snort include to:

• Cause minimal interference with system and network performance. Accordingly, Snort 2.0, the latest version at press time, contains only about 75,000 lines of code.
• Run within numerous parts of networks, gathering data that can be collected at a single point.
• Optimize the hit rate, while keeping the false alarm rate at a minimum.
• Offer easy-to-use reporting functions.
• Work in real time in detecting incidents and providing alerts.
• Provide packet capture capabilities. As mentioned previously in Chapter 6, being able to get to packet data quickly is a critical feature in IDSs.

Snort Modes

Snort runs in three different modes: sniffer mode, packet logger mode, and intrusion detection mode. This section discusses all three modes.

Sniffer Mode

Running Snort in Sniffer mode allows you to dump data in the header and body of each packet to the screen. To start Snort so that it displays all application data, enter the following:

./snort –d (this works in most versions of Snort)

or

./snort –dv (in the current version—you need to enter the “-v” option to keep from getting an error message)

To display packet headers for IP (layer 3) and TCP, UDP, and ICMP (layer 4) packets to the screen, enter the following:

./snort -v

To display both the layer 3 and 4 packet headers, and the application data, enter the following:

./snort –dv OR ./snort –d –v

Note, entering the –e flag causes the link layer (level 2) headers also to be displayed to a screen.

Packet Logger Mode

Packet logger mode is different from Sniffer mode in that in the former, packet data and/or headers are written to the hard drive of the host on which Snort runs. To write to a directory named log on the hard drive, enter the following:

./snort -dev -l ./log

To ensure logging captures data for a local network, it is also necessary to enter the IP address range of the network, as follows:

./snort -dev -l ./log -h 10.1.1.0/24

Note, in this example, once again, the source and destination IP addresses are private addresses—addresses that would not work for moving packets over the Internet—to avoid calling attention to any particular real-world addresses. The –h flag and the following argument ensures that Snort will log the packets for which the destination IP address is in the range from 10.1.1.0 to 10.1.1.255. A separate subdirectory under log will be created for each address. If Snort runs on a high-speed network, entering the –b switch, which will cause binary output, all of which goes to a single directory, is a good alternative. Other flags such as –d, -e, and –v are unnecessary because, in binary mode, everything in the packet—header and application data—is dumped. Note, also, that entering the –r flag causes Snort to play back the data in any specified tcpdump-formatted file. Finally, to view only one type of data (such as TCP data only), you can use bpf’s capabilities to filter out unwanted traffic by entering the following:

./snort -dvr packet.log tcp

Note

If Snort is started with the -b flag, any packet in which Snort becomes interested is recorded. If you have tagged a stream to be examined, it, too, will be recorded in a libpcap-style file.

Network Intrusion Detection Mode

Sniffer or packet logger modes are appropriate for bulk data capture, but sorting through volumes of packet data to determine whether a security breach has occurred is not practical. Snort’s network intrusion detection mode does not record packets but, rather, allows rules that you select to be applied. (Rules are covered in the section “Snort Rules.”) snort.conf is the file that, by default, contains these rules (although nearly any file you specify could be used instead). Snort will inspect only the traffic defined in snort.conf’s rule set.

A basic way to start Snort in intrusion detection mode is to enter the following:

./snort -dev -l ./log -h 10.1.1.0/24 -c snort.conf

Failing to enter an output directory will result in the output being written to /var/log/snort. Note, also, that the previously discussed flags can be entered in this mode, although the usefulness of entering some of these flags, such as the –e flag, which results in a dump of each link layer header, in the context of this mode is questionable.

Snort s IDS Components

Snort has four main IDS components: the packet capture engine, the preprocessor plug-ins, the detection engine, and the output plug-ins, as illustrated in Figure 10-1. We’ll start with the packet capture engine.

Figure 10-1: The four main components of the Snort IDS

Packet Capture Engine

The first component is the packet capture engine that picks up traffic using libpcap or WinPcap (both of which will from now on be collectively referred to simply as “pcap”). pcap is a library that enables applications to receive datagrams, parcels through which datalink-level data (data at level two of the seven-layer OSI model) are carried. The network interface card (NIC) physically captures the network traffic and passes it on to drivers that interface with the OS kernel. After the kernel processes the data, pcap then takes the data from the kernel and passes them on to Snort applications, which are normally drivers that interface with the third Snort component, the preprocessor plug-ins. For example, the data go through a bpf interpreter if the kernel supports it. The interpreter decides to which applications the data will be passed. If the no interpreter exists, pcap sends all the packets to the applications, which need to have filters to avoid being bombarded with data.

Note

As discussed in Chapter 6, someone who wants to capture network traffic normally has to put at least one network interface on a host in promiscuous mode. One nice thing about pcap, however, is it is not necessary to put the network interface(s) through which network traffic will be captured in promiscuous mode—pcap does this automatically.

Preprocessor Plug Ins

Snort’s preprocessor plug-ins test and inspect packet data they receive from pcap, determining what to do with each packet—whether to analyze it, change it, reject it, and/or generate an alert because of it. The preprocessor plug-ins are highly advantageous because they establish a structure for dealing with packets before they’re sent to the next component. Preprocessors modify URIs and URLs to conform to a standard format, provide stateful analysis of TCP/IP traffic, detect portscans, decode RPC packets, decode telnet packets, as well as serve other functions. They also alleviate having to deal with a wide range of undesirable and potentially malicious packet data, including data that could crash Snort or radically deteriorate its performance. Unless a preprocessor plug-in has rejected certain input, it passes it to the next component, the detection engine.

Detection Engine

The third major component is the detection engine. Packets are first decoded in a manner that defines the packet structure for layer two protocols, and then layer three protocols, and so on. This enables the detection engine to systematically compare data within every packet it receives to the rule options. This engine then conducts basic tests on whatever part(s) of each packet contain(s) a particular string or value associated with a rule, and then performs another such test using the next rule, and so forth until tests for all rules Snort knows about have been done. Any match is a “hit.” The detection engine then moves on to the next packet. A variety of plug-ins (which at the latest count numbered 22, as of version 2.0.2) can also be used to conduct extra detection tests on packets. Every keyword option in every rule is, in fact, associated with a plug-in which, if used, increases the detection engine’s capability to identify attacks.

Output Plug Ins

The final major component of Snort is the output plug-ins, the major purpose of which is to produce information to be displayed to intrusion detection analysts. Snort creates alerts based on alerting rules within the preprocessors, the decode engines, and the detection engine. An example of the output of the output plug-ins appears in section “Snort Output.” Other output plug-ins perform a variety of other functions, as discussed in the following technical note.

Note

Although the Snort IDS has four major components, new development efforts have resulted in new functions that are likely to prove as important as the four components covered in this chapter. A flexible response plug-in, flexresp2, for instance, enables Snort users to set up rules that result in dropping undesirable connection attempts—a “shunning” capability that makes Snort not just an IDS, but also now (at least to some degree) an IPS.

Snort Rules

The rules Snort uses are at the heart of its IDS functionality. This section explores the nature of these rules, considerations related to the ordering of rules, and how to write rules.

The Nature of Snort Rules

Among the many types of rules are those for FTP and web attacks, distributed DoS attacks, attempts to exploit weaknesses in the Server Message Block (SMB) protocol in Windows systems, and Remote Procedure Call (RPC) attacks. Each rule corresponds to a number, a Sensor ID (SID) that enables everyone to distinguish one from another easily. For example, the following code listing shows the rule for the Apache web server chunked-encoding memory-corruption vulnerability exploit. When processing requests coded with a type of encoding mechanism called the “chunked encoding” mechanism, Apache incorrectly determines buffer sizes needed. Consequently, specially formulated input from a malicious browser can cause a buffer overflow that could result in the execution of rogue code on an Apache server. Note, the signature is in the second through fifth lines. The Common Vulnerabilities and Exposures (CVE)—see http://www.cve.mitre.org) numbers (both of which start with CAN) are in the eighth and ninth lines. The SID for this attack is 1807, as an inspection of line 9 shows.

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS 
(msg:"WEB-MISC Transfer-Encoding: chunked"; 
flow:to_server,established;
content:"Transfer-Encoding:"; nocase; 
content:"chunked"; nocase; 
classtype:web-application-attack; 
reference:bugtraq,4474; 
reference:cve,CAN-2002-0079; reference:bugtraq,5033; 
reference:cve,CAN-2002-0392; sid:1807; rev:1;)

Over time, the number of available rules has increased substantially as more exploitation methods have been developed. As a result, Snort’s rules have become organized on the basis of type of rule, with related rules having SIDs within a certain numerical range. For example, the NetBIOS attack rules currently have sequentially numbered SIDs 529 through 539 (and a few others not within this range), as do telnet attack rules (which currently have SIDs 709 through 714, plus a few others outside this range). Anyone who deploys Snort can choose to use all the rules or can select only a subset of all the rules. Using all the rules results in a more complete detection capability, but at the disadvantage of slower performance. The more rules Snort must find and test, the slower Snort works. On the other hand, someone might want to use Snort for a special purpose, such as detecting only attacks directed at Windows systems. In this case, you might want to include only NetBIOS, MS-SQL, virus, web-IIS, and a few other rules.

Note

One potential problem with a signature and rule-based intrusion detection system is keeping signatures and rules current. Snort goes a long way in solving this problem by supporting the most recent rules only on the most current version. For example, the most recent rules work only on Snort 2.0, the most recent version at press time.

Rule Order

The Snort 2.0 detection engine examines five rule chains: Activation, Dynamic, Alert, Pass, and Log (as shown in Figure 10-2). By default, Activation rules (which generate an alert, and then activate some other dynamic rule) are applied first, and then Dynamic rules (which cause a packet to be logged when they’re triggered by an Activation rule), and then Alert rules (which issue an alert, and then log a packet), followed by Pass rules (used for ignoring certain kinds of packets, such as traffic from DNS servers, as well as to cause the use of the bpf filter language when Snort starts), followed by Log rules (which cause a packet to be logged, but without any alert). The ordering of any rule chain can easily be modified, however. To start Snort with full logging only (as indicated by the –l flag) and also to have Snort read the default configuration file for applying rules, enter the following:

./snort -l ./log -c snort.conf

Figure 10-2: Snort’s default order of applying rule chains

The –l flag means to use full logging and the ./log argument means to log to a file named log in the current directory. The –c flag means to read Snort’s default configuration file, which is snort.conf.

In Snort 1.x, if you want one rule applied before another, simply ensure the flag for that rule is to the left of the flag for another when you start Snort via the command line. In Snort 1.x, flags are always read and processed sequentially, left to right. Things are different in Snort 2.0, however. The rule-optimization mechanism in Snort takes apart the individual parts (flags, content requests, and so forth), and then creates an optimized list of rules that normally needs to be checked only once or, under unusual conditions, twice. The pattern-matching algorithm for content searching has also been changed to the Wu-Manber or Aho-Corasick algorithm (the choice is yours), resulting in much greater efficiency.

Once Snort 2.0 has applied a rule chain, it goes to the Rule Tree Nodes, further protocol-specific rules to be applied. The Rule Tree Nodes analyze TCP, UDP, ICMP, and IP traffic. Within each Rule Tree Node are options, one for Content, which results in a pattern-matching algorithm being applied to packet data and the other for Flow, which results in a detection plug-in being applied.

Writing Snort Rules

Another nice thing about Snort is that it is so extensible. Anyone who uses Snort can create custom rules that are not in the default rule set. Each rule consists of two parts: the rule header and rule option. The rule header contains the rule's action (alert, log, pass, activate, or dynamic, as discussed previously, or also custom for home-built rules), type of protocol, source and destination IP addresses, masks, and source and destination port. The rule option has the content of alert messages, as well as information concerning the portion of each packet that will be analyzed to decide if the action specified will be carried out. In the following example, if the signature (06 4a 05 42) for a Windows NET SEND message is found in a UDP packet, regardless of the particular source IP address, an alert labeled Windows messenger service message is issued.

alert udp any any -> 10.1.1.0/24 135 (content:"| 06 4a 05 42|" ; msg: "Windows messenger service message";)

Given all the possible variables that can be specified in each Snort rule, the number of potential rule options is mind-boggling.

Snort Filters

To help control the volume of traffic with which Snort must deal, Snort also provides filters. Filters control what data Snort does and does not dump. For example, if you wanted Snort to pick up all DNS-related traffic, UDP traffic destined for port 53, you could define the following filter:

udp and dst port 53

Then you would have to enter a command to activate this filter:

# tcpdump udp and dst port 53

The effect would be to examine a file that tcpdump writes to for every access to port 53.

Snort Output

The Snort-alerting function allows alert data to be sent as SNMP trap data (as covered first in this section) or to be appended to a log file or a database (such as a MySQL and Postres database).

Alerts

Understanding the format of Snort alerts and the various alert modes is essential for using alerts effectively. This section covers both of these issues.

Alert Format

Each detect is shown in double-spaced log files, as shown in the following code:

[**] SCAN-SYN FIN [**]
11/02-16:01:36.792199 10.0.0.1:21 -> 192.168.0.1:21
TCP TTL:24 TOS:0x0 ID:39426
**SF**** Seq: 0x27896E4 Ack: 0xB35C4BD Win: 0x404
 [**] SCAN-SYN FIN [**]
11/02-16:01:36.803980 10.0.0.1:21 -> 192.168.0.1:21
TCP TTL:25 TOS:0x0 ID:39426
**SF**** Seq: 0x27896E4 Ack: 0xB35C4BD Win: 0x404

Snort always shows the rule that was applied at the top, followed by summary information concerning the packet. In this example, Snort has labeled both of the TCP packets as part of a scan in which SYN-FIN packets have been sent to the destination host. These packets have been fabricated, as shown by the fact that the ID, sequence number, and acknowledgement number do not change from one packet to the next, as well as the fact that the source port (TCP port 21) is the same as the destination port, something that does not happen in real life. Whoever ran this scan may have been interested in discovering FTP-related vulnerabilities in the host at the destination address. Sending SYN/ACK packets without a previous SYN packet is a hacker trick designed to get the packets through firewalls that do not do stateful analysis of traffic. Nonstateful firewalls will accept SYN/ACK packets at face value, allowing them through, thinking the three-way TCP handshake sequence can be completed with a subsequent SYN packet from the client.

Alert Modes

Snort offers several Alert modes, each with its own special flag:

• –Full In this mode, Snort prints both the alert message content and the entire packet header for each packet. This is the default mode.
• –fast Choosing this mode results in a simplified format that contents the time, the message itself, and source and destination IP address and ports.
• –socket This option results in alerts being sent to a Unix socket to allow the data to be passed to a program.
• –syslog This option results in the syslog facility in Unix and Linux (or even Windows systems in which this facility has been implemented) to be used to send the alerts. One of the greatest advantages of this option is that alerts from various Snort boxes can be sent to a central console.
• –smb SMB is the Server Message Block, a protocol used by Windows systems (and also by SAMBA running on Linux and Unix) to transfer information from one host to another. Choosing the –smb option causes this protocol to be used to send alerts.
• –none Entering this option shuts off alerting altogether.

Log Files

Snort has two output options for writing to log files: ASCII (default) and binary. Although ASCII is sufficient most of the time, binary output is desirable when you need Snort to run as fast as possible and when interoperability with other tcpdump output is desirable. In fact, if you start Snort using both the –b (binary) and –A (“fast”) options, Snort can keep up with fairly high throughput rates. The syntax is as follows:

./snort -b -A fast -c snort.conf

The result will be that packets will be logged in tcpdump format with few alerts generated. The more alerts, the slower Snort runs.

Special Requirements

Snort, like any other IDS, has certain kinds of hardware and software requirements. This section discusses these requirements.

Hardware

In many respects, Snort is what you make it. You can run a bare bones deployment of Snort with most features disabled. If you do this, you will not need much in the way of disk space and special hardware. But most Snort deployments are much bigger. In this case, disk space is critical. Sufficient disk space is necessary for keeping all the data Snort’s detection engine uses to look for rule matches. Additionally, Snort can archive packet data (which, as those who have used tcpdump of a pcap program know well, can produce an unbelievable amount of data) and write to log files or produce alerts. Testing how fast a Snort host’s hard drive fills up for a given deployment of this tool is best, but nothing less than 10 to 20GB will normally do. Additionally, a single NIC is not likely to be sufficient. One NIC is necessary for promiscuous capture of network traffic but, another is generally required to allow remote connectivity to each Snort host for maintenance and operational access purposes. The larger the volume of data, the more likely a large amount of memory (such as 1GB of RAM) and a fast processor (such as 1GHz) will be needed. The same is true of the NIC that captures traffic.

Software

Once you obtain the hardware you need, you have to select an OS on which to run Snort. Although, in theory, Snort can run on virtually any Unix or Linux platform, some potential problems exist with certain platforms. Solaris, for example, does not support bpf, something needed in many Snort deployments. Additionally, Snort can run on platforms such as Windows NT and Windows 2000 but, if you choose a Windows OS, then you must deal with the many eccentricities (including a legion of security-related woes) of these systems. You also need current versions of the following software:

• A pcap implementation
• gcc, automake, and autoconf (only if you compile Snort from source)
• lex and yacc, or flex and bison (depending on the parsing environment needed)
• libnet 1.0.2a for the latest version of flexrep (if you want automated report generation)

If you want to dump Snort bulk trace dumps to a database, you need a database engine such as Oracle, MySQL, or Postres. If you want to monitor Snort, a convenient way to do this is to set up an Apache or Internet Information Server (IIS) server on the Snort host. (Caution: because of all the security problems that have surfaced in IIS, be sure to configure this web server properly and keep up with hot fixes if you decide to use it in connection with Snort.) Installing SSL and SSH on the web server ensures that all connections to and from the server will be encrypted. Certain Snort plugs-ins also require PHP and Perl. And, if you want to write Snort alerts to Windows hosts using WinPopup, you need to install smbclient.

More About Snort 2 0

We’ve already covered some features of Snort 2.0, but many more features and enhancements exist than have been covered so far. This section covers additional features and enhancements of this Snort release.

New and Optimized Features

Snort 2.0 represents an effort both to improve Snort itself and to introduce new functionality. This functionality includes (but is not limited to)

• An optimized detection engine (discussed earlier)
• A Protocol Flow Analyzer (discussed in the section “Protocol Flow Analyzer”)
• Improved protocol decoding (discussed in the section “Improved Protocol Decoding”)
• A new detection engine that includes a rule optimizer (discussed previously),
  a multirule search engine that deploys algorithms that use optimized rule sets, and an optimized event selector that more efficiently selects the appropriate event from the event queue for each packet Snort receives.
• New, updated rules
• Stateful pattern-matching based on knowing whether data sent between
  clients and servers has been sent by the client or the server
• New pattern-matching algorithms
• Keywords based on actual byte content
• Enhancements to preprocessor plug-ins that reproduce session streams and reassemble packet fragments (named “stream4” and “frag2,” respectively)
• Improved anomaly detection for major protocols
• An improved flexresp mode that allows special kinds of real-time countermeasures (such as sending RST packets or icmp host unreachable packets in response to packets from attacking hosts) to be deployed
• An improved tag function that allows someone to log extra traffic that pertains to a matched rule
• An updated version of snort.conf
• Capability to create a virtual root (chrooted) directory other than the directory containing the Snort executable
• Elimination of numerous bugs from 1.x versions of Snort

Protocol Flow Analyzer

One of the most important new features in Snort 2.0 is the Protocol Flow Analyzer. This section describes what this analyzer is, its advantages, and how it performs one specific type of analysis: the analysis of HTTP traffic.

What Is the Protocol Flow Analyzer?

The Snort 2.0 Protocol Flow Analyzer performs a high-level inspection of application-protocol traffic, breaking it into two separate flows: client-to-server and also server-to-client data flows. Instead of analyzing everything in each protocol flow, it looks only for several critical important parts of each, such as the nature of a server response to a client request (as determined by the response header or data) or the type of request a client has sent to a server, and then performs a thorough analysis of the information it uses, looking for content matches within each protocol flow.

Advantages

The main advantages of the Protocol Flow Analyzer are performance and accuracy. This analyzer tries to diminish the volume of network traffic the fusion detection engine needs to evaluate. It does this by knowing how client- and server-based communications occur for each network protocol of which it is aware and weeding out data not related to attacks. This applies both to packet-level analysis and to TCP stream reassembly, resulting in a substantial reduction of the amount of data that must be inspected for content matches. Having to examine only parts of protocol flows helps speed processing considerably. Restricting analysis to only certain parts of client-to-server or server-to-client communications also helps lower the false alarm rate. The analyzer will not erroneously find matches based on data that would have been analyzed in the previous release of Snort, but that now are not analyzed.

Case Study: The HTTP Flow Analyzer

The HTTP Flow Analyzer capitalizes on the fact that client requests generally contain relatively little data (because they generally consist of requests such as GETs and POSTs) compared to server responses. The overwhelming majority of server responses to client requests consist of response data, rather than response headers. Snort has a Fusion TCP State Engine that determines whether a client or server has sent data, allowing the HTTP Flow Analyzer to pick only the data flows of interest. Assuming a typical web server has at least an adequate level of security controls, presuming any data sent by that server are trusted and legitimate is reasonable. Client requests generally contain relatively little data compared to server responses and, as just mentioned, there is no reason to analyze server response data. The only parts of web-related traffic that need to be analyzed by the up to 500 HTTP-specific rules in Snort, therefore, are client packet headers, and data and server headers.

Packet-Based Versus Session-Based Processing

HTTP packets are processed in two ways: one is based on packets and the other is based on sessions. The following explains the differences.

Packet-Based Processing

As implied by its name, packet-based processing uses only information contained within each packet. When HTTP requests and responses are being processed packet-by-packet, the only processing information available is what is available in the packet. A variable you can set—HTTP Maximum Response Bytes—determines how many bytes within the packet will be processed. A few upfront checks verify the packet is a TCP packet, and the source port and destination ports appear legitimate and, finally, that the initial four bytes of the payload contain the string “HTTP” (meaning the packet is a response header, so the bytes in the packet will be processed until the byte corresponding to whatever the value of the HTTP Maximum Response Bytes parameter is reached). Otherwise, the packet is not processed, something that results in greatly improved processing efficiency.

Session-Based Processing

The key to understanding session-based processing is that it tracks the state of TCP connections. When client- or server-initiated HTTP data are sent, the HTTP Flow Analyzer determines whether they are part of an ongoing session. If not, the data are not analyzed. If they are part of an ongoing session, the analyzer determines whether the initial four bytes of the payload contain the string “HTTP.” If so, the analyzer conducts an analysis of the entire HTTP header. If not, it moves on to the next packet.

Improved Protocol Decoding

Although the preprocessor function in Snort 1.x was by no means bad, Snort 2.0 offers a much-improved preprocessor functionality, including enhanced protocol decoding. One of the major problem areas in the Snort 1.x preprocessor function was its inability to adequately handle the huge potential range of data with which Snort had to deal. “Weird” data also often escaped analysis. One of the major improvements in the Snort 2.0 preprocessor function is that it converts a wide range of data to a standard format, so the data can be processed. For example, a major type of attack on web servers today is to send specially formatted URLs that the web server cannot properly process, often causing execution of commands embedded in the URLs or DoS. The potential number of URL formats that can be sent to a web server is gargantuan. Accordingly, Snort 2.0 has an http_decode preprocessor that converts URLs to a standard format before the Detection Engine attempts to perform content matching on them.

Another challenge, one by no means unique to Snort, is dealing with packet content in which additional characters were inserted into data sent as part of an attack. Hacking tools, such as Fragroute, can, for example, launch "insertion" attacks, in which malicious commands sent to a server are disguised from IDS recognition by inserting extra, illegitimate data. When the commands reach the IDS, the IDS does not recognize them as attack signatures. The victim host, meanwhile, often discards the bad data, allowing the commands to run on it. The following is an example of this kind of input:

GET //cgi-bin//any.cgi 

This command represents an attempt to get to the ever-dangerous cgi-bin directory, something that could well happen (depending on whether the intended victim host accepts and processes this request anyway). Still another challenge is dealing with fragmented packets. Some of the preprocessors unify all fragments into a single fragment for processing purposes.

You can select preprocessors the preprocessors you want. Simply go to the snort.conf file located in ~(source_root)/etc/snort.conf.

Additional Tools

Open source software has many advantages, one of which is that additional tools are often developed to expand the functionality of a package. Three tools—Swatch, ACID and SnortSnarf—have, in particular, proven useful in connection with Snort. This next section discusses these tools.

Swatch

Simple log WATCHer and filter (Swatch) is a fairly easy to install and use Perl program developed by Todd Atkins. This tool automates responses to Snort alerts. Swatch is an active log-file monitoring tool. Swatch monitors logs and sends alerts to the appropriate person when designated events occur, and is available at http://swatch.sourceforge.net.

Analysis Console for Intrusion Databases (ACID)

Analysis Console for Intrusion Databases (ACID) is a consolidation and analysis tool. ACID is a PHP-based analysis engine that searches for security events of interest. Two extremely useful features are query-builder and packet-viewer. Query-builder finds alerts matching meta information and network details. such as source and destination address, ports, payload, and/or flags. Packet-viewer graphically displays layer 3/4 packet information. ACID can be downloaded from http://www.andrew.cmu.edu/~rdanyliw/snort/snortacid.html.

Snortsnarf

Snortsnarf takes data and files from SNORT, and produces HTML output that can be used for diagnostic inspection of problems. It can produce information at any desired time interval—hourly or daily, for example—producing output of all alerts. SnortSnarf is available at http://www.silicondefense.com/software/snortsnarf.

Evaluation

Snort is an open-source tool, lightweight, fairly easy to use, inexpensive to run, and constantly being expanded and improved. Its primary developers care so much about the security of this tool, they paid to have independent security audits of Snort performed, something most IDS and IPS vendors have still not done. At the same time, Snort’s simplicity (especially the simplicity of version 1.x) can prove a big limitation. Snort simply cannot identity a number of attacks that more sophisticated (but also financially costly) IDSs can. Snort false-alarm rates have also been a persistent problem over the years but, again, this is true more of version 1.x than of version 2.0, the latter of which has a number of capabilities designed to minimize the false alarm rate. Additionally, even in version 1.x, someone can substantially reduce the false alarm rate by tuning Snort rules, that is, by removing unneeded rules and rules that elevate the false alarm rate unacceptably. Finally, several serious vulnerabilities in Snort have surfaced. Probably the most publicized DoS tool that works against Snort is one named stick (visit http://www.eurocompton.net/stick). Stick uses every Snort signature, and then creates and transmits packets containing each signature to Snort, causing massive amounts of alerts and tying up virtually all resources. Upgrading to version 2.0 is the best solution because Snort 1.x vulnerabilities (such as a bug in the “stream4” preprocessor that can result in a heap overflow, allowing execution of rogue code) are not found in Snort 2.0. Patches for all these and other Snort bugs can be found at http://snort.sourcefire.org. Given how widely used Snort is, failure to install all of them is extremely unwise.

So, how much good can Snort do? The answer is that Snort can potentially do considerable good for organizations if it is deployed in the proper context for that organization. Consider the following possible deployment contexts:

• One context in which deploying Snort almost always makes sense is giving technical staff and students the opportunity to learn about and experiment with an IDS. Snort’s simplicity makes it almost ideal in this respect. People can then make a transition to a more complex IDS if this is what is needed.
• A small start-up company that cannot afford to invest a large amount of money to obtain a commercial IDS (and we are not even talking about monitoring and maintenance expenses here) would be well served by Snort.
• Snort can be used as a validation tool for other IDSs. Snort output can be compared to the output of the other IDSs to get an impression of the hit and false alarm rates of the others.
• Another possible context of use is to provide a more complete intrusion-detection capability. Snort can pick up events the other IDSs might miss.
• Snort can be used to provide supplementary data for subnets and other network zones for which inadequate intrusion-detection data-collection capability is in place.
• In some cases, Snort can be used as the only IDS, even possibly in extremely large organizations. After all, Snort keeps getting better and better, and the Snort developers have a reputation of fixing bugs that emerge in this tool faster than some vendors do.

Snort is not the answer for intrusion detection and intrusion prevention, but it is certainly is an attractive possibility. The mileage you get from Snort might vary, so to speak, but the longer you use this tool, the more mileage you should get.

Summary

Snort is a rule-based, rather than a signature-based, IDS. Snort runs in one of three modes: sniffer mode (in which Snort gathers packet headers and data and writes them to the screen); packet-logger mode (in which data and/or headers are dumped to the hard drive); and network intrusion-detection mode (which does not record packets but instead analyzes their content in comparison to rules that have been chosen). The Snort intrusion detection mode has four main components: the packet capture engine (which collects traffic using libpcap or WinPcap), the preprocessor plug-ins (which analyze packet data they obtain from pcap, determining what to do with each packet, and also dropping weird input), the detection engine (which systematically compares data in each packet it collects to rules), and the output plug-ins (which generate alerts and perform other functions such as terminating undesirable sessions).

Snort rules have a defined format and are numbered in a systematic manner, so related rules are mostly within the same numerical range. Although Snort offers a large number of rules, not all of them must be used. Snort, in fact, runs more efficiently if a reduced rule set is used. Custom rules can also be created to supplement the existing Snort rules. Snort 2.0 performs selective searches of data within rule sets, resulting in better performance. Snort’s alerting function enables alert data to be sent in a variety of ways, including using SNMP, or written to a log file or a database.

The hardware Snort depends on the size of the Snort deployment. Disk space, memory, and processor speed are important considerations. Software used in connection with Snort is also critical. Choosing an appropriate OS to run on the Snort platform is the first step. You also need software, such as pcap, gcc, automake, autoconf, lex and yacc or flex and bison, and flexrep.

Snort 2.0 offers numerous improvements, among which is the Snort 2.0 Protocol Flow Analyzer. This analyzer conducts a high-level analysis of application protocol traffic, breaking it into client-to-server and also server-to-client data flows. For the sake of efficiency, the analyzer inspects only certain portions of the data in data flows. Snort 2.0 also has improved protocol decoding in which the preprocessor function transforms a wide range of data to a single format to facilitate processing the data.

The key to getting value out of Snort is deploying it in the proper context for the organization that uses it. Snort’s growing sophistication and a number of other factors make it a very viable choice for intrusion detection.