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
---------------------------------------------------------------------------
---------------------------------------------------------------------------
Received on Jun 07 2004
Intro
