DNS attack prevention: Inside DNS components vulnerable to attack

DNS attack prevention demands an understanding of the four core DNS components attackers often target. Expert Char Sample explains.

This Content Component encountered an error

This tip is part of SearchSecurity.com's Security School lesson, Securing DNS Infrastructure. For more information, visit the lesson page; for additional learning resources, visit the Security School Course Catalog page.

 

The domain name system (DNS), one of the Internet’s foundational infrastructure services, has become a popular target for Internet attacks. Hackers are taking advantage of the inherent trust that applications place in DNS to carry out attacks that redirect legitimate traffic to attack websites, or carry out denial-of-service attacks.

Applications rely on a properly working DNS in order to perform their functions as needed. Infrastructure services, such as DNS, are typically invisible to end users; they must be reliable and highly available. As a result, however, attack detection becomes more difficult. For example, an end user, and most applications, attempting to reach www.cnn.com would not verify the IP address mapping in order to validate the destination, due to the inherent trust of the operating system and the Internet infrastructure.

In order to understand key concepts of DNS attack prevention, a basic understanding of DNS components is helpful. There are four major components associated with DNS operations: stub resolver, recursive resolver, authoritative nameserver and the caching nameserver. While each component is an attractive target, the caching nameserver has gathered the most attention, regarding DNS attacks.

DNS attacks, components, queries and responses responses
The DNS stub resolver is the resolver most often found on client machines. This software forms the request and sends it to the caching nameserver (CNS) within the user’s domain. Generally speaking, caching functionality and recursive service reside on the same host; however, these functions can also be separated. When the request reaches the CNS, a check is performed in order to determine if the record already exists in the cache. If the record exists, the response is given; otherwise the recursive resolver requests resolution and recurses through the DNS hierarchy, in search of an answer. Each path along the hierarchy represents an opportunity for request or response modification.

The authoritative nameserver is, as the name implies, the authoritative source for the DNS response. While DNS is hierarchical in design, zone administration is distributed in implementation. Authoritative responses come from the registered authoritative nameserver, while non-authoritative responses are the cached responses received from caching nameservers.

Considering all of the moving parts associated with DNS queries and responses, there are many attack vectors:

  • Queries can be intercepted from the stub resolver to the nameserver resulting in query redirection.
  • Queries from the recursive resolver can be intercepted and redirected also. Responses returned from authoritative nameservers can be modified before reaching the caching nameserver.
  • Denial-of-service (DoS) attacks can be leveled against authoritative nameservers, resulting in an outage.
  • A well-timed DoS attack against an authoritative nameserver, along with zone slamming can result in a legitimate domain being replaced with a fake domain.
  • Zone transfer data can become corrupted, or worse, the TCP channel used for zone transfers can be used to open a tunnel between two hosts for generic TCP communications.

DNS attack prevention: Mitigation tactics
There are a few tools and techniques that can be used to mitigate the majority of these DNS attacks. Three tools that provide the strongest defenses are DNS Security Extensions (DNSSEC), configuration best practices and DNS traffic monitoring.

DNSSEC provides the best defense against data modification. DNSSEC works through the use of digital signatures. A zone operator digitally signs the zone, so while the zone data is public and easily viewable, the digital signature protects the data from being modified in transit. It is very important to remember that simply signing a zone is not enough. A signed zone applies to the authoritative data for that zone, but does not protect against modifications to cached data. The recursive resolver that accepts DNS response from other authoritative servers must also be DNSSEC aware.

While DNSSEC provides a proven defense against data modification attacks, it is important to remember that DNSSEC does nothing to prevent DoS attacks. Also, DNSSEC key management requires careful planning and is not for the faint of heart.  There is no automated key exchange mechanism for DNSSEC keys; however, parents can create a chain of trust for all of their children. Also notable is the fact that the root zone has been signed and working for well over a year. The key that is used to sign the zone is known as the zone signing key (ZSK), and the zone administrator signs the ZSK with a key signing key (KSK). The KSK provides the final guarantee of authenticity and should be carefully stored. This is particularly relevant when considering IaaS cloud solutions.

The second mitigation area involves separation of functionality through configuration. Minimally, the caching service must be separated from authoritative response. This will minimize the impact of DoS attacks. A DoS attack aimed at the authoritative nameserver will allow the caching nameserver to continue to operate even if the authoritative nameserver is unavailable.

The final mitigation area involves monitoring of DNS data. DNS operates on port 53 both UDP and TCP. Simple queries and responses are UDP traffic. Larger payloads are usually associated with DNSSEC or zone transfers. Monitoring DNS destinations provides an opportunity to detect new usage patterns. In some cases, DNS monitoring provides the first clue in the emergence of a new attack, when internal hosts start contacting a new external host. Additionally, monitoring of DNS TCP traffic can detect unauthorized tunneling behavior. DNS TCP traffic should be restricted to DNSSEC traffic and secondary zone exchanges. DNS TCP traffic that is frequent (exceed the zone time to live specification) could be an indication of a tunnel and should be investigated.

DNS is an attractive attack target because it is integral to the operation of networked applications and services with weaknesses that are often hidden or out of the control of the application owner. Attacks to DNS service range from data modification to DoS and encompass other behaviors such as request redirection and tunneling behavior. Data modification attacks can be mitigated through the deployment of DNSSEC; however DNSSEC has limitations and must be supplemented with careful configuration and DNS data flow monitoring.

About the author:
Char Sample has close to 20 years of experience in Internet security, and she has been involved with integrating various security technologies in both the public and private sectors.  She is a doctoral candidate at Capitol College, where her dissertation topic deals with the use of soft markers in attack attribution.

This was first published in May 2012

Dig deeper on Monitoring Network Traffic and Network Forensics

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

0 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

-ADS BY GOOGLE

SearchCloudSecurity

SearchNetworking

SearchCIO

SearchConsumerization

SearchEnterpriseDesktop

SearchCloudComputing

ComputerWeekly

Close