Working with Snort Rules

This chapter is from the book 

3.6 Rule Options

Rule options follow the rule header and are enclosed inside a pair of parentheses. There may be one option or many and the options are separated with a semicolon. If you use multiple options, these options form a logical AND. The action in the rule header is invoked only when all criteria in the options are true. You have already used options like msg and ttl in previous rule examples. All options are defined by keywords. Some rule options also contain arguments. In general, an option may have two parts: a keyword and an argument. Arguments are separated from the option keyword by a colon. Consider the following rule options that you have already seen:

msg: "Detected confidential";

In this option msg is the keyword and “Detected confidential” is the argument to this keyword.

The remainder of this section describes keywords used in the options part of Snort rules.

3.6.1 The ack Keyword

The TCP header contains an Acknowledgement Number field which is 32 bits long. The field shows the next sequence number the sender of the TCP packet is expecting to receive. This field is significant only when the ACK flag in the TCP header is set. Refer to Appendix C and RFC 793 for more information about the TCP header.

Tools like nmap (http://www.nmap.org) use this feature of the TCP header to ping a machine. For example, among other techniques used by nmap, it can send a TCP packet to port 80 with ACK flag set and sequence number 0. Since this packet is not acceptable by the receiving side according to TCP rules, it sends back a RST packet. When nmap receives this RST packet, it learns that the host is alive. This method works on hosts that don't respond to ICMP ECHO REQUEST ping packets.

To detect this type of TCP ping, you can have a rule like the following that sends an alert message:

alert tcp any any -> 192.168.1.0/24  any (flags: A;    ack: 0; msg: "TCP ping detected";)

This rule shows that an alert message will be generated when you receive a TCP packet with the A flag set and the acknowledgement contains a value of 0. Other TCP flags are listed in Table 3-2. The destination of this packet must be a host in network 192.168.1.0/24. You can use any value with the ACK keyword in a rule, however it is added to Snort only to detect this type of attack. Generally when the A flag is set, the ACK value is not zero.

3.6.2 The classtype Keyword

Rules can be assigned classifications and priority numbers to group and distinguish them. To fully understand the classtype keyword, first look at the file classification.config which is included in the snort.conf file using the include keyword. Each line in the classification.config file has the following syntax:

config classification: name,description,priority

The name is a name used for the classification. The name is used with the classtype keyword in Snort rules. The description is a short description of the class type. Priority is a number that shows the default priority of the classification, which can be modified using a priority keyword inside the rule options. You can also place these lines in snort.conf file as well. An example of this configuration parameter is as follows:

config classification: DoS,Denial of Service Attack,2

In the above line the classification is DoS and the priority is 2. In Chapter 6, you will see that classifications are used in ACID,² which is a web-based tool to analyze Snort alert data. Now let us use this classification in a rule. The following rule uses default priority with the classification DoS:

alert udp any any -> 192.168.1.0/24 6838 (msg:"DoS";    content: "server";  classtype:DoS;)

The following is the same rule but we override the default priority used for the classification.

alert udp any any -> 192.168.1.0/24 6838 (msg:"DoS";    content: "server";  classtype:DoS; priority:1)

Using classifications and priorities for rules and alerts, you can distinguish between high- and low-risk alerts. This feature is very useful when you want to escalate high-risk alerts or want to pay attention to them first.

If you look at the ACID browser window, as discussed in Chapter 6, you will see the classification screens as shown in Figure 3-3. The second column in the middle part of the screen displays different classifications for captured data.

Figure 3-3. Use of the classification keyword in displaying Snort alerts inside ACID window.

Other tools also use the classification keyword to prioritize intrusion detection data. A typical
classification.config file is shown below. This file is distributed with the Snort 1.9.0. You can add
your own classifications to this file and use them in your own rules.

# $Id: classification.config,v 1.10 2002/08/11 23:37:18 cazz Exp $
# The following includes information for prioritizing rules
#
# Each classification includes a shortname, a description, and a default
# priority for that classification.
#
# This allows alerts to be classified and prioritized.  You can specify
# what priority each classification has.  Any rule can override the default
# priority for that rule.
#
# Here are a few example rules:
#
#   alert TCP any any -> any 80 (msg: "EXPLOIT ntpdx overflow";
#       dsize: > 128; classtype:attempted-admin; priority:10;
#
#   alert TCP any any -> any 25 (msg:"SMTP expn root"; flags:A+; #             
content:"expn root"; nocase; classtype:attempted-recon;)
#
# The first rule will set its type to "attempted-admin" and override
# the default priority for that type to 10.
#
# The second rule set its type to "attempted-recon" and set its
# priority to the default for that type.
#

