Tài liệu Snort rules application docx

1
1
Snort Rules: Application
Paul Ritchey,
Jacob and Sundstrom, Inc.

V1.0.0
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.
2
2
Agenda
!
Rule Analysis
!
Simple Rules
!
Difficult Rules
!
Advanced Rules
!
Writing Rules
!
Simple Rules
!
Difficult Rules
!
Advanced Rules
!

Tying It All Together
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.
3
3
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.
4
4
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
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.
5
5
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.
6
6
Simple Rule #1:
Back Orifice (cont.)
!
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
alert UDP $EXTERNAL any -> $INTERNAL 31337 \
(msg: "IDS188/trojan-probe-back-orifice";)

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.
7
7
Simple Rule #1:
Back Orifice (cont.)
!
Examine rule options.
!
No packet attributes are examined.
!
Only includes message.
!
Possibility of false-positives:
!
Low likelihood of occurrence.
!
High likelihood of false-positives.

alert UDP $EXTERNAL any -> $INTERNAL 31337 \
(msg: "IDS188/trojan-probe-back-orifice";)
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.
8
8
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.
9
9
Simple Rule #2:
Deep Throat (cont.)
!
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
alert udp any 2140 -> $HOME_NET 60000 \
(msg:"IDS106 - BACKDOOR SIGNATURE - \
DeepThroat 3.1 Server Active on Network";)
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.
10
10
Simple Rule #2:
Deep Throat (cont.)
!
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.
alert udp any 2140 -> $HOME_NET 60000 \
(msg:"IDS106 - BACKDOOR SIGNATURE - \
DeepThroat 3.1 Server Active on Network";)
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.
11
11
Rule Analysis: Complex Rules
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.
12
12
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 positives
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.
13
13
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;)
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.
14
14
Complex Rule #1:
NetMetro (cont.)
!
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
alert tcp $EXTERNAL_NET 5031 -> $HOME_NET !53:80 \
(msg:"IDS79 - BACKDOOR SIGNATURE - NetMetro Incoming
Traffic"; flags:PA;)
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.
15
15
Complex Rule #1:
NetMetro (cont.)
!
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.
alert tcp $EXTERNAL_NET 5031 -> $HOME_NET !53:80 \
(msg:"IDS79 - BACKDOOR SIGNATURE - NetMetro Incoming\
Traffic"; flags:PA;)
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.
16
16
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;)
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.
17
17
Complex Rule #2:
Myscan (cont.)
!
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
alert tcp $EXTERNAL_NET 10101 -> $HOME_NET any \
(msg: "IDS439 - Scan -myscan"; ttl: >220; \
ack: 0; flags: S;)
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.
18
18
Complex Rule #2:
Myscan (cont.)
!
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.
alert tcp $EXTERNAL_NET 10101 -> $HOME_NET any \
(msg: "IDS439 - Scan -myscan"; ttl: >220; \
ack: 0; flags: S;)
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.
19
19
Complex Rule #2:
Myscan (cont.)
!
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.
alert tcp $EXTERNAL_NET 10101 -> $HOME_NET any \
(msg: "IDS439 - Scan -myscan"; ttl: >220;
\
ack: 0;
flags: S;)
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).
20
20
Rule Analysis: Advanced Rules
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.
21
21
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 positives
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.
22
22
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|";)
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.
23
23
Advanced Rule #1:
Wu-FTP Exploit (cont.)
!
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
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|";)
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.
24
24
Advanced Rule #1:
Wu-FTP Exploit (cont.)
!
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.
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|";)
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.
25
25
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;)
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.