Securing DNS and BIND

As of this writing, the most current version is 8.2.2, patch level 5. Due to a particularly nasty buffer-overflow problem that can lead to unauthorized root access of vulnerable systems (the “NXT” bug, described in CERT Advisory #CA-99-14) in all older 8.2 releases, it is essential that anyone using BIND be at least at version 8.2.2P5.

Note that for some time after BIND v.8.1 was initially released in May 1997, many users deliberately continued using BIND v.4 due to its stability (and possibly to postpone having to learn the new configuration-file syntax). In fact, the Internet Software Consortium(ISC) continued to support, and even patch, version 4, releasing BIND v.4.9.7 a full year after 8.1's debut.

However, the ISC no longer recommends that anybody continue using BIND v.4, even v.4.9.7. So it bears repeating: everyone who runs BIND on an Internet server should be running the latest release of version 8.x.

We've established that you need the latest version of BIND. But should you use a pre-compiled binary distribution (such as an RPM), or should you compile it from source? For most users, it's perfectly acceptable to use a binary distribution, provided it comes from a trusted source. Virtually all UNIX variants include BIND with their “stock” installations; just be sure to verify that you indeed have the latest version.

The command to do this with Red Hat Package Manager is rpm -q -v bind8 if the package has already been installed, or rpm -q -v -p ./<path & filename of package> if you have a package file, but it hasn't been installed yet. The rpm package name for BIND is usually “bind8” or “bind”.

If you perform this query and learn you have an old (pre-8.2.2p5 version), most package formats support an “upgrade” feature; simply download a more current package version from the Linux distribution web site, and upgrade it using your package manager. To do this with RPM, the command syntax is rpm -U ./<path & filename of package>, assuming you don't need special install options. If the above doesn't work, you can try rpm -U --force ./<path & filename of package>.

If you can't find a suitable binary distribution, compiling it from source is easy: there is no “configure” script to run, and none of BIND v.8x's Makefiles need be edited. Simply follow the brief instructions in the source's INSTALL file (make; make install is all most people need to do).

It's premature to start named (the main process of BIND) just yet. But how you plan to run named will determine how it should be configured. Now is a good point, therefore, to talk about some startup options that can enhance security.

As with all Internet services, it's a good idea to run named in a “padded cell” in which a prospective cracker will be trapped should he/she exploit, for example, some obscure buffer-overflow vulnerability. Three flags make this cell easy to achieve: -u <username>, -g <group name> and -t <directory for named to chroot to>.

The first causes named to run under the specified user name. The second causes named to run under the specified group name, while the third changes (“chroots”) the root of all paths referenced by named. Note that when running named chrooted, this new root is applied even before named.conf is read. Therefore if, for example, you invoke named with named -u named -g wheel -t /var/named, then it will look for named.conf in /var/named/etc rather than in /etc. That is, the default location of named.conf is always /etc, but if named is chrooted to path /other/path, /etc will be translated as /other/path/etc.

The net effect of these three flags (when used properly) is that named's permissions, environment and even file system are severely limited. Should an unauthorized user somehow hijack named, instead of gaining root permissions (prior to BIND v.8, named ran as root) they'll gain the permissions of an unprivileged account. Furthermore, they'll see even less of the server's file system than an ordinary user can: directories connected to directory-tree nodes higher than the chroot-point won't, from named's perspective, even exist.

Running named in a padded cell is paranoid and elite in itself. But that's just the beginning! BIND 8.x's configuration file, named.conf, with its large number of supported parameters, allows you to control named's behavior with a great deal of granularity.

Consider the example named.conf file as shown in Figure 3.

Figure 3. Example named.conf File

The hypothetical server whose configuration file is represented here is an external DNS server. Since its role is to provide information to the outside world about coolfroods.org's publicly accessible services, it has been configured without recursion. In fact, it has no “.” zone entry (i.e., no pointer to a hints file), so it knows nothing about and cannot even learn about hosts not described in its local zone files. Transfers of its local zone databases are restricted by IP address to a group of trusted slave servers, and logging has been enabled for a variety of event types.

So how do we do these and even more nifty and paranoid things with named.conf?