A checklist for guarding against cache poisoning attacks
When reviewing your network infrastructure, don’t forget about that most arcane of networking technologies, the Domain Name System. A compromise of your name servers could cut you off from the Internet or redirect your customers to a competitor. It could even shunt sensitive electronic mail through an intermediate mail server or reroute your users to an exact replica of a popular web site, where their keystrokes, including account names and passwords, are captured.
Here’s a checklist of measures you can take to secure your DNS infrastructure:
1. Restrict recursion to only authorized queriers, or disable it entirely. You set your name servers up for a particular purpose: to answer queries about your zones, to serve your internal resolvers’ and name servers’ queries about Internet domain names, or both. If your name servers are dedicated to answering queries from other name servers on the Internet and nothing else, disable recursion. If your name servers’ exclusive function is to resolve Internet domain names for internal clients, restrict queries to those coming from your internal address space. If your name servers serve both functions, consider splitting the two functions between two sets of name servers and securing each set as already described. If you can’t split the functions, at least restrict access to recursion to your internal address space.
2. Restrict zone transfers to authorized secondary name servers. Most folks on the Internet don’t need to be able to transfer entire zones from your name server. (There are some exceptions: For example, some DNS registries require the ability to transfer zones from their registrants’ name servers.) Restrict zone transfers to your name servers’ authorized secondary name servers, using TSIG, if possible. On secondary name servers that shouldn’t serve zone transfers, disable them entirely.
3. Use forwarders to limit exposure. You could provide Internet name resolution by letting all of your internal name servers communicate directly with name servers on the Internet. But if your name servers turned out to have a vulnerability that allowed a hacker to crash them with a mal-formatted response, you’d have a lot of work on your hands to upgrade all of the exposed name servers. Instead, funnel Internet name resolution through a smaller set of name servers designated as forwarders. These can be sandwiched between your internal and external firewall, so that any compromise would be compartmentalized and wouldn’t expose your internal network.
4. Run the latest name server software. Our study also showed the only half of the name servers in the sample ran the latest name server code. Older name servers suffer from bugs and vulnerabilities, so it’s wise to upgrade to a modern version of the software. For BIND name servers, that’s something that begins with 9.5, or even 9.6.
5. Secure the platform. The name server software itself isn’t always the vector a hacker uses to attack a name server. In addition to securing the name server, you need to secure the underlying operating system platform. You’ll have to disable unnecessary network services and remove unnecessary accounts, for example. (Of course, if you buy an appliance, this is done for you.)
6. Check your work. BIND name servers, in particular, are hypersensitive to syntax. One seemingly innocuous mistake in a zone data file or named.conf file can have shockingly far-reaching effects, causing SERVFAIL responses to queries or even preventing your name server from restarting. The newest versions of BIND ship with two invaluable utilities, named-checkconf and named-checkzone, which you can use to check the syntax of your named.conf and zone data files before reloading. Or use a GUI to insulate you from the complexity of the underlying syntax.
7. Limit administrative access. On hosts running name servers, make sure that only authorized users have administrative access, and log their activity. This can be tricky on Unix- and Linux-based hosts, where a user with root access can do anything. But your OS may support more compartmented administrative access, or you may be able to rig something up using sudo, for example. Some commercial products also provide these capabilities.