37.3. Objective 3: Securing a DNS ServerAs with any computer sitting on the Internet, you need to secure your DNS server . Here are a few reasons:
Some of the things you can do to secure your DNS servers are:
Depending on your setup, there are other things you may be able to do. Also, as with any other program, bug and security fixes for BIND are frequently publicized, so keep abreast of BIND developments. Let's look at some of the items just listed, one by one. 37.3.1. Dedicated ServersIdeally, your DNS server should run only DNS. If you have your DNS server running on a computer with SMTP and POP (email), user accounts, a dozen web sites, and so on, you have many attack vectors open. A bare-bones computer that has only port 53 open is much more difficult to break into than one that has open ports for Telnet, HTTP, SMTP, POP, and IMAP. You should also have separate internal and external DNS servers. The internal servers should respond to queries only from internal addresses. You do that with a command such as the following (the IP address is a typical internal subnet address): allow-query {192.168.1.0/24;}; You can chain multiple subnets together using semicolons (;). If the internal servers need to resolve an address from outside the network, you can have them forward the query to the external server with: forwarders {200.200.1.17; 200.200.1.18;}; 37.3.2. Restricting Zone TransfersIf an attacker can do a zone transfer (and anyone who has access to nslookup or dig can do a zone transfer!), she can get a pretty good idea of how your network is laid out. Knowing how your network is laid out lets her know where to attack. Be sure that only your servers can do a zone transfer by putting a line like the following in your /etc/named.conf files on each server: options { allow-transfer {10.10.10.5;192.168.1.12;};} where the 10.10.10.5 and 192.168.1.12 addresses are examples; substitute the addresses of your other DNS servers. Another good idea is to use TSIGs (discussed next). 37.3.3. Using Transaction Signatures (TSIG)Transaction signatures, or TSIGs, were introduced in BIND 8.2 and more fully fleshed out in BIND 9. TSIGs encode the data whenever a zone transfer occurs. In BIND 9, TSIGs can also be used for dynamic updating of zone records. The process of using TSIGs is not complicated, but can be difficult to troubleshoot. One of the most important things to keep in mind is that the clocks on the DNS servers must be synchronized. The best and easiest way to do this is by using the Network Time Protocol (NTP). Additionally, all of your DNS servers should use the same NTP server. Here is the process for a server running BIND:
37.3.4. Recursive QueriesYour DNS servers should do recursive queries only from your network. Not only will this allow for better performance, but it can help prevent a DOS scenario known as DNS cache poisoning. All DNS servers cache the replies to their queries. Some are (mis)configured to cache all replies, even if they didn't send out a query. If an attacker sends a reply that says "www.oreilly.com is at 192.168.1.1" and the receiving DNS server accepts the reply and places it in the cache, the cache has been poisoned. In BIND, recursive queries are the default, so be sure to turn them off on your external servers with: recursion no; If you don't have separate external and internal servers (or you just don't want to turn off recursion), you can restrict recursive queries to specific subnets with a section such as: allow-recursion {192.168.1.0/24; 10.10.0.0/16;}; 37.3.5. Running BIND in a chroot Jail/Reduced PrivilegesRestricting which system resources BIND can access will make your server harder to break into and, if someone does break in, make it harder for her to do damage. The classic way of doing this is to run BIND in a chroot jail. The process is quite involved, so we won't get into details here. The basic process is:
The new -uusername and -tdirectory features of Bind 9 make it easier to run BIND in a chroot jail. Once the command-line options are read, BIND will chroot itself in the directory directory as the user username. This has the disadvantage that, for a short time during program startup, BIND is not chrooted. Also, some people think the chroot code in BIND needs more testing. On the other hand, it is much easier to use than a chroot jail. Tip: If you're going to use the -u and -t options, do not run BIND as the root user (-u root), because on most Linux systems, root can break out of a chroot jail. |