[Snort-users] "Flow:established" rules are never being fired (184.108.40.206)
weberdan at ...11827...
Fri Jan 22 16:58:10 EST 2010
I have a new snort set up, using 220.127.116.11 (although I had the same
issue with 18.104.22.168).
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
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
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
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?
More information about the Snort-users