Snort

An Open Source NIDS

1
Typical locations for NIDS's

2
 Snort Intro.
●
Developed by Martin Roesch
●
Available at www.snort.org
●
Available for Win, Linux, Mac, UNIX etc.
●
Commercial version is called Sourcefire
●
Sourecefire acquired by Cisco for $2.7 billion in 2013
●
Snort is a signature based NIDS that uses rules and
preprocessors to analyze traffic
●
Using the rules, signatures for network based attacks can
be created.

3
 Snort Intro. (2)

●
Can be used as a sniffer, like tcpdump, but not as powerful
●
Its main usage is as a NIDS
●
Its preprocessors gives snort the capability to examine a
stream of traffic, as opposed to just a single packet.

4
 Some Commercial NIDS
●
Cisco ●
Fortinet
●
Tipping Point ●
Crossbeam
●
TopLayer ●
Enterasys Dragon
●
McAfee Intushields ●
Arbor Networks
●
Proventia from IBM Peakflow X
– network behavioural
●
ISS anomaly detection
●
Juniper

5
 What can snort do?

●
The real power of snort lies in its ability to read in a rule
set, observe the traffic going across the wire, and detect if
any of the traffic matches any of the rules.
●
Rules can be created that watch for many forms of attack
●
When a rule fires, an alert is generated
●
Alerts are sent to a file : normally the alert file, but we
can change that at the command line.

6
 TCP/IP Layer Model

Physical layer
Snort works on network (IP) layer, transport (TCP/UDP)
layer protocol, and application layer
7
 Snort Modes
●
Three main operational modes
– Sniffer Mode (snort -v)
– Packet Logger Mode We are mainly
concerned with
– NIDS Mode this mode
– (Forensic Data Analysis Mode)
●
We specify which mode we are using via command line
switches
– Snort by default tries to go into NIDS mode, where it
looks for its configuration file, normally at
/etc/snort/snort.conf

8
 Snort Output
●
Various output options available
– Database (MySQL, PostgreSQL, Oracle,
unixODBC, etc)
– XML (snml DTD from CMU/CERT)
– Tcpdump binary format
– Unified (Snort specific) format
– ASCII, syslog, WinPopup (SMB)
– Etc.

9
 What do Packet Dumps look like
in Snort?
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

11/09-11:12:02.954779 10.1.1.6:1032 -> 10.1.1.8:23

TCP TTL:128 TOS:0x0 ID:31237 IpLen:20 DgmLen:59 DF
***AP*** Seq: 0x16B6DA Ack: 0x1AF156C2 Win: 0x2217 TcpLen: 20
FF FC 23 FF FC 27 FF FC 24 FF FA 18 00 41 4E 53 ..#..'..$....ANS
49 FF F0 I..

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

11/09-11:12:02.956582 10.1.1.8:23 -> 10.1.1.6:1032

TCP TTL:255 TOS:0x0 ID:49900 IpLen:20 DgmLen:61 DF
***AP*** Seq: 0x1AF156C2 Ack: 0x16B6ED Win: 0x2238 TcpLen: 20
0D 0A 0D 0A 53 75 6E 4F 53 20 35 2E 37 0D 0A 0D ....SunOS 5.7...
00 0D 0A 0D 00 .....

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

10
How is it different from tcpdump?

11:16:35.648944 10.1.1.8.23 > 10.1.1.6.1033: P 16:34(18) ack 16 win 8760 (DF) (ttl 255, id 49913)
4500 003a c2f9 4000 ff06 a2b4 0a01 0108
0a01 0106 0017 0409 1cf9 e7f6 001a e050
5018 2238 31c6 0000 fffe 1fff fe23 fffe
27ff fe24 fffa
11:16:35.649457 10.1.1.6.1033 > 10.1.1.8.23: P 16:19(3) ack 34 win 8727 (DF) (ttl 128, id 57861)
4500 002b e205 4000 8006 02b8 0a01 0106
0a01 0108 0409 0017 001a e050 1cf9 e808
5018 2217 6f19 0000 fffc 1f20 2020

11
 NIDS Mode

●
What it is best known for
●
Uses all phases of Snort + plug-ins to analyze
traffic for both misuse detection and
anomalous activity

12
 NIDS Mode (2)
