[Suggestion] Custom deny rules should not trigger the Basic Attack Limiter by default

What would you like to be added or improved?

Is the result of a block from a custom deny rule expected to be an attack?

If you create a custom deny rule, the request should just be blocked or even result in a packet drop optionally.
the Basic Attack Limiter should not be triggered by custom deny rules. Instead there might be a third limiter like Basic Block Limit usefull, so that you can differ between real attacks and just blocks.

Another way would be just a checkbox in the deny rules count every block as an attack.

Why is it needed?

If you just want to block access to special ressources or from special sources, you might not want to ban any of those blocks via the Basic Attack Limiter as it might not be considered to be an attack violating the deny rule.

Our current case is a problem with Outlook’s autodiscovery:
Our customer has a lot of different legitimate domains behind our WAF, and obviously all of them have Outlook email addresses. That’s why Outlook tries to read the autodiscover information for every domain from time to time… all at once… which is triggering a 404 error from the upstream server… which in turn is triggering the Basic Error Limit, and so it’s blocking that customer’s employees when they’re working from home without whitelisted IP addresses.

I’ve tried adding autodiscover to a custom block rule, but this results in each attempt being counted as an attack, which is even worse as the Basic Attack Limiter is set up more aggressive than the Basic Error Limit .

Thanks for the detailed explanation. We understand the issue now.
Currently, a request blocked by a custom deny rule is classified as a deny-rule hit and is also counted by the Basic Attack Limiter. As you pointed out, this can be undesirable when the rule is used only to restrict access to a resource, rather than to identify malicious traffic.
Your expected behavior is reasonable: the request should still be blocked and logged as a custom deny-rule event, but it should not contribute to the Basic Attack Limiter by default. An optional per-rule setting such as “count this block as an attack” could provide the required flexibility.
We will evaluate how to separate custom policy blocks from detected attacks without changing the existing blocking behavior. In the meantime, we will also check whether there is a practical workaround for the Outlook autodiscover scenario.
Thanks for the suggestion and the concrete use case.