[Snort-users] "Flow:established" rules are never being fired (2.8.5.2)

Alex Kirk akirk at ...1935...
Fri Jan 22 17:06:02 EST 2010


Not knowing anything about your current setup, something that strikes me as
a distinct possibility: are you running Snort on the same box that the
initial SYN is being sent from? If so, you're probably having checksum
issues (since packets get sent to Snort before they're sent to the layer of
the stack that computes checksums). If you are running in a setup like this,
try running snort with "-k none" to ignore checksums.

On Fri, Jan 22, 2010 at 4:58 PM, Dan Weber <weberdan at ...11827...> wrote:

> List,
>
> I have a new snort set up, using 2.8.5.2 (although I had the same
> issue with 2.8.5.1).
>
> Rules with "flow:established" are not being triggered.  For example,
> of these dummy rules for web traffic:
>
> <<<
> alert tcp any any -> any 80 (msg:"tiny";
> content:"alpha="; sid:11; rev:1;)
> alert tcp any any -> any 80 (msg:"tiny 1"; flow:to_server;
> content:"bravo="; sid:22; rev:1;)
> alert tcp any any -> any 80 (msg:"tiny 2"; flow:established;
> content:"charlie="; sid:33; rev:1;)
> alert tcp any any -> any 80 (msg:"tiny 3"; flow:to_server,
> established; content:"delta="; sid:44; rev:1;)
> <<<
>
> I can get "tiny" and "tiny 1" to trigger, but not the latter two.
>
> My stream5 lines from my snort.conf say:
>
> <<<
> preprocessor stream5_global: max_tcp 8192, track_tcp yes, \
>                            track_udp yes, track_icmp no
> preprocessor stream5_tcp:
> preprocessor stream5_udp:
> <<<
>
> Snort is seeing all three packets of the SYN - SYNACK - ACK handshake.
>  By all rights, it *should* have considered the connection started.
>
> I've spent a few hours going through the source to see where my
> problem is.  In src/preprocessors/Stream5/snort_stream5_tcp.c, it
> seems that the function ProcessTcp() calls NewTcpSession() in three
> (general) circumstances: if the packet has SYN but not ACK set, if it
> has both SYN and ACK set, and if it has ACK but not RST set while in a
> SYN_ACK state.
>
> I've traced that the first two packets of the three-way handshake are
> being set to NewTcpSession(), but the third is not.
>
> Furthermore, at the very top of ProcessTcp() I look at the
> Stream5LWSession->session_state variable.  With the first packet it is
> STREAM5_STATE_SYN, but for processing the next two packets the state
> is STREAM5_STATE_NONE.
>
> My current theory is that, somehow, the first SYN packet isn't being
> put into the data structure needed for the second packet to realize it
> should match it.  I haven't dug into this yet and haven't dived into
> the code to figure it out.  But at this point I figured I would ask
> for help.  I saw people asking for with with "no rules getting
> flow:established" in old archives.
>
> Is there something obvious I'm missing that I should look at before
> examining more code?
>
> Failing that, should I go looking for how Stream5 matches up a SYNACK
> to a prior SYN, or is that a tree up which I shouldn't bark?
>
>
> ------------------------------------------------------------------------------
> Throughout its 18-year history, RSA Conference consistently attracts the
> world's best and brightest in the field, creating opportunities for
> Conference
> attendees to learn about information security's most important issues
> through
> interactions with peers, luminaries and emerging and established companies.
> http://p.sf.net/sfu/rsaconf-dev2dev
> _______________________________________________
> 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=snort-users
>



-- 
Alex Kirk
AEGIS Program Lead
Sourcefire Vulnerability Research Team
+1-410-423-1937
alex.kirk at ...1935...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.snort.org/pipermail/snort-users/attachments/20100122/964be10f/attachment.html>


More information about the Snort-users mailing list