Hack 51 Secure BIND

Lock down your BIND setup to help contain potential security problems.

Due to BIND's not-so-illustrious track record with regard to security, you'll probably want to spend some time hardening your setup if you want to continue using it. One way to make running BIND a little safer is to run it inside a sandboxed environment. This is easy to do with recent versions of BIND, since it natively supports running as a nonprivileged user within a chroot( ) jail. All you need to do is set up the directory you're going to have it chroot( ) to, and then change the command you're using to start named to reflect this.

To begin, create a user and group to run named as (e.g., named). To prepare the sandboxed environment, you'll need to create the appropriate directory structure. You can create the directories for such an environment within /named_chroot by running the following commands:

# mkdir /named_chroot # cd /named_chroot # mkdir -p dev etc/namedb/slave var/run

Next, you'll need to copy your named.conf and namedb directory to the sandboxed environment:

# cp /etc/named.conf /named_chroot/etc # cp -a /var/namedb/* /named_chroot/etc/namedb

This assumes that you store your zone files in /var/namedb. If you're setting up BIND as a secondary DNS server, you will need to make the /named_chroot/etc/namedb/slave directory writable so that named can update the records it contains when it performs a domain transfer from the master DNS node. You can do this by running a command similar to the following:

# chown -R named:named /named_chroot/etc/namedb/slave

In addition, named will need to write its process ID (PID) file to /named_chroot/var/run, so you'll need to make this directory writable by the named user as well:

# chown named:named /named_chroot/var/run

Now you'll need to create some device files that named will need to access after it has called chroot():

# cd /named_chroot/dev # ls -la /dev/null /dev/random crw-rw-rw-    1 root     root       1,   3 Jan 30  2003 /dev/null crw-r--r--    1 root     root       1,   8 Jan 30  2003 /dev/random # mknod null c 1 3 # mknod random c 1 8 # chmod 666 null random

You'll also need to copy your time zone file from /etc/localtime to /named_chroot/etc/localtime. Additionally, named usually uses /dev/log to communicate its log messages to syslogd. Since this doesn't exist inside the sandboxed environment, you will need to tell syslogd to create a socket that the chrooted named process can write to. You can do this by modifying your syslogd startup command and adding -a /named_chroot/dev/log to it. Usually you can do this by modifying an existing file in /etc.

For instance, under Red Hat Linux you would edit /etc/sysconfig/syslogd and modify the SYSLOGD_OPTIONS line to read:

SYSLOGD_OPTIONS="-m 0 -a /named_chroot/dev/log"

Or if you're running FreeBSD, you would modify the syslogd_flags line in /etc/rc.conf:

syslogd_flags="-s -a /named_chroot/dev/log"

After you restart syslogd, you should see a log socket in /named_chroot/dev.

Now to start named all you need to do is run this command:

# named -u named -t /named_chroot

Other tricks for increasing the security of your BIND installation include limiting zone transfers to your slave DNS servers and altering the response to BIND version queries. Restricting zone transfers ensures that random attackers will not be able to request a list of all the hostnames for the zones hosted by your name servers. You can globally restrict zone transfers to certain hosts by putting an allow-transfer section within the options section in your named.conf.

For instance, if you wanted to restrict transfers on all zones hosted by your DNS server to only 192.168.1.20 and 192.168.1.21, you could use an allow-transfer section like this:

allow-transfer {     192.168.1.20;     192.168.1.21; };

If you don't want to limit zone transfers globally and instead want to specify the allowed hosts on a zone-by-zone basis, you can put the allow-transfer section inside the zone section.

Before an attacker attempts to exploit a BIND vulnerability, they will often scan for vulnerable versions of BIND by connecting to name servers and performing a version query. Since you should never need to perform a version query on your own name server, you can modify the reply BIND sends to the requester. To do this, add a version statement to the options section in your named.conf.

For example:

version "SuperHappy DNS v1.5";

Note that this really doesn't provide extra security, but if you don't want to advertise what software and version you're running to the entire world, you don't have to.

See Also