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
Implement DNS-over-HTTPS (DoH) to encrypt at the browser level, however DNSFilter recommends DNS-over-TLS, which covers the entire OS (not just browser traffic). We support DoT in all our Roaming Clients and our Relay.
Firefox recognizes when a computer is using the DNSFilter resolvers and automatically disables DNS-over-HTTPS, which is built-in to the Firefox browser. It works differently in that it checks to see if the configured DNS server supports DNS-over-HTTPS, and if so, will use it accordingly. When DoH is bypassed, the query is still encrypted by DNSFilter through DNS-over-TLS.
For other browsers, organizations that want to ensure their filtering policies are not circumvented can do this by blocking access to DoH providers. DNSFilter has contributed to a community-maintained list of DoH providers your firewall can block. Download the list of DoH providers.
For more details, check out our blog post on DNS-over-HTTPS.
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
nslookup(Windows) ordig(MacOS/Linux) to that domain over DNSFilter’s Anycast IP addressesnslookup YOURTESTSITE.com. 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:
nslookup YOURTESTSITE.com. 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.