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:
- [PATCH]: Snort manual fixes for 2.9.1-beta Joshua.Kinard (Jun 14)
- Re: [PATCH]: Snort manual fixes for 2.9.1-beta Russ Combs (Jun 15)