●
Snort uses rules to check for an intrusion.
●
If a rule is matched, either an alert or a log
entry is generated.
●
A wide variety of rules are available for its
signature engine
●
Rule example:

alert tcp any any -> $HOME_NET 3389 \

(msg:”RDP attack”; content: “|67 B4 3A|”;)

13
Packets that match the Snort rule on the
previous slide

67 A4 3A

Payload

Dest Port = 3389

TCP Header

Dest IP is in
$HOME_NET
IP Header

14
Snort Rules

15
Sample Snort Rule (1)

16
Sample Snort Rule (2)

17
Sample Snort Rule (3)

18
Sample Snort Rule (4)

19
Sample Snort Rule (5)

20
 Sources of Snort Rules
●
Snort Subscriber Rule Set is made available to users in the
following ways:
– Subscribers will receive rulesets in real-time as they are
released to Cisco customers - 30 days ahead of registered
users
– Subscription : $30/year for personal per sensor, and
$400/year for business per sensor
– Registered users (it is free to register) will receive rulesets
30 days after Subscribers.
– Unregistered users will receive access to the community
ruleset.
●
The Community Ruleset is freely available to all users.

Source:https://www.snort.org/products
21
 Rule Actions

●
Snort allows an action to be added to each rule, which
indicates what to do when a rule is triggered.
●
The action is usually alert or log.
●
An action of alert means to write the offending packet to a
file named alert which is often in /var/log/snort (or in a
directory called log in windows)
●
The next slide has an example of an entry in the alert file

22
 Rule Output (1) user assigned this
message in the alert
rule
[**] NMAP ACK Scan [**]
03/21-15:23:56:665120 172.16.10.5:1028 ->
192.168.7.3:80
IP Id. Number

TCP TTL:40 TOS:0x0 ID 18675

***A**** Seq: 0xE2A0005 Ack:0x0 Win: 0xC00

TCP Window
TCP Sequence No.
size
TCP Flags Ack.
Number
23
 Rule Output (2)
●
This rule was probably generated because the packet
was a TCP packet with the ACK bit set but with an
ACK value of 0, usually a sign of an nmap ack scan
attempting to locate a live host.

●
Someone was running an ACK scan against our web
server at 192.168.7.3

24
Running Snort

25
Running Snort – some command line options

# snort -d -h 192.168.1.0/24 -l ./log \

-c /etc/snort/snort.conf -s -i eth0 -D

-d dumps the application layer (more later on this)

-h home network
-l log location (dir. where log actions are sent)
-c where the snort configuration file is
-s log alerts to syslog
-i interface to listen on
-D run snort as a background process (daemon mode)

26
 Running Snort (2)
●
In this example, /var/log/messages will contain snort alerts, as we
have sent logs to syslog. (not a good idea)
●
If we had not done that, alerts are sent to /var/log/snort/alert (in
Daemon mode – see the man page).

●
We normally just use the following to run snort
snort -i ethX -c /etc/snort/snort.conf -D
●
The first time you run snort with a new rule set it may be a good
idea to leave the -D switch off so you can ensure snort loads with no
errors.

27
 Running Snort (3)
●
Test your configuration file:
snort -T -c /etc/snort/snort.conf

●
To send alerts to the console:
snort -A console

●
If you don't want error messages:
snort -K none

28
 Running Snort (4)
●
We can also run snort against a PCAP

snort -r traffic.pcap

●
We can also run snort against a PCAP using a specified
configuration file:
snort -c snort_pcap.conf -r traffic.pcap

29
 Running Snort (5)
●
-v : verbose

●
-d: ​displays the application layer data when in verbose or
packet logging mode.­

●
-e: ​displays or logs the link layer packet headers.

●
-A full: ​generates an alert using one of the specified alert ­
modes:fast,full,none and unsock. In this case we used the full
alert mode.­

30
 Running Snort (6)
●
-­ k none: ​disables Snort’s internal checksum verification. We
needed this to catch all the packets, because if it’s enabled,
then in some cases Snort can capture a local packet before the
Network Interface Card computes the checksum. Then it sees
the checksum as 0, and interprets it as a bad checksum and thus
does not inspect the packet.

●
-P 65535 : override the default snaplen of 1518 bytes, and
apply the rules to packets of size 65535 (the max possible)

31
Snort Configuration

32
 A look into /etc/snort/snort.conf

