[Oisf-users] Threshold.conf not working

[Anoop Saldanha]

IIRC, if we have a event filter set *in* the rule, it would override
the event filter set inside the conf file.

>From what you're describing, the behaviour hasn't been changed,
although it was on our cards.  Thought it had been changed.

Can you remove the threshold filter from the rule and check if the
suppression works?


On Mon, Jan 7, 2013 at 7:35 PM, Josh Brower <Josh at defensivedepth.com> wrote:
> My SOSERVER was doing a (legit) NTP lookup via that IP....
>
> Is it possible that this bug is the cause of the issue?
> https://redmine.openinfosecfoundation.org/issues/613
>
> -Josh
>
>
> On Mon, Jan 7, 2013 at 8:52 AM, Matt Jonkman <jonkman at jonkmans.com> wrote:
>>
>> I don't have any ideas on why the suppress isn't working, hopefully
>> someone else may have an idea there.
>>
>> I'm chasing down that false positive though. Looks like that IP is an irc
>> server as well which is probably where it got listed in the shadowserver
>> feed. Will ping them to see if they're ok removing it.
>>
>> Matt
>>
>>
>> On Sun, Jan 6, 2013 at 3:05 PM, Josh Brower <joshbrower at gmail.com> wrote:
>>>
>>> I am using Suricata with the latest version of Security Onion (12.04),
>>> which uses Suricata 1.3.3.  I have threshold.conf with 18 entries.  I have
>>> verified that Suricata loaded those 18 rules on startup ("Threshold config
>>> parsed: 18 rule(s) found")
>>>
>>> But I still get alerts firing for these entries... For example, in my
>>> threshold.conf:
>>>
>>> #Suppress - ET CNC Shadowserver Reported CnC Server IP (group 38)  for
>>> SOSERVER- False Positive - 12/12
>>>
>>>  suppress gen_id 1, sig_id 2404037, track by_dst, ip 72.8.140.222
>>>
>>> I restart Suricata, and I still get this alert firing for the dst IP of
>>> 72.8.140.222.
>>>
>>> What should I tshoot next?
>>>
>>> Thanks
>>>
>>> -Josh
>>>



-- 
Anoop Saldanha