Service provider takeaway: Service providers will learn about Snort 3.0's new architecture and how it can be used as a platform for generic network traffic inspection tools.
Recently, I attended a seminar offered by Sourcefire, the company that supports Snort. Marty Roesch, Snort's inventor and primary developer, discussed Snort 3.0. In this edition of the Snort Report, I summarize Marty's plans and offer a few thoughts on the direction of Snort development.
Snort 3.0 is more than just a single program. The new direction of Snort development involves deploying at least two components working in tandem. The first element is the Snort Security Platform (SSP). SSP is a generic platform upon which any developer can deploy traffic inspection (and other) applications. SSP performs data acquisition, traffic decoding and flow normalization, among other tasks.
 |
| More on Snort |
| Learn more about Snort in previous editions of the Snort Report. |
|
|
|
|
The second element is an engine. There can be more than one engine active and the engine runs on top of -- and depends upon -- the SSP. Engines perform various useful functions like inspecting traffic for suspicious and malicious activity.
From a developer's point of view, it's a revolution as far as network inspection tools are concerned. For example, Michal Zalewski published a new tool called Fl0p in late 2006. While capable of fingerprinting layer 7 traffic based on analysis of packet flow characteristics, according to the readme file, "Fl0p can be trivially bypassed. It does no stateful stream inspection, so an RST with invalid checksum, a clever fragmentation scheme or even a simple retransmission may all work fine."
In other words, as a network traffic inspection tool, Fl0p can't handle the sorts of evasion mechanisms that Snort's preprocessors are meant to address. For example, the Frag3 preprocessor is designed to mitigate IP fragmentation, the Stream5 preprocessor deals with fragmented TCP sessions, and the http_inspect preprocessor normalizes URIs and removes most obfuscation.
What if the power of those preprocessors could be applied to any network traffic inspection tool? That's the idea behind the SSP. The SSP can handle evasions and other conditions found in suspicious and malicious traffic and pass a "scrubbed" or normalized version to any engine for inspection. For example, Fl0p could be implemented as an engine on the SSP and would no longer be "trivially bypassed." As the SSP improved, the capabilities of the engines would be improved too.
I like to think of SSP as the next "must-have" platform, just as Libpcap is the "must-have" library for packet acquisition. Currently, it's not necessary to use Libpcap (or Winpcap on Windows) for packet acquisition. Many developers choose to write their own packet acquisition libraries, some of which are much faster than Libpcap. However, Libpcap runs just about everywhere and many developers are familiar with it, so most common traffic inspection applications rely on Libpcap.
Libpcap, however, doesn't address the sorts of evasions that plague network applications. That is why many so-called network forensics tools are trivially evadable -- some to the point of showing one set of evidence to an analyst when a different layer of activity really transpired. Eric Cronin, Micah Sherr and Matt Blaze demonstrated this problem very clearly in their 2006 paper The Eavesdropper's Dilemma, which shows how to evade traffic inspection tools that don't properly handle maliciously fragmented traffic. If those applications were written to run as an engine on top of the SSP, they wouldn't have to worry as much about common network evasion techniques.
Sourcefire plans to release most of its products -- including Snort 3.0, Sourcefire's Realtime Network Awareness and Realtime User Awareness -- on top of the SSP as engines. In an interesting move, Sourcefire has also ported Snort 2.8.2 as an engine for the SSP to get the new architecture into tester and user hands as quickly as possible. By the time you read this, Sourcefire may already have an open source beta of the SSP and at least Snort 2.8.2 as an engine available for beta testing, with a general open source release expected for the end of the year. After the open source community has tested the new architecture, Sourcefire customers can expect to see the new system in 2009, although the actual Snort 3.0 engine probably won't arrive until the second half of 2009.
Another important aspect of Snort 3.0 is its rules language. Marty admitted that because Snort 3.0 is still being developed, he doesn't know how the rules language will look. Two years ago I posted Snort Dynamic Rules Preview, showing how Snort 2.6.0RC1 introduced a new C-style rules syntax. The dynamic engine is still used in Snort 2.8.x, but that syntax is not necessarily Snort 3.0's syntax.
As I showed last year in Snort 3.0 Alpha and IPv6, Snort 3.0 relies on Lua as a mechanism for interacting with the Snort engine. Snort 3.0 will consist of at least a snortd daemon and a command shell. Using the command shell, operators will be able to dynamically reconfigure the engine without having to stop and start it. Marty made this a design goal for the new system, intending to support high-speed, inline and state-preserving operations. In fact, the SSP is expected to support a new engine called Policy Enforcement Point (PEP), a stateless (yes, not stateful) firewall that integrates with Sourcefire's other products. Any engine running on the SSP will be able to call PEP to enforce access control decisions, assuming the sensor/IPS is in a place to take such actions.
Overall, the new Snort architecture is very exciting. Marty made it clear that he concentrated on the areas that would make Snort more powerful, like packet handling (not pattern matching) and running on multiple threads on multiple CPUs (not simply distributing load across CPUs). It'll be interesting to see if other network traffic inspection developers build their applications on the SSP.
About the author
Richard Bejtlich is the founder of TaoSecurity, author of several books on network security monitoring, including Extrusion Detection: Security Monitoring for Internal Intrusions, and operator of the TaoSecurity blog.
