What is Snort-NG?
Snort-NG is a patch that replaces and improves the detection engine of Snort, one of the most well-known and deployed network intrusion detection system (NIDS). Our engine makes the critical operation of Snort - the decision whether a packet matches a predefined set of rules (or signatures) - faster.

What is the problem with the existing Snort, why should I use Snort-NG?
The existing Snort uses a two-dimensinal list structure to store rules. When the number of used signatures increases above a few hundred, a significant slowdown in the time it takes to scan a packet is noticed. Snort-NG optimizes the way that rules are compared to incoming packets, thereby it can keep up with loads that Snort cannot handle. In that sense, Snort-NG provides more security as the likelihood of dropping packets and threby missing an attack is reduced.

Why is it necessary to be fast when operating a NIDS?
A NIDS such as Snort that processes data in real-time needs to keep up with the speed packets are arriving on the network. If it is not fast enough, it will start to drop packets (i.e. it does not analyze them). Because of the fact that many exploits can hide in a single packet, it is important to be able to monitor as many as possible, optimally every single one.

Why does Snort-NG report more attacks than the Snort?
In contrast to Snort, Snort-NG reports all rules that match a certain packet. For some strange reason, Snort stops the detection process for a packet after the first matching rule - maybe to improve performance. Nevertheless, as most packets do not match at all, it might be worthwhile to spend some extra cycles on packets that actually do contain something interesting.

A Snort-compatibility mode can be enabled with the '-j' flag. Then Snort-NG reports at most one matching rule per packet.


How did you achieve this performance increase?
A complete description of the applied techniques can be found in the following technical report.

The basic observation was that Snort uses a simple two-dimensional list for storing rules and depends a lot on the type and number of rules which are fed to it. One problem is the large number of rules which are not distinguishable by their mandatory IP address and port fields (such as rules for incoming HTTP traffic). When a lot of such traffic is encountered, Snort needs to compare each packet to many rules and tends to slow down significantly.

Two important techniques that we have applied are:

  • Machine learning methods (clustering) to replace the lists by a tree structure. This helps to reduce redundant comparisons.
  • A modified combination of the Boyer-Moore and Karp-Rabin string matching algorithms which allows parallel string matching.

How fast is Snort-NG in comparison to the standard Snort? What does the speed of both depend on?
You can obtain performance measurements which allow you to compare the speed of both systems here. In general, both systems depend on the number of rules, their types and and the traffic that is actually monitored. As more signatures are used, the number of checks that have to be performed is obviously higher. Nevertheless, our engine tends to scale more gracefully and achieves a significant speed up when the complete set of all Snort 1.8.7 rules is used.

Will your patch be compatible with future versions of Snort?
This depends. We partial rely on the existing RTN/OTN data structure to do checks for features (or signature keywords) that we do not support directly. This allows one to extend Snort with new ones without breaking our patch. Nevertheless, when important keywords change or get replaced (such as it might be the case with flags in Snort 1.9), our approach slows down as more and more checks are done in the old fashion. However, when the keywords remain the same and the core detection does not change, it is really easy to port Snort-NG. We developed Snort-NG for Snort-1.8.6 and ported it to Snort-1.8.7 in less than half an hour.

Snort-NG maintainer