Sometimes, requests are blocked by deny rules due to content resembling attacks but may be valid for a web application. These blocks are called false positives. You have several configuration options in the CR DenyRules if you have verified that the target web application is working correctly and a blocked request is a false positive.
This article describes how and where to start reducing false positives.
Narrowing down and reducing false positives
This instruction is a best practice for narrowing down and reducing false positives that can be followed in most cases.
While integrating an Airlock Microgateway with an existing application, you can use the threatHandlingMode: LogOnly
to analyze the impact of deny rules on an application running in production. This allows for identifying false positives and configuring exceptions without disturbing productive traffic.
- Analyze the logs to narrow down the
block_reason
,rule_key
etc. of the false positives blocks. See Access log field reference for more information. - Consider choosing a lower security level for the corresponding deny rule group on the affected mapping (e.g., go back from level strict to standard).
- Add deny rule exceptions. Deny rules allow the definition of fine-grained exceptions for all attributes. See CR DenyRules for details, including exceptions for JSON content.
- If the block pertains to a specific deny rule, the rule can be set to
LogOnly
orUnfiltered
to turn off blocking. Note that this should not be done lightly. Instead, you should consider changing the web application if possible. - Check the access logs to verify the deny rule exception works as expected.
Tips for setting up deny rule exceptions
In general, be as specific as possible when defining exceptions. For instance, adding an exception for content type application/pdf
may allow bypassing a deny rule simply by adding a header to requests. Whether or not the content is interpreted as a PDF file depends on the application and cannot be controlled by Airlock Microgateway.
- Possible deny rule configuration options:
- Define a deny rule exception only with
blockedData
. This way, the configured exception is applied unconditionally to all paths, HTTP methods, remote IP addresses, ... - Define a deny rule exception with
blockedData
andrequestConditions
. This is the recommended configuration, as it only applies the exceptions to requests that matches therequestConditions
. - Define a deny rule exception only with
requestConditions
. This configuration should be chosen carefully, as deny rule checks are not applied at all to requests which matches therequestConditions
.
Further information and links
- Internal links:
- CR DenyRules
- Access log field reference