06:20 PM
Connect Directly

How Not To Respond To A DDoS Attack

Common mistakes made by victims of distributed denial-of-service attacks.

Distributed denial-of-service (DDoS) attacks just won't go away. Just ask the news and information aggregator service Feedly, which suffered waves of attacks over a three-day period last week that kept the site struggling to restore service.

Feedly is hardly alone. DDoS attacks occur regularly, many not so high-profile as that of a software-as-a-service firm or a financial services provider. There's no magic bullet to prevent a DDoS attack. Security experts and DDoS protection service providers say it's all about preparation and proper mitigation strategy.

But many victim organizations continue to be caught unawares and unprepared for a crippling DDoS attack. Here are some of the most common mistakes made by organizations targeted in a DDoS.

Not having a DDoS plan in place
The last thing you want when you're getting DDoSed is to have to find and enlist a DDoS mitigation provider such as Akamai Prolexic or CloudFlare while you are under siege. "If you have a 'shield' in place before an attacker starts, you're [basically] golden. But if you have to put that in place in the midst of an attack," stopping the attack will take longer, says Matthew Prince, co-founder and CEO of CloudFlare, which offers website protection and DDoS mitigation services.

CloudFlare, which was called in to help Feedly in the midst of the attacks on the site, basically moved Feedly's services to new IP address space to mitigate the attack. "It took a little time for that to happen," Prince says.

Fighting a DDoS after the fact is difficult. "There are a lot of moving pieces when you're under attack."

Gretchen Hellman, senior director of security strategy at SolarWinds, says not having a mitigation plan in place is the number one mistake in DDoS attacks.

"Such a plan should include evaluation of current DDoS protections, defined roles and responsibilities between the network and security teams, and a clear process of communication both internally and with your ISP," she says. "Failure to have a solid plan will result in mistakes, such as focusing on blocking IP addresses only -- attackers will use spoofed ones that change often -- reacting without taking the time to understand the nature of the DDoS traffic, and elongated response time when an attack occurs, resulting in more damage."

[Feedly fends off ransom demands of its DDoS attackers. Read Wave Of DDoS Attacks Down Cloud-Based Services.]

Not testing your DDoS mitigation defenses in advance
During the wave of DDoS attacks on US financial institutions in the fall of 2012, one large bank experiencing an attack on one of its sites decided to move its entire infrastructure to its DDoS mitigation service. "They flipped the switch for the entire infrastructure, and suddenly the network went offline," Prince says. "In the middle of a crisis, you don't want to turn on something" without proper testing and preparation.

Failing to test your defenses can backfire. Michael Bennett, software engineer for DDoS Strike, Security Compass's DDoS blackbox testing program, says not testing your infrastructure and defenses is a common mistake. "If you've never been hit by a DDoS, you won't know what it looks like, and you won't know what's happening or what to do." DDoS attacks can have a long tail and affect areas of your infrastructures in ways you may not notice right away.

"It could bog your databases down and slow your service down," he says. "This might not be obvious when you are reacting to them [DDoS attacks] on the fly."

He recommends testing DDoS response and defense processes to pinpoint any potential holes or weaknesses. That includes ensuring that the network team is communicating with the application team, for instance. Security Compass has seen cases where the network team has noticed a traffic spike, but since it didn't saturate the network, it didn't appear to be a DDoS, so the team didn't notify the application team.

"There might be a breakdown in communication," Bennett says. All teams need to be on the lookout for anomalies and to keep one another briefed on any activity that could be a DDoS.

Neglecting to bond with your ISPs
Sometimes your upstream ISP is the key to quelling a big DDoS. "They can provide you a bit of assistance in blocking malicious traffic far upstream" before it enters your network, Bennett says.

Jarl Stefansson, dev ops engineer at Security Compass, says upstream network providers have more capacity to block and filter DDoS traffic. "If you're only locally monitoring traffic, you're not necessarily going to identify a DDoS attack, and you're not going to have the visibility to diagnose it. You have to have the ability to manage infrastructure out of band."

Relying on your network alone to catch and stop a DDoS is risky. "You might be locked out of the system and unable to respond," he says. It's crucial to be able to tell whether the attackers are targeting the network itself or specific applications.

Prince says the key is having protection in place or at the ready before you need it.

"When an attack has started, it means that, not only do you have to enable a shield like CloudFlare, but you then have to, at a minimum, move your infrastructure to new addressing space. In some cases, even that isn't enough to hide the infrastructure from an attacker, and we'll enable BGP [Border Gateway Protocol] origin protection, where we actually announce a customer's IPS directly from the edge of our network and then set up a private tunnel back to their infrastructure so it cannot be targeted directly," he says. "Moving a complex infrastructure can take time. Moral of the story is, it's always easier if you sign up for protection before you need it."

