Managing Security with Snort & IDS Tools

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