ipvar HOME_NET 10.1.1.0/24

ipvar EXTERNAL_NET !$HOME_NET
ipvar HTTP_SERVERS $HOME_NET
ipvar DNS_SERVERS [192.168.1.5, 192.168.5.3]
portvar HTTP_PORTS 80
ipvar RULE_PATH /etc/snort/rules

include $RULE_PATH/local.rules
include $RULE_PATH/bad-traffic.rules
include $RULE_PATH/exploit.rules
33
 local.rules
●
It is recommended that you put your own local rules
in
/etc/snort/rules/local.rules

●
Back up this important file

34
 Snort rules in detail
Next, we examine in more detail what snort rules look
like and how to write them

35
 Writing Snort Rules (1)
●
A rule can be broken into 2 parts:
– rule header (up to the first bracket)
– rule options
●
the header defines what must be involved for the rule to be
considered by the rule options
●
the options defines what must be involved, including the
packet header or payload
●
Note that snort rules are stateless, in that each rule inspects
one and only one packet, and does not take other packets
into consideration.
– Snort tries to build in state via a preprocessor.

36
 Writing Snort Rules (2)
Most Snort rules are written in a single line. This was required in
versions prior to 1.8, but in current versions of Snort, rules may
span multiple lines by adding a backslash to the end of the line.

rule header rule options

37
 Writing Snort Rules (3)

Header Options

alert tcp !192.168.34.0/24 any -> 192.168.55.3 79 (msg:”finger attempt”;)

Action Src IP Src Port Dest IP Dest Port Colon

Protocol Direction Option Option

Keyword terminator

Option
Argument

38
 Writing Snort Rules (4)

alert tcp any any -> 192.168.1.0/24 111 \

(content:"|00 01 86 a5|"; msg:"mountd
access";)

pattern in the packet's payload

we are searching for message to print
keyword in alert file

39
 snort rule header
●
The header contains the following fields:
– Action (log,alert)
– protocol (ip, tcp, udp, icmp, any)
– src IP and port
– Direction operator ( “->”, “<>”)
– Dst IP and port

40
 Snort Rules (1)
●
Snort rules are often summarised as follows:
ACTION PROTOCOL IP[/mask] PORT ->
IP[/mask] PORT (OPTIONS)
●
where =IP is
– A specific address such as 10.1.1.101
– A range of addresses using CIDR notation mask:
10.1.1.0/24 or 10.1.0.0/16
– List of comma separated addresses and ranges:
10.1.1.101,192.168.1.0/24
– A variable such as $HOME_NET
– Any address using the any keyword
41
 Snort Rules (2)
●
PORT is
– A specific port such as 22
– A range of ports such as 3000:6000
– Port ranges lower than (example all privileged ports)
:1024
– Port ranges above (example all non-privileged ports)
1024:
– Any port using keyword any
– Use an exclamation mark, !, for port/range negation: !22
– A list of ports, such as [22,23,25,80,443]

42
 Snort Rules (3)
●
The option field is enclosed by parenthesis using a semi-
colon as an option delimiter. Snort will ignore white space
in the options allowing users to create easy to read option
rules.
●
Thus, we can have
( option ;)
●
or
( option ; option ;)

43
 Snort Rules (4)
●
Option rules are applied to perform some action or
select packet with finer granularity than the generic
snort rule.

44
 Snort Rule Action (1)
The rule action tells Snort what to do when it finds a packet that
matches the rule criteria. There are 8 available default actions:
1) alert - generate an alert using the selected alert method, and then
log the packet
2) log - log the packet (but don't create an alert)
3) pass – ignore the packet
4) drop – block and log the packet
5) reject – block, log and send either TCP Reset or ICMP
Unreachable (UDP)
6) sdrop – silent drop – block but do not log
7) activate – activate another rule
8) dynamic – dynamically enabled by activate rule

45
 Snort Rule Action (2)
The default order of rule processing is
activate
dynamic
pass
drop
sdrop
reject
alert
log
You can change this at the command line ( --alert-before-pass, --treat-
drop-as-alert) or in snort.conf (using the “config order:”)

46
 log action
