[Snort-devel] Order of stream_size and dsize checks?
kumba at ...2185...
Fri Mar 21 18:54:21 EDT 2014
On 03/21/2014 2:22 PM, snort user wrote:
> Joel -
> Could you please explain how the placing of stream_size or dsize will speed
> up evaluation of the rule? I can see that placing it upfront will eliminate
> evaluation of the more expensive options such as content or pcre, but is
> there some other aspect that will make the rule evaluation more faster with
> these rule options placed upfront?
> On Fri, Mar 21, 2014 at 2:11 PM, Joel Esler (jesler) <jesler at ...3461...>wrote:
>> You bring up a good point though, Harley, which is basically, if you put
>> those checks first in the rule (before the content match) it can speed up
>> the evaluation of the traffic by that rule.
>> *Joel Esler*
>> Open Source Manager
>> Threat Intelligence Team Lead
>> Vulnerability Research Team
>> On Mar 21, 2014, at 12:06 PM, Steven Sturges <
>> steve.sturges at ...402...> wrote:
>> Rule options are evaluated in the order specified in the rule.
>> On 3/21/14, 11:56 AM, Harley H wrote:
>> Are stream_size and dsize checked following any or all content
>> matches or are they performed first?
"dsize" is one of the "discrete" options. See Pg 229 in the back of the
Snort 188.8.131.52 manual for a complete list of current discrete keywords. Most
of them are checking specific numerical or flag/byte values in layer 3 & 4
(OSI Model) protocol headers. These should *always* go before any
Section 3.9.4 has a really good example of how content's recursion can cause
unneeded checks if you have a small pattern, but possibly large payload, and
you don't check the size of the payload w/ dsize before searching for the
As for whether stream_size is a discrete keyword...I am not certain. I've
always treated it more as a payload-based keyword. I suppose that since the
Stream5 Preprocessor sets up the data structure that keyword checks, it
could be considered discrete, similar to the flow and dsize keywords (which
are also calculated values, not present in the protocol headers in most cases).
Also, while we're on the topic, make sure for flowbits, that you treat it
more like an "if" conditional and place your isset/isnotset flowbits
keywords before payload checks (but after any discrete keywords). Place
remaining flowbits checks (set, setx, unset, toggle, reset, and noalert)
after the payload. This further optimizes and allows the detection engine
to bail early if a packet doesn't match.
Generally, I group Snort keywords into four categories: discrete, payload,
post-detection, & documentation. I thus write most rules like this:
<rule header> (msg:<msg>; sid:<sid>; rev:<rev>; <discrete> <payload>
Discrete, see above. Payload keywords, are pretty much *anything* that
operates on, touches, or manipulates payload data (flowbits keywords are
payload operations to me). Post-detection keywords include the likes of
threshold, detection_filter (even though this operates in the payload
checking phase, it doesn't touch payload), tag, logto, session, resp, react,
etc. Documentation keywords have no functionality (that I know of) on a
rule's operation and their performance is mostly limited to the parsing
phase at Snort start-up: metadata, reference, & priority.
I further lump msg, sid, rev, gid, & classtype as "core" options that are
usually always required in a rule (gid being the one exception; it's not
specifically required, but is internally assumed to be '1' if not present).
kumba at ...2185...
"The past tempts us, the present confuses us, the future frightens us. And
our lives slip away, moment by moment, lost in that vast, terrible in-between."
--Emperor Turhan, Centauri Republic
More information about the Snort-devel