SNORT RULES

Snort rules Snort uses a simple, lightweight rules description language that is flexible and quite powerful. A rule may be used to generate an alert message, log a message, or, in terms of Snort, pass the data packet, i.e., drop it silently. Rules are usually placed in a configuration file, typically snort.conf.

Most Snort rules are written in a single line Most Snort rules are written in a single line. This was required in versions prior to 1.8. In current versions of Snort, rules may span multiple lines by adding a backslash \ to the end of the line.

The First Bad Rule Here is the first (very) bad rule. In fact, this may be the worst rule ever written, but it does a very good job of testing if Snort is working well and is able to generate alerts. alert ip any any -> any any (msg: "IP Packet detected";) The rule will generate an alert message for every captured IP packet. It will soon fill up your disk space if you leave it there! This rule is bad because it does not convey any information.

The word “alert” shows that this rule will generate an alert message when the criteria are met for a captured packet. The criteria are defined by the words that follow. The “ip” part shows that this rule will be applied on all IP packets. The first “any” is used for source IP address and shows that the rule will be applied to all packets. The second “any” is used for the port number. The -> sign shows the direction of the packet.

The third “any” is used for destination IP address and shows that the rule will be applied to all packets irrespective of destination IP address. The fourth “any” is used for destination port. Again it is irrelevant because this rule is for IP packets and port numbers are irrelevant. The last part is the rule options and contains a message that will be logged along with the alert.

Again, this rule is useful to find out if Snort is working. The next rule isn’t quite as bad. It generates alerts for all captured ICMP packets. Again, this rule is useful to find out if Snort is working. alert icmp any any -> any any (msg: "ICMP Packet\ found";)

Structure of a Rule Snort rules are divided into two logical sections. rule header rule options.

structure of Snort rules The rule header contains the rule's action, protocol, source and destination IP addresses and the source and destination ports information. The rule option section contains alert messages and information on which parts of the packet should be inspected to determine if the rule action should be taken.

Structure of Snort rule header

Action Field The action is the first part of a Snort rule. It shows what action will be taken when rule conditions are met. An action is taken only when all of the conditions mentioned in a rule are true. action part of the rule determines the type of action taken when criteria are met and a rule is exactly matched against a data packet. Following actions are used in snort. Log Alert Pass (no longer look at package) Activate (turns on other rules) Dynamic (needs to be turned on by another rule)

1. Log Action 2. Alert Action The log action is used to log a packet. Packets can be logged in different ways. For example, a message can be logged to log files or in a database. Packets can be logged with different levels of detail depending on the command line arguments and configuration file. 2. Alert Action The alert action is used to send an alert message when rule conditions are true for a particular packet. An alert can be sent in multiple ways. For example, we can send an alert to a file or to a console. The functional difference between Log and Alert actions is that Alert actions send an alert message and then log the packet. The Log action only logs the packet.

3. Pass This action tells Snort to ignore the packet. This action plays an important role in speeding up Snort operation in cases where we don’t want to apply checks on certain packets. For example, if we have a vulnerability assessment host on our own network that we use to find possible security holes in our network, we may want Snort to ignore any attacks from that host. The pass rule plays an important part in such a case. 4. Activate The activate action is used to create an alert and then to activate another rule for checking more conditions. Dynamic rules, are used for this purpose. The activate action is used when we need further testing of a captured packet.

5. Dynamic Dynamic action rules are invoked by other rules using the “activate” action. In normal circumstances, they are not applied on a packet. A dynamic rule can be activated only by an “activate” action defined in another role.

Protocol Field The protocol part is used to apply the rule on packets for a particular protocol only. Some examples of protocols used are TCP UDP ICMP IP

Source and Destination IP Address Field The address parts define source and destination addresses. Addresses may be a single host, multiple hosts or network addresses. We can also use these parts to exclude some addresses from a complete network.

Source and Destination Port Field In case of TCP or UDP protocol, the port parts determine the source and destination ports of a packet on which the rule is applied. In case of network layer protocols like IP and ICMP, port numbers have no significance. Static port: 111 All ports: any Range: 110:300 Negation: !80

Direction Indicator The direction part of the rule actually determines which address and port number is used as source and which as destination. -> Source information specified to the left of arrow, destination information specified to the right of the arrow.

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. The action in the rule header is invoked only when all criteria in the options are true.

an option may have two parts: Keyword argument. Arguments are separated from the option keyword by a colon. Con-sider the following rule options msg: "Detected confidential"; In this option msg is the keyword and “Detected confidential” is the argument to this keyword.

