Network Security Hacks [Electronic resources] نسخه متنی

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

The section "Securing BIND" in Building Secure Servers with Linux, by Michael D. Bauer (O'Reilly)