DNS "spoofing" and "poisoning". Simply the name conjures up the kind of thoughts that keep network admins up at night. What if my RNDC key gets leaked? Could there be a rogue DHCP server within my perimeter? Are the Lizard Squad planning an attack on for Christmas?
Much of what we know now about DNS, address protocol, and packet priority is being redefined with the recent 'Net Neutrality' legislation. Instead of becoming a party to the hoopla that is partisan politics surrounding THAT issue, let me assure you there are many different mitigation strategies for not only securing your own network against DNS poisoning, but also working towards a harmonious kum-by-ah solution that in the end, may end up resolving (pun intended) the DNS plight. So, let's silence the alerting system, and get down to what DNS poisoning is, why it's still around, and one of the best ways to solve it.
Why is DNS Cache Poisoning Possible?
The first thing to understand about DNS 'poisoning' is that the purveyors of the Internet were very much aware of the problem. Essentially, DNS requests are "cached", or stored, into a database which can be queried in almost real-time to point names like 'hotmail.com' or 'google.com' to their appropriate IP addresses. Can you imagine having to remember a string of numbers instead of a fancy name to get to your desired WWW (or GOPHER - if that's your thing) resources? 321.652.77.133 or 266.844.11.66 or even 822.214.171.124 would be very hard to remember. [Note: I have obfuscated REAL IP addresses with very fake ones here. Always trying to stay one step ahead of the AI Armageddon. Real IP addresses end with the numerical value of '255' within each octet.]
No, remembering strings of numbers would be next to impossible. But thankfully, and all because of Al Gore (sarcasm) we have the DNS mechanism that gives us [relatively] easy names to remember how to get to our favorite resources.
DNS basically runs the Internet. Without it, only the most uber-geeky of computer scientists would be able to traverse it. Strings of numbers are just simply not how humans identify information. They help, but in reality, words and language are what separate us from our impending robotic overlords.
It's because of this, that as the Internet began to grow, the DNS (Domain Name System) was created. To help us get from one side of the world to the other, with little angst. However, due to the limitations of computing (especially storage and bandwidth) at the time, the early versions of DNS simply used a "distributed" text file for name resolution. Think "blockchain" for EVERY SINGLE HOST that existed on the 'Net back then. It was a nicer and friendlier place, and that system worked well. Until it didn't, and some nice folks at ARIN and ICANN came along and began the system we use today: DNS.
In its simplest explanation, DNS takes a name (e.g. yahoo.com) and looks at the locally configured 'Nameservers' for the "answer" to the question: 'What is the IP address of yahoo.com?'. Once an answer is found, it is passed back to the client requesting it, and the routing and magic of the TCP protocol kicks into gear, and the peasants rejoice. Except there are sometimes problems that arise that cause the peasants to NOT rejoice, and for network engineers to curse the vile notion of DNS. You see, since DNS arose during a time where "real-time" anything was not technically possible; to aid performance and allow for USABLE networks, DNS answers were logged into a locally stored 'cache' or database on the DNS server which issues the query. That's all fine and good when the 'Netizens were nice and jolly folks, but it didn't take long for the Web to evolve and, well, sometimes DNS cache can be the weakest point of your network.
We have seen quite a few vulnerabilities of the DNS protocol exploited over the years, the most primitive being the HOSTS file. This is *not* an article detailing the mitigation of a HOSTS file attack. It's been the "standard" strategy for solving DNS issues for entirely too long, and plenty of information on how to eliminate this type of "attack" is already available.
This has more to do with the re-thinking of the way networks are architected. Both in your home, and in your business. Whether it's a 2-bedroom apartment you share with your family, or a 50,000 employee enterprise - some of the holes within DNS can, (and have) caused not only loss of revenue, but the loss of sanity or in extreme cases - liberties. Without getting too "truther" on you, let's just acknowledge the fact that with a "targeted attack" vector like DNS cache poisoning, it becomes VERY difficult to validate almost anything. Unless your idea of a fun time on a Tuesday evening is analyzing 'dig' reports and looking at PCAPS, let's look at how a few simple design decisions can save you some headaches and maybe protect your own network before it goes out to the nastiness that can be the World Wide Web.
Essentially, all a DNS spoofing attack needs is a target. This can be an ‘Authoritative Name Server' (easily obtained by doing a domain WHOIS on any domain on the Internet) and a weak point on the system hosting that DNS cache. Without too much effort, someone can adjust the cache of that DNS server, and begin pointing traffic from 'yahoo.com' (or any other desired host) to anywhere else on the internet (or even more devious, the local LAN). The main problem with this is that using the ubiquity of DNS to provide 'spoofed' or 'hijacked' answers can lead to a plethora of: phishing attacks, SPAM, password leaks, social engineering attacks, political upheaval, and so on. It has the potential to ruin not only the desired target's day, but almost anyone else in that path as well. The good news? Even with these flaws being well-known there are some things a savvy network and/or systems architect or engineer can do to make those peasants remain in a constant state of "rejoice" instead of "revolt".
The first step: filter your DNS servers
Now, what does that mean? "Filter”? Well, in the most basic sense, DO NOT allow your DNS server to answer on the Internet over port 53. This is rule #1. Simply do not let your DNS servers answer Internet DNS queries. Unless you are running an ACTUAL name server, registered with ICANN, and control your own reverse zone (maybe less than 10% of the Internet hosts in the world fit this criteria) - just don't do it.
Trust ne. Now that you're not answering DNS requests, your exposure is much more limited. However, the localized attack vector is not completely eliminated. This is where you really need to evaluate your needs for DNS, and consider using somethings like RNDC encryption, stub zones, and decreasing the TTL values on your local DNS server(s). There are commercial products that will do this for you. Infoblox is solid, for example. There are dozens of "DNS/DHCP Security" suites that make this task MUCH easier. But they are expensive, and not every person will be able to justify their cost. But there's even more you can do!
This is an example of an Infoblox protected network. Notice the additional protections you’re able to add to your users by implementing a DNS security suite. But the cost isn’t the only barrier; keep reading to make sure you have considered the practical design principles with your DNS infrastructure
Check if Authoritative Name Server matches what is locally resolved
The basic principle behind these attacks is that DNS queries have little to no "check" mechanism. In the early days of the Internet, many requests required a valid check of the PTR (or 'reverse') records in order for the traffic to flow. SMTP servers can still use this, but it is becoming a rarity. Interestingly enough, IRC still does. The benefit of this "check" is that if the 'authoritative' name server provides an answer different from what is locally resolved, the DNS packet is marked as invalid. It's been "spoofed" and thankfully, most TCP/IP stacks will see this and not handle that traffic. It's not the best solution for a poisoned DNS cache, but it does help. Too bad it's not standard operating procedure with HTTP requests. Not yet at least.
In closing, this is an issue that could take literally hundreds of pages of boring text to fully explain and resolve. So in lieu of that I will provide just a Checklist that any savvy sysadmin or engineer can consider to help protect their DNS infrastructure and keep their overall network health in much better shape. If enough people begin to follow some of these ideals, the DNS poisoning attack will begin to lose its power. And trust me, nowadays; it has a lot of power...
- Set up and maintain your own DNS servers. It's really not that hard. even for a small network. BIND or Windows DNS can be configured (securely and properly) in less than 30minutes. It's MUCH better than the option of "hosted" DNS.
- Don't answer DNS requests over the WAN on port 53 (or any other port for that matter)
- If you MUST answer on port 53, use RNDC keys. Revolve them often.
- Set your TTL's to a low value. I like 15 minutes. Something that doesn't sacrifice your network performance. This way, if a cache poison DOES hot you, it's only going to be a "problem" for a short duration of time
- DISABLE 'HOSTS' FILE RESOLUTION ON YOUR CLIENTS AND SERVERS!!!
- Create and properly maintain your PTR zones. Even for local domains It's tedious, and boring, but VERY important. Especially for SMTP traffic.
- Consider using STUB zones for commonly accessed domains, or domains that could easily be compromised.
- Use DNS forwarders ONLY to verified DNS servers. Too many people simply forward to the 'Root Servers' and this is not ideal. Many of them don't answer, and with a localized routing table attack, you can end up creating your own poisoned cache. Just don't do it. Talk to your ISP and use their servers. Also, spot-check them frequently using 'dig'.
- Block DHCP on your firewall except from your one and only DHCP server on your network. If a "rogue" DHCP server is allowed to permeate on your network, you lose *all* control of your DNS and DHCP security. Not to mention, tracking down a "rogue" DHCP server is time consuming and frustrating.
- Learn how DNS works. Learn more than at the surface-level (which I've covered a bit here), but at its core-level as well. Once you do, you can see how some of the inherit flaws can be 'stopped' within your own network structure.
- Cluster your DNS resources. Many of our present issues with DNS came from a time when computing resources were incredibly finite, and performance was very poor. This is not much the case any longer. Shorter TTL's will increase your database I/O but not so much that many of your users will notice. Do your own testing. You will likely be a bit surprised that having more 'close to real-time' results doesn't really impact your latency or I/O on your DNS infrastructure.
There are MANY different protocols that make up the Internet. DNS is one of those that is critical to the proper functioning and core values of our "always-connected" world. Providing a clearer landscape with better network practices is an ideal any technical professional should embrace. Do not become the "lazy admin" that costs your family or your business with the results of a DNS poisoning attack. As always, feel free to reach me. You can find me at @acuralegend on Twitter or via email: email@example.com.