Linux Troubleshooting Bible [Electronic resources] نسخه متنی

BIND9 Security

BIND9 offers a number of new security settings that you can use to lock down your DNS servers. Although we don't have the space to cover them here, if you run BIND9, you should take the time to get to know these features:

Access control lists

Transaction signatures

RNDC and TSIG

DNSSEC

Split DNS

Whether or not you use these advanced security features, there are a few simple habits that will keep your DNS server secure. In this section, we describe two of these and show you how to keep DNS under control. In addition, use the security methods you have established for your other Internet services.

Lock Down Your Name Servers

The first thing you should do to enhance security on your DNS server is to lock it down. By doing this, you disallow zone transfers from anyone except your machines that have legitimate need for zone transfer data. By default, the zone definitions in

named.conf look like this:

zone "example.com" IN {
type master;
file "example.com.zone";
allow-update { none; };
};

This is a huge security risk if left as is. If not locked down, anyone can do zone transfers from your DNS server and see all of the machines that your DNS has records for. Consider the output of the following

dig command, which requests a zone transfer with the

axfr option:

# dig example.com axfr @10.1.1.1
; <<>> DiG 9.2.2-P3 <<>> example.com axfr @10.1.1.1
;; global options:  printcmd
example.com.            86400    IN     SOA     example.com.
tom.yahoo.com.example.com. 2004011823 10800 900 604800 86400
example.com.          86400   IN      A       10.1.1.1
example.com.          86400   IN      NS      ns.example.com.
example.com.          86400   IN      NS      ns2.example.com.
Ftp example.com.      86400   IN      CNAME   example.com.
mail.example.com.     86400   IN      CNAME   example.com.
ns.example.com.       86400   IN      A       10.1.1.1
ns2.example.com.      86400   IN      A       192.168.128.3
webdav.example.com.   86400   IN      CNAME   example.com.
www.example.com.      86400   IN      CNAME   example.com.
example.com.          86400   IN      SOA     example.com.
tom.yahoo.com.example.com. 2004011823 10800 900 604800 86400
;; Query time: 3 msec
;; SERVER: 10.1.1.1#53(10.1.1.1)
;; WHEN: Sun Jan 18 22:31:32 2004
;; XFR size: 12 records

If you were of a malicious mind, wouldn't that be useful information? Because you're a dutiful administrator, though, that output should frighten you. Luckily, it's easy to lock this down. Simply add the

allow-transfer directive to your

named.conf zone block, as in

zone  "example.com" IN {
type master;
file "example.com.Zone";
allow update   {   none; };
allow-transfer { 192.168.128.3; 127.0.0.1; 192.168.128.25; 10.1.1.1;   } :
};

Now, named will prevent zone transfers from any IP addresses other than those specified in

allow-transfer. If someone tries to snoop your DNS data now, that person will get this error message:

# dig example.com axfr @10.1.1.1
; <<>> DIG 9.2.2-P3 <<>> example.com axfr @10.1.1.1
;; global options:printcmd
; Transfer failed.

Be sure to take care of this on all running DNS servers, including secondary, and tertiary servers (that is, all slave servers) if you are running them. Without this setting, you leave yourself open to would-be crackers. Anyone can fully enumerate all the hosts in your domain, or even all the hosts on your network, with DHCP unless you close this hole.

Running BIND9 in chroot Mode

If you want to enhance the security of your DNS server, consider running BIND9 in

chroot mode. This ensures that if crackers get into your system, they will be trapped in the application's

chroot directory (/var/named/chroot ) and won't be able to get out into the rest of the filesystem where they could do real damage. It's a good option for those who are particularly nervous about external intrusion.

By default, Fedora Core Linux has started installing BIND9 to run in

chroot mode. However, there are some concerns that you should know about before you decide to keep BIND9 in this mode. In particular, see the BIND9 Bug sidebar in this chapter. You can tell whether your system is running in

chroot mode or normal mode with the

ps command, as in

# ps auxw| grep [n]amed
named   7288   0.0  1.1  36796 2484 ?  S    00:36   0:00
/usr/sbin/named -u named -t /var/named/chroot

This output shows that you're in

chroot mode. If you were running in normal mode, the output would look like this:

# ps auxw| grep [n]amed
named   7427   1.0  1.1   36348 2468 ?  S   01:13   0:00
/usr/sbin/named -u named

On Fedora Core, BIND's

chroot mode is controlled by the file

/etc/sysconfig/named. If you open this file in a text editor, you'll see a line beginning with

ROOTDIR . This line determines whether BIND9 runs in

chroot or normal mode. In

chroot mode (the default), the line looks like this:

ROOTDIR=/var/named/chroot

To change BIND9 to normal mode, change the line to this:

ROOTDIR=/

If you decide to leave your system in

chroot mode, be sure that you have a file at

/var/ named/chroot/etc/named.conf and that the file has content. You should also have these files to start with:

/var/named/chroot/var/named/
/var/named/chroot/var/named/named.ca
/var/named/chroot/var/named/named.local
/var/named/chroot/var/named/localhost.zone

At the time we wrote this book, there was an open bug in the BIND9

/named implementation on Fedora Core. Normally, when running in

chroot mode, the file

/var/named/chroot/ etc/named. conf contains the configuration file for

chroot 'd BIND9. Because of the bug, this file may be empty, which keeps DNS from running at all in

chroot mode unless you apply the fix. There are two workarounds to solve this problem.

The easy way to fix this bug is to run BIND9/named in normal root mode, changing the

ROOTDIR variable as described in the Running BIND9 in chroot Mode section of this chapter.

If you want to run in

chroot mode and take advantage of its more secure environment, you will have to do a bit of extra work and copy the

/etc/named.conf file into the

/var/named/ chroot/etc/ directory. Do so with this command:

# cp -p /etc/named.conf /var/named/chroot/etc cp: overwrite
'/var/named/chroot/etc/named.conf'? Y

The same problem exists with the zone files stored in

/var/named . You must copy these as well:

# cp -p /var/named/*.* /var/named/chroot/var/named
cp: overwrite '/var/named/chroot/var/named/localhost.zone ' ? Y
cp: overwrite '/var/named/chroot/var/named/named.ca ' ? Y
cp: overwrite '/var/named/chroot/var/named/named.local'? Y

This problem may be fixed by the time you read this book, but it's a good reminder that you should be careful when choosing an operating system for a production environment. You can always track bugs and patches at http://bugzilla.redhat.com .