.@ Tony Finch – blog

In recent months DNS amplification attacks have grown to become a serious problem, the most recent peak being the 300 Gbit/s Spamhaus DDoS attack which received widespread publicity partly due to effective PR by CloudFlare and a series of articles in the New York Times (one two three).

Amplification attacks are not specific to the DNS: any service that responds to a single datagram with a greater number and/or size of reply datagrams can be used to magnify the size of an attack. Other examples are ICMP (as in the smurf attacks that caused problems about 15 years ago) and SNMP (which has not yet been abused on a large scale).

The other key ingredient is the attacker's ability to spoof the source address on packets, in order to direct the amplified response towards the ultimate victim instead of back to the attacker. The attacks can be defeated either by preventing amplification or by preventing spoofed source addresses.

Smurf attacks were stopped by disabling ICMP to broadcast addresses, both in routers (dropping ICMP to local broadcast addresses) and hosts (only responding to directly-addressed ICMP). This fix was possible since there is very little legitimate use for broadcast ICMP. The fix was successfully deployed mainly because vendor defaults changed and equipment was upgraded. Nudge theory in action.

If you can't simply turn off an amplifier, you may be able to restrict it to authorized users, either by IP address (as in recursive DNS servers) and/or by application level credentials (such as SNMP communities). It is easier to police any abuse if the potential abusers are local. Note that if you are restricting UDP services by IP address, you also need to deploy spoofed source address filtering to prevent remote attacks which have both amplifier and victim on your network. There are still a lot of vendors shipping recursive DNS servers that are open by default; this is improving slowly.

But some amplifiers, such as authoritative DNS serves, are hard to close because they exist to serve anonymous clients across the Internet. It may be possible to quash the abuse by suitably clever rate-limiting which, if you are lucky, can be as easy to use as DNS RRL; without sufficiently advanced technology you have to rely on diligent expert operators.

There is a large variety of potential amplifiers which each require specific mitigation; but all these attacks depend on spoofed source addresses, so they can all be stopped by preventing spoofing. This has been recommended for over ten years (see BCP 38 and BCP 84) but it still has not been deployed widely enough to stop the attacks. The problem is that there are not many direct incentives to do so: there is the reputation for having a well-run network, and perhaps a reduced risk of being sued or prosecuted - though the risk is nearly negligible even if you don't filter. Malicious traffic does not usually cause operational problems for the originating network in the way it does for the victims and often also the amplifiers. There is a lack of indirect incentives too: routers do not filter spoofed packets by default.

There are a number of disincentives. There is a risk of accidental disruption due to more complicated configuration. Some networks view transparency to be more desirable than policing the security of their customers. And many networks do not want to risk losing money if the filters cause problems for their customers.

As well as unhelpful externalities there are perverse incentives: source address spoofing has to be policed by an edge network provider that is acting as an agent of the attacker - perhaps unwittingly, but they are still being paid to provide insecure connectivity. There is a positive incentive to corrupt network service providers that allow criminals to evade spoofing filters. The networks that feel the pain are unable to fix the problem.

More speculatively, if we can't realistically guarantee security near the edge, it might be possible to police spoofing throughout the network. In order for this to be possible, we need a comprehensive registry of which addresses are allocated to which networks (a secure whois), and a solid idea of which paths can be used to reach each network (secure BGP). This might be enough to configure useful packet filters, though it will have similar scalability problems as address-based packet forwarding.

So we will probably never be able to eliminate amplification attacks, though we ought to be able to reduce them to a tolerable level. To do so we will have to reduce both datagram amplifiers and source address spoofing as much as possible, but neither of these tasks will ever be complete.