snort 2.1 intrusion detection second edition phần 2 ppt

295_Snort_2e_01.qxd 5/4/04 4:50 PM Page 46
46 Chapter 1 • Intrusion Detection Systems
For maximum stealth, the attacker could even spoof the source; that doesn’t
matter in connectionless UDP.There is some likelihood that the attack packets
would get dropped if the network links were too oversaturated with the
Stick/Snot output, but it is likely that the actual attack packets would not be
picked up by the IDS, either because it’s only listening to established TCP ses-
sions and our attack is UDP or ICMP, or because the IDS is still listening to all
connections but is mobbed with false positives.
Notes from the Underground…
Stick, Snot, and Snort
Stick, Snot, and Snort are tools billed as “IDS Killers,” designed to over-
load your IDS to the point it becomes unusable.
■
Stick
gram based on an old version of the Snort ruleset, designed to
spew out so many alert-triggering packets per second that it
would force IDSs to come to a grinding halt. It was very effec-
tive for its time, but Snort now has measures in place to adjust
to and compensate for this style of attack.
■
Snot
index.html) that takes a Snort ruleset as argument and gener-
ates a series of packets that will trigger that ruleset. Cross-
platform and flexible, Snot allows script kiddies all over the
world to annoy to their IDS administrators.
If your Snort installation is being harried by these tools or similar
ones, you can limit your Snort alerts to noticing established TCP sessions
only with the snort –z est
stream4 preprocessor must be configured. Also keep in mind that this will
limit you from seeing all other nonstateful TCP alerts, so you will be

