DNS Amplification - Protecting Unrestricted (Open) DNS Resolvers

In a prior post, I gave a broad overview of some of the challenges we face in securing unrestricted DNS resolvers. I presented a talk at BSides Las Vegas on the topic and wanted to take some time to delve into more technical details regarding some of the attacks we have seen, as well as review some mitigation strategies. You can find video of the talk here. The most prevalent type of attack we see is DNS Amplification. Technically reflective distributed denial of service attacks (rDDoS), these attacks can manifest themselves in two ways: either you are the target or the middle man participating in an attack on another network. Either way, you don’t want to be in that position. So, how do these attacks work? Remember, DSN is an application-layer protocol that makes use of UDP connections primarily. UDP connections are stateless and essentially a best-effort protocol. There is no connection handshake, making it extremely easy to spoof the source IP address in the incoming packets. DNS request packet payload size used to be limited to 512 bytes in size, according to the RFC. But the introduction of EDNS(0) extensions and subsequent adoption of these standards means the DNS payload packet size can reach up to a maximum 4096 bytes before fragmentation and subsequent retry via TCP. (I will address the security implications of DNS & TCP in a future post.) A typical DNS incoming payload is between 50 and 100 bytes. Outgoing payloads can vary in size from very small (around 100-200 bytes) for an A or CNAME record to up to 4000 or more bytes for a large ANY or TXT record. Consider the following:

1. 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).
2. The malware spoofs the IP address in the request to be that of the target victim.
3. The pack is sent to a known open cache resolver.
4. The outbound packet is approximately 50 bytes (the actual size is 64 bytes).
5. 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).
6. 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

Now, consider that a single infected host (botnet member) using just 100 Kbps of bandwidth can send 100,000 bytes / 50 bytes = 2000 DNS requests per second. These requests will likely fall under the radar of most detective controls on the end point. A typical botnet controls hundreds of thousands of possible endpoint participants. In our example, imagine a botnet of just 10,000 endpoints each attacking the same IP address and using only 100 kbps per end point.

100 kbps x 10,000 end points x 60 (amplification factor) x .000001 Gbps/kbps = 60 Gbps

As 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:

1. Blacklisting IPs in your firewall. Be careful here because you are likely blacklisting the victim IP.
2. Rate-limiting via your firewall. This is again not very granular but will work in a pinch.

In our case, we were able to leverage our load balancers and incorporate iRules on our F5 interfaces to pre-process DNS traffic and apply a variety of rules. Those rules include blocking based on IP blacklist matches (know malicious IPs, not likely target IPs), rate-limiting based upon a combination of source IP, query type and query name (This allows legitimate queries through and ignores the malicious ones.) and some packet inspection to validate the structure of the DNS packets. All of these tests are built into a single iRule that inspects every incoming DNS request. All pertinent information is logged to our Graylog infrastructure for feedback analysis and only valid requests are passed through to our DNS clusters. This iRule makes use of automatically updated Data Group files, giving us a single distribution point to push changes to our global infrastructure. You can read about the automated update process here. I hope this overview of DNS Amplification and mitigation strategies helps in making your infrastructure more secure and less likely to participate in any of these attacks.  

Image

About the Author: Jim Nitterauer, CISSP is currently a Senior Security Specialist at AppRiver, LLC. His team is responsible for global network deployments and manages the SecureSurf global DNS infrastructure and SecureTide global SPAM & Virus filtering infrastructure as well as all internal applications and helps manage security operations for the entire company. He is also well-versed in ethical hacking and penetration testing techniques and has been involved in technology for more than 20 years. Editor’s Note: The opinions expressed in this guest author article are solely those of the contributor, and do not necessarily reflect those of Tripwire, Inc. Save