DNS in isolated networks, does it leak and how to mitigate when it does
Our business is to make sure that isolated networks are and stay disconnected from other (dirty) networks. We have a product, called Beacon, to do this checking in scale. We also help to figure out why networks leak, when they should not, and help to mitigate the leaks. Often the source of the leak is a misconfigured Domain Name System (DNS), and almost always when DNS leaks, it is due to Windows Active Directory (AD) settings.
Why does DNS leak?
When we deploy new Beacons, usually at least some leaks are observed in the first hours or days. DNS escape is one of those leaks that occur in nearly every new Beacon deployment. DNS is usually considered an essential part of network operation, and its security implications on isolated networks are relatively easy to miss.
DNS converts IP addresses to human readable domain names and vice versa. DNS is a hierarchically organized system with servers for different subdomains. When a user browses to website www.sensorfu.com, the browser asks the resolver configured in the system for the IP address of the www.sensorfu.com. The resolver contacts the root server and asks for the authoritative .com Top Level Domain (TLD) server. Then the .com TLD server is queried for the IP address of the authoritative DNS server responsible for handling sensorfu.com domain. Next the resolver queries that server to retrieve the IP address of the host www.sensorfu.com and returns the IP address to the browser. The browser continues communicating with www.sensorfu.com with that necessary piece of information. See figure 1 for an illustrated recursive DNS lookup. This makes it possible for humans to remember computer and service names by a canonical name, and machines to reach other machines using names in a possibly dynamic IP environment where the IP addresses of the machines might not be static. [1]
Figure 1: Local recursive DNS server resolving “www.sensorfu.com”’s IP-address
DNS is a fundamental protocol of the Internet. Without DNS, finding services or machines on the Internet would be more or less impossible. Nearly all networks utilize DNS one way or another. That includes isolated Operational Technology (OT) networks as well. Historically OT networks and nodes have not really depended on DNS for their main functionality, which is to enable communication between production equipment and stay running by itself for long periods in a relatively statically and pragmatically configured environment. In the modern days a functional name resolving infrastructure becomes more important and even essential in OT networks as well. Current security policies require centralized user credential management, which usually means AD server which in turn requires DNS by design. Periodical operating system security patches and antivirus definition updates are such cases where computers need to find the server from which the patches are available. These addresses are sometimes a dynamic pool of IP addresses in a cloud infrastructure, and therefore the update procedure needs DNS in order to function reliably.
When we have Internet technology (DNS) that enables global connectivity creeping into isolated OT networks it is easy to get more than you asked for. DNS servers might actually do a too good job bridging networks together when they should not.
How does DNS leak?
But why is DNS leak considered a leak? Since DNS is usually considered an essential part of network operation, its security implications are relatively easy to ignore or disregard. DNS is a common way to smuggle data in and out often under the radar. Malicious actors also know this.
To illustrate this try fetching Wikipedia content (from dgl.cx) via DNS by running this command on a terminal:
dig +short txt 'domain_name_system.wp.dg.cx'Or in a Windows prompt:
nslookup -q=txt domain_name_system.wp.dg.cxYou should get part of the Wikipedia article about DNS in a TXT record. This is one way to transfer arbitrary data in and out using DNS infrastructure. A malicious actor can also obfuscate the data and use other records, like A or CNAME to hide. This example shows that DNS can be used for other purposes beyond the original name resolution. You don’t need direct access to an external DNS server, it is enough that DNS servers in the chain can relay the query to the next hop. If your network is isolated and blocking arbitrary domain name queries this shouldn’t work. [2]
Figure 2: Beacon sends queries to local and public DNS resolvers to communicate with Home
We find DNS leaks by having our Beacon product trying to resolve external entities under our control through local and public DNS resolvers from within the isolated networks (see Figure 2). If it succeeds to reach the “Home” in the public network, then there is a leak.
How to stop DNS leaks?
Fully functioning DNS infrastructure can be used to initiate arbitrary two way communication. When this is undesirable or outright dangerous then the isolated networks should limit or “firewall” unwanted DNS communication.
Conditional forwarding
Simplest way to limit DNS is known as conditional forwarding, where only queries for whitelisted domains are allowed to be forwarded further to the upstream DNS system and thus to be resolved. Queries that do not match the entries in the whitelist will be discarded. In Windows DNS Manager this is easy to do. Caveat is that this method requires a dedicated DNS server for the isolated infrastructure.
It is also necessary to know the domains to be whitelisted. If not already done, the first thing to do is to enable and check the DNS server logs to see what names are being resolved.
This example forwards “*.windowsupdate.microsoft.com” queries to the specified servers for resolution. [3]
- In Windows DNS Manager, right-click on “Conditional Forwarders” and add the allowed domains.
2. Specify servers where the specific DNS queries should be forwarded.
3. Also disable forwarders and recursive forwarding towards root servers from [Server] “Properties” -> “Advanced” “Disable recursion (also disables forwarders)”
How to check conditional forwarding?
You can try resolving both whitelisted and generic domains from the isolated network, this is one way to do it on Windows:
C:\Users\User>nslookup windowsupdate.microsoft.com
Server: localhost
Address: 127.0.0.1
Non-authoritative answer:
Name: windowsupdate.microsoft.com
Address: 20.72.235.82
C:\Users\User>nslookup google.com
Server: localhost
Address: 127.0.0.1
*** localhost can't find google.com: Query refusedWhitelisted domains should resolve normally and other domains should refuse the query.
Other means to limit DNS
Windows 2016 Server introduced a more granular method to limit queries with DNS policies. This allows definition of resolution policies per subnet and does not necessarily need a dedicated DNS server for isolated networks. More information can be found here: https://learn.microsoft.com/en-us/windows-server/networking/dns/deploy/apply-filters-on-dns-queries [4]
Also, you could try firewalling or further isolating your AD server so that it can’t freely connect and resolve DNS but it might be a painful road when trying not to break things, such as Windows updates.
Wrapping it up
Even if you do a good job in firewalling, air gapping or otherwise isolating your OT networks, the DNS might surprise you. We see a lot of OT networks adopting Windows AD and Windows AD depends on DNS. DNS has been built for the Internet and you should take care that your AD doesn’t act as a gateway between the Internet and your OT network. Configuring your AD for conditional forwarding may be the lowest hanging fruit to regain the isolation you were aiming for.
References
- “Domain Name System”, Wikipedia, https://en.wikipedia.org/wiki/Domain_Name_System,
- “Wikipedia over DNS”, dgl.cx, https://dgl.cx/2008/10/wikipedia-summary-dns, accessed
- “Deploy Windows Server Update Services”, Microsoft, https://learn.microsoft.com/en-us/windows-server/administration/windows-server-update-services/deploy/2-configure-wsus#21-configure-network-connections
- “Use DNS Policy for Applying Filters on DNS Queries”, Microsoft, https://learn.microsoft.com/en-us/windows-server/networking/dns/deploy/apply-filters-on-dns-queries
