Snort Rules: Application

Paul Ritchey,
Jacob and Sundstrom, Inc.
pritchey@jasi.com

V1.0.0 1

Welcome to the class titled ‘Snort Rules: Application’. The purpose of this class is to take the
material you learned in the previous section, ‘Snort Rules: Syntax and Keywords’. This section will
take those individual keywords, values and syntax to form complete rules. You will also learn how
to analyze existing rules piece by piece to determine what the rule is looking for.

1
 Agenda
! Rule Analysis
! Simple Rules
! Difficult Rules
! Advanced Rules

! Writing Rules
! Simple Rules
! Difficult Rules
! Advanced Rules

! Tying It All Together

2

The first half of this presentation will examine rules of increasing complexity. You will be taught
how to analyze an existing rule to determine what it is looking for. This ability is key to
understanding how to piece together a complete rule from scratch that matches the signature of an
attack.

The second half of the presentation will ask you to write rules from scratch of increasing difficulty.
The process of creating these rules will be covered in a step by step process. This will show you a
possible methodology you can use when creating rules on your own.

The very last section will tie together everything you have learned so far, showing you a few of the
options available for Snort output.

This presentation covers Snort version 1.7. If you are using a newer version of Snort, please
remember that new features may have been added or existing features may have been modified after
this presentation was assembled.

2
 Rule Analysis: Simple Rules

This section will show you how to analyze simple rules, step by step. The analysis skills learned
here will be built upon in later sections to analyze rules of increasing difficulty. This will help you
later when you will be required to write rules from scratch.

3
 Rule Analysis: Simple Rules
! Learn to analyze simple rules.
! Signature based on rule header.
! Examples taken from snort.org rule
set and www.whitehats.com.
! Use logical approach
! Analyze rule header first
• Determine source and destination
addresses and ports
• Snort uses this section first.
! Analyze rule options next
4

In this section you will learn how to analyze simple rules. The rules were chosen because they do
not incorporate packet attributes which can make some rules difficult to analyze. These are real life
rules, taken directly from the rule set available from the snort.org web site and www.whitehats.com.
This means that it’s possible to do further research on the exploits that the rules are designed to
detect to fully round out your understanding of rules.

This section will start with teaching you how to analyze rules based on a logical approach. The first
step is to analyze the rule header. This determines what hosts, ports, protocols and traffic flow must
be involved before Snort even starts to examine the rest of the rule – this allows Snort to quickly
determine if it should completely analyze the rule against the options section, saving valuable time.

Later sections will combine the analysis of the rule header with the options section for more
complicated rules.

4
 Simple Rule #1:
Back Orifice
! Background:
! Trojan
! Allows remote control of infected
machine
! Rule:
! alert UDP $EXTERNAL any -> $INTERNAL 31337 \
(msg: "IDS188/trojan-probe-back-orifice";)

The first rule we are going to examine is one that looks for attempts at connecting Back Orifice
trojans. This particular exploit works by means of a trojan that is somehow installed on the target
machine. The trojan can be installed accidentally by end users running executables attached to email
messages, downloading the trojan masquerading as a useful utility, etc. Once installed, the trojan
opens a port and makes itself available for control from a remote host.

Further information on this particular trojan can be obtained any of the major online security web
sites. In depth analysis of this trojan is beyond the scope of this course.

5
 Simple Rule #1:
Back Orifice (cont.)
alert UDP $EXTERNAL any -> $INTERNAL 31337 \
(msg: "IDS188/trojan-probe-back-orifice";)

! Examine the rule header:

! Will ‘alert’ when triggered.
! Applies only to UDP traffic.
! Source defined by variable
• $EXTERNAL = !$HOME_NET
! Destination defined by variable
• $HOME_NET = your network
6

For this simple rule, the contents of the signature is completely contained in the rule header. This
rule, when it is triggered, will execute the action ‘alert’. Alert means Snort will write an entry to the
alert file and an entry to the logs unless they are overridden by command line options or other
means.

This rule only applies to UDP traffic. If snort the traffic Snort is examining is from another protocol,
this rule will not be tested against them.

The destination address is defined as a variable, HOME_NET. This variable is typically defined at
the top of the rules file being used, and is set to the addresses Snort is monitoring. In this particular
rule, the source address is also defined as a variable, named EXTERNAL. Typically, this is set to
!$HOME_NET, meaning that the source address should be outside of the network address space
Snort is monitoring.

The UDP packet can, however, be originating from any of the possible ports on the source host, but
must be destined specifically for the port 31337 (otherwise known as ‘eleet’) on the destination
machine.

6
 Simple Rule #1:
Back Orifice (cont.)
alert UDP $EXTERNAL any -> $INTERNAL 31337 \
(msg: "IDS188/trojan-probe-back-orifice";)

! Examine rule options.

! No packet attributes are examined.
! Only includes message.

! Possibility of false-positives:
! Low likelihood of occurrence.
! High likelihood of false-positives.
7

Examining the rule options section, it is seen that the only option being used is the message option.
This option provides a string that is used to tag alert and log entries, making it easier to determine
what a log or alert entry represents.

This rule is very simple. The only thing limiting the rule down to a specific subset of UDP traffic is
the destination port. Since no packet attributes or options are specified, it is very likely that detects,
although not often, may very well be false-positives. Any traffic, such as streaming audio or video,
that happens to be destined for destination port 31337 will trigger this rule. Care must be taken when
analyzing any available data to validate that the packet was truly a probe for Back Orifice or the
master program contacting a Back Orifice client.

7
 Simple Rule #2:
Deep Throat Trojan
! Background
! Trojan
! Allows remote control of infected host.