#
# config classification:shortname,short description,priority
#

config classification: not-suspicious,Not Suspicious Traffic,3
config classification: unknown,Unknown Traffic,3
config classification: bad-unknown,Potentially Bad Traffic, 2
config classification: attempted-recon,Attempted Information Leak,2
config classification: successful-recon-limited,Information Leak,2
config classification: successful-recon-largescale,Large Scale Information Leak,2
config classification: attempted-dos,Attempted Denial of Service,2
config classification: successful-dos,Denial of Service,2
config classification: attempted-user,Attempted User Privilege Gain,1
config classification: unsuccessful-user,Unsuccessful User Privilege Gain,1
config classification: successful-user,Successful User Privilege Gain,1
config classification: attempted-admin,Attempted Administrator Privilege Gain,1
config classification: successful-admin,Successful Administrator Privilege Gain,1


# NEW CLASSIFICATIONS
config classification: rpc-portmap-decode,Decode of an RPC Query,2
config classification: shellcode-detect,Executable code was detected,1
config classification: string-detect,A suspicious string was detected,3
config classification: suspicious-filename-detect,A suspicious filename was detected,2
config classification: suspicious-login,An attempted login using a suspicious username 
was detected,2
   config classification: system-call-detect,A system call was detected,2
   config classification: tcp-connection,A TCP connection was detected,4
   config classification: trojan-activity,A Network Trojan was detected, 1
   config classification: unusual-client-port-connection,A client was using an unusual port,2
   config classification: network-scan,Detection of a Network Scan,3
   config classification: denial-of-service,Detection of a Denial of Service Attack,2
   config classification: non-standard-protocol,Detection of a non-standard protocol or 
   event,2
   config classification: protocol-command-decode,Generic Protocol Command Decode,3
   config classification: web-application-activity,access to a potentially vulnerable web 
   application,2
   config classification: web-application-attack,Web Application Attack,1
   config classification: misc-activity,Misc activity,3
   config classification: misc-attack,Misc Attack,2
   config classification: icmp-event,Generic ICMP event,3
   config classification: kickass-porn,SCORE! Get the lotion!,1
   config classification: policy-violation,Potential Corporate Privacy Violation,1
   config classification: default-login-attempt,Attempt to login by a default username and 
   password,2
   

3.6.3 The content Keyword

One important feature of Snort is its ability to find a data pattern inside a packet. The pattern may be presented in the form of an ASCII string or as binary data in the form of hexadecimal characters. Like viruses, intruders also have signatures and the content keyword is used to find these signatures in the packet. Since Snort version 1.x does not support application layer protocols, this keyword, in conjunction with the offset keyword, can also be used to look into the application layer header.

The following rule detects a pattern “GET” in the data part of all TCP packets that are leaving 192.168.1.0 network and going to an address that is not part of that network. The GET keyword is used in many HTTP related attacks; however, this rule is only using it to help you understand how the content keyword works.

alert tcp 192.168.1.0/24 any -> ![192.168.1.0/24] any   (content: "GET"; msg: "GET matched";)

The following rule does the same thing but the pattern is listed in hexadecimal.

alert tcp 192.168.1.0/24 any -> ![192.168.1.0/24] any   (content: "|47 45 54|"; msg: "GET matched";)

Hexadecimal number 47 is equal to ASCII character G, 45 is equal to E, and 54 is equal to T. You can also match both ASCII strings and binary patterns in hexadecimal form inside one rule. Just enclose the hexadecimal characters inside a pair of bar symbols: ||.

When using the content keyword, keep the following in mind:

• Content matching is a computationally expensive process and you should be careful of using too many rules for content matching.

• If you provide content as an ASCII string, you should escape the double quote, colon and bar symbols.

• You can use multiple content keywords in one rule to find multiple signatures in the data packet.

• Content matching is case sensitive.

There are three other keywords that are used with the content keyword. These keywords add additional criteria while finding a pattern inside a packet. These are:

