I want to protect the company transactional website from L7 DoS/DDoS attacks using the DOS profile.
Users access to the website via web browsers and mobile applications.
In order to avoid false positives and unwanted service cut, I have gone through the official documentation, I will use the automatic Thresholds mode and I will run the profile on the transparent mode for 7 days, but I still have some technical questions :
When setting up either transaction-based or stress-based DoS protection, the mitigation methods are the JavaScript challenges or the CAPTCHA challenges, which are not compatible with mobile applications, thus the only mitigation method that can work is the rate limit :
In case of Thresholds Mode set to automatic, how does rate limit work? is there a difference between the rate limit mechanism used for transaction-based and stress-based DoS protection? it Will not impact the mobile application users experience?
knowing that the same VS is used for both user access types (browsers and mobile application), which scenario do you recommend:
S1: Use only the rate limit as mitigation method.
S2: configure a Irule to disable DOS profile for mobile application (using User agent string matching), and apply the 3 mitigation methods available for the browsers access.
Suppose the CAPTCHA is configured as a mitigation method, when a DoS/DDoS attack is detected and the mitigation is launched, is the WAF going to present the CAPTCH for all users or only for those who are suspicious? in this case is there difference between transaction-based and stress-based?
The WAF is based on the access history to identify the number of TPS expected at a given moment
what is the % thresholds from which the WAF considers a traffic as a DDoS attack, for example if the expected TPS is 100, what should be the reel received TPS to consider it as a attach (120 TPS, 140 TPS, …) ?
1. How do auto-thresholds work? When you build policy automatically, it understands the traffic, per-URI, and gets an idea of how many PPS, TPS and req/resp sizing of packets and flows. Again.. PER-URI. So the thresholds know if a URI typically has a 5k req. and gets a 500k resp. normally. It will threshold to the peak. If the VIP is variable, it will understand that, as well and ends up thresholding more to the delta between req / resp to understand that a resp could be proportionately larger as per the difference between the smallest respones and the peak.
2. I would not recommend that you use one policy for mobile and browser based. Maybe one VIP, but you should definitely select policy based on EUD.
3. You would do it either way. Can you show me the screen where you're mitigating DoS with CAPTCHA? You're talking about AFM as though it's a WAF. Are you using AFM or AWAF (ASM)?
4. It considers that threshold as whatever you set it to.
Quick thing.. DoS profiles usually work to defend against UDP / TCP / packets.
L7 is not done with a DoS profile unless you're doing DPI.. which is disctinctly NOT WAF.
Please just tell me what you want to do.. zIt sounds like you need AWAF, not AFM.
I saw you already got an answer. But I would like to mention the configuration I usually use to mitigate L7 HTTP/s DoS attacks.
My typical recomendation is to use BaDoS only. -Don´t use it together with TPS or stress-based!
From the screenshot you can take the config. BaDoS is a layered DoS protection, which means it has multiple options mitigation, but it does only kick in, when your server is under stress!
To get the details on traffic, stress, mitigation, ... etc you can go to the BaDoS dashboard. You find this in the drop-down menu of the BIG-IP dashboard.