The Msg Option The msg option allows the user or analyst to assign an appropriate message to the output of a triggered 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 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. alert tcp any any -> 192.168.1.0/24 any (flags: A; \ ack: 0; msg: "TCP ping detected";)

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

The classtype Keyword Rules can be assigned classifications and priority numbers to group them. alert udp any any -> 192.168.1.0/24 6838\ (msg:"DoS"; classtype: DoS;)

The offset Keyword we can start our search at a certain offset from the start of the data part of the packet Use a number as argument to this keyword. we can use the depth keyword to define the point after which Snort should stop searching the pattern in the data packets. alert tcp 192.168.1.0/24 any -> any any (content: \ "HTTP"; offset: 4; depth: 40; msg: "HTTP matched";)

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 TCP TTL:64 TOS:0x10 ID:30124 DF ***AP*** Seq: 0x93EE0AB7 Ack: 0xB8352E61 Win: 0x7D78 TCP Options => NOP NOP TS 112024246 27551686 55 53 45 52 20 61 6E 6F 6E 79 6D 6F 75 73 0D 0A USER anonymous..

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, we can find out if a packet contains data of a length larger than, smaller than, or equal to a certain number. alert ip any any -> 192.168.1.0/24 any (dsize: >\ 6000; msg: "Large size IP packet detected";)

Sample rule: alert icmp any any -> 192. 168. 5 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

The icmp_id Keyword icmp_id: <ICMP_id_number> The icmp_id option is used to detect a particular ID used with ICMP packet. The general format for using this keyword is as follows: icmp_id: <ICMP_id_number>

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. 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.37105 192.168.143.15 ->192.168.5.16 ICMP TTL:64 TOS:0x0 ID:00

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: Sample rule: alert udp any any -> 192.168.5.0/24 31335 \ (msg: "trinoo port"; logto: "DDoS";) This rule will log all ICMP packets having TTL value equal to 100 to file logto_log.

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

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. alert ip any any -> any any (msg: "Loose source routing attempt"; priority: 10;)

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. alert ip any any -> any any (msg: "Loose source routing attempt"; rev: 2;)

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;)

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: <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 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

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. The general format of the keyword is as follows: ttl: 100;

Format: ttl: <number>; Sample rule: alert udp any any -> 192 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

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.

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

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 ******** Seq: 0x1CED3E2E Ack: 0x0 Win: 0x1000 TCP Options => WS: 10 NOP MSS: 265 TS: 1061109567 0 EOL EOL

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. 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.

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

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[**] 04/25-05:28:28.146374 192.168.143.15:3487 -> 192.168.143.16:21 TCP TTL:64 TOS:0x10 ID:30637 DF ***AP*** Seq: 0xE1977C8D Ack: 0x452F7F9 Win:0x7D78 TCP Options => NOP NOP TS: 118248207 33775174 43 57 44 20 57 61 52 65 5A 0D 0A CWD WaReZ..

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.

Format: regex; Sample rule: log tcp any any -> 192. 168. 5 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 TCP TTL:64 TOS:0x0 ID:63821 IpLen:20 DgmLen:60 ***AP*** Seq: 0x32A77D55 Ack: 0x0 Win: 0x200 TcpLen: 20 2F 62 69 6E 2F 63 73 68 0A 00 00 00 00 00 00 00 /bin/csh........ 00 00 00 00

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.

Format: session: [printable|all] Sample rule: log tcp any any <> 192.168.5.0/24 21 (session: printable;)

Sample output: 220 linux2 FTP server (Version wu-2. 5 Sample output: 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 Goodbye

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. Format: tag: <type>, <count>, <metric>, [direction]

type. What traffic to record. count. Number of units specified by metric. metric. Number of packets/seconds to record. direction. Used only with "host" type to indicate host to tag.

Sample rule: alert tcp any any -> any 21 (msg: "FTP passwd access"; flags: A+; \ content: "passwd"; tag: session, 10, packets;) Sample output: [**] FTP passwd access [**] 03/21-20:31:05.610035 10.10.10.101:1454 -> 10.10.10.100:21 TCP TTL:128 TOS:0x0 ID:50697 IpLen:20 DgmLen:58 DF ***AP*** Seq: 0x17806739 Ack: 0x121C07E5 Win: 0x1FD3 TcpLen: 20

Writing Good Rules Use A message part using the msg keyword. Use Rule classification, using the classification keyword. Use a number to identify a rule with the help of the id keyword. Always use the rev keyword in rules to keep a record of different rule versions.