Attacks/Breaches
6/16/2014
06:20 PM
Connect Directly
Google+
Twitter
RSS
E-Mail
50%
50%

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 DarkReading.com. 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
Comments
Newest First  |  Oldest First  |  Threaded View
Kelly Jackson Higgins
100%
0%
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
50%
50%
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...
Whoopty
50%
50%
Whoopty,
User Rank: Moderator
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
50%
50%
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
50%
50%
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. 
andrewboon2739
50%
50%
andrewboon2739,
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"   @   http://bit.ly/1c0f35M
Christian Bryant
50%
50%
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
Cartoon
Current Issue
Dark Reading Tech Digest, Dec. 19, 2014
Software-defined networking can be a net plus for security. The key: Work with the network team to implement gradually, test as you go, and take the opportunity to overhaul your security strategy.
Flash Poll
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2014-8142
Published: 2014-12-20
Use-after-free vulnerability in the process_nested_data function in ext/standard/var_unserializer.re in PHP before 5.4.36, 5.5.x before 5.5.20, and 5.6.x before 5.6.4 allows remote attackers to execute arbitrary code via a crafted unserialize call that leverages improper handling of duplicate keys w...

CVE-2013-4440
Published: 2014-12-19
Password Generator (aka Pwgen) before 2.07 generates weak non-tty passwords, which makes it easier for context-dependent attackers to guess the password via a brute-force attack.

CVE-2013-4442
Published: 2014-12-19
Password Generator (aka Pwgen) before 2.07 uses weak pseudo generated numbers when /dev/urandom is unavailable, which makes it easier for context-dependent attackers to guess the numbers.

CVE-2013-7401
Published: 2014-12-19
The parse_request function in request.c in c-icap 0.2.x allows remote attackers to cause a denial of service (crash) via a URI without a " " or "?" character in an ICAP request, as demonstrated by use of the OPTIONS method.

CVE-2014-2026
Published: 2014-12-19
Cross-site scripting (XSS) vulnerability in the search functionality in United Planet Intrexx Professional before 5.2 Online Update 0905 and 6.x before 6.0 Online Update 10 allows remote attackers to inject arbitrary web script or HTML via the request parameter.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Join us Wednesday, Dec. 17 at 1 p.m. Eastern Time to hear what employers are really looking for in a chief information security officer -- it may not be what you think.