[Snort-users] A question about flow:established keyword

Risto Vaarandi risto.vaarandi at ...5731...
Fri May 9 07:32:10 EDT 2003

Shadi Rostami wrote:
> 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.

I run into the same problem recently and at least for me it looks like 
that flags:A+ and established are not identical. For example, the 
difference comes out when the snort is able to observe only the incoming 
traffic, but not the outcoming. In that case flags:A+ will produce 
alerts, while flow:established will not (this is what I have found when 
playing with snort).


> Thanks
> --Shadi
> -----Original Message-----
> From: Erick Mechler [mailto:emechler at ...7719...]
> Sent: Wednesday, March 26, 2003 3:57 PM
> To: Shadi Rostami
> Cc: snort-users at 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 at 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

More information about the Snort-users mailing list