If you would like to read the next part in this article series please go to DNS Security (Part 2): DNS Security Steps Prior to Deploying DNSSEC.
Introduction
Most of us take DNS for granted. In our everyday work on the Internet, we use applications that connect to the Internet automatically, without ever actually entering an Internet host name to resolve. And even when we open the browser and type a URL in the address bar, we don’t generally think about what’s happening on the back end to make sure that the name we typed in resolves to the correct IP address.
If you do think about it, though, you’ll realize that being able to use names instead of IP addresses is a huge convenience. Most humans can remember names far more easily than numbers. In the “olden days,” in order to place phone calls, we had to memorize (or look up) telephone numbers. Then speed dial came along, and today many of us couldn’t even recite the phone numbers of our closest friends and relatives because we have them “programmed” into our phones and can call them by simply touching their names in a list (or, to make it even easier, their photos).
Can you imagine having to remember the IPv4 addresses of all the hosts on the Internet that you want or need to connect to? Or having to flip through a book or scroll down a list to look them up manually? Even on your intranet, unless you have a very small network, it’s unlikely that you’ll be able to remember all of the IPv4 addresses of all the servers, much less the client IP addresses (which typically are assigned via DHCP anyhow). And when you consider that an IPv6 world is coming at us, slowly but surely, that scenario becomes even more problematic. Remembering the 128 bit IPv6 addresses would be virtually impossible, so in an IPv6 world, an accurate and reliable DNS isn’t a luxury, it’s an absolute necessity.
Here’s the problem. DNS was designed back in the early days of the Internet, when security was much less of an issue. Only governmental agencies and educational institutions really utilized the Internet then, and they were assumed to be trusted. Because it was a much more closed community, the protocol itself was left wide open. And today, in a completely different and much more high risk environment, DNS is vulnerable to attackers. The bad guys can create DNS denials of service, use “footprinting” to discover information about your network resources, spoof IPs, or redirect DNS queries to their own servers, which host malware.
Given the critical importance of DNS to normal network operations for both intranet and Internet connections, it’s clear that DNS security is an important consideration and something that shouldn’t be left to the “we’ll get around to that” pile. But before we get to the job of securing our DNS infrastructure, it would be interesting to examine some of the more common threats targeted against DNS servers. In general, you can categorize these threats as:
- Zone file compromise
- Zone information leakage
- Compromised dynamic updates
- DNS client flooding (denial of service)
- Cache poisoning
Zone File Compromise
In a Windows DNS server environment, the DNS server is hosted on one of a number of versions of the Windows Server operating system. The DNS administrator can configure the zone configuration and resource records using either a command line interface or the DNS mmc console. One of the easiest and most common ways your DNS infrastructure can be compromised is by someone who is able to directly edit the DNS server configuration or the resource records themselves right at the DNS server, or from a remote console.
This type of attack against DNS isn’t necessarily elegant or “extreme hAx0r” – in fact, it can be done by just about anyone with a little knowledge of DNS who has access to the server. The attacker can be physically sitting in front of the server, connected over RDP, or even logged on over Telnet. The perpetrator could be a malicious insider, or even a well-meaning admin who makes a critical mistake. The key security message here is that you should lock down the DNS server so that only authorized people are allowed access to the DNS configuration, and any remote access method to the DNS server should be limited to authorized individuals and perhaps authorized machines.
Zone Information Leakage
The DNS zone files on your DNS server contain the names of the computers in that zone, based either on manual configuration of the zone or via dynamic updates. On the intranet, you typically have a mix of manual resource record entries and dynamic registrations. The intranet DNS servers contain the names of all the servers on the network (or at least those you want to be accessible via names through DNS). On an Internet DNS server, you typically only enter the names of the servers that you want accessible over the Internet – although some of the servers may exist in an ISP hosting location and some of them may be located on your intranet.
Zone information leakage can take place when an intruder can gain important information about possible server roles on your network, based on the names of those servers. For example, if you have a server that is accessible via the name PAYROLL, that information could be very valuable to the attacker. This is sometimes called “footprinting.”
The attacker can discover the names on your network using a variety of methods. For example, if you enable zone transfer for all machines, then the intruder can download the entire zone database to his machine via the zone transfer mechanism. Even if you don’t allow zone transfer, a patient attacker can take advantage of reverse DNS queries to walk through your address space and discover the names of computers on your network. The attacker can create a comprehensive diagram of your network from this DNS data.
In addition, if the intruder can glean information about your network numbering scheme, he’ll be able to determine any unused addresses on the network. Then the attacker may be able to use those unused addresses to set up a rogue DNS server, since in many cases network access controls are set to an entire network ID or set of IDs, instead of individual IP addresses.
Finally, a common practice in small business DNS hosting (where the small business is hosting its own DNS services) is combining public and private zones on the same DNS server in a split DNS infrastructure situation. When you do this, you expose both your internal and external names in the same zone, making is much easier for an attacker to find out about your internal address space and naming conventions. Normally, the attacker would need to get inside your network to discover your internal zone information, but when the same server is hosting both public and private information on the same DNS server, you’ve done the attacker a big favor by making his life easier.
Compromised Dynamic Updates
DNS dynamic updates are a great convenience for the DNS administrator. Instead of being required to manually create records for all your clients and servers, all you need to do is enable dynamic DNS updates on both the clients and servers. When using Windows clients and DNS servers, you can even configure DHCP to support this dynamic DNS update function. With dynamic DNS update, you just need to turn it on and let the machines register themselves in DNS; there is no need for you to create manual DNS resource records.
Of course, as in most cases, there is a price to pay for convenience and in this case it is the potential security consequences of dynamic DNS. There are a number of ways that dynamic DNS updates can be performed, but in general you can categorize them as secure and non-secure updates. With secure updates, the client system has to be able to authenticate itself (for example, by using its computer account contained in the Active Directory) before it can dynamically update itself. Unsecure updates occur when you allow any host to dynamically register its address in DNS without requiring authentication.
Of course, secure dynamic updates are not all created equal; some are more secure than others. For example, if you limit the ability to join the domain to only domain admins or security admins, then dynamic DNS updates can be fairly secure in a Windows environment. However, if you allow any and everyone to join a machine to the domain, then you’ve lost the security that you would have otherwise have had if you had limited domain joins to trusted personnel.
Once the dynamic update process is compromised, the attacker can potentially change the information in key resource records so that names can be redirected to servers that the attacker has set up to attain the attacker’s goals (such as loading malicious software on your machine to make it part of a botnet that the attacker controls). Another thing that the attacker can do in this situation is create a simple denial of service (DoS) attack by just deleting key records, such as records for the DNS server or the domain controllers.
DNS Client Flooding (Denial of Service)
Speaking of DoS, if you have never been subjected to a DNS denial of service attack, then consider yourself fortunate. Because DNS queries are not authenticated, the DNS server will always attempt to answer the DNS queries it receives; after all, that’s its job. This means that it’s relatively easy to launch a distributed denial of service (DDoS) attack against a DNS server, and here are plenty of botnets out there that exist specifically to create these kinds of DDoS attacks so that a DNS server will be disabled long enough for the attacker to put up a rogue DNS server that will answer the queries on its behalf. Users will have no way of knowing that the new DNS server is actually a malicious one, and they will be redirected to sites that are owned by the attacker. These sites are usually designed to mimic real sites and use (or rather, misuse) the trust that users have in those real sites, in order to gain access to personally identifiable information that can potentially be used for identity theft.
Cache poisoning
DNS servers query other DNS servers to get information as part of their participation in DNS query resolution. To improve the performance of the overall DNS infrastructure, DNS servers will cache the results of DNS queries for a period of time typically assigned to the resource record that provides the name resolution. If a second query for the same name comes before the timeout for the resource record, the DNS server will respond with the information that it has stored in the DNS cache instead of querying another DNS server again.
While this improves the overall efficiency of the entire DNS infrastructure, it also opens up a potential security hole. The threat that exploits this security hole is called “DNS cache poisoning”. DNS cache poisoning takes place when the DNS server sends a query to another DNS server and that DNS server returns false information about the resource. In most cases, the DNS server that returned the false information was compromised in advance.
Cache poisoning can take place because often DNS servers do not check for the validity of the responses, nor do they verify that the responses they get from other DNS servers have anything to do with the original DNS query. The “client” DNS server will receive the information in the response and cache that information, and then provide that false cached information to machines that are configured to be DNS clients of the DNS server whose cache has been poisoned.
Conclusion
In this article, we took a look at some issues in DNS security and how the security of your DNS servers can be compromised. In part 2 of this article, we’ll take a closer look at some of the things you can do to improve your overall DNS security design and we’ll drill down into a security feature in Windows Server 2008 and above that’s called DNSSEC. We’ll configure a secure zone using DNSSEC and explain how you can use DNSSEC to improve DNS security for your organization. See you then! -Deb.
If you would like to read the next part in this article series please go to DNS Security (Part 2): DNS Security Steps Prior to Deploying DNSSEC.
