This post follows an earlier post about DNS amplification attacks being observed around the world. DNS Amplification Attacks are occurring regularly and even though they aren’t generating headlines targets have to deal with floods of traffic and ISP infrastructure is needlessly stressed—load balancers fail, network links get saturated, and servers get overloaded. And far more intense attacks can be launched at any time.

The latest twist on amplification attacks is to induct home gateways, tens of millions of them are scattered throughout the world and they can act as willing accomplice as shown in the diagram below. Attackers simply send packets with spoofed source addresses to gateways, which proxy them to the resolver they’re configured to use, typically an ISPs resolver. When ISP resolvers see DNS queries coming from IP addresses within their network they rightfully prepare responses and send them back to the home gateway. From there the home gateway forwards the response to the target using the spoofed source address. It’s a pretty neat trick, except its causing lots of problems for ISPs including those who go to great lengths to protect their networks.

In this case Best Practices like Source Address Validation/ingress filtering (BCP 38) and “closing” resolvers (restricting resolver access to IP ranges within a providers network) don’t work. The open DNS proxies on home gateways subvert resolver protections and since the attack packets are sourced from outside the network internal address spoofing protections aren’t effective. This presents a major problem for service providers: how to mitigate the attacks?

“Upgrade home gateways!” is a seemingly obvious response but even if patches can be developed to resolve the issue getting consumers to upgrade software on a device many probably forgot about shortly after they installed it is an unlikely proposition. Recall last year despite massive (and very costly) communications about DNSChanger and the prospect of losing Internet connectivity altogether many consumers were unwilling or unable to take action. In this case consumers don’t really suffer any inconvenience at all; most will never notice their home gateway is being used for an attack so there’s essentially no motivation to take action. Other approaches are needed.

Resource Rate Limiting (RRL) was devised to address DNS amplification but is currently only implemented on authoritative DNS servers so it doesn’t help with attacks that use resolvers. What’s needed is more intelligence in the resolver. The previous post in this series talked about the importance of logging DNS data. Logs will reveal critical details necessary to identifying and characterizing an attack: unusual spikes in the query rate (QPS) or unusual query activity—uncommon domain names among the top domains being queried, atypical query types (like ANY), or an uptick in requests for DNSSEC. Some kind of operational dashboard fed by DNS data is useful to track baseline (“normal”) operating conditions and to provide the basis for comparison when an attack is suspected.

Depending on the sophistication of the attack simple forensics can reveal the source, although it may also be necessary to drill down and visualize the data—by name, query type, etc. to investigate more deeply. No matter what having access to the data is critical, it should become a best practice to capture it all the time. In fact when data is logged as part of standard operating procedure proactive monitoring becomes possible. Setting alerts based on typical operating thresholds plus a variance factor can provide valuable lead time.

Once an attack has been identified it’s necessary to filter (drop) incoming queries to mitigate it. Filtering incoming traffic (versus filtering responses) is advantageous because the server has to do less work (it doesn’t have to look up the answer first). For simple attacks it might only be necessary to filter based on Query Type. For instance, ANY queries have few legitimate uses and it might be appropriate to deal with large spikes with a simple filtering policy. Since DNS is an essential network service it’s also important to ensure legitimate queries are always answered. Finer grained filters can be used for better targeting to eliminate collateral damage. For instance a slightly more sophisticated policy can filter based on Query Type and name. Tighter specification of drop criteria minimizes the possibility valid queries are impacted.

Amplification attacks will continue to evolve so methods for identifying and mitigating them will have to evolve too. The next post will discuss some of the latest insights from the wild.

Join Nominum for a 30 minute webinar on this topic on September 24. Sign up here.