DDoS Attack! Is Regulation The Answer?

The scale, diversity, and magnitude of recent DDoS attacks have knocked enterprises back on their heels. Now they're attracting attention from regulators. Intended or not, attackers are forcing a sea change. The question at hand is whether self-regulation will improve or if regulatory intervention is inevitable.

Cloudflare’s recent analysis of a February 13 denial of service attack explains the most recent variation on a recurring DDoS attack theme, and in doing so illustrates that we’ve made little or no progress in mitigating root causes of DDoS:

There are also other similarities between this and prior DDoS attacks. The attacks exploit UDP-based services (DNS, chargen, and now NTP). They exploit the absence of anti-spoofing measures by ISPs or private networks, and they exploit the "open" operation of these services, taking advantage of open DNS resolvers, publicly accessible network time servers, and services that should be configured to respond only to clients within specific administrative domains.

The takeaway is obvious: Services that run over UDP and are accessible in a public or open manner are targets for reflection or amplification attacks, and the ability to spoof IP addresses exacerbates this threat.

What’s also interesting to note from the Cloudflare report, is that the NTP DDoS attack volume was just shy of 400 Gbit/s, far larger than the DNS amplification attack against Spamhaus in March 2013, and totally dwarfing the magnitude of attacks against US banks in December 2013. Cloudflare and others warn that other yet-to-be-exploited UDP-based services (e.g., SNMP) have even greater amplification potential. This raises the question: Is a terabit-per-second DDoS inconceivable, or inevitable?

Who cares?
The technical community has repeatedly published methods to mitigate DDoS reflection and amplification attacks. The post mortems of nearly every DDoS attack include recommendations to implement anti-spoofing measures, to eliminate unbounded open DNS resolvers and open NTP servers, and to contain other UDP-based services within administrative boundaries.

I’m not optimistic that we’ll see any meaningful adoption of these mitigations for three simple reasons: willingness to pay, willingness to cooperate, and willingness to execute. ISPs, citing  cost or performance, are reluctant to implement ingress filtering. Private networks are lax in implementing egress filtering at firewalls. Therefore DDoS attacks remain largely unabated.

This is despite the fact that the means to abate DDoS attacks are well publicized. Numerous articles or advisories from security committees (BITAG, SSAC) explain how to operate DNS recursive resolvers responsibly. Yet as of October 2013, the Open Resolver Project reports that 32 million resolvers respond to queries from hosts outside the resolver’s administrative domain -- and 28 million of these pose threats. This and the Open NTP Project provide methods for operators to check whether the services they operate are open and a threat. That the numbers of these open services keep rising is strong evidence that the will to execute is not present.

Almost a year ago, I wrote in a blog that the DDoS problem will never be mitigated if every organization and every Internet access provider (or network operator) only implements measures that are self-beneficial. I’ll press further to say that today we have reached a point where our reluctance to collaborate is giving policy makers cause to suggest it’s time for an intervention.   

Is regulation needed?
Increasingly, organizations are being forced to invest in DDoS prevention, rather than use already scarce security budgets on more proactive measures. Have we reached the point where regulation is needed?  I asked colleagues who are DDoS subject matter experts to weigh in on the question. Here are their responses:

Paul Vixie, CEO of Farsight Security, reflects the frustration of many technical experts. "I do not foresee any regulatory action nor requirements from government procurement agencies," he told me. "(But) I believe that they would be beneficial."

John Bambenek, president of Bambenek Consulting, Ltd., and handler at the SANS Internet Storm Center, is less certain. "I'm sure there will be some beneficial aspects," says Bambenek, "That said, while PCI has helped nudge things to more security in credit card transactions, the Target incident (as well as others) show it never really solves the problem."

How can we stop the treadmill? Vixie thinks it’s time organizations fight back. "Victims should start filing suit against non-BCP38 ISPs for something like contributory negligence."

Joel Snyder, senior partner at Opus One, offers an alternative. "The Internet needs to leverage its own strengths to up the compliance with BC-P38… [The] self-regulators of the Internet need to change behavior by providing strong disincentives to misbehave.” Disincentives, for example, he said, could take the forms of refusal to peer or accept traffic from non-compliant networks.

Time to get tough
Without regulatory intervention, Vixie suggests C-level execs will need to  set more stringent procurement requirements: "Don't connect to ISP's who don't enforce BCP38 at their customer edge. Don't buy transit from them. Don't peer with them. Tell them why. Make them pay the highest possible cost to deliver reflected DDoS traffic to victims in your network,” he says.

Bambenek believes C-levels should tend their own networks better by implementing anti-spoofing measures and operating resolvers responsibly. "Doing this right takes a fraction of the resources that it would take to comply with a mountain of regulation that will do nothing more than grow your organization's Business Prevention Department," he says. 

While Snyder agrees that companies should require a statement of BCP38 compliance from their service providers, he also suggests that you have IT verify that your networks cannot be UDP amplifiers. He also reminds network administrators that rate-limiting features are generally included in all good firewalls -- but most people don't bother to turn them on. "Investigate the anti-DDoS features of existing firewalls and enable them," he advises.

Now it’s your turn. What actions is your organization willing to take to reduce the growing risk from DDoS attacks? Share your thoughts in the comments.