Marty Roesch on Snort 3.0
12 Dec 2006 10:43 PM / Filed in: I.T.
I've been to the groupe SUR monthly meeting in Paris (which I co-supervise with Hervé Schauer) this afternoon. As usual, there were two talks. While I gave the second talk with my friend Guillaume Arcas on Metasploit (the slides, in French, are online), the first was given by Marty Roesch, creator of Snort and founder of Sourcefire. The topic of his talk was The History and Future of Snort.
Marty started with the history of Snort. How it all started back in 1998 as an OSS pet project of his, how Snort gained momentum, how he started developing full-time and founded Sourcefire. I started playing with Snort on and off since version 1.5 and this part of the talk was quite nice. It helped understand how Snort got where it is now with version 2.6.1.2. But things started getting much interesting when Marty started speaking about the future of Snort and what features might be integrated in Snort 3.0, the next major version of this popular NIDS:
The three first features (auto-tuning, auto anti-evasion, and auto-prioritization) revolve around the same concept, called target-aware processing. Basically, if the NIDS can have confidence in what the attacked endpoint is (operating system, targeted application ...), it will be able to:
The fourth feature deals with the current necessity to stop Snort for changing the configuration. In Snort 3.0, you wouldn't need to stop the detection engine and lose context while doing so through the use of threads and data sources. A data source will implement data acquisition and decoding before handing the network data to the detection engine through an API which is implemented as a thread. If we need to change configuration, we would create a new thread and migrate the data source to it without context loss. As a beneficial side effect, it would be possible to have fail-over and load balancing between detection engines. A Snort daemon will be used as an interface between the administrator (who issues commands through a Cisco-like "shell" implemented in Lua) and the detection engine.
As for the fifth and last feature, Snort doesn't support currently the multi-core architecture of modern x86/x64 processors and Snort 3.0 needs to solve this.
All in all, it was a very interesting talk. Marty concluded by saying that many of these new features (such as threads and data sources) have been implemented in prototypes or are in the design phase. Since Snort 3.0 represents such a drastic change from the current Snort version, Sourcefire will be releasing subsystem alphas to the community for testing.
Edited to Add (20061213): On a side note, Guillaume Arcas and I will be giving a talk (in French) about the Bro IDS during the next groupe SUR monthly meeting (2007.01.16). Feel free to show up. Attendance is free. And we are also looking for a second talk for this meeting. If you are interested, drop me an email.
Edited to Add (20061218): According to Ureleet, IPv6 decoding will be native in Snort 3.0. Thanks for the update.
Marty started with the history of Snort. How it all started back in 1998 as an OSS pet project of his, how Snort gained momentum, how he started developing full-time and founded Sourcefire. I started playing with Snort on and off since version 1.5 and this part of the talk was quite nice. It helped understand how Snort got where it is now with version 2.6.1.2. But things started getting much interesting when Marty started speaking about the future of Snort and what features might be integrated in Snort 3.0, the next major version of this popular NIDS:
- Auto-tuning
- Auto anti-evasion (for layers 3 &4)
- Auto-prioritization of events
- No stopping to change configuration
- Taking advantage of multi-core processors
The three first features (auto-tuning, auto anti-evasion, and auto-prioritization) revolve around the same concept, called target-aware processing. Basically, if the NIDS can have confidence in what the attacked endpoint is (operating system, targeted application ...), it will be able to:
- Feed just the right policies (sets of detection rules) to the detection engine, thus eliminating unnecessary and often painful tuning (which is seldom done if any) and achieving the auto-tuning goal. Note that this is different from the current RNA (Real-time Network Awareness) product sold by Sourcefire. The detection engine in Snort 2.x is not aware of the RNA and all the intelligence (that is, the correlation of the NIDS and the RNA data) is done on the Defense Center, the central management software sold by Sourcefire.
- Model the target in such a way that the NIDS knows how to reassemble TCP packets or defragment IP packets and mimic the target. Marty said that evasion is a big issue and a very hard problem to solve. At least with knowledge gained on the target, Snort could become harder to evade in layers 3 & 4.
- Auto-prioritize events given knowledge on the target. Again, this is not RNA. The knowledge is gained somehow and fed right into the sensor so that when it sees an attack and it knows that the target might be vulnerable to it, it helps the analyst by giving that attack a higher priority that should be acted upon right away.
The fourth feature deals with the current necessity to stop Snort for changing the configuration. In Snort 3.0, you wouldn't need to stop the detection engine and lose context while doing so through the use of threads and data sources. A data source will implement data acquisition and decoding before handing the network data to the detection engine through an API which is implemented as a thread. If we need to change configuration, we would create a new thread and migrate the data source to it without context loss. As a beneficial side effect, it would be possible to have fail-over and load balancing between detection engines. A Snort daemon will be used as an interface between the administrator (who issues commands through a Cisco-like "shell" implemented in Lua) and the detection engine.
As for the fifth and last feature, Snort doesn't support currently the multi-core architecture of modern x86/x64 processors and Snort 3.0 needs to solve this.
All in all, it was a very interesting talk. Marty concluded by saying that many of these new features (such as threads and data sources) have been implemented in prototypes or are in the design phase. Since Snort 3.0 represents such a drastic change from the current Snort version, Sourcefire will be releasing subsystem alphas to the community for testing.
Edited to Add (20061213): On a side note, Guillaume Arcas and I will be giving a talk (in French) about the Bro IDS during the next groupe SUR monthly meeting (2007.01.16). Feel free to show up. Attendance is free. And we are also looking for a second talk for this meeting. If you are interested, drop me an email.
Edited to Add (20061218): According to Ureleet, IPv6 decoding will be native in Snort 3.0. Thanks for the update.
|