field. For instance, an ICMP type of 3 has many different ICMP codes associated with it. If you are just interested in seeing ICMP port unreachable messages, you must qualify the rule with an itype value of 3 and an icode value of 3.

Format:

itype: <number>; icode: <number>;

Sample rule:

alert icmp 1.1.1.0/24 any -> 192.168.5.0/24 any \ (msg: "port unreachable"; itype: 3; icode: 3;)

Sample output:

[**] port unreachable [**] 04/25-07:56:37.129338 1.1.1.16 -> 192.168.5.15 ICMP TTL:255 TOS:0xC0 ID:33569

DESTINATION UNREACHABLE: PORT UNREACHABLE

Flags Option

The flags option enables you to inspect TCP flag settings in many different ways. Starting from the least significant (rightmost) flag bit setting:

F: Finish flag set

S: Synchronize flag set

R: Reset flag set

P: Push flag set

A: Acknowledgement flag set

U: Urgent flag set

2: ECN echo flag set (formerly a reserved bit)

1: ECN congestion window reduced set (formerly a reserved bit) 0: No flag bits set

It's also possible to use one of three modifiers (+,*,!) to assist in examining flag combinations or negating a flag setting. For instance, the A+ flag setting indicates that the Acknowledgement flag must be set. It can be set alone, or any other flag might be set along with it. This could include an acknowledgement on push flag (meaning new data is being sent at the same time received data is being acknowledged to combine transfers into one packet), which is a common and legitimate combination. The * modifier is used when you have a combination of flags and any of those flags might be set. For instance, SFP* says that any combination of the SYN, FIN, and PSH flags can be set—they can all be set; a lone SYN, FIN, or PSH can be set; or any pair in the trio can be set. Finally, the ! modifier specifies to negate the current flag setting. The flags option !S specifies that any TCP segment without the SYN flag set will be a candidate packet.

Format:

flags: <flag_settings>

Flag Settings: F = FIN

S = SYN

R = RST

P = PSH

A = ACK

U = URG

2 = ECE

1 = CWR

0 = No flags set

See Figure 14.1 for a pictorial representation of Snort's TCP flag bits. Possible flag modifiers:

Figure 14.1. Snort's view of the TCP flag byte.

+ All, match if listed flag(s) set and any others set * Any, match if any combination of listed flag(s) set ! Not, match if listed flag(s) NOT set

Sample rule:

alert tcp any any -> any any (msg:"Null Scan"; flags:0;)

Sample output:

[**] Null Scan [**]

04/25-05:49:51.914748 192.168.143.15:54746 -> 192.168.143.16:21

TCP	TTL:51 TOS:0x0 ID:23446	Ack: 0x0	Win: 0x1000
******** Seq: 0x1CED3E2E				0 EOL EOL
TCP	Options => WS: 10 NOP MSS: 265 TS: 1061109567

In the previous sample output, you see a string of eight asterisks (********). Snort changes an asterisk to its respective flag bit letter association (12UAPRSF) if the flag is set in the packet that triggered the alert. Because this is a null scan, no flag bits are set;

hence, you see all asterisks.

Content Option

The content option is one of the most vital and potentially misused options. It provides a means of supplying payload content to search for in the packet. There are many ways to supply the content value and multiple different content values can be sought. This option is used liberally throughout the rules that are supplied in the Snort download, but the content option should also be used wisely. Seeking content in payload is considered to be computationally expensive—in other words, this can slow Snort down considerably if it is not done intelligently. Although the developers of Snort have maximized the efficiency of the algorithm applied to do content searches, it is a slow operation when compared with a more exact task such as a match of a header field value. This is because the header field value is, at most, four bytes long, yet payloads are often much longer, thus taking more time to search.

If at all possible, the content option should be qualified with other options as flags or those that will be discussed shortly, such as an offset into the payload where the content search begins, and depth into the payload where the content search ends. The content option is tested last even if it is listed first in the rule options. This is done to optimize the search by qualifying it with other options.

Content strings can be represented as text or a hexadecimal translation of binary data or a combination of text and hexadecimal. Text strings are enclosed in quotes ("") and matches are case sensitive unless the nocase option is used. Hexadecimal code is delimited with the pipe (|) characters. Multiple content options and values can be specified in a rule and all values associated with the multiple content options must be found in the packet. The content values associated with the multiple content options can appear in any order in the payload; in other words, they do not have to match the order in which they are listed in the rule. There is another available content option that will not be covered known as the content-list. This allows multiple content strings to be specified and if any of them match, the rule triggers. The Snort Users Manual found on www.snort.org discusses this option and gives an example.

Format:

content: <"value">;

content: <"value">; content: <"value">;

Sample rule:

alert udp $EXTERNAL_NET any -> $HOME_NET 53 \ (msg: "EXPLOIT BIND tsig Overflow Attempt"; \ content: "|00 FA 00 FF|"; content: "/bin/sh";);

Sample output:

02/22-15:33:19.472301 ATTACKER:1024 -> VICTIM:53 UDP TTL:64 TOS:0x0 ID:6755 IpLen:20 DgmLen:538 Len: 518

