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.
– “”: 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 -> 1:1023 : This rule will match with the attempts for tcp connection from any source to all the hosts in the network to a port range from 1 to 1023.

log udp :1024 -> 100: : Log all the UDP traffic from the network with source port less than 1024 and destination for the network with destination port greater than 100.

log tcp any <> 22 : Log all the SSH requests from the network to the host 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:
alert tcp any any ->; 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 ->; 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
alert tcp any any ->; 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 ->; 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
Snort from scratch (Part III): Writing Snort rules
Tagged on:     

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.


Get every new post delivered to your Inbox

Join other followers: