DNS Poisoning Attacks: A Guide for Website Admins

How to protect your
website against DNS cache poisoning attacks

There are literally hundreds of exploits
and several million viruses that could penetrate your network defenses. Going
after them all is a full-time job. Fortunately, that job is handled by experts
whose only purpose is cyber security and technology that’s designed to detect
and root out troublemakers.

One of the most odious and difficult to
detect is DNS poisoning, also known
as DNS spoofing, DNS hijacking, DNS cache poisoning, or DNS redirection.

What is this digital ailment, and what can you do to protect your networks?

Let’s hash it out.

What is DNS Poisoning?

How DNS works

Domain name systems are the equivalent of the internet’s phone directory. Every website has a unique domain name that’s used to identify its location on the internet. A domain name server (DNS) attack is a cybercrime that probes these servers looking for weaknesses to exploit. Once in, they can change coding or other information.

Simply put, a DNS poisoning attack
compromises DNS servers so visitors who try to go to a website are secretly
routed to the wrong IP address behind the scenes. The user may type “google.com”
into their browser, but they’re actually routed to a server run by a hacker.

The
main symptom of a DNS poisoning attack is a sudden, unexplained drop in web
traffic. Though web traffic is always volatile, if you see a sudden reduction
in the number of visitors to your site, it’s always worth investigating why.
You can sometimes spot a DNS poisoning attack by pretending to be a customer:
borrow a friend’s computer, or use a VPN to change your location, and try to
access your site. If you’re re-directed to a site you don’t recognize, the
chances are good that your DNS cache has been compromised.

How a DNS Exploit Endangers Your
Website

Unlike a Direct Denial of Service (DDoS) attack, which overloads your server by sending an avalanche of requests, DNS spoofing discreetly draws traffic away from your website. Once individuals have been lured to the fake website, all kinds of malfeasance can occur

DNS exploits can spread from server to server, impacting more and more users. This is because of the way that IP addresses and domain name systems work. Domain names are readable only to humans. When a URL is typed into the address bar on your browser, it sends a request to a server, which returns a numeric IP address that can be read by the computer. Many times, it returns more than one IP address.

Because internet service providers handle
millions of requests and IP addresses, they’re all stored in the same cache
until the request can be routed to the proper location. In addition to the
server and ISP you use to access the internet, your router acts as a type of
DNS server that caches the information from the servers connected to your ISP.

That’s a lot of potential attack surfaces and points of entry to protect. In theory, the only sure way to stop the cycle of poisoning is for every cache attached to the DNS, ISPs, and personal or business routers to be cleared simultaneously. In practice, the most likely fix is for the DNS server most upstream with the corrupt record to be fixed and then trickle the correct data down to the rest.

A recent example of the impact these exploits can have is last year’s attack on MyEtherWallet servers. This crime involved hijacking the crypto company’s domain and redirecting account holders to a phishing website, where they were tricked into revealing their wallet security keys and transferring the money in their accounts to the hacker’s wallet. The attacker was able to make away with $160,000 in Ethereum cryptocurrency before the breach was discovered.

What makes these exploits so hard to
detect is that they occur on the user side. Account holders have no idea that
the domain has been hijacked and they’re being redirected to a fictitious
website. They’re just going through their normal routine. The website owners
won’t notice either until they discover a problem with their metrics.

Preventing DNS Poisoning Attacks

On Feb. 1 of each year, various DNS software developers host a DNS Flag Day symposium to address security issues and create compliance metrics to shore up problems with servers. However, they haven’t been able to do enough to keep up with new or revamped attacks.

Preventing DNS attacks is important for two groups: users who want to avoid being spoofed, and sysadmins who want to protect their own site from this kind of attack. In this section, we’ll give you methods for avoiding DNS cache poisoning from both perspectives.

Certificate Management Checklist

Manage Digital Certificates like a Boss

14 Certificate Management Best Practices to keep your organization running, secure and fully-compliant.

