Cache poisoning attacks and how to prevent them

Cricket Liu
Halloween is an apt time to think about the threats menacing your network infrastructure, and to take steps to buttress network components against attack and accident. When reviewing your network infrastructure, don't forget about that most arcane of networking technologies, the

    Requires Free Membership to View

Domain Name System (DNS). 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. Now that would be a scary Halloween!

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.

More on this topic

Browse admin tips

DNS security

How DNS works

Expert Cricket Liu: Integration of Internet protocols; A critical year for the IETF

Browse network security tips

In the interest of keeping this a safe Halloween, 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.2, or even 9.3.
  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.

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.

This was first published in October 2005

There are Comments. Add yours.

TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.