Section 37.3. Objective 3: Securing a DNS Server

37.3. Objective 3: Securing a DNS Server

As with any computer sitting on the Internet, you need to secure your DNS server . Here are a few reasons:

• Losing your DNS server can mean losing access to your web server and email server because, without DNS, no one can find them, effectively creating a Denial of Service (DOS) scenario.

• An attacker who breaks into your DNS server can get information about your internal network, including the IP addresses of other servers, client machines, switches, and so on.

• By poisoning the data in your DNS server or manipulating your DNS information, an attacker can cause people attempting to connect to your servers to be rerouted to the attackers' servers. Imagine what would happen if your clients typed their credit card information into a server they thought was yours and wasn't.

Some of the things you can do to secure your DNS servers are:

• Have redundant servers. If one goes down, you'll have a backup.

• Use one or more dedicated servers for DNS. There should be no users logging in or any other services on the system that can be used to attack it.

• Restrict zone transfers so they can take place only between your DNS servers.

• Use TSIGs (transaction signatures) to encrypt zone transfers between DNS servers.

• Do not allow recursive queries to an Internet-facing nameserver. These servers should serve only name information that they are explicitly told about.

• Recursive queries should be allowed only from your internal network.

• Run BIND in a chroot jail and/or as a user with the minimum privileges necessary.

• Keep backups of your zone files in a separate environment, and monitor the information served by your DNS servers.

Depending on your setup, there are other things you may be able to do. Also, as with any other program, bug and security fixes for BIND are frequently publicized, so keep abreast of BIND developments.

Let's look at some of the items just listed, one by one.

37.3.1. Dedicated Servers

Ideally, your DNS server should run only DNS. If you have your DNS server running on a computer with SMTP and POP (email), user accounts, a dozen web sites, and so on, you have many attack vectors open. A bare-bones computer that has only port 53 open is much more difficult to break into than one that has open ports for Telnet, HTTP, SMTP, POP, and IMAP. You should also have separate internal and external DNS servers. The internal servers should respond to queries only from internal addresses. You do that with a command such as the following (the IP address is a typical internal subnet address):

 allow-query {192.168.1.0/24;}; 

You can chain multiple subnets together using semicolons (;).

If the internal servers need to resolve an address from outside the network, you can have them forward the query to the external server with:

 forwarders {200.200.1.17; 200.200.1.18;}; 

37.3.2. Restricting Zone Transfers

If an attacker can do a zone transfer (and anyone who has access to nslookup or dig can do a zone transfer!), she can get a pretty good idea of how your network is laid out. Knowing how your network is laid out lets her know where to attack.

Be sure that only your servers can do a zone transfer by putting a line like the following in your /etc/named.conf files on each server:

 options { allow-transfer {10.10.10.5;192.168.1.12;};} 

where the 10.10.10.5 and 192.168.1.12 addresses are examples; substitute the addresses of your other DNS servers. Another good idea is to use TSIGs (discussed next).

37.3.3. Using Transaction Signatures (TSIG)

Transaction signatures, or TSIGs, were introduced in BIND 8.2 and more fully fleshed out in BIND 9. TSIGs encode the data whenever a zone transfer occurs. In BIND 9, TSIGs can also be used for dynamic updating of zone records.

The process of using TSIGs is not complicated, but can be difficult to troubleshoot. One of the most important things to keep in mind is that the clocks on the DNS servers must be synchronized. The best and easiest way to do this is by using the Network Time Protocol (NTP). Additionally, all of your DNS servers should use the same NTP server.

Here is the process for a server running BIND:

1. Generate the MD5 key using dnssec-keygen. It is customary to name the key after the two servers involved:

    # dnssec-keygen -b 128 -a HMAC-MD5 -n ZONE server1-server2 

   
   

   This will create two files, Kserver1-server2.+157+55659.key and Kserver1-server2.+157+55659.private, where the 157 represents the algorithm used (HMAC-MD5 in our case) and 55659 represents the footprint of the file. In the next step, we will use the value in the Key line of the second output file:

    # cat Kserver1-server2.+157+55659.private Private-key-format: v1.2 Algorithm: 157 (HMAC_MD5) Key: 6tIpA0E/nTW677RqaBQLFQ== 

   
   

2. Create an entry on both servers. You can do it right in /etc/named.conf as follows:

    key server1-server2 {   algorithm hmac-md5;   secret "6tIpA0E/nTW677RqaBQLFQ=="; } 

   
   

   Better yet, create the entry in a separate file, say /etc/named.key, and include it in /etc/named.conf like this:

    include "/etc/named.key"; 

   
   

   In either case, make sure the permissions on the files are as restrictive as possible (through a chmod 400 on the file).

3. Use an ACL for each server and tell BIND which keys to use:

    acl "myservers" { server1, server2; }; server server2 {   transfer-format   keys {server1-server2;}; } 

   
   

4. Restart both servers and check for errors in the log files.

37.3.4. Recursive Queries

Your DNS servers should do recursive queries only from your network. Not only will this allow for better performance, but it can help prevent a DOS scenario known as DNS cache poisoning.

All DNS servers cache the replies to their queries. Some are (mis)configured to cache all replies, even if they didn't send out a query. If an attacker sends a reply that says "www.oreilly.com is at 192.168.1.1" and the receiving DNS server accepts the reply and places it in the cache, the cache has been poisoned.

In BIND, recursive queries are the default, so be sure to turn them off on your external servers with:

 recursion no; 

If you don't have separate external and internal servers (or you just don't want to turn off recursion), you can restrict recursive queries to specific subnets with a section such as:

 allow-recursion {192.168.1.0/24; 10.10.0.0/16;}; 

37.3.5. Running BIND in a chroot Jail/Reduced Privileges

Restricting which system resources BIND can access will make your server harder to break into and, if someone does break in, make it harder for her to do damage.

The classic way of doing this is to run BIND in a chroot jail. The process is quite involved, so we won't get into details here. The basic process is:

1. Create a chroot environment that contains all the files and directories that BIND will need to run.

2. Put BIND in the jail.

3. Run BIND.

The new -uusername and -tdirectory features of Bind 9 make it easier to run BIND in a chroot jail. Once the command-line options are read, BIND will chroot itself in the directory directory as the user username. This has the disadvantage that, for a short time during program startup, BIND is not chrooted. Also, some people think the chroot code in BIND needs more testing. On the other hand, it is much easier to use than a chroot jail.

---

Tip: If you're going to use the -u and -t options, do not run BIND as the root user (-u root), because on most Linux systems, root can break out of a chroot jail.

---