[Snort-devel] Config Stateful Issue
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.
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
"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,
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...
More information about the Snort-devel