Re: BARE BYTE UNICODE ENCODING

[Martin Roesch <roesch () sourcefire com>]

On Jun 4, 2004, at 10:11 AM, nick black wrote:

> What's the upshot of all this?  If you wish to specify that "this 
> should
> only be tested against TCP payloads", specify that, and design your
> signature language so the exact concept is expressible.  The blight of
> "flags: A+;" tests permeating snort's rulesets have always struck me as
> a misguided attempt to lazily optimize rule evaluation at the expense
> of correctness and clarity.  I'd love to be educated otherwise [0].

We added sp_clientserver into the detection functionality of Snort in 
the fall of 2002 (version 1.9.0), in the current shipping ruleset there 
are 10 (out of 2500+) rules that still use A+ for whatever reason.  I 
wouldn't exactly call that "permeating".  Back before Snort had TCP 
state tracking and stream reassembly, A+ was a kludge that gave a small 
amount of insight into what was going on for average (non-obfuscated) 
traffic and was in there purely as a performance hack.  In the Old Days 
we tried to keep things simple, it wasn't that I was necessarily 
"lazy", we just didn't have the stream reassembler available to track 
the state explicitly in a scalable and high performance manner so we 
made due with what we had.  Stream reassemblers are tricky to write (to 
put it lightly).

I think most people can agree that recent versions of Snort with 
mechanisms like pcre, byte_test/jump, flowbits and the flow keywords 
provide us with  vastly improved and much more precise analysis 
capabilities over what we had even 18 months ago.  We are highly 
stateful and capable of performing ad hoc protocol decoding with the 
Snort rules language, even keeping application state.  If you haven't 
looked at Snort in a couple years you should probably check out 2.1.3 
and especially check out the rules (like the rules we used to pick up 
LSASS.EXE attacks) and see how far it's come.

> [0] Even more so, I'd love to see the rigorous profiling determining 
> the
> superiority of pre-pruning content matching ops (proportional to 
> payload
> length) for generally payloadless [1] SYN packets vs. memory pressures
> resulting from the additional aggregate page spillage, cache/register
> loads, etc.

Are you talking about the Snort 2.X detection engine or just in general?

     -Marty

--
Martin Roesch - Founder/CTO, Sourcefire Inc. - (410)290-1616
Sourcefire: Intelligent Security Monitoring
roesch () sourcefire com - http://www.sourcefire.com
Snort: Open Source Network IDS - http://www.snort.org


---------------------------------------------------------------------------

---------------------------------------------------------------------------