Re: Undocumented parameters to the 'flow' option?

[Joel Esler <jesler () sourcefire com>]

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 () us-cert gov> 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 () sourcefire com] 
> Sent: Friday, December 17, 2010 7:11 PM
> To: Kinard, Joshua A
> Cc: <snort-devel () 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 () us-cert gov> 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 () lists sourceforge net
> > https://lists.sourceforge.net/lists/listinfo/snort-devel

------------------------------------------------------------------------------
Forrester recently released a report on the Return on Investment (ROI) of
Google Apps. They found a 300% ROI, 38%-56% cost savings, and break-even
within 7 months.  Over 3 million businesses have gone Google with Google Apps:
an online email calendar, and document program that's accessible from your 
browser. Read the Forrester report: http://p.sf.net/sfu/googleapps-sfnew
_______________________________________________
Snort-devel mailing list
Snort-devel () lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/snort-devel