[Oisf-users] Inconsistent Alerting

[Andreas Herz]

On 26/02/16 at 15:48, derek_smithg at yahoo.com wrote:
> Hello Andreas, Thanks for replying.  
> >How do you run suricata? And can you describe what you expected or
> >what you want to achieve?

> I am running it on a non root user with -c,
> -r, -l flags to point to my yaml, pcap, and log directory, and
> pointing output to a file "> suricata_run 2>$1".I am comparing it and
> snort so I am trying to figure out why suricata would alert a
> different number of times when digesting the same traffic. 

Snort uses the same rulset? Do you see any errors or so at the normal
suricata log (not the one for the events)?

> >Such big pcaps are rather hard to debug/send. Can you narrow down
> >"strange" behaviour to smaller pcaps that you can also share with us?
> I have extracted a smaller pcap with the ip causing the 12037 alert
> and also get inconsistent counts on 2101633 so it's a good small
> sample, and I am working on whether I can share it or not. But it may
> not be necessary. Looking through the yaml more closely I found a
> setting in the stream section that refers to the inconsistent
> alerting.  #     randomize-chunk-size: yes     # Take a random value
> for chunk size around the specified value.#                          
>                         # This lower the risk of some evasion technics
> but could lead#                                                   #
> detection change between runs. It is set to 'yes' by default.  I set
> this to 'no' and am getting consistent detection on this smaller pcap,
> without 12037 showing up. I will test it out on the larger ones
> today. But stemming from the yaml comments above, what evasion
> techniques are being thwarted by taking random chunks sizes while
> inspecting the raw stream? 
 
That could explain the behaviour somehow. You can also play around with
the randomize-chunk-range value. It would be great if you can generate
some pcap that you can share with us (if it's semi sensitiv at least
with us at the OISF team, then email it to aherz at oisf.net).

This is an issue when you have two content matches within a certain
range.

> Thank you for your help,Derek (Hopefully I replied to this one thread
> out of the email digest by replacing the subject line with the
> original. Please correct me if I did not.)

You broke the threading :) depending on what mail client you use, just
use reply-to-list and don't change subject etc. just the content body.

> 
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1 Date: Mon, 22 Feb 2016 22:20:46 +0100 From: Andreas Herz
> <andi at geekosphere.org> To: oisf-users at lists.openinfosecfoundation.org
> Subject: Re: [Oisf-users] Inconsistent Alerting Message-ID:
> <20160222212046.GP4767 at kvmbude> Content-Type: text/plain;
> charset=utf-8
> 
> Hi,
> 
> On 22/02/16 at 16:29, derek_smithg at yahoo.com wrote:
> >   I have been running Suricata against several pcaps withdifferent
> > yaml configurations and am seeing the total count of alerts
> > changefrom one run to another, or even with the same yaml but run at
> > a differenttime. Has anyone come across anything similar before?
> 
> How do you run suricata?
> 
> And can you describe what you expected or what you want to achieve?
> 
> >   Suricata-2.0.11
> 
> Might be worth to test 3.0 :)
> 
> >   I ran them against 3 pcaps of sizes roughly 100GB, 200GB,
> > and400GB, and tallied the alert counts, outputting any that were not
> > the same acrossthe board. 
> 
> Such big pcaps are rather hard to debug/send. Can you narrow down
> "strange" behaviour to smaller pcaps that you can also share with us?
> 
> >   This may be a different issue, but I have looked into 12037,which
> > is very similar to 2101633 but with added replace and byte_test
> > keywords,and think it might be a false positive. From carving out
> > the ip’s involved withit from the pcap and running Suricata on that
> > alone it hits that one alertabout 50% of the time. I ran it once
> > with alert-debug output and found thepacket it’s supposedly alerting
> > on and cannot find the byte pattern that wouldmatch to it. 
> 
> It would also be helpful to narrow this down to a smaller pcap with
> that we can also inform the ET guys if it's really a false positive.
> 
> 
> -- Andreas Herz
> 
> 
>   

> _______________________________________________
> Suricata IDS Users mailing list: oisf-users at openinfosecfoundation.org
> Site: http://suricata-ids.org | Support: http://suricata-ids.org/support/
> List: https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users
> Suricata User Conference November 9-11 in Washington, DC: http://oisfevents.net


-- 
Andreas Herz