ECSAv4 Module 08 Snort Analysis

Advanced
P
Penetration
t ti T Testing
ti
and Security Analysis
Module 8
Snort Analysis
Copyright by EC-Council
EC-Council All Rights Reserved. Reproduction is Strictly Prohibited
Module Objective
This module will familiarize you with:
Snort O
S Overview
i
Modes of operation
Configuring Snort
Plug-ins
l i and d Pre-processors
Workings of Snort
Writing Snort Rule
Rule Headers
Rule Options
Tool: IDS Policy Manager
Snort Overview
Snort, an O
S Open S
Source network-based
k b d iintrusion
i d detection
i sensor, iis the
h
most widely installed NIDS in the world.
Snort is capable of performing real-time traffic analysis and packet

logging
gg g on IP networks.
Snort performs protocol analysis and content searching/matching to

detect a variety of attacks and probes such as buffer overflows, stealth
port scans, CGI attacks, SMB probes, OS fingerprinting attempts, and
more.
Snort Overview (contd)
Snort is available in binary format for a few commercial and

O
Open S
Source operating
i systems, and d will
ill compile
il ffrom
sources on:
Linux.
Linux
Open/Free/NetBSD.
Solaris, SunOS 4.1.X.
HP UX.
HP-UX.
AIX.
IRIX.
Tru64.
Mac OSX.
Win32.
Modes of Operation
Reads the packets off of the network and displays them

Packet sniffer: for you in a continuous stream on the console (screen)
Packet logger: Logs the packets to disk
Allows Snort to analyze network traffic for matches

Network-based IDS: against a user-defined rule set and performs several
actions based upon
p what it sees
Obtains packets from iptables instead of from libpcap and

Inline mode: then causes iptables to drop or pass packets based on
Snort rules that use inline-specific rule types
Features of Snort
Flexible rules language
Detection engine utilizes a modular plugin architecture
Real-time alerting capabilities:

Via syslog
To user-specified files
Via Unix sockets
Via Windows pop-up messages
Configuring Snort
Configured via text-based

text based
Snort.conf
Configuration file is broken

down into sections:
Variables
Pre-processors
Output plug-ins
Rules
Snort: Variables
Variables
i bl are used d to d
define
fi parameters ffor d detection,
i
specifically those of your local network and/or specific
servers or p
ports for inclusion or exclusion in rules.
var HOME_NET [10.1.1.0/24,192.168.1.0/24]

,
var EXTERNAL_NET any
var DNS_SERVERS [1.2.3.4,5.6.7.8]
var HTTP_PORTS 80
Snort: Pre-processors
Pre-processors
Pre processors are used to implement ad advanced
anced features
features,
control deltas for specific checks, and/or implement specific
plug-ins (i.e., anomaly detection).
preprocessor frag2
preprocessor stream4: disable_evasion_alerts
disable evasion alerts
preprocessor stream4_reassemble
preprocessor http_inspect_server: server default \
profile all p
p ports { 80 8080 8180 } \
oversize_dir_length 500
Snort: Output Plug-ins
Output plug-ins define the means by which Snort will perform

logging and alerting, including to a file, database, or socket.
output alert_syslog: LOG_AUTH LOG_ALERT

output database: log, mysql, user=root \
password=test dbname=Snort host=localhost
output log_unified: filename Snort.log, limit 128
Snort: Rules
Rules
R l are the
th means bby which
hi h Snort
S tddetects
t t suspicious
i i
behavior and compromise attempts.
Multiple rule sets can be referenced, though careful

consideration should be taken to ensure only necessary rules
are enabled.
bl d
include $
$RULE_PATH/ftp.rules
p
include $RULE_PATH/web-cgi.rules
include $RULE_PATH/netbios.rules
Snort: Rules (contd)
The example rules below demonstrate:
An attempt to retrieve /etc/passwd via ftp.

A directory traversal attempt using unicode.
Traffic generated by the ramen worm.
alert tcp $EXTERNAL_NET any -> $HOME_NET 21 (msg:"FTP passwd retrieval attempt";
flow:to_server,established; content:"RETR"; nocase; content:"passwd"; reference
:arachnids,213; classtype:suspicious-filename-detect; sid:356; rev:5;)
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"WEB-IIS unicode d

