[Snort-devel] Config Stateful Issue
bwalder at ...1455...
Sun Feb 12 23:17:06 EST 2006
The requirement to handle mid-flows correctly is not dependent on whether or
not an in-line IPS drops packets - when the device is powered up in-line it
will probably come up mid-session for some users. Strictly enforcing the
3-way handshake would kill those sessions (not too much of a problem - they
will simply retry if they are legitimate and will then succeed)
However, NOT enforcing the 3-way handshake will leave a device open to
raising many alerts on stateless exploit tools such as Stick/Snot.
IMHO the best solution is to strictly enforce 3-way handshake except for an
admin-defined grace period following power cycle (giving time for previously
established sessions to complete). Couple this with a signature/state
analyser which alerts when it sees a mid-flow (and blocks it) and you have
all bases covered
The NSS Group
On 13/2/06 06:49, "Joel Ebrahimi" <jebrahimi at ...2857...> wrote:
> 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
> // 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
> "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
More information about the Snort-devel