11.2 DNS

Domain Name System (DNS) is in use on virtually all TCP/IP networks as the predominant name resolution service. Although simple in design, its original specification severely lacked any security considerations. However, many innovations have been made since its original release and now DNS is far more securable than before. In addition, employing a few important best practices can keep this system reasonably safe against attackers.

11.2.1 What Is DNS?

DNS takes the friendly textual name of a computer, such as www.contoso.com, and resolves it to an IP address such as 131.107.2.200. That IP address can then be used by TCP/IP to locate and communicate with the desired computer.

DNS is important because humans do not memorize numbers well. We can remember that www.contoso.com is a great web site, but we cannot easily remember that to communicate with it we need to type http://131.107.2.200 into our web browser. DNS solves that problem for us.

Essentially, DNS is just a big distributed database. The data is formatted into individual records that store information. DNS allows users and administrators to add records to, manage, and retrieve records from the database it maintains. There are numerous record types available in DNS, each representing the type and use of the data it stores. In this chapter, we're mostly concerned with A records (Address records) that map a hostname to an IP address and PTR records (Pointer records) that map an IP address back to a name. However, there are many more record types. They're listed in detail in RFCs 1035 and 1183.

Because the Internet is such a large place, no DNS server has a record for every single computer available. Instead, DNS supports a referral system. If your computer asks DNS to find a record for a computer name it doesn't know about, it has the ability to ask other DNS servers to help you. It can also give you a "next step" referral and allow your computer to contact another DNS server that may be able to resolve that name. These queries are known as recursive and iterative, respectively. I'll discuss the security concerns about recursive queries and how to mitigate them later in this chapter.

Because DNS is in such widespread use at this time, a lengthy explanation is avoided here. For more details, the authoritative reference on the topic is DNS on Windows Server 2003 from O'Reilly.

11.2.1.1 Requirements for DNS

Windows Server 2003 includes a DNS server component. Installing it requires nothing above the basic system requirements for Windows Server 2003. However, there are some security advantages to installing your DNS server in a domain environment or even on a domain controller.

11.2.1.2 DNS zone storage

Standard DNS terminology defines zone storage in a single fashion?there's only one kind. Windows Server 2003 offers two types of zones: standard (also called file-baked) and Active Directory-integrated. There is an enormous difference in security functionality between the two. You should be familiar with the benefits and drawbacks of each.

11.2.1.2.1 Standard DNS zones

Standard DNS zones are stored in a very simple manner. They're kept in a text file on the hard drive of the DNS server. This file isn't encrypted or protected in any special way. This allows administrators to directly modify the zone file if they so choose. It also provides some simplicity in that the DNS server always has a local copy of the zone file. Windows Server 2003's DNS server allows you to create a standalone DNS server in virtually any configuration, as there are no prerequisites or required underlying technologies needed.

However, standard DNS zones present many security concerns. Primarily, the text file on the hard drive is subject to tampering. The tampering can be done quite easily with an application such as Notepad and may be very difficult to monitor and trace. In addition, no security (beyond the standard NTFS ACL) can be applied to this type of zone for the same reason.

11.2.1.2.2 Active Directory-integrated DNS zones

Another place to store the DNS zone data is a database. Conveniently, Windows Server 2003 domains already have a database: Active Directory. Active Directory-integrated zones are simply zones in which the data is stored in Active Directory instead of a text file on the hard disk. While this change of data storage sounds (and is) simple, it provides numerous security advantages. It also has some requirements that standard zones do not.

Active Directory-integrated zones provide several features, including:

Security tab

The properties of each zone allow you to configure that zone. When you create an Active Directory-integrated zone, the properties of that zone display a security tab. That tab allows you to set permissions on the zone, similar to setting permissions on other objects in Active Directory. For example, you can explicitly deny users of some lesser-trusted groups access to the zone data entirely, while making other groups read-only for the zone data.

Require secure dynamic updates

