It is good for developers. But it is unrealistic expectation for end users (administrators) to write C code and use it in deployments. There is also very little flexibility from the configuration perspective to change parameters in existing .so rules. There should be some solution like web application firewalls do - deep packet inspection and protocol parsing.
Thanks Ravi On Wed, Mar 18, 2009 at 5:49 PM, Martin Roesch <[email protected]> wrote: > You guys do know that anything you can't do in the Snort rules > language natively can be done using .so rules, right? Write your > rules in C, store data statefully within Snort, manipulate things like > flowbits that other rules can reference, pretty much anything you care > to do in C. The only thing you can't do with it is generate > pseudopackets for other subsystems to analyze. > > No engine rewrite required. > > Marty > > On Wed, Mar 18, 2009 at 6:08 PM, Paul Schmehl <[email protected]> > wrote: >> --On Wednesday, March 18, 2009 15:39:23 -0400 Seth Hall <[email protected]> >> wrote: >>>> >>>> alert tcp any any -> $HTTP_SERVERS $HTTP_PORTS (msg: "Web attack - >>>> overflow attempt"; flow: to_server, established; content:"POST /"; >>>> http-method; content:"Content-Length3A"; nocase; depth:1; >>>> content:"This is where you would have to capture the value of >>>> Content-Length"; urilen:"value of Content-Length"; pcre:"/\w/"; >>>> classtype:web-application-attack; sid:1000001; rev:1;) >>> >>> It would actually be easy to identify with Bro. The problem with your >>> signature below is that it doesn't take into account the same byte value >>> being repeated for the total Content-Length. >> >> Yes, that's true. >> >>> It's a little more hacky to >>> make Bro identify the repeating character, but still possible. You're >>> also >>> ignoring the bounds Damiano placed on the value of the Content-Length >>> header. >> >> That's because snort doesn't have a way to define the bounds for that value, >> AFAIK. >> >>> If I have some time tonight, I'll write a script to detect this situation >>> and >>> post it to the list. >>> >> >> I'll be interested to see that. >> >> -- >> Paul Schmehl, Senior Infosec Analyst >> As if it wasn't already obvious, my opinions >> are my own and not those of my employer. >> ******************************************* >> Check the headers before clicking on Reply. >> >> >> >> > > > > -- > Martin Roesch - Founder/CTO, Sourcefire Inc. - +1-410-290-1616 > Sourcefire - Security for the Real World - http://www.sourcefire.com > Snort: Open Source IDP - http://www.snort.org > > >
