Cache poisoning attacks and how to prevent them
Want something scary to think about? 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. In this tip, Cricket Liu provides a checklist of measures you can take to secure your DNS infrastructure.
 |
|
 |
|
| Cricket Liu | |
|
|
Infoblox recently sponsored a study by The Measurement Factory to determine how vulnerable name servers on the Internet are to various types of attack. The results were alarming: of 1.3 million name servers surveyed, more than 75 percent allowed recursive queries from arbitrary IP addresses. Such name servers are more vulnerable to cache poisoning attacks than name servers that deny recursive queries or that only allow recursive queries to a set of authorized queriers. About 40 percent of the name servers sampled allowed zone transfers from arbitrary IP addresses. This could be exploited to mount a denial of service attack against the name server. And, in roughly a third of the cases, all of the name servers serving a particular zone were on the same /24 network, making both accidental and deliberate denials of service more likely.
|
||||
|
|
|||
|
||||
- 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.
- 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.
- 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.
- 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.2, or even 9.3.
- 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.)
- 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.
- 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.
Cricket Liu is the co-author of all of O'Reilly & Associates Nutshell Handbooks on the Domain Name System, DNS and BIND, DNS on Windows 2000, DNS on Windows Server 2003, and the DNS & BIND Cookbook, and was the principal author of Managing Internet Information Services.
Cricket is Infoblox's vice president of architecture and serves as a liaison between Infoblox and the DNS user community. He worked for Hewlett-Packard for nearly ten years, where he ran hp.com, one of the largest corporate domains in the world, and helped found HP's Internet consulting business. Cricket later co-founded his own Internet consulting and training company, Acme Byte & Wire. After Network Solutions acquired Acme Byte & Wire and later merged with VeriSign, Cricket became director of DNS Product Management.
