5.5. Operating BIND

Having read about the various attacks and risks associated with BIND, you may worry about the stability, security, or suitability of running BIND for a major enterprise. You should not. BIND is enterprise-class, production-quality software. Like all such software, whether open source or not, you must be aware of its weaknesses and guard against them. Consider that at least one of the .com nameservers runs BIND 9: if it can handle the load and stress of the .com zone, it can handle your zones.

5.5.1. Running BIND in chroot

BIND comes with the built-in ability to run in a chroot environment. You do not need to do much to configure a chroot environment properly for it. To make BIND run in a chroot environment, run it with the -u and -t options. The -u option indicates which user ID to assume while running. After doing the things that it must do as root (such as binding to port 53), BIND will then call setuid( ) to run as the given user ID. The -t option identifies the root of the chroot environment.

The instructions below work for the versions of FreeBSD and OpenBSD that we tested while writing. Be sure to check the BIND Administrator's Reference Manual (ARM) for the latest information when installing. It is distributed as part of the BIND 9 distribution.

FreeBSD stores its DNS zone data in /etc/namedb but does not include a chroot environment there. OpenBSD comes preconfigured to run BIND in a chroot sandbox, and it uses /var/named as its root. Because FreeBSD needs more configuration than OpenBSD to run its BIND in chroot, we will use /etc/namedb as the root of our chroot environment in our examples. The same concerns about locating zone data in /etc apply to BIND as to djbdns. See the discussion on "Locating zone data" to help decide if you ultimately want your zone data in /etc.

5.5.1.1 Make a filesystem

The chroot filesystem typically needs three directories: /dev, /etc, and /var. In this example, using /etc/namedb, you need to create /etc/namedb/dev, /etc/namedb/etc, and /etc/namedb/var directories. The named.conf file will tell named where to look for data and where to write its logfiles.

Three devices are needed in the /dev directory: /dev/null, /dev/zero, and /dev/random. You have to use the mknod command to do this. To create the devices properly, you must first use ls -l, as shown in Example 5-4, to determine the correct major and minor numbers for the devices.

Example 5-4. Using ls to determine major/minor numbers for device nodes

OpenBSD% ls -l /dev/null /dev/zero /dev/random crw-rw-rw- 1 root  wheel    2,   2 Jan 15 01:30 /dev/null crw-r--r-- 1 root  wheel   45,   0 Aug 19 16:24 /dev/random crw-rw-rw- 1 root  wheel    2,  12 Aug 19 16:24 /dev/zero FreeBSD% ls -l /dev/null /dev/zero /dev/random crw-rw-rw- 1 root  wheel    2,   2 Jan 12 13:33 /dev/null crw-rw-rw- 1 root  wheel  250,   0 Jan  9 11:13 /dev/random crw-rw-rw- 1 root  wheel    2,  12 Jan  9 10:22 /dev/zero

Notice that the numbers are different for /dev/random between FreeBSD and OpenBSD. FreeBSD 4.x uses still different numbers. Using sudo, create the device nodes as shown in Example 5-5.

Example 5-5. Making device nodes

FreeBSD$ sudo mknod /etc/namedb/dev/null c 2 2 FreeBSD$ sudo mknod /etc/namedb/dev/random c 250 0 FreeBSD$ sudo mknod /etc/namedb/dev/zero c 2 12

The virtual /etc directory needs to contain a named.conf file. Note that if you are running FreeBSD, you will use /etc/namedb/named.conf. That means you will create /etc/namedb/etc/namedb in addition to /etc/namedb/etc.

When running in chroot, using the -t option, all the filesystem paths are translated. That is, if named is compiled to use /etc/namedb/named.conf (which is how FreeBSD compiles BIND by default), then it is really expecting /etc/namedb/etc/namedb/named.conf. It is a good idea to remove or rename the /etc/namedb/named.conf file that lives in the real /etc directory. It might mislead you or another administrator who forgets that named runs in a chroot environment.

Alternatively, you can add -c /etc/namedb/named.conf to the named_flags option in /etc/rc.conf. This will cause that file to be used as the configuration file instead of /etc/namedb/etc/namedb/named.conf.