Preventing DNS Cache Poisoning as
a System Administrator

Let’s
look at the website administration side first. Since it’s often so hard for
website owners and administrators to detect DNS poisoning until after a lot of
damage is done, and exploits can be spread to every associated DNS once
launched, prevention is the best cure.

Choose Your Platform Wisely

The first place to start in preventing DNS poisoning is by choosing a secure hosting platform and content management system. If you don’t have the budget for a dedicated server, make sure that the hosting plan you choose has the most current encryption standards, DNS leak protection, SSL authentication, and a comprehensive back and restoration system. If you’re using WordPress as a CMS, follow basic security procedures like two-factor authentication (2FA) and regular software updates.

Keep Your DNS Servers Up to Date

In
addition to choosing the right hosting platform for your security needs, you
need to keep your DNS server updated. Regardless of whether you’re running
Bind, MicrosoftDNS, or another server, the latest version is always going to
have security patches and fixes installed as well as security standards like
HSTS, DNSSec and Response Rate Limiting (RRL) to repel DNS attacks.

Use
DNSSEC

Probably the single most important thing you can do to protect against DNS poisoning is to use DNSSec, which is critical for avoiding DNS cache poisoning. The standard has been strengthened in recent years with features specifically designed to prevent this kind of attack. It will verify the root domain (referred to as “signing the root”) whenever an end user attempts to access a site.

Audit Your Zones

Many private DNS servers are loaded with old test domains and subdomains that are out of sight and mind. These are ripe for exploitation. You can monitor all zones, including hidden or forgotten ones, as well as all IPs and records using a tool like Security Trails. These types of tools allow you to catch possible vulnerabilities and prevent attacks before they happen.

Consider Forcing HTTPS

With HSTS, you can force browsers to
always load your website on HTTPS. This helps you avoid DNS cache poisoning in
one key way: a hacker who creates a fake version of your website is unlikely to
be able to get a trusted SSL/TLS certificate for your domain. This means that
when visitors are directed to the hacker’s fake version of your website,
they’ll get a big security warning in their browser.

Preventing DNS Cache Poisoning as
a User

Users should also be aware of the dangers of DNS redirects, since this type of attack can fool you into entering sensitive details into fake websites. Here are a couple of ways you can avoid that:

Mask Your Bind Version

Hackers usually keep track of common flaws in various generations of commonly used platforms. They then use this information to break into networks or platforms that are using a particular version. By hiding software versions, you can make things just a little harder for hackers to perform DNS poisoning. If you’re using the popular Linux-based DNS service, Bind, masking your Bind version is a good idea.

If Bind is your DNS software, all that’s
required for a hacker to get your version number is to perform a remote query
using this code: dig @ns1.server.com -c
CH -t txt version.bind

That would return an answer like this if
the Bind version is not hidden:

ANSWER SECTION:VERSION.BIND. 0 CH TXT "named 9.8.2...

To hide this information, go into your /etc/named.conf file and find the
configuration block options { … }.
This leads you to a line that says version
“BIND”;
.

Change that line to say version “Forbidden”;, and
then save and close the file. You’ll have to restart Bind to apply the changes.

Check the Browser

One fast way to know if your DNS has been hijacked is to look for your business name in the certificate details displayed by the browser. The ability to see the company name in the address bar is an indication that the website is authenticated by an EV SSL/TLS certificate. Not all websites have an extended validation (EV) certificate, but the presence of the company name in the browser lets you know that it’s safe to proceed.

Final Thoughts

Your domain name is how your brand is identified on the internet. Protecting it from DNS poisoning attacks should be of the highest priority. Our goal is to provide you with actionable solutions that keep you from becoming the next cybercrime statistic and potentially costing your site its reputation.


*** This is a Security Bloggers Network syndicated blog from Hashed Out by The SSL Store™ authored by Gary Stevens. Read the original post at: https://www.thesslstore.com/blog/dns-poisoning-attacks-a-guide-for-website-admins/