Tuesday, August 03, 2010
Suricata in toolsmith: meet the meerkat
Rather than fan the Suricata versus Snort flames (you're both great kids and I love you equally) I'm opting for Swiss-like neutrality and simply invite you to explore Suricata at length.
See Victor Julien's post on the matter as he sums it up succinctly.
While I've always been a Snort user, I've also long been an ardent supporter of Matt Jonkman's Emerging Threats. Given his logical progression towards the Open Information Security Foundation (OISF), a "non-profit foundation organized to build a next generation IDS/IPS engine", I felt deeply obligated to cover Suricata in toolsmith.
Suricata: An Introduction is my effort to oblige.
While this article is painfully introductory, it should whet your appetite.
Suricata, as the "product" of OISF, is compelling on different fronts.
1) Intent: "OISF’s primary goal is to remain on the leading edge of open source IDS/IPS development, community needs and objectives."
As such, Suricata "is not intended to just replace or emulate the existing tools in the industry, but will bring new ideas and technologies to the field."
Committing to community needs and objectives, much as Emerging Threats has, is noble and valuable.
2) Scale: My testing on a dual core box matches Victor's assessment.
"Is Suricata faster than Snort on a single core cycle for cycle, tick for tick? No. But we scale. We’ve had reports of running on a 32 core box and scaling to use all cores. There Suricata is much faster."
I believe performance at scale is essential/vital/critical to IDS/IPS success in this burgeoning age of all things cloud and virtual (think complexity, and mondo network traffic). Groundbreaking thinking on my part, I know. ;-)
Consider that an unnamed military body has tested Suricata versus Snort on a large scale platform (24 processors and 128GB of RAM) and saw a very clear 6-fold speed increase over a tuned Snort implementation on the same platform.
3) HTP Library: In a context similar to all things cloud (online services), effective HTTP normalization and parsing is mighty important. Ivan Ristic's HTP Library endeavors to provide "very advanced processing of HTTP streams for Suricata."
4) Features: I'll let the comparison chart speak for itself.
Performance geeks will definitely want to explore the use of PF_RING and leveraging CUDA-capable hardware. The article clarifies these a bit more.
5) Same rules (Snort-based): Need I say more?
These should be ample reasons for you to give Suricata a really close look.
Deploy it.
Give it every opportunity to prove itself side by side with your current IDS/IPS solution.
Keep an eye on the project site, and get involved.
Start by downloading 1.0.1 here.
Cheers.
del.icio.us | digg | Submit to Slashdot
Please support the Open Security Foundation (OSVDB)
Subscribe to:
Post Comments (Atom)
Moving blog to HolisticInfoSec.io
toolsmith and HolisticInfoSec have moved. I've decided to consolidate all content on one platform, namely an R markdown blogdown sit...
-
Continuing where we left off in The HELK vs APTSimulator - Part 1 , I will focus our attention on additional, useful HELK features to ...
-
As you weigh how best to improve your organization's digital forensics and incident response (DFIR) capabilities heading into 2017, cons...
-
When, in October and November 's toolsmith posts, I redefined DFIR under the premise of D eeper F unctionality for I nvestigators in R ...
2 comments:
can u please share any data you have for Multi-core SNORT like what was the platform,traffic and perofmance..etc.. Thanks in advance
I asked Michael Rash of cipherdyne.org to give you feedback for this question given his broader experience:
"I believe that the method most people use to take advantage of multiple cores with snort is just to run multiple snort processes (since snort is not yet multi-threaded in the 2.x series). Then
bpf filters are used to have one snort process not examine the traffic that another sees (if they are sniffing the same interface), and separate signature sets are therefore needed as well. Performance data is always tricky business - average packet size, number of signatures, complexity of the signatures, traffic mix, and more are all at play. Oh, and inline mode is even worse. I've
seen rigorously tested IPS products deployed on large production networks where a different traffic mix caused unexpected spikes in latency that were difficult to reproduce in any testing network."
Post a Comment