10 things to secure your DNS server

10 things to secure your DNS server

The method, and misconfiguration issue behind the Spamhaus DNS attack is not new, nor should we be dealing with it at this point in time. There have been many previous such attacks, and many reports on how to remediate against such types of attacks, yet here we are...

There is a multitude of free and/or Open Source DNS Server implementations available on the Internet.  The two most significant of which are BIND, which serves most of the Internet, including the worlds largest Governments and Companies, and Microsoft DNS, which also has a large installed base in the Corporate Intranet world.   Any and all of these are capable of contributing to an extensive Distributed Denial of Service attack if not properly configured and secured.

What problems can a misconfigured  DNS server have? 
The most prevalent DNS issue is around "Open Resolvers", where a DNS server on the Internet is configured to allow recursive DNS resolution outside of the Domains for which it provides Authority.  This can lead to the types of recursive amplification DDOS attacks that impacted Spamhaus.

Cache Poisoning is another type of Denial of Service attack against , where the attacker attempts to flood a caching DNS server with fake requests, to slow down it's services. While doing this, the attacker simultaneously spoofs the authoritative DNS response for the domain they want to attack, in the hope that their spoofed request will get to the DNS Cache quicker than the true one.  Once spoofed, all traffic to that domain will be redirected to the new injected address. 

"we estimate that there are as many as 11,920,500 open resolvers on the Internet.

The total number of open resolvers on the Internet appears to be decreasing with time, but it is still quite high. We urge developers and manufacturers to read and implement RFC 5625, DNS Proxy Implementation Guidelines.[4] Administrators should read and implement RFC 5358, Preventing Use of Recursive Nameservers in Reflector Attacks.[5] "

10 things to secure your DNS server

1.            Implement Firewall rules for DNS Security- Your firewalls should only allow DNS query traffic on UDP/TCP port 53.  Additionally, it should only accept zone transfer requests from known DNS systems. (see item 7)

2.             Registered Black Lists.  Subscribe to - and block addresses from - these maintained lists of known malicious IP addresses. This can be done either by the firewall or on the DNS server itself.

3.            Segregate Internal and External DNS Servers - Keep your Internal DNS and associated private IP space inside of your firewall.  Use a DNS Proxy for DNS queries to the Internet. Do not advertise your private IP space at all on your External DNS servers. (See item 6) 

4.            Close Open Resolvers   on your External (Internet facing) DNS server. (for BIND) (for Microsoft)  There is no reason for your  Internet facing DNS to be recursive.    Internal DNS should be configured to allow recursion to Internal addresses only.  http://dns.measurement-factory.com/surveys/openresolvers.html

5.            Keep DNS Server Version Up to date and patched - Maintain regular patching on your DNS server. Any vulnerability that is discovered in the DNS software will quickly be exploited.

6.            Disable version banner - Service banners are a sure way to advertise what vulnerabilities your system may have. Turn them off.

7.            Restrict zone transfers - Only allow KNOWN DNS servers to request a Zone Transfer.  In BIND, you can restrict zone transfers using either (or both!) DNS Access Control Lists or TSIG - transaction Signatures. Here's how Microsoft recommends such restriction. 

8.            Configure Rate Limiting - Rate limiting is a relatively new feature in most DNS systems, but allows you to control DNS traffic flow so as to not get into a Denial of Service position.

9.            Do not Run DNS service as "root" or "Administrator" - Run the service under it's own non-privileged account.

10.          Run BIND in a chroot jail. - This separates the DNS process and it's associated file systems and access from the rest of the Operating System it is running upon.   If DNS *does* get compromised, they will not be able to escalate privileges to the rest of the server.