8 tips to prevent DNS attacks

The DNS is the heart and soul of the internet. It's like a giant phonebook that your computer uses to map hostnames to IP addresses in order to interact with public services such as websites.

At SecurityTrails we work a lot analyzing DNS servers, DNS zones, domains and IP addresses, and as we have seen in past blog posts, those technologies can reveal a lot of potentially useful information on any infosec investigation.

Today we will show you how to protect against common DNS attacks using general best practices. Follow these tips to keep your company protected against Domain Name System based attacks and information disclosure.

How do hackers attack the DNS infrastructure?

The DNS service is one of the most popular Internet services, and at the same time, it is the one that SysAdmins, DevOps, and Network Administrator often forget to harden.

They often focus on other popular services like database systems, SSH services, or the web servers.

DNS server configurations that lack proper security hardening can sometimes lead to really serious problems, as attackers can exploit the system to perform things like transferring DNS zones, modify DNS resolvers to report different IP addresses to scam people, redirect web and email traffic, or launch dangerous DNS amplifying attacks, among other types of attacks.

When this kind of thing happens, website visitors don't have a way to detect their traffic has been redirected to another server, or that their email was sent to a different server than the original MX servers from the attacked domain. That's why it's so important to always keep your DNS servers secured.

Follow us on Twitter to receive updates!

How can I prevent DNS attacks?

Let's start with eight key tips to harden your DNS services:

1. Audit your DNS zones

First things first. The most important thing you'll have to review apart from the DNS server main configuration is your DNS zone.

As time passes, we tend to forget about test domain names or subdomains that sometimes run outdated software or unrestricted areas vulnerable to attack, or if an A record is showing an internal/reserved intranet area by mistake.

Start exploring all your DNS public records using SecurityTrails: review all your zones, records and IPs. Audit your A, CNAME and MX records today. It's easy, as we've seen in past blog posts, like when we explored Google DNS or Microsoft subdomains.

2. Keep your DNS servers up-to-date

Running your own Name Servers gives you the ability to configure, test and try things that you may not be able to on private DNS servers like the ones your hosting provider gives you, or when you sign up for an account at Cloudflare.

When you decide to run your own DNS servers, probably using software like BIND, PowerDNS, NSD, or Microsoft DNS, and as the rest of the operating system software, it's crucial to keep these packages up-to-date in order to prevent service exploits targeting bugs and vulnerabilities.

Latest versions of all popular DNS servers include patches against known vulnerabilities, as well as support for security technologies like DNSSec and RRL (Response Rate Limiting) that are pretty useful in preventing DNS reflection attacks.

How can I update my bind server?

On RHEL based distros you can update Bind by running:

yum update bind -y

On Ubuntu and Debian based distros:

apt-get update bind9 bind9-host

Restart the service to apply the changes:

service named restart

or

service bind9 restart

3. Hide BIND version

While some people can't consider this as a security practice, security through obscurity is just another way to hide information from attackers when they are performing their initial security audit against your server.

In this case, if you are running Bind, for example, an attacker could easily get your DNS server version by running a remote query like this:

dig @ns1.server.com -c CH -t txt version.bind

If the server is not hiding the version number, it should return something like:

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

How can I hide the BIND version?

Edit your named.conf file, usually located at /etc/named.conf

Locate the options { … }; configuration block. At the end of this block, you will find a version variable (if not, add one):

version "BIND";

To hide your bind version just set this to something else, like:

version "Forbidden";

Save and close the configuration file.

Restart BIND to apply the changes:

service named restart

or

service bind9 restart

4. Restrict Zone Transfers

A DNS zone transfer is just a copy of the DNS zone, and while this technique is often used by slave name servers to query master DNS servers, sometimes attackers can try to perform a DNS zone transfer in order to have a better understanding of your network topology.

One of the things that can be done to prevent these kinds of tricks is to restrict which DNS servers are allowed to perform a zone transfer, or at least limit the allowed IP addresses that can make such requests.

That's why limiting zone transfers are one of the best ways to protect your precious DNS zone information. The best way to prevent this is by using an ACL, as we are going to see below.

How can I restrict DNS zone transfer to specific IP addresses?

First, let's edit BIND main configuration file again. Once open, let's add this new configuration block:

acl trusted-servers {  
173.88.21.10; // ns1  
184.144.221.82; // ns2  
};

Now search for your domain DNS zone configuration in the same file.

In the DNS zone configuration block for our domain name (securitytrails.com for us) we will add "allow-transfer" variable, along with the trusted-servers ACL we created before:

zone securitytrails.com {  
type master; file "zones/securitytrails.com";  
allow-transfer { trusted-servers; };  
};  

Restart BIND to apply changes:

service named restart

or

service bind9 restart

Testing your DNS zone transfer

Dig, host, and nslookup tools are your best friends when it comes to testing any DNS response from remote servers. Let's use host command to test if the DNS zone transfer is denied, or allowed.

host -T axfr securitytrails.com

If the zone transfer is denied, you should see something like:

Connection to 12.34.56.78#53(12.34.56.78) for axfr failed: connection refused.

5. Disable DNS recursion to prevent DNS poisoning attacks

DNS recursion is enabled by default on most Bind servers on all major Linux distributions, and this can lead to serious security issues, like DNS poisoning attacks, among others.

