[Snort-devel] [PATCH]: Snort manual fixes for 2.9.1-beta

Joshua.Kinard at ...3108... Joshua.Kinard at ...3108...
Wed Jun 15 02:19:15 EDT 2011


Hi snort-devel,

I've worked up three additional patches for the Snort manual to clarify
two little details and fix a typo.


snort-291beta-manual-fast_pattern-no_http_method.patch:

Per discussion earlier on the mailing list and the latest entry in the
ChangeLog, 'http_method' is no longer compatible with the 'fast_pattern'
modifier.  This patch annotates 'http_method' to indicate this.  It also
adds a mention to 'fast_pattern'.

It also removes the following line:
"Note, however, that it is okay to use the fast pattern modifier if
another http content modifier not mentioned above is used in combination
with one of the above to modify the same content."

I cannot ever foresee such a scenario where one would use two distinct
HTTP modifiers on the same content:
(content:"foobar"; http_header; http_client_body;)

This lines up with the change I submitted a few months ago to clarify
'uricontent', which states that 'uricontent' is not compatible with any
of the other HTTP modifiers.

I've done scans through the VRT rule set as of April 2011 and the
Emerging Threats all-rules files, and cannot find this particular
construct in use (but I did not do thorough scans).



snort-291beta-manual-flowbits-with-tag.patch:

The example under 'tag' that describes using two 'flowbits' keywords to
allow tag to work correctly need a clarification of /where/ to place
them.  The example currently reads:

alert tcp any any <> 10.1.1.1 any (flowbits:isnotset,tagged;
flowbits:set,tagged; tag:host,600,seconds,src;)

This does not offer any guidance on where to place any payload detection
keywords.  Before?  After?  The patch fixes this and changes this
example to:

alert tcp any any <> 10.1.1.1 any (flowbits:isnotset,tagged;
content:"foobar"; nocase; flowbits:set,tagged;
tag:host,600,seconds,src;)

The idea being the first flowbit will check that the 'tagged' state is
set, and if not, allow the content check to procede BEFORE setting the
tagged state.  That way, if the content check fails, the flowbit state
will not get set on that flow (incase a further packet down the line has
the content being searched for).  If the content check succeeds, then
the 'tagged' state is set so that subsequent alerts will not reset the
tagging.



snort-291beta-manual-tag-flags-example.patch:

This is a minor typo fix just after the 'tag' fix above:

alert tcp any any -> any 23 (flags:s,CE; tag:session,10,seconds;)

The 's' in 'flags' is converted to uppercase.



Cheers!,

--J
-------------- next part --------------
A non-text attachment was scrubbed...
Name: snort-291beta-manual-tag-flags-example.patch
Type: application/octet-stream
Size: 571 bytes
Desc: snort-291beta-manual-tag-flags-example.patch
URL: <https://lists.snort.org/pipermail/snort-devel/attachments/20110615/67bd0e3e/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: snort-291beta-manual-fast_pattern-no_http_method.patch
Type: application/octet-stream
Size: 1239 bytes
Desc: snort-291beta-manual-fast_pattern-no_http_method.patch
URL: <https://lists.snort.org/pipermail/snort-devel/attachments/20110615/67bd0e3e/attachment-0001.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: snort-291beta-manual-flowbits-with-tag.patch
Type: application/octet-stream
Size: 733 bytes
Desc: snort-291beta-manual-flowbits-with-tag.patch
URL: <https://lists.snort.org/pipermail/snort-devel/attachments/20110615/67bd0e3e/attachment-0002.obj>


More information about the Snort-devel mailing list