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.

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

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.

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

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

Example:

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

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