BIND is a DNS server package that's had a rather spotty history when it comes to security. However, despite these limitations, there are few alternatives for serving up DNS data that are as feature-rich as BIND.
If you just need to serve up DNS data without support for zone transfers, keys, and other features that BIND offers, using something like D.J. Bernstein's djbdns package may be sufficient. But if you need some of the more robust features that only BIND offers, you might as well learn a few things you can do to better secure your setup.
First, configure BIND not to report its version number. This can stop passive scanners from identifying the version of BIND you're using.
This trick doesn't really secure BIND as much as it obfuscates things a bit. You can do this by editing the named.conf file, as shown below:
options {
version "Not available";
}
You can also restrict which hosts can perform zone transfers. BIND configurations typically have no restrictions for performing a zone transfer, which can lead to providing unwanted data to potential attackers.
You can also set this restriction using the named.conf file. Here's an example:
options {
allow-transfer { 192.168.5.10; };
}
This restricts zone transfers to 192.168.5.10, which would be your secondary DNS server. You can also use Transaction Signatures (TSIG) to more securely perform zone transfers.
You should also disable recursive queries, which prevents your DNS server from being vulnerable to spoofing attacks. Add the following to the named.conf file:
options {
fetch-glue no;
recursion no;
}
Finally, you may also want to consider running BIND in a chrooted environment as a nonprivileged user. (BIND's documentation discusses how to do this.)
By running BIND in a chroot, you're locking it into a special section of your system where it can't interact with the rest of the system, minimizing the damage potentially caused by an attacker who successfully exploits it.
|