whitelist Googleusercontent.com ??

[Cool_Corona]

Getting a lot of positives from googleusercontent.com

Anybody know how to whitelist that domain in Suricata?

[bmeeks]

If you use Legacy Mode Blocking, you can create a FQDN alias in pfSense and then use that alias as part of a custom Pass List. The FQDN will be resolved by pfSense just like any other alias (once every 5 minutes by default). Suricata's Legacy Mode Blocking plugin will query the alias table in pf to see if it contains the IP address of the current packet being analyzed for potential blocking.

Here is a post that describes the process (follow the thread down a few posts to find a screenshot example): https://forum.netgate.com/topic/178266/suricata-pass-lists-and-alias-url-url-table. Although the thread is specifically referring to URL Table aliases, the same process works for an FQDN alias.

The problem with this is that CDNs frequently contain tons of IPs that have very short TTL values (sometimes even as short as 60 seconds, though 300 is more common). That means the IP of the host seen attempting the scan may not always match what is in the pf table for the FQDN from the most recent DNS query executed by the filterdns service.

If you create a custom Pass List for this, don't forget to actually assign the pass list to the desired interface and then restart Suricata on that interface so it sees the pass list.

[bmeeks]

I'm posting this observation separate from my earlier reply because the first dealt solely with adding a FQDN alias to a pass list.

From your shared screenshots from the BLOCKS tab, I assume you are running Suricata on the WAN and capturing these scans from that interface. Understand that Legacy Mode Blocking in Suricata depends on the pfSense pf firewall engine to actually implement the blocks of traffic. Suricata is not blocking the traffic itself. It is simply pulling out the IP addresses in the packets and adding them to a pf firewall table called snort2c.

The default firewall rule in place on the WAN drops all unsolicited inbound traffic already. So, you have the default DROP rule that is going to drop this scan attempt, then you have Suricata adding the IP to an internal pf table that is mapped to another firewall rule that is also going to just drop this traffic. Why do that? You are creating double work on your firewall by essentially dropping the same traffic twice. If you don't actually have any open ports on the WAN side that accept unsolicited inbound traffic, what's to be gained by this double blocking?

Lastly, these SCAN rules are somewhat prone to false positives. The Snort portscan preprocessor is notorious for false positives. There exists "normal" web traffic these days that such rules will misinterpret and trigger on producing a false positive. I suspect that is what's happening in this case.