The text "anonymous" is found at the 6th byte in the payload, but because we begin the offset count at 0, it is found in offset byte 5.

Depth Option

The depth option is another useful option to help limit the amount of processing Snort must do on content searches. The depth specifies the number of bytes to search from the offset. If no offset is given, the offset is assumed to be 0. This option can drastically improve Snort's performance if packets have large payloads and the content being sought appears in well-defined areas of the payload.

Format:

depth: <number>

Sample rule:

alert udp !$HOME_NET any -> $HOME_NET 5632 \

(msg: "PCAnywhere Startup"; content: "ST"; depth: 2;)

Sample output:

[**] PCAnywhere Startup [**]

04/24-12:11:08.724441 192.168.143.15:3484 -> 192.168.143.16:5632 UDP TTL:64 TOS:0x10 ID:30124 DF

73 74 61 72 74 75 70 STARTUP

This rule is triggered if the characters "ST" are discovered two bytes from the default offset of byte 0.

Nocase Option

The nocase option makes the content search in the payload case insensitive. This means that Snort will match the content string being searched no matter what case is used. This is one of the few options that does not have an option value partnered with it.

Format:

nocase;

Sample rule:

alert tcp any any -> any 21 \

(msg: "FTP warez snooping"; content: "warez"; nocase;)

Sample output:

[**] FTP warez snooping[**]

Regex Option

The regex option modifier of content allows wildcard characters to appear in the content string. Two wildcard characters are available: the ? specifies that a single character can be substituted in the position where the ? is found. The second wildcard character * indicates that any number of characters can be substituted where the * is found.

One excellent use of the regex option is looking for signs of buffer overflow characters. If a buffer overflow is successful on a UNIX host, the attacker might very well try to gain access to a shell such as the Bourne shell using /bin/sh. Yet, there are many other shells that can be used such as the C shell (csh), the Korn shell (ksh), and Bourne again shell (bash), to name a few. Therefore, specifying a proper string and wildcard character will

find all of the various shells. Prior to the addition of the regex option, the only way to test for all different shells was to use different rules. Be warned that the regex option will not be fully functional until release 2.0 of Snort.

Format:

regex;

Sample rule:

log tcp any any -> 192.168.5.0/24 515/

(msg: "Attempted shell on lpd"; content: "/bin/*sh"; regex;)

Sample output:

[**] Attempted shell on lpd [**]

03/23-07:41:11.282960 1.1.0.1:1892 -> 192.168.5.55:515

