{"shas":[["81a6a2b8896d8f7e62e4160004809ad8fd9e245b","035f816d23c808f99c8380c415b2522f8ae625cf@cipherdyne.org","Added content match ordering based on length\n\nIn cases where the 'fast_pattern' option is not used, Snort generally tries to\npick the longest pattern to match first since this should usually result in\nbetter performance.  That is, longer there is a higher chance for a longer\nstring to be more unique, and this would result in shorter strings from not\nbeing searched for.  This works in the context of iptables because 'matches'\nare AND'd togther, so if the first string match fails, no subsequent string\nmatches will be executed.  Hence, the search for \"shortstr\" below would not\nhappen if the search for \"thisisalongstring\" failed:\n\n-m string --string 'thisisalongstring' --algo bm -m string --string 'shortstr' --algo bm\n\nOne thing to note is that iptables does not support relative string matches\nin the same way that Snort does.  The iptables string match can specify an\noffset and depth into the packet via --from and --to.  The end result is that\nthe fwsnort way of maximizing performance is to find the longest string, do\nthe match, and apply an approximation for --from and --to whenever they are\nrequired for any pattern.  That is, it doesn't have to worry about relative\nmatches and finding the end of a pattern in order to know where to start the\nnext search.  Now, this will result in signature matching in fwsnort not\nbeing as accurate as Snort (remember that fwsnort emulates Snort behavior as\nclosely as possible given functionality implemented in iptables), but it\nshould be faster.","Michael Rash"],["1e024f14f34453eb992fa9370dd4f04b02374074","035f816d23c808f99c8380c415b2522f8ae625cf@cipherdyne.org","minor comment wording update for TCP options","Michael Rash"]],"ref":"refs/heads/master","size":2,"head":"1e024f14f34453eb992fa9370dd4f04b02374074","push_id":35788890}