How the rules files are organized ?
Snort’s rules directory sorts hundreds of rules into rules files according to
their purpose. Although the rules are cataloged a few different ways and
some of the rule categories have overlapping domains, there’s certainly a
method to the madness.
Rules files fit into eight major categories:
ߜ Low-level protocols (icmp, netbios, tcp, udp)
ߜ High-level protocols (http, ftp, dns, pop3, imap)
ߜ Web server specific (web-attack, web-cgi, web-client)
ߜ Exploit specific (shellcode, backdoor, exploit)
ߜ Service impacting (dos, ddos)
ߜ Policy specific (policy, info, misc, porn)
ߜ Scanning and probing activities (scan, bad-traffic)
ߜ Viruses, worms, and other malware (virus)
The best way to find out how the whole rule system works is to get your
hands dirty with a typical example:
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:”WEB-IIS CodeRed v2 root.exe access”;flow:to_server,established;uricontent:”/root.exe”; nocase; classtype:web application-attack; reference:url,
www.cert.org/advisories/CA-2001 19.html; sid:1256; rev:7;)
This rule demonstrates many of the options that you’re likely to encounter
with your own setup. We picked the Code Red worm alert from the web-
iis.rules file as our starting point.
Here’s a piece-by-piece explanation of that Code Red worm rule, which
appeared earlier in this section:
ߜ The alert directive (in bold in the following alert snippet) tells Snort
that if the packet matches this rule, then the rule should send its output
through the alert facility.
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS
$HTTP_PORTS...
The overwhelming majority of Snort’s rules use the alert facility,
although optionally, you can use the log facility. Chapter 6 explains the
difference between these two facilities.
ߜ The tcp keyword is an argument that identifies which network protocols
the rule applies to. The following alert snipped shows the tcp keyword
in bold:
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS
$HTTP_PORTS...
Because the tcp keyword is specified, Snort knows to match this rule
only to network traffic using the TCP protocol (other protocols, such as
UDP) will be ignored.
ߜ The network source and destination arguments are highlighted in bold
in the following statement:
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS
$HTTP_PORTS...
The preceding network source and destination arguments (including
port numbers) tell Snort to alert on any traffic that is either
• From the $EXTERNAL_NET on any port
• To any of our Web servers on the defined Web ports.
The network source and destination arguments use the variables estab-
lished at the beginning of the snort.conf file (the arguments beginning
with the $). These substitutions provide convenience and readability for
managing a large collection of rules, which can easily top a few thousand
entries. The last part of the rule gets even more granular with information the
rule should match on, as well as what Snort should do if the rule does
match . The following snippet shows what this looks like:
(msg:”WEB-IIS CodeRed v2 root.exe access”; flow:to_server,established;
uricontent:”/root.exe”; nocase; classtype:web application-
attack; reference:url, www.cert.org/advisories/CA-2001-19.html;
sid:1256; rev:7;)
• A few other tests tucked away in that last section must be passed
before an alert is generated. The flow: and uricontent: keywords
further refine the rule. In this case, if the uricontent (URI stands for
universal resource identifier) contains the text “/root.exe”. The
flow says that the connection should be going to the server and
should already be established. IP listed in your var HTTP_SERVERS
section of snort.conf, then an alert is generated with the message
“WEB-IIS CodeRed v2 root.exe access”.
Snort also identifies the type of attack by classifying it as a “web
applications-attack.” It further identifies the exact nature of the
alert setting the “sid” (Snort IDentification) field to 1256. Sids are
unique identifiers to Snort. They can nail down an offense to exactly one
alert. The reference: keyword provides a log entry regarding any other
information that’s known about the nature of the attack. References are
often URLs to security-related Web sites, such as CERT, Whitehats, or
SecurityFocus, which provide advisories on what the attack is and how
to patch for it (if possible). In our Code Red example, we point to the
CERT Web site with the following URL:
http://www.cert.org/advisories/CA-2001-19.html
Figure 8-1 shows a graphical overview of how a Snort rule is laid out. In it,
you see many of the bits and pieces of a rule.
Flow or direction operators represent how traffic is traversing the network.
Their use is pretty straightforward:
ߜ The > operator tells Snort that the network on the left should be regarded
as the source, and the one on the right should be the destination.
There isn’t a <- operator. All instances using it are written by flip-
flopping the arguments around the > command.
ߜ The <> operator will match any traffic between the network on the left
and the network on the right, regardless of which network originated the
traffic.
The directionless operator (<>) can sometimes cause a bit of confusion
with its use. It seems to makes sense that you would inspect traffic flowing
both ways from one computer or network to another, but that inspection
happens infrequently. Most Snort rules look something like this:
$EXTERNAL_NET any -> (internal host / port)
A rule that matches too broadly (which the preceding rule would do if it
contained <>) produces a huge Snort log and unduly burdens the pro-
cessing engine as it inspects everything that passes by.
Elements of the rule header
Sifting through the directory of rules shows that all the rules contain header
information, though most have a jumble of different items in their bodies. The
header is just a front-end filter that separates out traffic by using five key sift-
ing factors: source IP address, destination IP address, source port, destination
port, and protocol.
Rule actions
Snort comes built-in with five different rule actions. Each gives you a lot of
power in building your arsenal.
Before changing the default behavior of your Snort rules, spend some time
watching it operate in your environment and use its output to help you
reduce noisy false positives.
Here are Snort’s five rule actions:
ߜ The log action merely logs the offending packets to the output logging
that we set up when the Snort sensor was configured. The output plug-
ins options are many and varied, giving you a rich set of choices. A per-
rule log directive lets you customize logging down to a remarkable level.
ߜ The alert action can print a log entry and post a notification when
some event is associated with a higher priority and probably needs a
personal touch.
The alert action is the default action for most rules that come with
Snort. Snort’s job, after all, is to alert us of an attack on our network!
ߜ The pass action can ignore a matched packet and continue processing.
The pass action is useful when you’re tuning your rules and need to dis-
able some of the noisier ones so that you can actually see the output of
what you’re working with.
ߜ The most powerful of the Snort actions is the activate keyword.
Activate operates in concert with the dynamic action by triggering an
alert and running what’s specified by the associated dynamic rule.
The activate/dynamic pair is ideal for catching a complex series of
attacks that may otherwise go unnoticed.
ߜ The dynamic action is associated with a rule that shouldn’t run until
another event is encountered. You combine the dynamic action with
the activate action to set up a second level of processing in certain
circumstances.
The activate/dynamic pair isn’t often used in common Snort setups,
but it can be a handy tool for advanced intrusion detection.
Protocols
Snort, as a network IDS, must operate on the lowest level of the network to
do its job. Snort grabs Ethernet frames directly from the wire. Inside of those
frames are the four protocols that the free version of Snort normally scans: IP,
ICMP, TCP, and UDP.
Snort’s developers are attempting include other protocols, such as HTTP,
802.11, and ARP. The keywords for building your rules should include only
one of the original four.
For example, let’s say employees aren’t allowed to use the eBay auction Web
site on the job. A particular employee has been reprimanded for spending
hours browsing eBay, and HR wants to monitor his behavior. The following
rule logs all Web traffic that contains ebay.com coming from the host
192.168.1.18 with the message eBaying:
log tcp 192.168.1.18/32 any -> any 80 (msg:”eBaying”; uricontent:”ebay.com”;)
Source/destination
The last part of a well-formed Snort rule is probably the most important
piece of configuration data: The two IP address ranges that are involved with
the communication. The source and destination networks are identified in a
rule that takes this form:
(source network) (port) -> (destination network) (port)
CIDR (Classless Inter Domain Routing) notation is used for the network argu-
ments. CIDR notation is that funny way of expressing an IP address using a /
and another number — for example, 10.35.24.0/24, which means a Class C
network of 254 hosts on network 10.35.24.0 (plus the first and last
addresses that are reserved for the network address and the broadcast
address, namely 10.35.24.0 and 10.35.24.255).
For the Snort rules files, you really deal with only two types of entries:
ߜ Networks (which contain a /)
ߜ Hosts (which omit /)
Omitting / is a shorthand way of saying, “Just the single IP address, if
you please.” For example, the address 10.35.24.66 indicates just one
host for matching against.
You can also enter ranges of port numbers, similar to ranges of IP addresses.
Most of the examples that we cover in this chapter are single ports, such as
80 for the Web port, 443 for the encrypted Web port, and 25 for sendmail.
The entire range of available ports extends from 0 to 65535.
For a range of ports, you just place a colon between the two ports. The fol-
lowing rule looks for any traffic containing “ebay.com” occuring on any TCP
port between 1 and 1023.
log tcp 192.168.1.18/32 any -> any 1:1023 (msg:”eBaying”;
uricontent:”ebay.com”;)
You can also include the maximum and minimum ports ranges by simply
leaving off a number. For example :1023 means a range of ports from 0–1023,
and 1024: refers to a range of 1024–65535.
Wildcards
Wildcards simplify rules. Wildcards work just like those “splat” asterisks that
you can type into a DOS window or Unix shell to list only certain files. In
Snort, the any keyword is the most powerful wildcard — and it’s all over the
place. You’re allowed to use the any wildcard in both the network and port
configurations: any matches everything for the category you placed it in.
In the preceding section, we used the any wildcard in a couple of places. When
the host 192.168.1.18 tries to start a communication on any port with any
host on ports 1–1023 with the text “ebay.com” as part of a URI, then . . . bingo!
That’s a match, and the message eBaying appears in the logs.
Elements of the rule body
After being mangled by the pre-processors and whittled down by the filters of
the rule’s header, the rule’s body contains a virtual cornucopia of tests.
The most powerful test is pattern-matching what slips through for either spe-
cific keywords, phrases, or strings of binary data. Often, this inspection is the
most critical, because what’s being searched for is the “fingerprint” of the
attack itself.
Many of the most powerful features of Snort’s detection engine reside in the
body of the rule. Each feature has a different style, syntax, and set of options.
This flexibility can make rule management somewhat complicated, but very
worthwhile.
The layout of the rule body
Snort’s rule body must follow this specific structure:
ߜ The body section of a rule is always wrapped by one set of parentheses.
ߜ Body options (keywords, instructions, tests, and commands) are within
the parentheses.
ߜ Each body option is separated by a semicolon.
ߜ Each body option usually conforms to this format (the value is wrapped
in double quotes):
item: “value”;
ߜ The entire line is terminated with a semicolon.
While the structure contains a lot of punctuation, it helps keeps things
straight for both Snort and the person managing it.
The “content” option
Content analysis flushes out specific attack signatures within the packet. The
particulars of the content option is applied to each and every packet that
matches the header of the rule and can be expressed in either plain text form
(ASCII) or geek-speak (Hexadecimal).
Worms, viruses, and server cracks are normally transmitted onto your network
as raw machine code, which, to the naked eye, looks like gobbledy-gook, but is
in fact a series of instructions that harm your computers and servers.
Content matching is typically done at the application layer (Layer 7) of the
OSI networking model.
Text content matching (ASCII)
As a simple scenario for demonstration purposes, let’s say you’re concerned
about employees trading computer hacking information within your organiza-
tion. You can create a rule that generates an alert whenever an e-mail is sent
to your primary mail server (the mail server’s IP address is 172.16.30.7)
containing the word “hacking”. The mail port is 25; most mail is transmitted
using the TCP protocol, so the following rule illustrates how we can use the
content keyword to craft a rule to meet our goal.
alert tcp $EXTERNAL_NET any -> 172.16.30.7 25 (msg:”Found hacking reference in
e-mail”; content:”hacking”;)
Content analysis (by either text or hexadecimal matching) is used in more
than two-thirds of the rules that come with Snort.
Hexadecimal content matching
Hexadecimal (hex) content, although expressed differently than ASCII text, is
ultimately treated the same as ASCII by the Snort processing engine. In both
cases, the text is reduced to what the computer deals with best: bits, which is
then matched against the data streaming across your network. Hex is just a
shorthand way of representing the zeros and ones of binary machine code.
Hexadecimal is like a numerical alphabet that is 16 characters long, as com-
pared with English (which has 26 letters) or decimal math (which has 10
numerals). Hexadecimal is often referred to as base-16 because the “alpha-
bet” it uses has only 16 “letters” (0,1,2,3,4,5,6,7,8,9,A,B,C,D,E,F). Hexadecimal
strings entered into a Snort rule body contain only those characters and
none others. If you create a hexadecimal string with nonhex characters,
expect that Snort will turn up its nose.
Here’s a real example right out of the rules directory:
alert tcp $EXTERNAL_NET any -> $HOME_NET 22 (msg:”EXPLOIT ssh CRC32 overflow
filler”; flow:to_server,established; content:”|00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00|”; reference:bugtraq,2347;
reference:cve,CVE-2001-0144; classtype:shellcode-detect; sid:1325;
rev:3;)
To use a hex match for content searching, wrap the hexadecimal characters
to find with the pipe symbols (|). White space can separate out single bytes
of hexadecimal data (“00 00”). Snort ignores the white space, which is only
there to preserve the readability to the rule crafter.
The preceding rule is meant to watch for an attempted exploitation of the
Secure Shell server application (sshd) by scanning traffic coming from any-
where on the external network and destined for your home network on port
22 (the sshd port). The content search is a long series of binary zeros (18
sets of two, to be exact). How can a pattern of zeros be unique? A pattern of
zeros is frequently found in attack code and is often a give-away that some-
one is doing something you don’t like.
Mixing it up
You can mix and match the style of content searching without confusing
Snort. As long as the binary data you want to search for has the bookends of
the pipe characters, that block of text can be intermingled with other, plain
ASCII text. What follows is a good example from the back-door.rules file.
alert tcp $EXTERNAL_NET any -> $HOME_NET 12345:12346 (msg:”BACKDOOR netbus get-
info”; flow:to_server,established; content:”GetInfo|0d|”; refer-
ence:arachnids,403; classtype:misc-activity; sid:110; rev:3;)
Notice how the content search string is constructed: GetInfo|0d|. This
string tells Snort’s pattern matching subsystem to watch for the text phrase
GetInfo with a carriage return at the end. Pretty nifty, eh? Inserting hex into
a plain text string is useful for representing characters that can’t be repre-
sented by plain text, such as a carriage return. You can drift between text and
binary content all within the same search string.
The “depth” option
It would be nice if malicious content always occurred at the beginning or end
of a packet. Unfortunately, malicious content can occur almost anywhere in a
packet. The depth option specifies how many bytes into a packet the Snort
processor should look before moving on to the next rule.
The main reason for using the depth option is to restrict the search to the
most likely places where a match is found, without wasting valuable proces-
sor resources to search the entire packet. For example, if you want to find the
HTTP protocol version as part of a Web site communication, look in the first
few hundred bytes. Because a packet may be as large as 1,500 bytes (less the
header overhead), it makes a lot of sense to give Snort a break, especially if
what it must look through are millions upon millions of packets.
The following rule from the web-misc.rules file reveals that you need only
15 bytes to catch the sadmind worm. Hence, the content GET x http/1.0 is
always encountered at the very beginning of the packet.
web-misc.rules:alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS
(msg:”WEB-MISC sadmind worm access”; flow:to_server,established;
content:”GET x HTTP/1.0”; offset:0; depth:15; classtype:attempted-
recon; reference:url,www.cert.org/advisories/CA-2001-11.html;
sid:1375; rev:5;)
The “nocase” option
The nocase option, which appears in more than a third of the rules that ship
with Snort, basically says to ignore the case of the characters submitted for
searching. Because the nocase directive takes no arguments, it’s normally
just used with a terminating semicolon. The following example from the
info.rules file finds the text LOGIN FAILED or LoGIn FaIlEd on a telnet
session port.
alert tcp $HOME_NET 23 -> $EXTERNAL_NET any (msg:”INFO TELNET Bad Login”; con-
tent: “Login failed”; nocase; flow:from_server,established;
classtype:bad-unknown; sid:492; rev:6;)
The “offset” option
Another tool that gives us a more precise scope on where in the packet to
look is the offset option. Offset works by skipping over the number of bytes
supplied to the right of the colon. So, offset:90 skips the first 90 bytes of
the packet and then begins searching for the string given as part of the con-
tent keyword. Offset and depth work nicely together to make the search area
of a packet limited to a window that is bracketed by the two. Basically, if you
know where to look and what to look for, you can use these two options to
help Snort get a fast grip on where to spend its time.
The Uniform Resource Identifier (URI) option
You can use the uricontent option to conduct a similar type of content
searching. Its purpose is similar to the depth and offset options: to reduce
the overall processing burden on Snort as it watches for more attacks to
effectively do its job.
The uricontent option works much like the content one, except it restricts
its searching to only URIs in the payload of the packet. URIs (Uniform
Resource Identifiers) in Snort can specify other protocols than http, such as
ftp, gopher, rsync, and https.
The uricontent option only searches for the given text in URIs that is found
in the packet. If URIs aren’t present, no match occurs. URI searching is good
for catching malicious commands that are readily evident as they often
appear in the location request to a Web server. The following rule from the
web-iis.rules file shows an exploit attempt against the IIS server using
both content and uricontent analysis:
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:”WEB-IIS .asa HTTP
header buffer overflow attempt”; flow:to_server,established; con-
tent:”HTTP|2F|”; nocase; uricontent:”.asa”; nocase;
content:”|3A|”; content:”|0A|”; content:”|00|”; reference:bug-
traq,4476; classtype:web-application-attack; sid:1802; rev:4;)
A couple of interesting characteristics about this rule are worth discussing:
ߜ When nocase follows a string, its effect is upon the content string
immediately prior.
ߜ The nocase option has no effect upon binary search strings. Leaving it
off of those strings just helps the overall flow of the rule.
Classification
The classification options provide an overall description of a rule, along with
other helpful information about the rule, that can be used by the Snort pro-
gram itself and a system administrator. These options include the Snort ID,
the alert message to appear in the alert log, the rule revision number, the
alert priority, the alert classification, and external references for the exploit
or vulnerability that triggered the alert.
Snort IDs
Quite a few options help organize and classify detected alerts. The Snort ID
(sid) option is unique to the Snort system and a good way to get a handle on
classifications.
The format of the Snort ID value is the same as it as other classification
options. For example, a proper usage is as follows:
sid:;
When you get the hang of building your own sets of rules, assign each custom
rule a unique sid number somewhere above the 1,000,000 mark. That way,
updates to the Snort rule base won’t accidentally collide with your custom
rule. Table 8-1 gives you a breakdown of the uses for sid ranges.
default level and rate how important or impacting a particular rule is to your
unique environment. For example, the following command assigns the rule
associated with it the highest priority: 1.
priority:1;
Classtype
The classtype option can organize rules into major groups. A few dozen differ-
ent classification types are spread over three priority levels, which are
described in Tables 8-2, 8-3 and 8-4. For inclusion in a rule, the syntax is
classtype:;
Table 8-2 Priority 1 Classifications (Critical Severity)
classtype Description
Attempted privilege escalation to an
attempted-admin
Administrator level
Attempted privilege escalation to a User level
attempted-user
Discovered executable code
shellcode-detect
Achieved successful privilege escalation to an
successful-admin
Administrator level
Achieved successful privilege escalation to a
successful-user
User level
Discovered software code of a Trojan Network
trojan-activity
Attack
Failed privilege escalation to a User level
unsuccessful-user
Identified an attack upon a Web server’s appli-
web application attack
cation software
Table 8-3 Priority 2 Classifications (Intermediate Severity)
classtype Description
Attempted denial-of-service attack
attempted-dos
Attempted information collection
attempted-recon
(reconnaissance)
Potentially bad traffic seen (malformed)
bad-unknown
Denial-of-service attack possibly underway
denial-of-service
A catch-all category
misc-attack
Detection or use of a nonstandard protocol
non-standard-protocol
Portmap decode detected
rpc-portmap-decode
Denial of service detected
successful-dos
Large-scale information collection
successful –recon-
(reconnaissance)
largescale
Limited information collection (reconnaissance)
successful –recon-
limited
Strange or unusual filename was detected
suspicious-filename-
detect
Strange username was found attempting to
suspicious-login
login
System call was detected
suspicious-call-detect
A client was abnormally using a network port
unusual-client-port-
connection
Access was made to a potentially vulnerable
web-application-
web-app
activity
Table 8-4 Priority 3 Classifications (Low Severity)
classtype Description
A “ping” packet was detected
icmp-event
Some behavior was detected that may be
misc-activity
considered a policy warning
A host or network was being scanned
network-scan
Regular usage activity was detected
non-suspicious
A protocol instruction was decoded
protocol-command-decode
A pattern of specific bytes was detected
string-detect
Unknown or unclassified traffic
unknownRevision and versions
The Snort people thought ahead and even included a way to keep a version
tracking on each individual rule. The software industry uses many version
management schemes because the field is so fluid and so dynamic that tight
change control is almost a necessity. The format of the option is
rev:<#>;
Very few rules that come with Snort (less than 10 percent) have a revision
number of only 1. Busy enterprise networks are sometimes hostile and fast-
paced environments. Sometimes, rules are quickly added during the heat of a
malicious event so that immediate visibility is provided to the security man-
agers who must monitor the attack. After some analysis and a firmer under-
standing of the events takes shape, Snort’s rules are then revised (often only
subtly) to reflect what’s known about the event.
Messaging and output
The mesg option creates a customized output message that can be included
with any logs, alerts, and data dumps processed by the detection engine. By
looking through the rules directory, you can see that the fabricators of the
rules file have added messages to almost all the entries that they include.
The following is an example of the format of the mesg directive in use:
alert tcp $EXTERNAL_NET any -> $SMTP_SERVERS 25 (msg:”SMTP sendmail 5.5.5
exploit”; flow:to_server,established; content:”mail
from|3a20227c|”; nocase; reference:arachnids,119;
classtype:attempted-admin; sid:662; rev:4;)
See how cleverly the Snort makers had the output of this mail exploit attempt
reported as “SMTP sendmail 5.5.5 exploit”? Describing the nature of an attack
in plain English helps you in the long run (especially when you’re searching
through logs at trying to track down a breach).
External references
The second most powerful (and widely used) feature within a Snort rule is
the external reference option. You can reference Web-based resources that
provide you with tons of additional data on an attack or probe right in the
Snort logs.
A few different formats are used. Nearly all are Web site front-ends that look
up an attack based on a unique identifier. For example, using the example in
the preceding section, we find the following: reference:arachnids,119;
Thanks to this command, when Snort encounters this Sendmail attack, it pro-
vides a URL where the user can find out more about the Sendmail attack.
Table 8-5 gives a list of Snort’s external references.
Keyword URL Base
bugtraq http://www.securityfocus.com/bid/
cve http://cve.mitre.org/cgi-bin/cvename.cgi?name=
arachNIDS http://www.whitehats.com/info/IDS
McAfee http://vil.nai.com/vil/content/v_
Nessus http://cgi.nessus.org/plugins/dump.php3?id=
url http:// (a general URL that’s passed straight through)
Proper use of the external keyword takes this form:
Reference:
You can tie together any number of reference options as long as they’re sepa-
rated by a semicolon.
Advanced options and deep dark secrets
The advanced options give you a peek into the dark side: the stuff of the
geek-chic and the wizards of computer security.
Flow control
The flow control option lets you define the direction of a network stream. All
network communications have two endpoints and a direction, so Snort can
be configured to alert whenever one of many other triggers is tripped. Snort’s
internal engine must do some fancier processing for the flow control (includ-
ing some on-the-fly packet reconstruction), but it’s certainly worth the over-
head because it lets you know whether an attack actually worked or not.
Regular expressions
A regular expression (regex in computer-nerd circles) is the incredibly power-
ful voodoo of using wildcards to match substrings within other strings.
Without jumping into the deep end of this black art, a regular expression
combined with a Snort rule makes for powerful mojo!
Protocol options
Because of Snort’s primary function to act as a low-level packet trap and fil-
tering device, it can make lots of specific selections based on granular net-
work protocol components. For example, sometimes hackers use specialized
or fragmented packets to tease at the edge of networks for information about
what they may find if they break in. These probing and recon expeditions
may otherwise go unnoticed by a system administrator or a security package
not configured to watch for such errant behavior. Snort’s native IP rules
options put a huge amount of power at your fingertips.
How does Snort deal with all those rules?
Managing the files and their contents, let alone keeping a huge decision tree
running, is a fine programmatic accomplishment.
Snort keeps track of all those intricate rules (some with more than 20 differ-
ent options) with some fancy data processing internally. Without getting too
bogged down, the process of reading in a particular rule is governed by a
string parser, which cuts apart the rule into its component parts, which are
then stored into a series of linked lists.
Snort is a busy, complex, and low-level application. Every small or subtle
error that goes undetected or that causes minor annoyances can snowball
into a huge performance issue under certain circumstances. Although it
doesn’t happen often, a misplaced command or configuration option can
cause downtime or data loss.
Rule Refinements
This section is the fun part of tweaking specific rules to match your environ-
ment. We recommend a regular strategy of nosing through your Snort output.
As time passes, the composition of your network changes, and the minefield
of vulnerabilities expands.
Trimming the fat
Likely the first refinement that any IDS guru recommends, almost to the point
of being a broken record, is to reduce your false positives by stripping the
dead wood from your rules files.
We recommend that you sit down with a map of your network and a list of
your network connected assets (operating systems and exposed services are
the most critical) and build a table of your computer resources that can be
attacked. From there you comment out those rules that just don’t matter. If
you have ten Windows NT servers running MS Project Server and nothing
else, there’s little need for a thousand Linux/Unix rules.
Commenting out unneeded rules is a simple matter: Just edit the file contain-
ing the rule and place a “#” before the first character of the rule type (gener-
ally “alert”).
Chapter 9 includes more tuning methods that reduce false positives and the
reasons why removing the extra noise keeps your Snort a-snorting.
Making adjustments
Small changes to the rules files of your setup can keep your Snort installation
running at peak efficiency. By refining the rules that you are already running
with Snort, you generate better reports, waste less time reviewing them, and
react faster.
Before editing any Snort rule file, it’s highly recommended that you do the
following:
ߜ Always make a backup of that rule file.
ߜ Make sure that you use a plain text editor that doesn’t add any funky for-
matting or characters when you save the file. The vi program in Linux
and Notepad in Windows are good examples.
Start by finding a rule that can use some tweaking. Maybe this DNS rule was
misclassed:
alert udp $EXTERNAL_NET 53 -> $HOME_NET any (msg:”DNS SPOOF query response PTR
with TTL\: 1 min. and no authority”; con-
tent:”|85800001000100000000|”;
content:”|c00c000c00010000003c000f|”; classtype:bad-unknown;
sid:253; rev:2;)
Out of the box, it’s classified as a “bad-unknown” alert. Maybe it should be
reclassified as a reconnaissance or information probe, consistent with an
“attempted-recon” tag. To change the rule, just edit the dns.rules (the file
that contains the rule we’re modifying) and change it to something like
alert udp $EXTERNAL_NET 53 -> $HOME_NET any (msg:”DNS SPOOF query response PTR
with TTL\: 1 min. and no authority”; con-
tent:”|85800001000100000000|”;
content:”|c00c000c00010000003c000f|”; classtype:attempted-recon;
sid:253; rev:3;)
We bumped up the revision number to 3 so that another person can see that
something’s changed.
If you plan on making lots of changes to the base rules that come with Snort,
keep a local backup copy of the original version outside of the directory that
Snort uses to manage its configuration. If you upgrade Snort without keeping
copies of all your custom tweaking, you may accidentally overwrite the
whole lot with one punch of the enter key!
Building a rule from whole cloth
In some cases, a new rule is needed. Situations that might require a new rule
include:
ߜ Some sort of odd behavior on the network has been noticed: Maybe an
abnormal amount of data is transferred on the network after hours, or a
particular server is rebooting for no apparent reason. An investigation
begins to determine what these oddities mean, and based on captured
network data, you can create a rule that matches the odd event.
ߜ A new attack hits the Internet. There are no existing Snort rules that
match the attack, so you decide to create a rule on your own.
For almost all configurations, the standard set of rules (if regularly updated)
can be just what the doctor ordered. The need to build a whole rule from
scratch isn’t an everyday occurrence.
Here’s a real-world situation that we can use as an example. While on-site at a
customer’s facility, we heard that its network was acting irrationally and that
the customer needed our help in isolating the cause of it. After an hour of
tracking back a huge amount of network bandwidth coming from two work-
station computers, we found that they were infected with some sort of virus.
We diagnosed a virus by running a packet sniffer and capturing all of those
workstations’ network communications.
All of that techno-sleuthing work we did can be best summarized into a
packet capture, or at least a fair approximation of one. What follows is a snip-
pet of what we were looking at:
15:30:05.000913 10.3.232.38.1522 > 192.168.4.81.1434: udp 376
0x0000 4500 0194 bec2 0000 6d11 d406 d963 055d E.......m....c.]
0x0010 d8ab 0224 1069 059a 0180 6b52 0401 0101 ...$.i....kR....
0x0020 0101 0101 0101 0101 0101 0101 0101 0101 ................
0x0030 0101 0101 0101 0101 0101 0101 0101 0101 ................
0x0040 0101 0101 0101 0101 0101 0101 0101 0101 ................
0x0050 0101 0101 0101 0101 0101 0101 0101 0101 ................
0x0060 0101 0101 0101 0101 0101 0101 0101 0101 ................
0x0070 0101 0101 0101 0101 0101 0101 01dc c9b0 ................
0x0080 42eb 0e01 0101 0101 0101 70ae 4201 70ae B.........p.B.p.
0x0090 4290 9090 9090 9090 9068 dcc9 b042 b801 B........h...B..
0x00a0 0101 0131 c9b1 1850 e2fd 3501 0101 0550 ...1...P..5....P
0x00b0 89e5 5168 2e64 6c6c 6865 6c33 3268 6b65 ..Qh.dllhel32hke
0x00c0 726e 5168 6f75 6e74 6869 636b 4368 4765 rnQhounthickChGe
0x00d0 7454 66b9 6c6c 5168 3332 2e64 6877 7332 tTf.llQh32.dhws2
0x00e0 5f66 b965 7451 6873 6f63 6b66 b974 6f51 _f.etQhsockf.toQ
0x00f0 6873 656e 64be 1810 ae42 8d45 d450 ff16 hsend....B.E.P..
0x0100 508d 45e0 508d 45f0 50ff 1650 be10 10ae P.E.P.E.P..P....
0x0110 428b 1e8b 033d 558b ec51 7405 be1c 10ae B....=U..Qt.....
0x0120 42ff 16ff d031 c951 5150 81f1 0301 049b B....1.QQP......
0x0130 81f1 0101 0101 518d 45cc 508b 45c0 50ff ......Q.E.P.E.P.
0x0140 166a 116a 026a 02ff d050 8d45 c450 8b45 .j.j.j...P.E.P.E
0x0150 c050 ff16 89c6 09db 81f3 3c61 d9ff 8b45 .P........ 192.168.4.81.1434: udp 376
Table 8-6 identifies the meaning of each of the preceding line’s component
elements.
Table 8-6 Components of Packet Trace
Description Value
Time packet was sent 15.30:05.000913
Source address 10.3.232.38
Description Value
Source port 1522
Destination address 192.168.4.81
Destination port 1434
Protocol UDP
Packet size (bytes) 376
All that’s needed from Table 8-6 are the protocol and the destination port.
The source IP address, source port, and destination IP address show up dif-
ferently when coming from and going to different systems. Remember, we’re
looking for new instances of this worm, not the infected systems we already
know about. Coupled with the signature that was scissored from that big
block of packet data, that’s the complete makings of a fledgling Snort rule. All
the pieces fit together like this:
alert udp $EXTERNAL_NET any -> $HOME_NET 1434 (msg:”New MSSQL Worm A-
Multiplyin’”; content:”|c050 ff16 89c6 09db 81f3 3c61 d9ff 8b45|”;
sid:1000001; rev:1;)
The preceding example highlights the following best-practices in creating a
Snort rule:
ߜ We followed the path of the good Snort administrator and made the
Snort ID equal to 1,000,000.
ߜ The revision is marked as 1, meaning that this attempt was our first at
drafting a rule to achieve the wanted results.
After testing, if our signature isn’t right or other elements need tweaking, we
can make the changes and increase the rev number to reflect the changes.
Snort’s rules directory sorts hundreds of rules into rules files according to
their purpose. Although the rules are cataloged a few different ways and
some of the rule categories have overlapping domains, there’s certainly a
method to the madness.
Rules files fit into eight major categories:
ߜ Low-level protocols (icmp, netbios, tcp, udp)
ߜ High-level protocols (http, ftp, dns, pop3, imap)
ߜ Web server specific (web-attack, web-cgi, web-client)
ߜ Exploit specific (shellcode, backdoor, exploit)
ߜ Service impacting (dos, ddos)
ߜ Policy specific (policy, info, misc, porn)
ߜ Scanning and probing activities (scan, bad-traffic)
ߜ Viruses, worms, and other malware (virus)
The best way to find out how the whole rule system works is to get your
hands dirty with a typical example:
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:”WEB-IIS CodeRed v2 root.exe access”;flow:to_server,established;uricontent:”/root.exe”; nocase; classtype:web application-attack; reference:url,
www.cert.org/advisories/CA-2001 19.html; sid:1256; rev:7;)
This rule demonstrates many of the options that you’re likely to encounter
with your own setup. We picked the Code Red worm alert from the web-
iis.rules file as our starting point.
Here’s a piece-by-piece explanation of that Code Red worm rule, which
appeared earlier in this section:
ߜ The alert directive (in bold in the following alert snippet) tells Snort
that if the packet matches this rule, then the rule should send its output
through the alert facility.
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS
$HTTP_PORTS...
The overwhelming majority of Snort’s rules use the alert facility,
although optionally, you can use the log facility. Chapter 6 explains the
difference between these two facilities.
ߜ The tcp keyword is an argument that identifies which network protocols
the rule applies to. The following alert snipped shows the tcp keyword
in bold:
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS
$HTTP_PORTS...
Because the tcp keyword is specified, Snort knows to match this rule
only to network traffic using the TCP protocol (other protocols, such as
UDP) will be ignored.
ߜ The network source and destination arguments are highlighted in bold
in the following statement:
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS
$HTTP_PORTS...
The preceding network source and destination arguments (including
port numbers) tell Snort to alert on any traffic that is either
• From the $EXTERNAL_NET on any port
• To any of our Web servers on the defined Web ports.
The network source and destination arguments use the variables estab-
lished at the beginning of the snort.conf file (the arguments beginning
with the $). These substitutions provide convenience and readability for
managing a large collection of rules, which can easily top a few thousand
entries. The last part of the rule gets even more granular with information the
rule should match on, as well as what Snort should do if the rule does
match . The following snippet shows what this looks like:
(msg:”WEB-IIS CodeRed v2 root.exe access”; flow:to_server,established;
uricontent:”/root.exe”; nocase; classtype:web application-
attack; reference:url, www.cert.org/advisories/CA-2001-19.html;
sid:1256; rev:7;)
• A few other tests tucked away in that last section must be passed
before an alert is generated. The flow: and uricontent: keywords
further refine the rule. In this case, if the uricontent (URI stands for
universal resource identifier) contains the text “/root.exe”. The
flow says that the connection should be going to the server and
should already be established. IP listed in your var HTTP_SERVERS
section of snort.conf, then an alert is generated with the message
“WEB-IIS CodeRed v2 root.exe access”.
Snort also identifies the type of attack by classifying it as a “web
applications-attack.” It further identifies the exact nature of the
alert setting the “sid” (Snort IDentification) field to 1256. Sids are
unique identifiers to Snort. They can nail down an offense to exactly one
alert. The reference: keyword provides a log entry regarding any other
information that’s known about the nature of the attack. References are
often URLs to security-related Web sites, such as CERT, Whitehats, or
SecurityFocus, which provide advisories on what the attack is and how
to patch for it (if possible). In our Code Red example, we point to the
CERT Web site with the following URL:
http://www.cert.org/advisories/CA-2001-19.html
Figure 8-1 shows a graphical overview of how a Snort rule is laid out. In it,
you see many of the bits and pieces of a rule.
Flow or direction operators represent how traffic is traversing the network.
Their use is pretty straightforward:
ߜ The > operator tells Snort that the network on the left should be regarded
as the source, and the one on the right should be the destination.
There isn’t a <- operator. All instances using it are written by flip-
flopping the arguments around the > command.
ߜ The <> operator will match any traffic between the network on the left
and the network on the right, regardless of which network originated the
traffic.
The directionless operator (<>) can sometimes cause a bit of confusion
with its use. It seems to makes sense that you would inspect traffic flowing
both ways from one computer or network to another, but that inspection
happens infrequently. Most Snort rules look something like this:
$EXTERNAL_NET any -> (internal host / port)
A rule that matches too broadly (which the preceding rule would do if it
contained <>) produces a huge Snort log and unduly burdens the pro-
cessing engine as it inspects everything that passes by.
Elements of the rule header
Sifting through the directory of rules shows that all the rules contain header
information, though most have a jumble of different items in their bodies. The
header is just a front-end filter that separates out traffic by using five key sift-
ing factors: source IP address, destination IP address, source port, destination
port, and protocol.
Rule actions
Snort comes built-in with five different rule actions. Each gives you a lot of
power in building your arsenal.
Before changing the default behavior of your Snort rules, spend some time
watching it operate in your environment and use its output to help you
reduce noisy false positives.
Here are Snort’s five rule actions:
ߜ The log action merely logs the offending packets to the output logging
that we set up when the Snort sensor was configured. The output plug-
ins options are many and varied, giving you a rich set of choices. A per-
rule log directive lets you customize logging down to a remarkable level.
ߜ The alert action can print a log entry and post a notification when
some event is associated with a higher priority and probably needs a
personal touch.
The alert action is the default action for most rules that come with
Snort. Snort’s job, after all, is to alert us of an attack on our network!
ߜ The pass action can ignore a matched packet and continue processing.
The pass action is useful when you’re tuning your rules and need to dis-
able some of the noisier ones so that you can actually see the output of
what you’re working with.
ߜ The most powerful of the Snort actions is the activate keyword.
Activate operates in concert with the dynamic action by triggering an
alert and running what’s specified by the associated dynamic rule.
The activate/dynamic pair is ideal for catching a complex series of
attacks that may otherwise go unnoticed.
ߜ The dynamic action is associated with a rule that shouldn’t run until
another event is encountered. You combine the dynamic action with
the activate action to set up a second level of processing in certain
circumstances.
The activate/dynamic pair isn’t often used in common Snort setups,
but it can be a handy tool for advanced intrusion detection.
Protocols
Snort, as a network IDS, must operate on the lowest level of the network to
do its job. Snort grabs Ethernet frames directly from the wire. Inside of those
frames are the four protocols that the free version of Snort normally scans: IP,
ICMP, TCP, and UDP.
Snort’s developers are attempting include other protocols, such as HTTP,
802.11, and ARP. The keywords for building your rules should include only
one of the original four.
For example, let’s say employees aren’t allowed to use the eBay auction Web
site on the job. A particular employee has been reprimanded for spending
hours browsing eBay, and HR wants to monitor his behavior. The following
rule logs all Web traffic that contains ebay.com coming from the host
192.168.1.18 with the message eBaying:
log tcp 192.168.1.18/32 any -> any 80 (msg:”eBaying”; uricontent:”ebay.com”;)
Source/destination
The last part of a well-formed Snort rule is probably the most important
piece of configuration data: The two IP address ranges that are involved with
the communication. The source and destination networks are identified in a
rule that takes this form:
(source network) (port) -> (destination network) (port)
CIDR (Classless Inter Domain Routing) notation is used for the network argu-
ments. CIDR notation is that funny way of expressing an IP address using a /
and another number — for example, 10.35.24.0/24, which means a Class C
network of 254 hosts on network 10.35.24.0 (plus the first and last
addresses that are reserved for the network address and the broadcast
address, namely 10.35.24.0 and 10.35.24.255).
For the Snort rules files, you really deal with only two types of entries:
ߜ Networks (which contain a /)
ߜ Hosts (which omit /)
Omitting / is a shorthand way of saying, “Just the single IP address, if
you please.” For example, the address 10.35.24.66 indicates just one
host for matching against.
You can also enter ranges of port numbers, similar to ranges of IP addresses.
Most of the examples that we cover in this chapter are single ports, such as
80 for the Web port, 443 for the encrypted Web port, and 25 for sendmail.
The entire range of available ports extends from 0 to 65535.
For a range of ports, you just place a colon between the two ports. The fol-
lowing rule looks for any traffic containing “ebay.com” occuring on any TCP
port between 1 and 1023.
log tcp 192.168.1.18/32 any -> any 1:1023 (msg:”eBaying”;
uricontent:”ebay.com”;)
You can also include the maximum and minimum ports ranges by simply
leaving off a number. For example :1023 means a range of ports from 0–1023,
and 1024: refers to a range of 1024–65535.
Wildcards
Wildcards simplify rules. Wildcards work just like those “splat” asterisks that
you can type into a DOS window or Unix shell to list only certain files. In
Snort, the any keyword is the most powerful wildcard — and it’s all over the
place. You’re allowed to use the any wildcard in both the network and port
configurations: any matches everything for the category you placed it in.
In the preceding section, we used the any wildcard in a couple of places. When
the host 192.168.1.18 tries to start a communication on any port with any
host on ports 1–1023 with the text “ebay.com” as part of a URI, then . . . bingo!
That’s a match, and the message eBaying appears in the logs.
Elements of the rule body
After being mangled by the pre-processors and whittled down by the filters of
the rule’s header, the rule’s body contains a virtual cornucopia of tests.
The most powerful test is pattern-matching what slips through for either spe-
cific keywords, phrases, or strings of binary data. Often, this inspection is the
most critical, because what’s being searched for is the “fingerprint” of the
attack itself.
Many of the most powerful features of Snort’s detection engine reside in the
body of the rule. Each feature has a different style, syntax, and set of options.
This flexibility can make rule management somewhat complicated, but very
worthwhile.
The layout of the rule body
Snort’s rule body must follow this specific structure:
ߜ The body section of a rule is always wrapped by one set of parentheses.
ߜ Body options (keywords, instructions, tests, and commands) are within
the parentheses.
ߜ Each body option is separated by a semicolon.
ߜ Each body option usually conforms to this format (the value is wrapped
in double quotes):
item: “value”;
ߜ The entire line is terminated with a semicolon.
While the structure contains a lot of punctuation, it helps keeps things
straight for both Snort and the person managing it.
The “content” option
Content analysis flushes out specific attack signatures within the packet. The
particulars of the content option is applied to each and every packet that
matches the header of the rule and can be expressed in either plain text form
(ASCII) or geek-speak (Hexadecimal).
Worms, viruses, and server cracks are normally transmitted onto your network
as raw machine code, which, to the naked eye, looks like gobbledy-gook, but is
in fact a series of instructions that harm your computers and servers.
Content matching is typically done at the application layer (Layer 7) of the
OSI networking model.
Text content matching (ASCII)
As a simple scenario for demonstration purposes, let’s say you’re concerned
about employees trading computer hacking information within your organiza-
tion. You can create a rule that generates an alert whenever an e-mail is sent
to your primary mail server (the mail server’s IP address is 172.16.30.7)
containing the word “hacking”. The mail port is 25; most mail is transmitted
using the TCP protocol, so the following rule illustrates how we can use the
content keyword to craft a rule to meet our goal.
alert tcp $EXTERNAL_NET any -> 172.16.30.7 25 (msg:”Found hacking reference in
e-mail”; content:”hacking”;)
Content analysis (by either text or hexadecimal matching) is used in more
than two-thirds of the rules that come with Snort.
Hexadecimal content matching
Hexadecimal (hex) content, although expressed differently than ASCII text, is
ultimately treated the same as ASCII by the Snort processing engine. In both
cases, the text is reduced to what the computer deals with best: bits, which is
then matched against the data streaming across your network. Hex is just a
shorthand way of representing the zeros and ones of binary machine code.
Hexadecimal is like a numerical alphabet that is 16 characters long, as com-
pared with English (which has 26 letters) or decimal math (which has 10
numerals). Hexadecimal is often referred to as base-16 because the “alpha-
bet” it uses has only 16 “letters” (0,1,2,3,4,5,6,7,8,9,A,B,C,D,E,F). Hexadecimal
strings entered into a Snort rule body contain only those characters and
none others. If you create a hexadecimal string with nonhex characters,
expect that Snort will turn up its nose.
Here’s a real example right out of the rules directory:
alert tcp $EXTERNAL_NET any -> $HOME_NET 22 (msg:”EXPLOIT ssh CRC32 overflow
filler”; flow:to_server,established; content:”|00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00|”; reference:bugtraq,2347;
reference:cve,CVE-2001-0144; classtype:shellcode-detect; sid:1325;
rev:3;)
To use a hex match for content searching, wrap the hexadecimal characters
to find with the pipe symbols (|). White space can separate out single bytes
of hexadecimal data (“00 00”). Snort ignores the white space, which is only
there to preserve the readability to the rule crafter.
The preceding rule is meant to watch for an attempted exploitation of the
Secure Shell server application (sshd) by scanning traffic coming from any-
where on the external network and destined for your home network on port
22 (the sshd port). The content search is a long series of binary zeros (18
sets of two, to be exact). How can a pattern of zeros be unique? A pattern of
zeros is frequently found in attack code and is often a give-away that some-
one is doing something you don’t like.
Mixing it up
You can mix and match the style of content searching without confusing
Snort. As long as the binary data you want to search for has the bookends of
the pipe characters, that block of text can be intermingled with other, plain
ASCII text. What follows is a good example from the back-door.rules file.
alert tcp $EXTERNAL_NET any -> $HOME_NET 12345:12346 (msg:”BACKDOOR netbus get-
info”; flow:to_server,established; content:”GetInfo|0d|”; refer-
ence:arachnids,403; classtype:misc-activity; sid:110; rev:3;)
Notice how the content search string is constructed: GetInfo|0d|. This
string tells Snort’s pattern matching subsystem to watch for the text phrase
GetInfo with a carriage return at the end. Pretty nifty, eh? Inserting hex into
a plain text string is useful for representing characters that can’t be repre-
sented by plain text, such as a carriage return. You can drift between text and
binary content all within the same search string.
The “depth” option
It would be nice if malicious content always occurred at the beginning or end
of a packet. Unfortunately, malicious content can occur almost anywhere in a
packet. The depth option specifies how many bytes into a packet the Snort
processor should look before moving on to the next rule.
The main reason for using the depth option is to restrict the search to the
most likely places where a match is found, without wasting valuable proces-
sor resources to search the entire packet. For example, if you want to find the
HTTP protocol version as part of a Web site communication, look in the first
few hundred bytes. Because a packet may be as large as 1,500 bytes (less the
header overhead), it makes a lot of sense to give Snort a break, especially if
what it must look through are millions upon millions of packets.
The following rule from the web-misc.rules file reveals that you need only
15 bytes to catch the sadmind worm. Hence, the content GET x http/1.0 is
always encountered at the very beginning of the packet.
web-misc.rules:alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS
(msg:”WEB-MISC sadmind worm access”; flow:to_server,established;
content:”GET x HTTP/1.0”; offset:0; depth:15; classtype:attempted-
recon; reference:url,www.cert.org/advisories/CA-2001-11.html;
sid:1375; rev:5;)
The “nocase” option
The nocase option, which appears in more than a third of the rules that ship
with Snort, basically says to ignore the case of the characters submitted for
searching. Because the nocase directive takes no arguments, it’s normally
just used with a terminating semicolon. The following example from the
info.rules file finds the text LOGIN FAILED or LoGIn FaIlEd on a telnet
session port.
alert tcp $HOME_NET 23 -> $EXTERNAL_NET any (msg:”INFO TELNET Bad Login”; con-
tent: “Login failed”; nocase; flow:from_server,established;
classtype:bad-unknown; sid:492; rev:6;)
The “offset” option
Another tool that gives us a more precise scope on where in the packet to
look is the offset option. Offset works by skipping over the number of bytes
supplied to the right of the colon. So, offset:90 skips the first 90 bytes of
the packet and then begins searching for the string given as part of the con-
tent keyword. Offset and depth work nicely together to make the search area
of a packet limited to a window that is bracketed by the two. Basically, if you
know where to look and what to look for, you can use these two options to
help Snort get a fast grip on where to spend its time.
The Uniform Resource Identifier (URI) option
You can use the uricontent option to conduct a similar type of content
searching. Its purpose is similar to the depth and offset options: to reduce
the overall processing burden on Snort as it watches for more attacks to
effectively do its job.
The uricontent option works much like the content one, except it restricts
its searching to only URIs in the payload of the packet. URIs (Uniform
Resource Identifiers) in Snort can specify other protocols than http, such as
ftp, gopher, rsync, and https.
The uricontent option only searches for the given text in URIs that is found
in the packet. If URIs aren’t present, no match occurs. URI searching is good
for catching malicious commands that are readily evident as they often
appear in the location request to a Web server. The following rule from the
web-iis.rules file shows an exploit attempt against the IIS server using
both content and uricontent analysis:
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:”WEB-IIS .asa HTTP
header buffer overflow attempt”; flow:to_server,established; con-
tent:”HTTP|2F|”; nocase; uricontent:”.asa”; nocase;
content:”|3A|”; content:”|0A|”; content:”|00|”; reference:bug-
traq,4476; classtype:web-application-attack; sid:1802; rev:4;)
A couple of interesting characteristics about this rule are worth discussing:
ߜ When nocase follows a string, its effect is upon the content string
immediately prior.
ߜ The nocase option has no effect upon binary search strings. Leaving it
off of those strings just helps the overall flow of the rule.
Classification
The classification options provide an overall description of a rule, along with
other helpful information about the rule, that can be used by the Snort pro-
gram itself and a system administrator. These options include the Snort ID,
the alert message to appear in the alert log, the rule revision number, the
alert priority, the alert classification, and external references for the exploit
or vulnerability that triggered the alert.
Snort IDs
Quite a few options help organize and classify detected alerts. The Snort ID
(sid) option is unique to the Snort system and a good way to get a handle on
classifications.
The format of the Snort ID value is the same as it as other classification
options. For example, a proper usage is as follows:
sid:
When you get the hang of building your own sets of rules, assign each custom
rule a unique sid number somewhere above the 1,000,000 mark. That way,
updates to the Snort rule base won’t accidentally collide with your custom
rule. Table 8-1 gives you a breakdown of the uses for sid ranges.
default level and rate how important or impacting a particular rule is to your
unique environment. For example, the following command assigns the rule
associated with it the highest priority: 1.
priority:1;
Classtype
The classtype option can organize rules into major groups. A few dozen differ-
ent classification types are spread over three priority levels, which are
described in Tables 8-2, 8-3 and 8-4. For inclusion in a rule, the syntax is
classtype:
Table 8-2 Priority 1 Classifications (Critical Severity)
classtype Description
Attempted privilege escalation to an
attempted-admin
Administrator level
Attempted privilege escalation to a User level
attempted-user
Discovered executable code
shellcode-detect
Achieved successful privilege escalation to an
successful-admin
Administrator level
Achieved successful privilege escalation to a
successful-user
User level
Discovered software code of a Trojan Network
trojan-activity
Attack
Failed privilege escalation to a User level
unsuccessful-user
Identified an attack upon a Web server’s appli-
web application attack
cation software
Table 8-3 Priority 2 Classifications (Intermediate Severity)
classtype Description
Attempted denial-of-service attack
attempted-dos
Attempted information collection
attempted-recon
(reconnaissance)
Potentially bad traffic seen (malformed)
bad-unknown
Denial-of-service attack possibly underway
denial-of-service
A catch-all category
misc-attack
Detection or use of a nonstandard protocol
non-standard-protocol
Portmap decode detected
rpc-portmap-decode
Denial of service detected
successful-dos
Large-scale information collection
successful –recon-
(reconnaissance)
largescale
Limited information collection (reconnaissance)
successful –recon-
limited
Strange or unusual filename was detected
suspicious-filename-
detect
Strange username was found attempting to
suspicious-login
login
System call was detected
suspicious-call-detect
A client was abnormally using a network port
unusual-client-port-
connection
Access was made to a potentially vulnerable
web-application-
web-app
activity
Table 8-4 Priority 3 Classifications (Low Severity)
classtype Description
A “ping” packet was detected
icmp-event
Some behavior was detected that may be
misc-activity
considered a policy warning
A host or network was being scanned
network-scan
Regular usage activity was detected
non-suspicious
A protocol instruction was decoded
protocol-command-decode
A pattern of specific bytes was detected
string-detect
Unknown or unclassified traffic
unknownRevision and versions
The Snort people thought ahead and even included a way to keep a version
tracking on each individual rule. The software industry uses many version
management schemes because the field is so fluid and so dynamic that tight
change control is almost a necessity. The format of the option is
rev:<#>;
Very few rules that come with Snort (less than 10 percent) have a revision
number of only 1. Busy enterprise networks are sometimes hostile and fast-
paced environments. Sometimes, rules are quickly added during the heat of a
malicious event so that immediate visibility is provided to the security man-
agers who must monitor the attack. After some analysis and a firmer under-
standing of the events takes shape, Snort’s rules are then revised (often only
subtly) to reflect what’s known about the event.
Messaging and output
The mesg option creates a customized output message that can be included
with any logs, alerts, and data dumps processed by the detection engine. By
looking through the rules directory, you can see that the fabricators of the
rules file have added messages to almost all the entries that they include.
The following is an example of the format of the mesg directive in use:
alert tcp $EXTERNAL_NET any -> $SMTP_SERVERS 25 (msg:”SMTP sendmail 5.5.5
exploit”; flow:to_server,established; content:”mail
from|3a20227c|”; nocase; reference:arachnids,119;
classtype:attempted-admin; sid:662; rev:4;)
See how cleverly the Snort makers had the output of this mail exploit attempt
reported as “SMTP sendmail 5.5.5 exploit”? Describing the nature of an attack
in plain English helps you in the long run (especially when you’re searching
through logs at trying to track down a breach).
External references
The second most powerful (and widely used) feature within a Snort rule is
the external reference option. You can reference Web-based resources that
provide you with tons of additional data on an attack or probe right in the
Snort logs.
A few different formats are used. Nearly all are Web site front-ends that look
up an attack based on a unique identifier. For example, using the example in
the preceding section, we find the following: reference:arachnids,119;
Thanks to this command, when Snort encounters this Sendmail attack, it pro-
vides a URL where the user can find out more about the Sendmail attack.
Table 8-5 gives a list of Snort’s external references.
Keyword URL Base
bugtraq http://www.securityfocus.com/bid/
cve http://cve.mitre.org/cgi-bin/cvename.cgi?name=
arachNIDS http://www.whitehats.com/info/IDS
McAfee http://vil.nai.com/vil/content/v_
Nessus http://cgi.nessus.org/plugins/dump.php3?id=
url http:// (a general URL that’s passed straight through)
Proper use of the external keyword takes this form:
Reference:
You can tie together any number of reference options as long as they’re sepa-
rated by a semicolon.
Advanced options and deep dark secrets
The advanced options give you a peek into the dark side: the stuff of the
geek-chic and the wizards of computer security.
Flow control
The flow control option lets you define the direction of a network stream. All
network communications have two endpoints and a direction, so Snort can
be configured to alert whenever one of many other triggers is tripped. Snort’s
internal engine must do some fancier processing for the flow control (includ-
ing some on-the-fly packet reconstruction), but it’s certainly worth the over-
head because it lets you know whether an attack actually worked or not.
Regular expressions
A regular expression (regex in computer-nerd circles) is the incredibly power-
ful voodoo of using wildcards to match substrings within other strings.
Without jumping into the deep end of this black art, a regular expression
combined with a Snort rule makes for powerful mojo!
Protocol options
Because of Snort’s primary function to act as a low-level packet trap and fil-
tering device, it can make lots of specific selections based on granular net-
work protocol components. For example, sometimes hackers use specialized
or fragmented packets to tease at the edge of networks for information about
what they may find if they break in. These probing and recon expeditions
may otherwise go unnoticed by a system administrator or a security package
not configured to watch for such errant behavior. Snort’s native IP rules
options put a huge amount of power at your fingertips.
How does Snort deal with all those rules?
Managing the files and their contents, let alone keeping a huge decision tree
running, is a fine programmatic accomplishment.
Snort keeps track of all those intricate rules (some with more than 20 differ-
ent options) with some fancy data processing internally. Without getting too
bogged down, the process of reading in a particular rule is governed by a
string parser, which cuts apart the rule into its component parts, which are
then stored into a series of linked lists.
Snort is a busy, complex, and low-level application. Every small or subtle
error that goes undetected or that causes minor annoyances can snowball
into a huge performance issue under certain circumstances. Although it
doesn’t happen often, a misplaced command or configuration option can
cause downtime or data loss.
Rule Refinements
This section is the fun part of tweaking specific rules to match your environ-
ment. We recommend a regular strategy of nosing through your Snort output.
As time passes, the composition of your network changes, and the minefield
of vulnerabilities expands.
Trimming the fat
Likely the first refinement that any IDS guru recommends, almost to the point
of being a broken record, is to reduce your false positives by stripping the
dead wood from your rules files.
We recommend that you sit down with a map of your network and a list of
your network connected assets (operating systems and exposed services are
the most critical) and build a table of your computer resources that can be
attacked. From there you comment out those rules that just don’t matter. If
you have ten Windows NT servers running MS Project Server and nothing
else, there’s little need for a thousand Linux/Unix rules.
Commenting out unneeded rules is a simple matter: Just edit the file contain-
ing the rule and place a “#” before the first character of the rule type (gener-
ally “alert”).
Chapter 9 includes more tuning methods that reduce false positives and the
reasons why removing the extra noise keeps your Snort a-snorting.
Making adjustments
Small changes to the rules files of your setup can keep your Snort installation
running at peak efficiency. By refining the rules that you are already running
with Snort, you generate better reports, waste less time reviewing them, and
react faster.
Before editing any Snort rule file, it’s highly recommended that you do the
following:
ߜ Always make a backup of that rule file.
ߜ Make sure that you use a plain text editor that doesn’t add any funky for-
matting or characters when you save the file. The vi program in Linux
and Notepad in Windows are good examples.
Start by finding a rule that can use some tweaking. Maybe this DNS rule was
misclassed:
alert udp $EXTERNAL_NET 53 -> $HOME_NET any (msg:”DNS SPOOF query response PTR
with TTL\: 1 min. and no authority”; con-
tent:”|85800001000100000000|”;
content:”|c00c000c00010000003c000f|”; classtype:bad-unknown;
sid:253; rev:2;)
Out of the box, it’s classified as a “bad-unknown” alert. Maybe it should be
reclassified as a reconnaissance or information probe, consistent with an
“attempted-recon” tag. To change the rule, just edit the dns.rules (the file
that contains the rule we’re modifying) and change it to something like
alert udp $EXTERNAL_NET 53 -> $HOME_NET any (msg:”DNS SPOOF query response PTR
with TTL\: 1 min. and no authority”; con-
tent:”|85800001000100000000|”;
content:”|c00c000c00010000003c000f|”; classtype:attempted-recon;
sid:253; rev:3;)
We bumped up the revision number to 3 so that another person can see that
something’s changed.
If you plan on making lots of changes to the base rules that come with Snort,
keep a local backup copy of the original version outside of the directory that
Snort uses to manage its configuration. If you upgrade Snort without keeping
copies of all your custom tweaking, you may accidentally overwrite the
whole lot with one punch of the enter key!
Building a rule from whole cloth
In some cases, a new rule is needed. Situations that might require a new rule
include:
ߜ Some sort of odd behavior on the network has been noticed: Maybe an
abnormal amount of data is transferred on the network after hours, or a
particular server is rebooting for no apparent reason. An investigation
begins to determine what these oddities mean, and based on captured
network data, you can create a rule that matches the odd event.
ߜ A new attack hits the Internet. There are no existing Snort rules that
match the attack, so you decide to create a rule on your own.
For almost all configurations, the standard set of rules (if regularly updated)
can be just what the doctor ordered. The need to build a whole rule from
scratch isn’t an everyday occurrence.
Here’s a real-world situation that we can use as an example. While on-site at a
customer’s facility, we heard that its network was acting irrationally and that
the customer needed our help in isolating the cause of it. After an hour of
tracking back a huge amount of network bandwidth coming from two work-
station computers, we found that they were infected with some sort of virus.
We diagnosed a virus by running a packet sniffer and capturing all of those
workstations’ network communications.
All of that techno-sleuthing work we did can be best summarized into a
packet capture, or at least a fair approximation of one. What follows is a snip-
pet of what we were looking at:
15:30:05.000913 10.3.232.38.1522 > 192.168.4.81.1434: udp 376
0x0000 4500 0194 bec2 0000 6d11 d406 d963 055d E.......m....c.]
0x0010 d8ab 0224 1069 059a 0180 6b52 0401 0101 ...$.i....kR....
0x0020 0101 0101 0101 0101 0101 0101 0101 0101 ................
0x0030 0101 0101 0101 0101 0101 0101 0101 0101 ................
0x0040 0101 0101 0101 0101 0101 0101 0101 0101 ................
0x0050 0101 0101 0101 0101 0101 0101 0101 0101 ................
0x0060 0101 0101 0101 0101 0101 0101 0101 0101 ................
0x0070 0101 0101 0101 0101 0101 0101 01dc c9b0 ................
0x0080 42eb 0e01 0101 0101 0101 70ae 4201 70ae B.........p.B.p.
0x0090 4290 9090 9090 9090 9068 dcc9 b042 b801 B........h...B..
0x00a0 0101 0131 c9b1 1850 e2fd 3501 0101 0550 ...1...P..5....P
0x00b0 89e5 5168 2e64 6c6c 6865 6c33 3268 6b65 ..Qh.dllhel32hke
0x00c0 726e 5168 6f75 6e74 6869 636b 4368 4765 rnQhounthickChGe
0x00d0 7454 66b9 6c6c 5168 3332 2e64 6877 7332 tTf.llQh32.dhws2
0x00e0 5f66 b965 7451 6873 6f63 6b66 b974 6f51 _f.etQhsockf.toQ
0x00f0 6873 656e 64be 1810 ae42 8d45 d450 ff16 hsend....B.E.P..
0x0100 508d 45e0 508d 45f0 50ff 1650 be10 10ae P.E.P.E.P..P....
0x0110 428b 1e8b 033d 558b ec51 7405 be1c 10ae B....=U..Qt.....
0x0120 42ff 16ff d031 c951 5150 81f1 0301 049b B....1.QQP......
0x0130 81f1 0101 0101 518d 45cc 508b 45c0 50ff ......Q.E.P.E.P.
0x0140 166a 116a 026a 02ff d050 8d45 c450 8b45 .j.j.j...P.E.P.E
0x0150 c050 ff16 89c6 09db 81f3 3c61 d9ff 8b45 .P........ 192.168.4.81.1434: udp 376
Table 8-6 identifies the meaning of each of the preceding line’s component
elements.
Table 8-6 Components of Packet Trace
Description Value
Time packet was sent 15.30:05.000913
Source address 10.3.232.38
Description Value
Source port 1522
Destination address 192.168.4.81
Destination port 1434
Protocol UDP
Packet size (bytes) 376
All that’s needed from Table 8-6 are the protocol and the destination port.
The source IP address, source port, and destination IP address show up dif-
ferently when coming from and going to different systems. Remember, we’re
looking for new instances of this worm, not the infected systems we already
know about. Coupled with the signature that was scissored from that big
block of packet data, that’s the complete makings of a fledgling Snort rule. All
the pieces fit together like this:
alert udp $EXTERNAL_NET any -> $HOME_NET 1434 (msg:”New MSSQL Worm A-
Multiplyin’”; content:”|c050 ff16 89c6 09db 81f3 3c61 d9ff 8b45|”;
sid:1000001; rev:1;)
The preceding example highlights the following best-practices in creating a
Snort rule:
ߜ We followed the path of the good Snort administrator and made the
Snort ID equal to 1,000,000.
ߜ The revision is marked as 1, meaning that this attempt was our first at
drafting a rule to achieve the wanted results.
After testing, if our signature isn’t right or other elements need tweaking, we
can make the changes and increase the rev number to reflect the changes.
