Windows Server 2003 : Planning DNS Security

Determining DNS Security Threats

DNS name resolution is an essential part of TCP/IP networking. Both Internet and Active Directory communications rely on the ability of DNS servers to supply clients with the IP addresses they need. There are two primary security threats associated with DNS: interruption of service and compromise of DNS data. As part of your name resolution strategy, you must evaluate the threats to your DNS servers and the possible consequences, and then take steps to protect the servers without compromising their functionality.

Some of the potential threats to your DNS servers are as follows:

• Denial-of-service (DoS) attacks Flooding a DNS server with huge numbers of recursive queries can eventually force the processor to 100 percent usage, preventing the server from processing name resolution requests from actual clients. This type of attack does not require a great deal of skill from the attacker, and can be extremely effective in shutting down a network. The inability to resolve DNS names can prevent users from accessing Internet resources, and even from logging on to Active Directory servers.

• Footprinting Intruders gather information about a network’s infrastructure by intercepting DNS data, usually to identify targets. By capturing DNS traffic, intruders can learn the domain names, host names, and IP addresses you are using on your network. This information frequently discloses the functions of specific computers on the network, enabling the intruder to decide which ones are worth attacking in other ways.

• IP spoofing Intruders can use a legitimate IP address (often obtained through footprinting) to gain access to network services or to send damaging packets to network computers. Spoofing can enable packets to get through filters that are designed to block traffic from unauthorized IP addresses. Once granted access to computers and services using this technique, the attacker can cause a great deal of damage.

• Redirection In this type of attack, an intruder causes a DNS server to forward name resolution request messages to an incorrect server that is under the attacker’s control. The attacker usually accomplishes this by corrupting the DNS cache in a server that is using unsecured dynamic updates.

Securing DNS

A number of techniques can protect your DNS servers and your namespace data from attack, and it is up to you to locate the threats to your servers and to determine what steps to take to protect against them. As with most security problems, it is just as possible to err on the side of caution as it is to be negligent. As an example of negligence, not implementing security measures can leave your DNS servers open to access from the Internet and can allow them to exchange zone transfers and dynamic updates with any other computer. This leaves the servers vulnerable to any of the attacks described in the previous section.

At the opposite extreme, you can close off your network from the outside world by denying all Internet access, creating an internal root, using Active Directory domain controllers for your DNS servers, limiting administrative access to the DNS servers, and encrypting all DNS communications. These measures secure the DNS servers from most forms of attack, but they also compromise the functionality of the network by preventing users from accessing the Internet. There certainly are times when extreme measures like these are warranted, but it is up to you to decide what level of security your network requires.

Some of the security measures you can use to protect your DNS servers from outside (and even internal) intrusion are described in the following sections.

Providing Redundant DNS Services

When you use registered domain names on your network, your DNS servers must be accessible from the Internet, and they are therefore vulnerable to DoS attacks and other forms of intrusion. To prevent intruders from crippling your network by these attacks, it is a good idea to use multiple DNS servers to provide redundant services to your users. This type of protection can be as simple as configuring your DNS clients to use your ISP’s DNS server when yours is unavailable or unresponsive. This way, your users can continue to access Internet services, even when someone disables your own DNS server by a DoS attack. Unless the intruder attacks both your DNS server and the ISP’s server, name resolution services continue to function properly.

Deploying multiple DNS servers is also a way to protect your namespace from footprinting. Install one server on your perimeter network, for Internet name resolution, and another on your internal network, to host your private namespace and provide internal name resolution services. Then, configure the internal DNS server to forward all Internet name resolution requests to the external DNS server. This way, no computers on the Internet communicate directly with your internal DNS server, making it less vulnerable to all kinds of attacks.

Limiting DNS Interface Access

Another way of securing DNS servers against unauthorized access from the Internet is to limit the network interfaces over which the server can receive name resolution requests. If you have configured your DNS server computer with multiple IP addresses, you can click the Interfaces tab in the server’s Properties dialog box in the DNS console and specify the IP addresses that DNS clients can use to contact the server (see Figure 1). For example, if a server is connected to both an internal network and to the Internet, you can prevent the server from receiving name resolution requests that originate on the Internet.

Securing Zone Replication

Although it is possible to footprint a namespace by capturing name resolution traffic, a more efficient method (for the attacker) is to intercept zone replication traffic. By capturing zone transfer packets, for example, an intruder can get a complete picture of a zone and all its domains and hosts, at once.

