Custom deny rules

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

  • Custom deny rules work exactly in the same way as built-in deny rules but differ from these in the following:
  • Custom rules can be added in the CR DenyRules. See the example below.
  • Security levels and exceptions cannot be applied to custom deny rules.

Example configuration

  • Custom deny rules are defined using the following elements:
  • ruleKey must be a unique denomination and match ^[A-Z][A-Z0-9_]*$, e.g., ruleKey: MY_CUSTOM_KEY_01.
  • threadHandlingMode can be set to LogOnly to avoid blocking requests when a custom deny rule matches.
  • blockData specify request data that are blocked by the custom deny rule.
  • requestConditions add conditions that must match for the custom deny rule to match. Note that requestConditions may also be used without blockData to block all requests meeting the specified conditions.

The following configuration example contains rules to block requests with specific referrer headers, parameter and media types:

copy
apiVersion: microgateway.airlock.com/v1alpha1  
kind: DenyRules  
metadata:  
  name: deny-rules-sample  
spec:
  request: 
    custom: 
      rules: 
        - ruleKey: CM_REFERRER_BLOCK 
          blockData: 
            header: 
              name: 
                matcher: 
                  exact: referer 
              value: 
                matcher: 
                  regex: .*bad.tv 
        - ruleKey: CM_BAD_PARAM_BLOCK 
          blockData: 
            parameter: 
              name: 
                matcher: 
                  exact: bad-param 
              value: 
                matcher: 
                  exact: bad-value 
        - ruleKey: CM_LOG_UNWANTED_JSON_DATA 
          threatHandlingMode: LogOnly 
          blockData: 
            json: 
              value: 
                matcher: 
                  exact: bad-value 
                  ignoreCase: false 
          requestConditions: 
            path: 
              matcher: 
                prefix: /api/ 
...

The rule LOG_UNWANTED_JSON_DATA uses both blockData and requestConditions to restrict the rule scope. See also CR Deny Rules reference documentation.
The example also uses threatHandlingMode: LogOnly to log unwanted JSON values without actually blocking any requests.

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.

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