13.2 A Secure BIND Installation

The discussion of DNS has largely focused on theoretical information to this point. It is time to shift to more practical aspects of DNS security; in particular, the focus will be on securing a BIND installation.

BIND is the software that allows DNS to function for most of the Internet; in fact, BIND servers handle more than 90 percent of all DNS queries on the Internet. BIND is incredibly robust. Many of the root name servers use BIND, and they are answering more than 200 million queries a day.

BIND was first developed in 1983 at the University of California-Berkeley as a way to handle DNS queries. Over the years the ownership of BIND has moved from organization to organization. Currently, the Internet Software Consortium maintains BIND. Like the DNS protocol itself, BIND was not originally designed with security in mind, and over the years BIND security exploits have given system administrators a fair share of headaches . Between 1998 and 2001, BugTraq reported 14 exploits found in various versions of BIND, ^[1] compared to five exploits found in Sendmail during the same time period.

^[1] As of this writing no bugs had been reported for 2002.

BIND exploits often have a significant business impact because they can cause e-mail and websites to become unavailable, or, worse , directed somewhere else at the whim of an attacker.

BIND vulnerabilities first came into the public light in 1997 when Eugene Kashpureff, who operated a now- defunct alternative registry called AlterNIC, used a common BIND exploit to direct traffic away from the Network Solutions website and to the AlterNIC website. Mr. Kashpureff used a well-known exploit that would allow additional information to be sent to a caching name server when a request was made. More about this exploit will be explained shortly.

Two steps can be taken to immediately increase the security of a BIND installation:

1. Upgrade to the latest version.

2. Separate caching and authoritative functions.

The current version of BIND is Version 9.2.x; no known security holes have been exploited to date for this version of BIND. That does not mean they don't exist, but it does mean that upgrading to BIND Version 9.2 is one of the best ways to secure your BIND installation. It is also a good idea to subscribe to the ISC mailing list bind-announce, a low volume list that sends out announcements about new versions of BIND, security fixes, and patches. This allows administrators to stay current about the latest BIND information.

In addition to having the latest version of BIND, it is a good idea to separate caching from authoritative functions whenever possible. BIND is designed to handle both services. Because the two perform such different functions, there are usually different security policies associated with each function. By separating them it is easier to apply more stringent security restrictions to the servers.

Not only is it a good idea to separate the services, but also it is critical to ensure that BIND is not running on any machines that are not acting as DNS servers. Because BIND is an open -source software project, it is often distributed by default with operating systems, including Solaris and most versions of Linux. Whenever an audit is performed on a server, BIND should be one of the packages that is watched for and removed.

The separation of caching services gives an administrator a couple of benefits. First, it makes the firewall rule very easy: Block all traffic on Port 53 (the DNS port), but allow UDP and TCP traffic from any source IP address on any port destined for the authoritative server on Port 53.

Typical DNS traffic uses UDP to send and receive queries, but if a zone file is larger than 512 KB (the largest allowed UDP packet), a DNS server will return the information in one or more TCP packets.

Second, the separation allows administrators to apply different security policies to the different name servers. Machines from all over the world query an authoritative name server. On the other hand, a caching name server should only be queried by local users on your networkor possibly remote offices if they are connected to the network. Either way, an administrator should have control over who accesses a caching name server, and can limit to whom the caching name server will issue responses.

NOTE

In addition to standard server security precautions , it is usually a good idea to install software-based firewalls, such as IPFilter, on a DNS server.

13.2.1 BIND Security

Before different types of BIND servers can be secured, a better understanding of how to secure a BIND installation is needed. BIND can be unwieldy to manage without a basic understanding of how the program works.

When BIND is first started it has to bind itself to Port 53. On most systems a program cannot bind itself to a port unless the system administrator runs it. This was one of the biggest security holes within BIND. Having the BIND daemon owned by the administrative user meant that it was susceptible to root exploits. A root exploit is carried out when an attacker is able to successfully gain administrative access to a system through a program that is owned by the administrative user.

Current versions of BIND do not have this problem. BIND is still started by the administrative user, but ownership of the BIND daemon is transferred to an nonprivileged user, in most cases a user created specifically for the purpose of running BIND. The conventional name for the BIND user is named because named is the program that actually handled DNS queries. : The process status command is great for determining the owner of a process, in this case the owner of named:

 [root@ns1 root]# ps -aux  grep named  named 4764 0.0 0.8 12276 4260 ? S 18:38 0:00 named -u named  named 4765 0.0 0.8 12276 4260 ? S 18:38 0:00 named -u named  named 4766 0.0 0.8 12276 4260 ? S 18:38 0:00 named -u named  named 4767 0.0 0.8 12276 4260 ? R 18:38 0:00 named -u named  named 4768 0.0 0.8 12276 4260 ? S 18:38 0:00 named -u named 

In addition to running BIND as a nonprivileged user, many people recommend running BIND in a chrooted environment, on UNIX servers. Chroot creates a sandbox that can help limit the damage an attacker can cause should an application be exploited. A sandbox is a restricted shell that is used to limit the access a user has to a system, by essentially making that directory the root directory and keeping the user trapped.

