1
1
Snort Rules: Syntax and
Keywords
Paul Ritchey,
Jacob and Sundstrom, Inc.
[email protected]
V1.0.0
Welcome to the class titled ‘Snort Rules: Syntax and Keywords’. The purpose of this section is to
teach you the basic building blocks for writing Snort rules. These basic building blocks consist of
the syntax and keywords Snort provides for writing signatures and taking various types of actions. A
later section will take these building blocks and teach you how to apply them to make a complete
rule along with understanding the purpose of existing rules.
2
2
Agenda
!
Brief Overview
!
What is Snort?
!
Data Flow
!
What are rules?
!
Basic rule anatomy
!
Rule headers
!
Rule options
!

• Customisable via plug-in architecture.
Snort is an intrusion detection system (IDS) made freely available by Marty Roesch at
http://www.snort.org.
Snort supports both header and payload inspection methods, allowing you to fully specify in a single
rule what constitutes a suspect packet. This flexibility allows you to build rules customized to your
site that greatly aid in minimizing false positives, but in a format that is in a human readable.
Snort is also flexible when detecting events, allowing you to choose from a variety of methods how
you want to be notified. Snort can output to files, databases, SAMBA alerts and various other ways.
Snort also has limited capability in responding to intrusion attempts by sending ‘resets’ or other
various packets.
Snort can be compiled to run on most flavors of Unix including: Linux, BSD variations, Solaris, HP-
UX, AIX, IRIX, Tru64 and even MacOS X. Snort will run on most operating systems that are
capable of compiling and installing libpcap (a requirement). A Windows version is also available
providing the same capabilities for the those not working in a Unix environment.
Note the last two items: It's free and you can customize it. Snort is available in source code form for
free under the standard GNU license. If Snort doesn't do something you need, write a plug-in! This
allows you to extend Snort beyond what Marty and the development team has provided you, and
allows you another means to customize its capabilities to your specifics site's needs.
5
5
Snort Data Flow
Packet Decoder
Preprocessor
(Plug-ins)
Detection Engine
(Plug-ins)
Output Stage
(Plug-ins)
Packet Stream
Sniffing

–
HTTP protocol normalization
–
Tiny fragment detection
–
IP defragmentation
–
TCP stream reassembly
Preprocessor plug-ins are done after the packet decoding, but before the detection engine processing. They are
called only a single time per packet and may perform highly complex functions such as TCP stream assembly.
They can manipulate packet data and even call the detection engine directly.
The Tiny Fragment preprocessor was the first preprocessor written and was developed as something of a
prototype to demonstrate the usefulness of the preprocessor plug-in interface in Snort. It’s job is to look at the
size of fragments on the wire and raise an alert if a fragment is below a preset threshold size. This is useful for
detecting malicious fragmentation that is commonly used in an effort to circumvent network intrusion detection
systems that do not perform fragmentation. Commonly, these attacks fragment packets to the smallest size
allowed by the protocol in an effort to complicate the job of a NIDS sensor. An IDS can use this fact to detect
when these evasive tools are in use on the network, because packets which are fragmented by standard
commercial network equipment are seldom found to be smaller than 128 bytes.
The HTTP protocol normalization preprocessor takes HTTP URL strings and converts them to ASCII strings.
The tiny fragment detection preprocessor looks for fragments that are smaller than a threshold size you specify.
This can be used to detect subversive behaviour most likely from a crafted packet.
The portscan detection plug-in will generate alerts when an IP connects to a certain number of ports in a
predetermined time interval. These values are defined in the rules file. In the rules from www.snort.org, the
number of ports defaults to 3 and the time interval to 5 seconds. A preprocessor ignore rule can be used to
ignore known valid hosts that generate scan-like behaviour and trigger false alarms.
The IP defragmentation preprocessor takes fragmented IP packets and puts them back together for the detection
engine to consider. The defragmenter takes no arguments. This preprocessor largely supersedes the tiny
fragment preprocessor and it is probably not necessary to run the tiny fragment detector alongside the
defragmentation preprocessor.

