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

George Yunaev gyunaev at ...14734...
Fri Jan 22 17:23:33 EST 2010


Hi all,

I would add that this problem looks very similar to one I described some time 
ago with "Content rule matches on PCAP but does not match when snort listens" 
subject.

> 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:
> >> 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...
> 
> ---------------------------------------------------------------------------
> --- 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
> 
-- 
With best regards, George.
http://www.kchmviewer.net - the first CHM files viewer for Qt/KDE.




More information about the Snort-users mailing list