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.