Common DDoS Response Mistakes

I found and interesting article on, which discussed some of the common mistakes that organizations make when they are under a DDoS attack. The unfortunate thing about these types of attacks is that there is no real cure, and DDoS attacks are going to remain a pain our sides for some time to come. Below is a list of some of the common mistakes that organizations make when responding to a DDoS.

* Not having a plan to prevent DDoS attacks in the first place.

Security firms say that it is much more difficult to remediate a DDoS attack after it has started. It is much easier and more effective to put a shield in place that can prevent this type of crippling traffic from starting in the first place. Senior director of security strategy at SolarWinds, Gretchen Hellman, says, 
"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."
I like the fact that she says that it is a good idea to take some time to figure out and understand the nature of the attack, what kind of mechanisms is it using to execute the attack, what part of the network is it targeting or is it targeting the entire network, is the attack only focused on the Web server? Reacting too quickly can actually cause more damage than stepping back for a second to really evaluate the situation fully or at least to the best or ones ability. Having a slow response time can also lead to damaging circumstances as well. So, I think the take away from this one is to have a plan before the DDoS actually occurs so that damage can be kept to a minimum.

* Not having a plan to test the plan ...

Waiting to try out a DDoS plan in the midst of an attack is probably not the best way to go. This article gives an example, which talks about a popular bank that was hit by a DDoS back in 2012. After verifying that they were indeed under attack, they tried to switch all of their services over to their DDoS mitigation solution. When they flipped the switch their whole network went down. Ummmmm .......... is the look that I can imagine everyone had on their faces. Looks like testing their solution a head of time might have come in handy.

Michael Bennett, from DDoS Strike, says that not testing the infrastructure and defenses is a common mistake. If you have never seen or been hit by a DDoS attack, how will you know what that kind of attack looks like, and you want know what to do or how to react in that situation. Testing your plan can help to determine where there might be holes or weaknesses, which includes communication between pertinent teams within the organization.

Communication communication communication, that is one of the key points that I caught from reading this part of the article. Table top exercises would probably be a good place to start. At least it would get the conversation going and open up proper channels between each department within the organization.

* Not becoming close buddies with your ISPs 

It can is much easier to have the traffic be blocked further upstream before it even reaches your network. It is much easier to put the protection in place before you need it, and I feel that in the case of a DDoS it is almost inevitable, depending on the type or size of the org, that an attack will happen sooner of later. I would rather have something in place, so that I wouldn't be running around is circles.

So, in conclusion:

  • Plan
  • Test
  • Look outside of the immediate network 


Popular posts from this blog

Emby Media Server | Arch Linux

Installing Arch Linux & Gnome 3 Desktop