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.
Because of the unique nature of the domain name system (DNS), it is important to remember not all misbehaving DNS traffic is attack traffic. This is important to note because many security experts will focus on known DNS vulnerabilities when securing the enterprise DNS infrastructure. This is a rather short-sighted strategy that can still leave a site open to many other exposures, such as zero-day attacks and protocol exploitations.
DNS denial-of-service (DoS) attacks: Reflector attacks are the best example of exploits of denial-of-service vulnerabilities in default DNS configurations. Default configurations of ISC BIND and the DNS Server Service in Windows 2000, 2003 and NT 4.0, for example, were vulnerable to reflector attacks.
DoS attacks are typically difficult to defend. This particular DoS attack was invoked against the DNS application by taking advantage of normal recursive DNS lookup behavior. By separating out the functionality between authoritative nameservers and recursive resolvers, sites are able to direct externally sourced queries to the authoritative nameserver, and recursive resolution is performed only for local clients. This prevents an external user from having the site’s recursive resolver seeking query resolution on behalf of an external entity.
Query or request redirection: Request redirection occurs when the DNS query is intercepted and modified in transit to the DNS server. If the request is redirected on the path to the caching nameserver, this indicates that the interception occurred on the LAN. This is significant because the mitigation technique differs from redirection that occurs outside of the local network. Query interception can also occur on recursive queries outside of the local network.
Query redirection that occurs outside of the local network can be mitigated through the use of DNSSEC. The recursive resolver must turn on the DNSSEC enables flag in the name daemon configuration file. DNSSEC-enabled validation checks works when the zone data is signed; not all public zones are signed. In the case of a LAN interception, or an unsigned response, traffic monitoring is needed. New addresses should be minimally compared against black lists and whois registrations.
DNS cache-poisoning attack: These attacks have been around for quite some time and can cause high levels of damage because they result in the user being sent to a malicious site when the user enters in the correct name. The most recent noteworthy cache poisoning attack is the Kaminsky bug. Discovered by researcher Dan Kaminsky, the bug resulted when the random values for transaction ID and source port were easily guessed, thereby, allowing the attacker to insert a “poisoned” value.
When the Kaminsky attack was first discovered, it was noted that sites running DNSSEC with DNSSEC validation enabled were immune to the attack. This single fact did much to increase the number of DNSSEC deployments. The patch for this problem made the random number for the return port a stronger number to crack. Presently, this fix also works, but given the history of random number breaking and Moore’s law, the safer tactic is to deploy DNSSEC with DNSSEC validation enabled.
Zone enumeration: Enumeration of zone data occurs when a user invokes DNS diagnostic commands, such as dig or nslookup, against a site in an attempt to gain information about the site’s network architecture. Often times this behavior precedes an attempt at an attack.
Mitigating zone-enumeration threats requires the site administrator to determine what the site wishes to advertise to the Internet. This can require some extra planning if the site is also running DNSSEC, because only one zone can be signed. Many sites split DNS views by running internal and external DNS servers.
Tunnels: Most of the attention paid to DNS security focuses on the DNS query and response transaction. This transaction is a UDP transaction; however, DNS utilizes both UDP and TCP transport mechanisms. DNS TCP transactions are used for secondary zone transfers and for some DNSSEC traffic. Andreas Gohr, details how to tunnel any TCP traffic over port 53.
Mitigating DNS tunneling traffic relies on a combination of traffic monitoring and server configuration. Zone transfers should only occur between the authoritative server and the secondary server. This should be fairly straightforward, since the secondary server is a known entity and should be in the whitelist. Things get more interesting when dealing with DNSSEC traffic. DNSSEC traffic that utilizes the TXT record will need to have external sources monitored and compared. In addition to examining the external addresses, the quantity of transactions should also be monitored, since this could be an indication of DNS misuse.
DNS fast flux: Fast flux represents the ability to quickly move the location of a Web, email, DNS, or any Internet or distributed service from one or more computers connected to the Internet to a different set of computers to delay or evade detection.
Defending against fast flux sites requires monitoring and blocking techniques. In some cases, there are known IP address ranges that are associated with fast flux behavior, so these addresses can be blocked. However, the dynamic nature of these sites makes monitoring as important as blocking. A sudden appearance of new destination addresses requires investigation in order to determine if the site is legitimate or a potential fast flux site.
Phishing and pharming are big business in cybercrime and rely in part on DNS exploits. Phishing utilizes fast flux behavior when a link to a fast flux address is inserted in a targeted email. Pharming is associated with poisoned DNS cache records or DNS redirection, which occurs when a user enters a legitimate destination address but the request is redirected to a malicious site.
DNS is an attractive attack target due to the fact that DNS is an application that acts as an infrastructure service. The types of DNS attacks in use today are numerous, complex and popular. Mitigating DNS risks relies on DNSSEC, traffic monitoring and configurations that separate (and isolate) the various DNS functions. There is much more that can be written about DNS security and the threat landscape continues to evolve.
It should be noted that these recommendations work well in the standalone environment and they also provide the foundation for DNS security in the cloud. However, the cloud introduces additional concerns and new potential vulnerabilities that are beyond the scope of this article.
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.