[Snort-devel] Config Stateful Issue

Eric Lauzon eric.lauzon at ...1967...
Fri Feb 10 18:16:00 EST 2006

Well as of mid sessions capture
What is the worst case senario you can encounter , and drop those inline idea from the perspective?

Also if you remove config statefull dont you think it might break some legacy behavior?

Anyhow as long as there is a good and documented way of how statefull / stream4 stream behavior is implemented 
and what is the default behavior i wouldn't really mind of seeing -z/config statefull going away but as i see it

(-z/config stateful PRECEDE [enforce_state / state_protection]) so if the packet goes in 
with config stateful ["mid session"] but is not considered as is by stream4 it will be droped anyways,
major overhead? Redundency? ..probably depends on what you want to do , if you are doing state inspection
mabey , what if the engine uses stream4 but might also want to inspect out of session packets as what you
where trying to do joel .. i guess its hard to see the hole picture because it depend on setup/instance needs.

But im sure some firegod(holding the source of fire ..[friday]) will sort this out.

Have a good week-end.


From: Joel Ebrahimi [mailto:jebrahimi at ...2857...] 
Sent: 10 février 2006 20:59
To: Steven Sturges
Cc: Eric Lauzon; snort-devel at lists.sourceforge.net
Subject: RE: [Snort-devel] Config Stateful Issue

	Well I think some it of is confusing due to the current bug and some of the documentation or lack of, but after re-reading everything and going through your emails I dont nesacarily think the 'config stateless' is a bad thing that should go away. 
	In the case where a deployment is brought up you would have a number of mid-streams sessions and there is always the potential to drop a packet when Snort is running in a passive sniff mode. My interpretation had been 'config stateful' would have required the 3 way handshake but then that would make enforce_state redundant. And it also makes sense why Snort would alert on the previous pcap since there had been replies from a server.Maybe better documenatation explaining what set stateful is actaully looking for other than established connections would help.
	Now if the Snort was running in inline mode than config stateful would not really make sense other than catching the initial mid-stream connections, but considering how you can never really can tell how someone could be deploying Snort from an inline sensor to a  underpowered sensor that cant keep up with the current traffic having the config stateful seems beneficial.
	// Joel


	From: Steven Sturges [mailto:steve.sturges at ...402...]
	Sent: Fri 2/10/2006 2:13 PM
	To: Joel Ebrahimi
	Cc: Eric Lauzon; snort-devel at lists.sourceforge.net
	Subject: Re: [Snort-devel] Config Stateful Issue

	Joel, Eric, et al... 

	The Stream4 code sometimes marks a session as established. 
	This occurs when a session is picked up midstream and 
	we've seen both sides of the connection.  We attempt to 
	determine the correct TCP state on these sessions in the 
	case of dropped packets -- or in your case, a PCAP that 
	is deliberately missing the SYN/SYN-ACK.  See line 3200 
	(or so) of spp_stream4.c. 

	Turning on enforce_state in Stream4 config causes Stream4 
	to only mark sessions as established when it sees the 
	full 3WHS. 

	config stateful really only makes sense in that context 
	because the stream can be marked as established because 
	of midstream pickups. 

	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 

	Any votes on the matter?


Le présent message est à l'usage exclusif du ou des destinataires mentionnés ci-dessus. Son contenu est confidentiel et peut être assujetti au secret professionnel. Si vous avez reçu le présent message par erreur, veuillez nous en aviser immédiatement et le détruire en vous abstenant d'en faire une copie, d'en divulguer le contenu ou d'y donner suite.


This communication is intended for the exclusive use of the addressee identified above. Its content is confidential and may contain privileged information. If you have received this communication by error, please notify the sender and delete the message without copying or disclosing it.

More information about the Snort-devel mailing list