Blocked Sites Exceptions Logic
I'm trying to understand WatchGuard's Blocked Sites Exceptions logic. If I put a site in the list, default threat protection, proxy policies, Geolocation, WebBlocker and such will not be allowed to ban the site. However, if I have a packet filter policy set with Auto-block sites that attempt to connect, that does not care about the Blocked Sites Exceptions. Why would packet polices, but not proxy policies, ignore the Blocked Sites Exceptions list?
0
Sign In to comment.
Comments
I assume that it is a result of the incoming packet processing order.
"Auto-block sites that attempt to connect" is invoked for an incoming packet for which you have no policy allowing it.
(I don't have this option enabled, and I don't recommend having it enabled because of unexpected results, such as external DNS sites ending up on the temp Blocked Sites list when they have a slow response - longer then the default UDP timeout of 15 secs. Over the years, this option has bitten a number of sites with DNS no longer working for them for a period of time...)
From your experience, Blocked Sites Exceptions processing would happen after the "Auto-block" processing, and would only apply if Auto-block didn't deny a packet.
Thank Bruce. I think I understand. It is an order of operations of the firewall. Proxies stop to inspect the packet, so it can review the block exceptions list before processing the Auto-block sites that attempt to connect. Packet filters don't inspect like a proxy and can only block and not perform a lookup.
We have a few deny and block policies setup, as for example, no one has any business trying to telnet inbound. However, twice now this year we had an errant packet come in from a Google DNS server on port 23/TCP and thus blacklisted Google DNS, causing some issues.
There is a strict order of firewall packet processing.
Step 2 processing is not done if step 1 denied the packet.
The only way a next step processes a packet is if the previous step allow it.
Proxies will not review the blocked sites exceptions list because "Blocked Sites Exceptions" processing has already been done prior to any proxy policy checks.
Hi @tolcheen
It depends how the site is entered.
An IP will be rather finite, while a FQDN means different things depending on how the proxy is configured.
The packet filter policies will check the FQDN table and apply traffic. If this is HTTPS, the FQDN will often come from the SNI in the cert.
If you're using a proxy policy with content inspection on, we can see the actual get request, and will generally use that.
-James Carson
WatchGuard Customer Support
We entered the IPs into the Blocked Sites Exception list.
It's confusing based on the support ticket we opened about it. We were told "We do not have a publicly available document about the order of operations of the Firebox" and they couldn't point us to anything that said Auto-block sites that attempt to connect is processed without checking the exception list.
Without supports help, all we could find was a reference on a document that said "Traffic from sites on the Blocked Sites Exceptions list is also not blocked automatically based on thresholds configured in Default Threat Protection and by block actions configured in a proxy policy." Hence Bruce, why I said proxies respect the do not block list put packet filters do not.
Hi @tolcheen Do you happen to have that case number?
I suspect they would've been trying to find some more information, but we don't have just a general order of operations document for everything. There's too much going on to make it comprehensible
If you're going by straight IP, that is one of the first things the firebox processes, but it'll only do so for NEW connections. If a PC already has a connection open to that IP, it'll continue to do so until that connection ends or the firewall is rebooted, causing all connections to effectively end.
-James Carson
WatchGuard Customer Support
While this document does not mention Blocked Sites Exception processing,
it does provide a better understanding of the order of checks done by Fireware:
About Policy Precedence
https://www.watchguard.com/help/docs/help-center/en-US/Content/en-US/Fireware/policies/policy_precedence_about_c.html
I wish there was something more clear cut, but at least I understand it now. Thank you both.