Home page logo
/

snort logo Snort mailing list archives

Re: Undocumented parameters to the 'flow' option?
From: <Joshua.Kinard () us-cert gov>
Date: Tue, 21 Dec 2010 17:36:42 -0500


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


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]
AlienVault