Policies by FQDN WatchGuard Training

Policies by FQDN RFE36954: Ability to use FQDN in policies and blocked sites lists RFE27064: Ability to use FQDN in From and/or To field in policies RFE79740: Ability to use FQDN in From and/or To field in policies WatchGuard Training

Policies by FQDN What it is… What it isn’t… FQDN as part of the source and/or destination of a policy FQDN as part of an alias FQDN for a blocked site FQDN for a blocked site exception Wildcards for the host on a domain (*.example.com) What it isn’t… FQDN resolved to IPv6 addresses FQDN for server configurations (Log Server, SSO Agent, etc.) WatchGuard Training

Use Cases WatchGuard Training

Use Cases Allow traffic to a specific domain using a separate policy Allow traffic to software update sites such as windowsupdate.microsoft.com or antivirus signature update sites, even though all other traffic is blocked. This is especially useful when these sites are hosted on content delivery networks (CDNs) that frequently add and change IP addresses. Deny traffic to a specific domain Deny all traffic from CDE (Cardholder Data Environment) but allow signature updates For PCI compliance traffic from the CDE must be restricted, however allowing critical updates is still necessary. Many of the services that need to be allowed are also using CDNs WatchGuard Training

Configuration WatchGuard Training

FQDN in Policies When modifying the To or From fields in a policy, FQDN is now listed in after selecting Add > Add Other This allows the configuration of a FQDN and can include a single leading wildcard. WatchGuard Training

FQDN in Aliases FQDN members can also be added to aliases, which are then used in policies. WatchGuard Training

FQDN in Blocked Sites (and Exceptions) FQDN members can also be added to the blocked sites, and blocked sites exceptions lists. WatchGuard Training

FQDN in Logging Logging will show the FQDN that was matched in the logs when a policy is applied to traffic by FQDN. WatchGuard Training

FQDN in Reporting Reporting will show the FQDN that was matched when the policy was applied to traffic by FQDN. WatchGuard Training

FQDN in Reporting Blocked Sites will identify the IP addresses blocked by FQDN included in the configuration. WatchGuard Training

How does this work? WatchGuard Training

Forward Lookups When a user configures a domain name, the system will perform forward DNS resolution and store the mapping. Clients and the Firewall should use the same name servers. For example: www.google.com Non-authoritative answer: Name: www.google.com Address: 74.125.25.104 Address: 74.125.25.105 Address: 74.125.25.147 Address: 74.125.25.99 Address: 74.125.25.106 Address: 74.125.25.103 WatchGuard Training

Why not Reverse lookups? It is natural to think that we might be able to perform reverse DNS resolution on the source or destination IP when receiving a traffic, and see if the resolved FQDN matches the configuration. Unfortunately, reverse DNS resolution might not always work. Quite commonly, the reverse DNS resolution result is not what you might expect. For example: 74.125.25.147 (from our previous lookup to www.google.com) Non-authoritative answer: 147.25.125.74.in-addr.arpa name = pa-in-f147.1e100.net. WatchGuard Training

What about Wildcards? With Wildcards we do forward lookups for www and the domain itself For example: *.google.com we resolve www.google.com and google.com To resolve the rest of the hosts implied by *.google.com, we implement DNS sniffing for A records that match our configuration. As DNS traffic passes through the firewall, we learn the responses to relevant queries. WatchGuard Training

What happens when don’t we see responses? As seen here, if the clients are trying to reach an internal destination with an internal name server, the firewall may not have an opportunity to sniff this traffic for local servers. We recommend that internal name servers are on a different internal network than clients to ensure the firewall can see responses from the server. WatchGuard Training

Thank You! WatchGuard Training