[Snort-users] "Flow:established" rules are never being fired (22.214.171.124)
weberdan at ...11827...
Fri Jan 22 17:20:27 EST 2010
Thanks for the suggestion. Yes, I am sending the SYN from the snort
box itself, but I already put in "-k none". I also checked when
passing a packet through the box, and I get a similar behavior.
Launching it with ./snort -c /var/aef/snort-drop.conf -k none -U -y -J 500
On Fri, Jan 22, 2010 at 5:06 PM, Alex Kirk <akirk at ...1935...> wrote:
> 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:
>> I have a new snort set up, using 126.96.36.199 (although I had the same
>> issue with 188.8.131.52).
>> 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
>> attendees to learn about information security's most important issues
>> interactions with peers, luminaries and emerging and established
>> Snort-users mailing list
>> Snort-users at lists.sourceforge.net
>> Go to this URL to change user options or unsubscribe:
>> Snort-users list archive:
> Alex Kirk
> AEGIS Program Lead
> Sourcefire Vulnerability Research Team
> alex.kirk at ...1935...
More information about the Snort-users