Suppress ALL snort alerts for a single source IP?

[Andrew Lamarra]

I can't seem to figure this out. I'd like to be able to suppress ALL snort alerts for several source/destination IP addresses. I add the following line to my /etc/nsm/rules/threshold.conf:

suppress gen_id 0, sig_id 0, track by_dst, ip 192.168.1.45

Then I run rule-update, test it with "curl http://testmyids.com" from that machine, and no alert is triggered, great! Note, I did test that command before-hand to make sure it IS triggering the snort alert.

Then I add another line with everything the same except the IP is .46 instead:

suppress gen_id 0, sig_id 0, track by_dst, ip 192.168.1.45
suppress gen_id 0, sig_id 0, track by_dst, ip 192.168.1.46

However, now when I run rule-update, "snort-1" could not be started. Running "so-start" gives me the following lines:

* starting: snort-1 (alert data) [ FAIL ]
- check /var/log/nsm/onion-eth0/snortu-1.log for error messages

Of course, then I check /var/log/nsm/onion-eth0/snortu-1.log and it gives me the following line:

ERROR: /etc/nsm/onion-eth0/threshold.conf(119) suppress could not be created.
Fatal Error, Quitting..

Which happens to be the line number of the newly added suppression. So I figured I can't have 2 "track by_dst" lines to suppress all rules, so I change those lines to this:

suppress gen_id 0, sig_id 0, track by_dst, ip [192.168.1.45,192.168.1.46]

Running "rule-update" then "so-start" gets everything back to normal. I test it out & run "curl http://testmyids.com" from both machines. Neither trigger the alert. Great! However, when I add another line to "track by_src", I have the same issues with Snort not starting:

suppress gen_id 0, sig_id 0, track by_dst, ip [192.168.1.45,192.168.1.46]
suppress gen_id 0, sig_id 0, track by_src, ip 217.160.0.187

Is there something I'm doing wrong? Can I only have ONE line that starts with "suppress gen_id 0, sig_id 0,"?

[Andrew]

Sorry about the misleading title. I did a lot of testing before posting this and forgot to fix that part. Seems I can't even edit my post :(

[Andrew]

And to answer the inevitable "why would you want to do that?" question... Because I'm running Security Onion on a training range and there are certain IP addresses that are running scans of the network & constantly generating false positives. These IP's are either off-limits or inaccessible to the red team so I'm not worried about them.

[Wes Lambert]

Andrew,

One option would be to use a granular BPF:

https://github.com/Security-Onion-Solutions/security-onion/wiki/BPF#granular-bpfconf

Thanks,

Wes

On Mon, Apr 30, 2018 at 7:12 PM, Andrew <andrew....@gmail.com> wrote:

And to answer the inevitable "why would you want to do that?" question... Because I'm running Security Onion on a training range and there are certain IP addresses that are running scans of the network & constantly generating false positives. These IP's are either off-limits or inaccessible to the red team so I'm not worried about them.

--
Follow Security Onion on Twitter!
https://twitter.com/securityonion
---
You received this message because you are subscribed to the Google Groups "security-onion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to security-onion+unsubscribe@googlegroups.com.
To post to this group, send email to security-onion@googlegroups.com.
Visit this group at https://groups.google.com/group/security-onion.
For more options, visit https://groups.google.com/d/optout.

--

https://twitter.com/therealwlambert

https://securityonion.net/

[Andrew]

Yeah, seems that works. Thank you!

On Monday, April 30, 2018 at 8:19:59 PM UTC-5, Wes wrote:
> Andrew,
>
>
> One option would be to use a granular BPF:
>
>
> https://github.com/Security-Onion-Solutions/security-onion/wiki/BPF#granular-bpfconf
>
>
>
> Thanks,
> Wes
>
>
> On Mon, Apr 30, 2018 at 7:12 PM, Andrew <andrew....@gmail.com> wrote:
> And to answer the inevitable "why would you want to do that?" question... Because I'm running Security Onion on a training range and there are certain IP addresses that are running scans of the network & constantly generating false positives. These IP's are either off-limits or inaccessible to the red team so I'm not worried about them.
>
>
>
>
>
> --
>
> Follow Security Onion on Twitter!
>
> https://twitter.com/securityonion
>
> ---
>
> You received this message because you are subscribed to the Google Groups "security-onion" group.
>

> To unsubscribe from this group and stop receiving emails from it, send an email to security-onio...@googlegroups.com.
>
> To post to this group, send email to securit...@googlegroups.com.