[Snort-devel] generic vs. unique rules

Andrew Chi achi at ...227...
Fri Jul 11 18:19:10 EDT 2003

after reading http://www.snort.org/docs/RuleManager.pdf, i was still a
little bit confused about conflict problems with generic/unique rules,
and what exactly makes a rule either generic or unique.

how this applies to me:
i've been trying to see why this ruleset had problems:
(i've reduced the commonalities between the rules (certain attributes
that coicided with all of them, such as "flow: to_server", "flags: PA"

alert tcp any any -> any !80 (\
  dsize: 2;\
  content: "HE";\
  msg: "msg1";)

alert tcp any any -> any 80 (\
  content: "PXXXXXXXX";\
  msg: "msg2";)

alert tcp any any -> any 80 (\
  content: "POST ";\
  content: "|0D 0A 0D 0A 07 00 00 00 FF FF FF FF|";\
  offset: 5;\
  msg: "msg3";)

alert tcp any any -> any !25 (\
  dsize: 20;\
  content: "C";\
  msg: "msg4";)

alert tcp any any -> any !25 (\
  dsize: 1;\
  content: "P";\
  msg: "msg5";)

i'm trying to get msg3 to fire, but as it is, using only this ruleset
and no other preprocessors, what would make msg3 fire (if it were the
only rule) doesn't cause msg3 to fire.  however, if i remove any one
of these rules, msg3 will fire.

getting back to the issue:
i understand that a generic rule lacks distinction from other rules in
areas of:
 * tcp/udp (src|dst).ip
 * icmp fields
 * ip fields

so if that was the case, then why isn't there any explanation about
conflicts between generic rules (since there is less differentiation)

now i'm not sure which category this set of rules fall into, since the
content is the main difference, but there are certain other flags that
make them different from the others (ports, dsize, multiple contents),
but nevertheless, it fails to work.

however, removing the dsize flag from either msg4 or msg5 will allow
msg3 to alert.  changing msg2's content from PXXX to XXXX will allow
the msg3 to alert.  there are a host of other minute changes that
allow msg3 to alert normally.

so i'm wondering is this how snort is supposed to perform, or is this
a bug?  if snort is supposed to perform this way, is it possible in a
future release to change the rule "optimizing" engine so that it
performs at a finer level?  also, what src files contain the rule
engine?  is there some kind of debug that prints out rule chain
logical structure (like in http://www.snort.org/docs/lisapaper.txt)?

in any case, sorry for the long message, and thanks to anyone who
actually gets through all of this.


More information about the Snort-devel mailing list