<div dir="ltr">I apologize, but I am not sure what you mean, when you say <i>"<span style="font-family:arial,sans-serif;font-size:13px">Can you remove the threshold filter from the rule and check if the </span><span style="font-family:arial,sans-serif;font-size:13px">suppression works?"</span></i><div>
<span style="font-family:arial,sans-serif;font-size:13px"><br></span></div><div style><span style="font-family:arial,sans-serif;font-size:13px">Thanks</span></div><div style><span style="font-family:arial,sans-serif;font-size:13px"><br>
</span></div><div style><span style="font-family:arial,sans-serif;font-size:13px">-Josh</span></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Jan 8, 2013 at 1:36 PM, Anoop Saldanha <span dir="ltr"><<a href="mailto:anoopsaldanha@gmail.com" target="_blank">anoopsaldanha@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">IIRC, if we have a event filter set *in* the rule, it would override<br>
the event filter set inside the conf file.<br>
<br>
>From what you're describing, the behaviour hasn't been changed,<br>
although it was on our cards.  Thought it had been changed.<br>
<br>
Can you remove the threshold filter from the rule and check if the<br>
suppression works?<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On Mon, Jan 7, 2013 at 7:35 PM, Josh Brower <<a href="mailto:Josh@defensivedepth.com">Josh@defensivedepth.com</a>> wrote:<br>
> My SOSERVER was doing a (legit) NTP lookup via that IP....<br>
><br>
> Is it possible that this bug is the cause of the issue?<br>
> <a href="https://redmine.openinfosecfoundation.org/issues/613" target="_blank">https://redmine.openinfosecfoundation.org/issues/613</a><br>
><br>
> -Josh<br>
><br>
><br>
> On Mon, Jan 7, 2013 at 8:52 AM, Matt Jonkman <<a href="mailto:jonkman@jonkmans.com">jonkman@jonkmans.com</a>> wrote:<br>
>><br>
>> I don't have any ideas on why the suppress isn't working, hopefully<br>
>> someone else may have an idea there.<br>
>><br>
>> I'm chasing down that false positive though. Looks like that IP is an irc<br>
>> server as well which is probably where it got listed in the shadowserver<br>
>> feed. Will ping them to see if they're ok removing it.<br>
>><br>
>> Matt<br>
>><br>
>><br>
>> On Sun, Jan 6, 2013 at 3:05 PM, Josh Brower <<a href="mailto:joshbrower@gmail.com">joshbrower@gmail.com</a>> wrote:<br>
>>><br>
>>> I am using Suricata with the latest version of Security Onion (12.04),<br>
>>> which uses Suricata 1.3.3.  I have threshold.conf with 18 entries.  I have<br>
>>> verified that Suricata loaded those 18 rules on startup ("Threshold config<br>
>>> parsed: 18 rule(s) found")<br>
>>><br>
>>> But I still get alerts firing for these entries... For example, in my<br>
>>> threshold.conf:<br>
>>><br>
>>> #Suppress - ET CNC Shadowserver Reported CnC Server IP (group 38)  for<br>
>>> SOSERVER- False Positive - 12/12<br>
>>><br>
>>>  suppress gen_id 1, sig_id 2404037, track by_dst, ip 72.8.140.222<br>
>>><br>
>>> I restart Suricata, and I still get this alert firing for the dst IP of<br>
>>> 72.8.140.222.<br>
>>><br>
>>> What should I tshoot next?<br>
>>><br>
>>> Thanks<br>
>>><br>
>>> -Josh<br>
>>><br>
<br>
<br>
<br>
</div></div><span class="HOEnZb"><font color="#888888">--<br>
Anoop Saldanha<br>
</font></span></blockquote></div><br></div>