●
logged packets are saved, by default, in tcpdump binary
format in a file in the directory /var/log/snort
●
The file is called tcpdump.log.TIMESTAMP
●
This can be changed by tweaking the configuration file
●
To read the tcpdump formatted file use
tcpdump -r <file-name>
●
If you want to have your logs in ascii, add
-K ascii
●
to the command line

47
 Rule Example (1)
alert tcp $EXTERNAL_NET any -> $HOME_NET any
(msg:"SCAN ipEye SYN scan"; flow:stateless; flags:S;
seq:1958810375; reference:arachnids,236;
classtype:attempted-recon; sid:622; rev:7;)

tcp this relates to the protocol type in use

$EXTERNAL_NET is used to state traffic coming in from an
external source i.e.: Internet
any this says that any port applies i.e.: no specific port stated
-> the director symbol show the flow of traffic in this case from
external to internal
$HOME_NET is used to identify the home network
48
 Rule Example (2)
alert tcp $EXTERNAL_NET any -> $HOME_NET any
(msg:"SCAN ipEye SYN scan"; flow:stateless; flags:S;
seq:1958810375; reference:arachnids,236;
classtype:attempted-recon; sid:622; rev:7;)

msg:"SCAN ipEye SYN scan" will be the message printed out

when the signature fires
flow:stateless is used to have the signature fire regardless of the
state of the session
flags:S is used to specify exact TCP flags or flag combinations
seq:1958810375 is used to look for a specific TCP sequence
number
49
 Rule Example (3)
alert tcp $EXTERNAL_NET any -> $HOME_NET any
(msg:"SCAN ipEye SYN scan"; flow:stateless; flags:S;
seq:1958810375; reference:arachnids,236;
classtype:attempted-recon; sid:622; rev:7;)

reference:arachnids,236 is used to identify a specific signature in

the Arachnids IDS database ( an old database of snort rules)
classtype:attempted-recon is used to denote what classtype the
signature belongs to
sid:622 is a value used to uniquely identify Snort signatures
rev:7 is used to identify the revision number for the signature

50
The following slides will
examine some of the
snort options in more
detail

51
 Rule Option : msg
●
assign an appropriate message to the output of a triggered
rule
●
e.g.
alert udp any any -> 192.168.5.0/24 31337 \
(msg:”Back Orifice”;)
●
will cause the following to be added to the start of the alert
file entry generated:

[**] Back Orifice [**]

52
 31337
●
31337
●
ELEET
●
Known as the ELEET Port
●
Used by Back Orifice (often shortened to BO)
Backdoor System (Remote Admin Tool) circa 2000

53
 Rule Option : sid
●
snort rule id
●
Identifies a snort rules by ID uniquely
●
syntax is sid:<number>
●
As a rule of thumb you should always start your custom rules
at a number greater than one million. This allows your rules
not to collide with any other rules previously defined in a
snort system.
●
eg sid:1000001;

54
 Rule Option : logto
●
allows you specify the filename to which activity is to be logged.
●
normally sent to a default file, or to a file specified by the -l
option.
●
can be used to send the output of a specific rule to a specific file.
●
e.g.
alert udp any any -> 192.168.5.0/24 31335 \
(msg:”trinoo port”; logto:DDoS;)
●
output will be logged to /var/log/snort/DDoS

55
 Rule Option : ttl (1)
●
allows you examine the TTL field
e.g.
alert udp any any -> 192.168.5.0/24 \
33000:34000 (msg:”unix traceroute”; ttl:1;)

●
logs traffic to the subnet 192.168.5.0/24 with a UDP port range
of 33000 to 34000 and an arriving TTL value of 1

56
 Rule Option : ttl (2)
How traceroute works
TTL =1

ICMP TimeX
attacker Hop 1 Hop 2 victim

57
 Rule Option : ttl (3)
How traceroute works
TTL =2 TTL =1

ICMP TimeX

attacker Hop 1 Hop 2 victim

58
 Rule Option : id
●
specifies a IP Identification field value
●
e.g.
alert ip any any -> 192.168.5.0/24 any \
(msg:”suspect IP Id value”; id:0;)

59
 Rule Option : ipopts
●
IPv4 Options including Record Route (rr), Time Stamps
(ts), Loose Source Routing (lsrr), Strict Source Routing
(ssrr)
●
The following alerts on finding a loose source routed packet

alert ip any any -> any any (ipopts: lsrr;

msg: "Loose source routing attempt";)

