The rule header contains the information that defines the who, where, and what of a packet, as well as what to do in the event that a packet with all the attributes indicated in the rule should show up. The first item in a rule is the rule action. The rule action tells Snort what to do when it finds a packet that matches the rule criteria. There are 5 available default actions in Snort, alert, log, pass, activate, and dynamic. In addition, if you are running Snort in inline mode, you have additional options which include drop, reject, and sdrop.
You can also define your own rule types and associate one or more output plugins with them. You can then use the rule types as actions in Snort rules.
This example will create a type that will log to just tcpdump:
ruletype suspicious { type log output log_tcpdump: suspicious.log }
This example will create a rule type that will log to syslog and tcpdump: database:
ruletype redalert { type alert output alert_syslog: LOG_AUTH LOG_ALERT output log_tcpdump: suspicious.log }
The next field in a rule is the protocol. There are four protocols that Snort currently analyzes for suspicious behavior - TCP, UDP, ICMP, and IP. In the future there may be more, such as ARP, IGRP, GRE, OSPF, RIP, IPX, etc.
The next portion of the rule header deals with the IP address and port information for a given rule. The keyword any may be used to define any address. Snort does not have a mechanism to provide host name lookup for the IP address fields in the config file. The addresses are formed by a straight numeric IP address and a CIDR[3] block. The CIDR block indicates the netmask that should be applied to the rule's address and any incoming packets that are tested against the rule. A CIDR block mask of /24 indicates a Class C network, /16 a Class B network, and /32 indicates a specific machine address. For example, the address/CIDR combination 192.168.1.0/24 would signify the block of addresses from 192.168.1.1 to 192.168.1.255. Any rule that used this designation for, say, the destination address would match on any address in that range. The CIDR designations give us a nice short-hand way to designate large address spaces with just a few characters.
In Figure , the source IP address was set to match for
any computer talking, and the destination address was set to match on the
192.168.1.0 Class C network.
There is an operator that can be applied to IP addresses, the negation
operator. This operator tells Snort to match any IP address except the one
indicated by the listed IP address. The negation operator is indicated with a
!. For example, an easy modification to the initial example is to make it alert
on any traffic that originates outside of the local net with the negation
operator as shown in Figure .
This rule's IP addresses indicate any tcp packet with a source IP address not originating from the internal network and a destination address on the internal network.
You may also specify lists of IP addresses. An IP list is specified by
enclosing a comma separated list of IP addresses and CIDR blocks within square
brackets. For the time being, the IP list may not include spaces between the
addresses. See Figure for an example of an IP list in
action.
Port numbers may be specified in a number of ways, including any ports, static
port definitions, ranges, and by negation. Any ports are a wildcard value,
meaning literally any port. Static ports are indicated by a single port number,
such as 111 for portmapper, 23 for telnet, or 80 for http, etc. Port ranges are
indicated with the range operator :. The range operator may be applied in a
number of ways to take on different meanings, such as in Figure .
Port negation is indicated by using the negation operator !. The negation
operator may be applied against any of the other rule types (except any, which
would translate to none, how Zen...). For example, if for some twisted reason
you wanted to log everything except the X Windows ports, you could do something
like the rule in Figure .
The direction operator -3#3 indicates the orientation, or direction, of the
traffic that the rule applies to. The IP address and port numbers on the left
side of the direction operator is considered to be the traffic coming from the
source host, and the address and port information on the right side of the
operator is the destination host. There is also a bidirectional operator, which
is indicated with a 13#13 symbol. This tells Snort to consider the address/port
pairs in either the source or destination orientation. This is handy for
recording/analyzing both sides of a conversation, such as telnet or POP3
sessions. An example of the bidirectional operator being used to record both
sides of a telnet session is shown in Figure .
Also, note that there is no 2#2- operator. In Snort versions before 1.8.7, the direction operator did not have proper error checking and many people used an invalid token. The reason the 2#2- does not exist is so that rules always read consistently.
Note:
Activate and Dynamic rules are being phased out in favor of a combination of
tagging (
|
Activate/dynamic rule pairs give Snort a powerful capability. You can now have one rule activate another when its action is performed for a set number of packets. This is very useful if you want to set Snort up to perform follow on recording when a specific rule goes off. Activate rules act just like alert rules, except they have a *required* option field: activates. Dynamic rules act just like log rules, but they have a different option field: activated_by. Dynamic rules have a second required field as well, count.
Activate rules are just like alerts but also tell Snort to add a rule when a specific network event occurs. Dynamic rules are just like log rules except are dynamically enabled when the activate rule id goes off.
Put 'em together and they look like Figure .
These rules tell Snort to alert when it detects an IMAP buffer overflow and collect the next 50 packets headed for port 143 coming from outside $HOME_NET headed to $HOME_NET. If the buffer overflow happened and was successful, there's a very good possibility that useful data will be contained within the next 50 (or whatever) packets going to that same service port on the network, so there's value in collecting those packets for later analysis.