irectory traversal attempt"; flow:to_server,established; content:"/..%c0%af../";
nocase; classtype:web-application-attack;
l t b li ti tt k reference:cve,CVE-2000-0884;
f CVE 2000 0884 sid:981;
id 981
rev:6;)
alert tcp $HOME_NET any -> $EXTERNAL_NET 27374 (msg:"MISC ramen worm"; flow:to_s
erver,established; content:"GET "; depth:8; nocase; reference:arachnids,461; cla
sstype:bad-unknown; sid:514; rev:4;)
How Snort Operates
Initialization Decoding
Detection Preprocessing
Initializing Snort
Snort begins in the main() function:
To start Snort as a Windows service, the main() function:

P
Performs
f validation
lid i on the
h parameters passed d to S
Snort.
Checks for the /SERVICE keyword to see if Snort is compiled for Windows.
The SnortMain() function is called:
Th
The SnortMain()
S tM i () function
f ti b begins
i b by associating
i ti a sett off h
handlers
dl
for the signals Snort receives:
It does this using the signal() function.
When SnortMain() () finishes,, the return value from this function is
returned to the shell.
Signal Handlers
Signal Handler Description
SIGTERM SigTermHandler() This handler calls the CleanExit() function to free up

Snort resources and exit cleanly.
SIGINT SigIntHandler() This function calls the CleanExit() function.
SIGQUIT SigQuitHandler() The CleanExit() function is called by this handler to

correctly shut Snort down.
SIGHUP SigHupHandler() The SigHupHandler() function calls the Restart()
function. This frees all data required and closes the pcap
object that was created. If Snort is compiled with the
PARANOID variable defined, the execv()
function is used to reexecute Snort. Otherwise, execvp()
is used.
SIGUSR1 SigUsr1Handler() The SIGUSR1 signal is used as a programspecific
signal. The handler for this calls the DropStats()
function to output the current Snort statistics
statistics. It then
resumes program execution.
Parsing the
Configuration File
Snort calls the ParseRuleFile() function to parse the selected configuration file:
This function reads in the configuration file line-by-line and passes it to the
ParseRule() function for testing.
The ParseRule() function tests the start of the rule to determine what type of
rule has been passed.
ParsePreprocessor():
This function is called if the rule line is a preprocessor statement.
ParseOutputPlugin():
If the line in the configuration file being parsed describes an output plug-in,
plug-in this function
is called to set up the appropriate data structures.
Decoding
Execution b
begins
g at the ProcessPacket()
() function when a new p
packet is
received.
The definition
Th d fi iti off th
the ProcessPacket()
P P k t() function
f ti iis shown
h iin th
the ffollowing
ll i
example:
void ProcessPacket(char *user, struct pcap_pkthdr * pkthdr,

u_char
h * pkt)
kt)
When the ProcessPacket() function is called, it begins by incrementing the

packet count and storing the time the packet was captured.
At a basic level, each of these decoders parses its appropriate header data,
validating certain fields before setting the packet pointer to the next header and
passing the pointer to the next decoder.
Possible Decoders
Decoder Description
DecodeIptablesPkt This decoder is used to decode Iptables packets in Inline mode
mode. It is
basically a wrapper around the DecodeIP() Function.
DecodeIpfwPkt This decoder is used to decode packets from the Internet Protocol
Firewall (IPFW) firewall; at the moment, this function is also a
wrapper around d the
h ffunction.
i
DecodeEthPkt This decoder checks the ether_type field of the Ethernet header, and
calls the appropriate packet decoders to break the packet down further.
DecodeIEEE80211 This decoder examines 802
802.11
11 Wireless Local Area Network (WLAN)
Pkt packets.
DecodeFDDIPkt This decoder is used to decode Fiber Distributed Data Interface (FDDI)
packets.
DecodePppPkt This decoder is used to decode Point-to-Point Protocol (PPP) traffic. It
does this using RFC 1661 standards.
DecodeChdlcPkt This decoder is used to decode High-Level Data Link Control (HDLC)
encapsulated packets
packets. It tests the size of the packet and the various
HDLC fields before passing to the DecodeIP() function.
Pre-processing
This phase begins as soon as the packet decoding is finished.

