The rules Snort uses are at the heart of its IDS functionality. This section explores the nature of these rules, considerations
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
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS \
(msg:"WEB-MISC Transfer-Encoding\: chunked"; \
content:"Transfer-Encoding\:"; nocase; \
content:"chunked"; nocase; \
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
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.
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.
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.
flags are always read and
Once Snort 2.0 has applied a rule chain, it goes to the Rule Tree Nodes, further
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
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
has the content of alert messages, as well as information concerning the portion of each packet that will be
alert udp any any -> 10.1.1.0/24 135 (content:" 06 4a 05 42" ; msg: "Windows messenger service message";)
Given all the possible
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:
udp and dst port 53
Then you would have to enter a command to activate this filter:
# tcpdump udp and dst port 53
The effect would be to examine a file that tcpdump