[Snort-devel] Flowbits Set and Not Checked Against SRC/DST Networks

Martin Holste mcholste at ...2499...
Mon Jun 27 11:01:09 EDT 2011


I understand you guys have standard bug-filing protocols, but a pcap
isn't really relevant here.  If you have a rule that solely checks for
a SYN flag and you set a flowbit for it, that flowbit will be
erroneously attached to ALL flow sessions everywhere, regardless of
source or dest.  So, if you set a bit on one packet using a SYN flag,
you set that bit on ALL packets that flow through Snort.

On Mon, Jun 27, 2011 at 8:57 AM, Joel Esler <jesler at ...402...> wrote:
> Eoin,
>
> I've been asked to get a hold of you from the developers, they are heads down in coding this week and we need to confirm or deny the remaining bugs that we know about.
>
> Do you have pcaps for this?  I know I could make my own, and may have to, but with the bugs I have in my cue as well, it may take me awhile to get to it.
>
> Can you provide them to me?
>
> Joel
>
> On Jun 24, 2011, at 4:10 PM, Eoin Miller 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?
>>
>>
>> # snort --version
>>   ,,_     -*> Snort! <*-
>>  o"  )~   Version 2.9.0.5 IPv6 GRE (Build 135)
>>   ''''    By Martin Roesch & The Snort Team: http://www.snort.org/snort/snort-team
>>           Copyright (C) 1998-2011 Sourcefire, Inc., et al.
>>           Using libpcap version 1.1.1
>>           Using PCRE version: 8.02 2010-03-19
>>           Using ZLIB version: 1.2.3
>>
>> I haven't really gone through the code to much to see if this is the issue, but I think the reasoning is sound based upon output review/testing.
>>
>> -- Eoin
>>
>>
>> ------------------------------------------------------------------------------
>> All the data continuously generated in your IT infrastructure contains a
>> definitive record of customers, application performance, security
>> threats, fraudulent activity and more. Splunk takes this data and makes
>> sense of it. Business sense. IT sense. Common sense..
>> http://p.sf.net/sfu/splunk-d2d-c1
>> _______________________________________________
>> Snort-devel mailing list
>> Snort-devel at 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/snort-devel
>




More information about the Snort-devel mailing list