- A single end point – commonly a compromised computer commandeered and participating in a botnet. The botnet malware generates a simple DNS request for ANY record for isc.org (the first Amplification Attack domain used).
- The malware spoofs the IP address in the request to be that of the target victim.
- The pack is sent to a known open cache resolver.
- The outbound packet is approximately 50 bytes (the actual size is 64 bytes).
- The packet hits the open cache resolver and that server responds with a response packet that is much larger – for sake of ease in calculations, we will go with 3000 bytes (the actual size in 3223 bytes).
- We can calculate the amplification factor as follows: Bytes Out Per Request / Bytes In Per Request = Amplification Factor. In this case, 3000 bytes / 50 bytes = 60x amplification
100 kbps x 10,000 end points x 60 (amplification factor) x .000001 Gbps/kbps = 60 GbpsAs you can see, it really does not take much in the way of commandeered resources to mount a vicious and unstoppable DDoS attack against a target. Attacks of this type have been seen generating close to 500 Gbps of traffic directed at the target. Consider also that each botnet member is likely sending these DNS requests to an array of several hundred thousand open caching resolvers. According to the Open Resolver Project, there are more than 11.6 million publicly accessible resolvers on the Internet at the time of this writing. While the total number of these resolvers has declined over the past few years, that decline has done little to mitigate the problem. These botnets can target a single IP target or a group of IPs. They can use multiple domains in the attack and can be used to target an entire organization or nation-state on a global basis. The mere fact that your organization runs an open DNS cache resolver makes it very likely that you are participating as a man in the middle in these types of attack. Over the past several weeks, we have seen a continual DNS Amplification Attack using the domain DYN.COM with ANY records targeting IP addresses associated with a Turkish telecommunications company. This attack is likely designed to limit or prevent Internet access with the country. So, what can be done to stop these attacks? First and foremost, if you don’t have a need to allow unrestricted access from the Internet to your DNS cache resolvers, then don’t! Restrict access by IP range, or better yet, only allow access from your LAN IP address space. Close the listener on all Internet-facing interfaces. But you say, “I need to have an open cache resolver on the Internet, what do I do to protect my DNS?” The short answer – rate limit incoming queries by source IP and type and force certain query type to be “re-asked” over TCP. Implementing in practice is a bit tougher depending upon your environment. BIND, for example, has a rate limiting option built in for version 9.9.4 and newer. This feature only rate limits all queries globally. BIND also has a feature known as Response Policies. These can be configured to alter the response sent by BIND, but this does nothing to inhibit the flow of incoming and outgoing requests. If you are using Microsoft DNS on an Internet-facing interface, well, not sure what to say here other than "why?" Unbound does not have any built-in rate-limiting features but does have some denial-of-service protection that kicks in under heavy loads. Another mitigation technique that is employed to help mitigate DNS Amplification involves configuring the responding DNS server to force certain query types like ANY and TXT record queries to use TCP. BIND and Simple DNS have this feature. Check the documentation for your DNS server software to see if there is a configuration for this. Keep in mind that you will have to expose TCP port 53 to the Internet. Most attackers will ignore redirect to TCP responses because that would require a three-way handshake and could reveal the source IP of the attacker. Also, note source IPs can be spoofed in TCP packets, and having TCP 53 open may allow for another type of attack called a SYN/ACK flood to be initiated from your DNS server. Aside from these simple options, most DNS servers give you little granularity in configuring protective controls for your DNS server. Other mitigation strategies include:
- Blacklisting IPs in your firewall. Be careful here because you are likely blacklisting the victim IP.
- Rate-limiting via your firewall. This is again not very granular but will work in a pinch.