this cannot be considered very robust in terms of rule or packet granularity. The rule options form the core of Snort's intrusion-detection capabilities.

Format of Snort Options

The rule options are separated from the rule header via required parentheses ( ). Look at the following rule:

alert tcp !$HOME_NET any -> $HOME_NET any (flags: SF; \ msg: "SYN-FIN scan";)

The options portion is as follows:

(flags: SF; msg: "SYN-FIN scan";)

Each option is made up of an option keyword, and possibly a value for the particular option keyword. In the preceding example, you find the option keyword flags paired with a value of SF and an option keyword of msg paired with a value of SYN-FIN scan. The value that is associated with a given option keyword depends on the option. Some options require numeric values and others require text. Option keywords are separated from the associated value via the colon (:), and individual options are delimited by a semi-colon (;). A semi-colon must follow the final option as well or an error will be generated. Although most option keywords are usually followed by a value, there are some options that require no value. One such example is the option nocase that indicates a search for content in the packet's payload is to be case insensitive.

Snort is pretty unconcerned and forgiving about the lack or abundance of whitespace between delimiters such as ; and :. You don't have to supply spaces, or you can supply multiple spaces between options, values, and delimiters. For instance, the two following options should both work:

(flags:SF;msg:"SYN-FIN scan";)

(flags: SF ; msg : "SYN-FIN scan" ;)

