Dealing with false positives
Dealing with deny rules false positives

Sometimes, requests are blocked by deny rules due to content that resembles attacks but may actually be valid for a certain web application. These blocks are called false-positives. Usually, these kinds of blocks occur during integration or at an early stage after going live.

Search the logs for block messages

Block log messages are generally identified by a log_id starting with WR-SG-BLOCK*.

  • For deny rule blocks, search for:
  • ●
    WR-SG-BLOCK-110-01
  • ●
    WR-SG-BLOCKDET-110-*

Request summary log messages are always a good source of information and could be helpful to compose a deny rule exception. The table below shows how to combine the log information with the corresponding DSL setting to compose a deny rule exception.

Log message id
Log key
DSL key
Example log message
WR-SG-SUMMARY
entry_path
exceptions[].path.pattern
"entry_path":"/contactform/"
WR-SG-BLOCK-110-01
or
WR-SG-BLOCKDET-110-*
rule_group_key
rule_group_keys[]
"rule_group_key":"HTML_PARAM_VALUE"
WR-SG-BLOCKDET-110-05
message
exceptions[].parameter_name.pattern
"message":"Blocked parameter: \"comment=..."

The WR-SG-BLOCKDET-* log messages are only logged in the integration log level.

Resolve the false-positives

After verifying that the blocked request was a false-positive, there are the following options to resolve this issue:

  • ●
    Add a deny rule exception for the blocking deny rule group.

    • To configure a deny rule exception, add the exceptions segment in the deny_rule_groups section of the mapping (see DSL reference).

      The example will add a deny rule exceptions for:

    • ●
      the parameter password on for all deny rule groups.
    • ●
      the parameter comment, on the path /contactform for the deny rule group HTML_PARAM_VALUE.
        mappings:
      - name: example
        entry_path:
          value: /
        ...
        deny_rule_groups:
          - exceptions:
              - parameter_name:
                  pattern: ^password$
          - rule_group_keys:
              - HTML_PARAM_VALUE
            exceptions:
              - path:
                  pattern: ^/contactform
              - parameter_name:
                  pattern: ^comment$

    Check Deny rule exceptions to understand how Airlock Microgateway applies exceptions.

  • ●
    Choose a lower security level for the corresponding deny rule group.
    The example configures security level "strict" for all deny rule groups. For the deny rule group SQLI_PARAM_VALUE the security level will be set to "standard".
    •     mappings:
      - name: example
        entry_path:
          value: /
        ...
        deny_rule_groups:
          - level: strict
          - rule_group_keys:
              - SQLI_PARAM_VALUE
            level: standard