60
 Rule Option : dsize
●
examine the size of the payload
●
e.g.
alert icmp any any -> 192.168.5.0/24 any \
(msg:”large ICMP payload”; dsize: >1024;)
●
can also use
dsize: <1024
dsize: 1024 (exactly 1024 bytes)
dsize : 5<>20 (between 5 and 20 bytes)

61
 Rule Option : seq
●
examine the value of the TCP sequence number
●
e.g.
alert tcp any any -> any any \
(msg:”possible DDoS”; seq:0x28374839;)

●
matches Shaft DDoS traffic which is know to have a fixed
sequence number value (very old system)

62
 Rule Option : ack
●
examine the value of the TCP acknowledgement
number
●
e.g.
alert tcp any any -> any any \
(msg:”nmap ACK scan”; flags:A; ack:0;)

●
matches packets with the ACK bit set, and with an
acknowledgement value of 0.

63
 Rule Options : itype and icode

●
used to select ICMP packets with particular types and codes
(see the tcpdump cheat sheet)
●
e.g.
alert icmp any any -> any any \
(msg:”host unknown”; itype:3; icode: 7;)

●
matches icmp packets with type 3 and code 7, which is
destination host unknown

64
 Rule Option : fragbits (1)
●
3 flags in the IP header :
– Reserved Bit (RB), which is reserved for future
use, but should be zero
– Don’t Fragment Bit (DF).
– More Fragments Bit (MF).
●
D is used for DF bit. You can use R for reserved bit and M
for MF bit.

65
 Rule Option : fragbits (2)
The following rule will alert on fragmented packets
alert ip any any -> any any \
(fragbits:M; msg:"Fragmented Packet";)

The following rule will alert if the reserved bit is set

alert ip any any -> any any \
(fragbits:R; msg:"Evil Bit set";)

66
 Rule Option : flags (1)
●
used to inspect TCP flag settings
●
Valid flags are S for SYN, F for FIN, R for RST, P for PSH, A for
ACK, U for URG, 2 for ECN echo, 1 for ECN congestion and 0 for
no flags set.
●
e.g.
alert tcp any any -> any any \
(flags:SF,12; msg:"Possible SYN FIN scan";)

●
matches packets with only the SYN and FIN flags set, ignoring the
two congestion bits

67
 Rule Option : flags (2)
●
You can prepend either a + , *, or ! to the flags,
+ match on all the flags plus any others,
* match on any of the flags,
! match if none of the flags are set.
●
e.g.
flags:+SF (S and F must be set + any others)
flags: *RAS (any of R or A or S must be set)
flags: !SPU (none of S or P or U must be set)

68
 Rule Option : content (1)
●
check if the payload contains specific content
●
there are many ways to supply the content, and multiple
contents can be sought
●
can be computationally expensive
●
ideally should be qualified with other options such as offset
and depth
●
the content option is always tested last by snort, even if it is
the first option listed.
●
Content can be listed in ascii or hex

69
 Rule Option : content (2)
●
text (ascii) strings are enclosed in quotes (“) and are case sensitive,
unless the nocase option is used.
●
hex code is delimited by the pipe symbol (|).
●
e.g.
alert tcp any any -> any any \
(msg:"Possible buffer overflow attempt"; \
content:"|90 90 90 90|";)
●
This digit, 0x90, is the hexadecimal equivalent of the NOP
instruction on the x86 architecture, and is often seen in exploit code -
buffer overflow exploits.

70
Rule Options : content, offset, depth

●
If you wanted to limit content matches to starting at say byte 40 and
75 bytes in all, of the data portion of a packet, you could modify the
previously shown rule to look like this:
alert tcp any any -> any any \
(msg:"computer mentioned";
content:"Computer"; offset:40; depth:75;)
●
You can also match against packets that do not contain the specified
sequence by prefixing it with a !

71
 Rule Options : offset, depth

●
By default, content searches start at the first byte of the
payload, which is considered to be offset 0. We can
change this using the offset option.

●
depth helps limit the amount of processing snort must do
on content searches.
●
it specifies the number of bytes to search from the offset.

72
 Rule Options : Distance, Within