• The offset keyword

• The depth keyword

• The nocase keyword

These keywords are discussed later in this chapter. The first two keywords are used to confine the search within a certain range of the data packet. The nocase keyword is used to make the search case-insensitive.

3.6.4 The offset Keyword

The offset keyword is used in combination with the content keyword. Using this keyword, you can start your search at a certain offset from the start of the data part of the packet. Use a number as argument to this keyword. The following rule starts searching for the word “HTTP” after 4 bytes from the start of the data.

alert tcp 192.168.1.0/24 any -> any any   (content: "HTTP"; offset: 4; msg: "HTTP matched";)

You can use the depth keyword to define the point after which Snort should stop searching the pattern in the data packets.

3.6.5 The depth Keyword

The depth keyword is also used in combination with the content keyword to specify an upper limit to the pattern matching. Using the depth keyword, you can specify an offset from the start of the data part. Data after that offset is not searched for pattern matching. If you use both offset and depth keywords with the content keyword, you can specify the range of data within which pattern matching should be done. The following rule tries to find the word “HTTP” between characters 4 and 40 of the data part of the TCP packet.

alert tcp 192.168.1.0/24 any -> any any (content:    "HTTP"; offset: 4; depth: 40; msg: "HTTP matched";)

This keyword is very important since you can use it to limit searching inside the packet. For example, information about HTTP GET requests is found in the start of the packet. There is no need to search the entire packet for such strings. Since many packets you capture are very long in size, it wastes a lot of time to search for these strings in the entire packet. The same is true for many other Snort signatures.

3.6.6 The content-list Keyword

The content-list keyword is used with a file name. The file name, which is used as an argument to this keyword, is a text file that contains a list of strings to be searched inside a packet. Each string is located on a separate line of the file. For example, a file named “porn” may contain the following three lines:

“porn”

“hardcore”

“under 18”

The following rule will search these strings in the data portion of all packets matching the rule criteria.

alert ip any any -> 192.168.1.0/24 any (content-list:    "porn"; msg: "Porn word matched";)

You can also use the negation sign ! with the file name if you want to generate an alert for a packet where no strings match.

3.6.7 The dsize Keyword

The dsize keyword is used to find the length of the data part of a packet. Many attacks use buffer overflow vulnerabilities by sending large size packets. Using this keyword, you can find out if a packet contains data of a length larger than, smaller than, or equal to a certain number. The following rule generates an alert if the data size of an IP packet is larger than 6000 bytes.

alert ip any any -> 192.168.1.0/24 any (dsize: > 6000;    msg: "Large size IP packet detected";)

3.6.8 The flags Keyword

The flags keyword is used to find out which flag bits are set inside the TCP header of a packet. Each flag can be used as an argument to flags keyword in Snort rules. A detailed description of the TCP flag bits is present in RFC 793 at http://www.rfc-editor.org/rfc/rfc793.txt. These flag bits are used by many security related tools for different purposes including port scanning tools like nmap (http://www.nmap.org). Snort supports checking of these flags listed in Table 3-2.

Table 3-2. TCP flag bits

Flag	Argument character used in Snort rules
FIN or Finish Flag	F
SYN or Sync Flag	S
RST or Reset Flag	R
PSH or Push Flag	P
ACK or Acknowledge Flag	A
URG or Urgent Flag	U
Reserved Bit 1	1
Reserved Bit 2	2
No Flag set	0

You can also use !, +, and * symbols just like IP header flag bits (discussed under the fragbits keyword) for AND, OR and NOT logical operations on flag bits being tested. The following rule detects any scan attempt using SYN-FIN TCP packets.

alert tcp any any -> 192.168.1.0/24 any (flags: SF;    msg: "SYNC-FIN packet detected";)

Note that ! symbol is used for NOT, + is used for AND, and * is used for OR operation.

3.6.9 The fragbits Keyword

The IP header contains three flag bits that are used for fragmentation and re-assembly of IP packets. These bits are listed below:

• Reserved Bit (RB), which is reserved for future use.

• Don't Fragment Bit (DF). If this bit is set, it shows that the IP packet should not be fragmented.

