DNS

Like mail, DNS has a large set of application-specific security guidelines in addition to a few simple network best practices that are discussed here. From an application security standpoint, there are several references that you will find useful:

• DNS and BIND, by Paul Albitz and Cricket Liu (O'Reilly, 2001)
• Secure BIND Template, by Rob Thomas, http://www.cymru.com/Documents/secure-bind-template.html
• Securing an Internet Name Server, by Cricket Liu, http://www.linuxsecurity.com/resource_files/server_security/securing_an_internet_name_server.pdf

These sources discuss many of the finer points of DNS security all based on the Berkeley Internet Name Domain (BIND) as maintained by the Internet Software Consortium (http://www.isc.org). This section of the chapter assumes you are familiar with DNS and BIND. If you are new to DNS and BIND, reading the first few chapters of DNS and BIND will get you off to a good start. These application controls can augment the controls put in place at the network and can do things only possible at the application layer. Some of these lockdown procedures include the following:

• Running BIND in a chroot jail (http://en.tldp.org/HOWTO/Chroot-BIND-HOWTO.html)
• Limiting which hosts can initiate zone transfers and recursive queries
• Using signatures to authenticate zone transfers
• Stopping CHAOS queries to learn your BIND version
• Controlling which parts of your zone are visible to which subnets

From a network perspective, the controls are similar to mail controls. The most secure alternative is the separation of the internal network DNS from the external network (more on this later). At a base level, the following best practices apply. (Some basic application controls are included because they are so critical.)

Don't Put All Your DNS Servers in One Place

The bare-minimum DNS configuration has two servers. One server is the authoritative master server for your domain, and a second server is the slave. As your network grows in size, you might have multiple masters and many slaves. The key point is not to put the master and the slave in the same location because this makes them vulnerable to denial of service (DoS) attacks. The separation means this:

• Don't have all your servers share the same network segment.
• Don't have all your servers share the same WAN connection to the Internet.

For example, if your DNS servers are all connected to the same T1 link, a simple flood of that link can cause you to disappear from the Internet as soon as the cached data on everyone else's servers times out (the Time-to-Live [TTL] value in your start of authority [SOA] record). Just such an attack hit Microsoft Corporation in January 2001 (though it had a bit more than one T1 running at the time).

Have More Than One Authoritative DNS Server

If you have only one authoritative server for your domain, even if you spread out your DNS servers, you can still be hit with a DoS attack directed against the authoritative server. This attack takes longer because slave servers still provide DNS data for the time period defined by the expire value in the SOA (generally, 1 week or more). Interesting research on these types of outages is available at the following URL: http://www.menandmice.com/dnsplace/healthsurvey.html.

The easiest way to ensure that this doesn't happen is to host multiple authoritative DNS servers that are in different parts of the network and are not served by a single network link that is vulnerable to a flooding attack.

Make Your External DNS Servers Nonrecursive Responders Only

A DNS server can receive two types of queries: recursive and nonrecursive. When a server receives a recursive query, it finds an answer for the resolver (client), even if that means communicating with several different other servers. The DNS server you use every day on your PC supports recursive queries. That is, you request www.domain.com, and your server queries a root name server (assuming the com name server [NS] record isn't already cached), then the com NS, then finally the domain.com NS, which will return the IP address for host www. Your DNS server responds to you with the answer. In the end, you have made one query; your DNS server has made three.

Nonrecursive resolution means the DNS server responds only with the best answer it already has and will not make further queries on behalf of the resolver making the request.

By making your external DNS servers iterative responders only, you prevent other hosts from using your DNS servers as their regular name servers, which can significantly increase the load on the system and potentially make you vulnerable to DNS spoofing attacks. DNS spoofing has many variants. One common method is shown in Figure 8-4.

Figure 8-4. DNS Spoofing Attack

Here, an attacker first installs a DNS server on the Internet and makes it authoritative for his domain (imajerk.com). The DNS code the attacker runs has been modified to send additional bogus data in the reply. The attacker then queries your external server for information about his own domain. Your server queries the attacker's server and receives the bogus response, which your server caches. This bogus response can do a number of different things, depending on the patch level of the DNS code your server is running. The most popular form of the attack is to populate your server's cache with information about your own domain so that when users connect to www.yourorg.com, they are redirected to the attacker's system. From here the attacker can, among other options, launch man-in-the-middle (MITM) attacks.

By making your external servers unresponsive to recursive queries, this kind of attack goes away. Your external servers will only give answers to queries for your own domains and will not even provide your internal users with DNS services. To do this, you must pair this best practice with the next one.

Provide Protected Internal DNS Servers

To allow your external servers to be nonrecursive only, you must provide internal servers that allow recursive queries for your users. There are several ways to do this; one of the more common is to use internal servers for internal DNS data and separate forwarders for information outside the organization. This allows a smaller number of forwarders to have a rich cache. This will shorten DNS resolution times and reduce the load on your WAN links. These forwarders should make requests directly to the Internet and should not use your external DNS servers, which don't respond to recursive queries.

Separate the Information Provided by External and Internal DNS Servers

Oftentimes, you will have a number of internal systems that external Internet users have no business knowing about. The DNS data for these systems can be configured on your internal servers and not included on your external servers. This means there will be two views of your domain. The first is from your authoritative servers and shows only systems that must be reachable from the Internet (mail servers, web servers, and so on). The second view is internal to your organization and includes these hosts in addition to your internal systems (HR, finance, and so on).

Limit Zone Transfers to Authorized Servers

Zone transfers send the entire zone data to the requesting system rather than answering a single query as is generally done. Zone transfers are necessary for slave name servers to get zone information from the master name server. No other zone transfers are required. As such, zone transfers should be blocked at master and slave servers and allowed only when specifically needed to support zone propagation between master and slave or slave and slave. This must be done within the DNS configuration. When using BIND, the setting is inside the named.conf file.

NOTE

As the first crop of firewalls was installed around the Internet, some administrators mistakenly thought that TCP 53 was only used for zone transfers and that blocking zone transfers from unauthorized hosts was as simple as stopping TCP 53. Although it is true that most DNS queries use UDP 53, larger queries will use TCP if they cannot fit in a single User Datagram Protocol (UDP) datagram. Blocking TCP 53 certainly stops zone transfers, but down the line in can break DNS resolution as well.

 

DNS Filtering Case Studies

This section takes all of the network recommendations and provides diagrams and sample ACLs for the firewall.

Single Local Server

The simplest design from a network perspective is a single DNS master onsite and a remote DNS server (possibly another master) at an ISP. This is also the most insecure and least robust because the server must be fairly open from a network perspective, and a failure of this server will affect outbound communication (and inbound, if the second master is down as well). The topology is shown in Figure 8-5. This design is appropriate only for the smallest networks. Even in these cases, it is probably better to host all of your external DNS with an ISP and have a single internal DNS server behind your firewall. Most of the security controls in this design are dependent on the application's configuration rather than the network access control policy.

Figure 8-5. Single Local DNS Server

The firewall access control policies to implement this design are as follows. Only the DNS-related portions of the ACL are shown. Bogon and ingress filtering are excluded for clarity. These ACLs assume that the remote DNS server is a slave as opposed to another master. This means the slave can update by zone transfers. If the slave were a master, you would need to determine another way to synchronize the data.

Inbound on the inside interface:

!Permit the DNS Queries from Internal hosts to the DNS server
access-list 101 permit udp 10.8.0.0 0.0.255.255 host 192.0.2.52 eq 53
access-list 101 permit tcp 10.8.0.0 0.0.255.255 host 192.0.2.52 eq 53
!Deny all other DNS traffic
access-list 101 deny udp any any eq 53
access-list 101 deny tcp any any eq 53

Inbound on the outside interface:

!Permit outside hosts to make DNS queries (recursive and zone transfer
!restrictions are up to the application)
access-list 102 permit udp any host 192.0.2.52 eq 53
access-list 102 permit tcp any host 192.0.2.52 eq 53
!Deny all other DNS traffic
access-list 102 deny udp any any eq 53
access-list 102 deny tcp any any eq 53

Inbound on the public services interface:

!Prevent DNS server from querying the internal network
access-list 103 deny udp host 192.0.2.52 10.8.0.0 0.0.255.255 eq 53
access-list 103 deny tcp host 192.0.2.52 10.8.0.0 0.0.255.255 eq 53
!Permit DNS queries to any other host
access-list 103 permit udp host 192.0.2.52 any eq 53
access-list 103 permit tcp host 192.0.2.52 any eq 53
!Deny all other DNS traffic
access-list 103 deny udp any any eq 53
access-list 103 deny tcp any any eq 53

 

Distributed DNS Design

This design is appropriate for midsize to large organizations. The only difference between the two sizes is the number of servers in each part of the network. The number of servers you need has more to do with performance and resilience than security. Figure 8-6 shows the topology. In this design, application configuration is used to enforce certain DNS rules, but the security is increased through the use of multiple layers of separation in the DNS architecture.

Figure 8-6. Distributed DNS Design

Internal clients are configured through DHCP to use a local DNS server in close network proximity. These DNS servers (there can be dozens) forward all queries they can't locally answer to a smaller group of forwarders that are allowed to make requests of the Internet at large. The internal servers have their own view of the domain and do not need to communicate with the perimeter or external DNS servers, though they are not expressly forbidden from doing so. External users can resolve addresses in your domain by querying either your local master DNS server or another master or slave somewhere on the Internet. These servers respond only to nonrecursive queries for your domain and allow zone transfers only from external slave servers. This configuration is made in the application.

The firewall access control policies to implement this design are as follows. Only the DNS-related portions of the ACL are shown. Don't forget that the method you use to synchronize the data between your master servers must be added to these rules. (Master-to-master synchronization is not part of the DNS protocol.)

Inbound on the inside interface:

!Permit queries from the forwarders outbound to the Internet
access-list 101 permit udp host 10.8.8.5 any eq 53
access-list 101 permit tcp host 10.8.8.5 any eq 53
access-list 101 permit udp host 10.8.8.6 any eq 53
access-list 101 permit tcp host 10.8.8.6 any eq 53
!Deny all other DNS traffic
access-list 101 deny udp any any eq 53
access-list 101 deny tcp any any eq 53

Inbound on the outside interface:

!Permit outside hosts to make DNS queries (recursive and zone transfer
!restrictions are up to the application)
access-list 102 permit udp any host 192.0.2.52 eq 53
access-list 102 permit tcp any host 192.0.2.52 eq 53
!Deny all other DNS traffic
access-list 102 deny udp any any eq 53
access-list 102 deny tcp any any eq 53

Inbound on the public services interface:

!Deny all DNS traffic (remember, this is a non-recursive responder
!only meaning it never has to make requests of other servers.
!It only offers answers to questions about its own domain. Master master sync
!still needs to be facilitated in some manner)
access-list 103 deny udp any any eq 53
access-list 103 deny tcp any any eq 53

NOTE

An extension to DNS called DNSSEC is on the standards track within the Internet Engineering Task Force (IETF). RFCs 2535 and 3007 provide a good overview of the technology. DNSSEC is not measurably deployed in the Internet's infrastructure today.