13.3 Limit Access to Domain Information | The Practice of Network Security: Deployment Strategies for Production Environments

Generally there are two goals when trying to secure a DNS server: Limit information access to authorized users and limit the information authorized users can access. Of course, how DNS information is secured depends on the type of server that is being secured.

Regardless of whether you are trying to secure a caching or authoritative name server, a tool that can help this process is an ACL. ACLs are a statement within the named.conf file. An ACL can be applied universally , or to specific domains, depending on the administrator's needs.

The process of using ACLs to protect routers was outlined in Chapter 4. Securing BIND using ACLs is very similar, with the difference being that with BIND there is no need for an implied allow statement at the end of an ACL. BIND assumes that anything that is not implicitly denied is allowed. A common DNS security practice is to blackhole all requests that originate from RFC 1918 addresses:

 acl badaddresses { 10.0.0.0/8; 172.16.0.0/12; \ 192.168.0.0/16; };

In the options statement, include the following line:

 options {  ..     blackhole { badaddresses; };  ..  };

Placing the ACL in the options statement blackholes all requests to the name server from addresses in the RFC 1918 space. An ACL can also be applied to only a specific domain (for example, if separating caching and authoritative name servers is not an option). An ACL can be created specifically for local addresses and bound to the caching zone entry. In fact, BIND has a built-in ACL for local address called localnets. The localnets ACL consists of any address in one of the netblocks bound to the name server interface. For example, if the name server has an address of 10.10.0.10 with a netmask of 255.255.255.0, then addresses 10.10.0.1 through 10.10.0.254 would be able to connect to a localnets ACL.

BIND has three other native ACLS:

Any allows all hosts to connect.
None denies all hosts.
Localhost allows any IP that is bound to an interface on the name server.

There may not be a need to apply ACLs to the name server if they duplicate what is already attached to the router. On the other hand, redundant security is rarely a bad thing.

13.3.1 A Caching Name Server

Many of the security precautions discussed in this chapter can be applied to a caching-only name server. In particular, very stringent ACLs should be applied to this device. For example, using the localnets ACL described in the previous section, the options statement should probably look like similar to this:

 options {  directory "/var/named";   // query-source address * port 53;  allow-query { localnets; };  };

Add in the hints zone and a zone file for the localhost address:

 zone "." IN {     type hint;     file "named.ca";  };  zone "0.0.127.in-addr.arpa" {     type master;     file "127.0.0.in-addr.arpa";  };

More verbose logging can be added to improve security, if desired, but if syslog monitoring is in place, that may not be necessary. As long as standard server security precautions are taken (limited access, strong password policy, etc.), a simple caching name server configuration can be fairly secure.

13.3.2 An Authoritative DNS Server

An authoritative DNS server can be much more difficult to secure because, like a web server, it has to allow access from anywhere . The best strategy with an authoritative DNS server is to block access to rogue addresses, at the firewall or router level, and to restrict the information that the authoritative DNS server will provide.

Once again, using ACLs can help secure an authoritative name server. A common tool used by attackers to map your network is to perform a zone transfer:

 [root@ns1 root]# dig @ns1.example.com example.com axfr  ; <<>> DiG 9.1.3 <<>> @ns1.example.com example.com axfr  ;; global options: printcmd  example.com.      38400 IN   SOA  ns1.example.com. dns.example.com.  99  5551903 10800 3600 432000 38400  example.com.      38400 IN   A   192.168.0.20  example.com.      38400 IN   MX 10 mail.example.com.  example.com.      38400 IN   MX 50 mail.uu.net.  example.com.      38400 IN   NS   ns1.example.com.  example.com.      38400 IN   NS   auth50.ns.uu.net.  anoncvs.example.com.   38400 IN   A   192.168.0.20  cpanel.example.com.   38400 IN   A   198.93.70.124  cpanel2.example.com.   38400 IN   A   198.93.70.125  dcw.example.com.    38400 IN   A   192.168.0.20  exuunet.example.com.   38400 IN   A   192.168.0.20  ftp.example.com.    38400 IN   A   192.168.0.20  jrun.example.com.    38400 IN   A   192.168.0.9  mail.example.com.    38400 IN   A   192.168.0.20  test.example.com.    38400 IN   A   192.168.0.40  www.example.com.    38400 IN   A   192.168.0.20  example.com.      38400 IN   SOA  ns1.example.com. dns.example.com.  99  5551903 10800 3600 432000 38400  ;; Query time: 5 msec  ;; SERVER: 192.168.0.19#53(ns1.example.com)  ;; WHEN: Mon Apr 22 17:58:54 2002  ;; XFR size: 18 records

Using the supplied information, an attacker has a pretty good idea about the netblocks used on the example.com network, and also has an idea of what services are being run on which machines. This information can be used to build a network map and launch attacks against a particular server.

You can stop unauthorized machines from making zone transfers in this manner using the allow-transfer tag. Some machines, a secondary name server for example, have to be able to perform full zone transfers, others do not; a caching name server only needs to pull information for the host name that is being queried. The allow-transfer tag can be applied on a per-domain basis, or it can be applied to all domains. If you have multiple domains, with multiple secondary servers, you may need to apply this information on a per-domain basis.

In the previous example, the secondary name server is auth50.ns.uu.net, or 198.6.1.161. An entry can be made in the zone entry for example.com allowing this IP to perform transfers:

 zone "example.com" {     type master;     file "example.com.hosts";     allow-transfer { 198.6.1.161; };     };

Now, when the attacker tries to perform a full zone transfer, there is an error:

 [root@test root]# dig @ns1.example.com example.com axfr  ; <<>> DiG 9.1.3 <<>> @ns1.example.com example.com axfr  ;; global options: printcmd  ; Transfer failed.

However, normal caching server behavior is not affected:

 root@test root]# dig @ns1.example.com www.example.com A  ;; QUESTION SECTION:  ;www.example.com.    IN   A  ;; ANSWER SECTION:  www.example.com. 38400 IN   A   192.168.0.20  ;; AUTHORITY SECTION:  example.com.   38400 IN   NS   ns1.example.com.  example.com.   38400 IN   NS   auth50.ns.uu.net.