• More Fragments Bit (MF). If this bit is set, it shows that more fragments of this IP packet are on the way. If this bit is not set, it shows that this is the last fragment (or the only fragment) of the IP packet. The sending host fragments IP packets into smaller packets depending on the maximum size packet that can be transmitted through a communication medium. For example, the Maximum Transfer Units or MTU defines the maximum length of a packet on the Ethernet networks. This bit is used at the destination host to reassemble IP fragments.

For more information on Flag bits refer to RFC 791 at http://www.rfc-editor.org/rfc/rfc791.txt. Sometimes these bits are used by hackers for attacks and to find out information related to your network. For example, the DF bit can be used to find the minimum and maximum MTU for a path from source to destination. Using the fragbits keyword, you can find out if a packet contains these bits set or cleared. The following rule is used to detect if the DF bit is set in an ICMP packet.

alert icmp any any -> 192.168.1.0/24 any (fragbits: D;    msg: "Don't Fragment bit set";)

In this rule, D is used for DF bit. You can use R for reserved bit and M for MF bit. You can also use the negation symbol ! in the rule. The following rule detects if the DF bit is not set, although this rule is of little use.

alert icmp any any -> 192.168.1.0/24 any (fragbits: !D;    msg: "Don't Fragment bit not set";)

The AND and OR logical operators can also be used to check multiple bits. The + symbol specifies all bits be matched (AND operation) while the * symbol specifies any of the specified bits be matched (OR operation).

3.6.10 The icmp_id Keyword

The icmp_id option is used to detect a particular ID used with ICMP packet. Refer to Appendix C for ICMP header information. The general format for using this keyword is as follows:

icmp_id: <ICMP_id_number>

An ICMP identified field is found in ICMP ECHO REQUEST and ICMP ECHO REPLY messages as discussed in RFC 792. This field is used to match ECHO REQUEST and ECHO REPLY messages. Usually when you use the ping command, both of these types of ICMP packets are exchanged between sending and receiving hosts. The sending host sends ECHO REQUEST packets and the destination host replies with ECHO REPLY-type ICMP packets. This field is useful for discovering which packet is the reply to a particular request. The following rule checks if the ICMP ID field in the ICMP header is equal to 100. It generates an alert if this criterion is met.

alert icmp any any -> any any (icmp_id: 100;    msg: "ICMP ID=100";)

3.6.11 The icmp_seq Keyword

The icmp_seq option is similar to the icmp_id keyword The general format for using this keyword is as follows:

icmp_seq: <ICMP_seq_number>

The sequence number is also a field in the ICMP header and is also useful in matching ICMP ECHO REQUEST and ECHO REPLY matches as mentioned in RFC 792. The keyword helps to find a particular sequence number. However, the practical use of this keyword is very limited. The following rule checks a sequence number of 100 and generates an alert:

alert icmp any any -> any any (icmp_seq: 100;    msg: "ICMP Sequence=100";)

3.6.12 The itype Keyword

The ICMP header comes after the IP header and contains a type field. Appendix C explains the IP header and the different codes that are used in the type field. A detailed discussion is found in RFC 792 at http://www.rfc-editor.org/rfc/rfc792.txt. The itype keyword is used to detect attacks that use the type field in the ICMP packet header. The argument to this field is a number and the general format is as follows:

itype: "ICMP_type_number"

The type field in the ICMP header of a data packet is used to determine the type of the ICMP packet. Table 3-3 lists different ICMP types and values of the type field in the ICMP header.

Table 3-3. ICMP type filed values

Value	Type of ICMP Packet
0	Echo reply
3	Destination unreachable
4	Source quench
5	Redirect
8	Echo request
11	Time exceed
12	Parameter problem
13	Timestamp request
14	Timestamp reply
15	Information request
16	Information reply

For example, if you want to generate an alert for each source quench message, use the following rule:

alert icmp any any -> any any (itype: 4;    msg: "ICMP Source Quench Message received";)

The ICMP code field is used to further classify ICMP packets.

3.6.13 The icode Keyword

In ICMP packets, the ICMP header comes after the IP header. It contains a code field, as shown in Appendix C and RFC 792 at http://www.rfc-editor.org/rfc/rfc792.txt. The icode keyword is used to detect the code field in the ICMP packet header. The argument to this field is a number and the general format is as follows:

icode: "ICMP_codee_number"