“Installing Snort.”
(www.eurocompton.net/stick/projects8.html) is a C pro-
is another similar tool (www.stolenshoes.net/sniph/
arguments. For this to work, however, the
missing UDP, ICMP, and ARP-based alerts. However, your IDS will still be
up and running. We go into depth on configuring snort in Chapter 3,
www.syngress.com
Simpo PDF Merge and Split Unregistered Version -
295_Snort_2e_01.qxd 5/4/04 4:50 PM Page 47
47 Intrusion Detection Systems • Chapter 1
Nmap offers a noisy scan that generates a whole bunch of fake packets as
alternate “sources,” using the –D “decoy” option.To the target, it looks like they
are being scanned by all the decoy machines at once, and your real scan is
masked among the fake ones.
Now, the quiet way.These are the attackers you really need to worry about.
We have already described fragroute and Dug Song’s evasive techniques as laid
out in the original Newsham-Ptacek paper, but Nmap also offers options for
stealth.There is the idle scan, the FTP bounce attack, timing-based attacks like a
very slow scan stretched out over days, fragmentation and reassembly based
attacks,TCP flag combination attacks, and even an idle scan off an unwitting
zombie host.To read details about the packet construction behind all these
attacks, refer to the Nmap man page at www.insecure.org/nmap/data/
nmap_manpage.html.
Return on Investment—Is It Worth It?
At the end of the day, the deciding factor for many businesses is what the
expected return on investment is. Is there truly going to be enough enhance-
ment to your network security that it’s worth installing, configuring, and main-
taining an IDS? Security is often referred to as an economic sinkhole for
businesses; they spend money on it, but if all goes well, they rarely see returns.
Instead, the returns are in costs saved rather than in products made. Because of

this, many CEOs are reluctant to spend the money necessary for expensive sys-
tems or solutions, more so if they’ve already spent money on an IDS and have
seen few positive results from it but many false positives.
If you are considering adding an IDS to your network, consider it as a busi-
ness case. How much money does your company lose if there is an intrusion?
What are the odds of that intrusion happening? How much will it cost to install
and maintain an IDS? How much will the IDS offset or mitigate the risks of that
intrusion? How will an IDS affect your organization legally? Earlier in the
chapter, we discussed the possible implications of wiretap and privacy laws on a
company’s use of an IDS. However, an IDS can also assist in compliance with
corporate accounting laws such as the Sarbanes-Oxley requirements, and in
establishing an audit trail in the event of a compromise. Sections 302 and 304 of
the Sarbanes-Oxley requirements place the responsibility on a corporation to
establish internal controls within their network. An IDS can be a demonstrable
part of these controls. When combined with a third-party penetration test of
your network security, this can go a long way toward validating your own data
www.syngress.com
Simpo PDF Merge and Split Unregistered Version -
295_Snort_2e_01.qxd 5/4/04 4:50 PM Page 48
48 Chapter 1 • Intrusion Detection Systems
with an external audit, complete with trail. Some locations now require compa-
nies to notify customers when their data has been compromised; the State of
California is one such place. Having an IDS can allow you to detect compromise
attempts more reliably. Being able to go to your CEO with strong numbers, legal
backing, and business precedent will be far more impressive than “uh, I guess we
need one of those, everyone else seems to have one.”
Defining IDS Terminology
Being able to understand the differences between different types of IDSs and
their features is crucial when trying to design a security architecture. Let’s look at
some of the most common terminology in the IDS field, and make sure we

understand all the options available.
Intrusion Prevention Systems (HIPS and NIPS)
An IDS that not only detects possible attack, but also responds to prevent the
attack from being successful.This response can be anything from creating firewall
rules to black-hole the attacker, to killing the offending process (when dealing
with a Host IPS), to dropping the offending traffic (when dealing with a
Network IPS).
Gateway IDS
An IDS that sits at the bottleneck between your network and the Internet (or
whatever peering upstream you may be connected to). Also known as an inline
IDS, all traffic must pass through this gateway to leave your local network.This
may also function as an IPS if it includes the capability to make decisions about
whether traffic should be allowed.
Network Node IDS
The method of intrusion detection where one establishes a baseline of “normal”
network traffic, and then looks for deviations from that norm and flags them as
possible attack traffic.
www.syngress.com
Simpo PDF Merge and Split Unregistered Version -
295_Snort_2e_01.qxd 5/4/04 4:50 PM Page 49
49 Intrusion Detection Systems • Chapter 1
Protocol Analysis
The method of intrusion detection where one looks at the flow of data within
the specifications of each protocol, looking for anomalies and possible malicious
traffic based on the expected protocol behavior.
Target-Based IDS
A new flavor of IDSs specifically aimed at what is actually on the network.They
are designed to have fewer false positives and only alert on attacks that are rele-
vant to your network and the specific services running on your network.
www.syngress.com

Simpo PDF Merge and Split Unregistered Version -
295_Snort_2e_01.qxd 5/4/04 4:50 PM Page 50
50 Chapter 1 • Intrusion Detection Systems
Summary
IDSs can serve many purposes in a defense-in-depth architecture. In addition to
identifying attacks and suspicious activity, you can use IDS data to identify secu-
rity vulnerabilities and weaknesses.
IDSs can audit and enforce security policy. For example, if your security
policy prohibits the use of file-sharing applications such as Kazaa, Gnutella, or
messaging services such as Internet Relay Chat (IRC) or Instant Messenger, you
could configure your IDS to detect and report this breach of policy.
IDSs are an invaluable source of evidence. Logs from an IDS can become an
important part of computer forensics and incident-handling efforts. Detection
systems are used to detect insider attacks by monitoring traffic from Trojans or
malicious code and can be used as incident management tools to track an attack.
Correlation of data, whether from a HIDS or NIDS or DIDS, is probably the
best way to approach intrusion detection data. While an IDS can be a valuable
contributor to a security architecture, it is by no means enough in and of itself to
protect a network.
A NIDS can be used to record and correlate malicious network activities.
The NIDS is stealthy and can be implemented to passively monitor or to react to
an intrusion.The HIDS plays a vital role in a defense-in-depth posture; it repre-
sents the last bastion of hope in an attack. If the attacker has bypassed all of the
perimeter defenses, the HIDS might be the only thing preventing total compro-
mise.The HIDS resides on the host machine and is responsible for packet inspec-
tion to and from that host only. It can monitor encrypted traffic at the host level,
and is useful for correlating attacks that are detected by different network sensors.
Used in this manner it can determine whether the attack was successful.The logs
from a HIDS can be a vital resource in reconstructing an attack or determining
the severity of an incident.

Solutions Fast Track
Introducing Intrusion Detection Systems
� An intrusion is an unauthorized access, use, or attack on your network
or computers.
� IDSs work by watching network and system activity, and comparing that
to known signatures or against algorithms to separate legitimate activity
from suspicious activity.
www.syngress.com
Simpo PDF Merge and Split Unregistered Version -
295_Snort_2e_01.qxd 5/4/04 4:50 PM Page 51
51 Intrusion Detection Systems • Chapter 1
� IDSs can then log the attack and respond in a number of ways.The
most common response is to alert the system administrators through
SNMP traps, text messages, phone calls, or pages.
Answering Common IDS Questions
� Attackers are interested in everyone connected to the Internet these
days; it’s not necessarily personal.
� An IDS can alert you to network traffic and system activity of which
you may not have been aware. It can increase the effectiveness of a good
system administrator, and provide him with additional data.
� An IDS will not replace your existing security staff, or make people stop
attacking you.
Fitting Snort into Your Security Policy
� Snort is a network IDS with sophisticated pattern-matching capabilities
that are used to uniquely describe attack traffic.
� Snort signatures for the latest viruses, worms, and other new
vulnerabilities are usually written and released within hours or days of
the new attacks’ debut.
� You can write your own Snort signatures to match company policy vio-
lation, new or unique traffic, or anything else.

Analyzing IDS Design and Architecture
� IDSs can be configured to just detect and alert, or to respond as well.
� Possible responses include dropping the traffic, spoofing ICMP or TCP
Reset packets, or identifying and tracing back toward the attack source.
� IDSs are not perfect or foolproof—they can be tricked or eluded.They
are valuable contributors to a security policy, but not enough all by
themselves to enforce it.
www.syngress.com
Simpo PDF Merge and Split Unregistered Version -
295_Snort_2e_01.qxd 5/4/04 4:50 PM Page 52
52 Chapter 1 • Intrusion Detection Systems
Frequently Asked Questions
The following Frequently Asked Questions, answered by the authors of this book,
are designed to both measure your understanding of the concepts presented in
this chapter and to assist you with real-life implementation of these concepts. To
have your questions about this chapter answered by the author, browse to
www.syngress.com/solutions and click on the “Ask the Author” form. You will
also gain access to thousands of other FAQs at ITFAQnet.com.
Q: Why doesn’t my firewall serve as an IDS?
A: Firewalls are designed primarily to pass, drop, or reject traffic, not to alert on
suspicious traffic. IDSs are designed to let you know when suspicious activity
is occurring.The two functions are different and conflict in key issues. We
discuss this further in Chapter 12.
Q: Can IDSs gather data from anywhere besides sniffing on a network?
A: Yes, some IDSs can also gather data from log parsing, watching system calls,
or monitoring a filesystem.
Q: What can an IDS do for me that my system administrator can’t?
A: Parse a few hundred million packets or log entries (or more) a day in binary.
Most administrators get tired after a while.
Q: What can my system administrator do for me that my IDS can’t?

A: Bring creative thinking and an understanding of the significance of this net-
work activity to the analysis.
Q: Will I have to spend time tuning my IDS?
A: Yes. If you don’t want to be drowning in false positives, it really is best to
tune your IDS to fit its environment.
Q: Does physical security still matter if I have the best network security in the
world?
A: Absolutely. If we can walk in to your office and walk out with your server,
you’ve still been rooted.
Q: Why should I bother writing my own signatures, when Snort has so many
already?
A: You certainly don’t have to, but you might want to add functionality that’s
not present in the extant ruleset, like rules tailored to your enterprise policy
or to detect attacks targeting specific proprietary applications.
www.syngress.com
Simpo PDF Merge and Split Unregistered Version -
295_Snort2e_02.qxd 5/4/04 4:55 PM Page 53
Chapter 2
Introducing
Snort 2.1
Solutions in this Chapter:
■
What Is Snort?
■
Understanding Snort’s System
Requirements
■
Exploring Snort’s Features
■
Using Snort on Your Network

■
Considering System Security While Using
Snort
� Summary
� Solutions Fast Track
� Frequently Asked Questions
53
Simpo PDF Merge and Split Unregistered Version -
295_Snort2e_02.qxd 5/4/04 4:55 PM Page 54
54 Chapter 2 • Introducing Snort 2.1
Introduction
It’s 9:30 A.M
., and Bob Sysadmin has just walked out of his boss’s office, shaking
his head ruefully. When he arrived at work that morning, it was to face an angry
Web development team whose beautiful and elegantly designed index page had
been replaced with the crude legend, “Y0U H4\/3 B33N 0WN3D BY AG3NT
D3L3T3! l@m3 security, d00d. greetz to m4g3, p1><1e, and the V0R!” Bob was
initially shocked, and then profusely apologetic. Dialing up his boss on the cell
phone, he ran for the server room to yank out the Ethernet cable of the compro-
mised machine and get the computer emergency response team involved. Perhaps
now, he thought grimly, his budget request for an Intrusion Detection System
(IDS) wouldn’t seem so “unnecessary.”
Bob’s meeting with his boss was somewhat rocky. Fortunately, Bob was able
to calmly counter the angry management “How did this happen? Someone’s
head is going to roll!” bluster with a clear explanation of the weaknesses in their
network defenses, and the budgetary and managerial reasons why they hadn’t
been strengthened. He pointed out their staffing shortages, the lack of defense in
depth, and the critical lack of information about ongoing attacks. Although the
meeting started badly, by the end of it, Bob’s boss was asking thoughtful ques-
tions and framing a productive response to the compromise. Bob began to hope

that, with management support, he might be able to make a real difference in his
company’s network security.
It’s 9:30
A.M., and across town, Jennifer Sysadmin has just finished briefing
her boss about the intrusions that occurred the night before. Although she was
dismayed by the initial compromise, she was able to respond almost immediately
thanks to the IDS alert sent to her pager. After determining that the attacks were
successful against one of her boxes, she immediately yanked the compromised
system off the network, took disk images and live data for forensics, and analyzed
the extent of the compromise. By the time the developers and management
showed up to work in the morning, she had the last-known good backup
restored to the system, locked down the hole that the attacker had used to com-
promise the server, and tasked her junior system administrators with making sure
that all their systems were up to date on their security patches, just to be safe.
She prepared a report for her managers about which vulnerabilities in the Web
server’s code were exploited, and what the response of her security team was.
She’s also scheduling a vulnerability scan of her network for that weekend, when
normal network usage will be light, to make sure that she and her team have not
www.syngress.com
Simpo PDF Merge and Split Unregistered Version -
295_Snort2e_02.qxd 5/4/04 4:55 PM Page 55
55 Introducing Snort 2.1 • Chapter 2
missed any potentially damaging holes in their defense. Logging in to her work-
station, she downloads the latest Snort ruleset and applies it to her sensors,
making sure that they are using the very latest definitions of network attack sig-
natures. Running a few quick probes from her pen-testing box to make sure the
new signatures are alerting on the sensors properly, she grins, stretches, and gets
up. It’s definitely time for a morning cup of coffee.
It’s 9:30
A.M., and Andy Attacker is sound asleep. After his successful evening

breaking in to other peoples’ systems, he has a few dozen new zombie machines
for his botnet, just waiting for his command to launch a distributed denial-of-
service (DDoS) attack against anyone he decides he doesn’t like. He’s defaced a
few Web pages, garnered a few new root accounts with his new Solaris exploit,
and is planning to spend tomorrow night trading movies and media files from
“his” brand new servers. Happy dreams of exploits that never fail, servers that
never go down, and sysadmins who never catch on, fill his head.
Had Andy been a somewhat more sophisticated attacker, it’s entirely possible
that Bob Sysadmin and his team of Web developers wouldn’t have had any idea
that their server had been compromised. Often, it’s only attackers out to promote
a cause or gain a reputation in their community who bother with defacing a site.
There are also attackers who are much more subtle about their assault, hiding
their success rather than advertising it, and quietly using your resources for their
own purposes. Without the capability to look in depth at system and network
activity, you may be blind to these sorts of attempts.This is the very reason why
many system administrators, security engineers, and Chief Information Officers
(CIOs) are interested in IDSs like Snort.
What Is Snort?
Snort is a modern security application with three main functions: it can serve as
a packet sniffer, a packet logger, or a Network-based Intrusion Detection System
(NIDS).There are also many add-on programs to Snort to provide different ways
of recording and managing Snort logfiles, fetching and maintaining current Snort
rulesets, and alerting to let your admins know when potentially malicious traffic
has been seen. Although not part of the core Snort suite, the add-ons provide a
rich variety of features to the security administrator. As you will see, there are
many ways to use Snort as part of your company’s security design.
Normally, Snort only speaks TCP/IP. Although, with custom extensions,
Snort can be made to support other network protocol suites, such as Novell’s
www.syngress.com
Simpo PDF Merge and Split Unregistered Version -

295_Snort2e_02.qxd 5/4/04 4:55 PM Page 56
56 Chapter 2 • Introducing Snort 2.1
IPX,TCP/IP is the common-tongue protocol of the Internet.Therefore, our
coverage of Snort’s analysis and alerting on TCP/IP protocols does not mean
we’re ignoring the other protocols out there; it’s simply that Snort does not
address them in the main code train.
OINK!
Lead Snort developer Martin Roesch, commonly known as Marty in the
Snort community, chose a name for Snort based on its role as a “sniffer
and more.” The combination of the Snort name, the pig mascot, and
programmers’ senses of humor ensures that many Snort add-on and ref-
erences are pig or farm related. There is also the underground rumor
that Marty chose the name Snort because he already had too many pro-
grams named a.out.
When designing the early versions of Snort (and to a lesser degree, its prede-
cessor APE), Marty considered several features essential. He wanted an application
that would be portable, working on many different operating systems. He wanted
packet output in hex dump format and in ASCII, and he wanted all different
types of packets to be displayed in a consistent format. Snort does all of these
things, plus signature-based rule matching and alerting.
There are many resources available online for the Snort enthusiast, including
mailing lists for Snort development, writing signatures, general Snort discussion,
Snort announcements, and even tracking of CVS changes. All of these are avail-
able online at www.snort.org/lists.html.There are also Web pages for Snort
enthusiasts in a given area, such as www.my-snort.org, a site promoting the use
of Snort in Malaysia, and Snort user groups in localities from Munich, Germany
to Japan.
There are also commercial solutions and products using Snort technology. By
far the most famous is Sourcefire (www.sourcefire.com); a detailed discussion of
Sourcefire is outside the scope of this book.

www.syngress.com
Simpo PDF Merge and Split Unregistered Version -
295_Snort2e_02.qxd 5/4/04 4:55 PM Page 57
57 Introducing Snort 2.1 • Chapter 2
Understanding Snort’s
System Requirements
To a large degree, determining what type of hardware and software configuration
you will need to run an optimal Snort installation is a matter of understanding
your network. First, you have questions of scale. Roughly speaking, the bigger
your network is, the better machines you’ll need to serve as your Snort sensor(s).
Snort will need to be able to keep up with your network, have enough disk
space to log its alerts, and have a fast enough processor and enough memory to
be able to handle the normal amount of traffic you see, with some wiggle room
built in for intense attacks and traffic spikes. While a number of optimizations
can be done to speed Snort up significantly, these are the basic issues that you
need to consider. For an in-depth discussion of how to optimize snort, see
Chapter 10, “Optimizing Snort.”
OINK!
Questions of scale you should consider when designing a Snort system
for your network:
■
Do you run a small home network, a small business network, a
large enterprise, or an Internet service provider (ISP)?
■
How much traffic do you normally see within your network?
■
How much traffic goes from your network to the outside world,
and vice versa?
■
Where will the alerts be stored?

■
How long do you want to store the alerts for?
■
Do you want to store packets related to the alerts as well?
In addition, you will have questions of management.You want to be sure
your system administrators will be familiar with the operating system on which
you choose to run Snort, that your method of generating alerts will not overrun
either the capabilities of your machines or your administrators, and that the sen-
sors and any other add-ons you may choose will be able to be managed in a
secure and scalable fashion.
www.syngress.com
Simpo PDF Merge and Split Unregistered Version -
295_Snort2e_02.qxd 5/4/04 4:55 PM Page 58
58 Chapter 2 • Introducing Snort 2.1
OINK!
Questions of management you should consider when designing a Snort
system for your network:
■
Who is going to be responsible for monitoring the Snort sys-
tems? What is that person’s skill set? With which operating sys-
tems and management tools is that person familiar?
■
Have you defined a procedure to follow when a Snort alert that
looks like it might be serious occurs? Who is responsible for fol-
lowing up on the alert?
■
How are you going to patch your Snort systems? Who is respon-
sible for maintaining and for testing them after maintenance to
ensure proper operation?
With these questions in mind, let’s look at the various options available in

designing a Snort system.
Hardware
Hardware requirements play an essential role in designing a good security system.
For Snort, there aren’t hard and fast guidelines like “you must have a 2-gigahertz
or faster processor to run this system.”The speed, storage space, and amount of
memory you’ll want on a Snort sensor are going to vary widely, depending on
how much traffic you expect your sensor to see, how many rules you want
enabled, the forms of output and alerting you choose, and how busy your net-
work segments are.
“But argh!” we can hear you saying. “What if I don’t know all that?” In that
case, you’ll have to do what you normally do for any new system: get an idea of its
requirements, make your best guess, and watch your system carefully for the first
few weeks to try to correct any errors you might have made. When in doubt, it’s
generally better to allocate extra resources—far better a sensor that’s more than
capable of handling the load you throw at it than a sensor that’s positively
drowning because you vastly underestimated. For example, it’s probably not a good
idea to try to build your Snort sensor on the oldest piece of hardware you have. It
is actually very common to purchase a high-end system to act as your sensor and
then move it over to more general-purpose use when it becomes insufficient for
monitoring.You will almost certainly want a reasonably fast processor, a relatively
large and fast hard drive, and two good quality network interface cards (NICs). As
we said before, this is discussed in depth in Chapter 10, but these are the general
issues to consider.
www.syngress.com
Simpo PDF Merge and Split Unregistered Version -
295_Snort2e_02.qxd 5/4/04 4:55 PM Page 59
59 Introducing Snort 2.1 • Chapter 2
Let’s take a closer look at these unique requirements of Snort. What type of
resources is it likely to want? First, you’ll need at least one NIC. It is strongly
recommended that you have two NICs on your Snort system, one configured

without an IP address to silently listen to the network traffic, and the other to
manage the sensor, send alerts, and handle other normal TCP/IP activity.
Some people recommend cutting the transmit wires of the Ethernet cable
that connects the silent listening interface to your hub or switch, on the sensor
side.This way, the sensing interface is much harder to detect, and cannot acciden-
tally betray its presence by replying to an Address Resolution Protocol (ARP)
packet or other such network tomfoolery. (We’ll get into more details about
detecting a sensing interface at the end of the chapter, when we discuss attacking
Snort.) However, many NICs have trouble maintaining the link state without
both transmit and receive signals. Solutions for this vary, from dead-ending the
transmit pair into a hub with no other connections, to splicing the wires back
into themselves, as suggested in Patrick Gray’s 2002 paper “One Way Cable
Preparation Guide” (
OneWayCable.pdf ).These solutions can be quite complicated; it is up to you to
determine whether the decreased risk of detection is worth the extra effort for
your system.
One common configuration for switched networks is to set the port on your
switch that is connected to your sensor to spanning mode.This ensures that all
traffic sent out any other port on this switch is also sent to the spanning port.
However, even spanning ports will sometimes fail to send errors or VLAN infor-
mation to the spanned port. Depending on your security model, this may be data
you want to see.To deal with these cases, often a company will buy specialized
Ethernet taps, hardware designed to allow silent NIDS sniffing by performing port
mirroring in hardware rather than in software and directing all data, errors, VLAN
information and all, to the connected NIDS interface.This is especially helpful
because if the tap loses power, the network connection through it will stay up.
You will want your NICs to be capable of dealing with the full possible
capabilities of your network. If your network is a mixture of 10 Mbps and 100
Mbps systems, you want your Snort sensor to have two 100 Mbps NICs. If some
devices on your network are half duplex and others are full duplex, you want the

NICs of your Snort sensor to be full duplex. If your NICs on your Snort sensor
are below par, they won’t be able to keep up with the other devices on your net-
work, and you’ll miss traffic, and therefore will miss potential attacks.
www.syngress.com
Simpo PDF Merge and Split Unregistered Version -
295_Snort2e_02.qxd 5/4/04 4:55 PM Page 60
60 Chapter 2 • Introducing Snort 2.1
In addition, you want to make sure that the port that is connected to your
sensing interface will be able to see all the traffic—we’ll be dealing with this
more in the section Snort and Your Network Architecture later in this chapter.
Snort can generate many alerts. If you’re logging your alerts locally, you’ll
need some serious disk space to be able to deal with these alerts. For a large
enterprise, this can run in the range of 10GB for the partition that Snort alerts to
(usually /var, but you can change this if so desired). For a home or small business
use, this can be considerably smaller. If you choose to log your Snort alerts to a
remote database, remember to make sure that that machine also has the requisite
disk space.Your disk space needs will change, depending on how often you clear
out older alerts, and how well tuned your Snort ruleset is. A default install is usu-
ally going to be far busier than a Snort install with known false positives tuned
out. Performance and conservation of hardware resources are just more reasons to
keep your Snort sensors well tuned.
Operating System
By design, Snort is portable, running on many different modern operating sys-
tems. Currently, there are releases of Snort 2.1 available for x86-architecture
Linux, FreeBSD, NetBSD, OpenBSD, and Windows. Other systems supported
include Sparc-architecture Solaris, MacOS X and MkLinux, and PA-RISC HP-
UX. If your favorite operating system isn’t on that list, Snort’s source code is
available under a GPL license, and you can port the code to the operating system
of your choice.
A common question is, “yes, yes, but which one is the best?”There are two

factors to consider when choosing the operating system on which Snort will
run: which operating systems you or your system administrators are most familiar
with and comfortable working with, and the performance of the operating
system itself
OINK!
Choice of operating systems tends to be a hot-button issue among
system administrators, often approaching or exceeding politics or reli-
gion as a potentially inflammatory topic. You’re the one who’s going to
have to administer your Snort installation, so choose an operating
system that you can work with happily.
www.syngress.com
Simpo PDF Merge and Split Unregistered Version -
295_Snort2e_02.qxd 5/4/04 4:55 PM Page 61
61 Introducing Snort 2.1 • Chapter 2
If, through some strange twist of fate, you are equally skilled at all operating
systems, or you truly do want to choose your OS based on performance only,
TCP/IP stack performance is going to be a big factor in your OS’s performance.
(Speed of disk access may also matter—for that, you’ll have to look at both the
underlying hardware and the OS drivers to address it.) You might want to look at
the TCP/IP stack system benchmarks at there are
some fairly in-depth and varied tests there. As of the time of this writing, Linux
2.6 came out on top for overall performance, but FreeBSD and NetBSD also
made quite impressive showings. We discuss installing Snort on different oper-
ating systems in Chapter 3, “Installing Snort,” and provide detailed information
on Linux, Windows, and OpenBSD.
Other Software
In addition to the basic operating system, if you intend to compile Snort from
source code, you will need the tools to do so. Make sure you have the following
installed:
■

autoconf and automake
■
gcc
■
lex and yacc, or the GNU equivalents flex and bison
■
libpcap
Most of these are downloadable from your nearest GNU mirror
(www.gnu.org/order/ftp.html), but libpcap is available at www.tcpdump.org.
You might also want to install Snort add-ons or management tools, such as
the popular Analysis Console for Intrusion Detection (ACID) Web interface,
which requires the Apache Web server (Secure Socket Layer support is highly
recommended), PHP, and a database for the alerts such as MySQL or
PostgreSQL. Some popular Snort add-ons include:
■
ACID
■
Oinkmaster
■
SnortSnarf
■
SnortReport
There are many more options available; check www.snort.org for a more
exhaustive listing.
www.syngress.com
Simpo PDF Merge and Split Unregistered Version -
295_Snort2e_02.qxd 5/4/04 4:55 PM Page 62
62 Chapter 2 • Introducing Snort 2.1
Additionally, you will probably want some method of remote management of
your Snort sensor—requiring physical access to the box to make any configura-

tion changes quickly becomes tiresome in all but the most paranoid or the
smallest environments.To this end, you might want to consider a SSH server, or a
Terminal server, depending on your chosen operating system.
OINK!
While you do need a compiler (gcc) and tools like autoconf and yacc to
install Snort, they should not be on a production IDS sensor! Your sen-
sors should be built to survive a hostile environment, which means
removing software that may be useful to an attacker (such as a com-
piler). You also want to make sure you add tools to help protect the
sensor. Things like a file integrity checker (for example, AIDE or Tripwire)
and a log-monitoring tool (for example, logwatcher or swatch) should
be part of every default IDS install.
Exploring Snort’s Features
Let’s take a more in-depth look under the hood of Snort. While we discuss Snort’s
internals in depth later in the book (Chapters 4, 6, and 7), it is necessary to have a
general understanding before we talk about using Snort. When a packet arrives at
its NIC, how does it decode and display it? How does it decide whether that par-
ticular packet is worth alerting on, or whether it’s part of some treacherous data
flow that deserves attention, or whether the packet and everything it’s a part of is
harmless normal traffic that should be allowed to pass without alerting? Snort uses
an ordered set of behaviors to determine what traffic matches its rules and should
be alerted on. Much of this behavior is customizable.
Incoming data is decoded first by the packet decoder. If you are using Snort
solely as a packet sniffer, the decoded data will be formatted for the console dis-
play and shown. If you’re using Snort as a packet logger, the data will be put into
either ASCII format in a directory tree or a binary file, whichever one you speci-
fied on the command line, and saved to disk. If you are using Snort as a NIDS,
the processing is somewhat more complicated.
When using Snort as a NIDS, after the incoming packets are parsed by the
packet decoders, the data is then sent through any preprocessors that you may

www.syngress.com
Simpo PDF Merge and Split Unregistered Version -
295_Snort2e_02.qxd 5/4/04 4:55 PM Page 63
63 Introducing Snort 2.1 • Chapter 2
have enabled in your snort.conf file.That data is passed to the detection engine,
which matches it against the rules in any ruleset enabled in your snort.conf file.
Matches are sent to the alerting and logging components, to be passed through
whatever output plug-ins you have selected, and they will log the data or gen-
erate alerts as they have been configured to do.
Packet Decoder
The packets enter through the NIC and are decoded off the wire by the packet
decoder, which determines which protocol is in use for a given packet and
matches the data against allowable behavior for packets of their protocol.The
packet decoder can generate alerts of its own based on malformed protocol
headers, overly long packets, unusual or incorrect TCP options that are set in the
headers, and other such behavior.You can enable or disable more verbose alerting
for all of these fields in your snort.conf. Here’s the default configuration for a
FreeBSD installation of Snort 2.1 as far as packet decoding:
# Configure the snort decoder
# ============================
# Snort's decoder will alert on lots of things such as header
# truncation or options of unusual length or infrequently used tcp options
#
# Stop generic decode events:
# config disable_decode_alerts
#
# Stop Alerts on experimental TCP options
# config disable_tcpopt_experimental_alerts
#
# Stop Alerts on obsolete TCP options

# config disable_tcpopt_obsolete_alerts
#
# Stop Alerts on T/TCP alerts
# In snort 2.0.1 and above, this only alerts when the a TCP option is
# detected that shows T/TCP being actively used on the network. If this is
# normal behavior for your network, disable the next option.
# config disable_tcpopt_ttcp_alerts
#
www.syngress.com
Simpo PDF Merge and Split Unregistered Version -
295_Snort2e_02.qxd 5/4/04 4:55 PM Page 64
64 Chapter 2 • Introducing Snort 2.1
# Stop Alerts on all other TCPOption type events:
# config disable_tcpopt_alerts
#
# Stop Alerts on invalid ip options
# config disable_ipopt_alerts
After the packets are matched against the decoder, they are then sent to the
preprocessors, if any have been defined in your snort.conf file.
The Preprocessors
Preprocessors are plug-ins to Snort that allow you to parse incoming data in dif-
ferent ways that may be useful. If you run Snort without any preprocessors speci-
fied in your snort.conf configuration file, you will only look at each individual
packet as it comes in over the wire.This is probably going to lead to you missing
some attacks, since many modern attacks depend on things like overwriting data
in overlapping fragments, deliberate IDS evasion techniques like putting part of a
malicious application request in one packet and the rest in another packet, and
other such practices.
Data hits the preprocessors after it has been parsed by the packet decoder.
Snort 2.1 offers a wide variety of preprocessors, configurable to detect portscans

(the portscan and portscan2 preprocessors), reassemble TCP fragments (the frag2
preprocessor), track streams of data to look for stealth or evasive activity (the
stream4 preprocessor), and many more options. At the time of this writing, there
are 10 preprocessors described in the Snort manual for Snort 2.1 (available at
www.snort.org/docs/snort_manual/node17.html), as well as several more experi-
mental preprocessors, such as arpspoof, designed to detect ARP spoofing on a
network segment.
OINK!
It is important to remember that the preprocessors get the packets
before the detection engine. This means that even if you set up a pass
rule for specific traffic, it won’t prevent the preprocessor from alerting
on that traffic. This is because the packet won’t be compared to the pass
rule until after it has gone through the preprocessors.
www.syngress.com
Simpo PDF Merge and Split Unregistered Version -
295_Snort2e_02.qxd 5/4/04 4:55 PM Page 65
65 Introducing Snort 2.1 • Chapter 2
To get a better idea of how a preprocessor functions, let’s take a more
detailed look at one. Although there are many different preprocessors available for
Snort, let’s look at one that is new in Snort 2.1, HTTPInspect. For a detailed dis-
cussion of all the preprocessors, see Chapter 6, “Preprocessors.”
Example: HTTPInspect
In Snort 2.1, HTTPInspect replaces http_decode as the preprocessor responsible
for decoding HTTP traffic and detecting application layer attacks attempting to
exploit features of HTTP design or implementation. It will look inside the data
buffer of packets, search for HTTP traffic, and attempt to perform data normal-
ization of any HTTP traffic that it does find. HTTPInspect will recognize both
server and client traffic.
In versions of Snort up to 2.1.1, HTTPInspect does not maintain state itself.
If another preprocessor is performing stateful data stream reassembly,

HTTPInspect will catch more data, but it will only look at each individual
packet, not perform stream reassembly for the entire HTTP session.
HTTPInspect has two configuration sections, a global section and a server
section.The global section allows you to give it mapping files for IIS Unicode
mapping, configure alerting for proxy servers with proxy_alert (to tell you if your
users are attempting to circumvent your proxy servers or using unauthorized
proxy servers), or configure detection of HTTP traffic on nonauthorized ports
with detect_anomalous_traffic. Here’s the global section of the HTTPInspect
preprocessor configuration from our snort.conf:
# http_inspect: normalize and detect HTTP traffic and protocol anomalies
#
# lots of options available here. See doc/README.http_inspect.
# unicode.map should be wherever your snort.conf lives, or given
# a full path to where snort can find it.
preprocessor http_inspect: global \
iis_unicode_map unicode.map 1252
You also have a server configuration section for the HTTPInspect prepro-
cessor, allowing you to set different HTTP server profiles for different known
servers, configure the types of attacks and normalization necessary based on the
server’s flavor (IIS servers are vulnerable to different classes of HTTP attacks than
Apache servers are, for example, so there are different files and configurations you
can set depending on what type of HTTP servers you have), and which ports to
www.syngress.com
Simpo PDF Merge and Split Unregistered Version -
295_Snort2e_02.qxd 5/4/04 4:55 PM Page 66
66 Chapter 2 • Introducing Snort 2.1
attempt decoding HTTP traffic on. Here’s the server section of the
HTTPInspect preprocessor configuration from our snort.conf:
preprocessor http_inspect_server: server default \
profile all \

ports { 80 8080 }
An important note with HTTPInspect is to realize that it will not “see
inside” encrypted SSL traffic, and so it should not be configured to attempt
decoding on HTTPS traffic, as you may generate false positives and will not gen-
erate real hits.
Each of Snort’s preprocessors behaves similarly, taking data from the packet
decoder and applying its own rules to try to find anomalous behavior patterns and
network alerts. After the data is returned from the preprocessors, it is passed to the
detection engine. Let’s look at another preprocessor, flow-portscan, which will
show us how flow data can be reorganized and matched for known data patterns.
Example: flow-portscan
flow-portscan is a good example of how one preprocessor can depend on
another. For flow-portscan to work, the flow preprocessor must be enabled.
Flow-portscan takes the data that the flow preprocessor has already parsed into
data flows, and looks for portscans of one host to many other hosts, or one host
to many ports on one other host. It replaces the portscan and portscan2 prepro-
cessors, which are depreciated and will soon be removed from Snort.
In operation, the flow-portscan preprocessor receives data flows from the
flow preprocessor. If the data flow is a new one (determined by comparing
source and destination IP addresses, the protocol in use, and the destination port),
flow-portscan determines whether the destination IP is in the watched network,
identifies the “talkers” and “scanners” by traffic patterns and frequency, and incre-
ments counters for each hit. If the traffic count is greater than the designated
threshold, and less than the ignore limit, an alert is generated
You can pass several options to the flow-portscan preprocessor to help tune it
more precisely to your needs.The src-ignore-net and dst-ignore-net parameters are
particularly valuable if you have known scanners or problematic networks that
you want to ignore.The server-watchnet parameter will tell you which network
you want to be watching.You can tweak the alert-mode or the output-mode to
your liking and adapt it to your local alerting system. Here’s one sample configu-

ration—you can find much more detail online in the Snort manual at
www.syngress.com
Simpo PDF Merge and Split Unregistered Version -
295_Snort2e_02.qxd 5/4/04 4:55 PM Page 67
67 Introducing Snort 2.1 • Chapter 2
www.snort.org/docs/snort_manual/node17.html#SEC-
TION00386000000000000000:
preprocessor flow-portscan: server-watchnet [192.168.1.0/24] \
unique-memcap 5000000 \
unique-rows 50000 \
tcp-penalties on \
server-scanner-limit 50 \
alert-mode all \
output-mode msg \
server-learning-time 3600
The Detection Engine
The detection engine is probably what most people think of when they think of
Snort’s functionality as a NIDS. It’s the component of Snort that takes data from
the packet decoder and preprocessors (if any are enabled) and compares it against
the rules in your snort.conf. How does it do this? In what order are rules
matched? If you want to make sure that your pass rule is more important than
your alert rules, how do you turn that on?
Flow-Portscan as Example Feature
First, the detection engine will try to determine what rulesets it ought to be
matching against for a given piece of data. It classifies this first by protocol—
TCP, UDP, ICMP, or IP—and then by identifying characteristics within the pro-
tocol. For TCP and UDP, this is source and destination port number. For ICMP,
it’s the ICMP type. For plain old IP packets, it’s what non-TCP/UDP/ICMP
transport protocol is in use.
Once the relevant ruleset has been determined, the detection engine then

follows procedures based on which rule in the relevant ruleset is unique.
Rules and Matching
It used to be the case that Snort was a first-match-out IDS—the first rule that
matched a packet in a file was the one that fired. By default, Snort will only fire
once on any given piece of data, unlike other IDSs that will generate multiple
alerts on the same packet. However, Snort now includes the capability to per-
form multiple matching against a given event, and to generate multiple alerts
www.syngress.com
Simpo PDF Merge and Split Unregistered Version -
295_Snort2e_02.qxd 5/4/04 4:55 PM Page 68
68 Chapter 2 • Introducing Snort 2.1
against the same packet. Since the introduction of Snort 2.1.3 Release Candidate
1, there is now a choice for how you want to order your rule matching. Since
this is designed to address an IDS-evading vulnerability, let’s take a closer look at
the vulnerability and the response from the Snort team.
After the introduction of Snort 2.0, data was matched against a fast pat-
tern matcher. If several signatures matched a given event, Snort implemented a
two-phase system for determining which rule would fire in case of multiple
matches.
The first phase of rule matching was a setwise pattern match. Put simply,
this means that the most exact content match to a given piece of data will win.
Therefore, if you have a rule that alerts on a packet with the content “test-cgi,”
and a rule that alerts on the content “test-cgi/vulnerable-script,” the second rule
will be the one that fires.The longest match will win.
If there is a rule with content, and a rule with no content, the rule with con-
tent wins. If there are two rules with no content, the more specific rule will win
if it specifies a destination port where the other has “any”; if it specifies an ICMP
type where the other has “any,” it will win.The rule with the longest content
match will win.
However, this opened up the possibility to mask an attack by causing Snort

to trip on a long content match signature that didn’t look like a big problem,
while not tripping on a higher priority alert that had a shorter content match.
Snort has addressed this problem in two ways: by implementing multiple matches
so that Snort now matches against the longest content match in any given group
(rather than the longest content match overall), and by allowing you to set Snort
rule filtering by event priority rather than by the length of the content match.
These modifications enhance Snort’s speed, performance, and security.
In general, “alert” rules will fire before “pass” rules.This is a design decision,
so that a badly written pass rule won’t accidentally invalidate a large chunk of
“alert” rules. However, if you would rather have this behavior reversed, you can
specify the –o option to Snort on the command line, making the order “pass,”
“alert,” “log” instead.This is a good thing to do, as pass rules won’t have any
effect if you don’t have them evaluated first. As you will see in Chapter 5,
“Playing by the Rules,” pass rules can be a very powerful tool when you have a
rule that you don’t want to turn off but that is consistently generating false posi-
tives on a specific kind of traffic.
www.syngress.com
Simpo PDF Merge and Split Unregistered Version -
295_Snort2e_02.qxd 5/4/04 4:55 PM Page 69
69 Introducing Snort 2.1 • Chapter 2
Snort rule writing is a fine art, and we’ll be investigating that in detail in
Chapter 5. For now, let’s look at one of the new keywords available in Snort
2.1—Perl Compatible Regular Expressions, or PCRE.
Example: PCRE
PCRE is an excellent example of some of the powerful new features in recent
versions of Snort.The introduction of the pcre keyword to Snort rules allows you
to match data with Perl-compatible regular expressions within the payload of the
packet.This can make it much easier to look for data patterns in potentially
polymorphic malicious code, particularly since many Snort rule writers are
already familiar with Perl.This is especially helpful, since some servers are looser

than others about things such as case sensitivity. For example, let’s say that we
wanted to look for root logins over any cleartext protocol. We could construct a
Snort rule like the following:
alert tcp any any -> any [21:1023] (pcre:"/ROOT/i";)
to let us know when we see ROOT, root, or any other variation of upper- and
lowercase characters crossing the network destined for TCP ports 21 through 1023.
OINK
!
While PCRE is very powerful, it is also an excellent way to overload your
sensor by forcing it to perform overly complex pattern matches. Before
you put a rule that uses PCRE into your production IDS network, be sure
to test it carefully to make sure it won’t overwhelm the system on which
your sensor is running.
Thresholding and Suppression
Snort also has the capability to alert if there have been a certain number of
instances of a given data set within a set time period.This is called thresholding,
and is covered in greater detail in Chapter 5.You can choose to either alert on
the first X number of alerts of a given event, or alert every Y instances of a given
event, to keep one bursty instance from filling up your logs and distracting you
from other alerts that may also require your attention.You can define these
events based on a Snort signature ID (SID).You can also define these events
www.syngress.com
Simpo PDF Merge and Split Unregistered Version -
295_Snort2e_02.qxd 5/4/04 4:55 PM Page 70
70 Chapter 2 • Introducing Snort 2.1
based on no SID, and limit how many alerts you’ll get from a given source to a
given destination, and many other combinations.
You can also use event suppression to keep a given event from firing on a
rule, without having to remove that rule from the rulebase. Event suppression
happens before event thresholding, so suppressed events will not be counted in

threshold values. Event suppression is usually used to ignore known events from
known subnets.
The Alerting and Logging Components
Finally, after the rules have been matched against the data, we have the alerting
and logging components.The logging mechanism in Snort will archive the
packets that triggered Snort rules, while the alerting mechanism is used to notify
the analyst that a rule has fired. Like the preprocessors, these functions are called
from your snort.conf file, where you can specify which alerting and logging
components you want to enable.You have determined which data is worth
alerting on, but you have a wide variety of choices as to how to send these alerts,
and where and how to log your packet data.You can send alerts through SMB
pop-up windows to a Windows workstation, record/log them to a logfile, across
a network connection through UNIX sockets, or via SNMP traps.The alerts can
also be stored in an SQL database such as MySQL or PostgreSQL. Some third-
party systems will page a system administrator with IDS alerts, or even send them
to a cell phone via SMS text messages.
Useful Add-Ons to Snort
There are many additional programs available to help you get the most
out of your Snort alerts, and to help you parse the data in a way that’s
right for you and your network. Here are a few of our favorites:
■
The Analysis Console for Intrusion Detection (ACID), found
front end to Snort log analysis.
Tools & Traps…
online at www.andrew.cmu.edu/~rdanyliw/snort/
snortacid.html, is a PHP-based log parser, search engine, and
Continued
www.syngress.com
Simpo PDF Merge and Split Unregistered Version -