RE: A question about flow:established keyword

["Shadi Rostami" <shadi () inkra com>]

Hello Eric,
Thanks for your reply. This is the definition that I find for "established" in that chapter:
"established 
trigger only on established TCP connections "

It also says
"The established keyword will replace the flags: A+ used in many places to show established TCP connections."
However, it does not necessarily mean that "established" is the same as A+. I can say that "established" is a superset 
of A+. Because after 3-way handshaking is done,  and connection is established, all the packets would have Ack bit set.
However, if you just send a single packet with Ack bit set (without establishing the connection), Snort will not look 
in that packet for signatures that has flow:established in them. Am I right?

About 2-hour timeout, as you said it is a very long timeout, and I may end up keeping a lot of states that causes my 
stream4 engine to run out of memory.
Also, an admin may not know about the timeout of all servers that accept tcp connections.

Thanks
--Shadi

-----Original Message-----
From: Erick Mechler [mailto:emechler () techometer net]
Sent: Wednesday, March 26, 2003 3:57 PM
To: Shadi Rostami
Cc: snort-users () lists sourceforge net
Subject: Re: [Snort-users] A question about flow:established keyword


:: [Shadi Rostami] It is not just looking for A+. I believe it checks if TCP 3way-handshaking is done. 
:: This feature is added to protect snort against stick and snot tools, I think. Those tool were trying to send tcp 
packets with attack signatures without creating real tcp connection (therefore, they could send lots of them very 
fast). They can cause lots of false positive in the IDS, so the administrator would be overwhelmed and won't be able to 
find the real attack in the log file.

http://www.snort.org/docs/writing_rules/chap2.html#tth_sEc2.3.36

This section of the manual says that the established keyword, when used
with the stream reassembly preprocessor, is functionally equivalent to
looking for "A+" flags.

:: [Shadi Rostami] That document mentions that there is a timeout for
:: stream4 preprocessor. However, it does not saying anything about my
:: specific problem.

Well, to address your specific concern (which I didn't do in my first
post), the solution is to make sure that your preprocessor timeout is set
to something greater than the amount of time it would take for established
sessions to send a timeout on your network.  Eg, if A has an established
TCP connection to B, you want to know how long it will take A to send a
keep-alive packet back to B after a period of inactivity.  If you see the
keep-alive packet sent, it should reset your timer in the stream
preprocessor.

For my FreeBSD 4.8-RC system, the default is 2 hours (net.inet.tcp.keepidle
sysctl).  It appears that it's the same for Windows 2000 as well:

  http://support.microsoft.com/default.aspx?scid=kb;en-us;315669

So, depending on your environment, it would seem that something around 2 
hours is what would be necessary.  However, also depending on your 
environment, 2 hours could result in gi-normous state tables :)

I realize my first post didn't really answer your question; sorry about
that.  Hopefully this one is a bit better.

Cheers - Erick



-------------------------------------------------------
This SF.net email is sponsored by:
The Definitive IT and Networking Event. Be There!
NetWorld+Interop Las Vegas 2003 -- Register today!
http://ads.sourceforge.net/cgi-bin/redirect.pl?keyn0001en
_______________________________________________
Snort-users mailing list
Snort-users () lists sourceforge net
Go to this URL to change user options or unsubscribe:
https://lists.sourceforge.net/lists/listinfo/snort-users
Snort-users list archive:
http://www.geocrawler.com/redir-sf.php3?list=snort-users