TCP TTL: 46 TOS: 0X0 ID: 19678
****** A* Seq: 0XE4F00003 ACK: 0x0 Win: 0XC00
Directory name
:
1.2.3.4
File name:
TCP:1029-80
Contents:
This slide attempts to show the results of finding some kind of malicious activity that matches a rule. We
have asked for Snort to alert and log the activity. Snort will either default to the logging file
‘/var/log/snort’, or a log directory that you select as a command line option. The log directory
will contain a subdirectory with a name of the IP number that directed the hostile activity. This
subdirectory contains a file name that specifies the protocol and the source and destination ports involved
in the activity. What you see on the right side of the slide is that we've received some activity from
hostile IP 1.2.3.4 and that becomes a directory name. In that directory, we find a file TCP:1029:80 which
says that 1.2.3.4 sent a TCP packet from source port 1029 to destination port 80.
If an alert rule fires, the packet will be logged and an entry including the alert message will be placed in
the alert file. When a packet is logged in its default format to a log file, the messages are also included
with the packet dumps. The reason that there is an alert file and a log file is that all alert rules have the
packets that cause the alerts logged, but log rules only send packets to the logging facility. The alert file
exists to store all the alerts in one place for easy lookup, while the various log files exist to provide an in
depth examination of the packets that caused alerts to go off, as well as a place to store packets that had
applicable log rules.
If we look at the contents of the alerts file, we see the output that tripped the alert. It appears that the
ACK (acknowledgement) number is 0 which should never happen in anything other than a normal TCP
SYN portion of a three-way-handshake, and so this is perceived to be an nmap scan that is attempting to
verify if the destination host 192.168.5.5 is alive. It is possible that 192.168.5.5 will respond with a
RESET to an unsolicited ACK to indicate it is alive.
9
9

the alert message as identified in the rule, and the IP's and ports involved. Also, you can disable
alerting all together which might be done if Snort is being used simply as a collection agent and not
as a reporting agent.
Alerts can also be sent to a Windows host using Samba; this is useful if you or the Snort analyst has
a Windows workstation where you are most likely to do your daily work. Alerts can be written to
the UNIX syslog file, a database or even a highly portable XML output file if you so choose.
This slide shows a very small subset of the possible mechanisms Snort can use to record hostile
activity. It’s very likely that more will be added as time passes making Snort even more convenient
and valuable to use.
10
10
What Are Rules?
!
Rules define what Snort is to watch for.
!
Define ‘who’ and ‘what’ is involved.
!
Simple syntax, easy to read and create.
!
Inspect header, payload or both.
By defining rules, you tell Snort what traffic is to be considered hostile. Rules define everything
from the ‘who’ is involved (source and destination machines) to the ‘what’ is considered hostile
(invalid TCP flag settings, for example). The syntax and keywords are very simple and intuitive, but
they are very specific and must be followed closely. For those who have tried deciphering
complicated tcpdump filters (such as those used for Shadow), this is a welcome change and makes
keeping up with the latest trends in hacking much easier.
Rules can be written to be very specific, looking for particular payloads and packet attributes, or they
can be very general, specifying only a single IP or port. This allows you great flexibility and the
ability to fine tune individual rules to aid in minimizing false positives, or to look for specific types
of traffic.

!
Defines ‘who’ is involved
!
Protocol
!
Source and destination IPs
!
Source and destination ports
!
Direction of traffic
alert tcp !10.1.1.0/24 any -> 10.1.1.0/24 any (flags: SF; msg: “SYN-FIN scan”;)
Rule Header Rule options
The rule header is the first portion of each rule. It defines the network protocol and ‘who’ must be
involved. For each of the individual fields there are many options (with specific syntax) that can be
used to specify single values, ranges, or groups of values. Each field will be discussed in upcoming
slides, covering possible values and the proper syntax for each.
Note: Snort’s detection engine breaks the comparison of a packet into two parts, corresponding to
the parts of a rule. The first comparison compares the rule header to the packet. If the packet does
not fit the profile of one of the rule headers in a rules set, the detection engine moves on to the next
packet. If the packet does fit the profile of the rule header, then the detection engine continues on to
test the rule options.
14
14
Rule Header: Action
!
Action field tells Snort what to do.
!
Valid values include:
!
Alert – alert and log packet when triggered.

