How to Fix and Prevent DNS Spoofing and DNS Poisoning in your Computer

Let me ask; what exactly is Domain Name System (DNS) “spoofing” and “poisoning”? In simple explanation, the name came up with the kind of thoughts that keep network admins awake throughout a night. On a second thought, what if your Remote Name Daemon Control (RNDC key) gets leaked out? What will you do? It could be that there is a rogue DHCP server within your admin perimeter. Is someone planning an attack on your server?

If you ask me, a lot of what everyone now know about DNS, address protocol, and packet priority is being updated with the recent ‘Net Neutrality’ legislation. But instead of becoming so scared, let me assure you there are several prevention measures and/or strategies you can follow.

These measures will go a long way to secure your own network against DNS poisoning. Furthermore, it will also work towards resolving (pun intended) the dreadful DNS “wahala”. Without talking much, let’s switch off the the sounding alarm system, and begin step b step explanation of what DNS poisoning is, why it’s still troubling tech admins, and some of the best steps to resolve it permanently. Take a look at DNS Cache Poisoning Detection & Attacks Prevention guide.

What is DNS poisoning/spoofing?

Domain name system (DNS) cache poisoning, popularly known as DNS spoofing, is a computer hacking technique whereby traffic is maliciously diverted to a victim’s computer device through a corrupted cached data/files.

Now, to the explanation. The very first thing you have to understand about the DNS ‘poisoning’ is that the developers of the Internet knew about this problem. Basically, DNS requests are “cached”, or stored, into a database which can be queried in almost real-time to point names like ‘aol.com’ or ‘google.com’ to their original 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? 315.459.66.731 or 461.545.11.42 or even 367.23.0.6 would be very hard to remember.

[Notice: I changed REAL IP addresses with very ordinary numbers. Always trying to stay one step ahead of the AI Armageddon. Real IP addresses end with the numerical value of ‘255’ within each octet.]

Where does DNS Run?

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.

Where did DNS begin and what does it do?

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.

Vulnerabilities of the DNS protocol

Over the years, 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.

What is a DNS spoofing attack?

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 to prevent a DNS attack: 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.

Conclusion

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…

How to Prevent DNS Spoofing Attack on your computer

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. It is much more connected to the following;

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

Do this immediately 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 so you can prevent attacks.

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.

Provide a clearer landscape with better network practices

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 for that this is a Free Guide to DNS Spoofing Attacks. Don’t be the “lazy tech admin” that costs your family or your business with the results of a DNS poisoning attack. As always, for folks looking for updates on DNS Cache Poisoning & Spoofing, feel free to reach me for more guide.

- Advertisement -