Securing DNS Servers

---

Earlier in this chapter, you learned about the general principles that you can apply to secure your infrastructure servers, including DNS servers. In this section, you will learn the different techniques within the DNS service itself that can be configured to increase the level of security for your organization.

Probably the single most important service running in support of Active Directory is the DNS service. If an attacker can gain control of your DNS infrastructure, there are several ways that your organization’s security can be compromised. One of the simplest exploits occurs when insecure zone transfers are allowed. Insecure zone transfers would allow an attacker to request your entire DNS zone, thereby giving the attacker all of the names and TCP/IP addresses of the hosts in your network. In addition to the names and addresses of the hosts, the attacker would know which servers are running which services.

In Figure 8.6, you can see that having an entire zone returned to a server that you don’t control would allow an attacker to view, among other things, the SRV record for the Global Catalog server, the Kerberos server, and so on.

Figure 8.6: DNS zone SRV records

Once the attacker has this information, they would know enough to direct attacks at the servers that host the services that they want to hijack. The attacker could spoof or poison the DNS data so that a DNS query would return their server’s address when a request is made for a trusted server.

If zone transfers must be allowed, you should prevent an attacker from retrieving the entire zone. You accomplish this by specifying which servers are allowed to receive the zone data. The most secure setting is to supply the IP addresses of the authorized DNS servers, setting it to Only To Servers Listed On The Name Servers Tab. This setting requires a DNS lookup to determine whether or not the requesting server is allowed to receive the zone transfer. This would be susceptible to DNS spoofing. To alleviate the potential for DNS spoofing to affect your DNS security, you should select the Only To The Following Servers option and manually add the IP addresses of the appropriate servers, which eliminates the need for a DNS lookup. These settings can be modified in the Zone Transfers tab of the DNS server Properties window, shown in Figure 8.7, from the DNS Management MMC snap-in.

Figure 8.7: Zone Transfers tab

Note

By default, zone transfers are disabled.

The next DNS-specific vulnerability that can be exploited is the dynamic update feature. The most secure solution is to simply disable dynamic updates; however, this would require much more administrative tasks. To disable dynamic updates completely, you would set the Dynamic Updates drop-down list on the General tab to None, as seen in Figure 8.8.

Figure 8.8: Dynamic updates via the General tab

Real World Scenario: Preventing Attacks by Securing DNS Updates

Jim is the security architect of a small financial institution that processes market trades for its customers. The employees answer calls in a call center and process the trades using a web application. In addition to the line-of-business application that processes the market trades, all applications are run from an internal web server, including the human resources and accounting applications.

Because all of the applications are run from the finbank.net domain, it has been added to the trusted zones for all workstations in the domain. When employees enter the web address into their browser, a DNS lookup will return the address of the server—which may change—that is running an ASP.NET web application.

An attacker is able to modify the DNS entries by updating the DNS server and changing the record of the trusted server so that it points to a server that the attacker controls. Now when employees navigate to the site that they believe is running their business applications, they are in fact navigating to the attacker’s website. The site is considered trusted by the users’ browsers and will be given the permissions as such. This may allow certain applets to run and access sensitive information on the workstations of the users.

After discovering the attack, Jim changes the permissions on the DNS server so that it supports only secure updates.

If you decide to support dynamic updates, you will want to make sure that only secure updates are allowed, which prevents unauthenticated users from creating entries. If you allow insecure updates, anyone could create a record in your DNS zone that points to the server of their choice. To support secure updates, the zone must be Active Directory–integrated to provide discretionary access control lists (DACLs) on the DNS data.

You should have a separate DNS infrastructure for your public or Internet presence and your internal network. The internal DNS servers could support dynamic updates, while the public DNS servers would not. Also, by default the DNS service will listen on all interfaces on the computer. If the DNS service is running on a multihomed computer, you should specify which interfaces it should be listening and responding to.

The last major attack to DNS is accomplished by poisoning the DNS cache. An attack of this sort is very difficult to prevent if you control the master server for the zone and nearly impossible if you do not control the master server. Poisoning, in this scenario, refers to changing the data in the cache on the downstream DNS servers such that they are pointing to bogus or malicious addresses instead of the proper address. This can occur because of a malicious or invalid update to the master server that gets propagated to a downstream DNS server where it is considered to be valid until the cache expires. Figure 8.9 shows the correct process of DNS caching.

Figure 8.9: Proper DNS caching process

If a hacker can modify the cache on the ISP’s DNS server, any requests for that cached data will be serving the malicious information. In Figure 8.10 it is an attacker’s IP address.

Figure 8.10: Compromised process

You can minimize the poisoning of the DNS cache to a certain extent by selecting the Secure Cache Against Pollution option (the default setting) on the Advanced tab in the DNS server Properties dialog box (see Figure 8.11).

Figure 8.11: DNS server properties

In the “Securing the DNS infrastructure” Design Scenario, you will evaluate the scenario and make the appropriate security-driven decisions to secure the DNS infrastructure.

Windows 2003 DNSSEC Support (RFC 2535)

The security extensions that were added to DNS, named DNSSEC, describe the services that perform data origin authentication and integrity checking. Windows Server 2003 DNS does not fully support the features specified in DNSSEC. Windows Server 2003 DNS provides, as stated by Microsoft, “basic support” of the DNS security extensions, which means that Windows Server 2003 DNS servers can be secondary servers to an existing DNSSEC-compliant secure zone. Windows Server 2003 is not capable of signing zones and resource records or validating the SIG resource records. The DNSSEC resource records are SIG, KEY, and NXT. For more information, examine RFC 2535.

Design Scenario: Securing the DNS Infrastructure

You are the security architect of a large company that will be using a Windows Server 2003 Active Directory domain. You will have an Internet presence in which your organization will be maintaining its own DNS records for the Internet-accessible servers. You also need to support dynamic DNS for your internal network. Currently, you have two DNS servers, one for the Internet hosts (your ISP will maintain a secondary DNS server for your Internet domain) and the other for the internal hostname resolution. The IT budget will allow for the purchase of just one more server to maintain the internal DNS infrastructure.

1. Question: You need to make sure that you prevent an attacker from the Internet from making unauthorized changes to the DNS servers while minimizing the administrative requirements of maintaining these servers. What should you do? Answer: You should first make sure that the Internet-accessible DNS servers do not allow dynamic updates. You should also configure an IPSec policy that prevents the internal DNS servers from being accessed by any computers outside of the local network segment. In addition, you should configure the internal DNS server to accept only secure updates and to allow zone transfers to the new backup DNS server by IP address only.

---