Home page logo
/

snort logo Snort mailing list archives

Undocumented parameters to the 'flow' option?
From: <Joshua.Kinard () us-cert gov>
Date: Fri, 17 Dec 2010 18:15:59 -0500


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, 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]>|<stateless>
;



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


  By Date           By Thread  

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