Category list

Snort Rules

The rules Snort uses are at the heart of its IDS functionality. This section explores the nature of these rules, considerations related to the ordering of rules, and how to write rules.

The Nature of Snort Rules

Among the many types of rules are those for FTP and web attacks, distributed DoS attacks, attempts to exploit weaknesses in the Server Message Block (SMB) protocol in Windows systems, and Remote Procedure Call (RPC) attacks. Each rule corresponds to a number, a Sensor ID (SID) that enables everyone to distinguish one from another easily. For example, the following code listing shows the rule for the Apache web server chunked-encoding memory-corruption vulnerability exploit. When processing requests coded with a type of encoding mechanism called the “chunked encoding” mechanism, Apache incorrectly determines buffer sizes needed. Consequently, specially formulated input from a malicious browser can cause a buffer overflow that could result in the execution of rogue code on an Apache server. Note, the signature is in the second through fifth lines. The Common Vulnerabilities and Exposures (CVE)—see http://www.cve.mitre.org) numbers (both of which start with CAN) are in the eighth and ninth lines. The SID for this attack is 1807, as an inspection of line 9 shows.

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS \


(msg:"WEB-MISC Transfer-Encoding\: chunked"; \


flow:to_server,established;\


content:"Transfer-Encoding\:"; nocase; \


content:"chunked"; nocase; \


classtype:web-application-attack; \


reference:bugtraq,4474; \


reference:cve,CAN-2002-0079; reference:bugtraq,5033; \


reference:cve,CAN-2002-0392; sid:1807; rev:1;)

Over time, the number of available rules has increased substantially as more exploitation methods have been developed. As a result, Snort’s rules have become organized on the basis of type of rule, with related rules having SIDs within a certain numerical range. For example, the NetBIOS attack rules currently have sequentially numbered SIDs 529 through 539 (and a few others not within this range), as do telnet attack rules (which currently have SIDs 709 through 714, plus a few others outside this range). Anyone who deploys Snort can choose to use all the rules or can select only a subset of all the rules. Using all the rules results in a more complete detection capability, but at the disadvantage of slower performance. The more rules Snort must find and test, the slower Snort works. On the other hand, someone might want to use Snort for a special purpose, such as detecting only attacks directed at Windows systems. In this case, you might want to include only NetBIOS, MS-SQL, virus, web-IIS, and a few other rules.

Note

One potential problem with a signature and rule-based intrusion detection system is keeping signatures and rules current. Snort goes a long way in solving this problem by supporting the most recent rules only on the most current version. For example, the most recent rules work only on Snort 2.0, the most recent version at press time.

Rule Order

The Snort 2.0 detection engine examines five rule chains: Activation, Dynamic, Alert, Pass, and Log (as shown in Figure 10-2). By default, Activation rules (which generate an alert, and then activate some other dynamic rule) are applied first, and then Dynamic rules (which cause a packet to be logged when they’re triggered by an Activation rule), and then Alert rules (which issue an alert, and then log a packet), followed by Pass rules (used for ignoring certain kinds of packets, such as traffic from DNS servers, as well as to cause the use of the bpf filter language when Snort starts), followed by Log rules (which cause a packet to be logged, but without any alert). The ordering of any rule chain can easily be modified, however. To start Snort with full logging only (as indicated by the –l flag) and also to have Snort read the default configuration file for applying rules, enter the following:

./snort -l ./log -c snort.conf

Figure 10-2: Snort’s default order of applying rule chains

The –l flag means to use full logging and the ./log argument means to log to a file named log in the current directory. The –c flag means to read Snort’s default configuration file, which is snort.conf.

In Snort 1. x, if you want one rule applied before another, simply ensure the flag for that rule is to the left of the flag for another when you start Snort via the command line. In Snort 1. x, flags are always read and processed sequentially, left to right. Things are different in Snort 2.0, however. The rule-optimization mechanism in Snort takes apart the individual parts (flags, content requests, and so forth), and then creates an optimized list of rules that normally needs to be checked only once or, under unusual conditions, twice. The pattern-matching algorithm for content searching has also been changed to the Wu-Manber or Aho-Corasick algorithm (the choice is yours), resulting in much greater efficiency.

Once Snort 2.0 has applied a rule chain, it goes to the Rule Tree Nodes, further protocol-specific rules to be applied. The Rule Tree Nodes analyze TCP, UDP, ICMP, and IP traffic. Within each Rule Tree Node are options, one for Content, which results in a pattern-matching algorithm being applied to packet data and the other for Flow, which results in a detection plug-in being applied.

Writing Snort Rules

Another nice thing about Snort is that it is so extensible. Anyone who uses Snort can create custom rules that are not in the default rule set. Each rule consists of two parts: the rule header and rule option. The rule header contains the rule's action (alert, log, pass, activate, or dynamic, as discussed previously, or also custom for home-built rules), type of protocol, source and destination IP addresses, masks, and source and destination port. The rule option has the content of alert messages, as well as information concerning the portion of each packet that will be analyzed to decide if the action specified will be carried out. In the following example, if the signature (06 4a 05 42) for a Windows NET SEND message is found in a UDP packet, regardless of the particular source IP address, an alert labeled Windows messenger service message is issued.

alert udp any any -> 10.1.1.0/24 135 (content:" 06 4a 05 42" ; msg: "Windows messenger service message";)

Given all the possible variables that can be specified in each Snort rule, the number of potential rule options is mind-boggling.

Snort Filters

To help control the volume of traffic with which Snort must deal, Snort also provides filters. Filters control what data Snort does and does not dump. For example, if you wanted Snort to pick up all DNS-related traffic, UDP traffic destined for port 53, you could define the following filter: