Snort Turns 9, Marty Talks About 3.0

Snort turns 9 years old this month. It's come a long way and gotten a lot bigger:

paul@arnold ~/snort-0.96$ find . -type f |wc -l
21
paul@arnold ~/snort-2.8.0$ find . -type f |wc -l
1311

Today Marty blogged about the changes that Sourcefire has in mind for the 3.0 engine. Some of this is old news, some of it's brand new. Here's what I found to be of specific interest:

0) Rewrite the core frameworks for Snort from the ground up to clean out code base cruft and leverage external libraries where possible to [...] effectively reduce the size and complexity of the code base making it easier to extend and ultimately lending the security benefits of a smaller code base.

Amen. The Snort 2.8.0 binary alone is over 8MB, to say nothing of the dynamic preprocessor libraries. It can be more if you compile in support for MySQL or PostgreSQL. That said, 2.8 and stream5 are significant improvements over their predecessors. If you're still on 2.6 or 2.7, don't wait for 3.0.

1) Build an "contextually aware engine", one that has the ability to understand what it's defending built around the concept of network context. Network context is essentially data about the environment that is being defended by Snort, the composition of the hosts in the network as well as the local network composition.

I'm glad to hear Marty say this, though frankly it's part of what we've built with the help of Oinkmaster. Trying to get the right rules turned on and looking at the right traffic is tough and requires deep knowledge of your network and how to configure your IDS. And it takes time. But it's worth it, and it is definitely the hardest part of tuning out false positives (and avoiding overtuning so that you miss real attacks). Anything Sourcefire can do to make this process more intuitive is a good thing in my book

2) Abstract and compartmentalize Snort's subsystems to make components "separable".

Sure. I think that we started seeing this with 2.6 and the dynamic preprocessors. I would like to add that I think Snort is due for an update or replacement for barnyard. Something more flexible and more easily integrated (and with better documentation) would be nice.

4) Add an interactive shell to the system so that it may be more fully orchestrated at runtime.

He's talking about Lua. I like the idea of an interactive shell interface to the engine. Honestly, though, I'm not sure what I'd do with it.

5) Multithread the engine to take better advantage of multi-core platforms that are standard today.

If you wouldn't hate me for it, I'd embed dancing hamsters or puppies or something equally ridiculous as a symbol of my elation. In other words, it's about effin time. Snort being single-thread only is, in my opinion, the single greatest scalability barrier that it has.

Data Source API - An abstraction API between the facilities provided by the data source and the rest of the Snort 3.0 software framework. This API exists to that the rest of Snort 3.0 can work without caring whether the Data Source is implemented as hardware or software.

And last but not least, what may be a second I-told-you-so for me this week. I don't know, but I suspect the purpose of this API is to eliminate the need for a LibPcap-bound network interface and open up the possible ways Snort can acquire network data like, say, disk?