Preparing for, Preventing, and Addressing Self-Inflicted DDoS Attacks
Last month we discussed how Amazon.com’s website went down due to a self-inflicted DDoS (distributed denial of service) attack that occurred when Amazon’s servers just couldn’t keep up with the annual Prime Day traffic – something we said might occur if Amazon did not properly ready itself for Prime Day the month before the previous blog post. Amazon, however, is not the only company that has ever suffered from a self-inflicted DDoS attack. In fact, chances of your website going down due to a self-inflicted DDoS attack are actually greater than suffering such an attack due to hackers. How does a self-inflicted DDoS occur? What can you do if your website is suffering server downtime due to a self-inflicted DDoS attack? This post will explain how and why self-inflicted DDoS crashes happen and what you can do prevent this specific type of website downtime. We will also discuss what you can do if your servers and website are already down due to failing to prevent this particular issue.
How a Self-Inflicted DDoS Attack Occurs
Oftentimes a self-inflicted DDoS attack occurs when a website heavily promotes a certain sale or event but hasn’t taken the steps necessary for the site to scale and cope with such a massive increase in traffic. Because the website’s servers aren’t ready to handle the huge increase in traffic, those servers become overloaded. This then results in website downtime. It’s akin to when you have too many browsers and programs open on your computer. At some point, your computer simply can’t handle the demand, so it freezes and stops working. That is what happens to websites when they begin to experience a massive increase in traffic and haven’t prepared their servers for the increase. The server becomes so overloaded it simply stops working.
In most cases complete website downtime due to an increase in traffic is preceded by website performance issues. This in itself is a problem since visitors to the site will usually assume there’s a problem with their browser. As a result, those visitors hit refresh, often multiple times. This in turn creates a snowball effect in which the servers, which are already struggling due to the sheer volume of traffic, must now contend with multiple requests from each visitor. What started out as a performance problem then results in complete downtime.
How to Fix Website Downtime Due to a Self-Inflicted DDoS Attack
The only way to fix this issue as it occurs is if your website architecture has been designed to allow you to add extra servers on the fly. If your website is properly prepared for such changes, you can add services or processing power while the site is suffering due to a DDoS. This will allow you to bring your site back up in a timely and effective manner, allowing for minimal impact on visitors. Not all websites, however, have an architecture that allows for adding servers on the fly in such a situation. If your system isn’t flexible and doesn’t allow for the addition of servers and resources quickly and in real time, then the only way to break the DDoS downtime is to cut some visitors off, reducing the load the servers are experiencing. This is far from ideal, since cutting off those visitors results not only in lost sales, but also in a very negative customer experience. At that point you are not only dealing with addressing and remedying your site’s downtime, but you are also faced with appeasing the numerous customers who have been impacted. We saw just how customers feel when we wrote about the tweets pertaining to Amazon during the downtime it experienced on Prime Day, and it isn’t pretty.
Preventing a Self-Inflicted DDoS Attack Altogether
Ensuring that your website has auto-scaling capabilities in terms of traffic and server resources is critical. While you may not think you need to implement such measures if you aren’t expecting a mass influx of traffic, the fact of the matter is that you don’t necessarily need to plan for such an event in order to be affected. All it takes is one post about your site going viral or a bit of media attention to have your site’s servers crash if they aren’t capable of auto-scaling for a large increase in the amount of traffic your website receives. This is why you need to design or restructure your site to scale rapidly and in real time, even if you aren’t expecting a huge influx of traffic.
If you want to avoid any DDoS attack including the self-inflicted variety, an action plan is also necessary. First, ensure your system is created to absorb the demand caused by a massive traffic increase. For example, if your site usually receives 500 visitors per minute, make sure your servers have the ability to accommodate 10 times that amount, or 5,000 visitors per minute. You also want to ensure that if server resources above and beyond this amount are needed, your site can scale automatically and immediately to prevent your site from going down due to the increased traffic. You should also set threshold limits for when your site’s traffic goes beyond a certain level. While cutting off the traffic at a certain threshold isn’t idea, it’s better than the entire site going down because it can’t handle the number of visitors it’s receiving. You will also want to utilize a quality website monitoring service so you can receive alerts if your website does start to go down. The sooner you are notified of potential problems, the sooner you can get to work fixing the problem and mitigating losses. While dumping logs should be a last-ditch effort if the DDoS is self-inflicted, realize this might be your only option if you have no other way to get your site back online quickly.
Proper preparation and a solid action plan will help you reduce your risk of succumbing to a DDoS attack, whether malicious or self-inflicted, and will also reduce the extent of the damage done if your website does go down.
Archives:
- April 2022 (1)
- April 2021 (1)
- February 2021 (1)
- January 2021 (2)
- December 2020 (1)
- January 2020 (2)
- October 2019 (1)
- September 2019 (1)
- August 2019 (1)
- July 2019 (1)