MODULE 2

Introduction to Snort@ Technolog

About This Module

This module presents a basic overview of Snort and its architecture.

Module Objectives:

r
.
o

Understand what Snort is

Discuss Snort's basic architectural components
Understand Snort's dynamic plug-in capabilities

t-

t9

lntroduction to Snort@ Technology

What is Snort?
Slide 24

Snort is an application developed by Martin Roesch which today is primarily used as an

Intrusion Detection System/Intrusion Protection System (IDS/IPS). Snort, however, is
capable of more:
a

Packet sniffing

Packet logging

Intrusion detection

Additionally, Snort is supported on a wide variety of OS platforms including a wide variety of

Unix platforrns and Windows. Another distinguishing feature of Snort is that it is completely
open source. This gives Snort a big advantage over many of its commercial counterparts
because users can see what it's doing and tune the system accordingly. That degree of visibility
into the intemals of the product is generally not an option in the commercial IDSIIPS world.
It's free availability and broad platform support has made Snort one of the most popular and
widely used network security tools.

Snort's Basic Architecture

Slide 25

Snort has four primary components:

o
o

Preprocessors

The detection engine

The output and alerting module

The sniffer

Each of these components will be discussed in greater detail in the sections that follow.

Notes:

20

lntroduction to Snor(O Technology

Packet Snffing
Slide 26

:t:r"

*&ffi
u"I\ffnw$
W

Packet snifftng is the act of reading datagrams offthe wire. Normally, a device's MC is only
concemed with the kaflic addressed specifically to the device. However, the sniffing
component of Snort places the interface into a state known as promiscuous mode which
enables the NIC to read all the traffic on the wire not just the traffic directly addressed to it.

Snort's Packet Sniffer

Snort makes use of a Data Aquisition Module (DAQ) to collect packets offthe wire. The DAQ
serves as an abstraction layerbetween differenttypes ofpacket capture libraries and Snort. The

benefit of the DAQ is that different capture libraries may be used without the need to
recompile Snort. The DAQ supports both passive and inline operation. The DAQ mode can be
selected at startup via command line arguments or through the configuration files. the default
method of packet collection if no arguments are specified is pcap. The mode of operations
include:

o
e

PCAP - is the default DAQ

AFPacket - Functions similar to the pcap DAQ but with better performance. This also
allows for inline operation.
IPQ - This is the old way to process iptables packets. This replaces the compile option
--enabl-e-inl-ine used in previous versions of Snort.

NFQ - This is the new and improved way to process iptables packets.

IPFW - Is used by BSD systems. It replaces the compile option

--enable-ipfw

The DAQ promiscuously picks data offthe wire and passes it along to the decoding engine.
Libpcap 1.0.0 or later must be installed prior to the DAQ. The DAQ must be compiled before
Snort as they are separate components.

Packet Decoding
In order for Snort to know what's in a packet, it must be presented in such a way that each field
of the packet is correctly parsed starting from the Layer 2 (Data Link) protocols (Ethernet,
Token Ring, etc.) on through to the application layer payload. Snort is focused on TCP/IP so it
is decoded in its entirety. Other networking protocols are only decoded up to Layer 2 so they
can be identified, but no further action is taken on them.
Snort stores the decoded packet information in data structures held in memory that are then
passed on to the other elements ofthe Snort architecture; the preprocessors, detection engine
and output processors respectively.

Notes:

27

lntroduction to Snort@ Technology

Preprocessors
Slide 27

In order for packets to be inspected in a contextually relevant way, some further processing
must be performed on them to reveal the context in which the packets are intended to be used.
For example:

.
.
o

Are the packets part of a TCP communication, and, if so, what protocol is being utilized?
Are the packets fragmented, and,
inspection?

if

so, can they be correctly reassembled prior to

Are packets identified as belonging to a particular protocol fging used within the
parameters of that protocol correctly?

This is a sampling of some of the things that must be done so that packets are presented in a
contextually relevant way. Snort preprocessors handle this task. They are specially designed to
put network traffic into context for presentation to the other elements of the Snort architecture.
There are several preprocessors that come with a standard Snort distribution. The list below
provides a sampling of some of the major ones:

Protocol Decoders - These preprocessors are used to normalize various TCP haffrc
streams including: telnet, ftp, smtp, and rpc.

o
o
o

http_inspect - This preprocessor normalizes http traffic.

frag3 preprocessor - Used to reassemble packet fragments prior to inspection.
streamS preprocessor - Used to reconstruct TCP data streams so that inspection can be
done in the context of a TCP conversation rather than the individual packets that make up
the stream.

o
o

DCEIRPC2 - Used to decode and desegment DCE traffic.

slPortscan - A portscan detection plug-in.

Preprocessors play a vital function in network traffic inspection. In addition to normalizing

haffic and presenting contextually relevant data up to the detection engine, preprocessors also
have the ability to alert if they detect anomalous conditions as defined by their settings.

Notes:

22

sllffitftrs

lntroduction to Snort@ Technology

Detection Engine
Slide 28

The detection engine accepts the parsed, normalized and stream-reassembled network traffic

for inspection against the rule base. This component of the Snort architecture actually has two
components to perform the action of inspection:

r
o

Rules builder

Inspection against the built rules

On startup, the Snort rules builder goes through all the rules files to review the rules and
assemble them in such a way that inspection is optimized and redundancies in tenns of
sources, destinations and port sources and destinations are not replicated in the construct
against which network traffic is evaluated. Chains of rules are built, which will be discussed in
greater detail in a subsequent section.
Network traffic inspection takes place against the rule chains constructed during the build
process. Snort rules have a fairly simple structure as defined below:

Rule header - This portion provides the basic information regarding where
from, where its going to, what to do

if

a match occurs and the

packet came

protocol on which the rule

should match.

Rule Options - This portion of the rule provides information on what specifically to look
for in a packet payload or certain header fields to trigger a match. For example, the options
for a given rule may trigger a match on the occurrence of a particular string as defined by
the Content option.

The rule sl,ntax facilitates the matching of rules in the rule chains by providing the most
relevant rule-matching information. When a match of the information occurs, the packet is
further inspected against the options in the rule chain that matched. Snort rules speciff actions
to take in the event that a rule is matched. The actions available in IDS mode are as listed
below:

r
r
.

Pass - Ignore the packet that matched all the parameters specified in the rule

Alert - Generate an alert

and log the packet that triggered

it

Log - Log the trafiic that matches the rule parameters but don't alert

Notes:

23

lntroduction to Snor(D Technology

Output Module
Slide 29

The output module handles the task of writing and displaying events. Snort-generated data can
be presented to standard output, logged to files or logged to a database. The output module is
somewhat unique in that it can receive input from various sources including the following:

.
o

The packet decoder to produce tcpdump-style output.

Preprocessors can send alerts directly to the output module on detection of anomalous
conditions as they inspect and assemble packets and packet streams.
The detection engine sends log and alert data to the output module when rules are matched.

When Snort is run as a sniffer, the output module receives decoded packet data directly from
the decoder. Snort runs in this mode any time a conf file is not specified on start up. This mode
essentially writes data to the screen or log file in a tcpdump-like fashion.

In inkusion detection mode, the output module can send logs and alerts to files in straight
ASCtr or pcap format which is recognizable by a large number of applications including
tcpdump, Wireshark, and Snort to name a few. You can also direct output to syslog or
databases. One last output option exists which is called unified output.
The unified ouQut is a very lightweight, binary form of output. This t)?e of output is readable
by an application called Barnyard which takes unified output and converts it to other fonns of
output much like Snort's output module. Having a second process purposely built for
manipulating output offloads some of the processing burden from Snort. Tmplementing Snort
in this configuration provides a perfomrance boost that can be critical for optimizing the IDS/
IPS in higher utilization network environments.

Notes:

24

lntroduction to Snor(O Technology

Dynamic Plug-ins
Slide 30

One of the features available in Snort beginning with version 2.6 is the ability to load custom
modules at Snort's initialization time. A module could be one of the following:

rules

preprocessors

detection engines

Dynamic modules are components you can code in C which take advantage of API's available
as of Snort 2.6 lltich give coders direct access to functions the Snort engine already perforrns.
This gives security analysts the ability to write much more specific detection frnctionality than
is available via Snort's stock rules language. These modules are loaded along with Snort at its
initialization through configuration directives in the snort . conf file.

Notes:

25

lntroduction to Snort@ Technology

Module Summary
This module presented a quick snapshot of Snort and its architectural components. In the
sections that follow, each of these components will be explored in greater detail.

Notes:

26