The type field in the ICMP header shows the type of ICMP message. The code field is used to explain the type in detail. For example, if the type field value is 5, the ICMP packet type is “ICMP redirect” packet. There may be many reasons for the generation of an ICMP redirect packet. These reasons are defined by the code field as listed below:

• If code field is 0, it is a network redirect ICMP packet.

• If code field is 1, it is a host redirect packet.

• If code is 2, the redirect is due to the type of service and network.

• If code is 2, the redirect is due to type of service and host.

The icode keyword in Snort rule options is used to find the code field value in the ICMP header. The following rule generates an alert for host redirect ICMP packets.

alert icmp any any -> any any (itype: 5;    icode: 1; msg: "ICMP ID=100";)

Both itype and icode keywords are used. Using the icode keyword alone will not do the job because other ICMP types may also use the same code value.

3.6.14 The id Keyword

The id keyword is used to match the fragment ID field of the IP packet header. Its purpose is to detect attacks that use a fixed ID number in the IP header of a packet. Its format is as follows:

id: "id_number"

If the value of the id field in the IP packet header is zero, it shows that this is the last fragment of an IP packet (if the packet was fragmented). The value 0 also shows that it is the only fragment if the packet was not fragmented. The id keyword in the Snort rule can be used to determine the last fragment in an IP packet.

3.6.15 The ipopts Keyword

A basic IPv4 header is 20 bytes long as described in Appendix C. You can add options to this IP header at the end. The length of the options part may be up to 40 bytes. IP options are used for different purposes, including:

• Record Route (rr)

• Time Stamps (ts)

• Loose Source Routing (lsrr)

• Strict Source Routing (ssrr)

For a complete list of IP options see RFC 791 at http://www.rfc-editor.org/rfc/rfc791.txt. In Snort rules, the most commonly used options are listed above. These options can be used by some hackers to find information about your network. For example, loose and strict source routing can help a hacker discover if a particular network path exists or not.

Using Snort rules, you can detect such attempts with the ipopts keyword. The following rule detects any attempt made using Loose Source Routing:

alert ip any any -> any any (ipopts: lsrr;    msg: "Loose source routing attempt";)

You can also use a logto keyword to log the messages to a file. However, you can't specify multiple IP options keywords in one rule.

3.6.16 The ip_proto Keyword

The ip_proto keyword uses IP Proto plug-in to determine protocol number in the IP header. The keyword requires a protocol number as argument. You can also use a name for the protocol if it can be resolved using /etc/protocols file. Sample entries in this file look like the following:

ax.25   93      AX.25           # AX.25 Frames
ipip    94      IPIP            # Yet Another IP encapsulation
micp    95      MICP            # Mobile Internetworking Control Pro.
scc-sp  96      SCC-SP          # Semaphore Communications Sec. Pro.
etherip 97      ETHERIP         # Ethernet-within-IP Encapsulation
encap   98      ENCAP           # Yet Another IP encapsulation
#       99                      # any private encryption scheme
gmtp    100     GMTP            # GMTP
ifmp    101     IFMP            # Ipsilon Flow Management Protocol
pnni    102     PNNI            # PNNI over IP

The following rule checks if IPIP protocol is being used by data packets:

alert ip any any -> any any (ip_proto: ipip;    msg: "IP-IP tunneling detected";)

The next rule is the same except that it uses protocol number instead of name (more efficient).

alert ip any any -> any any (ip_proto: 94;    msg: "IP-IP tunneling detected";)

Protocol numbers are defined in RFC 1700 at http://www.rfc-editor.org/rfc/rfc1700.txt. The latest numbers can be found from the ICANN web site at http://www.icann.org or at IANA web site http://www.iana.org.

3.6.17 The logto Keyword

The logto keyword is used to log packets to a special file. The general syntax is as follows:

logto:logto_log

Consider the following rule:

alert icmp any any -> any any (logto:logto_log; ttl: 100;)

This rule will log all ICMP packets having TTL value equal to 100 to file logto_log. A typical logged packet in this file is as follows:

[root@conformix]# cat logto_log
   07/03-03:57:56.496845 192.168.1.101 -> 192.168.1.2
   ICMP TTL:100 TOS:0x0 ID:33822 IpLen:20 DgmLen:60
   Type:8  Code:0  ID:768   Seq:9217  ECHO
   61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70  abcdefghijklmnop
   71 72 73 74 75 76 77 61 62 63 64 65 66 67 68 69  qrstuvwabcdefghi
   
   =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   
   [root@conformix]#
   

