On Mon, 2005-05-09 at 16:03 +1000, Erik de Castro Lopo wrote:
1) Both content and pcre searches update the same current
position pointer to be equal to the end of any matches
they make.
I hope this helps.
It's sinking in now :) Thanks for digging into the code. According to
above both of the following appear to be valid (if not, speak up:
content - pcre /R (which will match from the end of the content match.
Any distance will have to be done within the regex)
pcre - content - distance/within (which will match content within range
after a distance from the pcre match)
I assume that the pcre ends with the first match. (i.e. pcre:"/a/"; will
match on a packet with "aaaaabbbb" on the first a, which would mean a
following content match at distance 0 would hit an "a" and not a "b").
If the above are correct, then shouldn't we be able to split pcre
matches in order to improve processing speed?
For example: SID 2001401 of the Bleeding rules contains:
pcre:"/(EMBED|FRAME|SRC|NAME)\s*=\s*["']\w{2086}|\W{2086}/im"
Wouldn't it save processing cycles to split this into:
pcre:"/(EMBED|FRAME|SRC|NAME)/im"; pcre:"/\s*=\s*["']\w{2086}|
\W{2086}/imR";
That way, it EMBED or FRAME or SRC or NAME was not found, it would end
the search and not even further match any additional regex which may be
complex and nested and drive processing time up.
On the other hand, does a second regex incur additional processing cost
for again calling the pcre functions within Snort? Where would the
balance be and when would it be advisable to split the regex and when
not?
And finally, when does "The Art of Snort Tuning" appear in the book
stores? ;)
Later,
Frank
signature.asc
Description: This is a digitally signed message part
