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

Matthew Jonkman jonkman at jonkmans.com
Fri Aug 6 13:29:04 EDT 2010


APpreciate the feedback Mike. I think we can at this point already do better than the test you ran, but you're right in that suricata isn't faster yet. 

But suricata hasn't been internally performance optimized yet, and we have a long way to go to improve on scaling. 

Lots of room to improve, and we're just at the beginning!

Matt

On Aug 6, 2010, at 12:29 PM, Mike Lococo wrote:

> 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
> 
> _______________________________________________
> Emerging-sigs mailing list
> Emerging-sigs at emergingthreats.net
> http://lists.emergingthreats.net/mailman/listinfo/emerging-sigs
> 
> Support Emerging Threats! Get your ET Stuff! Tshirts, Coffee Mugs and Lanyards
> http://www.emergingthreats.net/index.php/support-et-and-buy-et-schwag.html


----------------------------------------------------
Matthew Jonkman
Emerging Threats
Open Information Security Foundation (OISF)
Phone 765-429-0398
Fax 312-264-0205
http://www.emergingthreats.net
http://www.openinfosecfoundation.org
----------------------------------------------------

PGP: http://www.jonkmans.com/mattjonkman.asc





More information about the Emerging-sigs mailing list