Information logged in the above example is as follows:

• Data and time the packet was logged.

• Source IP address is 192.168.1.101.

• Destination IP address is 192.168.1.2.

• Protocol used in the packet is ICMP.

• The TTL (Time To Live) field value in the IP header is 100.

• The TOS (Type Of Service) field value in IP header is 0. This value shows that this is a normal packet. For details of other TOS values, refer to RFC 791.

• IP packet ID is 33822.

• Length of IP header is 20 bytes.

• Length of the packet is 60 bytes.

• ICMP type filed value is 8.

• ICMP code value is 0.

• ICMP ID value is 768.

• ICMP Sequence field value is 9217.

• The ECHO part shows that this is an ICMP ECHO packet.

• The remaining part of the log shows the data that follows the ICMP header.

There are a few things to remember when you use this option:

• Don't use the full path with the file name. The file will automatically be created in the log directory which is /var/log/snort by default.

• Don't use a space character after the colon character used with logto keyword. If you use a space character, it is considered part of the file name. If you use a space character for clarity, enclose the file name in double quotation marks.

3.6.18 The msg Keyword

The msg keyword in the rule options is used to add a text string to logs and alerts. You can add a message inside double quotations after this keyword. The msg keyword is a common and useful keyword and is part of most of the rules. The general form for using this keyword is as follows:

msg: "Your message text here";

If you want to use some special character inside the message, you can escape them by a backslash character.

3.6.19 The nocase Keyword

The nocase keyword is used in combination with the content keyword. It has no arguments. Its only purpose is to make a case insensitive search of a pattern within the data part of a packet.

3.6.20 The priority Keyword

The priority keyword assigns a priority to a rule. Priority is a number argument to this keyword. Number 1 is the highest priority. The keyword is often used with the classtype keyword. The following rule has a priority 10:

alert ip any any -> any any (ipopts: lsrr;    msg: "Loose source routing attempt"; priority: 10;)

The priority keyword can be used to differentiate high priority and low priority alerts.

3.6.21 The react Keyword

The react keyword is used with a rule to terminate a session to block some sites or services. Not all options with this keyword are operational. The following rule will block all HTTP connections originating from your home network 192.168.1.0/24. To block the HTTP access, it will send a TCP FIN and/or FIN packet to both sending and receiving hosts every time it detects a packet that matches these criteria. The rule causes a connection to be closed.

alert tcp 192.168.1.0/24 any -> any 80 (msg: "Outgoing    HTTP connection"; react: block;)

In the above rule, block is the basic modifier. You can also use the warn modifier to send a visual notice to the source. You can also use the additional modifier msg which will include the msg string in the visual notification on the browser. The following is an example of this additional modifier.

alert tcp 192.168.1.0/24 any -> any 80 (msg: "Outgoing    HTTP connection"; react: warn, msg;)

In order to use the react keyword, you should compile Snort with --enable-flexresp command line option in the configure script. For a discussion of the compilation process, refer to Chapter 2.

The react should be the last keyword in the options field. The warn modifier still does not work properly in the version of Snort I am using.

3.6.22 The reference Keyword

The reference keyword can add a reference to information present on other systems available on the Internet. It does not play any role in the detection mechanism itself and you can safely ignore it as far as writing Snort rules is concerned. There are many reference systems available, such as CVE and Bugtraq. These systems keep additional information about known attacks. By using this keyword, you can link to this additional information in the alert message. For example, look at the following rule in the misc.rules file distributed with Snort:

alert udp $EXTERNAL_NET any -> $HOME_NET 1900 (msg:"MISC UPNP malformed advertisement";
 content:"NOTIFY * "; nocase; classtype:misc-attack; reference:cve,CAN-2001-0876; reference:cve, 
CAN-2001-0877; sid:1384; rev:2;)

This rule generates the following entry in /var/log/snort/alert file:

[**] [1:1384:2] MISC UPNP malformed advertisement [**]
[Classification: Misc Attack] [Priority: 2]
12/01-15:25:21.792758 192.168.1.1:1901 -> 239.255.255.250:1900
UDP TTL:150 TOS:0x0 ID:9 IpLen:20 DgmLen:341
Len: 321
[Xref => cve CAN-2001-0877][Xref => cve CAN-2001-0876]