5.5.1.2 Launch BIND from /etc/rc.conf

To launch at named boot time, set the named_enable variable in /etc/rc.conf. Set the named_flags variable to include the correct command-line options for your installation. For OpenBSD, there is a single line to add:

named_flags="-u named -t /var/named"

OpenBSD comes with a user called named already in the password file and a chroot environment already built in /var/named. By virtue of the fact that named_flags is not the string NO, named is invoked at boot time. Note that the named command in /etc/rc is run from the default PATH. That is, rather than invoking /usr/sbin/named explicitly, the script just invokes named. The binary to execute is resolved using the PATH environment variable set at the beginning of the /etc/rc script. If you want to override the named binary that is executed, you will have to manually edit the /etc/rc script itself.

To enable named at boot time on FreeBSD, a very similar named_flags line needs to be added to /etc/rc.conf. Notice that FreeBSD calls its DNS user bind instead of named. The named_enable variable must be set to YES. If you are running BIND 9, but chose not to overwrite the base installation, you have to define an additional variable, named_program, to specify which named binary to execute. A typical FreeBSD configuration looks like:

named_enable="YES" named_flags="-u bind -t /etc/namedb"

FreeBSD, beginning with the 5.X versions, now uses a more advanced /etc/rc system for booting. The tasks for starting up BIND are in /etc/rc.d/named. They include a special function that will automatically keep a chroot area up to date. If you set named_chroot_autoupdate=yes in /etc/rc.conf, a series of commands will execute at boot time to make sure that some files are copied into the right place. Do not use this variable and functionality if you run BIND 9. It does not make all the devices that you will need (e.g., /dev/random) and it tries to copy an obsolete program (named-xfer). The automatic chroot feature only works for BIND Version 8.

5.5.2. Configuration Ideas

There are a few standard techniques that DNS administrators use to make their servers more secure, more auditable, or both. They include the restricting access to certain features, restricting access to functionality, and obscuring the version number.

5.5.2.1 Security restrictions

All of the following options are applicable in both FreeBSD and OpenBSD contexts. They are useful for either defending against attacks or for preventing extraneous use of your server. All of these options are demonstrated in Example 5-6.

allow-recursion

This also should be set to none if your server is authoritative. If your server is a caching server that is supposed to allow recursion, omit this directive from your default options section, and instead add it to the view that you define for recursion.

allow-transfer

Set this to none to prevent anyone from performing zone transfers by default. For each zone that should have zone transfers enabled, specifically identify the proper servers through an access control list (ACL).

controls

This line should always be present in the named.conf file, whether you intend to use rndc's ability to control named or not. If you do not want to use rndc in any way at all, this line must still be present. It should read controls {};.

query-source

Sometimes it is useful to have BIND use a specific source address and port. Perhaps the server is "multi-homed" (i.e., having more than one IP address assigned to it). Perhaps, in order to make the firewall rules maximally restrictive, the DNS responses must have both source and destination ports set to 53. The query-source line can accomplish these tasks.

version

Set it to something other than the obvious. An attacker can try to probe your BIND version by querying for the TXT record "version.bind" in the Chaos class. Chaos is a vestigial class that is not used anymore. To try to query your own version, run dig @servername version.bind. chaos txt. Replace servername with the name of your BIND server. Realize that this is of very limited value. Only script kiddies will blindly trust the version that your server reports and base their attacks on it.

The configuration options in Example 5-6 are a recommended starting point. You will need to customize them for your own use.

Example 5-6. Several security-related BIND options