finished
ProcessPacket() function
f nction tests the mode in which
hich Snort is running.
r nning
If S
Snortt iis running
i iin:
Packet Log mode: The CallLogPlugins() function is used to log the

packet accordingly.
p gy
IDS mode: The decoded packet structure is passed to the
Preprocess() to begin the pre-processing phase.
Detection
The detection phase begins in the Detect() function:
This function verifies the existence of the packet and IP header before passing
the packet to the fpEvalPacket() function for further testing.
The fpEvalPacket() function tests the ip_proto

field of the IP header to determine what to do next:
If the packet is TCP/UDP or ICMP, then the fpEvalHeaderTcp(),

fpEvalHeaderUdp(), and fpEvalHeaderICMP() functions are called
Otherwise, the fpEvalHeaderIp() function is used to check, based on IP.
Content Matching
To accomplish
p the complex
p p
pattern matching g used in Snort rules,, the
Snort team has implemented a series of string matching and parsing
functions.
These functions are contained in the src/mstring.c and src/mstring.h

files in the Snort source tree.
Content matching implemented with the mSearch() function utilizes

the Boyer-Moore algorithm to accomplish the match.
The performance of Boyer-Moore algorithm increases with an increase in

the length of the pattern.
pattern
Content-Matching
Functions
F
Function
i D
Description
i i
int mSearch(char *, int, char *, The mSearch() function is also used to
int int *, int *);
int, ); test for the occurrence of a substring
within another string.
int mSearchCI(char *,, int, The mSearchCI() function is a case

case-
char *, int, int *, int *); insensitive version of the mSearch()
function.
int *make_skip(char *, int); Creates a Boyer-Moore skip table.
int *make_shift(char *, int); Creates a Boyer-Moore shift table.
The Stream4 Pre-processor
The stream4 preprocessor was originally implemented to

provide stateful functionality to Snort.
It was directly created in response to the Stick and Snot

tools at which time both provided a dangerous attack
tools,
vector against a non-stateful IDS.
With the stream4 preprocessor enabled, Snort users are

able to drop packets that are not associated with an
established TCP stream.
Inline Functionality
The inline functionality of Snort is implemented utilizing the iptables or ipfw

f
firewall
ll to provide
d the
h ffunctionality
l ffor a new set off rule
l types, Drop, Reject,
j and
d
SDROP.
In order for Snort to implement inline functionality via the iptables firewall, a
kernel module called the ipqueue module must be installed and functional:
The ipqueue
pq module allows p
packets to be scheduled before being
g dropped,
pp , or accepted.
p
The following commands can be used to queue all of the network traffic that the
IDS sensor can see:
iptables -A OUTPUT -j QUEUE

iptables -A INPUT -j QUEUE
iptables
i t bl -A
A FORWARD -j
j QUEUE
Writing Snort Rules
Snort uses a simple, lightweight rules description language that is flexible and
quite powerful.
powerful
Snort rules are divided into two logical sections, the rule header and the rule
options.
The rule header contains the rules action, protocol, source, and destination IP
addresses and netmasks, and the source and destination ports information.
The rule option section contains alert messages and information on which parts of
the packet should be inspected to determine if the rule action should be taken.
Sample Snort rule:
alert tcp any any -> 192

192.168.1.0/24
168 1 0/24 111
(content:"|00 01 86 a5|"; msg:"mountd access";)
Snort Rule Header
Th fields
The fi lds off rule
l hheader
d are:
Rule Action
Protocol
IP Address
Port Number
Directional Operator
Snort Rule Header:
Actions
Default Snort Rule Actions
Pass The packet is ignored.
Alert An alert is generated and the packet is logged.
Log
og Thee packet
pac et iss simply
s p y logged;
ogged; no
oaalert
e t iss ge
generated.
e ated.
Dynamic A rule with dynamic actions remains dormant until triggered by an
activate rule. If not triggered, it acts as a log rule.
Activate An activate rule alerts and then turns on a dynamic rule.
rule
Snort Inline Rule Actions
Drop The packet is not allowed to pass through to the destination host.
Reject The packet will be dropped by iptables and Snort will log it. A TCP
reset will be returned if the protocol is TCP, and an ICMP port
unreachable packet will be sent if it is UDP.
Sdrop The sdrop action silently drops the packet without logging it.
Snort Rule Header:
Other Fields
This field dictates which protocol the rule should

