Yesterday, our Chief Security Officer, Jeff Horne shared his perspective on NAME:WRECK and the vulnerabilities associated with DNS that were found. As a follow up, I wanted to share some best practices for DNS security.

The most common DNS exploits are exploits like exfiltration, payload delivery, and commands and control. Sometimes outright flaws in code (like a few mentioned in NAME:WRECK) are leveraged also. DNS is a vulnerable and necessary service that can be secured with good practices and solid Zero Trust policy.

In this blog we will explore a number of DNS configurations, explore what’s right and wrong and steps you can take to secure your configuration.

Scenario 1 (Worst Case) 

In this scenario, endpoints of all sort query some internet source (typically Google or Verizon) for name lookups directly. This is a typical home user configuration and unfortunately a typical configuration for IoT devices and guest networks across many verticals in enterprise. In this scenario attacks can come from nearly any ware upstream, and in any form from bad packets, bad answers (sending the host to a malicious location) or worse.

Even a Next-Generation firewall capable of DNS application understanding is not enough.

Scenario 2 (Typical Enterprise) 

This is the most common implementation of DNS in enterprises across the world where a local authoritative name server is the ‘first hop’ and provides recursion out to the internet. Some enterprises are further adding some layer of DNS security in response policy zones, leveraging Next-Generation firewalls, or Secure DNS solutions on the internet side. If this is set up in best practice, this delivers minimal security(yes minimal) but if we are working in Cyber-Physical Systems like Manufacturing, Healthcare or Financial Services then this is not nearly enough.

What is Best Practice?

The Firewall would block all DNS requests (outbound/inbound) except to the Internal DNS server that was running DNS security in the form of response policy zones, and furthermore the internet resolver would be a Secure DNS source (i.e., Cisco Umbrella, Akamai, Neustar or other such provider).

Scenario 3 (Reference DNS) 

This is a better set up and is often considered the ‘reference’ DNS architecture for many. This scenario will protect most internal hosts from many, many sorts of exploits and attacks. However, this configuration still falls short for Cyber-Physical Systems (and even some core services servers) when we apply Zero Trust concepts to the DNS service.

Scenario 4 (Best Practice for Cyber Physical Systems) 

Following the Reference DNS set up with Best Practices, we need to add yet another dimension to the architecture for Cyber Physical systems.

Most Cyber Physical Systems do not rely on internet lookups to function and if we apply Zero Trust ideology to the DNS architecture we should deny them access that is not necessary.  This architecture permits internal look ups and communications as needed but stops any communications, lookups, payloads, C &C, or other DNS mischief dead in its tracks. For the few systems that look up a single address for Firmware download or other sort of check ins or even for cloud-based management, simply add conditional forwarders for those domains. (i.e. an imaging system might store images in the cloud and need a set of internet facing addresses so only allow lookups for that domain).

This method can take some time to set up, but is overall much more secure and will protect your most valuable and critical systems from DNS-related exploit and harm.

In Summary 

  1. Do not allow internal HOSTS to query the internet directly.
  2. Do not trust external nameservers (like Verizon and Google).
  3. Leverage Secure DNS providers like Cisco Umbrella, Neustar, Akamai and others for recursion and further leverage DNS Security in the form of Response Policy Zones (RPZ) internally.

Interested in Learning More?

Subscribe today to stay informed and get regular updates from Ordr Cloud

Ready to Get Started?