Depth is how far to LOOK into the payload from the start of the
payload.
Offset is how far to SKIP into the packet from the beginning of the
payload before looking for the current match
Distance is how far to SKIP from the LAST byte of the previous
match before looking for the current match. Applies if you have
more than one content rule.
Within says only look in the NEXT x bytes AFTER the last byte of
the last content match. Applies if you have more than one content
rule.
So offset and depth are from the start of payload and often used
together, distance and within are similar but relevant to the last
content match.
73
Rule Options : Depth, Offset, Distance, Within

source:http://doc.emergingthreats.net/bin/view/Main/SuricataSnortSigs101

74
 Rule Option : uricontent (1)
●
Make snort “protocol aware”
●
search only the URI portion of a HTTP packet
instead of the entire packet/payload
●
You need to have the http_inspect preprocessor
enabled

alert tcp 192.168.1.18/32 any -> any 80 \

(msg:"eBaying"; uricontent:"ebay.com";)

75
 Rule Option : uricontent (2)
●
uricontent searches the NORMALIZED request URI field.
For example, the URI:
/scripts%c0%af../winnt/system32/cmd.exe?/c+ver
will get normalized into:
/winnt/system32/cmd.exe?/c+ver

Another example: the URI:

/cgi-bin/aaaaaaaaaaaaaaaaaaaaaaaa/..%252fp%68f? is
/cgi-bin/aaaaaaaaaaaaaaaaaaaaaaaa/../p%68f?
will get normalized into:
/cgi-bin/phf?
76
 Rule Option : nocase
●
Match the content string regardless of the case of the
letters.
●
Use sparingly, as it has resource implications

alert tcp any any -> any any \

(msg:"computer mentioned"; \
content:"Computer"; nocase;)

77
 Rule Option : regex (1)
●
regex tells snort that you will be using a regular expression in
your content search. It modifies only the content option that it
follows.
●
regex allows wildcard characters appear in the content string:
? matches a single character
* matches any number of characters

