Re: String matching in snort.

[Matt Kettler <mkettler () evi-inc com>]

Hmmm, from the paper I'm not 100% convinced that's a genuine improvement. 
It improves a very special case by a lot, but also very wildly increases 
the amount of memory used by snort, and only has a relatively small 
improvement in the more general case.

It also is optimized for improving the performance of string matches where 
the content contains repeated substrings. In general most snort rules can 
be written in a manner which avoids such problems, and in fact it's been 
repeatedly said that rule writers should avoid repetitive strings whenever 
possible.

Looking at the general mixed content/non-content 854 rule case you get an 
improvement from 43.97 seconds to 37.19 seconds. Mind you these number are 
BIASED because they forced case sensitivity off, even for rules which are 
specifically case sensitive. So even cheating a little by forcing a 
non-realistic rule set they got a 15.4% improvement. Now look at the memory 
usage which went up from 3684 12312. That's over triple the memory usage. 
(334% actually).

I do wonder how much this tweak would improve snort in its normal mode, 
with case sensitive searches enabled if the rule is written for it.

And yes, the all-content rule case went up quite a lot in speed, but that's 
completely not realistic in the case of snort. It does show that that 
aspect of snort was improved quite a bit, but also shows (when combined 
with the other results) that improving that aspect quite a lot does not 
radically improve general performance.

I don't know if snort implemented this feature or not, it probably has, but 
I'd certainly say it is not clear cut of an improvement as you might think 
based on the title of the paper.

I would say that the snort team would almost certainly adopt any 
improvement suggestions which are clear wins, and looking at the changelog 
several of them have been made over the life of snort. Marty and crew would 
be fools and quite frankly negligent if they ignored speed improvement 
suggestions, but they'd also be fools just to accept a suggestion based on 
the headlines.



At 09:15 PM 5/12/2002 -0400, Ashley Thomas wrote:
> Hi,
>
> Came across a paper which suggests some
> modifications to make string matching faster.
>
> http://www.silicondefense.com/software/acbm/speed_of_snort_06_21_2001.pdf
>
> Did snort do something like this to speed up the
> string matching ?
> (The paper is quite old ..so i dont know if snort moved
> on to much faster algorithms)
>
> Any pointers...
>
> thanks
> ashley
>
>
> _______________________________________________________________
>
> Have big pipes? SourceForge.net is looking for download mirrors. We supply
> the hardware. You get the recognition. Email Us: bandwidth () sourceforge net
> _______________________________________________
> Snort-users mailing list
> Snort-users () lists sourceforge net
> Go to this URL to change user options or unsubscribe:
> https://lists.sourceforge.net/lists/listinfo/snort-users
> Snort-users list archive:
> http://www.geocrawler.com/redir-sf.php3?list=snort-users


_______________________________________________________________

Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: bandwidth () sourceforge net
_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users