options {         directory "/etc/namedb";        // inside our virtual root         allow-recursion { none; };      // we are authoritative only         allow-transfer  { none; };      // default deny; override in zones.         query-source address * port 53; // for firewalls         version "Undisclosed";          // obscure our version.bind }; controls {         inet 127.0.0.1 allow { localhost; } keys { rndc_key; }; }; key rndc_key {         algorithm "hmac-md5";         // This is just some randomness that I got by doing         // dd if=/dev/random bs=32 count=1 | openssl base64         secret "sQMUKll0IV1gUz6oUkIaxU1B5uQBioXFgAORoa+/OZA="; }; include "example.com.zone";             // See Example 5-8

5.5.2.2 Logging

BIND 9 provides reasonably fine-grained logging options to allow you to sort through all the different events it might log and guide them to the right places. Example 5-7 shows one potential configuration for logging.

Example 5-7. Organizing BIND's logs

logging {         channel my_default    { syslog local7; severity info; };         channel my_security   { syslog local6; severity notice; };         category security     { my_security; };         category default      { my_default; };         category config       { my_default; };         category xfer-in      { my_default; };         category xfer-out     { my_default; };         category update       { null; };         category lame-servers { null; };         category queries      { null; }; };

In the example, we have created just three categories of messages. The usual messages that one might expect to accumulate in /var/log/messages are directed to syslog using the LOCAL7 service at severity info. Security-oriented messages (as defined by BIND's notion of "security") are sent to a different syslog service. This allows us to configure syslog to treat them differently. Perhaps we will log security messages off-system in addition to a special security logfile. Lastly, a few types of logged messages that are rarely useful are discarded. These tend to be useless messages that bloat logfiles, except in specific circumstances when you need forensic information. See the ARM for the full list of categories of events that can be logged.

There are a few good reasons, however, why you might temporarily watch the update or xfer-out categories more closely. If you suspect that someone is trying to misuse your DNS server, you may want to send these two categories to a special logfile for a little while. Sometimes performance for DNS can slow down because Windows systems are attempting many dynamic updates (a fundamental technique used in Active Directory). Turning on update logging will quickly show you if that is the case. Alternatively, you may find attempted updates from nonlocal networks. These may be symptomatic of an attack probe of some kind, or they may be the result of a simple misconfiguration somewhere at the foreign site. The xfer-out category will show you who is trying to transfer zones (using either AXFR or IXFR queries) from your server. A quick grep for "denied" will find the systems that are attempting and failing to transfer your zones. This might be useful information to correlate with firewall or intrusion detection logs to see if the failed transfers coincide with other unusual network activity.

5.5.2.3 Using includes to separate permissions

Some parts of the named configuration are more sensitive than others and should be protected differently. Logging options, for instance, are much less critical than the keys that allow updates or authenticate zone transfers. By using BIND's include directive, you can put sensitive material in separate files, and then protect those files more carefully. The fragment of named.conf shown in Example 5-6 demonstrates this by including a file named example.com.zone, which contains the zone configuration information shown in Example 5-8. Keys used for rndc or TSIG, for example, are good candidates to be included this way.

5.5.3. Managing BIND

BIND includes a program called rndc for managing the named daemon. In previous versions, this program was called ndc and was substantially limited in what it could really do. The rndc program, by contrast, can do many things that administrators have wanted for a long time. Zones can be added and deleted, updates can be sent to slave servers, and the server can be stopped and started.

In order to use rndc, it is important to configure it properly. If it is configured poorly, then a variety of vulnerabilities are introduced. Remote users could stop the server or even drop whole zones.

Example 5-6 included the two statements (controls and key rndc_key) that enable the control by rndc. BIND 9 includes a script called rndc-confgen that will create the key file and the corresponding rndc.conf file. By giving rndc-confgen the -a option to perform automatic configuration and the correct -t and -u options, like you would give named, it will create the files in the right locations. For example: rndc-confgen -a -t /etc/namedb -u named.

5.5.4. Transaction Signatures (TSIG)

One of the long-standing problems with DNS is the lack of authenticity for records in zones and the ability to establish trust relationships between servers. Some solutions could exist, using TCP connections that used application-level authentication. However, with DNS being as pervasive as it is, it has always benefited from being UDP-based. Individual packets, often no larger than 512 bytes, travel quickly across the net and create minimum burden on the network. To continue in this low-bandwidth tradition, DNS needs authentication that can still fit in UDP packets. Several different security mechanisms have been defined in DNS. These mechanisms are covered in more detail in DNS and BIND by Liu and Albitz. Of the various DNS security measures (typically considered together under the label DNSSEC), only TSIG has real practical value today.

Defined in RFC 2845, TSIG provides a mechanism for attaching a digital signature to a DNS request. Currently the signature is a message authentication code (MAC) using the MD5 hashing algorithm, thus the algorithm is called hmac-md5. Any request can be signed. It can be a simple request for an MX record, or it can be a dynamic update request. Responses can also be signed in the same way. Using TSIG, two DNS servers can authenticate their conversations.

5.5.4.1 Cautions about using TSIG

One of the significant drawbacks to TSIG is that it is based on a symmetric cryptography system. It requires both DNS servers to have the same shared secret established in advance. TSIG, therefore, is only used between systems that explicitly trust each other (for example, two servers operated by the same organization). It is only practical on a small scale. It might be scalable to perhaps a handful of organizations, or across a few dozen systems within a large organization. It also suffers another risk of symmetric cryptography: if the shared secret is compromised, then authentic messages can be forged without being detected.

TSIG is useful, so long as you maintain its key as carefully as you maintain other critical cryptographic keys. Most SSL-enabled web servers, for example, store a private key in a file that must be readable by the web server but must also be protected from prying eyes. The TSIG key for named, then, is very similar and must be handled appropriately. As an alternative to what is shown in Example 5-6, BIND 9 will also look in the file /etc/rndc.key for the rndc key (or /etc/namedb/rndc.key under FreeBSD). While this was primarily added to BIND as a migration aid for migrating from BIND 8 to BIND 9, it serves the additional purpose of allowing us to protect our key material differently than the named.conf file itself.

If you are using FreeBSD, the rndc.key and rndc.conf files are probably good candidates for ACLs (see Chapter 2). Using ACLs, the file access permissions can be set to permit only the bind user to access the file.

5.5.4.2 Practical uses for TSIG

There are two common, practical uses of TSIG: authenticating dynamic updates and authenticating zone transfers (either full or incremental). Example 5-8 shows a domain with both of these options enabled. The server will only respond to zone transfer requests if they are signed by a specific key. It will also accept dynamic updates to the zone, but only if they are signed. All of these directives could be put in a separate file called example.com.inc and then that file could be included using BIND's include syntax.

Example 5-8. Restricting access via TSIG

key "example.com.key." {         algorithm hmac-md5;         secret "WW91IGFjdHVhbGx5IGRlY29kZWQgdGhpcz8="; }; acl "tsig_example.com" {         key example.com.key.; }; zone    "example.com"  {         type master;         file "example.com";         allow-update   { "tsig_example.com"; };         allow-query    { any; };         allow-transfer { "tsig_example.com"; }; }; server  12.34.56.78 {         keys { "example.com.key."; }; };

The syntax demonstrated in Example 5-8 suggests ways that access can be controlled. There is no limit to the number of different access control list (ACL) statements that can be included in the configuration file. Furthermore, an ACL can combine TSIG-based authentication with IP-based authentication. That is, requests from certain IP addresses could be trusted without signatures, while the presence of a correct signature would cause requests to be honored regardless of the originating IP address.

The server line in Example 5-8 shows how to indicate which cryptographic keys your server shares with another server. There are several limitations to this scheme. You can only specify servers by IP address. If the server's IP changes, you must alter your named.conf file and restart named. All conversations with that server will be signed with TSIG signatures even basic queries. This can increase the computational load on your server as it computes signatures and verifies the signatures on the responses. You cannot limit TSIG usage, for example, to just zone transfer requests. Lastly, though the syntax implies using multiple keys with a given server, it is actually not possible. BIND only supports exactly one key per server.

Keep in mind, when writing access control lists, that each ACL is an "or" list. Access is granted if any one of the characteristics in the ACL is satisfied. Likewise, the allow-transfer and allow-update lists work the same way. As long as the request satisfies one of the listed authorizers, the request is honored. More complex behavior is possible, but it makes the named.conf file dangerously complex.