content: “/bin/*.exe” ; regex;

would search for any filename with an exe extension in /bin
being mentioned in the payload

78
 Rule Option : regex (2)

●
regex has resource implications, so use
sparingly

79
 Rule Option : session (1)
●
captures clear text data from TCP sessions
●
allows you to log and view usernames, passwords,
executed commands etc.
The following prints an entire ftp session to the alert file:

alert tcp any any -> any 21 \

(msg:"FTP session data"; session:printable;)

80
 Rule Option : session (2)
●
The printable modifier outputs all the printable text from a
session.
– Very useful option for a plain-text session such as FTP
or Telnet.
●
If the protocol is a little more complex, use the all modifier to
output all the data from the session.
●
Often a good idea to also use the logto keyword to log the
traffic to a particular file.

81
 Rule Option : resp (1)
●
allows for an automated active response when malicious activity
is detected.
●
often involves sending a RST, aborting TCP sessions.
●
If the offending packet is UDP, ICMP messages can be sent to
interrupt the UDP data flow.
For this to work, when snort is being configured, it should be
configured as follows:
./configure --enable-flexresp
●
You might need to get a libnet.h file
●
Be aware that if you are sending an active response, the source
address might be spoofed.

82
 Rule Option : resp (2)
●
Also be aware of timing. DNS UDP request-responces are very
fast. If you try to respond to a malicious DNS query, the
response might be gone before snort reacts.
●
Sample rule:
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS 80
(msg:"WEB-IIS CodeRed v2 root.exe access"; flags:A+;
uricontent:"scripts/root.exe?"; nocase; resp:rst_snd;)
●
The response is rst_snd which send a RST to the source IP
address

source:http://www.sans.org/resources/idfaq/active.php
83
 Rule Option : resp (3)
●
Other resp options:
rst_rcv: send RST to destination socket
rst_all: send RST to source and destination
icmp_net: send ICMP_NET_UNREACH to source
icmp_host: send ICMP_HOST_UNREACH to source
icmp_port: send ICMP_PORT_UNREACH to source
icmp_all: send all of above ICMP error indicators to
source

84
 Rule Option : resp (4)
●
rule example
alert tcp any any -> $HOME_NET 21 \
(msg: “FTP password file retrieval”; \
resp:rst_all; content: “get passwd”; nocase;)

●
If a packet containing get passwd is detected, the
connection is closed by the above rule.

85
 Rule Option : tag (1)
●
enables snort to capture additional packets after a rule triggers.
●
without this option, only the offending packet is recorded. However,
logging pre-incident traffic with the tag option is not possible.
●
usage: tag: type|count|metric|direction
●
type specifies what traffic to record. It may be session or host.
session records packets from both sides, whereas host causes only
packets from the host that sent the offending packet to be recorded.
●
count: This indicates either the number of packets logged or the
number of seconds during which packets will be logged. The
distinction between the two is made by the metric argument.

86
 Rule Option : tag (2)
●
metric: You can use either “packets” or “seconds” as
mentioned above.
●
direction: This argument is optional. You can use either
“src” to log packets from source or “dst” to log packets
from the destination.
●
The following rule logs 100 packets on the session after it is
triggered.
alert tcp 192.168.2.0/24 23 -> any any \
(content:"boota"; msg:"Detected boota";\
tag:session,100,packets;)

87
 Rule Option : tag (3)
●
The following rule looks for the start of any session on port
23 (usually telnet) and any packets that occur on that
specific session for the next 10 seconds after the rule is
triggered.

alert tcp any any -> any 23 \

(flags:S; tag:session,10,seconds;)

88
 Rule Option : flow (1)

●
Flow is different from direction.
●
The direction operator “->” tells it which way the packet
should be going.
●
flow tells the rule to look at a piece of traffic in relation
to who started the conversation.
●
The flow definitions are
●
Client to server (to_server | from_client)
●
server to client (to_client | from_server)

89
 Rule Option : flow (2)
●
Snort thinks about client/server in terms of “who initiated
the conversation”.
●
At the beginning of a TCP conversation there is a 3-way
handshake. SYN, SYN-ACK, ACK.
1. CLIENT -> SYN -> SERVER
2. CLIENT <- SYN, ACK <- SERVER
3. CLIENT -> ACK -> SERVER
●
The client is who initiated the conversation, the server is
who is responding.

90
 Rule Option : flow (3)
alert tcp $HOME_NET any -> aib.ie 80 \
(flow: to_server;)
●
says, look for a packet going outbound to aib.ie from our
network that we initiated.

alert tcp $HOME_NET any -> aib.ie any \

(flow: to_client;)
●
someone from aib.ie's network came to OUR network
●
now we are looking for the traffic that came into our
network and is RETURNING to aib.ie, but aib.ie initiated
the connection.
91
 Rule Option : flow (4)
●
Suppose an attacker owns a box on the network and
gets a command shell to create a backdoor to allow
him/her come back over a port (cmd.exe).

alert tcp $HOME_NET any -> $EXTERNAL_NET any

●
The above would catch it.
●
But you'd get all kinds of false positives.
●
For example, if, someone sent an email via pop3, this
would then flag the IDS, thus being a false positive.
92
 Rule Option : flow (5)

alert tcp $HOME_NET any -> $EXTERNAL_NET any

(flow: to_client; flags:SA;)

would catch the scenario where someone OUTSIDE of

our network connected INTO our network, got a reverse
shell and is INITIATING a connection outbound.

93
 Rule Option : flow (6)

The stateless option is used to apply the rule without

considering the state of a TCP session.
The established option is used to apply the rule to
established TCP sessions only.
The no_stream option enables rules to be applied to
packets that are not built from a stream. TCP streams
are handled by the stream preprocessor.
The stream_only option is used to apply the rules to
only those packets that are built from a stream.

94
 Rule Option : flow (7)

Source:http://resources.infosecinstitute.com/snort-rule-writing-for-the-it-professional-part-2-2/

95
 Example Rule

alert tcp any any -> any 445 (msg: “conficker.a

shellcode”; content: “|e8 ff ff ff ff c1|^|8d|N|10 80|1|c4|
Af|81|9EPu|f5 ae c6 9d a0|O|85 ea|O|84 c8|O|84 d8|O|c4|
O|9c cc|IrX|c4 c4 c4|,|ed c4 c4 c4 94|&<O8|92|\;|d3|WG|
02 c3|,|dc c4 c4 c4 f7 16 96 96|O|08 a2 03 c5 bc ea 95|\;|
b3 c0 96 96 95 92 96|\;|f3|\;|24|i| 95 92|QO|8f f8|O|88 cf
bc c7 0f f7|2I|d0|w|c7 95 e4|O|d6 c7 17 f7 04 05 04 c3 f6
c6 86|D|fe c4 b1|1|ff 01 b0 c2 82 ff b5 dc b6 1b|O|95 e0
c7 17 cb|s|d0 b6|O|85 d8 c7 07|O|c0|T|c7 07 9a 9d 07
a4|fN|b2 e2|Dh|0c b1 b6 a8 a9 ab aa c4|]|e7 99 1d ac b0
b0 b4 fe eb eb|”; sid: 2000002; rev: 1;)

96
Preprocessors

97
 Introduction (1)
●
The Preprocessor is run before the detection engine
is called, but after the packet has been decoded.
●
The Preprocessor can be used to modify or analyze
the packet
●
Preprocessors help in identifying possible attack
packets before rules are applied
●
Preprocessors need to be configured in snort.conf
– frag2 should be commented out if frag3 is
used and stream4 is commented out if
stream5 is used.
●
We now examine some of these preprocessors

98
 Introduction (2)
●
Note that the more preprocessors that are enabled,
the greater the performance hit.
●
All enabled preprocessors must examine each packet
in turn; i.e., there is no mechanism for a
preprocessor to maturely cut short packet processing
and bypass the remaining ones.
●
This means that if a large number of CPU-intensive
preprocessors are loaded then it is likely to have an
adverse effect on overall performance.
●
Be careful when choosing to enable a preprocessor.

99
 Introduction (3)
●
Snort's preprocessors fall into two categories.
– some examine packets for suspicious activity
– Some reassemble packets so that the detection
engine can properly interpret them
●
Snort cycles packets through every preprocessor
●
Preprocessor parameters are configured and tuned
via the snort.conf configuration file.

100
 frag Preprocessor
●
The frag preprocessor can help detect attack types
that are related to fragmentation, whether they are
IDS evasion techniques or malicious DoS attacks.

101
 stream Preprocessor
●
The stream preprocessor is what Snort uses to
maintain the state of TCP streams, which is used in
detecting some types of information gathering
attacks.
●
Stateful inspection with stream helps Snort better
match attack signatures across multiple packets.

102
 HTTP_decode Preprocessor

●
The HTTP_decode preprocessor is responsible for
detecting abnormal HTTP traffic and normalizing it so
that the detection engine can properly interpret it.
●
Normalizing traffic is the process of translating an
obscure character set, such as Unicode or Hex, to a
character set that Snort can recognize.
●
HTTP_decode works specifically with the URI string of
an HTTP request. It generates an alert if it encounters
traffic that requires decoding.

103
 arpspoof Preprocessor

●
ARPspoof is a preprocessor designed to detect
malicious Address Resolution Protocol (ARP) traffic,
especially ARP Cache Poisoning on a LAN

104
 fnord Preprocessor

●
The fnord preprocessor is designed to detect and defeat
polymorphic shellcode evasion attempts.

105
 portscan Preprocessor

●
The portscan preprocessor can detect vertical
portscans, i.e scans that sweep the entire range of ports
on one host. It can also detect horizontal portscans,
which scan one port across many hosts.

106
 SPADE Preprocessor (1)

●
SPADE (Statistical Packet Anomaly Detection Engine) is
a preprocessor that detects suspicious traffic via
anomaly detection methods.
●
SPADE determines whether traffic is anomalous by
building a table to describe normal traffic patterns. When
traffic does not match data stored in the table, SPADE
outputs an alert.

107
 SPADE Preprocessor (2)
●
SPADE functions by assigning all incoming packets
an anomaly score. High anomaly scores are assigned
to specific packets that are rare in occurrence. SPADE
defines a unique packet by combining packet IP and port
information.
●
A table is constructed that reflects the occurrences of
different kinds of packets over time. Recent packets are
given precedent over aged packets. Over time, an
alerting threshold is defined for SPADE. For each packet
that exceeds this threshold, an alert is generated.

108
 Links
●
Working with snort rules:
http://www.informit.com/articles/article.aspx
●
http://manual.snort.org/ – Online Snort Manual
●
Snort User Manual
https://s3.amazonaws.com/snort-org-site/production/
document_files/files/000/000/086/original/snort_manual.pdf
●
Free Snort book (2003):
http://ptgmedia.pearsoncmg.com/images/0131407333/downloads/
0131407333.pdf

109