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

[Mike Cox <mike.cox52 () gmail com>]

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?

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.

Thanks.

-Mike Cox

On Thu, Nov 8, 2012 at 2:59 PM, Joel Esler <jesler () sourcefire com> wrote:
> If you have the content as a pre qualifier, then the pcre should execute
> (especially something that small) really quickly.  It shouldn't be hard to
> perf test that, but if I did it, 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..)
>
> So we'd need to perf test it on a live network in parallel.  Mike, care to
> do so?
>
> --
> Joel Esler
> Senior Research Engineer, VRT
> OpenSource Community Manager
> Sourcefire
>
> On Nov 8, 2012, at 3:52 PM, Russ Combs <rcombs () sourcefire com> wrote:
>
> Good question.  Do we have perf data for content:"foo" vs. pcre:"foo" ?
> That would probably be indicative.
>
> On Thu, Nov 8, 2012 at 3:38 PM, Joel Esler <jesler () sourcefire com> wrote:
> > We are looking at this Mike, we think this is an interesting idea,
> >
> > However, implementing a pcre like "pcre:"/bad\.pdf$/";"  shouldn't have
> > that much of an impact.
> >
> > --
> > Joel Esler
> > Senior Research Engineer, VRT
> > OpenSource Community Manager
> > Sourcefire
> >
> > On Nov 7, 2012, at 4:22 PM, Mike Cox <mike.cox52 () gmail com> wrote:
> >
> > AFIK, it isn't possible to do this without a PCRE but I though I'd
> > ask: is is possible to tell a preprocessor content buffer (like
> > http_uri) to match at the end (or beginning) of the buffer without
> > using a PCRE?
> >
> > For example, let's say I want to match the URI 'bad.pdf".  I know this
> > will be at the end of the URI (and thus the end of the http_uri
> > buffer) and I want to match that specifically so I don't also get
> > alerts on things like "/bad.pdfoobar/index.aspx".
> >
> > Normally I'd just do this:
> >
> > content:"/bad.pdf"; http_uri;
> >
> > But I know that this will be at the end of the URI buffer and I don't
> > want to do a PCRE as well to ensure this due to performance concerns.
> >
> > It seems like this ability would be moderately easy to build into the
> > engine and computationally trivial as far as performance goes.  Maybe
> > have something like, "http_uri:end", "http_uri:beginning",
> > "http_uri:beginning,end", http_cookie:end", etc. or have special
> > characters (that would otherwise have to be escaped) to indicate that
> > you want to match on the beginning or end of the buffer.
> >
> > Just a thought since you guys are re-writing the http-inspect
> > preprocessor :)  Joel, feel free to send to snort-dev, I don't think
> > I'm on that list.
> >
> > Thanks!
> >
> > -Mike Cox
> >
> >
> > ------------------------------------------------------------------------------
> > LogMeIn Central: Instant, anywhere, Remote PC access and management.
> > Stay in control, update software, and manage PCs from one command center
> > Diagnose problems and improve visibility into emerging IT issues
> > Automate, monitor and manage. Do more in less time with Central
> > http://p.sf.net/sfu/logmein12331_d2d
> > _______________________________________________
> > Snort-sigs mailing list
> > Snort-sigs () lists sourceforge net
> > https://lists.sourceforge.net/lists/listinfo/snort-sigs
> > http://www.snort.org
> >
> >
> > Please visit http://blog.snort.org for the latest news about Snort!
> >
> >
> >
> >
> > ------------------------------------------------------------------------------
> > Everyone hates slow websites. So do we.
> > Make your web apps faster with AppDynamics
> > Download AppDynamics Lite for free today:
> > http://p.sf.net/sfu/appdyn_d2d_nov
> > _______________________________________________
> > Snort-sigs mailing list
> > Snort-sigs () lists sourceforge net
> > https://lists.sourceforge.net/lists/listinfo/snort-sigs
> > http://www.snort.org
> >
> >
> > Please visit http://blog.snort.org for the latest news about Snort!

------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_nov
_______________________________________________
Snort-devel mailing list
Snort-devel () lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/snort-devel
Archive:
http://sourceforge.net/mailarchive/forum.php?forum_name=snort-devel

Please visit http://blog.snort.org for the latest news about Snort!