When DNS recursion is enabled on your server configuration, the DNS server allows recursive queries for other domains that are actually not real master zones located on the same name server, this simply allows third-party hosts to query the name servers as they want.

This setting can also increase your exposure to DNS amplification attacks, that's why you should always disable DNS recursion on your DNS servers if your plan is not to receive recursive DNS queries.

How do DNS poisoning attacks work?

Also known as DNS cache pollution, DNS cache poisoning is one of the most common DNS attacks, it happens when a spoofing attack happens in the middle, providing information to a DNS server that wasn't the one from authoritative DNS sources.

This will allow the attacker to send altered information in response to a specific DNS query. The result will probably be traffic redirection from one host to another, for example, www.securitytrails.com would be redirected to www.microsoft.com.

Test if your server is vulnerable to DNS recursion attacks

Let's use the host command to find out if your DNS server has DNS recursion enabled or not, see the examples below:

\[webtech@localhost ~\]$ host securitytrails.com. 8.8.8.8  
Using domain server:  
Name: 8.8.8.8  
Address: 8.8.8.8#53  
Aliases:  
securitytrails.com has address 151.139.243.5  
securitytrails.com mail is handled by 1 aspmx.l.google.com.  
securitytrails.com mail is handled by 5 alt1.aspmx.l.google.com.  
securitytrails.com mail is handled by 5 alt2.aspmx.l.google.com.  
securitytrails.com mail is handled by 10 aspmx2.googlemail.com.  
securitytrails.com mail is handled by 10 aspmx3.googlemail.com.

The DNS recursion is enabled in this case, as we were able to get the answer from the remote DNS server. Now let's do it again, replace ns1.google.com with your real Name Server.

\[webtech@localhost ~\]$ host securitytrails.com. ns1.google.com  
Using domain server:  
Name: ns1.google.com  
Address: 216.239.32.10#53  
Aliases:  
Host securitytrails.com not found: 5(REFUSED)  
\[webtech@localhost ~\]$

If you see "REFUSED", then DNS recursion was disabled on the DNS server configuration.

How can I disable DNS recursion?

In order to disable recursive queries, you will have to alter your bind configuration by adding these lines inside the options configuration block at named.conf file:

allow-transfer {“none”;};  
allow-recursion {“none”;};  
recursion no;

This will also take care of the DNS transfer we saw previously.

Restart BIND to apply changes and test your server again:

service named restart

or

service bind9 restart

An alternative approach to protecting your DNS server against cache poisoning is to enable DNSSEC, a solid security extension for the traditional DNS protocol that works by using security signatures in order to ensure the query response we receive is authenticated on the real origin server.

6. Use isolated DNS servers

Running your own DNS server is possible using a dedicated server or cloud where you host the rest of the web services like an application server, HTTP server or database server.

This is a common practice among small companies who often store all their server services in a single cPanel or Plesk box.

If you decide to put all your eggs in one basket, you must ensure that this box has a pretty solid server hardening for each daemon you are running, as well as for the applications running inside of the operating system.

Although the best you can do is to use your own dedicated DNS server environment, it doesn't matter if it is based on Cloud or Dedicated servers as long as it is 100% dedicated to DNS services only.

Having this DNS server isolated from the rest of your application servers will help to reduce the chance of getting hit by web application attacks.

Close all unneeded server ports, stop unwanted OS services, filter your traffic using a firewall, and only allow basic services such as SSH and the DNS server itself. This will help a lot to mitigate the chances of a DNS attack.

7. Use a DDOS mitigation provider

While small and midsize DOS and DDOS can be mitigated by tweaking network filters, HTTP services, and kernel response from the operating system, when a big DDOS comes after you, only a few Data Centers will be able to help their customers with a real anti-DDOS service.

If you run your own DNS servers and you are under massive DDOS attack, your usage in terms of bandwidth usage or packets per second will probably cause you a big downtime, if your service provider doesn't apply a null route to your IP addresses first.

That's why the best thing you can do is to hire an anti-DDOS specialized service like Cloudflare, Incapsula or Akamai to mitigate DDOS in the best possible way and keep your DNS servers secure and responding well at all times.

8. Two-Factor Authentication

If you are not running your own DNS servers and decide to use a third party DNS managed service like Cloudflare DNS or DNSMadeEasy, you can be sure their servers are pretty well secured.

However, none (not even their CEO) is safe from getting an account compromise, but the probabilities are very low, to be honest.

And, even in the worst case, an attacker can gain access to your username and password, but you can still have your account under control if you are using a two-factor authentication.

That's our final advise in order to avoid a DNS zone compromise: set up a two-factor authentication protection on your DNS server provider, if possible avoid phone call or SMS verification, and use Google Authenticator instead — that is way more secure.

Conclusion

Hackers will always try to target your public company services, researching to find weaknesses inside your Domain Name System. Having a solid DNS hardening policy will help to mitigate most of the attacks described above.

Start auditing your DNS zones today using SecurityTrails as the first step in order to secure your DNS servers, collect information, and try to reduce your DNS public information as much as possible.

---

If you manage a lot of domain names and DNS zones, you can also automate any DNS investigation by integrating our intelligent cybersecurity platform with your own apps with our powerful API. Grab your free API account today.