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 of these deny rules 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 global security level.
• The threadHandlingMode (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.

General tips for working with CRs

• CLI:
• Use kubectl explain <replace with CRD name> --recursive to list all available options and the YAML structure.
• Check the CRD description texts with kubectl explain <replace with CRD name and path> of the available options for more details.

• API Reference documentation:
• Click on the link to open the CR-related documentation in a new browser tab or window: CRD Reference documentation. See also the API Reference documentation links at the end article.

copy

apiVersion: microgateway.airlock.com/v1alpha1 
kind: DenyRules 
metadata: 
  name: deny-rules-sample 
spec: 
  request: 
    builtIn: 
      settings: 
        level: Strict 
        threatHandlingMode: Block 
      overrides:  
        - conditions: 
            ruleKeys: 
              - XSS 
          settings: 
            level: Standard 
      exceptions: 
        - blockedData: 
            parameter: 
              name: 
                matcher: 
                  exact: search 
              source: Post  
          requestConditions: 
            path: 
              matcher: 
                regex: ^/member/ 
            method: 
              - POST             
          ruleKeys: 
            - SQL   

In our example, the global security level is set to Strict. This setting is overridden for the rule key XSS, which is set to Standard. An exception is defined for SQL Injection deny rule that matches the parameter search in POST requests for the path ^/member/. Therefore, the Post parameter search is not checked against SQL deny rules if it was a POST request with the path starting with /member/.

See also the API Reference documentation link at the end of this article.

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.

See also the API Reference documentation link at the end of this article.

The global built-in deny rule settings are applied to all built-in deny rules, except the ones with overrides.

Example:

apiVersion: microgateway.airlock.com/v1alpha1 
kind: DenyRules 
metadata: 
  name: deny-rules-sample 
spec: 
  request: 
    builtIn: 
      settings: 
        level: Strict 
        threatHandlingMode: Block
...

In our example, the built-in deny rules are applied with the global security level Strict and thread handling mode Block.

See also the API Reference documentation link at the end of this article.

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 security level. To do so, configure non-global security levels for deny rules using the ruleKeys or the types element.

Example:

...
      overrides:  
        - conditions: 
            ruleKeys: 
              - XSS
            types:
              - Parameter  
          settings: 
            level: Standard 
 ...

In this example, the global security level Strict is overridden with security level Standard for the XSS deny rule check for parameters.
This means that the built-in XSS deny rule will be applied with security level Standard on parameters, whereas all other built-in deny rules will still be applied with security level Strict.

See also the API Reference documentation link at the end of this article.

• 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 headers and parameters or for blocked JSON data.
• requestConditions exceptions for general characteristics of blocked requests, e.g. request path or originating remote IP if used without blockedData.

Both must match when using blockedData and requestConditions in conjunction to fulfill the exception.

The request conditions should be chosen carefully, especially when used without blockedData, as this can bypass the denial rules' security measures altogether. We recommend configuring a combination of blockedData and requestConditions for each exception to a deny rule, if possible.

Example:

...
      exceptions: 
        - blockedData: 
            parameter: 
              name: 
                matcher: 
                  exact: search 
              source: Post  
          requestConditions: 
            path: 
              matcher: 
                regex: ^/member/ 
            method: 
              - POST             
          ruleKeys: 
            - SQL

...  

This example defines an exception for the SQL deny rule on the Post parameter search. The exception will only apply to POST requests with a path starting with /member/.
Another possible requestConditions configuration option would be header identified by name and/or value.

See also the API Reference documentation link at the end of this article.

The CR DenyRules needs to be referenced in the CR ContentSecurity.

...
spec:
  filter:
    denyRulesRef:
      name: deny-rules-sample
...

Replace the name: in our example with the actual name from the metadata section of the respective DenyRules CR.

See also the API Reference documentation link at the end of this article.

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

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