fields—make sure you convert to bytes. Finally, remember that the location where bits fall in the byte is significant. It might be necessary to normalize if you are dealing with bits in the high-order nibble. If you are up to the challenge of all of this, I think you will get a true sense of satisfaction after you have mastered the deciphering of data and the creation of potentially revealing filters.

Chapter 13. Introduction to Snort and Snort Rules

Snort is an open source free NIDS that was developed by Marty Roesch. It was initially written so that Marty could do traffic sniffing at his job and has grown to a full-featured NIDS. Along the way, Marty has attracted a vast following of admirers and coders who work collectively to enhance the code and issue new releases. In early 2002, Snort was downloaded from its home at www.snort.org over 10,000 times a week to protect government, corporate, home, and educational sites.

Snort is a signature-based NIDS that uses a combination of rules and preprocessors to analyze traffic. The rules offer a simple and flexible means of creating signatures to examine a single packet. The preprocessor code allows more extensive examination and manipulation of data that cannot be done via rules alone. Preprocessors can perform a variety of tasks such as IP defragmentation, portscan detection, web traffic normalization, and TCP stream reassembly, to name a few. Preprocessors give Snort the capability to look at and manipulate streams, as opposed to the single-packet-at-a-time view rules use.

The current version of Snort in March 2002 is 1.8.3 and is a compact 1.8 megabytes of source code. It is extremely portable and currently runs on approximately 23 different platforms including Linux, Solaris, BSD, IRIX, HP-UX, Mac OS X, and Win32. Snort is also easily configurable and flexible, allowing users to create their own signatures and alter the base functionality through the use of plug-ins. Plug-ins are code that can optionally be compiled into Snort at installation time and offer features such as active response to malicious traffic.

The focus of this section of the book is writing filters and signatures, so many aspects of Snort will not be discussed, such as installation, configuration, and output. If you would like more information on these topics about Snort, please visit www.snort.org. This chapter will cover an introduction to Snort, the anatomy of a Snort rule, and explore fields and possible values found in the first part of a Snort rule known as the rule header. The next chapter will continue rule writing by discussing the second part of the rule known as the rule options. It will also cover writing more advanced rules.

An Overview of Running Snort

Snort can be run in various modes from simply dumping sniffed traffic to the screen, to NIDS mode where Snort is able to compare the network traffic with a preconfigured set of signatures known as rules that are housed in one or more files. The latter is the most common mode in which to run Snort.

Snort is typically run from the command line, whether it is run on a UNIX or Windows host. There is software offered known as IDScenter, which provides a Windows GUI interface, as well as Demarc/Puresecure, which provides a Windows and UNIX GUI interface. There are many command-line options that can be used, but the most practical one (-c snort.conf) allows the user to place Snort in NIDS mode by informing it of the configuration file to be used. As the name implies, this is where Snort configuration occurs, including assigning variables used in the rules values, informing Snort which preprocessor options to use, and telling Snort which rules to include in traffic analysis. A skeleton configuration file named snort.conf is provided in the Snort download directory. The user must customize this file for his site.

When Snort is run in NIDS mode, by default, it places the output of events of interest triggered by the rules in various files. Snort allows an action to be assigned to each rule, indicating what to do when the rule is triggered. An action of alert means to write the offending packet to a file named alert, which is created in /var/log/snort on many UNIX hosts, by default. On Windows hosts, the alert file is created in the log subdirectory in the current directory from which Snort is run. Here is an example of a Snort alert file entry:

[**] NMAP TCP ping [**]

03/21-13:33.51:880120 1.2.3.4:1029 -> 192.168.5.5:80

TCP TTL:46 TOS:0x0 ID:19678

******A* Seq: 0xE4F00003 Ack: 0x0 Win: 0xC00

There is an identifying message associated with the alert that the user can assign when the rule is created. This is optional; however, it informs the analyst of the perceived problem. The message for the preceding alert is "NMAP TCP ping". On the next line, there is a date and timestamp followed by source IP address (1.2.3.4) and port (1029), direction of the traffic (source to the left of the arrow and destination to the right of the arrow), and the destination IP address (192.168.5.5) and port (80) of the offending packet. The third line indicates that the traffic is TCP, it has an arriving time-to-live value of 46, a type of service value of 0, and an IP identification number of 19678. The final line lists the TCP flags set; the A signifies that the acknowledgement flag is set. It is followed by a hexadecimal representation of the TCP sequence number, the acknowledgement number, and the TCP window size. All of these fields can provide more details about the packet that triggered the alert.

This alert appeared because there is a rule that examines TCP segments with an acknowledgement flag set but an accompanying acknowledgement value of 0. Most of the time when this is observed, it is a telltale sign of nmap attempting to discover a live host. If the acknowledgement is allowed to reach the destination host, the host should respond to the unsolicited acknowledgement with a reset, regardless of whether the port is listening or not. That is why the message accompanying the alert is "NMAP TCP ping."