main

• | Table of Contents
• | Index
• | Reviews
• | Reader Reviews
• | Errata
• | Academic
Managing Security with Snort and IDS Tools
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

• | Table of Contents
• | Index
• | Reviews
• | Reader Reviews
• | Errata
• | Academic
Managing Security with Snort and IDS Tools
By Kerry J. Cox, Christopher Gerg
Publisher | : O'Reilly
Pub Date | : August 2004
ISBN | : 0-596-00661-6
Pages | : 288

Copyright
Preface
 | Audience
 | About This Book
 | Assumptions This Book Makes
 | Chapter Synopsis
 | Conventions Used in This Book
 | Comments and Questions
 | Acknowledgments
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 Intrusion)?
 | 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 Ps
 | 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 Variables
 | 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 Open
 | 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 Configuration
 | 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 Installation
 | Section 11.2. SnortCenter Agent Installation
 | Section 11.3. SnortCenter Management Console
 | Section 11.4. Logging In and Surveying the Layout
 | Section 11.5. Adding Sensors to the Console
 | Section 11.6. Managing Tasks
Chapter 12. Additional Tools for Snort IDS Management
 | 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 Balancers
 | Section 13.3. The IDS Distribution System (I(DS)2)
Appendix A. Snort and ACID Database Schema
 | 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 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 Management
 | Section C.9. From Chapter 13: Strategies for High-Bandwidth Implementations of Snort
Colophon
Index


Day Day Up

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 (http://safari.oreilly.com). For more information, contact our corporate/institutional sales department: (800) 998-9938 or corporate@oreilly.com.

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.


Preface

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 utilities.

  • 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 environment.

  • Strategies for deploying an IDS in switched, high-security, and high-bandwidth environments.


Audience

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: http://freshmeat.net and http://sourceforge.net. If you are unable to locate the applications, use a search engine such as http://www.google.com 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 http://www.snort.org.

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 defense-in-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 Makes

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 protection.


Chapter Synopsis

Chapter 1

Introduces the concepts behind network security and intrusion detection.

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 examined.

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 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, web-based 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 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 sensors.

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, too.

Appendix C

Provides a compilation of web resources and download sources from throughout the book.


Conventions Used in This Book

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).

Italics

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 commands.

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 caution.


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 local)
(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:

http://www.oreilly.com/catalog/snortids

To comment or ask technical questions about this book, send email to:

bookquestions@oreilly.com

For more information about our books, conferences, Resource Centers, and the O'Reilly Network, see our web site at:

http://www.oreilly.com


Acknowledgments

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 co-workers. 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 source-code 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, Jessika!)

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. Introduction

This book is about building a network-based 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, full-featured solution that provides competition for some very expensive commercial solutions (and surpasses many).

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-to-network 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 example).

The final layer of intrusion detection is NIDS.


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 environment?

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 difficult.

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 crazy.

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 themselves.

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 installation.

1.5.4 Unrealistic Expectations

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:

Cost

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.

Flexibility

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 situation.

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 | http://www.snort.org
SecurityFocus IDS Page | http://www.securityfocus.com/ids
The SANS Institute | http://www.sans.org
CERT homepage | http://www.cert.org
The NSA Security Guides | http://www.nsa.gov/snac/index.cfm
tcpdump homepage | http://www.tcpdump.org
ethereal homepage | http://www.ethereal.com


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, special-built systems, but now a simple laptop) with a network card that watches traffic between computers and other network-capable 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 Protocols

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 are:

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.

2.1.1.1 The three-way handshake

To establish a TCP conversation, a three-way 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 handshake

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-of-sequence 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 network-aware 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)
Broadcasts
Network File System (NFS port 2049)
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: 172.30.17.45.

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 machine.

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 pings.

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 hands.

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 Packet

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 encapsulation.

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 low-level 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 information:

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 data.

Identification

Identifies the current datagram. Packets can fragment on slower network connections; this information is used to piece the fragments back together.

Flags

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 forever.

Protocol

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 feature.

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 information:

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 receive

Data offset

Indicates the beginning point of the data payload in the packet—essentially, the size of the header in 32-bit words.

Reserved

Not used and reserved for future use.

Flags

Contains information like the SYN, ACK, and FIN bits used in connection establishment and teardown.

Window

Specifies the size of the sending machine's receive window

Checksum

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

Options

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.

Data

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

    Previous Section < Day Day Up > Next Section


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—whether 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 approval.


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 install:

# cp tcpdump-3.8.1.tar.gz /usr/local/src/

# cp libpcap-0.8.1.tar.gz /usr/local/src/

# 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 ping.net > myhost.com: icmp echo request (DF)

07:00:48.036776 myhost.com > ping.net: icmp: echo reply (DF)

07:02:12.622460 log.net.3155 > syslog.com.514: udp 101

07:03:01.132414 send.net.32938 > mail.com.25 S 248631:248631(0) win 8760

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 data-only 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 needed.

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 Output

The more data collected by tcpdump, the clearer the content of the network traffic stream becomes. Here is another example of a tcpdump capture:

14:02:09.181190 specto.ksl.com.33248 > quasi.ksl.com.ftp: S 1191864640:1191864640(0)

win 5840 <mss 1460,sackOK,timestamp 238617 0,nop,wscale 0> (DF)

Here's what each field in this output means:

14:02:09.181190

Timestamp

specto.ksl.com.33248

Hostname and source port

quasi.ksl.com.ftp

Hostname and destination port (translated to FTP)

S

First character of the TCP flag: PSH, RST, SYN, FIN (the ACK flag is shown somewhere else)

1191864640

Initial sequence number from source

1191864640

Ending sequence number, which is the initial sequence number plus the size of the packet in data bytes

(0)

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)

sackOK

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)

nop

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)

(DF)

The "don't fragment" bit is set

The tcpdump output shows this packet to be a connection request from specto.ksl.com to establish an FTP connection to quasi.ksl.com. 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 three-way 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 MBit/s.

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 section.

# tcpdump -F /home/myname/tcp.filter

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 addresses:

# 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 traffic.

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 port ssh

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 192.168.10.5 and not port ssh

Also, say I want to restrict tcpdump to a single port and host:

# tcpdump -r /tmp/tcpdump.out -n host 192.168.10.5 and port 80

To watch traffic between two specific hosts, I would use:

# tcpdump -r /tmp/tcpdump.out host 192.168.10.5 and host 192.168.10.10

2.7.3 tcpdump Capture of the TCP Three-Way Handshake

Test your skills by looking at the tcpdump output below (my laptop checking slashdot.org for the latest news):

22:21:50.378070 192.168.1.104.4268 > slashdot.org.http: S 1626477748:1626477748(0)

win 64512 <mss 1260,nop,nop,sackOK> (DF)

22:21:50.488810 slashdot.org.http > 192.168.1.104.4268: S 3322271704:3322271704(0)

ack 1626477749 win 5840 <mss 1460,nop,nop,sackOK> (DF)

22:21:50.489146 192.168.1.104.4268 > slashdot.org.http: . ack 1 win 64512 (DF)


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 install

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 wait.

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 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 format.

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 connections.

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 slashdot.org.

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:2b:01:00:01 DEC_STP Hello Packet

0.407305 64.147.136.1 -> 224.0.0.10 EIGRP Hello

0.820469 00000000.00c0b607af66 -> 00000000.ffffffffffff IPX SAP Nearest Query

0.999948 00:d0:bc:ed:15:e4 -> 09:00:2b:01:00:01 DEC_STP Hello Packet

1.159977 00:30:65:8c:84:50 -> 09:00:07:ff:ff:ff AARP Who has 65280.194? Tell 65280.

128

1.218995 aa:00:04:00:59:9e -> 09:00:2b:00:00:0f 0x6004 DEC LAT

1.528072 00008001.080009a95de6 -> 00008001.ffffffffffff IPX SAP General Response

1.999953 00:d0:bc:ed:15:e4 -> 09:00:2b:01:00:01 DEC_STP Hello Packet

2.723358 00:00:f8:52:5b:79 -> ab:00:00:02:00:00 0x6002 DEC DNA Remote Console

2.743625 00008001.00d0bced15e4 -> 00008001.ffffffffffff IPX SAP General Response

2.915255 64.147.136.1 -> 224.0.0.10 EIGRP Hello

3.000008 00:d0:bc:ed:15:e4 -> 09:00:2b:01:00:01 DEC_STP Hello Packet

3.121764 aa:00:04:00:bd:9e -> ab:00:00:03:00:00 0x6003 DEC DNA Routing

3.123641 aa:00:04:00:bd:9e -> 09:00:2b:02:00:00 0x6003 DEC DNA Routing

3.125544 aa:00:04:00:bd:9e -> ab:00:00:04:00:00 0x6003 DEC DNA Routing

3.205372 64.147.136.5 -> 224.0.0.10 EIGRP Hello

3.235634 aa:00:04:00:59:9e -> 09:00:2b:00:00:0f 0x6004 DEC LAT

3.999932 00:d0:bc:ed:15:e4 -> 09:00:2b:01:00:01 DEC_STP Hello Packet

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.

ethereal | http://www.ethereal.com
libpcap | http://www.tcpdump.org
libpcap tutorial | http://www.cet.nau.edu/~mc8/Socket/Tutorials/section1.html
Packetyzer | http://www.networkchemistry.com/products/packetyzer/
Pcap tutorial | http://www.tcpdump.org/pcap.htm
Sans TCP/IP Guide | http://www.sans.org/resources/tcpip.pdf
tcpdump | http://www.tcpdump.org
Tethereal | http://www.ethereal.com
WinDump | http://windump.polito.it
WinPcap | http://winpcap.polito.it


Chapter 3. Installing Snort

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 NIDS.


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 download.

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 Counterpart

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-to-date 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 numbers.

3.2.1 Source Code Installation

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 support.

Once you've downloaded and uncompressed the source distribution from http://www.snort.org, 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

$ ./configure

$ make

# 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 http://www.tcpdump.org) or PCRE. PCRE stands for "Perl-Compatible Regular Expressions," and it's available from http://www.pcre.org. Download the library (or libraries) you need, uncompress the file, and build it using ./configure, make, and make install.

3.2.1.1 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 http://www.packetfactory.net/libnet. 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 http://winpcap.polito.it. Once WinPcap is installed, grab the binary version of Snort (snort.exe). The Win32 version is available at http://www.snort.org/dl/binaries/win32/. Snort is run under Windows from a command prompt.

Another version of Snort configured for Windows users is available at http://winsnort.com. 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 server.

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 high-demand 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 http://www.snort.org/dl/snapshots/. 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 http://lists.sourceforge.net/lists/listinfo/snort-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, http://groups.google.com. The newsgroup name is mailing.unix.snort. The direct link to the Snort mailing list on the Google newsgroup site is http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&group=mailing.unix.snort.

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 elsewhere.


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.

-b

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 networks.

-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 mode.

-C

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.

-d

Displays the application layer data when in verbose or packet logging mode.

-D

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.)

-e

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 (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 systems.

-I

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 capture.

-n packet-count

Processes the given number of packets and then exits. Useful when you want to capture a small snapshot network traffic.

-N

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 configurations.

-o

Changes the order in which the rules are applied to packets. Instead of the rules being applied in the standard Alert [image] Pass [image] Log order, this option applies them in Pass [image] Alert [image] 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).

-O

When in ASCII packet dump mode, replaces the IP addresses printed to the screen or logfile with "xxx.xxx.xxx.xxx". 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.

-p

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.

-q

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 time.

-s

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 syslog.

-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.

-T

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.

-U

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.

-v

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.

-V

Displays the Snort version number and then exits. Use this to determine which version of Snort is installed on your system.

-X

Displays raw packet data starting at the link layer. With this option you can see the entire packet, including Ethernet headers and trailers.

-y

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.

-z

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 system.

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 <path_to_conf_file>)

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 command-line 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 administrators.

Enable sniffer mode for Snort using the -v flag:

# 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 Complete ==--

-*> Snort! <*-

Version 2.1.x (Build 72)

By Martin Roesch (roesch@sourcefire.com, www.snort.org)

06/24-11:19:32.257859 64.147.136.193:3131 -> 192.168.0.15:9100

TCP TTL:128 TOS:0x0 ID:21742 IpLen:20 DgmLen:48 DF

******S* Seq: 0x5DB36D37  Ack: 0x0  Win: 0xFAF0  TcpLen: 28

TCP Options (4) => MSS: 1460 NOP NOP SackOK

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

06/24-11:19:32.261606 64.147.136.5 -> 224.0.0.10

EIGRP TTL:2 TOS:0x0 ID:0 IpLen:20 DgmLen:60

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

06/24-11:19:34.470931 64.147.136.1 -> 224.0.0.10

EIGRP TTL:2 TOS:0xC0 ID:0 IpLen:20 DgmLen:60

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

06/24-11:19:34.482799 64.147.136.1 -> 224.0.0.10

EIGRP TTL:2 TOS:0xC0 ID:0 IpLen:20 DgmLen:60

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

===========================================================================

Snort analyzed 38 out of 38 packets, dropping 0(0.000%) packets

Breakdown by protocol:                Action Stats:

    TCP: 1          (2.632%)          ALERTS: 0

    UDP: 0          (0.000%)          LOGGED: 0

   ICMP: 0          (0.000%)          PASSED: 0

    ARP: 0          (0.000%)

  EAPOL: 0          (0.000%)

   IPv6: 0          (0.000%)

    IPX: 0          (0.000%)

  OTHER: 37         (97.368%)

DISCARD: 0          (0.000%)

===========================================================================

Wireless Stats:

Breakdown by type:

    Management Packets: 0          (0.000%)

    Control Packets:    0          (0.000%)

    Data Packets:       0          (0.000%)

===========================================================================

Fragmentation Stats:

Fragmented IP Packets: 0          (0.000%)

    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          (0.000%)

         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 64.147.136.1 tell 64.147.136.144

06/24-11:27:35.408860 64.147.136.144:50507 -> 64.147.130.2:53

UDP TTL:64 TOS:0x0 ID:0 IpLen:20 DgmLen:57 DF

Len: 29

E8 0A 01 00 00 01 00 00 00 00 00 00 03 6E 73 31  .............ns1

03 6B 73 6C 03 63 6F 6D 00 00 01 00 01           .ksl.com.....

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

06/24-11:27:35.408838 ARP reply 64.147.136.1 is-at 0:D0:BC:ED:15:E4

06/24-11:27:35.409465 64.147.130.2:53 -> 64.147.136.144:50507

UDP TTL:63 TOS:0x0 ID:0 IpLen:20 DgmLen:121 DF

Len: 93

E8 0A 85 80 00 01 00 01 00 02 00 01 03 6E 73 31  .............ns1

03 6B 73 6C 03 63 6F 6D 00 00 01 00 01 C0 0C 00  .ksl.com........

01 00 01 00 00 70 80 00 04 40 93 82 02 C0 10 00  .....p...@......

02 00 01 00 00 70 80 00 02 C0 0C C0 10 00 02 00  .....p..........

01 00 00 70 80 00 06 03 6E 73 32 C0 10 C0 47 00  ...p....ns2...G.

01 00 01 00 00 70 80 00 04 40 93 82 03           .....p...@...

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

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 packet:

# snort -vde

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

06/24-11:34:00.840645 0:8:74:F3:CC:F9 -> 0:D0:BC:ED:15:E4 type:0x800 len:0x47

64.147.136.144:50507 -> 64.147.130.2:53 UDP TTL:64 TOS:0x0 ID:0 IpLen:20 DgmLen:57 DF

Len: 29

