Mitigating DNS Reflection Denial-of-Service Attacks
Currently, we have been seeing an uptick in the number of denial-of-service attacks using DNS reflection or amplification. There are many variants, but the general outline of the attack is the same:
- An attacker creates a DNS query with a fake source IP address – that of the intended victim. (Consider this as being analogous to a fake return-to-sender address.)
- The query is sent to a DNS server that accepts queries from external addresses (i.e., those from a different ISP/network than its own). In addition, the query is crafted to generate the largest reply possible. Frequently, DNSSEC is used, as returns using it tend to be much larger than other DNS replies.
- The intended victim is flooded with packets. These can either be replies from the DNS server, or error messages sent along the way which are sent back to the “sender.”
- Using DNS reflection, it is possible to use a relatively small number of hosts (often compromised) to generate huge volumes of traffic aimed at victims. Often, the abused DNS servers don’t even know they are involved in an ongoing attack.
- This type of attack is very hard to trace as the source is well masked and you need lots of cooperation from the DNS server operators as well as their network service providers to trace attack to a source.
Both network operators and the administrators of DNS servers can help mitigate these attacks.
It is estimated that 14.1% of netblocks, which total 16.8% of all IP addresses, can be spoofed. That may sound small, but the Internet is a big place. An attack using DNS reflection can cause a large amount of damage, even if much less than 1% of IP addresses are used.
Ingress filtering applied at the router or firewall is one way to prevent networks from being a source of this type of attack. It prevents packets from transiting the router if the source address of the packet does not belong on the interface on which the packet was received. By analogy, this would be like a post office rejecting outgoing mail that had return addresses from out of town.
This doesn’t stop spoofing attacks from machines on the same network, it does prevent machines from initiating spoofing-based attacks against outside networks. One of the best resources here is BCP-38, which describes in detail how to implement this type of filtering.
DNS Server Operators
Operators of DNS servers have a part to play in dealing with this threat as well. If you operate DNS servers with publicly accessible domains, it is obvious that queries from any host on the Internet should be allowed to query your server for these domains. But what about domains that you don’t control?
It may seem that there’s no harm in letting any IP on the Internet ask your DNS server for an A record for, say, www.trendmicro.com. If you don’t consider the possibility of source address spoofing that would be harmless. However, because the authenticity of the source IP for queries from outside networks can’t be validated, there’s no way to tell if the query your servers just replied to is harmless or part of an ongoing attack.
One common way to face this problem is by setting up two sets of name servers. One would respond to queries for domains available to the public that you host, while ignoring requests for any other domain. A second set would support end users for your network and offer recursive resolution for any sites that they access. (This can be done with just one set of servers, but configuring it is more complex.)
If for some reason you feel that you must continue to run open-facing DNS resolvers, please consider using rate-limiting to prevent abuse.