[Snort-sigs] SO rules vs regular rules

Patrick Mullen pmullen at ...435...
Wed Feb 3 13:50:08 EST 2010

> If you are planning on using the converter published at
> labs.snort.org, you will not see any performance gain for straight
> translation of rules to shared objects.  In all practical terms, the
> detection from the shared object rules using the output the converter
> are exactly the same as textual rules.

Do not use the converter present on Snort Labs to convert standard
text rules to SO rules in an effort to improve detection speed.  The
automatically generated detection function does not implement looping
or "back stepping" like a normal text rule does and could introduce
false negatives.  This does *NOT* imply that the SO rules we ship do
not have these features -- the version online has a very minor
difference from the one we use internally so I (we) don't need to
explain a minor code change that needs to be done to use the custom
detection function rather than the built-in detection functions.

To explain what I'm talking about, imagine the following rule fragment:

content:"A"; content:"B"; distance:3; within:1;

And the packet data:


Without looping and back checking, as done in the autogenerated
detection rule from the online snort rules to SO rules converter, the
first content match would match on the first "A" then check the second
content match and see "2" and return RULE_NOMATCH.  With looping
(something you can easily add manually but is beyond the scope of the
SO Rules generator), when the second content match failed, it would
retry the first content match and find the second "A".  From there, it
would check the second content match and successfully find the "B" and
return RULE_MATCH.

If you're interested, the change to make the converted SO rule operate
like a text rule is to set the function pointer within the Rule struct
to NULL.  This will tell snort to use the internal detection functions
and will never call the ruleXXXXeval() function.

But as Brian said, it won't improve performance anyway.  I just wanted
to explain why you wouldn't want to do it from a purely
detection/functional point of view.



More information about the Snort-sigs mailing list