Snort mailing list archives

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


From: Russ Combs <rcombs () sourcefire com>
Date: Wed, 15 Jun 2011 11:14:15 -0400

Thanks, we'll try to address these before release.

On Wed, Jun 15, 2011 at 2:19 AM, <Joshua.Kinard () us-cert gov> wrote:


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


------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Snort-devel mailing list
Snort-devel () lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/snort-devel


------------------------------------------------------------------------------
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
_______________________________________________
Snort-devel mailing list
Snort-devel () lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/snort-devel

Current thread: