[Snort-devel] Undocumented parameters to the 'flow' option?

Joel Esler 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?
> 
> Thanks!,
> 
> --J 
> 
> -----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 
>> allows
>>     snort to do dynamic firewall rulesets.  Experimental for now, so 
>> if
>>     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.,
> 'flow:not_established,to_server;'.
>> 
>> 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,
> however).
>> 
>> 
>> 
>> 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, 
>> csd->or
>> 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:
>> flow:<[established|not_established][,][to_server|from_client|to_client
>> |f 
>> rom_server][,][no_stream|only_stream][,][no_frag|only_frag]>|<stateles
>> s>
>> ;
>> 
>> 
>> 
>> 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'
> parameters.
>> 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
> 'stateless'
>> can be combined with them.
>> 
>> Valid?
>> flow:stateless,no_frag;
>> flow:stateless,only_stream,no_frag;
>> flow:stateless,no_stream,only_frag;
>> 
>> 
>> 
>> 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?
>> 
>> Thanks!,
>> 
>> --J
>> 
>> ----------------------------------------------------------------------
>> --------
>> 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.
>> http://p.sf.net/sfu/lotusphere-d2d
>> _______________________________________________
>> Snort-devel mailing list
>> Snort-devel at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/snort-devel




More information about the Snort-devel mailing list