6 Tips for Preventing DDoS Attacks Using Rate Limits
Rate limiting is a well-known technique for limiting network traffic to web servers, APIs, or other online services. It is also one of the methods available to you for blocking DDoS attackers from flooding your system with requests and exhausting network capacity, storage, and memory.
You typically define rate-limiting rules in your Web Application Firewall (WAF), where you set a limit on the number of requests that can be made within a specific time frame. When the limit is reached, the system can either delay or reject further requests.
While rate limiting is an important tool, it requires careful tuning or else it can create false positives and block legitimate traffic. Also, rate limiting cannot help against more complex attacks, such as large botnets that send a small number of requests from each IP that together bring down the system. Additional methods are required to protect against more sophisticated attacks.
Here are six tips for using rate limiting efficiently to block DDoS attacks.
1. Use granular rules
The key challenge with rate limiting is ensuring that it does not block legitimate traffic while identifying harmful attacks. The solution is creating rules that are tailored to fit the various parts of your website and services that need protecting.
Subdomain rules allow you to impose limitations for specific areas or services while reducing the possibility of false positives. For example, an API-specific sub-domain of a gaming company.
Specific path rules are more difficult to maintain, so we recommend you use them only for sensitive paths, such as login pages, which often require extensive backend resources. You can set a low threshold for a path without risking false positives.
2. Apply rules only to non-cached assets
Assuming you have a CDN, then use rate-limiting rules only for pages and assets that are not cached. Cached elements are delivered by the CDN and do not reach your origin servers. This will allow you to define more efficient rules with lower thresholds.
3. Define bad actor rules
Different WAF solutions use different scoring techniques to assess whether a request is valid or was submitted by an automated machine or a malicious user. For example, Cloudflare has a “Bot Score” indicating how likely it is that a request came from a bot.
We recommend creating a rule with a lower threshold that will encompass only suspicious requests, in order to improve protection without impacting legitimate users. Also, be aware that hackers continually find new tools to bypass vendor mechanisms.
4. Use error-response rules
Another technique is a rate limit that is triggered by requests receiving 4xx or 5xx server errors. If a user or source IP continues sending requests after receiving such error messages several times, then it is safe to assume it is attempting to scan or cause damage to the service.
While such rules may not succeed in blocking an attack, they may help identify the attack source during recovery.
5. Set response actions to match the threat
For any violation of a rate-limiting rule, you can define a corresponding action. Naturally, you want to correlate the response ‘severity’ to the rate limit violation and the desired level of user impact.
Log – We recommend you use “log mode while setting up and tuning rate-limit rules. This will allow you to evaluate the effect of the rules and the number of false positives without any impact on legitimate users.
JavaScript Challenge – This tactic involves presenting a transparent JavaScript challenge for user verification. This is a low-impact action, as it is invisible to users and easily handled by most web browsers.
CAPTCHA – This web challenge requires user completion to proceed, adding an extra layer of verification. This is a more ‘aggressive’ response that should be used with care.
Block Request – You can choose to drop a request, preventing it from being forwarded to the origin server, immediately halting a specific potential threat. This approach is not typically recommended. Instead, we advise blocking a suspect user.
Block User – This response places the user in a ‘penalty box’ for a predefined period, dropping all subsequent requests as a deterrent against malicious activities.
6. Tune the rules
It is crucial that you tune the thresholds of your rate-limiting rules, in order to ensure that they do not compromise user experience and, at the same time, are effective in blocking illegitimate traffic. That’s why we recommend using the “log mode” while initially setting up rate-limit rules. This will allow you to evaluate their effect, gauge the number of expected false positives, and fine tune them with no impact on legitimate users.
Tuning must also be done on a regular basis in order to ensure ongoing effectiveness and service continuity. You want to reach the best threshold balance between accessibility and protection. A general rule of thumb is that you block only a single legitimate user per month.