[Emerging-Sigs] SURICATA in holisticinfosec.org toolsmith article

Mike Lococo mikelococo at gmail.com
Fri Aug 6 12:29:48 EDT 2010


On 08/06/2010 06:58 AM, Kevin Ross wrote:
> Here you can get it here:
> 
> http://holisticinfosec.org/toolsmith/docs/august2010.html
> 
> I like this part though:
> 
> "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."

To phrase this result another way, Suricata requires 4x more
clock-cycles than Snort to do the same job.  I don't see that as such a
terrible thing at this stage of the project's life, it is young and
still has *lots* of room for improvement and optimization.  But to claim
that Suricata is faster today, one first must ignore the many mature
techniques for scaling snort to multiple CPU's using multiple
processes... and then one must use relatively beefy hardware to
significantly beat even single-CPU snort performance.

I've done some limited and unscientific testing on my own hardware, it
isn't difficult to get both packages running side-by-side.  I used a
live link with daily peaks of about 1.2gigabits/sec, testing on an 8-CPU
box with Endace Dag hardware that is capable of doing hash-based
load-balancing to 4 processes, or delivering the entire packet stream to
a single process.

My typical snort configuration consists of a fairly heavy ruleset
involving large portions (but not all of) VRT + ET.  The 4-snort
processes acting in conjunction with the DAG load-balancing monitor this
line with about 50% utilization of 4-CPU's.  The remaining CPU's in the
8-processor sensor are either idle or used by other applications.  The
performance increase from 1 to 4 CPU's is linear within my ability to
measure it.  I know from conversations with other folks that snort
scales fairly linearly *at least* up to 12-16 CPU's on the right
commodity hardware.

A single Suricata process receiving the complete stream from the DAG
card, and using the same ruleset would peg all 8-CPU's and drop a large
fraction of packets.  It's possible that I'm failing to optimize
Suricata well, I still have much more experience with Snort.  I haven't
seen a result that claims anything significantly different than what
I've observed, though.

I have no opinion about the Snort/Suricata flameware that seems to be
going on these days, and I'm watching Suricata development with great
interest.  Based on my testing, it's wishful thinking to say that
Suricata is faster right now, though.  The slowdown is significant
enough that I'm not able to run Suricata on my links without upgrading
the hardware that snort is successfully running on.

Cheers,
Mike Lococo


More information about the Emerging-sigs mailing list