On the slave server the zone entry can be configured to not allow any transfers:

 zone "example.com" {     type slave;     masters { 192.168.0.19; };     file "example.com.slave";     allow-transfer { none; };  };

To further enhance security, an administrator can restrict transfers from the master name server to slave name servers that supply a correct key. Combining key security with the allow-transfer limitations provides additional security and ensures that domains will not be transferred to spoofed IP addresses ” assuming the spoofed IP address does not also have the key.

Messages secured using encrypted keys are called transaction signatures (TSIG), outlined in RFC 2845. BIND has supported TSIG messages since Version 8.2. Messages are secured using an MD5 algorithm. The master and the slave server both need to have the same secret key. When the slave name server requests information from the master server, it sends the secret key. The master verifies that it is the correct key and sends the information. Most experts recommend at least a 128-bit key, though there are no minimum requirements. BIND 9 supports 64-bit through 512-bit keys.

Versions of BIND that support TSIG messages include a tool for creating the secret key. The tool, called dnssec-keygen , is first used to create the keys:

 [root@test root]# dnssec-keygen -a HMAC-MD5 -b 512 -n \  HOST auth-ns1.example.com

The standard convention is to name the keys after the secondary and primary name servers, in this case auth-ns1.example.com. The “ b tag tells BIND that the key should be 512-bits. The dnssec-keygen command creates two files, the .key and the .private file. Both files contain the newly generated key; the key file should be copied into the BIND root directory /var/named/. The key will look something like this:

 EhCCOHJHYYbcoJWIsN7Sh7tfeA8rBCi7KhesBbm/d \  +uEZwIQA2awWdV7 tY8jVprr1OO3fkXbSjY73yBO73lpwA==

The key has to be defined on the master name server, in the named.conf file:

 key auth-ns1. {   algorithm hmac-md5;   secret " EhCCOHJHYYbcoJWIsN7Sh7tfeA8rBCi7KhesBbm/d \  +uEZwIQA2awWdV7 tY8jVprr1OO3fkXbSjY73yBO73lpwA";  };

The key name needs to be included in the zone file entry:

 zone "example.com" {  type master;  file "example.com.hosts";  allow-transfer { key auth-ns1.; };  };

The same key entry needs to be made in the named.conf file on the slave server:

 key auth-ns1. {   algorithm hmac-md5;   secret " EhCCOHJHYYbcoJWIsN7Sh7tfeA8rBCi7KhesBbm/d \  +uEZwIQA2awWdV7 tY8jVprr1OO3fkXbSjY73yBO73lpwA";  };

BIND has to be told that all messages to the master server should be signed:

 server 192.168.0.19 {  keys { auth-ns1.; };  };

Then create the slave zone file as before:

 zone "example.com" {     type slave;     masters { 192.168.0.19; };     file "example.com.slave";     allow-transfer { none; };  };

The master and slave authoritative DNS servers have now been secured so that the master only allows zone transfers to the IP address of the slave, and it requires that the requests include the encrypted key. The slave name server will not allow any transfers.

Assuming standard security precautions have been followed on both the master and slave name servers, DNS transactions between the two should now be secure.