How Not To Respond To A DDoS Attack

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."