James C. Foster

Playing by the Rules

This chapter provides an overview of a road map to let a user understand and compose his/her own Snort rules. Snort incorporates numerous methods for controlling engine-related configurations to ensure that the engine and rules are tailored for each environment. Most of these configuration choices can be made in one of the two ways. The first would be to directly specify the desired configuration option via the command line when executing Snort. The second method (a more efficient and manageable method for enterprise environments) involves defining Snort configurations in a configuration file and just telling Snort to use that configuration file when starting. Snort grabs that configuration file and reads all of the configuration options and values individually, just as if they were specified via the command line. It is highly recommended that the user creates and uses configuration files when deploying Snort sensors in the environment, unless he/she is merely testing rules and engine capabilities.

Introducing Snort 2.1

This chapter provides a practical introduction to the open-source IDS Snort. It examines the different requirements for installing Snort, from hardware requirements like speedy network interface cards to operating system. It also covers the architecture and design of Snort and the different plug-ins that can be selected to customize the way data is processed, from the packet decoder through the preprocessors into the detection engine, and out again through the output plug-ins of your choice Snort is a modern security application with three main functions: it can serve as a packet sniffer, a packet logger, or a Network-based Intrusion Detection System (NIDS). There are also many add-on programs to Snort to provide different ways of recording and managing Snort logfiles, fetching and maintaining current Snort rule sets, and alerting to let admins know when potentially malicious traffic has been seen. Although not part of the core Snort suite, the add-ons provide a rich variety of features to the security administrator. There are many resources available online for a Snort enthusiast, including mailing lists for Snort development, writing signatures, general Snort discussion, Snort announcements, and even tracking of Concurrent Version System (CVS) changes.

Keeping Everything Up to Date

This chapter illustrates several techniques that can be used to keep systems at their optimal performance levels. Snort is an open-source Intrusion Detection System (IDS) and is under constant development. New minor and major releases appear regularly. To maintain an up-to-date IDS, a user should install update periodically. The update of executables does not need to be done each time a new release is issued, especially for production systems. Each upgrade has to be carefully considered. The process of upgrading executables is rather simple, as backward compatibility is usually preserved. It is usually possible to simply install a new executable over the old one while preserving configuration information. Much more important are updates to the rules. They need to be watched regularly. There are semi-automated tools for rule management, Oinkmaster currently being the most convenient. Keeping Snort up to date is best done through various means such as monitoring mailing list and newsgroup. A users IDS rules can also be used to help fight worms and viruses and assist in patch management and verification of patches.

Mucking Around with Barnyard

This chapter discusses the ways to install, configure, and use Barnyard as part of a Snort installation. With Barnyard deployed, Snort does not have to deal with the myriad of ways that the alerts need for getting formatted and dispatched. Instead, Snort can simply output the events using the unified output plug-in and Barnyard will handle the details of inserting them into a database, generating syslog. The most obvious situation in which to use Barnyard is when Snort is being used to monitor a high-speed network—the scenario envisioned when Barnyard was additionally developed. However, several other advantages can be realized by using Barnyard. For example, although Snort requires some level of root privileges to promiscuously sniff network traffic, Barnyard has no such requirement. Barnyard only needs to be able to read the unified files generated by Snort. Therefore, the security conscious users may want to use Barnyard to implement privilege separation.

Dealing with the Data

This chapter discusses the methodology and tools that help to manage the task of monitoring Snort sensors and analyzing intrusion data. Providing the ability to view actual packet data is one of Snorts strong points. In many commercial solutions, the ability to view the packets that caused the alerts to fire is not available. As a result, a user is not able to tell the reason behind a mistake committed (when it inevitably happens) by the Intrusion Detection System. The ultimate goal of installing and using Snort is to help a security analyst monitor and study intrusion attempts. Currently, intrusion-related traffic on the internet is high. If the users sensor is located on a busy network, it can generate megabytes of data each day. The user requires some tool to automate the process of monitoring and alerting, because it is impossible for a human to browse such a huge amount of data and come to any meaningful conclusion. A variety of tools are available for this purpose: (1) Swatch—for real-time log file monitoring and alerting; (2) SnortSnarf—provides features for generation of static HTML reports from log files; and (3) “Snort_Stat.pl”— a simple Perl script to extract event data summary reports from the users Snort alert files.

Chapter 1 – Intrusion Detection Systems

