Securing DNS and BIND

Decreasing the vulnerability of your DNS server is largely a matter of staying current and private.
Selecting and Installing the Appropriate BIND Software

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).

Starting named: The Padded Cell

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.

Overview of named.conf

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?

______________________

Webinar
One Click, Universal Protection: Implementing Centralized Security Policies on Linux Systems

As Linux continues to play an ever increasing role in corporate data centers and institutions, ensuring the integrity and protection of these systems must be a priority. With 60% of the world's websites and an increasing share of organization's mission-critical workloads running on Linux, failing to stop malware and other advanced threats on Linux can increasingly impact an organization's reputation and bottom line.

Learn More

Sponsored by Bit9

Webinar
Linux Backup and Recovery Webinar

Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.

In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.

Learn More

Sponsored by Storix