! Rule:
! alert udp any 2140 -> $HOME_NET 60000 \
(msg:"IDS106 - BACKDOOR SIGNATURE - DeepThroat
3.1 Server Active on Network";)

The next simple rule we will examine is one that detects Deep Throat trojans. Deep Throat is
another trojan that can be accidentally installed by users who unknowingly execute attachments or
download the software by accident. Once installed, the trojan opens a port that allows remote hosts
to control the infected machine.

8
 Simple Rule #2:
Deep Throat (cont.)
alert udp any 2140 -> $HOME_NET 60000 \
(msg:"IDS106 - BACKDOOR SIGNATURE - \
DeepThroat 3.1 Server Active on Network";)

! Examine the rule header:

! Will ‘alert’ when triggered.
! Applies only to UDP traffic.
! Source specified as ‘any’
• ‘Any’ matches all possible IP addresses, including
internal addresses.
! Destination defined by variable
• $HOME_NET = internal network
9

For this simple rule, the contents of the signature is again completely contained in the rule header. This
rule, when it is triggered, will execute the action ‘alert’. Alert means Snort will write an entry to the
alert file and an entry to the logs unless they are overridden by command line options or other means.

This rule only applies to UDP traffic. If snort the traffic Snort is examining is from another protocol,
this rule will not be tested against them.

Now the rule deviates from the previous example. Instead of specifying a variable for the source IP
address, the keyword ‘any’ is specified. This means that the packet can originate from any possible IP
address, there are no restrictions. However, the packet must originate from a specific port – 2140. The
packet must be destined for the network the variable HOME_NET is set to, and to the specific port
6000. If the packet meets all of the above criteria, it will trigger the rule and will be logged to the alert
file and logs with the message specified in the rule options section.

I would like take a second to discuss the keyword ‘any’ that was specified for the source address. Snort
is typically installed on a machine that resides in a ‘DMZ’. The DMZ sites outside of your internal
network, and sees all traffic in bound from the internet to your network, or outbound from your network
to the internet. It does not and should not see your internal traffic. Because of this, it would have been
just as effective to replace the keyword ‘any’ with !$HOME_NET.

9
 Simple Rule #2:
Deep Throat (cont.)
alert udp any 2140 -> $HOME_NET 60000 \
(msg:"IDS106 - BACKDOOR SIGNATURE - \
DeepThroat 3.1 Server Active on Network";)

! Examine rule options.

! No packet attributes are examined.
! Only includes message.
! Possibility of false-positives:
! Low likelihood of occurrence.
! Likelihood of detect being a false-positives.

10

Examining the rule options section, we again that this rule like the previous example is only
specifying the message option. This option provides a string that is used to tag alert and log entries,
making it easier to determine what a log or alert entry represents.

This rule is very simple. The only real limiting factors are the source and destination ports. Both
ports are ephemeral ports, meaning they are out of the reserved range. Although unlikely, it’s
possible that this port combination could be used during the course of a valid connection, and
because there are no other criteria for the rule false-positive detects may be made. Most virus
software should be capable of detecting this trojan if properly installed and used regularly. This
increases the chances that a detect is a false-positive so care must be taken to fully resolve any
detects.

10
 Rule Analysis: Complex Rules

11

In this section the rules presented for analysis are a little more complicated than the previous
examples. Essentially they provide additional information about packets that are considered hostile
beyond source and destination IPs and ports.

11
 Rule Analysis: Complex Rules
! Learn to analyze complex rules.
! Signature based on rule header.
! Signature also based on rule options.

! Examples taken from www.snort.org rule

set and www.whitehats.com.
! Use logical approach
! Analyze rule header first
! Analyze rule options next
• Specifies specific packet attributes
• Can increase accuracy – decrease false positives12

This section concentrates on analyzing more complicated rules – those containing packet attributes
in the rule options section. In these rules, the signature doesn’t just consist of the contents of the rule
header. It consists of the rule header and additional information specified in the rule options.

This section will continue to build on the rule analysis technique that was used in the first section.
Interpretation of the rule option section with different kinds of packet attributes will be introduced
here. By adding packet attributes (such as TCP flags) to the rule options section, it’s possible to
make rules more accurate, which can potentially reduce the number of false positives.

The example rules used in this section are real world rules. They have been taken from the rule sets
available at the www.snort.org web site and from the www.whitehats.com web site.

12
 Complex Rule #1:
NetMetro
! Background:
! Trojan
! Allows remote control of infected
machine
! Rule:
! alert tcp $EXTERNAL_NET 5031 -> $HOME_NET !53:80 \
(msg:"IDS79 - BACKDOOR SIGNATURE – NetMetro
Incoming Traffic"; flags:PA;)

13

The rule we are going to examine next is one that detects the NetMetro trojan. NetMetro is another
trojan that when installed allows remote control of the infected machine. Again, this trojan like any
other can be accidentally installed by executing attachments to email messages, or downloading the
trojan as it masquerades as a useful utility or game. Most virus detection software should detect this
trojan as long as the signatures are properly maintained.

13
 Complex Rule #1:
NetMetro (cont.)
alert tcp $EXTERNAL_NET 5031 -> $HOME_NET !53:80 \
(msg:"IDS79 - BACKDOOR SIGNATURE - NetMetro Incoming
Traffic"; flags:PA;)

! Examine the rule header:

! Will ‘alert’ when triggered.
! Applies only to TCP traffic.
! Source defined by variable
• $EXTERNAL_NET = !$HOME_NET
! Destination defined by variable
• $HOME_NET = your network
14

This rule when triggered will alert – meaning it will create an entry in the alerts file and create a log
file, unless these options are overridden by command line options. It also only applies to TCP traffic
that meets the criteria of the rest of the signature.

The source address is specified by the variable EXTERNAL_NET. In most cases

EXTERNAL_NET is set to !$HOME_NET, which means that the source address can be any IP
address except the IPs belonging to your network. The destination address is specified by the
variable HOME_NET. This variable is set to the IP addresses your sensor is to monitor. Both of
these variables are typically defined at the top of a rules file, but may also be set by command line
options.

The source port the traffic must originate from is port 5031. If the source port is anything but 5031,
it will not match the rule header information and this rule will not be triggered. The destination port
setting is more interesting. It specifies that the destination port can be any port except ports 53
through 80, inclusive.

14
 Complex Rule #1:
NetMetro (cont.)
alert tcp $EXTERNAL_NET 5031 -> $HOME_NET !53:80 \
(msg:"IDS79 - BACKDOOR SIGNATURE - NetMetro Incoming\
Traffic"; flags:PA;)

! Examine the rule options:

! TCP flags PUSH and ACK must be set.
! No other packet attributes examined.

! Likelihood of false positives:

! Low likelihood of occurrence.
! High likelihood of being false positive.
15

This rule is the first example of packet attributes being used in the rule options section. The attribute
being tested is the TCP flags setting. In this case, the TCP flags PUSH and ACK must be set. Other
flags, such as SYN, FIN, URG and the two reserved bits must NOT be set. No other packet attributes
are examined beyond the TCP flag setting.

For this particular rule, there is a low likelihood of false positives, although they will happen. The false
positives are limited because the source port must exactly match 5031, and the destination port must be
outside the specified range. The addition of packet attributes (in this case TCP flags) to the rule options
section aids in reducing the possibility of false positives because it helps to narrow the possibility of
matches somewhat.

To rule out the possibility of a detect being a false positive, additional data possibly beyond what Snort
provides may need to be examined. For example, if an outside user telnets in to a server in your
network, it’s possible this rule may be triggered. The source port 5031 is an ephemeral port, meaning
that is not a reserved port and available for anyone and any application to use. If the port 5031 is used
by the person connecting to your telnet server, the rule will be triggered as soon as the TCP three way
handshake is completed and the first packed with a payload is sent inbound to your network. Telnet
runs on port 23, outside the range specified by the destination port setting that specifies what ports it
cannot be.

15
 Complex Rule #2:
Myscan
! Background:
! Port scanner.
! Allows remote detection of available
services and OS fingerprinting.
! Rule:
! alert tcp $EXTERNAL_NET 10101 -> $HOME_NET any \
(msg: "IDS439 - Scan - myscan"; ttl: >220; ack: 0; \
flags: S;)

16

The second difficult rule to be examined detects a particular tool used for scanning. This particular
scanner can allow an attacker to easily determine what services are available on a host. Combined
with the ability to determine the OS, and the hacker now has enough information to launch an
effective attack.

For this scanner certain packet attributes are hard coded in the original source code. This allowing
an accurate rule to be written that can easily detect scans from this software. It can also allow the
rule to be tuned to help eliminate false positives, increasing the accuracy.

16
 Complex Rule #2:
Myscan (cont.)
alert tcp $EXTERNAL_NET 10101 -> $HOME_NET any \
(msg: "IDS439 - Scan -myscan"; ttl: >220; \
ack: 0; flags: S;)

! Examine the rule header:

! Will ‘alert’ when triggered.
! Applies only to TCP traffic.
! Source defined by variable
• $EXTERNAL_NET = !$HOME_NET
! Destination defined by variable
• $HOME_NET = your network
17

This rule when triggered will alert – meaning it will create an entry in the alerts file and create a log
file, unless these options are overridden by command line options. It also only applies to TCP traffic
that meets the criteria of the rest of the signature.

The source address is specified by the variable EXTERNAL_NET. In most cases

EXTERNAL_NET is set to !$HOME_NET, which means that the source address can be any IP
address except the IPs belonging to your network. The destination address is specified by the
variable HOME_NET. This variable is set to the IP address range your sensor is to monitor. Both of
these variables are typically defined at the top of a rules file, but may also be set by command line
options.

The source port the traffic must originate from is port 10101. If the source port is anything but
10101, it will not match the rule header information and this rule will not be triggered. The
destination port can be anything, specified by the keyword ‘any’. This means the rule does not care
what port is used on the destination host.

17
 Complex Rule #2:
Myscan (cont.)
alert tcp $EXTERNAL_NET 10101 -> $HOME_NET any \
(msg: "IDS439 - Scan -myscan"; ttl: >220; \
ack: 0; flags: S;)

! Examine the rule options:

! Time to live value must be greater than 220.
! Acknowledgement number must be zero (0).
! TCP flag SYN must be set.
! Likelihood of false positives:
! Low likelihood of occurrence.
! Low likelihood of being false positive.
18

In this rule’s option section, the packet attributes time to live (ttl), acknowledgement number (ack)
and the TCP flag settings are examined. The first attribute that is examined, time to live, must have
a value greater than or equal to 220. The second attribute, the acknowledgement number, must be
zero (0). The last attribute, TCP flags, must have the SYN flag set.

For this rule, there is a low likelihood that the rule will be triggered, but a very high likelihood that if
it is triggered that it is NOT a false positive. There are many key items that lead to this conclusion
and show that this rule is a very well written one. The next slide will show you the individual parts
that combined together make this happen.

18
 Complex Rule #2:
Myscan (cont.)
alert tcp $EXTERNAL_NET 10101 -> $HOME_NET any \
(msg: "IDS439 - Scan -myscan"; ttl: >220; \
ack: 0; flags: S;)

! Source Port
! High into ephemeral ports (non-reserved).
! Time To Live
! Only one OS uses setting greater than 220.
! Acknowledgement Number.
! Cannot normally be set to zero (0).
! Rule vulnerable to mutations.
19

The first item that helps tune this rule is the specification of a specific port for the source port. By
specifying a specific value, only source addresses using that specific port might cause a trigger.
Because the source port is such a high number, it is very unlikely – but possible, that source port will be
used. Ephemeral ports, meaning the non-reserved ports, start at 1024 and go up. They are typically
used in sequence, so for a source address to reach 10,101, it must have made many connections to other
machines.

The second item that helps tune this rule is the time to live value. Most operating systems specify a
value much less than 220 when the packet is created. Only the Solaris 2.x operating system sets the
time to live attribute to a value greater than 220. All other operating systems use values much less than
220.

The last item that contributes to the rule’s tuning is the acknowledgement attribute value. The rule
specifies that this attribute must be set to the value zero (0). Under normal conditions, the
acknowledgement number can never be zero. Only in a crafted packet will this value ever be used.

All of the above combine to make this a finely tuned rule that will not false positive very often.
However it does depend on the above settings in the crafted packet not to be changed. This makes it
vulnerable to mutations of the scanning utility. The source code for this utility is freely available, and
by making a single simple alteration and recompiling it the rule will no longer detect it (although
Snort’s scan detection preprocessor should detect it, but it will not identify the utility being used).

19
 Rule Analysis: Advanced Rules

20

This section provides analysis of advanced rules – those using more sophisticated packet attributes to
examine the packet’s payload. These rules are the most difficult to write because they require close
analysis of an attack’s signature and of the source code of the attack application if available.

These types of rules also have the lowest likelihood of false positives because of the completeness of
the examination of the packets. They are also the easiest to avoid triggering by making slight
alterations in the application’s source code.

20
 Rule Analysis: Advanced Rules
! Learn to analyze difficult rules.
! Signature based on rule header.
! Signature also based on rule options.

! Examples taken from www.snort.org rule

set and www.whitehats.com.
! Use logical approach
! Analyze rule header first
! Analyze rule options next
• Specifies specific packet attributes
• Can increase accuracy – decrease false positives21

This section concentrates on analyzing more complicated rules – those containing packet attributes
in the rule options section. In these rules, the signature doesn’t just consist of the contents of the rule
header. It consists of the rule header and additional information specified in the rule options.

This section will continue to build on the rule analysis technique that was used in the first section.
Interpretation of the rule option section with different kinds of packet attributes will be introduced
here. By adding packet attributes (such as TCP flags) to the rule options section, it’s possible to
make rules more accurate, which can potentially reduce the number of false positives.

The example rules used in this section are real world rules. They have been taken from the rule sets
available at the www.snort.org web site and from the www.whitehats.com web site.

21
 Advanced Rule #1:
Wu-FTP Exploit
! Background:
! Exploits a bug in wu-ftp daemon.
! Allows instant root access.

! Rule:
! alert tcp $EXTERNAL_NET any -> $HOME_NET 21 \
(msg: "IDS458 - FTP wuftp260-tf8"; flags: PA; \
content: "|31C0 31DB 31C9 B046 CD80 31C0 31DB \
4389 D941 B03F CD80|";)

22

The first advanced rule we will examine is one that exploits a bug in an ftp daemon provided by
www.wu-ftpd.org that is used as a replacement for many native ftp daemons on some flavors of
Unix, as well as coming native in many Linux distributions. In this case the exploit is known as the
wuftp2600.c exploit which was originally distributed in a broken form. If the exploit is successful,
the attacker is instantly granted root access on a high numbered port that is opened up.

22
 Advanced Rule #1:
Wu-FTP Exploit (cont.)
alert tcp $EXTERNAL_NET any -> $HOME_NET 21 \
(msg: "IDS458 - FTP wuftp260-tf8"; flags: PA; \
content: "|31C0 31DB 31C9 B046 CD80 31C0 31DB \
43 89D941 B03F CD80|";)

! Examine the rule header:

! Will ‘alert’ when triggered.
! Applies only to TCP traffic.
! Source defined by variable
• $EXTERNAL_NET = !$HOME_NET
! Destination defined by variable
• $HOME_NET = your network
23

This rule when triggered will alert – meaning it will create an entry in the alerts file and create a log
file, unless these options are overridden by command line options. It also only applies to TCP traffic
that meets the criteria of the rest of the signature.

The source address is specified by the variable EXTERNAL_NET. In most cases

EXTERNAL_NET is set to !$HOME_NET, which means that the source address can be any IP
address except the IPs belonging to your network. The destination address is specified by the
variable HOME_NET. This variable is set to the IP addresses your sensor is to monitor. Both of
these variables are typically defined at the top of a rules file, but may also be set by command line
options.

The source port is set to the keyword ‘any’, meaning that the TCP packet can originate from any
possible port on the source host. However, the packet must be destined for port 21. Port 21 is a well
known reserved port that is used to provide FTP services.

23
 Advanced Rule #1:
Wu-FTP Exploit (cont.)
alert tcp $EXTERNAL_NET any -> $HOME_NET 21 \
(msg: "IDS458 - FTP wuftp260-tf8"; flags: PA; \
content: "|31C0 31DB 31C9 B046 CD80 31C0 31DB \
4389 D941 B03F CD80|";)

! Examine the rule options:

! TCP flags PUSH and ACK must be set.
! Examines payload for specific values.

! Likelihood of false positives:

! Low likelihood of occurrence.
! Low likelihood of being false positive.
24

For this rule, two packet attributes are examined in order to detect the exploit. The first attribute is
the TCP flag settings. For this rule, the PUSH and ACK TCP flags must be set. The second attribute
specified examines the packet’s payload. The examination of a packets payload is triggered by
specifying the keyword ‘content’. In this example the content that is being searched for is given in
hex values, which is denoted by the enclosing pipe (‘|’) symbols.

This rule is tuned ever so slightly by the TCP flags attribute. Only packets with a payload should be
applied against this rule. These packets will have the PUSH flag set indicating that data is being
sent. It’s possible to have other flag settings without the PUSH flag set and still have a payload,
however these are typically other exploits which this rule doesn’t apply to and should have a
different rule written to detect them. The exploit detected here works by initiating a proper TCP
connection, more specifically an anonymous FTP session and initiating a buffer overflow.

For this rule, detects will very rarely occur primarily because of the very specific content that is
being searched for. When detects do occur, it’s very likely that it is a positive detect. The content
value, although possible, is very unlikely to occur during a normal FTP session, hence this rule’s
high level of accuracy.

24
 Advanced Rule #2:
cgitest.exe Exploit
! Background:
! Web exploit.
! Allows arbitrary execution of code on
server.
! Rule:
! alert tcp $EXTERNAL_NET any -> $HOME_NET 80 \
(msg:"IDS265 - Web cgi cgitest"; \
content:"cgitest.exe|0d0a|user"; nocase; flags: AP; \
offset:4;)

25

The second advanced rule we will examine is a web based exploit. The ‘cgitest.exe’ is a CGI that if
it is left installed on a particular web server can allow a remote attacker to execute arbitrary code on
the web server. The exploit works because of a buffer overflow vulnerability, which is one of the
more lethal types of attacks an attacker can use. The web daemon affected by this vulnerability runs
on Windows 95, which limits the possible ramifications of a successful attack that might exist on a
Unix or Windows NT machine.

25
 Advanced Rule #2:
cgitest.exe Exploit (cont.)
alert tcp $EXTERNAL_NET any -> $HOME_NET 80 \
(msg:"IDS265 - Web cgi cgitest"; \
content: "cgitest.exe|0d0a|user"; nocase; \
flags: AP; offset:4;)

! Examine the rule header:

! Will ‘alert’ when triggered.
! Applies only to TCP traffic.
! Source defined by variable
• $EXTERNAL_NET = !$HOME_NET
! Destination defined by variable
• $HOME_NET = your network
26

This rule when triggered will alert – meaning it will create an entry in the alerts file and create a log
file, unless these options are overridden by command line options. It also only applies to TCP traffic
that meets the criteria of the rest of the signature.

The source address is specified by the variable EXTERNAL_NET. In most cases

EXTERNAL_NET is set to !$HOME_NET, which means that the source address can be any IP
address except the IPs belonging to your network. The destination address is specified by the
variable HOME_NET. This variable is set to the IP addresses your sensor is to monitor. Both of
these variables are typically defined at the top of a rules file, but may also be set by command line
options.

The source port is set to the keyword ‘any’, meaning that the TCP packet can originate from any
possible port on the source host. However, the packet must be destined for port 80. Port 80 is one of
the most common ports used for web daemons. If there are web daemons used on your network
using alternative ports, the rule should be duplicated for each of the ports being used.

26
 Advanced Rule #2:
cgitest.exe Exploit (cont.)
alert tcp $EXTERNAL_NET any -> $HOME_NET 80 \
(msg:"IDS265 - Web cgi cgitest"; \
content: "cgitest.exe|0d0a|user"; nocase; \
flags: AP; offset:4;)

! Examine the rule options:

! TCP flags PUSH and ACK must be set.
! Examines payload for specific values.

! Likelihood of false positives:

! Low likelihood of occurrence.
! Low likelihood of being false positive.
27

For this rule, two packet attributes are examined in order to detect the exploit. The first attribute is the
TCP flag settings. For this rule, the PUSH and ACK TCP flags must be set. The second attribute
specified examines the packet’s payload. The examination of a packets payload is triggered by
specifying the keyword ‘content’. In this example the content that is being searched for is a
combination of two sections of ASCII data and one section of hex values. This example shows how
ASCII and hex values can be combined to form a payload signature, and can be interspersed between
each other. Note the use of the ‘nocase’ option. This informs Snort that for the ASCII content being
searched for, it can appear in any possible combination of upper and lower case letters possible.
This rule is tuned ever so slightly by the TCP flags attribute. Only packets with a payload should be
applied against this rule. These packets will have the PUSH flag set indicating that data is being sent.
It’s possible to have other flag settings without the PUSH flag set and still have a payload, however
these are typically other exploits which this rule doesn’t apply to and should have a different rule
written to detect them. The exploit detected here works by initiating a proper TCP connection to a web
server, and then executing the ‘cgitest.ext’ CGI on that server and causing a buffer overflow.
The content attribute can be a very resource intensive attribute to use. To help reduce the overhead of
processing that must take place, it can be tuned by specifying the ‘offset’ and ‘depth’ options. These
options reduce the amount of a packet’s payload that must be inspected by Snort. In this rule, only the
‘offset’ option is used. This rule tells Snort to start examining the payload 4 bytes in, effectively
ignoring the first 3 bytes. This may not seem like a lot, but by ignoring 3 bytes of every packet on a
very busy network can quickly add up.
For this rule, detects will very rarely occur primarily because of the very specific content that is being
searched for. When detects do occur, it’s very likely that it is a positive detect. The content value,
although possible, is very unlikely to occur during a normal web sessions by chance.

27
 Writing Rules

28

In this section will demonstrate how to write a few rules from scratch of increasing difficulty. A
specification for a needed rule will be provided, followed by a possible solution. Keep in mind that
for some types of rules there may be several possible answers, all of which may be correct.

28
 Writing Rules: Simple Rule
! Your boss wants to know about all
ICMP echo requests (pings) coming
into your network. Write the rule
using the variable HOME_NET to
represent your network address space.
The rule should both alert and log.
The alert message should contain the
text ‘Inbound Ping’.

29

Your boss is concerned about inbound ICMP echo requests from outside addresses. He would like to
have Snort record this packets for future analysis and to see if there are any trends. Write the rule,
using the variable HOME_NET to represent your network address space.

Please briefly pause this presentation now and resume it when you have written the rule.

29
 Writing Rules: Simple Rule
(cont.)
! Possible Answer:
alert icmp !$HOME_NET any -> $HOME_NET any \
(msg:“Inbound Ping"; itype: 8;)

30

According to the specification given on the previous slide, the rule is to both alert and log. To do
this, the rule’s action field must be set to the value ‘alert’. We were also told to only record inbound
ICMP echo requests. Therefore the protocol field is set to ICMP, and the source address field is set
to ‘!$HOME_NET’. We were told that the variable HOME_NET would represent our internal
network, so specifying the not sign (‘!’) with the HOME_NET variable represents all addresses
except those in your network.

Snort rules always require a port to be specified, but ICMP does not use ports so we used the
keyword ‘any’ as a placeholder. We could have used any value for this field, it will be ignored by
Snort when evaluating a packet against this rule. It is needed only to satisfy the rule parser when
Snort reads and process the rules file on startup.

In the rules option section we set the message option to the appropriate value as requested. We also
used the ‘itype’ attribute with a value of ‘8’ to limit the rule to only record echo requests – otherwise
known as pings.

30
 Writing Rules: Simple Rule #2
! Corporate headquarters routinely runs
a scan of all IPs owned by the
company, including satellite offices.
Write a rule that will cause Snort to
ignore all inbound TCP packets from
the scanning machine, 192.168.1.1.
The address space at the satellite
office you work at is the Class B
10.1.x.x. What command line option
must also be included?
31

In order to try to keep a step ahead of the hackers, corporate headquarters decided to run a periodic
scan against all IP addresses the company owns, including the satellite office you work at. Tired of
filtering through the false positives caused by this routine scanning, you decided to write a rule to
ignore inbound packets from this scanning box. Also list the command line option that must be
included for this rule to be effective.

Please briefly pause this presentation now and resume it when you have written the rule.

31
 Writing Rules: Simple Rule #2
(cont.)
! Possible Answer:
! pass tcp 192.168.1.1/32 any -> 10.1.0.0/16 any

! Snort Command Line:

! Snort –c snortrules -o

32

This is a simple rule to write, but also has a special requirement that must not be forgotten. To
ignore packets, the rule’s action field must be set to the value ‘pass’. This tells Snort to drop the
packet being inspected when the rule is triggered. This can be a useful capability in order to reduce
false positives or to ignore traffic from a particular host.

You were told this rule should ignore TCP traffic, so the protocol field in the rule was set to the
value ‘TCP’. The source address was set to the specific host from corporate headquarters,
192.168.1.1. Since the source port can vary, the keyword ‘any’ was specified, indicating that we
don’t care what the source port is, it can be any in the entire range possible. The destination address
field is set to the proper CIDR notation for the satellite office, 10.1.0.0/16. The destination port is set
to the same value as the source port, the keyword ‘any’.

In order for this rule to be effective, Snort must be told to process the ‘pass’ rules first. By default
Snort processes alert and log rules first, then the pass rules last. This effectively ignores pass rules.
To reverse this order, you must specify the ‘-o’ option. This causes Snort to process pass rules first,
then alert and log rules.

32
 Writing Rules: Difficult Rule
! Odd behavior has been detected on
your anonymous FTP server. Write
a rule to log all activity to this
server (192.168.1.2) to a single
file. The source of the possible
anomalous behavior is the 10.1.1.0
class C address space.

33

During routine monitoring of your logs on your anonymous FTP server, you have detected some
behavior that just doesn’t seem normal. In order to investigate this matter further, you have decided
to log all FTP activity to this server to a separate log file so you can see the full session. Write a
Snort rule that will accomplish this.

Please briefly pause this presentation now and resume it when you have written the rule.

33
 Writing Rules: Difficult Rule
(cont.)
! Possible Answer:
log 10.1.1.0/24 any -> 192.168.1.2/32 21 \
(msg: “FTP activity to anonymous FTP server”; \
session: printable; logto: “anonftp”;)

34

For this rule, we specified the ‘log’ action. We don’t really want to have every packet’s header
written to the alerts file, we really don’t care about having them. For the source IP we specified the
class C where the potentially hostile traffic is originating from using CIDR notation. Since the
source port can be any of the ephemeral ports, we decided to specify the keyword ‘any’. We could
have specified the range of ports from 1,024 and up, but just in case the traffic is hostile and the
attacker tries to use a reserved port we decided to use ‘any’ instead.

For the destination address we specified its full IP address in CIDR notation, along with the
destination port of 21. Port 21 is the ‘control’ port for FTP sessions where we can record the
commands and responses of the user and server.

To record the activity, we have specified the ‘session’ option which will record all printable (ASCII)
information. We have also redirected the output to the file ‘anonftp’ by using the ‘logto’ option.
This will conveniently log all of the activity to a single file making it easy to review any activity that
is recorded.

34
 Writing Rules: Advanced Rule
! A new (fictitious) probe has been detected
from a new scanner called ‘pr0b3z’. The
scan originates from port 53 to port 53 and
has a TCP sequence number of
123456789 for every packet. The packets
also include the payload ‘Boo!’ and have
only the SYN TCP flag set. The network
being monitored is the class C address
space of 192.168.1.x. Write a rule that will
both alert and log.
35

The next rule to write is one for a new fictitious scan that has been seen recently. This particular
scan use port 53 for both the source and destination ports, and each packet has the same sequence
number. Oddly enough there is a payload of varying length that always contains the string ‘Boo!’
imbedded somewhere. Although there is a payload, the PUSH flag is not set. The only TCP flag set
is the SYN flag.

Please briefly pause this presentation now and resume it when you have written the rule.

35
 Writing Rules: Advanced Rule
(cont.)
! Possible Answer:
alert any 53 -> 192.168.1.0/24 53 \
(msg: “Inbound Scan: Pr0b3z”; \
seq: 123456789; flags: S; content: “Boo!”;)

36

For this rule we set the action field to the standard ‘alert’ action. We want this activity to be written to
both the alert file and the log file – especially if we later run SnortSnarf on these files which we use
during our analysis work. These scans can originate anywhere so we have specified the keyword ‘any’
as the source IP. Since both the source and destination ports use 53, we have set both in the rule to that
number. For the destination addresses we specified our network using standard CIDR notation.

In the rules option section we specified on output message that’s descriptive and will mean something to
us when we review the alerts file and log data later. From the description we have been given the
sequence number is the same for all packets. We used the ‘seq’ packet attribute to specify the sequence
number.

The content option was used to search packets for a payload that contains the ASCII string ‘Boo!’.
According to the description this string can appear anywhere in the payload, so we can’t specify the
‘offset’ or ‘depth’ options to limit the amount of processing Snort will have to do. But, the description
given to use said that the packets only have the SYN flag set, and no other flags. We’ll specify this in
the rule using the ‘flags’ attribute and this will indirectly limit the amount of payload processing Snort
will have to do because although it is possible to have a payload in a SYN packet it is a rare occurrence.

36
 Tying It All Together

37

You have learned how to write rules and all of the syntax and keywords that go along with it. This
last section will what you have learned and tie it all together showing how those rules would be used
in real world situations. Sample Snort output is supplied as well, showing how the detects being
monitored for are provided to you when they are detected.

37
 Specifying Rules File
snort -c snort-lib

ls -l /var/log/snort

drwx------ 2 root root 4096 Mar 22 06:58 192.168.5.5

drwx------ 2 root root 4096 Mar 22 06:58 1.2.3.4
-rw------- 1 root root 2512 Mar 22 06:58 alert

cat alert

[**] NMAP TCP ping! [**]

03/21-13:33:51.880120 1.2.3.4:60216 -> 192.168.5.5:80
TCP TTL:46 TOS:0x0 ID:19678
******A* Seq: 0xE4F00003 Ack: 0x0 Win: 0xC00
38

When using Snort, you will most often use it along with a rules file which tells Snort what to
consider as hostile. The ‘-c’ command line option is the one you will use to do this. With this
option you specify the rules file that you want to use. Snort will process the file to build a list of
anomalies to detect for alerting and logging, and turn on additional options that cannot be specified
by command line options.

After Snort has run for a while and detected anomalous behaviour, it will write the activity to the
alerts file and the log directory and files. The default directory Snort writes all of its output to is
‘/var/log/snort’. Special Note: This directory must already exist. Snort will not create this directory
automatically if it does not exist. Instead, Snort will issue an error message and exit.

While Snort is running, if it detects any packets that match any of the rules it will write the activity
out to the alert file and to a logging subdirectory in a log file. The content of these files is similar,
but the log files can contain additional information the alert files does not if certain options are
turned on.

Examining the alert file, we see that the information it contains is simply the message from the
triggered rule and the header information from the packet.

38
 Specifying Rules File
(cont.)
snort -c snort-lib

cd 192.168.5.5; ls -l

total 12
-rw------- 1 root root 232 Mar 22 06:58 TCP:12345-2985
-rw------- 1 root root 232 Mar 22 06:58 TCP:12346-1611
-rw------- 1 root root 243 Mar 22 06:58 TCP:6969-2701

cat TCP:12345-2985

[**] Netbus/GabanBus [**]

03/21-13:33:54.275350 192.168.5.5:12345 -> 1.2.3.4:2985
TCP TTL:64 TOS:0x0 ID:9173 DF
**S***** Seq: 0x9C9B544A Ack: 0x0 Win: 0x7D78
TCP Options => MSS: 1460 SackOK TS: 9306314 0 NOP WS: 0 39

Continuing from the previous slide, we will examine one of the log subdirectories found in
‘/var/log/snort’. Changing directories to one of the ones listed - 192.168.5.5 - we see
additional files that house all logged activity originating from that IP. For instance, the file
TCP:12345-2985 represents activity from the host 192.168.5.5 that used the TCP protocol and has a
source port of 12345 and a destination port of 2985.

Examining the contents of that file you see that source IP 192.168.5.5 sent IP 1.2.3.4 traffic to
destination port 2985. The reason this traffic was logged there is because a rule fired that checks for
traffic to or from port 12345. A well known trojan named Netbus uses this port.

39
 Log Alerts to Directory ./log

snort -c snort-lib -l ./log

" Output placed in directory ./log

" alerts file contains alerts generated by Snort
" IP subdirectories with logged payloads

ls -l ./log
drwx------ 2 root root 4096 Mar 22 08:16 1.2.3.4
drwx------ 2 root root 4096 Mar 22 08:16
192.168.5.5
-rw-------- 1 root root 2512 Mar 22 08:16 alerts

40

By default, Snort places the logs and alerts in /var/log/snort. You can specify a default
directory by using the ‘-l’ option and the name of the directory where you want the information
placed. In this case, we have created a log file in the current directory and want the activity recorded
there.

Snort will then record all alerts to an alert file in this directory, as well as creating the logging
directories and log files here. This is the same as if everything was written to the default directory
‘/var/log/snort’. Remember – the directory you tell Snort to write the alert and logs to must already
exist. Snort will not create this directory on its own.

40
 Logging Options
• Default: Full logging to default Snort
directory
• Binary: tcpdump binary output to a
single log file
• None: Disable logging
• Database: Log packets to SQL database
• XML: Log packets in portable XML format

41

The default method of logging is to capture the output generated from Snort detects and store it in
the default Snort directory /var/log/snort. Depending on other command line options or rules
options you use, this will log the traffic that triggered the scan in some kind of human readable
format.

Alternatively, you can take any detect that is discovered and log in tcpdump raw output binary
format. This is often done with high traffic volume so as not to bog down Snort with the logging
process.

There are also output plugins available to log packets to a XML formatted file as well as a variety of
SQL databases (e.g. MySQL, PostgreSQL, Oracle)

Finally, logging can be totally disabled if not desired. This is only recommended if you are not
interested in the payload of packets that trigger rules. The log files (or file if you are logging in
binary format) are the only place the FULL packet will be written out to including the payload.

41
 Alerting Options
• Full: writes alert message and header
information to alert file (default)
• Fast: writes alert message and condensed
header to alert file
• None: disable alerts
• Syslog: send alert messages to syslog
• SMB: send WinPopup messages to Windows
hosts via ‘smbclient’
• Database: Send alerts to SQL database
• XML: Write alerts in a portable XML format
42

Alerts are an abbreviated format of capturing the detect. The default method is to capture the detect
in the file /var/log/snort/alert. The fast method writes partial information to the alert file.
None will disable alerting all together.

Full alerting is Snort’s default behaviour. When using this level of alerting, the message (if any) in
the rule is written to the alert file first, followed by a date/timestamp and full packet header
information. Fast alerting on the other hand writes the message (if any) in the rule is again written
first, followed only by a data/timestamp and source and destination ports and addresses. Fast
alerting does not include the full packet header information. Syslog alerts send messages in a format
similar to the fast alerts, but write them to the syslog facilities. There are also options available to
send alerts to a database, Windows host via SMB alerts, as well as to an XML formatted file.

42
 Alert and Logging
Differences
• Alerts are all contained in one file
• Alerts are decoded through transport
layer only
• Logging produces multiple files
• Logging creates a directory structure by
IP numbers
• Subdirectories contain activity - possibly
decoded through application layer

43

You may be wondering what the difference between logging and alerting is. Logging will create
multiple files under multiple directories based on the IP number of the source host. The directory
name (IP number) indicates the source IP that triggered the logging activity, and the contents are
files named according to the protocol and ports involved. The actual contents of the files record the
payload of the packet(s) involved.

Alerts are more abbreviated captures of the detect that can all be found in a single file. This is a
better overview of what is happening on the network versus the more detailed captures for logging.
It also provides a convenient one stop place to do quick searches for items that may be of interest,
such as specific exploits or specific hosts.

Logging and alerting are conceptually different in a few ways. Alerts exist to let the user know that
something has happened and to give that user enough information to decide whether the alert
warrants further investigation immediately. Logs exist to allow the user to analyse the exact packets
that caused an alert in addition to any other packets that are possibly related to the alert event. The
log files are there to allow follow forensic analysis of events, the alert files exist merely to give the
user a single place to monitor for Snort events.

43
 Alert and Logging Format
[**] IDS249 - SMTP Relaying Denied [**]
Alert/Log Message Text
10/09-02:34:59.775359 FF:FF:FF:FF:FF:FF -> FF:FF:FF:FF:FF:FF type:0x800
len:0x71
Date, Timestamp Ethernet (optional)
192.168.1.2:25 -> 192.168.200.2:25432 TCP TTL:255 TOS:0x0 ID:24915 DF
*****PA* Seq: 0x30AC5391 Ack: 0x1E3E4A55 Win: 0x2238

Packet Header (varies)

35 35 30 20 35 2E 37 2E 31 20 3C FF FF FF FF 2D 550 5.7.1 <blah-
FF FF FF FF FF FF 40 FF FF FF FF FF FF FF FF FF blahrs@blahblahb
FF 2E 63 6F 6D 3E 2E 2E 2E 20 52 65 6C 61 79 69 l.com>... Relayi
6E 67 20 64 65 6E 69 65 64 0D 0A ng denied..

Packet Payload, Hex and ASCII (optional, log file only) 44

This slide shows you the general format of the alert and log files. Alert and log records are identical,
with the exception of the packet payload which can be optionally included in the log files. If the
packet payload is included in the logs, both the hex representation of the payload and the ASCII
printable characters will be displayed.

Both log and alert messages start with the message text included in the rule. This essentially labels
each detect as it is written to disk, making it easy to determine why the packet was logged. The next
item written is a date and timestamp. The date and timestamp represent the time on the sensor when
the detect was made. Optionally following the date and timestamp is the ethernet information. Next,
the source and destination addresses and ports involved in the detect appear, followed immediately
by the packet’s decoded header information which can vary depending on the protocol of the packet.

44
 Logging/alert Examples
• The following rule will be used to test
various options to log and alert:

alert tcp any any > 192.168.143.0/24 21 \

(msg: "anonymous FTP attempt"; flags: PA; \
Content: "anonymous"; nocase)

• Place the above rule in rules file

‘snortrules’.

45

In the next several slides, different options will be shown to explain various logging and alerting
choices. The above rule will be used for most of the detects.

This rule says that we want to alert if any ftp connection is generated to the 192.168.143 network
that has the PUSH and ACK flags set and has a content of 'anonymous' in the payload. We will put
this single rule in the rules file name ‘snortrules’ to simplify the logging and alert messages
generated.

45
 Alert and Log
snort -l logdir -c snortrules

In directory logdir you will find a file named alert.

[**] Anonymous FTP attempt [**]

04/28-11:58:06.350754 192.168.143.15:1536-> 192.168.143.16:21
TCP TTL:64 TOS:0x10 ID:18558 DF
*****PA* Seq: 0x7C451B73 Ack: 0x7DC44632 Win: 0x7D78
TCP Options => NOP NOP TS: 27713449 92831

46

In this first example, we specify that we want to use a default logging directory of logdir. This has to
be an existing directory. We run Snort using our one rule found in ‘snortrules’. Next, what you
don't see above is we attempt to ftp to a host on the 192.168.143 network using a username of
anonymous. That triggers a detect and causes Snort to create an entry in the alerts file.

If we examine the contents of logdir directory, we notice that there is a file named ‘alert’. It
contains the output that was generated for the detect, in this case since we did not specify the alert
level Snort will default to ‘full’. It contains the packet information decoded through the TCP
transport layer as can be seen by examining the file.

46
 Alert and Log (Cont)
The directory logdir contains a subdirectory named:
192.168.143.15.

The subdirectory 192.168.143.15 contains a file:

TCP:1536-21

[**] Anonymous FTP attempt [**]

04/28-11:58:06.350754 192.168.143.15:1536 -> 192.168.143.16:21
TCP TTL:64 TOS:0x10 ID:18558 DF
*****PA* Seq: 0x7c451b73 Ack: 0x7dc44632 win: 0x7d78

TCP options => NOP NOP TS: 27713449 92831

47

In the same logdir directory, we discover a subdirectory 192.168.143.15 that represents the
hostile IP that attempted the anonymous ftp access. This is a log directory. If we ‘cd’ into that
directory, we discover a file name TCP:1526-21. The filename identifies the protocol (TCP) as
well as the source (1526) and destination ports (21) involved in the detect. We find the same
message generated in the alert file.

47
 Alert and Log With
Decode
snort -l logdir -c snortrules -d

In directory logdir the file alert has the

following contents:

[**] Anonymous FTP attempt [**]

04/28-12:03:59.888357 192.168.143.15:1537 -> 192.168.143.16:21
TCP TTL:64 TOS:0x10 ID:20566 DF
*****PA* Seq: 0x7C451B73 Ack: 0x7DC44632 Win: 0x7D78
TCP Options => NOP NOP TS: 27713449 92831

48

Now we add the ‘-d’ option to the same command used previously, which says to decode the
application layer. We follow the same process as before and discover that we have an alert file in
logdir which is the same as before. Note that the contents of the alert file have not changed
from what would normally be recorded.

The alert file still contains the message from the triggered rule, the date/timestamp and the hosts
involved. It also still contains the full packet header information, still written in a human readable
format.

48
 Alert and Log With
Decode (Cont)
The directory logdir contains the subdirectory
192.168.143.15.

The directory 192.168.143.15 contains file named:

TCP:1537-21

[**] Anonymous FTP attempt [**]

04/28-12:03:59.888357 192.168.143.15:1537 ->192.168.143.16:21
TCP TTL:64 TOS:0x10 ID:20566 DF
*****PA* Seq: 0x94102D52 Ack: 0x94529A7B Win: 0x7D78
TCP Options => NOP NOP TS: 27748803 128108
55 53 45 52 20 61 6E 6F 6E 79 6D 6F 75 73 0D 0A USER anonymous..
49

If you now look at the log file, you will not only see the information contained in the alerts file, but
now the actual payload of the packet at the bottom of the alert. The output of the packet’s payload is
broken into two parts. The left portion contains the hex values of the payload, while the right portion
contains the ASCII representation.

49
 Alert and Log in Binary
snort -l logdir -c snortrules -d -b

The directory logdir contains the file alert.

[**] Anonymous FTP attempt [**]

04/28-11:58:06.350754 192.168.143.15:1536 -> 192.168.143.16:21
TCP TTL:64 TOS:0x10 ID:18558 DF
*****PA* Seq: 0x7C451B73 Ack: 0x7DC44632 Win: 0x7D78
TCP Options => NOP NOP TS: 27713449 92831

50

The ‘-b’ option allows you to log the packets to a tcpdump file instead of the normal decoded ASCII
files. This creates a single binary file instead of creating many subdirectories with files in them that
may contain only one packet.

If you are deploying Snort on high capacity networks or Snort starts to drop packets, log in binary
format. Logging using the binary format is much more efficient than having Snort write out a
completely decoded packet in an ASCII format. It also relieves Snort from having to create
directories and constantly opening and closing files to write out the information in ASCII format.
Instead Snort can open one file and continuously write to that file for the entire duration Snort is
running.

50
 Alert and Log in Binary
(Cont)
In directory logdir we find the
following file:
snort-0428@1158.log

This is a tcpdump binary output of

entire packet.

51

In the logdir directory, we find a file snort-0428@1158.log which is a tcpdump raw binary
output file of the detect that was captured. The name has the date of the capture (0428 - April 28th)
and the time of the capture (11:58 AM). This can be read either using Snort with the ‘-r’ option or
with tcpdump with the ‘-r’ option. This requires less work of Snort to capture and is used when
there is a lot of traffic on the network and there is a concern for packets being dropped.

51
 Reading Tcpdump Files
snort -vd -r tcpdump.raw.data
Initializing Network Interface...
snaplen = 144
Entering readback mode....

03/21-13:33:51.960219 1.2.3.4:1398 -> 192.168.5.5:2307

TCP TTL:64 TOS:0x0 ID:7569 DF
**S***** Seq: 0x9C857C3C Ack: 0x0 Win: 0x7D78
TCP Options => MSS: 1460 SackOK TS: 9306083 0 NOP WS: 0

03/21-13:33:51.960269 1.2.3.4:1399 -> 192.168.5.5:693

TCP TTL:64 TOS:0x0 ID:7570 DF
**S***** Seq: 0x9C55968F Ack: 0x0 Win: 0x7D78
TCP Options => MSS: 1460 SackOK TS: 9306083 0 NOP WS: 0 52

Another useful ability of Snort is the ‘-r’ command line option. This option instructs Snort to read
from tcpdump binary files instead of the network interface. This can be done if you've collected data
using tcpdump from another sensor or other tcpdump compatible software, or instructed Snort to log
in binary. In the example shown here, we are using Snort in verbose mode, sending the data to the
screen, but this time we use the ‘-r’ switch to tell Snort to read its input from
‘tcpdump.raw.data’ instead of from the network interface. This assumes that we have collected
‘tcpdump.raw.data’ earlier and it contains tcpdump binary data.

Note the ‘Entering readback mode’. This is Snort’s way of informing you that it is reading from a
file and not from the network interface. Also, note the ‘snaplen = 144’. That is the tcpdump
snapshot length, indicating that the software used to create the dump file collected 144 bytes for each
packet collected.

Readback mode can be especially useful for busy networks where full and constant processing on the
sensor itself may not be feasible. In that case you can pull the data back periodically and run Snort
on the retrieved data without using extra CPU cycles on the sensor itself.

52
 Snortsnarf.Pl
• perl script to take alerts:
– Formats Snort alert and log files into html output
– Places output in following files for ‘drill down’:

• Overall summary of detected alerts (index.html)

• Alert wrap-up html files
• Specific source/destination alert html files
• Optionally linked to log files for packet inspection

• Located in snort directory contrib subdirectory

• http://www.silicondefense.com/snortsnarf/

snortsnarf.pl /var/log/snort/alert
53

There are tools available that will help you with the analysis of the alert and log files. One tool that
has proven to be popular as well as being very useful is SnortSnarf. The SnortSnarf program is
intended to help you view your Snort alerts in an orderly fashion using a web browser. This is easier
than trying to assess what is happening by looking at the alerts file, and allows you to drill down
from the general list of alerts to the specific packet that triggered the alert (providing logging was
turned on and the decode option was specified).

At the top level, SnortSnarf creates an index.html file containing a summarized list of alerts. At
the next level down, an html file is created containing each of the same alerts in a single file. If
logging was turned on in Snort, and you provide the directory the logs are located in, SnortSnarf
will allow you to drill down to the packet that triggered a specific alert.

53
 SnortSnarf Output
Snortsnarf: Snort signatures in snort.alert et al
7 alerts processed.
Files included:
•snort.alert
•snort_portscan.log
Earliest alert at 02:34:59.775359 on 10/09
Latest alert at 03:00:36 on 10/9

Signature (click for definition) # Alerts # Sources # Destinations Detail link

IDS249 - SMTP Relaying Denied 1 1 1 Summary

UDP scan 6 1 1 Summary

Generated by Snortsnarf v100400.1 (Jim Hoagland and Stuart Staniford)

54

This is a sample index page created by SnortSnarf. This page contains a summarized list of alerts
that were triggered during the time period listed. It lists the signatures that were detected, number of
times it was triggered, and the total number of source and destination hosts involved. To see
additional details, click on the summary link which will display a page containing information about
the selected alerts.

For some signatures, such as the ‘SMTP Relaying Denied’ example shown here, you can click on the
signature name and a page displaying information about the signature will be displayed. The
information displayed can include a sample rule that would detect the traffic, sample packets, and
further explanation of the exploit.

54
 Summary of alerts in snort.alert et al for signature:
IDS249 - SMTP Relaying Denied
1 alerts on this signature.
Looking in files:
•snort.alert
•snort_portscan.log
Earliest such alert at 02:34:59.775359 on 10/09
Latest such alert at 02:34:59.775359 on 10/09
IDS249 - SMTP Relaying Denied 1 sources 1 destinations

Sources triggering this attack signature

Source # Alerts (sig) # Alerts (total) # Dsts (sig) # Dsts (total))

192.168.1.2 1 1 1 1

Destinations receiving this attack signature

Destinations # Alerts (sig) # Alerts (total) # Srcs (sig) # Srcs (total))

192.168.200.2 1 1 1 1

Generated by Snortsnarf v100400.1 (Jim Hoagland and Stuart Staniford) 55

When clicking on the link from the summarized index page, you arrive at this page. This page lists
all of the source and destination hosts involved with the selected alert. In this case only one alert of
the type ‘SMTP Relaying Denied’ is listed and it involved only one source and destination IP. If
there were multiple instances of this alert, they would all be listed here, including all of the hosts that
were involved.

Clicking on the source IP address will take you to the alerts triggered by that source host for this
signature. The chart to the right of the address shows you how many alerts were triggered by that
host for this specific alert, the grant total of alerts triggered by the host for all alerts, and the number
of destination hosts involved for both of those totals.

55
All 1 alerts from 192.168.1.2 in snort.alert et al
Looking in files:
•snort.alert
•snort_portscan.log
Earliest: 02:34:59.775359 on 10/09
Latest: 02:34:59.775359 on 10/09
1 different signatures are present for 206.181.216.216 as a source

•1 instances of IDS249 - SMTP Relaying Denied

There are 1 distinct destination IPs in the alerts of the type on this page.

Whois lookup at: ARIN RIPE APNIC Geektools

192.168.1.2

DNS lookup at: Amenesi Riherds Princeton

[**] IDS249 - SMTP Relaying Denied [**]

56

56