The Domain Name System (DNS) has long been a favored target for threat actors looking to disrupt victims. Whether criminals are looking to use DNS to misdirect traffic in order to steal information, gain access, or launch attacks that deny access to a victim’s resources, it is a critical link that can become a huge vulnerability.
DNS vulnerability was put under the spotlight in the Mirai attack on the DynDNS service in 2016. In that case, attacking a single DNS source had an impact on scores of major organizations. And that’s one of the great attractions DNS has as a target: Disrupting DNS can have an outsize impact on the organization (or organizations) hit by an attack.
Other qualities make DNS a favorite tool for hackers. Because the information returned is considerably larger than the query, and DNS is a service that nearly every firewall will allow to pass, DNS servers make useful amplification tools in DDoS attacks. That usefulness means DNS servers and services need to be protected in two different dimensions.
First, DNS must be protected so that it continues to resolve names consistently and correctly for the organization it serves. Next, it must be protected so that it can’t be used as a weapon against other organizations and individuals. Many of the steps to protect one will protect the other, but some defensive mechanisms focus on one aspect or the other.
Many of the protective steps on this list can be taken without rushing out to buy new networking hardware. The question for many organizations will be how to prioritize defensive steps and ensure that all the steps taken work in harmony to protect an organization’s network, applications, and users.
To a great extent, protecting DNS today begins with DNSSEC. The DNS Security Extensions handle one set of tasks, but it’s an extremely important set in the overall scheme of things. DNSSEC is all about making sure that the server (or service) you want to talk to is the one you’re actually talking to.
DNSSEC uses a DNSSEC-validating DNS resolver to check DNS signatures and ensure that the resolution information has not been changed and the responding server is the correct server. It’s important to note that the signatures in DNSSEC aren’t used for any sort of encryption — they’re only responsible for validating the identity of the servers involved.
It’s also important to note that DNSSEC can protect more than Web pages. Any service that uses a DNS-based address, from email to instant messaging, can benefit from the server authentication provided by DNSSEC.
DNS is, by its very nature, a distributed architecture. From the root servers, to authoritative servers, to the local DNS servers that organizations might host to speed queries, DNS was designed to spread its workload to a huge number of servers. That’s a good thing, but it can be even better if an organization optimizes the distribution of its resolving servers.
Distribution in service to security can mean having multiple DNS servers or services available in a redundant configuration. As an example, if your organization manages its own DNS server, a contract with a DNS service such as Oracle Dyn, Edgecast, or Cloudflare can be a significant contributor to system resilience in the case of a DDoS attack against the local server or an identified case of a server being used as the reflector in an attack on another.
Building the switchover into the playbook for attack remediation (and practicing the procedures in the playbook on a regular basis) will be instrumental in minimizing the effects of a DNS-targeting DDoS attack on the organization.
Security information and event management (SIEM) systems are not specific to DNS, but they can be critical for ensuring the continued operation of the DNS server in the case of an attack. As with any other network service being monitored, the key to effective use of the SIEM is linking the DNS server’s information source to the SIEM.
While there are elements of the linking that will be specific to the particular SIEM in question, other aspects are common to many systems. In addition, staff will need to decide which events are appropriate for which types of alerts and automated responses.
It’s obvious that SIEMs are not the only security devices that are available to protect DNS. In particular, a next-generation firewall (NGFW) may be the central component in a security matrix that includes DNS protection. But for most organizations, including DNS information in the SIEM’s input will be an important early step in protecting their DNS.
Response Policy Zones (Blacklist)
One of the most common ways that DNS is used for an attack is when a DNS server is fed incorrect or counterfeit data. This article has already presented DNSSEC as one method for fighting incorrect server information. But another method, the DNS Response Policy Zone (RPZ), can be particularly useful when either bad or preferred servers are known.
The first use of the RPZ is to block access to known bad destinations via a black listQ@. These could be recognized command-and-control (C&C) servers for botnets and malware or websites that are known to be hotbeds of malware distribution. A number of different organizations maintain lists of these known servers — organizations that include Dissect Cyber, Infoblox, Spamhaus, and SURBL.
Depending on the nature of the bad site, users entering the link can be dropped, redirected to the “real” site for which the masquerade is underway, or directed to an information page explaining that the chosen site is bad and can’t be visited from the organization’s equipment and network. These responses demonstrate another set of uses from a different RPZ capability: the whitelist.
Response Policy Zones (Whitelist)
Just as RPZs can prevent users from visiting known bad sites, they can ensure that careless or clumsy users go to known good sites that can educate and protect them from malware writers and themselves.
RPZ was developed as part of the Berkeley Internet Name Domain (BIND) system that is part of virtually every Linux distribution and is the default DNS server for Linux. When blocking sites, as in the blacklist, RPZ is often described as being a DNS firewall. When it doesn’t simply block but redirects the user to a synthesized, known good or informational site, it is part of a “walled garden” of safe destinations.
BIND is open-source and vendor-neutral. A number of different companies and organizations provide the reputation information on which RPZ responses are built; it is possible to subscribe to multiple reputation lists for more complete or comprehensive coverage.
DNS becomes a weapon when a DNS server is flooded with requests from a spoofed address; when data is returned, it overwhelms the innocent victim. The weaponization can be reduced when the rate of responses to queries from a single address is limited.
In BIND, rate limiting is relatively straightforward to implement using a standard command. With this, an administrator can specify how many queries from a single address per second will receive a response. In other DNS systems, such as the Windows DNS server, the process is similar, though the options for fine-tuning the limits might vary so that queries from known good addresses or subnets are handled differently than those from “the wild.”
Rate limiting, set up properly, can restrict the ability of hackers to use the DNS server as a weapon while allowing it to serve the DNS needs of the organization’s legitimate users. Issues like IPv6, with its larger headers, make setting rate limits more complex but also make using rate limiting more critical to maintain good Internet neighbor cred in the online neighborhood.
DNS remains a critical protocol for Internet activity of all types. Unfortunately, those activities will continue to include malicious actors for the foreseeable future. Using available services and technology will allow organizations to be safer in their DNS use while maintaining the performance and functionality their users demand.