In traditional DNS configurations, an administrator maintains the zone database manually. But newer versions of Windows help lessen that maintenance burden. Servers can be configured to allow clients to update their own DNS records automatically through a process called dynamic update. This is especially useful when using DHCP, because addresses may change more frequently than an administrator can handle. If the clients and servers are performing these updates automatically, having stale DNS record information can be avoided.

Dynamic update has a flaw: anyone can make the update. So someone could replace existing legitimate DNS data with data of their preference. We answer this problem with secure dynamic update. This is a feature of Active Directory-integrated zones in which the client must prove its identity and perform the DNS update through a secure channel. Unknown clients are unable to change or add DNS data.

Zone replication control

Because zone information is stored in Active Directory, it can be easily replicated to other servers. DNS allows you to control the zone data replication to ensure that it is not replicated to inappropriate servers where the data might be compromised. This is a desirable security feature, and it helps regulate network bandwidth consumption by zone data.

Of the two types of zones, Active Directory-integrated zones obviously have more security features that we can use to protect against attackers. If you're using Active Directory in your environment already, you should consider using Active Directory-integrated zones. They truly provide huge benefits against denial-of-service attacks and allow you to optimize more of your networking environment. To be fair, standard zones can maintain reasonable security. But if you're already paying the price for the Active Directory-integrated zones, you should use them.