match.
Protocol:
There are four protocols that Snort currently analyzes
for suspicious behavior TCP, UDP, ICMP, and IP.
Syntax of this section is as follows:

IP address and p
port
<1ST IP ADDRESS> <1ST PORT> <DIRECTION
information: OPERATOR> <2nd IP> <2nd PORT>
It is a symbol that describes the orientation of the

Directional operator: traffic needed to trigger the alert.
IP Address Negation Rule
The next portion of the rule header deals with the IP address and port information for a given
rule.
rule
The keyword any may be used to define any address. Snort does not have a mechanism to
provide host name lookup for the IP address fields in the rules file.
The addresses are formed by a straight numeric IP address and a CIDR block.
For example, the address/CIDR combination 92.168.1.0/24 would signify the block of
addresses
dd ffrom 192.168.1.1
68 to 192.168.1.255.
68
The negation operator tells Snort to match any IP address except the one indicated by the
listed IP address.
The negation operator is indicated with a !.
alert tcp !192.168.1.0/24

!192 168 1 0/24 any -> 192
192.168.1.0/24
168 1 0/24 111 \ (content:
"|00 01 86 a5|"; msg: "external mountd access";)
IP Address Filters
You
ou may
ay a
also
so spec
specifyy lists
sts o
of IP add
addresses.
esses.
An IP list is specified by enclosing a comma separated list of IP addresses

and CIDR blocks within square
q brackets.
alert tcp ![192.168.1.0/24,10.1.1.0/24] any -> \