28 BF 01 00 00 01 00 00 00 00 00 00 03 6E 73 31  (............ns1

03 6B 73 6C 03 63 6F 6D 00 00 01 00 01           .ksl.com.....

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

06/24-11:34:00.841157 0:D0:BC:ED:15:E4 -> 0:8:74:F3:CC:F9 type:0x800 len:0x87

64.147.130.2:53 -> 64.147.136.144:50507 UDP TTL:63 TOS:0x0 ID:0 IpLen:20 DgmLen:121 DF

Len: 93

28 BF 85 80 00 01 00 01 00 02 00 01 03 6E 73 31  (............ns1

03 6B 73 6C 03 63 6F 6D 00 00 01 00 01 C0 0C 00  .ksl.com........

01 00 01 00 00 70 80 00 04 40 93 82 02 C0 10 00  .....p...@......

02 00 01 00 00 70 80 00 02 C0 0C C0 10 00 02 00  .....p..........

01 00 00 70 80 00 06 03 6E 73 32 C0 10 C0 47 00  ...p....ns2...G.

01 00 01 00 00 70 80 00 04 40 93 82 03           .....p...@...

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

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 mode:

-v

Dump packet headers to standard output. "Verbose" mode—although ironically, less verbose than -vd or -ve.

-d

Dump packet payloads.

-a

Display ARP packets.

-e

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 Logger

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 full-blown denial-of-service attack. If you're not careful, you can cause yourself real headaches.

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/temp.log

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/temp.log

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 analysis.

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 capability.

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 intrusion.

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 time."

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.

3.4.3.1 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:

http://www.snort.org/dl/rules/snortrules-snapshot-2_1.tar.gz

If you are running Snort CURRENT (riding the bleeding edge), you can download the latest rules from:

http://www.snort.org/dl/rules/snortrules-snapshot-CURRENT.tar.gz

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.tar.gz

$ cd rules

or:

$ tar zxvf snortrules-snapshot-CURRENT.tar.gz

$ 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.

3.4.3.2 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 default.

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 plug-ins, 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/snort_rules/march_2004/rules

To get Snort started, enter the following command line:

snort -c /usr/local/share/snort_rules/march_2004/rules/snort.conf

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/snort_rules/rules/snort.conf

+++++++++++++++++++++++++++++++++++++++++++++++++++

Initializing rule chains...

,-----------[Flow Config]----------------------

| Stats Interval:  0

| Hash Method:     2

| Memcap:          10485760

| Rows  :          4099

| Overhead Bytes:  16400(%0.16)

`----------------------------------------------

No arguments to frag2 directive, setting defaults to:

    Fragment timeout: 60 seconds

    Fragment memory cap: 4194304 bytes

    Fragment min_ttl:   0

    Fragment ttl_limit: 5

    Fragment Problems: 0

    Self preservation threshold: 500

    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 bytes

    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: INACTIVE

    flush_data_diff_size: 500

    Ports: 21 23 25 53 80 110 111 143 513 1433

    Emergency Ports: 21 23 25 53 80 110 111 143 513 1433

HttpInspect Config:

    GLOBAL CONFIG

      Max Pipeline Requests:    0

      Inspection Type:          STATELESS

      Detect Proxy Usage:       NO

      IIS Unicode Map Filename: /usr/local/share/snort_rules/rules/unicode.map

      IIS Unicode Map Codepage: 1252

    DEFAULT SERVER CONFIG:

      Ports: 80 8080 8180

      Flow Depth: 300

      Max Chunk Length: 500000

      Inspect Pipeline Requests: YES

      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: YES

      %U Encoding: YES alert: YES

      Bare Byte: YES alert: YES

      Base36: OFF

      UTF 8: OFF

      IIS Unicode: YES alert: YES

      Multiple Slash: YES alert: NO

      IIS Backslash: YES alert: NO

      Directory: YES alert: NO

      Apache WhiteSpace: YES alert: YES

      IIS Delimiter: YES alert: YES

      IIS Unicode Map: GLOBAL IIS UNICODE MAP CONFIG

      Non-RFC Compliant Characters: NONE

rpc_decode arguments:

    Ports to decode RPC on: 111 32771

    alert_fragments: INACTIVE

    alert_large_fragments: ACTIVE

    alert_incomplete: ACTIVE

    alert_multiple_requests: ACTIVE

telnet_decode arguments:

    Ports to decode telnet on: 21 23 25 119

1652 Snort rules read...

1652 Option Chains linked into 152 Chain Headers

0 Dynamic rules

+++++++++++++++++++++++++++++++++++++++++++++++++++

+-----------------------[thresholding-config]----------------------------------

| memory-cap : 1048576 bytes

+-----------------------[thresholding-global]----------------------------------

| none

+-----------------------[thresholding-local]-----------------------------------

| gen-id=1      sig-id=2275       type=Threshold tracking=dst count=5   seconds=60

+-----------------------[suppression]------------------------------------------

-------------------------------------------------------------------------------

Rule application order: ->activation->dynamic->alert->pass->log

        --== Initialization Complete ==--

-*> Snort! <*-

Version 2.1.x (Build 24)

By Martin Roesch (roesch@sourcefire.com, www.snort.org)

It will sit here (watching the traffic) until you stop Snort by hitting Ctrl-C or using kill-USR1. The following summary then appears:

===============================================================================

Snort analyzed 3210 out of 3807 packets, dropping 597(15.682%) packets

Breakdown by protocol:                Action Stats:

    TCP: 2602       (68.348%)         ALERTS: 6

    UDP: 2          (0.053%)          LOGGED: 6

   ICMP: 8          (0.210%)          PASSED: 0

    ARP: 0          (0.000%)

  EAPOL: 0          (0.000%)

   IPv6: 0          (0.000%)

    IPX: 0          (0.000%)

  OTHER: 0          (0.000%)

DISCARD: 0          (0.000%)

===============================================================================

Wireless Stats:

Breakdown by type:

    Management Packets: 0          (0.000%)

    Control Packets:    0          (0.000%)

    Data Packets:       0          (0.000%)

===============================================================================

Fragmentation Stats:

Fragmented IP Packets: 0          (0.000%)

    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       (68.348%)

         Stream Trackers: 1559

          Stream flushes: 0

           Segments used: 0

   Stream4 Memory Faults: 0

===============================================================================

Final Flow Statistics

,----[ FLOWCACHE STATS ]----------

Memcap: 10485760 Overhead Bytes 16400 used(%2.287951)/blocks (239909/1564) Overhead

blocks: 1 Could Hold: (73326)

IPV4 count: 1563 frees: 0 low_time: 1080162455, high_time: 1080162458, diff: 0h:00:

03s

    finds: 2612 reversed: 1022(%39.127106)

    find_sucess: 1049 find_fail: 1563 percent_success: (%40.160796) new_flows: 1563

 Protocol: 1 (%0.306279) finds: 8  reversed: 3(%37.500000)

  find_sucess: 5 find_fail: 3 percent_success: (%62.500000) new_flows: 3

 Protocol: 6 (%99.617152) finds: 2602  reversed: 1018(%39.123751)

  find_sucess: 1043 find_fail: 1559 percent_success: (%40.084550) new_flows: 1559

 Protocol: 17 (%0.076570) finds: 2  reversed: 1(%50.000000)

  find_sucess: 1 find_fail: 1 percent_success: (%50.000000) new_flows: 1

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 Information Leak] [Priority: 2]

03/24-15:07:35.187504 192.168.1.2 -> 192.168.1.105

ICMP TTL:51 TOS:0x0 ID:23210 IpLen:20 DgmLen:28

Type:8  Code:0  ID:1290   Seq:0  ECHO

[Xref => http://www.whitehats.com/info/IDS162]

[**] [1:618:5] SCAN Squid Proxy attempt [**]

[Classification: Attempted Information Leak] [Priority: 2]

03/24-15:07:35.583826 192.168.1.2:49641 -> 192.168.1.105:3128

TCP TTL:44 TOS:0x0 ID:56810 IpLen:20 DgmLen:40

******S* Seq: 0x4EB5A7C6  Ack: 0x0  Win: 0x400  TcpLen: 20

[**] [1:1421:3] SNMP AgentX/tcp request [**]

[Classification: Attempted Information Leak] [Priority: 2]

03/24-15:07:35.589463 192.168.1.2:49641 -> 192.168.1.105:705

TCP TTL:44 TOS:0x0 ID:54050 IpLen:20 DgmLen:40

******S* Seq: 0x4EB5A7C6  Ack: 0x0  Win: 0x400  TcpLen: 20

[Xref => http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-0013][Xref => http://

cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-0012]

[**] [1:615:5] SCAN SOCKS Proxy attempt [**]

[Classification: Attempted Information Leak] [Priority: 2]

03/24-15:07:35.674332 192.168.1.2:49641 -> 192.168.1.105:1080

TCP TTL:44 TOS:0x0 ID:9794 IpLen:20 DgmLen:40

******S* Seq: 0x4EB5A7C6  Ack: 0x0  Win: 0x400  TcpLen: 20

[Xref => http://help.undernet.org/proxyscan/]

[**] [1:1420:3] SNMP trap tcp [**]

[Classification: Attempted Information Leak] [Priority: 2]

03/24-15:07:35.696925 192.168.1.2:49641 -> 192.168.1.105:162

TCP TTL:44 TOS:0x0 ID:41259 IpLen:20 DgmLen:40

******S* Seq: 0x4EB5A7C6  Ack: 0x0  Win: 0x400  TcpLen: 20

[Xref => http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-0013][Xref => http://

cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-0012]

[**] [1:1418:3] SNMP request tcp [**]

[Classification: Attempted Information Leak] [Priority: 2]

03/24-15:07:35.827022 192.168.1.2:49641 -> 192.168.1.105:161

TCP TTL:44 TOS:0x0 ID:37753 IpLen:20 DgmLen:40

******S* Seq: 0x4EB5A7C6  Ack: 0x0  Win: 0x400  TcpLen: 20

[Xref => http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-0013][Xref => http://

cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-0012]

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 Information Leak] [Priority: 2]

This is the header and packet information for the packet that caused this alert:

03/24-15:07:35.827022 192.168.1.2:49641 -> 192.168.1.105:161

TCP TTL:44 TOS:0x0 ID:37753 IpLen:20 DgmLen:40

******S* Seq: 0x4EB5A7C6  Ack: 0x0  Win: 0x400  TcpLen: 20

Each Snort alert includes a link to a description of the rule that generated the alert:.

[Xref => http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-0013][Xref => http://

cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2002-0012]

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 Enemy

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.

Opportunists

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 activity.

Thieves

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.

Vandals

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 noticing.

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 groups.

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 Contractors

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 defense-in-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 traffic.

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 networks.

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.

4.2.1.1 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—without 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 information:

http://www.networksolutions.com/en_US/whois/index.jhtml

Performs lookups on the administrative, technical, and billing contacts for a particular domain name.

http://www.arin.net/

Searches for the registrant and IP address range of a particular IP address. Useful for tracking down offending IP addresses.

http://www.bankes.com/nslookup.htm

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 commands.

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 http://www.hyperwhois.com and http://www.accesswhois.com 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 risks.

There are several free tools for Windows-based machines that execute commands similar to those found on Linux. The two I mention here are Sam Spade and IP-Tools. 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 netcraft.com 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.

4.2.1.2 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 http://www.insecure.org/nmap/ 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.insecure.org/nmap/ ) at 2003-09-17 19:36 MDT

Interesting ports on localhost (127.0.0.1):

(The 1203 ports scanned but not shown below are in state: closed)

PORT     STATE SERVICE     VERSION

21/tcp   open  ftp         vsFTPd 1.1.3

22/tcp   open  ssh         OpenSSH 3.5p1 (protocol 2.0)

25/tcp   open  smtp        Sendmail smtpd Secure/Rabid

80/tcp   open  http        Apache httpd 1.3.28 ((Unix) PHP/4.3.2)

110/tcp  open  pop3        UW Imap pop3 server 2001.78rh

6000/tcp open  X11         (access denied)

Device type: general purpose

Running: Linux 2.4.X|2.5.X

OS details: Linux Kernel 2.4.0 - 2.5.20

Uptime 9.486 days (since Mon Sep  8 07:56:31 2003)

Nmap run completed -- 1 IP address (1 host up) scanned in 16.151 seconds

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 Information Leak] [Priority: 2]

09/18-02:58:18.144568 64.147.136.144 -> 209.63.147.19

ICMP TTL:22 TOS:0x0 ID:51496 IpLen:20 DgmLen:28

Type:8  Code:0  ID:44209   Seq:8907  ECHO

[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.

4.2.1.3 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, too.

One open source tool has risen above the others (arguably including the commercial alternatives): Nessus. It can be downloaded from http://www.nessus.org. Nessus is free, manageable even by novice users, has clients for both Unix-based 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 (http://www.tenablesecurity.com). 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 later.

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/nessus-update-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 solutions.

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 Information Leak] [Priority: 2]

03/21-22:01:41.686864 192.168.1.105:33977 -> 192.168.1.100:134

TCP TTL:38 TOS:0x0 ID:1147 IpLen:20 DgmLen:60

**U*P**F Seq: 0xEB5E3384  Ack: 0x0  Win: 0xC00  TcpLen: 40  UrgPtr: 0x0

TCP Options (5) => WS: 10 NOP MSS: 265 TS: 1061109567 0 EOL

[Xref => http://www.whitehats.com/info/IDS30]

[**] [1:2385:3] NETBIOS SMB DCE/RPC NTLMSSP invalid mechlistMIC attempt [**]

[Classification: Attempted Denial of Service] [Priority: 2]

03/21-22:01:47.771281 192.168.1.105:53857 -> 192.168.1.100:445

TCP TTL:64 TOS:0x0 ID:14271 IpLen:20 DgmLen:269 DF

***AP*** Seq: 0x737329C2  Ack: 0xF9186CC  Win: 0x16D0  TcpLen: 32

TCP Options (3) => NOP NOP TS: 1654636883 34559859

[Xref => http://www.securityfocus.com/bid/9635][Xref => http://www.securityfocus.com/

bid/9633][Xref => http://cgi.nes

sus.org/plugins/dump.php3?id=12054]

[**] [1:2251:4] NETBIOS DCERPC Remote Activation bind attempt [**]

[Classification: Attempted Administrator Privilege Gain] [Priority: 1]

03/21-22:01:48.364347 192.168.1.105:53861 -> 192.168.1.100:135

TCP TTL:64 TOS:0x0 ID:14354 IpLen:20 DgmLen:256 DF

***AP*** Seq: 0x73FB71F0  Ack: 0x957540DC  Win: 0x16D0  TcpLen: 32

TCP Options (3) => NOP NOP TS: 1654637476 0

[Xref => http://www.microsoft.com/technet/security/bulletin/MS03-039.asp][Xref =>

http://cve.mitre.org/cgi-bin/cvenam

e.cgi?name=CAN-2003-0605][Xref => http://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-

2003-0528][Xref => http://cve.mit

re.org/cgi-bin/cvename.cgi?name=CAN-2003-0715]

4.2.1.4 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 http://www.wiretrip.net/rfp/ 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_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"WEB-

MISC whisker HEAD/./"; flow:to_server,established; content:"HEAD/./"; classtype:

attempted-recon; reference:url,www.wiretrip.net/rfp/pages/whitepapers/whiskerids.

html; sid:1139;  rev:6;)

web-misc.rules:# alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"WEB-M

ISC whisker HEAD with large datagram"; content:"HEAD"; offset: 0; depth: 4; nocase;

dsize:>512; flow:to_server,established,no_stream; classtype:attempted-recon;

reference:url,www.wiretrip.net/rfp/pages/whitepapers/whiskerids.html; sid:1171; rev:

7;)

web-misc.rules:alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"WEB-

MISC whisker space splice attack"; content:"|20|"; flow:to_server,established; dsize:

1; reference:arachnids,296; classtype:attempted-recon; reference:url,www.wiretrip.

net/rfp/pages/whitepapers/whiskerids.html; sid:1104;  rev:6;)

web-misc.rules:alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS $HTTP_PORTS (msg:"WEB-

MISC whisker tab splice attack"; dsize: <5; flow:to_server,established; content:

"|09|"; reference:arachnids,415; classtype:attempted-recon; reference:url,www.

wiretrip.net/rfp/pages/whitepapers/whiskerids.html; sid:1087; rev:6;)

Installing and running nikto is simple. Download the source code and uncompress it in a secure directory. Within the new nikto/ directory, run the nikto.pl Perl script. Be sure to define the target host with a -h <target> option. Here is how a sample command appears.

# ./nikto.pl -h www.mydomain.com

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 HTML.

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.

# ./nikto.pl -h www.mydomain.com

-*** SSL support not available (see docs for SSL install instructions) ***

---------------------------------------------------------------------------

- Nikto 1.30/1.06     -     www.cirt.net

+ Target IP:       192.168.0.10

+ Target Hostname: www.mydomain.com

+ Target Port:     80

+ Start Time:      Sat Oct 11 08:17:36 2003

---------------------------------------------------------------------------

- Scan is dependent on "Server" string which can be faked, use -g to override

+ Server: Apache/1.3.26 (Unix) PHP/4.2.2

+ Allowed HTTP Methods: GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, PATCH, PROPFIND,

PROPPATCH, MKCOL, COPY, MOVE, LOCK, UNLOCK, TRACE

+ HTTP method 'PUT' method may allow clients to save files on the web server.

+ HTTP method 'CONNECT' may allow server to proxy client requests.

+ HTTP method 'DELETE' may allow clients to remove files on the web server.

+ HTTP method 'PROPFIND' may indicate DAV/WebDAV is installed. This may allow DAV

authorized users to consume system memory via large requests or fill disk quotas.

+ HTTP method 'PROPPATCH' may indicate DAV/WebDAV is installed. This may allow DAV

authorized users to consume system memory via large requests or fill disk quotas.

+ HTTP method 'TRACE' may allow client XSS or credential theft. See http://www.

cgisecurity.com/whitehat-mirror/WhitePaper_screen.pdf for details.

+ Apache/1.3.26 appears to be outdated (current is at least Apache/2.0.46). Apache 1.

3.27 is still widely used and considered secure.

+ PHP/4.2.2 appears to be outdated (current is at least PHP/4.3.0)

+ Apache/1.3.26 - Apache 1.3 below 1.3.27 are vulnerable to a local buffer overflow

which allows attackers to kill any process on the system. CAN-2002-0839.

+ /~root - Enumeration of users is possible by requesting ~username (responds with

Forbidden for real users, not found for non-existent users) (GET).

+ /icons/ - Directory indexing is enabled, it should only be enabled for specific

directories (if required). If indexing is not used all, the /icons directory should

be removed. (GET)

+ /index.html.en - Apache default foreign language file found. All default files

should be removed from the web server as they may give an attacker additional system

information. (GET)

+ /manual/images/ - Apache 2.0 directory indexing is enabled, it should only be

enabled for specific directories (if required). Apache's manual should be removed and

directory indexing disabled. (GET)

+ / - TRACE option appears to allow XSS or credential theft. See http://www.

cgisecurity.com/whitehat-mirror/WhitePaper_screen.pdf for details (TRACE)

+ / - TRACK option ('TRACE' alias) appears to allow XSS or credential theft. See

http://www.cgisecurity.com/whitehat-mirror/WhitePaper_screen.pdf for details (TRACK)

+ /manual/ - Web server manual? tsk tsk. (GET)

+ /test/ - This might be interesting... (GET)

+ 1632 items checked - 9 items found on remote host

+ End Time:        Sat Oct 11 08:17:59 2003 (23 seconds)

---------------------------------------------------------------------------

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 http://www.digitaloffense.net.

4.2.1.5 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.

Firewalk

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

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.

SNMPwalk

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 chapter).

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 attack.

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 http://www.securityfocus.com and http://www.securiteam.com is a good idea, too. The list below gives some of the penetration methods (it's by no means comprehensive).

4.2.2.1 Authentication grinding

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 web-based 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.

4.2.2.2 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 result.

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.

4.2.2.3 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.

4.2.2.4 System configuration errors

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."

4.2.2.5 User input validation problems

One consequence of not checking what information a user supplies to an application was discussed in Section 4.2.2.2, 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 authentication.

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 remote-control 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 Internet).

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 systems.


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 web-based 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:

snot -r snort.rules -s www.somerandomhost.org/24 -d somesnortuser.com -l 10

Snot first reads in the snort.rules file, sends packets with a source address from anywhere on the CIDR-notated /24 network that www.somerandomhost.org resolves to, and then transmits the packets to somesnortuser.com, sleeping for up to 10 seconds per packet.

If your CIDR notational skills are lacking, refer to the following URL for a refresher course: http://jodies.de/ipcalc/.

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 enabled:

# snort -i eth0 -c /etc/snort/snort.conf -l /var/log/snort -z

Running Snot on machine B while targeting machine A appears as follows:

# /usr/local/bin/snot -r snortrules.txt -d 192.168.10.254 -s 192.168.10.0/24 -n 16384

The snortrules.txt file is a default snort.conf configuration in which all rules are gathered in one file. The address 192.168.10.254 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 attack.

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 <file> <destination>

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 -> 216.80.99.202 any ( sid: 1791; rev: 2; msg: "BACKDOOR fragroute

trojan connection attempt"; reference: bugtraq,4 898; classtype: trojan-activity;)

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 | http://www.dslreports.com/scan
CERT | http://www.cert.org
Cryptcat | http://sourceforge.net/projects/cryptcat/
DoS Help | http://www.doshelp.com/dostest.htm
Firewalk | http://www.packetfactory.net/projects/firewalk/
fragroute | http://www.monkey.org/~dugsong/fragroute/
hping | http://www.hping.org
ID Serve | http://grc.com/id/idserve.htm
IEEE OUI and Company_id Assignments | http://standards.ieee.org/regauth/oui/index.shtml
IP Calculator / IP Subnetting | http://jodies.de/ipcalc/
IP-Tools | http://www.ks-soft.net/ip-tools.eng/
ISECOM Security Tools | http://www.ideahamster.org/projects/operationaltools.htm
John the Ripper | http://www.openwall.com/john/
L0phtCrack LC4 | http://www.atstake.com/research/lc/
libevent | http://www.monkey.org/~provos/libevent/
LibWhisker | http://www.wiretrip.net/rfp/lw.asp
Netcat | http://www.atstake.com/research/tools/network_utilities/
GNU Netcat | http://netcat.sourceforge.net
Nessus | http://www.nessus.org
Nikto | http://www.cirt.net/code/nikto.shtml
Nmap | http://www.insecure.org/nmap/
The Packetfactory | http://www.packetfactory.net
Packetstromsecurity | http://packetstormsecurity.nl
Tenable Security | http://www.tenablesecurity.com
Razor Security | http://razor.bindview.com
Reverse WWW Shell | http://www.megasecurity.org/Sources/rwwwshell-1_6_perl.txt
Sam Spade | http://www.samspade.org
SANS | http://www.sans.org
SecurityFocus | http://www.securityfocus.com
SNMPwalk | http://www.ece.ucdavis.edu/ucd-snmp/
Snot | http://www.stolenshoes.net/sniph/index.html
SSL Proxy | http://www.obdev.at/products/ssl-proxy/index.html
Stick | http://www.eurocompton.net/stick/projects8.html
Virusdot.org | http://www.governmentsecurity.org/articles/DefaultLoginsandPasswordsforNetworkedDevices.php
Whisker+SSL | http://www.digitaloffense.net


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 configuration
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 alerts.

To specify a single address, simply enter the IP address:

var HOME_NET 10.120.25.135

You can also specify multiple addresses. Enclose the group of addresses in square brackets and separate them with commas (no spaces):

var HOME_NET [10.10.10.20,192.168.1.23,172.16.30.25]

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 255.255.255.0 subnet mask (24 bits of subnet), use a "/24":

var HOME_NET 10.10.10.0/24

You can mix and match specific IP addresses with the RFC 1918 subnet designations: square brackets, commas, and no spaces:

var HOME_NET [192.168.1.12,172.16.0.0/16,10.10.10.10,10.10.20.0/24]

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:

var EXTERNAL_NET !$HOME_NET

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:

var ORACLE_PORTS 1521

To designate a range of ports (in this case, ports 8000 through 8080 inclusive):

8000:8080

We could also designate all ports up to a port (here we're saying all ports up to port 8080):

:8080

To designate all ports that are not 80:

var SHELLCODE_PORTS !80

5.1.1 Default Variables from snort.conf

The default variables from snort.conf are:

HOME_NET

Use this to specify the IP addresses of the systems you are protecting.

EXTERNAL_NET

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 HOME_NET and EXTERNAL_NET 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 -> $EXTERNAL_NET any (msg:"ATTACK-RESPONSES directory

listing"; content: "Volume Serial Number"; flow:from_server,established; classtype:

bad-unknown;

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:

DNS_SERVERS
SMTP_SERVERS
HTTP_SERVERS
SQL_SERVERS
TELNET_SERVERS
SNMP_SERVERS

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).

alert tcp $HTTP_SERVERS $HTTP_PORTS -> $EXTERNAL_NET any (msg:"ATTACK-RESPONSES

command completed"; content:"Command completed"; nocase; flow:from_

server,established; classtype:bad-unknown; sid:494; rev:6;)

HTTP_PORTS

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.

SHELLCODE_PORTS

Commonly set to !80 (any port besides port 80). You can, in most cases, leave this alone.

ORACLE_PORTS

Specifies the port that Oracle is listening on. By default, Oracle listens on port 1521. If you have changed this port, change the setting here.

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).

AIM_SERVERS

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.

RULE_PATH

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 /usr/local/share/snort_rules/march_2003/rules, set the variable like this:

var RULE_PATH /var/local/share/snort_rules/march_2003/rules


5.2 Snort Decoder and Detection Engine Configuration

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_experimental_alerts

# config disable_tcpopt_obsolete_alerts

# 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

Option

Description

config order: [pass, alert, log, activation, or dynamic]

Change the order that rules are evaluated.

config alertfile: alerts

Set the alerts output file.

config decode_arp

Turn on arp decoding (snort -a).

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: <interface name>

Set the network interface (snort -i).

config alert_with_interface_name

Append interface name to 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 -n).

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).

config checksum_mode : all

Types of packets to 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 -U).

config verbose

Use Verbose logging to stdout (snort -v.)

config dump_payload_verbose

Dump raw packet starting at link layer (snort -X ).

config show_year

Show year in timestamps (snort -y).


5.3 Preprocessor Configurations

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 self-defense. 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:

memcap

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.

rows

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 plenty.

stats_interval

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.

hash

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 flow:

preprocessor flow: stats_interval 0 hash 2

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 attacks.

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 preprocessors.

frag2 has several options:

timeout

The number of seconds before an inactive session is flushed from memory. It defaults to 60 seconds.

memcap

The number of bytes of memory to set aside. The default of 4 Megabytes (4,194,304 bytes) is plenty for most applications.

detect_state_problems

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.

min_ttl

Sets the minimum time to live (ttl) accepted by the preprocessor. Set to 0 by default.

ttl_limit

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 conversation.

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:

detect_scans

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.

detect_state_problems

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.

disable_evasion_alerts

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.

min_ttl

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.

ttl_limit

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.

noinspect

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 off.

timeout

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.

log_flushed_streams

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 with.

memcap

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 bytes).

Here's a suggested setting for stream4:

preprocessor stream4: detect scans, disable_evasion_alerts, timeout 60, ttl_limit 10

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 command-line 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:

clientonly

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.

serveronly

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.

both

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.

noalerts

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 stream4_reassembly.

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 stream4_reassemble:

preprocessor stream4_reassemble: both

5.3.5 HTTP Inspect Preprocessor

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.

5.3.5.1 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 unicode.map) 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).

detect_anomalous_servers

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 enabled.

proxy_alert

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 global:

preprocessor http_inspect: global iis_unicode_map unicode.map 1252

5.3.5.2 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 addresses).

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, iis_unicode_map, 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"

Option

Setting

flow_depth

300

chunk_encoding

Alert on chunks larger than 500,000 bytes

lis_unicode_map

The map used in the global configuration

ascii

No

non_refc_char

On

multi_slash

No

directory

No

apache_whitespace

Yes

double_decode

Yes

j_encode

Yes

bare_byte

Yes

lis_unicode

Yes

lis_backslash

No

lis_delimiter

Yes

Table 5-3. Settings for profile "apache"

Option

Setting

flow_depth

300

chunk_encoding

Alert on chunks larger than 500,000 bytes

ascii

No

non_rfc_char

On

multi_slash

No

directory

No

apache_whitespace

Yes

utf_8

No

non_strict

On

Table 5-4. Settings for profile "iis"

Option

Setting

flow_depth

300

lis_unicode_map

The map used inthe global configuration

ascii

No

multi_slash

No

directory

No

double-decode

Yes

u_encode

Yes

bare_byte

Yes

lis_unicode

Yes

lis_backslash

No

lis_delimiter

Yes

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 unicode.map) 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 ANSI- Latin I code map that is used in English).

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 traffic.

non_rfc_char {< list of bytes>}

This option allows you to alert on certain non-RFC character (designated as a list of space-delimited 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 slashes.

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 yes.

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 positives.

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.

no_pipeline_req

Turns inspection of pipeline encoding off. This should really only be disabled if you are experiencing performance problems.

non_strict

Some servers allow broken URIs (Apache, for instance). If you have Apache servers, enable this option.

allow_proxy_use

Allows proxy use on the specified web server. This option suppresses alerts generated by this server for unauthorized proxy use (if enabled).

no_alerts

Turns off all alerts generated by http_inspect.

oversize_dir_length < non-zero positive integer>

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.

inspect_uri_only

If you are having performance issues, you can limit http_inspect to watching only the URI portion of the HTTP request (which catches 90-95% 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: server default profile all ports {80 8080}

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: server 10.10.10.100 profile iis ports {80 8080}

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: server 10.10.10.200 profile apache ports {80 8080}

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 rpc_decode:

alert_fragments

Generates alerts for any fragmented RPC traffic. It is likely to generate only false positives.

no_alert_multiple_requests

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.

no_alert_large_fragments

RPC fragments can be larger than the current fragment size. If you are seeing false positives, you have the option for disabling these alerts.

no_alert_incomplete

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 alerts.

Here's a suggested setting for rpc_decode:

preprocessor rpc_decode:111 32771 1024

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 telnet_decode:

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. flow-portscan relies on the flow preprocessor being configured and operational to function (see the description of flow, above).

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 options.

There are three basic components of flow-portscan:

Scoreboards

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 options:

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 table.

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 range.

scanner-sliding-threshold < integer>

Defaults to 40 and sets the number of points that a scanner must accumulate in the scanner-sliding-threshold time range.

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 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 range.

talker-sliding-threshold < integer>

Defaults to 30 and sets the number of points that a scanner must accumulate in the talker-sliding-threshold time range.

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 uniqueness.

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 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 notation>

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 notation>

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 notation>

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 portscan.

server-scanner-limit < hit count>

Defaults to 500 and specifies how many requests on a port on an IP address in the server-watchnet flow-portscan 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 circumstances.

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 useful.

Here is a sample configuration for flow-portscan (remember that the flow preprocessor must be configured and running for flow-portscan to work):

preprocessor flow-portscan: server-watchnet [10.10.10.0/24,10.10.20.0/24]

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: 192.168.40.1 f0:0f:00:f0:0f:00

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 options:

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 packets)
Mbits per second (total)
Pattern-matching percent (average percent of data received that Snort processes
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:

preprocessor perfmonitor: time 30 events flow file stats.profile max \

console pktcnt 10000

preprocessor perfmonitor: time 300 file /var/tmp/snortstat pktcnt 10000


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 plug-ins 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 Snort.

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 LOG_AUTH:

LOG_AUTH
LOG_AUTHPRIV
LOG_DAEMON
LOG_LOCAL0
LOG_LOCAL1
LOG_LOCAL2
LOG_LOCAL3
LOG_LOCAL4
LOG_LOCAL5
LOG_LOCAL6
LOG_LOCAL7
LOG_USER

The priority option also specifies one of the syslog standard priorities and defaults to LOG_ALERT:

LOG_EMERG
LOG_ALERT
LOG_CRIT
LOG_ERR
LOG_WARNING
LOG_NOTICE
LOG_INFO
LOG_DEBUG

Here's a sample configuration for the alert_syslog output plug-in:

output alert_syslog: LOG_AUTH LOG_ALERT

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 number>

Here's an example of a Windows version of this output plug in's configuration:

output alert_syslog: host=10.10.10.100 LOG_AUTH LOG_ALERT

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/tcpdump.out

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>, <database type>, <parameter list>

<log|alert>

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 only).

When configuring the particular database output plug-in, set the following parameters (there are no commas in the parameter list):

host

The IP address of the database server. If left blank, it goes to the local machine.

port

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).

user

The username Snort uses to log into the database.

password

The password used to log into the database.

sensor_name

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.

encoding

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, human-readable). ascii is recommended.

detail

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.

5.4.3.1 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

5.4.3.2 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 --with-postgresql at configure time. Here's an example:

./configure --with-postresql

5.4.3.3 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

5.4.3.4 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.

5.4.3.5 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 high-demand 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/bad-traffic.rules

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 genuine.

# Include classification & priority settings

include classification.config

# Include reference systems

include reference.config


Chapter 6. Deploying Snort

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, too.

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 unnoticed.

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 decision.

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 advised.

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 watched.

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 Points

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 switches.

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 e-commerce 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 situation.

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 load-balancing 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 connected).

Figure 6-3. Snort is now able to watch the web transaction

    Previous Section < Day Day Up > Next Section


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 environment.

Closely managing the Snort systems is important. The operating systems should be configured according to industry-accepted 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 System

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 uptime.

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 Unix-based 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:

Supportability

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.

Performance

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 system.

Stability

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 Unix-based 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.

Security

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 security-related 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 Services

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-to-date. This is an essential step to making a system secure.

6.4.4 Apply Patches and Updates

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 state.

6.4.5 Utilize Robust Authentication

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 guesses).

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 choices.

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 Effectively

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 Snort-based NIDS deployment. Chapter 7 discusses strategies to keep your signatures up-to-date and effective.


6.6 Sites of Interest

Guide to Hardening Linux | http://www.antioffline.com/deviation/linux.html
Guide to Hardening BSD | http://www.antioffline.com/deviation/bsd.html
Apache 1.3 Security Tips | http://httpd.apache.org/docs/misc/security_tips.html
Apache 2.0 Security Tips | http://httpd.apache.org/docs-2.0/misc/security_tips.html
MySQL Security Tips | http://dev.mysql.com/doc/mysql/en/Security.html
NSA Secure Configuration Guides | http://www.nsa.gov/snac/index.cfm?MenuID=scg10.3.1
Microsoft Central Security Portal | http://www.microsoft.com/technet/security


Chapter 7. Creating and Managing Snort Rules

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 network.

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 security.


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:

http://www.snort.org/dl/rules/snortrules-snapshot-2_1.tar.gz

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) to /usr/local/share/snort_rules/april_1_2004/. I then extract the archive (which puts everything into a rules directory) using:

tar -zxvf snortrules-snapshot-2_1.tar.gz

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):

attack-responses.rules  local.rules       shellcode.rules

backdoor.rules          misc.rules        smtp.rules

bad-traffic.rules       multimedia.rules  snmp.rules

chat.rules              mysql.rules       sql.rules

ddos.rules              netbios.rules     telnet.rules

deleted.rules           nntp.rules        tftp.rules

dns.rules               oracle.rules      virus.rules

dos.rules               other-ids.rules   web-attacks.rules

experimental.rules      p2p.rules         web-cgi.rules

exploit.rules           policy.rules      web-client.rules

finger.rules            pop2.rules        web-coldfusion.rules

ftp.rules               pop3.rules        web-frontpage.rules

icmp-info.rules         porn.rules        web-iis.rules

icmp.rules              rpc.rules         web-misc.rules

imap.rules              rservices.rules   web-php.rules

info.rules              scan.rules        x11.rules

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 positives.


7.2 The Rule Sets

Here is a brief description of the rule sets:

attack-responses.rules

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 response.

backdoor.rules

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).

bad-traffic.rules

Watches for illegal packet header settings like a TCP and UDP port 0 traffic, or a SYN packet to a multicast address.

chat.rules

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.

ddos.rules

Alerts on traffic generated by many well-known distributed denial-of-service 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 environment.

deleted.rules

Actually not referenced by default in the snort.conf file; really just a museum of old Snort rules.

dns.rules

Alerts on attacks against DNS servers (including detection of zone transfers).

dos.rules

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.

experimental.rules

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.

exploit.rules

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 attack.

finger.rules

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.

ftp.rules

Generates alerts when known attacks are detected against the FTP service.

icmp-info.rules

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.

icmp.rules

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.

imap.rules

Generates alerts when known attacks against the IMAP email service are detected.

info.rules

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.

local.rules

Stores rules that you create.

misc.rules

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.

multimedia.rules

Disabled by default. If it is against your organization's security policies to run multimedia applications across the network, enable this rule set.

mysql.rules

Detects known attacks against mySQL database servers.

netbios.rules

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.

nntp.rules

Contains signatures that indicate attack against network time protocol servers.

oracle.rules

Detects known attacks against Oracle database servers.

other-ids.rules

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.

p2p.rules

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.

policy.rules

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).

pop2.rules

Generates alerts when known POP2 email service attacks are detected.

pop3.rules

Generates alerts when known POP3 email service attacks are detected.

porn.rules

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).

rpc.rules

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 network.

rservices.rules

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.

scan.rules

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.

shellcode.rules

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.

smtp.rules

Generates alerts when known SMTP email service attacks are detected.

snmp.rules

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.

sql.rules

Detects known attacks against Microsoft SQL Server database servers.

telnet.rules

Alerts on dangerous traffic transmitted in telnet sessions.

tftp.rules

Alerts on attacks against the TFTP service.

virus.rules

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.

web-attacks.rules

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 positives.

web-cgi.rules

Generates alerts when known attacks against CGI services are detected.

web-client.rules

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.

web-coldfusion.rules

Generates alerts when known attacks against Coldfusion web application services are detected.

web-frontpage.rules

Generates alerts when known attacks against Frontpage web authoring services are detected.

web-iis.rules

Detects known attacks against Microsoft Internet Information Server (IIS) web servers.

web-misc.rules

Generic web attack detection rules.

web-php.rules

Detects attacks against web servers running PHP applications (primarily runs on Apache, but it is possible to run on IIS).

x11.rules

Detects attacks against remote X-Windows 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 use.

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 -> $HOME_NET any (msg:"SCAN SYN FIN";flags:SF; reference:

arachnids,198; classtype:attempted-recon; sid:624; rev:1;)

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:

alert

Alerts and logs the packet when triggered.

log

Only logs the packet when triggered.

pass

Ignores or drops the packet or traffic matching.

activate

Alerts then activates a dynamic rule or rules.

dynamic

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 file).

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 [64.147.128.0/19,198.60.72.0/23] any -> $HOME_NET any

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 equal-to 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 [64.147.128.0/19,198.60.72.0/23] 21:23 -> $HOME_NET any

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 -> $HOME_NET any

(msg:"SCAN SYN FIN";flags:SF; reference:arachnids,198;

classtype:attempted-recon; sid:624; rev:1;)

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 rule.

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 flags.

alert tcp $HOME_NET 146 -> $EXTERNAL_NET 1024: (msg:"BACKDOOR Infector.1.x"; content:

"WHATISIT"; flags: A+; reference:arachnids,315; sid:117; classtype:misc-activity;

rev:3;)

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 100-1,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 sid-msg.map 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 -> $TELNET_SERVERS 23 ( sid: 210; rev: 3; msg:

"BACKDOOR attempt"; flow: to_server,established; content: "backdoor"; nocase;

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 flags:

A = ACK

F = FIN

P = PSH

R = RST

S = SYN

U = URG

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 specified.

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 case-sensitive, 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 rule.

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.

alert tcp $HTTP_SERVERS $HTTP_PORTS -> $EXTERNAL_NET any ( sid: 495; rev: 6; msg:

"ATTACK-RESPONSES command error"; flow: from_server,established; content: "Bad

command or filename"; nocase; classtype: bad-unknown;)

alert tcp $HOME_NET 22 -> $EXTERNAL_NET any ( sid: 1810; rev: 3; msg: "ATTACK-

RESPONSES successful gobbles ssh exploit (GOBBLE)"; flow: from_

server,established; content: "|2a|GOBBLE|2a|"; reference: bugtraq,5093;

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 data.

alert tcp $HOME_NET 902 -> $EXTERNAL_NET any ( sid: 1760; rev: 2; msg: "OTHER- IDS

ISS RealSecure 6 event collector connection attempt"; flow: from_

server,established; content: "6ISS ECNRA Built-In Provider, Strong Encryption";

offset: 30; depth: 70; nocase; classtype: successful-recon-limited;)

depth: < value>;

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 -> $EXTERNAL_NET any ( sid: 1761; rev: 2; msg: "OTHER-

IDS ISS RealSecure 6 daemon connection attempt"; flow: from_server,established;

content: "6ISS ECNRA Built-In Provider, Strong Encryption"; offset: 30; depth:

70; nocase; classtype: successful-recon-limited;)

nocase;

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 <> $EXTERNAL_NET 6699 ( sid: 561; rev: 6; msg: "P2P

Napster Client Data"; flow: established; content: ".mp3"; nocase; classtype:

policy-violation;)

regex

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 (PCRE).

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 -> 192.168.10.0/24 23 (logto:"telnets";)

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 traceroute.

alert icmp $EXTERNAL_NET any -> $HOME_NET any ( sid: 385; rev: 3; msg: "ICMP

traceroute"; ttl: 1; itype: 8; reference: arachnids,118; classtype: attempted-

recon;)

id: < number>;

The IP identification value found in the IP header of the datagram is a 16-bit value. These values increase by 1 or 256 for each datagram sent out. Normally, you will see standard 16-bit 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 value).

alert tcp $EXTERNAL_NET any -> $HOME_NET any (msg:"DOS Land attack"; id:3868;

seq: 3868; flags:S; reference:cve,CVE-1999-0016; classtype:attempted-dos; sid:

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 -> $HOME_NET any ( sid: 499; rev: 3; msg: "ICMP

Large ICMP Packet"; dsize:  >800; reference: arachnids,246; classtype: bad-

unknown;)

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 -> $HOME_NET any ( sid: 628; rev: 2; msg: "SCAN nmap

TCP"; flags: A,12; ack: 0; reference: arachnids,28; classtype: attempted-recon;)

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 -> $HOME_NET 1054 ( sid: 106; rev: 4; msg: "BACKDOOR

ACKcmdC trojan scan"; flags:  A,12; seq:  101058054; ack:  101058054; reference:

arachnids,445; classtype: misc-activity;)

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 <> $HOME_NET any ( sid: 1855; rev: 2; msg: "DDOS

Stacheldraht agent->handler (skillz)"; content: "skillz"; itype: 0; icmp_id:

6666; reference: url,staff.washington.edu/dittrich/misc/stacheldraht.analysis;

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 ( sid: 485; rev: 2; msg: "ICMP Destination

Unreachable (Communication Administratively Prohibited)"; itype: 3; icode: 13;

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 process.

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 -> $HOME_NET any ( sid: 467; rev: 1; msg: "ICMP

Nemesis v1.1 Echo"; content: "|0000000000000000000000000000000000000000|";

dsize:  20; itype:  8; icmp_id:  0; icmp_seq:  0; reference: arachnids,449;

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 equivalents.

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.

rr

Record route

eol

End of list

nop

No op

ts

Timestamp

sec

IP security option

lsrr

Loose source routing

ssrr

Strict source routing

satid

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 -> $HOME_NET any ( sid: 475; rev: 1; msg: "ICMP

traceroute ipopts"; ipopts:  rr; itype:  0; reference: arachnids,238; classtype:

attempted-recon;)

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.

R

Reserved bit

D

Don't fragment bit

M

More fragments bit

This example uses the reserved bits setting or R fragbits option.

alert ip $EXTERNAL_NET any -> $HOME_NET any ( sid: 523; rev: 4; msg: "BAD-TRAFFIC

ip reserved bit set"; fragbits: R; classtype: misc-activity;)

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[, react_additional_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.0/24 80 ( content-list: "

adult"; msg: "Warning, adult content"; react: block, msg;)

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 -> $HTTP_SERVERS $HTTP_PORTS ( sid: 1328; rev: 4;

msg: "WEB-ATTACKS ps command attempt"; flow: to_server,established; uricontent:

"/bin/ps"; nocase; classtype: web-application-attack;)

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 -> $HOME_NET any (msg:"Cisco IPv4 DoS";

classtype:attempted-dos; ip_proto 53;)

alert ip $EXTERNAL_NET any -> $HOME_NET any (msg:"Cisco IPv4 DoS";

classtype:attempted-dos; ip_proto 55;)

alert ip $EXTERNAL_NET any -> $HOME_NET any (msg:"Cisco IPv4 DoS";

classtype:attempted-dos; ip_proto 77;)

alert ip $EXTERNAL_NET any -> $HOME_NET any (msg:"Cisco IPv4 DoS";

classtype:attempted-dos; ip_proto 103;)

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 c:\WINNT\system32\drivers\etc\protocol under Windows.

sameip;

This is a very simple option that always stands by itself. It looks for identical source and destination IP addresses.

alert ip any any -> any any ( sid: 527; rev: 4; msg: "BAD-TRAFFIC same SRC/DST";

reference: cve,CVE-1999-0016; reference: url,www.cert.org/advisories/CA-1997-28.

html; classtype: bad-unknown; sameip;)

stateless;

Some alerts examine TCP traffic using stateful packet inspection. In certain cases, it waits until the three-way 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 ( msg: "All TCP flags set"; flags: 12UAPRSF;

stateless;)

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 -> $SQL_SERVERS 1433 ( sid: 704; rev: 5; msg: "MS-SQL

xp_sprintf possible buffer overflow"; flow: to_server,established; content:

"x|00|p|00|_|00|s|00|p|00|r|00|i|00|n|00|t|00|f|00|"; nocase; reference:

bugtraq,1204; classtype: attempted-user;)

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 -> $EXTERNAL_NET 25 ( sid: 721; rev: 4; msg:

"VIRUS OUTBOUND .pif file attachment"; flow: to_server,established; content:

"Content-Disposition|3a|"; content: "filename=|22|"; distance: 0; within: 30;

content: ".pif|22|"; distance: 0; within: 30; nocase; classtype: suspicious-

filename-detect;)

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

Attempted User Privilege Gain

unsuccessful-user

Unsuccessful User Privilege Gain

successful-user

Successful User Privilege Gain

attempted-admin

Attempted Administrator Privilege Gain

successful-admin

Successful Administrator Privilege Gain

shellcode-detect

Executable code was detected

trojan-activity

A Network Trojan was detected

web-application-attack

Web Application Attack

kickass-porn

Porn Content Requested

policy-violation

Potential Corporate Privacy Violation

The following is an example of classtype used in a Snort rule.

alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS ( sid: 1233; rev: 7; msg:

"WEB-CLIENT Outlook EML access"; flow: from_client,established; uricontent: ".

eml"; classtype: attempted-admin;)

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 -> $EXTERNAL_NET $HTTP_PORTS ( sid: 1284; rev: 9; msg:

"WEB-CLIENT readme.eml download attempt"; flow: from_client,established;

uricontent: "/readme.eml"; nocase; reference: url,www.cert.org/advisories/CA-

2001-26.html; classtype: attempted-user;)

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 match.

  • 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-to-Date

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 mailing list | http://lists.sourceforge.net/lists/listinfo/snort-sigs
CERT | http://www.cert.org
SANS | http://www.sans.org
Oinkmaster | http://oinkmaster.sf.net/oinkmaster/
IDSPolMan | http://www.activeworx.com
SnortCenter | http://users.pandora.be/larc/


Chapter 8. Intrusion Prevention

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 host-based 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 http://project.honeynet.org.


8.1 Intrusion Prevention Strategies

Several intrusion detection strategies have been developed, including:

Host-based memory and process protection

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 conversation.

Figure 8-1. Snort as a session interceptor

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 SnortSAM.

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 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 itself.

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 complete.

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 about.

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

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 http://www.packetfactory.net/libnet.

Once Snort is built with flexible response enabled, you can include several new options within your Snort rules. The option uses the following format:

resp:<resp_keyword>[,<resp_keyword>...]

The response keywords that you can add to the rules are:

rst_snd

Sends a RST packet to the sender of the packet that generated the alert.

rst_rcv

Sends a RST packet to the recipient of the packet that generated the alert.

rst_all

Sends a RST packet to both parties in the TCP session.

icmp_net

Sends an ICMP_NET_UNREACH message to the sender.

icmp_host

Sends an ICMP_HOST_UNREACH message to the sender.

icmp_port

Sends an ICMP_PORT_UNREACH message to the sender.

icmp_all

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 -> $HTTP_SERVERS $HTTP_PORTS (msg:"WEB-ATTACKS netcat

command attempt"; flow:to_server,established; content:"nc%20";nocase; sid:1360;

classtype:web-application-attack; rev:4; resp:rst_all)

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:

react:<react_keyword>[,<react_keyword>...]

The keywords you can use with react are:

block

Blocks access to the session when the malicious content is matched.

warn

Sends a visible warning to the client's web browser.

msg

The content of this setting is included with the warning returned to the user.

proxy

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 (content: "naughtyword"; msg: "Not for children!";

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 networks.

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 http://snort-inline.sourceforge.net 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 instance.

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 10.10.10.0/24 range are ever blocked, we can do this:

var EXTERNAL_NET !10.10.10.0/24

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:

drop

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 packet:

drop tcp $EXTERNAL_NET any -> $HOME_NET 22 (msg:"EXPLOIT gobbles SSH exploit

attempt"; flow:to_server,established; content:"GOBBLES"; reference:bugtraq,5093;

classtype:misc-attack; sid:1812; rev:2;)

sdrop

Configures Snort to drop packets matching the rule without triggering an alert. You can use this feature to configure Snort to block ICMP echo-request 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 alert:

sdrop udp $EXTERNAL_NET any -> $HOME_NET 1434 (msg:"MS-SQL ping attempt";

content:"|02|"; offset:0; depth:1; reference:nessus,10674; classtype:misc-

activity; sid:2049; rev:1;)

replace

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 -> $HOME_NET 21 (msg:"FTP ~root attempt"; flow:to_

server,established; content:"~root"; replace:"~ userroot"; nocase; )

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 http://www.snortsam.net. 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.gz

# cd snortsam

# chmod +x makesnortsam.sh

# ./makesnortsam.sh

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 SnortSAM

Download snortsam-patch.tar.gz from http://www.snortsam.net/files/snort-plugin/snortsam-patch.tar.gz 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 this:

# cd /usr/local/src/snortsam-patch/

# tar -zxvf snortsam-patch.tar.gz

# chmod +x patchsnort.sh

# ./patchsnort.sh /usr/local/src/snort/snort2.1.x/

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>,< pre-shared 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 192.168.1.0/24, supersecretkey

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 supersecretdefaultkey

port < port number>

The port number that SnortSAM uses to communicate with Snort sensors (898 is the default). Here's an example:

port 6666

dontblock < address or DNS hostname>

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, 10.10.10.0/24), or a hostname. There can only be one entry per line, but there can be an unlimited number of lines. Here's an example:

dontblock a.root-servers.net

dontblock 192.168.0.0/16

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 follows.

0:

Quiet

No logging occurs.

1:

Sparse

Only errors are logged.

2:

Normal

Errors and blocks are logged.

3:

Verbose

Additional information (such as connections/disconnections) 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

daemon

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:

daemon

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 period>

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 example:

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 example:

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> < enable_password>

pix < ip_address_of_PIX_firewall> < username/password> < enable_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 10.10.10.1 p1xp455w0rd 3n4bl3p455w0rd

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 example:

iptables eth1

Once the snortsam.conf is built, you can run SnortSAM, designating the location of the file:

# /usr/local/bin/snortsam /usr/local/etc/snortsam.conf

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 Server IP address>:<port>/<pre-shared key>

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: 192.168.1.1:6666/pr3sh4r3dk3y

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 illustration.

<duration>

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 -> $EXTERNAL_NET any (msg:"ATTACK-RESPONSES Microsoft

cmd.exe banner"; flow:from_server,established; content:"Microsoft Windows";

content:"(C) Copyright 1985-"; distance:0; content:"Microsoft Corp."; distance:0;

reference:nessus,11633; classtype:successful-admin; sid:2123; rev:1;

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 -> $HOME_NET 1434 (msg:"MS-SQL Worm propagation

attempt"; content:"|04|"; depth:1; content:"|81 F1 03 01 04 9B 81 F1 01|";

content:"sock"; content:"send"; reference:bugtraq,5310; classtype:misc-attack;

reference:bugtraq,5311; reference:url,vil.nai.com/vil/content/v_99992.htm; sid:

2003; rev:2; fwsam: src, 15 minutes;)


8.6 Sites of Interest

The HoneyNet Project | http://project.honeynet.org
libnet | http://www.packetfactory.net/libnet
SnortSAM | http://www.snortsam.net
Snort Inline Patch | http://snort-inline.sourceforge.net


Chapter 9. Tuning and Thresholding

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 Alarms)

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 overemphasized.

Sometimes false positives indicate a non-security-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 Alerts)

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-to-date as possible (see Chapter 7 for details).

  • 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-to-date 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 subdepartments.

  • 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 environments.

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—which 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 Tuning

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, low-risk 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, worm-related 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 CPU-intensive preprocessors is the frag2 preprocessor, which rebuilds these fragmented packets. If the sensor is behind the firewall, this preprocessor can be disabled.

Below are some changes that can be made to the snort.conf file to eliminate many common false positives.

9.3.1.1 The Snort decoder configuration

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_alerts

config disable_tcpopt_obsolete_alerts

config disable_tcpopt_ttcp_alerts

config disable_tcpopt_alerts

config disable_ipopt_alerts

9.3.1.2 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 0 hash 2

9.3.1.3 The frag2 preprocessor

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

9.3.1.4 The stream4_reassemble preprocessor

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: noalerts

9.3.1.5 The http_inspect preprocessor

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: server default \

    profile all ports { 80 8080 8180 } oversize_dir_length 500 no_alerts

9.3.1.6 The flow-portscan preprocessor

The flow-portscan preprocessor is the first (and currently only) flow-based plug-in. 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-sliding-scale-factor 0.50 \

#       talker-fixed-threshold 30 \

#       talker-sliding-threshold 30 \

#       talker-sliding-window 20 \

#       talker-fixed-window 30 \

#       scoreboard-rows-talker 30000 \

#       server-watchnet [10.2.0.0/30] \

#       server-ignore-limit 200 \

#       server-rows 65535 \

#       server-learning-time 14400 \

#       server-scanner-limit 4 \

#       scanner-sliding-window 20 \

#       scanner-sliding-scale-factor 0.50 \

#       scanner-fixed-threshold 15 \

#       scanner-sliding-threshold 40 \

#       scanner-fixed-window 15 \

#       scoreboard-rows-scanner 30000 \

#       src-ignore-net [192.168.1.1/32,192.168.0.0/24] \

#       dst-ignore-net [10.0.0.0/30] \

#       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.

9.3.2.1 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 disabled.

# 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 9.3.2.2, 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 set:

# 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 sets:

# 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 environments):

exploit.rules

dos.rules

ddos.rules

attack-responses.rules

9.3.2.2 Tuning individual rules

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 enabled.

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 Suppression

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 file):

Limit

Alert on the first M events during the time interval, then ignore events for the rest of the time interval.

Threshold

Alert every M times this event is seen during the time interval.

Both

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|both], track [by_src|by_dst], count n , seconds m ;

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 -> $HTTP_SERVERS $HTTP_PORTS (msg:"WEB-IIS unicode

directory traversal attempt"; flow:to_server,established; content:"/..%c0%af../";

nocase; classtype:web-application-attack; reference:cve,CVE-2000-0884; threshold:

type limit, track_by_dst, count 1, seconds 60; sid:981; rev:6;)

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 high:

    alert tcp $HTTP_SERVERS $HTTP_PORTS -> $EXTERNAL_NET any (msg:"ATTACK-

RESPONSES 403 Forbidden"; flow:from_server,established; content:"HTTP/1.1 403";

depth:12; classtype:attempted-recon; threshold: type threshold, track by_dst,

count 20, seconds 60; sid:1201; rev:7;)

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 minutes:

    alert tcp $SQL_SERVERS 1433 -> $EXTERNAL_NET any (msg:"MS-SQL sa login

failed"; content: "Login failed for user |27|sa|27|"; flow:from_

server,established; classtype:unsuccessful-user; threshold: type both, track by_

dst, count 5, seconds 60; sid:688; rev:4;)

Standalone thresholds are written with the following syntax:

threshold gen_id gen-id, sig_id sig-id, type [limit|threshold|both], track [by_

src|by_dst], count n , seconds m

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, type limit, track by_src, count 1, seconds 120

And limit to logging every fifth event in 120 seconds for the same signature:

threshold gen_id 1, sig_id 1759, type threshold, track by_src, count 5, seconds 120

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, type both, track by_src,  count 50, seconds 60

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 limit, track by_src, count 1, seconds 120

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 address:

threshold gen_id 0, sig_id 0, type limit, track by_dst, count 1, seconds 120

..."

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 alerts.

Suppression rules are written with the following syntax:

suppress gen_id gen-id, sid_id sid-id, track [by_src|by_dst], ip IP/MASK-BITS

Suppress this event completely:

suppress gen_id 1, sig_id 114

Suppress this event from this source IP address:

suppress gen_id 1, sig_id 114, track by_src, ip 10.2.1.154

Suppress this event to this destination CIDR block:

suppress gen_id 1, sig_id 114, track by_dst, ip 10.2.1.0/24


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—we 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 Internet.


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 components:

  • MySQL

  • Snort

    • MySQL Support

  • Apache

    • GD Support

    • OpenSSL Support

    • MySQL Support

  • PHP

    • GD Support

    • OpenSSL Support

    • MySQL Support

  • ACID

    • Adodb

    • Jpgraph/phplot

    • GD

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 (http://www.mysql.com/).

10.1.1.1 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 \

'root'@'localhost'=password('your_password_goes_here');

mysql> create database snort;

mysql> exit

Some systems may generate the following error:

Can't connect to local MySQL server through socket '/tmp/mysql.sock'

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 mysql.sock

# 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 on

You'll be prompted for a root password upon login in order to access the database files. Enter the new password at the prompt.

# 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.

10.1.1.2 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-devel

Remove the installed Apache and PHP versions.

# 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 | tar xvf -

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:

PATH=$PATH:$HOME/bin:/usr/local/mysql/bin

Change to the uncompressed MySQL directory and run the following commands as root:

# cd /mysql-4.0.xx/

# ./configure --prefix=/usr/local/mysql

# make

# 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 location.

# chown -R root /usr/local/mysql

# chown -R mysql /usr/local/mysql/var

# chgrp -R mysql /usr/local/mysql

# cp support-files/my-medium.cnf/ etc/my.cnf

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/ld.so.conf file.

/usr/local/lib

/usr/local/mysql/lib/mysql

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 --user=mysql &

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 daemon:

# cp /usr/local/src/mysql-4.0.xx/support-files/mysql.server /etc/init.d/mysql

# 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.

10.1.1.3 Adding tables and permissions

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 third-party 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-2.1.x/contrib/create_mysql;

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 rights.

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 create_mysql script. Or, if you are feeling adventurous, here is another method that works well:

# zcat /usr/local/src/snort-2.1.x/contrib/snortdb-extra.gz | mysql -p snort

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;

mysql> grant CREATE,INSERT,SELECT,DELETE,UPDATE on snort.* to snort;

mysql> grant CREATE,INSERT,SELECT,DELETE,UPDATE on snort.* to snort@localhost;

mysql> grant CREATE,INSERT,SELECT,DELETE,UPDATE on snort.* to \

snort@www.mydomain.com;

Replace the variable "www.mydomain.com" 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.

mysql> grant CREATE,INSERT,SELECT,UPDATE on snort.* to acidviewer;

mysql> grant CREATE,INSERT,SELECT,UPDATE on snort.* to acidviewer@localhost;

mysql> grant CREATE,INSERT,SELECT,UPDATE on snort.* to acidviewer@www.mydomain.com;

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'@'localhost'=password('your_password');

mysql> set password for 'snort'@'www.mydomain.com'=password('your_password');

mysql> set password for 'snort'@'%'=password('your_password');

mysql> set password for 'acidviewer'@'localhost'=password('your_other_password');

mysql> set password for 'acidviewer'@'www.mydomain.com'=password('your_other_

password');

mysql> set password for 'acidviewer'@'%'=password('your_other_password');

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 machine.

Once you have set all the variables, verify who has what permissions. Connect to the mysql database and issue the following command:

# 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 possible.

mysql> select user,host from user;

+------------+------------------+

| user       | host             |

+------------+------------------+

| acidviewer | %                |

| snort      | %                |

|            | localhost        |

| acidviewer | localhost        |

| root       | localhost        |

| snort      | localhost        |

|            | www.mydomain.com |

| acidviewer | www.mydomain.com |

| root       | www.mydomain.com |

| snort      | www.mydomain.com |

+------------+------------------+

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 following:

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 | www.mydomain.com |

| root       | www.mydomain.com |

| snort      | www.mydomain.com |

+------------+------------------+

8 rows in set (0.00 sec)

This is yet another small security measure to ensure the safety of the network management console machine.

10.1.1.4 Cleaning house or reinstalling

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 data.

10.1.2 Installing the Web Server

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 (http://www.apache.org) 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.

10.1.3.1 Installing from RPMs

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 location:

ftp://ftp.redhat.com/pub/redhat/linux/9/en/os/i386/RedHat/RPMS/

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.

10.1.3.2 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 | tar xvf -

# cd openssl-0.9.6g/

# ./config

# make

# 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 | tar xvf -

# cd httpd-2.0.xx/

# ./configure --prefix=/usr/local/httpd \

--enable-so --enable-cgi --enable-info --enable-rewrite \

--enable-speling --enable-usertrack --enable-deflate \

--enable-mime-magic

# 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/httpd/php \

--with-apxs2=/usr/local/httpd/bin/apxs \

--with-config-file-path=/usr/local/httpd/php \

--with-mysql --enable-track-vars \

--enable-force-cgi-redirect --with-zlib \

--with-gettext --with-gdbm --with-gd

# make

# make install

# cp -p .libs/libphp4.so /usr/local/httpd/modules/

# cp php.ini-dist /usr/local/httpd/php/php.ini

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 with this directive:

LoadModule php4_module modules/libphp4.so

# Add index.php to your DirectoryIndex line:

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 start

Follow these steps for integrating the included script into the startup run command directories.

# cd /usr/local/httpd/bin/

# cp apachectl /etc/init.d/httpd

# cd /etc/rc3.d/

# ln -s ../init.d/httpd S85httpd

# ln -s ../init.d/httpd K85httpd

# cd /etc/rc5.d/

# ln -s ../init.d/httpd S85httpd

# ln -s ../init.d/httpd K85httpd

10.1.3.3 Testing Apache and PHP

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 this:

# /etc/rc5.d/S85httpd start

Starting httpd:                                            [  OK  ]

or execute the daemon from the command line using the full path:

# /usr/local/httpd/bin/apachectl start

The web server should now be running. Additional security and optimization items are addressed later in this chapter.

10.1.3.4 Managing dependencies

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.

# wget http://www.zlib.net/zlib-1.2.1.tar.gz

# gunzip -c zlib-1.2.1.tar.gz | tar xvf -

# 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.

10.1.3.5 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 > /etc/httpd/conf/ssl.key/server.key

Generating RSA private key, 1024 bit long modulus

........++++++

...........++++++

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/httpd/conf/ssl.key/server.key \

-x509 -days 365 -out /etc/httpd/conf/ssl.crt/server.crt

Enter pass phrase for /etc/httpd/conf/ssl.key/server.key:

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 information that will be incorporated

into your certificate request.

What you are about to enter is what is called a Distinguished Name or a DN.

There are quite a few fields but you can leave some blank

For some fields there will be a default value,

If you enter '.', the field will be left blank.

-----

Country Name (2 letter code) [GB]:US

State or Province Name (full name) [Berkshire]:Wisconsin

Locality Name (eg, city) [Newbury]:Mount Horeb

Organization Name (eg, company) [My Company Ltd]:The Xentinel Group

Organizational Unit Name (eg, section) []:IDS Security

Common Name (eg, your name or your server's hostname) []:test.xentinel.net

Email Address []:someone@xentinel.net

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 80.

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_ssl/2.0.40 (Pass Phrase Dialog)

Some of your private key files are encrypted for security reasons.

In order to read them you have to provide us with the pass phrases.

Server new.host.name:443 (RSA)

Enter pass phrase:

Ok: Pass Phrase Dialog successful.                        [  OK  ]

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 https://www.mydomain.com.

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 server, specto.ksl.com.

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 Configurations

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/access_log common

CustomLog /usr/local/httpd/logs/access_log combined

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 NameWidth=*

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 /usr/local/httpd/bin/apachectl 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 http://grc.com/id/idserve.htm 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 access.

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 restart

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 start

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 /usr/local/httpd/bin/httpd

webuser 17676 17675 0 13:14 ? 00:00:00 /usr/local/httpd/bin/httpd

webuser 17677 17675 0 13:14 ? 00:00:00 /usr/local/httpd/bin/httpd

webuser 17678 17675 0 13:14 ? 00:00:00 /usr/local/httpd/bin/httpd

webuser 17679 17675 0 13:14 ? 00:00:00 /usr/local/httpd/bin/httpd

webuser 17680 17675 0 13:14 ? 00:00:00 /usr/local/httpd/bin/httpd

root 17682 3648 0 13:14 pts/2 00:00:00 grep http

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 Installation

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, http://acidlab.sourceforge.net. 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 network.

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 /var/www/html/.

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.

# cp acid-0.9.6b23.tar.gz /usr/local/httpd/htdocs/

# cp adodb360.tgz /usr/local/httpd/htdocs/

# cp jpgraph-1.12.1.tar.gz /usr/local/httpd/htdocs/

# cp phplot-4.4.6.tar.gz /usr/local/httpd/htdocs/

# cp gd-2.0.12.tar.gz /usr/local/httpd/htdocs/

Uncompress the transplanted files within the web root directory.

# cd /usr/local/httpd/htdocs/

# gunzip -c acid-0.9.23.tar.gz | tar xvf -

# gunzip -c adodb360.tgz | tar xvf -

# gunzip -c jpgraph-1.12.1.tar.gz | tar xvf -

# gunzip -c phplot-4.4.6.tar.gz | tar xvf -

# gunzip -c gd-2.0.12.tar.gz | tar xvf -

Some of the directories require renaming along with a shuffling of files.

# cd jpgraph-1.12.1/src/

# mkdir /usr/local/httpd/htdocs/jpgraph

# cp -R * /usr/local/httpd/htdocs/jpgraph/

# 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 Support

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:

http://<youracidhost>/jpgraph/utils/misc/chkgd.php

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/jpgraph_cache/

Open the URL to verify that your images were generated correctly.

http://<youracidhost>/jpgraph/utils/misc/gencolorchart.php

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 GD.

http://<youracidhost>/jpgraph/examples/

Figure 10-2 is an example showing the images generated via the web page.

Figure 10-2. Example image generated using the JpGraph utility

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, /usr/local/httpd/htdocs/acidviewer.

# mkdir /usr/local/httpd/htdocs/acidviewer

# cd /usr/local/httpd/htdocs/acid/

# cp -R * /usr/local/httpd/htdocs/acidviewer/

# cd ../acidviewer

# vim acid_conf.php

Modify the following variables in the /usr/local/httpd/htdocs/acidviewer/acid_conf.php 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 account.

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/passwords/acid_passwords admin

# htpasswd /usr/local/httpd/passwords/acid_passwords acidviewer

# cd /usr/local/httpd/

# chown -R webuser.webuser passwords/

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> sections.

<Directory "/usr/local/httpd/htdocs/acid">

    AuthType Basic

    AuthName "your_company_name"

    AuthUserFile /usr/local/httpd/passwords/acid_passwords

    Require user admin

    AllowOverride None

</Directory>

<Directory "/usr/local/httpd/htdocs/acidviewer">

    AuthType Basic

    AuthName "your_company_name"

    AuthUserFile /usr/local/httpd/passwords/acid_passwords

    Require user acidviewer

    AllowOverride None

</Directory>

Restart the HTTP daemon using your command of choice:

# /usr/local/httpd/bin/apachectl restart

or the following, if using the Apache RPMs:

# 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 machine:

http://<youracidhost>/acid/index.html

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 address:

http://<youracidhost>/acidviewer/index.html

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 following:

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 AG."

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 Console

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.

https://my.domain.com/acid/

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.

https://my.domain.com/acidviewer/

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.

10.3.1.1 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 glance.

Figure 10-3. ACID's main interface (each link is highlighted)

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 system.

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.

10.3.1.2 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—whether 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.

10.3.1.3 Searching and graphing

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.

10.3.1.4 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 incident.

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 Data

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:

Signature

A brief description of the alert and a link to an external site explaining its signature in detail

Classification

The grouping into which this alert type falls

Total #

The number of times a particular signature has been logged since analysis began

Sensor #

The ID of the sensor that logged that signature

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

First

The timestamp a logged packet is first detected and a link to its payload

Last

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 function.

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.

10.4.1.1 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 discounted.

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,short description,priority

#

not-suspicious,Not Suspicious Traffic,3

unknown,Unknown Traffic,3

bad-unknown,Potentially Bad Traffic, 2

attempted-recon,Attempted Information Leak,2

successful-recon-limited,Information Leak,2

successful-recon-largescale,Large Scale Information Leak,2

attempted-dos,Attempted Denial of Service,2

successful-dos,Denial of Service,2

attempted-user,Attempted User Privilege Gain,1

unsuccessful-user,Unsuccessful User Privilege Gain,1

successful-user,Successful User Privilege Gain,1

attempted-admin,Attempted Administrator Privilege Gain,1

successful-admin,Successful Administrator Privilege Gain,1

# NEW CLASSIFICATIONS

rpc-portmap-decode,Decode of an RPC Query,2

shellcode-detect,Executable code was detected,1

string-detect,A suspicious string was detected,3

suspicious-filename-detect,A suspicious filename was detected,2

suspicious-login,An attempted login using a suspicious username,2

system-call-detect,A system call was detected,2

tcp-connection,A TCP connection was detected,4

trojan-activity,A Network Trojan was detected, 1

unusual-client-port-connection,A client was using an unusual port,2

network-scan,Detection of a Network Scan,3

denial-of-service,Detection of a Denial of Service Attack,2

non-standard-protocol,Detection of a non-standard protocol or event,2

protocol-command-decode,Generic Protocol Command Decode,3

web-application-activity,access to a vulnerable web application,2

web-application-attack,Web Application Attack,1

misc-activity,Misc activity,3

misc-attack,Misc Attack,2

icmp-event,Generic ICMP event,3

kickass-porn,SCORE! Get the lotion!,1

policy-violation,Potential Corporate Privacy Violation,1

default-login-attempt,Attempt to login by a default username and password,2

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 detail.

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.

10.4.1.2 Identifying known attacks

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.

10.4.1.3 Notifying the offender

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.

10.4.1.4 Searching the database

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 occurrences.

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.

10.4.1.5 Graphing data for viewing

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-to-understand 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 generated.

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 option.

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 high-traffic 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 investigated.

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

MySQL Database Server | http://www.mysql.com
Apache Web Server | http://httpd.apache.org
IDServe Web Server Identification Tool | http://grc.com/id/idserve.htm
ACID IDS Management Console | http://acidlab.sourceforge.net
PHP Hypertext Preprocessor | http://www.php.net
Installation guide for RedHat 9 | http://www.snort.org/docs/snort_acid_rh9.pdf
Installation guide for Solaris 9 | http://www.snort.org/docs/snort-acid_solaris9.pdf
Installation guide for FreeBSD | http://www.snort.org/docs/FreeBSD47RELEASE-Snort-MySQLVer1-3.pdf


Chapter 11. Using SnortCenter as a Snort IDS Management Console

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 Installation

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 Snort-related 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 include:

Apache

You can find Apache intallation instructions in Chapter 10.

PHP

Instructions for installing PHP are located in Chapter 10.

ADODB

ADODB installation instructions are also in Chapter 10.

cURL Binary

Can be found at http://curl.haxx.se/download.html. 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 http://www.openssl.org.

11.1.1.1 Installing curl Binary

From the curl web site (http://curl.haxx.se):

Curl is a command-line tool for transferring files with URL syntax, supporting FTP, FTPS, HTTP, HTTPS, GOPHER, TELNET, 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/local/src/curl/.

# cd /usr/local/src/curl

# rpm -ivh curl-7.10.5-42.i586.rpm

11.1.2 Installing the Console Software

The URL for downloading the SnortCenter software is located at http://users.pandora.be/larc/download/.

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 Snort-1.9.1 and earlier.

Here is one possible method for downloading and installing the latest SnortCenter code.

# cp snortcenter-v1.0-RC1.tar.gz /usr/local/httpd/htdocs/

# cd /usr/local/httpd/htdocs/

# gunzip -c snortcenter-v1.0-RC1.tar.gz | tar xvf -

# cd www/

# mkdir /usr/local/httpd/htdocs/snortcenter/

# cp -R * /usr/local/httpd/htdocs/snortcenter/

# cd /usr/local/httpd/htdocs/snortcenter/

# rm -rf /usr/local/httpd/htdocs/www

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 http://www.megaloman.com/~hany/software/hd2u/ or from an open source repository, such as Freshmeat (http://freshmeat.net).

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 specified:

$alert_console = "http://<youracidhost>/acid/

";

$snortrules_url = "http://www.snort.org/dl/rules/snortrules-stable.tar.gz

";

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 change.

# 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 Installation

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 prerequisites:

Perl5

Most systems have Perl installed. If you need to install Perl, you can find it at http://www.perl.com 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 at http://www.openssl.org.

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 http://symlabs.com/Net_SSLeay/.

11.2.2 Installing the Agent

Download the latest agent (snortcenter-agent-v1.0-RC1.tar.gz) from:

http://users.pandora.be/larc/download/

Then install the agent using the following command line:

# mkdir /usr/local/src/snortcenter_agent

# cp snortcenter-agent-v1.0-RC1.tar.gz /usr/local/sec/snortcenter_agent/.

# cd /usr/local/src/snortcenter_agent

# tar -zxvf snortcenter-agent-v1.0-RC1.tar.gz

# cd sensor

# ./setup.sh

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 on

  • The IP address it should use

  • The authentication information for the agent

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 11-1.

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 Internet.

  • 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 sensors.

  • Supports the SnortSAM application.

  • A single sensor agent can handle multiple Snort daemons, provided the system has multiple network interfaces.

  • 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 sensors.

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 drop-down 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 drop-down 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 nature.

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 sensor.

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 [image] Rules [image] 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 settings.

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.

11.4.3.1 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).

  2. Set the rule name as desired and set the action and protocol fields (normally these will be set to "alert" and "TCP").

  3. Set the source and destination IP addresses (variables such as $HOME_NET and $EXTERNAL_NET can be used).

  4. Set the flow field (normally, to "to_server,established").

  5. 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 [image] Config [image] Rule 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 [image] Rules [image] View 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 use.


11.5 Adding Sensors to the Console

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 Console

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 setup.sh file under the snortcenter-agent/ directory. If a connection cannot be established, revisit the configuration.

After confirming connectivity, open the Sensor Config [image] 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 users.

11.6.1 Updating Rules and Signatures

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: http://www.snort.org/dl/.

11.6.1.1 Automatic update feature

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/snortcenter/db_pars.php?source=net&push=yes"

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://localhost/snortcenter/db_pars.php?source=net&push=yes"

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 needed.

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 sid-msg.map 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 icon.

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 eliminated.

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 process.


Chapter 12. Additional Tools for Snort IDS Management

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
Link: | http://www.circuitsmaximus.com
Download Link: | http://freshmeat.net/projects/snortreport/
Platform: | Web-based (PHP)
Prerequisites: | 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
Link: | http://www.silicondefense.com
Download Link: | http://www.silicondefense.com/software/snortsnarf
Platform: | Any (Perl-based)
Prerequisites: | 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 pages.

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

Developer: | Dragos Ruiu
Link: | http://dragos.com/cerebus
Download Link: | http://dragos.com/cerebus/download.html
Platform: | Linux, FreeBSD, OpenBSD, Solaris, Windows
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 sid-msg.map 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 console

12.1.4 IDS Policy Manager

Developer: | Jeff Dell
Link: | http://www.activeworx.com/idspm/
Download Link: | http://www.activeworx.com/downloads/
Platform: | 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 (SCP).

IDS Policy Manager is a very full-featured 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 12-4.

Figure 12-4. The IDS Policy Manager sensor management interface

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 preprocessors.

Figure 12-5. The flow preprocessor configuration interface

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
Link: | http://oinkmaster.sourceforge.net
Download Link: | http://oinkmaster.sourceforge.net/download.shtml
Platform: | 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 http://www.snort.org/dl/rules/snortrules-snapshot-2_1.tar.gz.The 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 installed.

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 Snort-based solutions on the market. They are, not surprisingly, very polished and full-featured. They are also not inexpensive. Three solutions rise to the top when considering the current products on the market.

12.2.1 Applied Watch Console

Developer: | Applied Watch Technologies
Link: | http://www.appliedwatch.com
Supported platforms | 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
Link: | http://www.demarc.com/products/puresecure/
Supported platforms: | Available for Windows, Linux, *BSD, and 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 console

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 http://www.demarc.com/downloads/PureSecure/personal.

12.2.3 Sourcefire Management Console

Developer: | Sourcefire, Inc.
Link: | http://www.sourcefire.com
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 (Real-time 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 Snort

For most environments, Snort running on a modern computer (even a workstation-class 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 single-threaded. 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 tools.

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 <filename>, limit <log file size>

filename

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 unified.log, limit 512

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 below).

13.1.2 Installing Barnyard

Download Barnyard from http://www.snort.org/dl/barnyard 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    /local/src/barnyard/barnyard-0.x.0/

# ./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 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 expression>

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 options>

(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>, < priority>

Outputs using the syslog mechanism with the same options as Snort (see Chapter 5).

output alert_syslog2: < facility>, < priority>

Uses a mechanism similar to the alert_syslog output line, but has the expanded formats of syslog2 available.

output log_pcap: <filename>

Outputs data in the standard pcap format.

output alert_acid_db : <database type>, sensor_id <sensor id>, database <database name>, server <server address>, user <username for database>, password <database password>

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, sensor_id 1, database snort, server 10.10.10.25, user

snort_user, password pa$$w0rd, detail full

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 1, database sguil, server 10.10.10.25, user sguil_

user, password pa$$w0rd, sguild_host localhost, sguild_port 7736

13.1.4 Barnyard Command-Line Options

Barnyard runs in one of three modes: one-shot, 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:

-R

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 logs.

-L < dir>

If Barnyard is configured to output to files, this path designates where the files should be written.

-v

Increases verbosity of console output.

-s < file>

The path to Snort's sid-msg.map file. Included with the Snort rules download and specifies the sid for an alert message.

-g < file>

The path to Snort's gen-msg.map 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 timestamp.

-n

Only process new events.

-w < file>

The checkpoint (waldo) file used for continual with checkpoint mode.

-D

Run in daemon mode.

-X < file>

Specify a file to store the PID of the Barnyard process.

-o

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.conf -d /var/log/snort \

-c /usr/local/share/snort_rules/classification.config \

-s /usr/local/share/snort_rules/sid-msg.map \

-g /usr/local/share/snort_rules/gen-msg.map -o unified.log.1083726235

Then we have continual mode with checkpoint:

barnyard -c /usr/local/etc/barnyard.conf -d /var/log/snort \

-c /usr/local/share/snort_rules/classification.config \

-s /usr/local/share/snort_rules/sid-msg.map \

-g /usr/local/share/snort_rules/gen-msg.map -w /usr/local/etc/waldo.chk \

-f unified.log

13.1.5 Sguil: An Alternative Management Console

Developer: | Bamm Visscher
Link: | http://squil.sourceforge.net
Download Link: | http://sourceforge.net/project/showfiles.php?group_id=71220
Platform: | Tcl/Tk client/server architecture
Prerequisites: | MySQL, Snort, Barnyard, Tcl/Tk 8.3 or newer (http://www.tcl.tk/software/tcltk/), Tclx libraries (http://tclx.sourceforge.net), Mysqltcl (http://www.xdobry.de/mysqltcl/), incr tcl (itcl) (http://incrtcl.sourceforge.net/itcl/), tcllib extension (http://tcllib.sf.net), Tcpflow (http://www.circlemud.org/~jelson/software/tcpflow/), p0f (http://lcamtuf.coredump.cx/p0f.shtml)

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 post-incident 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 flow-portscan 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 action

Figure 13-3. The sguil query builder

    Previous Section < Day Day Up > Next Section


13.2 Commericial IDS Load Balancers

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 Switches

F5 Networks (http://www.f5networks.com) 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 Appliance

Radware (http://www.radware.com) 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 (http://www.toplayer.com) 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 (I(DS)2).

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 routing

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 CPU-intensive. 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 on.

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 System.

Figure 13-5. The IDS Distribution System (1 Gbps capacity)

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 systems.

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 two-legged 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 network.

The outbound port of the Layer 2 cross-connect 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 network.

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.

13.3.3.1 Layer 2 cross-connect

The Layer 2 cross-connect (MAC Munger) can be downloaded from http://www.sourceforge.net/projects/l2cc. 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/l2cc-linux/l2cc-0.010.diff

Configure the kernel to enable l2cc:

# cd /usr/src/linux

# make menuconfig

Turn on these options:

Code maturity level options --->

      [*] Prompt for development and/or incomplete code/drivers

...

Networking options --->

      [*] Layer 2 Cross Connectr (EXPERIMENTAL)  (NEW)

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 interface:

l2ccadm [-a|-d] -i <interface name for SPAN port side> -o <interface name of policy

router side> -m <MAC address of outside interface of policy router>

-a

Adds a cross connect (you can only have either -a or -d, not both).

-d

Deletes a cross-connect.

-i

Indicates the "in" interface (example: eth0).

-o

Indicates the "out" interface (example: eth1).

-m

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 line:

# l2ccadm -a -i eth0 -o eth1 -m FE:FD:11:00:01:01

13.3.3.2 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 10.10.0.0/16 to the sensor with the IP address of 172.30.16.11 and all traffic to and from 10.20.0.0/16 to the sensor with the IP address of 172.30.16.12. eth0 is the inbound aggregated stream from the l2cc system and eth1 is the outbound interface that routes traffic to the sensors.

#!/bin/tcsh

# Rules to send all traffic to and from designated range to route table 31

ip rule add type unicast from 10.10.0.0/16 table 31

ip rule add type unicast to 10.10.0.0/16 table 31

# Rules to send all traffic to and from designated range to route table 32

ip rule add type unicast from 10.20.0.0/16 table 32

ip rule add type unicast to 10.20.0.0/16 table 32

# map route table 31 to sensor at designated address out from eth1

ip route add default via 172.30.16.11 dev eth1 table 31

# map route table 32 to sensor at designated address out from eth1

ip route add default via 172.30.16.12 dev eth1 table 32

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 Schema

The following tables are in a database configured for Snort and ACID:

acid_ag | event | sensor
acid_ag_alert | icmphdr | sig_class
acid_event | iphdr | sig_reference
acid_ip_cache | opt | signature
data | reference | tcphdr
detail | reference_system | udphdr
encoding | schema |

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             | Null | Key | Default | Extra          |

+----------+------------------+------+-----+---------+----------------+

| ag_id    | int(10) unsigned |      | PRI | NULL    | auto_increment |

| ag_name  | varchar(40)      | YES  |     | NULL    |                |

| ag_desc  | text             | YES  |     | NULL    |                |

| ag_ctime | datetime         | YES  |     | NULL    |                |

| ag_ltime | datetime         | YES  |     | NULL    |                |

+----------+------------------+------+-----+---------+----------------+

A.1.1 acid_ag_alert

+--------+------------------+------+-----+---------+-------+

| Field  | Type             | Null | Key | Default | Extra |

+--------+------------------+------+-----+---------+-------+

| ag_id  | int(10) unsigned |      | PRI | 0       |       |

| ag_sid | int(10) unsigned |      | PRI | 0       |       |

| ag_cid | int(10) unsigned |      | PRI | 0       |       |

+--------+------------------+------+-----+---------+-------+

A.1.1.1 acid_event
+--------------+------------------+------+-----+---------------------+-------+

| Field        | Type             | Null | Key | Default             | Extra |

+--------------+------------------+------+-----+---------------------+-------+

| sid          | int(10) unsigned |      | PRI | 0                   |       |

| cid          | int(10) unsigned |      | PRI | 0                   |       |

| signature    | int(10) unsigned |      | MUL | 0                   |       |

| sig_name     | varchar(255)     | YES  | MUL | NULL                |       |

| sig_class_id | int(10) unsigned | YES  | MUL | NULL                |       |

| sig_priority | int(10) unsigned | YES  | MUL | NULL                |       |

| timestamp    | datetime         |      | MUL | 0000-00-00 00:00:00 |       |

| ip_src       | int(10) unsigned | YES  | MUL | NULL                |       |

| ip_dst       | int(10) unsigned | YES  | MUL | NULL                |       |

| ip_proto     | int(11)          | YES  | MUL | NULL                |       |

| layer4_sport | int(10) unsigned | YES  | MUL | NULL                |       |

| layer4_dport | int(10) unsigned | YES  | MUL | NULL                |       |

+--------------+------------------+------+-----+---------------------+-------+

A.1.1.2 acid_ip_cache
+---------------------+------------------+------+-----+---------+-------+

| Field               | Type             | Null | Key | Default | Extra |

+---------------------+------------------+------+-----+---------+-------+

| ipc_ip              | int(10) unsigned |      | PRI | 0       |       |

| ipc_fqdn            | varchar(50)      | YES  |     | NULL    |       |

| ipc_dns_timestamp   | datetime         | YES  |     | NULL    |       |

| ipc_whois           | text             | YES  |     | NULL    |       |

| ipc_whois_timestamp | datetime         | YES  |     | NULL    |       |

+---------------------+------------------+------+-----+---------+-------+

A.1.1.3 data
+--------------+------------------+------+-----+---------+-------+

| Field        | Type             | Null | Key | Default | Extra |

+--------------+------------------+------+-----+---------+-------+

| sid          | int(10) unsigned |      | PRI | 0       |       |

| cid          | int(10) unsigned |      | PRI | 0       |       |

| data_payload | text             | YES  |     | NULL    |       |

+--------------+------------------+------+-----+---------+-------+

A.1.1.4 detail
+-------------+---------------------+------+-----+---------+-------+

| Field       | Type                | Null | Key | Default | Extra |

+-------------+---------------------+------+-----+---------+-------+

| detail_type | tinyint(3) unsigned |      | PRI | 0       |       |

| detail_text | text                |      |     |         |       |

+-------------+---------------------+------+-----+---------+-------+

A.1.1.5 encoding
+---------------+---------------------+------+-----+---------+-------+

| Field         | Type                | Null | Key | Default | Extra |

+---------------+---------------------+------+-----+---------+-------+

| encoding_type | tinyint(3) unsigned |      | PRI | 0       |       |

| encoding_text | text                |      |     |         |       |

+---------------+---------------------+------+-----+---------+-------+

A.1.1.6 event
+-----------+------------------+------+-----+---------------------+-------+

| Field     | Type             | Null | Key | Default             | Extra |

+-----------+------------------+------+-----+---------------------+-------+

| sid       | int(10) unsigned |      | PRI | 0                   |       |

| cid       | int(10) unsigned |      | PRI | 0                   |       |

| signature | int(10) unsigned |      | MUL | 0                   |       |

| timestamp | datetime         |      | MUL | 0000-00-00 00:00:00 |       |

+-----------+------------------+------+-----+---------------------+-------+

A.1.1.7 icmphdr
+-----------+----------------------+------+-----+---------+-------+

| Field     | Type                 | Null | Key | Default | Extra |

+-----------+----------------------+------+-----+---------+-------+

| sid       | int(10) unsigned     |      | PRI | 0       |       |

| cid       | int(10) unsigned     |      | PRI | 0       |       |

| icmp_type | tinyint(3) unsigned  |      | MUL | 0       |       |

| icmp_code | tinyint(3) unsigned  |      |     | 0       |       |

| icmp_csum | smallint(5) unsigned | YES  |     | NULL    |       |

| icmp_id   | smallint(5) unsigned | YES  |     | NULL    |       |

| icmp_seq  | smallint(5) unsigned | YES  |     | NULL    |       |

+-----------+----------------------+------+-----+---------+-------+

A.1.1.8 iphdr
+----------+----------------------+------+-----+---------+-------+

| Field    | Type                 | Null | Key | Default | Extra |

+----------+----------------------+------+-----+---------+-------+

| sid      | int(10) unsigned     |      | PRI | 0       |       |

| cid      | int(10) unsigned     |      | PRI | 0       |       |

| ip_src   | int(10) unsigned     |      | MUL | 0       |       |

| ip_dst   | int(10) unsigned     |      | MUL | 0       |       |

| ip_ver   | tinyint(3) unsigned  | YES  |     | NULL    |       |

| ip_hlen  | tinyint(3) unsigned  | YES  |     | NULL    |       |

| ip_tos   | tinyint(3) unsigned  | YES  |     | NULL    |       |

| ip_len   | smallint(5) unsigned | YES  |     | NULL    |       |

| ip_id    | smallint(5) unsigned | YES  |     | NULL    |       |

| ip_flags | tinyint(3) unsigned  | YES  |     | NULL    |       |

| ip_off   | smallint(5) unsigned | YES  |     | NULL    |       |

| ip_ttl   | tinyint(3) unsigned  | YES  |     | NULL    |       |

| ip_proto | tinyint(3) unsigned  |      |     | 0       |       |

| ip_csum  | smallint(5) unsigned | YES  |     | NULL    |       |

+----------+----------------------+------+-----+---------+-------+

A.1.1.9 opt
+-----------+---------------------+------+-----+---------+-------+

| Field     | Type                | Null | Key | Default | Extra |

+-----------+---------------------+------+-----+---------+-------+

| sid       | int(10) unsigned    |      | PRI | 0       |       |

| cid       | int(10) unsigned    |      | PRI | 0       |       |

| optid     | int(10) unsigned    |      | PRI | 0       |       |

| opt_proto | tinyint(3) unsigned |      |     | 0       |       |

| opt_code  | tinyint(3) unsigned |      |     | 0       |       |

| opt_len   | smallint(6)         | YES  |     | NULL    |       |

| opt_data  | text                | YES  |     | NULL    |       |

+-----------+---------------------+------+-----+---------+-------+

A.1.1.10 reference
+---------------+------------------+------+-----+---------+----------------+

| Field         | Type             | Null | Key | Default | Extra          |

+---------------+------------------+------+-----+---------+----------------+

| ref_id        | int(10) unsigned |      | PRI | NULL    | auto_increment |

| ref_system_id | int(10) unsigned |      |     | 0       |                |

| ref_tag       | text             |      |     |         |                |

+---------------+------------------+------+-----+---------+----------------+

A.1.1.11 reference_system
+-----------------+------------------+------+-----+---------+----------------+

| Field           | Type             | Null | Key | Default | Extra          |

+-----------------+------------------+------+-----+---------+----------------+

| ref_system_id   | int(10) unsigned |      | PRI | NULL    | auto_increment |

| ref_system_name | varchar(20)      | YES  |     | NULL    |                |

+-----------------+------------------+------+-----+---------+----------------+

A.1.1.12 schema
+-------+------------------+------+-----+---------------------+-------+

| Field | Type             | Null | Key | Default             | Extra |

+-------+------------------+------+-----+---------------------+-------+

| vseq  | int(10) unsigned |      | PRI | 0                   |       |

| ctime | datetime         |      |     | 0000-00-00 00:00:00 |       |

+-------+------------------+------+-----+---------------------+-------+

A.1.1.13 sensor
+-----------+------------------+------+-----+---------+----------------+

| Field     | Type             | Null | Key | Default | Extra          |

+-----------+------------------+------+-----+---------+----------------+

| sid       | int(10) unsigned |      | PRI | NULL    | auto_increment |

| hostname  | text             | YES  |     | NULL    |                |

| interface | text             | YES  |     | NULL    |                |

| filter    | text             | YES  |     | NULL    |                |

| detail    | tinyint(4)       | YES  |     | NULL    |                |

| encoding  | tinyint(4)       | YES  |     | NULL    |                |

| last_cid  | int(10) unsigned |      |     | 0       |                |

+-----------+------------------+------+-----+---------+----------------+

A.1.1.14 sig_class
+----------------+------------------+------+-----+---------+----------------+

| Field          | Type             | Null | Key | Default | Extra          |

+----------------+------------------+------+-----+---------+----------------+

| sig_class_id   | int(10) unsigned |      | PRI | NULL    | auto_increment |

| sig_class_name | varchar(60)      |      | MUL |         |                |

+----------------+------------------+------+-----+---------+----------------+

A.1.1.15 sig_reference
+---------+------------------+------+-----+---------+-------+

| Field   | Type             | Null | Key | Default | Extra |

+---------+------------------+------+-----+---------+-------+

| sig_id  | int(10) unsigned |      | PRI | 0       |       |

| ref_seq | int(10) unsigned |      | PRI | 0       |       |

| ref_id  | int(10) unsigned |      |     | 0       |       |

+---------+------------------+------+-----+---------+-------+

A.1.1.16 signature
+--------------+------------------+------+-----+---------+----------------+

| Field        | Type             | Null | Key | Default | Extra          |

+--------------+------------------+------+-----+---------+----------------+

| sig_id       | int(10) unsigned |      | PRI | NULL    | auto_increment |

| sig_name     | varchar(255)     |      | MUL |         |                |

| sig_class_id | int(10) unsigned |      | MUL | 0       |                |

| sig_priority | int(10) unsigned | YES  |     | NULL    |                |

| sig_rev      | int(10) unsigned | YES  |     | NULL    |                |

| sig_sid      | int(10) unsigned | YES  |     | NULL    |                |

+--------------+------------------+------+-----+---------+----------------+

A.1.1.17 tcphdr
+-----------+----------------------+------+-----+---------+-------+

| Field     | Type                 | Null | Key | Default | Extra |

+-----------+----------------------+------+-----+---------+-------+

| sid       | int(10) unsigned     |      | PRI | 0       |       |

| cid       | int(10) unsigned     |      | PRI | 0       |       |

| tcp_sport | smallint(5) unsigned |      | MUL | 0       |       |

| tcp_dport | smallint(5) unsigned |      | MUL | 0       |       |

| tcp_seq   | int(10) unsigned     | YES  |     | NULL    |       |

| tcp_ack   | int(10) unsigned     | YES  |     | NULL    |       |

| tcp_off   | tinyint(3) unsigned  | YES  |     | NULL    |       |

| tcp_res   | tinyint(3) unsigned  | YES  |     | NULL    |       |

| tcp_flags | tinyint(3) unsigned  |      | MUL | 0       |       |

| tcp_win   | smallint(5) unsigned | YES  |     | NULL    |       |

| tcp_csum  | smallint(5) unsigned | YES  |     | NULL    |       |

| tcp_urp   | smallint(5) unsigned | YES  |     | NULL    |       |

+-----------+----------------------+------+-----+---------+-------+

A.1.1.18 udphdr
+-----------+----------------------+------+-----+---------+-------+

| Field     | Type                 | Null | Key | Default | Extra |

+-----------+----------------------+------+-----+---------+-------+

| sid       | int(10) unsigned     |      | PRI | 0       |       |

| cid       | int(10) unsigned     |      | PRI | 0       |       |

| udp_sport | smallint(5) unsigned |      | MUL | 0       |       |

| udp_dport | smallint(5) unsigned |      | MUL | 0       |       |

| udp_len   | smallint(5) unsigned | YES  |     | NULL    |       |

| udp_csum  | smallint(5) unsigned | YES  |     | NULL    |       |

+-----------+----------------------+------+-----+---------+-------+


Appendix B. The Default snort.conf File

#--------------------------------------------------

#   http://www.snort.org     Snort 2.1.2 Ruleset

#     Contact: snort-sigs@lists.sourceforge.net

#--------------------------------------------------

#  $ Id: snort.conf,v 1.333.2.3 2004/02/25 16:52:51 jh8 Exp  $

#

###################################################

# This file contains a sample snort configuration.

# You can take the following steps to create your own custom configuration:

#

#  1) Set the network variables for your network

#  2) Configure preprocessors

#  3) Configure output plugins

#  4) Customize your rule set

#

###################################################

# Step #1: Set the network variables:

#

# You must change the following variables to reflect your local network. The

# variable is currently setup for an RFC 1918 address space.

#

# You can specify it explicitly as:

#

# var HOME_NET 10.1.1.0/24

#

# or use global variable $<interfacename>_ADDRESS which will be always

# initialized to IP address and netmask of the network interface which you run

# snort at.  Under Windows, this must be specified as

# $(<interfacename>_ADDRESS), such as:

# $(\Device\Packet_{12345678-90AB-CDEF-1234567890AB}_ADDRESS)

#

# var HOME_NET $eth0_ADDRESS

#

# You can specify lists of IP addresses for HOME_NET

# by separating the IPs with commas like this:

#

# var HOME_NET [10.1.1.0/24,192.168.1.0/24]

#

# MAKE SURE YOU DON'T PLACE ANY SPACES IN YOUR LIST!

#

# or you can specify the variable to be any IP address

# like this:

var HOME_NET any

# Set up the external network addresses as well.  A good start may be "any"

var EXTERNAL_NET any

# Configure your server lists.  This allows snort to only look for attacks to

# systems that have a service up.  Why look for HTTP attacks if you are not

# running a web server?  This allows quick filtering based on IP addresses

# These configurations MUST follow the same configuration scheme as defined

# above for $HOME_NET.

# List of DNS servers on your network

var DNS_SERVERS $HOME_NET

# List of SMTP servers on your network

var SMTP_SERVERS $HOME_NET

# List of web servers on your network

var HTTP_SERVERS $HOME_NET

# List of sql servers on your network

var SQL_SERVERS $HOME_NET

# List of telnet servers on your network

var TELNET_SERVERS $HOME_NET

# List of snmp servers on your network

var SNMP_SERVERS $HOME_NET

# Configure your service ports.  This allows snort to look for attacks destined

# to a specific application only on the ports that application runs on.  For

# example, if you run a web server on port 8081, set your HTTP_PORTS variable

# like this:

#

# var HTTP_PORTS 8081

#

# Port lists must either be continuous [eg 80:8080], or a single port [eg 80].

# We will adding support for a real list of ports in the future.

# Ports you run web servers on

#

# Please note:  [80,8080] does not work.

# If you wish to define multiple HTTP ports,

#

## var HTTP_PORTS 80

## include somefile.rules

## var HTTP_PORTS 8080

## include somefile.rules

var HTTP_PORTS 80

# Ports you want to look for SHELLCODE on.

var SHELLCODE_PORTS !80

# Ports you do oracle attacks on

var ORACLE_PORTS 1521

# other variables

#

# AIM servers.  AOL has a habit of adding new AIM servers, so instead of

# modifying the signatures when they do, we add them to this list of servers.

var AIM_SERVERS # [64.12.24.0/24,64.12.25.0/24,64.12.26.14/24,64.12.28.0/24,64.12.29.0/

24,64.12.161.0/24,64.12.163.0/24,205.188.5.0/24,205.188.9.0/24]

# Path to your rules files (this can be a relative path)

var RULE_PATH ../rules

# Configure the snort decoder

# ============================

#

# Snort's decoder will alert on lots of things such as header

# truncation or options of unusual length or infrequently used tcp options

#

#

# Stop generic decode events:

#

# config disable_decode_alerts

#

# Stop Alerts on experimental TCP options

#

# config disable_tcpopt_experimental_alerts

#

# Stop Alerts on obsolete TCP options

#

# config disable_tcpopt_obsolete_alerts

#

# Stop Alerts on T/TCP alerts

#

# In snort 2.0.1 and above, this only alerts when a TCP option is detected

# that shows T/TCP being actively used on the network.  If this is normal

# behavior for your network, disable the next option.

#

# config disable_tcpopt_ttcp_alerts

#

# Stop Alerts on all other TCPOption type events:

#

# config disable_tcpopt_alerts

#

# Stop Alerts on invalid ip options

#

# config disable_ipopt_alerts

# Configure the detection engine

# ===============================

#

# Use a different pattern matcher in case you have a machine with very limited

# resources:

#

# config detection: search-method lowmem

###################################################

# Step #2: Configure preprocessors

#

# General configuration for preprocessors is of

# the form

# preprocessor <name_of_processor>: <configuration_options>

# Configure Flow tracking module

# -------------------------------

#

# The Flow tracking module is meant to start unifying the state keeping

# mechanisms of snort into a single place. Right now, only a portscan detector

# is implemented but in the long term,  many of the stateful subsystems of

# snort will be migrated over to becoming flow plugins. This must be enabled

# for flow-portscan to work correctly.

#

# See README.flow for additional information

#

preprocessor flow: stats_interval 0 hash 2

# frag2: IP defragmentation support

# -------------------------------

# This preprocessor performs IP defragmentation.  This plugin will also detect

# people launching fragmentation attacks (usually DoS) against hosts.  No

# arguments loads the default configuration of the preprocessor, which is a 60

# second timeout and a 4MB fragment buffer.

# The following (comma delimited) options are available for frag2

#    timeout [seconds] - sets the number of [seconds] that an unfinished

#                        fragment will be kept around waiting for completion,

#                        if this time expires the fragment will be flushed

#    memcap [bytes] - limit frag2 memory usage to [number] bytes

#                      (default:  4194304)

#

#    min_ttl [number] - minimum ttl to accept

#

#    ttl_limit [number] - difference of ttl to accept without alerting

#                         will cause false positves with router flap

#

# Frag2 uses Generator ID 113 and uses the following SIDS

# for that GID:

#  SID     Event description

# -----   -------------------

#   1       Oversized fragment (reassembled frag > 64k bytes)

#   2       Teardrop-type attack

preprocessor frag2

# stream4: stateful inspection/stream reassembly for Snort

#----------------------------------------------------------------------

# Use in concert with the -z [all|est] command line switch to defeat stick/snot

# against TCP rules.  Also performs full TCP stream reassembly, stateful

# inspection of TCP streams, etc.  Can statefully detect various portscan

# types, fingerprinting, ECN, etc.

# stateful inspection directive

# no arguments loads the defaults (timeout 30, memcap 8388608)

# options (options are comma delimited):

#   detect_scans - stream4 will detect stealth portscans and generate alerts

#                  when it sees them when this option is set

#   detect_state_problems - detect TCP state problems, this tends to be very

#                           noisy because there are a lot of crappy ip stack

#                           implementations out there

#

#   disable_evasion_alerts - turn off the possibly noisy mitigation of

#                            overlapping sequences.

#

#

#   min_ttl [number]       - set a minium ttl that snort will accept to

#                            stream reassembly

#

#   ttl_limit [number]     - differential of the initial ttl on a session versus

#                             the normal that someone may be playing games.

#                             Routing flap may cause lots of false positives.

#

#   keepstats [machine|binary] - keep session statistics, add "machine" to

#                         get them in a flat format for machine reading, add

#                         "binary" to get them in a unified binary output

#                         format

#   noinspect - turn off stateful inspection only

#   timeout [number] - set the session timeout counter to [number] seconds,

#                      default is 30 seconds

#   memcap [number] - limit stream4 memory usage to [number] bytes

#   log_flushed_streams - if an event is detected on a stream this option will

#                         cause all packets that are stored in the stream4

#                         packet buffers to be flushed to disk.  This only

#                         works when logging in pcap mode!

#

# Stream4 uses Generator ID 111 and uses the following SIDS

# for that GID:

#  SID     Event description

# -----   -------------------

#   1       Stealth activity

#   2       Evasive RST packet

#   3       Evasive TCP packet retransmission

#   4       TCP Window violation

#   5       Data on SYN packet

#   6       Stealth scan: full XMAS

#   7       Stealth scan: SYN-ACK-PSH-URG

#   8       Stealth scan: FIN scan

#   9       Stealth scan: NULL scan

#   10      Stealth scan: NMAP XMAS scan

#   11      Stealth scan: Vecna scan

#   12      Stealth scan: NMAP fingerprint scan stateful detect

#   13      Stealth scan: SYN-FIN scan

#   14      TCP forward overlap

preprocessor stream4: disable_evasion_alerts

# tcp stream reassembly directive

# no arguments loads the default configuration

#   Only reassemble the client,

#   Only reassemble the default list of ports (See below),

#   Give alerts for "bad" streams

#

# Available options (comma delimited):

#   clientonly - reassemble traffic for the client side of a connection only

#   serveronly - reassemble traffic for the server side of a connection only

#   both - reassemble both sides of a session

#   noalerts - turn off alerts from the stream reassembly stage of stream4

#   ports [list] - use the space separated list of ports in [list], "all"

#                  will turn on reassembly for all ports, "default" will turn

#                  on reassembly for ports 21, 23, 25, 53, 80, 143, 110, 111

#                  and 513

preprocessor stream4_reassemble

# http_inspect: normalize and detect HTTP traffic and protocol anomalies

#

# lots of options available here. See doc/README.http_inspect.

# unicode.map should be wherever your snort.conf lives, or given

# a full path to where snort can find it.

preprocessor http_inspect: global \

    iis_unicode_map unicode.map 1252

preprocessor http_inspect_server: server default \

    profile all ports { 80 8080 8180 } oversize_dir_length 500

#

#  Example unique server configuration

#

#preprocessor http_inspect_server: server 1.1.1.1 \

#    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 \

#    no_alerts

# rpc_decode: normalize RPC traffic

# ---------------------------------

# RPC may be sent in alternate encodings besides the usual 4-byte encoding

# that is used by default. This plugin takes the port numbers that RPC

# services are running on as arguments - it is assumed that the given ports

# are actually running this type of service. If not, change the ports or turn

# it off.

# The RPC decode preprocessor uses generator ID 106

#

# arguments: space separated list

# alert_fragments - alert on any rpc fragmented TCP data

# no_alert_multiple_requests - don't alert when >1 rpc query is in a packet

# no_alert_large_fragments - don't alert when the fragmented

#                            sizes exceed the current packet size

# no_alert_incomplete - don't alert when a single segment

#                       exceeds the current packet size

preprocessor rpc_decode: 111 32771

# bo: Back Orifice detector

# -------------------------

# Detects Back Orifice traffic on the network.  Takes no arguments in 2.0.

#

# The Back Orifice detector uses Generator ID 105 and uses the

# following SIDS for that GID:

#  SID     Event description

# -----   -------------------

#   1       Back Orifice traffic detected

preprocessor bo

# telnet_decode: Telnet negotiation string normalizer

# ---------------------------------------------------

# This preprocessor "normalizes" telnet negotiation strings from telnet and ftp

# traffic.  It works in much the same way as the http_decode preprocessor,

# searching for traffic that breaks up the normal data stream of a protocol and

# replacing it with a normalized representation of that traffic so that the

# "content" pattern matching keyword can work without requiring modifications.

# This preprocessor requires no arguments.

# Portscan uses Generator ID 109 and does not generate any SID currently.

preprocessor telnet_decode

# Flow-Portscan: detect a variety of portscans

# ---------------------------------------

# Note:  The Flow preprocessor (above) must first be enabled for Flow-Portscan to

# work.

#

# This module detects portscans based off of flow creation in the flow

# preprocessors.  The goal is to catch catch one->many hosts and one->many

# ports scans.

#

# Flow-Portscan has numerous options available, please read

# README.flow-portscan for help configuring this option.

# Flow-Portscan uses Generator ID 121 and uses the following SIDS for that GID:

#  SID     Event description

# -----   -------------------

#   1       flow-portscan: Fixed Scale Scanner Limit Exceeded

#   2       flow-portscan: Sliding Scale Scanner Limit Exceeded

#   3       flow-portscan: Fixed Scale Talker Limit Exceeded

#   4       flow-portscan: Sliding Scale Talker Limit Exceeded

# preprocessor flow-portscan: \

#       talker-sliding-scale-factor 0.50 \

#       talker-fixed-threshold 30 \

#       talker-sliding-threshold 30 \

#       talker-sliding-window 20 \

#       talker-fixed-window 30 \

#       scoreboard-rows-talker 30000 \

#       server-watchnet [10.2.0.0/30] \

#       server-ignore-limit 200 \

#       server-rows 65535 \

#       server-learning-time 14400 \

#       server-scanner-limit 4 \

#       scanner-sliding-window 20 \

#       scanner-sliding-scale-factor 0.50 \

#       scanner-fixed-threshold 15 \

#       scanner-sliding-threshold 40 \

#       scanner-fixed-window 15 \

#       scoreboard-rows-scanner 30000 \

#       src-ignore-net [192.168.1.1/32,192.168.0.0/24] \

#       dst-ignore-net [10.0.0.0/30] \

#       alert-mode once \

#       output-mode msg \

#       tcp-penalties on

# arpspoof

#----------------------------------------

# Experimental ARP detection code from Jeff Nathan, detects ARP attacks,

# unicast ARP requests, and specific ARP mapping monitoring.  To make use of

# this preprocessor you must specify the IP and hardware address of hosts on

# the same layer 2 segment as you.  Specify one host IP MAC combo per line.

# Also takes a "-unicast" option to turn on unicast ARP request detection.

# Arpspoof uses Generator ID 112 and uses the following SIDS for that GID:

#  SID     Event description

# -----   -------------------

#   1       Unicast ARP request

#   2       Etherframe ARP mismatch (src)

#   3       Etherframe ARP mismatch (dst)

#   4       ARP cache overwrite attack

#preprocessor arpspoof

#preprocessor arpspoof_detect_host: 192.168.40.1 f0:0f:00:f0:0f:00

# Performance Statistics

# ----------------------

# Documentation for this is provided in the Snort Manual.  You should read it.

# It is included in the release distribution as doc/snort_manual.pdf

#

# preprocessor perfmonitor: time 300 file /var/snort/snort.stats pktcnt 10000

####################################################################

# Step #3: Configure output plugins

#

# Uncomment and configure the output plugins you decide to use.  General

# configuration for output plugins is of the form:

#

# output <name_of_plugin>: <configuration_options>

#

# alert_syslog: log alerts to syslog

# ----------------------------------

# Use one or more syslog facilities as arguments.  Win32 can also optionally

# specify a particular hostname/port.  Under Win32, the default hostname is

# '127.0.0.1', and the default port is 514.

#

# [Unix flavours should use this format...]

# output alert_syslog: LOG_AUTH LOG_ALERT

#

# [Win32 can use any of these formats...]

# output alert_syslog: LOG_AUTH LOG_ALERT

# output alert_syslog: host=hostname, LOG_AUTH LOG_ALERT

# output alert_syslog: host=hostname:port, LOG_AUTH LOG_ALERT

# log_tcpdump: log packets in binary tcpdump format

# -------------------------------------------------

# The only argument is the output file name.

#

# output log_tcpdump: tcpdump.log

# database: log to a variety of databases

# ---------------------------------------

# See the README.database file for more information about configuring

# and using this plugin.

#

# output database: log, mysql, user=root password=test dbname=db host=localhost

# output database: alert, postgresql, user=snort dbname=snort

# output database: log, odbc, user=snort dbname=snort

# output database: log, mssql, dbname=snort user=snort password=test

# output database: log, oracle, dbname=snort user=snort password=test

# unified: Snort unified binary format alerting and logging

# -------------------------------------------------------------

# The unified output plugin provides two new formats for logging and generating

# alerts from Snort, the "unified" format.  The unified format is a straight

# binary format for logging data out of Snort that is designed to be fast and

# efficient.  Used with barnyard (the new alert/log processor), most of the

# overhead for logging and alerting to various slow storage mechanisms such as

# databases or the network can now be avoided.

#

# Check out the spo_unified.h file for the data formats.

#

# Two arguments are supported.

#    filename - base filename to write to (current time_t is appended)

#    limit    - maximum size of spool file in MB (default: 128)

#

# output alert_unified: filename snort.alert, limit 128

# output log_unified: filename snort.log, limit 128

# You can optionally define new rule types and associate one or more output

# plugins specifically to that type.

#

# This example will create a type that will log to just tcpdump.

# ruletype suspicious

# {

#   type log

#   output log_tcpdump: suspicious.log

# }

#

# EXAMPLE RULE FOR SUSPICIOUS RULETYPE:

# suspicious tcp $HOME_NET any -> $HOME_NET 6667 (msg:"Internal IRC Server";)

#

# This example will create a rule type that will log to syslog and a mysql

# database:

# ruletype redalert

# {

#   type alert

#   output alert_syslog: LOG_AUTH LOG_ALERT

#   output database: log, mysql, user=snort dbname=snort host=localhost

# }

#

# EXAMPLE RULE FOR REDALERT RULETYPE:

# redalert tcp $HOME_NET any -> $EXTERNAL_NET 31337 \

#   (msg:"Someone is being LEET"; flags:A+;)

#

# Include classification & priority settings

#

include classification.config

#

# Include reference systems

#

include reference.config

####################################################################

# Step #4: Customize your rule set

#

# Up to date snort rules are available at http://www.snort.org

#

# The snort web site has documentation about how to write your own custom snort

# rules.

#

# The rules included with this distribution generate alerts based on on

# suspicious activity. Depending on your network environment, your security

# policies, and what you consider to be suspicious, some of these rules may

# either generate false positives ore may be detecting activity you consider to

# be acceptable; therefore, you are encouraged to comment out rules that are

# not applicable in your environment.

#

# The following individuals contributed many of rules in this distribution.

#

# Credits:

#   Ron Gula <rgula@securitywizards.com> of Network Security Wizards

#   Max Vision <vision@whitehats.com>

#   Martin Markgraf <martin@mail.du.gtn.com>

#   Fyodor Yarochkin <fygrave@tigerteam.net>

#   Nick Rogness <nick@rapidnet.com>

#   Jim Forster <jforster@rapidnet.com>

#   Scott McIntyre <scott@whoi.edu>

#   Tom Vandepoel <Tom.Vandepoel@ubizen.com>

#   Brian Caswell <bmc@snort.org>

#   Zeno <admin@cgisecurity.com>

#   Ryan Russell <ryan@securityfocus.com>

#=========================================

# Include all relevant rulesets here

#

# The following rulesets are disabled by default:

#

#   web-attacks, backdoor, shellcode, policy, porn, info, icmp-info, virus,

#   chat, multimedia, and p2p

#

# These rules are either site policy specific or require tuning in order to not

# generate false positive alerts in most enviornments.

#

# Please read the specific include file for more information and

# README.alert_order for how rule ordering affects how alerts are triggered.

#=========================================

include $RULE_PATH/local.rules

include $RULE_PATH/bad-traffic.rules

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.rules

include $RULE_PATH/web-iis.rules

include $RULE_PATH/web-frontpage.rules

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.rules

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/web-attacks.rules

# include $RULE_PATH/backdoor.rules

# include $RULE_PATH/shellcode.rules

# include $RULE_PATH/policy.rules

# include $RULE_PATH/porn.rules

# include $RULE_PATH/info.rules

# include $RULE_PATH/icmp-info.rules

# include $RULE_PATH/virus.rules

# include $RULE_PATH/chat.rules

# include $RULE_PATH/multimedia.rules

# include $RULE_PATH/p2p.rules

include $RULE_PATH/experimental.rules

# Include any thresholding or suppression commands. See threshold.conf in the

# <snort src>/etc directory for details. Commands don't necessarily need to be

# contained in this conf, but a separate conf makes it easier to maintain them.

# Uncomment if needed.

# include threshold.conf


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 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 Management

    Section C.9. From Chapter 13: Strategies for High-Bandwidth Implementations of Snort


C.1 From Chapter 1: Introduction

Snort's homepage | http://www.snort.org
SecurityFocus IDS Page | http://www.securityfocus.com/ids
The SANS Institute | http://www.sans.org
CERT homepage | http://www.cert.org
The NSA Security Guides | http://www.nsa.gov/snac/index.cfm
tcpdump homepage | http://www.tcpdump.org
Ethereal homepage | http://www.ethereal.com


C.2 From Chapter 2: Network Traffic Analysis

Ethereal | http://www.ethereal.com
libpcap | http://www.tcpdump.org
libpcap tutorial | http://www.cet.nau.edu/~mc8/Socket/Tutorials/section1.html
Packetyzer | http://www.networkchemistry.com/products/packetyzer/
Pcap tutorial | http://www.tcpdump.org/pcap.htm
Sans TCP/IP Guide | http://www.sans.org/resources/tcpip.pdf
tcpdump | http://www.tcpdump.org
Tethereal | http://www.ethereal.com
WinDump | http://windump.polito.it
WinPcap | http://winpcap.polito.it


C.3 From Chapter 4: Know Your Enemy

Broadband Reports | http://www.dslreports.com/scan
CERT | http://www.cert.org
Cryptcat | http://sourceforge.net/projects/cryptcat/
DoS Help | http://www.doshelp.com/dostest.htm
Firewalk | http://www.packetfactory.net/projects/firewalk/
fragroute | http://www.monkey.org/~dugsong/fragroute/
hping | http://www.hping.org
ID Serve | http://grc.com/id/idserve.htm
IEEE OUI and Company_id Assignments | http://standards.ieee.org/regauth/oui/index.shtml
IP Calculator / IP Subnetting | http://jodies.de/ipcalc/
IP-Tools | http://www.ks-soft.net/ip-tools.eng/
ISECOM Security Tools | http://www.ideahamster.org/projects/operationaltools.htm
John the Ripper | http://www.openwall.com/john/
L0phtCrack LC4 | http://www.atstake.com/research/lc/
libevent | http://www.monkey.org/~provos/libevent/
LibWhisker | http://www.wiretrip.net/rfp/lw.asp
Netcat | http://www.atstake.com/research/tools/network_utilities/
GNU Netcat | http://netcat.sourceforge.net
Nessus | http://www.nessus.org
Nikto | http://www.cirt.net/code/nikto.shtml
Nmap | http://www.insecure.org/nmap
The Packetfactory | http://www.packetfactory.net
Packetstromsecurity | http://packetstormsecurity.nl
Tenable Security | http://www.tenablesecurity.com
Razor Security | http://razor.bindview.com
Reverse WWW Shell | http://www.megasecurity.org/Sources/rwwwshell-1_6_perl.txt
Sam Spade | http://www.samspade.org
SANS | http://www.sans.org
SecurityFocus | http://www.securityfocus.com/
SNMPwalk | http://www.ece.ucdavis.edu/ucd-snmp/
Snot | http://www.stolenshoes.net/sniph/index.html
SSL Proxy | http://www.obdev.at/products/ssl-proxy/index.html
Stick | http://www.eurocompton.net/stick/projects8.html
Virusdot.org | http://www.governmentsecurity.org/articles/DefaultLoginsandPasswordsforNetworkedDevices.php
Whisker+SSL | http://www.digitaloffense.net


C.4 From Chapter 6: Deploying Snort

Guide to Hardening Linux | http://www.antioffline.com/deviation/linux.html
Guide to Hardening BSD | http://www.antioffline.com/deviation/bsd.html
Apache 1.3 Security Tips | http://httpd.apache.org/docs/misc/security_tips.html
Apache 2.0 Security Tips | http://httpd.apache.org/docs-2.0/misc/security_tips.html
MySQL Security Tips | http://dev.mysql.com/doc/mysql/en/Security.html
NSA Secure Configuration Guides | http://www.nsa.gov/snac/index.cfm?MenuID=scg10.3.1
Microsoft Central Security Portal | http://www.microsoft.com/technet/security


C.5 From Chapter 7: Creating and Managing Snort Rules

Snort-sigs mailing list | http://lists.sourceforge.net/lists/listinfo/snort-sigs
CERT | http://www.cert.org
SANS | http://www.sans.org
Oinkmaster | http://oinkmaster.sf.net/oinkmaster/
IDSPolMan | http://www.activeworx.com
SnortCenter | http://users.pandora.be/larc/


C.6 From Chapter 8: Intrusion Prevention

The HoneyNet Project | http://project.honeynet.org
libnet | http://www.packetfactory.net/libnet
SnortSAM | http://www.snortsam.net
Snort Inline Patch | http://snort-inline.sourceforge.net


C.7 From Chapter 10: Using ACID as a Snort IDS Management Console

MySQL Database Server | http://www.mysql.com
Apache Web Server | http://httpd.apache.org
IDServe Web Server Identification Tool | http://grc.com/id/idserve.htm
ACID IDS Management Console | http://acidlab.sourceforge.net
PHP Hypertext Preprocessor | http://www.php.net
Installation guide for RedHat 9 | http://www.snort.org/docs/snort_acid_rh9.pdf
Installation guide for Solaris 9 | http://www.snort.org/docs/snort-acid_solaris9.pdf
Installation guide for FreeBSD | http://www.snort.org/docs/FreeBSD47RELEASE-Snort-MySQLVer1-3.pdf


C.8 From Chapter 12: Additional Tools for Snort IDS Management

SnortReport | http://www.circuitsmaximus.com
SnortSnarf | http://www.silicondefense.com
Cerebus | http://dragos.com/cerebus
IDS Policy Manager | http://www.activeworx.com/idspm/
Oinkmaster | http://www.oinkmaster.sourceforge.net
Applied Watch | http://www.appliedwatch.com
PureSecure Console | http://www.demarc.com/products/puresecure
PureSecure Personal Console | http://www.demarc.com/downloads/PureSecure/personal/
Sourcefire | http://www.sourcefire.com


C.9 From Chapter 13: Strategies for High-Bandwidth Implementations of Snort

Barnyard | http://sourceforge.net/projects/barnyard/
sguil | http://sguil.sourceforge.net
The Layer 2 Cross-Connect |


Day Day Up

Colophon

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 subjects.

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 19th-century 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.


index

[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]


index_SYMBOL

[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


index_A

[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 Detection)
Alert Group (AG) maintenance
alert information
Alert Listing page
analyzing captured data
Apache [See Apache, installing and configuring]
confirming GD support
console
accessing
browsing
installing
ongoing utilization of
customizing configuration files
database
sending alert information to (barnyard.conf)
sending log information to (barnyard.conf)
database schema
GD and
Graph Alert Data link 2nd
Graph alert detection time
homepage
identifying known attacks
IDS Management Console
initializing web page
installing and configuring
main interface
MySQL [See MySQL, installing and configuring]
notifying offender
on-the-fly graphing
overview
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
Snapshot
summary of dependencies for components
tracking alerts
typical packet capture
using
view only portal
viewing packets
acid_ag table
acid_ag_alert table
acid_conf.php file
acid_event table
acid_ip_cache table
ACK
ack: rule option
acknowledgment (ACK)
Action field (rule headers)
Address Resolution Protocol (ARP)
ADODB
AIM_SERVERS variable (snort.conf)
alert file
alert-mode option (flow-portscan preprocessor)
alert_fragments option (rpc_decode preprocessor)
alert_syslog plug-in
alert_with_interface_name option (snort.conf)
alertfile: alerts option (snort.conf)
alerts
checking
checking machines generating
controlling number of
discounting
generated by Snort
logging
modes
throttling technique
unreachable destination
allow_proxy_use option (http_inspect_server)
antivirus software versus signature-based IDS
Apache
changing User and Group variables
compiling code from source
displaying static files in empty root directory
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 files
Version 2.0 Security Tips
Version1.3 Security Tips
web daemon, automating startup
web page
web server
disabling rule set
apache_whitespace option (http_inspect_server)
APNIC
application behavior boundary flaws
Applied Watch
Console
Applied Watch Technologies
archiving logged Snort packets
ARIN
ARP (Address Resolution Protocol)
arpspoof preprocessor
ascii option (http_inspect_server)
ASCII packet dump mode
attack-responses.rules
attack_responses.rules rule set
attackers
disgruntled employees
opportunists
professionals
robots
techniques
thieves
using fragmentation
vandals
viruses
worms
attacks
anatomy of
paralyze
penetrate [See penetrate attack phase]
persist
probe [See probe attack phase]
propogate
denial-of-service [See denial-of-service attacks]
detecting latest methods
familiarizing yourself on different
IDS evasion
attempted-recon signature
authentication
biometric
robust
authentication grinding


index_B

[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
backdoor.rules
bad-traffic.rules
bare_byte option (http_inspect_server)
Barnyard 2nd
command-line options
configuring [See barnyard.conf file]
installing
overview
running in background
barnyard.conf file
declarations section
output plug-ins section
base-score option (flow-portscan preprocessor)
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 generate
bo preprocessor
both option (stream4_reassemble preprocessor)
boundary flaws, application behavior
bpf_file: filters.bpf option (snort.conf)
Broadband Reports
broadcasts
buffer overflows
build-time options when installing Snort


index_C

[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
homepage
certificates
secure
test
CGI services, detecting attacks to
change management, poor
character data, printing
chat protocols, detecting
chat.rules
Checkpoint Firewall-1 and SnortSAM
checksum_mode : option (snort.conf)
chroot: option (snort.conf)
chunk_length option (http_inspect_server)
Cisco
Catalyst 3550
PIX Firewall and SnortSAM
routers and SnortSAM
switches
classtype: rule option
clientonly option (stream4_reassemble preprocessor)
Code Red worm
Coldfusion
detecting attacks to services
disabling rule set
command-line options (Snort)
-?
-A alert-mode
-b
-B address-conversion-mask
-C
-c config-file
-d
-D
-e
-F bpf-file
-g group
-h home-net
-I
-i interface
-k checksum-mode
-L binary-log-file
-l logging-directory
-m umask
-N
-n packet-count
-o
-O
-p
-P snap-length
-q
-r tcpdump-file
-s
-S variable
-T
-t chroot
-U
-u user
-v
-V
-X
-y
-z
configuration file [See snort.conf file]
configuring Snort [See also snort.conf file]
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
installing
Cryptcat
Cult of the Dead Cow
curl binary, installing
current, staying


index_D

[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
parameters
database plug-in
database schema for Snort and ACID
day zero attack
ddos.rules
decode_arp option (snort.conf)
decode_data_link option (snort.conf)
decoder
configuring
detection engine configuration
tailoring
default option (http_inspect_server)
defaultkey option (snortsam.conf)
defense-in-depth
deleted.rules
Demarc
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 preprocessor)
detect_state_problems option (frag2 preprocessor)
detect_state_problems option (stream4 preprocessor)
directory option (http_inspect_server)
disable_decode_alerts option (snort.conf)
disable_evasion_alerts option (stream4 preprocessor)
disable_ipopt_alerts option (snort.conf)
disable_tcpopt_alerts option (snort.conf)
disable_tcpopt_experimental_alerts option (snort.conf)
disable_tcpopt_obsolete_alerts option (snort.conf)
disable_tcpopt_ttcp_alerts option (snort.conf)
disgruntled employees
DMZ and sensor placement
DNS servers, detecting attacks on
dns.rules
DNS_SERVERS variable (snort.conf)
dontblock option (snortsam.conf)
dos.rules
double_decode option (http_inspect_server)
download resources
drift net scans
drop rule action
DServe Web Server Identification Tool
dsize: rule option
dst-ignore-net option (flow-portscan preprocessor)
dump_chars_only option (snort.conf)
dump_payload option (snort.conf)
dump_payload_verbose option (snort.conf)
dumpall option (flow-portscan preprocessor)


index_E

[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]

encapsulation
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
homepage
installing from source
network analyzer
options
real-time packet capture session
starting
Tethereal
event table
experimental.rules
exploit beating attempted block
exploit.rules
EXTERNAL_NET variable (snort.conf)


index_F

[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
controlling
indicators
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
finger.rules
fingerprint attempts
FireProof
Firewalk 2nd
firewall
alternatives to
running Snort behind
Snort running as
flags: rule option
flexible response
keywords
icmp_all
icmp_host
icmp_net
icmp_port
rst_all
rst_rcv
rst_snd
flow control
flow preprocessor
configuring
flow-portscan preprocessor
configuring
flow_depth option (http_inspect_server)
frag2 preprocessor
configuring
options
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
ftp.rules
fwsam rule option


index_G

[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
GD and ACID
confirming support
gen_id parameter
Gigabit fiber link
GLBA
GNU Netcat
Guide to Hardening BSD
Guide to Hardening Linux
Gullet, David


index_H

[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
overview
HIPAA
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 protection
hping 2nd
http_inspect preprocessor
configuring
global options
http_inspect_server
HTTP_PORTS variable (snort.conf)
HTTP_SERVERS variable (snort.conf)
httpd.conf file


index_I

[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 Protocol)
troubleshooting network problems
icmp-info.rules
icmp.rules
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
IDS
detecting traffic generated by other
evasion
load balancers
commercial
log retention requirements
Policy Manager 2nd
signature-based versus antivirus software
stress-testing
IDS Distribution System (I(DS)2)
installing
IDS management
ACID [See ACID]
commercial tools
Applied Watch Console
PureSecure Console
Sourcefire Management Console
open source tools
Cerebus
IDS Policy Manager
Oinkmaster
SnortReport
SnortSnarf
SnortCenter [See SnortCenter]
IDs, changing after initialization 2nd
IDSPolMan 2nd
IEEE OUI and Company_id Assignments
iis_backslash option (http_inspect_server)
iis_delimeter option (http_inspect_server)
iis_Unicode option (http_inspect_server)
iis_Unicode_map option (http_inspect preprocessor)
iis_Unicode_map option (http_inspect_server)
illegal packet header settings
IMAP email service, detecting attacks to
imap.rules
implied trust
include command
include option (snortsam.conf)
info.rules
inline patch (Snort)
configuring Snort
creating rules for
downloading
inspect_uri_only option (http_inspect_server)
installing Snort
build-time options
source code installation
staying current
version
Windows installations
instant messengers, detecting
interface: option (snort.conf)
interfaces
configuring with sensors
monitoring multiple
network
promiscuous mode
Snort listens on
stealth
Internet Control Message Protocol (ICMP)
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
gateway
network, challenges of
false positives
missing prerequisites
prerequisites
unrealistic expectations
real-time
systems
intrusion prevention [See also IPS]2nd
strategies
Intrusion Prevention System [See IPS]
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 identification
iptables and SnortSAM
iptables option (snortsam.conf)
ISECOM Security Tools
itype: rule option


index_J

[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


index_K

[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)


index_L

[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
L0phtCrack LC4
LACNIC
Layer 2 Cross-Connect
Layer 2 cross-connect (MAC Munger)
libevent
libnet
libpcap
tutorial
libpcap library
LibWhisker
LibWhisker's anti-IDS methods
limit type thresholding example
Linux
ipchains and SnortSAM
iptables and SnortSAM
versus Windows when deciding which OS to use for Snort sensor
load balancers
commercial IDS
local.rules
local.rules file
log_flushed_streams option (stream4 preprocessor)
log_tcpdump plug-in
log_unified output plug-in
logdir: option (snort.conf)
logfile option (snortsam.conf)
logfiles, setting filename
logging
IDS log retention requirements
monitoring system logs
packets
binary dumps
naming files
tcpdump format
specifying directory
turning off packet
loglevel option (snortsam.conf)
logto: rule option


index_M

[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 management]
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
misc.rules
modes of operation (Snort)
msg (react response keyword)
msg: rule option
multi_slash option (http_inspect_server)
multimedia applications, detecting on network
multimedia.rules
MySQL
adding tables and permissions
cleaning house or reinstalling
creating user login that cannot delete alerts from Snort database
detecting attacks to
disabling rule set
errors
homepage
installing and configuring
logging
root password
RPM install
Security Tips
setting passwords
source install
viewing users and access
MySQL Database Server
mysql.rules
mysqld service in Red Hat Linux


index_N

[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
netbios.rules
Netcat
netcraft.com site
Netscreen firewall and SnortSAM
network
configuration problems
detecting scans
mappers
time protocol servers, detecting attacks to
traffic analysis
traffic, capturing small snapshot of
Network Interface Card (NIC)
network packets
dissecting
formation
IP header
TCP header
NFS (Network File System)
NIDS
mode, running Snort in
overview
running Snort as
solution
context for
Snort as
targeting
nikto
IDS evasion mode
installing and running
nitko
Apache sample results
Nmap 2nd
home page
how best run
scans and Snort installations
web-based attacks
NMPwalk
nntp.rules
no_alert_incomplete option (rpc_decode preprocessor)
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 (http_inspect_server)
no_promisc option (snort.conf)
noalerts option (stream4_reassemble preprocessor)
nocase; rule option
noinspect option (stream4 preprocessor)
nolog option (snort.conf)
non_rfc_char option (http_inspect_server)
non_strict option (http_inspect_server)
NOT (!) directive
NSA Secure Configuration Guides
NSA Security Guides


index_O

[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
Okena
one-time password generators
open source applications, challenges of using
OpenSSL, compiling
operating system, choosing for securing sensors
opportunists
opt table
options, listing
Oracle
database servers, detecting attacks to
database, disabling rule set
logging
oracle.rules
ORACLE_PORTS variable (snort.conf)
order: [pass, alert, log, activation, or dynamic] option (snort.conf)
other-ids.rules
Outlook Web Access traffic, detecting
output configurations
output-mode option (flow-portscan preprocessor)
oversize_dir_length option (http_inspect_server)


index_P

[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)
p2p.rules
Packetfactory
packets [See also network packets]
capture length
changing order of rules applied to
checksums, controlling
illegal header settings
logging, turning off
sniffing
viewing in ACID
with nonidentifiable yet suspicious content
Packetstromsecurity
Packetyzer
paralyze attack phase
pass rules
passwords
confusing MySQL root with Linux root
cracking utilities
locking accounts after bad guesses
one-time password generators
patching Snort to enable support for SnortSAM
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
PHP
application services, disabling rule set
applications, detecting attacks to
enabling modules
Hypertext Preprocessor
source code, configuring for integration with Apache2
testing Apache integration
phplot
ping of death attack
pings specific to particular attack tools, detecting
pix option (snortsam.conf)
pkt_count: option (snort.conf)
policy router 2nd
policy.rules
POP2 email service, detecting attacks to
pop2.rules
POP3 email service, detecting attacks to
pop3.rules
porn.rules
port
monitoring
scanners
port option (snortsam.conf)
ports option (http_inspect_server)
ports option (stream4_reassemble preprocessor)
portscans
software version-mapping and
PostgrSQL logging
preprocessor configuration
arpspoof
bo
flow
flow-portscan
frag2
http_inspect
perfmonitor
rpc_decode
stream4
stream4_reassemble
telnet_decode
preprocessors
flow, configuring
flow-portscan, configuring
frag2, configuring
http_inspect, configuring
stream4_reassemble, configuring
tailoring
printing packets to console
prioritizing systems and networks to watch
priority: rule option
probe attack phase
mining the web
vulnerability scanners
web page scanners
professionals
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 preprocessor)
PureSecure Console 2nd
PureSecure Personal Console


index_Q

[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


index_R

[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]

Radware
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)
RIPE
robots
Roesch, Martin
rollbackhosts option (snortsam.conf)
rollbacksleeptime option (snortsam.conf)
rollbackthreshold option (snortsam.conf)
root directory, changing after initialization
routes, redirecting
rows option (flow preprocessor)
rpc.rules
rpc_decode preprocessor
rservices (rlogin, rsh, and rexec), detecting on network
rservices.rules
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
ack:
classtype:
content:
content_list:
depth:
dsize:
flags field
flags:
fragbits:
fwsam
icmp_id:
icmp_seq:
icode:
id:
ip_proto:
ipopts:
itype:
keywords and values
logto:
message
msg:
nocase;
offset:
parts of
priority:
react:
reference:
regex
rev:
sameip;
seq:
session:
sid:
stateless;
ttl:
uricontent:
rule sets
getting latest
tailoring
trimming high noise
useful
rule-management tools
RULE_PATH variable (snort.conf) 2nd
rules [See also rule sets]
creating and managing
creating for inline patch
custom
creating
downloading
editing custom
executing
keeping up-to-date
list of
modifying rules that generate blocking requests
pass
suppression 2nd
threshold
tuning individual
updating
where to keep
writing good


index_S

[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
Sarbannes-Oxley
scan.rules
scanner-fixed-threshold option (flow-portscan preprocessor)
scanner-fixed-window option (flow-portscan preprocessor)
scanner-sliding-scale-factor option (flow-portscan preprocessor)
scanner-sliding-threshold option (flow-portscan preprocessor)
scanner-sliding-window option (flow-portscan preprocessor)
scanning machines on your network
schema table
scoreboard-memcap-scanner option (flow-portscan preprocessor)
scoreboard-memcap-talker option (flow-portscan preprocessor)
scoreboard-rows-scanner option (flow-portscan preprocessor)
scoreboard-rows-talker option (flow-portscan preprocessor)
Scoreboards component (flow-portscan preprocessor)
scrambling networks
script kiddies
sdrop rule action
secure certificates
SecurityFocus
SecurityFocus IDS Page
self-inflicted denial-of-service
self-test mode, starting Snort in
sensor table
sensors
administration problems
configuring interfaces
managing Snort [See IDS management]
placement
creating connection points
prioritizing systems and networks to watch
placing
securing
applying patches and updates
choosing operating system
monitoring system logs
robust authentication
seq: rule option
Server statistics tracker component (flow-portscan preprocessor)
server-ignore-limit option (flow-portscan preprocessor)
server-learning-time option (flow-portscan preprocessor)
server-memcap option (flow-portscan preprocessor)
server-rows option (flow-portscan preprocessor)
server-scanner-limit option (flow-portscan preprocessor)
server-watchnet option (flow-portscan preprocessor)
serveronly option (stream4_reassemble preprocessor)
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
sguil
sguil server database
sending log information to (barnyard.conf)
shaft
shellcode in the packet payload, detecting
shellcode.rules
SHELLCODE_PORTS variable (snort.conf)
show_year option (snort.conf)
sid: rule option
sig_class table
sig_id parameter
sig_reference table
signature table
signature-based IDS versus antivirus software
signatures
attempted-recon
automatic updates
disabling high-noise
faulty
of known exploits
Snort and
updating
skiphosts option (snortsam.conf)
skipinterval option (snortsam.conf)
smart cards
SMTP (Simple Mail Transfer Protocol)
SMTP email service, detecting attacks to
smtp.rules
SMTP_SERVERS variable (snort.conf)
sniff trace, directing to logfile
SniffDet
sniffer
sniffer mode for Snort
sniffer-mode output
sniffing
turning off promiscuous mode
SNMP traffic, detecting
snmp.rules
SNMP_SERVERS variable (snort.conf)
SNMPwalk
Snort
as NIDS solution
database schema
deploying [See deploying Snort]
installing [See installing Snort]
overview
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
sections
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
prerequisites
logging in and surveying layout
management console
features
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 menu
Rule Category Overview link
Rule Policy Templates section
Rules Selection drop-down menu
Variable Selection drop-down menu
Sensor Console button
trickiest part
updating rules and signatures
snortdb-extra.gz file
SnortReport 2nd
SnortSAM 2nd 3rd
downloading
installing
output plug-in
patching Snort to enable support for
starting
snortsam.conf file options
accept
daemon
defaultkey
dontblock
include
ipchains
iptables
logfile
loglevel
pix
port
rollbackhosts
rollbacksleeptime
rollbackthreshold
skiphosts
skipinterval
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.rules
SQL_SERVERS variable (snort.conf)
src-ignore-net option (flow-portscan preprocessor)
SSH (Secure Shell)
SSL Accelerator
SSL proxies 2nd
sslproxy
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
configuring
stress-testing IDS machines
subversion
Sullo
suppression rules 2nd
syntax
switches
Cisco
configured to span several ports
enterprise-class
listing
SYN (synchronize sequence numbers) packet
SYN FIN scan attempt
synchronize sequence numbers (SYN) packet
syslog server, sending alerts to
system configuration errors


index_T

[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 (flow-portscan preprocessor)
talker-fixed-window option (flow-portscan preprocessor)
talker-sliding-scale-factor option (flow-portscan preprocessor)
talker-sliding-threshold option (flow-portscan preprocessor)
talker-sliding-window option (flow-portscan preprocessor)
targeting IDS
TCP (Transmission Control Protocol)
header
three-way handshake
tcp-penalties option (flow-portscan preprocessor)
TCP/IP
suite of protocols
ARP
ICMP
IP
TCP
UDP
tcpdump 2nd
-n and -nn options 2nd
-s option
-v option
-x option
basics
capture example
filters
homepage
installing
output
capture of TCP three-way handshake
data within the < and > characters
replacing
running
syntax options
writing data to temp file
tcphdr table
telnet sessions, detecting dangerous traffic transmitted in
telnet.rules
telnet_decode preprocessor
TELNET_SERVERS variable (snort.conf)
Tenable Security 2nd
Tethereal 2nd
TFTP (Trivial File Transfer Protocol)
TFTP service, detecting attacks to
tftp.rules
thieves
three-way handshake (TCP)
threshold type thresholding example
thresholding 2nd
difference between standalone thresholds and those included in rules
examples
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
Trin00
Trojan horse
ttl: rule option
ttl_limit option (frag2 preprocessor)
ttl_limit option (stream4 preprocessor)
tuning Snort


index_U

[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 preprocessor)
unique-rows option (flow-portscan preprocessor)
Uniqueness tracker component (flow-portscan 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)


index_V

[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
vandals
verbose option (snort.conf)
version number, displaying
virus.rules
Virusdot.org
viruses
Visscher, Bamm
VLANs, mirroring multiple
VTP (Virtual Terminal Protocol)
vulnerability scanners


index_W

[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 information
web sites, running secure
automating startup
certificates
creating test certificate
generating random key
on port 443
unlocking secure certificate
web-attacks.rules
web-cgi.rules
web-client.rules
web-coldfusion.rules
web-frontpage.rules
web-iis.rules
web-misc.rules
web-php.rules
webcrawling utilities
Welchia worm
Whisker
Whisker+SSL
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
winpcap
WinPcap
worms


index_X

[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
x11.rules


index_Y

[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


index_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]

zlib file