[Snort-devel] Config Stateful Issue

Joel Ebrahimi jebrahimi at ...2857...
Sun Feb 12 21:44:01 EST 2006

Does flow:established behave the same way as enforce_state (ie, seeing the complete 3 way handshake before marking established) or how config: stateful would (ie, seeing some non RST response from the server). I dont see a definitive answer in the docs but Im presuming from what Brian said its the same as enforce_state (except being applied on a per rule basis).
If thats the case the only nice thing about config stateful is it determines to some extent valid sessions where packets may have been dropped in the 3 way handshake. But really if your dropping packets your not providing adequate security coverage already.
I guess depending on the answer to the first part above it could ultimately be argued that both config stateful and enforce_state should/could be removed and the in rule option flow would be best suited to handle this all on a per rule basis.
// Joel

From: Brian Caswell [mailto:bmc at ...835...]
Sent: Sun 2/12/2006 2:17 PM
To: Steven Sturges
Cc: Joel Ebrahimi; Eric Lauzon; snort-devel at lists.sourceforge.net
Subject: Re: [Snort-devel] Config Stateful Issue

On Feb 10, 2006, at 5:13 PM, Steven Sturges wrote: 
> I'm all in favor of removing config stateful entirely, 
> because it has added all sorts of confusion with the 
> addition of the enforce_state (a while ago, mind you) to 
> Stream4. 

"config stateful" has always been dumb.  I voiced that complaint many  
years ago.  As per Snort's manual, using "config stateful" or the -z  
command line option has been superseded by "flow:established;" since  

The implementation of "enforce_state" leaves much to be desired.  The  
idea is to disregard sessions that Snort doesn't see the complete  
session.  While this feature protects Snort's performance in harsh  
deployments, it alters how rules are processed in a manor that it  
should not.  The following rule, as written, should match all TCP  
packets, regardless of state of a session. 

        alert tcp any any -> any any (content:"bmc is awesome";) 

However, using "enforce_state", as documented earlier in this thread,  
does not. 

As I see it, this is not really a voting matter.  One side of the  
house induces a side-effect that breaks rules as written, whilst the  
other does not. 

BTW, some might say "flow" and "uricontent" also exhibit the same  
behavior, however these keywords have inherent prerequisites. 


No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.1.375 / Virus Database: 267.15.6/257 - Release Date: 2/10/2006

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-devel/attachments/20060212/dbb8d32e/attachment.html>

More information about the Snort-devel mailing list