Sites not on Blocked Sites list are blocked

pacificadmin

M370
12.8.2

I've had multiple instances where sites are getting auto-blocked but not showing on the Blocked Sites list. In each case that I'm aware of the sites have been external DNS servers, which causes all kids of problems for users on the network. Today for example, traffic was being blocked to 68.105.29.16 (Cox DNS). Traffic Monitor shows that IP is blocked, however the Blocked Sites list in FSM is emtpy. I've had similar problems when using Google DNS servers, for example 8.8.8.8.

So first of all, why are DNS servers getting auto-blocked in the first place? Second, why are blocked sites not showing as such? And how who you go about unblocking a site that's not in the list? Is a reboot the only way. Seems like a bug. Am i missing something?

Bruce_Briggs

Why are DNS servers getting auto-blocked in the first place?

The most likely reason is that you have "Auto-block source IP of unhandled external packets" selected in your config, AND there is a slow response from a DNS server past the Fireware default 30 second UDP session timeout value, so the DNS reply packet isn't matched, and thus the block.

Options:
1) unselect "Auto-block source IP of unhandled external packets"
or
2) change the default UDP timeout to 60 secs (1 min) using the CLI.
The command is:

global-setting udp-timeout minute 1

No idea why they are not showing in FSM.

james.carson

The log at the far right of your screenshot suggests that they may be blocked due to the botnet feature (I'd need to see the whole log vice the cropped screenshot to verify that.)

Botnet acts as a blocked sites list (as does geolocation) so the logs look similar.

Bruce_Briggs

If 68.105.29.16 was listed as a botnet IP addr on 12/9, it no longer is.
My pings to it work today.

pacificadmin

Here are ping results to two Cox DNS servers. One is working the other is not. The log does mention botnet="destination". I haven't looked into botnet controls. What does that mean?

EDIT: I read up on botnet detection. It looks like the Firebox blocked this destination IP address as a botnet. I've added botnet exceptions so should be good now.

Bruce_Briggs

It means that for unknown reason, this IP addr seems to be getting added to your botnet site list.

I just ran a 5 minute continuous ping to 68.105.29.16 using PingPlotter, and 68.105.29.16 never shows up as a botnet deny for me.

You can add this IP addr to the botnet exceptions list.

About Botnet Detection
https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/services/botnet/botnet_about_c.html

"The list of Botnet Detection sites is too large to display in the Blocked Sites List."

pacificadmin

Did you try 68.105.28.16 also?

EDIT: I just tried pinging 68.105.28.16 from behind a different Firebox and it got blocked as well. So for some reason this Cox DNS server IP is on Watchguard's botnet list.

james.carson

Hi @pacificadmin

68.105.28.16 ended up on the botnet list, which adds IPs from that service to your blocked sites list if you have botnet enabled. That IP was picked up as a CnC (command and control) IP for a botnet a few days ago from what I can see. It should eventually fall off the botnet list if nothing else is detected.

I would suggest simply making an exception for 68.105.28.16 so long as you're only using it for DNS.

The exceptions for botnet are in the setup for it, which you can find here:

https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/services/botnet/botnet_config_c.html

also

https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/services/botnet/botnet_exceptions_c.html

james.carson

@pacificadmin
I opened case 1809390 on your behalf to track this, feel free to update/reply whichever side you're more comfortable with -- the case is mostly for internal tracking of the issue.

pacificadmin

Got it. Thanks @james.carson