This chapter discusses the concept of Intrusion Detection System (IDS). IDSs can serve many purposes in a defense-in-depth architecture. IDSs are a weapon in the arsenal of system administrators, network administrators, and security professionals, allowing real-time reporting of suspicious and malicious system and network activity. In addition to identifying attacks and suspicious activity, IDS data can be used to identify security vulnerabilities and weaknesses. IDSs can audit and enforce security policy. For example, if a security policy prohibits the use of file-sharing applications such as Kazaa, Gnutella, or messaging services such as Internet Relay Chat (IRC) or Instant Messenger, an IDS can be configured to detect and report this breach of policy. IDSs are an invaluable source of evidence. Logs from an IDS can become an important part of computer forensics and incident-handling efforts. Detection systems are used to detect insider attacks by monitoring traffic from Trojans or malicious code and can be used as incident management tools to track an attack.

Implementing Snort Output Plug-Ins

This chapter discusses Snort plug-ins, the role they play in formatting data, and the overall schema and API that the plug-ins implement. In general, output plug-ins can be considered as product add-ons because they can be written by anyone and included within Snort at compile time. After the plug-ins have been built within the Snort application, a user can refer to them via Snort configuration files, from the command line and from within defined Snort rules. The packet capture engine in Snort retrieves packets off the wire and “sends” them to the analysis module. Snort output plug-in functionality can be divided into seven main categories: (1) copyright and header information; (2) files, dependencies, and global variables; (3) keyword registration;(4) argument parsing and function list linking; (5)data formatting, processing, and storage; (6) preprocessor processing; and (7) application cleanup and exiting. Because the Snort development team has implemented an application programming interface (API) structure for the use of output plug-ins, both private organizations and professional security team can design in-house plug-ins. These in-house plug-ins can be driven by technology or customers, but the common goal should always remain to minimize manual data compilation tasks.

Chapter 3 – Installing Snort

Publisher Summary This chapter reviews the steps necessary to successfully install a functioning Snort Intrusion Detection System (IDS). It discusses the way to install Snort on three different operating systems: Linux, OpenBSD, and Windows. The OpenBDS ports system is a method for installing software that has been prepared to compile on OpenBSD, which comes directly from FreeBSD. The ports tree is located in/usr/ports and is divided into categories to ease the finding of the software. To save time and trouble, OpenBSD maintains precompiled binary distributions of every package for each released version of OpenBSD and its associated ports tree. Installing Snort is as simple as downloading and installing a package. The quickest way is to install the Snort package from remote, although most OpenBSD users are too untrusting to do so. OpenBSD has its own nuances and particularities, but overall it is a fantastic operating system. If a user is building a 100MB sensor, OpenBSD is a great choice, as long he/she is comfortable performing the required maintenance and administration.

Chapter 4 – Inner Workings

Publisher Summary This chapter provides an overview of the way packets are processed through Snort. It explains the different steps Snort takes to decode packets for later processing. The life of a packet inside Snort is rather simple. Snort uses pcap for reading packets. Snort tells pcap to use the callback function “ProcessPacket” whenever it reads a packet. “ProcessPacket” calls the decoder, which decodes each of the network layers. After decoding, the next step depends on the way Snort was started. In Intrusion Detection Systems mode, Snort calls the detection engine, whereas in the packet-logging mode, Snort calls the output plug-ins—the same output plug-ins used by Snort when it generates an alert. One of the most useful features of Snort happens after the detection phase on any of the packets that did not trigger alerts. Rule writers can add the “tag” rule option— a post-detection rule option—to log a specific amount of data from the session or host after the rule fires. After an alert is fired, but before Snort calls the output plug-ins, there are two additional steps that Snort goes through: (1) threshholding—rule writers can limit the number of events that are triggered by rules and (2) Suppression—prevents rules from firing on a specific network segment without removing the rules from the ruleset.

Chapter 13 – Advanced Snort

Publisher Summary This chapter provides an overview of the more advanced features of Snort and the way it can be used to provide an even greater degree of information security. With proper and knowledgeable configuration, Snort can be used to increase the effective security in organization while at the same time saving a great deal of money. Snort can also be used for detecting unusual traffic such as odd IP-based protocols. This can be helpful for infrastructure level attacks such as those against routers and high-end switches. Another use is in policy-based detections such as when a Web server starts generating traffic other than Web traffic and generating an alarm, or for capturing advanced Trojan traffic such as in the 55808 Trojan. Snort— Snort-Inline and its mangling of packets—can be used to stop attacks from occurring. Snort can also help an IDS team interact with law enforcement investigations. The use of some of the keywords from the Snort language, such as “logto” to keep investigation traffic and alarms separate from normal day-to-day alarms or “session,” can be useful in displaying contents of Web traffic or the contents of an investigation suspects traffic.