Note: I wrote this in 2013, and it's still as relevant to DDOS discussions today as it was then.
In light of the recent Spamhaus DNS "the Internet is falling!" FUD , I thought I would write an article on the 10 best things you can do to secure your DNS Infrastructure.
(Plain English explanation of the Spamhaus DDOS attack)
What is DNS? - Go ! Read! I'm not going to explain it here!
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.
 |
| http://dns.measurement-factory.com/surveys/201010/ Distribution of name server software versions |
"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
- 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)
- 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.
- 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)
- 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
- 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.
- Disable version banner - Service banners are a sure way to advertise what vulnerabilities your system may have. Turn them off.
- 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.
- 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.
- Do not Run DNS service as "root" or "Administrator" - Run the service under it's own non-privileged account.
- 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.
NOTE: I understand that I've not brought up DNSSEC. I'll save that for a future discussion on it's own.
Resources:
http://www.ietf.org/rfc/rfc1035.txt -- DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION
http://www.ietf.org/rfc/rfc5358.txt -- Preventing Use of Recursive Nameservers in Reflector Attacks
http://www.ietf.org/rfc/rfc1918.txt -- Address Allocation for Private Internets
http://www.ietf.org/rfc/rfc5625.txt -- DNS Proxy Implementation Guidelines
http://www.ietf.org/rfc/rfc2845.txt -- Secret Key Transaction Authentication for DNS (TSIG)
http://www.zytrax.com/books/dns/ch4/
http://dns.measurement-factory.com/surveys/sum1.html
The Continuing Denial of Service Threat Posed by DNS Recursion (v2.0)
http://en.wikipedia.org/wiki/Paul_Mockapetris
http://en.wikipedia.org/wiki/Jon_Postel
http://en.wikipedia.org/wiki/Internet_Assigned_Numbers_Authority
http://en.wikipedia.org/wiki/Comparison_of_DNS_server_software
http://blog.isc2.org/isc2_blog/2008/08/securing-dns-se.html
NIST: How to Secure a Domain Name Server (DNS)
www.cert.org/archive/pdf/dns.pdf - Cricket Liu
http://spi.unob.cz/old/last/ostatni/proceed2001.pdf#page=70
http://www.prolexic.com/gad/2012-q4-attack-report.html
http://blog.cloudflare.com/the-ddos-that-almost-broke-the-internet
http://www.redbarn.org/dns/ratelimits
http://www.cisco.com/web/about/security/intelligence/dns-bcp.html
http://www.sans.org/reading_room/whitepapers/dns/securing-dns-zone-transfer_868
http://www.zytrax.com/books/dns/ch7/xfer.html
No comments:
Post a Comment