Defending DNS

2349 0

The Domain Name System, or DNS, is arguably the most important system on the Internet. Without it, we’d all have to memorize IP addresses the way we once did the phone numbers of our friends and family by heart. Actually, in the case of IP addresses, we’d probably just not use the Internet, at all, since even the web applications we use rely on DNS to call services and content from other addressable locations on the Internet. As security or IT practitioners, we spend a lot of time securing and ensuring the availability of applications. However, none of them would function either if DNS wasn’t available.

So, for those of us tasked with securing and ensuring the availability of DNS, we clearly have our work cut out for us. Since most DNS systems must be available via UDP in addition to TCP, criteria such as source IP address are no longer meaningful. Doubly so, when the entire Internet must be able to resolve your host names. While there have been many vulnerabilities tied to BIND (the world’s most prevalent DNS server), there are books written on how to harden your installation, and staying patched will mostly prevent most malicious exploits. If those challenges weren’t enough, the prevalence of open network paths on DNS’ popular protocol port 53 introduces vectors for data loss via malware infections or other sources of DNS tunneling.

Many DNS servers enable us to detect abuses of the DNS protocol like the tunneling example above. DNS protocol validation (ensuring that requests are well-formed) as well as filters for record types (for example, allow A record requests, deny TXT record requests) and opcodes are useful and effective mitigation techniques. Many IPS and firewall systems can augment the DNS server’s own protocol stack by monitoring for known malicious patterns in DNS query payloads, usually via signatures. And although UDP means source IP addresses are trivial to forge, there are still some very good IP address reputation lists that will help reduce the noise from known bad sources.

At this point, we’re starting to feel a little more confident that we can effectively secure DNS services in our data center. However, what about availability? DNS itself is vital to the availability of virtually every other service on the Internet. What threatens the availability of DNS?

Denial of service attacks are pervasive, affecting every industry vertical as well as every Internet protocol. DNS is no exception. DNS amplification attacks (again, leveraging UDP) are not only capable of DoS’ing DNS services, but flooding massive amounts of bandwidth, as well. Service-based scrubbing solutions are good solutions for handling these kinds of bandwidth-based DoS attacks. Other DNS DoS vectors such as over-sized TXT payloads and NXDOMAIN request-floods (request for non-existent records) can be mitigated by appropriate protocol-level filtering, assuming your DNS server or firewall can detect and keep up with the request volume.

However, this leaves the most insidious type of DNS DoS attack: request floods for legitimate records. In this scenario, the DNS requests are well-formed, defeating any protocol validation filter. Additionally, these requests can’t be denied or filtered based on source, especially if the attackers are wise enough to effectively randomize their source IP addresses. At best, you can hope to throttle or rate-limit requests, but this mitigation technique means that all users will see slower than normal DNS resolutions. When seconds count in page-load time, adding overhead is likely unacceptable. One option is scaling out the DNS server environment, but even with dedicated DNS servers, performance limits for authoritative responses is limited to a mere 200K queries per second. Hosted DNS services are another options for dealing with query volume, but these services are also not immune to DoS attacks.

Because DNS query floods can reach volumes in the millions per second, the investment in BIND-based appliances or hosted DNS service can become cost-prohibitive. Most DNS firewall solutions will also struggle to keep up at these volumes and, in fact, can become DoS vectors themselves. The reliance on BIND limits performance, and avails attackers of potential vulnerabilities of an unpatched system. Seeking out a hardened DNS firewall solution that is able to keep up with authoritative response volume while still performing protocol validation and other security functions is a key component of DNS defense in depth.

In seeking an alternative approach to DNS firewalling, security practitioners should seek out proxy-based solutions able to parse the complete DNS request including payload, ensuring that tunneling or other malicious content is not present. For this reason, network firewall ALG’s and IPS/IDS solutions that rely on traffic sampling will often be bypassed by persistent malware or other threat actors. An effective DNS firewall should also not be based on BIND, if possible, to reduce the known vulnerability attack surface and provide greater query response performance without need of a large DNS server farm. In essence, attempting to protect DNS servers with host-based and/or BIND-based solutions alone runs counter to a defense-in-depth strategy.

A robust DNS firewall solution should offer :

  • High performance (500K to 1M+ query responses per second)
  • DNS services not rooted in BIND, or hardened/optimized to reduce risk
  • Full DNS request parsing and protocol support
  • Support for Response Policy Zones
  • Caching resolver (outbound) and authoritative screen (inbound) functionality
  • Request and response logging
About Brian A. McHenry
Brian_McHenryAs a Security Solutions Architect at F5 Networks, Brian McHenry focuses on web application and network security. McHenry acts as a liaison between customers, the F5 sales team, and the F5 product teams, providing a hands-on, real-world perspective. Prior to joining F5 in 2008, McHenry, a self-described “IT generalist”, held leadership positions within a variety of technology organizations, ranging from startups to major financial services firms.

Twitter: @bamchenry


In this article