The last line of this alert shows a reference where more information about this alert can be found. The reference.config file plays an important role because it contains the actual URL to reach a particular reference. For example, the following line in reference.config file will reach the actual URL using the last line of the alert message.

config reference: cve  http://cve.mitre.org/cgi-bin/cvename.cgi?name=

When you add CAN-2001-0876 at the end of this URL, you will reach the web site containing information about this alert. So the actual URL for information about this alert is http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2001-0876.

Multiple references can be placed in a rule. References are also used by tools like ACID³ to provide additional information about a particular vulnerability. The same log message, when displayed in an ACID window, will look like Figure 3-4. In this figure, the URL is already inserted under the “Triggered Signature” heading. You can click on it to go to the CVE web site for more information.

Figure 3-4. Use of reference keyword in ACID window.

3.6.23 The resp Keyword

The resp keyword is a very important keyword. It can be used to knock down hacker activity by sending response packets to the host that originates a packet matching the rule. The keyword is also known as Flexible Response or simply FlexResp and is based on the FlexResp plug-in. The plug-in should be compiled into Snort, as explained in Chapter 2, using the command line option (--with-flexresp) in the configure script. The following rule will send a TCP Reset packet to the sender whenever an attempt to reach TCP port 8080 on the local network is made.

alert tcp any any -> 192.168.1.0/24 8080 (resp: rst_snd;)

You can send multiple response packets to either sender or receiver by specifying multiple responses to the resp keyword. The arguments are separated by a comma. The list of arguments that can be used with this keyword is found in Table 3-4.

Table 3-4. Arguments to resp keyword

Argument	Description
rst_snd	Sends a TCP Reset packet to the sender of the packet
rst_rcv	Sends a TCP Reset packet to the receiver of the packet
rst_all	Sends a TCP Reset packet to both sender and receiver
icmp_net	Sends an ICMP Network Unreachable packet to sender
icmp_host	Sends an ICMP Host Unreachable packet to sender
icmp_port	Sends an ICMP Port Unreachable packet to sender
icmp_all	Sends all of the above mentioned packets to sender

3.6.24 The rev Keyword

The rev keyword is added to Snort rule options to show a revision number for the rule. If you are updating rules, you can use this keyword to distinguish among different revision. Output modules can also use this number to identify the revision number. The following rule shows that the revision number is 2 for this rule:

alert ip any any -> any any (ipopts: lsrr;    msg: "Loose source routing attempt"; rev: 2;)

For more information, refer to the sid keyword, which is related to the rev keyword.

3.6.25 The rpc Keyword

The rpc keyword is used to detect RPC based requests. The keyword accepts three numbers as arguments:

• Application number

• Procedure number

• Version number

These arguments are separated by a comma. You can also use an asterisk to match all numbers in a particular location of the arguments. The following rule detects RPC requests for TPC number 10000, all procedures and version number 3.

alert ip any any -> 192.168.1.0/24 any (rpc: 10000,*,3;    msg: "RPC request to local network";)

3.6.26 The sameip Keyword

The sameip keyword is used to check if source and destination IP addresses are the same in an IP packet. It has no arguments. Some people try to spoof IP packets to get information or attack a server. The following rule can be used to detect these attempts.

alert ip any any -> 192.168.1.0/24 any (msg: "Same IP";    sameip;)

3.6.27 The seq Keyword

The seq keyword in Snort rule options can be used to test the sequence number of a TCP packet. The argument to this keyword is a sequence number. The general format is as follows:

seq: "sequence_number";

Sequence numbers are a part of the TCP header. More explanation of sequence number is found in Appendix C where the TCP header is discussed.

3.6.28 The flow⁴ Keyword

The flow keyword is used to apply a rule on TCP sessions to packets flowing in a particular direction. You can use options with the keyword to determine direction. The following options can be used with this keyword determine direction:

• to_client

• to_server

• from_client

• from_server

These options may be confusing the first time you look at them. Just keep in mind that options starting with “to” are used for responses and options starting with “from” are used for requests.

Other options are also available which are used to apply the rule to different states of a TCP connection.

• The stateless option is used to apply the rule without considering the state of a TCP session.

