[Snort-sigs] Matching the beginning or end of a (preprocessor) content buffer

Joel Esler jesler at ...435...
Fri Nov 9 12:38:21 EST 2012

I suppose if your pcap was big enough, sure. For rule metrics. But not for engine performance. 

Two different things. 

Sent from my iPhone

On Nov 9, 2012, at 12:23 PM, Mike Cox <mike.cox52 at ...2420...> wrote:

> On Fri, Nov 9, 2012 at 9:13 AM, Joel Esler <jesler at ...435...> wrote:
>> On Nov 9, 2012, at 9:55 AM, Mike Cox <mike.cox52 at ...2420...> wrote:
>> So I can probably do some tests when I get the time (thanks for the
>> responses BTW), but I'm somewhat concerned with the comment, "...it
>> would be against static pcaps which doesn't test performance.  (Some
>> people think that looping a pcap through a system a bunch of times
>> test performance..)"
>> Can you elaborate on this?
>> We've heard of people testing performance by taking a big pcap and looping
>> it through their engine many times and thinking that's a "real world"
>> performance test.  (Which in reality, it's a test of how fast your hard
>> drive can be read ;)
>> I understand that using the '-r' option to tell Snort to read a pcap
>> will not test performance of things like bandwidth, dropped packets,
>> etc.  However, in a case like this when you want to test *relative*
>> performance between rules, is Performance Profiling not accurate for
>> thing like avg_ticks, total_ticks, etc.?  Does the engine not load the
>> rules, build the matching data structures/logic, and process thing the
>> same way when the '-r' option is used?  Let me say again that I am
>> asking about relative performance numbers between rules, not absolute
>> numbers necessarily.
>> Yeah…. ehh….
>> So..  Here's the deal.  If you are testing a rule against a pcap that you
>> know is going to fire, you are going to get a performance number.  That
>> performance number is relative to that pcap (No matter how big your pcap
>> is).  You can do some tweaking to a rule to get better performance against
>> that pcap, but there is no accounting for how the rule will actually work in
>> the real world.
>> I'll give you a completely awful example, but I am hoping you will look past
>> the example and not debate me on the merits of this example ;)  (Not you
>> Mike, but someone else on the list might feel like being pedantic or
>> argumentative and do so)
>> content:"User-Agent|3a 20|"; content:"badstuff";
>> You run this against any static pcap, and you will get "x" number.  Then you
>> can change the rule to read:
>> content:"User-Agent|3a 20|": content:"badstuff|0d 0a|";
>> You'll get a better performance number and you'll get "y" number, which is
>> better than "x" and think "well I improved the performance of the rule"  And
>> you did.  Against that pcap.  However, in the real world, your fast pattern
>> match is "User-Agent|3a 20|" which will match on almost every http session
>> there is.
> Performance can be measured in many ways and the Snort Performance
> Profiling takes in to account many of these.
> Sure, in these examples the fast-pattern matcher will default to the
> longest string which is, "User-Agent: ".
> So when you are looking at specific rule performance, I don't see how
> a rule that has to match on two additional bytes can be more efficient
> than one that doesn't (if all other things are equal).
>> We test against pcaps all day.  Constantly.  Just about every rule we have
>> in the VRT ruleset has a pcap and exploit associated with it.  But it's no
>> match for the real thing.
> Pcaps *are* the real thing.  Again, I'm only talking about relative
> rule performance, not data speeds, etc.
>> TL;DR -- You can test all you want against pcaps, at the end of the day,
>> it's meaningless.  Real World traffic mix is where it's at.  You want big
>> packets, small packets, complex packets, simple packets, etc.
> This is confusing.  Network data is network data, no matter how it is
> generated ... it still sounds like using the '-r' option to tell Snort
> to read a pcap file is different from telling Snort to process data
> over an interface ('-i').  Is this right?  Pcap files can contain,
> "big packets, small packets, complex packets, simple packets, etc." so
> I'm confused about the cognitive disparity here.
> To be clear, I'm not talking about relative performance metrics across
> multiple pcaps in Snort using the '-r' option, I'm talking about
> metrics generated by a single pcap (or a network feed from an
> interface), which contains data to be evaluated by the engine which is
> configured to use multiple rules, and those rules are the basis for
> the relative performance evaluations.
> Thanks.
> -Mike Cox

More information about the Snort-sigs mailing list