As with any other security measure, it is important not to rely too heavily on chroot to protect a server. While it is a powerful tool, there are ways out of a chroot environment. That's why it is better to run BIND as an unprivileged user in a chrooted environment, rather than running BIND as the administrative user.

Running BIND in a chrooted environment is simply a matter of starting it with the t flag:

 [root@ns1 root]# /usr/sbin/named -u named -t /var/named/ 

This command will start BIND as root, but have it run as the user named . It also creates a chrooted environment with /var/named/ as the root directory. The only caveat to using this type of security is that the value of some of the variables in the named.conf file will need to be changed so that they are within this new root directory.

13.2.1.1 Named.conf

The heart of any BIND installation is the named.conf file. Usually located in the /etc directory on a UNIX system, and dns\etc\ on a Windows system, this file is what allows an administrator to change the security and configuration settings of the DNS server. The owner of the named process should own the named.conf file. Permissions should be set so that only the named process owner has read access; other system users should have no access to the file (chmod 600 on a UNIX server). The named.conf file has several sections, and looks like this:

 options {     directory "/var/named";    // query-source address * port 53;  };  zone "." IN {     type hint;     file "named.ca";  };  zone "example.com" {     type master;     file "example.com.hosts";     };  zone "example2.com" {     type master;     file "example2.com.hosts";     }; 

This is a simple version of the named.conf file. The first section, labeled options, defines information that will be universal to all of the zone files. The next section is a list of the actual zones that the name server has information about. The server is acting as an authoritative and caching name server. The first zone in the list ".", with the type hints, indicates that this server can be queried for information about domain names not located on the server.

If this were a caching-only name server this would be the only entry in the named.conf file. The next two zone entries, example.com and example2.com, are domains for which the name server thinks it is master. The actual zone is stored in the file listed in the file entry (i.e., example.com.hosts and example2.com.hosts).

The named.conf file allows an administrator to add directives, called statements, to modify the configuration of a zone file. A complete explanation of the various statements is beyond the scope of this book. For more information refer to the BIND documentation available online.

By default BIND logs all queries to syslog ( generally /var/log/messages). Using the logging statement an administrator can direct logs to a separate file and monitor the BIND logs individually. This may not be an ideal solution for all companies. If syslog information is being sent to a separate server and monitored by third-party software, as is often the case with large companies, separate BIND logging may not provide any benefit.

However, the logging statement does allow an administrator to split logs depending on the channel, severity, or category. This is particularly useful if one person, or a group , is dedicated to managing the DNS infrastructure. It is possible to use the logging directive to send warning, and more severe, messages to the syslog daemon, while notice, and less severe, messages are send to a separate log file. A basic logging statement will look like this:

 logging {  channel default_syslog {   syslog daemon;      severity info;  };  channel default_debug {   file "named.debug";  };  }; 

This logging statement sends errors that are informational, and above, to the syslog daemon. All debug errors are sent to a file called named.debug. It is a relatively simple configuration, and will not meet the needs of a complex DNS solution. However, it makes a good starting point from which to grow.

Another commonly used practice to secure a name server is to hide the version information. Ordinarily, an attacker can use the dig command (installed by default with BIND) to determine the version of BIND a remote name server is running:

 [root@ns1 root]# dig @ns1.example.com version.bind chaos txt  ;; QUESTION SECTION:  ;version.bind.       CH   TXT  ;; ANSWER SECTION:  version.bind.    0   CH   TXT  "9.1.3"  ;; Query time: 2 msec  ;; SERVER: 192.168.0.40#53(ns1.example.com)  ;; WHEN: Sun Apr 21 18:31:06 2002  ;; MSG SIZE rcvd: 48 

Now an attacker can look for exploits to which Version 9.1.3 of BIND is susceptible and act accordingly . While version.bind is a BIND convention, it has been incorporated into other DNS servers, so this command is a common way of finding exploitable systems. You can change the information that is output by making the following adjustment under the options statement:

 version "DNS, we aint got no stinkin DNS"; 

Now, if the same command is issued, the following will appear:

 [root@ns1 root]# dig @ns1.example.com version.bind chaos txt  ;; QUESTION SECTION:  ;version.bind.       CH   TXT  ;; ANSWER SECTION:  version.bind.    0   CH   TXT  "DNS, we aint got no stinkin DNS"  ;; Query time: 2 msec  ;; SERVER: 192.168.0.40#53(ns1.example.com)  ;; WHEN: Sun Apr 21 18:38:33 2002  ;; MSG SIZE rcvd: 74 

As you can see this prints out the message "DNS, we aint got no stinkin DNS," instead of the version of BIND. The merits of this form of security are somewhat debatable. The wrong message may simply serve as an enticement for an attacker to try to break into your system. By changing the version information you are attempting to understand the psyche of an attacker, and that may or may not be a good idea. Some administrators prefer not to change the version, but simply leave it blank so that no information is provided to a potential attacker.

Other named.conf security considerations will be discussed in the next section.