• The established option is used to apply the rule to established TCP sessions only.

• The no_stream option enables rules to be applied to packets that are not built from a stream.

• The stream_only option is used to apply the rules to only those packets that are built from a stream.

TCP streams are handled by the stream4 preprocessor discussed in the next chapter. TCP streams are also discussed in RFC 793. A TCP session is established and finished with a defined sequence of TCP packet exchanges as defined in RFC 793. The stateless and established options are related to TCP session state.

3.6.29 The session Keyword

The session keyword can be used to dump all data from a TCP session. It can dump all session data or just printable characters. The following rule dumps all printable data from POP3 sessions:

log tcp any any -> 192.168.1.0/24 110 (session: printable;)

If you use “all” as argument to this keyword, everything will be dumped. Use the logto keyword to log the traffic to a particular file.

A TCP session is a sequence of data packets exchanged between two hosts. The session is usually initiated and closed by the client using the three-way handshake method discussed in RFC 793. For example, when your e-mail client software starts collecting e-mail from a POP3 server, it first starts the communication by exchanging TCP packets. The mail is then downloaded. After downloading the e-mail, the client closes the connection. All communication taking place during this process is a TCP session.

3.6.30 The sid Keyword

The sid keyword is used to add a “Snort ID” to rules. Output modules or log scanners can use SID to identify rules. Authors have reserved SID ranges for rules as shown below:

• Range 0-99 is reserved for future use.

• Range 100-1,000,000 is reserved for rules that come with Snort distribution.

• All numbers above 1,000,000 can be used for local rules.

Refer to the list of rules that came with your Snort distribution for examples. The only argument to this keyword is a number. The following rule adds SID equal to 1000001.

alert ip any any -> any any (ipopts: lsrr;    msg: "Loose source routing attempt"; sid: 1000001;)

Using SID, tools like ACID can display the actual rule that generated a particular alert.

3.6.31 The tag Keyword

The tag keyword is another very important keyword that can be used for logging additional data from/to the intruder host when a rule is triggered. The additional data can then be analyzed later on for detailed intruder activity. The general syntax of the keyword is as follows:

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

The arguments are explained in Table 3-5.

Table 3-5. Arguments used with tag keyword

Argument	Description
Type	You can use either “session” or “host” as the type argument. Using session, packets are logged from the particular session that triggered the rule. Using host, all packets from the host are logged.
Count	This indicates either the number of packets logged or the number of seconds during which packets will be logged. The distinction between the two is made by the metric argument.
Metric	You can use either “packets” or “seconds” as mentioned above.
Direction	This argument is optional. You can use either “src” to log packets from source or “dst” to log packets from the destination.

The following rule logs 100 packets on the session after it is triggered.

alert tcp 192.168.2.0/24 23 -> any any     (content: "boota"; msg: "Detected boota";     
tag: session, 100, packets;)

3.6.32 The tos Keyword

The tos keyword is used to detect a specific value in the Type of Service (TOS) field of the IP header. The format for using this keyword is as follows:

tos: 1;

For more information on the TOS field, refer to RFC 791 and Appendix C, where the IP packet header is discussed.

3.6.33 The ttl Keyword

The ttl keyword is used to detect Time to Live value in the IP header of the packet. The keyword has a value which should be an exact match to determine the TTL value. This keyword can be used with all types of protocols built on the IP protocol, including ICMP, UDP and TCP. The general format of the keyword is as follows:

ttl: 100;

The traceroute utility uses TTL values to find the next hop in the path. The traceroute sends UDP packets with increasing TTL values. The TTL value is decremented at every hop. When it reaches zero, the router generates an ICMP packet to the source. Using this ICMP packet, the utility finds the IP address of the router. For example, to find the fifth hop router, the traceroute utility will send UDP packets with TTL value set to 5. When the packet reaches the router at the fifth hop, its value becomes zero and an ICMP packet is generated.

Using the ttl keyword, you can find out if someone is trying to traceroute through your network. The only problem is that the keyword needs an exact match of the TTL value.

For more information on the TTL field, refer to RFC 791 and Appendix C where the IP packet header is discussed.

3.6.34 The uricontent Keyword

The uricontent keyword is similar to the content keyword except that it is used to look for a string only in the URI part of a packet.