CR DenyRules

Airlock Microgateway has built-in deny rules to 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 ruleKey refers to different attack types such as SQL injection, XSS, GraphQL, TEMPLATE injection, etc.

• The CRD DenyRules allows configuring the following in the CR:
• The security level of the applied deny rules.
• The threatHandlingMode (i.e., Block or LogOnly) can be configured globally and on the ruleKey level. Non-deny rule depending threatHandlingMode can be configured on feature level, i.e. Limits, OpenAPI and GraphQL within their CR.
• 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 DenyRules 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 helpful 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.

Deny rule exceptions can be defined for different data elements.

• Data element types for exceptions:
• blockedData for exceptions on 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.
• requestConditions, to create 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.

Note that exceptions will only reduce blocks if the configured exception covers all data elements that trigger deny rules.

For example, if an exception is configured to unblock search parameters, a request containing a search and a language parameter could still be blocked if the language parameter triggers a deny rule. The same mechanism applies to other blocked data elements such as parameters, headers or JSON data.

Body data of requests with content-type header application/json are parsed as JSON content and might cause false positives. Deny rule exceptions can be defined for JSON keys or values based on the access log information. Additionally, exceptions can be restricted to a defined JSONPath. In the JSONPath expressions, wildcards (*) can be used, like in this JSONPath syntax reference.

Example:

{ 
  "books": [ 
    { 
      "title": "DevSecOps Starters Guide", 
      "author": "Joe Bloggs", 
      "stars": 723 
    }, 
    { 
      "title": "JSONPath for Geeks", 
      "author": "Jane Smith", 
      "stars": 27 
    } 
  ] 
}

This JSON example contains 6 key-value pairs (aka leaves), 3 pairs for each book. The values of the JSON leaves can be filtered with the corresponding JSONPath from the following table.

JSONPath          | Value 
------------------|---------------------------- 
$.books[0].title  | "DevSecOps Starters Guide", 
$.books[0].author | "Joe Bloggs", 
$.books[0].stars  | 723 
$.books[1].title  | "JSONPath for Geeks", 
$.books[1].author | "Jane Smith", 
$.books[1].stars  | 27

• Additional JSONPath examples:
• $..author – matches every leaf of the key author (Joe Bloggs and Jane Smith) in every book.
• $.books[*].author – matches every leaf of the key author in all books.

For instance, an exception for all books of authors named Joe can be configured as follows.

Example:

copy

apiVersion: microgateway.airlock.com/v1alpha1
kind: DenyRules
metadata:
  name: my-webapp
 spec: 
  request: 
    builtIn:
      exceptions: 
        - blockedData: 
            json: 
              jsonPath: $.books[*].author 
              value: 
                matcher: 
                  contains: Joe

• For deny rule exceptions, operators [] with expressions and script expressions are not supported. For example, $..book[?(@.age)].title does NOT work as JSONPath expression.
• The JSONPath expression must always match a leaf. For example, $.books[*] does not contain a leaf and will not work, whereas $.books[*].author does.

Custom deny rules can be configured 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.

• API Reference:
• CR DenyRules reference documentation
• CR ContentSecurity reference documentation

• Internal links:
• Reducing false-positive blocks
• Access log field reference

• External links:
• JSONPath syntax reference