In this article
This article outlines how to prevent end-users from circumventing DNSFilter on network devices. Users could circumvent filtering policies by changing DNS settings if prevention is not in place.
Network administrators can prevent circumvention at different network levels:
- Device network interface
- Operating System or browser encryption
- Firewall rules and deep packet inspection
- Roaming Client admin settings
Select the method(s) that best serve your organization's preferences and systems.
Lock device DNS settings
Denying users the ability to edit the network interface on their devices eliminates the possibility of circumvention.
Implement operating system or browser encryption
DNS-over-HTTPS (DoH) encrypts DNS requests at the browser level. DNSFilter also supports DNS-over-TLS (DoT), which encrypts all DNS traffic at the OS level. DoT is available in all Roaming Clients and the Relay.
Firefox automatically detects when DNSFilter resolvers are in use and disables its built-in DoH. In those cases, Firefox continues using DNS-over-TLS, so queries remain encrypted. DNSFilter also returns an NXDOMAIN response for Firefox’s DoH detection domain, use-application-dns.net, ensuring the browser correctly identifies that secure DNS resolution is already managed.
Other browsers may still attempt to use DoH. To prevent circumvention, you can block access to known DoH providers. DNSFilter contributes to a community-maintained list of DoH servers that can be blocked at the firewall.
✍️ Note: If you plan to use DNSFilter’s DoH behind a site, make sure doh.dnsfilter.com is not blocked in your policy (not blocked by default) or by your firewall/proxies.
Force DNS traffic to DNSFilter with firewall rules
There are several ways to accomplish this that depend on your firewall's options. Reference your firewall manufacturer's documentation for detailed instruction.
Transparently redirect any outbound DNS request to DNSFilter. Setup firewall rules to forward DNS traffic to port 5353 or 5354 (UDP only) to prevent ISP and end-user content filtering circumvention. This is useful if the ISP is transparently proxying DNS, or if end-users have the ability to use 3rd party DNS servers.
See methods using iptables in our Community.
Load balance round robin settings. If the organization's firewall offers destination-based round robin settings, enter multiple destinations to load balance the two DNSFilter AnyCast IP addresses.
Intercept all DNS lookups with a Fortinet NAT rule. Organizations that use a Fortinet firewall can create a NAT rule to intercept all DNS lookups on port 53 and port 853 that forward the lookups to localhost (127.0.0.1), centralizing DNS resolution.
Test firewall rules
Test firewall rules to ensure that users cannot circumvent DNSFilter policies.
- From the DNSFilter dashboard, Block List a domain
-
Perform an
resolve-dnsname(Windows) ordig(macOS/Linux) to that domain over DNSFilter’s Anycast IP addressesresolve-dnsname -name YOURTESTSITE.com. -server 103.247.36.36 dig +short YOURTESTSITE.com. @103.247.36.36
-
Copy the resulting IP address (in Windows
non-authoritative answer) for the domain into a browser and attempt to visit it. There should be a block page as below -
Now, perform the same test but using Google’s public DNS resolver:
resolve-dnsname -name YOURTESTSITE.com. -server 8.8.8.8 dig +short YOURTESTSITE.com. @8.8.8.8
The test should return the same result as the previous query. This is evidence that the firewall rule is operative and DNS queries are being sent to DNSFilter. Users will be blocked according to policy, no matter what they have set on their device.
Know All Your Security Settings
Many firewalls and other security softwares have settings that can prevent DNSFilter from functioning as expected. Assess your full cyber security setup to make sure other elements of the system don't conflict with DNSFilter.
Block end-user VPN installation
Depending on the type of end-user and use case, you may decide to block the ability for end-users to use a VPN. Follow these suggestions to block VPN installation.
|
SSL VPNs
|
Background SSL VPNs are common with free and consumer-focused VPN offerings. SSL VPNs usually use one of the following ports to connect:
Because these ports are used for very common applications, a network administrator cannot normally block these ports in a firewall. |
|
Solution Deep Packet Inspection is a feature available with some firewalls and security-focused network appliances. The technology analyzes packet information to determine if the packets’ attributes match the intended usage of the port and protocol being used. If the packets have non-standard attributes, they are blocked. If Deep Packet Inspection is enabled and monitoring the aforementioned ports, it’s likely that most SSL VPNs will not connect. | |
|
IPSec VPNs |
Background Unlike SSL VPNs, these VPN types usually use standardized ports which are dedicated to IPSec VPNs and can normally be blocked in the firewall without affecting any applications or services:
|
|
Solution VPN servers and services can usually be configured to run over any port, and VPN services which specifically advertise the ability to get around proxies or content filters are more likely to use nonstandard ports. If the firewall or appliance has Deep Packet Inspection capabilities, it’s recommended to enable it if circumvention is a concern on the network. | |
|
SSTP VPNs |
Background An SSTP VPN uses the HTTP protocol as part of its initialization process. If the HTTP connection is blocked, the VPN will fail to initialize. |
|
Solution If the firewall supports Layer-7 filtering, create a rule to inspect all outbound 80/tcp traffic and block any “HTTP_Connect” headers that contain: "SSTP_VERSION:*" |
Prevent Windows Roaming Client interference
The Windows agent is installed via a standard MSI package format. As a standard application, normal users in a Windows environment are unable to prevent the filter from running.
However, in some environments, IT allows local users to have admin privileges on their devices. While the Roaming Client cannot prevent itself from being uninstalled, there are several precautions available to prevent even administrative users from interfering with filtering policies:
Use a GPO. Apply a Group Policy Object (GPO) to prevent users from stopping the DNSFilter service.
✍️ Even when working correctly, this will not prevent the user from killing the process via the task manager, and though the service will restart more or less immediately, fast-fingered individuals will be able to delete or rename the executable and prevent the service from reloading correctly, or simply delete the containing folder.
Remove the DNSFilter agent from Add/Remove Programs. Hide the agent (ARPSYSTEMCOMPONENT=1) to make it more difficult to remove. This method alone does not prevent the Roaming Client from being uninstalled via the command line.
Hide the tray icon. Use the flag TRAYICON="disabled" to hide the tray icon. Remember that hiding the tray icon will make it more difficult to troubleshoot any issues that should arise.
Comments
0 comments
Please sign in to leave a comment.