Attacks/Breaches
2/28/2014
09:42 AM
Dave Piscitello
Dave Piscitello
Commentary
Connect Directly
Twitter
RSS
E-Mail
100%
0%

DDoS Attack! Is Regulation The Answer?

Four security experts weigh in on why there's been little progress in combating DDoS attacks and how companies can start fighting back.

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:

  • The attack was distributed, emanating from over four thousand servers and twelve hundred networks.
  • The attack used reflection, a technique where the source IP address of query traffic is "spoofed.” All of the attacking hosts set the source IP address of queries to the IP address of the targeted host so that the responses will overwhelm the victim.
  • The attack also used amplification, a technique where a small query results in a much larger response being transmitted in order to deplete the target’s resources more rapidly.

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.

(Image: Cyber Inz)
(Image: Cyber Inz)

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.

Dave Piscitello has been involved with Internet technologies (broadband access, routing, network management, and security) for over 35 years. He left private sector consulting and his company, Core Competence, to provide security and ICT coordination for security and policy ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
davepiscitello
50%
50%
davepiscitello,
User Rank: Apprentice
3/3/2014 | 12:28:17 PM
Re: More regulation? Don't think so
Regulation could come in the form of procurement requirements imposed on ISPs; for example, government agencies would not be able to accept bids on services unless the ISP were to provide ingress IP source address filterin (BCP 38). Other countries our the EU, for example, could follow suit.

Quasi-regulation might also be appropriate. ICANN's SSAC has published a report on DDOS (SAC 065) that suggests that BCP 38 requirements be incorporated into ISO 27002 standards. The outcome of such an action would be that any organization that would seek ISO 27K compliance would have to provide antispoofing.
Marilyn Cohodas
50%
50%
Marilyn Cohodas,
User Rank: Strategist
3/3/2014 | 11:57:29 AM
More regulation? Don't think so
It's hard for me to imagine a hue and cry for more regulation, Dave. Who would do the regulating? 
davepiscitello
50%
50%
davepiscitello,
User Rank: Apprentice
3/1/2014 | 7:44:33 AM
Re: Just fix it!
Agree. John Bambenek makes this exact point in his quote.

There is a world of denial around (a) being the target of an attack and (b) the tangible + intangible cost of getting hit by a DDoS

Ironically, and wrongly, some industry pundits are suggesting that the intangibles are decreasing because so many sites are under attack that "you don't stand out". I think this creates a really attractive denial proposition for folks who hear the cost of DDoS prevention services. Of course, they are still not thinking mitigation but response. 
Somedude8
50%
50%
Somedude8,
User Rank: Apprentice
2/28/2014 | 9:33:08 PM
Re: Just fix it!
Seriously! When looking at the cost of finding your digital shorts around your ankles, an ounce of prevention is absolutely the smart thing! I find it just completely nuts that this is isn't super obvious.

I have a client right now wrestling with a colo/managed hosting facility. They are telling her that her server suffered from a DDOS attack becuase of problems in the code that runs her websites. Think about that one for a second... lol! Yeah, she is moving her stuff to another server with another company as we speak.
davepiscitello
50%
50%
davepiscitello,
User Rank: Apprentice
2/28/2014 | 9:28:55 PM
Re: New Commons
This is certainly an approach that everyone's left off the table. 

Can you point to any economic studies that would be relevant or similar?
davepiscitello
50%
50%
davepiscitello,
User Rank: Apprentice
2/28/2014 | 9:27:03 PM
Re: Just fix it!
Well, it's pretty evident from our current condition that you're right: getting everyone to do something voluntarily is not easy, nor is it working out for us. This is why regulatory intervention is beginning to look inevitable if not appealing. I think John Bambenek's observation that implementing antispoofing measures is actually not nearly as hard or expensive as it seems is important, though. Perhaps if more people debunk the "too hard, too costly" myths we'll see more uptake.
Brian Bartlett
50%
50%
Brian Bartlett,
User Rank: Apprentice
2/28/2014 | 8:43:17 PM
New Commons
It's still the "Tragedy of the Commons" again, and again, and again! If we really want to be proactive I'd suggest the IETF let some economists have a look at the whole of the ecosystem. Surely there has to be more than myself in that overlapping of the fields. (hint: they both deal with constraints) Then use known externality mitigation strategies, which could include regulations, to deal with these. That's how you get ahead of this.
Marilyn Cohodas
50%
50%
Marilyn Cohodas,
User Rank: Strategist
2/28/2014 | 3:02:24 PM
Re: Just fix it!
I tend to agree with you, @Samedude8, the eyes of most C-levels will glaze over at the first mention of UDP-based services,  ingress filtering and BC-P38.  I suspect they will sit up and take notice given a choice between self-regulation or regulatory intervention. It goes without saying that the repurcussions of a DDoS attack would not be welcome at all! 
Somedude8
50%
50%
Somedude8,
User Rank: Apprentice
2/28/2014 | 2:45:47 PM
Just fix it!
I agree that this would be a great step forward:
"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."

However, I find that anytime a potential answer invovles any variation of "If everyone would just...", that answer is just not going to happen. Besides, I think anyone C-Level got lost at "BC uh whatever that thing was. Just fix it, that is what we pay you for!"

Good article though!
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Dark Reading December Tech Digest
Experts weigh in on the pros and cons of end-user security training.
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-5426
Published: 2014-11-27
MatrikonOPC OPC Server for DNP3 1.2.3 and earlier allows remote attackers to cause a denial of service (unhandled exception and DNP3 process crash) via a crafted message.

CVE-2014-2037
Published: 2014-11-26
Openswan 2.6.40 allows remote attackers to cause a denial of service (NULL pointer dereference and IKE daemon restart) via IKEv2 packets that lack expected payloads. NOTE: this vulnerability exists because of an incomplete fix for CVE 2013-6466.

CVE-2014-6609
Published: 2014-11-26
The res_pjsip_pubsub module in Asterisk Open Source 12.x before 12.5.1 allows remote authenticated users to cause a denial of service (crash) via crafted headers in a SIP SUBSCRIBE request for an event package.

CVE-2014-6610
Published: 2014-11-26
Asterisk Open Source 11.x before 11.12.1 and 12.x before 12.5.1 and Certified Asterisk 11.6 before 11.6-cert6, when using the res_fax_spandsp module, allows remote authenticated users to cause a denial of service (crash) via an out of call message, which is not properly handled in the ReceiveFax dia...

CVE-2014-7141
Published: 2014-11-26
The pinger in Squid 3.x before 3.4.8 allows remote attackers to obtain sensitive information or cause a denial of service (out-of-bounds read and crash) via a crafted type in an (1) ICMP or (2) ICMP6 packet.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Now that the holiday season is about to begin both online and in stores, will this be yet another season of nonstop gifting to cybercriminals?