[Snort-devel] Undocumented parameters to the 'flow' option?
jesler at ...402...
Tue Dec 21 17:59:03 EST 2010
We've already targeted this bug for an upcoming version. Thanks Joshua!
Sent from my iPhone
On Dec 21, 2010, at 5:36 PM, <Joshua.Kinard at ...3108...> wrote:
> Any updates to this bit so I can get some feedback to cook up a patch?
> -----Original Message-----
> From: Joel Esler [mailto:jesler at ...402...]
> Sent: Friday, December 17, 2010 7:11 PM
> To: Kinard, Joshua A
> Cc: <snort-devel at lists.sourceforge.net>
> Subject: Re: [Snort-devel] Undocumented parameters to the 'flow' option?
> This is the best kind of feedback!
> I'll file a bug to get these put in the manual/ fixed.
> Sent from my iPhone
> On Dec 17, 2010, at 6:15 PM, <Joshua.Kinard at ...3108...> wrote:
>> Hi snort-devel,
>> I was looking to understand the 'flow' keyword a bit better, so I look
>> a look at its source code, and noticed the presence of three
>> undocumented options (not covered in Snort or SourceFire
>> documentation). This raises some questions regarding usage.
>> The three options are 'not_established', 'no_frag', and 'only_frag'.
>> The 'not_established' parameter was added back in Sep of 2004 it
>> looks, and doesn't have a lot of information other than what is in the
>> changelog (Rev 1.337 in CVS). It states the following:
>> * src/detection_plugins/sp_clientserver.c:
>> Add not_established keyword to the flow detection option. This
>> snort to do dynamic firewall rulesets. Experimental for now, so
>> any wants to try let me know.
>> This suggests that the 'not_established' keyword allows for usage
>> where a stream is not fully established (perhaps a PCAP fragment
>> wherein the TCP handshake is missing). I.e.,
>> Is this still considered an experimental parameter, or does it have
>> valid use? I do not see it being used in a snapshot of either ET
>> rules or VRT rules (both snapshots are at least 2 months old,
>> Regarding the 'no_frag' and 'only_frag' parameters, they were added in
>> Oct of 2008, and their Changelog entry offers no information on their
>> exact purpose. Both look like they tweak the same struct members as
>> 'no_stream' and 'only_stream' (csd->ignore_reassembled and
>> csd->only_reassembled, respectively). Are they experimental as well,
>> supplanted by the 'fragbits' option in any form or fashion? I also do
>> not see them being used in any ET or VRT rulesets either.
>> I also assume that 'no_frag' and 'only_frag' constitute a fourth
>> parameter set to 'flow', i.e.,
>> 'flow:established,to_server,only_stream,no_frag;'. Correct? If so, I
>> assume a proper documentation example would be:
>> Regarding the 'stateless' parameter, there are checks in
>> src/detection-plugins/sp_clientserver.c to make sure that 'stateless'
>> is not used with the to_server/from_server/to_client/from_client
>> parameters as well as with the 'established' or 'not_established'
>> There are no checks for 'stateless' against either the 'no_stream' and
>> 'only_stream' or 'no_frag' and 'only_frag' parameters.
>> The first set of checks suggests to me that 'stateless' can only be
>> used by itself, i.e., 'flow:stateless;'. But lacking any checks on
>> the stream/frag parameters, this begs the question on whether
>> can be combined with them.
>> If I can get these inquiries clarified, I can work on a patch for the
>> documentation and to fixup sp_clientserver.c a little bit in the
>> parsing function. There are some other bits in that function that
>> could use some TLC, so I want to roll them into a single patch.
>> Lastly, Was the blurb from the SourceFire manual regarding 'flow' and
>> UDP traffic morphed into something for the Snort manual? Do any of
>> these three undocumented options apply at all to UDP traffic?
>> Lotusphere 2011
>> Register now for Lotusphere 2011 and learn how to connect the dots,
>> take your collaborative environment to the next level, and enter the
>> era of Social Business.
>> Snort-devel mailing list
>> Snort-devel at lists.sourceforge.net
More information about the Snort-devel