Preventing DNS Amplification Attacks
Posted by Kevin Stange, Last modified by Ben Galliart on 14 February 2014 06:20 PM
In March 2013, the Open DNS Resolver Project identified many IP addresses on our network that were of moderate to severe risk of participating in a DNS amplification attack. This attack queries name servers for large results using a fake source address. This request causes the response to go back to the faked address, resulting in a large amount of data being sent to a computer that did not request it. This effect, when used with thousands of DNS servers, directs a very large amount of traffic to a single IP to form an efficient distributed attack. The anti-spam organization Spamhaus was recently the victim of an attack that may have been as large as 300 Gbps using this technique.
This attack can be performed easily using a server you control without compromising its security, and could result in heavy outbound bandwidth usage. This may impact performance of your services and cause unexpected bandwidth overage bills.
The most common environment we have found with a problem is a CentOS 5.x server running BIND with default settings. The default BIND version for CentOS 5.x causes a moderate risk. A severe risk occurs if any DNS server is configured to act as a public DNS resolver. A public resolver is a server that allows anyone to query it for the DNS records of a domain it does not directly host.
You can confirm your server is affected by querying the server from a Linux or Mac command line on a separate computer:
A version of the "dig" command for Windows can be downloaded from here.
If the resulting status is NOERROR, your server allows queries that it should not. If the information contains AUTHORITY results but does not containANSWER results, it is a moderate risk. If it contains any ANSWER results, then the risk is severe. Other statuses, such as REFUSED, NXDOMAIN, SERVFAIL, or a timeout error message, do not indicate an issue.
To mitigate a moderate risk, the best option is to install the CentOS 5.x bind97 package. In a cPanel/WHM environment, upgrading to bind97 can be accomplished with the following commands:
In a non-cPanel environment, you can perform similar steps, but you will likely need to rebuild the /etc/named.conf file from the /etc/named.conf.rpmsave.
Another option that can be used to mitigate the moderate risk level is to upgrade your server from CentOS 5.x to CentOS 6.x. This upgrade enables you to access other new and improved software and may improve server performance. However, doing this usually requires reinstalling your operating system and restoring data from backups.
To mitigate a severe risk, you must reconfigure your name server manually. Recursive resolver behavior is not the default, which means that a configuration change was made to enable recursion on your server.
For advice on how to adjust a server to prevent public recursion or limit the IP ranges that can use recursion, or any other questions about the topics discussed in this article, please visit our Help Desk or email us. BIND consulting is covered under managed services.