What to do when your Site Experiences a DDoS Attack
It’s always in the early dawn hours – an SMS alert on your phone forces you to drag up your eyelids and look at a text: your site traffic has surpassed its usual threshold. You start to run through the possibilities as you drift off in search of a few more minutes of sleep but traffic keeps rapidly increasing and your brain jumps to a conclusion…could it be a DDoS Attack?
You pull yourself out of bed and begin to investigate. All of the server requests are coming from legitimate URLs, the majority from inside the U.S., but about 30% are stemming from abroad; China, Russia, and a few other countries – the hairs on the back of your neck prick up, this is a definitely a DDoS Attack and it’s de-referencing IPs. You quickly go in and block traffic to the malicious IPs, that’s a no-brainer but is that the end of it?
If you’re experiencing a DDoS Attack, early detection is critical, and if you operate with an out of house security provider, it’s best to know in advance what the process will be before the worst happens.
Setting up some clever monitoring is a good way to stay ahead of the game. Read on for our tips.
Table of Contents
What is a DDoS Attack
A DDoS attack is a flood of malicious traffic that overtakes your host or server, overloading it to keep your actual users out.
The first DDoS Attack was 21 years ago, not long after the 1995 movie, Hackers portrayed it’s pop-culture take on a coordinated cyber attack, when a latex-clad group of international hackers synchronized an attack on a single system. While the movie takes a lot of liberties, it paints the right kind of picture for simultaneously flooding an IP, servers, or URL with requests that lead to a major outage.
A DDoS Attack aims to:
- Flood your site with malicious traffic
- Overload your applications
- Block legit users from accessing your services
Completely overtaking your service and devouring your bandwidth.
Detecting a DDoS Attack Before Your Customers Complain
What you don’t want, (if you can avoid it), is an onslaught of support tickets coming in alerting you to a problem before you’re aware of its existence – better that you set up some failsafes to give yourself a heads up before your clients start breaking down your door.
Notoriously, DDoS attacks are designed to be hard to detect since the alerts they trigger often have many common causes:
- Your server responds with a 503 error due to service outages
This could be something as routine as the server being down for maintenance to a legitimate overload before the question is it DDoS is even raised.
- The TTL (time to live) on a ping request times out
The destination device may be off or disconnected, or is incorrectly configured. This could also be due to an intermediary device not behaving properly.
An alert that usually directly indicates a DDoS attack is the elusive return of a 404 error, which tells you the browser was unable to communicate with your server and couldn’t respond to the user’s request.
Because the alerts can present as everyday events – the volume and frequency of the alerts is going to be a bigger tip off that you may be dealing with a DDoS.
Tip: Create an API Check to validate that the HTTP status code matches the specified status (503) with an added escalation for a prolonged outage.
What to Check if you Suspect a DDoS Attack
Check your load balancer, and the servers sitting behind it. Your load balancer has the task of distributing your web traffic over select servers. Load balancing is the networking equivalent of not putting all your eggs in one basket – if a single point fails, you’re less likely to go down.
TIP: If your IP address isn’t publicly available, consider whitelisting your monitoring service servers.
Verify that your check updates are functioning before you finalize by using the Run Test tool to confirm your results will return as expected. You’ll also want to view the real-time analysis for your check to see which locations are down. If all locations are down, and sensitivity is at or above our recommendations, the problem is almost certainly legitimate and you can use that information to hone in on root cause.
Confirm the accuracy of your site traffic. This is probably the most reliable way to confirm you are under a DDoS attack. Look for:
- A major increase in traffic from a localized geographical area
- Large amounts of traffic originating from a single IP address
- Traffic spikes at abnormal levels and irregular time of day
- A flood of requests for a single endpoint
- A rapid increase in bandwidth
TIP: Setup a RUM check which will gather the load time of all site visitors and alert if over a certain threshold.
What Makes You a Target?
DDoS attacks don’t require an army of humans to execute. Most often, the actual attackers are bots, or botnets (networks made up of zombie computers – computers compromised by hackers). As with zombies, the parameters for being a DDoS target are minimal – you just need to have brains, or in this case, a substantial or relevant userbase.
- Competition – A DDoS Attack is being used by a competitor to take out rivals
- Relevance to Current Events – In 2020 DDoS Attacks against schools supporting virtual learning are trending
- Hacktivism/Vandalism – Cyber vandals going after high profile sites or government agencies
Attack Response Protocol
Well, you’ve gone through all your checks and you’re sure of it, you’ve been deemed important enough to attack, it’s definitely a DDoS and it’s the worst form of flattery. Now, you have to move forward – It’s one thing to monitor and confirm, but how do you mitigate?
The first action is to alert your network security provider – but the first step would be to have metrics for Time to Detect and Time to Mitigate already secured in your Service Level Agreement (SLA).
Having your own monitoring in place is crucial but third-party DDoS monitoring is smart. It can also take several hours for mitigation after an attack so it’s important that you have well-defined obligations in place for your mitigation provider specifying their action and response time, as well as parameters for what happens if they can’t meet the agreement.
You also have your own notifying to accomplish which you can partially do via your company status page. Informing your users, stakeholders, and team efficiently can cut down on negative press, response time, and support tickets. Though, in the grim instance of suffering a DDoS attack, you’re probably in for some tense emergency meetings and calls with chief officers.
Learning from a DDoS Attack
Like with any incident, there are things to be learned from an attack – namely, how to better prevent one going forward. Here’s some things to observe:
Identify the type
DDoS attacks fall into two categories:
- Network Level
Network level DDoS attacks overtake the target by flooding all of the available bandwidth.
Application layer DDoS attacks target the application running the service that your users want to access, then consumes the resources for that service like No Face from Spirited Away.
What is the attack targeting?
An attack feels different than a ‘’regular’’ outage but in terms of monitoring and response, it’s just another incident type to be prepared for. Observing the attack and noting the type, origin, and targeted endpoints can make you a less likely target going forward. Is a single page or endpoint being flooded with requests, or are there multiple targets? If one particular service is being targeted take a look at your third-party involvement, API’s and security parameters weak spots.
Another aspect to consider is the cost of server downtime. What services did the DDoS Attack affect, what was the effect on site traffic and revenue, and what is that value compared to what you’re willing to spend on future protection?
Establishing best practices is the best preventive medicine; developing incident response strategies, ensuring your SLA protects you, and regularly monitoring your site will give you the best combined advantage in the event of an incident or attack.
Minute-by-minute Uptime checks.
Start your 21-day free trial with no credit card required at Uptime.com.