Snort from scratch (Part III): Writing Snort rules

Continuing with the posts about Snort Snort from scratch (part II), now we have a complete installation and web interface to monitor our network alerts. One of the most important things when you maintain an IDS like Snort in a network, is the include of new rules to alert of possible attacks, behaviors of Malware or simply the needed of control a part of our traffic for some reasons. The rules of Snort are very flexible and has a lot of possibilities of configuration, logically in this post I’ll do a short introduction to write basic rules explaining the components of a rule and some options that can be useful.
Anatomy of a rule
A Snort rule, basically is composed by the header (information about the traffic) and the options (contains some action to do on the packet).

• Headers is composed by:

Action Protocol Source IP Source Port Direction Operator Destination IP Destination Port (Options)
Action: Refers what snort will do when a packet match with the rule. Possible actions:
- alert: Generates an alert and register the packet.
- log: register the packet.
- pass: ignore the packet.
- activate: make an alert and next run other dynamic rule.
- dynamic: Remain inactive until an activate rule active them. Then will run as log action.
Protocol: We can use TCP, UDP, ICMP and IP protocols.
We can use the next syntax to refer an IP address or Port number:
- “!” : exclude the IP address or Port number for the rule.
- “172.16.0.0/16″: refers all the device from this network.
- “any”: refers any IP address or Port number.
- “:” : Refers a range of ports number.
- variables: We can use the variables declared in snort.conf like HOME_NET and EXTERNAL_NET.
Direction Operator: indicates the orientation of the packet for the apply of the rule. The possible operators:
- “->”: Indicates the source IP and port before the operator and after the destination.
- “<>“: Used to refer bidirectional traffic, Snort consider the pair IP and port numbers as source or destination.
Some examples of header rules
alert tcp any any -> 172.16.0.0/16 1:1023 : This rule will match with the attempts for tcp connection from any source to all the hosts in the network 172.16.0.0 to a port range from 1 to 1023.
log udp 10.0.0.0/8 :1024 -> 192.168.1.0/24 100: : Log all the UDP traffic from the network 10.0.0.0 with source port less than 1024 and destination for the network 192.168.1.0 with destination port greater than 100.
log tcp 192.168.1.0/24 any <> 192.168.1.1 22 : Log all the SSH requests from the network 192.168.1.0 to the host 192.168.1.1 and the SSH request from this host.

• Options: Contains the messages and information necessary for the decision of the alert. The different options are separated with the caracter “;”. Exists 4 main categories of options:

Meta-data: Provides some information about the rule. Posible metadata options can be:
- msg: Indicates a string message to print when the rule is matched.
- sid: identification for a single snort rule.
- rev: Used with the option id for reference a revision number for a rule.
- classtype: Defines the classification of a rule and is defined in the file configuration classification.config and is classified by a priority.
Payload: Refers to the “useful” data from the interior of a packet, usually is known the body of the data excluding the data overhead like the packet headers. Some possible options:
- content: This option allows a rule to search specific content in useful data of a packet. The pattern to search can be in text format or in binary mode written between the character pipe “|”, representing binary numbers like hexadecimal format.
- rawbytes: Allows a rule search in the packet data without any decodification from the preprocessor.
- depth: indicates the number of bytes that Snort will search on the payload.
Non-payload: Looks data in other parts of the packet different of the body data. Some options:
- dsize: Indicates the payload size in bytes.
- id: Is used to revise the ID field on the packet header. Some exploits or scanners specify this field.
- flags: Used to check if specific TCP flag bit is enabled, some useful flags are S (SYN), A (ACK), F (Finish).
Post-detection: This option is a trigger for a rule when this is activate.
Some Examples of Snort Rules

• Detecting when root user is trying to send an email:

1	alert tcp any any ->; 192.168.1.0/24 25 (sid:1002345;rev:2;msg: "root users attempts to send an email"; content: "mail from: root";classtype:suspicious-login;)

• Identifying the source of icmp traffic of a windows host:

- First of all I had to capture a icmp packet with tcpdump to see what’s the signature for a ping packet of a Windows host, and this is the capture that I received of data in Hexadecimal format:

alert icmp any any ->; 192.168.1.0/24 any (sid:1002356;msg:"Hey!! A windows Host is pinging me!";itype:8;content:"|6566 6768 696a 6b6c 6d6e 6f70 7172 7374 7576 7761 6263 6465 6667 6869|";nocase;depth:32;classtype:icmp-event;)

• Registering all access to the url /admin on the web server 192.168.1.250:

alert tcp any any ->; 192.168.1.250 80 (sid:1002354;rev:2;msg:"Warning!!, A host is trying to access /admin"; uricontent:"/admin";classtype:web-application-activity;)

• Alert all SMTP traffic that contains a file virus.exe attached:

alert tcp any any ->; 192.168.1.0/24 25 (sid:1002311; rev:3; msg:"Warning!! The virus.exe is included in one mail!!"; content:"filename="virus.exe"";classtype:suspicious-filename-detect;)

To add our rules in needed to include the new file in snort.conf file and restart snortd:

# vi /etc/snort/snort.conf include $RULE_PATH/test.rule

# /etc/init.d/snortd restart

• To see in more depth of write rules on Snort visit the official documentation: http://manual.snort.org/node27.html