Google Home and Mini snort2c blocks
-
I recently installed a Netgate firewall. I installed and enabled Snort initially. But I'm seeing traffic from a Google Home Hub & Mini outbound getting blocked. When this happens the Google Assistant can't respond. I created a fw rule to never block outbound from these devices to TCP/443. I also stopped Snort on the WAN interface, no other interfaces were configured. These IPs the Google devices need to communicate with keep getting added to the snort2c table. How do I prevent these IPs from continuing te get added to the snort2c table. I'd like to enable Snort again at some point, but first I need to be sure this traffic won't continue to get blocked.
Thanks,
David -
I ended up removing Snort. Even though I only had disabled all rules, deleted the interface, etc, it kept adding legitimate IPs to the snort2c block list. I had enabled a pass list, added the IPs there, still kept blocking. I even added outbound rules to permit traffic for those IPs, but still they kept getting added to the snort2c list. Uninstalling the Snort package resolved the issue. I may take another crack at it later.
-
@davparker Couple things for next time...
Run Snort on LAN not WAN. It will log LAN IPs instead of the WAN IP. Snort runs outside the firewall so on WAN you will end up scanning lots of inbound traffic that your firewall will then drop.
Run in alert only mode for a week or two so you can review the alerts, adjust rules etc.
You can disable rules entirely, or suppress the alerts by source or destination IP.
As you found, in legacy mode (the default) you can create a pass list to ignore the Google IP ranges if you can figure them out. PCs on LAN are in the internal pass list by default IIRC. Restart Snort on the interface to load the updated pass list.
Firewall rules won't override the Snort block table.
-
@steveits Thanks, but I couldn't figure out why it was still adding IPs to the blacklist even after having alert mode only, deleting Snort on interfaces altogether and stopping the Snort process. I had no idea what process was deciding to blacklist IPs much less why. I could not prevent it from happening. I'll need to read up more before I attempt this again. It is quite a bit different than running Snort on a Firepower even though there are some similarities.
-
@davparker possibly, there was a second/zombie Snort process running? It’s been posted about before. For instance if watchguard is installed and it starts Snort during a Snort update/restart.
-
@steveits I've reinstalled Snort and have things setup again, in Alert mode. It appears that 120:3 "(http_inspect) NO CONTENT-LENGTH OR TRANSFER-ENCODING IN HTTP RESPONSE" was responsible blocking IPs left and right. I've force-disabled that for now. I do have Snort enabled on the WAN interface. I don't want it blocking internal IPs. The setup examples I've come across so far indicate to monitor a WAN interface.
-
@davparker It won't block LAN IPs by default.
WAN is (was?) the default for a long time but look at posts by bmeeks, the package maintainer, discussing WAN vs LAN. It'll work on WAN, just with the caveats I posted above.
-
Actually, I am now running Snort on WAN & LAN. I plan on keeping the LAN in Alert mode, to collect data, I've enable Blocking mode on the WAN. All is good so far.
-
@steveits Thanks, that is good info. I may just do LAN entirely.