Suricata blocking google.com
-
Rules block things, so which rule is triggering?
Research and identify if that rule is triggering on a false positive. If so, then disable it or suppress it. For true false positives, I tend to favor disabing so as to conserve CPU cycles.
-
@bmeeks Its really hard to say since there are so many IPs that is related to Google services.
And it just keeps on blocking if I cant whitelist google.com as a domain....
-
You will need to indentify the rule (or rules) that is triggering and take action on the GID:SID level by disabling or suppressing the rule.
If you are having issues with Google, it is likely that you are being much too aggressive with the rules you have enabled. In other words, you have too much turned on. That is the balancing act of IPS, especially legacy-mode IPS where the blocking is done at the host IP level instead of by selectively dropping just individual packets. You can't enable lots of rules for blocking and not expect trouble with false positives.
If the impact is significant, then switch off blocking mode, and then clear all the blocked hosts on the BLOCKS tab (I assume you are using Legacy Mode).
-
@cool_corona The same here. Once I noticed the problem I ran the command ping www.google.com to get Google's IP address and I could find the affected rules , put it in the suppress list and remove from Blocked Hosts. I'm using Legacy Mode.
-
@audax10 Which one trigged it for you?
-
@cool_corona The ones below:
#SURICATA STREAM excessive retransmissions
suppress gen_id 1, sig_id 2210054#ET POLICY PE EXE or DLL Windows file download HTTP
suppress gen_id 1, sig_id 2018959#ET INFO EXE - Served Attached HTTP
suppress gen_id 1, sig_id 2014520 -
@audax10 This is currently my suppress list.
I managed to get around it by installing a browser extension to firefox that didnt use google.com but google.ch as browser redirect for search results and startpage.
#SURICATA STREAM excessive retransmissions
suppress gen_id 1, sig_id 2210054#SURICATA Applayer Detect protocol only one direction
suppress gen_id 1, sig_id 2260002#SURICATA STREAM 3way handshake wrong seq wrong ack
suppress gen_id 1, sig_id 2210010#SURICATA Applayer Wrong direction first Data
suppress gen_id 1, sig_id 2260001#SURICATA STREAM reassembly overlap with different data
suppress gen_id 1, sig_id 2210050#ET POLICY External IP Lookup Domain (myip.opendns .com in DNS lookup)
suppress gen_id 1, sig_id 2023472, track by_dst, ip 208.67.222.222#ET POLICY Reserved Internal IP Traffic
suppress gen_id 1, sig_id 2002752#ET POLICY exe download via HTTP - Informational
suppress gen_id 1, sig_id 2003595#SURICATA TLS certificate invalid der
suppress gen_id 1, sig_id 2230027 -
@audax10 A few of the notes I have on Suricata setup from over the years:
- check "Disable hardware checksum offload" in (System->Advanced->Networking) [because otherwise it triggers checksum alerts]
- Suricata: disable ALL stream-events.rules or it will block lots of traffic on false positives
- On a new install, do not enable blocking right away, instead monitor alerts for a while to look for false positives
from the package maintainer:
“The ET Policy and ET Info rules are really not for detecting "bad" things. They are designed to alert you if some machine is doing something that matches the policy. So that ET POLICY WMIC WMI rule is simply telling you that it detected WMI (Windows Management Instrumentation) traffic over the link. That is typically harmless and does not mean malware exists. Generally speaking, for home users and even most small business users, the ET POLICY rules are not a good thing to enable. They will give you plenty of alerts, but the alerts do not mean anything bad is happening. I would recommend not using that rule category in most circumstances.”Rule "ET POLICY PE EXE or DLL Windows file download HTTP" for example is saying a PC tried to download a binary file over insecure HTTP. If your goal is to block that then leave that enabled.
-
@steveits Thanks. I think the best to do is enable Inline Mode if the hardware supports it, so we could check the alert before blocking.
As far as I understand, Legacy Mode blocks the host, while Inline blocks (drop/reject) the triggered rules. This is a big difference. I noticed that Google Maps connects to the same host as "ET INFO Android Device Connectivity Check" rule. So when the host is blocked rather than the rule specification, we will probably block more than we need. Is it correct @bmeeks ?
-
@audax10 said in Suricata blocking google.com:
As far as I understand, Legacy Mode blocks the host, while Inline blocks (drop/reject) the triggered rules. This is a big difference. I noticed that Google Maps connects to the same host as "ET INFO Android Device Connectivity Check" rule. So when the host is blocked rather than the rule specification, we will probably block more than we need. Is it correct @bmeeks ?
Yes, Inline IPS Mode is much more selective as it drops individual packets instead of entirely blocking a host by its IP address. However, when using Inline IPS Mode, you must change the action of rules that you wish to block traffic from ALERT to DROP. Otherwise, they will just generate alerts and not drop or block the traffic. Rule actions are default set to ALERT. In Legacy Mode, any alert is interpreted as a block. But that is NOT the case when using Inline IPS Mode. In that mode rule actions are interpreted literally! So if the action is ALERT, that's all that happens. To block traffic in Inline IPS Mode, the rule action must be changed to DROP.
Changing to Inline IPS Mode without also changing rule actions via SID MGMT or some other means will result in nothing being blocked.
The easiest way to manage this is to use the SID MGMT tab features. You can also alter the action of individual rules on the RULES tab and on the ALERTS tab once Inline IPS Mode is enabled. If you are new to this, you should read through this long Sticky Post first: https://forum.netgate.com/topic/143812/snort-package-4-0-inline-ips-mode-introduction-and-configuration-instructions. While a little of the information in that thread is probably dated by now, the majority of it is still applicable.
