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

Joel Esler jesler at ...435...
Thu Nov 8 15:59:05 EST 2012


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 at ...435...> 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 at ...435...> 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 at ...2420...> 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 at 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 at 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!
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-sigs/attachments/20121108/fac82e67/attachment.html>


More information about the Snort-sigs mailing list