For much more information on zone configuration and requirements, see DNS on Windows Server 2003 (O'Reilly).

11.2.1.3 DNS security concerns

The benefits of using DNS in your environment are clear and should already be apparent to you. However, the benefits should be weighed against the drawbacks. None of these threats exists entirely because of DNS. But DNS often makes attacks in this area easier to implement.

When the RFCs that define DNS were created (RFCs 1034 and 1035), the Internet was a small and reasonably secure place. Access was largely restricted to computer übergeeks and military personnel. Because access was restricted and because little or no malicious intent existed on the Internet at that time, DNS was designed without any security considerations. In fact, a search of RFC 1034 and 1035 on the word security results in no hits.

Because the world has changed and the Internet is now peopled with malcontents and miscreants, DNS comes under frequent attack. Its fundamental lack of security design makes it vulnerable to a number of attacks. And although new methods are being developed to help provide security, its inherent lack of security design often allows attackers enough leeway to cause harm.

The types of threats that are common to DNS servers are:

Spoofing

Attackers often try to compromise security by fooling you into thinking that their computer is actually the computer you were looking for. You assume your communication is secure, and it may be, but it's secure to their computer instead of the one you believe you're communicating with. Such an attack is called spoofing. Spoofing is frequently accomplished by attacking DNS and adding false data to its database and cache.

For example, if you attempt to browse to http://www.woodgrovebank.com, your computer queries a DNS server. When the DNS server looks up the IP address, it may find a false address added by the attacker. That false IP address is provided to your computer, and your web browser displays the data from that web site. The attacker has, from your perspective, taken the place of www.woodgrovebank.com. That's spoofing.

Network footprinting

Footprinting is the practice of learning as much information about a target network as possible. This is usually carried out before an attack to help map out resources and possibly security devices. Because DNS must, by its nature, know about all TCP/IP hosts on a network, it holds much of the information that's necessary to build an accurate footprint of a network. For that reason, attackers often attempt to retrieve all information stored in a DNS server. This gives them details on what resources are available and, often, where they are.

Denial-of-service attacks

You've already read about denial-of-service attacks and that they work by flooding a legitimate server with false requests until it can no longer service the authentic network clients. DNS servers are often the target of such attacks. When a DNS server is taken down with this type of attack, no clients can resolve hostnames to IP addresses, which essentially downs the entire network. Equally damaging is when the target DNS server hosts the records for an Internet presence, such as a web server. Clients can no longer contact the web server in that case, which may result in lost revenue.

Countermeasures, both procedural and technology-based, can help protect DNS against these types of attacks. These countermeasures are discussed in the following section.

11.2.2 Using DNS Securely

The previous sections described the numerous attack vectors provided by DNS. They also described the benefits of having DNS and that, in many networks, it's an indispensable benefit. All these benefits have frequently outweighed the lack of security in DNS for many years. However, some progress has been made in the realm of DNS security. Several new techniques and technologies can help protect both DNS servers and clients and help provide some level of resistance against attackers.

Windows Server 2003 incorporates many of the newer DNS security features. These security features, as well as ways to use them and threats that they help mitigate, are the focus for the rest of this section.

11.2.2.1 Setting permissions for DNS administration

The first step to securing your DNS server is controlling who has the ability to modify it. Although the default settings are reasonably restrictive, you may want to limit even further the number of users or groups able to configure the server. This is one example of role separation on a DNS server running on a Windows Server 2003 domain controller, where administrators of one component or network service may not require administrative access to another.

You restrict the users and groups that can manage the DNS server by following this procedure:

The DnsAdmins group has full permissions to the DNS server. That's the built-in group that is designed to contain your DNS administrators. By default, this group is empty. You should add authorized DNS administrators to that group and make as few other changes to the ACL as possible. Ensure you tightly control membership of this group to prevent unauthorized changes to your DHCP configuration.

11.2.2.2 Setting permissions on DNS objects

Windows Server 2003's DNS server doesn't stop at the basic restriction of a DNS server. You can get very detailed when securing a DNS server. You can set permissions on Active Directory-integrated zones and even records in the same manner as described previously.

For example, perhaps you have an internal DNS domain called research.woodgrovebank.com. You want to limit access to that domain's data only to members of the Research security group. That's easily accomplished in Windows Server 2003's DNS by doing the following once the Active Directory-integrated zone has been created:

Figure 11-7. The Research group now has permission to use the data in the research.woodgrovebank.com domain

This configuration results in a very limited DNS domain. Members of that domain, who are also members of the Research group, can manage their own records and query for other hosts in the same domain. However, outsiders cannot use DNS to identify or footprint the Research group's computers. They don't have permission to get the information from DNS.

The same procedure can be carried out to set permissions on individual records as well. Although this isn't a very common practice, it can be useful in some scenarios. For example, you may want to secure high-value records for line-of-business servers so that an attacker or errant administrator cannot modify the record and cause a denial of service.

11.2.2.3 Enabling secure dynamic updates

By default, new Windows Server 2003 DNS servers with Active Directory-integrated zones are configured to allow clients to dynamically update their DNS records. This is allowed because it can be done in a reasonably secure manner.

The fact that the zone is Active Directory-integrated means that Windows Server 2003 can require the client to authenticate with Active Directory. These authenticated credentials can then be passed to the DNS server with the client record update request. The DNS server would then validate the client's credentials before processing the record update.

When DHCP is configured to update DNS, it can potentially add records that it believes are accurate but that are not. This could lead you to believe that the DNS server is attacking the DHCP server. In fact, the attacker is attacking the DNS server through DHCP.

Dynamic updates can also be allowed without the security, principally for standard zones. In this case, all clients are trusted to provide authentic records to the DNS server. This can be dangerous, as it allows clients to pollute the zone data and potentially hijack legitimate resource records, redirecting the client to a host of the attacker's choosing. As described earlier in the chapter, this is bad.

To configure an Active Directory-integrated zone to allow only secure dynamic updates, you should follow these steps:

Figure 11-8. Configuring secure dynamic updates

Now the server will accept dynamic updates only from authenticated clients. Note that you can still manually add, delete, and manage records through the DNS Management console. This setting applies only to dynamic client updates.

11.2.2.4 Restricting zone transfers

Zone transfers are a very common method of network footprinting. If an attacker can obtain a complete zone transfer from either your internal or DMZ-based DNS server, he can use that information to identify hosts. An attacker can often extrapolate computer roles from hostnames, and many record types indicate what type of server is associated with an address. For example, in a Windows Server 2003 domain environment, finding an _ldap._tcp.* record often indicates that the associated host is a domain controller.

To help prevent this from happening, you should restrict zone transfers so that only authorized DNS servers can perform zone transfers with each other. Before you do this, you must identify all DNS servers that need to perform zone transfers with each other. This should be part of your network infrastructure plan and should be accomplished well before DNS is implemented. However, because many networks are not implemented with complete or far-reaching plans, such plans often do not exist.

I mentioned earlier that there are two zone storage types for Windows Server 2003 DNS servers: standard and Active Directory-integrated. Our preferred zone storage type is Active Directory-integrated, as we have far more security options on this type of storage. This is especially true for zone transfers, which by default are secured when you use only Active Directory-integrated zones. In addition, a DNS zone stored in Active Directory takes full advantage of Active Directory's built-in replication. Zone transfers for standard zones must be configured in a different way because of the way they're stored and secured.

Restricting zone transfer for a standard DNS zone can be done with the following steps:

Figure 11-9. This zone will be transferred only to the identified DNS server; all other zone transfer requests will be rejected

Configuring DNS zone replication for Active Directory-integrated zones is far simpler. First, you must decide if you want the zone replicated to any servers other than DNS servers in the same domain. Usually you don't, unless you specifically want to replicate the data for redundancy, reduction in referrals, or some other business need. Also, if you have Windows 2000 DNS servers in the same domain and want them to receive the DNS zone, you can choose that option using this procedure.

Restrict the DNS zone transfer for an Active Directory-integrated zone with these steps:

11.2.2.5 Restricting recursive queries

Another restriction you can place on your DNS servers to strengthen security is on recursion. If your infrastructure allows it (if you don't use forwarders), you should disable recursive queries on your Internet-accessible DNS servers. This helps thwart a specific type of spoofing attack in which an attacker sends a recursive query to your DNS server that points back to a DNS server under her control. When that happens, your DNS server essentially trusts all IP information coming from the attacker's DNS server. This can result in a polluted cache and redirected network communications.

Disabling recursion puts your DNS server into a "passive" mode from which it never sends queries on behalf of other servers or clients. Once you've verified that you can disable recursive queries without affecting required network functionality, you can disable DNS recursion by following this procedure:

Figure 11-11. Disabling recursion on the DNS server

That's all there is to disabling recursion and preventing an entire class of attack. It's worth mentioning a second time that you should be absolutely certain that this change will not have an impact on your name resolution infrastructure. Disabling recursion without first understanding the implications could adversely affect your network.

11.2.2.6 Auditing DNS

Unfortunately, DNS provides very little security-oriented event logging. The built-in events and triggers are not sufficient to identify a threat. Therefore, auditing DNS activities through an event log for security analysis is not practical. DNS in Windows Server 2003 provides a configurable debug log feature. However, because this debug logging is intended as a troubleshooting tool, the logging must be manually configured and the resulting log file must be manually retrieved and analyzed. There are no automated tools or processes for doing this work.

However, this does not mean that you should just leave your DNS server alone. The DNS server should be manually audited periodically. These audits should look for common problems such as:

• Misconfiguration, whether intentional or not

• Record pollution

• Access control list conformance to established access control policy

Auditing these problems is simply a matter of using the aforementioned procedures to verify configuration instead of actually establishing that configuration. If any problems arise, you should investigate further to determine how the problem occurred and ensure that it doesn't happen again. For example, if you notice that user David Loudon is a DNS administrator whereas he was not before and is not authorized for that role, you should determine how he became an administrator. That will help you determine a corrective course of action. The action may be as simple as correcting an administrative procedure that allowed David to become an administrator or as difficult as firing David for obtaining administrative permissions through an attack. But without finding the root cause of the problem, you cannot effectively mitigate it.

Copyright eTutorials.org 2008-2023. All rights reserved.