<lines omitted to condense								output>
00	3F	90	E8	72	FF FF FF 2F			62 69	6E	2F	73	68	00	.?..r	.../bin/sh.
0E	0F	10	11	12	13	14 15	16	17 18	19	1A	1B	1C	1D	..................!"#$%&'()*+,-
1E	1F	20	21	22	23	24 25	26	27 28	29	2A	2B	2C	2D
2E	2F	30	31	32	33	34 35	36	37 38	39	3A	3B	3C	EB ./0123456789:;<.
07	C0	00	00	00	00	00 3F	00	01 02	03	04	05	06	07	.......	?........
08	09	0A	0B	0C	0D	0E 0F	10	11 12	13	14	15	16	17	................	!"#$%&'
18	19	1A	1B	1C	1D	1E 1F	20	21 22	23	24	25	26	27	........
28	29	2A	2B	2C	2D	2E 2F	30	31 32	33	34	35	36	37	()*+,-./01234567
38	39	3A	3B	3C	EB 07 C0 00			00 00	00	00	3F	00	01	89:;<........		?..
02	03	04	05	06	07	08 09	0A	0B 0C	0D	0E	0F	10	11	................	|	@
D8	FA FF BF D8 F7 FF BF D0							7C 0D	08	04	F7	10	40	.........
22	23	24	25	26	27	28 29	2A	2B 2C	2D	2E	2F	30	31	"#$%&'()*+,-./01
32	33	34	35	36	37	38 39	3A	3B 3C	EB 07 C0 00 00 23456789:;<.....
00	00	00	3F	00	01	02 03	04	05 06	07	08	09	0A	0B	...?............
0C	0D	0E	0F	10	11	12 13	14	15 16	17	18	19	1A	1B	....................!"#$%&'()*+
1C	1D	1E	1F	20	21	22 23	24	25 26	27	28	29	2A	2B
2C	2D	2E	2F	30	31	32 33	34	35 36	37	38	39	3A	3B	,-./0123456789:;
3C	EB 07 C0 00 00 00 00 00							00 00	FA 00 FF <.............

This output provides the hex characters in the payload on the left side of the output, followed by the ASCII interpretation of those characters on the right side. The rule that was created looks for UDP traffic from outside the trusted network to destination port 53 on a host on the trusted network. Specifically, it looks for the existence of two strings—the first expressed in hexadecimal 00 FA 00 FF, and the second, the text /bin/sh. Both strings must appear in the payload in any order. This rule will be refined more after some other options are discussed.

Some rule options are used only as modifiers to a content option—in other words, they are meaningless and will generate an error message unless the content option is used. These options are: offset, depth, nocase, and regex. They follow the content option that they qualify and if multiple content options are given, the offset, depth, nocase, and regex options modify only the content option that they immediately follow.

To Push or Not to Push

If you examine the TCP rules supplied with Snort, you will discover that many of those with a content option include a flag option of A+. This means for the rule to trigger, the acknowledgement flag must be set and other flags can be set as well. This might seem odd because logically, you might be thinking, "Why isn't the flag setting P+?" After all, shouldn't Snort examine content when payload bytes are pushed in the packet?

That is absolutely true; it makes the processing more efficient by qualifying the rule to look at content when actual payload data is transmitted. According to the noted author, Richard Stevens, in TCP/IP Illustrated, Volume 1, many BSD derived stacks set the push flag any time data is transmitted; but other operating system stacks set the push flag when data is sent only if the sender empties its write buffer. This means that if the receiver advertises a small TCP window size and the sender doesn't empty its write buffer when transmitting data, only the acknowledgement flag is set. That is why the A+ flag setting is used, because it will match the condition regardless if the push flag is set or not. Although many packets with only the acknowledgement flag set do not have payload, they will be considered for examination.

Alternatively, an option of dsize > 0 could be used to make sure that there was payload in the packet before examining it. This would catch unusual traffic such as data on the SYN, which the A+ would not.

As an example of payload data sent in a packet with only the acknowledgement flag set, look at two TCPdump records from LaBrea version 2, as discussed in Chapter 9, "Examining Embedded Protocol Header Fields," that slowed the attacker by advertising an unusually small TCP window size and then effectively arrested data transfer by decreasing the TCP window size to 0. The first record shows the LaBrea host 10.10.10.155 pretending to be a web server and advertising an usually small TCP window size of 5. Host attacker.net sends 5 bytes of payload, yet you see there is no push flag set along with the acknowledgement flag because this amount of data was too small to empty attacker.net's TCP write

buffer:

10.10.10.155.www > attacker.net.2045: S 998514038:998514038(0) ack 882335287

win 5

attacker.net.2045 > 10.10.10.155.www: . 1:6(5) ack 1 win 8576 (DF)

Offset Option

As mentioned, the content search is computationally expensive, but it can be made more efficient by starting the search at an offset into the payload if the location of the content is known to begin somewhere other than the first byte in the payload. By default, the content search starts at the first byte, which is considered to be offset 0.

Format:

offset: <number>;

Sample rule:

alert tcp any any -> 192.168.5.0/24 21 \ (msg: "Attempted anonymous ftp access"; \ content: "anonymous"; offset: 5;)

Sample output:

[**] Attempted anonymous ftp access [**] 04/24-12:11:08.724441 192.168.143.15:3484 -> 192.168.5.16:21