The best and simplest way to secure zone replication traffic is to deploy all your DNS servers on your domain controllers and store all your zones in Active Directory. Active Directory is then responsible for performing all zone replication. All Active Directory domain controllers perform a mutual authentication procedure before they exchange data, so a potential intruder cannot use IP spoofing to impersonate a domain controller. In addition, Active Directory encrypts all traffic, which prevents anyone capturing the packets from reading the data they contain. Finally, access to the domain controllers themselves is restricted by the policies you already have in place to protect your other Active Directory data.

One way to protect zone transfer data is to specify the IP addresses of the DNS servers that you allow to participate in zone transfers. If you do not do this, a potential intruder can simply install a DNS server, create a secondary zone, and request a zone transfer from your primary zone. The intruder then has a complete copy of your zone and all the information in it. To limit zone transfers on a Windows Server 2003 DNS server, you open the DNS console, display the Properties dialog box for a primary zone and then click the Zone transfers tab to display the dialog box shown in Figure 2. Select the Allow Zone Transfers check box and then choose either the Only To Servers Listed On The Name Servers Tab or the Only To The Following Servers option button. You can then specify the IP addresses of the DNS servers that contain your secondary zones, in either the IP Address text box or the Name Servers tab.

Although the preceding technique can prevent unauthorized DNS servers from receiving zone transfers, it does not protect the packets containing the zone transfer data themselves. An intruder with a protocol analyzer, such as Microsoft’s System Monitor application, can capture the zone transfer traffic and read the data inside the packets. To prevent this, you can configure your DNS servers to encrypt their traffic using the Internet Protocol Security extensions (IPSec) or virtual private networking.

Preventing Cache Corruption

Potential attackers might try to load a DNS server’s name cache with incorrect information, in an effort to redirect client connections to other servers and gather information from the clients. The Windows Server 2003 DNS server includes a feature that helps to prevent cache corruption. In a DNS server’s Properties dialog box, click the Advanced tab (see Figure 3) and then select the Secure Cache Against Pollution check box under Server Options. Activating this feature prevents the server from caching unrelated resource records included in reply messages. For example, if a DNS server sends a query to an Internet server requesting the resolution of a name in the adatum.com domain, it would normally cache all the resource records supplied by the Internet server, no matter what information they contained. If you activate the Secure Cache Against Pollution option, however, the DNS server caches only resource records for names in the adatum.com domain. The server ignores all records for names in other domains.

Using Secure Dynamic Update

As the DNS was originally designed, administrators had to create all resource records by hand, typing the host name of each computer and its IP address or other information.

This eventually became a problem as the use of automatic IP addressing solutions such as the Dynamic Host Configuration Protocol (DHCP) became more prevalent. DHCP is designed to automatically supply IP addresses and other TCP/IP configuration parameters to computers, which means that it is possible for a computer’s IP address to change periodically. Because it would be impractical for network administrators to keep track of these changes and modify the appropriate resource records manually, the developers of the DNS created a new standard, referred to as dynamic update.

Dynamic update enables DNS clients on the network to send messages to their DNS servers during system startup. These messages contain the IP addresses the DHCP server has assigned to the clients, and this information is used by the DNS server to update its resource records with the new information.

Although dynamic update saves DNS administrators a lot of work, it also leaves the DNS servers vulnerable to serious forms of attack. An intruder could create a false dynamic update message and send it to your network’s DNS server. The message could state that your company’s Internet Web server has changed its IP address, forcing your DNS server to add a counterfeit address to the resource record for the Web server’s host name. From now on, Internet traffic intended for your company Web server is redirected to a server under the attacker’s control.

To prevent this from occurring, you should create Active Directory-integrated zones whenever possible, and configure them to accept only secure dynamic updates. The procedure is to display the zone’s Properties dialog box, click the General tab, and, from the Allow Dynamic Updates selector select Secure Only (see Figure 4).

Using Standard Security Measures

In addition to these specialized DNS security measures, you can also protect your Windows Server 2003 DNS servers from attack using the same techniques you use for any computer on your network. Limiting physical access to the server and using permissions to control administrative access are basics that you should not omit in the case of a DNS server, because intruders can come from inside the organization as well as from outside. You can also use the packet filtering capabilities of your firewall to control access to the computer itself and to Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) port number 53, which is the well-known port number for DNS.