[192.168.1.0/24,10.1.1.0/24] 111 (content: "|00 01 86
a5|"; \ msg: "external mountd access";)
Port Numbers
Port numbers may be specified in a number of ways, including any ports, static
portt d
definitions,
fi iti ranges, and
dbby negation.
ti
Any ports are a wildcard value, meaning literally any port.
log udp any any -> 192.168.1.0/24 1:1024

(log udp traffic originating from any port and destination
ports ranging from 1 to 1024)
log tcp any any -> 192.168.1.0/24 :6000

(log tcp traffic from any port directed to ports less than or
equal to 6000)
log tcp any :1024 -> 192.168.1.0/24 500:

(log tcp traffic from privileged ports less than or equal to
1024 directed to ports greater than or equal to 500)
The direction Operator
The direction operator indicates the orientation, or direction, of the traffic to which the rule
applies.
li
The IP address and port numbers on the left side of the direction operator is considered to be
the traffic coming from the source host, and the address and port information on the right
side of the operator is the destination host.
There is also a bidirectional operator, which is indicated with a <> symbol.
This tells Snort to consider the address/port pairs in either the source or destination
orientation.
This is handy for recording/analyzing both sides of a conversation, such as telnet or POP3
sessions.
log tcp !192.168.1.0/24 any <> 192.168.1.0/24 23

Rule Options
The rule options allow the user to specify exactly what they want to match
and what they want to display after a successful match.
They form a semicolon (;) delimited list directly after the rule header and
are enclosed in parentheses ().
Classifications of Rule Options

Metadata The metadata options provide information related to the rule, but
do not have any effect on the detection itself.
Payload
y These options
p look for data inside the p
payload
y of a p
packet.
Nonpayload These options look at data that is not in the payload.
Post-detection Post-detection options are events that occur after a rule is
triggered.
Activate/Dynamic Rules
Activate rules are jjust like alerts,, but also direct Snort to add a rule when a specific
p
network event occurs,
Dynamic rules are similar to log rules . They are dynamically enabled when the
activate rule id is triggered.
activate tcp !$HOME_NET any -> $HOME_NET 143 (flags: PA; \

| |/ ; activates: 1;
content: "|E8C0FFFFFF|/bin"; ; \ msg:
g "IMAP buffer
overflow!";) dynamic tcp !$HOME_NET any -> $HOME_NET 143
(activated_by: 1; count: 50;)
These rules tell Snort to alert when it detects an IMAP buffer overflow and collect
th nextt 50 packets
the k t h
headed
d d ffor portt 143 coming
i ffrom outside
t id $HOME NET
headed to $HOME NET.
If a successful attempt of buffer overflow attack occurs, it is quite possible that

useful data will be contained within the next 50 packets.
Metadata Rule Options: msg
The msg rule option tells the logging and alerting engine the message to
print along with a packet dump or to an alert.
It is a simple text string that utilizes the \ as an escape character to

indicate a discrete character that might otherwise confuse Snorts rules
parser.
msg: "<message text>";
The reference Keyword
The reference keyword allows rules to include references to external

attack
tt k id
identification
tifi ti systems.
t
alert tcp any any -> any 7070 (msg:"IDS411/dos-realaudio"; \

flags:AP; content:"|fff4 fffd 06|";
reference:arachnids,IDS411;)
alert tcp any any -> any 21 (msg:"IDS287/ftp-wuftp260-

venglin-linux"; \ flags:AP; content:"|31c031db 31c9b046 cd80
31 031db|" \ reference:arachnids,IDS287;
31c031db|"; f h id S287
reference:bugtraq,1387; \ reference:cve,CAN-2000-1574;)
The sid/rev Keyword
The sid keyword is used to uniquely identify Snort rules.

rules This information
allows output plugins to identify rules easily.
This option should be used with the rev keyword.
d
rev denotes revision
i i off Snort
S rules.
l
This example is a rule with the Snort Rule ID of 1000983

1000983.
alert tcp any any -> any 80 (content:"BOB"; sid:1000983;
rev:1;)
The classtype Keyword
The classtype
yp keyword
y categorizes
g alerts to be attack classes.
The user can specify what priority each type of rule classification has.
Rule classifications are defined in the classification.config file
The config
Th fi fil
file uses the
h ffollowing
ll i syntax: config classification: <class
name>,<class description>,<default priority>
alert tcp any any -> any 80 (msg:"EXPLOIT ntpdx overflow"; \

dsize: >128; classtype:attempted-admin; priority:10 );
alert tcp any any -> any 25 (msg:"SMTP expn root"; flags:A+;
\ content:"expn root"; nocase; classtype:attempted-recon;)
Snort Default
Classifications
Payload Detection Rule
Options: content
The content keyword is one of the more important features of Snort.

Snort
It allows the user to set rules that search for specific content in the packet payload
and trigger response based on that data.
If the packets payload contains the content that matches the argument data
string the test is successful and the remaining rule option tests are performed.
This test is case sensitive.

sensitive
The binaryy data is g

generallyy enclosed within the p
pipe
p (|) character and represented
p
as bytecode.
Payload Detection Rule
Options: content (cont
(contd)
d)
Bytecode represents binary data as hexadecimal numbers and is a good shorthand
method for describing complex binary data.
data
Multiple content rules can be specified in one rule.
If the rule is preceded by a !, the alert will be triggered on packets that do not
contain this content.
alert tcp any any -> any 139 (content:"|5c

00|P|00|I|00|P|00|E|00 5c|";)
Mixed Binary Bytecode and Text in a content
content keyword
alert tcp any any -> any 80 (content:!"GET";)
Negation Example
Modifier Keywords
The content keyword

y has a number of modifier keywords.
y
These modifier keywords are: depth, offset, distance, within, nocase

and rawbytes.
Example: nocase:
The nocase keyword allows the rule writer to specify that the Snort should look for
the specific pattern, ignoring case.
alert tcp any any -> any 21 (msg:"FTP ROOT"; content:"USER
root"; nocase;)
Modified
DATA
The offset/depth Keywords
The offset keyword allows the rule writer to specify where to start
searching for a pattern within a packet.
Offset modifies the previous content

content keyword in the rule:
alert tcp any any -> any 80 (content: "cgi-bin/phf";

offset:4; depth:20;)
Skip the first 4 bytes, and look for cgi-bin/phf in the next 20 bytes
The uricontent Keyword
The uricontent parameter in the Snort rule language searches the NORMALIZED request
URI field.
This means that if you are writing rules that include things that are normalized, such as %2f
or directory traversals, these rules will not alert.
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:
\begin{verbatim} /cgi- bin/aaaaaaaaaaaaaaaaaaaaaaaaaa/..%252fp%68f?

Will get normalized into:
/cgi-bin/phf?
The fragoffset Keyword
The fragoffset keyword allows you to compare the IP fragment

offset field against a decimal value.
To catch all the first fragments of an IP session,

session you could use the
fragbits keyword and look for the More fragments option in
conjunction with a fragoffset of 0.
alert ip any any -> any any \

(msg: "First Fragment"; fragbits: M; fragoffset: 0;)
The ttl Keyword
The ttl keyword is used to check the IP time-to-live value.
This option keyword was intended for use in the detection of traceroute
attempts.
This example checks for a time-to-live value that is less than 3:
ttl:<3;
This example checks for a time-to-live value that is between 3 and 5:

ttl:3-5
tt :3 5
The id Keyword
The id keyword is used to check the IP ID field for a specific value.
This example looks for the IP ID of 31337: id:31337;
The flags Keyword
The flags keyword is used to check if specific TCP flag bits are present.
The following bits may be checked:
F - FIN (LSB in TCP Flags byte)

S SYN
R RST
P PSH
A ACK
U URG
1 - Reserved bit 1 (MSB in TCP Flags byte)
2 - Reserved bit 2
0 - No TCP Flags Set
This example checks whether the SYN and the FIN bits are
set,, ignoring
g g reserved bit 1 and reserved bit 2:
alert tcp any any -> any any (flags:SF,12;)
The itype
keyword: icmp id
The itype keyword is used to check for a specific ICMP ID value.
This is useful because some covert channel programs use static ICMP
fields when they communicate.
communicate
This example looks for an ICMP ID of 0: icmp_id:0;
Writing Good Snort Rules
General concepts to keep in mind when developing

Snort rules:
Content matching
Catch the vulnerability, not the exploit
Catch the oddities of the protocol in the rule
Optimizing
i i i rulesl
Sample Rule to Catch Metasploit
Buffer Overflow Exploit
Rule:
1. content:"|00 00 00 00|"; offset:4; depth:4;
2. content:"|00 01 87 88|"; offset:12; depth:4;
3. content:"|00 00 00 01 00 00 00 01|"; offset:16; depth:8;
4. byte_test:4,>,200,36;
Tool for Writing Snort Rules:
IDS Policy Manager
http://www activeworx org/

http://www.activeworx.org/
IDS Policy Manager was written to manage Snort

IDS sensors in a distributed environment.
It has a graphical interface for easy manageability of

Snort rule and configuration files.
Merge new Snort rules into existing rule files.
Make quick changes to Snort rules.

rules
Update rules via the web.
IDS Policy Manager
Subscribe to Snort Rules
Sourcefire, the company behind Snort, changed its rule licensing rule.
The company introduced a registration and subscription model.
Three sets of rules were introduced:
Sourcefire VRT Certified Rules - The Official Snort Ruleset

(subscription release)
Sourcefire
S fi VRT Certified
C ifi d Rules
l - Theh Offi
Official
i l Snort
S Ruleset
l
Community Rules
Customers running Snort for personal use need to pay $29.99 per year for any number of
sensors.
Enterprise customers are charged $499 per sensor per year for one to five sensors, or $399
per sensor per year for six or more sensors.
Those who do not wish to pay for Sourcefire VRT rules can register, but they will have to wait
30 days to access the latest rules.
Honeynet Security
Console Tool
Honeynet Security Console is an analysis tool to view events on

your personal network or honeynet.
It gives you the power to view events from Snort, TCPDump,

Firewall,, Syslog
y g and Sebek logs.
g
It also allows you to correlate events from each of these data types
t have
to h a ffull
ll grasp off th
the attackers'
tt k ' actions.
ti
Key Features
Intuitive interface to view all event logs on your personal network or honeynet
View Snort, firewall, syslog, Sebek, TCPDump logs
Powerful interactive graphs with drilldown capabilities
Simple yet powerful search/correlation capabilities
Integrated IP tools
TCPDump payload and session decoder
Built in passive OS fingerprinting and geographical location capabilities
Quickly view detailed event information from the Internet
Dashboard view to quickly see status of events
Limited to a single Snort sensor

Honeynet Security
Console: Screenshots
Honeynet Security Console:
Screenshots (cont
(contd)
d)
Summary
In this module, we reviewed network intrusion prevention and detection system,

Snort; its features
features, modes of operation
operation, configuration
configuration, and working
working.
We have discussed major components of Snort configuration:
Variables
Preprocessors
Output Plugins
Rules
We have discussed about writing Snort rules, rule header and various rule
options.
We have discussed use of Snort rules and tools to write rules.

ECSAv4 Module 08 Snort Analysis

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ECSAv4 Module 08 Snort Analysis

Uploaded by

Copyright:

Available Formats

Advanced

This module will familiarize you with:

Snort is capable of performing real-time traffic analysis and packet

Snort performs protocol analysis and content searching/matching to

Snort is available in binary format for a few commercial and

Reads the packets off of the network and displays them

Packet logger: Logs the packets to disk

Allows Snort to analyze network traffic for matches

Obtains packets from iptables instead of from libpcap and

Flexible rules language

Detection engine utilizes a modular plugin architecture

Real-time alerting capabilities:

Configured via text-based

Configuration file is broken

var HOME_NET [10.1.1.0/24,192.168.1.0/24]

Output plug-ins define the means by which Snort will perform

output alert_syslog: LOG_AUTH LOG_ALERT

Multiple rule sets can be referenced, though careful

The example rules below demonstrate:

An attempt to retrieve /etc/passwd via ftp.

alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"WEB-IIS unicode d

Snort begins in the main() function:

To start Snort as a Windows service, the main() function:

The SnortMain() function is called:

Signal Handler Description

SIGTERM SigTermHandler() This handler calls the CleanExit() function to free up

SIGQUIT SigQuitHandler() The CleanExit() function is called by this handler to

This function is called if the rule line is a preprocessor statement.

void ProcessPacket(char *user, struct pcap_pkthdr * pkthdr,

When the ProcessPacket() function is called, it begins by incrementing the

This phase begins as soon as the packet decoding is finished.

Packet Log mode: The CallLogPlugins() function is used to log the

The detection phase begins in the Detect() function:

The fpEvalPacket() function tests the ip_proto

If the packet is TCP/UDP or ICMP, then the fpEvalHeaderTcp(),

These functions are contained in the src/mstring.c and src/mstring.h

Content matching implemented with the mSearch() function utilizes

The performance of Boyer-Moore algorithm increases with an increase in

int mSearchCI(char *,, int, The mSearchCI() function is a case

int *make_skip(char *, int); Creates a Boyer-Moore skip table.

int *make_shift(char *, int); Creates a Boyer-Moore shift table.

The stream4 preprocessor was originally implemented to

It was directly created in response to the Stick and Snot

With the stream4 preprocessor enabled, Snort users are

The inline functionality of Snort is implemented utilizing the iptables or ipfw

iptables -A OUTPUT -j QUEUE

Sample Snort rule:

alert tcp any any -> 192

This field dictates which protocol the rule should

Syntax of this section is as follows:

It is a symbol that describes the orientation of the

The negation operator is indicated with a !.

alert tcp !192.168.1.0/24

An IP list is specified by enclosing a comma separated list of IP addresses

alert tcp ![192.168.1.0/24,10.1.1.0/24] any -> \

Any ports are a wildcard value, meaning literally any port.

log udp any any -> 192.168.1.0/24 1:1024

log tcp any any -> 192.168.1.0/24 :6000

log tcp any :1024 -> 192.168.1.0/24 500:

There is also a bidirectional operator, which is indicated with a <> symbol.

log tcp !192.168.1.0/24 any <> 192.168.1.0/24 23

Classifications of Rule Options

activate tcp !$HOME_NET any -> $HOME_NET 143 (flags: PA; \

void ProcessPacket(char user, struct pcap_pkthdr pkthdr,

int make_skip(char , int); Creates a Boyer-Moore skip table.

int make_shift(char , int); Creates a Boyer-Moore shift table.