It’s also possible to define your own action types which can be used to route rule output to various destinations.
This sophisticated usage will not be covered here, but can be explored at Snort’s web site – www.snort.org.
Note: The normal order rules are processed in is alert rules first, pass rules second and log rules last. To change
this default behavior, you must specify the ‘-o’ option which changes the order the rules are processed.
Specifying the ‘-o’ option changes the rule processing order to pass rules first, alert rules second and log rules
last. This was done when Snort was developed for public use to avoid having an errant pass rule accidentally
disable every alert and log rule in the system. The –o option was developed as an “expert mode” for people
once they understood how the rules system worked.
15
15
Rule Header: Protocol
!
Protocol field tells Snort what type of
network traffic the rule applies to.
!
Valid values include:
!
tcp
!
udp
!
icmp
alert tcp
!10.1.1.0/24 any -> 10.1.1.0/24 any
Protocol field
The protocol field in the rule header tells snort what type of network traffic the rule applies to. Snort
currently supports three different types of network traffic: TCP (Transmission Control Protocol),
UDP (User Datagram Protocol) and ICMP (Internet Control Message Protocol). Additional
protocols will be added in the future.
16

135.1.0.0/16 = Class B
192.168.5.0/24 = Class C
192.168.5.5/32 = Host address
Special keywords
:
any - match all addresses
! - negate address (!192.168.5.5/24 - all but 192.168.5.5)
$HOME_NET – variable defined elsewhere in rules file.
This slide depicts the supported formats you can specify the source IP in using CIDR notation.
Examples are provided for the standard network classes (A, B, C) as well as for specifying a specific
host. For locations where subnetting is used, specify the number of bits in the the network mask that
you are using (such as 30).
For rules that apply to any traffic, specify the keyword ‘any’ which matches all possible IP
addresses. Use the negation operator (‘!’) to apply a rule to all traffic except the specified host or
network.
A new syntax was introduced with Snort version 1.7 which allows you to specify more than on
address at a time. To do this, specify the list of addresses in CIDR notation, separating them by a
comma. The entire list is then enclosed by brackets (‘[‘, ‘]’). Note: Do not leave any spaces when
using this format. At this time Snort’s rule parser cannot support spaces embedded in the address
list.
In order to make your rules more portable, it’s also possible to use a variable which is defined
elsewhere (command line option or rules file) to specify the source IP. Variables and their usage are
discussed in a later section.
The formats specified here also apply when to the destination IP field, which is covered on a later
slide.
18
18
Rule Header: Source Port
!
Source Port field defines from what

33,999.
The formats specified here also apply when specifying the destination ports, which is covered on a
later slide.
In situations where a rule uses the two-way traffic flow for the traffic direction field (‘<>’), this port
can represent either a source or destination port.
20
20
Rule Header: Traffic Direction
!
Traffic Direction field defines what
direction packets must be traveling.
!
Two options:
!
-> defines source to destination
!
<> direction doesn’t matter (bi-directional)
alert tcp !10.1.1.0/24 any ->
10.1.1.0/24 any
Traffic Direction field
The traffic direction field allows you to specify the direction the packet must be traveling. Two
options are available, allowing you to specify a specific direction of flow, or that direction doesn’t
matter.
Using the notation that looks like an arrow (‘->’), the packet must be traveling from a source to a
destination. The source information is specified to the left of the arrow, and the destination is on the
right. The packet must be traveling in the specified direction. If it is traveling in the opposite
direction, the packet will not pass the rule header test and will not be inspected any further against
the rule.
If you use the notation that looks similar to a double headed arrow (‘<>’), the packet can be traveling
to or from either address/port pair. For this notation, either address can represent the source IP and

Destination Port field
The destination port field defines the port on the destination machine the traffic must be destined for.
The destination port is defined using the same formats used to specify the source port. Please refer
to the slides pertaining to the source port field for the available formats and proper syntax.
In situations where a rule uses the two-way traffic flow for the traffic direction field (‘<>’), this port
can represent either a source or destination port depending on the direction the traffic is traveling.
23
23
Rule Options
This section discusses the rule option portion and the syntax that is used to define it.
24
24
Rule Options
!
Defines ‘what’ is involved.
!
Tells Snort what packet attributes
must be inspected.
!
Forms a signature defining a specific
attack or probe.
alert tcp !10.1.1.0/24 any->10.1.1.0/24 any (flags: SF; msg: “SYN-FIN scan”;)
Rule Header Rule options
The rule options portion is the second half of a rule. The rule options define the ‘what’ portion of a
rule – what attributes of a packet must be inspected and the values they must contain for the packet
to be considered hostile. This portion of a rule is only used if the packet meets the specifications of
the rule header parameters first.
If a packet has met both the requirements of the rule header and the rule options, the rule is then
‘triggered’. Depending on the type of rule, certain actions can take place. The most common action
that takes place is an alert message being written to the alert file and the packet data being sent to the