Two data points are used to determine a baseline of activity:
-
The transaction rate history interval: This is the average number of requests-per-second sent. This number is also tracked as the average number of transactions for the past hour, and is updated roughly every 10 seconds.
-
The transaction rate detection interval: This is the average number of requests-per-second sent, and is what triggers the attack mitigation. This number is calculated at a proprietary interval.
If the ratio of the transaction rate during the detection interval to the transaction rate during the history interval is greater than an automatically or manually specified requests-per-second threshold, OR if the Absolute Threshold is reached, ASM considers the IP address to be malicious.
When you deploy your DoS profile, the thresholds are updated about every hour for the first 24 hours. After that, ASM uses a proprietary algorithm to update the thresholds using different metrics. Using Transparent mode does not impact these calculations. The tricky part in setting an accurate threshold for Device ID, Source IP and URL is that in each application there are different entities functioning at different rates of request-per-second traffic. For example, you might have a few URLs that receive a lot of traffic, but many of these might be accessed only once. A threshold that is good for a resource-intensive URL is lower than a less resource-intensive URL. Generally, we try to mitigate using the least aggressive method first--do a client-side integrity check, then CAPTCHA, then rate limit, then block all. Don't lose sight of the fact that a big goal here is not to interfere with legitimate users. The processing occurs based on which mitigation options you chose in the GUI, from the top down.
Does this help?
Nimbostratus