The backslash (\) is a rule continuation character; rules can be continued on separate lines if this character is supplied at the end of any unfinished line. Speaking of special characters, the pound sign (#) is used as the comment character for Snort rules.

Rule Options

Some of the most important and commonly used options will be discussed now to convince you of the power of Snort rules. The entire list of burgeoning options will not be covered, but descriptions of all of them can be found at www.snort.org by examining the online Snort

Users Manual under the documentation link.

Msg Option

The msg option allows the user or analyst to assign an appropriate message to the output of a triggered rule. When you examine an alert or logged entry for the triggered rule, you will see the offending packet. You will not see the actual rule that triggered the alert in the output itself, so you need some descriptive way of associating the alert with the rule. If you assign an msg option value, it will appear before the offending packet output to give you a better idea of why the rule triggered.

Look at the following format, rule, and an associated alert that triggered from the rule:

Format:

msg: "<message text>";

Sample rule:

alert udp any any -> 192.168.5.0/24 31337 \ (msg:"Back Orifice";)

Sample output:

[**] Back Orifice [**]

04/24-08:49:21.318567 192.168.143.15:60256 -> 192.168.5.16:31337 UDP TTL:41 TOS:0x0 ID:49951

Len: 8

The Snort rule says to alert (and log) when a UDP packet from any source IP address or port goes to subnet 192.168.5 destination port 31337 and to assign it a message of "Back Orifice". When the rule is triggered, the alert is recorded with "[**] Back Orifice [**]" to

describe the activity.

Logto Option

The logto option allows you to specify a filename to which to log the activity. This applies to rules with the alert or log action in the rule header only. A rule that is triggered with the alert or log action will normally write to a default directory (either /var/log/snort for UNIX hosts or, on a Windows machine, a subdirectory named log from wherever Snort is launched) or a directory specified using the –l filename option on the command line. This assumes that the user hasn't changed the default logging to binary output (-b commandline option), to send the output to the syslog daemon (-s command-line option), or disabled logging altogether (-N command-line option).

The logto option can be used to send the output for a specific rule or class of user-chosen rules to a given file. Why might you want to use this option? Well, this is an excellent way to separate the truly dangerous or harmful kinds of alerts from those that are the garden variety. In the case shown in the example, if you suspect that you have some kind of trinoo distributed denial-of-service (DDoS) infestation or any other DDoS activity on the network, you can look directly at the DDoS file for signs of this. This will also be logged to the default alert file as well because the following sample rule uses the action alert.

Format:

logto: "<filename>";

The supplied filename should not include a path, only a filename. Including a path causes Snort to display an error message. You should place the filename in quotes, otherwise an initial space is sometimes added before the name.

Sample rule:

alert udp any any -> 192.168.5.0/24 31335 \ (msg: "trinoo port"; logto: "DDoS";)

Sample output:

If the rule is triggered, the output on this UNIX host will be found in /var/log/snort/DDoS:

[**] trinoo port [**]

04/24-09:07:41.320938 192.168.143.15:56881 -> 192.168.5.16:31335 UDP TTL:42 TOS:0x0 ID:4011

Len: 8

Ttl Option

The ttl option allows you to examine the arriving time-to-live field for a specific value. This option could be used for a variety of reasons. One reason to examine this field would be to look for a packet with a low arriving TTL value, which can be indicative of a UNIX host performing a traceroute or a Windows host performing a tracert. When the protocol is UDP and the port ranges are 33000 through 34000, it is most likely a UNIX traceroute. A Windows tracert is done via ICMP echo requests.

The following rule looks for UNIX traceroute traffic to the 192.168.5 network with a UDP port in the range 33000 through 34000 inclusive and an arriving TTL value of 1.

Format:

ttl: <number>;

Sample rule:

alert udp any any -> 192.168.5.0/24 33000:34000 \ (msg: "Unix traceroute"; ttl: 1;)

Sample output:

[**] Unix traceroute [**]

04/24-09:29:37.971353 192.168.143.15:40920 -> 192.168.5.16:33437 UDP TTL:1 TOS:0x0 ID:40923

Len: 18

Id Option

As you recall, the IP identification value is a 16-bit value that is found in the IP header of each datagram. Each new datagram is assigned a unique IP ID number that is typically incremented by 1 for each packet. This number becomes the fragment ID, which assists the destination host in reassembling fragments. The sample rule looks for an unusual IP ID value of 0. It now appears that Linux 2.4 kernels set the IP ID value to 0 when the Don't Fragment (DF) flag is set in the packet. The reasoning for this is that if the packet will never become fragmented, why bother to assign it a fragment ID?

Format:

id: <number>;

Sample rule:

alert icmp any any -> 192.168.5.0/24 any \ (msg: "Suspect IP Identification #"; ID:0;)

Sample output:

[**] Suspect IP Identification # [**] 04/25-09:21:36.371005 192.168.143.15 -> 192.168.5.16 ICMP TTL:64 TOS:0x0 ID:00

Dsize Option

The dsize option allows Snort to examine the size of the payload. You can inspect the payload size for an exact value, or a value less than or greater than a particular number. This can come in handy when you are creating a rule for buffer overflow attacks. These attacks might have a telltale signature of having a larger payload than expected. The following sample rule looks for ICMP packets with a payload size greater than 1,024 bytes.

Format:

dsize: [<|>] number

Sample rule:

alert icmp any any -> 192.168.5.0/24 any \ (msg: "Large ICMP payload"; dsize: >1024;)

Sample output:

[**] Large ICMP payload [**]

04/24-11:10:24.110169 192.168.143.100 -> 192.168.5.16 ICMP TTL:255 TOS:0x0 ID:5487 DF

ID:7564 Seq:0 ECHO

Sequence Option

The sequence option checks the value of the TCP sequence number. The Shaft distributed denial-of-service software is known to assign a fixed sequence number—hexadecimal 28374839—when a TCP flood is directed to a victim site. No doubt, this is something that is configurable in the source code, so this is not a failsafe method of identifying Shaft. Of course, a benign packet could coincidentally be using the same sequence number, too.

Format:

seq: <number>;

Sample rule:

alert tcp any any -> any any \

(msg: "Possible Shaft DDoS"; seq: 0x28374839;)

Sample output:

[**]Possible Shaft DDoS [**]

04/25-07:19:58.582562 192.168.143.100:35680 -> 192.168.143.15:23 TCP TTL:255 TOS:0x0 ID:7705 DF

******S* Seq: 0x28374839	Ack: 0x0 Win: 0x2238
TCP Options => MSS: 1460
Acknowledgement Option

The acknowledgement option examines the value of a TCP acknowledgement number. The primary use for this currently is to detect nmap pings. As you discovered in the previous chapter, nmap sends a unique signature when it tries to assess if a host is alive. It sets the ACK flag on, and it sets the acknowledgement value of 0. This would be a rare setting to find in normal traffic because it would be indicative of an already established connection acknowledging that the previous TCP sequence number received was 232 – 1, and now the acknowledgement number is wrapping back to 0.

Format:

ack: <number>;

Sample rule:

alert tcp any any -> any any \

(msg: "nmap TCP ping"; flags: A; ack: 0;)

Sample output:

[**] nmap TCP ping [**]

04/25-07:27:13.578488 192.168.143.15:63367 -> 192.168.143.16:80 TCP TTL:42 TOS:0x0 ID:26253

***A**** Seq: 0x16680003	Ack: 0x0	Win: 0xC00
Itype and Icode Options

The itype option is used to select a particular ICMP message type. The message type field is found in the zero byte offset of the ICMP message.Valid values for this and its partner option icode, which is used to represent the ICMP message code, can be found at www.iana.org/assignments/icmp-parameters. The icode option is often used in conjunction with the itype option. The ICMP message code is found in the first byte offset of the ICMP message. Many ICMP messages share the same type but are further delineated using the ICMP code