The previous rule looks for shell access to destination port 515 known as the line printer daemon. The regex qualifier to the content value of /bin/*sh is used to find all the different

types of shell access.

Session Option

The session option is used to capture user data from TCP sessions. It can provide a good forensics tool to see what a particular user is doing, especially if you suspect some kind of malicious behavior is taking place.

There are two available argument keywords for the session rule option: printable or all. The printable keyword only prints out data that the user would normally see or be able to type. The all keyword substitutes non-printable characters with their hexadecimal equivalents.

You should be aware that the use of the session option can degrade the performance of Snort, so it is best used retrospectively; capture the data in binary format (TCPdump files) and then run it through Snort. Also, note that typically when you use this option, you should use the direction operator that specifies both directions as shown in the example. Finally, it is best to use the –d command-line option to dump at the application level; otherwise, it doesn't make much sense to specify the session option.

By default, the session is recorded in the default log directory. The subdirectory beneath that is the IP number of the host initiating the activity. A file named SESSION:sourceportdestport, where sourceport and destport are the actual source, destination ports for the connection will be located in that directory.

Format:

session: [printable|all]

Sample rule:

log tcp any any <> 192.168.5.0/24 21 (session: printable;)

Sample output:

Assuming the source host for the session is 1.2.3.4 on port 1025, the following output will

be in the log directory in subdirectory 1.2.3.4 file SESSION: 1025-21:

220 linux2 FTP server (Version wu-2.5.0(1) Tue Sep 21 16:48:12 EDT 1999) ready.

USER jsmith

331 Password required for jsmith. PASS snorty-the-p1g

230 User jsmith logged in. SYST

215 UNIX Type: L8 QUIT

221-You have transferred 0 bytes in 0 files.

221-Total traffic for this session was 239 bytes in 0 transfers. 221-Thank you for using the FTP service on linux2.

221 Goodbye

Resp Option

The resp option allows an automated active response when malicious activity is detected. An active response attempts to disable a connection. There are many different combinations of active responses and multiple resp options can be given in a single rule. TCP connections can be aborted by sending a reset to the sending host socket connection, the receiving host socket connection, or both hosts' socket connections. If the offending packet is UDP, different ICMP messages can be sent in an attempt to interrupt the UDP data flow. An ICMP network, host, or port unreachable message—or a combination of all three of these ICMP messages—can be sent.

The response option doesn't come automatically enabled with the source distribution. To

enable it, you must explicitly configure Snort via the following command:

./configure --enable-flexresp

This includes the necessary code for compilation. It is also possible that your configuration of UNIX doesn't have a libnet.h include file required for this to compile. It is available from

www.packetfactory.net.

No discussion of active response is complete unless the requisite caveats are offered. First, think smoking-brain hard before you decide to indiscriminately use active response. It should be used for situations where you perceive that unauthorized harmful access could occur such as a buffer overflow. Keep in mind that attackers can spoof source IP addresses, and you might end up using active response against an IP address or addresses that never sent you traffic to begin with. Think about the consequences of active response if someone spoofs a legitimate partner's IP addresses; it is possible for you to end up attacking a vital resource. Also, a false positive could cause a totally benign connection to be halted. This can cause a denial of service to legitimate users.

Another concern is timing issues. Many requests and responses are almost instantaneous, especially one such as a UDP DNS query-response pair. Attempting to actively respond to a perceived malicious DNS query might prove to be futile because by the time Snort reacts, the response has probably already been sent.

Format:

resp <resp_option[, resp_option…]>;

Available choices for the response are:

Sample session:

[root@verbo hping2-beta53]# ftp sparky Connected to sparky.

220 sparky FTP server (SunOS 5.7) ready. Name (sparky:root): jsmith

331 Password required for jsmith. Password:

230 User jsmith logged in. Remote system type is UNIX.

Using binary mode to transfer files. ftp> cd /etc

250 CWD command successful. ftp> get passwd

local: passwd remote: passwd 200 PORT command successful.

421 Service not available, remote server has closed connection

The previous rule calls for an active response to a connection to an ftp server that references the password file passwd. Snort resets both ends of the connection to interrupt this attempt because the resp option of rst_all was selected.

Look at the last line of the ftp session. You see that right after the attacker entered the command get passwd, the connection was actually closed. It is possible that the

password file had already been transferred before the reset occurred.

Tag Option

The use of the tag option enables Snort to dynamically capture additional packets after a rule triggers. Without the tag option, only the packet that caused the rule to be triggered is recorded. This is an excellent way to see what transpires after the rule is triggered to get a better idea of the intent of the activity. This can also be useful for validating that some activity that triggered a rule is simply a false positive.

Format:

tag: <type>, <count>, <metric>, [direction]

type. What traffic to record.

session. Record the packets from both sides of the connection

host. Record the packets from the host that caused the rule to trigger (must use direction modifier)

count. Number of units specified by metric.

metric. Number of packets/seconds to record.

packets. Record host/session for <count> packets.

seconds. Record host/session for <count> seconds.

direction. Used only with "host" type to indicate host to tag.

src. Tag all traffic of source IP in triggered rule.

dst. Tag all traffic of destination IP in triggered rule.

Sample rule:

alert tcp any any -> any 21 (msg: "FTP passwd access"; flags: A+; \ content: "passwd"; tag: session, 10, packets;)

Sample output:

The alert file shows the abbreviated data from the miscreant connection to destination port

21:

[**] FTP passwd access [**]

03/21-20:31:05.610035 10.10.10.101:1454 -> 10.10.10.100:21