Kelly Jackson Higgins is Executive Editor at She is an award-winning veteran technology and business journalist with more than two decades of experience in reporting and editing for various publications, including Network Computing, Secure Enterprise ... View Full Bio

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
Kelly Jackson Higgins
Kelly Jackson Higgins,
User Rank: Strategist
6/17/2014 | 2:09:31 PM
Re: Defending Against a DDoS Attack
That would definitely make things a lot more interesting!
Christian Bryant
Christian Bryant,
User Rank: Ninja
6/17/2014 | 2:07:35 PM
Re: Defending Against a DDoS Attack
 @Kelly Jackson Higgins

Yes, it is controversial.  I wouldn't even get into the difficulties of how that could be navigated legally.  I do support it, still, but understand the risks and complexities involved.  If only we could get government-sanctioned teams that could "turn the tables" under one large umbrella that would represent businesses and the interests of everyday citizens, but with the ability to act immediately without the red tape...
User Rank: Ninja
6/17/2014 | 12:20:14 PM
Re: Defending Against a DDoS Attack
Indeed, especially when you consider that most members of a botnet that's performing a DDOS attack have no idea they've been recruited, since malware has made them an unwitting member. 
Randy Naramore
Randy Naramore,
User Rank: Ninja
6/17/2014 | 10:08:03 AM
Re: Defending Against a DDoS Attack
Good article, should always plan and test for the worst case scenario. DDOS planning is something that should be tested periodically. 
Kelly Jackson Higgins
Kelly Jackson Higgins,
User Rank: Strategist
6/17/2014 | 9:24:01 AM
Re: Defending Against a DDoS Attack
Turning the tables on DDoSers sounds like the ultimate revenge. But it's really not something most organizations can/should do. Even security researchers have had to tread carefully when using this tactic. Like any offensive security approach, it's controversial and comes with some risks of its own. 
User Rank: Apprentice
6/17/2014 | 8:10:17 AM
Two common Web application attacks illustrate security concerns
The issue of cybersecurity is a major and growing concern for the business community. Its time organizations adopt stronger measures to check security breaches, spotting and mitigating cyber crime and other security related issues will be of utmost importance in a digitally connected world. I work with McGladrey and there's a whitepaper on our website that offers useful information on the common security concerns for businesses and ways to mitigate them. "Two common Web application attacks illustrate security concerns"   @
Christian Bryant
Christian Bryant,
User Rank: Ninja
6/17/2014 | 1:16:01 AM
Defending Against a DDoS Attack
Brings to mind your article from a while back DIY: Defending Against a DDoS Attack.  While I agree most enterprises need the help of expert companies to fend off DDoS attacks, I very much support the idea of striking back as well, and preferably bringing the attackers themselves down.  The stronger security teams in the enterprise become, the harder it is for cyber criminals to gain a foothold.  Hacktivists can help in this regard by retaliating on behalf of small businesses that otherwise can't stand a chance against these attacks. 
Register for Dark Reading Newsletters
White Papers
Current Issue
Dark Reading Tech Digest September 7, 2015
Some security flaws go beyond simple app vulnerabilities. Have you checked for these?
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
Published: 2015-10-02
Buffer overflow in Canary Labs Trend Web Server before 9.5.2 allows remote attackers to execute arbitrary code via a crafted TCP packet.

Published: 2015-10-02
Cisco NX-OS 6.0(2)U6(0.46) on N3K devices allows remote authenticated users to cause a denial of service (temporary SNMP outage) via an SNMP request for an OID that does not exist, aka Bug ID CSCuw36684.

Published: 2015-10-02
Cisco Email Security Appliance (ESA) 8.5.6-106 and 9.6.0-042 allows remote authenticated users to cause a denial of service (file-descriptor consumption and device reload) via crafted HTTP requests, aka Bug ID CSCuw32211.

Published: 2015-10-01
lxc-start in lxc before 1.0.8 and 1.1.x before 1.1.4 allows local container administrators to escape AppArmor confinement via a symlink attack on a (1) mount target or (2) bind mount source.

Published: 2015-10-01
kernel_crashdump in Apport before 2.19 allows local users to cause a denial of service (disk consumption) or possibly gain privileges via a (1) symlink or (2) hard link attack on /var/crash/vmcore.log.

Dark Reading Radio
Archived Dark Reading Radio
What can the information security industry do to solve the IoT security problem? Learn more and join the conversation on the next episode of Dark Reading Radio.