|
|
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
| Tip |
To learn more, consult the BIND9 Administrator Reference Manual at www.nominum.com/content/documents/bind9arm.pdf. |
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.
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.
| Tip |
You can also fix this problem by setting the allow-transfer option globally to {! 0.0.0.0;}, which will disallow zone transfers from all IPs on the Internet by default. Then you can simply allow them on a zone-per-zone basis as needed. |
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.
|
|
|