[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 .

Start by tracing how custom deny rules feed the Basic Attack Limiter and how the Basic Error Limit is configured, then review the related limiter tests or entry points. Done should mean that the maintainers have selected and implemented one clear policy for custom blocks, with tests covering the chosen behavior and its interaction with legitimate autodiscovery requests.