- 7.0.5_1
- OpnSense
- Believe it’s part of default OpnSense install.
I recently configured monit to notify me of when Suricata has blocked something with content = "blocked" Currently, I’m probably getting 10 to 20 messages per day with almost all of them definitely false positives. I’ll share all of the different alerts I’m receiving on this thread. In the mean, time is there anything I should do to reduce the false positives?
I keep getting spammed by ET SCAN Sipvicious Scan. I believe that’s a security company checking for vulnerable ports. I do not use VOIP. Can I just block the ports VOIP uses, and the alert will be silenced?
If you are running the Suricata instance on the WAN interface, then you can only silence unwanted alerts by suppressing them or by disablilng the particular rule SID that is alerting. When operating on the WAN, Suricata sees traffic directly from the NIC before any firewall rules have been applied. Thus you can’t use firewall rules to control what Suricata sees in that case.
Generally speaking, on firewall systems such as OPNsense and pfSense, it is better to put IDS/IPS instances on the LAN and/or other internal-facing interfaces. That way you can use the firewall rules to filter out and drop the vast majority of Internet “noise” that hits the WAN interface leaving the IDS/IPS only needing to spend resources processing traffic which made it past the firewall rules. Otherwise the IDS/IPS is expending precious computational resources to analyze traffic that is simply going to be dropped by the typical “default deny” configuration of the WAN firewall rules for inbound traffic.
I will also note that Suricata questions related to both OPSsense and pfSense should first be posted on the specific help forums for those firewall distros. That’s because both distros use a custom GUI front-end for managing the Suricata configuration. Here are links to each forum:
OPNsense: https://forum.opnsense.org/
pfSense: https://forum.netgate.com/category/53/ids-ips
I’ll ask more on OPNsense. Is this still the right place to ask if an alert is something important or not?
How I have my IDS/IPS setup is I have Zen Armor on the LAN side, and Surricata on the WAN side. That’s the recommendation I keep seeing from users using OPNsense. I believe doing that would stop packages that get past Surricata from calling home.
If there’s no other way to filter out notifications coming from security researchers, I suppose I could customize my Monit alert to ignore them. I’ll probably be on here asking you if IP addresses are known false positives.
You can certainly ask for users’ opinions on particular alerts on this forum. Just remember that it is best to keep the questions more general because many users of Suricata actually use the binary package available on Linux distros. They will not be familiar with the GUI controls offered in the OPNsense and pfSense versions, so questions pertaining to GUI settings are not likely to generate any replies here.
One of the downsides of running Suricata on the WAN side of the two *sense distros (OPNsense and pfSense) is that the Suricata instance is outside of the firewall and thus firewall rules can’t help filter what Suricata is seeing (to prevent it from having to process the “noise” that firewall rules are likely to drop anyway). Another downside of putting it on the WAN is that all the local IP addresses are hidden by NAT (when NAT is used). Thus you can’t readily discern which particular local host is the target or source of something alerting in Suricata because all local traffic presents as the WAN’s public-facing IP address in the alerts.
I created and maintain the GUI package for Suricata on pfSense. I am not an OPNsense user, but I am familiar with how it works in that distro and I do visit their forums regularly as a guest.
In the pfSense package there is a GUI mechanism for quickly adding IP addresses and/or SIDs to the Suppression List so that rules that match the suppress condition do not alert. Not sure if the OPNsense package offers something similar, but I would expect it does.