Limiting effects of an intrusion

Even if you’re prepared to implement any DNS fix as soon as it appears, you may be too late - even by only a couple of hours:

your system could be compromised anyway. It is therefore advisable to take precautions in order to minimize the impact of a possible compromise.

7.3.6.1 Running BIND with less privileges

In some distributions, BIND runs as root. If BIND is compromised, the attacker may get root access. This can be prevented by running BIND under a non-privileged user and group.

It is tempting to use user nobody and group nogroup. But as many services already run as nobody and nogroup another security issue arises: these services might hence be able to communicate in one way or another.

Best practice is to create a special user, e.g. named, and a corresponding group (which could also be called named), and run the name server under this user/group combination.

To use the special user and group, specify the -u and -g options to named:

named -u named -g named

On a Debian system the start line in /etc/init.d/bind would be:

start-stop-daemon ... --exec /usr/sbin/named -- -u named -g named

(For clarity other options were replaced by dots). The extra -- tells the start-stop-daemon where its options end, all other options will be passed on to the named program.

On a Red Hat (or compatible) system, the startup file can be found in /etc/rc.d/init.d/named. On RHEL systems the service is already configured to run under the user ’named’. You can set additional options in /etc/sysconfig/named, for example you can add -u named there. To start the service on Red Hat (compatible) systems, use the service command:

# service named start

Generating /etc/rndc.key: [ OK ]

Starting named: [ OK ]

To make named start up in the proper runlevels on Red Hat (compatible) systems run `chkconfig named on`.

Note

Make sure the name server has write access in the directory specified by thedirectoryoption innamed.conf.

7.3.6.2 Running BIND in a chroot jail

Another way to prevent damage from a compromised name-server process is to put the process in a chroot jail. On startup the process will set a directory (e.g. /var/cache/bind) as its root directory. As no process is ever capable of accessing anything above its set root this prevents the process of accessing anything outside the hierarchy that starts at /var/cache/bind.

7.3.6.2.1 Preparing a chroot jail

All files that BIND needs need to be copied over to the new root directory. Full details can be found here:ChrootBind9.

In short:

• You will need to copy the etc, dev, lib, sbin or usr/sbin, and var/run directories under the new root.

• You’ll probably need the /dev/null device under the new root. The next command will create it:

mknod -m 666 /var/cache/bind/dev/null c 1 3

• You will need a passwd and a group file in the new /etc:

cd /var/cache/bind/etc cp -p /etc/{passwd,group} .

This copies the literal passwd and group files. An alternative is to create special passwd and group files, as will be shown in Section7.3.6.3.

You may also need to copy over ld.so.cache and localtime:

cd /var/cache/bind/etc cp /etc/ld.so.cache . cp /etc/localtime .

• The BIND configuration should also be placed under the new root, as named might need it when you reload the server. Given that your new root is set to /var/cache/bind you should copy the file over to /var/cache/bind/etc/bind.

Note that each directory specified in the new named.conf - the ones specified with the directory option - is relative to the new root directory, so you do not need (nor should) include the prefix /var/cache/bind there.

• The new lib directory must contain at least all the shared libraries used by bind. You can list these with the ldd command.

For instance, suppose the command:

ldd /usr/sbin/named yields

libc.so.6 => /lib/libc.so.6 (0x40015000)

/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

When looking in (real) /lib, libc.so.6 is a symlink to libc-2.1.3.so and ld-linux.so.2 is a symlink to ld-2.

1.3.so. Both the symlinks and the files they point to must be copied to the lib directory under the new root:

cd /var/cache/bind/lib

cp -pd /lib/{libc.so.6,libc-2.1.3.so,ld-linux.so.2,ld-2.1.3.so} .

• Both the named and the named-xfer programs must be present under the new root. The rndc program may be of help too.

For example:

cp -p /usr/sbin/named{,-xfer} /var/cache/bind/usr/sbin cp -p /usr/sbin/rndc /var/cache/bind/usr/sbin

7.3.6.2.2 Running BIND chrooted

To start the BIND name server in a chroot jail, simply add the -t option followed by a directory name, either on the command line, in the startup script or in the sysconfig file.

Note

The-toption actually runs thechroot command to start the name server. Read the manual pages on the chroot command to learn more.

In some systems you may need to add the option to the startup file. For example:

start-stop-daemon ... --exec /usr/sbin/named -- -t /var/cache/bind or

daemon ... /sbin/named -t /var/cache/bind

Important

The BIND name server switches to the new root immediately after succesful parsing of the arguments on the command line, thus before any configuration files are read. Any path names you use in the configuration file should be relevant to the new root.

7.3.6.2.3 Configuration for a chrooted BIND

As a consequence of using a chrooted jail, every configuration file (e.g. zone files and the named.conf file) must be present in a configuration directory (e.g., /etc/bind) under the chroot directory.

Logging to syslog does not work either as the chrooted process can not access the Unix socket located outside its jail (no access to /dev/log). There are various workarounds but the simplest one is to provide an alternate logfile location inside the chrooted environment. See this snippet of the named.conf file you might use inside the chrooted environment:

logging {

channel some_log {

file "bind.log" versions 3;

severity info;

};

category default { some_log; };

// ...

};

This will write logging information to the file /var/cache/bind/var/cache/bind/bind.log.

Zone files, if any, should also be put inside the chroot environment. For instance, if named.conf contains a definition of a master zone like this:

zone "example.com" IN { type master;

file "/etc/bind/example.com.zone";

};

the example.com.zone file needs to be in /var/cache/bind/etc/bind, again assuming your chroot directory is /var/cache/bind.

7.3.6.3 Combining special user and chroot

More technical security can be obtained by using a combination of a chrooted environment and running the nameserver under a special non-privileged user and group. Note that you need to add these users to the copies of /etc/passwd and /etc/group you need in the chrooted environment. Finally, set permissions on the chrooted zone- and configuration files so they are not writable by the named user and group.

Note

Inspecting the source for BIND reveals the order of things:

• parsing of commandline options

• chrooting

• become a background process and write pid file

• change to new user and group

The pid file is still written by therootuser, after that the less privileged ’named’ user will be used.

The chroot environment may and should contain special /etc/passwd, /etc/shadow and /etc/group files, that may completely differ from the ones used by the rest of the system. The special user and group used by the name server may not even exist outside the jail.