CR DenyRules

Airlock Microgateway has built-in deny rules that effectively block malicious requests to upstream web applications. This deny rule set is constantly evolving and updated to respond to the latest threats.
Each deny rule is identified by a deny rule key that can be referenced for configuration purposes. Each ruleKeys refers to different attack types such as SQL injection, XSS, TEMPLATE injection, etc.

• The CRD DenyRules allows configuring the following in the CR:
• The security level of the applied deny rules.
• The threatHandlingMode (e.g. Block or LogOnly) can be configured globally and on the rule key level.
• Deny rule overrides to change settings (e.g. security level or threat handling mode) of specific deny rules.
• Deny rule exceptions for requests that match one or more deny rules but should not be blocked. Exceptions can be configured and fine-tuned to reduce the number of false positives using blockedData and/or requestConditions based on various characteristics.
• The definition of custom deny rules.

This CR needs to be referenced in the CR ContentSecurity.

For the default and an example configuration including custom rules, see CR Deny Rules reference documentation.

• The example covers:
• spec.request.builtIn.settings – global deny rule settings
• spec.request.builtIn.override – deny rule override, to override the global deny rule settings for some deny rules
• spec.request.builtIn.exceptions – deny rule exceptions
• spec.custom.rules – custom deny rule definition

In addition to the API Reference documentation, this article adds useful background information for the available configuration options.

Different security levels can be configured on global and deny rule levels. This makes it possible to configure the balanced processing of requests with a high level of security and a low number of false positives simultaneously.

For fine-tuning, i.e., to reduce the number of false positives, the security level or the threat handling mode for individual deny rules may be configured differently from the global settings. To do so, configure non-global security levels for deny rules using the ruleKeys or the types element.

For an override example, see CR Deny Rules reference documentation, spec.request.builtInDeny.override.

Deny rule exceptions can be defined for data elements that have been blocked by a deny rule to reduce false positives using:

• blockedData exceptions for blocked data elements, e.g., for blocked parameters, headers or JSON data.
  Note that blockedData only allows requests if the string triggering the false positive was in the configured parameter, header or JSON data.

Example deny rule exception:



apiVersion: microgateway.airlock.com/v1alpha1 
kind: DenyRules 
metadata: 
  name: deny-rules-example 
spec: 
  request: 
    builtIn:
      exceptions:  
        - blockedData: 
            parameter: 
              name: 
                matcher: 
                  exact: search 

The example above creates a deny rule exception for the parameter search

• With this exception, a request with the search parameter is not blocked if the search parameter triggers the deny rule.
• With this exception, a request with the search and language parameter is still blocked if the language triggers the deny rule.

The same mechanism described in the example applies to other blocked data elements such as parameters, headers or JSON data.

See also article Deny rule exceptions for JSON content.

• requestConditions exceptions for general characteristics of blocked requests, e.g. request path or originating remote IP.

• 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 and requestConditions:

This is the recommended configuration, as it only applies the exceptions to requests that matches the requestConditions.

• 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 the requestConditions.

For a deny rule exception example, see CR Deny Rules reference documentation, spec.request.builtInDeny.exceptions.

Custom deny rules can be configured as required to complement the built-in deny rules.

• Difference to built-in deny rules:
• Custom rules can be added in the CR DenyRules.
• Security levels and exceptions cannot be applied to custom deny rules.

If one of the configured rules matches a request, the ruleKey is included in the corresponding access log message. Therefore we recommend using short, descriptive denominations for rule keys.

Note that the ruleKey must be a unique denomination and match ^[A-Z][A-Z0-9_]*$, e.g. ruleKey: MY_CUSTOM_KEY_01.

For a custom deny rule example, see CR Deny Rules reference documentation, spec.custom.rules.

• API Reference:
• CR Deny Rules reference documentation
• CR Content Security reference documentation

• Internal links:
• Deny rule exceptions for JSON content
• Default access log field reference