When a denial-of-service incident occurs, you won’t have time to consider and decide on your mitigation options. It’s important to consider them before an incident happens, and make sure your controls are configured to mitigate the attack automatically and that your team knows how to respond.
All mitigations need to be tuned to your systems, to ensure they kick in before your system is knocked offline. Without proper tuning, it is possible that a small number of requests to computationally expensive resources could take down a service, while the protection service does not see anything “wrong”.
Types of attack mitigations
To reduce the impacts of a DoS incident, there are several mitigation options to consider. Some examples are:
- Traffic scrubbing
DDoS protection companies can act as intermediaries, so that your system’s traffic goes through their network first. This lets them remove or “scrub” the bad traffic. The service may just scrub out volumetric attacks, or it might also protect against protocol and application layer attacks, using some of the other mitigation techniques below.
- Source or location blocking
One of the most common mitigations is a source or location block, which involves adding the IP address, CIDR range, or geolocation to the ‘deny list’ on your network device or Content Distribution Network (CDN).
This form of mitigation may lead to a whack-a-mole situation where the attacker simply performs their attack from a different IP address range or geolocation. It should be paired with another mitigation in case the attacker tries again. - Pattern and behaviour blocking
Another common mitigation is to block traffic matching a specific pattern or behaviour. The network device or CDN you use to manage traffic may be able to learn normal user patterns, and block any traffic that sits outside this pattern. They may also be able to block common attack patterns, such as strings of oversized or malformed packets.
- Disabling dynamic functions
If your website loads a lot of dynamic content, you might want to consider disabling this content during an attack. For example, if your website loads large amounts of graphs from your back end servers on each request, you could disable these features, or pages, to reduce the number of back end server calls. Doing this means your system can handle more requests during the attack.
- Displaying CAPTCHA
For application layer DoS attacks, you could serve CAPTCHA challenges for any requests that may be bot traffic. That way, each request would require a valid CAPTCHA response before being submitted back to your server.
Using CAPTCHA challenges should be discussed with your technical and business teams, as they can present some accessibility challenges to your genuine users.
It’s important to make sure the mitigations you have in place kick in at the right threshold. This is why being prepared and understanding the capacity of each layer of your infrastructure is so important. When a DoS event happens, you will be squeezed for time.
Additional incident response steps
Aside from considering the mitigations, there are two other key actions to include in your DoS incident plan.
Checking for other events
A DoS attack can be simple to execute, and can fill up your logs and distract you from other events. It’s important that your incident response playbook includes a step to keep a close eye on other network or application events and logs to make sure that this attack isn’t just a distraction.
Off-network communications
You may discover your key communication systems, such as Voice Over IP (VOIP) phones or email, are also affected during a DoS attack. Having off-network communications for your incident response team, such as a cloud-based team communication tool or secure mobile group chat such as Signal, are important as a backup.