Managing Security with Snort and IDS Tools @Team DDU

Managing Security with Snort and IDS Tools @Team DDU
Managing Security with Snort
and IDS Tools
Table of Contents
About This Book
Assumptions This Book Makes
Chapter Synopsis
Conventions Used in This Book
Comments and Questions
Chapter 1. Introduction
1.1 Disappearing Perimeters
1.2 Defense-in-Depth
1.3 Detecting Intrusions (a
Hierarchy of Approaches)
1.4 What Is NIDS (and What Is
an Intrusion)?
1.5 The Challenges of Network
Intrusion Detection
1.6 Why Snort as an NIDS?
1.7 Sites of Interest
Chapter 2. Network Traffic
2.1 The TCP/IP Suite of
2.2 Dissecting a Network
2.3 Packet Sniffing
2.4 Installing tcpdump
2.5 tcpdump Basics
2.6 Examining tcpdump Output
2.7 Running tcpdump
2.8 ethereal
2.9 Sites of Interest
Chapter 3. Installing Snort
3.1 About Snort
3.2 Installing Snort
3.3 Command-Line Options
3.4 Modes of Operation
Chapter 4. Know Your Enemy
4.1 The Bad Guys
4.2 Anatomy of an Attack: The
Five Ps
4.3 Denial-of-Service
4.4 IDS Evasion
4.5 Sites of Interest
Chapter 5. The snort.conf File
5.1 Network and Configuration
5.2 Snort Decoder and
Detection Engine Configuration
5.3 Preprocessor Configurations
5.4 Output Configurations
5.5 File Inclusions
Chapter 6. Deploying Snort
6.1 Deploy NIDS with Your
Eyes Open
6.2 Initial Configuration
6.3 Sensor Placement
6.4 Securing the Sensor Itself
6.5 Using Snort More
6.6 Sites of Interest
Chapter 7. Creating and
Managing Snort Rules
7.1 Downloading the Rules
7.2 The Rule Sets
7.3 Creating Your Own Rules
7.4 Rule Execution
7.5 Keeping Things Up-to-Date
7.6 Sites of Interest
Chapter 8. Intrusion Prevention
8.1 Intrusion Prevention
8.2 IPS Deployment Risks
8.3 Flexible Response with
8.4 The Snort Inline Patch
8.5 Controlling Your Border
8.6 Sites of Interest
Chapter 9. Tuning and
9.1 False Positives (False
9.2 False Negatives (Missed
9.3 Initial Configuration and
9.4 Pass Rules
9.5 Thresholding and
Chapter 10. Using ACID as a
Snort IDS Management
10.1 Software Installation and
10.2 ACID Console Installation
10.3 Accessing the ACID
10.4 Analyzing the Captured
10.5 Sites of Interest
Chapter 11. Using SnortCenter
as a Snort IDS Management
11.1 SnortCenter Console
11.2 SnortCenter Agent
11.3 SnortCenter Management
11.4 Logging In and Surveying
the Layout
11.5 Adding Sensors to the
11.6 Managing Tasks
Chapter 12. Additional Tools
for Snort IDS Management
12.1 Open Source Solutions
12.2 Commercial Solutions
Chapter 13. Strategies for HighBandwidth Implementations of
13.1 Barnyard (and Sguil)
13.2 Commericial IDS Load
13.3 The IDS Distribution
System (I(DS)2)
Appendix A. Snort and ACID
Database Schema
A.1 acid_ag
Appendix B. The Default
snort.conf File
Appendix C. Resources
C.1 From Chapter 1:
C.2 From Chapter 2: Network
Traffic Analysis
C.3 From Chapter 4: Know
Your Enemy
C.4 From Chapter 6: Deploying
C.5 From Chapter 7: Creating
and Managing Snort Rules
C.6 From Chapter 8: Intrusion
C.7 From Chapter 10: Using
ACID as a Snort IDS
Management Console
C.8 From Chapter 12:
Additional Tools for Snort IDS
C.9 From Chapter 13:
Strategies for High-Bandwidth
Implementations of Snort
Table of Contents
Reader Reviews
Managing Security with Snort and IDS To
By Kerry J. Cox, Christopher Gerg
Publisher : O'Reilly
Pub Date : August 2004
ISBN : 0-596-00661-6
Pages : 288
This practical guide to
managing network security
covers reliable methods for
detecting network intruders,
from using simple packet
sniffers to more sophisticated
IDS (Intrusion Detection
Systems) applications and the
GUI interfaces for managing
them. A comprehensive
resource for monitoring illegal
entry attempts, Managing
Security with Snort and IDS
Tools provides step-by-step
instructions on getting up and
running with Snort 2.1, and
how to shut down and secure
workstations, servers, firewalls,
routers, sensors and other
network devices.
Table of Contents
Reader Reviews
Managing Security with Snort and IDS To
By Kerry J. Cox, Christopher Gerg
Publisher : O'Reilly
Pub Date : August 2004
ISBN : 0-596-00661-6
Pages : 288
About This Book
Assumptions This Book Makes
Chapter Synopsis
Conventions Used in This Book
Comments and Questions
Chapter 1. Introduction
Section 1.1. Disappearing Perimeters
Section 1.2. Defense-in-Depth
Section 1.3. Detecting Intrusions (a
Hierarchy of Approaches)
Section 1.4. What Is NIDS (and What Is an
Section 1.5. The Challenges of Network
Intrusion Detection
Section 1.6. Why Snort as an NIDS?
Section 1.7. Sites of Interest
Chapter 2. Network Traffic Analysis
Section 2.1. The TCP/IP Suite of Protocols
Section 2.2. Dissecting a Network Packet
Section 2.3. Packet Sniffing
Section 2.4. Installing tcpdump
Section 2.5. tcpdump Basics
Section 2.6. Examining tcpdump Output
Section 2.7. Running tcpdump
Section 2.8. ethereal
Section 2.9. Sites of Interest
Chapter 3. Installing Snort
Section 3.1. About Snort
Section 3.2. Installing Snort
Section 3.3. Command-Line Options
Section 3.4. Modes of Operation
Chapter 4. Know Your Enemy
Section 4.1. The Bad Guys
Section 4.2. Anatomy of an Attack: The Five
Section 4.3. Denial-of-Service
Section 4.4. IDS Evasion
Section 4.5. Sites of Interest
Chapter 5. The snort.conf File
Section 5.1. Network and Configuration
Section 5.2. Snort Decoder and Detection
Engine Configuration
Section 5.3. Preprocessor Configurations
Section 5.4. Output Configurations
Section 5.5. File Inclusions
Chapter 6. Deploying Snort
Section 6.1. Deploy NIDS with Your Eyes
Section 6.2. Initial Configuration
Section 6.3. Sensor Placement
Section 6.4. Securing the Sensor Itself
Section 6.5. Using Snort More Effectively
Section 6.6. Sites of Interest
Chapter 7. Creating and Managing Snort Rules
Section 7.1. Downloading the Rules
Section 7.2. The Rule Sets
Section 7.3. Creating Your Own Rules
Section 7.4. Rule Execution
Section 7.5. Keeping Things Up-to-Date
Section 7.6. Sites of Interest
Chapter 8. Intrusion Prevention
Section 8.1. Intrusion Prevention Strategies
Section 8.2. IPS Deployment Risks
Section 8.3. Flexible Response with Snort
Section 8.4. The Snort Inline Patch
Section 8.5. Controlling Your Border
Section 8.6. Sites of Interest
Chapter 9. Tuning and Thresholding
Section 9.1. False Positives (False Alarms)
Section 9.2. False Negatives (Missed Alerts)
Section 9.3. Initial Configuration and Tuning
Section 9.4. Pass Rules
Section 9.5. Thresholding and Suppression
Chapter 10. Using ACID as a Snort IDS
Management Console
Section 10.1. Software Installation and
Section 10.2. ACID Console Installation
Section 10.3. Accessing the ACID Console
Section 10.4. Analyzing the Captured Data
Section 10.5. Sites of Interest
Chapter 11. Using SnortCenter as a Snort IDS
Management Console
Section 11.1. SnortCenter Console
Section 11.2. SnortCenter Agent Installation
Section 11.3. SnortCenter Management
Section 11.4. Logging In and Surveying the
Section 11.5. Adding Sensors to the Console
Section 11.6. Managing Tasks
Chapter 12. Additional Tools for Snort IDS
Section 12.1. Open Source Solutions
Section 12.2. Commercial Solutions
Chapter 13. Strategies for High-Bandwidth
Implementations of Snort
Section 13.1. Barnyard (and Sguil)
Section 13.2. Commericial IDS Load
Section 13.3. The IDS Distribution System
Appendix A. Snort and ACID Database
Section A.1. acid_ag
Appendix B. The Default snort.conf File
Appendix C. Resources
Section C.1. From Chapter 1: Introduction
Section C.2. From Chapter 2: Network
Traffic Analysis
Section C.3. From Chapter 4: Know Your
Section C.4. From Chapter 6: Deploying
Section C.5. From Chapter 7: Creating and
Managing Snort Rules
Section C.6. From Chapter 8: Intrusion
Section C.7. From Chapter 10: Using ACID
as a Snort IDS Management Console
Section C.8. From Chapter 12: Additional
Tools for Snort IDS Management
Section C.9. From Chapter 13: Strategies for
High-Bandwidth Implementations of Snort
Copyright © 2004 O'Reilly Media, Inc.
Printed in the United States of America.
Published by O'Reilly Media, Inc., 1005
Gravenstein Highway North, Sebastopol,
CA 95472.
O'Reilly books may be purchased for
educational, business, or sales
promotional use. Online editions are also
available for most titles
( For more
information, contact our
corporate/institutional sales department:
(800) 998-9938 or
[email protected]
Nutshell Handbook, the Nutshell
Handbook logo, and the O'Reilly logo are
registered trademarks of O'Reilly Media,
Inc. Managing Security with Snort and
IDS Tools, the image of a man on a rope
with an ax, and related trade dress are
trademarks of O'Reilly Media, Inc.
Many of the designations used by
manufacturers and sellers to distinguish
their products are claimed as trademarks.
Where those designations appear in this
book, and O'Reilly Media, Inc. was aware
of a trademark claim, the designations
have been printed in caps or initial caps.
While every precaution has been taken in
the preparation of this book, the publisher
and authors assume no responsibility for
errors or omissions, or for damages
resulting from the use of the information
contained herein.
This book explains how to manage your
network's security using the open source
tool Snort. The examples in this book are
designed for use primarily on a Red Hat
Linux machine. They should be fully
functional on the latest Red Hat Enterprise
Linux version as well as the latest Fedora
release by Red Hat. All instructions were
documented using the most recent Red Hat
releases, patches, and software. The
applications were configured using default
packages needed for a standard
installation, and each machine was
secured according to the latest errata.
The instructions in this book apply to
other Linux flavors, such as SuSE,
Gentoo, Debian, and most Unix variants,
including FreeBSD, OpenBSD, and
Solaris. Many of the applications are
available for download as source or as
precompiled binaries. Since performance
is often a consideration when deploying
an IDS solution, you will probably find
that building the applications from source
yields the best results. If you do not have
the time, desire, or need to build from
source, the prebuilt packages should work
just fine and install without trouble on
most systems. Consult your Linux
distribution or Unix-based operating
system for further information regarding
source compilation and installation. Snort
binaries are also available for the
Microsoft Windows platform, and
instructions for running Snort on a
Windows platform are included.
Links to the applications and their
respective web sites are provided
throughout and at the end of the chapters.
Appendix C also contains a compendium
of all software programs and applications
referenced. Check all software sites
regularly for the latest updates and
information regarding their use. Many of
the programs are under active
development and new versions are posted
frequently. Some applications require an
update with the release of new Linux
versions. Stay current with the most recent
release in order to avoid any
vulnerabilities or security issues that
appear over time.
Topics covered include:
Packet capture and analysis using a
variety of command-line and GUI
An introduction to the interpretation
of packet headers and content within
an IDS environment.
The threats to your organization's
technology assets.
Instructions for installing,
configuring, tuning, and customizing
an open source, enterprise-level
network intrusion detection system
(NIDS) for use in corporate and/or
home office environments.
A discussion of ways to utilize Snort
as a sniffer, a network gateway that
blocks malicious traffic, and a
passive IDS sensor.
Details on how to configure and tune
your Snort IDS installation to
maximize the effectiveness and
minimize the labor involved in
detecting and tracking down attacks.
An in-depth look at a variety of
administration tools that assist in the
management of the Snort IDS
Strategies for deploying an IDS in
switched, high-security, and highbandwidth environments.
This book is designed for network,
system, and security administrators of
large-scale enterprises as well as
managers of small businesses or home
offices. The instructions should be
readable for those with only a small
amount of network and Unix experience,
but also useful for experienced
administrators with a varied background
in networking and system administration.
To be sure, the more experienced you are,
the easier it will be to interpret the results
generated by the Snort IDS.
About This Book
Snort can be used for a variety of
applications, from acting as a simple
network sniffer to an enterprise-class
gateway intrusion detection system (IDS).
This book discusses the various ways to
use Snort, and methods of configuring,
tuning, and customizing the application to
best suit your environment. Implementing
an IDS solution can be a labor-intensive
and sometimes overwhelming project.
This book helps streamline the processes
of the initial setup and ongoing care and
feeding of Snort.
All the source code discussed here is
freely available for download off the
Internet. I have avoided any software that
is closed source, requires a license, or
costs money. Though links and source
code versions do change over time, every
effort has been made to keep listings and
release numbers for each application as
up-to-date as possible. If you find the URL
does not work as listed, please check with
some of the major open source
repositories: and If you are unable to
locate the applications, use a search
engine such as to
find the program's new home or current
web site.
Links to required libraries or associated
applications are usually found on the home
pages of most programs. For example,
links to SnortCenter and Barnyard are
found on the main Snort page at
Now that you know what this book is
about, here is what it's not about. This
book is not a beginner's guide to packet
analysis. It is intended to help you
implement viable solutions to everyday
intrusion detection problems. This book
does not spend countless pages examining
the nuances and vagaries of every type of
fragmented packet or possible buffer
overflow. Instead, it explains how to
quickly capture a sampling of network
traffic and look for the tell-tale signs that
indicate hostile activity.
If you are searching for a theoretical
manual that provides detailed insight into
every possible security application or that
explains how to dissect new intrusive
packets, you won't find it here. This book
deals with strategies and speedy
implementations using a reasonable,
common-sense approach. By the end of
this book, the reader will understand that a
network-based intrusion detection system
is one part of a larger strategy of defensein-depth. The book is based on the
experience of a Network Security
Engineer who has both attacked and
defended very large corporate networks
and systems. Whether you are looking for
something to help secure your home
network, or looking for an Enterprise-
class solution that can watch 2 Gbps of
bandwidth in near-real-time, this book
will help.
Assumptions This Book
This book does not make too many
demands on the average reader. It is
written in an informal manner and is
intended for most security administrators,
whether they are using Linux (or another
Unix offshoot like BSD) or Windows. The
main focus of the book will be running
Snort on a Linux platform. Even beginning
Linux users should have no trouble
grasping the concepts. Most
applications​along with their installation
and configuration​are clearly spelled out.
While this book will provide the average
user with the ability to get a Snort sensor
up and running, professional deployments
of any IDS solution benefit from a good
knowledge of networking and system
administration. Without this background,
discrimination of what is naughty and
what is nice will be more difficult.
If any of the steps explained in later
chapters do not answer all your questions,
please consult the application's home page
or subscribe to its mailing list, if one is
available. It will be helpful if you are
familiar with Usenet newsgroups and can
post detailed questions regarding any
additional use of the applications
presented here. You will find that the open
source community surrounding Snort and
the related applications is active and
incredibly helpful.
This book assumes that you have access to
one or more machines, can perform a
standard operating system installation, and
have a relatively stable connection to the
Internet. It also operates on the assumption
that a LAN or switched Ethernet network
is available for testing purposes. Though
this is not required, it does help when
monitoring packets flowing between
machines and in and out of networks. This
book also presupposes that a secure
firewall is in place. It is your
responsibility to ensure that your network
remains safe during the IDS installation
and implementation phase. Newly
installed systems do not survive long
when exposed to the Internet without
Chapter Synopsis
Chapter 1
Introduces the concepts behind
network security and intrusion
Chapter 2
Goes into some depth on how the
systems on your network use the
network to accomplish their tasks.
The structure of packets will be
examined, equipping you to
recognize anomalous network traffic.
Chapter 3
Introduces you to getting Snort up and
running quickly using the various
command-line options. It discusses
the various modes in which Snort can
be used, including as a sniffer and
packet logger.
Chapter 4
We examine how the "bad guys"
attempt to probe, penetrate, persist,
propagate, and paralyze your
network and systems. Methods of
detecting these methods are
Chapter 5
Provides an in-depth examination of
this central configuration file. The
snort.conf file controls how Snort
watches the network and detects
malicious activity.
Chapter 6
Strategies for making a Snort
Strategies for making a Snort
deployment as effective and
successful as possible are discussed
in this chapter.
Chapter 7
The core of a signature-based
intrusion detection system are the
rules that recognize attacks in
progress. One of the real strengths of
Snort is the flexibility and
discrimination of its rule sets.
Chapter 8
Several mechanisms and strategies
can be employed that turn Snort from
an intrusion detection system into an
intrusion prevention system. These
strategies are not without their own
risks, however.
Chapter 9
This is perhaps the most important
chapter. Proper tuning and
thresholding allows security
administrators to minimize the
number of false positives generated
by an IDS sensor, making their time
spent working with Snort more
efficient and effective.
Chapter 10
ACID is a popular, powerful, webbased IDS management system for
managing alerts generated by Snort.
Chapter 11
SnortCenter makes administering
multiple IDS sensors much easier.
Chapter 12
A wide variety of tools can help
A wide variety of tools can help
manage a Snort-based IDS
deployment. Some of these solutions
are more effective than others.
Chapter 13
If your intention is to deploy Snort as
an IDS in a high-demand
environment, this chapter will help
by discussing strategies that ensure
nothing is missed by overburdened
Appendix A
Provides the schemas for the Snort
and ACID database tables in order to
aid developers in creating new tools
or modifying existing tools.
Appendix B
Presents the default snort.conf file
for reference when reading the book
and configuring sensors. The
comments are actually quite good,
Appendix C
Provides a compilation of web
resources and download sources
from throughout the book.
Conventions Used in This
The following typographical conventions
are used in this book:
Plain text
Indicates menu titles, menu options,
menu buttons, preprocessors, and
keyboard accelerators (such as Alt
and Ctrl).
Indicates new terms, example URLs,
example email addresses, filenames,
file extensions, pathnames,
directories, and Unix utilities.
Constant width
Indicates commands, options,
switches, variables, attributes, keys,
functions, types, classes,
namespaces, methods, modules,
properties, parameters, values,
objects, events, event handlers, XML
tags, HTML tags, macros, the
contents of files, or the output from
Constant width bold
Shows commands or other text that
should be typed literally by the user.
Constant width italic
Shows text that should be replaced
with user-supplied values.
This icon signifies a tip, suggestion, or
general note.
This icon indicates a warning or
Comments and Questions
Please address comments and questions
concerning this book to the publisher:
O'Reilly Media, Inc.
1005 Gravenstein Highway North
Sebastopol, CA 95472
(800) 998-9938 (in the United States
or Canada)
(707) 829-0515 (international or
(707) 829-0104 (fax)
We have a web page for this book, where
we list errata, examples, and any
additional information. You can access
this page at:
To comment or ask technical questions
about this book, send email to:
[email protected]
For more information about our books,
conferences, Resource Centers, and the
O'Reilly Network, see our web site at:
The authors wish to thank the people who
contributed to this project.
Kerry Cox
I owe many thanks to all the people who
shared with me their time, talents, and
experiences while patiently answering my
questions. Thanks especially to all the
employees at KSL, Bonneville
International, Bonneville
Communications, LDS Business College,
and Deseret Management Corporation
who allowed me to install intrusion
detection systems on their servers and then
critiqued the systems' performance,
providing me with feedback that assisted
in many ways to make this a better book.
I would especially like to thank all the
technical and nontechnical staff with
whom I work at Bonneville International,
KSL, and the Deseret Management
Corporation: Greg James, Roger Graves,
Owen Smoot, Don Huntsman, Steve
Tolman, Edward Cheadle, Brent
Cherrington, Mark Fenton, Jason
Williams, Hal Whitlock, Steve Wise,
Bryan Carter, Brent Cole, Karl Hancock,
Trevor Gunnell, Jamie Hall, Kevin
McReynolds, Julie Hill, Jason Jones, Amy
Kimball, Pat Neilson, and the many others
whom I may have forgotten.
According to Eric S. Raymond, "Given
enough eyeballs, all bugs are shallow."
This was especially true of the assistance
I received from many friends and coworkers. There are fewer errors here than
there might otherwise have been thanks to
their diligence in proofing this material. I
am deeply indebted to these people for the
time and effort they took to verify the
accuracy of what I wrote. I consider each
and every one contributing editors to this
work. This is as much for them as it is for
the readers.
I wish especially to thank the following
people, who spent many hours reviewing
and critiquing the text and code of this
book before submissions were sent to
O'Reilly. I am extremely grateful to Jason
Jones for checking each chapter's syntax
and tightening up the content. He pointed
out some crucial items that made the
reading flow better. Our conversations to
and from work every day helped to
improve the quality of this material. I am
deeply indebted to him for all his work.
I wish to thank Brad Hokanson for testing
the source code and installing numerous
programs on his machines. He proved that
everything shown here actually works on
various operating systems. His work with
encryption and wireless security was most
valuable. I want to thank Jason Williams
for his help in proofing the layout and
looking over the subject matter for
viability. Edward Cheadle was very
helpful in implementing many of these
applications in real-world scenarios. His
feedback improved much of the content.
Thanks to Steve Scott for his assistance in
providing detailed IDS documentation.
Also, I owe many thanks to Patrick S.
Harper for his useful notes and
explanations for performing a full sourcecode install. His excellent paper has
helped many a beginner on the road to
configuring a working IDS box. Thanks
also to Jamie Hall and Karl Hancock for
continued feedback from their own
experiences with open source intrusion
detection systems.
I also need to thank Jason Williams again,
for providing me with the laptop on which
I ran Linux. Many are the nights and days
on the train I was able to write this book
thanks to his donation. It proved very
useful for testing Kismet and AirSnort and
setting up wireless security applications.
My hat is also off to Mike Loukides for
his assistance in bringing this book to
print. He provided invaluable suggestions
for improving the layout, content, and
syntax of each chapter. I value his input
and appreciate the trust he has placed in
me. I want to also thank the several
technical reviewers who proofed this
document for potential flaws or errors. I
want to personally thank Edin Dizdarevic
for his close scrutiny, analysis, and
commentary. I very much enjoyed his
German commentary and notes on each
section. Thanks also to the other editors
who contributed their time and talents to
making this a better book: Kevin
Binsfield, Andrea Barisani, Daniel
Harrison, and Adam Hogan.
I would especially like to thank my wife,
Karen, for her encouragement. It was she
who suggested I write this book and stood
by me these past few months. Her
unwavering support has not gone
unnoticed. I have also my boys to thank for
their encouragement. Kids, I'm finally
done. Let's play.
Christopher Gerg
This book would not have been possible
without the support of my peers, friends,
and family. The Security Services team
that I work with at Berbee Information
Networks is the most talented and diverse
group of people I've had the privilege to
work and learn with. I've learned more in
the last five years than I have up to that
point in my life. Paul Tatarsky, Matt Jach,
Peyton Engel, David Klann, and Joe
Mondloch have shared their wit and large
brains with me most generously. I hope
I'm able to repay a fraction of the debt I
owe. (Assume the horse stance...)
Thanks to Eric Patterson for everything.
Of course, I wouldn't be able to
accomplish much of anything without the
support of my wife, Becky, and our two
crumb-crunchers, Matthew (shorty) and
Sarah (the Bunner). They keep me sane
and centered. Well, centered, anyway.
Standard thanks to my Mother and Father
for having me and setting the stage for my
career and fruitful adulthood. (Hi,
A special thanks to Jim Elliot for
introducing me to my editor, Mike
Loukides. Thanks, Mike, for giving me the
opportunity to step into this project. The
work of John Ives, the technical reviewer,
was excellent​thank you very much.
Chapter 1.
This book is about building a networkbased intrusion detection system (NIDS)
based on the open source application
called Snort. Snort got a modest start as
the open source project of a software
engineer names Martin Roesch (who
incidentally was the lead engineer in the
development of an IDS solution for GTE).
Snort is now a high-performance, fullfeatured solution that provides
competition for some very expensive
commercial solutions (and surpasses
A context for the use of an NIDS solution
is established by examining the challenges
confronting a network administrator with
regards to security. New technologies are
making it easier for remote users and
partners to access the insides of the
network, bypassing perimeter security
entirely. A new breed of Internet worm is
attacking from a variety of
directions​through email, across the
network, and even across virtual private
network (VPN) connections. Hacker
communities are creating tools that make
attacking a network much easier. This
gives rise to "script kiddies," who
download an attack tool and penetrate an
organization's network​all without knowing
how the tool they are using works or the
effect it will have on the target system.
1.1 Disappearing Perimeters
In the old days (two years ago or so), a
firewall was most of what an
administrator needed to protect a network
from attack. It was easy to establish where
your network ended and the Internet
began. Technological advances and
decreasing costs for wide area network
technologies have eroded this concept of a
perimeter. VPNs have all but replaced
conventional dial-up modem pools. Most
users have high-speed DSL or Cable
Modem service, and the VPN makes the
user feel like he's sitting at his desk. Some
VPNs use an appliance that sits on the
perimeter of the network and has the
capability of controlling how the network
is used remotely. While this is a boon for
telecommuters, it is a real risk for most
networks. A virus or worm-infected
system on the user's home network
suddenly has unfettered access to the
inside of your network. That high-speed
highway into your network can allow
rapid propagation of an aggressive worm.
Connections to business partners used to
be an expensive proposition and were
only for the most well-to-do
organizations. Dedicated T1 links are
expensive. With less expensive network
options (not to mention network-tonetwork VPN connections), this cost has
decreased significantly. This allows many
organizations to connect their network to
yours​sometimes directly into the internal
network. Without real precautions in
place, security problems on the partner
networks quickly become security
problems on your network​very often
undetected until much damage is done.
Whether you trust your partner to that
extent is another matter.
1.2 Defense-in-Depth
When deploying troops in a theater of
war, a general has to consider all the
ways an enemy may attack: by land (either
at the front line, or a commando raid
behind the lines), by sea (surface ships or
submarines), or by air (helicopters,
fighters, bombers, missiles, or artillery).
The general has to deploy defenses against
all potential vectors of attack. He doesn't
just trust the trenches at the front line for
all his security. He will deploy troops to
the front line, as well as at high-value
assets behind the lines. He will deploy a
variety of anti-submarine and anti-surface
ship defenses. He will deploy a variety of
anti-air assets to protect against the
various air threats. This concept of
multiple overlapping defensive measures
is known as defense-in-depth.
A similar system can be applied to
network security. Instead of trusting the
eroding value of perimeter defenses
(firewalls) for all of our security, we turn
to other mechanisms. We configure
systems according to industry-accepted
best practices (disable unnecessary
services, keep software updated, run
antivirus software). We establish a system
to securely aggregate our system logs in
one place (and we monitor those logs for
anomalies). We segregate our network to
control access to important machines and
to "wall-off" partner and remote
connections. We utilize strong
authentication and authorization practices.
And finally, we take steps to detect and
prevent intrusions (preferably attempted
intrusions) on our network and on our
systems. We also try to do this with
limited budgets and limited time. In the
real world, the general is trying to protect
against lost real estate. In the network
world, the administrator is protecting
against downtime and data loss. I won't
beat the analogy to death. The main thing
to remember is not to trust a single
component of your security framework for
all your security. If you are able to, apply
security as close to the thing you are trying
to secure as possible. These steps will
help you stop at least 80% of attacks.
Intrusion detection should catch the
remaining 20%.
1.3 Detecting Intrusions (a
Hierarchy of Approaches)
Intrusion detection is simply trying to
detect the signs of a network intruder
before damage is done, a service denied,
or data lost. This can be done through the
use of a variety of mechanisms. Properly
configured systems generate system logs
that keep track of services, users, and
data. These logs very often show traces of
suspicious (or downright nefarious)
activity. The problem is that these logs
often have a lot more information in them
than a security administrator is interested
in. It is important to consider system log
review as a basic intrusion detection
mechanism, though. Many times the system
logs show their value in a forensic
analysis after the fact.
The next layer of intrusion detection (and
prevention) is automated tools, commonly
referred to as host-based intrusion
detection (HIDS). HIDS tools include
antivirus software, personal firewalls,
NIDS installed on the individual hosts,
and a new breed of software (intrusion
prevention systems) that protects system
memory against buffer overflow attacks or
enforces security policies. Many products
are a hybrid mix of these solutions (a
personal firewall/antivirus product, for
The final layer of intrusion detection is
1.4 What Is NIDS (and What
Is an Intrusion)?
On a basic level, network intrusion
detection is exactly what it sounds like:
the process of determining when
unauthorized people are attempting to
break into your network. Keeping those
attackers out or extracting them from the
network once they've gotten in is a
different problem. Obviously, keeping
intruders out of your network is a
meaningless task if you don't know when
they're breaking in.
Detecting unauthorized connections is a
good start, but it is not the whole story.
Network intrusion detection systems like
Snort are great at detecting attempts to
login to your system, access unprotected
network shares, and things like that. But
there are other kinds of intrusion that are
not as clear-cut as an outsider walking
past the receptionist at the front desk and
sitting down at a computer. Is a denial of
service attack​one that operates by sending
a carefully crafted sequence of packets to
a network server and ultimately crashing
it​an intrusion? No one has literally gained
access to your machine's physical
resources. However, bandwidth, CPU
time, and hard-drive space on your IDS
are all consumed by the attack. Denial of
service is considered a successful attack
because it occupies resources that would
have been employed somewhere else.
Does someone probing your networks
with port scans or pings constitute an
intrusion? Perhaps not, but it is a sign that
she may soon start doing something more
hostile. So we also consider probing an
intrusion, and expect our intrusion
detection system to warn us whenever
things such as these happen.
Generally speaking, an intrusion detection
system like Snort scans network traffic
looking for suspicious activity based on
the signatures of bad packets. You are
probably already familiar with tools like
tcpdump and ethereal, which display all
the traffic flowing on your network within
a specific subnet. An intrusion detection
system is essentially an automated
tcpdump, a packet sniffer that sniffs in the
background and does not require you to
watch or analyze the traffic yourself.
Tools like ethereal work well for
debugging; for instance, when you have to
look at each packet to figure out what
might be wrong. But on any real network,
there is just too much traffic to watch for
suspicious activity. That is what
computers are good for: doing a very
boring job repetitively, and alerting you
when something interesting comes along.
An IDS watches the packets traversing
your network and decides whether
anything is suspicious. How does it know
what is suspicious? Snort bases its
analysis on the signatures of bad packets:
essentially, a list of descriptions of the
types of packets that indicate the system is
under attack or a successful attack has
already taken place. For example, if you
receive an ICMP packet that is abnormally
large, you may infer somebody is trying
the antiquated ping of death attack against
a host on the network. If you see
fragmented packets that are extremely
short, you may also infer that somebody is
trying one of the many attacks that rely on
fragmentation to sneak by firewalls. Snort
(and other intrusion detection systems)
comes with thousands of signatures, based
on attacks that have been observed "in the
wild." The list grows longer every day
and updates are constantly posted to the
Snort web site. Part of the job (and one
that is managed nicely by the tool we will
soon discuss) is keeping your signature
list up-to-date.
Snort and other intrusion detection
systems thus provide an important first
line of defense against attacks. If an
intruder manages to login to your network
server, you might be able to find the
evidence in system logs, although a smart
cracker would delete your logfiles. The
host intrusion detection system watches
for unauthorized activity on an individual
system. If someone manages to
compromise the same server using a
fragmentation attack, you might be able to
figure out what happened after the fact by
looking at logs, but you might not​and at
that point, it is too late.
While it is too optimistic to talk about
"real-time" intrusion detection, it is
extremely important that an IDS detect
attacks early, before any damage can be
done, and that it send notifications to you
and to a secure database. We discuss
"invisible" or stealthy methods of logging
Snort's warnings and alerts to a database
elsewhere. If you can head off an attack,
so much the better​but even if you cannot,
an IDS might be the only way to figure out
what happened and prevent it from
happening again.
1.5 The Challenges of
Network Intrusion Detection
The benefits of detecting an intrusion as
early as possible are undeniable. But it is
important to deploy an IDS with realistic
expectations. There are some real
challenges in installing, maintaining, and
interpreting the output from an intrusion
detection system.
1.5.1 Prerequisites
A potential intrusion detection
administrator needs a good knowledge of
the environment into which she is
introducing NIDS. What is the network
layout? This information helps determine
the positioning of the sensors and also
may help determine which mode of
operation should be used. What kinds of
systems are in the environment?
Windows? Unix? What services are the
systems providing? Email? Web services?
How is encryption used in the
A good understanding of how systems
communicate on the network is very
important in interpreting the output of the
NIDS sensors. Without knowing the
makeup of a TCP packet, an alert
specifying a problem within a packet will
only cause confusion. If you are not
familiar with network sniffing tools like
tcpdump and ethereal, spend some time
watching the traffic on your network.
Review the contents of Chapter 2 to help
you interpret the results. Only good can
come from this time spent watching and
learning how things talk and move around
your network. Without this background,
the job of determining what is really
something to worry about​as well as tuning
out unneeded rules and features​is very
1.5.2 False Positives
Very often (and especially before tuning),
when Snort sends you a warning that
something suspicious is happening, there
is nothing really serious going on. Any
NIDS is going to generate a lot of false
positives, warnings that someone or
something is launching some form of
attack, when in fact nothing is happening.
You may be able to minimize false
positives, but you cannot entirely
eliminate them. Furthermore, the more
false positives you receive, the more
likely it is that Snort is missing an actual
attack or subversive intrusion attempt. It is
up to you to figure out an acceptable level
of risk. Do you really want to be notified
about every port scan? About every
unauthorized attempt to mount a Windows
share? Even on a home network this can
quickly drive most sane administrators
There is no perfect solution. There's an
easy way to guarantee an attack is never
goes unnoticed: flag every incoming
packet as suspicious. That is obviously
not realistic. You won't have to worry
about missing a potential attack, but the
flood of false positives will be
overwhelming. At the other extreme, you
could tune out the majority of alerts and
turn off most of the features of Snort. You
won't have many false positives, but you'll
also miss many of the real dangers. You
must find a happy medium and decide just
how many alerts you are willing to
tolerate for the sake of your network. The
process of reaching this compromise can
only be accomplished over an extended
period of time, by fine-tuning Snort and
viable signatures and enabling or
disabling features within the Snort sensors
1.5.3 Missing Prerequisites
A common phrase I use when talking to
clients about deciding to deploy an IDS is,
"If you don't do basic system log review
on a regular basis, an IDS is just going to
generate more logs for you to ignore." As
discussed earlier, system logs are the first
line of defense in intrusion detection.
Reviewing system logs yields great
benefits in learning how your systems
function and in determining the health and
well-being of your systems. An IDS only
provides value as a component in a
defense-in-depth strategy. Do not lay all
security responsibility on your IDS
1.5.4 Unrealistic
When deciding to embark on a Snort
installation (or any other NIDS solution,
for that matter), understand that there is
some significant work that needs to be
done on the frontend. None of it is
particularly difficult, just time-consuming
and detail-oriented. A common
misconception is that once the NIDS
sensors are deployed and initially
configured, and the central management
console is built and reporting, the
administrator can throw a dust cloth on it
and walk away. Snort is a signature-based
NIDS. Signatures need to be updated
periodically to keep up with the latest
exploits and attack methods. They also
need constant tuning to eliminate false
positives and allow for changes in your
network environment. These tasks are not
overwhelming, but not allowing time for
them greatly diminishes the value of the
NIDS deployment.
1.6 Why Snort as an NIDS?
Snort represents a cost-effective and
robust NIDS solution that fits the needs of
many organizations. This book should be
all you need to get Snort installed,
configured, tuned, and alerting accurately
in your environment. Snort is covered
from initial configuration to ongoing
maintenance. Strategies are revealed to
make Snort useful for a home office or a
large corporation with a dedicated and
experienced network security staff. The
approach is one of attempting to derive
reasonable approaches to the issues at
hand. I try hard not to be a zealot.
Snort does not stand by itself as the
beginning and end of a security framework
for an organization. It is part of an overall
defense-in-depth strategy that incorporates
security in all aspects of a network.
Whether Snort is an important and
significant contributor relies on strong
planning and an ongoing dedication to the
care and feeding of your NIDS.
There are a wide variety of choices in the
area of intrusion detection. Digging
through the propaganda generated by the
various marketing departments is not easy.
Even the definition of intrusion detection
is murky, often moving from one solution
to another. To cut through the noise,
consider the following:
Open source software is hard to beat
on price. To be sure, very often such
software can be more difficult to
operate. Snort is one of the more
mature open source packages out
there and competes with any
commercial product for return on
investment. There is the occasional
C-level executive that will throw out
an open source solution because
there is no one to call when it breaks.
With mainstream acceptance of open
source solutions increasing
constantly, this is less often a
problem. For those who cling to this
thinking, there are several
commercial products that use Snort
as their core technology. Chief
among these is Sourcefire, an
organization at the forefront of Snort
development and implementation.
Sourcefire was started by a fellow
named Martin Roesch, now the CTO
(does that name sound familiar?).
Stability, speed, and robustness
Since very early on, one of the main
goals of Snort's developers was to
keep it lightweight, fast, and lean, in
order to keep up with ever-
increasing network bandwidths.
Since it is not a new solution, bugs
are virtually nonexistent. A Snort
instance crashing is almost unheard
of. I personally have a Snort
installation that watches sustained
450 Mbps of bandwidth using a
cluster of six sensors. The only time
Snort is down is during a planned
maintenance window to upgrade
signatures or move to a new version.
This demonstrates not only Snort's
stability, but also its ability to be
adapted to very demanding
environments (see Chapter 13).
The preprocessors
In Chapter 5, I go into great detail on
the inner workings of the Snort
preprocessors. For the moment, let
me just say that the preprocessors
massage the network data flow in
real time to increase the chances of a
signature noticing a malicious packet.
The incredibly complex ways that
computers can communicate and be
used on a network presents a real
challenge. The preprocessors act as
interpreters for the Snort detection
engine. Another real strength of the
preprocessors is their ability to
defeat many IDS evasions
techniques. Chapter 4 discusses the
ways that attackers go after your
systems and also the ways they try to
trick, hide from, or simply
overwhelm your IDS defenses.
Snort is very flexible in the ways it
can be deployed. Chapter 4 through
Chapter 8 detail the ways that Snort
can be used, from a simple network
sniffer to a true gateway IDS that
kills a dangerous network
conversation in its tracks. Because
you can customize existing signatures
or write your own custom rules,
Snort can adapt to almost any
There are a number of applications
that can act as central monitoring and
alerting consoles. I talk about
several, concentrating on ACID and
SnortCenter. There are also a number
of community contributed scripts and
plug-ins that extend Snort's
functionality​allowing syslogs to be
parsed and alerted from, and another
allowing the dynamic creating of
access control lists on Cisco routers,
for example.
Industry support
Particularly with the advent of
several commercial versions of
Snort, many security industry
watchdogs include Snort signatures
in their security announcements
(CERT and SANS, to name two).
The Snort open source community is
very active keeping signatures up to
date. When worms are ravaging the
Internet and there are constantly new
variants, there are sometimes updates
multiple times a week. The Snort
mailing lists are a fantastic resource
for people who are trying to run
Snort or write their own signatures.
1.7 Sites of Interest
Snort's homepage
SecurityFocus IDS
The SANS Institute
CERT homepage
The NSA Security
tcpdump homepage
ethereal homepage
Chapter 2. Network
Traffic Analysis
A network IDS is really just a network
sniffer that compares the contents of
packets of information traveling the wire
to a catalog of signatures that indicate
potential malicious activity. A sniffer is a
device (formerly very expensive, specialbuilt systems, but now a simple laptop)
with a network card that watches traffic
between computers and other networkcapable devices. This device can do a
number of things with this traffic: record,
sort, or analyze it.
Because most network security and
intrusion detection is based on identifying
and interpreting packet data, it's important
to understand how a packet is constructed
and how it performs in real-world
scenarios. In most cases, you can trust
intrusion detection tools such as Snort and
their alerts regarding suspicious packets,
but there are times when the packet
payload must be examined a person rather
than a computer program. A careful
analysis of a packet is sometimes required
to determine if an alert is in fact a real
alert or a red herring. Not knowing at least
the basics of how computers use the
network to communicate makes this task
much harder, if not impossible.
This chapter starts with some level-setting
discussions about how networks are used
by systems to communicate using the
TCP/IP suite of protocols. We'll cover the
TCP/IP suite in general and concentrate on
TCP in particular. While looking at TCP,
we will break down the structure of an
individual TCP packet, looking at the
different options available. We will then
examine the very important concept of the
three-way handshake. This will be a
quick survey of TCP/IP networking and is
not meant to be a comprehensive
education. The goal is to give you the
tools you need to interpret what your IDS
sensors are telling you.
One of the main tools used to capture and
analyze network traffic is an open source
tool called tcpdump. tcpdump is one of
the most common tools for learning the
basics of interpreting packets. It's easy to
install on a number of platforms, freely
available, runs on both Unix-based and
Windows systems, and it's very flexible. I
explain how to install and properly
configure tcpdump and examine the basic
usage of tcpdump as a teaching tool and a
security application. I then look at
ethereal, a graphical tool for examining
network packets. ethereal has all the
functions of very expensive commercial
network analysis products and is an
invaluable tool for a network
administrator. The reason we start with
the command-line-based tcpdump instead
of the easy-to-use ethereal is to gain an
understanding of what's going on under the
hood. Since it is common to only have
access to a remote command shell on a
system, knowledge of the command-line
tools at your disposal is vital. Once you
become familiar with using a sniffer and
discover the true value of watching your
network at this level, ethereal will be at
your side constantly. Finally, we will get
to work and examine how systems
establish and engage in conversations.
2.1 The TCP/IP Suite of
TCP/IP (Transmission Control
Protocol/Internet Protocol) is a suite of
network protocols. TCP and IP are only
two of the protocols within the suite but
arguably the most important. The TCP/IP
protocols were designed to allow
different applications on dissimilar
operating systems to communicate across
a network. I'll talk about some (certainly
not all) of the TCP/IP protocols in the
context of intrusion detection.
2.1.1 TCP
TCP (Transmission Control Protocol) is a
connection-oriented transport layer
protocol designed to provide a reliable
connection for data exchange between two
systems. TCP ensures that all packets are
properly sequenced and acknowledged,
and that a conversation is established
before data is sent. This ensures that both
machines are ready to have a conversation
and that the information moving from one
system to another makes it without
anything being lost. Services using TCP as
their communication mechanism listen on
specific port numbers for clients to make
requests. Some applications that make use
of TCP as their method of communication
Virtual Terminal Protocol (Telnet
port 23)
File Transfer Protocol (FTP ports 20
and 21)
Simple Mail Transfer Protocol
(SMTP port 25)
Secure Shell (SSH port 23)
TCP provides its reliability through the
use of an acknowledgment (network geeks
call this an ACK). An ACK is returned by
a receiving machine to a sending machine
to tell the sender that the message that was
sent was received without error. If the
sender does not receive an ACK, it
resends the message.
If a receiving machine needed to send an
ACK for every packet, it would result in
incredible overhead for the system and the
network. To reduce the overhead, a
mechanism called windowing is used. The
receiving system advertises a certain
number of packets it can receive at a time
(essentially an input buffer size). The
sending system watches for an ACK after
the designated number of packets is sent.
If an ACK is not received, data will be
retransmitted from the point of the last
ACK. If the receiving machine has trouble
keeping up with the inflow of packets, it
reduces the window size. If the machine is
really getting hammered, it advertises a
window size of zero and the sender stops
transmission until an ACK with a nonzero
window value is received. The three-way
To establish a TCP conversation, a threeway handshake is exchanged between a
sending machine and a receiving machine.
This establishes a communications link
between the two systems. To start things,
the sending machine sends a synchronize
sequence numbers (SYN) packet to the
receiving machine, which informs the
receiving machine that a new conversation
is requested and establishes a starting
point for the sequence numbers that will
number the packets being sent. These
sequence numbers ensure that data is
received and processed in the order that it
was sent.
The receiving machine must acknowledge
the SYN packet and tell the sending
machine the initial sequence number that it
will be using. In order to do this, the
receiving machine transmits a packet with
both a SYN and an ACK packet to the
sending machine. Finally, the sending
machine sends an ACK to the receiving
machine, along with the first batch of data
(Figure 2-1).
Figure 2-1. Three-way
This entire process ensures that the
receiving machine is alive and ready to
accept data. To end the conversation, a
similar three-step process takes place,
wrapping things up with a FIN packet.
Some applications choose to ignore the
standard and simply send a RST packet
that ends the conversation instead of
performing a graceful close.
2.1.2 UDP
UDP (User Datagram Protocol) provides
an unreliable, connectionless system to
deliver packets. Instead of providing
mechanisms to guarantee delivery and
sequencing, UDP lets upper-level
applications worry about lost or out-ofsequence data. This protocol allows
messages (called datagrams with UDP) to
be sent without the overhead involved
with ACKs and the establishment of a
communications link. UDP is mostly used
for broadcast communications or networkaware computer games. Services using
UDP listen on specific port
numbers​similar to TCP. Upper-level
applications that use UDP as their
communications mechanism include:
Trivial File Transfer Protocol (TFTP
port 79)
Network File System (NFS port
Unreal Tournament 2004 (port 7777)
2.1.3 IP
The Internet Protocol (IP) is used to
handle datagram services between hosts.
It handles the addressing, routing,
fragmentation, and reassembly of packets.
IP addresses are 32 bits long and are
organized into 4 octets separated by
periods. Here's an example:
2.1.4 ICMP
The Internet Control Message Protocol
(ICMP) performs four main functions:
Flow control
When a system is too busy to handle
incoming streams of data, ICMP
sends a Source Quench message to
stop the stream.
Unreachable destination alerts
If a system is unreachable, due to an
address not matching an system on
the network, or due to a link failure,
a router will send a Destination
Unreachable message to the sending
Redirecting routes
A gateway machine can direct a
sending machine to another gateway
if it knows that there exists a
preferential route to the network that
the destination system resides on. It
does this by sending an ICMP
Redirect message.
Checking remote hosts
ICMP echo messages are used to
check the connectivity to a target
system. These are commonly called
Many network administrators restrict the
types of ICMP packets allowed to
traverse their networks. There are a
number of network discovery tools that
use ICMP to find information about the
type and version of operating system
running on a system.
That said, there is an argument against
blocking ICMP in general. A ping of death
is an oversized ICMP packet that causes a
system to lock up. The days of systems
being vulnerable to these sorts of things
are past. Most firewalls discard such
malformed packets automatically. In
addition, ICMP is one of the most useful
troubleshooting tools for network
administrators. Blocking ICMP takes this
useful tool out of your administrator's
2.1.5 ARP
Every network interface card has a unique
serial number associated with it (called a
MAC address). At the lowest levels, this
serial number is used to direct network
packets to specific hosts on the local
network. To send a packet to another
network, an IP address is required.
Mapping IP addresses to these MAC
addresses is handled with the Address
Resolution Protocol (ARP). A system will
build an address resolution table
dynamically as it learns of hosts on the
local network.
2.2 Dissecting a Network
A network packet is nothing more than a
chunk of data that an application wants to
deliver to another system on the network.
This chunk of data has information added
to the front and back that contains
instructions for where the data needs to go
and what the destination system should do
with it once it arrives. The addition of this
routing and usage information is called
The TCP/IP model uses four layers of
encapsulation, also referred to as a stack
or an IP stack. A packet is something like
Russian Matroishka or "nesting" dolls:
painted wooden figurines that hold
smaller versions of themselves. Each doll
is slightly smaller than the parent into
which it is placed. The smallest doll,
which cannot be opened, is the actual
application data. Each larger, enclosing
doll represents the header data affixed to
the original content. The insertion and
removal of each layer of a Matroishka
doll is equal to a network-level header
being added or removed from a packet.
Figure 2-2 illustrates the process. We start
with a chunk of application data, to which
we add a header. We take that data
(application data plus application header)
and package it up as a series of TCP
segments by adding TCP headers. We then
add an IP header to each TCP segment,
making IP datagrams. Finally, we add
Ethernet headers and trailers to the IP
datagrams, making an Ethernet frame that
we can send over the wire. Each layer has
its own function: TCP (the transport layer)
makes sure data gets from point A to point
B reliably and in order; IP (the network
layer) handles routing, based on IP
addresses and should be familiar to you;
and Ethernet (the link layer) adds lowlevel MAC (media access control)
addresses that specify actual physical
devices. It's also important to note that
there are several choices at each layer of
the model: at the transport layer, you can
see either TCP, UDP, or ICMP. Each
layer of the network stack is unaware of
the layers above and below. The
information coming from the layers above
are simply treated as data to be
encapsulated. Many application protocols
can be packed into TCP. When the packet
is received at its final destination, the
same process is repeated in reverse. The
packet is de-encapsulated and the headers
stripped off when it is received by the
intended target.
Figure 2-2. User data is
encapsulated with headers
from each layer
Most alerts generated by Snort are the
result of matching strings inside the data
payload of the packet, but many others are
generated by the headers​most commonly
the IP and TCP headers.
2.2.1 The IP Header
Primarily, the IP header specifies where
the packet is going and where it came
from. The IP header (Figure 2-3) is 20
bytes long and contains the following
IP version
Specifies either Version 4 or Version
6. Version 4 is what 99.9% of the
Internet uses; Version 6 is outside the
scope of this book.
IP header length
Specifies the total datagram header
length in 32-bit words.
Type of service
Specifies how an upper-layer
protocol would like a current
datagram to be handled. Also assigns
importance levels. For instance, you
can request be sent with minimal
delay or that the conversation use
maximum throughput. These are
fairly specialized and usually
ignored by network devices.
Total length
The length, in bytes, of the entire
packet, including the headers and the
Identifies the current datagram.
Packets can fragment on slower
network connections; this information
is used to piece the fragments back
This field is only three bits long​and
only first two are used. Bit one
indicates whether the packet can be
fragmented. Bit two indicates if the
packet is the last packet in a series of
fragmented packets.
Fragment Offset
Indicates where in the series of
fragmented packets this packet is
positioned. Some attackers will
attempt to confuse network devices
or IDS systems by setting this value
to an unlikely or impossible value.
Time to live (ttl)
Maintains a counter that gets
decremented every time the datagram
passes through a network hop (router
or firewall). When the counter
reaches zero, a "destination
unreachable" ICMP packet is
returned to the sender. This keeps the
packet from wandering the network
Indicates which upper-layer protocol
is to receive the incoming packet on
the receiving end (i.e., TCP, UDP).
Header checksum
Ensures the header's integrity. Really
a transmission check, not a security
Source address
Specifies the IP address of the
sending system.
Destination address
Specifies the IP address of the
receiving system.
Figure 2-3. The IP header:
four bytes per row
2.2.2 The TCP Header
The TCP header is used to inform the
receiving machine which upper-layer
application should receive the data and
information related to the establishment,
maintenance, and tear down of TCP
connection-oriented conversations. The
TCP header (Figure 2-4) is of variable
length and contains the following
Source port and destination port
Identifies the numbered port on
which an upper-layer application is
listening for data.
Sequence number
Usually specifies the number
assigned to the first byte of data in
the current message. In the
connection-establishment phase, this
field also can be used to identify an
initial sequence number to be used in
an upcoming transmission.
Acknowledgment number
The sequence number of the next
packet that the sender expects to
Data offset
Indicates the beginning point of the
data payload in the packet​essentially,
the size of the header in 32-bit
Not used and reserved for future use.
Contains information like the SYN,
ACK, and FIN bits used in
connection establishment and
Specifies the size of the sending
machine's receive window
Ensures the header's integrity. Again,
this is not really a security feature,
but an integrity feature.
Urgent pointer
Points to the first urgent data byte in
the packet
Used (although not commonly) to
designate preferences for flow
control, routing, and compression of
the packet. Can also be used to
indicate a government or commercial
security classification (like Top
Secret, Classified, and so on). These
fields are often used for experimental
purposes. Different operating
systems use these fields in different
ways, making this field a source of
false positive alerts.
Contains data for upper-level
applications that perform work on the
packet's actual data payload (like
IPSEC and encryption applications).
Figure 2-4. The 12 fields of a
TCP header
2.3 Packet Sniffing
One of the most important techniques
covered in this book is how to sniff or
capture network packets for closer
analysis. tcpdump extracts packets
traversing the network and either displays
them in real-time​a term open to
interpretation and highly dependent on
network bandwidth speed​or else tcpdump
logs the packets to the system for later
analysis. This process is called packet
sniffing. Understanding a packet's basic
composition can give a preliminary
indication of whether a packet is good or
bad​w hether it is benign and should be
logged or simply ignored, or flagged and
the administrator alerted.
In normal network operations, a Network
Interface Card (NIC) receives only traffic
addressed to it. The card sees all the
traffic on the wire; it just passes traffic
destined for itself on to the operating
system. In order to sniff packets on the
network, the network device must first be
able to see all packets passing through. To
support packet analysis, most network
interfaces provide a promiscuous mode.
Promiscuous mode "tells" the NIC to pass
all the packets it sees on the wire to the
network driver, even if they are not
directed to the local system. However,
before you can start looking at the packets
rushing by your NIC, you must think a bit
about your network. If your network uses
switches (or even dual-speed hubs), you
still won't see all the traffic. A switch
sends each node only the packets that are
addressed to it. Promiscuous mode doesn't
help, because your NIC never gets to see
the packets. The solution is to enable port
monitoring (called a SPAN port in the
Cisco world) on the switch, or (as a
temporary measure), replace the switch
with a hub.
Promiscuous mode on a network interface
card is not a bad thing unless it is enabled
on a machine that is normally not
permitted to sniff packets. Be wary of any
machine that has promiscuous mode
drivers enabled and is actively checking
network packets. A tool such as SniffDet
is useful for tracking down machines that
are running in promiscuous mode or
capturing and logging packets.
Promiscuous machines may indicate that a
cracker is already inside your network
and looking for sensitive data or
passwords within those packets. If you
closely manage network security, no one
should be sniffing packets without your
2.4 Installing tcpdump
The tcpdump application may already be
installed on your Linux distribution.
tcpdump requires the libpcap library,
which in all likelihood is also already
installed as an RPM package. libpcap is
the basis of all packet-sniffing
applications. This library provides a
portable framework for low-level
network monitoring. Besides packet
sniffing, it is used for network statistics
collection, security monitoring, and
network debugging. Most hardcore
security administrators prefer
downloading the latest source, verifying
the PGP signature, and compiling and
installing them manually. If tcpdump and
libpcap are not already installed, compile
both programs from source. Even if you
already have the RPM version, consider
installing the latest version using the
source code. The latest versions very
often have much better performance and
stability than the pre-installed binaries.
Simply uninstall the preinstalled versions
of libpcap and tcpdump and proceed. As
an example, if your distribution uses RPM
packages, you can remove tcpdump by
using the following command line:
# rpm -e tcpdump
After copying the compressed files to a
standard location, such as /usr/local/src/,
uncompress the code. Here is an example
# cp tcpdump-3.8.1.tar.gz /usr/loca
# cp libpcap-0.8.1.tar.gz /usr/loca
# cd /usr/local/src
# tar -zxvf tcpdump-3.8.1.tar.gz
# tar -zxvf libpcap-0.8.1.tar.gz
Replace the version number (as shown
above) with the latest release number. The
commands for installing both applications
are covered in the INSTALL files
included with each application's source
code. These are fairly standard and do not
require much modification. You may add
other configuration options to the install
process. To view these options, use the -help flag following the configure
command. In most cases, though, you
won't need any options. Here's how to
install libpcap and tcpdump from source:
# cd libpcap-0.8.1
# ./configure ; make ; make install
# cd ../tcpdump-3.8.1
# ./configure ; make ; make install
Rather than use a semicolon to
separate multiple commands on the
same line, some developers
recommend &&. With &&, a
command is executed only if prior
commands succeed. If something fails
during the configuration or make
process, the entire process halts. The
";" symbol allows the next command
to execute regardless of errors. Use
your own discretion when running
multiple compilation commands on a
single line.
2.5 tcpdump Basics
The most effective way to start learning
about network packet formation is to study
some examples. tcpdump operates by
capturing packets from a network
connection. The output is displayed in a
standard format understandable by other
network sniffing applications. Here's
some captured data, as seen by tcpdump:
07:00:48.036746 > myhost.c
07:00:48.036776 > ping.n
07:02:12.622460 > sysl
07:03:01.132414 > ma
tcpdump prints more (verbose)
information about the sniffed traffic with
the -v option, and prints its output in
hexadecimal with -x. It can also write the
"raw packets" to a file using -w rather than
sending them to standard output or to the
console. Writing the contents to a file is
extremely useful when you only have
command-line access to a sniffer but want
to dump the capture to a file for later
analysis (or analysis by another tool).
tcpdump filters assist in specifying dataonly traffic on a particular port, such as
port 22, or by using a specific protocol
such as UDP, instead of collecting all data
and filling up the logs. These filters are
applied directly within the kernel, so no
circular copying to the user space is
In some cases, tcpdump resolves the
port number to a particular service.
For example, port 21, in some
instances, is resolved to "ftp". Check
the /etc/services file for more
information regarding the port number
and the actual service.
2.6 Examining tcpdump
The more data collected by tcpdump, the
clearer the content of the network traffic
stream becomes. Here is another example
of a tcpdump capture:
win 5840 <mss 1460,sackOK,timestamp
Here's what each field in this output
Hostname and source port
Hostname and destination port
(translated to FTP)
First character of the TCP flag: PSH,
RST, SYN, FIN (the ACK flag is
shown somewhere else)
Initial sequence number from source
Ending sequence number, which is
the initial sequence number plus the
size of the packet in data bytes
Data bytes or payload size of this
TCP packet
win 5840
Size of the receiving data window
The data within the < and > characters are
the TCP options; they ensure safe and
effective delivery of the packet. While
there are some techniques where an
attacker can gather information about a
host based upon how they respond to
strange settings in these options, their real
importance is most often secondary to
what is contained in the main header and
data payload of the packet. Here are the
options for the packet we're examining:
mss 1460
Max-segment-size or mss option
(TCP option)
Selective acknowledgement
permitted (TCP option)
timestamp 238617
Round-trip delivery time used for
tracking changes in latency that may
require acknowledgment timer
adjustments (TCP option)
No operation provides padding
around other options; useful for
acknowledging receipt of packets
without forcing resends (TCP option)
wscale 0
Window scale (not to be confused
with the standard TCP header field
of window size) used for recording
the bytes of buffer space the host has
for receiving data (TCP option)
The "don't fragment" bit is set
The tcpdump output shows this packet to
be a connection request from to establish an FTP
connection to While older
versions of tcpdump might display only
the port number, port 21 resolves here to
the FTP service. This is resolved using
the /etc/services file.
A useful parameter for tcpdump is the
-n or -nn switch, which tells tcpdump
not to resolve hostnames and services.
It's commonly used on hosts that are
not able to properly resolve
hostnames, i.e., without DNS access
or /etc/hosts entries. In cases such as
these, tcpdump may delay output or
even drop packets. It's also a good
idea to get used to looking at packet
captures without DNS enabled.
Because this is the first step in
establishing a session, the SYN flag is
sent, identifiable by the S option in the
tcpdump output (this will be covered more
closely when we discuss the TCP threeway handshake). The initial beginning and
ending sequence numbers are the same,
since no data is being sent. In most cases,
no data is sent until the three-way
handshake is completed. There are
exceptions to this rule; RFC 793 points
out that data can be sent prior to
completion of the handshake and that not
all handshakes receive completion. In any
case, a packet that doesn't conform to the
protocol's established standards should be
considered suspicious.
2.7 Running tcpdump
Knowing the basics behind the captured
tcpdump data, we can start looking at how
to use tcpdump within the network.
tcpdump can be used to test lines and
network connections or sniff packets.
There may be instances when problems
arise within the network and you cannot
physically lay hands on any machines for
testing. It is times such as these that
tcpdump comes in handy. If you can secure
shell or SSH into a machine on the
network and configure your network card
to run in promiscuous mode, you can sniff
the packets flowing by and later analyze
them for issues.
It's interesting to note that tcpdump
captures packets before the kernel
receives them and after they leave it. Even
more importantly, the packets are captured
before they are processed by Netfilter.
tcpdump allows you to see if the packets
are arriving; it can also check the local
machine for faulty configurations in the
event of network problems.
If you are not sniffing from a remote
host through an SSH session, instead
of the client itself, be careful! You can
end up sniffing your own terminal
session traffic. tcpdump generates line
after line of output that gets sent to
your client through the terminal
session, which generates more traffic,
which gets sniffed, which... well, you
get the idea. You can exclude the
traffic generated by your terminal
session with careful filtering
(discussed later in the chapter).
Because tcpdump is command-line based,
it is easy to run on any machine. You need
not worry about a GUI interface as you
would with ethereal. Rather than viewing
the packets in real-time via the console, it
is often more useful to capture them to a
logfile and then use secure FTP (SFTP) or
Secure Copy (SCP) to transfer the logs to
another location. Use ethereal to better
analyze the content.
2.7.1 Syntax Options
There are a few ways to run tcpdump from
the command line. Rather than viewing
every packet as it scrolls across the
screen, write the data to a temporary file.
If your network is as busy as mine, it will
be impossible to view everything. Even if
you could, you may drop packets, since a
standard display cannot keep up with
normal network speed. The console uses a
serial terminal connection emulation,
which has a speed far less then 100
This example shows tcpdump writing data
to a temp file:
# tcpdump -w /tmp/tcpdump.out
After capturing the data in raw binary
format, use tcpdump to read or print the
data in human-readable form. tcpdump is a
better interpreter than WinDump, the
Windows equivalent. WinDump
sometimes experiences errors when
reinterpreting raw data. There have been
some reports that the latest alpha release
of winpcap broke the ability to capture
dial-up and PPP traffic. In other words,
all ndiswan traffic from modem devices is
inaccessible. Use an older, more stable
version of WinDump and the winpcap
library if you need to view this type of
traffic on a Windows system.
# tcpdump -r /tmp/tcpdump.out
tcpdump can also collect data through a
filter. Not all packets must be viewed;
only those of interest are presented for
further study. tcpdump filters are
explained in more detail in the next
# tcpdump -F /home/myname/tcp.filte
To disable name/port resolution, use the
following option:
# tcpdump -nn
While the -n option is enough to
prohibit the conversion of host
addresses to names, the -nn option
disables the conversion of protocol
and port numbers to names as well.
You can further modify the data gathered
and view only MAC addresses of the
source and destination network interface
cards. The following option disables
name resolution and shows only MAC
# tcpdump -e
Inorder to specify a specific number of
packets to capture (useful on very busy
networks or as protection against sniffing
your own terminal traffic) you can use this
(here we're specifying 100 packets):
# tcpdump -c 100
To specify how much of the packet to
capture, use the -s (snaplength) option. I
have been burned by not capturing enough
of the packet to capture what I'm looking
for. Here we are going to capture the first
1,500 bytes of the packet:
# tcpdump -s 1500
For more tcpdump options, consult the
tcpdump manpage. Some options include
sniffing data through a specific interface
and stipulating the number of bytes for
collection. You can also assign tcpdump
to listen only for a specific host or traffic
on a particular network or subnet. Using
tcpdump in real-life situations is the best
way to become familiar with your network
2.7.2 tcpdump Filters
tcpdump's power lies in its ability to filter
out any unimportant data. Filters are
usually additional options affixed to the
end of the tcpdump command that specify
which packets should be captured or
examined. The examples below outline
ways to filter for specific hosts, networks,
or protocols. tcpdump can perform much
more complex filtering. Knowing the
TCP/IP header layout (down to the
specific bits!) and what fields define
which protocol, flags, options, and so
forth is crucial to being able to create
these more complex tcpdump filters.
Filtering this complex is more easily
performed using one of the GUI sniffers,
like ethereal. If you're capturing traffic on
a remote system, it's a good idea to dump
the traffic to a file (using the -w option)
with tcpdump and analyze the file using
ethereal on another machine.
The following examples filter packets by
running tcpdump against saved binary data
(a common technique). For example, if I
use SSH to securely connect to another
machine but want to capture all traffic
without seeing the local SSH packets
generated by my connection, I filter all
SSH packets using this command:
# tcpdump -r /tmp/tcpdump.out not p
In order to view only traffic from a certain
IP address and no port 22 or SSH traffic, I
would use:
# tcpdump -r /tmp/tcpdump.out host
Also, say I want to restrict tcpdump to a
single port and host:
# tcpdump -r /tmp/tcpdump.out -n ho
To watch traffic between two specific
hosts, I would use:
# tcpdump -r /tmp/tcpdump.out host
2.7.3 tcpdump Capture of the
TCP Three-Way Handshake
Test your skills by looking at the tcpdump
output below (my laptop checking for the latest news):
win 64512 <mss 1260,nop,nop,sackOK>
22:21:50.488810 >
ack 1626477749 win 5840 <mss 1460,n
2.8 ethereal
As I mentioned early in this chapter, there
are alternatives to tcpdump that provide
GUI interfaces. However, it is important
that you familiarize yourself first with the
structure of packets as they are captured
and then with command-line interface
tools before making the leap to a GUI
application that may overwhelm you with
too much information. Starting off with
something such as ethereal before learning
the basics is like purchasing a top-end
calculator with all the whistles and bells
without knowing how to do simple
addition, subtraction, and multiplication
commands. You can still perform basic
calculations, but you'll end up using only a
small fraction of the calculator's total
power or resources.
2.8.1 Installing from Source
The ethereal network analyzer is a
standard feature of most Linux
distributions, including Red Hat Linux.
Just like tcpdump, ethereal captures its
data in libpcap format. It can also read
captured data from a variety of other
network sniffing appliances that may use
different logging formats. Check the
ethereal manpage for a complete listing of
the applications with which it is
compatible. Chances are if your
application of tool is not listed, the
ethereal developers can easily create a
port of it or you may just find ethereal to
be all that you need.
For those who prefer compiling the latest
ethereal from source rather than simply
installing the RPMs, the main ethereal
page provides links and ports to nearly
every available operating system and
flavor of Unix on the market, including a
Windows version. Most RPMs for
ethereal are a couple versions behind the
latest source release. Staying ahead of the
game and up-to-date on the most current
version is incentive enough for anyone to
use the source rather than the binary.
Although there are several different
options available for customizing ethereal,
the standard commands apply. Use the
following commands to build and install a
default version of the application on your
system after uncompressing the source
code in a standard location:
# ./configure && make && make insta
ethereal is a fairly beefy application,
weighing in at over three and a half
megabytes. It can take some time to
compile on older systems. It is worth the
2.8.2 Available Options
ethereal is a GUI tool that offers a wealth
of information. This section provides a
quick overview of many of its features.
However, for a more detailed explanation
of all its features, consult the User's
Guide on ethereal's home page.
Start ethereal from the root shell prompt.
The ampersand tells Linux to run the
process in the background. Since this is a
graphical program, we do not need to
capitalize our command prompt until
we're done with ethereal:
# ethereal &
To begin immediately capturing data, go
to the Capture drop-down menu and select
Start. This brings up the main Capture
Options menu. Here you select from a
variety of features, including the interface
you wish to sniff, whether you want to
capture packets in promiscuous mode, any
filters you wish to apply, and whether you
want an update of captured packets in
real-time. You can also choose to scroll
the packets on-screen as they are captured
and enable MAC address and network
name resolution. Many of these features
are similar to the ones available under
tcpdump. Figure 2-5 is an example of the
Capture Options screen with a few
options enabled.
Figure 2-5. Enable similar
Figure 2-5. Enable similar
options under ethereal as you
would with tcpdump
Once you start the packet capture, unless
you have specified otherwise, it will
continue to log information until you press
the Stop button on the Capture window.
Figure 2-6 is an example of a real-time
packet capture session.
Figure 2-6. Packet capture in
real time using ethereal
When you are done capturing packets, you
can save the data to a file in a variety of
formats, including the libpcap native
If the data collected does not have the
information you were looking for, modify
the ethereal values or preferences in the
Edit drop-down menu. You can change
how the output appears within the ethereal
window by unselecting all options and
enabling only those of interest. The
Display drop-down window also
provides different options for customizing
the application, such as colorizing the
display so that certain items or protocols
are highlighted. You may also choose to
collapse or expand features within the
middle pane window. The Tools drop-
down menu provides options for enabling
additional plug-ins, along with a Summary
and Statistics of all captured data packets.
It is possible to use filters in conjunction
with ethereal, just as you would with
tcpdump. ethereal uses the same syntax
and the filters can be customized under the
Edit drop-down menu. One of the most
versatile features of ethereal is its ability
to follow a particular TCP stream. If a
particular network discussion appears
interesting, simply highlight the connection
in question and select Follow TCP Stream
with the right mouse button. Notice the
Filter: field at the bottom of the ethereal
window; when you tell ethereal to follow
a stream, it generates an appropriate filter
with the correct syntax. This filter can be
easily reset or modified and the changes
applied in order to resume capturing other
traffic. Along with a particular stream,
you can add color filters to make packets
of interest stand out against other network
It does not take long to become adept at
capturing only those packets you wish to
see. Like with tcpdump, you can closely
analyze all datagram content in the lower
pane window as hexadecimal output. It is
never wise to implicitly trust ethereal's
output. Viewing the hexadecimal is crucial
for corroborating evidence within the
captured packets.
2.8.3 ethereal Capture of
TCP Three-Way Handshake
Figures Figure 2-7 through Figure 2-9
show the details of the three-way
handshake between my laptop and
Figure 2-7. SYN
Figure 2-8. SYN-ACK
Figure 2-9. ACK
2.8.4 Tethereal
No section on ethereal would be complete
without mentioning the command-line or
terminal-based packet capture option,
Tethereal. Tethereal comes with ethereal
and includes many of the same features.
The manpages for the two programs are
nearly identical. Tethereal captures and
reads data the same way as ethereal, but
can be run remotely on any machine,
including machines without an X Window
interface. Like ethereal, Tethereal must be
run as root in order to have access to all
command-line functions.
Here is the output from a Tethereal packet
capture session:
# tethereal
Capturing on eth0
0.000000 00:d0:bc:ed:15:e4 -> 09:00
0.407305 ->
0.820469 00000000.00c0b607af66 -> 0
0.999948 00:d0:bc:ed:15:e4 -> 09:00
1.159977 00:30:65:8c:84:50 -> 09:00
1.218995 aa:00:04:00:59:9e -> 09:00
1.528072 00008001.080009a95de6 -> 0
1.999953 00:d0:bc:ed:15:e4 -> 09:00
2.723358 00:00:f8:52:5b:79 -> ab:00
2.743625 00008001.00d0bced15e4 -> 0
2.915255 ->
3.000008 00:d0:bc:ed:15:e4 -> 09:00
3.121764 aa:00:04:00:bd:9e -> ab:00
3.123641 aa:00:04:00:bd:9e -> 09:00
3.125544 aa:00:04:00:bd:9e -> ab:00
3.205372 ->
3.235634 aa:00:04:00:59:9e -> 09:00
3.999932 00:d0:bc:ed:15:e4 -> 09:00
Tethereal can be used as a replacement
for tcpdump in remote situations when you
are using a console or using secure shell
(SSH) to connect to another machine. Use
the -V flag with Tethereal to render nearly
as much verbose information as the GUI
interface. Those familiar with ethereal
will find that Tethereal provides many of
the same functions. I prefer to use tcpdump
if all I have is a command line, but your
mileage may vary.
2.9 Sites of Interest
The following lists the URL of each
pertinent item mentioned in this chapter.
Each site also has links to additional
informative sites. I highly recommend
browsing some of the locations for further
tutorials, related applications, or
noteworthy information.
Chapter 3. Installing
This chapter examines common techniques
for capturing packets and analyzing their
contents. In this chapter, we will get Snort
installed and start experimenting with
some of the ways to use it. We start with
using Snort as a sniffer, a packet logger,
and finally start using it as an actual
3.1 About Snort
Snort is perhaps the best known open
source intrusion detection system
available. Snort is designed primarily to
operate from the command line, and it has
been integrated into several other
applications and ported to various
platforms. Many third-party applications
have been engineered around its use. Snort
is actively maintained, and it is possibly
the best open source IDS available for
Snort was first developed in November
1998. It was originally intended to
function as a packet sniffer. Since then it
has grown to become much more. Each
week Snort is downloaded by thousands
of users and developers. It is currently
used in most IDS situations, from small
office and home networks to corporate
and IT offices worldwide. It has been
ported to a variety of platforms, so finding
a release for your particular operating
system should be no problem. I currently
run Snort on Windows, FreeBSD, Linux,
and Solaris.
3.1.1 Snort's Commercial
No discussion of Snort would be complete
without mentioning its commercial
counterpart. The Snort developers created
their own company, Sourcefire, which
supplies an intrusion detection appliance
for enterprise-level networks. The
Sourcefire appliance combines an
enhanced version of Snort with other
proprietary technologies to create what
they call an Intrusion Management
System (IMS). The capabilities of Snort
and other applications are combined into a
seamless whole that offers state-of-the-art
monitoring, perimeter defense, system
management, and real-time awareness.
For the cost, Sourcefire offers perhaps the
most up-to-date and reliable IDS devices
for those interested in investing in a
commercial variant. By any measure, it
competes strongly with solutions from the
big players​Cisco, ISS, NFR, and Top
Layer, to name a few.
3.2 Installing Snort
Not much needs to be said about installing
Snort. It downloads and installs on nearly
all platforms. The commands for
configuring Snort are much the same as for
other source code or RPM builds. The
source is freely available for download in
the event users wish to stay current with
the latest releases. I strongly recommend
downloading and compiling the Snort
source code rather than installing a binary
release; you are assured pristine code that
has not been modified by any third party.
You may also configure Snort with
additional options, such as MySQL
support. The most recent Snort release
appears as source code before it comes
out in RPM format. For the most up-todate code, use the source.
The latest version of Snort as of this
writing is snort-2.1.x. The developers
attempt to keep abreast of the latest
developments, patch submissions, and
vulnerabilities, while also incorporating
new features into their releases. Unlike the
Linux kernel numbering scheme, the Snort
minor number is not indicative of a stable
or developmental release. Stables
releases use odd as well as even release
3.2.1 Source Code
Building Snort is fairly easy. There are a
lot of options that you can request; the
most important configure Snort to use
various databases for storage. However,
at this point, I'll show you how to do a
quick and dirty build for some simple
experimentation. In Chapter 6, when I talk
about deploying a full-blown network
IDS, I'll get into issues like database
Once you've downloaded and
uncompressed the source distribution from, building it is easy. I
create a directory in /usr/local/src called
snort. I move the downloaded gzipped
tarball to that directory and perform the
following commands:
tar xvft snort-2.1.x.tar.gz
cd snort-2.1.x
make install
The last command must be run as root. It
installs the Snort binary in /usr/local/bin.
Any user can run it, although you need to
be root to place network interfaces in
promiscuous mode.
If that works, fine. If it doesn't work, the
configure command will tell you what's
missing. The problem is almost certainly
that one of two libraries is missing:
libpcap (discussed in the previous
chapter; it's available from or PCRE.
PCRE stands for "Perl-Compatible
Regular Expressions," and it's available
from Download the
library (or libraries) you need,
uncompress the file, and build it using
./configure, make, and make install. Build-time options
If you want to see all the build-time
options, use the command ./configure -help. One option worth noting is flexible
response or session sniping. This option
gives Snort the ability to terminate
connections that appear malicious.
Session sniping is enabled by adding -enable-flexresp to the configure
command. In Chapter 8, as we cover
advanced uses for Snort, we'll see that
nondefault configuration details such as -enable-flexresp can be used with the
react option, which blocks access to
certain URLs or warns users. This is a
feature added in Snort release 2.0.
You may also want to enable support for
one of several databases, allowing your
Snort sensor to log alerts to a database.
This will allow other programs to use the
data (like the console application ACID,
discussed in Chapter 10). For example,
you can use --with-mysql to enable
Snort to log to a MySQL database.
Additional libraries may be required as
you enable more options. For example,
libnet is needed when compiling Snort
with the flexresp option. libnet is
available from If
you plan on using the flexible response
features, download the source and install
the libnet packet assembly library prior to
compiling Snort. libnet is a high-level API
toolkit that allows the application
programmer to construct and inject
network packets. Discussion of libnet
could take up an entire chapter​it provides
a portable and simplified interface for
low-level network packet shaping,
handling and injection. It also features
portable packet creation interfaces at the
IP layer and link layer. libnet can help you
whip up quick and simple packet
assembly applications.
3.2.2 Windows Installations
If you want to run Snort on Windows,
download and install the WinPcap library
for Windows from Once WinPcap is
installed, grab the binary version of Snort
(snort.exe). The Win32 version is
available at
Snort is run under Windows from a
command prompt.
Another version of Snort configured for
Windows users is available at This is an offshoot of
the regular Snort code and is supported
exclusively by Michael E. Steele. It, too,
is free, although the author does require
users to register in order to download the
files. This version of Snort for Windows
operates well with the Microsoft SQL
server and has a wizard-driven
installation that makes things easier. There
are also several documents that explain
how to configure this Snort release under
a variety of platforms and using several
different databases, all on a Windows
There has been a great deal of discussion
about which operating system provides the
best performance. There was quite a stir a
short while ago when someone on the
Snort user's mailing list revealed some
benchmarks that showed that the Windows
version was actually faster than the Linux
or BSD. There were some flaws in the
benchmark, so the results were tainted.
The general wisdom is that FreeBSD has
blazing fast networking components,
newer versions of the Linux kernel
provide very efficient use of threads and
memory management, and Windows
makes up ground with how it uses the
filesystem. Choose the operating system
you are most familiar with. The
performance levels of any of the modern
operating systems should be adequate
from most applications. When you are
trying to use an NIDS in a very highdemand environment, visit Chapter 13.
3.2.3 Staying Current
While support for the Windows-based
version of Snort is rather limited, you can
always download the cutting-edge (if not
bleeding-edge) version of Snort on your
Linux machine. To stay current with the
most recent build, download the Snort
source code from This
can give you the access to the very latest
features and bug fixes. The only problem
is there may be some stability or
performance issues​not uncommon when
riding the bleeding edge.
Though the instructions presented here are
fairly complete, the Snort web page
remains the most comprehensive site and
source of information. There are various
README documents and man pages,
instructions for writing Snort Rules, and a
Snort mailing list. Sign up for the mailing
list at
users/. Also, consult the Snort newsgroup
at dfi.lists.snort-users, a Usenet posting
of this same mailing list, or use the
archives posted within the newsgroups
hosted by Google, The newsgroup
name is mailing.unix.snort. The direct
link to the Snort mailing list on the Google
newsgroup site is
Exercise proper list etiquette before
posting to the mailing list. Remember
to check the mailing list archives,
"lurk" or monitor other posts (chances
are someone has posted or will post a
similar query), and, of course, read the
manpages, FAQ, or documentation
pages, also known as RTFM, before
posting questions already answered
3.3 Command-Line Options
Before we go into Snort's basic
operational modes, let's first look at a
breakdown of the command-line options.
This chapter covers each item listed here,
but some are not frequently used or may
only be used in conjunction with other
variables. Some of the options can be
specified in the config file instead of at
the command line. If you are just trying
something out, specify the setting at the
command line. If you are planning on
keeping the setting for a while, set it in the
config file.
-A alert-mode
Generates an alert using one of the
specified alert-modes: fast, full,
none, and unsock. Rather than
specifying the alert mode within a
configuration file, you can include it
here at the command line.
Logs packets in tcpdump format (i.e.,
libpcap). Files in tcpdump format are
smaller, so this is the best method of
recording large amounts of logged
data and packets. It is very fast and
may be a good option on high-traffic
-B address-conversion-mask
Scrambles the networks specified in
the -h (or HOME_NET) setting. This
helps hide the real internal network
addresses inside binary logs.
-c config-file
Allows you to specify which
configuration file you want to use. If
you have different configurations
with various rules enabled, you can
specify which configuration to use at
the command line. This option is
required when Snort is run in NIDS
Prints the character data found in the
packet payload, rather than
displaying it in hexadecimal format.
Reading this information is easier
than wrestling with Hex output.
Displays the application layer data
Displays the application layer data
when in verbose or packet logging
Runs Snort in daemon mode. Alerts
are dumped to the alert file in the
logging directory (/var/log/snort by
default). Daemon mode is useful if
you wish to automate the startup of
Snort in the event of a reboot.
Passing this option to Snort in a
command script starts Snort in the
background. No error messages are
printed to the console in this mode.
Do not use this mode unless you are
already familiar with Snort and have
a working, viable configuration. (Use
the -T option, discussed below, to
test your configuration before using
daemon mode.)
Displays or logs the link layer packet
headers. This is the more verbose
method of viewing captured packets
when running Snort in sniffing mode.
-F bpf-file
Reads Berkeley Packet Filters
Reads Berkeley Packet Filters
(BPF) from a bpf file. These filters
are useful when running Snort as a
SHADOW replacement or when
performing an analysis via a
command-line filter. This filter is
commonly used to tune out noise or
random alerts. (It is not commonly
used.) You could use a BPF filter to
tell one system to watch only web
traffic and another to watch
everything else.
-g group
Changes the default group ID or GID
under which Snort runs after
initialization. This is helpful if you
want to run Snort in a special group
for security reasons.
-h home-net
Sets the "home network" to a specific
address in CIDR format. With this
variable set, all decoded packet
logging is done relative to the home
network address space. This option
is equivalent to setting the
HOME_NET variable in the
configuration file.
-i interface
Specifies which interface Snort
should listen on. This option is used
on machines that have more than one
network interface card or that have
different kinds of interfaces, besides
Ethernet. Naming conventions for
interfaces vary between operating
In alerts, displays the interface on
which each packet arrived. Useful
when monitoring multiple interfaces;
you can see which interface received
the suspicious packet. Also very
useful when multiple Snort sensors
are sending their alerts to a central
database (discussed further in
Chapter 5).
-k checksum-mode
Controls which packet checksums
Snort computes and verifies. Valid
checksum modes include all, noip,
notcp, noudp, noicmp, and none.
This can be used to eliminate packets
that fail their checksums - caused
either by network faults or IDS
evasion attempts
-l logging-directory
Specifies the logging directory. All
alerts and packet logs are placed in
this directory. The default logging
directory is /var/log/snort, but that
default is only used when Snort is in
alert (-A) mode. If you want to use
Snort as a simple packet logger, you
must use the -l option and specify
the logging directory explicitly. Often
used when debugging Snort and when
logging packets to a temporary
directory so that the new logs do not
mingle with production logs.
-L binary-log-file
Sets the filename of the binary
logfile. If this switch is not used, the
default name is a timestamp for when
the file was created, plus snort.log.
-m umask
Sets the file mode creation mask to
the designated umask variable. This
is a simple security measure to
prevent others from viewing the
logfiles generated during packet
-n packet-count
Processes the given number of
packets and then exits. Useful when
you want to capture a small snapshot
network traffic.
Turns off packet logging. Alerts are
still generated but are printed to the
console only. No records are kept on
the system of the generated alerts.
This can be useful when testing your
Changes the order in which the rules
are applied to packets. Instead of the
rules being applied in the standard
Log order, this
option applies them in Pass
Log order. Recommended for
users running SnortCenter and other
web interfaces. This is how the
developers of these applications
decided to display captured Snort
packets. This option is also used to
ensure that pass rules are applied
before detection rules. See Chapter 9
for the caveats with using this option
(and pass rules).
When in ASCII packet dump mode,
replaces the IP addresses printed to
the screen or logfile with
"". If the home-net
address switch is set, -h, only
addresses on home-net are
obfuscated, while non-home net IPs
are left visible. Use this option when
capturing sample alerts or packets
that need to be posted or shared with
other non-trusted users. It is perfect
for posting a packet capture to a
discussion group or a mailing list.
Turns off promiscuous mode sniffing.
When first working with Snort, the
usefulness of this option evaded me.
The answer came to me in the
shower​it can be used to protect only
one host. When not in promiscuous
mode, an adapter will only accept
packets addressed to itself.
-P snap-length
Sets the maximum packet capture
length to a certain size. Some packets
may be very large. While most rules
look for characteristics or signatures
in the beginning of a packet, setting
the maximum packet length may
cause you to miss large malicious
packets, when the offending string is
located at the end.
Tells Snort to run quietly. Does not
display banner and initialization
information. If you aren't interested in
the initialization messages, you can
suppress them with this.
-r tcpdump-file
Use this option to process a
tcpdump-formatted file. The output
appears much like it would when
capturing data in real-time. This
option is used to analyze a packet
trace that was collected at an earlier
Sends alert messages to a syslog
server. This can be either a local or
remote server. Use this option when
capturing logs and alerts within
-S variable=value
Sets the variable name variable to
the value value. There are a number
of variables that Snort uses to define
what systems are on your local
network (HOME_NET), which are
web servers or DNS servers, and
which systems are external to your
network. It is advised to keep all
variables in the snort.conf file to
limit confusion.
-t chroot
Changes Snort's root directory to
chroot after initialization. Paths for
logfiles and alert files are relative to
the new root directory.
Starts Snort in self-test mode. Useful
for debugging Snort before it is run in
daemon mode or before it is
launched on a production box. Can
be used for testing the correctness of
your configuration files.
-u user
Changes the default user ID or UID
under which Snort runs after
initialization.Like the -g option, an
added security feature for running
Snort as a nondescript user.
Forces the timestamp in all logs to be
in UTC (a.k.a. GMT) format. A
recommended option when capturing
logs from multiple sources on a
single syslog server and if sensors
are scattered across a large WAN;
you won't have to deal with time
zone differences.
The verbose option prints all packets
to the console. Be careful when using
this option, as it may slow Snort and
result in dropped packets.
Displays the Snort version number
and then exits. Use this to determine
which version of Snort is installed on
your system.
Displays raw packet data starting at
the link layer. With this option you
can see the entire packet, including
Ethernet headers and trailers.
Includes the year in all alerts and
logfiles. Useful when you want to
create an archive of logged Snort
packets that can be referred to later.
Enables the stream4 preprocessor.
Preprocessors manage incoming
packets before passing them off to
Snort. They are sometimes used to
reconstruct fragmented packets. This
option takes advantage of stream4's
stateful packet inspection
capabilities. It tells Snort to generate
alerts only when a packet is part of
an established session, foiling some
IDS evasion mechanisms.
Lists all switches and options and
then exits.
This chapter provides examples of nearly
all these options. With the working
examples or the options shown here, you
should be able to configure your own
Snort process. Experiment with the
options to see how they act on your
Further discussion of these command-line
options can be found within the Snort
manpages or within the documentation
contained on the main Snort page.
Although much is covered here,
documentation does change over time (and
new features and options are added from
version to version). Consult the most
recent release.
3.4 Modes of Operation
At this point, you may be asking yourself,
Why do I need to know Snort? It sounds
much like tcpdump, in that it sniffs packets
and can read and write into the same
libpcap format. Here are just a few of the
reasons Snort is a versatile solution for
both packet sniffing and intrusion
detection. Snort:
Is descriptive and verbose.
Is more versatile than tcpdump in
output and readability.
Determines each entry's value.
Identifies individual fields and
computes corresponding fields.
Can be customized to print out all
varying fields in the headers.
Has rules that are relatively easy to
configure and understand.
Can report on separate wireless
networks using specialized patches.
Generates alerts (it's a network
intrusion detection system).
As you begin to use Snort, you will notice
the many advantages it offers over
tcpdump for raw data interpretation.
Next, we'll cover how to run Snort in its
three basic operational modes.
Sniffer (snort -v)
Packet logger (snort -l)
Network Intrusion Detection System
(snort -A or snort -c
3.4.1 Snort as a Sniffer
While the previously discussed network
sniffer tools (tcpdump, ethereal, and
Tethereal) are more full-featured and
provide excellent packet analysis, there
may come a time when you quickly look at
the network traffic on a Snort sensor. In
this case, using Snort as a sniffer might be
valuable. The Snort sniffer-mode output is
slightly different than the other commandline sniffers. It is actually very easy to
read and you may find you prefer it for
quick captures. One very nice feature of
sniffer-mode Snort is the network traffic
summary at the end of the capture.
Sometimes this can be a very useful
troubleshooting tool for network
Enable sniffer mode for Snort using the -v
# snort -v
Running in packet dump mode
Log directory = /var/log/snort
Initializing Network Interface eth0
--== Initializing Snort ==Initializing Output Plugins!
Decoding Ethernet on interface eth0
--== Initialization Complet
-*> Snort! <*Version 2.1.x (Build 72)
By Martin Roesch ([email protected]
TCP TTL:128 TOS:0x0 ID:21742 IpLen:
******S* Seq: 0x5DB36D37
Ack: 0x0
TCP Options (4) => MSS: 1460 NOP NO
EIGRP TTL:2 TOS:0x0 ID:0 IpLen:20 D
EIGRP TTL:2 TOS:0xC0 ID:0 IpLen:20
EIGRP TTL:2 TOS:0xC0 ID:0 IpLen:20
Snort analyzed 38 out of 38 packets
Breakdown by protocol:
TCP: 1
UDP: 0
ARP: 0
IPv6: 0
IPX: 0
Wireless Stats:
Breakdown by type:
Management Packets: 0
Control Packets:
Data Packets:
Fragmentation Stats:
Fragmented IP Packets: 0
Fragment Trackers: 0
Rebuilt IP Packets: 0
Frag elements used: 0
Discarded(incomplete): 0
Discarded(timeout): 0
Frag2 memory faults: 0
TCP Stream Reassembly Stats:
TCP Packets Used: 0
Stream Trackers: 0
Stream flushes: 0
Segments used: 0
Stream4 Memory Faults: 0
Snort exiting
Upon startup, Snort displays the mode, the
logging directory, and the interface on
which it is currently listening. When
initialization completes, Snort begins
dumping packets to the screen. This output
is fairly basic: it displays only the IP and
TCP/UDP/ICMP headers and little else.
To break out of sniffer mode, use Ctrl-C.
Snort exits by generating a summary of
packets captured, including the protocols,
packet fragmentation statistics, and stream
reassembly stats. To view application
data, use the -d flag. This option provides
even more detailed output:
# snort -vd
06/24-11:27:35.408290 ARP who-has 6
UDP TTL:64 TOS:0x0 ID:0 IpLen:20 Dg
Len: 29
E8 0A 01 00 00 01 00 00 00 00 00 00
03 6B 73 6C 03 63 6F 6D 00 00 01 00
06/24-11:27:35.408838 ARP reply 64.
UDP TTL:63 TOS:0x0 ID:0 IpLen:20 Dg
Len: 93
E8 0A 85 80 00 01 00 01 00 02 00 01
03 6B 73 6C 03 63 6F 6D 00 00 01 00
01 00 01 00 00 70 80 00 04 40 93 82
02 00 01 00 00 70 80 00 02 C0 0C C0
01 00 00 70 80 00 06 03 6E 73 32 C0
01 00 01 00 00 70 80 00 04 40 93 82
The application data is clearly visible and
you can see the plain text within packets.
In this instance, the text sent from a DNS
server shows up in plain text.
To view more details and see results
similar to tcpdump​including data link
layer headers, as opposed to just the
application layer data​use the -e flag as
well. Using both the -d and -e options
displays almost all the data within the
# snort -vde
06/24-11:34:00.840645 0:8:74:F3:CC: -> 64.147.130.
Len: 29
28 BF 01 00 00 01 00 00 00 00 00 00
03 6B 73 6C 03 63 6F 6D 00 00 01 00
06/24-11:34:00.841157 0:D0:BC:ED:15 ->
Len: 93
28 BF 85 80 00 01 00 01 00 02 00 01
03 6B 73 6C 03 63 6F 6D 00 00 01 00
01 00 01 00 00 70 80 00 04 40 93 82
02 00 01 00 00 70 80 00 02 C0 0C C0
01 00 00 70 80 00 06 03 6E 73 32 C0
01 00 01 00 00 70 80 00 04 40 93 82
The hexadecimal dump displays more
data. MAC addresses are visible, in
addition to the IP addresses. When
performing tests on a network or simply
capturing data using Snort, the -vde
switches provide the most information.
Most networks generate traffic at such a
rate that it causes the Snort sniffer output
to scroll by too fast. In order to direct the
sniff trace to a logfile instead of the
console, use snort -dve > temp.log.
You can also use Snort in packet-logger
mode, discussed in the next section.
In summary, here are the available runtime
switches to use with Snort in sniffer
Dump packet headers to standard
output. "Verbose" mode​although
ironically, less verbose than -vd or ve.
Dump packet payloads.
Dump packet payloads.
Display ARP packets.
Display link layer data.
These switches can be run individually or
in combination with each other, whatever
works best for your purposes.
3.4.2 Snort as a Packet
The next step past sniffing packets is
logging them. Logging is as simple as
adding the -l option, followed by the
directory in which you wish to store the
logs. Snort's default logging directory is
/var/log/snort. If you specify a directory
that does not exist, Snort exits with an
error message. You can use the -d, -a,
and -e options (discussed in the previous
section) to control the amount of
information logged for each packet. In this
example, the logging directory is set to
/usr/local/log/snort, rather than the
default /var/log/snort, and the logfiles
include the packet payloads:
# snort -l /usr/local/log/snort -d
When run in this mode, Snort collects
every packet it sees and places it in the
logging directory in hierarchical mode. In
other words, a new directory is created
for each address captured and the data
pertaining to that address is stored in that
directory. Snort places the packets into
ASCII files, with filenames generated
from the protocol and port number. This
organization makes it easy to see who has
been connecting to your network and what
ports and protocols they are using: simply
use ls -R (or dir /s in Windows) to list
the log directory. Be sure to specify your
home network variable (either in your
configuration file or using the -h switch)
to specify logging for just your home
network. This hierarchical organization is
most useful if a limited number of hosts
are involved or if you wish to view the IP
addresses of captured hosts at a glance.
However, the logging directory can
become very congested over time due to
the ever-increasing number of directories
and files. If you're logging all the traffic
on a very active network, it is even
possible to run out of inodes (a Unix
datastructure that limits the total number of
files in a filesystem) long before you're
run out of storage. If someone were to do
a full scan of your network and map all
65,536 TCP ports as well as all 65,536
UDP ports, you would suddenly have
131,000 or more files, all possibly in a
single directory. This file explosion can
severely tax the limits of most any
machine, and could easily turn into a fullblown denial-of-service attack. If you're
not careful, you can cause yourself real
Binary logging dumps everything to a
single file that is readable by Snort,
tcpdump, or ethereal. This greatly
increases the speed and portability of the
packet capture. Most systems can capture
and log at network speeds of 100 Mbps
without trouble.
To log packets in binary, use the -b
switch. Here is one example:
# snort -b -l /usr/local/log/snort/
Once you have your capture, you can read
back the file you just created using the -r
switch. The output is similar to Snort's
sniffer output Note that -r can't be used
with -C. It would make it easier to follow
simple conversations, though.
# snort -r /usr/local/log/snort/tem
While in this mode, Snort is not limited to
reading the stored binary data in sniffer
mode. You can run Snort in NIDS mode
with a set of rules or filters that search for
suspicious traffic. This can be useful for
forensic analysis of suspicious traffic. By
storing the data and then having a script
examine it later, you have the luxury of
very careful analysis of the packet stream.
You also have the luxury of using tools
other than Snort to help with your
3.4.3 Snort as an NIDS:
Quick and Dirty
While Snort is a passable network sniffer,
it is an excellent tool to detect intruders.
When used as an NIDS, Snort provides
near real-time intrusion detection
Although some companies claim it,
there is no such thing as a "real-time
alert." When a packet is received and
its content deciphered and judged to
be malicious, the IDS must send out a
notification to the administrator. In the
time it takes for the administrator to
receive the notification, log in to the
system, and confirm the packet's
signature, several minutes to an hour
may have passed. The attacker's goal
may be accomplished in that time.
Some of the signatures are triggered
by a host's response to a successful
attack​certainly too late to stop the
Also, if network devices are brought
down or if the monitoring software is
attacked, it could be several hours or
days before the administrator
physically arrives at the location or
discovers there was an attack. Most
successful infiltrations take less time
to accomplish than it takes for the IDS
system to notify an administrator that
an attack has occurred. Security
administrators must define for
themselves what constitutes "real
We will spend a lot of time looking at the
various ways that Snort can be used as an
NIDS and all of the configuration options
available. For now, let's just get it running
and logging to the console so you can see
Snort in action. Get the latest rule sets
To get going, we need the latest set of
rules. I usually keep my rules in a single
location so that I can track changes and
keep track of my configuration files. I
create a directory in /usr/local/share/
called snort_rules (this is not a
requirement, it just allows me to keep
everything in one spot, and the guy who
taught me FreeBSD did it this way). Inside
this directory, I create a directory with the
month and year (for example,
march_2004). Since the Snort rules are
updated fairly often (and you want to be
able to spot the latest attacks), you should
update your rules regularly. As long as
you are running the same version of Snort,
you can likely just copy your snort.conf
file from one rules directory to another
(run Snort using the -T option after
upgrading, just to be sure).
If you are running Snort Version 2.1.x, you
can download the latest rules from:
If you are running Snort CURRENT
(riding the bleeding edge), you can
download the latest rules from:
Copy the gzipped tarball to the rules
directory you created and expand it and
move into the uncompressed rules
directory using the following commands:
$ tar zxvf snortrules-snapshot-2_1.
$ cd rules
$ tar zxvf snortrules-snapshot-CURR
$ cd rules
You now have a directory with about 60
files. The files with the .rules extension
contain the actual signatures that Snort
uses to match against the packet contents
going by on the wire. The threshold.conf
file is where you will put your threshold
and suppression rules (investigated in
Chapter 9). The snort.conf file stores the
configuration for Snort when running in
IDS mode. The other files help Snort
classify the different alert generators and
rules. You will not need to touch most of
these files. The only thing you will likely
need to be aware of (certainly initially) is
the snort.conf file. Initial configuration
of the snort.conf file
In alert mode, Snort requires a
configuration file (in fact, just specifying
the location of the snort.conf file puts
Snort into alert mode). The default
location for the configuration file is
/etc/snort.conf; if your configuration file
is located somewhere else, you must
supply the -c switch along with the file's
location. Alerts are placed in the alert file
in your logging directory (/var/log/snort
by default, or the directory you specified
with the -l switch). Snort exits with an
error if the configuration file or its logging
directory does not exist. You can specify
what type of alert you want (full, fast,
none, or Unix sockets) by supplying the
-A command-line switch. You need to use
the -A switch if you do not use the -c
switch, or Snort will not enter alert mode.
Additionally, if you use just the -c switch,
Snort will use the full alert mode by
Your friend through the entire process of
learning about the IDS mode of Snort will
be the -T flag (test mode). It initializes the
configuration, preprocessors, output plugins, and rule sets, and outputs the results
of the initialization to the console, letting
you see if everything is working correctly.
A first look at the snort.conf file is a bit
daunting for the uninitiated. The
snort.conf file is used to store all the
configuration information for a Snort
process running in IDS mode. The vast
bulk of the snort.conf file is commented-
out instructions on how to use the file. In
Chapter 5, we will go into great detail on
the various settings and entries in this
critical Snort file, but let's get a quick
configuration built so we can start
watching for attackers (and seeing how
Snort watches for the bad guys).
The default settings for almost all of the
entries in the file should be fine for your
initial explorations. We won't make
changes to most of the variables (this
might lead to some false-positive alerts,
but while we're playing it won't really
matter). The only variable we want to set
is the RULE_PATH variable​this tells Snort
where to find the rule set files. Find the
line below in the snort.conf file:
var RULE_PATH ../rules
Change the line to the full path to where
you've extracted the rules. For example:
var RULE_PATH /usr/local/share/snor
To get Snort started, enter the following
command line:
snort -c /usr/local/share/snort_rul
It generates the following output on the
console (this output includes the
configuration of several preprocessors):
Running in IDS mode
Log directory = /var/log/snort
Initializing Network Interface eth0
--== Initializing Snort ==Initializing Output Plugins!
Decoding Ethernet on interface eth0
Initializing Preprocessors!
Initializing Plug-ins!
Parsing Rules file /usr/local/share
Initializing rule chains...
,-----------[Flow Config]---------| Stats Interval:
| Hash Method:
| Memcap:
| Rows
| Overhead Bytes:
No arguments to frag2 directive, se
Fragment timeout: 60 seconds
Fragment memory cap: 4194304 by
Fragment min_ttl:
Fragment ttl_limit: 5
Fragment Problems: 0
Self preservation threshold: 50
Self preservation period: 90
Suspend threshold: 1000
Suspend period: 30
Stream4 config:
Stateful inspection: ACTIVE
Session statistics: INACTIVE
Session timeout: 30 seconds
Session memory cap: 8388608 byt
State alerts: INACTIVE
Evasion alerts: INACTIVE
Scan alerts: INACTIVE
Log Flushed Streams: INACTIVE
MinTTL: 1
TTL Limit: 5
Async Link: 0
State Protection: 0
Self preservation threshold: 50
Self preservation period: 90
Suspend threshold: 200
Suspend period: 30
Stream4_reassemble config:
Server reassembly: INACTIVE
Client reassembly: ACTIVE
Reassembler alerts: ACTIVE
Zero out flushed packets: INACT
flush_data_diff_size: 500
Ports: 21 23 25 53 80 110 111 1
Emergency Ports: 21 23 25 53 80
HttpInspect Config:
Max Pipeline Requests:
Inspection Type:
Detect Proxy Usage:
IIS Unicode Map Filename: /us
IIS Unicode Map Codepage: 125
Ports: 80 8080 8180
Flow Depth: 300
Max Chunk Length: 500000
Inspect Pipeline Requests: YE
URI Discovery Strict Mode: NO
Allow Proxy Usage: NO
Disable Alerting: NO
Oversize Dir Length: 500
Only inspect URI: NO
Ascii: YES alert: NO
Double Decoding: YES alert: Y
%U Encoding: YES alert: YES
Bare Byte: YES alert: YES
Base36: OFF
IIS Unicode: YES alert: YES
Multiple Slash: YES alert: NO
IIS Backslash: YES alert: NO
Directory: YES alert: NO
Apache WhiteSpace: YES alert:
IIS Delimiter: YES alert: YES
Non-RFC Compliant Characters:
rpc_decode arguments:
Ports to decode RPC on: 111 327
alert_fragments: INACTIVE
alert_large_fragments: ACTIVE
alert_incomplete: ACTIVE
alert_multiple_requests: ACTIVE
telnet_decode arguments:
Ports to decode telnet on: 21 2
1652 Snort rules read...
1652 Option Chains linked into 152
0 Dynamic rules
| memory-cap : 1048576 bytes
| none
| gen-id=1
Rule application order: ->activatio
--== Initialization Complet
-*> Snort! <*-
Version 2.1.x (Build 24)
By Martin Roesch ([email protected]
It will sit here (watching the traffic) until
you stop Snort by hitting Ctrl-C or using
kill-USR1. The following summary then
Snort analyzed 3210 out of 3807 pac
Breakdown by protocol:
TCP: 2602
UDP: 2
ARP: 0
IPv6: 0
IPX: 0
Wireless Stats:
Breakdown by type:
Management Packets: 0
Control Packets:
Data Packets:
Fragmentation Stats:
Fragmented IP Packets: 0
Fragment Trackers: 0
Rebuilt IP Packets: 0
Frag elements used: 0
Discarded(incomplete): 0
Discarded(timeout): 0
Frag2 memory faults: 0
TCP Stream Reassembly Stats:
TCP Packets Used: 2602
Stream Trackers: 1559
Stream flushes: 0
Segments used: 0
Stream4 Memory Faults: 0
Final Flow Statistics
,----[ FLOWCACHE STATS ]----------
Memcap: 10485760 Overhead Bytes 164
blocks: 1 Could Hold: (73326)
IPV4 count: 1563 frees: 0 low_time:
finds: 2612 reversed: 1022(%39.
find_sucess: 1049 find_fail: 15
Protocol: 1 (%0.306279) finds: 8
find_sucess: 5 find_fail: 3 perce
Protocol: 6 (%99.617152) finds: 26
find_sucess: 1043 find_fail: 1559
Protocol: 17 (%0.076570) finds: 2
find_sucess: 1 find_fail: 1 perce
Snort exiting
Now, a file called alert is in the
/var/log/snort directory. This file
contains the alerts generated while Snort
was running. The output for this run is
shown below (I ran an nmap SYN scan on
the Snort host to generate some alerts):
[**] [1:469:1] ICMP PING NMAP [**]
[Classification: Attempted Informat
03/24-15:07:35.187504 -
ICMP TTL:51 TOS:0x0 ID:23210 IpLen:
[Xref =>
[**] [1:618:5] SCAN Squid Proxy att
[Classification: Attempted Informat
TCP TTL:44 TOS:0x0 ID:56810 IpLen:2
******S* Seq: 0x4EB5A7C6
Ack: 0x0
[**] [1:1421:3] SNMP AgentX/tcp req
[Classification: Attempted Informat
TCP TTL:44 TOS:0x0 ID:54050 IpLen:2
******S* Seq: 0x4EB5A7C6
Ack: 0x0
[Xref =>
[**] [1:615:5] SCAN SOCKS Proxy att
[Classification: Attempted Informat
TCP TTL:44 TOS:0x0 ID:9794 IpLen:20
******S* Seq: 0x4EB5A7C6
Ack: 0x0
[Xref =>
[**] [1:1420:3] SNMP trap tcp [**]
[Classification: Attempted Informat
TCP TTL:44 TOS:0x0 ID:41259 IpLen:2
******S* Seq: 0x4EB5A7C6
Ack: 0x0
[Xref =>
[**] [1:1418:3] SNMP request tcp [*
[Classification: Attempted Informat
TCP TTL:44 TOS:0x0 ID:37753 IpLen:2
******S* Seq: 0x4EB5A7C6
Ack: 0x0
[Xref =>
Let's quickly dissect an alert. Here's an
identification number for the alert
followed by the alert name:
[**] [1:1418:3] SNMP request tcp [*
Snort alerts are classified according to the
type of alert. The classification for this
alert is "Attempted Information Leak." A
Snort rule specifies a priority for an alert
as well. This lets you filter out low
priority alerts to concentrate on the most
worrisome. The priority of this alert is 2:
[Classification: Attempted Informat
This is the header and packet information
for the packet that caused this alert:
TCP TTL:44 TOS:0x0 ID:37753 IpLen:2
******S* Seq: 0x4EB5A7C6
Ack: 0x0
Each Snort alert includes a link to a
description of the rule that generated the
[Xref =>
This link is very useful for determining if
the alert is a false positive or an actual
problem. Alerts that you build yourself or
get from the mailing lists or newsgroups
will likely not have this information.
In the next chapter, we will look at the
threats to your network and how Snort is
able to detect these attacks in the act.
Following that interlude, we dive back
into the technical details of getting Snort
up and running in a way that suits your
environment best.
Chapter 4. Know Your
Any security-related project starts with an
inventory. You need to know what systems
are in your environment and what
software they are running. You also need
to know what business processes exist in
your organization so you can tailor your
information technology decisions to
support these processes.
When starting an IDS project, it's
important to know not just what you're
protecting, but also what the threats to
your environment are. If you don't
understand the nature and methods of your
enemy, building defenses to protect
against their attack is nearly impossible.
While you might stumble onto something
by accident, a targeted approach to an IDS
deployment yields better returns on your
time (and budget).
4.1 The Bad Guys
It's unlikely that a maniacal billionaire is
hiring some elite hacker to break into your
network or that a group of former Spetnatz
commandos are trying to steal the secret to
how your widgets are manufactured. The
threat often comes from people who aren't
targeting you specifically; they are simply
scanning huge ranges of Internet-connected
systems looking for vulnerable systems
that they can use for whatever purpose. No
matter the identity of these individuals,
they can be the cause of your two real
enemies: downtime and data loss.
4.1.1 Opportunists, Thieves,
and Vandals
Most often these attackers are not targeting
your environment specifically. They scan
and probe wide ranges of addresses
looking for systems that are vulnerable to
the exploits they are familiar with. They
range from the classic 15-year-old boy
trying to gain notoriety with his peers to a
SPAM sender looking for an open mail
server to act as a relay for his unsolicited
emails. While this group of people
represents mainly an annoyance, it is folly
to ignore the threat.
Simply connecting your network to the
Internet exposes you to this kind of
attacker. It's not a matter of if but when
someone will probe and attempt to
penetrate your network.
These individuals are trying to break
into systems just for the challenge.
They might just look around after
getting in, or may become vandals.
While not (at least initially)
malicious, they can inadvertently do
damage or cause service
interruptions in the course of their
These people are generally not trying
to get your data​they're after your
bandwidth, computing power, or
want to use your mail system for their
own purposes. Your network
bandwidth is probably better than
theirs and would make their
explorations much easier than their
slow dial-up line. Your computers
compile programs better, have more
disk space for their pirated DVD
rips, and are easier to get to than
their own systems for their friends.
In the old days, someone would
shimmy up a water tower and spray
paint his high school's team name for
everyone to see. Now, someone will
shimmy into your web server and do
the same thing with your main web
page. As soon as your web site is
defaced, they hop onto their favorite
IRC channel and tell their friends to
have a look. In the meantime, your
company faces reputation damage
and you, as the person who's
ultimately responsible for the
security of your network, have to
explain how it happened without you
4.1.2 Professionals
There are many stories from the cold war
era of spies using computers to steal
information or do harm to their opponent.
The East Germans broke into the
Lawrence Berkeley National Laboratory
(chronicled in Clifford Stoll's "The
Cuckoo's Egg") and the United States
planted faulty designs for software and
computer chips that caused a massive
explosion of the trans-Siberian pipeline.
The attackers of government systems these
days are more likely to be terrorist-related
The threat of a professional attack on your
environment is relatively small. The
payout for the freelancer doing the work is
low for days of painstaking work (the
work is harder when you have to cover
your tracks). The impact of such an attack
can be huge, however. Intellectual
property can be lost, or systems can be
destroyed. I've met people who do this for
a living​the threat is real.
4.1.3 Disgruntled Current
and Former Employees and
The threat from this group is often
underestimated. These folks have been
trained by you, are familiar with your
environment, and can often bypass your
perimeter security measures. They have
motive, opportunity, and the skills
necessary to do real damage. The
existence of this threat inside your
network is a strong argument for defensein-depth. Protecting internal systems from
internal users is fairly difficult and
requires consideration and vigilance.
4.1.4 Robots and Worms
Once, the only way to get a virus on your
system was to use an infected floppy disk.
Now, an actual virus is fairly rare.
Infections occur from across the network.
The newly infected machine, in turn,
infects other systems. Many times the
inconvenience is not the impact on the
infected systems, but the impact on the
network. The SQL Slammer worm caused
many networks to become completely
saturated with the 404-byte UDP packets
(the entire worm was contained in a single
UDP packet!).
The worms are getting faster, too. The
Code Red worm took about 13 hours to
infect 90 percent of the hosts it would
eventually affect. SQL Slammer took 10
minutes to do the same thing! This speed
of propagation is due to the fact the UDP
worms have the unfair advantage of not
needing to establish a three-way
handshake​not all subsequent worms will
have this advantage. Increased vigilance
is absolutely called for, and the only way
to notice is by watching your network
Simply closing ports on your firewall
does not help much, either. The series of
worms that exploited the vulnerable RPC
services on Windows systems (Blaster,
SoBig, Nachi, Welchia, and so on)
required access to TCP ports 135-139​not
normally open to the Internet. Most
organizations were infected across VPN
connections, remote dial-up connections,
and backend connections to business
partners. See Chapter 1 for a discussion of
the disappearing perimeters of our
Sometimes the automated attack is not
actually a worm, but a script running on
the Internet looking for systems that are
vulnerable to a particular attack. The
results of this scan then acts as a target list
for an actual person to attack. This method
has been suggested as one way to
introduce a worm in a fashion that jumps
up the growth curve; e.g., by finding a
large number of vulnerable machines in
advance, an attacker can start the worm
from 5,000 hosts (each scanning the
network) at once, instead of, say, 5 hosts.
4.2 Anatomy of an Attack:
The Five Ps
In a meeting with an engineer (Jonathan
Hogue) from a security company called
Okena (recently acquired by Cisco), I was
introduced to the concept of the five Ps.
Hogue graciously gave me the
presentation slide and I use it all the time.
There are a lot of models of how an attack
progresses, but this is the best I've seen.
These five steps follow an attack's
progression whether the attack is sourced
from a person or an automated worm or
script. We will concentrate on the Probe
and Penetrate phases here, since these are
the stages that Snort monitors. Hopefully,
the attacker won't get past these phases
without being noticed. The five Ps are
Probe, Penetrate, Persist, Propagate,
and Paralyze.
4.2.1 Probe
In this phase, the attacker gathers
information on a potential target. In a
targeted attack, the scanning may be
limited to your allocated range of IP
addresses. In an untargeted attack (see
Section 4.1.1, above), it might be against a
wide range of addresses. Often, the initial
activities of this information-gathering
will not send a single packet to your
network. A surprising amount of
information can be gathered from
information stores on the Internet. The
goal of this phase is to map out your
network and determine details about the
systems on your network, permitting the
attacker to tailor an attack to exploit
known vulnerabilities in the software
version running on your system, or
perhaps to a configuration error. Mining the Web
What follows are methods attackers use to
gather information about the network, IP
address range, or business assets they
wish to attack​w ithout sending a single
packet to your network:
WHOIS, ARIN and DNS lookups
Gleaning data from off corporate
web sites
Web-based reconnaissance
General reconnaissance using Sam
Spade, IP Tools, etc.
The victimized network is not always
purposefully sought out. Drift net
scans or blindly probing large subnets
for vulnerable devices sometimes
brings networks onto radar screens.
Such is the importance of staying
current with patches and closing
susceptible ports.
An initial tactic is to gather information
regarding the IP addresses owned or
managed by a particular company, the
contact people, or even the physical
address or location of the company. Here
are some sites that give out this type of
Performs lookups on the
administrative, technical, and billing
contacts for a particular domain
Searches for the registrant and IP
address range of a particular IP
address. Useful for tracking down
offending IP addresses.
Executes multiple DNS lookups on
IP addresses or domain names. This
site is used for performing both
forward and reverse name resolution.
It is comparable to the Linux
command line nslookup or dig
There are several other free WHOIS
services available on the Internet. Each
one offers nearly the same information that
can be gleaned from the main Network
Solutions page. Sites such as and are also
used. Attackers visit these sites to locate
domain names pending expiration.
Network Solutions and Verisign have
proved most accommodating recently by
providing alternative misspellings of
common domain names. Both of these
features are useful when attempting to take
over a domain or redirect normal
commerce traffic to another site by means
of subversion. Check these web pages for
information about your own company. If
too much data is available on the Internet
or if you wish to minimize your company's
exposure, resubmit the correct forms to
Network Solutions or to your domain
name provider. Also, update the
information contained on the ARIN site by
modifying RWHOIS records. One tactic is
to replace names with titles, or even use
bogus names to make it harder for social
engineering to succeed.
Another common tactic is to gather data
from corporate web sites. Most
companies list their physical address and
provide maps and directions. Typical
business sites often display not only the
president or CEO's name (and all other
higher management personnel) but provide
an email address and phone number.
These are useful to attackers when
performing social engineering. In addition,
the email address can assist in DNS
requests and MX record lookups.
Minimize the amount of data you are
willing to share with strangers by
censoring corporate web pages. Explain
this to company managers as well as to the
webmaster. Anyone using the corporate
web site for marketing or sales purposes
should be aware of any inherent security
There are several free tools for Windowsbased machines that execute commands
similar to those found on Linux. The two I
mention here are Sam Spade and IPTools. Their URLs are listed at the end of
this chapter. The former is free, while the
latter currently requires a $35 registration
fee. Both of these utilities provide
Windows users with much the same
functionality as Linux. They offer many
like features, including webcrawling
utilities, real-time blackhole lists for
determining the IP addresses of repeat
spam offenders, ping, whois, dig, and
traceroute. The IP-Tools application
does have some added functionality such
as port and NetBIOS scanning similar to
that of Nmap for Linux, along with a telnet
utility. It also performs netstat
commands that displays open ports
listening for connection requests.
There are several other DNS query tools
available for use directly off web pages. I
recommend the site for
determining version and release numbers
of a particular web server. This leads us
into the active probing that can be
performed to gather information about
your network. Portscans and
software version-mapping
One of the most widely used network
mappers or port scanners is Nmap.
Fyodor, the author, describes his tool in
the following manner
Nmap or "Network Mapper" is an
open source utility for network
exploration or security auditing. It
was designed to rapidly scan large
networks, although it works fine
against single hosts. Nmap uses raw
IP packets in novel ways to
determine what hosts are available
on the network, what services
(ports) they offer, what operating
system (and OS version) they are
running, what type of packet
filters/firewalls are in use, and
dozens of other characteristics.
Nmap is available for most systems,
including nearly all BSD variants, Solaris
and Linux, and Windows. Nmap can be
used from the command line as a console
tool or in its graphical release. It is started
from the prompt with the command nmap.
The graphical version is initiated using
nmapfe, short for "nmap frontend." Nmap
is best run as root so all options are
granted to the user. Consult the Nmap
home page at for
available options and latest source code.
Nmap comes in source and RPM formats.
It is included as a standard package with
most Linux distributions, including Red
Hat. Install it initially or compile it later
from source.
Figure 4-1 shows Nmap run as root with
the graphical frontend. Selecting different
variables within "Scan options" and
"General options" customizes how
stealthy or unobtrusive the scans run
against target systems. The output as it
appears on the command line is displayed
directly below the options. By noting the
syntax that appears below the main
window, a scan can be run from the
console or the command line.
Figure 4-1. The main
interface for the Nmap Front
End tool
After selecting a target IP address, subnet,
or domain name, execute the scan. The
output displays in the lower box. All
detected open ports are shown here with
the service name and port number.
The latest release of Nmap shows not only
the open ports but performs fingerprinting
of the listening ports and displays the
software version and release currently
running on that port. Not only can I find
out if a port is open, but I can see the
Apache version and the current PHP
release running on my system.
Currently, Nmap is best run from the
command line for a detailed report on
available services. Here is what a scan
showed against a typical machine with a
default or "vanilla" configuration.
# nmap -sV -T4 -F localhost
Starting nmap 3.45 ( http://www.ins
Interesting ports on localhost (127
(The 1203 ports scanned but not sho
vsFTPd 1
Apache h
UW Imap
6000/tcp open
Device type: general purpose
Running: Linux 2.4.X|2.5.X
OS details: Linux Kernel 2.4.0 - 2.
Uptime 9.486 days (since Mon Sep
Nmap run completed -- 1 IP address
Nmap scans are useful for testing Snort
installations. By default, Nmap is fairly
noisy and easily detectable. Most Nmap
scans readily show up in the alerts file or
via the ACID web page.[1] Existing
signatures that alert administrators to
Nmap scans can be customized to suit.
[1] The Analysis Console for Intrusion Detection
(ACID) is an open source project developed by
Roman Danyliw at the CERT coordination
center, as part of the AIRCERT project. It uses
a PHP-based web application that can act as the
frontend for several tools. See Chapter 10 for
more about ACID.
Here is one of several possible alerts that
appear in the Snort alert log when Nmap
is run (using Nmap's -P0 option prevents
the ping from being sent).
[**] [1:469:1] ICMP PING NMAP [**]
[Classification: Attempted Informat
ICMP TTL:22 TOS:0x0 ID:51496 IpLen:
[Xref =>
arachnids 162]
There are also Nmap-specific scans that
show up in the Snort alert log. These
range from Nmap web-based attacks to
fingerprint attempts (much like the
example scan shown above) to TCP scans.
To view sample alerts generated by Snort
when Nmap is run against it, simply grep
the text "nmap" within the Snort rules.
There are plenty of occurrences in which
Nmap plays a role in generating alerts.
Each of these rules can be customized to
give alerts on a more specific level.
Once ACID is operational with Snort,
consult the logs frequently for network
scans and connection attempts. Some
Nmap scans may be stealthy connection
attempts so also look for SNMP requests
and proxy scans, which are fairly typical
for Nmap.
A quick word of caution. Those of
you reading this book who think you
are now an "elite hacker" or that this
and the other outlined tools will assist
in cracking other systems, do not be
fooled. Simply running Nmap against
other computers does no such thing.
All Nmap does is show open ports and
available software versions. That said,
since a portscan is often a precursor
to an attack, most people do not take
kindly to network portscans. Consider
yourself warned. People have been
prosecuted for attacking a network
after only performing a portscan.
Armed with this information, an attacker
can go to a variety of web sites and
discover if you are running an operating
system or service version with known
vulnerabilities. Once this is determined, it
is a relatively easy manner to find scripts
or programs that can exploit the
vulnerable system, leading to a
penetration. Automated
vulnerability scanners
Port scanning, fingerprinting, and
determining software versions takes a
considerable amount of time and some
skill at rooting out information on the
Internet. To make research easier, a
number of tools are available that perform
all these tasks automatically. There are
expensive commercial solutions and free
open source tools. While these tools were
designed to make it easier for
administrators to evaluate their security
posture, they are a boon to the bad guys,
One open source tool has risen above the
others (arguably including the commercial
alternatives): Nessus. It can be
downloaded from
Nessus is free, manageable even by
novice users, has clients for both Unixbased systems and Windows, and displays
the data in an easy-to-understand format. It
also suggests what measures to take to fix
any listed problems. It should be noted
that Nessus works with a client/server
model and only a client is available for
Windows systems. A server version
exists, but it is a commercial solution from
Tenable Security
( Nessus
also includes Nmap and provides
additional reports on OS detection, what
ports are currently open, and so forth.
Nessus should not be implicitly trusted.
False positives are a frequent occurrence
and corroborating evidence is suggested
before taking aggressive measures against
any system.
Because Nessus is manageable even by
new Linux users, it is often abused. As a
result, Nessus probes and scans readily
show up in Snort alerts. There are a
variety of Snort signatures that detect a
typical Nessus scan. These are normally
classified as attempted-recon and as such
fall under a classtype 2 categorization or
have a Medium severity. Nessus scans are
serious infractions and should be
considered a potential threat. Just because
they are classtype 2 does not mean the
information gathered may not affect you
There are currently four different methods
of downloading and installing Nessus.
You can install directly from the web site,
by running a local script, or you can build
from source. Some distributions have
precompiled binaries available. Refer to
the documentation to determine which
method suits your environment.
Once the program is installed and a
certificate and user are added, start the
Nessus daemon on the local server with
the command:
# /usr/local/sbin/nessusd -D &
You will not need to reboot the machine
upon starting this daemon. However, you
should automate startup of the Nessus
daemon on the local server after a reboot
by placing this command on a line in the
/etc/rc.d/rc.local file. Remember, the
Nessus daemon must be running for the
Nessus client to run. The client is
typically run locally but can also be run on
another system by connecting to the local
daemon. Keep the Nessus application
current with the latest plug-ins by running
the command /usr/local/sbin/nessusupdate-plugins. This command can be
placed in a cron job and run nightly. Some
users prefer doing this manually.
Start the Nessus client from the command
line as a regular user (or by executing the
Windows binary). You are warned that all
dangerous plug-ins, or those that have the
ability to crash a system, have been
disabled. This is the suggested method of
running Nessus initially. These dangerous
plug-ins include checks that may cause a
service or system to crash and should only
be used as when downtime will not
adversely affect your environment.
Be aware that the information
obtained from scanning machines on
your network can be potentially
dangerous. In the hands of a malicious
user, the knowledge gained might be
used to crash scanned machines. Burn
the reports to CD and store them in a
safe location. This way the data is not
modifiable and can be secured offsite
and removed from a mounted drive. It
can be referred to later when updates
and patches have been completed on
affected systems.
There are varying levels of testing
available for use with the Nessus client.
Before trying anything familiarize yourself
with the available plug-ins, preferences,
scan options, and target selection
possibilities. Security scans can be
customized to be extremely nonintrusive
and last for several hours, or they can
blast away at a network or a single box
while employing all the local machine's
available CPU power and memory to run
the scan.
Figure 4-2 is a sample screenshot of
available plug-ins that can be enabled
during a test scan. Note the checkboxes to
the far-right of the listed plug-ins.
Figure 4-2. Enable or disable
available plug-ins in Nessus
depending on the type of scan
A typical network scan can include
multiple servers or systems at the same
time. The more machines you select to
scan, however, the higher the CPU load on
your system and the slower the results. A
typical scan can also be run overnight to
reduce the load on the system and
minimize the effect on the target systems.
When complete, the scan's final results are
displayed in a window much like that
shown in Figure 4-3. Here you can burrow
down into the findings and view the
warnings, notes, or security holes detected
by Nessus, along with recommended
Figure 4-3. Viewing the final
Nessus report
Save the report when it's done. It can be
useful later when running follow-up scans.
The report itself is saved in a variety of
formats, including NBE (a proprietary
Nessus format), NSR (an older deprecated
Nessus style), XML, HTML, LaTeX,
ASCII text, or even in HTML format with
pies and graphs. The last option makes for
clean presentations when you are
presenting findings to an audience.
Since Nessus attempts hundreds of
different checks against the target systems,
it generates many alerts with a wide
variety of signatures. Here is a sample of
the Snort output from a Nessus scan:
[**] [1:1228:3] SCAN nmap XMAS [**]
[Classification: Attempted Informat
TCP TTL:38 TOS:0x0 ID:1147 IpLen:20
**U*P**F Seq: 0xEB5E3384
Ack: 0x0
TCP Options (5) => WS: 10 NOP MSS:
[Xref =>
[**] [1:2385:3] NETBIOS SMB DCE/RPC
[Classification: Attempted Denial o
TCP TTL:64 TOS:0x0 ID:14271 IpLen:2
***AP*** Seq: 0x737329C2
Ack: 0xF9
TCP Options (3) => NOP NOP TS: 1654
[Xref => http://www.securityfocus.c
bid/9633][Xref => http://cgi.nes]
[**] [1:2251:4] NETBIOS DCERPC Remo
[Classification: Attempted Administ
TCP TTL:64 TOS:0x0 ID:14354 IpLen:2
***AP*** Seq: 0x73FB71F0
Ack: 0x95
TCP Options (3) => NOP NOP TS: 1654
[Xref =>
e.cgi?name=CAN-2003-0605][Xref => h
2003-0528][Xref => Web page scanners
Another network scanner of note is nikto,
a web CGI probe that performs
comprehensive tests against web servers
for multiple vulnerabilities. This includes
detecting over 2,200 potentially dangerous
files or CGIs on over 140 servers and
problems on over 210 servers. Written by
Sullo, it superseded the Whisker
application originally written by Rain
Forest Puppy (or RFP), who decided to
abandon development of Whisker in favor
of nikto. This application uses the
LibWhisker libraries from Rain Forest
Puppy Labs (rfp.labs) or as a base for
all network detection. Nikto is not an
overly stealthy tool. It tests a web server
in the shortest time span possible and its
probes are readily apparent in the web
server's logfiles.
Snort can easily detect a nikto probe.
There are entire categories of signatures
that define web attack and web CGI rules.
Nikto appears plainly in Snort alerts. The
name "nikto" may not be obvious, but a
flurry of web CGI alerts should show up
in the Snort logs when a scan is run
against the web servers.
Here are just a few of the possible alerts
that can be generated in response to a
Whisker- or nikto-based scan. These are
all classified as miscellaneous web rules.
A URL points to more information on
identifying Whisker-based scans.
Detecting such a scan almost always
indicates that the early stages of an attack
are underway.
web-misc.rules:alert tcp $EXTERNAL_
MISC whisker HEAD/./"; flow:to_serv
attempted-recon; reference:url,www.
html; sid:1139;
web-misc.rules:# alert tcp $EXTERNA
ISC whisker HEAD with large datagra
dsize:>512; flow:to_server,establis
web-misc.rules:alert tcp $EXTERNAL_
MISC whisker space splice attack";
1; reference:arachnids,296; classty
web-misc.rules:alert tcp $EXTERNAL_
MISC whisker tab splice attack"; ds
"|09|"; reference:arachnids,415; cl
Installing and running nikto is simple.
Download the source code and
uncompress it in a secure directory.
Within the new nikto/ directory, run the Perl script. Be sure to define the
target host with a -h <target> option.
Here is how a sample command appears.
# ./ -h
Refer to the help file for additional
options you can tailor the scan for your
environment to speed things up. Nikto can
use an Nmap file as input and can generate
output in several formats, including
Here are some sample results when nikto
is run against an older Apache web server
on a standard Linux machine. As you can
see, there are several items that can and
should be cleaned up.
# ./ -h
-*** SSL support not available (see
----------------------------------- Nikto 1.30/1.06
+ Target IP:
+ Target Hostname:
+ Target Port:
+ Start Time:
Sat Oct 11 08:17
- Scan is dependent on "Server" str
+ Server: Apache/1.3.26 (Unix) PHP/
+ Allowed HTTP Methods: GET, HEAD,
+ HTTP method 'PUT' method may allo
+ HTTP method 'CONNECT' may allow s
+ HTTP method 'DELETE' may allow cl
+ HTTP method 'PROPFIND' may indica
authorized users to consume system
+ HTTP method 'PROPPATCH' may indic
authorized users to consume system
+ HTTP method 'TRACE' may allow cli
+ Apache/1.3.26 appears to be outda
3.27 is still widely used and consi
+ PHP/4.2.2 appears to be outdated
+ Apache/1.3.26 - Apache 1.3 below
which allows attackers to kill any
+ /~root - Enumeration of users is
Forbidden for real users, not found
+ /icons/ - Directory indexing is e
directories (if required). If index
be removed. (GET)
+ /index.html.en - Apache default f
should be removed from the web serv
information. (GET)
+ /manual/images/ - Apache 2.0 dire
enabled for specific directories (i
directory indexing disabled. (GET)
+ / - TRACE option appears to allow
+ / - TRACK option ('TRACE' alias)
+ /manual/ - Web server manual? tsk
+ /test/ - This might be interestin
+ 1632 items checked - 9 items foun
+ End Time:
Sat Oct 11 08:17
Some of the more obvious results are that
both Apache and PHP should be updated
to the latest version. The scan displays the
most grievous security concerns and
provides some suggested measures. The
first line of the scan also indicates that
there is no built-in secure socket layer
(SSL) support in this version of nikto. Do
not enable features you do not understand
or that may be unnecessary. If the server
your are scanning only supports SSL
connections (port 443), consider running
the scans through an open-source tool
called SSL Proxy. There is also an older,
alternative Whisker release that does
support SSL at Other probe tools
Several useful tools exist that have more
esoteric results, duplicate the functionality
of the tools we discussed earlier, or are
more difficult to use. You are invited to
investigate these tools at your leisure.
This tool enables an attacker to map
out the access control lists of your
firewall by using a variety of TCP/IP
investigation mechanisms.
Hping uses a variety of techniques to
map networks, discover the
configuration of firewalls, perform
operating system fingerprinting, and
make other configuration mapping.
The next version of hping promises
even more power.
Part of the UCD-SNMP set of tools,
this permits an attacker to enumerate
a great deal of configuration
information about a system whose
SNMP ports are exposed to the
Internet. SNMP can be a huge
security hole, so the SNMP ports
should be blocked.
4.2.2 Penetrate
Once the systems and potentially
vulnerable services have been
discovered, the next step is an attack. The
attack can take a variety of forms. The
attack may cause a system to execute code
of the attacker's choice. If the attacker has
access as an unprivileged user, the attack
may escalate the user account to an
administrator-level access. The attack
may simply crash a service or entire
system (see Section 4.3 later in this
There are a myriad of penetration methods
and the vast bulk of Snort signatures are
built to detect them in progress.
Automated attacks such as worms or
scripts actually combine the Probe and
Penetrate phases by simply launching
attacks against a range of addresses
(which fail against systems that are not
vulnerable). If a rule exists that is
designed to recognize one of these attacks,
Snort will certainly detect these attempts.
Sometimes the attack is hidden in a Trojan
horse​usually an attack program hidden in
another. The attack sometimes contains a
remote control utility that calls back to an
attacker, giving the attacker a point of
presence inside your network. An entire
class of rules exist to watch for Trojan
horse traffic.
Some of the most useful Snort signatures
do not actually trigger on an attack
attempt, but on the traffic generated by a
successfully attacked host. For instance,
an attack is launched against a Windows
web server that attempts to trick it into
returning a directory listing of the web
root. One Snort rule watches for the string
"The Volume in Drive C: has no label"
coming from port 80 (or another
configured web port). Very rarely will
legitimate traffic trigger this rule. The nice
thing about the signatures in the attack-
responses.rules rule set is that it doesn't
matter what attack generated the traffic
that triggered the alert​they are almost
always true indicators of a successful
Perhaps the best way to get up to speed on
the different attacks is to examine the
Snort rules themselves. Keeping an eye on
resources like and is a good
idea, too. The list below gives some of the
penetration methods (it's by no means
comprehensive). Authentication
If during the Probe phase a
username/password prompt for a
particular service is discovered, an
attacker can use a script (or one of several
password grinding tools available) to start
guessing passwords. The script can either
brute-force the passwords of various
lengths by trying all possible
combinations or use a dictionary of
potential passwords. Usernames are fairly
easy to discover since email addresses
are very often the same as usernames.
Alternatively, many operating systems and
services have default usernames that can
be guessed. If the authentication
mechanism behind the discovered
username/password prompt does not lock
accounts after a certain number of bad
password guesses (Windows does not
lock the built-in Administrator account by
default), an attacker can take as long as is
necessary to discover passwords. Even
diligent administrators who enable
intruder lockout protections in their
environment can be defeated by a webbased interface that does not use the same
protection when authenticating users. Even
with these measures in place, you are just
making it take longer to guess the
passwords. A patient attacker will throttle
the speed of the guessing so as to not
trigger lockout. Buffer overflows
Buffer overflows represent at least 50%
of newly discovered vulnerabilities.
Simply put (very simply... it can get
complex), when an application is running,
it allocates memory for the different
information it needs to keep track
of​names, addresses, phone numbers, costs,
item names, and so on. Very often,
applications ask the system or the user of
the application for information to insert
into these memory locations. If the
application blindly accepts whatever the
user (or system) provides, problems can
Let's say that an application asks for your
name. It allocates 20 characters in
memory for this information. If the user
provides more than this number of
characters and the application does not
check for that possibility, memory past the
previously allocated 20 characters can be
overwritten with the user's information. If
the user is very crafty and provides a
character length that forces the application
to overwrite portions of memory that the
system uses to run other programs, it may
be possible to trick the system into running
whatever you want it to run. This could be
a variety of things: instructions to install
remote control software, return the
contents of a directory, dump the username
and password database, and so on.
Anything you can put in a small chunk of
code can be run using this technique.
Most buffer overflows result in a service
or system crashing. The real art in crafting
a successful buffer overflow is
determining how many characters to insert
before the malicious code to get the code
to run. This length is commonly referred to
as the offset. Application behavior
boundary flaws
This is a difficult category to define.
When a developer designs an application,
he does not always anticipate the ways the
application may be tricked into doing
other things that are not intended. A great
example of this are the techniques that
tricked Windows IIS web servers into
running a command shell from the system
directories using Unicode characters to
represent a "dot-dot-slash." In most
operating systems, a "../" moves a
command shell up a layer in the
filesystem. By crafting a URL with these
Unicode characters and sending it to a
vulnerable web server, it was possible to
trick the web server into jumping out of its
web root directory and into the system
directory. From the there the attacker
could execute any of the system
applications​including cmd.exe, the
command shell. Once a command shell
running under the context of the web
server is available, anything is possible.
This is just one example and there are
many like it that affect a wide range of
applications and operating systems.
Please don't think I'm picking on
Microsoft. Snort is well equipped to catch
most of the known variations of this class
of attack. System configuration
When a system is not configured
according to industry-accepted best
practices, security vulnerabilities can be
exposed. If an account has a very poor
password, it may be guessed, for example.
If a firewall is misconfigured to allow
dangerous ports through into the internal
network, it may increase the chances of a
successful attack against your
environment. A fair number of Snort
signatures catch some of this "low-hanging
fruit." User input validation
One consequence of not checking what
information a user supplies to an
application was discussed in Section, above. Other, equally dire,
consequences can result from not
validating a user's input. A rule of thumb
when attempting to write secure code is,
"Never trust anything a user or other
process tells you."
One common technique for exploiting
careless user input validation is called
SQL Injection. Most (really useful) web
pages are built from the data contained in
a database. If a web page asks the user for
input (including things like login
credentials), it is possible to replace what
the web page is looking for with SQL
code that gets passed to the database
server on the backend. If this is properly
crafted, it can make the database dump
data that the user would normally not have
access to​sometimes sensitive business
data. It is also possible to insert data into
the database, thereby poisoning the
database and making it impossible to trust.
The inserted data could also be used to
create a user and password with high
privileges if the database is used for
There are several Snort signatures that
watch for this variety of attack, as well.
4.2.3 Persist
Once an attacker goes through the trouble
of finding a vulnerable system, locates or
builds the attack, and then successfully
attacks the machine, it would be a
nuisance to have to repeat the process
every time he wants to access the system.
It may be that between visits, the system
gets attention from an administrator and is
no longer vulnerable. Launching an attack
multiple times against a system increases
the chances of being noticed.
As a result, one of the first things an
attacker does once a machine has been
"owned" is make it easier to get back onto
the system. The attacker may create an
administrator-level user with a password
that only he knows. He may simply
acquire the username and password
database from the system and crack the
passwords using a password cracking
utility (like John the Ripper or
L0phtcrack) to decrypt the passwords on
their system. Once the passwords are
cracked, the attacker can login as
whomever he wants.
The attacker may install some remotecontrol software, too. This makes it easier
to work remotely on the system. The most
common of these tools is a utility called
netcat. Netcat is a very flexible remote
command-shell utility that is easy to
install remotely and can be configured to
run on any network port, making it
possible to access through a firewall.
Most serious attackers attempt to hide
evidence of their activity at this point by
altering or deleting system and firewall
logs. They may use utilities that hide the
directories that hold their attack tools
from the eyes of administrators.
If the attacker was an automated tool or a
network worm, it may copy itself to
system files, and ensure that it will
survive past a reboot. It may go so far as
take steps to hide itself, too.
4.2.4 Propagate
Once the attacker has an established
presence on a system, the next move is to
see what else is available. The attack
phases begin anew with the compromised
system as the source of the activity. The
attacker will try to map the internal
network (or the network that contains the
compromised system). The newly
enumerated machines will then be
attacked, if they are interesting to the
attacker. If the attack was a worm, this
phase is sometimes the most damaging.
The worm attempts to infect (probe and
penetrate) other systems on the local
network (or systems on the public
There is a concept called implied trust, in
which a username and password that
works on one system (or group of
systems) works on another system. For
example, if the system that was
compromised is a Linux system, the
username and password that works on this
system may also work on the
organization's Windows systems, as well.
While the concept of "single sign-on" is an
administrative aid, it can be a detriment in
the event of a successful attack.
The only good news is that, if an attack
gets to this point, it may be possible to
detect this second round of attacks with
your Snort systems.
4.2.5 Paralyze
This is the ultimate goal of a targeted
attack, in which the attacker goes after
your environment with a goal in mind. The
goal may be to steal or destroy data, bring
your systems down, or attack another
organization from one of your systems,
making you look guilty. The attacker looks
for what I call the "soft, chewy center" of
your network. This is most often a
database that hosts your organization's
proprietary data, financial information,
inventory, or even email.
If a worm was the source of all your
trouble, the result in this phase may be
clogged network connections and crashing
4.3 Denial-of-Service
Sometimes the goal of an attack is not to
steal something from you, but to make your
systems or network unavailable either by
crashing a system or saturating the
resources of the target systems or network
connection. This form of attack has
consequences beyond inconvience.
Imagine a clothing company that does the
bulk of their sales through an online
catalog. If people can't log into the web
site, they can't buy sweaters and polo
shirts. This loss of business can have
significant impact in a short time. (This is
what happened to eBay, Yahoo, and other
large web services in February of 2000.)
A large number of signatures help detect
this category of attack. With a combination
of signatures, portscan detection,
automated blocking, and the new
thresholding and suppression rule types,
Snort can be a very good countermeasure
against denial-of-service (DoS) attacks.
4.4 IDS Evasion
When dealing with networks that use
intrusion detection systems such as Snort,
you must be aware of any other tools that
can bypass security restrictions. If an
attacker can disguise his activities from
your IDS, you may not be aware of the
attack until it is too late. There are a
variety of strategies employed by
attackers to hide their actions.
Some of the tools we've already discussed
have components that help hide their
traffic from your IDS. Nmap has the
ability to throttle the packets it sends when
scanning so that packets are sent so slowly
that they do not trigger portscan detection
mechanisms. Another nmap evasion
technique is to generate numerous packets
in addition to the actual scan. These
packets have forged source addresses and
the actual scan gets lost in the noise. This
technique does not keep the IDS from
noticing the portscans; instead, it
generates so many alerts that determining
the actual source is more difficult.
The web scanner nikto has an IDS evasion
mode, as well. As of Version 1.10,
LibWhisker's anti-IDS methods have been
enabled in the event you wish to test your
IDS. Depending on how recently you
updated your signatures, the anti-IDS
feature may or may not be able to
circumvent your IDS. It may have greater
luck bypassing proprietary intrusion
detection systems whose signatures have
not been recently updated. Refer to the
help file for additional options. You
enable the IDS evasion mode by
appending the -evasion+ option and the
preferred IP address.
Another strategy for evading detection is
to encrypt traffic; encrypted packets will
not match the signatures and thus won't
trigger alerts. sslproxy is a useful tool for
encrypting web scans; it negotiates an SSL
connection with an SSL-enabled web
server. The proxy then sends the scan
across this encrypted tunnel. Any webbased attack activity can be sent across
the tunnel, effectively making it invisible
to the IDS.
Stick is a program that is still in the
works. Its author is considering releasing
to the public. It is labeled an "IDS stress
tool" and is used to evaluate the
bottleneck in a production environment.
During testing it caused the ISS Real
Secure IDS Version 5.5 to turn itself off
due to errors. The ISS Real Secure sensor
died two seconds after the attack with
Stick began. The same results occur with
other IDS solutions, including Snort.
The concept behind Stick is a simple one:
overwhelm a network intrusion detection
system with so many alerts using valid
signatures that the security administrator
can no longer distinguish between false
positives and legitimate alerts. According
to the author, Stick uses a Snort rule set
and a C program via lex that, when
compiled, produces an IP packet capable
of triggering that rule from a spoofed IP
range (or all possible IP addresses) into a
target IP range. A function is produced for
each rule and a loop executes all rules in
random order. The tool currently produces
250 alarms per second. A Linux-based
Snort IDS will hit 100% CPU and start
dropping packets at this level of attack. So
far, the author has only released the Stick
source code to IDS vendors. More
information regarding Stick is available in
the author's "Papers" section. The one
titled "Fun with Packets: Designing a
Stick" by Coretez Giovanni is particularly
useful for explaining how Stick works and
how to overwhelm IDS devices.
Two other tools that can be used for
stress-testing an IDS machine prior to
gaining access or slipping in undetected
are Snot and Fragroute. The former is
similar to Stick in that it triggers false
Snort alerts using a Snort rules file for its
input. This both overwhelms and confuses
the IDS since the security administrator
can no longer tell the difference between
the false positives caused by snot or any
real alerts triggered by the attacker. Snot
is basically an IDS evasion tool. It
attempts to randomize the sequence of
rules or alerts generated so that a "Snot
generation" rule is not triggered by Snort.
Snot is easily executed on a Linux or
Unix-based system. Here is an example of
snot -r snort.rules -s www.somerand
Snot first reads in the snort.rules file,
sends packets with a source address from
anywhere on the CIDR-notated /24
network that
resolves to, and then transmits the packets
to, sleeping for up to
10 seconds per packet.
If your CIDR notational skills are
lacking, refer to the following URL for
a refresher course:
However, there are rules within Snort that
do account for these types of attacks and
do alert administrators that a Stick/Snot
attack is underway. Using the -z
command-line switch in concert with the
stream4 code, Snort generates alerts
warning the administrator when it sees
these types of anti-IDS attacks. The -z
switch runs without arguments. If the -z
switch is specified, Snort only sends
alerts (for TCP traffic) on streams that
have been established via a three-way
handshake or streams where cooperative
bi-directional activity is observed, i.e.,
where some traffic went one way and
something other than a RST or FIN was
seen returning to the originator. With the z option enabled, Snort completely
ignores TCP-based Stick/Snot "attacks"
and logs other malicious packets
normally. In other words, Snort operates
as usual and is not confused by an IDS
evasion tool.
If you suspect a Snot/Stick attack is
underway against your system, initiate
Snort using the correct flags. For example,
here is how you might start the Snort
command on machine A with the -z option
# snort -i eth0 -c /etc/snort/snort
Running Snot on machine B while
targeting machine A appears as follows:
# /usr/local/bin/snot -r snortrules
The snortrules.txt file is a default
snort.conf configuration in which all rules
are gathered in one file. The address belongs to machine A, the
target of the Snot attack. As such, machine
A operating as a Snort sensor continues to
see only regular traffic and not a surplus
of false positives generated by a Snot
The second application, Fragroute,
intercepts, modifies, and rewrites egress
traffic to a given host. It complicates
normal traffic to such a degree that an IDS
does not know what to do with certain
packets. It features a simple ruleset
language to delay, duplicate, drop,
fragment, overlap, print, reorder, segment,
source-route, or otherwise monkey with
all outbound packets destined for a target
host, with minimal support for randomized
or probabilistic behavior, unlike Snot,
which attempts to randomize the inserted
rules. According to the author, Dug Song,
this tool was written in good faith to aid in
the testing of network intrusion detection
systems, firewalls, and basic TCP/IP
stack behavior. He, as well as many
others, asks that security administrators
not abuse this software. It is provided for
testing local network security.
The Fragroute application does require
additional libraries, specifically the
libevent file. This library is also
available for download from Dug Song's
site. Once installed, the fragroute
application is then compiled. The binary
is placed in the /usr/local/sbin/ along
with Firewalk and the Nessus daemon.
The fragroute program uses the following
syntax for execution:
# /usr/local/sbin/fragroute -f <fil
Replace the <file> variable with a
snort.rules file and the <destination>
variable with a valid IP address,
preferably one associated with an IDS
monitoring box. There are additional
variables that randomize the rules, change
the TCP packet size, and set other options.
Familiarize yourself with this
application's use on a test machine before
attempting to use it on a production IDS
box. The last thing you want to do is bring
down an operating IDS and blind yourself
to real attacks.
Snort can also detect these types of
attacks. There is a default fragroute rule
included with the standard Snort rules.
Here is a sample alert generated by a
fragroute attack:
alert ip any any -> a
trojan connection attempt"; referen
With the current version of Snort, most of
these IDS evasion techniques can be
detected and countered. Like most aspects
of network security, it is a case of the
attackers developing new methods and the
defenders developing new
countermeasures against the attacks. Once
these countermeasures become accepted
practice, the attackers develop counter-
countermeasures, ad infinitum.
4.5 Sites of Interest
Broadband Reports
DoS Help
ID Serve
IP Calculator / IP
ISECOM Security
John the Ripper
L0phtCrack LC4
GNU Netcat
The Packetfactory
Tenable Security
Razor Security
Reverse WWW
Sam Spade
SSL Proxy
Chapter 5. The
snort.conf File
In Chapter 3, we took a (very) quick look
at running Snort in alert mode (NIDS
mode). When you changed the line in the
snort.conf file that specified what path
contained the rule files, you probably
noticed that it is not a small file. There are
a lot of settings in it and a newer version
of Snort may include changes that can
confuse even experts.
The snort.conf file controls everything
about what Snort watches, how it defends
itself from attack, what rules it uses to find
malicious traffic, and even how it watches
for potentially dangerous traffic that isn't
defined by a signature. A thorough
understanding of what is in this file and
how to configure it is essential to a
successful deployment of Snort as an IDS
in your environment.
Take your time with this chapter. It might
be useful to have the file in front of
you​either on your computer or printed out.
Make a copy of the default snort.conf file
(found in the same directory you untared
the rules in) so that you can go back to the
default settings if you make a mistake or
just want to start over. It is important to
know that the settings in this file change as
Snort changes​new features will be
developed that need to be configured. If
you move to a different version of Snort,
examine the new snort.conf to make sure
things haven't drastically changed.
Several of the options have suggested
configurations that should work in most
environments. The configurations attempt
to reasonably compromise on sensitivity,
false positive generation, and system load.
The file is organized into several sections
(and consists mostly of comments and
instructions to remind you of the some of
the options available for the different
configuration items):
Network and configuration variables
Snort decoder and detection engine
Preprocessor configurations
Output configurations
File inclusions
5.1 Network and
Configuration Variables
The first section of the file is devoted to
recording some configuration information.
Most of these variables are used by the
Snort rules to determine the function of
some systems and the location of others.
The variables map out the layout of your
environment so that Snort can make
educated decisions about which events
deserve an alert. The variables are
looking for either IP addresses (one or
several) or specific TCP ports on which a
service is listening.
By default, the variables are declared
with the value any. This matches any IP
address. While this value works, it may
cause a large number of false positive
To specify a single address, simply enter
the IP address:
You can also specify multiple addresses.
Enclose the group of addresses in square
brackets and separate them with commas
(no spaces):
var HOME_NET [,192.168.1
You also have the ability to specify an
entire RFC 1918 address space (CIDR
blocks). This method specifies the number
of bits in the subnet mask. To specify a subnet mask (24 bits of
subnet), use a "/24":
You can mix and match specific IP
addresses with the RFC 1918 subnet
designations: square brackets, commas,
and no spaces:
var HOME_NET [,172.16.0
Here's where it gets fun. You can use a "!"
as a NOT. For example, if you have a
range of addresses specified for your
home network, you can designate all
addresses that are not in that range as the
external networks. Note that when setting
the variables, you just use the variable
name. When you are actually using the
variable, you have to put a "$" before the
variable name. The following example
sets the EXTERNAL_NET variable to be
all addresses that are not contained in the
HOME_NET variable:
The "!" (NOT) directive indicates the
inverse of what follows. This can get
you into trouble if you are saying NOT
for a variable that is set to any. The
opposite of any is none. You would
match no addresses in this case. Do
not use this to say, for instance, that
you do not have internal SMTP
servers. Try to enumerate the SMTP
servers that your internal systems
utilize​or keep it any, since you will still
want to watch for attacks sourced
from inside your network against
external SMTP servers. Setting this
variable to "not any" may prevent
those rules from doing their work.
Some of the variables are looking for port
numbers instead of IP addresses. Snort
currently does not support listing multiple,
nonsequential ports. This functionality is
planned for future versions. Right now,
we can designate a single port, a
contiguous range of ports, or the inverse
of a port (using the "!" directive).
Suggested settings are given below, in the
description for the different variables.
To designate a single port:
To designate a range of ports (in this case,
ports 8000 through 8080 inclusive):
We could also designate all ports up to a
port (here we're saying all ports up to port
To designate all ports that are not 80:
5.1.1 Default Variables from
The default variables from snort.conf are:
Use this to specify the IP addresses
of the systems you are protecting.
If you specify IP addresses in
HOME_NET, it's usually a good idea
to use the "!" operator to specify
everything that is not your internal
network as the external network.
Let's look at a rule that uses the
variables. While we will go into a lot of
detail on how rules are constructed in
Chapter 7, we can get a preview by
looking at this rule from the
attack_responses.rules rule set. This rule
looks for the content "Volume Serial
Number" in a packet coming from the
internal network ($HOME_NET) and
going to the external network
($EXTERNAL_NET) as part of an
established TCP session. Finding
"Volume Serial Number" indicates
someone getting a command-line directory
listing of a Windows system, which
usually indicates a response to a
successful attack.
alert tcp $HOME_NET any -> $EXTERNA
listing"; content: "Volume Serial N
There are many rules designed to watch
specific services in your environment.
Variables tell Snort where to expect to
find the services. Setting specific
addresses for these servers goes a long
way towards reducing the number of false
positives that Snort generates. Sometimes
the servers you are enumerating are not on
your network. For example, you may not
have internal DNS servers. In that case,
include the DNS server that your internal
systems use on the Internet. The variables
used to define the servers running services
that have specific rules are:
Here is another rule from the
attack_responses.rules rule set (my
favorite batch of rules). It watches for the
content "Command completed" traveling
from the designated web servers to the
outside network from the designated web
server ports (as part of an established
TCP session).
command completed"; content:"Comman
server,established; classtype:bad-u
Port 80 is the default HTTP port.
Specifying port 443 (HTTPS) does
you little good since traffic on this
port is encrypted and triggers a
signature match. Chapter 6 discusses
strategies that may allow you to
watch this traffic.
Commonly set to !80 (any port
besides port 80). You can, in most
cases, leave this alone.
Specifies the port that Oracle is
listening on. By default, Oracle
listens on port 1521. If you have
changed this port, change the setting
These variables are looking for port
numbers instead of IP addresses.
Specifying ports here goes even further to
targeting your rules more accurately (by
reducing false positives).
The AIM_SERVERS variable is
used by rules that watch peer-to-peer
and instant messenger traffic. It is
already configured with the latest list
of AOL Instant Messenger server
addresses. This list changes from
time to time. The latest snort.conf
included with the latest rules will
have the latest list.
This variable needs to be set
properly or Snort will not start. It
should point to the location of the
rules sets in your filesystem. This
path can also be relative to where
Snort is running from, which can be
helpful if the same configuration file
might be used on different systems
with different directory structures. If
the rules are located in
set the variable like this:
var RULE_PATH /var/local/share/
5.2 Snort Decoder and
Detection Engine
The Snort decoder watches the structure
of network packets to make sure they are
constructed according to specification. If a
packet has a strange size, strangely set
options, or uncommon settings, Snort will
generate an alert. If you are not concerned
about these alerts or you find a large
number of false positives, you can disable
alerts generated by the Snort decoder. By
default, all such alerts are enabled. To
disable a particular type of alert, remove
the comment character (#) at the beginning
of the line. The Snort decoder
configuration options are:
# config disable_decode_alerts
# config disable_tcpopt_experimenta
# config disable_tcpopt_obsolete_al
# config disable_tcpopt_ttcp_alerts
# config disable_tcpopt_alerts
# config disable_ipopt_alerts
By default, the Snort decoder alerts on the
use of some of the uncommon TCP option
settings. Since it is rare to see them in a
normal network conversation, it is
assumed that their presence indicates
nefarious activity. This may not be the
case. The negative logic is a little weird,
but if you want to disable the alerts
generated by the decoder when it comes
across one of these TCP options, remove
the "#" character from the beginning of
appropriate line.
The option that may not seem familiar is
the disable_tcpopt_ttcp_alerts
option. If you use T/TCP in your
environment (a hybrid transaction
protocol between TCP and UDP in
function and used to facilitate web
transactions​see RFC 1644 for details),
you will want to disable alerts when Snort
sees these options being used.
Please note that you can also insert many
of the Snort command-line options in this
portion of the snort.conf file, too. Table
5-1 shows some of these options.
Table 5-1. snort.conf configure options
config order: [pass,
alert, log,
activation, or
Change the order that rules
are evaluated.
config alertfile:
Set the alerts output file.
config decode_arp
Turn on arp decoding (snort
config dump_chars_only Turn on character dumps
(snort -C).
config dump_payload
Dump application layer
information(snort -d).
config decode_data_link
Decode Layer2 headers
(snort -e).
config bpf_file: filters.bpf
Specify BPF filters (snort F).
config set_gid: 30
Change to GID to specified
GID (snort -g).
config daemon
Run Snort in daemon mode
(snort -D).
config interface:
Set the network interface
<interface name>
(snort -i).
Append interface name to
alert_with_interface_name alert (snort -I).
config logdir: /var/log/snort
Set the logging directory
(snort -l).
config umask: <umask>
Set umask when running
(snort -m).
config pkt_count: N
Exit after N packets (snort
config nolog
Disable logging. Note: alerts
still occur (snort -N).
config obfuscate
Obfuscate IP addresses
(snort -O).
config no_promisc
Disable promiscuous mode
(snort -p).
config quiet
Disable banner and status
reports (snort -q).
config chroot: /home/snort
Chroot to specified directory
(snort -t).
Types of packets to
config checksum_mode : calculate checksums.
Values: none, noip, notcp,
noicmp, noudp, or all.
config set_uid: <id>
Set UID to <id> (snort -u).
config utc
Use UTC instead of local
time for timestamps (snort
config verbose
Use Verbose logging to
stdout (snort -v.)
Dump raw packet starting at
link layer (snort -X ).
config show_year
Show year in timestamps
(snort -y).
5.3 Preprocessor
The Snort preprocessors have changed a
lot in recent versions. Old, standby
preprocessors (like portscan2) are gone,
replaced with new methods born out of
development work by the open source
community and the commercial
incarnation of Snort from Sourcefire. It
seems that the code for some of these
deprecated preprocessors is still there​you
could still use some of the old
functionality if that is what you are used
to. We won't talk about it here, however.
The preprocessors serve a few purposes.
They normalize traffic for a variety of
services, ensuring that the data in the
packets Snort is watching will have the
best chance of being in a format that the
signatures will recognize. Another
function of the preprocessors is selfdefense. A variety of attacks have been
developed that are designed to confuse or
overwhelm an NIDS sensor, so an attacker
can do her work unnoticed. The frag2 and
stream4 preprocessors are primarily
defense mechanisms.
The final benefit provided by the
preprocessors is that they extend Snort's
ability to detect network anomalies that
may be signs of intrusion​not just notice
things that are contained in the rule sets.
Apart from just the raw performance that
Snort offers, the preprocessors serve to
differentiate Snort from other NIDS
solutions on the market today.
5.3.1 flow
The flow preprocessor is going to be the
central storehouse for state keeping in
Snort. Right now, there is only one module
for flow: flow-portscan (see below). flow
watches all traffic and keeps track of
connections between unique systems and
between unique ports. When a new unique
flow is detected, the information is
converted to a hash (smaller and faster to
keep track of than tracking IP addresses
and port numbers) that is stored in a
memory-resident table.
The options for the flow preprocessor are:
You can specify a cap for the
memory allocated for flow tracking.
By default, flow uses about 10
megabytes of memory. For most
applications this is more than enough.
If you start noticing dropped packets
in the statistic summary when Snort
is terminated, or low memory
problems on the Snort system itself,
you can reduce this number.
You can specify the number of rows
in the hash table (the number of
unique flows). By default, this is set
to 4,099 rows, which should be
You can dump the statistics of the
flow preprocessor to stdout. Its value
is an integer that represents the time
(in seconds) between dumps. This is
useful for testing purposes, but can
be disabled by supplying 0 as the
value. This information is dumped at
shutdown, in any case.
The method used for hashing the
information in the table. Can be set to
1 for "hash by byte" or 2 for "hash by
integer." Use 2​it's much faster.
Here's a recommended configuration for
preprocessor flow: stats_interval 0
5.3.2 frag2
When a packet is travelling from one
network to another, it occasionally needs
to be broken (fragmented) into a series of
smaller packets, because the second
network has a limit on packet size that's
smaller than the first network. The pieces
are reassembled when they reach their
destination. A number of network attacks
have been based on using very small
packets to sneak past firewalls or
intrusion detection systems. For example,
consider a Snort rule that is looking for
the string /users.pwd in the data section of
a packet. An attacker might create a
fragmented sequence of small packets in
which each fragment only contains a few
bytes of data: the first fragment might
contain /user, and the second might
contain s.pwd. These packets won't trigger
alert by themselves, because they don't
match the rule. The frag2 preprocessor, by
reassembling the fragments into a whole,
allows snort to see the "big picture" and
detect the string /users.pwd.
An attacker can also use fragmentation to
cause problems. Some devices do not
handle fragmented packets well and can
crash as a result. Too many very small
packets can cause resource starvation on a
system and overlapping packets can
confuse others. There's an attack tool
called Fragroute that fragments a network
stream (discussed in Chapter 4). frag2 has
several options that defend against these
The placement of the Snort sensor has a
bearing on whether or not to use the frag2
preprocessor. Some network devices
perform fragment reassembly before
passing the traffic on. The Cisco PIX
firewall is one such device. If the Snort
sensor is behind one of these devices, the
frag2 preprocessor has almost nothing to
do and can likely be disabled altogether,
freeing up the resources for other
frag2 has several options:
The number of seconds before an
inactive session is flushed from
memory. It defaults to 60 seconds.
The number of bytes of memory to set
aside. The default of 4 Megabytes
(4,194,304 bytes) is plenty for most
Turns on alerts for some unnatural
Turns on alerts for some unnatural
fragmentation conditions (like
overlapping fragments). Since such
conditions are very often sign of
malicious activity, this should be
enabled for most environments.
Sets the minimum time to live (ttl)
accepted by the preprocessor. Set to
0 by default.
Sets the maximum variance of ttl
between packets of a network stream.
This should not vary too much and a
wide variance may be a sign of
nefarious activity on the network.
Defaults to a value of 5.
Here's a recommended configuration for
frag2. It's very simple. Because no options
are used, the colon can be omitted:
preprocessor frag2
5.3.3 stream4
stream4 was initially written to protect
Snort from a new class of attacks that
attacked an environment's NIDS sensors
by overwhelming them with packets
containing strings likely to trigger alerts.
These attacks came to light with the
release of two tools called stick and snot,
previously mentioned in our discussion of
IDS evasion techniques (Chapter 4). Stick
actually uses the Snort rules to create
packets that match the characteristics that
Snort is watching for (it will also
probably generate alerts for other IDS
solutions), thus flooding it with alerts.
Since a network conversation (at least a
TCP session) is started by a three-way
handshake with a server, if there was a
way to track the active conversations that
were set up correctly, it would be
possible to eliminate these stick packets
since they are not part of an active
stream4 has two goals: stateful inspection
and awareness and session reassembly.
Session reassembly is handled by the
stream4_reassemble preprocessor. For
accurate function of stream4,
stream4_reassemble should be enabled.
Along with providing a defense against
tools such as stick and snot, tracking the
state of a network conversation provides
additional benefit. We will discuss this in
much more detail in Chapter 7, but
stream4 gives us the ability to build rules
that watch a particular side of a
conversation using the flow keyword (not
to be confused with the flow
preprocessor). This helps reduce false
positives. To activate this stateful
inspection by rules, use the -z option at
the command line. It used to be necessary
to use -z est to enable this, but the "est"
is deprecated and no longer needed (in
fact, it causes an error).
The default settings for stream4 do a
decent job, but consider tuning things
further to suit your environment (and to
further reduce false positives). The
options for the stream4 preprocessor are:
Disabled by default. This directive
tells stream4 to generate an alert
when a portscan is detected. stream4
detects portscans that use
nonstandard methods to identify
listening ports. For instance, if a
packet is sent to a port on a host with
the FIN flag set, the host responds
with a RST packet if the port is
closed and replies with nothing if the
port is open and listening. These are
referred to as stealth scans and can
take a variety of forms. Include this
parameter if you are interested in
detecting stealth scans.
Disabled by default. This generates
an alert when a problem with the
state of a conversation is detected.
This option generates a large number
of alerts and generally remains
disabled in most environments.
Networks with Windows systems
generate a large number of these
alerts. High-latency environments
experience a large number of false
positives, since a system that
transmits packets after an ACK is
sent causes alerts to be generated.
Disabled by default, too. If enabled,
Disabled by default, too. If enabled,
this option may detect attackers
trying to confuse the IDS by sending
retransmissions of packets, thinking
that the second one would make it
through. It is also possible to send a
data payload with a SYN packet.
Since a SYN packet is often used to
initiate a TCP connection, it does not
carry a data payload by design.
Generally, it is best to keep this
option enabled.
Sets a minimum time to live (ttl)
setting for packets accepted into the
stream4 preprocessor. Some attacks
may have an artificially low ttl so
that they make it to the IDS
(overwhelming it), while the packet
does not make it to the actual server.
This situation is fairly rare, and it's
usually acceptable not to set a value
for this option. This option defaults
to 1.
Sets the maximum amount the time to
live setting can vary in a network
conversation. Every time a packet
travels through a router, the ttl setting
is decremented by one. During a
network conversation, the packets
traveling between the two hosts
follow generally the same path
across the network and the ttl should
be fairly constant in each direction. If
an attacker is trying to insert packets
into a network conversation, the ttl
may change, indicating an attack is
underway. Since routing is dynamic
(thus, a change in ttl might not be
something nefarious), it is difficult to
decide on a value for this option (a
flapping route might cause false
positive alerts, too). Most sources
indicate that a value between 10 and
15 is reasonable. This option
defaults to 5.
keepstats [machine, binary]
Disabled by default. If enabled, it
outputs statistics on each session
tracked in one of two modes:
machine dumps to a text file; binary
outputs a unified binary format
useable by tools like Barnyard.
Normally defaults to off. Tells
stream4 to disable stateful inspection
of all packets that are destined for
ports not included in the
stream4_reassemble's ports option.
(See Section 5.3.4 below for details
on the ports option). You might not
be concerned with traffic destined
for ports that you are not listening on.
In general, you can leave this option
Normally, when a TCP connection is
torn down, it is pruned from the
session table. If the connection is not
torn down or is improperly torn
down, this timeout setting prunes the
session from the table after an
indicated period of time has passed
without activity. Essentially, it acts
as an idle timer. This option defaults
to a value of 30 seconds​kind of short,
for most environments. Since the
memory requirements are fairly low
(on the order of a few kilobytes) for
the session table, setting this to 60
seconds is not a bad idea.
If a packet in a monitored stream
causes an alert, you can dump the
session information from stream4 to
disk. This only works if you are
logging in pcap mode. This option
does carry some overhead and is not
commonly enabled. The packet logs
it generates are difficult to work
This looks for a number of bytes sets
a limit on the amount of memory
allocated to stream4. Normally, the
default value works fine, but if you
have the memory or are operating in
an enterprise-class environment with
a dedicated sensor, you could ratchet
this value up. Keep in mind that the
option is looking for a number of
bytes, not Megabytes. This option
defaults to 8 Megabytes (8,388,608
Here's a suggested setting for stream4:
preprocessor stream4: detect scans,
5.3.4 stream4_reassemble
Snort relies on being able to match strings
of characters in a network packet to a
string of characters in a signature. If an
attacker could split the characters that
would normally match the signature across
multiple packets, Snort may not trigger an
alert​much like what happens with
fragmented packets. stream4_reassemble
acts to reassemble network traffic that is
part of a stream of conversation between
two systems, increasing the chance of
matching a signature.
Network conversations between highly
interactive services (very often commandline services like Telnet, FTP, and SMTP)
can cause content to be spread across
multiple packets in the same way.
Reassembly of traffic generated by these
services is essential to prevent missed
alerts (false negatives).
Another attack IDS evasion technique is to
inject packets in the middle of an attack
with characteristics (like invalid
checksums) that cause the injected packets
to be dropped by the target system.
stream4_reassemble looks past these
injected packets, finding the attack
signature in the traffic stream.
There are a number of options for the
stream4_reassemble preprocessor:
Only performs reassembly on the
client side of the conversation
stream. If your sensor is having
performance issues, you might want
to watch only one side​perhaps you
are watching an internal network that
contains only clients and does not
offer services to the public Internet.
In this case, you may want to enable
the clientonly option. This option
is enabled by default.
Only performs reassembly on the
server side of the conversation
stream. If your sensor is having
performance issues, you might want
to only watch the one side. If your
internal network only contains server
systems offering services to the
Internet, you might want to enable the
serveronly option.
Performs reassembly on both sides of
the conversation. If your Snort sensor
is watching both clients and servers,
you might want to enable this option.
Reassembly is performed, but alerts
are not generated for reassembly
attacks and evasions. Unless you are
seeing a large number of false
positives, do not disable alerts for
ports [ list]
Specifies a list of ports that are
reassembled. This greatly limits the
overhead of performing this task and
normalizes traffic on services that
often have their content spread
across multiple packets. The ports
are simply typed out with a space
between them (for example: 21 22 23
25 110 143 1433). By default the
ports that are reassembled are 21,
23, 25, 53, 80, 110, 111,143, 513,
and 1433.
Here's a suggested setting for
preprocessor stream4_reassemble: bo
5.3.5 HTTP Inspect
There are a wide variety of ways that
information can formatted in an HTTP
session. There are also a very large
number of different types on information
that can be a part of an HTTP session
(multimedia, .xml, .HTML, .asp, .php,
.java, and so on). As a result, Snort must
"massage" the content of HTTP
conversations so that the data is in a
format that has the best chance of being
matched to the signatures. The
http_inspect preprocessor performs this
task (http_inspect takes the place of
http_decode, found in previous versions
of Snort).
There are two types of http_inspect
configuration: global and server. The
global configuration makes changes that
affect all HTTP traffic. The server
configuration contains settings for a single
server or a group of similar servers. Since
the different web servers encode things
and operate in different ways, you can
configure the http_inspect_server
preprocessor to suit the needs of
particular types of web servers​most
commonly, Microsoft Internet Information
Server (IIS) or Apache.
Note that you can only have one
configuration line for http_inspect (which
is the global setting), but you can have
multiple http_inspect_server lines. It is
also important to be aware that
http_inspect is not aware of the state of a
packet it is examining. It relies on other
preprocessors to handle reassembly of
traffic. Rumor has it that stateful
inspection will be added in the future. http_inspect (global)
This preprocessor contains settings that
affect the inspection of all HTTP traffic.
The global http_inspect preprocessor has
three options:
iis_unicode_map < filename> [codemap
< integer>]
This option is actually not optional. It
needs to be included or an error
results. By default, the location of the
map file (called is
included with the rules you
downloaded and extracted. It tells the
preprocessor how to map Unicode
characters into ASCII text that can be
matched to the signatures. You must
specify the normal code map to use
(1252 is the ANSI- Latin I code map
that is used in English).
Generates an alert if standard HTTP
traffic is detected on nonstandard
ports. Since many devices and
services offer a web-based interface
on potentially nonstandard ports, this
can be a source of numerous false
positives. This is not commonly
If you are using a proxy server to
regulate your Internet users, this
option generates alerts for users that
are not using the proxy. It does not
detect blind firewall proxies,
however. If you don't use a proxy
server in your environment (or are
confident that people can't get around
your proxy), this has the potential of
generating a very large number of
false positives.
Here's a suggested setting for http_inspect
preprocessor http_inspect: global i http_inspect_server
http_inspect_server is the server
configuration portion of the http_inspect
preprocessor. You can specify settings for
the specific type of server or servers in
your environment. Most administrators
have a server configuration for their IIS
servers and another for their Apache
servers. At the end of this section, I will
include a sample of each.
There are many options for this
preprocessor and at first it can seem
overwhelming. Start with the suggested
settings and modify them as you see them
in action. Setting an option to "no"
prevents that option from generating
alerts, but doesn't disable the option​the
processing still takes place. There are two
types of http_inspect_server
configurations: "default" and "by IP
address." The "default" configuration
configures the inspection of all web traffic
that is not associated with a specifically
configured IP address. The "by IP
address" configuration specifies the
settings for a specific IP address or range
of addresses. The options for the
http_inspect_server preprocessor are:
default or < IP address>
Supply either the word "default" or
an IP address (or CIDR block of
profile <all|apache|iis>
Since there are so many settings, you
can choose a preconfigured set of
options by selecting apache or iis.
Select all to make a custom
configuration. Choose all for the
default configuration and select iis
or apache for specific servers or
groups of servers. If a profile is
used, you cannot change the settings
that are part of the profile. This
leaves only four settings available
for you to change: ports,
allow_proxy_use, and
flow_depth.The settings configured
by the three profile options are
shown in Table 5-2, Table 5-3, and
Table 5-4.
Table 5-2. Settings for profile "all"
Alert on chunks larger than 500,000
The map used in the global
apache_whitespace Yes
Table 5-3. Settings for profile "apache"
Alert on chunks larger than 500,000
apache_whitespace Yes
Table 5-4. Settings for profile "iis"
The map used inthe global
apache_whitespace Yes
ports {< port list>}
Lists the ports (separated by spaces
and contained in the curly brackets)
on which HTTP services are offered.
iis_unicode_map < filename> [codemap
< integer>]
Identical to the configuration for the
global configuration. It's actually not
optional; it needs to be included or
an error results. By default, the
location of the map file (called is included with the
rules you downloaded and extracted.
It tells the preprocessor how to map
Unicode characters into ASCII text
that can be matched to the signatures.
You must specify the normal code
map you will use (1252 is the ANSILatin I code map that is used in
flow_depth < integer>
Since most signatures alert in the first
150-300 bytes of an HTTP packet's
payload, we don't need to look past
that point. This greatly reduces the
overhead of http_inspect.
ascii <yes/no>
It is normal to see ASCII encoding in
URLs. Disabling alerting is
recommended on this option.
utf_8 <yes/no>
Apache uses UTF-8 encoding as a
part of normal operation. It is usually
best to disable alerts on the presence
of UTF-8 encoding.
u_encode <yes/no>
Since there aren't any known web
clients that use this method of
encoding, it is best to enable alerting
when this encoding is detected.
bare_byte <yes/no>
This is a tricky way to identify IIS
servers by how they react to a
particular set of non-ASCII
characters used in UTF-8 encoding.
The short story is that no legitimate
clients use this encoding and alerting
should be enabled.
base36 <yes/no>
Enables the decode of base_36
characters. Commonly left off.
iis_unicode <yes/no>
Unicode traffic usually indicates an
attempted attack and alerting should
be enabled.
double_decode <yes/no>
Alerts on an IIS attack trick that
encodes Unicode with Unicode,
tricking the web server into doing
bad things. Alerting should be
enabled since this is always naughty
non_rfc_char {< list of bytes>}
This option allows you to alert on
certain non-RFC character
(designated as a list of spacedelimited bytes contained in curly
brackets). Be careful. If you specify a
commonly used character, you could
end up generating a large number of
false positives.
multi_slash <yes/no>
Some web servers allow malicious
activity if a URL is obfuscated by
including multiple directory slashes
in a row. This would usually indicate
a malicious request and should be
generate an alert.
iis_backslash <yes/no>
If you want an alert when a
Windows-style blackslash is used
instead of a normal foreward slash,
set this to yes. Either way,
http_inspect normalizes these
directory <yes/no>
Using strange strings of characters,
some attackers can trick a web
server into performing a directory
traversal. Characters such as "/../"
and "_/" are normalized to "/" by
http_inspect. If you want an alert for
such traversal attempts, set this to
apache_whitespace <yes/no>
Some Apache servers may be
vulnerable to the replacement of a
space with a tab character. While
enabling alerting may give you
warning of an attempted attack, it
happens often enough that you may
generate a large number of false
iis_delimeter <yes/no>
Most web servers accept this
delimiter without problem. There is
likely no need to alert on it.
chunk_length <non-zero positive integer>
Over-large chunk lengths may be a
method of attack. A setting of
500,000 bytes usually provides
adequate discrimination between
attacks and tunneling protocols that
use chunked encoding across HTTP.
Turns inspection of pipeline
encoding off. This should really only
be disabled if you are experiencing
performance problems.
Some servers allow broken URIs
(Apache, for instance). If you have
Apache servers, enable this option.
Allows proxy use on the specified
web server. This option suppresses
alerts generated by this server for
unauthorized proxy use (if enabled).
Turns off all alerts generated by
oversize_dir_length < non-zero
positive integer>
If the directory length in a URL is
If the directory length in a URL is
over the size specified, an alert is
generated. Some application servers
generate huge URLs that can be a
source of false positives. A setting of
300 should be sufficient.
If you are having performance issues,
you can limit http_inspect to
watching only the URI portion of the
HTTP request (which catches 9095% of the actual attacks).
Here's a setting for a default
http_inspect_server configuration (this
acts as a catch-all for servers not
specifically enumerated):
preprocessor http_inspect_server: s
Here's a setting for a server
http_inspect_server configuration for an
IIS server (this tunes the options to best
match the characteristics of traffic to and
from an IIS server):
preprocessor http_inspect_server: s
A sample setting for a server
http_inspect_server configuration for an
Apache server (this greatly aids accurate
alerting for Apache-based web servers):
preprocessor http_inspect_server: s
5.3.6 rpc_decode
RPC's traffic can be spread across
multiple packets and encoded in a variety
of ways. The rpc_decode preprocessor
normalizes this traffic so that it is
formatted in a consistant manner that Snort
can compare against the signature lists. A
list of ports that RPC services are running
on is provided on the configuration line.
There are four additional options for
Generates alerts for any fragmented
RPC traffic. It is likely to generate
only false positives.
Specifies that no alert be generated
when more than one RPC request is
contained in a packet. By default,
alerts are generated. Normally, it is
desirable to generate alerts when this
happens. If in the course of running
Snort you find many false positives,
you have the option of disabling
these alerts. Sometimes the
combination of stream4_reassembly
coupled with rpc_decode can be a
source of false positives.
RPC fragments can be larger than the
current fragment size. If you are
seeing false positives, you have the
option for disabling these alerts.
RPC messages can be very
large​sometimes larger than the MTU
of the network they are traversing.
This can be a cause of many false
positives for some RPC network
services. If you are seeing many false
positives, consider disabling these
Here's a suggested setting for rpc_decode:
preprocessor rpc_decode:111 32771 1
5.3.7 bo
Back Orifice was created by a cracker
organization called the Cult of the Dead
Cow (regulars at DefCon). It is used for
remote control of client systems. It is
actually very full-featured and includes
the ability encrypt the data stream. The
encryption mechanism was not the most
robust and can actually be brute-forced on
the fly by the bo preprocessor (with a
significant CPU penalty). With the now
ubiquitous presence of antivirus software
in most environments and Back Orifice on
the list of proscribed applications, it is not
nearly the problem it once was.
This preprocessor was created to watch
for Back Orifice traffic and decrypt it on
the fly. It takes no arguments. Many
administrators disable the preprocessor
altogether by commenting out the line with
a # character at the beginning of the line.
Here's a suggested setting for bo:
# preprocessor bo
5.3.8 telnet_decode
This preprocessor normalizes nonstandard
characters and session negotiation strings
in Telnet and FTP traffic. It does not
generate alerts and has no options.
Here's a suggested setting for
preprocessor telnet_decode
5.3.9 flow-portscan
This (very complicated) preprocessor is
brand new. Documentation is thin and bug
fixes are still being introduced. flowportscan relies on the flow preprocessor
being configured and operational to
function (see the description of flow,
flow-portscan takes the place of the
portscan2 and conversation
preprocessors. You might be familiar with
these (in fact, the support is still there, for
time being); but it's time to let go and
move on. flow-portscan has many
advantages over the old ways​better
performance, lower memory costs, and a
significant increase in configuration
There are three basic components of flowportscan:
There are two indices that track the
types of servers that Snort sees
transmitting on your network, called
scoreboards. They track two
different types of host, talkers and
scanners. A talker is any host that is
active on your network. A scanner is
a host that makes a connection to a
port on a server in the network you
have designated as the network
containing your servers (called the
server watch net). Not every
incoming packet is a scan, just a
potential scan.
Uniqueness tracker
Tracks if a network connection is
unique. To be unique, it must have
one of the following characteristics
different from other network traffic
already detected: source IP address,
destination IP address, IP protocol,
or destination port.
Server statistics tracker
Used to track the number of times a
particular service on a server in your
server watch net has had a
connection made to it. This hit count
is tracked by destination IP address,
destination port, and IP protocol.
This preprocessor develops a picture of
how your servers are used in the normal
course of business. Ports that are
consistently (and legitimately) used are
added to a list of ports that can be ignored
as potential portscan-generated
connections. If a server is recognized as
performing business on port 80,
connections to that port will not be tallied.
This ignore list also affects how the
scoreboards are tracked.
There are a large number of configuration
options for this preprocessor. They set
time limits on how long certain metrics
are tracked, what networks contain
servers, how much memory flow-portscan
can use, what kind and how much output
flow-portscan generates, and what
networks and hosts can be ignored either
as talkers or scanners.
Detecting stealthy portscans is very
difficult (this is the reason for the extreme
measures taken to detect them accurately).
An attacker can use a number of strategies
beyond messing with the SYN/ACK/FIN
flags. An attacker can:
Not attack ports in order
Insert varying delays between probes
for particular ports
Interleave scans for several machines
on your network
Originate the scans from thousands of
fictional addresses on his network or
different networks
All of the above
We'll look at the options available for the
flow-portscan and then see some
examples. The flow-portscan defaults are
a very good place to start. They are, for
the most part, very reasonable, and it is
likely you will never need to change them.
If you find that you are missing scans or
that you are generating too many false
positives, start tinkering. Now, on to the
scoreboard-memcap-talker < bytes>
Defaults to 24 megabytes
(25,165,824 bytes). It specifies how
much memory is used to track talkers.
scoreboard-rows-talker < count>
Defaults to 1,000,000 and specifies
the number of rows in the talker
scoreboard-rows-scanner < count>
Defaults to 250,000 and specifies the
number of rows in the scanner table.
scoreboard-memcap-scanner < bytes>
Defaults to 6 megabytes (6,291,456
bytes) and specifies how much
memory is used to track scanners.
scanner-fixed-threshold < integer>
Defaults to 15 and sets the number of
points that a scanner must accumulate
in the scanner-fixed-threshold time
scanner-sliding-threshold < integer>
Defaults to 40 and sets the number of
points that a scanner must accumulate
in the scanner-sliding-threshold time
scanner-fixed-window < integer>
Defaults to 15 and sets the number of
seconds should elapse before
resetting the fixed scanner score.
scanner-sliding-window < integer>
Defaults to 30 and sets the number of
Defaults to 30 and sets the number of
seconds that should elapse before
resetting the sliding scanner score.
scanner-sliding-scale-factor < float>
Defaults to 0.5 and specifies the
factor by which the sliding window
should be increased when a new
sliding scanner entry is made.
talker-fixed-threshold < integer>
Defaults to 15 and sets the number of
points that a scanner must accumulate
in the talker-fixed-threshold time
talker-sliding-threshold < integer>
Defaults to 30 and sets the number of
points that a scanner must accumulate
in the talker-sliding-threshold time
talker-fixed-window < integer>
Defaults to 30 and sets the number of
seconds should elapse before
resetting the fixed talker score.
talker-sliding-window < integer>
Defaults to 30 and sets the number of
seconds that should elapse before
resetting the sliding talker score.
talker-sliding-scale-factor < float>
Defaults to 0.5 and specifies the
factor by which the sliding window
should be increased when a new
sliding talker entry is made.
unique-memcap < bytes>
Defaults to 24 megabytes
(25,165,824 bytes). It specifies how
much memory is used to track
unique-rows < integer>
Defaults to 1,000,000 and specifies
how many rows to have in the
uniqueness tracking table.
server-memcap < bytes>
Defaults to 2 megabytes (2,097,152
Defaults to 2 megabytes (2,097,152
bytes). It specifies how much
memory is used to track servers.
server-rows < integer>
Defaults to 65,536 and specifies how
many rows to have in the server
tracking table.
server-watchnet < ip list in Snort
Specifies a list of IP addresses using
the same format as that used when
configuring variables, above (the
HOME_NET variable, for example).
It should specify where servers that
offer services to the external
networks reside. This helps map how
your servers are used and allow
Snort to only alert on anomalous
activity. Increases the accuracy of
flow-portscan significantly.
src-ignore-net < ip list in Snort
Uses the same IP address list format
as server-watchnet, but specifies a
range of addresses that flow-portscan
can ignore as source addresses.
dst-ignore-net < ip list in Snort
Uses the same IP address list format
as server-watchnet, but specifies a
range of addresses that flow-portscan
can ignore as destination addresses.
tcp-penalties <on|off>
Defaults to on and when enabled,
allowing flow-portscan to give
strange TCP flag settings additional
weight on the scoreboard. For
example, if the SYN and FIN flags
are both set in a packet, this counts as
three points on the scoreboard since
it is almost always someone trying to
be cute with a portscan.
server-learning-time < seconds>
Defaults to 28,800 and is the amount
of time that flow-portscan keeps the
counters for server port activity.
server-ignore-limit < hit count>
Defaults to 500 and specifies how
many legitimate connections to a
service flow-portscan must see
before ignoring it as a possible
server-scanner-limit < hit count>
Defaults to 500 and specifies how
many requests on a port on an IP
address in the server-watchnet flowportscan must see before labeling it
as a talker.
alert-mode <once|all>
Defaults to once and triggers either a
single alert for a detected portscan or
for each time a packet goes past
thresholds. You are strongly advised
to use once here. all is
tremendously noisy.
output-mode <msg|pktkludge>
Defaults to msg and specifies how
flow-portscan outputs its
information. msg generates a variable
text message with appropriate scores
included. pktkludge generates a
fake packet and use the logging
output system. This generates some
strange data in the output mechanism.
msg is preferable in most
base-score < integer>
Set to 1 by default. The only real
reason to change this value is for
debugging changes to settings. Keep
it set to 1.
dumpall <1>
If you specify this option (with the
value 1), Snort dumps the contents of
the server and uniqueness tables
when it exits, as well as the
scoreboards. This might be
interesting when tinkering with
settings, but generally is not that
Here is a sample configuration for flowportscan (remember that the flow
preprocessor must be configured and
running for flow-portscan to work):
preprocessor flow-portscan: server-
5.3.10 arpspoof
arpspoof is an experimental preprocessor
designed to detect nefarious activity on the
local network. It watches for the signs of
someone using a tool such as Ettercap or
arpspoof that fools two hosts into letting a
host perform man-in-the-middle attacks on
a conversation between them. It is
disabled by default. If the Snort sensor is
not on the same local network as the hosts
it is protecting (there's a routing device
between them), then having this enabled
provides no value and only generates false
positives and consumes resources. This
preprocessor requires the administrator to
enter a static list of IP addresses and their
proper MAC addresses​the very definition
of labor intensive and administrative
overhead. It makes Snort a nice tool for
rooting out suspected network attacks in
progress, but the return is not worth the
labor involved in configuring the arpspoof
preprocessor (a capable network engineer
can get this information from a network
devices's logs much easier).
Here's a suggessted setting for arpspoof:
# preprocessor arpspoof
# preprocessor arpspoof_detect_host
5.3.11 perfmonitor
One of the more highly touted features of
the latest Snort is its ability to monitor its
own operational status. perfmonitor
measures Snort's real-time and theoretical
maximum performance. When this
preprocessor is turned on, it should also
have an output mode enabled. This is
either "console", which prints statistics to
the console window, or "file", where the
data is stored to a specified filename. The
default statistics that are processed are
real-time variables of Snort's
performance. These include the following
Packets received
Packets dropped
Percentage of packets dropped
Packets Received
Kpackets per second
Average bytes per packets
Mbits per second (wire)
Mbits per second (rebuilt) (average
Mbits Snort injects after rebuilding
Mbits per second (total)
Pattern-matching percent (average
percent of data received that Snort
in pattern matching)
CPU usage (user time, system time,
idle time)
Alerts per second
SYN packets per second
SYN/ACK packet per second
New sessions per second
Deleted sessions per second
Total sessions
Max sessions during time interval
Stream flushes per second
Stream faults per second
Stream timeouts
Frag completes per second
Frag inserts per second
Frag deletes per second
Frag flushes per second
Frag timeouts
Frag faults
When the keyword "flow" is enabled, it
prints out the statistics regarding the type
of traffic and protocol distributions seen
by Snort. The keyword "events" turns on
event reporting and prints statistics about
the number of signatures matched by the
setwise pattern matcher and the number of
those matches that were verified with the
signature flags. These are called
nonqualified and qualified events. It
shows if there is a problem with the user's
rule set.
The keyword "max" turns on the
theoretical maximum performance that
Snort calculates given the processor speed
and current performance. This is only
valid for uniprocessor machines, since
many operating systems don't keep
accurate kernel statistics for multiple
CPUs. The keyword "pktcnt" adjusts the
number of packets to process before
checking for the time sample. This boosts
performance since checking the time
sample reduces Snort's effectiveness. By
default, this level is set at 10,000.
Here are some examples of how to
configure and enable the perfmonitor
preprocessor perfmonitor: time 30 e
console pktcnt 10000
preprocessor perfmonitor: time 300
5.4 Output Configurations
One of Snort's real strengths are the
options available for output of alerts and
other detection information. While running
tail -f on the alert file in /var/log/snort
certainly lets you see that alerts that Snort
generates, using that information
effectively requires more horsepower.
Many Snort administrators use third-party
applications to monitor and investigate the
information generated by Snort. To do
this, Snort must output the data a particular
format. The output plug-ins perform this
task. Note that using some of these plugins require the administrator to take some
steps at the time that Snort is compiled.
For example, to allow Snort to output to a
MySQL database, a MySQL client needs
to be installed on the Snort system and the
--with-mysql option must be specified
with the ../configure command. Some
of these options are only available on a
particular platform. For instance, only a
Windows system can log directly to
Microsoft SQL Server with the mssql
plug-in (Unix-based systems must use
ODBC with the odbc plug-in).
Multiple output plug-ins can be enabled,
allowing a variety of tools to be employed
by Snort administrators.
5.4.1 alert_syslog
Unix-based systems use the syslog facility
to aggregate messages generated by one or
more systems into a single place. There
are a number of different ways that the
Snort-generated information can be
presented to the syslog. You can specify
the facility used by Snort and also the
priority assigned to entries generated by
The format of the this plug-in is:
Output alert_syslog:
<facility> <Priority>
The facility option specifies one of the
standard syslog facilities and defaults to
The priority option also specifies one of
the syslog standard priorities and defaults
Here's a sample configuration for the
alert_syslog output plug-in:
output alert_syslog: LOG_AUTH LOG_A
Windows systems have the option of
specifying a particular host in the config
file (a Unix-based system can be
configured at the operating system level to
send a particular facility to a separate
syslog server). To do this, specify a host
and a port number in the following format
(port number is optional):
Host=<host IP address>:<port
Here's an example of a Windows version
of this output plug in's configuration:
output alert_syslog: host=10.10.10.
5.4.2 log_tcpdump
This logs packets to the tcpdump file
format. There are a variety of applications
that can read this format. The only option
for this output plug in is the filename in
which the information is written. A
timestamp is prepended to the filename.
Here's a sample configuration for the
log_tcpdump plug-in:
output log_tcpdump /var/log/snort/t
5.4.3 Database
The database plug-in allows you to write
to a variety of relational databases either
on the same system that Snort is running on
or to another host on the network. When
logging to a database, a great deal of
information is recorded​including the alert,
the hosts involved, and the actual packet
that caused the alert​making discriminating
between real alert and false positives
much easier.
Sometimes logging to a busy database
server can cause a bottleneck, since only
one alert can be logged at a time. A
dedicated, well-configured database
server helps with this problem, as well as
with tuning and thresholding effectively
(see Chapter 9). The database schema that
Snort uses can be found in Appendix A.
The argument as to which database server
is better devolves into a religious
argument quickly. Personally, I prefer
MySQL. It's open source, free (you can get
paid support, too​details at MySQL), it's
very fast, and it's very configurable. I have
extensive experience with PostgreSQL
and Microsoft SQL Server, too. Choose
whichever you're most familiar with,
since tuning the database server for
performance pays dividends.
The database output plug-in takes the
following format:
output database: <log|alert>, <data
Choose either log or alert here. log
sends log information to the
database, and alert sends the alert
stream. Note that log includes alert
information and the alert-generating
packet information. log is the option
I use most often. If you want to send
both to a database, you need two
output database lines, each
specifying one of the options.
< database type>
This is where you specify what type
of database you are logging to. Snort
supports the following settings:
mysql, postgresql, oracle, odbc,
and mssql (Windows Snort systems
When configuring the particular database
output plug-in, set the following
parameters (there are no commas in the
parameter list):
The IP address of the database
server. If left blank, it goes to the
local machine.
The port the database is listening on.
You only need to specify this if a
nonstandard port is being used.
dbname=<database name>
The type of database you are logging
to (one from the list above).
The username Snort uses to log into
the database.
The password used to log into the
A sensor name for this configuration
(optional). Otherwise, the -I option
at the command line uses the IP
address of the sensor as the name.
The encoding used for logging to the
database. You can specify hex (takes
up less space, is searchable, but not
easily read by people), base64
(smaller than plain text, not
searchable, not human readable), or
ascii (larger, searchable, humanreadable). ascii is recommended.
You can specify what detail level is
used when sending information to the
database. full will include all
information that Snort gathers,
including header and packet
information. fast is a bit faster, but
includes such a small amount of
information​really just the alert name,
source and destination addresses and
ports, and a timestamp​that forensic
analysis is very difficult. The full
option is highly recommended. MySQL
MySQL logging requires that database
support be present on the system running
Snort in the form of the MySQL client
software and libraries. At the time Snort
is installed, support for MySQL is
included by adding the --with-mysql at
configure time. Here's an example:
./configure --with-mysql PostgreSQL
PostgrSQL logging requires that database
support be present on the system running
Snort in the form of the PostgreSQL client
software and libraries. At the time Snort
is installed, support for PostgreSQL is
included by adding the --withpostgresql at configure time. Here's an
./configure --with-postresql ODBC
ODBC logging requires that database
support be present on the system running
Snort in the form of the ODBC client
software and libraries. At the time Snort
is installed, support for MySQL is
included by adding the --with-odbc at
configure time. Here's an example:
./configure --with-odbc MsSQL
This option is built-in for Windows
systems running Snort. For Unix-based
systems running Snort, ODBC is used to
log to Microsoft SQL Server. Oracle
Oracle logging requires that database
support be present on the system running
Snort in the form of the Oracle client
software and libraries. At the time Snort
is installed, support for Oracle is included
by adding the --with-oracle at
configure time. Here's an example:
./configure --with-oracle
5.4.4 unified
unified logs in the Unified Binary format.
This is a very fast, compact format for
logging designed to be used by Barnyard.
The unified format will be discussed in
Chapter 13 when strategies for highdemand environments are discussed.
5.5 File Inclusions
The final element used within a standard
snort.conf file is the include item. The
include command tells Snort to include
the information in files located in the
Snort sensor's filesystem. These files
include configuration information and the
files containing the rules that Snort uses to
catch bad guys. The default path should
have already been defined earlier in the
configuration. Use the $RULE_PATH
variable to refer to their location, or use
relative or full pathnames to refer to the
rules files you wish to use.
Multiple includes can be utilized within a
configuration, one for each rules file cited.
Consult the downloaded list of rules files
for the exact spelling of each file. Disable
any type of file by commenting out the
appropriate line.
Here is an example of the include
configurations that tell Snort which of the
rule set files to use. The line containing
the bad-traffic.rules file is commented out
with a # character that tells Snort to
exclude this file in the list of rules that
Snort uses.
# include $RULE_PATH/
include $RULE_PATH/exploit.rules
include $RULE_PATH/scan.rules
If you are using any classification and
priority settings or referencing any
systems, use the following items as well.
Make certain these files exist before
starting Snort. Default examples can be
found packaged with the rules you
downloaded and extracted. These files
help classify and prioritize the alerts
according to severity. You can edit the
classification.config file to make custom
prioritizations. You might find one group
of rules to be particularly important for
your environment and choose to make
these higher priority. Once this file is
configured according to your needs, you
use your management console to search
for high priority alerts.
The reference.config file includes links to
web sites with information for all the
alerts. It's very useful to include. Each
official rule has a great deal of
information on the Internet about the attack
the rule is attempting to attack. It can help
intrusion analysts determine if an alert is
# Include classification & priority
include classification.config
# Include reference systems
include reference.config
Chapter 6. Deploying
Deploying an NIDS presents an
administrator with some real challenges
(apart from attempting to find a rational
explanation for management on the return
on investment for a security project).
Installing and getting Snort up and running
is just the beginning. You need to figure
out what you want to watch, how you can
watch it, and how to get meaningful
information out of your effort.
Many of the obstacles to your NIDS
deployment efforts are not technical at all.
You might have to convince management
that intrusion detection has value on par
with the dollars and labor involved.
Another, sometimes unforeseen issue is
that an organization may have separate
departments for network, server, and
security administration​and communication
between the groups may be poor.
Snort makes meeting these challenges a bit
easier. Snort is free and will run on
relatively low-cost hardware (it's unreal
how inexpensive memory and disk have
become!). The initial installation and
configuration of Snort is fairly
straightforward, and you can use my
experiences and advice in this book (and
the available support of the open source
community surrounding Snort) to aid in the
ongoing maintenance and administration of
your IDS installation. While Snort won't
magically get your different departments
talking to one another, Snort sits as a
passive listener on the network, needing
little cooperation with the other
departments to get installed and running.
Once you call the server guys with
notification that they may be suffering a
security breach and it is confirmed, you
will see communication improve quickly.
Spending time and care on the installation,
initial configuration, and placement of
Snort will reduce false positives, improve
performance, and ensure that you are
watching what is important. Let's look at
the nontechnical challenges to deploying
an NIDS (Snort, specifically) and then
dive into the technical issues.
6.1 Deploy NIDS with Your
Eyes Open
While this book discusses strategies to
make the installation, configuration,
tuning, and administration of Snort as
efficient and effective as possible, it is
important to understand that running an
NIDS is not as simple as plugging it in and
watching. People often underestimate the
labor involved with the ongoing
maintenance of an NIDS (any NIDS, not
just Snort). While you can minimize their
occurrence, false positive alerts keep you
busy confirming that they are, indeed,
false. New signatures come out that detect
the latest batch of Internet worms and they
need to be reviewed, tuned, integrated,
and distributed.
One of the challenges of using an open
source application like Snort is that there
are new versions fairly regularly. These
new versions may have additional
functionality that you want to use. The
only problem is that sometimes this
functionality causes older ways of doing
things to change or be replaced (the
portscan2 and conversation preprocessors
being replaced by flow-portscan, for
example). Test new versions and functions
before upgrading. Sometimes new
functions can introduce new bugs, too.
Fortunately, open source testing of beta
versions along with the cooperation and
development done by Sourcefire (the
company that sells the commercial version
of Snort) eliminate most bugs before they
make it into production code.
None of the previous discussion even
touches on the challenges involved when
you really find evidence that you are under
attack or that you've been hacked. An
effective security manual that includes a
thorough incident response plane will pay
dividends (of course, developing the plan
takes time, too). The difficulty of getting
those Balkanized departments to work
together will certainly figure in to the fun,
All of these things can conspire to make
you a very busy administrator. Is having a
good awareness of what is going on in
your network and on your servers worth
the effort? In my experience, absolutely.
Sticking your head in the sand and being
ignorant of the harm being done to your
organization is no way to run a network.
We talked in the introduction about the
concept of defense-in-depth, where each
device on your network plays a role in its
own security and multiple strategies are
employed to make catching (and stopping)
attacks possible. An NIDS deployment
will not be the big box of security that
some people think they need to "have
security" in their organization (almost
every organization has a person with an
MBM degree​Management By Magazine).
There is no such thing as a single device
that will secure your network.
NIDS is another layer of defense. It
compliments your efforts in other areas,
catching things that your other efforts miss.
You still need to apply security patches to
your software and systems. You still need
to segregate Internet-facing systems to an
isolated network (usually referred to as a
DMZ). You still need to audit your system
logs. An NIDS provides early warning
that someone is probing you or that an
attack is being attempted against your
systems​you catch them when they are
looking in the window or jiggling the
doorknob instead of catching them after
they are inside the house (or not noticing
them at all).
6.2 Initial Configuration
Take your time with the initial installation
and configuration of your Snort system. Be
sure to try things out; there are many
options and a great deal of functionality at
your disposal. Almost any effective
information technology project will start
with an inventory​an NIDS deployment is
no exception. A thorough understanding of
the types of systems, their location, and
the services they provide will allow you
to make educated decisions about how to
configure your sensors.
6.2.1 Targeted IDS
If you have only Windows systems in your
network, employing the rules that watch
for attacks on Unix-based systems will
only generate noise. If you are running
Apache as your web server, eliminating
the Microsoft IIS rules keeps Snort from
alerting on attacks that would not affect
your web servers. Look at the information
on the Snort rule sets in the next chapter
and the discussion of tuning Snort in
Chapter 9. They will help you eliminate
rules that watch for attack attempts that
will only generate false-positive alerts.
Consider what you want out of your NIDS
installation. The Internet is noisy with
scanners, worms, scripts, and probes.
Generating alerts on all this noise is of
questionable value. Before the advent of
all this activity, a probe was usually a
genuine precursor to an attack. These
days, it is nearly impossible to discern the
early stages of an actual network probe
from this noise. Tune your IDS to match
the operating systems, software, and
devices you are running in your network.
Some of the strategies presented in the
next section can help you target your
efforts more effectively.
6.3 Sensor Placement
Since the Snort sensor can only alert on
what it sees, the placement of the sensor is
very important. In many networks, putting
the sensor in the wrong spot can cause you
to miss an entire network's traffic. Figure
6-1 illustrates this in a simplistic example.
If you place the Snort sensor at point A,
you will be able to see all traffic between
the internal network and the Internet. You
will not be able to see the traffic between
your DMZ (containing a web server and
mail server) and the Internet. In this case,
an attack on your web server would go
Figure 6-1. The importance
of sensor placement
If you put the sensor at point B, you will
see all traffic between the systems in your
DMZ and the Internet. In this case, you
will not see the traffic between the
internal network and the Internet. Please
note that this might be desirable. Perhaps
you have a sensor dedicated to the DMZ
with a tuned set of rules and
preprocessors specifically for those
servers. You might have another sensor
located at point A that watches that traffic
that is tuned appropriately.
Locating a sensor at point C will allow
you to see all traffic traveling to and from
both networks (DMZ and internal) and the
Internet. Putting the sensor at point C still
leaves a potential blind spot: traffic
between the DMZ and the internal network
will not be watched.
As you can see, connecting your sensor to
the network is not a trivial decision. Let's
examine some of the aspects of this
6.3.1 Systems and Networks
to Watch
It is not realistic to expect to watch all
traffic between all systems on your
network effectively with NIDS.
Prioritization of your systems and
networks is necessary.
Systems that provide services to the
Internet are a good first choice. These
systems are more at risk than systems on
your internal network. They also may be
providing services to your customers or
business partners that are very important
(if not increasingly central) to the goals of
your organizations. A rule of thumb is to
segregate any systems that provide
services to the public Internet in a
separate network that has limited access
to your internal network. This arrangement
makes watching the traffic much easier.
There are also a group of servers that
provide services to people sitting at the
desks: print servers, file servers,
authentication and directory servers, mail
servers, intranet servers, and databases.
The incidence of false positives increases
greatly when watching internal LAN
traffic. The normal chatter between
Windows systems can generate an
overwhelming volume of such alerts and
the sheer amount of effort involved in
tracking these down outweighs the value
of doing so. Target high-value systems​the
database storing your ERP solution or
your accounting systems​for NIDS sensor
vigilance. You can make up for the lack of
an NIDS watching traffic by the
disciplined administration of your
systems, including following best
practices when building the systems,
pervasively using antivirus software, and
auditing system logs.
This isn't to say that we will ignore the
workstations, laptops, and other citizens
of the internal network. It is suggested that
traffic between these systems and the
Internet be watched by an NIDS. If you
have a WAN connection to your business
partners or branch offices, a sensor
watching traffic across these links is
The exact placement of sensors is made
easier by looking for natural
bottlenecks​connections between networks
make very nice connection points. The
point (or points) that your network
connects to the Internet is an easy choice.
As previously mentioned, WAN links are
important bottlenecks to watch. Consider
putting your internal servers on a separate
network so that traffic between the
networks containing your desktop users
and your servers can be aggregated and
One question remains: do you want to
place your sensor on the Internet side of
the firewall (outside) or on the internal
side (inside)? Outside, the sensor sees all
inbound attempts to probe the network.
Inside, it provides even more targeting for
your sensors, since only inbound traffic
that makes it through open ports in the
firewall will be monitored. Given the
noise and the questionable usefulness of
alerting on that noise, I prefer locating the
sensors behind the firewall.
6.3.2 Creating Connection
The high-speed switches that most
networks use direct traffic to just the ports
that connect to the systems engaging in the
conversation​making eavesdropping on that
conversation with an NIDS sensor
impossible without further assistance.
Some administrators plug a small hub into
the path of the traffic they want to watch.
While this tactic works (hubs send all
traffic out all ports), small hubs are very
often not as reliable as enterprise-class
There are a variety of hardware network
taps that can make a copy of traffic
traveling on copper and fiber network
cables. Some are commercial and others
can be built with instructions on the
Internet. The commercial solutions are
usually well made, but represent a
potential single point of failure for the
cable being tapped. While I know one end
of a soldering iron from the other, I
wouldn't want to trust my network's
Internet connection to my skills.
A better solution is available from most
enterprise-class switches on the market.
The specific examples here are those used
on Cisco switch hardware. It is possible
for the switch itself to make a copy of the
traffic from one or several ports and send
it out a designated port that you can plug
the NIDS sensor into. This is called a
SPAN port (Switched Port Analyzer) by
Cisco. You can mirror the traffic from a
single port, or aggregate the traffic from
multiple ports (even ports on remote
switches!). Please note that we are talking
about Cisco switches, not routers.
Because you are using your existing
(likely redundant) hardware to perform
this task, you are not introducing any
potential failure points. Going back to
Figure 6-1, if we create a SPAN port that
aggregates the traffic from both points A
and B, we can watch traffic between both
the internal network and the Internet and
the DMZ and the Internet with a single
sensor interface.
Plan carefully. On Cisco switches,
you are allowed only two SPAN ports
per physical switch.
There is one thing to watch out for when
spanning multiple ports into a single
monitor port. If the total bandwidth you
are aggregating is larger than the
bandwidth of the port you're sending it to,
the extra traffic will be lost and not
monitored. For example, if you are
sending the traffic from five 100 Mbps
Fast Ethernet ports​each of which is
carrying 25 Mbps of traffic​to a single 100
Mbps Fast Ethernet port, you will lose 25
Mbps of traffic, since you cannot send 125
Mbps of traffic through a 100 Mbps port.
When possible, I try to use a Gigabit port
as the SPAN port to get around this
problem. In truth, this much traffic causes
most systems running Snort to get little Xs
on their eyes and fall over backwards. For
such high traffic levels, consider some of
the strategies presented in Chapter 13.
6.3.3 Encrypted Traffic
It's also important to have a good
understanding of how your systems
perform their business. You might want to
use Snort to monitor a very important ecommerce web server that processes
credit card purchases from Internet based
customers. This traffic is encrypted using
SSL encryption​making the transaction
much more secure. It is impossible for the
Snort sensor to match the content of an
encrypted packet to signatures in the rule
files. The goal of encrypting the traffic is
to make it nearly impossible to intercept
and monitor. Figure 6-2 illustrates this
Figure 6-2. Snort can't watch
encrypted traffic
One solution that allows your web traffic
to remain encrypted (maintaining the
security of the transaction) but also allows
Snort to watch for signs of intrusion is an
SSL proxy. SSL proxies go by many
names, including Content Switch, SSL
Accelerator, and SSL Proxy. This device
sits between the client and the server and
handles the task of encrypting the traffic.
The traffic from the web server to the SSL
proxy is not encrypted, but the traffic
between the proxy and the web client is
encrypted. Plugging the Snort sensor
between the web server and the proxy
allows the traffic to be monitored.
Another real advantage to the
implementation of an SSL proxy is the
ability to offload CPU-intensive
encryption tasks to a dedicated device,
allowing your web servers to scale more
effectively. SSL proxies very often can
perform other tasks, such as loadbalancing and authentication. Figure 6-3
illustrates the implementation of an SSL
proxy between the web server and the
client (and where the Snort sensor can be
Figure 6-3. Snort is now able
to watch the web transaction
6.4 Securing the Sensor Itself
It should be obvious that protecting the
integrity of the systems responsible for
monitoring and maintaining the security of
your network is very important. You need
to protect the integrity not just of your
NIDS systems but of your syslog servers,
authentication servers, monitoring, and
management tools. One strategy that I
employ is a management network. This
network is behind its own firewall and
access to the systems contained within the
management network is closely
controlled. The systems inside do not even
participate in the same authentication
domains as the systems on the inside of the
network. The only openings in the firewall
are those that are needed to get monitoring
traffic to the systems that watch the
Closely managing the Snort systems is
important. The operating systems should
be configured according to industryaccepted best practices and should be kept
up-to-date with patches and updates. After
all, a compromised IDS sensor would
have access to all the traffic to and from
your most sensitive systems​a dangerous
situation, to say the least.
6.4.1 Choose an Operating
I squirm uncomfortably when people ask
me what operating system they should use
for a particular function. I carefully try to
avoid discussions about religion, politics,
and operating systems​all for the same
reason. They're too controversial.
However, I will briefly put on my
consultant hat and walk you through the
process of deciding which operating
system to use for your Snort sensor.
I started my Information Technology
career doing Microsoft phone tech support
for the launch of Windows 95. My
background in modems and networking
(Commodore 64, 300 baud modem at the
beginning of things) quickly got me into a
mentor role. My MCSE certification was
first in NT 3.51. I consider myself a
Windows expert. That said, about five
years ago I discovered Linux and BSD. I
liked the fact that I could strip the system
down to just the services I wanted. It
made administration much easier (and the
side effect was better general security). I
hated the fact that my Windows servers
needed to be rebooted all the time to keep
them running. Linux had outstanding
Now, if I build a system, it's a Linux box
(RedHat or Suse are nice) more often than
not. My desk at work has three systems: a
Windows XP laptop, a Suse Laptop, and a
FreeBSD server. At home I have a Debian
server (my mail server), a Suse linux
server (test box), a FreeBSD server (Web
Server), and a Windows gaming system. I
spend about 60% of my time in a Unixbased environment of some sort. If I am
going to build a server, it will be either
Debian or FreeBSD, since I can build a
minimum configuration and keep it up to
date very easily. (I really like FreeBSD,
but my company has standardized on
Redhat as a Linux server OS). The recent
changes in Suse are pretty exciting, too.
I share this information to give you a
frame of reference for my approach to
choosing an appropriate operating system.
There are several things to consider;
supportability, performance, stability, and
security are at the top of the list:
Very often, the decision of which
operating system to use is based on
what you know how to run. Choose
an operating system that you know
how to configure and maintain
effectively. If you know Windows
well and little or nothing about
Linux, use Windows! I'm speaking
about a Snort system that will be
relied on to secure a network. If you
are just playing or testing, installing
and configuring Linux or FreeBSD
Snort sensor might be a nice way to
learn a new OS. Most of the web
resources dedicated to running Snort
lean towards a Linux-based
installation. It is arguably easier to
"strip down" a Linux or BSD
system​Windows installs a lot of
things you just don't need.
It is generally accepted (and I'm
opening a real can of worms here)
that the network stack on Linux and
BSD is faster than the Windows
network stack. In my experience, it
seems that a Linux sensor can watch
higher bandwidth levels than
Windows using a given
configuration. This makes sense
when you consider that Snort (and the
underlying infrastructure of libpcap)
is written for a Unix-based operating
It used to be an easy argument that
Linux and BSD were much more
stable than Windows. That really
isn't as true anymore for a well
configured and patched Windows
system. I would still argue that a
competently administered Unixbased operating system has better
uptime compared to Windows (email
me with your arguments). When
considering stability, you may find
yourself going back to the
supportability issues.
I can lock down and secure a
Windows system as well as I can
lock down a Linux or FreeBSD
system. The problem is, it has been
much (much!) more work to keep a
Windows system secure over time.
The number of patches released for
Windows services has been nearly
overwhelming. There have certainly
been patches for other operating
systems and Unix-based services.
However, there have been fewer in
general, and since Unix-based
operating systems tend to run fewer
services, there is a smaller chance
that you will be affected by a
particular vulnerability. For securityrelated tasks, I tend to migrate to
Linux or BSD over Windows.
6.4.2 Configure Interfaces
Along with the creation of a controlled
management network, there are more steps
to be taken to protect the integrity of your
security systems.. Snort sensors should be
configured with at least a pair of
interfaces. One of these interfaces will be
on the management network; all alerting
and management traffic will use this
interface, keeping it away from prying
eyes. Snort will use the other interface as
a monitoring point. This interface will not
be configured with an IP address, so it
will be invisible to hosts on that network.
This is commonly referred to as a stealth
interface. Keeping the listening interface
invisible to the other systems on the
network makes keeping the sensor secure
much easier.
We discussed using SPAN ports in a
switched network to allow the monitoring
of switched ports. SPAN ports can
actually help hide your Snort sensors,
since they can be configured to only
transmit traffic from monitored ports and
not listen to interfaces plugged into them.
6.4.3 Disable Unnecessary
If a service is not needed for the business
function of a server, it should not be
installed or enabled. The fewer services
running on a system, the fewer potential
issues need to be secured and kept up-todate. This is an essential step to making a
system secure.
6.4.4 Apply Patches and
These days, there are always updates and
patches that need to be applied to the
operating system and services​especially
on a freshly installed system. This is true
no matter what operating system you use.
As time goes by, it is important that
administrators keep abreast of newly
discovered vulnerabilities in their
operating system and services. If possible,
establish a maintenance window for when
updates will be made to your systems.
This will allow you to establish a change
routine​notify necessary people that the
system will be unavailable, test the
updates on a test system, and establish a
back-out plan so that if the change blows
up, you can go back to the initial system
6.4.5 Utilize Robust
Where possible, use stronger
authentication than just a simple username
and password. The weaknesses inherent in
passwords are well-documented.
Passwords can be attacked through
dictionary attacks or simple brute-force. If
you do need to use passwords, utilize
mechanisms (varies from operating system
to operating system) that enforce
passwords of a certain length and
complexity. Force the users to pick
different passwords by remembering the
last few they've used. Force the
passwords to be changed periodically
(every 60 days or so). Most importantly,
configure the authentication mechanism to
lock out the account after a certain number
of consecutive failed password guesses (I
prefer locking the account after five failed
If you can, employ a stronger mechanism
for authenticating users (it's not possible
in most environments). Smart cards (and
PKI), one-time password generators, or
biometric mechanisms are excellent
I do have some reservations about
biometric authentication. While very
convenient and certainly better than
passwords, this method has one
serious flaw. When someone loses
their smart card or one-time
password-generating device, the old
one is marked as revoked in the
authentication system and a new card
or mechanism is issued. If someone
intercepts or finds a way to decipher
the digital representation of a
biometric authentication, how can I
revoke a thumb or a retina?
6.4.6 Monitor System Logs
It is very important that the system is
configured to generate logs and that those
logs are reviewed regularly for signs of
system, hardware, or configuration
problems (including signs of intrusion).
Auditing authentication, system function,
and hardware operation is a good place to
start. If possible, send the logs to a central
syslog server (hopefully located on your
controlled management network). This
makes it much easier to review the logs
and establish some correlation of events
across multiple systems and networks.
6.5 Using Snort More
It doesn't take long before only logging to
the alert file becomes ineffective. The
alerts scroll by too quickly and making
sense of the data logged in a timely
manner can be impossible. In Chapter 5,
we looked at how to configure Snort to
log to a database. The information sent to
the database contains an incredible
amount of information​including details
about the packet that triggered the alert.
Refer to Appendix A for details on the
data contained in the database. Choose a
database and configure Snort to send
alerts to it.
Once the data is in the database, you need
to choose some tools that can present the
data in a way that makes managing the
alerts and the sensors quick and easy. I
prefer to use ACID (the Analysis Console
for Intrusion Detection). You may find that
another tool suits you better. Refer to
Chapter 10, Chapter 11, and Chapter 12
for an examination of the tools that are
available to help you manage your Snortbased NIDS deployment. Chapter 7
discusses strategies to keep your
signatures up-to-date and effective.
6.6 Sites of Interest
Guide to
Guide to
Apache 1.3
Security Tips
Apache 2.0 Tips 2.0/misc/security_tips.html
Security Tips
NSA Secure
Configuration MenuID=scg10.3.1
Chapter 7. Creating
and Managing Snort
Snort is a signature-based intrusion
detection system. While the preprocessors
do not rely on signatures to generate alerts
on potential malicious traffic, the heart of
Snort's ability to detect intrusion is the
catalog of signatures located in the rules
files. Being a signature-based IDS is both
a strength and weakness.
Because Snort is signature-based, it can
be configured for specific threats​the latest
worm, the latest IIS exploit, and so on.
The rules watch for the specific contents
of a packet or for strange settings in the
headers. This allows the security
administrator to quickly determine the
nature of the potential attack since he can
easily examine the rule that triggered the
alert (as well as the packet itself with
some of the other tools available, like
ACID or SnortCenter). A comparison is
commonly made between signature-based
IDS and antivirus software. Both have a
catalog of signatures that they use to match
against a stream of data flowing by a
sensor component. In antivirus software,
this process is accomplished by a
software component that watches memory
and filesystem access. An IDS, on the
other hand, watches packets traveling the
To detect the latest attack methods, you
need the latest signatures (although I've
been surprised at how often a generic
signature will draw my attention to a new
kind of attack that does not have its own
rule). As a result, it is important to keep
the rules as up to date as is reasonable. I
stick to a schedule of updating the entire
rule set once every two weeks. I do create
my own rules for new threats that spring
up in the interim period between updates
(these are stored in the local.rules file).
To keep up to date on the latest rules and
threats, I closely follow the snort-sigs
mailing list and some of the major security
web sites. CERT and SANS very often
include Snort rules with their security
bulletins for newly discovered threats.
Another potential issue that arises when
you use the catalog of signatures as your
primary detection method is that the bad
guys have access to the catalog, too. They
can craft their attacks so as not to trigger
the signature catalog (sometimes this is
quite difficult, since an attack may trigger
multiple types of rules). As we discussed
in Chapter 4, one of the strategies of
attackers is to flood an IDS with packets
that will trigger alerts, either hiding their
actual attack in the noise or simply
overwhelming the IDS sensors. Snort
copes with these attacks by using the
stream4 preprocessor.
All in all, given the ease of use, cost, and
balance of strengths and weaknesses,
Snort is usually a valuable component for
a defense-in-depth strategy for network
7.1 Downloading the Rules
While the Snort source package includes a
complete package of rules, you will need
to upgrade your rules more often than you
upgrade Snort itself. To download the
latest rules for Snort 2.1.x, use the
following link:
There are a number of schools of thought
on where to keep your rules. Some people
say to put them in /etc/snort, others
/usr/local/etc/snort. They also want you
to copy the snort.conf file to one or
another location, too. I've been running
Snort on the same sensor systems for
several years now and have tried several
methods for updating and keeping track of
my rules. I keep everything in
/usr/local/share/snort_rules (I keep the
Snort source code itself in
/usr/local/src/snort). I make a directory
with the month, day, and year, and
download the rule archive to that
directory. For example, if it's early April,
2004 and I want to update my rules, I
download the latest snapshot (using wget)
I then extract the archive (which puts
everything into a rules directory) using:
tar -zxvf snortrules-snapshot-2_1.t
Wherever you decide to put it, just make
sure that you set the RULE_PATH
variable in the snort.conf file to point to
the directory containing the *.rules files.
Below is a listing of the rules files (the
archive also includes a snort.conf file
template and several *.config files used
by Snort):
Each rule file includes a listing of rules
that are organized according to the type of
attack or type of traffic they watch for. To
disable a rule set, comment out (with a #
at the beginning of the line) the INCLUDE
line in the snort.conf file that mentions the
rule you want to turn off. To disable a
particular rule within a rule set, comment
out the line containing the rule (again, with
a #). See Chapter 9 for a discussion of
tuning your rules to match your
environment and controlling false
7.2 The Rule Sets
Here is a brief description of the rule sets:
My personal favorite set of rules.
They detect when a host on your
local network is sending a known
response to a successful attack.
While it might not be as useful as
catching the attacker before he has
succeeded, the alerts these rules
generate are very often not false
positives. There are some that are a
little noisy​in particular the rule that
alerts on a "403 - Forbidden" HTTP
Detects traffic generated by backdoor
network connections, including those
created by attackers using many
rootkits and stealthy remote control
applications (like subseven, netbus,
and deepthroat).
Watches for illegal packet header
settings like a TCP and UDP port 0
traffic, or a SYN packet to a
multicast address.
Disabled by default. It watches for
people using instant messengers and
other Internet chat protocols. If this
activity is against your organization's
security policy, enable this rule set.
Alerts on traffic generated by many
well-known distributed denial-ofservice mechanisms, including
Trin00 and shaft. The Stacheldraht
rules can be noisy, since they are just
looking for specific words in the
payload that may be common in your
Actually not referenced by default in
the snort.conf file; really just a
museum of old Snort rules.
Alerts on attacks against DNS
servers (including detection of zone
Detects traffic generated by known
denial-of-service attacks. It will
detect some specifically named
attacks like winnuke and jolt, but
will also detect classes of attacks
like IGMP and teardrop attacks.
This is where new types of rules are
included. This file is included by
default, so check it for new rules.
Very often this is just an empty file.
Includes the signatures of many
known exploits. Seeing an alert
generated by these rules should not
cause immediate panic. They indicate
that an exploit attempt has occurred.
When you see one of these alerts,
verify that the target system is, in
fact, vulnerable to the attack.
Hopefully, you have the system
patched or updated to address the
vulnerability the exploit attempted to
Alerts on many known types of attack
against the finger service that runs by
default on many Unix-based
operating systems. If you have the
finger service disabled on your
systems (I do, where possible), you
can disable this rule set.
Generates alerts when known attacks
Generates alerts when known attacks
are detected against the FTP service.
This noisy little set of rules is
disabled by default. It may be useful
when troubleshooting a specific
ICMP problem on your network, but
in general it just generates noise and
should remain disabled.
Alerts when it sees the signs of pings
specific to particular attack tools.
These alerts can be very useful. The
"destination unreachable" rules can
be very noisy, though, and if you
choose to keep this set of rules
enabled, consider turning off the loud
"unreachable" rules.
Generates alerts when known attacks
against the IMAP email service are
Disabled by default. They generate
Disabled by default. They generate
alerts on a variety of traffic that is
normally found on a healthy, secure
network. They may be useful in
troubleshooting some issues, though.
Stores rules that you create.
Contains rules that don't fit easily
into other categories. In my
experience, they generate a large
number of false positives on traffic
that should not be a concern on a
network that utilizes reasonable
defense-in-depth strategies. I usually
disable this entire rule set.
Disabled by default. If it is against
your organization's security policies
to run multimedia applications across
the network, enable this rule set.
Detects known attacks against
mySQL database servers.
Detects several of the recent
Windows-attacking worms that are
causing headaches for network and
system administrators around the
world. Some of the alerts can
generate false positives (namely the
administrative share access rules and
the rules that alert on SMB and
NetBIOS access). If the Snort sensor
is watching Internet traffic only and
NetBIOS traffic is not allowed in or
out of your environment, consider
disabling this rule set.
Contains signatures that indicate
attack against network time protocol
Detects known attacks against Oracle
database servers.
Watches for traffic generated by
Watches for traffic generated by
other IDSs. If you are the only person
authorized to run an IDS in your
environment, this can be a relevant
concern. You can likely disable this
rule set.
Disabled by default. They detect
activity generated by peer to peer
software. Peer to peer clients can
represent a dangerous vector for the
introduction of viruses, worms, and
other malicious code into your
environment. If your organization has
policies against the use of such
software, enable this rule set.
Disabled by default. It contains rules
that watch for activity that may
against some organization's security
policies (for example, an alert will
be generated by PC Anywhere and
VNC traffic, or an anonymous FTP
login). Consider reviewing the rules
in this file and leaving those that
match your policies enabled, while
disabling the rest (after enabling the
rule set itself, of course).
Generates alerts when known POP2
email service attacks are detected.
Generates alerts when known POP3
email service attacks are detected.
Disabled by default, these rules will
alert when a variety of off-color
packet contents go by on the wire. If
it is against your organization's
security policy to visit such content
on the Internet, consider enabling the
rule set (but be prepared for some...
interesting alerts).
Generates alerts on attacks against
the remote procedure call (RPC)
services employed by nearly every
operating system. If the sensor is
watching Internet traffic and RPC
activity is not allowed in or out of
the environment, consider disabling
this set of rules. If the sensor is
watching internal traffic, some tuning
may be necessary, depending on the
types of systems running on the
Alerts when rservices (rlogin, rsh,
and rexec) are detected on the
network. These are powerful
commands to control remote systems.
If you use these in your environment,
you may want to disable this rule set.
Detects a variety of different network
Detects a variety of different network
and service scans, from deceptive
portscans to SSH and UpnP service
scans. It detects the signatures of
some specific scanning tools, too.
Disabled by default. It will detect
shellcode in the packet payload that
is attempting to compromise a variety
of systems. This shellcode may be
the payload of a successful attack that
does not have its own signature.
Since these rules are designed the
check the payloads of all traffic, they
can cause a significant performance
hit when enabled.
Generates alerts when known SMTP
email service attacks are detected.
Detects a variety of SNMP traffic.
SNMP is used to manage devices on
a network and many vulnerabilities
have been detected in the protocol. If
you are running a sensor that is only
watching Internet traffic and SNMP
traffic is not allowed in or out, you
can disable this rule set.
Detects known attacks against
Microsoft SQL Server database
Alerts on dangerous traffic
transmitted in telnet sessions.
Alerts on attacks against the TFTP
Disabled by default. This rule set is
not being actively maintained and the
rules really just watch for a variety
of file extensions transmitted in email
traffic. The real virus signatures are
located within the specific service's
rule sets now.
Disabled by default. It generates
alerts when known generic attacks
against web servers are detected.
Consider enabling it, since it does
not generate a large number of false
Generates alerts when known attacks
against CGI services are detected.
Generates alerts when potentially
dangerous web client traffic is
detected. Most of these alerts are
based on Microsoft Outlook Web
Access traffic and generate a large
number of false positives. Consider
disabling this rule set.
Generates alerts when known attacks
against Coldfusion web application
services are detected.
Generates alerts when known attacks
against Frontpage web authoring
services are detected.
Detects known attacks against
Microsoft Internet Information Server
(IIS) web servers.
Generic web attack detection rules.
Detects attacks against web servers
running PHP applications (primarily
runs on Apache, but it is possible to
run on IIS).
Detects attacks against remote XWindows sessions.
7.3 Creating Your Own Rules
There are two separate elements that make
up a typical Snort rule. We used an
example previously to demonstrate a
rule's composition. These next few
sections explain in greater detail the
individual portions of a Snort rule and
how to create a customized rule for local
7.3.1 Snort Rule Headers
Rule headers make up the first section of
a typical Snort rule. The header defines
the who within the packet in question.
The rule header can be considered a brief
description of the network connection.
Four parameters define a unique network
connection: Source IP, Source Port,
Destination IP, and Destination Port. The
header also includes the direction of the
packet traverse, as defined by the -> or <>
symbols. Using a basic example, we will
break down a typical header into its
component parts and explain what each
part does.
Here is a portion of a standard rule
alerting the user to a SYN FIN scan
attempt. As shown in the example below,
this scan is characterized by TCP data
entering the internal network with the
SYN and FIN flags set in the TCP header
field. Snort looks for those flags within
the packet and notes the reference and the
attack's classification. The rule then prints
out an alert that a scan was performed
with SYN and FIN flags set.
alert tcp $EXTERNAL_NET any -> $HOM
arachnids,198; classtype:attempted-
The section enclosed within parentheses
is referred to as the Rule Options
section. Here is where the rule determines
default messages, flags, and attack
classification. Rule options are discussed
later in this section.
The first field in the header is the Action
field. In this example, an alert is the
defined action when a matching signature
is detected. The signature in this case is
the presence of predefined flags set in the
TCP header. Signatures within other rules
may be matching payload content, other
flags, or binary data. An entry is generated
in the alert file within /var/log/snort when
a matching packet is detected and the
packet is logged in a specific directory
based on its IP address.
Different values can be placed in the
action field. Here are those values:
Alerts and logs the packet when
Only logs the packet when triggered.
Ignores or drops the packet or traffic
Alerts then activates a dynamic rule
or rules.
Ignores, until started by the
activate rule, at which time, acts as
a log rule.
The last two values are slowly being
phased out, so do not expect to see them in
later versions of Snort. The replacement
option is called "tagging."
The next field is the Protocol field. This
can be IP, TCP, UDP or ICMP (more
protocols are planned for future versions
of Snort, including ARP, IGRP, GRE,
OSPF, RIP, and so on). The Source IP
field follows next. This is the originating
network or range used by those devices
sending hostile packets. Multiple IP
addresses can also be used in this field
using an IP List, a bracketed list of IP
addresses and their CIDR netmask,
separated by a comma (the same as
specifying addresses in the snort.conf
For example, using the same example from
above, substitute the variable
$EXTERNAL_NET for an IP list. What
follows is the rule header only.
alert tcp [,198.60.7
There should be no spaces between each
IP address listing when using this format.
You can also negate an address by placing
an exclamation point or bang (!)​also
known as a negation operator​directly in
front of the address
Immediately following this field is the
Source Port field. Here, the example used
is any, but it could just as easily be a
specific number, such as 21 for the FTP
port, or a range of numbers, such as 20:23,
indicating FTP-data through telnet. For
ports that are less-than or greater-than a
given port number, place a colon in front
of the number to specify ports less-than or
equal-to that port number. Likewise, place
the colon after the port number to indicate
all subsequent ports greater-than or equalto that port. When defining ICMP in the
protocol field, no port value is needed.
Again, building on the example above,
define any packets coming from the IP list
using ports 21 through 23 or ftp through
telnet, rather than using the any option.
alert tcp [,198.60.7
Remember that when doing ranges,
the ports indicated are inclusive. This
means the example above looks for
ports 21, 22, and 23.
Next is the Traffic Direction operator.
This is where the rule defines what
direction the packets are traveling through
the network. The arrow symbol (->)
indicates packets originating from a
source traveling to a destination. All items
to the left of the symbol are source values.
Using the < > symbols indicates direction
is moot or that the traffic is bi-directional.
Finally, the last two fields are the
Destination Address and Destination
Port. The reasoning behind the respective
Source Address and Source Port fields
also applies.
7.3.2 Rule Options
The second half of the rule or the rule
options define what is involved in the
network packet. It is basically a message
to Snort to inspect the packet for matching
values and determine whether to consider
the packet malicious. These options are
triggered only if the rule headers match
certain packet content. If there is a match,
Snort most commonly writes an alert
message to the alert file in the Snort
logging directory. Packet data is logged as
well. This ensures that once an alert is
issued, the administrator can go back,
review the packet and confirm or deny it
was an intrusion attempt.
Using the same example as in the rule
headers definitions, here are some of the
explanations for the rule options. The rule
itself has been broken onto multiple lines
for clarity. You can also do this when
building rules by putting a backslash (\ )
character at the end of the line.
alert tcp $EXTERNAL_NET any -> $HOM
(msg:"SCAN SYN FIN";flags:SF; refer
classtype:attempted-recon; sid:624;
The options section must start and end
with a parenthesis. Each rule option is
delimited by a semicolon.
The options portion of a Snort rule can
be left out. The rule alert ip any any
-> any any is a completely legitimate
The first part of the rule option is the
message that specifies the type of attack
or hostile activity. Notice that there is a
keyword and a value. The message
keyword or "msg" is followed by the
value​a text message enclosed in quotes.
This message is written to the logging
directory or to the alert database.
Messages are usually short and succinct.
When creating your own rules, do not
write something esoteric or ambiguous, or
use acronyms that only you can decipher.
Your rules may one day end up in the main
Snort Rules database. Keep messages
clear and to the point.
The next field in this example of rule
option is the flags field (flags:SF). This
may or may not be present within other
rule option sections, depending on the type
of packet examined or the rule class.
Rules are highly customizable and fields
can be added or subtracted depending on
what you look for. In this instance, the rule
is looking in the TCP header for packets
with the SYN and FIN flags set.
Along with the basics, there are other
arguments that can be used in conjunction
with the TCP flags. For instance, the plus
sign (+) matches the specified flag, along
with any other flags. The asterisk (*)
matches any of the flags to which it is
applied; the exclamation point or negation
operator (!) negates any flags.
For example, in the following rule, the
ACK flag is set. But this rule also states to
match the ACK flag along with any other
alert tcp $HOME_NET 146 -> $EXTERNA
"WHATISIT"; flags: A+; reference:ar
In some cases, these two pairs may be the
extent of a rule option. However,
additional pairs often appear in the rule
option section of other rules. These are
used both for reference and specificity
when avoiding false positives. Defining
the additional fields in the aforementioned
example, the reference section states
where the signature originated or where
more information regarding its purpose
can be found. The classtype option
specifies the category of attack the packet
matched. The sid pair or signature ID is
useful for locating more information about
that particular signature. The rev section
is the rule revision number. If you or
someone else modifies an existing rule,
this value should be incremented to reflect
the fact that this is a new rule or a
variation on an old theme.
SIDs ranging from 0-100 are reserved
for future use. The numbers 1001,000,000 are for Snort distribution
rules, and rules numbered over
1,000,000 are for locally created rules.
A mapping of sids to alerts can be
found in the file.
7.3.3 Common Rule Options
Many additional items can be placed
within rule options. The next section
provides a brief overview of some of the
more common options that can be used
within the Rule Options section. Refer to
the latest Snort Handbook (included in the
/docs directory of the Snort source code
archive). A rule example is provided for
each when needed.
msg: < sample message>;
The message option explains the type
of activity being logged. It is a way
for the rule's author to better explain
the reason for the alert. In this
example, the message "BACKDOOR
attempt" defines this type of attack.
alert tcp $EXTERNAL_NET any ->
"BACKDOOR attempt"; flow: to_se
classtype: attempted-admin;)
flags: < flags>;
This option matches all flags within
the capture. Here is a brief summary
of all the arguments that match TCP
2 = reserved bit
1 = most significant bit
0 = no flags
This option also uses the +, *, and !
signs. For example, F+ means that the
FIN flag must be set but other flags
can be set along with it. SA* means
that either the SYN or the ACK, or
both the SYN and ACK flags and any
other flags can be set. The "!" negates
the use of any flags. The example
flags: !RP; negates both the RST
and PSH flags, matching packets
where neither RST nor PSH is set.
Multiple flag options result in the
rule checking only the final one
content: < straight text>; content: <
hex data>;
The content option is a keyword for
defining stings of text or hexadecimal
data within the payload. This is the
method for detecting buffer overflow
attempts or when doing analysis on
binary data. This option is casesensitive, but can be used with the
nocase modifier for case-insensitive
matching. Use the pipe (|) symbol for
matching hexadecimal data. You can
have multiple content fields in a
single rule. The more specific the
content fields, the more
discriminating (and accurate) the
The rule in this first example is
looking for packets that contain the
text string, "Bad command or
filename", indicative of a failed
access attempt. The second example
looks for a value within the
hexadecimal data indicated by the
pipe symbols. It attempts to find
matching binary packets that first
contain the hex value 2A followed by
the literal text "GOBBLE", and then
followed by another 2A hex value.
"ATTACK-RESPONSES command error
command or filename"; nocase; c
alert tcp $HOME_NET 22 -> $EXTE
RESPONSES successful gobbles ss
server,established; content: "|
classtype: successful-admin;)
The following four items (offset,
depth, nocase, and regex) are
modifiers of the content option.
offset: < value>;
One of four content helpers,
offset defines the point or offset in
the payload to begin searching for a
match. This modifier must always
follow after the content option. The
default offset is or the first byte of the
packet payload. In this example, the
rule looks for the text string "6ISS
ECRNA Built-In Provider, Strong
Encryption" 30 bytes into the payload
alert tcp $HOME_NET 902 -> $EXT
ISS RealSecure 6 event collecto
server,established; content: "6
offset: 30; depth: 70; nocase;
depth: < value>;
This content modifier limits the
This content modifier limits the
depth from the initial offset that a
content check runs, preventing it from
examining the entire payload. If no
depth is specified, the check runs to
the packet's end. The following
example limits the byte depth the rule
runs from the initial offset. In this
instance, the limit is set at 70 bytes.
There is no need to go beyond this
point, since the content string will
occur before this limit.
alert tcp $HOME_NET 2998 -> $EX
IDS ISS RealSecure 6 daemon con
content: "6ISS ECNRA Built-In P
70; nocase; classtype: successf
The content modifier nocase
deactivates case-sensitivity and
looks for matching content. This is
useful for protocols where the server
is insensitive to upper- and
lowercase. This does not affect
hexadecimal matching. In the
example below, the rule looks for
any suffix to a file ending in .mp3,
.MP3, or .Mp3:
alert tcp $HOME_NET any <> $EXT
Napster Client Data"; flow: est
This modifier allows the user to
specify a content search using
wildcards. For example, when used
with the content option, characters
such as the following may be used:
content: "string*"; regex; or
content: "string?"; regex; This
feature has been superceded by Perl
Compatible Regular Expressions
logto: < file_name>;
This option logs specific data to a
unique filename in the /var/log/snort
directory, allowing for easier
categorization (or directory specified
with the -l option). For example, if a
rule had the pair logto: "ICMP", all
packets matching this rule are placed
in the /var/log/snort/ICMP
directory. This option is not normally
found in the basic rule set
downloadable for SnortCenter. It is
intended for user customization. Here
is a basic rule that logs all telnet
connection attempts to a specific IP
address range and places those alerts
in /var/log/snort/telnets.
log tcp any any ->
ttl: < number>;
The time to live option examines the
arriving ttl field and checks for
matching values. Fields with a ttl
value of "1" indicate an ICMP
alert icmp $EXTERNAL_NET any ->
traceroute"; ttl: 1; itype: 8;
id: < number>;
The IP identification value found in
the IP header of the datagram is a 16bit value. These values increase by 1
or 256 for each datagram sent out.
Normally, you will see standard 16bit value IDs. When a packet is
fragmented into multiple smaller
packets, the identification value will
designate which packets belong
together (they will have the same id
alert tcp $EXTERNAL_NET any ->
seq: 3868; flags:S; reference:c
269; rev:3;)
dsize: [<|>] < number>;
The dsize option looks at the
payload size. Certain packets should
not exceed a predetermined limit.
ICMP packets for example should not
be very big. This alert looks for
packets greater than 800 bytes.
alert icmp $EXTERNAL_NET any ->
Large ICMP Packet"; dsize:
ack: < number>;
This option checks for a particular
acknowledgment number. It can be
used to check for the fingerprint of
some scanners (such as Nmap pings)
in the following rule. In this rule, the
ack option matches packets that have
the ack flag set and an
acknowledgment number of "0".
alert tcp $EXTERNAL_NET any ->
TCP"; flags: A,12; ack: 0; refe
seq: < hex_value>;
This option checks the value of a
particular TCP sequence number.
Some DoS attacks use a specific
sequence number. Here is a sample
backdoor Trojan scan using a TCP
sequence number:
alert tcp $EXTERNAL_NET 80 -> $
ACKcmdC trojan scan"; flags:
arachnids,445; classtype: misc-
itype: < number>;
This option looks for a particular
ICMP message type. It's found in the
zero byte offset of the ICMP
message. Stacheldraht uses this
option, making it easy to spot.
alert icmp $EXTERNAL_NET any <>
Stacheldraht agent->handler (sk
6666; reference: url,staff.wash
classtype: attempted-dos;)
icode: < number>;
The icode option is often used in
conjunction with the itype option.
This field is found in the first byte
offset of the ICMP message. If you
are interested in seeing the timestamp
code within an ICMP message, use
the icode option with a value of 13,
as shown below:
alert icmp any any -> any any (
Unreachable (Communication Admi
classtype: misc-activity;)
icmp_id: < number>;
The same principle behind the icode
option applies to the ICMP ID
option. Notice in a prior example the
ID was 6666, a static value used by
Stacheldraht. This fixed numeral
makes identification a simple task.
The ICMP identification value is
usually found in the fourth and fifth
bytes offset of the ICMP message. It
is used for pairing requests and
responses and reflects the ping ID
icmp_seq: < hex_value>;
ICMP sequence numbers usually
increment by one with each
succeeding ICMP echo request
packet sent by the host. A zero value
indicates something is amiss. This
rule is also looking for unique
content: a long sequence of 0 bytes in
binary format.
alert icmp $EXTERNAL_NET any ->
Nemesis v1.1 Echo"; content: "|
20; itype:
8; icmp_id:
classtype: attempted-recon;)
session: [printable|all];
Use the session option to capture
user data from TCP sessions. This is
useful for watching what a specific
user may be doing on a system or on
the network connection. Use either of
the variables printable or all.
printable shows what the user
would see or be able to type. It
echoes hidden characters and might
be used for password sniffing. The
variable all substitutes nonprintable
characters with their hexadecimal
ipopts: < ip_option>;
IP options are not normally used for
regular TCP/UDP and ICMP traffic.
They look primarily at source
routing, in which a datagram learns
its route from source to destination as
it hops from one point to the next.
Source routing is a mechanism
whereby the desired route for a
packet is contained in the packet
itself. This can be a mechanism to
map a network (traceroute),
troubleshoot a problem, or improve
performance​by directing packets to a
low-cost connection, for instance. It
is not normally used and any traffic
with source routing enabled should
be considered suspicious. There are
two types of source routing: loose
and strict. Here is a list of possible
identifying options associated with
source routing, all of which can be
specified in the rule.
Record route
End of list
No op
IP security option
Loose source routing
Strict source routing
Stream identifier
Source routing may be used for
spoofing a source IP address and
getting back a response. This is how
a cracker may hide her real IP
address. If a sniffer is installed
somewhere along the way, a cracker
can grab the response and begin
spoofing. Only a single ipopts
option may be used in a rule.
alert icmp $EXTERNAL_NET any ->
traceroute ipopts"; ipopts:
fragbits: < flag_settings>;
This option looks for the
fragmentation and reserved bit in the
IP header. There are only three flag
settings, as shown here.
Reserved bit
Don't fragment bit
More fragments bit
This example uses the reserved bits
setting or R fragbits option.
alert ip $EXTERNAL_NET any -> $
ip reserved bit set"; fragbits:
content_list: < filename>;
The content-list option can be
used with the react option. It
provides the ability to look for a
collection of strings within a packet's
payload. This is useful for creating
filters or running lists of illegal
activity. A sample list may contain
items such as warez, sploits,
hackz, pr0n, and so on. The file is
built with one string per line.
react: <react_basic_modifier[,
In order to use this option, you must
compile Snort with the --flexresp
option during initial configuration.
This may require additional
libraries, such as libnet. Check your
configuration for the latest
requirements. This option is also
used in conjunction with the
content-list option, as mentioned
in the previous example.
Some of the basic modifiers for this
option are block, which allows
Snort to actually close a connection
and send a warning notice visible to
the user, and warn, which only sends
a simple warning notice. Additional
features that should be available
soon, if not already, are msg, which
includes the the message option text
in the blocking notice. There's also
proxy: <port_nr>, in which react
uses the defined proxy port to send
the notice.
Here is an example of how the react
option is used:
alert tcp any any <> 192.168.10
adult"; msg: "Warning, adult co
uricontent: [!] "content string";
This option performs a string match
just like the content option, only it
matches against URIs sent to a web
server. In this example, the rule
warns of Unix commands sent to a
web server.
alert tcp $EXTERNAL_NET any ->
msg: "WEB-ATTACKS ps command at
"/bin/ps"; nocase; classtype: w
ip_proto: [!] < name or number>;
This option specifies any of the
available 256 protocol numbers or
values found in the protocols file,
allowing users to go beyond the
regular IP, TCP, UDP, and ICMP
protocols normally used. For
example, in mid July 2003, a serious
bug was detected in the Cisco IOS
release. Protocols 53, 55, 77, and
103 were deemed vulnerable and a
crafted packet could cause a router to
lock up. Within hours, Snort had a
working rule that detected any
attempts to exploit this vulnerability.
Here are the rules as they were
added to the rule base:
alert ip $EXTERNAL_NET any -> $
classtype:attempted-dos; ip_pro
alert ip $EXTERNAL_NET any -> $
classtype:attempted-dos; ip_pro
alert ip $EXTERNAL_NET any -> $
classtype:attempted-dos; ip_pro
alert ip $EXTERNAL_NET any -> $
classtype:attempted-dos; ip_pro
These rules use three items within the
rule options: a msg field, a
classtype field, and the ip_proto
field. For more information about
available protocols, check the file
/etc/protocols on Unix systems or
under Windows.
This is a very simple option that
always stands by itself. It looks for
identical source and destination IP
alert ip any any -> any any ( s
reference: cve,CVE-1999-0016; r
html; classtype: bad-unknown;
Some alerts examine TCP traffic
Some alerts examine TCP traffic
using stateful packet inspection. In
certain cases, it waits until the threeway handshake has been completed
before triggering an alert. Stateful
packet inspection was added after
tools like stick and snot, designed to
overwhelm an IDS with false alerts,
came on the scene.
In some instances, it may not be
necessary to await the handshake, but
the packet is strange enough in its
own right to trigger an alert. In cases
such as these, allowing "stateless"
checking is sufficient. The following
example shows all TCP flags set.
alert tcp any any -> any any (
sid: < snort rules id>;
An SID is normally intended for
tools such as SnortCenter that parse
alert messages. It does not affect
signature recognition. Because each
alert has its own unique ID,
categorization is easier. This option
simply provides a rule SID used by
programs such as ACID and
SnortCenter. Snort normally assigns
an SID to each alert. Users need not
assign a specific variable or ID to a
custom alert.
alert tcp $EXTERNAL_NET any ->
xp_sprintf possible buffer over
bugtraq,1204; classtype: attemp
rev: < revision integer>;
This option shows the revision
number of a particular rule. When a
rule is improved or a more accurate
signature is added, its revision
number increases by one. This way
you can identify which version of the
rule triggered the alert.
alert tcp $SMTP_SERVERS any ->
"VIRUS OUTBOUND .pif file attac
"Content-Disposition|3a|"; cont
content: ".pif|22|"; distance:
classtype: < class name> :
This option provides more
information about an event, but does
not actually trigger the alert. The
following list is extracted from
Snort's classification.config file,
located within the Snort source.
All classtypes ending with a "1" are
High Priority. The examples listed
here are only those classtypes that
are a "1" or High Priority. Medium,
Low, and No Priority classtypes are
2, 3, and 4, respectively, and are not
shown here.
Attempted User
Privilege Gain
unsuccessful- Unsuccessful User
Privilege Gain
successful- Successful User
Privilege Gain
Privilege Gain
Privilege Gain
Executable code was
A Network Trojan was
webapplication- Web Application
Porn Content
Potential Corporate
Privacy Violation
The following is an example of
classtype used in a Snort rule.
alert tcp $HOME_NET any -> $EXT
"WEB-CLIENT Outlook EML access"
eml"; classtype: attempted-admi
priority: < priority integer>;
The classification.config file assigns
a priority of High, Medium, Low,
and None to all classtypes. Use this
option with other external tools such
as ACID and SnortCenter to search
output for specific priorities.
reference : <id system>,<id>;
This option provides a link or URL
to a web site or sites with more
information about any given attack.
alert tcp $HOME_NET any -> $EXT
"WEB-CLIENT readme.eml download
uricontent: "/readme.eml"; noca
2001-26.html; classtype: attemp
Using the instructions presented here, you
should have enough information to begin
creating your own rules or customizing
existing ones. The best method for
creating custom rules is to capture
network traffic using tcpdump. Look for
those packets that appear unique or match
what you currently see happening on your
network. Look for any common features
that could be applied to a Snort rule, such
as payload data information, unique
content, or specific flags or options set
within the TCP or IP header. Adding these
markers to a Snort rule helps identify
incoming packets.
There are some rules of thumb for writing
good rules:
The longer the contents that you
include in your rules to match the
payload of a packet, the better the
Try to write the rules to match the
characteristics of the vulnerability
instead of the exploit. This is not
easy, but leads to a rule that catches
most attempted attacks.
Don't forget that content rules are
case-sensitive (unless the nocase
option is used).
7.4 Rule Execution
Snort has changed the way rules are
checked in recent versions. Rules are
checked in order of protocol (in this
order: TCP/UDP, ICMP, and then IP).
Beyond that, the more discriminating rules
will be checked first. A rule that checks
for a specific TCP port will get checked
before an "any" rule. A rule that has a
larger string in the rule content will get
checked. For example, a rule that checks
for the content "Volume in drive C has no
label" will be checked before a rule with
the content "Volume in". Also note that
content-matching rules are checked before
non-content-checking rules.
7.5 Keeping Things Up-toDate
Periodically download the latest Snort
rules from the Snort home page. This
feature can be automated using various
scripts or plug-ins available from the
variety of tools available from the
community. A popular choice is
Oinkmaster, a series of Perl scripts that
back up the old rules directory, download
the latest, make configurable changes
(even commenting out particular rules!),
and generate a report on the changes in the
new rules as compared to the old
directory. Oinkmaster does a very nice
job, but is not perfect. There are also
some rule-management tools included
with the Snort frontends IDSPolman
(Chapter 12) and SnortCenter (Chapter
11). Or simply write your own Bash script
to download the latest list on a nightly
basis. However, many administrators do
not believe in an auto-update process, as
it can step on finely tuned rules and cause
hours of work to be overwritten. While
sometimes tedious, manually updating rule
sets is the most accurate method of
updating your rules.
The ability to control the changing of
Snort rules is an important element of
good intrusion detection. Any problem
with a download or rule set from the main
Snort repository can prevent Snort from
starting correctly, as has happened in past
rule updates. Manual downloads are the
recommended method, though automated
downloads are still available if the latest
rule sets are required immediately.
7.6 Sites of Interest
Snort-sigs list sigs
Chapter 8. Intrusion
The world of intrusion detection is
starting to change. People are interested in
not only detecting attacks, but preventing
them. This shift of focus has led to the
development of a new class of security
tool, the Intrusion Prevention System
(IPS). While the term IPS bears the strong
odor of a marketing department, the
concept is attractive.
Some of the solutions on the market
(advertised as IPS) are really just network
IDS installed locally on servers and
workstations throughout the enterprise, but
some are truly designed to detect and
prevent intrusions. There are several
intrusion prevention strategies being
developed and deployed, including hostbased memory and process protection
mechanisms, session interception
(sniping), and network firewall/gateway
solutions. The Honeynet project has done
some great work with Snort Inline and
similar technologies in their second
generation Honeypots. You can look at
their work at
8.1 Intrusion Prevention
Several intrusion detection strategies have
been developed, including:
Host-based memory and process
Systems for monitoring process
execution and killing processes that
appear malicious; for example,
processes that are trying to execute a
buffer overflow. These tools are
interesting, but not particularly
related to Snort.
Session interception
Terminates a TCP session by sending
an RST (reset) packet. When the
flexible response plug-in is enabled,
Snort can automatically terminate
TCP sessions that appear to be
hostile attacks using the flexible
response plug in. This feature is also
called session sniping.
Gateway intrusion detection
Snort can block hostile traffic using
Snort Inline (thus acting as a router),
or send messages to other routers
manipulating their access lists to
block hostile traffic using SnortSAM.
Figure 8-1 is Snort running as a session
interceptor using the flexible response
plug-in. When an attack is detected, RST
packets are sent to the hosts, ending the
Figure 8-1. Snort as a session
Figure 8-2 shows Snort running as
firewall/router/IPS. When an attack is
detected, all future traffic from the
attacker is blocked.
Figure 8-2. Snort as a
gateway IPS
Figure 8-3 shows Snort running with
Figure 8-3. Snort managing
access lists on border devices
When an attack is detected, the border
router is directed to block inbound traffic
from the attacking host.
8.2 IPS Deployment Risks
The promise of intrusion protection is
very attractive, but there are some risks
that are not obvious at first glance. These
risks should be considered when planning
to deploy an IPS​including Snort operating
in one of the IPS modes. There is, without
question, a place for IPS in most
environments. Most often, its value can be
best utilized as another layer in a robust
defense-in-depth strategy. Some of the
risks associated with IPS are:
Session interception IPS identification
When a Snort sensor detects an attack
When a Snort sensor detects an attack
and terminates the TCP session with
a RST packet, the characteristics of
the packet may allow the attacker to
determine not only that an IPS was
responsible for the terminated
session, but the type of system the
IPS software is running on. There are
a number of passive operating system
identification tools that analyze how
different operating systems craft and
transmit packets and are then able to
make a guess at the underlying
operating system. One such tool is
p0f (Passive OS Fingerprinting
Tool). By simply listening to the
packets on the network, p0f can
determine what type of machine sent
the RST packet, allowing the attacker
to make a guess at just what IPS
solution is causing the difficulty.
Knowing what he is up against
allows him to craft his attacks to
escape the notice of the IPS, or to
find a way to crash or crack the IPS
Exploit beating the attempted block
If there is a slight lag between the
time the IPS detects the attack and
when it orders a change in the access
control lists of the border device, an
attack might succeed in exploiting the
target and establishing a "backdoor"
connection to another system in the
attacker's control. Even when
everything works as planned with the
IPS and the border device, it may be
too late​another argument in favor of
adopting a defense-in-depth strategy.
Self-inflicted denial-of-service
Altering the source IP address of a
packet is a trivial thing. The packet
still arrives at the destination and
may still trigger an IPS to order an
access control list change on a
border router or firewall, thereby
blocking the forged source address.
If this forged source address is
actually a system that the network
needs, a denial-of-service condition
results. Spoofing the address of DNS
servers prevents name resolution.
Spoofing a mail gateway address
stops email from flowing. Forging
routing peers for border devices
(BGP neighbors) can stop all traffic
from being routed to the Internet as
routing protocols adjust. Most IPS
solutions try to take this into account
by utilizing an exclude list
(sometimes called a white list),
which contains addresses that should
never be blocked, preventing a
denial-of-service. The only problem
is ensuring that the exclude list is
Blocking legitimate traffic
If legitimate traffic is incorrectly
identified as an attack and the traffic
is blocked by the IPS, it can have
serious consequences. Here's an
example. A large ISP in the Midwest
hosts a customer that sells clothing
from a web-based catalog. A very
popular daytime talk show host
mentions how nice the web site is
and the millions of viewers all sprint
to their computers to buy sweaters
and rugby shirts. At first, this looks
like some kind of denial-of-service
attack, flooding the network and
potentially overwhelming the
servers. If an IPS incorrectly
identifies this unexpected activity as
an attack and blocks the millions of
inbound connections, the customer
would have lost a great deal of
money. Careful consideration should
go into the kind of traffic that triggers
an alert and the thresholds that
represent something to be worried
There is no real rule of thumb to follow.
You must understand how your network
operates in its normal (and even extreme
but normal) capacity. The best advice
when considering an IPS is to run it in a
test mode for an extended period of time,
watching what it does during the course of
business, and tuning the thresholds and
alerts so that legitimate traffic is not
blocked. A thorough analysis of blocking
events should be performed over the
course of the life of the IPS to ensure the
accuracy of your testing and assumptions.
False positives can caues an IPS to block
legitimate traffic. Extreme care must be
taken to only enable blocking actions for
alerts that almost never generate false
positives. Such precautions may allow
some attacks through, but they will stop
those that are certainly trouble.
8.3 Flexible Response with
Snort's flexible response plug-in allows
Snort to act as a session interception IPS.
It adds an option to a rule so that when the
rule is triggered, an action is taken. In
environments where the Snort sensor has a
dedicated stealth interface, another
interface should be present to send the
responses. To enable flexible response,
use the following command line when
running configure:
# ./configure -enable-flexresp
# make
# make install
You may also need the libnet library, if it
is not installed. It allows Snort to craft
and inject packets onto the network. It can
be found at
Once Snort is built with flexible response
enabled, you can include several new
options within your Snort rules. The
option uses the following format:
The response keywords that you can add
to the rules are:
Sends a RST packet to the sender of
the packet that generated the alert.
Sends a RST packet to the recipient
of the packet that generated the alert.
Sends a RST packet to both parties in
the TCP session.
message to the sender.
message to the sender.
message to the sender.
Sends all three ICMP responses to
the sender.
For example, to reset a session when
Snort detects that the remote control
software NetCat is in use on port 80, use
something like this:
alert tcp $EXTERNAL_NET any -> $HTT
command attempt"; flow:to_server,es
classtype:web-application-attack; r
8.3.1 The react Response
The react response is useful for
responding to HTTP-based attacks.
Among other things, it lets you send a
message to the client web browser
explaining that access to the offending site
is forbidden. It also knows how to deal
with proxies. The format of the react
response directive is:
The keywords you can use with react
Blocks access to the session when
the malicious content is matched.
Sends a visible warning to the
client's web browser.
The content of this setting is included
with the warning returned to the user.
Indicates a proxy port number to send
the response on, if necessary.
For example, to block access to web sites
that contain the string "naughtyword"
(substitute your own), use this:
alert tcp any any <> $HOME_NET 80 (
react: block, msg;)
8.4 The Snort Inline Patch
The Snort inline patch allows a Snort
sensor to act as a gateway IDS (GIDS). It
is similar in function (although much
simpler) to SnortSAM; the difference is
that the inline patch only allows the sensor
itself to be the gateway. It is also limited
in that it only supports iptables. It is not
commonly used in more complex
To act as a gateway, the Snort sensor has
to be configured with two network
interfaces​one on the internal network and
the other on the external network. Traffic
flows through the sensor. The sensor
becomes the firewall for the internal
network, a firewall based on iptables,
which dynamically drops traffic when an
attack is detected. This sounds very
exciting, but I must remind you to be very
careful when blocking traffic dynamically.
You may cause more trouble than you are
preventing. Only enable blocking for rules
that are almost never going to generate
false positives.
The Snort inline patch requires that
iptables be enabled in the kernel. You'll
also need libnet Version 1.0.x. The Snort
inline patch is downloadable from and is
the full version of Snort, already patched
and ready for compiling. Once the latest
version is downloaded, it is configured,
made, and installed with the following
command line:
# ./configure --enable-inline
# make
#make install
8.4.1 Configuring Snort
Once the inline patch has been installed,
configure Snort using the techniques we've
discussed. It is important to carefully
configure the network variables to ensure
that Snort knows what it is protecting. You
may want to limit the networks that are
watched​only the servers on your DMZ, for
There is no "exclude" or "white" list with
the inline patch. You can perform the same
function by careful configuration of the
$EXTERNAL_NET variable. If you
configure the variable to be the inverse of
the addresses that you never want to
block, you've for all practical purposes
created a white list. Here's a (very
simplified) example. If we want to make
sure that no hosts in the
range are ever blocked, we can do this:
Next, configure the preprocessors
appropriately. We still want to normalize
traffic to increase Snort's ability to match
the signatures within the rules. Output
plug-ins can be used, just like in a normal
Snort sensor.
Do not attempt to use the gateway sensor
the same way you would use a standalone
sensor. Excessive load on your gateway
device can result in performance
problems for the network. Only enable the
services that you need in order for the
gateway to act as a dynamic firewall.
8.4.2 Creating Rules for the
Snort Inline Patch
The Snort inline patch adds two rule
actions, drop and sdrop, and one rule
option, replace. To use drop or sdrop,
replace the alert action in the rule with
one of these new actions. You also have
the option of altering the packet as it
passes through the gateway, making it
harmless to the destination host. Here are
the new rule actions:
Generates an alert as usual but also
drops the packet​it doesn't pass it on
to the internal network at all. This
rule generates an alert and drops the
drop tcp $EXTERNAL_NET any -> $
attempt"; flow:to_server,establ
classtype:misc-attack; sid:1812
Configures Snort to drop packets
matching the rule without triggering
an alert. You can use this feature to
configure Snort to block ICMP echorequest packets​ICMP probes are
annoying and occur all the time.
Simply blocking them without
generating an alert is an adequate
response. The following rule drops
the packet without generating an
sdrop udp $EXTERNAL_NET any ->
content:"|02|"; offset:0; depth
activity; sid:2049; rev:1;)
Replaces the content of the packet
(which matches the content field in
the rule) with the contents of the
replace field. The contents of the
replace field should allow the
meaning of the content to pass
through without allowing the target to
be affected adversely.
Snort signatures try to match strings
within packets to determine if they
are an alert​if the string may also be
inside an email or another document
being transferred on the network. To
make sure that legitimate
communication is not hindered but a
real attack is, you can replace a
potentially dangerous string with a
more innocuous string that still gets
the point across for legitimate uses.
In this case, you can use the replace
option. Here's an example:
alert tcp $EXTERNAL_NET any ->
server,established; content:"~r
When coupled with the iptables firewall
rules, the Snort inline patch lends a great
deal of additional functionality. As long as
proper care is taken and details are
attended to, Snort as a Gateway IDS
(GIDS) has a great deal of promise for a
large number of organizations.
8.5 Controlling Your Border
SnortSAM is a plug-in for Snort that can
be found at It
was developed by a team of people who
saw the value in coupling a strong attach
detection mechanism with the ability to
change access controls on border
devices​stopping an attack in progress.
SnortSAM can order changes in the access
control lists of the following network
border devices:
Checkpoint Firewall-1
Cisco PIX Firewall
Cisco Routers
Netscreen firewall
IP Filter (ipf)​Unix-based OS firewall
Linux ipchains
Linux iptables
Watchguard firewall
SnortSAM consists of two components: a
patch for the Snort sensor itself and the
SnortSAM application, which can be run
on the Snort sensor or another, dedicated
SnortSAM system. SnortSAM allows the
Snort sensor to act as a gateway IDS by
running multiple interfaces, enabling
routing, and running Iipchains or iptables.
When an alert is detected, the ipchains or
iptables access lists are modified to block
traffic from the offending network. More
commonly, a Snort sensor is configured to
modify the access control lists for existing
border devices using SnortSAM. The
requested blocks can be given a specific
lifetime, so that they do not last forever.
8.5.1 Installing SnortSAM
The first step in installing SnortSAM is to
download and unpack the source code.
There are some precompiled SnortSAM
binaries for a wide range of operating
systems that you can use, but I prefer to
compile my own. After downloading the
source, create a directory (I usually put
the source in /usr/local/src/snortsam/ ),
and copy the gzipped tarball to the
directory. To install SnortSAM on your
designated SnortSAM system (could be
the system running Snort or a separate
system altogether​please note that version
numbers will change over time), use this:
# cd /usr/local/src/snortsam
# tar -zxvf snortsam-src-2.23.tar.g
# cd snortsam
# chmod +x
# ./
This creates the binary called snortsam
that you can copy to a directory such as
/usr/local/bin. The above process creates
a binary on FreeBSD, Linux, and Solaris.
To compile for Windows, open the file
called SnortSam.dsp with Visual C++ and
select the project that you want to compile
(Normal, in all likelihood).
8.5.2 Patching Snort to
Enable Support for
Download snortsam-patch.tar.gz from and make a
directory to store the patch source (I use
/usr/local/src/snortsam-patch/ ). Copy
the patch source to this directory. To
apply the patch to Snort (substitute the
path to the Snort source directory), use
# cd /usr/local/src/snortsam-patch/
# tar -zxvf snortsam-patch.tar.gz
# chmod +x
# ./ /usr/local/src/sn
Then recompile Snort.
8.5.3 Starting SnortSAM
Running SnortSAM is simple since it only
needs to be supplied with one argument:
the location of the snortsam.conf file. The
file needs to be built from scratch (I
suggest locating it in /usr/local/etc/ ). You
only need to include the applicable
options for your environment. Append the
desired configuration options in the
snortsam.conf file. When supplying a
pres-hared key, this is simply a string of
characters that both the server and sensor
knows, used to encrypt the traffic. The
snortsam.conf file can include the
following options:
accept < addresses from which to
accept alerts>/< net mask>,< preshared key>
Designates the address of Snort
sensors that are allowed to send the
SnortSAM server blocking requests.
The pre-shared key is used to encrypt
the communication between the
sensor and the SnortSAM server (the
two-fish algorithm is used). Here's
an example:
accept, supersec
defaultkey < pre-shared key>
This is a pre-shared key that needs to
be configured in the snort.conf file
on the sensors, as well. SnortSAM
uses the default key if one is not
specified for a particular sensor.
Here's an example:
defaultkey supersecretdefaultke
port < port number>
The port number that SnortSAM uses
to communicate with Snort sensors
(898 is the default). Here's an
port 6666
dontblock < address or DNS
Specifies hosts that should never be
blocked. This list is referred to as the
White List in the documentation. It
can be a single IP address, a range of
address (address/mask bits​for
example,, or a
hostname. There can only be one
entry per line, but there can be an
unlimited number of lines. Here's an
logfile < filename>
A file that SnortSAM can use to log
its activity. Here's an example:
logfile snortsam.log
loglevel < level>
This defaults to level 2. The default
is suggested, but the options are as
0: Quiet
No logging occurs.
1: Sparse
Only errors are logged.
2: Normal
Errors and blocks are
Additional information
(such as
3: Verbose
are logged as well.
Here's an example:
loglevel 1
include < filename>
You can specify additional files to
include in the configuration.
SnortSAM comes with a list of the
root name servers to include in your
white list called rootservers.cfg.
You could keep another file called
donotblock.conf that contains the
entire white list and include it, as
well. Here's an example:
include rootservers.cfg
This option takes no arguments. If it
is present, SnortSAM runs in
Daemon mode​similar to the -D
option in Snort. Here's an example:
skipinterval <time period>
This defaults to a value of 10
seconds. It causes SnortSAM to
ignore the same block request if it
falls within the specified time
period. Here's an example:
skipinterval 60 secs
skiphosts < integer>
Works with skipinterval and
designates how many blocks are kept
in memory. Here's an example:
skiphosts 30
rollbackhosts < integer>
Tells SnortSAM to keep a record of
the designated number of blocking
requests for each Snort sensor. These
traffic blocks are disabled if the
rollback threshold is exceeded.
Here's an example:
rollbackhosts 20
rollbackthreshold < integer> / < time
If more than <integer> blocking
requests occur in a given <time
period>, SnortSAM "unblocks" the
number of blocks designated in the
rollbackhosts directive.Here's an
rollbackthreshold 30 / 60 secs
rollbacksleeptime < time period>
Tells SnortSAM to ignore new
blocking requests for the specified
period of time, giving SnortSAM
time to catch up and reduce the load.
Defaults to 15 minutes.Here's an
rollbacksleeptime 2 minutes
You need to include configuration
information for the firewalls SnortSAM
will use to block offending addresses.
Below are examples for the Cisco PIX,
ipchains, and iptables. For details on
supporting other firewalls (like
Checkpoint or Watchguard, or Cisco
Routers), refer to the documentation:
pix < ip_address_of_PIX_firewall> <
telnet_password> <
pix < ip_address_of_PIX_firewall> <
username/password> <
Instructs SnortSAM to telnet to the
PIX firewall located at the
designated address, log in with the
supplied password (or, in the second
case, the TACACS or RADIUS
username and password), enter
enable mode with the supplied
password, and generate a SHUN
command. The SHUN command
blocks the offending address,
supplied by the patched Snort sensor.
If the enable password is not
included on the configuration line,
the telnet password will be used for
both.Here's an example:
pix p1xp455w0rd 3n4b
ipchains < interface> < log_option>
SnortSAM uses this option when it's
running on the Linux router running
ipchains. ipchains creates a
blocking rule for the reported naughty
address on the specified interface.
Optionally, a log option can be
designated (log or logall).Here's
an example:
ipchains eth0
iptables < interface> < log_option>
SnortSAM uses this option when it's
on a Linux router running iptables. It
creates a blocking rule for the
offending address on the specified
interface. Optionally, a log option
can be designated. Here's an
iptables eth1
Once the snortsam.conf is built, you can
run SnortSAM, designating the location of
the file:
# /usr/local/bin/snortsam /usr/loca
8.5.4 Supporting the
SnortSAM Output Plug-in
Add a line in the snort.conf on the Snort
sensor so it can send notifications to the
SnortSAM server (this might be the sensor
system itself). Add the following line to
the snort.conf file:
output alert_fwsam: <SnortSam Serve
This tells Snort to send SnortSAM
blocking instructions to the SnortSAM
server located at the designated IP
address. If the server is using a
nonstandard port, it can be designated
here. Finally, include the pre-shared key
that you entered into the accept line in the
snortsam.conf file. These two keys must
match exactly. Here's an example:
output alert_fwsam:
8.5.5 Modifying Rules That
Trigger Block Requests
Once you have the output plug-in
configured, modify the rules that generate
blocking requests. To do this, you'll use a
new rule option, fwsam. It's made up of
these elements:
<which host to block>
Can be src, source, dst, dest, or
destination. Designates which
address should be blocked. In Snort
rules, the source address is always
before the direction indicator (->).
For some rules, the "bad guys" would
be the source and for others, the
destination. Examine what the rule is
doing before making this choice. See
the examples below for an
Duration of block in seconds,
minutes, hours, days, weeks, or
years. A value of 0, or the keyword
PERM, INF, or ALWAYS blocks the
host permanently.
Here are some examples. The
following blocks the destination
address for the packet that triggered
the alert for 1 hour:
alert tcp $HOME_NET !21:23 -> $
cmd.exe banner"; flow:from_serv
content:"(C) Copyright 1985-";
reference:nessus,11633; classty
fwsam: dst, 1 hour;)
The following blocks the source address
for the packet that triggered the alert for
15 minutes:
alert udp $EXTERNAL_NET any -> $HOM
attempt"; content:"|04|"; depth:1;
content:"sock"; content:"send"; ref
reference:bugtraq,5311; reference:u
2003; rev:2; fwsam: src, 15 minutes
8.6 Sites of Interest
The HoneyNet
Snort Inline Patch
Chapter 9. Tuning and
This chapter revolves around controlling
false positives (alerts generated by
nonmalicious activity) and managing the
load on the system running Snort. The
opposite of a false positive is a false
negative​an actual malicious packet that
does not trigger an alert. We will discuss
the causes of missed alerts and some steps
for remediation of this gap. We will
examine some of the challenges
surrounding the initial tuning and
customization of the Snort sensor, as well
as the ongoing challenges of keeping the
information the sensor reports useful. All
your work installing and configuring Snort
is wasted if the real alerts are not noticed,
or lost in the noise of thousands of false
positives. We will also discuss how to
keeps things managed, from "pass" rules
to thresholding and suppression rules.
Many of these strategies are thinly
documented and have arisen from the use
of Snort in very high bandwidth
environments (an OC-48 SONET ring
connecting multiple data centers with
three redundant OC-3s to the Internet).
While these strategies come from
environments that not many users of Snort
will encounter (even in most businesses),
they are useful for anyone running Snort.
9.1 False Positives (False
When examining alerts, remember that
there will always be false positives. False
positives are alerts that Snort classifies as
intrusion attempts, but which are really
benign and can safely be ignored. The
sooner you learn to recognize these false
positives and disable them accordingly,
the better off your system (as well as your
mental health) will be.
The best indicator of a false positive is
that a rule generates a far greater number
of alerts than usual. If you have thousands
of alerts from a single signature and yet
only a small sampling of other alerts, your
IDS may be registering a false positive.
Check the source and destination IP
addresses. If both of the addresses are
within your network, it may simply be a
normal packet that Snort falsely identifies
as malicious. Or it may be normal traffic
coming from a server using some unique
port or protocol. Or it may be a genuine
intrusion attempt, and you'll need to
correct the problem at its source.
The next step in recognizing a false
positive is to check the Snort rule
generating the alert. The rule may simply
be too generic or broad and, as a result,
detect peripheral traffic. In circumstances
such as these, you may want to edit the
rule and redefine its focus. Either disable
the rule altogether or create exceptions to
those machines generating the alerts. You
can also narrow the focus of the rule.
Sometimes user-created rules are not
specific enough or use non-unique
characteristics to trigger an alert. Careful
analysis of the characteristics of captured
attack traffic allows a more specific and
accurate rule to be created.
Physically check the machines generating
the alerts, if at all possible. If a machine
generates alerts within your local network
or WAN, log in securely to that machine
and verify that no one else is causing the
type of network traffic generating the
alerts. Chances are the machines are not
compromised but are sending valid
network traffic that happens to trigger an
alert. If the alerts are originating outside
your network, check the machines being
targeted. If they are high-profile, the alerts
may in fact be valid. However, your
machines may simply be issuing their own
queries outside the network and the
replies are being logged as an alert.
Be careful not to discount alerts and deem
them false positives too quickly. Check
the rule causing the alerts first. Portions of
the signature that match the offending
packet can be found within the rule. Make
certain the machines affected by these
alerts have not been actually
compromised. Finally, check the alerts
themselves to make certain they are truly
benign and can be safely ignored. The
importance of actually looking at the
packet that generated the alert using an
interface like ACID cannot be
Sometimes false positives indicate a nonsecurity-related issue, such as faulty
hardware, misconfigured network
equipment, or poorly (or oddly) written
network-aware software. While not a
security issue, these can be important
issues for a network or system
administrator. Don't disable a rule or
ignore a series of alerts without
investigating the root cause.
9.2 False Negatives (Missed
False negatives​genuine attacks that aren't
noticed​are obviously a problem. False
negatives are hard to quantify​it's difficult
to figure out what you don't know​but there
are steps that an administrator can take to
help keep the incidence of false negatives
at a minimum. Sometimes other
components of your defense-in-depth
strategy (i.e., syslogs or weblogs) will
show signs of attack that the IDS is not
alerting on.
9.2.1 Common Causes of
False Negatives
Here are some common causes of false
negatives (missed alerts) and suggestions
for remediation:
Traffic encryption. As discussed in
Chapter 6, the placement of an IDS
sensor is critical. Encrypted traffic
does not trigger alerts because the
signature patterns don't match. It may
be possible to address this by
placing the sensor on the network
behind the device performing the
encryption (SSL Accelerator, VPN
Concentrator, and so on) where the
traffic is clear text. There will likely
be some traffic that cannot be
monitored.Network configuration
problems. Mistakes in sensor
placement or complexities of
network infrastructure may cause
some traffic to be missed by the
Snort sensor. If there are multiple
paths into a network, the sensor may
not be able to see all inbound and
outbound traffic. If a switch is
configured to span several ports to
allow a Snort sensor to monitor the
traffic, the aggregate bandwidth
being spanned may exceed the
bandwidth capacity of the port the
sensor is plugged into. For example,
6 ports running at sustained 20 Mbps
will have an aggregate bandwidth of
120 Mbps. This situation clearly
exceeds the capacity of a 100 Mbps
Fast Ethernet span port (discussed in
Chapter 6). Multiple sensors or a
Gigabit Ethernet port may be called
for. Some of the more extreme
measures discussed in Chapter 13
may need to be considered, as
well.Day zero attack. Snort is a
signature-based IDS; if an attack or
exploit occurs for which there is no a
signature, it will go undetected. The
signatures for Snort are updated
frequently and you should establish
for keeping the signatures as up-todate as possible (see Chapter 7 for
Faulty signatures. It may be that a
signature is written incorrectly
(common in user-developed rules
that have not been peer-reviewed)
and are not watching for the correct
attack signature. A variant of an
attack might not trigger the same rule
as its ancestor. Thorough testing of
user-created rules and keeping up-todate with signatures is the best way
to address this issue (see Chapter 7
for details).
Poor change management. Very
often there are separate departments
in an organization that handle
network administration, server
administration, workstation support,
and security. If these departments do
not communicate well, changes that
affect the security posture of an
environment may go unnoticed by the
security team. There is no
replacement for good communication
between information technology
Snort sensor administration
problems.. If, in the course of
overzealously tuning the Snort rule
set to control false positives, an
administrator eliminates an important
rule, an attack or probe may go
unnoticed. Later in this chapter, we'll
discuss strategies that help to
establish a procedure for organizing
a reasonable rule set.
It may be possible that the system is
under too much load to keep upwith
the packets the sensor is tasked to
watch. Careful monitoring ofthe
system is required to ensure that the
sensor can keep up. See Chapter 13
for ways to watch highbandwidth or
particularly demanding network
Later in the chapter, we discuss ways to
limit the number of alerts generated for a
particular rule or a particular host. It is
also possible to suppress alerts entirely
for a particular rule or host. However, if
you aren't careful, you may miss real
security events or give them less priority
than they should have. For example, an
Internet worm-infected host might generate
thousands of alerts in a very short period
of time​w hich should quickly get an
administrator's attention. But if
thresholding (or another alert throttling
technique) is enabled, the same host
would generate far fewer alerts, attracting
far less attention. Controlling the number
of alerts for a particular event can
dramatically reduce system load and
administrative workload, but it does carry
some risk.
9.3 Initial Configuration and
Spending some time pruning the rules and
features that Snort uses pays dividends.
Your decisions in this phase of tuning
have the potential to make your life as an
administrator much easier. Be careful,
though. Mistakes at this point have serious
consequences. There are some easy, lowrisk things you can do, however. The
suggestions below provide a place to start
and will help address the majority of the
sources of false positives. As an
administrator is able to establish a
baseline for what is "normal" for the way
their network is used, further tuning and
customization is possible. It should be
mentioned that when you make changes to
the snort.conf file or the rules, you must
stop the Snort process and restart it for the
changes to take effect.
9.3.1 Tailoring the Decoder
and Preprocessors
Anyone who watches a network with a
connection to the Internet will tell you that
the volume of port-scanning traffic, wormrelated attempted exploits, and scripted
attacks against arbitrary ranges of
addresses is constantly increasing. A
Snort sensor watching this traffic
generates many alerts​particularly the
portscan components. While the alerts
generated as a result of this traffic might
be an indicator of the initial phazes of an
attack, the usefulness of these alerts is
questionable given their volume. Tracking
down the source may be difficult,
too​particularly if the system is located in
another country. Sometimes the source is a
worm-infected workstation sitting behind
a shared IP address. While it might be
possible to track the source to a particular
organization, the work involved in
notifying that organization of the infected
system (and the time that you spend
explaining how you noticed and how to
find the offending system) is a drain on
your resources.
When configured to monitor the Internet
connection for an organization, many Snort
preprocessor settings are vestigial and
really only serve to generate false (or
relatively low-value) alerts. Some of the
preprocessors alert on packet anomalies
that are not of significant concern when
trying to detect attackers. Many of these
alerts can be eliminated by making
changes to the preprocessor options in the
snort.conf file. (These alerts can be useful
when the Snort sensor is being used for
more than just intrusion detection.)
In Chapter 6, sensor placement strategies
were discussed that can help manage the
type of traffic the sensor watches. For
instance, if the sensor is placed behind the
firewall instead of on the public side, the
firewall will de-fragment packets
(fragmenting packets is a common IDS
evasion technique). One of the most CPUintensive preprocessors is the frag2
preprocessor, which rebuilds these
fragmented packets. If the sensor is behind
the firewall, this preprocessor can be
Below are some changes that can be made
to the snort.conf file to eliminate many
common false positives. The Snort decoder
To enable these options, delete the # at the
beginning of the line in the snort.conf file.
These entries are a way to enter
command-line options that will be the
same every time you run Snort. The
majority of alerts generated by leaving
these alerts enabled are false. It is
recommended that the config entries
below be uncommented, which enables
them. It seems strange to say, "enable the
disabling of these alerts," but there you go.
config disable_decode_alerts
config disable_tcpopt_experimental_
config disable_tcpopt_obsolete_aler
config disable_tcpopt_ttcp_alerts
config disable_tcpopt_alerts
config disable_ipopt_alerts The flow preprocessor
The flow preprocessor is used to unify all
flow-related plug-ins and preprocessors.
As of Snort 2.1.0, the only functionality
built into this preprocessor is some
portscan detection routines. This
preprocessor must be enabled for the
flow-portscan preprocessor to work. If an
administrator is not interested in watching
portscan activity, this preprocessor can be
disabled. If you choose to disable flow,
the line should look like this:
# preprocessor flow: stats_interval The frag2
If the Snort sensor is positioned behind a
firewall or router that does fragment
reassembly (most firewalls, including
Linux-based ones and the Cisco PIX, do
fragment reassembly), the frag2
preprocessor can be disabled. To disable
this preprocessor, comment out the line. If
you decide to disable frag2, the line
should look like this:
# preprocessor frag2 The
A variety of non-security-related issues
can cause stream4 reassembly errors. To
disable notification of these errors, add
the noalerts configuration to the default
line. It should look something like this:
preprocessor stream4_reassemble: no The http_inspect
While the alerts that this preprocessor
generates can be interesting when
troubleshooting some web proxy server or
network infrastructure problems, it is
largely just noisy. It is best not to just
disable the preprocessor, though. The
suggestions in Chapter 5 shows how to
tune this component for the web servers in
your environment. The assistance it
provides in allowing web traffic to be
inspected is very valuable, but some
network configurations result in thousands
of false positives. To disable alerting for
this preprocessor, add the no_alerts
configuration to the line. The modified
default line from snort.conf file is below:
preprocessor http_inspect_server: s
profile all ports { 80 8080 818 The flow-portscan
The flow-portscan preprocessor is the
first (and currently only) flow-based plugin. If the flow preprocessor is disabled to
allow the administrator to ignore portscan
alerts, this configuration line should be
disabled, as well. This preprocessor is
disabled by default (it can still be
considered test code). The lines will look
something like this:
# preprocessor flow-portscan: \
talker-fixed-threshold 30 \
talker-sliding-threshold 30
talker-sliding-window 20 \
talker-fixed-window 30 \
scoreboard-rows-talker 3000
server-watchnet [
server-ignore-limit 200 \
server-rows 65535 \
server-learning-time 14400
server-scanner-limit 4 \
scanner-sliding-window 20 \
scanner-fixed-threshold 15
scanner-sliding-threshold 4
scanner-fixed-window 15 \
scoreboard-rows-scanner 300
src-ignore-net [
dst-ignore-net [
alert-mode once \
output-mode msg \
tcp-penalties on
9.3.2 Tailoring the Rule Set
Here are some guidelines for tailoring
your rule sets. General rule set
pruning (trimming high
noise rule sets)
By default, the following rules are
disabled (as mentioned in Chapter 7, you
can disable a set of rules contained in a
.rules file by using a # as the first
character of the line or deleting the entire
line in the snort.conf file). For most
applications, it is best to leave these
# web-attacks.rules
# backdoor.rules
# shellcode.rules
# policy.rules
# porn.rules
# info.rules
# icmp-info.rules
# virus.rules
# chat.rules
# multimedia.rules
# p2p.rules
The following are sources of false
positives and can be disabled in most
deployments. Before disabling the
misc.rules file, read through it. Some of
the alerts provide warnings for suspected
worm activity. You may elect to disable
individual rules themselves, leaving the
worm-related rules operational (see
Section, below):
# icmp.rules
# misc.rules
# nntp.rules
# finger.rules
If you are not running a Coldfusion
application server, disable the following
rule set:
# web-coldfusion.rules
If you are not running FrontPage
Extensions on any web servers in your
environment, disable the following rule
# web-frontpage.rules
If you are not running PHP application
services in your environment, disable the
following rule set:
# web-php.rules
If you are not running an Oracle database
in your environment, disable the following
rule set:
# oracle.rules
If you are not running a mySQL database
in your environment, disable the following
rule set:
# mysql.rules
If you are not running a Microsoft SQL
Server in your environment, disable the
following rule set:
# sql.rules
If you do not have Unix systems in your
environment, disable the following rule
# rpc.rules
# rservices.rules
# x11.rules
If you do not have Microsoft Windows
systems in your environment, disable the
following rule set:
# netbios.rules
If you do not run an Apache web server in
your environment, disable the following
rule set:
# web-cgi.rules
If you do not run a Microsoft Internet
Information Services (IIS) web server in
your environment, disable the following
rule set:
# web-iis.rules
The following rules sets are useful and
result in false positives less often than
most (keep these enabled in most
attack-responses.rules Tuning individual
Further tuning may be performed by
disabling individual rules inside the .rules
files. Disabling individual rules in a rules
files is the same as disabling rule sets in
the snort.conf file (by using a # or
deleting the entire line). This should not
be done without careful consideration.
You risk missing valid alerts if you do not
fully understand the rule being disabled.
Many administrators disable the
misc.rules file in their first tuning pass.
It's normally a good idea, since there are
many high-noise signatures in this rule set.
But there are some excellent Internet
worm-detection signatures. Consider
disabling the high-noise signatures and
leaving the worm-related signatures
When you're running Snort behind a
firewall and using it primarily to watch an
Internet connection, you can tune it to
watch just the services allowed through
the firewall. Most corporate firewalls do
not allow the bulk of network traffic
through to the internal network. Disabling
these rules decreases your ability to detect
malicious activity outbound from their
environment, however. And detection of
attacks sourced from inside the network
can be important.
9.4 Pass Rules
When compared to the new suppression
rules, pass rules are a clumsy and
lumbering way to address the need to
ignore alerts from certain hosts, networks,
or rules. A poorly written pass rule can
cause all signatures to be passed, making
the Snort sensor useless. For example, if a
pass rule is written to ignore alerts for a
range of network addresses on TCP port
23, actual attacks may go unnoticed.
Thresholding and suppression rules
should be used instead of pass rules.
9.5 Thresholding and
Threshold and suppression rules were
first introduced in Snort Version 2.0.0.
They allow an administrator to control
how many alerts are generated from (or
to) a given host or for a particular
signature. Unfortunately, they were very
thinly documented and (while it might get
me in a bit of trouble with the folks at
Sourcefire) were a little buggy. Snort
2.1.x not only fixes the problems, it also
introduces global thresholds. Global
thresholds let you control alert volume for
all rules. Threshold and suppression
commands are, by convention, placed in
the threshold.conf file in the same
directory as the rule sets. While this is not
required, it is a good idea to keep them in
one place. Threshold and suppression
rules can track by source or destination IP
address. Sometimes a signature alerts on
an inbound attack packet or an outbound
response to an attack. It should be noted
that suppression rules are applied before
thresholding rules.
9.5.1 Simple Thresholds
Threshold rules come in three flavors
(excerpt from the README.thresholding
Alert on the first M events during the
time interval, then ignore events for
the rest of the time interval.
Alert every M times this event is
seen during the time interval.
Alert once per time interval after
seeing M occurrences of the event,
then ignore any additional events
during the time interval.
Threshold rules can be incorporated into
the rule definitions themselves or built as
standalone rules. The administrative ease
of keeping the threshold rules in one place
argues against incorporating them into the
rules directly. When scattered among the
rule sets, threshold rules can be hard to
find. There are, however, some instances
when it makes sense to incorporate the
threshold components to a rule.
Here's an excerpt from the
README.thresholding file:
There is no functional difference
between adding a threshold to a
rule, or using a separate threshold
command applied to the same rule.
There is a logical difference. Some
rules may only make sense with a
threshold. These should incorporate
the threshold command into the rule.
For instance, when security policies are
set to lock out an account after four bad
password guesses, alerting on the fifth bad
guess is appropriate. Such a threshold can
be incorporated into the rule itself.
When incorporating thresholds into rules,
the following format is used:
threshold: type [limit|threshold|bo
Here are some thresholding examples:
Limit type
Logs the first event to a particular
destination IP address of this
signature every 60 seconds:
alert tcp $LOCAL_NET any ->
directory traversal attempt"; f
nocase; classtype:web-applicati
type limit, track_by_dst, count
Threshold type
Logs every twentieth event on this
signature during a 60-second
interval​so if less than 20 occur in 60
seconds, nothing gets logged. Once
an event is logged, a new time period
starts for type=threshold. This
might be used to watch for the 403:
Forbidden web responses where the
administrator is concerned when the
incidence of this event becomes too
alert tcp $HTTP_SERVERS $HT
RESPONSES 403 Forbidden"; flow:
depth:12; classtype:attempted-r
count 20, seconds 60; sid:1201;
Both type
Logs at most one event every 120
seconds if at least 4 events on this
sid are fired. This is the example
given previously, in which an
account locks after four bad guesses.
Only one alert would be generated
for a locked account every two
alert tcp $SQL_SERVERS 1433
failed"; content: "Login failed
server,established; classtype:u
dst, count 5, seconds 60; sid:6
Standalone thresholds are written
with the following syntax:
threshold gen_id gen-id, sig_id
src|by_dst], count n , seconds
The main difference between standalone
thresholds and those incorporated into
rules is the inclusion of the gen_id and
the sig_id parameters. These are needed
in the standalone threshold rules to specify
the rule and generators to which the
threshold applies. As discussed in
Chapter 7, gen_id refers to the Snort
generator involved and sig_id is the
unique identifier for the rule the threshold
is being applied to. Only one threshold
can be applied per unique sig_id. Most
often, the gen_id is set to 1 (the Snort
Rules Engine).
Here's how you would limit to logging 1
event per 120 seconds for the signature
with the sig_id of 1,759 (MS-SQL
xp_cmdshell program execution):
threshold gen_id 1, sig_id 1759, ty
And limit to logging every fifth event in
120 seconds for the same signature:
threshold gen_id 1, sig_id 1759, ty
And limit to logging just 1 event per 60
seconds, but only if we exceed 50 events
in 60 seconds:
threshold gen_id 1, sig_id 1759, ty
9.5.2 Global Thresholds
Global threshold commands are the same
as standalone thresholds, except the
sig_id is parameter is set to 0 to indicate
"all rules."
Here's how you would limit to logging 1
event per 120 seconds per IP triggering
any rule generated by the Snort rules
engine tracking by source address:
threshold gen_id 1, sig_id 0, type
And here's how you'd limit to logging 1
event per 120 seconds per IP triggering
any rule for any Snort event generator
component tracking by destination
threshold gen_id 0, sig_id 0, type
9.5.3 Suppression Rules
Suppression rules are similar in syntax to
standalone threshold rules. Suppression
rules can suppress alerts by signature, by
source or destination address, or by an
entire CIDR network block. This
flexibility has considerable power. Care
must be taken to only suppress the correct
alerts or addresses. An administrator
could inadvertently suppress legitimate
Suppression rules are written with the
following syntax:
suppress gen_id gen-id, sid_id sid-
Suppress this event completely:
suppress gen_id 1, sig_id 114
Suppress this event from this source IP
suppress gen_id 1, sig_id 114, trac
Suppress this event to this destination
CIDR block:
suppress gen_id 1, sig_id 114, trac
Chapter 10. Using
ACID as a Snort IDS
Management Console
Running Snort from the command line and
using tail -f to watch the alert log file
is fine when testing or experimenting. But
when you want to use Snort to protect your
network, you need better analysis and
monitoring tools. ACID (the Analysis
Console for Intrusion Detection) is an
open source project developed by Roman
Danyliw at the CERT coordination center,
as part of the AIRCERT project. It uses a
PHP-based web application that can act
as the frontend for several tools​w e will
only discuss using ACID with Snort in this
chapter. ACID interfaces with the
database that Snort uses to log alerts.
ACID should be considered beta software
and may be vulnerable to user input
validation problems. Care should be taken
to secure access to the ACID console
(discussed further below). The current
version is 0.9.6b23; it has not been
updated since January of 2003. It still
does an outstanding job in acting as a
Snort alert console, but the recent changes
in Snort (namely the move from the
portscan2 and conversation preprocessors
to flow-portscan) have exposed some
problems. I still prefer ACID over almost
any other open source solution (there are
some commercial products that can act as
a management console for Snort, too).
ACID was designed to help a security
administrator manage the alerts generated
by multiple IDS sensors. ACID can
generate trending information and allow
searches based upon time, address, alert,
priority, classification, or sensor. The
alert display includes all information
about the rule that generated the alert, as
well as all the configuration information
(including payload) of the packet that
generated the alert. It is an invaluable tool
for Snort administrators.
This chapter discusses the installation of
ACID with Apache on Unix-based
systems, primarily because most of the
components that ACID requires were
developed using this setup and you will
have a more reliable experience using the
native configuration. We will use MySQL
as the database backend. If you would like
to install ACID on a Windows system,
there are several tutorials available on the
10.1 Software Installation
and Configuration
The various components of an ACID
installation each have their own
dependencies on other components. It is
important that the components on which
they depend are installed first. The
instructions below are written in a
specific order with this in mind. Here's
summary of dependencies for the
MySQL Support
GD Support
OpenSSL Support
MySQL Support
GD Support
OpenSSL Support
MySQL Support
The Linux distribution used in this chapter
for both the management console and
sensor is the latest Red Hat Linux. These
instructions should work for both Red Hat
Enterprise and Fedora Core. Nuances
particular to these distributions are
explained in greater depth. This does not
mean the same explanations cannot also be
used on other Linux distributions.
The installation mechanism or package
management system on some operating
systems may allow you to simply install
the latest version of ACID, taking care of
all the dependencies automatically. This is
an attractive alternative for quick
deployments or inexperienced users.
FreeBSD, Suse Linux, Debian
GNU/Linux, and Gentoo Linux are all
examples of operating systems with robust
package management systems. From a
performance and troubleshooting
standpoint, it is usually better to install
things from source. The choice is
yours​ease of use versus performance.
10.1.1 MySQL Installation
and Configuration
The first step is to configure MySQL
correctly. To facilitate ease of
installation, my recommendation for new
users is to use the MySQL release that
comes with the Linux distribution CDs.
However, you may prefer compiling from
source or using the latest binaries. The
following instructions are geared toward a
Red Hat Linux RPM install, although an
explanation for installing MySQL entirely
from source also follows. You can
download the RPMs, source, or binaries
from the MySQL homepage
( MySQL RPM install
To install MySQL using the RPMs
distributed with Red Hat Linux, execute
the following rpm command within the
directory containing the RPMs. You may
want to do this during the initial Linux
installation phase; if you do it later, you
will have to mount the distribution CD and
then change to the directory in which the
RPMs are located:
# mount /dev/cdrom /mnt/cdrom
# cd /mnt/cdrom/RedHat/RPMS/
# rpm -ivh mysql-*
This command installs three packages:
mysql, mysql-devel, and mysql-server.
Once the packages are installed, start the
MySQL daemon using the start command.
Log in and configure the root password
for the database server. Also, create the
Snort database for later use with the
intrusion detection system.
# /sbin/service mysqld start
# mysql -u root
mysql> set password for \
mysql> create database snort;
mysql> exit
Some systems may generate the following
Can't connect to local MySQL server
This error message occurs when the
database looks for a MySQL socket in the
/tmp directory when it really is in
/var/lib/mysql/. Execute the following
commands to rectify this error:
cd /tmp/
ln -s /var/lib/mysql/mysql.sock m
cd /var/lib/mysql
touch mysql.sock
Check the permission and path on the
/tmp/mysql.sock to verify it is
symbolically linked to the main MySQL
file using the ls -la command.
In Red Hat Linux, the mysqld service does
not automatically start if you boot into run
level 3 or the console run level. Enable
this service in run level 3 by using the
chkconfig command or the serviceconf
command within a GUI environment. Here
is how you enable the mysqld service in
run level 3 using chkconfig.
# /sbin/chkconfig --level 3 mysqld
You'll be prompted for a root password
upon login in order to access the database
files. Enter the new password at the
# mysql -u root -p
Do not confuse the MySQL root
password with the Linux root
password. They are independent of
each other. Do not use the same
password for the MySQL root and the
Linux root. Performing a
MySQL source install
If you are compiling from source, start by
uninstalling any precompiled (RPM)
versions of Apache, MySQL, and PHP.
Execute the following commands if you
are certain you wish to run everything
from source code you've compiled
yourself. Verify which versions of
MySQL and Apache are installed.
# rpm -e mysql mysql-server mysql-d
Remove the installed Apache and PHP
# rpm -e httpd httpd-devel php
If there are any complaints of broken
dependencies, remove them as well.
Place the downloaded MySQL source
code in a standard location and
uncompress the file.
# gunzip -c mysql-4.0.xx.tar.gz | t
Next, create a mysql user and group. Most
Linux distributions create a group with the
same name as that of the user at the same
time the user is created. Users of
FreeBSD and Solaris should create the
group in addition to the user.
# useradd mysql
Add an entry to your /root/.bash_profile
file that points to the location of the
MySQL binaries and default directory.
You may also add this to the /etc/profile
file so that it applies to all users. Add a
line such as the following:
Change to the uncompressed MySQL
directory and run the following commands
as root:
cd /mysql-4.0.xx/
./configure --prefix=/usr/local/m
make install
This compilation process may take some
time, depending on the speed of your
machine and the size of the latest source
release. When the process is complete,
run the following script also found in the
scripts/ directory within the MySQL
source. This creates the default tables and
provides additional information on
securing and starting the MySQL server.
Take careful note of the information
displayed. I suggest copying the text to a
file for later reference.
# bin/mysql_install_db
Change the permissions on some of the
newly created directories and copy over
the configuration file to a standard
chown -R root /usr/local/mysql
chown -R mysql /usr/local/mysql/v
chgrp -R mysql /usr/local/mysql
cp support-files/my-medium.cnf/ e
This setup permits the basic MySQL
daemon to run, but you need also make
Linux aware of the new libraries. Add the
following lines to the /etc/ file.
Run the /sbin/ldconfig script after the file
has been changed.
# /sbin/ldconfig
You should be ready to start up the
MySQL server. Start the daemon using the
example provided:
# /usr/local/mysql/bin/mysqld_safe
After executing this command, verify that
the daemon is running by using the
following command, which "greps" out the
MySQL process using the ps command.
You should see at least one running
MySQL process.
# ps -ef | grep mysql
Place the previous startup command in the
/etc/rc.d/rc.local file to automate startup
of the daemon process upon bootup. Or,
do as recommended by the MySQL
authors and use their script in place of an
addition to the rc.local file. Here is how
they suggest automating the MySQL
cp /usr/local/src/mysql-4.0.xx/su
cd /etc/rc3.d/
ln -s ../init.d/mysql S85mysql
ln -s ../init.d/mysql K85mysql
cd /etc/rc5.d/
ln -s ../init.d/mysql S85mysql
ln -s ../init.d/mysql K85mysql
cd ../init.d/
chmod 755 mysql
MySQL should be fully functional. We
will now create our tables and configure
the web server with PHP. Adding tables and
This section explains how to add the
required tables the snort database created
in Section 10.1.1. Use the script
create_mysql to add the required tables.
The latest version of this script is
available within the Snort source code in
the contrib/ directory. There is also a
version of ACID and several other thirdparty applications and scripts useful for
adding functionality to Snort and ACID.
To install this script, place a call to it
from the mysql prompt. Remember that
you created a Snort database on your
MySQL server. If you neglected to
perform this step or simply forgot, here is
the command once more, along with the
call to the create_mysql script using the
full path.
# mysql -u root -p
mysql> create database snort;
mysql> connect snort;
mysql> source /usr/local/src/snort-
After connecting to the database and
adding the tables from the included script,
grant the correct permissions to the users
connecting to the database.
The default administrative user is "snort".
When logging in as the Snort user, you
have root privileges and may delete any
and all data or alerts within the database.
Use caution when issuing any commands
as "snort" or "admin" or whatever user
you decide should have administrative
Some Snort users also recommend
installing the file snortdb-extra.gz found
in the contrib/ directory. Install this file
the same way you would the
script. Or, if you are
feeling adventurous, here is another
method that works well:
# zcat /usr/local/src/snort-2.1.x/c
Enter password:
A prompt for the Snort user password
appears. It may take some time to extract
all the information, but when complete, the
data helps to make items on the ACID
website more readable.
Here are the commands to use the
create_mysql script and grant rights to
your primary user:
# mysql -u root -p
mysql> connect snort;
mysql> source create_mysql;
[email protected];
Replace the variable
"" with the Fully
Qualified Domain Name (FQDN) of your
system. If you later change the name of
your machine, you should also update this
final variable.
This next step creates a user login that
cannot delete alerts from the Snort
database, but may only view the database
and associated alerts. This user is named
"acidviewer" since they may view the
ACID web page, but cannot make any
changes. This is the suggested login for
management, nontechnical users, and
others who should not be allowed to
remove important alerts before you can
review their severity.
Set the passwords for the MySQL
accounts. You can allow users to connect
from as broad or narrow a set of hosts as
you prefer. The percentage symbol (%)
operates as a wildcard and allows the
snort and avidviewer users to connect
from virtually any host. Customize the
options to limit the locations from where
they can connect.
mysql> connect mysql;
mysql> set password for 'snort'@'lo
mysql> set password for 'snort'@'ww
mysql> set password for 'snort'@'%'
mysql> set password for 'acidviewer
mysql> set password for 'acidviewer
mysql> set password for 'acidviewer
mysql> flush privileges;
mysql> exit
The MySQL command stating the
machine's full name is optional. If you
only use the first two options and do not
set the FQDN of the system, the
SnortCenter configuration may fail when
you try to run it, or you may have
problems connecting to the MySQL
database. Even though the % wildcard
should handle this situation, I like to make
certain all options work for my particular
Once you have set all the variables, verify
who has what permissions. Connect to the
mysql database and issue the following
# mysql -u root -p
mysql> connect mysql;
mysql> select user,host from user;
You should have a full table displaying all
database users and listing who has access
to which database. The formatting may be
a bit off, so make your terminal window
full screen in order to display as much as
mysql> select user,host from user;
| user
| host
| acidviewer | %
| snort
| %
| localhost
| acidviewer | localhost
| root
| localhost
| snort
| localhost
| |
| acidviewer | |
| root
| |
| snort
| |
10 rows in set (0.01 sec)
According to the previous table, MySQL
has blank user accounts. This means
anyone can log into the database server.
To eliminate this security hole, do the
mysql> delete from user where user=
Query OK, 2 rows affected (0.09 sec
mysql> delete from db where user=""
Query OK, 2 rows affected (0.00 sec
mysql> select user,host from user;
You should now see only the following
lines when the same command is executed
(the empty accounts have been removed):
mysql> select user,host from user;
| user
| host
| acidviewer | %
| snort
| %
| acidviewer | localhost
| root
| localhost
| snort
| localhost
| acidviewer | |
| root
| |
| snort
| |
8 rows in set (0.00 sec)
This is yet another small security measure
to ensure the safety of the network
management console machine. Cleaning house or
If you later decide that you either want to
perform a clean update or start your
databases anew, it is easiest to drop the
databases you created. To drop all the
databases, perform the following:
# mysql -u root -p
mysql> show databases;
| Database
| mysql
| snort
| snortcenter |
| test
4 rows in set (0.00 sec)
mysql> drop database snort;
mysql> drop database snortcenter;
mysql> exit
This should be done only if you are
willing to delete all the information
gathered from your network. Once you
drop a database, the stored entries are
gone. Create the databases again and start
over. When updating to a new release of
Snort, you may need to create a new
database into which you plug the new
10.1.2 Installing the Web
This section provides a basic rundown on
configuring the Apache HTTP server. It is
by no means intended to be a
comprehensive set of instructions for
setting up Apache. Consult a more
complete reference guide for additional
instructions on customizing this or other
web servers.
There are a several methods of installing
and configuring Apache. The first is to use
the existing Apache RPMs included with
your Linux distribution or download the
latest RPMs from your Linux distributor
or another trusted RPM source. Red Hat
Fedora currently ships with the Apache
2.0.x RPMs.
There are two versions of Apache
available for production use. I cover only
Version 2.0.x using both RPMs and source
code. Some people may prefer older, tried
and tested Apache releases compiled from
source, but it is best to update to the most
recent release.
10.1.3 Installing Apache2
Because Apache release 1.3.x will
eventually be deprecated and no longer
supported by the Apache group,
familiarize yourself with the latest
Apache2 release. Check the Apache web
page ( for the
most recent code and documentation. This
section is intended for Linux users using
the default Apache RPMs rather than
compiling recent Apache versions from
source. Most Linux distributions are
releasing Apache Version 2 as well. Installing from
If you have not already done so during the
initial Linux configuration, download the
RPMs or install them from the distribution
CDs. The latest Apache RPMs for Red
Hat Linux can be found at the following
Change to the correct directory to reflect
your Linux release. There are only a few
packages needed for the Apache web
server. Here is an example Apache install
using RPMs. This example also shows
how to verify that the Apache web
daemon starts upon bootup. Replace any
version numbers that may differ here with
the correct ones.
rpm -ivh httpd-2.0.xx.i386.rpm
rpm -ivh mod_ssl-2.*.i386.rpm
rpm -ivh php*.i386.rpm
chkconfig --level 2345 httpd on
/etc/rc.d/init.d/httpd start
Check that your web server is running by
bringing up a web browser either on the
local box or on a networked machine and
connecting to the default Apache web
page. Use any of these variables for
connecting to the web server: the
machine's fully qualified domain name, its
IP address, or localhost if attaching
locally. Compiling the latest
Apache code from source
Although compiling the latest release of
Apache code from source appears more
tedious and time-consuming than RPMs,
you may soon discover that compiling
source code is perhaps one of the most
rewarding aspects of Linux and open
source applications in general. It not only
allows you more flexibility with related
applications, but there is something
satisfying about creating custom binaries.
Besides, it is more secure to access the
code first-hand and create your own
binaries using source downloaded from a
trusted location. It would also be a good
idea to verify PGP signatures or MD5
checksums for the downloaded source, to
ensure integrity.
A precursor to compiling Apache may be
to install OpenSSL from source,
particularly if you are going to enable the
SSL module. Here are the steps to
compile OpenSSL.
gunzip -c openssl-0.9.6g.tar.gz |
cd openssl-0.9.6g/
make test
make install
Although this is an older OpenSSL
release and newer versions are
available, some Snort-centric
applications prefer this particular
version. Be aware that there may be
some security considerations for
running an older version.
Once all necessary required libraries are
installed, place the latest Apache source
code in a standard directory. Uncompress
the file and change to the new directory.
Use the following commands for
configuring and compiling the source. In
this instance, we use /usr/local/httpd as
the default directory. This is the Apache
root directory for Version 2.0.x. Only the
prefix name and the so module require
enabling in the example provided. I have
added additional modules should users
wish to enable these as well.
# gunzip -c httpd-2.0.xx.tar.gz | t
# cd httpd-2.0.xx/
# ./configure --prefix=/usr/local/h
--enable-so --enable-cgi --enable-i
--enable-speling --enable-usertrack
# make
# make install
When this is complete, change to the
uncompressed PHP source code located in
the same directory. Run the following
commands to configure it for integration
with Apache2.
# cd ../php-4.3.x/
# ./configure --prefix=/usr/local/h
--with-mysql --enable-track-vars \
--enable-force-cgi-redirect --with--with-gettext --with-gdbm --with-g
# make
# make install
# cp -p .libs/ /usr/local
# cp php.ini-dist /usr/local/httpd/
Edit the httpd.conf file located in
/usr/local/httpd/conf/ and enable the
newly installed PHP modules. The
following lines are added to the
httpd.conf file. These entries may already
be present, depending on your installation.
# Make sure there's only **1** line
LoadModule php4_module modules/libp
# Add index.php to your DirectoryIn
DirectoryIndex index.html index.php
AddType application/x-httpd-php php
Finally, automate the startup of the new
Apache web daemon. This is done in one
of two ways: by adding the following
lines to /etc/rc.d/rc.local or using the
script that comes with the source. Here
are the lines to add to the rc.local file.
# Start the Apache web daemon
/usr/local/httpd/bin/apachectl star
Follow these steps for integrating the
included script into the startup run
command directories.
apachectl /etc/init.d/httpd
-s ../init.d/httpd S85httpd
-s ../init.d/httpd K85httpd
-s ../init.d/httpd S85httpd
-s ../init.d/httpd K85httpd Testing Apache and
Test the new Apache install to verify PHP
has been successfully integrated. Create a
file in /usr/local/httpd/htdocs/ called
test.php. Place the following line of code
in the file:
<?phpinfo( )?>
Finally, start up the new Apache daemon
in one of the following ways. You can do
# /etc/rc5.d/S85httpd start
Starting httpd:
or execute the daemon from the command
line using the full path:
# /usr/local/httpd/bin/apachectl st
The web server should now be running.
Additional security and optimization items
are addressed later in this chapter. Managing
There are some required applications for
both Apache releases. One file that you
may consider downloading and installing
from source rather than depending on the
RPM version is zlib. This file is
optimized by PHP. This portion is entirely
optional; however, if you want to specify
your own binaries rather than use existing
ones, download and compile any
additional programs.
gunzip -c zlib-1.2.1.tar.gz | tar
cd zlib-1.2.1/
./configure ; make test
make install
Again, this application is entirely
optional, but if you are relying wholly on
source code rather than RPMs, consider
installing this and any other application
from source. Running a secure
web site
Because you do not want to allow others
to sniff HTTPD packets or surreptitiously
gain entry to your site, enable SSL for
web browsing on the IDS box in addition
to password-protecting the web page.
If you are creating an IDS machine for
another company as part of a consulting
project or if others outside your company
are reviewing the data, purchase a secure
certificate from a Certificate Authority
(CA) such as Thawte or Verisign. A
security certificate ensures that pages
viewed by visitors are secure and
encrypted and that the certificate was
signed and validated by an outside
authority. CAs charge fees ranging
anywhere from $150 to $1,000 for a valid
certificate. Make certain this is what you
want or is required before using an
outside authority. Otherwise, use one of
the free CAs on the Internet or sign your
own certificate. Be certain you can trust a
free CA. Otherwise, you will be getting
exactly what you pay for​nothing.
The next few steps explain how to create a
test certificate for internal use. Remove
the fake key and certificate generated
during the default Apache RPM
installation in the following manner:
# cd /etc/httpd/conf
# rm ssl.key/server.key
# rm ssl.crt/server.crt
Generate your own random key:
# make genkey
Your system displays a message similar to
the following:
umask 77 ; \
/usr/bin/openssl genrsa -des3 1024
Generating RSA private key, 1024 bi
e is 65537 (0x10001)
Enter pass phrase:
The PEM phrase is a password or key
phrase that unlocks the secure certificate.
Type a secure password where a PEM
phrase is required. Choose one that is not
used anywhere else and that is associated
only with launching the https daemon. For
best security, your password should
contain at least eight characters, include
numbers, special characters and/or
punctuation, and not be a dictionary word.
Remember that with Linux all passwords
are case-sensitive.
You need to enter this password
every time you start your secure web
server, so make certain it is something
you will not easily forget. If you do not
enter the passphrase to start the
secure web server, the web interface
will not be operational.
Create your own test certificate. You can
call it whatever you like, but for the
purposes of example, I am calling the
certificate testcert.
# make testcert
The following output appears in your
terminal window as you are also
prompted for the password:
umask 77 ; \
/usr/bin/openssl req -new -key /etc
-x509 -days 365 -out /etc/httpd/con
Enter pass phrase for /etc/httpd/co
After entering the password, you are
prompted for additional information.
Provide the correct information for your
organization and host. You should also
take note of the variables entered here in
case you wish to re-issue the certificate.
You'll see something similar to the
following is typical output:
You are about to be asked to enter
into your certificate request.
What you are about to enter is what
There are quite a few fields but yo
For some fields there will be a def
If you enter '.', the field will be
----Country Name (2 letter code) [GB]:
State or Province Name (full name)
Locality Name (eg, city) [Newbury]:
Organization Name (eg, company) [My
Organizational Unit Name (eg, secti
Common Name (eg, your name or your
Email Address []:[email protected]
After you have provided the information
pertinent to your site, a self-signed
certificate is created and placed in
/etc/httpd/conf/ssl.crt/server.crt. Edit the
httpd.conf file located in the
/etc/httpd/conf directory if you are using
the Apache RPMs or in the
/usr/local/httpd/conf directory if you are
using the configuration file generated from
the source code. You need only make a
minor editorial change in order for the
connection to be on port 443, the secure
port, rather than the common HTTP port
Place a pound (#) mark before the Listen
80 variable to comment this feature out.
This variable defines port 80 as the
default port. The configuration file now
uses port 443 as its secure port rather than
port 80. Restart the Apache web server.
Ensure that any firewalls between the
clients and the web server are configured
to allow TCP port 443.
# service httpd restart
Before the daemon launches, you will be
prompted for the PEM password
mentioned earlier. The prompt looks
something like this:
Starting httpd: Apache/2.0.40 mod_s
Some of your private key files are
In order to read them you have to p
Server (RSA)
Enter pass phrase:
Ok: Pass Phrase Dialog successful.
If you need to restart the computer or if it
is rebooted, you must also restart the httpd
service using the previous command. The
only way to browse your
SnortCenter/ACID console is via
When logging into the system the first
time, the web server displays a warning
message saying it cannot certify the
authenticity of this server or that the web
site is certified by an unknown authority.
Figure 10-1 shows a sample message
displayed when connecting to a test
Figure 10-1. Warning
message regarding unknown
Certificate Authority
You can choose to accept this certificate
permanently or only for a limited time.
Some people may wish to automate the
startup of the secure web server. This is
possible, although not recommended. If
you want the secure server to start
automatically upon bootup, either leave
the pass phrase portion empty or automate
the pass phrase entry with a custom script.
The latter option is also not
recommended​it may open up more
security holes than the secure server is
intended to close. If all else fails, start up
the secure server manually or use the
standard web server.
Finally, test this web daemon for PHP
integration. Create a test.php file in the
htdocs/ or web root directory. Access this
page and confirm that it works as
specified. After confirming that PHP is
installed and that Apache recognizes it
correctly, delete the test file.
10.1.4 Final Apache
It is imperative that your Apache
installation be as secure as possible. Your
IDS is only as safe as your weakest or
least-secure program. Modify the
following options within your httpd.conf
file to improve performance and shore up
security holes in your web server.
I prefer having the logfiles be a
combination of the access, agent, and
referer information. Customize your
httpd.conf settings as follows:
#CustomLog /usr/local/httpd/logs/ac
CustomLog /usr/local/httpd/logs/acc
I also prefer divulging as little information
as possible about my server to others. By
turning the ServerSignature setting to
Off, you avoid telling others what Apache
version you are currently running.
ServerSignature Off
This feature is only applicable to web
directories that contain static files or lack
index files. Your Apache version number
does not appear below the shown files.
If the web server also has static files that
you wish to display in an empty root
directory without an index.html file, use
the following option to display the full file
name. Apache normally truncates files​so
the entire filename, including the suffix at
the end, is not always visible. This option
in the httpd.conf file corrects that feature.
IndexOptions FancyIndexing NameWidt
Apache has the FancyIndexing option on
by default, so simply add the NameWidth
option to the appropriate line of your
httpd.conf file. Restart the Apache web
daemon by issuing a
restart command. All static files in a
given directory should now be fully
visible. This option is useful if you are
using your management console as a
repository for other open source software
or if you are making the latest source code
available for other systems or sensors.
There are other tools that query your web
daemon and determine the type and
version number. The site provides a
small, Windows-based tool that shows not
only your Apache web version, but your
PHP version and any other compiled-in
features. The latest nmap can also
determine the Apache release running on
your system.
One final safety precaution is to create a
default user without a home directory that
owns all Apache web processes. The
users nobody and httpd are popular names
used by the system when the root httpd
process forks into child processes. Rather
than entrust my security to the default
options, I prefer creating a generic user
with very limited permissions to own the
forked httpd processes. Substitute the
default entries with webuser as both the
default User and Group in the httpd.conf
file. Be sure not to set a password for this
user​no one other than root should have
Create a generic user without a home
directory in the following manner:
# useradd -M webuser
Change the User and Group variables in
the httpd.conf file to reflect the new
default user. Restart your web server
using the following command:
# /usr/local/httpd/bin/apachectl re
Besides the restart command, you can
also use the graceful and configtest
options. graceful sends a SIGUSR1 to
the running process or starts the daemon if
it is not already running. configtest
performs a configuration syntax test.
Whatever command you decide to use
should be automated, so that upon reboot
or startup, the web daemon always
launches. Place this command in the
/etc/rc.d/rc.local file:
# Start up the Apache web daemon
/usr/local/httpd/bin/apachectl star
Verify that all is running as it should by
using the ps command.
# ps -ef | grep http
root 17675 1 0 13:14 ? 00:00:00 /us
webuser 17676 17675 0 13:14 ? 00:00
webuser 17677 17675 0 13:14 ? 00:00
webuser 17678 17675 0 13:14 ? 00:00
webuser 17679 17675 0 13:14 ? 00:00
webuser 17680 17675 0 13:14 ? 00:00
root 17682 3648 0 13:14 pts/2 00:00
Verify that your web daemon can now
manage PHP files. Make a test file in your
~htdocs/ directory called test.php. Place
some sample PHP tags in this file. I
suggest using the single tag <?phpinfo(
)?> as a test. When accessing this page
from a browser, you should see
information relating to your Apache
daemon and PHP version. If everything
appears and works like it should, delete
this test file and then move on to the next
section. The Apache web site has
extensive documentation on getting
Apache configured and running. If you
have any trouble, it's a good place to look
for help.
10.2 ACID Console
The next step is to install ACID or create
a web interface that displays all alerts
generated by Snort. Remember to
download the latest version of ACID from
its homepage, You also
need the programs ADODB and phplot. If
you have ACID Version 0.9.6b22 or
higher, use JpGraph instead of phplot. Try
both to see which version works best.
Be aware that ACID is not a very
secure web program. Although this
chapter does explain how to set up
password protection and although the
register globals option is disabled,
ACID may still be easy to crack. Use
caution as to what machines are
running ACID and to whom the pages
are accessible. Keep ACID pages
internal and limited to select users. It's
a good idea to locate the ACID
console server on the management
The examples presented here are what
work for me. More HowTos and FAQs
appear on the Internet each week,
explaining new methods of installing
ACID or configuring Snort. There are
plenty of papers and tutorials online.
If you have not already installed it, the
latest version of GD is also required by
the system. You may opt to use the GD
library that is included with the PHP
source code instead.
After downloading all the necessary files,
place the source code in the root directory
of your web server. If you are using
Apache as described previously, all files
are placed in the /usr/local/httpd/htdocs/
directory. If you are using the default
Apache that came with Red Hat Linux,
place the compressed files in
Copy all additional program files to the
web root directory. Update the version
numbers to the most recent releases. These
examples are current as of this writing.
acid-0.9.6b23.tar.gz /usr/loca
adodb360.tgz /usr/local/httpd/
jpgraph-1.12.1.tar.gz /usr/loc
phplot-4.4.6.tar.gz /usr/local
gd-2.0.12.tar.gz /usr/local/ht
Uncompress the transplanted files within
the web root directory.
cd /usr/local/httpd/htdocs/
gunzip -c acid-0.9.23.tar.gz | ta
gunzip -c adodb360.tgz | tar xvf
gunzip -c jpgraph-1.12.1.tar.gz |
gunzip -c phplot-4.4.6.tar.gz | t
gunzip -c gd-2.0.12.tar.gz | tar
Some of the directories require renaming
along with a shuffling of files.
cd jpgraph-1.12.1/src/
mkdir /usr/local/httpd/htdocs/jpg
cp -R * /usr/local/httpd/htdocs/j
cd /usr/local/httpd/htdocs/
rm -rf jpgraph-1.12.1/
mv gd-2.0.12/ gd/
mv phplot-4.4.6/ phplot/
Be sure to remove the version number
from those directories as specified.
Normally, only the gd/ and phplot/
directories require this.
10.2.1 Confirming GD
If you think everything installed correctly,
you can skip this step. It is intended more
as a troubleshooting section for those who
may not have installed GD properly or
who want to be certain that they can
generate images on-the-fly from within
their ACID web page.
You might want to confirm that GD
support is enabled on your system in the
event you are using phplot for ACID
Versions 0.9.6b9-0.9.6b21. To do this,
first make certain that all the directories in
the Apache root directory are owned by
the default webuser or nobody or
whatever user you chose to own the
Apache web processes.
# cd /usr/local/httpd/htdocs/
# chown -R webuser.webuser *
Run the following commands within the
gd/ directory if you are using the GD
libraries compiled from source:
# ./configure ; make ; make install
If you are using JpGraph, make certain it
recognizes your current GD installation.
Use a local URL such as the following to
confirm this:
You should get a notification back saying:
"You have GD 2 installed. Version
2.0 (or higher)."
Check to see if PHP can generate
graphical images. First, create a
/tmp/jpgraph_cache directory and then
change ownership of the directory to the
default webuser.
# mkdir /tmp/jpgraph_cache/
# chown -R webuser.webuser /tmp/jpg
Open the URL to verify that your images
were generated correctly.
You should be able to locally bring up the
.html pages and/or .png images in the
/tmp/jpgraph_cache directory. There
should be several blocks of color along
with a small description of each.
Test some of the options using the
following URL. You should be able to
view simple graphical representations
depending upon what sort of graphical
support you compiled in with PHP and
Figure 10-2 is an example showing the
images generated via the web page.
Figure 10-2. Example image
generated using the JpGraph
If everything works properly and you can
bring up graphical images similar to the
examples shown previously using the
*.php links, move on to the next step.
10.2.2 Customizing the ACID
Configuration Files
Once all the programs have been placed in
the Apache web root directory and you
have verified that GD support has been
enabled in the respective programs, begin
editing the configuration files for the
ACID program. The ACID configuration
files should first be examined. Use your
favorite text editor; vim, pico, nedit, or
emacs all work nicely.
Change to the directory holding the
configuration files and make the needed
modifications. My editor of choice is vim.
# cd /usr/local/httpd/htdocs/acid
# vim acid_conf.php
In the acid_conf.php file, modify the
following entries. Change the variable
xxxxxxxx to reflect the password you
chose for the Snort database account.
$DBlib_path = "../adodb
$alert_dbname = "snort
$alert_host = "localhost
$alert_port = "";
$alert_user = "snort
$alert_password = "xxxxxxxx
$ChartLib_path = "../jpgraph
There are other options available in this
configuration file that can be edited to
enhance performance. Exercise caution
when modifying anything other than these
recommended items. Changing anything
other than what is shown may cause your
database and program to quit working.
Set up the "view only" ACID portal,
which​again​does not allow for event
deletion. This is good precaution for those
who only need to view alerts, such as
managers, helpdesk users, or
administrative folk who may do more
harm than good. (You know who you are.)
Copy the files located in the
/usr/local/httpd/htdocs/acid directory to
a new directory created in the same root
web directory,
mkdir /usr/local/httpd/htdocs/aci
cd /usr/local/httpd/htdocs/acid/
cp -R * /usr/local/httpd/htdocs/a
cd ../acidviewer
vim acid_conf.php
Modify the following variables in the
file. Again, change the variable yyyyyyyy
to reflect the password you've chosen for
the acidviewer account.
$alert_user = "acidviewer
$alert_password = "yyyyyyyy
Next, secure both of the ACID web sites
using the Apache htpasswd utility. Set up
two separate accounts for accessing both
the snort and acidviewer pages on the
ACID website. When prompted, enter the
web password you've chosen for that web
account. Be careful to omit the -c option
when adding more users to the password
Make certain that the passwords/
directory is owned by the default web
user, which, in this case, is webuser. You
can opt to create these files and accounts
wherever you like. The examples
suggested here are only recommendations.
mkdir /usr/local/httpd/passwords
htpasswd -c /usr/local/httpd/pass
htpasswd /usr/local/httpd/passwor
cd /usr/local/httpd/
chown -R webuser.webuser password
Add the following lines to
/usr/local/httpd/conf/httpd.conf file in the
Directory portion of your file. You can
place these portions of text near the
general area of the other <Directory>
<Directory "/usr/local/httpd/htdocs
AuthType Basic
AuthName "your_company_name"
AuthUserFile /usr/local/httpd/p
Require user admin
AllowOverride None
<Directory "/usr/local/httpd/htdocs
AuthType Basic
AuthName "your_company_name"
AuthUserFile /usr/local/httpd/p
Require user acidviewer
AllowOverride None
Restart the HTTP daemon using your
command of choice:
# /usr/local/httpd/bin/apachectl re
or the following, if using the Apache
# service httpd restart
Remember to add one of the above lines
to your /etc/rc.d/rc.local or enable startup
of the web daemon using the ntsysv or
serviceconf command. You may also
enable the httpd RPM in all run levels by
doing the following:
# chkconfig --level 2345 httpd on
A reboot may be the best method to check
that everything starts up correctly: the
Apache web daemon, permissions, etc.
Finally, test your installation and
configuration by attempting to connect to
these web pages. You should be prompted
for a password. If not, go back and check
your syntax. Your ACID installation is
now complete. However, do not try to
modify anything quite yet on the ACID
web page. Some additional configuration
files still require editing.
10.2.3 The ACID Console
You should now have two web sites for
the ACID console: one for administrative
users to view and delete alerts, the other
for management or helpdesk users to only
view alerts. They should not have
permission to delete alerts. Here is a more
detailed listing of the available sites
running on the management console
This site is for administrative tasks and
can be accessed using the "admin" or
equivalent account created earlier. View,
delete, and sort events using this web
Anyone requiring read-access only to the
intrusion event log should use this web
page. It is accessed with the acidviewer
account created earlier. Users of this site
cannot delete events.
10.2.4 Initializing the ACID
Web Page
Now you're ready to access and configure
the default ACID web page. There are a
variety of ways to do this: by accessing
the ACID host via its Fully Qualified
Domain Name, by its IP address, or by
means of its loopback address when
configuring the system locally.
The first time you connect to the ACID
web site, a web page appears stating the
The database version is valid, but
the ACID DB structure (table:
acid_ag) is not present. Use the
Setup page to configure and
optimize the DB.
Click on the link labeled "Setup page" to
proceed to database initialization. You are
then prompted to create the ACID AG,
which adds tables to the Snort database
and extends the functionality of ACID.
Select the button labeled "Create ACID
When the table creation process is
complete, a new page appears informing
you of the successful creation of the ACID
tables and the Search Indexes. Click on
the hyperlink labeled "Main Page" near
the bottom of the browser window. This
brings up the main ACID web page.
Through this page, you access alerts and
notifications regarding any and all
suspicious packets captured by the Snort
program. From here, you can navigate
through all other stored messages, packet
headers, and information regarding the
captured packets.
10.3 Accessing the ACID
The ACID web page should be fully
functional on the network intrusion
detection system. This page is normally
accessible using the following URL in a
graphical web browser. Remember when
accessing this page as administrator or as
the primary Snort user, all rights and
privileges to modify the snort database are
granted. Use the following URL for
modifying database content.
To view ACID web content without the
rights to modify or delete entries, open the
acidviewer web page. Verify the MySQL
database permissions are set correctly so
that any user referencing this particular
page cannot remove or hide alerts.
This page should be available only to
those individuals needing to consult or
view logged alerts. These users should not
have the authority to remove existing
alerts. Employees should not be able to
transmit malicious or harmful content
through your network and then cover their
tracks once the IDS or internal sensor
detects their packets.
Likewise, no one outside your network
should have access to either of these
pages. The content within the ACID web
pages displays source and destination IP
addresses containing internal IP
addresses. If you are running Name
Address Translation (NAT) on your
internal network, this information could
provide an attacker the added advantage
of knowing not only your numbering
scheme, but what boxes might be
vulnerable and what ports on these
machines may be open to attack. I highly
recommend password-protecting these
and all other web pages of a sensitive
nature. Even most internal network end
users should not be authorized to view the
ACID web pages.
10.3.1 Using ACID
After resolving most security concerns
regarding ACID's use and Internet
accessibility, begin examining the
component parts of the ACID web page
and analyzing what each link does. The
ACID page, overall, is self-explanatory,
although understanding where each
hypertext link leads helps in determining
the types of packets being captured.
Starting with the main ACID page, this
section examines each link, explains
where it leads, and discusses how to
interpret the content. Main ACID page
The main ACID interface (as shown in
Figure 10-3) provides numerous links that
explain, in detail, each separate element
captured by Snort. This page greets
visitors to the typical ACID site. It
conveys most pertinent information at a
Figure 10-3. ACID's main
interface (each link is
This page provides a brief summary of the
primary links and lists the alerts
registered by Snort. The information listed
on the very first line (in red) notifies the
visitor of new alerts added to the cache
since the page was last viewed or
refreshed. Remember, this is the alert
cache found in the /var/log/snort
directory. This file constantly updates as
Snort detects new packets. The web page
also refreshes itself periodically if left
open, providing an up-to-the-minute
analysis of what is happening on your
The next three lines on the main ACID
web interface display the following
information: first, the current timestamp
or when the database was last queried via
the web interface; second, the database
name​or, in this case, the username​by
which Snort accesses the MySQL
database; and third, the time window, or
when the Snort process was first started
until the present time. As shown in the
initial screenshot, the following alerts
were logged over the space of five days.
The last item of information, the time
window, is useful for security
administrators who need to know the
overall logging period at a glance. Alert information
The next section of the ACID web
interface is set apart by two individual
frames that break down the database into
easily digestible chunks. The right-hand
frame graphically displays the protocol
traffic in percentages. It also shows any
and all portscan traffic detected by Snort.
Portscans are relatively frequent
occurrences, and knowing what
percentage of the events of interest are
actually scans from outside entities is
useful for determining if your network has
become a target for an attack. The
frequency and source of a portscan can be
indicative of forthcoming events. Beware
of falling into the "false positive" lull and
ignoring the seriousness of portscans. You
will have to determine for yourself what
percentage of portscan traffic should be
considered normal and what may
constitute early warning signs of an attack.
While you don't want to investigate every
portscan, a sudden increase in the number
of portscans is a cause for concern.
The left-hand frame shows the number of
sensors capturing data, the number of
unique alerts and their respective
categories, along with the total number of
alerts. The categories selection is another
name for the alert classification in
question. These fall under the rules
selection within Snort.
The alerts are next broken down by their
source and destination addresses. The
unique IP links are distinct connections
established from a specific source address
to a destination address. They determine
what IP address or machine name the
source address is targeting. This detail is
useful for identifying the flow of
traffic​w hether the packet is destined for an
internal host or is an outbound packet.
Below these categories are the source and
destination ports. Each number on the
first line specifies the originating unique
port number and then is separated into
TCP or UDP packets. The same applies to
the destination ports. A security
administrator can return to her logs to
confirm if the packet was crafted to
originate at a higher or lower port than
normally intended.
Each number shown in these sections is a
hypertext link to more descriptive pages.
These pages list the infraction or alert
type, the IP addresses, and the port
numbers in greater detail. It is worthwhile
to click on each of these links and view
the contents collected under the respective
pages. Searching and
Below the framed section is the
interactive portion of the ACID web page.
Inquiries to the Snort database for a
particular signature or packet matching the
criteria specified are made via a link to
the Search function. The Search link is for
viewing and reading through the packet
payload of any offending alert stored
within the logs. Unlike most other
commercial intrusion detection systems,
ACID, together with MySQL and Snort,
captures and stores packet payload data.
Even when the system alerts you to a
possible intrusion, you don't need to trust
it implicitly. You can go back and verify
that the payload matches the signature of a
valid attack. More will be said about the
Search capabilities of ACID later in this
chapter. This is a key function towards the
elimination of false positives for user-
created rules.
Below the Search option is the Graph
Alert Data link. Here it becomes
important to properly compile GD into
PHP and install JpGraph. These
applications generate a real-time graph
that displays the types and amounts of
alerts detected. The graph itself is
customizable in various ways and the data
it examines can also be modified to suit.
This link is examined in more detail later
in this chapter.
Both the Search and the Graph Alert data
hyperlinks bring up pages in which the
typical user or security administrator can
input more information and query the
MySQL database. Knowing both these
pages render data to the user is important
for understanding the types of packets
logged by Snort. Data snapshots
The next section on the main ACID page is
labeled Snapshot. The links here provide
a quick look into the most recent alerts
over varying periods of time or by
frequency or address or port. The links
themselves are relatively self-explanatory
and are useful if you are familiar with the
types of attack or the port numbers or
addresses of the systems in question. Each
link provides a detailed glimpse of what
is currently happening on the network.
Next is Graph alert detection time, which
links to yet another graph-generating chart,
and allows users to view the time alerts
are logged. This section is helpful when
attempting to determine the times at which
most alerts were detected and if
additional security measures should be
implemented at different times of the day.
The final two links are for advanced
customization or knowledge gathering.
The first, Alert Group (AG) maintenance,
allows users to create and modify their
own alert groups. Snort can create
additional alert groups, aside from the
basic alert file. For example, if you want
all ICMP packets to be logged on a
particular system, create a new Alert
Group and give it a descriptive name.
This name is intended mostly for
informational purposes. It can be useful on
large networks to group signatures related
to a single event (or group of related
events). It can also be useful because it
allows multiple security administrators to
understand what is going on during an
The item listed below the Alert Group
maintenance link provides information
regarding the Application cache and status
of MySQL or the database of your
choosing. This link displays a page with
details regarding the installed PHP
version and its compatibility with the IDS
system and related applications. It also
generates information about the database
type and the events stored within the Alert
and IP Address cache.
10.4 Analyzing the Captured
Once you have familiarized yourself with
the main interface, investigate the actual
functionality of the ACID page in more
detail. Here is where you can examine the
types of packets hitting your network and
what they contain. This section closely
details the searching and graphing
capabilities of ACID. Although it attempts
to clarify the nuances of each page and the
results presented therein, it cannot explain
every minor detail or categorize all
possible attack scenarios. The best thing
to do is to become acquainted with each
listing and the data it contains as we work
through this section.
10.4.1 Tracking the Alerts
After checking the main ACID web page
for the latest attacks, your first point of
reference for additional details will
probably be the Unique Alerts link. All
alerts are sorted here, by time, with the
oldest signature listed first. The most
recent unique alert is placed last.
The default Alert Listing page has several
columns containing data, most of which
also link to detailed content. The page is
broken down by column headings in the
following manner:
A brief description of the alert and a
link to an external site explaining its
signature in detail
The grouping into which this alert
type falls
Total #
The number of times a particular
The number of times a particular
signature has been logged since
analysis began
Sensor #
The ID of the sensor that logged that
Src. Addr.
A link to the source address(es) from
where the signature originated
Dest. Addr.
A link to the IP address(es) to which
the packet was destined
The timestamp a logged packet is
first detected and a link to its
The logged packet's most recent
timestamp and a link to its payload
To the far left of these columns are radio
buttons for selecting a particular alert.
These buttons link to the drop-down
Actions menu at the bottom of the page.
Select a unique alert or signature and then
choose an action, such as adding the
signature by type to the AG, deleting the
alert, or emailing yourself or someone
else a summary of the alert. Clicking the
Selected button then performs the
specified action.
Remember that if you are logged in as
the acidviewer user or some other
user without privileges to remove an
entry, the Delete action will not
Under the Signature column heading,
notice the links listed in brackets and
highlighted in blue. Most of these links are
labeled [snort]; when clicked, they launch
a web page displaying the associated
Snort rule. Often there is an additional
reference to Bugtraq, Nessus, CVE,
Whitehats, or some other security-related
site providing more data about the
offending signature. Viewing the packet
There is no lack of information about
logged signatures. ACID provides links
aplenty to signature repositories. Your
task as a security administrator is to
determine if the selected alert represents a
valid attack or security threat. The best
way to determine this is to closely inspect
the packet, the systems against which it
was sent, and its point of origination.
First, check the classification under which
the signature falls. A misc-activity
classification is perhaps not as serious as
an attempted-admin classification. Any
sort of policy-violation should not be
All classtypes are listed in the etc/
directory within the Snort source code.
The file classification.config lists the
classification shortname, a brief
description, and a priority level. A
priority of 1 is the most severe, while 2,
3, and 4 indicate diminishing levels of
severity. The individual classtype listings
and their ratings follow:
# config classification:shortname,s
not-suspicious,Not Suspicious Traff
unknown,Unknown Traffic,3
bad-unknown,Potentially Bad Traffic
attempted-recon,Attempted Informati
successful-recon-largescale,Large S
attempted-dos,Attempted Denial of S
successful-dos,Denial of Service,2
attempted-user,Attempted User Privi
unsuccessful-user,Unsuccessful User
successful-user,Successful User Pri
attempted-admin,Attempted Administr
successful-admin,Successful Adminis
rpc-portmap-decode,Decode of an RPC
shellcode-detect,Executable code wa
string-detect,A suspicious string w
suspicious-filename-detect,A suspic
suspicious-login,An attempted login
system-call-detect,A system call wa
tcp-connection,A TCP connection was
trojan-activity,A Network Trojan wa
unusual-client-port-connection,A cl
network-scan,Detection of a Network
denial-of-service,Detection of a De
non-standard-protocol,Detection of
protocol-command-decode,Generic Pro
web-application-activity,access to
web-application-attack,Web Applicat
misc-activity,Misc activity,3
misc-attack,Misc Attack,2
icmp-event,Generic ICMP event,3
kickass-porn,SCORE! Get the lotion!
policy-violation,Potential Corporat
default-login-attempt,Attempt to lo
In order to view the Query Results page to
find out more about a signature, click on
the appropriate link under the Total #
column. Every instance of each captured
packet is logged here. The most pertinent
column is the one labeled "ID," falling
under the first heading. The ACID
program groups each logged data packet
with its own unique identification tag.
Click on the ID tag to view the contents in
Figure 10-4 is a graphical representation
of a typical packet capture. ACID breaks
the data down into four categories: Meta
Criteria, IP Criteria, Layer 4 Criteria, and
Payload Criteria. The first category
displays the most basic information, the
signature triggered, and the sensor that
logged it. The second grouping shows the
source and destination address, along with
header length, flags, time to live,
checksum data, and other items gathered
from the packet header. The third grouping
displays Layer 4 data such as protocol
type, source and destination port, and the
length of the packet captured. Finally, the
fourth grouping shows the actual payload
in hexadecimal or translated text.
Figure 10-4. The breakdown
of a logged packet viewed
under ACID
Note that the format in Figure 10-4
resembles typical captured Snort content.
If certain packets merit a more detailed
query, use the provided links on both top
and bottom to proceed to the next captured
packet in that categorization.
If you wish to return to the previous
page, do not use the web browser's
Back button but use the Back link at
the top of each page. The browser
Back button may cause web page
navigation problems.
It's a good idea to use the right-click
feature of most web browsers and
open the initial link in a new window.
This way you can close the new
window without having to worry about
using the Back link or navigating
backward through the PHP calls. Identifying known
In most cases, it only takes a few hours to
gather enough packets to collect a
repository of known attacks against your
system or network. Depending on the
average amount of traffic traveling through
the network, you may soon find yourself
overwhelmed with alerts. ACID and Snort
do a fine job of explaining what they think
each attack might be. It never hurts,
however, to perform some reconnaissance
and examine the packet yourself.
Some of the most common attacks seen on
intrusion detection sensors exploit known
Windows vulnerabilities​some of which
are quite old, yet remain troublesome on
many unsecured machines. There are a fair
number of new exploits aimed at
unpatched Linux machines, along with
attacks designed for well known
applications such as Oracle.
Figure 10-5 shows the ACID event page
after Snort detects a well known attack.
This screenshot displays the packet
content of a WEB-IIS encoding access
attempt. This is a known exploit whose
packets are still detected by many
intrusion detection systems. Because there
are no IIS machines in our network, this
attack can usually be ignored.
Figure 10-5. Examining a
typical attack signature
But if you are running applications or
services vulnerable to this exploit, the
alert is a valid one. Know what systems
make up your network and be aware of the
exploits designed to attack them. Just
because the attack targets another
operating system does not mean you
should not take additional precautions to
shore up your own machines, no matter
what platform they are using.
The importance of this alert depends on
the location of the sensor relative to your
firewall and web server. If the sensor is in
your DMZ or in front of your firewall, it
may see many harmless attacks. But if it's
behind the firewall, you have to ask
yourself how an IIS attack made it through
the firewall​even if the attack itself is
harmless (because you aren't using IIS).
Such an attack should never be seen in the
internal network and may mean someone
(or something) has gotten in.
Packets with nonidentifiable yet
suspicious content should be looked at
closely. Sometimes Snort misidentifies
new or recent attacks because the packet
shares common elements with previous
attack patterns. The result may be
confusing, but is still a warneing​and
possibly your only warning​that something
is amiss. Notifying the
There is much information to be gleaned
from the links on the Query Results page.
The columns labeled Source Address and
Dest. Address show not only the ports
from which attacks originate and those
ports to which they are destined, but
provide links to related IP addresses
within the ACID database. Here you can
find out more about the originating IP
address. The hypertext link points to a
page displaying the number of times that a
specific IP address appeared as either the
source or destination, along with a
timestamp of its first and last occurrence.
The ACID page has quick links to sites
such as ARIN, RIPE, APNIC, and
LACNIC for performing registry lookups
in authoritative databases. There are also
links to external sites for executing DNS,
whois, and SamSpade lookups. If, for
instance, you detect an external IP address
attempting to perform multiple
administrative connections and if that
same IP address appears under different
classifications, it would be wise to
contact the administrator of that IP address
block and inform him of the offending IP
address, along with the time and date of
the attack. Include a copy of your Snort
alert with the email. Most ISPs provide an
email address reserved for attacks
originating from their system. If one is not
available, try the prefix "abuse" or
"postmaster" with the ISP's registered
domain name. Searching the
After you've become acquainted with the
basic alerts and web pages linked to
logged packets, use the interactive Search
function on the main ACID web page. This
is perhaps ACID's most versatile feature
since it queries the database for specific
One reason for using the Search function
is to determine the number of attacks
launched against a server from a
particular subnet or IP address. It then
becomes a simple matter to add rules to
the firewall to counteract the attacking IP
address or addresses. The Search function
also registers the number of attacks within
a specific time frame​always a useful
feature for determining when to ramp up
security or when not to bring down the
network firewall for a much needed
update. Basing updates on the types of
attacks seen is another method of staying
ahead of the attackers. The Search
function allows most administrators to
determine potential weakness or find
patterns not normally seen in a cursory
overview. Figure 10-6 shows an example
of the Query Results page. Pay close
attention to each of the fields and the
variables they search.
Figure 10-6. Performing a
search of the database brings
up the Query Results page
Clicking the Search link brings up the
Query Results page. This page has three
different sections from which to select
varying options. You can build requests
based on any of the Meta Criteria,
including the signature name, its
classification, or the alert time. To
perform a search based on the IP address
of the source or destination machine, fill
in the appropriate fields under the IP
Criteria section. You can also look for any
instances that match specific IP header
fields, or you may choose an option based
on Layer 4 or protocol type. The last
section from which you can input
variables is the Payload Criteria section.
Input any data that may be encountered in
the payload.
If you are aware of a certain string of
characters that belong to the Nimda or
CodeRed virus, input that string here and
search for matching packets. For instance,
in the case of CodeRed, we want to look
for a string of characters that represent a
unique "fingerprint." CodeRed copies
CMD.EXE (the Windows command shell)
to the web root and renames it
ROOT.EXE, so we'll look for "/root.exe".
As another example, the following string
of characters is found in a SQL Slammer
infection attempt (SQL Slammer is
entirely contained in a single UDP
packet): "|81 F1 03 01 04 9B 81 F1 01|".
In each part of the query, you can add
multiple criteria by clicking the Add
button on the right. Lastly, select the sort
order method you prefer in the final field.
The Query DB button inputs your data and
looks for corresponding matches in the
database. All packets matching your
criteria will be displaced. Graphing data for
Not everyone enjoys viewing raw data or
perusing Snort alerts, particularly not
management. My own experience is that
most executives wish to be shown the data
or results in a simple-to-read and easy-tounderstand fashion. You can accomplish
this via graphs charting the history of
attacks and their severity. Images are a
simple means of presenting sometimes
complicated data in an easy-to-understand
format. The graphs generated using ACID
are no exception.
ACID supports on-the-fly graphing via its
Graph Alert Data link. Figure 10-7 shows
the Graph Alert Data page.
Figure 10-7. Using the
variables listed, graph all
alerts logged by the system
Choose the plot type (bar, line, or pie
chart) and select the time periord for the
graph. The time it takes to create a chart
or graph can vary, depending on the
amount of data requiring reading and the
speed of the IDS machine. Be patient
when generating graphs that track longer
periods of time, such as a month or more.
Because no book or set of instructions can
cover all possible charts, you'll have to do
some experimentation. Try different
graphing combinations with small data
sets until you find an informative and
appealing format is found.
Figure 10-8 is a graph that uses the default
values. Even a graph as simple as this
conveys the importance of intrusion
detection. This image plots the number of
alerts received throughout a 24-hour
period over the course of five days. Its
results are fairly typical​most attacks occur
later in the day, from late afternoon and
into the night.
Figure 10-8. An example
graph charting alerts logged
over a period of five days
Based on this graph, an administrator
might keep closer watch on network
traffic prior to leaving for the day, and
also review the captured packets every
morning to inspect attacks that occurred in
the late evening. He might even consider
keeping a closer eye on traffic throughout
the evening in order to inspect the alerts
The Graph Alert detection time link
located directly below the Snapshots
section on the main ACID page also
generates a graph. This option produces a
visual rendering of all detected alerts.
Rather than worrying about Meta, IP, or
Payload criteria, this link renders data
fast, in a graphical format. This option is
recommended for managerial types who
want to know how many probes, scans, or
overall attacks were logged by the system
within a fixed period of time. It is also
suggested for helpdesk personnel who
need to produce a graph of the day's
attacks. Users who do not have permission
to delete alert records should use this
This utility is not the suggested method
of determining the severity of attacks,
only their frequency and number
within a given time frame.
Figure 10-9 displays the overall number
of alerts logged in a few days time period.
Notice that you can graph days in the
futuer as well as the past. Days with
registered alerts are highlighted in blue.
This image was generated via the "Graph
Alert detection time" link.
Figure 10-9. Quickly graph
all alerts on an hourly, daily,
or weekly basis
10.4.2 The Ongoing Use of
the ACID Console
So you have Snort running, logging alerts
to the database, and ACID running to
watch events as they unfold. How can you
make the most of this setup? While a
single person can check the ACID console
periodically, you may want to consider
deputizing several people to watch the
read-only ACID viewer interface we set
up earlier. This will have the benefit of
increasing awareness of security in your
environment and gets more eyes and
perspectives watching for problems. This
is especially valuable in larger
organizations, where the information
technology departments are Balkanized.
What might appear to be a false positive
to you might be a portent of doom for one
of the admins in another department. To be
sure, a fair amount of training is
necessary, but ACID is fairly
straightforward to use.
Over time, as the ACID console works,
alerts will build up (especially on hightraffic networks). You may choose to
review the alerts at a certain point and
then flush them out of the system. For
instance, you might purge all alerts over
two weeks old. The best way to do this is
to search for alerts in a range of dates and
delete the entire query. Another option is
to delete alerts when they have been
determined to be false positives, or when
the potential attack is mitigated or
There's a problem with simply deleting
the alerts and forgetting about them. When
the alert is gone, you might lose some
ability to do a forensic analysis of an
attack in the future. Perhaps the alert you
deleted today is just a precursor to
another, more heinous attack that will
occur next week. Archival data could be
valuable. There are regulatory mandates
that specify how long some IDS logs must
be kept​HIPAA, GLBA, and Sarbannes-
Oxley all have record retention
requirements. HIPAA says that all system
logs must be archived for six years! This
regulation can put an immense strain on
long-term information storage and
retrieval mechanisms.
What I have done at some customer
installations is move older alerts (for
example, all alerts older than two weeks)
to another database with its own ACID
console. The archive database is simply
backed up periodically and the archives
kept in long term storage in case they are
needed. This strategy keeps my primary
ACID console lean and quick, but still
allows me access to older alert archives.
It can easily be scripted.
10.5 Sites of Interest
Apache Web
Web Server
guide for
RedHat 9
guide for
Solaris 9
guide for
Chapter 11. Using
SnortCenter as a Snort
IDS Management
ACID provided us with a powerful tool to
manage the alerts generated by the Snort
sensors. Managing the sensors
themselves​the configurations,
preprocessors, rule sets​can all be
accomplished from the command line.
However, when you have to manage
multiple sensors in several different
locations, it's easier to manage all the
systems from one location. SnortCenter
provides this capability through a web
interface. Many administrators use the
same web server to run SnortCenter and
the ACID console. If you prefer a
standalone system, refer to the installation
directions for Apache and PHP in Chapter
10. Then move to the installation section
for SnortCenter, below.
11.1 SnortCenter Console
There are two parts to the SnortCenter
installation, the console and the agent.
The console runs on the management
console and provides the web interface
for managing all Snort sensors. As
previously mentioned, it can be installed
on the same system running ACID. The
SnortCenter agent runs on all peripheral
Snort sensors. They report all Snortrelated alerts and configuration
information to the console.
Download and install the SnortCenter
console software. This application is used
for a variety of purposes, including
updating your list of signatures and rules,
managing and customizing the different
sensors in your networks, creating custom
signatures, and adding pre-processors to
the rule base. SnortCenter is a powerful
program that can simplify the management
of your Snort deployment. It also includes
plug-in support for the SnortSAM
application, which allows for automated
blocking of IP addresses from a variety of
firewalls. SnortSAM is discussed in
Chapter 8.
11.1.1 Prerequisites
The SnortCenter console prerequisites
You can find Apache intallation
instructions in Chapter 10.
Instructions for installing PHP are
located in Chapter 10.
ADODB installation instructions are
also in Chapter 10.
cURL Binary
Can be found at
Installation details below.
OpenSSL library
Most Unix-based systems these days
have OpenSSL installed. It is
necessary for SSH support. If you do
not have it installed, it can be found
at Installing curl
From the curl web site
Curl is a command-line tool for
transferring files with URL syntax,
supporting FTP, FTPS, HTTP,
DICT, FILE, and LDAP. Curl
supports HTTPS certificates, HTTP
POST, HTTP PUT, FTP uploading,
kerberos, HTTP form based upload,
proxies, cookies, user+password
authentication, file transfer resume,
http proxy tunneling, and a busload
of other useful tricks.
From the download page, select an RPM
that includes SSL support and install it
using the following command line
# mkdir /usr/local/src/curl
# cp curl-7.10.5-42.i586.rpm /usr/l
# cd /usr/local/src/curl
# rpm -ivh curl-7.10.5-42.i586.rpm
11.1.2 Installing the Console
The URL for downloading the SnortCenter
software is located at
Be sure to download the correct
version for your Snort release.
Version 1.0-RC1 is the latest release
for Snort-2.1.x. Previous versions of
SnortCenter work only with Snort1.9.1 and earlier.
Here is one possible method for
downloading and installing the latest
SnortCenter code.
# cp snortcenter-v1.0-RC1.tar.gz /u
cd /usr/local/httpd/htdocs/
gunzip -c snortcenter-v1.0-RC1.ta
cd www/
mkdir /usr/local/httpd/htdocs/sno
cp -R * /usr/local/httpd/htdocs/s
cd /usr/local/httpd/htdocs/snortc
rm -rf /usr/local/httpd/htdocs/ww
The files in this directory may need to be
converted to Unix format. This was the case for
earlier versions; it may have been rectified by the
time you read this book.
I recommend using the dos2unix conversion
program for converting these files back to Unix
format. The dos2unix program is available in RPM
format and comes with Red Hat Linux. Select it
during the initial install or download the source
code from the dos2unix home page at
or from an open source repository, such as
Freshmeat (
Convert the files back to Unix format
within the snortcenter/ directory:
# dos2unix *
Edit the main configuration file:
# vim config.php
Modify the following lines in config.php.
The $DB_password variable should be the
root password on the default database;
$hidden_key_num should just be a
random number. $hidden_key_num is
used in the authentication system to
encrypt a value in the cookie. Since this is
a text file containing sensitive data
(passwords and so on), there should be
some consideration given to protecting
this file with strong access controls, etc.
Of course, the same goes for any file that
contains usernames and passwords in
clear text, such as the snort.conf file.
$DBlib_path = "../adodb
$DB_dbname = "snortcenter";
$DB_host = "localhost";
$DB_user = "root
$DB_password = "xxxxxxx
$DB_port = "";
$hidden_key_num = "2345678
There are other items that can be enabled
or left disabled. Check the remaining
options in the configuration file and
decide what features should be enabled​for
example, the notification of rule updates, a
default mail server and email address, and
a link to the main ACID interface. Here
are additional variables that can be
$alert_console = "http://<youracidh
$snortrules_url = "http://www.snort
Once the config.php file has been edited
correctly, create the SnortCenter database
in MySQL. I've chosen to call the
database "snortcenter"​you could certainly
choose something else. If you do, make
certain that the config.php file reflects the
# mysql -u root -p
mysql> create database snortcenter;
mysql> exit
This database is used to store all the rules
and updates needed to stay current with
any new signatures.
11.2 SnortCenter Agent
The SnortCenter agent is installed on the
Snort sensor system itself. It watches
Snort and reports back to the SnortCenter
console system. It also accepts
instructions from the SnortCenter console
and makes appropriate changes to the
Snort configuration. The installation is
fairly uncomplicated. The agent will have
to be installed on all sensors that you want
to manage with SnortCenter. Snort should
be installed and configured before the
SnortCenter agent.
11.2.1 Prerequisites
Here are the SnortCenter agent
Most systems have Perl installed. If
you need to install Perl, you can find
it at or in your
package management system.
OpenSSL library
Most Unix-based systems these days
have OpenSSL installed. It is
necessary for SSH support. If you do
not have it installed, it can be found
Net::SSLeay Perl Module
If you are using SSL to secure the
communication between the agent
and the console (strenuously
recommended!), you will need this
library. It can be found at
11.2.2 Installing the Agent
Download the latest agent (snortcenteragent-v1.0-RC1.tar.gz) from:
Then install the agent using the following
command line:
# mkdir /usr/local/src/snortcenter_
# cp snortcenter-agent-v1.0-RC1.tar
# cd /usr/local/src/snortcenter_age
# tar -zxvf snortcenter-agent-v1.0# cd sensor
# ./
The script will ask you several questions;
for most, you can accept the default
response. You will need to provide:
A location to store the config file for
the agent (built by the script)
A location for the agent logfiles
The location of Perl
The location of the Snort binary
What operating system and version
you are running
What port you want the agent to listen
The IP address it should use
The authentication information for the
Once the information has been gathered,
the agent is installed. It will then ask if
you want the agent to start automatically.
The remote portion of the sensor setup
should be complete. If you have made any
errors during the configuration, stop any
running sensor processes, uninstall, and
run the setup script again.
11.3 SnortCenter
Management Console
SnortCenter is a web-based client-server
management system written in PHP and
Perl. It interfaces with a local web
server​preferably Apache, but almost any
other Unix-based web server works.
SnortCenter assists in configuring Snort
and in keeping all signatures current on the
system. The management console portion
of SnortCenter builds the configuration
files and pushes them out to remote
sensors. Alhough Version 1.0 of
SnortCenter has just been released at the
time of this writing, it already shows
promise. This web-based interface is
designed to be used with ACID. While
ACID displays the results of alerts
collected using Snort, SnortCenter
provides an easy-to-use management tool
for administering the Snort rule sets and
remote sensors. It is intended primarily as
a means of keeping Snort up-to-date via a
web interface rather than the command
line. It interacts well with most other
utilities described in previous chapters.
An outline of SnortCenter's interaction
with other IDS tools is shown in Figure
Figure 11-1. A sample
network layout using Snort,
ACID, SnortCenter, and
other described IDS tools
A single SnortCenter install is all that is
required for managing a lone IDS system
or for controlling multiple remote sensors.
These sensors are placed throughout the
local area network (LAN) or on machines
across the wide area network (WAN).
The sensors report all suspicious packets
to the central management console where
they are gathered, processed, and
displayed on the ACID console.
Here are some of the features of the
SnortCenter management console:
Provides SSL encryption between
management consoles and remote
sensor agents.
Contains built-in user authentication.
Automatically imports and updates
new Snort signatures from the
Remotely starts or stops Snort.
Pushes specific configurations to
each sensor.
Creates custom Snort rules or
modifies existing rules.
Provides Rule Templates support for
easy configuration of multiple
Supports the SnortSAM application.
A single sensor agent can handle
multiple Snort daemons, provided the
system has multiple network
Has multilanguage support, i.e.,
English, German, French, Spanish,
Italian, and Dutch.
Management console and sensor
agents for Linux, BSD, Unix variants,
and Windows are available.
11.4 Logging In and
Surveying the Layout
With each release of SnortCenter,
additional components are added to or
removed from the web interface layout.
The most recent version of SnortCenter as
of this writing requires an initial login.
After successfully logging in, the default
SnortCenter home page displays all
configured sensors and their current state
of operations. This information helps to
immediately determine if Snort is running
and fully functional on all the configured
In most cases​as with the example shown
in Figure 11-2​SnortCenter displays only a
single sensor, because the sensor agent is
running on the same system as the
management console. This is the
recommended architecture for launching a
new intrusion detection system and is a
common configuration for small networks.
It is also a useful configuration for
learning how to use Snort. As you become
more familiar with Snort, you will
probably install additional sensors
throughout your network.
Figure 11-2. The initial
SnortCenter login displaying
all configured sensors
Some browsers display the
SnortCenter web interface better than
others. I find Mozilla works the best.
The KDE Konqueror web browser
appears to have some display issues.
Microsoft IE does not display all dropdown menus correctly. Various
browsers render the SnortCenter
content differently. Find one that
works best for you.
The trickiest part of understanding
SnortCenter is navigating its myriad dropdown menus and understanding their
functions. The terms used in each menu
may not be entirely self-explanatory, and
they may not always make sense. But once
you are familiar with each menu and its
purpose, SnortCenter becomes second
The menus displayed on the initial page
are Sensor Console, Sensor Configuration,
Resources, and Admin. Although these
links are fairly self-explanatory, they
deserve a more detailed inspection. To the
far right on the main page are some
standard navigational buttons. The first,
Alert Console, links to your default ACID
web page. This link is configured within
the config.php file located in the
snortcenter/ directory. The last icon is a
Logout button. Always log out and shut
down your browser when you are through
with SnortCenter. Leaving an unattended
and open configuration menu is never a
good idea.
The next few sections are a close-up
examination of each menu and its purpose.
Although the location of each function may
change in later releases, the basic items
and tasks should remain the same.
11.4.1 Sensor Console
The Sensor Console button allows you to
view, add, and remove sensors from your
configuration. Remote sensors are added
and maintained by the SnortCenter
management console via this link. The
Sensor Console button also refreshes the
default page that displays all configured
sensors. Whether you're adding a sensor
on the local management console or on
some other remote system, the
configuration settings remain basically the
same. The only items that change are the
IP addresses and allowable subnets or
address ranges. If at some later time you
also wish to remove a remote sensor from
production or need to upgrade the system
on which it runs, do so by selecting the
Remove Sensor link.
11.4.2 Sensor Configuration
The Sensor Configuration menu lets you
modify existing rules and select different
options within the snort.conf file. Instead
of editing the file by hand, you can make
all desired changes from the GUI console.
All settings can be modified​variables,
preprocessors, ruletypes, classifications,
and so on.
The items listed in this drop-down menu
are selection options shown in the
following order: Rule Selection, Variable
Selection, Preprocessor Selection, Output
Plugin Selection, RuleType Selection,
Classification Selection, and Reference
Selection. Each of the items listed offers a
range of editing choices for modifying
Snort for a particular local or remote
Possibly the most important item is the
Rules Selection drop-down menu. These
are the same rules that are either
downloaded off the Internet via the
SnortCenter option or in a compressed file
from the Snort download page. The top
portion of the page lists options for
viewing or hiding different rules. After
starting the IDS, all items listed initially
under the Rule Policy Templates section
to the far left can be activated by clicking
on the red Xs and changing them to green
checkmarks. Leave those categories you
do not wish to monitor disabled. The Rule
Category Overview link to the far-right
offers a complete perspective on all
downloaded rules and shows which
categories are enabled and disabled.
The Edit tool allows you to customize the
individual rule fields; any field with the
option shown in bold can be modified. To
create a new rule, select Resources
Create Rule. (This feature will
be discussed in the next section). If you
decide to abandon your edit and restore
the rule to its original state, click the
Restore Default button.
Be aware that when you edit rules
and later update the rule sets from the
Internet, your changes may be lost. If
you want to create your versions of
existing rules, move all custom content
to the local.rules file and keep it
backed up.
The other selections listed under Sensor
Config enable or disable individual
features. The Variable Selection and
Preprocessor Selection drop-down menu
items can be left with default values
enabled. The values in these menus are
easy to turn on or off. Clicking a green
checkmark deactivates that particular
variable. Modifying the variables
themselves again falls under the
Resources drop-down menu option.
The other item of importance under the
Sensor Config menu is the Output Plugin
Selection. This item allows you to
configure the database settings your Snort
sensors use to report activity. Modifying
the plug-in requires going to the
Resources drop-down menu. The menus
RuleType, Classification, and Reference
can either be left alone or enabled. Be
careful choosing the items you activate or
leave disabled. Unless you are absolutely
certain what each feature does, leave the
items in these three menus in their default
11.4.3 Resources
The third drop-down menu on the
SnortCenter page is the Resources link.
The Resources menu exists to add new
features to the Snort rules, modify existing
rules, or create new rules. For each of the
items listed under the previous menu, a
similar feature can be added or
customized under Resources. The standard
method is to view existing items and then
add a new item to the existing list.
For example, the View Rules list under
Resources and Rules shows all available
Snort rules. Next to each rule is an Edit
icon, which, when clicked, brings up all
possible fields available for editing
changes, complete with assigned values
for that particular rule. Figure 11-3 shows
the menu for rule settings.
Figure 11-3. Edit or modify
existing rules to suit
You aren't required to fill in all the fields.
Additional values can be added or
removed from the settings and updated to
the rule or saved as a new rule. These
include settings such as SnortSAM
options, specific logto: filenames, and IP,
TCP, and ICMP settings. If you do decide
to edit an existing rule, you should, as a
matter of habit, always increment the rule
option rev or increment the rev field one
number. This step makes tracking default
rules against those customized by users
much simpler. Creating a new rule
To create a new rule, it's often easiest to
start with an existing rule. Start by finding
the type of rule that corresponds to the
type of packet you want to monitor. For
example, to create a rule that watches
TCP packets for some particular contents,
select one of the existing rules (i.e., sid
2093) and click the Edit button. Then
make the following changes:
1. Change the category to local.rules.
SnortCenter will do this
automatically when you're done,
but I find it helpful to make the
change explicitly. SnortCenter will
also assign an appropriate sid (one
more than the last sid in the
local.rules category).
Set the rule name as desired and set the
action and protocol fields (normally these
will be set to "alert" and "TCP").
Set the source and destination IP
addresses (variables such as
can be used).
Set the flow field (normally, to
Set the content fields to specify the
string you're looking for as precisely as
possible. Consult Chapter 7 for details.
Keeping this book open to Chapter 7
during this process might be helpful during
this process.
Very often, the default settings generated
by SnortCenter are adequate. Once you
have approved the new rule, enable it
under the Sensor
Selection option. The new rule should be
the only one viewable. Click on the black
X and enable it as a green checkmark. You
now have a custom-designed working
rule. You can always refer back to this
rule and make further modifications by
returning to Resources
Rules. To edit the rule again or add
additional content, click on the Edit icon
once more.
11.4.4 Additional Resources
The same functions for adding new rules
apply to the remaining options listed under
the Resources menu. The items shown
under the Variables, Preprocessors,
Output Plugins, Rule Types,
Classifications, and Reference headings
can all be edited to suit. You can also
create new options based on existing rules
or even start from scratch. Again,
familiarize yourself with existing
constructs and the manner in which they
are created before attempting to fashion a
new resource. If you make any mistakes in
the syntax, the SnortCenter program or
Snort will let you know.
Pay close attention to the Output Plugins
selection. The current Outplut Plugin
displays the name of the sensor, the
database name and type, and the username
and password for logging into the
database. These options are defined
during the IDS setup routine. If you decide
to modify these options or create a new
database, be certain to edit these variables
as well. The Rule Type feature is also
crucial to running Snort properly. The
normal procedure is to use the "log"
attribute rather than the "alert" feature.
11.4.5 Admin
The final drop-down menu is called
Admin. This link ties into the download
and installation options of new rules from
the Snort rule page. It is also used for
various administrative tasks, such as
configuring existing users and granting
new users access to the SnortCenter
management console.
The first option under the Admin menu
grants users the ability to import or update
rules. This can be done in several ways.
The first and most common method is to
update the rules directly from the Internet,
with an automated script that grabs a
compressed file from the Snort download
site. The location of the script is
configured in the config.php file in the
SnortCenter directory. Remember that
after downloading the complete rule set
and then pushing it out to the customized
snort.conf file, all custom or edited rules
are overwritten, except those within the
local.rules section.
Rather than downloading all rules, you
may prefer to add new rules as they
become available. For example, shortly
after the SQL Slammer worm appeared on
the Internet, the Snort administrators
posted a custom rule that recognized the
worm's signature. The best method for
creating or adding custom signatures is to
use the Copy & Paste option under the
Admin menu. Paste the new rule directly
into the database in the area provided.
When new rules are posted on the Snort
site, any user can copy and paste them
directly into the database using this link.
Another option is to download the
compressed rule base onto your local
machine, open the SnortCenter web
interface, and select the "Upload file"
option under the Admin menu. Browse for
the file stored locally and upload it to the
database on the IDS server. This is a
useful option for users on slow
connections who still require the full rule
database. This file is easily transferable
via floppy disks or CDs.
Another important listing under the Admin
menu is User Administration, which is
designed to add and edit permissions for
users with access to the local SnortCenter
web page. You can also specify the email
address associated with each user. The
default configuration is "admin" and
"change" as the username and password,
respectively. Modify these immediately
after the initial install.
The remaining options under each of the
drop-down menus are self-explanatory.
The best method for learning the
SnortCenter management console is to test
each option under the drop-down menus
and become familiar with its individual
11.5 Adding Sensors to the
This section explains how to add new
sensors to SnortCenter and how to
properly configure them using the
provided menus.
11.5.1 Configuring Sensors
Within the SnortCenter
Adding new sensors to the list of
available sensors on the SnortCenter
console is a simple task. Click on the
Sensor Console drop-down menu and
select the Add Sensor option. Customize
the sensor name to be descriptive of that
device. Fill in the correct IP address of
the sensor and add port number 2525. (If
the sensor is on the other side of a
firewall, you may need to add a rule to
allow it to pass port 2525 traffic.) Define
a username and password. Identify the
default sniffing interface on the sensor and
the Snort command-line options.
Once a new sensor has been added,
confirm that you can connect to it via the
SnortCenter display. Make certain this
sensor has the management console IP
address listed as an allowable address​this
should have been done using the
file under the snortcenter-agent/
directory. If a connection cannot be
established, revisit the configuration.
After confirming connectivity, open the
Sensor Config
Output Plugin Selection
menu on the SnortCenter page. The Sensor
Scope field at the top of this page
provides a selection of the available
configured sensors. Select the new, added
sensor and activate the output database.
Return to the View Sensors page and push
the custom rules from the management
console to the sensor. Activate the Snort
program on the remote sensor. All sensors
should now be visible along with their
status via the View Sensors page.
11.6 Managing Tasks
One well-liked feature of SnortCenter is
its ability to handle a wide assortment of
tasks normally performed from the
command line. A GUI interface via a web
browser provides easy functionality for
beginning users. However, SnortCenter
still offers intermediate and advanced
administrators the ability to perform
complex tasks. This section covers some
of the more complex options, along with
command-line features for advanced
11.6.1 Updating Rules and
There are various third-party scripts
(Oinkmaster is one of the more well
known) that assist in automating the
download of the Snort rules database.
They can all be obtained from the Snort
page and installed and configured on most
open source IDS machines. These and
other scripts keep SnortCenter current
with the latest signatures. In the event a
new type of attack appears on the Internet,
either download the latest rule set or
manually add a new signature to the
rulebase. Most administrators do not want
to wait for the rules database to be
automatically populated with the most
recent releases.
You know that adding a new rule is a
simple matter when you use the
SnortCenter management console. Open
the Admin menu and select Import/Update
Rules, then choose the option that works
best for your needs. If you insist on using
the command line, it is just as simple to
place a rule within the snort.conf file and
push the new configuration out to all
sensors. For a local IDS, add the rule and
restart the Snort process. Remember, the
latest Snort signatures can be fetched from
the main Snort download site at the
following address: Automatic update
For those who prefer automatic updates to
the signature database, an automatic
update feature is included with the
SnortCenter management console. This
feature saves administrators the hassle of
regularly downloading the rules and
pushing them out to the sensors.
SnortCenter can automatically grab the
new rules at any given time​determined by
a cron job​and push them out to the
multiple sensors.
First, verify that the following parameter
is listed within the config.php file on the
management console:
$User_authentication = 2;
If this variable is set to "0", user
authentication is completely disabled. If it
is set at "1", user authentication is
enabled. When the variable is configured
at "2", user authentication is disabled only
for automatic update.
Create a cron job on the management
console similar to the following:
0 0 * * * curl "http://localhost/sn
SnortCenter recommends the use of curl.
There is no need to download another
application for retrieving the latest
ruleset. However, the wget utility can be
used equally well as shown in the
following example cron entry:
0 0 * * * wget -O - "http://localho
This setting pushes out new updates to
each of the sensors every night at
midnight. It's as clever as it looks​you're
not really using curl to download a file,
you're using it to (effectively) click on a
link through a cron job.
11.6.2 Managing False
Positives and Negatives
Chapter 9 outlines several strategies to
control the incidence of false positive and
false negative alerts. SnortCenter
provides a very useful interface for tuning
and configuring your Snort environment as
To remove or disable rules generating
false positives, locate the sid of the
offending alert. The sid for a particular
alert can be found in the file
or from the ACID web page. The Unique
Alerts section helps find false positives or
determine which rule generates the most
alerts. If this alert is passive and can be
safely turned off, find its sid and return to
SnortCenter. Choose the Sensor Config
button and go to the Rule Selection page.
Figure 11-4 is an example page with all
the rules deactivated.
Figure 11-4. Deactivate rules
that generate false positives
Under Category Scope, you can either
choose the rules file you want to look in
and locate the sid by hand or fill out the
Find field in the upper right-hand box to
locate the sid. To deactivate the rule
associated to the sid, click on the pushpin
Take great care when disabling or altering
rules. You can inadvertently rob the Snort
installation of its effectiveness.
11.6.3 Editing Custom Rules
The concept of customizing rules to
accommodate your unique network
situation can also be applied to any
existing rules. For example, to set up a
custom rule to alert you in the event some
user activates a peer to peer filesharing
network and begins abusing network
bandwidth by sharing illegal files, either
adapt one of the existing rules that detects
this traffic or customize a rule to detect a
specific port number or signature.
To create new rules most effectively, you
can redefine existing rules and customize
them to suit. For example, to capture new
peer to peer filesharing traffic, first install
the P2P program, capture sample traffic
using tcpdump, and then look for
identifying signatures or unique features
within those packets. Using a sample rule
from the p2p.rules file, create a new rule
that contains a content string matching
found in the captured packets. This new
rule should alert you to traffic passed on
your network using the peer to peer
application. Some testing and tweaking of
the content rule may be needed before
false positives or negatives are
The ability to create and modify rules is a
necessary skill for a security administator.
You may not always be able to rely
wholly on the Snort database. Your own
internal network may deal with unique
ports or applications that create false
alerts. A brand new exploit may require
you to create a rule to protect yourself
before a rule is released on the Internet.
SnortCenter can be invaluable in this
Chapter 12. Additional
Tools for Snort IDS
Apart from ACID and SnortCenter, there
are a number of applications to help you
administer, monitor, and manage your
Snort sensors. Some of the solutions are
open source; others are commercial. We'll
examine the open source tools more
closely, but all of the commercial
solutions we look at actually grew out of
open source beginnings.
The main difference between the open
source and the commercial tools is the
ease of installation and what I'll call the
"fit and finish." Open source tools are
more difficult to install and their
interfaces are not as polished. While we
are not going into nearly as much detail as
we did with ACID and SnortCenter, the
main features of each application are
highlighted. Investigate the tools to
determine if they fit your particular needs.
12.1 Open Source Solutions
Many open source tools are designed to
help with some aspect of managing Snort.
Most target a particular task (updating
rules, managing alerts, and so on), but
some are surprisingly full-featured. Snort
has changed a great deal (the moves from
1.x to 2.x and from 2.x to 2.1.x were
dramatic). Some of the tools do not
support new features, such as the new
preprocessors (even ACID is showing
signs of age as its development falters).
12.1.1 SnortReport
Developer: David Gullet
Web-based (PHP)
Apache, PHP (GD Support compiled in),
MySQL, Jpgraph, Snort
Installation of SnortReport consists of
nothing more than ensuring that the
prerequisite applications are installed and
running, extracting a directory of web
pages and PHP files, creating a directory
in your web root (or creating a virtual
host), and editing the srconf.php file. The
srconf.php file is filled out with login
information for the MySQL database that
your Snort sensors are logging to.
The development of SnortReport seems to
have been stalled for some time. The
current version on the Freshmeat web site
is 1.04, but the FreeBSD ports catalog has
install source for Version 1.2.
SnortReport is nothing more than an
interface into the alerts in the database. It
is does not have many features, but can be
a useful interface for keeping an eye on
things. All things considered, ACID is far
superior (and not much harder to get
running). Figure 12-1 shows the
SnortReport main page.
Figure 12-1. SnortReport
main page
12.1.2 SnortSnarf
Developer: Jim Hoagland and Stuart Staniford
Any (Perl-based)
Apache (or any web server), Perl, Perl Time
module, Snort
Installing SnortSnarf involves extracting
the archive into a working directory. The
entire program consists of a Perl script
that parses the alert logfile generated by
Snort (in /var/log/snort, by default) and
generates a directory of summary web
Development of SnortSnarf also seems to
be stalled. It's a very lightweight reporting
tool that presents the user with a listing of
alerts and links to summaries for the top
20 addresses (source and destination).
SnortSnarf is not intended to be a
monitoring interface for Snort, but simply
a reporting tool. It pales in comparison to
the alternatives. Figure 12-2 shows a
sample SnortSnarf report page.
Figure 12-2. SnortSnarf
sample report
12.1.3 Cerebus
Dragos Ruiu
Linux, FreeBSD, OpenBSD, Solaris,
Prerequisites: Snort
Download a precompiled executable for
the operating system you will be using to
run Cerebus. At the command line, supply
the path to the Snort logfile (in unified
binary output format) and the
file (included with the Snort rules
download). Cerebus is a text-based
console application; it's a fairly powerful
utility for parsing Snort logfiles in the
unified binary format. You can sort based
on timestamp, address, alert priority,
alert, or classification, and group and
delete alerts by sorting criteria, as well.
Cerebus is limited in that it can only read
the unified binary Snort logs and thus is
not a live monitoring tool. For
environments that utilize the binary
formatted logfiles, Cerebus can be useful
for pruning alerts before sending the files
to another tool, such as Barnyard (see
Chapter 13). Figure 12-3 shows the
Cerebus console interface.
Figure 12-3. The Cerebus
12.1.4 IDS Policy Manager
Jeff Dell
Download Link:
Windows 2000 and Windows XP
Prerequisites: None
IDS Policy Manager comes in a standard
Windows installer. It includes everything
you need to manage Unix-based Snort
sensors, including PuTTY's Secure Copy
IDS Policy Manager is a very fullfeatured application that allows you to
manage multiple Unix-based Snort
sensors. Interestingly, even though this
application is Windows-based, you cannot
use it to manage Windows-based Snort
sensors. With the IDS Policy Manager
interface, you can configure all aspects of
Snort​variables, preprocessors, output
plug-ins, and rules. The main sensor
management interface is shown in Figure
Figure 12-4. The IDS Policy
Manager sensor management
IDS Policy Manager keeps track of
settings for a sensor (or group of sensors)
by storing configuration information in the
form of a policy that can be edited with
the Policy Editor. Figure 12-5 shows the
configuration screen for the flow
Figure 12-5. The flow
preprocessor configuration
As mentioned, all aspects of Snort sensor
configuration can be managed using the
Policy Editor, including rules. Through
this interface, it is possible to enable,
disable, customize, merge, and delete
rules. Figure 12-6 shows the interface to
manage the active rules on the sensor.
Figure 12-6. Managing the
Snort rules
IDS Policy Manager is a very capable,
powerful tool for managing multiple Snort
sensors. Of all the open source tools, this
is the most current in development. Its
functionality rivals the commercial tools
available for sensor management.
12.1.5 Oinkmaster
Developer: Andreas ...stling
Any (Perl-based)
Prerequisites: Wget (text-based file retriever)
In order to install Oinkmaster, download
and extract the archive, which contains a
group of Perl scripts (there's also an RPM
distribution). The most important of these
is the one called Oinkmaster. The
Oinkmaster.conf file stores configuration
information. The file configures URLs to
the latest Snort rules archives. Please note
that the download paths have changed
recently. You can download the latest set
of rules for Snort Version 2.1.x from oinkmaster.conf
file is also used to configure which files
will not be compared and which rules
will be disabled when the new rules are
Oinkmaster is run from the command line
with a list of arguments (oinkmaster -h
lists the options). Oinkmaster downloads
the latest rule set, compares them to the
existing set of rules, and updates the old
rules, following the instructions in the
configuration file. While Oinkmaster does
a good job, it can cause problems if you
let it update the rules automatically. To
avoid problems, use the oinkmaster -c
option, which performs a comparison and
outputs it to the console. I normally use
this mode to get a listing of what is new,
changed, or deleted from the rule files. I
then take this listing and use it as a guide
when manually updating my rules. I have
found Oinkmaster to be extremely useful
in managing Snort rules.
12.2 Commercial Solutions
There are a number of commercial Snortbased solutions on the market. They are,
not surprisingly, very polished and fullfeatured. They are also not inexpensive.
Three solutions rise to the top when
considering the current products on the
12.2.1 Applied Watch
Developer: Applied Watch Technologies
Pre-installed appliance available: OpenBSD,
NetBSD, FreeBSD, Linux, Microsoft
Windows, Mac OS 386/Sparc Sun Solaris,
and other operating systems that run Java
Runtime Environment
This is a full-featured Java-based console
that can manage Snort sensors. A
commercial version of Snort is available
in the form of a hardware appliance, as
well. The console or the sensor can also
be purchased as an appliance.
12.2.2 PureSecure Console
Developer: Demarc
Supported Available for Windows, Linux, *BSD, and
platforms: Solaris
PureSecure Console was an open source
Snort management system that matured
into a nice IDS management tool. It runs a
stable and polished SSL-encrypted web
interface and is a good interface for
managing multiple Snort sensors. Figure
12-7 shows the PureSecure console.
Figure 12-7. The PureSecure
personal edition management
There's a commercial version and a
personal version. The personal version is
downloadable for no cost, but can only be
used by home users. When installing the
personal edition, start with a pristine,
minimal operating system installation. The
installation program downloads what it
needs to run. Upgrade the individual
components as needed. I consider myself
advanced at system administration, and
retrofitting PureSecure to an existing
installation was challenging. The console
manages alerts and rules well, but is
disappointing when managing the sensor's
configuration. The personal version is at
12.2.3 Sourcefire
Management Console
Sourcefire, Inc.
Supported platforms: Dedicated hardware appliance
Sourcefire is the company started by the
initial developer of Snort, Martin Roesch.
Sourcefire offers three main products: a
sensor (based upon Snort​actually a more
advanced version of Snort), a management
console, and a product called RNA (Realtime Network Analysis), which is an
event-correlation and anomaly-detection
mechanism for intrusion detection.
There is no solution more full-featured or
capable for network intrusion detection.
Sourcefire is one of the primary
contributors to open source Snort and, in
fact, is the source of most of the newer,
advanced features. If you are looking for a
commercial NIDS solution and you don't
have the time or ability to deploy an open
source solution, consider the Sourcefire
line of products.
Chapter 13. Strategies
for High-Bandwidth
Implementations of
For most environments, Snort running on a
modern computer (even a workstationclass system) will have enough resources
to keep up with most network traffic. This
is especially true of sensors that are only
watching the network connection to the
Internet​often relatively slow connections
(most often less than 10 Mbps). When the
traffic volumes increase or the
configuration gets complex, the Snort
system starts to suffer.
As we've seen through the course of this
book, Snort is a very full-featured
application. The various preprocessors,
output plug-ins, and rule sets all take a toll
on memory and CPU usage. An interesting
fact is that while Snort has many
components and performs many tasks
(watching the traffic, performing a
signature comparison, and tracking
conversation state), it is still singlethreaded. If the network is busy when
Snort wants to log an alert to a database
running on another system, it has to wait
until the log entry is made, potentially
missing packets during that pause. Even
writing to local alert logs in "full" mode
can result in a short lag.
When the network bandwidth that the
sensor is watching starts getting larger, the
CPU and memory needs increase. There
are a variety of strategies that you can
employ when a sensor is showing signs of
strain (high CPU utilization, low memory,
paging hard drives, and so on). You can
switch from "full" to "fast" logging. This
adjustment reduces the overhead for disk
writes, but less information is logged.
Dropping the additional information can
make the discrimination of false positives
and post-incident analysis much more
difficult. You can allocate less memory to
the various Snort preprocessors, but such
a step reduces their effectiveness. You can
also eliminate preprocessors or rule sets
altogether, reducing the load on the
systems sometimes significantly​but then
you lose the utility the components and
rules were designed to provide.
A better approach is to take some of the
high-cost functions of Snort and split them
out into their own applications, allowing
Snort to take advantage of a system with
multiple processors or allowing the other
tasks to be performed by another system
entirely. This is the approach taken by
Barnyard, an open source application that
grew out of the work done at Sourcefire
(the company started by Martin Roesch,
the initial developer of Snort). Barnyard
reads Snort's very quick-to-write Unified
Binary output format and performs several
of the CPU and disk intensive tasks,
leaving Snort to watch the traffic.
Another technique is to control the amount
of traffic that a sensor watches. If a Sensor
is having trouble keeping up with 200
Mbps of sustained traffic, it's a good idea
to split the traffic to multiple sensors
(perhaps 2 sensors, each watching 100
Mbps, or 4 watching 50 Mbps each). This
can be performed using a network device
called an IDS load balancer. There are a
couple of these commercial solutions on
the market and one that I developed with
some clever Linux kernel programmers.
We will examine these solutions below,
but first let's look at Barnyard.
13.1 Barnyard (and Sguil)
One of the costliest activities Snort
performs is its alert logging. Data needs to
be gathered, formatted, and written. In the
case of database writes, Snort must send
the alert to the database and wait for
confirmation of a successful write. The
situation is made even worse when the
database server is running on another
system on network.
Snort has the ability to dump the
information that it has gathered on a
particular alert into a binary file. This is
very quick, since no processing needs to
be performed on the data. The Barnyard
application reads this file, formats the
alert data, and writes it to the chosen
output mechanism. The output mechanism
can be the conventional Snort logfile,
syslogs, comma-separated-value
formatted (CSV) file, or a database
server. Barnyard can be configured to run
on the same platforms as Snort, and their
installation and configuration are very
similar. Figure 13-1 illustrates the way
Snort and Barnyard work together.
Barnyard does a very good job of logging
to the ACID database allowing
Administrators to continue using familiar
Figure 13-1. Barnyard
working with Snort
13.1.1 Configuring Snort's
Unified Binary Output
When using unified binary output, Snort is
configured normally; the only difference is
the output plug-in selected in the
snort.conf file. The log_unified output
plug-in is the only output plug-in that
should be configured. The format of the
directive is:
output log_unified: filename <filen
The base filename Snort uses when
logging alerts. A timestamp is
appended to the filename. The file is
created in the location you chose for
Snort logfiles to be written
(/var/log/snort by default, but
configurable using -l.
logfile size
Designates the maximum size that a
logfile can attain. Consider 128 MB
a minimum size. When this file is
full, Snort stops writing to that one
and starts another with the same base
name but a new timestamp.
A sample snort.conf entry would be:
output log_unified: filename unifie
When Snort starts writing to a new file as
a result of the size limit being reached,
Barnyard continues processing with new
file automatically if it is running in
continual mode (see Section 13.1.4
13.1.2 Installing Barnyard
Download Barnyard from and
extract it to a standard location (I prefer
/usr/local/src/barnyard). To enable
database support, you need to use a
directive when running configure. To
enable support for MySQL support, use (-enable-mysql); to enable PostgreSQL,
use (--enable-postgres). The command
line is below:
# cd /usr
# ./configure --enable-mysql
# make
# make install
After install, you can find the Barnyard
executable in /usr/local/bin and the
barnyard.conf file in the /etc directory in
your source directory. You can copy this
to a location like /usr/local/etc or keep it
where it is.
13.1.3 The barnyard.conf File
Most Barnyard options are managed using
the barnyard.conf file. There are two
sections to the file: the declarations and
the output plug-ins.
Here are the configuration declarations:
config daemon
Designates that Barnyard runs in the
background (as a daemon). The same
as the -D command-line option.
config localtime
Sets Barnyard to use local time
Sets Barnyard to use local time
instead of UTC. This is generally not
recommended due to the confusion it
can cause with multiple sensors.
config hostname : <hostname>
Sets the hostname of the sensor.
Currently only used by the ACID
database plug-in.
config interface : <interface name>
Sets the interface name for use with
the ACID database plug-in.
config filter: < filter regular
Normally, this is set to stop an
infinite loop if you are sniffing traffic
on the same interface you are running
a console using SSH. Here's a
sample setting:
Config filter: not port 22
The output plug-ins consist of:
output alert_fast: < filename>
Outputs a file that is similar to
Snort's "fast" format; very stripped
down, with no packet headers.
output log_dump: < filename>
Outputs a file that is similar to
Snort's ASCII packet dump mode.
output alert_csv: < long list of
(Experimental plug-in) Creates a file
with user-designated fields. It might
be useful for some custom scripting,
but for the vast majority of
administrators who are sophisticated
enough to use Barnyard, a database is
a better choice. If you want to do
custom scripting, refer to the
database schema in Appendix A and
create database-aware scripts. You'll
be happier.
output alert_syslog: < facility>, <
Outputs using the syslog mechanism
with the same options as Snort (see
Chapter 5).
output alert_syslog2: < facility>, <
Uses a mechanism similar to the
alert_syslog output line, but has the
expanded formats of syslog2
output log_pcap: <filename>
Outputs data in the standard pcap
output alert_acid_db : <database
type>, sensor_id <sensor id>,
database <database name>, server
<server address>, user <username
for database>, password <database
Sends alert information (less detailed
than log information) to an ACID
database. Designate the database
type (mysql, postrgres, and so on),
and supply the location of the server
(localhost or IP address), database
name, and the authentication
information for the database user.
output log_acid_db : <database type>,
sensor_id <sensor id>, database
<database name>, server <server
address>, user <username for
database>, password <database
password>, detail <full or fast>
Sends detailed log information to an
ACID database. Designate the
database type (mysql, postrgres,
and so on) and supply the location of
the server (localhost or IP address),
database name, and the authentication
information for the database user.
One last bit of data to include is the
detail option (fast or full). I
always use full. Here's a sample
configuration line for the ACID
output plugin:
output log_acid_db: mysql, sens
snort_user, password pa$$w0rd,
output sguil : <db type>, sensor_id
<sensor ID>, database <db name>,
server <IP address or hostname>,
user <db username>,password <db
password>, sguild_host <IP
address or hostname>, sguild_port
<port number>
Sends detailed log information to a
sguil server database. Designate the
database type (mysql, postgres,
and so on), supply the location of the
database server, the database user
and password, the sguil server
location, and the port that sguil is
listening on (defaults to 7736).
Here's sample configuration for the
sguil output plug-in:
output sguil: mysql, sensor_id
user, password pa$$w0rd, sguild
13.1.4 Barnyard CommandLine Options
Barnyard runs in one of three modes: oneshot, continual, or continual with
checkpoint. One-shot mode (or batch
mode) is used to run Barnyard against a
single unified logfile and then exit.
Continual watches a unified logfile as it is
written to. The continual with checkpoint
mode is similar to the continual mode
except it keeps track of where it is in the
file by keeping a pointer in a file
(sometimes called a waldo file). If
Barnyard crashes, processing will
continue at this point in the unified logfile.
The mode that Barnyard is running in (as
well as other potentially ephemeral
configuration settings) is designated at the
command line. The command line options
for Barnyard are:
Similar to the -T test mode of Snort.
Processes the configuration and tells
you if you have any problems. This
has gotten very useful in recent
versions of Barnyard.
-c < path to barnyard.conf>
The path to the configuration file.
-d < dir>
The directory where Snort will be
writing the unified binary format
-L < dir>
If Barnyard is configured to output to
files, this path designates where the
files should be written.
Increases verbosity of console
-s < file>
The path to Snort's file.
Included with the Snort rules
download and specifies the sid for an
alert message.
-g < file>
The path to Snort's file.
Included with the Snort rules
download and specifies the detection
generator that is associated with a
generator ID.
-p < file>
The path to Snort's
classification.config file. This is
included with the Snort rules
download and specifies the alert
classifications used by Snort.
-a < dir>
If a unified logfile is processed, it
can be archived to another location
as specified.
-f < base>
The base name for the Snort unified
binary format logs. This is the
filename without the appended
Only process new events.
-w < file>
The checkpoint (waldo) file used for
continual with checkpoint mode.
Run in daemon mode.
-X < file>
Specify a file to store the PID of the
Barnyard process.
Enable one-shot mode on the
specified file.
-t < timestamp>
You can specify the timestamp for the
first file to be processed. The
timestamp is in Unix time (seconds
since the epoch).
Here are some sample command lines
(they can get very long). First, there's
batch (one-shot) mode:
barnyard -c /usr/local/etc/barnyard
-c /usr/local/share/snort_rules/cla
-s /usr/local/share/snort_rules/sid
-g /usr/local/share/snort_rules/gen
Then we have continual mode with
barnyard -c /usr/local/etc/barnyard
-c /usr/local/share/snort_rules/cla
-s /usr/local/share/snort_rules/sid
-g /usr/local/share/snort_rules/gen
-f unified.log
13.1.5 Sguil: An Alternative
Management Console
Developer: Bamm Visscher
Tcl/Tk client/server architecture
MySQL, Snort, Barnyard, Tcl/Tk 8.3 or new
(, Tclx libra
(, Mysqltcl
(, incr tcl (itc
(, tcllib exte
(, Tcpflow
p0f (
As the prerequisite list indicates,
installing Sguil can be hairy. Getting it
running involves installing the standard
Snort components, Tcl (tool control
language) and tk (a graphical user
interface toolkit), several add-on Tcl
libraries, and the Tcpflow and p0f
applications. Then set up a database for
Sguil to use, install the GUI server, and
the GUI client, patch Snort's source code
and recompile, configure Barnyard's Sguil
output plugin, and configure a script to get
the data from Snort, Tcpflow, and p0f into
the database. Detailed installation
instructions are available on the Sguil
web page.
Sguil is a near real-time interface to Snort
alerts that relies on Barnyard, Tcpflow,
and p0f to gather alert data. Tcpflow and
p0f are used to create a transcript of
network traffic that can be useful in
discrimating false positives and postincident forensic analysis. The interface is
actually very nice to use and presents the
alert information in a useful format.
An extract from the Sguil home page:
Events can be validated by placing
them into one of seven incident
categories or marking the event as
having no further action required
(NA). These actions remove the
events from the RealTime tab of all
the connected clients but are not
deleted from the database. Archived
events can easily be retrieved from
the database through preformatted
queries, or the analyst can create a
custom query using SQL.
Sguil isn't that different from the ACID
interface: both allow you to monitor alerts
and search by event, sensor, alert
classification, alert priority, or timestamp.
Sguil is more up-to-date with the latest
preprocessors​particularly the new flowportscan system. Both ACID and Sguil
lack sensor-management tools.
Where connecting to ACID is easy since it
is a web-based interface, the only way to
get a remote client to connect to a central
server is by using an exported X-session
(a security no-no). Looking back at the last
few paragraphs, I see that I'm drawing a
lot of comparisons between ACID and
sguil. Functionally, they are very similar.
Sguil's transcript feature differentiates it.
A daunting installation, poor client model,
and lack of many new features make it
difficult to recommend Sguil. I advise
sticking with ACID.
Figures Figure 13-2 and Figure 13-3 show
screenshots of Sguil in action.
Figure 13-2. Sguil console in
Figure 13-3. The sguil query
13.2 Commericial IDS Load
Another strategy for easing the load on a
single sensor in a high-demand
environment is to spread the workload
across multiple sensors. These devices
(commonly referred to as IDS load
balancers) make a copy of the traffic on a
network link and send traffic to or from a
group of hosts to a particular sensor, and
traffic to or from another group of hosts to
another sensor. Some of the devices
available can distribute the traffic across
10 or more sensors. These solutions
perform as advertised, but they do not
have small price tags. There are three
main commercial players in this niche.
13.2.1 F5 Network's VLAN
Mirroring with Big Iron
F5 Networks
( has the
ability to mirror multiple VLANs on their
Big Iron line of switches. This mirroring
can be used to distribute traffic load
across multiple IDS sensors. With blazing
fast backplanes, there are very few
environments in which these devices
would have trouble keeping up.
13.2.2 Radware's Fireproof
Radware ( has
a device called FireProof that can be used
as an IDS load balancer. It already
integrates code that performs an IDS
function, making additional sensors
somewhat redundant.
13.2.3 Top Layer Network's
IDS Balancer
Top Layer Networks
( was the first
on the market with a dedicated IDS load
balancer capable of multigigabyte
bandwidth channeling. This is a very good
choice when you have a group of sensors
available. It is fast and easy to configure.
13.3 The IDS Distribution
System (I(DS)2)
So there I was, faced with a strict budget
and the mandate to monitor up to 400
Mbps of sustained bandwidth (which did
not necessarily follow a symmetric path
through the pair of core switches and three
Internet routers) with an IDS system. I
examined a variety of solutions to make
this work​commercial and open source​and
nothing worked, given the requirements
and budget. I needed to build (or have
someone help me build) a solution that
used off-the-shelf hardware and open
source software that could keep up with
the monstrous volume of traffic. From this
was born the IDS Distribution System
13.3.1 A Little Background
I (Christopher Gerg) am the Network
Security Manager for a data center hosting
company (and ISP) that has an OC-48
SONET ring connecting the data centers
(there are two of them) with the telecom
central offices. There are three redundant
OC-3 Internet connections from the
SONET ring. This traffic all collapses on
a pair of large Cisco switches and from
there onto our data center customers. We
do not use symmetric routing; as a result, a
request can come in from the Internet to
one of our customers in the data center by
entering in router A, passing through
switch A, and then return to the client
through switch B and out router C. Simply
setting up a SPAN port on one of switches
would potentially only allow half of the
conversation to be watched. Figure 13-4
illustrates this asymmetric routing.
Figure 13-4. Asymmetric
13.3.2 The Solution
The multithreaded Linux-kernel-based
policy routing engine was a good start:
fast, thrifty with CPU utilization, and
flexible (routing can be based on protocol
or IP address). The only problem is that
the routing engine only acts on packets
destined for the MAC address of an
interface installed in the system.
Given the extensibility of the Linux kernel,
a custom module that would take all traffic
in one interface, change the MAC address
to that of the policy routing system, and
send the modified packets out another
interface had to be developed. This
module was created and turned out be
easily configured and not very CPUintensive. It is referred to as the Layer 2
Cross-Connect (a.k.a l2cc, a.k.a the MAC
Munger​I still call it the MAC Munger, but
we needed a grown-up name). This kernel
patch allowed me to take the traffic from a
SPAN port on each core switch, aggregate
it into one stream, change the MAC
address of each packet, and forward the
stream onto the Linux Policy Router.
The policy router can be configured to
send all traffic to or from a range of
addresses to a particular IP address (the
IP address of a Snort sensor interface).
The traffic can also be routed based upon
source or destination port, allowing me to
send all web traffic to a particular sensor,
all FTP traffic to another sensor, and so
The inside interface of the Policy Router
is plugged into a fast LAN switch using a
Gigabit fiber link that also has the sensor's
promiscuous monitoring interfaces
connected. Up to this point, all the traffic
travels on Gigabit fiber links. The
switches are able to use 100 Mbps Fast
Ethernet ports and traffic is balanced so as
not to over-saturate these links. The
switch I am using has two Gigabit links,
so I created a SPAN port for the
distribution switch that watches the entire
flow of traffic. A dedicated sensor
watches this SPAN port for portscans and
signs of denial-of-service attacks. Using
tcpdump on this portscan sensor, I can
record all traffic between two hosts for
later examination​an excellent
troubleshooting and forensic tool. Figure
13-5 illustrates the IDS Distribution
Figure 13-5. The IDS
Distribution System (1 Gbps
With the policy router acting on packets, it
was trivial to send particular packets to
particular NIDS sensors. After testing, it
was determined that the systems could
keep up with Gigabit Ethernet at full line
rates. CPU utilization for the l2cc system
at 400 Mbps was 23%; the policy router
ran at 24%. These are 1 GHz Pentium III
Since Internet traffic travels through two
VLANs (one on each core switch), a pair
of NIDS distribution systems could work
in tandem to watch up to two Gbps of
traffic! This potential capacity allows me
to monitor traffic for the foreseeable
future. Figure 13-6 illustrates the twolegged mechanism that allows the load
balancing of up to two Gbps of traffic.
Figure 13-6. IDS Distribution
of up to 2 Gbps
13.3.3 Installation
Installation of the IDS Distribution system
involves a few steps, including one kernel
patch and recompile and one kernel
configuration and recompile. Before
launching into the steps below, you need a
SPAN port configured on the switch you
are monitoring that is making a copy of the
traffic you want to watch. This may be
more than one SPAN port, as in my
example. You need a system for the Layer
2 cross-connect, configured with one
network interface for each of the inbound
SPAN ports, and one for the outbound
aggregated traffic stream. I also include an
additional interface that is on the
dedicated (and protected) management
The outbound port of the Layer 2 crossconnect is plugged directly into one of the
interfaces on the Linux policy router
system. You need another interface for the
outbound routed traffic, connected directly
to the distribution switch. Again, I use an
additional interface on the management
Next, you need the distribution switch. It
can be any enterprise-class workgroup
switch. I use a Cisco Catalyst 3550 for my
setup. It has 24 10/100 Fast Ethernet ports
and 2 Gigabit fiber ports. The outbound
interface of the policy router plugs into
one of the fiber ports and the other fiber
port is configured as a SPAN port of the
first. The portscan/DoS-watch Snort
sensor is plugged into the fiber SPAN port
and watches All the traffic.
Finally, configure as many Snort sensors
as you need to ensure that CPUs and
memory are not being used up and packets
aren't being dropped. Configure each with
a promiscuous network interface that
accepts traffic routed to its IP address by
the policy router. There's another interface
on the management network, also used for
database communication.
My configuration has a dedicated database
server running MySQL. This could be one
of the sensor systems in your environment,
or perhaps an existing database server. Layer 2 crossconnect
The Layer 2 cross-connect (MAC
Munger) can be downloaded from
It contains instructions in the README
(nearly the same as what's below). It
consists of a kernel patch and an
administration application. The kernel
patch has been built to work with the stock
2.4.18 kernel. Development is ongoing to
move it to a more modern kernel. Check
the web site for updates.
Download the archive and extract it to
something like /usr/local/src/l2cc/.
Assuming your kernel source resides in
/usr/src/linux/, execute the following
command line to patch the kernel:
# cd /usr/src/linux
# patch -p1 < /usr/local/src/l2cc/l
Configure the kernel to enable l2cc:
# cd /usr/src/linux
# make menuconfig
Turn on these options:
Code maturity level options --->
[*] Prompt for development an
Networking options --->
[*] Layer 2 Cross Connectr (E
Compile and install the kernel as required
for your system/distribution. If you have
any problems with this, check the
README at the top level of the Linux
kernel source tree.
Compile the l2ccadm admin utility:
# cd /usr/local/src/l2cc/l2cc-linux
# make l2ccadm
If you get errors, try modifying the
CFLAGS variable in the Makefile. The
Makefile is documented to help with this.
To run the Layer 2 cross-connect, use the
l2ccadm utility. This utility has the
command line to change the MAC
addresses of all packets captured on the
SPAN port interfaces to the MAC address
of the outside interface of the policy
router, and forward the packet out another
l2ccadm [-a|-d] -i <interface name
router side> -m <MAC address of out
Adds a cross connect (you can only
have either -a or -d, not both).
Deletes a cross-connect.
Indicates the "in" interface (example:
Indicates the "out" interface
(example: eth1).
This is the MAC address to which all
the packets headers will be modified
in order to indicate the next hop
(since the policy router outside
interface's MAC address). This
tricks the policy router into routing
our packets for us​the real heart of the
IDS-DS. Here's a sample command
# l2ccadm -a -i eth0 -o eth1 -m Policy router
There is nothing fancy about the policy
router​it uses standard Linux policy router
kernel functionality. Indeed, it does not
even have to be a Linux policy router. I
used it because I am familiar with Linux
policy routing and I was on a tight budget.
It's turned out to work magnificently.
You need to enable policy routing in the
kernel using menuconfig:
# cd /usr/src/linux
# make menuconfig
Turn on these options:
Networking options --->
IP: advanced router
IP: policy routing
Compile and install the kernel as required
for your system/distribution. If you have
any problems with this, check the
README at the top level of the Linux
kernel source tree.
Now, configure the policy routing to route
ranges of addresses to particular sensors.
In the example shell script below, we
send all traffic to and from to
the sensor with the IP address of and all traffic to and from to the sensor with the IP
address of eth0 is the
inbound aggregated stream from the l2cc
system and eth1 is the outbound interface
that routes traffic to the sensors.
# Rules to send all traffic to and
ip rule add type unicast from 10.10
ip rule add type unicast to 10.10.0
# Rules to send all traffic to and
ip rule add type unicast from 10.20
ip rule add type unicast to 10.20.0
# map route table 31 to sensor at d
ip route add default via 172.30.16.
# map route table 32 to sensor at d
ip route add default via 172.30.16.
ip route flush cache
echo Showing Rules...
ip rule list
ip route list table 31
ip route list table 32
All that's left to do is plug in the sensors
and get Snort configured and running.
Appendix A. Snort and
ACID Database
The following tables are in a database
configured for Snort and ACID:
Figure A-1 shows the relationship
between the tables.
Figure A-1. The relationship
between the tables
A description of each table follows.
A.1 acid_ag
+----------+------------------+---| Field
| Type
| Nul
+----------+------------------+---| ag_id
| int(10) unsigned |
| ag_name
| varchar(40)
| ag_desc
| text
| ag_ctime | datetime
| ag_ltime | datetime
A.1.1 acid_ag_alert
+--------+------------------+-----| Field
| Type
| Null
+--------+------------------+-----| ag_id
| int(10) unsigned |
| ag_sid | int(10) unsigned |
| ag_cid | int(10) unsigned |
A.1.1.1 acid_event
| Field
| Type
| sid
| int(10) unsigned |
| cid
| int(10) unsigned |
| signature
| int(10) unsigned |
| sig_name
| varchar(255)
| sig_class_id | int(10) unsigned |
| sig_priority | int(10) unsigned |
| timestamp
| datetime
| ip_src
| int(10) unsigned |
| ip_dst
| int(10) unsigned |
| ip_proto
| int(11)
| layer4_sport | int(10) unsigned |
| layer4_dport | int(10) unsigned |
A.1.1.2 acid_ip_cache
+---------------------+-----------| Field
| Type
| ipc_ip
| int(10) uns
| ipc_fqdn
| varchar(50)
| ipc_dns_timestamp
| datetime
| ipc_whois
| text
| ipc_whois_timestamp | datetime
A.1.1.3 data
| Field
| Type
| sid
| int(10) unsigned |
| cid
| int(10) unsigned |
| data_payload | text
A.1.1.4 detail
+-------------+-------------------| Field
| Type
| detail_type | tinyint(3) unsigned
| detail_text | text
A.1.1.5 encoding
+---------------+-----------------| Field
| Type
| encoding_type | tinyint(3) unsign
| encoding_text | text
A.1.1.6 event
+-----------+------------------+--| Field
| Type
| Nu
+-----------+------------------+--| sid
| int(10) unsigned |
| cid
| int(10) unsigned |
| signature | int(10) unsigned |
| timestamp | datetime
A.1.1.7 icmphdr
+-----------+---------------------| Field
| Type
+-----------+---------------------| sid
| int(10) unsigned
| cid
| int(10) unsigned
| icmp_type | tinyint(3) unsigned
| icmp_code | tinyint(3) unsigned
| icmp_csum | smallint(5) unsigned
| icmp_id
| smallint(5) unsigned
| icmp_seq
| smallint(5) unsigned
A.1.1.8 iphdr
| Field
| Type
| sid
| int(10) unsigned
| cid
| int(10) unsigned
| ip_src
| int(10) unsigned
| ip_dst
| int(10) unsigned
| ip_ver
| tinyint(3) unsigned
| ip_hlen
| tinyint(3) unsigned
| ip_tos
| tinyint(3) unsigned
| ip_len
| smallint(5) unsigned |
| ip_id
| smallint(5) unsigned |
| ip_flags | tinyint(3) unsigned
| ip_off
| smallint(5) unsigned |
| ip_ttl
| tinyint(3) unsigned
| ip_proto | tinyint(3) unsigned
| ip_csum
| smallint(5) unsigned |
A.1.1.9 opt
| Field
| Type
| sid
| int(10) unsigned
| cid
| int(10) unsigned
| optid
| int(10) unsigned
| opt_proto | tinyint(3) unsigned |
| opt_code
| tinyint(3) unsigned |
| opt_len
| smallint(6)
| opt_data
| text
A.1.1.10 reference
+---------------+-----------------| Field
| Type
+---------------+-----------------| ref_id
| int(10) unsigned
| ref_system_id | int(10) unsigned
| ref_tag
| text
A.1.1.11 reference_system
| Field
| Type
+-----------------+---------------| ref_system_id
| int(10) unsigne
| ref_system_name | varchar(20)
A.1.1.12 schema
| Field | Type
| Null |
| vseq
| int(10) unsigned |
| ctime | datetime
A.1.1.13 sensor
+-----------+------------------+--| Field
| Type
| Nu
+-----------+------------------+--| sid
| int(10) unsigned |
| hostname
| text
| YE
| interface | text
| YE
| filter
| text
| YE
| detail
| tinyint(4)
| YE
| encoding
| tinyint(4)
| YE
| last_cid
| int(10) unsigned |
A.1.1.14 sig_class
+----------------+----------------| Field
| Type
+----------------+----------------| sig_class_id
| int(10) unsigned
| sig_class_name | varchar(60)
A.1.1.15 sig_reference
+---------+------------------+----| Field
| Type
| Null
+---------+------------------+----| sig_id
| int(10) unsigned |
| ref_seq | int(10) unsigned |
| ref_id
| int(10) unsigned |
A.1.1.16 signature
| Field
| Type
| sig_id
| int(10) unsigned |
| sig_name
| varchar(255)
| sig_class_id | int(10) unsigned |
| sig_priority | int(10) unsigned |
| sig_rev
| int(10) unsigned |
| sig_sid
| int(10) unsigned |
A.1.1.17 tcphdr
+-----------+---------------------| Field
| Type
+-----------+---------------------| sid
| int(10) unsigned
| cid
| int(10) unsigned
| tcp_sport | smallint(5) unsigned
| tcp_dport | smallint(5) unsigned
| tcp_seq
| int(10) unsigned
| tcp_ack
| int(10) unsigned
| tcp_off
| tinyint(3) unsigned
| tcp_res
| tinyint(3) unsigned
| tcp_flags | tinyint(3) unsigned
| tcp_win
| smallint(5) unsigned
| tcp_csum
| smallint(5) unsigned
| tcp_urp
| smallint(5) unsigned
A.1.1.18 udphdr
+-----------+---------------------| Field
| Type
| sid
| int(10) unsigned
| cid
| int(10) unsigned
| udp_sport | smallint(5) unsigned
| udp_dport | smallint(5) unsigned
| udp_len
| smallint(5) unsigned
| udp_csum
| smallint(5) unsigned
Appendix B. The
Default snort.conf File
Contact: [email protected]
$ Id: snort.conf,v 1.333.2.3 200
# This file contains a sample snort
# You can take the following steps
1) Set the network variables for
2) Configure preprocessors
3) Configure output plugins
4) Customize your rule set
# Step #1: Set the network variable
# You must change the following var
# variable is currently setup for a
# You can specify it explicitly as:
# var HOME_NET
# or use global variable $<interfac
# initialized to IP address and net
# snort at.
Under Windows, this mu
# $(<interfacename>_ADDRESS), such
# $(\Device\Packet_{12345678-90AB-C
# var HOME_NET $eth0_ADDRESS
# You can specify lists of IP addre
# by separating the IPs with commas
# var HOME_NET [,192.168
# or you can specify the variable t
# like this:
var HOME_NET any
# Set up the external network addre
# Configure your server lists.
# systems that have a service up.
# running a web server?
This allow
# These configurations MUST follow
# above for $HOME_NET.
# List of DNS servers on your netwo
# List of SMTP servers on your netw
# List of web servers on your netwo
# List of sql servers on your netwo
# List of telnet servers on your ne
# List of snmp servers on your netw
# Configure your service ports.
# to a specific application only on
# example, if you run a web server
# like this:
# var HTTP_PORTS 8081
# Port lists must either be continu
# We will adding support for a real
# Ports you run web servers on
# Please note:
[80,8080] does not
# If you wish to define multiple HT
## var HTTP_PORTS 80
## include somefile.rules
## var HTTP_PORTS 8080
## include somefile.rules
# Ports you want to look for SHELLC
# Ports you do oracle attacks on
# other variables
# AIM servers.
AOL has a habit of
# modifying the signatures when the
var AIM_SERVERS # [,64
# Path to your rules files (this ca
var RULE_PATH ../rules
# Configure the snort decoder
# ============================
# Snort's decoder will alert on lot
# truncation or options of unusual
# Stop generic decode events:
# config disable_decode_alerts
# Stop Alerts on experimental TCP o
# config disable_tcpopt_experimenta
# Stop Alerts on obsolete TCP optio
# config disable_tcpopt_obsolete_al
# Stop Alerts on T/TCP alerts
# In snort 2.0.1 and above, this on
# that shows T/TCP being actively u
# behavior for your network, disabl
# config disable_tcpopt_ttcp_alerts
# Stop Alerts on all other TCPOptio
# config disable_tcpopt_alerts
# Stop Alerts on invalid ip options
# config disable_ipopt_alerts
# Configure the detection engine
# ===============================
# Use a different pattern matcher i
# resources:
# config detection: search-method l
# Step #2: Configure preprocessors
# General configuration for preproc
# the form
# preprocessor <name_of_processor>:
# Configure Flow tracking module
# ------------------------------#
# The Flow tracking module is meant
# mechanisms of snort into a single
# is implemented but in the long te
# snort will be migrated over to be
# for flow-portscan to work correct
# See README.flow for additional in
preprocessor flow: stats_interval 0
# frag2: IP defragmentation support
# -------------------------------
# This preprocessor performs IP def
# people launching fragmentation at
# arguments loads the default confi
# second timeout and a 4MB fragment
# The following (comma delimited) o
timeout [seconds] - sets the n
fragment w
if this ti
memcap [bytes] - limit frag2 m
min_ttl [number] - minimum ttl
ttl_limit [number] - differenc
will caus
# Frag2 uses Generator ID 113 and u
# for that GID:
# -----
Event description
Oversized fragment (rea
Teardrop-type attack
preprocessor frag2
# stream4: stateful inspection/stre
# Use in concert with the -z [all|e
# against TCP rules.
Also performs
# inspection of TCP streams, etc.
# types, fingerprinting, ECN, etc.
# stateful inspection directive
# no arguments loads the defaults (
# options (options are comma delimi
detect_scans - stream4 will det
when it sees the
detect_state_problems - detect
noisy b
disable_evasion_alerts - turn o
min_ttl [number]
- set a
ttl_limit [number]
- differ
the n
keepstats [machine|binary] - ke
get them
noinspect - turn off stateful i
timeout [number] - set the sess
default is 3
memcap [number] - limit stream4
log_flushed_streams - if an eve
cause all
packet bu
works whe
# Stream4 uses Generator ID 111 and
# for that GID:
# -----
Event description
Stealth activity
Evasive RST packet
Evasive TCP packet retr
TCP Window violation
Data on SYN packet
Stealth scan: full XMAS
Stealth scan: SYN-ACK-P
Stealth scan: FIN scan
Stealth scan: NULL scan
Stealth scan: NMAP XMAS
Stealth scan: Vecna sca
Stealth scan: NMAP fing
Stealth scan: SYN-FIN s
TCP forward overlap
preprocessor stream4: disable_evasi
# tcp stream reassembly directive
# no arguments loads the default co
Only reassemble the client,
Only reassemble the default lis
Give alerts for "bad" streams
# Available options (comma delimite
clientonly - reassemble traffic
serveronly - reassemble traffic
both - reassemble both sides of
noalerts - turn off alerts from
ports [list] - use the space se
will turn on rea
on reassembly fo
and 513
preprocessor stream4_reassemble
# http_inspect: normalize and detec
# lots of options available here. S
# should be wherever yo
# a full path to where snort can fi
preprocessor http_inspect: global \
iis_unicode_map 125
preprocessor http_inspect_server: s
profile all ports { 80 8080 818
Example unique server configurat
#preprocessor http_inspect_server:
ports { 80 3128 8080 } \
flow_depth 0 \
ascii no \
double_decode yes \
non_rfc_char { 0x00 } \
chunk_length 500000 \
non_strict \
oversize_dir_length 300 \
# rpc_decode: normalize RPC traffic
# ---------------------------------
# RPC may be sent in alternate enco
# that is used by default. This plu
# services are running on as argume
# are actually running this type of
# it off.
# The RPC decode preprocessor uses
# arguments: space separated list
# alert_fragments - alert on any rp
# no_alert_multiple_requests - don'
# no_alert_large_fragments - don't
# no_alert_incomplete - don't alert
exceeds the
preprocessor rpc_decode: 111 32771
# bo: Back Orifice detector
# -------------------------
# Detects Back Orifice traffic on t
# The Back Orifice detector uses Ge
# following SIDS for that GID:
Event description
# ----#
Back Orifice traffic de
preprocessor bo
# telnet_decode: Telnet negotiation
# ---------------------------------
# This preprocessor "normalizes" te
# traffic.
It works in much the sa
# searching for traffic that breaks
# replacing it with a normalized re
# "content" pattern matching keywor
# This preprocessor requires no arg
# Portscan uses Generator ID 109 an
preprocessor telnet_decode
# Flow-Portscan: detect a variety o
# --------------------------------# Note:
The Flow preprocessor (abo
# work.
# This module detects portscans bas
# preprocessors.
The goal is to ca
# ports scans.
# Flow-Portscan has numerous option
# README.flow-portscan for help con
# Flow-Portscan uses Generator ID 1
# -----
Event description
flow-portscan: Fixed Sc
flow-portscan: Sliding
flow-portscan: Fixed Sc
flow-portscan: Sliding
# preprocessor flow-portscan: \
talker-fixed-threshold 30 \
talker-sliding-threshold 30
talker-sliding-window 20 \
talker-fixed-window 30 \
scoreboard-rows-talker 3000
server-watchnet [
server-ignore-limit 200 \
server-rows 65535 \
server-learning-time 14400
server-scanner-limit 4 \
scanner-sliding-window 20 \
scanner-fixed-threshold 15
scanner-sliding-threshold 4
scanner-fixed-window 15 \
scoreboard-rows-scanner 300
src-ignore-net [
dst-ignore-net [
alert-mode once \
output-mode msg \
tcp-penalties on
# arpspoof
# Experimental ARP detection code f
# unicast ARP requests, and specifi
# this preprocessor you must specif
# the same layer 2 segment as you.
# Also takes a "-unicast" option to
# Arpspoof uses Generator ID 112 an
# -----
Event description
Unicast ARP request
Etherframe ARP mismatch
Etherframe ARP mismatch
ARP cache overwrite att
#preprocessor arpspoof
#preprocessor arpspoof_detect_host:
# Performance Statistics
# ----------------------
# Documentation for this is provide
# It is included in the release dis
# preprocessor perfmonitor: time 30
# Step #3: Configure output plugins
# Uncomment and configure the outpu
# configuration for output plugins
# output <name_of_plugin>: <configu
# alert_syslog: log alerts to syslo
# ---------------------------------
# Use one or more syslog facilities
# specify a particular hostname/por
# '', and the default port
# [Unix flavours should use this fo
# output alert_syslog: LOG_AUTH LOG
# [Win32 can use any of these forma
# output alert_syslog: LOG_AUTH LOG
# output alert_syslog: host=hostnam
# output alert_syslog: host=hostnam
# log_tcpdump: log packets in binar
# ---------------------------------
# The only argument is the output f
# output log_tcpdump: tcpdump.log
# database: log to a variety of dat
# --------------------------------# See the README.database file for
# and using this plugin.
# output database: log, mysql, user
# output database: alert, postgresq
# output database: log, odbc, user=
# output database: log, mssql, dbna
# output database: log, oracle, dbn
# unified: Snort unified binary for
# ---------------------------------
# The unified output plugin provide
# alerts from Snort, the "unified"
# binary format for logging data ou
# efficient.
Used with barnyard (t
# overhead for logging and alerting
# databases or the network can now
# Check out the spo_unified.h file
# Two arguments are supported.
filename - base filename to wr
- maximum size of spo
# output alert_unified: filename sn
# output log_unified: filename snor
# You can optionally define new rul
# plugins specifically to that type
# This example will create a type t
# ruletype suspicious
# {
type log
output log_tcpdump: suspicious.
# }
# suspicious tcp $HOME_NET any -> $
# This example will create a rule t
# database:
# ruletype redalert
# {
type alert
output alert_syslog: LOG_AUTH L
output database: log, mysql, us
# }
# redalert tcp $HOME_NET any -> $EX
(msg:"Someone is being LEET"; f
# Include classification & priority
include classification.config
# Include reference systems
include reference.config
# Step #4: Customize your rule set
# Up to date snort rules are availa
# The snort web site has documentat
# rules.
# The rules included with this dist
# suspicious activity. Depending on
# policies, and what you consider t
# either generate false positives o
# be acceptable; therefore, you are
# not applicable in your environmen
# The following individuals contrib
# Credits:
Ron Gula <[email protected]
Max Vision <[email protected]
Martin Markgraf <[email protected]
Fyodor Yarochkin <[email protected]
Nick Rogness <[email protected]
Jim Forster <[email protected]
Scott McIntyre <[email protected]>
Tom Vandepoel <[email protected]
Brian Caswell <[email protected]>
Zeno <[email protected]>
Ryan Russell <[email protected]
# Include all relevant rulesets her
# The following rulesets are disabl
web-attacks, backdoor, shellcod
chat, multimedia, and p2p
# These rules are either site polic
# generate false positive alerts in
# Please read the specific include
# README.alert_order for how rule o
include $RULE_PATH/local.rules
include $RULE_PATH/bad-traffic.rule
include $RULE_PATH/exploit.rules
include $RULE_PATH/scan.rules
include $RULE_PATH/finger.rules
include $RULE_PATH/ftp.rules
include $RULE_PATH/telnet.rules
include $RULE_PATH/rpc.rules
include $RULE_PATH/rservices.rules
include $RULE_PATH/dos.rules
include $RULE_PATH/ddos.rules
include $RULE_PATH/dns.rules
include $RULE_PATH/tftp.rules
include $RULE_PATH/web-cgi.rules
include $RULE_PATH/web-coldfusion.r
include $RULE_PATH/web-iis.rules
include $RULE_PATH/
include $RULE_PATH/web-misc.rules
include $RULE_PATH/web-client.rules
include $RULE_PATH/web-php.rules
include $RULE_PATH/sql.rules
include $RULE_PATH/x11.rules
include $RULE_PATH/icmp.rules
include $RULE_PATH/netbios.rules
include $RULE_PATH/misc.rules
include $RULE_PATH/attack-responses
include $RULE_PATH/oracle.rules
include $RULE_PATH/mysql.rules
include $RULE_PATH/snmp.rules
include $RULE_PATH/smtp.rules
include $RULE_PATH/imap.rules
include $RULE_PATH/pop2.rules
include $RULE_PATH/pop3.rules
include $RULE_PATH/nntp.rules
include $RULE_PATH/other-ids.rules
# include $RULE_PATH/
# include $RULE_PATH/backdoor.rules
# include $RULE_PATH/shellcode.rule
# include $RULE_PATH/policy.rules
# include $RULE_PATH/porn.rules
# include $RULE_PATH/info.rules
# include $RULE_PATH/icmp-info.rule
# include $RULE_PATH/virus.rules
# include $RULE_PATH/chat.rules
# include $RULE_PATH/multimedia.rul
# include $RULE_PATH/p2p.rules
include $RULE_PATH/experimental.rul
# Include any thresholding or suppr
# <snort src>/etc directory for det
# contained in this conf, but a sep
# Uncomment if needed.
# include threshold.conf
Appendix C. Resources
Section C.1. From Chapter 1:
Section C.2. From Chapter 2:
Network Traffic Analysis
Section C.3. From Chapter 4: Know
Your Enemy
Section C.4. From Chapter 6:
Deploying Snort
Section C.5. From Chapter 7:
Creating and Managing Snort Rules
Section C.6. From Chapter 8:
Intrusion Prevention
Section C.7. From Chapter 10:
Using ACID as a Snort IDS
Management Console
Section C.8. From Chapter 12:
Additional Tools for Snort IDS
Section C.9. From Chapter 13:
Strategies for High-Bandwidth
Implementations of Snort
C.1 From Chapter 1:
Snort's homepage
SecurityFocus IDS
The SANS Institute
CERT homepage
The NSA Security
tcpdump homepage
Ethereal homepage
C.2 From Chapter 2:
Network Traffic Analysis
C.3 From Chapter 4: Know
Your Enemy
Broadband Reports
DoS Help
ID Serve
IP Calculator / IP
ISECOM Security
John the Ripper
L0phtCrack LC4
GNU Netcat
The Packetfactory
Tenable Security
Razor Security
Reverse WWW
Sam Spade
SSL Proxy
C.4 From Chapter 6:
Deploying Snort
Guide to
Guide to
Apache 1.3
Security Tips
Apache 2.0 Tips 2.0/misc/security_tips.html
Security Tips
NSA Secure
C.5 From Chapter 7:
Creating and Managing
Snort Rules
Snort-sigs list sigs
C.6 From Chapter 8:
Intrusion Prevention
The HoneyNet
Snort Inline Patch
C.7 From Chapter 10: Using
ACID as a Snort IDS
Management Console
Apache Web
Web Server
guide for
RedHat 9
guide for
Solaris 9
guide for
C.8 From Chapter 12:
Additional Tools for Snort
IDS Management
IDS Policy
C.9 From Chapter 13:
Strategies for HighBandwidth Implementations
of Snort
The Layer 2
Our look is the result of reader comments,
our own experimentation, and feedback
from distribution channels. Distinctive
covers complement our distinctive
approach to technical topics, breathing
personality and life into potentially dry
The image on the cover of Managing
Security with Snort and IDS Tools is a
man on a rope with an ax.
Colleen Gorman was the production
editor and copyeditor for Managing
Security with Snort and IDS Tools. Emily
Quill, Genevieve d'Entremont, and Claire
Cloutier provided quality control. Julie
Hawks wrote the index.
Emma Colby designed the cover of this
book, based on a series design by Edie
Freedman. The cover image is a 19thcentury engraving from Men: A Pictorial
Archive. Emma Colby produced the cover
layout with QuarkXPress 4.1 using
Adobe's ITC Garamond font.
David Futato designed the interior layout.
This book was converted by Julie Hawks
to FrameMaker 5.5.6 with a format
conversion tool created by Erik Ray,
Jason McIntosh, Neil Walls, and Mike
Sierra that uses Perl and XML
technologies. The text font is Linotype
Birka; the heading font is Adobe Myriad
Condensed; and the code font is
LucasFont's TheSans Mono Condensed.
The illustrations that appear in the book
were produced by Robert Romano and
Jessamyn Read using Macromedia
FreeHand 9 and Adobe Photoshop 6. The
tip and warning icons were drawn by
Christopher Bing. This colophon was
written by Colleen Gorman.
The online edition of this book was
created by the Safari production group
(John Chodacki, Becki Maisch, and Ellie
Cutler) using a set of Frame-to-XML
conversion and cleanup tools written and
maintained by Erik Ray, Benn Salter, John
Chodacki, Ellie Cutler, and Jeff Liggett.
[SYMBOL] [A] [B] [C] [D] [E] [F]
[G] [H] [I] [J] [K] [L] [M] [N] [O]
[P] [Q] [R] [S] [T] [U] [V] [W]
[X] [Y] [Z]
[SYMBOL] [A] [B] [C] [D] [E] [F]
[G] [H] [I] [J] [K] [L] [M] [N] [O]
[P] [Q] [R] [S] [T] [U] [V] [W]
[X] [Y] [Z]
! (NOT) directive
[SYMBOL] [A] [B] [C] [D] [E] [F]
[G] [H] [I] [J] [K] [L] [M] [N] [O]
[P] [Q] [R] [S] [T] [U] [V] [W]
[X] [Y] [Z]
accept option (snortsam.conf)
access control lists
ACID (Analysis Console for Intrusion
Alert Group (AG) maintenance
alert information
Alert Listing page
analyzing captured data
Apache [See Apache,
installing and configuring]
confirming GD support
ongoing utilization of
customizing configuration files
sending alert information to
sending log information to
database schema
GD and
Graph Alert Data link 2nd
Graph alert detection time
identifying known attacks
IDS Management Console
initializing web page
installing and configuring
main interface
installing and configuring]
notifying offender
on-the-fly graphing
packets with nonidentifiable yet
suspicious content
portscan traffic
protocol traffic
Query DB button
Query Results page
Search capabilities
searching database
security issues
sensors capturing data
summary of dependencies for
tracking alerts
typical packet capture
view only portal
viewing packets
acid_ag table
acid_ag_alert table
acid_conf.php file
acid_event table
acid_ip_cache table
ack: rule option
acknowledgment (ACK)
Action field (rule headers)
Address Resolution Protocol (ARP)
AIM_SERVERS variable (snort.conf)
alert file
alert-mode option (flow-portscan
alert_fragments option (rpc_decode
alert_syslog plug-in
alert_with_interface_name option
alertfile: alerts option (snort.conf)
checking machines generating
controlling number of
generated by Snort
throttling technique
unreachable destination
allow_proxy_use option
antivirus software versus signature-based
changing User and Group variables
compiling code from source
displaying static files in empty root
FancyIndexing option
final configurations
forked httpd processes
htpasswd utility
installing and configuring
installing from RPMs
managing dependencies
nikto run on
nobody and httpd users
running secure web sites
[See web
sites, running secure]
testing PHP integration
turning ServerSignature setting to Off
verifying web daemon manages PHP
Version 2.0 Security Tips
Version1.3 Security Tips
web daemon, automating startup
web page
web server
disabling rule set
apache_whitespace option
application behavior boundary flaws
Applied Watch
Applied Watch Technologies
archiving logged Snort packets
ARP (Address Resolution Protocol)
arpspoof preprocessor
ascii option (http_inspect_server)
ASCII packet dump mode
attack_responses.rules rule set
disgruntled employees
using fragmentation
anatomy of
[See penetrate
attack phase]
probe [See
probe attack
[See denial-of-
service attacks]
detecting latest methods
familiarizing yourself on different
IDS evasion
attempted-recon signature
authentication grinding
[SYMBOL] [A] [B] [C] [D] [E] [F]
[G] [H] [I] [J] [K] [L] [M] [N] [O]
[P] [Q] [R] [S] [T] [U] [V] [W]
[X] [Y] [Z]
Back Orifice
backdoor network connections
bare_byte option (http_inspect_server)
Barnyard 2nd
command-line options
configuring [See barnyard.conf
running in background
barnyard.conf file
declarations section
output plug-ins section
base-score option (flow-portscan
base36 option (http_inspect_server)
Berkeley Packet Filters (BPF)
biometric authentication
blackhole lists
Blaster worm
blindly probing large subnets for
vulnerable devices
block (react response keyword)
blocking legitimate traffic
blocking requests, modifying rules that
bo preprocessor
both option (stream4_reassemble
boundary flaws, application behavior
bpf_file: filters.bpf option (snort.conf)
Broadband Reports
buffer overflows
build-time options when installing Snort
[SYMBOL] [A] [B] [C] [D] [E] [F]
[G] [H] [I] [J] [K] [L] [M] [N] [O]
[P] [Q] [R] [S] [T] [U] [V] [W]
[X] [Y] [Z]
Cerebus 2nd
CERT 2nd
CGI services, detecting attacks to
change management, poor
character data, printing
chat protocols, detecting
Checkpoint Firewall-1 and SnortSAM
checksum_mode : option (snort.conf)
chroot: option (snort.conf)
chunk_length option
Catalyst 3550
PIX Firewall and SnortSAM
routers and SnortSAM
classtype: rule option
clientonly option (stream4_reassemble
Code Red worm
detecting attacks to services
disabling rule set
command-line options (Snort)
-A alert-mode
-B address-conversion-mask
-c config-file
-F bpf-file
-g group
-h home-net
-i interface
-k checksum-mode
-L binary-log-file
-l logging-directory
-m umask
-n packet-count
-P snap-length
-r tcpdump-file
-S variable
-t chroot
-u user
configuration file
[See snort.conf
[See also
snort.conf file]
configuring Snort
initial configuration 2nd
connection points, creating
content helpers (rule options)
Content Switch
content: rule option
content_list: rule option
create_mysql script
granting rights to primary user
Cult of the Dead Cow
curl binary, installing
current, staying
[SYMBOL] [A] [B] [C] [D] [E] [F]
[G] [H] [I] [J] [K] [L] [M] [N] [O]
[P] [Q] [R] [S] [T] [U] [V] [W]
[X] [Y] [Z]
daemon mode, running Snort in
daemon option (snort.conf)
daemon option (snortsam.conf)
Danyliw, Roman
data table
database output plug-in
database plug-in
database schema for Snort and ACID
day zero attack
decode_arp option (snort.conf)
decode_data_link option (snort.conf)
detection engine configuration
default option (http_inspect_server)
defaultkey option (snortsam.conf)
denial-of-service attacks
detecting 2nd
deploying Snort
depth: rule option
Destination Address field (rule headers)
Destination Port field (rule headers)
detail table
detect_anomalous_servers option
(http_inspect preprocessor)
detect_scans option (stream4
detect_state_problems option (frag2
detect_state_problems option (stream4
directory option (http_inspect_server)
disable_decode_alerts option
disable_evasion_alerts option (stream4
disable_ipopt_alerts option (snort.conf)
disable_tcpopt_alerts option (snort.conf)
option (snort.conf)
disable_tcpopt_obsolete_alerts option
disable_tcpopt_ttcp_alerts option
disgruntled employees
DMZ and sensor placement
DNS servers, detecting attacks on
DNS_SERVERS variable (snort.conf)
dontblock option (snortsam.conf)
double_decode option
download resources
drift net scans
drop rule action
DServe Web Server Identification Tool
dsize: rule option
dst-ignore-net option (flow-portscan
dump_chars_only option (snort.conf)
dump_payload option (snort.conf)
dump_payload_verbose option
dumpall option (flow-portscan
[SYMBOL] [A] [B] [C] [D] [E] [F]
[G] [H] [I] [J] [K] [L] [M] [N] [O]
[P] [Q] [R] [S] [T] [U] [V] [W]
[X] [Y] [Z]
encoding table
encrypted traffic 2nd
enterprise-class switches
ethereal 2nd
Capture drop-down menu
capture of three-way handshake
Capture Options menu
Display drop-down window
Edit drop-down menu
following particular TCP stream
installing from source
network analyzer
real-time packet capture session
event table
exploit beating attempted block
EXTERNAL_NET variable (snort.conf)
[SYMBOL] [A] [B] [C] [D] [E] [F]
[G] [H] [I] [J] [K] [L] [M] [N] [O]
[P] [Q] [R] [S] [T] [U] [V] [W]
[X] [Y] [Z]
F5 Networks
false negative
managing alerts
false negatives
common causes of
day zero attack
faulty signatures
network configuration problems
poor change management
sensor administration problems
traffic encryption
false positives
and non-security related issues
checking rule generating alert
IPS (Intrusion Prevention System) and
managing alerts
sources of
watching internal LAN traffic and
file inclusions
file mode creation mask, setting
finger service, detecting attacks on
fingerprint attempts
Firewalk 2nd
alternatives to
running Snort behind
Snort running as
flags: rule option
flexible response
flow control
flow preprocessor
flow-portscan preprocessor
flow_depth option (http_inspect_server)
frag2 preprocessor
fragbits: rule option
fragmentation attacks 2nd
Fragroute 2nd 3rd
additional libraries
FreeBSD installation guide
FrontPage Extensions, disabling rule set
Frontpage web authoring services,
detecting attacks to
FTP (File Transfer Protocol)
detecting attacks to
fwsam rule option
[SYMBOL] [A] [B] [C] [D] [E] [F]
[G] [H] [I] [J] [K] [L] [M] [N] [O]
[P] [Q] [R] [S] [T] [U] [V] [W]
[X] [Y] [Z]
Gateway IDS (GIDS) 2nd 3rd
changing after initialization
confirming support
gen_id parameter
Gigabit fiber link
GNU Netcat
Guide to Hardening BSD
Guide to Hardening Linux
Gullet, David
[SYMBOL] [A] [B] [C] [D] [E] [F]
[G] [H] [I] [J] [K] [L] [M] [N] [O]
[P] [Q] [R] [S] [T] [U] [V] [W]
[X] [Y] [Z]
hash option (flow preprocessor)
high-bandwidth implementations of Snort,
strategies for
Hoagland, Jim
Hogue, Jonathan
home network, setting to specific address
in CIDR format
HOME_NET variable (snort.conf)
Honeynet project
HoneyNet Project
host-based memory and process
hping 2nd
http_inspect preprocessor
global options
HTTP_PORTS variable (snort.conf)
HTTP_SERVERS variable (snort.conf)
httpd.conf file
[SYMBOL] [A] [B] [C] [D] [E] [F]
[G] [H] [I] [J] [K] [L] [M] [N] [O]
[P] [Q] [R] [S] [T] [U] [V] [W]
[X] [Y] [Z]
ICMP (Internet Control Message
troubleshooting network problems
icmp_all (response keyword)
icmp_host (response keyword)
icmp_id: rule option
icmp_net (response keyword)
icmp_port (response keyword)
icmp_seq: rule option
icmphdr table
icode: rule option
ID Serve
id: rule option
detecting traffic generated by other
load balancers
log retention requirements
Policy Manager 2nd
signature-based versus antivirus
IDS Distribution System (I(DS)2)
IDS management
commercial tools
Applied Watch Console
PureSecure Console
Sourcefire Management Console
open source tools
IDS Policy Manager
SnortCenter [See SnortCenter]
IDs, changing after initialization 2nd
IDSPolMan 2nd
IEEE OUI and Company_id Assignments
iis_backslash option
iis_delimeter option
iis_Unicode option (http_inspect_server)
iis_Unicode_map option (http_inspect
iis_Unicode_map option
illegal packet header settings
IMAP email service, detecting attacks to
implied trust
include command
include option (snortsam.conf)
inline patch (Snort)
configuring Snort
creating rules for
inspect_uri_only option
installing Snort
build-time options
source code installation
staying current
Windows installations
instant messengers, detecting
interface: option (snort.conf)
configuring with sensors
monitoring multiple
promiscuous mode
Snort listens on
Internet Control Message Protocol
Internet Information Server (IIS) web
servers, detecting attacks to
Internet Information Services (IIS) web
server, disabling rule set
Internet Protocol (IP)
intrusion detection
approaches to
network, challenges of
false positives
missing prerequisites
unrealistic expectations
intrusion prevention [See also
Intrusion Prevention System [See
IP (Internet Protocol)
IP addresses
gathering information regarding
listing in rule headers
mapping to MAC addresses
negating in rule headers
IP Calculator / IP Subnetting
IP Filter (ipf) - Unix-based OS firewall
and SnortSAM
IP header
IP stacks (TCP/IP)
IP-Tools 2nd
ip_proto: rule option
ipchains and SnortSAM
ipchains option (snortsam.conf)
iphdr table
ipopts: rule option
IPS (Intrusion Prevention System)
deployment risks
blocking legitimate traffic
exploit beating attempted block
self-inflicted denial-of-service
session interception IPS
iptables and SnortSAM
iptables option (snortsam.conf)
ISECOM Security Tools
itype: rule option
[SYMBOL] [A] [B] [C] [D] [E] [F]
[G] [H] [I] [J] [K] [L] [M] [N] [O]
[P] [Q] [R] [S] [T] [U] [V] [W]
[X] [Y] [Z]
John the Ripper 2nd
JpGraph 2nd
[SYMBOL] [A] [B] [C] [D] [E] [F]
[G] [H] [I] [J] [K] [L] [M] [N] [O]
[P] [Q] [R] [S] [T] [U] [V] [W]
[X] [Y] [Z]
keepstats option (stream4 preprocessor)
[SYMBOL] [A] [B] [C] [D] [E] [F]
[G] [H] [I] [J] [K] [L] [M] [N] [O]
[P] [Q] [R] [S] [T] [U] [V] [W]
[X] [Y] [Z]
L0phtCrack LC4
Layer 2 Cross-Connect
Layer 2 cross-connect (MAC Munger)
libpcap library
LibWhisker's anti-IDS methods
limit type thresholding example
ipchains and SnortSAM
iptables and SnortSAM
versus Windows when deciding which
OS to use for Snort sensor
load balancers
commercial IDS
local.rules file
log_flushed_streams option (stream4
log_tcpdump plug-in
log_unified output plug-in
logdir: option (snort.conf)
logfile option (snortsam.conf)
logfiles, setting filename
IDS log retention requirements
monitoring system logs
binary dumps
naming files
tcpdump format
specifying directory
turning off packet
loglevel option (snortsam.conf)
logto: rule option
[SYMBOL] [A] [B] [C] [D] [E] [F]
[G] [H] [I] [J] [K] [L] [M] [N] [O]
[P] [Q] [R] [S] [T] [U] [V] [W]
[X] [Y] [Z]
MAC addresses, mapping to IP addresses
mailing.unix.snort newsgroup
management network
managing Snort sensors [See IDS
memcap option (flow preprocessor)
memcap option (frag2 preprocessor)
memcap option (stream4 preprocessor)
Microsoft Central Security Portal
Microsoft SQL Server logging
min_ttl option (frag2 preprocessor)
min_ttl option (stream4 preprocessor)
mining the web
modes of operation (Snort)
msg (react response keyword)
msg: rule option
multi_slash option (http_inspect_server)
multimedia applications, detecting on
adding tables and permissions
cleaning house or reinstalling
creating user login that cannot delete
alerts from Snort database
detecting attacks to
disabling rule set
installing and configuring
root password
RPM install
Security Tips
setting passwords
source install
viewing users and access
MySQL Database Server
mysqld service in Red Hat Linux
[SYMBOL] [A] [B] [C] [D] [E] [F]
[G] [H] [I] [J] [K] [L] [M] [N] [O]
[P] [Q] [R] [S] [T] [U] [V] [W]
[X] [Y] [Z]
Nachi worm
Nessus 2nd
downloading and installing
keeping current
Snort alerts and
Snort output from scan
viewing final report
NetBIOS scanning
Netcat site
Netscreen firewall and SnortSAM
configuration problems
detecting scans
time protocol servers, detecting
attacks to
traffic analysis
traffic, capturing small snapshot of
Network Interface Card (NIC)
network packets
IP header
TCP header
NFS (Network File System)
mode, running Snort in
running Snort as
context for
Snort as
IDS evasion mode
installing and running
Apache sample results
Nmap 2nd
home page
how best run
scans and Snort installations
web-based attacks
no_alert_incomplete option (rpc_decode
no_alert_large_fragments option
(rpc_decode preprocessor)
no_alert_multiple_requests option
(rpc_decode preprocessor)
no_alerts option (http_inspect_server)
no_pipeline_req option
no_promisc option (snort.conf)
noalerts option (stream4_reassemble
nocase; rule option
noinspect option (stream4 preprocessor)
nolog option (snort.conf)
non_rfc_char option
non_strict option (http_inspect_server)
NOT (!) directive
NSA Secure Configuration Guides
NSA Security Guides
[SYMBOL] [A] [B] [C] [D] [E] [F]
[G] [H] [I] [J] [K] [L] [M] [N] [O]
[P] [Q] [R] [S] [T] [U] [V] [W]
[X] [Y] [Z]
obfuscate option (snort.conf)
ODBC logging
offset: rule option
Oinkmaster 2nd
one-time password generators
open source applications, challenges of
OpenSSL, compiling
operating system, choosing for securing
opt table
options, listing
database servers, detecting attacks to
database, disabling rule set
ORACLE_PORTS variable (snort.conf)
order: [pass, alert, log, activation, or
dynamic] option (snort.conf)
Outlook Web Access traffic, detecting
output configurations
output-mode option (flow-portscan
oversize_dir_length option
[SYMBOL] [A] [B] [C] [D] [E] [F]
[G] [H] [I] [J] [K] [L] [M] [N] [O]
[P] [Q] [R] [S] [T] [U] [V] [W]
[X] [Y] [Z]
p0f (Passive OS Fingerprinting Tool)
packets [See also network
capture length
changing order of rules applied to
checksums, controlling
illegal header settings
logging, turning off
viewing in ACID
with nonidentifiable yet suspicious
paralyze attack phase
pass rules
confusing MySQL root with Linux
cracking utilities
locking accounts after bad guesses
one-time password generators
patching Snort to enable support for
Pcap tutorial
peer-to-peer software, detecting activity
generated by
penetrate attack phase
application behavior boundary flaws
authentication grinding
buffer overflows
system configuration errors
user input validation problems
perfmonitor preprocessor
persist attack phase
application services, disabling rule
applications, detecting attacks to
enabling modules
Hypertext Preprocessor
source code, configuring for
integration with Apache2
testing Apache integration
ping of death attack
pings specific to particular attack tools,
pix option (snortsam.conf)
pkt_count: option (snort.conf)
policy router 2nd
POP2 email service, detecting attacks to
POP3 email service, detecting attacks to
port option (snortsam.conf)
ports option (http_inspect_server)
ports option (stream4_reassemble
software version-mapping and
PostgrSQL logging
preprocessor configuration
flow, configuring
flow-portscan, configuring
frag2, configuring
http_inspect, configuring
stream4_reassemble, configuring
printing packets to console
prioritizing systems and networks to
priority: rule option
probe attack phase
mining the web
vulnerability scanners
web page scanners
profile option (http_inspect_server)
promiscuous mode (network interfaces)
promiscuous mode sniffing, turning off
propogate attack phase
Protocol field (rule headers)
proxy (react response keyword)
proxy_alert option (http_inspect
PureSecure Console 2nd
PureSecure Personal Console
[SYMBOL] [A] [B] [C] [D] [E] [F]
[G] [H] [I] [J] [K] [L] [M] [N] [O]
[P] [Q] [R] [S] [T] [U] [V] [W]
[X] [Y] [Z]
quiet option (snort.conf)
quietly, running Snort
[SYMBOL] [A] [B] [C] [D] [E] [F]
[G] [H] [I] [J] [K] [L] [M] [N] [O]
[P] [Q] [R] [S] [T] [U] [V] [W]
[X] [Y] [Z]
Rain Forest Puppy
raw packet data, displaying
Razor Security
react response
react: rule option
real-time intrusion detection
RedHat 9 installation guide
redirecting normal commerce traffic to
another site
redirecting routes
reference table
reference: rule option
reference_system table
regex rule option
registry lookups
remote hosts, checking
remote procedure call (RPC) services,
detecting attacks to
replace rule action
rev: rule option
reverse name resolution
Reverse WWW Shell
RFC 1918 address space (CIDR blocks)
Roesch, Martin
rollbackhosts option (snortsam.conf)
rollbacksleeptime option (snortsam.conf)
rollbackthreshold option (snortsam.conf)
root directory, changing after
routes, redirecting
rows option (flow preprocessor)
rpc_decode preprocessor
rservices (rlogin, rsh, and rexec),
detecting on network
rst_all (response keyword)
rst_rcv (response keyword)
rst_snd (response keyword)
Ruiu, Dragos
rule headers
Action field
Destination Address field
Destination Port
options section
Protocol field
Source IP field
Source Port field
Traffic Direction operator
rule options
flags field
keywords and values
parts of
rule sets
getting latest
trimming high noise
rule-management tools
RULE_PATH variable (snort.conf) 2nd
rules [See also rule sets]
creating and managing
creating for inline patch
editing custom
keeping up-to-date
list of
modifying rules that generate blocking
suppression 2nd
tuning individual
where to keep
writing good
[SYMBOL] [A] [B] [C] [D] [E] [F]
[G] [H] [I] [J] [K] [L] [M] [N] [O]
[P] [Q] [R] [S] [T] [U] [V] [W]
[X] [Y] [Z]
Sam Spade 2nd
sameip; rule option
SANS 2nd 3rd
SANS Institute
Sans TCP/IP Guide
scanner-fixed-threshold option (flowportscan preprocessor)
scanner-fixed-window option (flowportscan preprocessor)
scanner-sliding-scale-factor option (flowportscan preprocessor)
scanner-sliding-threshold option (flowportscan preprocessor)
scanner-sliding-window option (flowportscan preprocessor)
scanning machines on your network
schema table
scoreboard-memcap-scanner option
(flow-portscan preprocessor)
scoreboard-memcap-talker option (flowportscan preprocessor)
scoreboard-rows-scanner option (flowportscan preprocessor)
scoreboard-rows-talker option (flowportscan preprocessor)
Scoreboards component (flow-portscan
scrambling networks
script kiddies
sdrop rule action
secure certificates
SecurityFocus IDS Page
self-inflicted denial-of-service
self-test mode, starting Snort in
sensor table
administration problems
configuring interfaces
managing Snort [See IDS
creating connection points
prioritizing systems and networks
to watch
applying patches and updates
choosing operating system
monitoring system logs
robust authentication
seq: rule option
Server statistics tracker component (flowportscan preprocessor)
server-ignore-limit option (flow-portscan
server-learning-time option (flowportscan preprocessor)
server-memcap option (flow-portscan
server-rows option (flow-portscan
server-scanner-limit option (flowportscan preprocessor)
server-watchnet option (flow-portscan
serveronly option (stream4_reassemble
ServerSignature setting
service scans, detecting
services, disabling
session interception
IPS identification
Snort running as interceptor
session: rule option
set_gid: option (snort.conf)
set_uid: option (snort.conf)
sguil server database
sending log information to
shellcode in the packet payload, detecting
show_year option (snort.conf)
sid: rule option
sig_class table
sig_id parameter
sig_reference table
signature table
signature-based IDS versus antivirus
automatic updates
disabling high-noise
of known exploits
Snort and
skiphosts option (snortsam.conf)
skipinterval option (snortsam.conf)
smart cards
SMTP (Simple Mail Transfer Protocol)
SMTP email service, detecting attacks to
SMTP_SERVERS variable (snort.conf)
sniff trace, directing to logfile
sniffer mode for Snort
sniffer-mode output
turning off promiscuous mode
SNMP traffic, detecting
SNMP_SERVERS variable (snort.conf)
as NIDS solution
database schema
deploying [See
installing [See installing Snort]
reasons to use
using more effectively
Snort Inline Patch
Snort newsgroup
Snort's homepage
snort-sigs mailing list 2nd
snort.conf file 2nd
command-line options
default settings for
default variables
designating multiple ports
designating single port
editing in SnortCenter
editing with SnortCenter
initial configuration
type of alert wanted
network and configuration variables
preprocessors [See
preprocessor configuration]
RULE_PATH variable
Snort decoder and detection engine
specifying a single address
specifying multiple addresses
variables to define servers running
services that have specific rules
SnortCenter 2nd 3rd 4th
adding new rules
adding sensors to console
Admin drop-down menu
automatic updates
browsing console
editing custom rules
installing agent
installing console
logging in and surveying layout
management console
managing false positive and false
negative alerts
managing tasks
Output Plugins selection
Resources link
creating a new rule
Sensor Configuration menu
Edit tool
Output Plugin Selection
Preprocessor Selection drop-down
Rule Category Overview link
Rule Policy Templates section
Rules Selection drop-down menu
Variable Selection drop-down
Sensor Console button
trickiest part
updating rules and signatures
snortdb-extra.gz file
SnortReport 2nd
SnortSAM 2nd 3rd
output plug-in
patching Snort to enable support for
snortsam.conf file options
SnortSnarf 2nd
Snot 2nd
SoBig worm
software download resources
software version-mapping
Solaris 9 installation guide
Source IP field (rule headers)
Source Port field (rule headers)
source routing
Sourcefire 2nd
Management Console
SPAN port (Cisco)
SPAN ports
spanning multiple ports into single
monitor port
SQL Server database servers, detecting
attacks to
SQL Server, disabling rule set
SQL Slammer worm
SQL_SERVERS variable (snort.conf)
src-ignore-net option (flow-portscan
SSH (Secure Shell)
SSL Accelerator
SSL proxies 2nd
Stacheldraht rules
stacks (TCP/IP)
Staniford, Stuart
stateless; rule option
stats_interval option (flow preprocessor)
stealth interface
Steele, Michael E.
Stick 2nd
stopping Snort
stream4 preprocessor 2nd
stream4_reassemble preprocessor
stress-testing IDS machines
suppression rules 2nd
configured to span several ports
SYN (synchronize sequence numbers)
SYN FIN scan attempt
synchronize sequence numbers (SYN)
syslog server, sending alerts to
system configuration errors
[SYMBOL] [A] [B] [C] [D] [E] [F]
[G] [H] [I] [J] [K] [L] [M] [N] [O]
[P] [Q] [R] [S] [T] [U] [V] [W]
[X] [Y] [Z]
talker-fixed-threshold option (flowportscan preprocessor)
talker-fixed-window option (flowportscan preprocessor)
talker-sliding-scale-factor option (flowportscan preprocessor)
talker-sliding-threshold option (flowportscan preprocessor)
talker-sliding-window option (flowportscan preprocessor)
targeting IDS
TCP (Transmission Control Protocol)
three-way handshake
tcp-penalties option (flow-portscan
suite of protocols
tcpdump 2nd
-n and -nn options 2nd
-s option
-v option
-x option
capture example
capture of TCP three-way
data within the < and > characters
syntax options
writing data to temp file
tcphdr table
telnet sessions, detecting dangerous traffic
transmitted in
telnet_decode preprocessor
Tenable Security 2nd
Tethereal 2nd
TFTP (Trivial File Transfer Protocol)
TFTP service, detecting attacks to
three-way handshake (TCP)
threshold type thresholding example
thresholding 2nd
difference between standalone
thresholds and those included in rules
global threshold commands
global thresholds
simple threshold rules
timeout option (frag2 preprocessor)
timeout option (stream4 preprocessor)
timestamps in UTC format
tools that can bypass security restrictions
Top Layer Networks
Traffic Direction operator (rule headers)
traffic encryption 2nd
Trojan horse
ttl: rule option
ttl_limit option (frag2 preprocessor)
ttl_limit option (stream4 preprocessor)
tuning Snort
[SYMBOL] [A] [B] [C] [D] [E] [F]
[G] [H] [I] [J] [K] [L] [M] [N] [O]
[P] [Q] [R] [S] [T] [U] [V] [W]
[X] [Y] [Z]
u_encode option (http_inspect_server)
UDP (User Datagram Protocol)
udphdr table
UIDs, changing after initialization
umask: option (snort.conf)
unified binary output, configuring
unified logs
unique-memcap option (flow-portscan
unique-rows option (flow-portscan
Uniqueness tracker component (flowportscan preprocessor)
Unix systems, disabling rule sets
unreachable destination alerts
Unreal Tournament 2004
uricontent: rule option
user input validation problems
utc option (snort.conf)
utf_8 option (http_inspect_server)
[SYMBOL] [A] [B] [C] [D] [E] [F]
[G] [H] [I] [J] [K] [L] [M] [N] [O]
[P] [Q] [R] [S] [T] [U] [V] [W]
[X] [Y] [Z]
validation problems, user input
verbose option (snort.conf)
version number, displaying
Visscher, Bamm
VLANs, mirroring multiple
VTP (Virtual Terminal Protocol)
vulnerability scanners
[SYMBOL] [A] [B] [C] [D] [E] [F]
[G] [H] [I] [J] [K] [L] [M] [N] [O]
[P] [Q] [R] [S] [T] [U] [V] [W]
[X] [Y] [Z]
warn (react response keyword)
Watchguard firewall and SnortSAM
web attack detection rules
web page scanners
web resources
web servers, detecting attacks to
web sites that give out company
web sites, running secure
automating startup
creating test certificate
generating random key
on port 443
unlocking secure certificate
webcrawling utilities
Welchia worm
WHOIS services, free
Windows systems, disabling rule sets
Windows versus Linux when deciding
which OS to use for Snort sensor
Windows-attacking worms, detecting
WinDump 2nd
[SYMBOL] [A] [B] [C] [D] [E] [F]
[G] [H] [I] [J] [K] [L] [M] [N] [O]
[P] [Q] [R] [S] [T] [U] [V] [W] [X]
[Y] [Z]
X-Windows sessions, detecting attacks to
[SYMBOL] [A] [B] [C] [D] [E] [F]
[G] [H] [I] [J] [K] [L] [M] [N] [O]
[P] [Q] [R] [S] [T] [U] [V] [W]
[X] [Y] [Z]
year, including in alerts and logfiles
[SYMBOL] [A] [B] [C] [D] [E] [F]
[G] [H] [I] [J] [K] [L] [M] [N] [O]
[P] [Q] [R] [S] [T] [U] [V] [W]
[X] [Y] [Z]
zlib file
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF