Re: Flowbits Set and Not Checked Against SRC/DSTNetworks

[<Joshua.Kinard () us-cert gov>]

It is my understanding that 'flow:stateless' on a TCP rule with 'flowbits' is non-sensical -- it should, in fact, throw 
a fatal error (but doesn't currently).  Snort would need an established session present before it can apply 'flowbits', 
and since the SYN packet usually defines the start of a TCP session, you're basically asking the chicken which came 
first, it or the egg it hatched from.

Of course, how Snort handles 'flow' on UDP is a bit of a mystery to me.  Never tried 'flowbits' on a UDP rule before, 
but the documentation suggests it is possible.  UDP packets are basically stateless by virtue of the protocol's design.

There is a formerly-undocumented option to 'flow' that might be worth trying: 'not_established'.  It works well when 
you play back PCAP files that exclude the TCP handshake, due to how the packets were logged.  But likely, if you are 
looking for the first SYN packet, 'flags:S,CE;' will probably be the best bet.


As for this bug report itself, if I am reading correctly, does this affect ALL uses of 'flowbits', such that it fails 
to check the IP/Port pairing in a flow to guarantee uniqueness before checking the flowbits?  My understanding based on 
the manual and much Google-searching (because the manual is quite vague on this point), is that 'flowbits' are unique 
*per-flow*.  Thus, if there is a bug that treats all flows as non-unique (because of a failure to check the IP/port 
pairs), it effectively disables flowbits and could cause a large ruleset to cease working.


Cheers!,

--J

 

-----Original Message-----
From: Martin Holste [mailto:mcholste () gmail com] 
Sent: Monday, June 27, 2011 12:15 PM
To: beenph
Cc: bugs () snort org; snort-devel () lists sourceforge net
Subject: Re: [Snort-devel] Flowbits Set and Not Checked Against SRC/DSTNetworks

Hm, forgot about stateless.  Eoin, do you recall if we tried stateless
as opposed to flags:S to improve performance over flags:A+?  I would
think that stateless=flags:S for our purposes.

On Mon, Jun 27, 2011 at 11:09 AM, beenph <beenph () gmail com> wrote:
> On Fri, Jun 24, 2011 at 4:10 PM, Eoin Miller
> <eoin.miller () trojanedbinaries com> wrote:
> > We were having some issues when setting flowbits for sessions based upon IP lists. I think I have narrowed down the 
> > problem after creating and running these rules:
> >
> > alert tcp $HOME_NET any <> [127.0.0.1,127.0.0.2,127.0.0.3,127.1.0.0/24,127.2.0.0/24,127.127.0.0/16] any (msg:"TEST 
> > talking to localhost"; flags:S; flowbits:set,AOL.test; classtype:bad-unknown; sid:7000004; rev:1;)
> > alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"TEST http_uri to localhost"; flowbits:isset,AOL.test; 
> > content:"/"; http_uri; classtype:bad-unknown; sid:7000005; rev:1;)
> >
> > The first rule never creates alerting output. But the second rule will fire on every HTTP request from our client 
> > net while these are both running. What I think is occurring is that the packet causes an alert and a flowbit to be 
> > set for the stream because it sees the initial SYN packet (which is true). But the alert output is never created 
> > because it is actually checked against the SRC/DST networks in the rule and therefor it gets suppressed. But, the 
> > flowbit must not be getting compared against the SRC/DST network ranges and ports and unset if it doesn't match. Can 
> > I bug you guys to take a look into this?
>
> If you change your first rule to the following rules
> alert tcp $HOME_NET any ->
> [127.0.0.1,127.0.0.2,127.0.0.3,127.1.0.0/24,127.2.0.0/24,127.127.0.0/16]
> any (msg:"TEST talking to localhost"; flags:S; flowbits:set,AOL.test;
> flow:stateless ;classtype:bad-unknown; sid:7000003; rev:2;)
> alert tcp [127.0.0.1,127.0.0.2,127.0.0.3,127.1.0.0/24,127.2.0.0/24,127.127.0.0/16]
> any -> $HOME_NET any (msg:"TEST talking to localhost"; flags:S;
> flowbits:set,AOL.test; flow:stateless ;classtype:bad-unknown;
> sid:7000004; rev:2;)
>
> If you change your second rule from from:
>
> alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"TEST
> http_uri to localhost"; flowbits:isset,AOL.test; content:"/";
> http_uri; classtype:bad-unknown; sid:7000005; rev:1;)
> to
> alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"TEST
> http_uri to localhost"; flowbits:isset,AOL.test; content:"/";
> http_uri; classtype:bad-unknown; sid:7000005; flow:established;
> rev:2;)
>
> Do you have any changes to results?
>
> Assertion that source/dest is not checked is not what i see from the
> code stack (i might interpret it wrong) but
> mabey there is an issue with
> CheckBidirectional(Packet *p, struct _RuleTreeNode *rtn_idx,
>        RuleFpList *fp_list, int check_ports)
>
> 0.02 cents.
> -elz
>
> ------------------------------------------------------------------------------
> All of the data generated in your IT infrastructure is seriously valuable.
> Why? It contains a definitive record of application performance, security
> threats, fraudulent activity, and more. Splunk takes this data and makes
> sense of it. IT sense. And common sense.
> http://p.sf.net/sfu/splunk-d2d-c2
> _______________________________________________
> Snort-devel mailing list
> Snort-devel () lists sourceforge net
> https://lists.sourceforge.net/lists/listinfo/snort-devel

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Snort-devel mailing list
Snort-devel () lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/snort-devel

------------------------------------------------------------------------------
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
_______________________________________________
Snort-devel mailing list
Snort-devel () lists sourceforge net
https://lists.sourceforge.net/lists/listinfo/snort-devel