Mitigation Techniques for DoS and Bot Protection
F5 ASM/AWAF offers a variety of mitigation techniques designed to protect web applications from attacks such as DoS (Denial of Service), bot traffic, and other malicious activities. These techniques can help ensure the integrity of the application, protect user sessions, and minimize the impact of such attacks on the system's performance.
Client-Side Integrity Defense (JavaScript Challenges)
JavaScript Challenges are used to distinguish between legitimate human browsers and automated scripts or bots:
Purpose: This method challenges suspicious IP addresses to execute a JavaScript function, which verifies whether the client is a legitimate browser (capable of executing JavaScript) or an automated script that cannot process such challenges.
Default Status: The default status for this technique is disabled, but it can be enabled when needed.
Operation: When a suspicious request is detected (from a bot or script), the system sends a JavaScript challenge. If the client successfully executes the challenge, it is treated as legitimate. If not, the request can be blocked or flagged as suspicious.
CAPTCHA Challenge
The CAPTCHA (Completely Automated Public Turing Test To Tell Computers and Humans Apart) challenge is a more advanced method of ensuring that requests come from real human users rather than automated bots:
Purpose: ASM/AWAF generates a CAPTCHA challenge and then grades the response. If the client correctly answers the CAPTCHA, it indicates that the client is a legitimate human user.
Usage: This is particularly useful for applications that are under attack from automated bots or scraping tools. By requiring human interaction, it ensures that the traffic is coming from a person rather than a script or bot.
Behavior: If the CAPTCHA challenge is not solved correctly, the request can be blocked or flagged.
Request Blocking (Rate Limit / Block All)
Request Blocking is a technique to mitigate high traffic loads, particularly during a DoS or bot attack. The two options available are:
Rate Limiting:
Purpose: This technique limits the number of requests from an IP address or device within a specific period. It ensures that requests do not exceed a normal threshold, preventing server overloads during an attack.
Default Action: Rate Limiting is enabled by default to prevent excessive request rates.
Mechanism: The system tracks the rate of requests and blocks those exceeding the predefined threshold. If the rate of requests exceeds a set limit, further requests are dropped or delayed.
Block All:
Purpose: This more extreme action completely blocks all requests from the offending IP or client.
Use Case: It’s used when a more drastic mitigation is necessary, such as during a full-blown attack where the threat needs to be completely blocked.
Mechanism: When an attack is detected, the system can drop all traffic from the offending source, preventing the attack from reaching the server.
Prevention Duration and Escalation/De-escalation Periods
F5 ASM/AWAF also provides Prevention Escalation and De-escalation periods, which help control how long and how aggressively mitigation techniques are applied. These settings ensure that the system adapts dynamically to the severity of the attack.
Prevention Escalation Period:
Default: 120 seconds (2 minutes).
Purpose: Specifies the minimum time to apply each mitigation step before moving to the next escalation step.
Behavior: After detecting a DoS attack, the system applies the initial mitigation techniques for the specified escalation period. If the attack is not stopped during this period, the system escalates to the next prevention measure.
Example: During the Prevention Escalation Period, the system might initially apply rate limiting or a CAPTCHA challenge, and after the escalation period, it could block all requests from suspicious IPs.
Prevention De-escalation Period:
Default: 7200 seconds (2 hours).
Purpose: Defines the time spent in the Final Escalation Step before retrying the mitigation steps from the beginning.
Behavior: After the escalation period has passed and the attack has not been fully mitigated, the system enters the de-escalation period, which lasts for the specified duration. Once this period ends, the system can revert to earlier steps, retrying mitigation from the beginning.
Configurable: If the value is set to 0, no de-escalation occurs, and the system will continue applying the final escalation step indefinitely. The de-escalation period must be greater than the escalation period unless set to 0.
Summary of Mitigation Techniques and Prevention Timing
Client-Side Integrity Defense (JavaScript Challenges): Used to ensure that requests come from legitimate browsers and not automated scripts.
CAPTCHA Challenge: Verifies whether a request is from a human user by challenging them to solve a CAPTCHA.
Request Blocking (Rate Limit / Block All): Limits the number of requests from a client or completely blocks requests during an attack.
Prevention Escalation Period: Defines the minimum time spent in each mitigation step before escalating to a more aggressive defense.
Prevention De-escalation Period: Defines the time spent in the final mitigation step before the system retraces its steps or moves to the next level of mitigation.
Last updated