Deny rules configuration
Configuration of deny rules

Deny rules establish a negative security model, they are also known as black lists.

They are organized in groups, where each group cover certain aspects of attacks and define conditions for request attributes such as HTTP method, request parameters or headers.

For a request to be blocked by a deny rule group, the following conditions must hold:

  • ●
    Any deny rule in the group must match.
    That is, matching states of deny rules within a group are combined by a logical OR operation.
  • ●
    A deny rule matches if all defined conditions match.
    That is, conditions within deny rules are combined with a logical AND operation.

Default deny rules and group keys

Airlock Microgateway provides a set of default deny rule groups to protect against common attack scenarios. Default deny rule groups are identified by the (default) name prefix and have an individual group key used to identify a group in the DSL configuration. The group key corresponds to the first subtitle of the group's documentation page.

The reference Default deny rule groups shows a complete list of deny rules.

The default mapping template contains the default deny rules being enabled, which can be adjusted for specific mappings by using the DSL.

Basic deny rule settings

Deny rules are configured using the deny_rule_groups node within mappings. All deny_rule_group entries, could have the same basic settings.

Field
Description
enabled
Controls whether the deny rules are enabled or not.
level
Selects the security level (basic, standard or strict). Each deny rule group has preconfigured rules for each level.
log_only
If set to true, matching requests are not blocked. Only a log message is written.
rule_group_keys
Optional set of group keys, selecting the specific deny rule groups for which the settings are made. If this field is empty, all deny rule groups are affected by the settings.
exceptions
Exceptions for deny rules. As an example, parameters resulting in false-positive alerts may be excluded from deny rule matching.

Using deny rule group keys

The various deny rule settings can either be defined for all deny rule groups (field rule_group_keys is empty) or for a specific set of deny rule groups. Deny rule groups are selected by the group key.

The example shows a configuration with two deny rule group configuration sections. The first section enables deny rules with security level "standard". Because the rule_group_keys field is missing, this setting affects all deny rule groups. The second section only applies to the two deny rule groups with keys HTML_PARAM_VALUE and SQLI_PARAM_VALUE. For these groups, the security level is raised to strict and an exception for parameter name "comment" is made.

copy
apps: 
  - mappings: 
      - name: example 
        deny_rule_groups: 
          - enabled: true 
            level: standard 
          - enabled: true 
            level: strict 
            rule_group_keys: 
              - HTML_PARAM_VALUE 
              - SQLI_PARAM_VALUE 
            exceptions: 
              - parameter_name: 
                  pattern: ^comment$

Custom deny rules

In addition to using default deny rules, it is possible to define own custom deny rules. Custom deny rules are defined in the global deny_rule_groups section and must provide a unique rule group key. Using the rule group key, these deny rules can be used within the apps[].mappings.deny_rule_groups[] section, just like default deny rules. Global deny rule settings, i.e., without a restriction to rule group keys, also apply to custom deny rules.

Let's assume we wanted to block all requests with a referrer header "site.ru", a header sometimes used by malicious bots. This example defines a corresponding custom deny rule and shows how to apply it in "log only" mode:

copy
deny_rule_groups:
  - rule_group_key: "CUSTOM_UNWANTED_REFERRER"          
      deny_rules:
        - rule_key: "SITE-RU"     
          header_name:
            pattern: "^Referer$"  # Note: The header is spelled with a single 'r'
          header_value:
            pattern: "^site\.ru$"

apps:
  - mappings:
      - name: example
        deny_rule_groups:
          - log_only: true
            rule_group_keys:
              - CUSTOM_UNWANTED_REFERRER

Custom deny rules are enabled by default. It is possible to define patterns for parameter name/value, header name/value, path, method and content type. Please have a look at the DSL reference for details.

In the community edition, custom deny rules are only available in the "log only" mode. That is, matching requests will not be blocked.

Preference of deny rule settings

Deny rule group settings can be configured for specific groups or globally for all groups. In case there are multiple deny rule configuration sections affecting a deny rule group, the following preferences determine the effective settings:

  • Preference of deny rule settings
  • 1.
    Default settings
  • 2.
    Global settings (i.e., no group is selected)
  • 3.
    Settings specific to a deny rule group (i.e., the group is selected using its group key)

If there are two contradicting settings with the same preference, e.g., both global or for the same group, the last setting in the configuration wins. Otherwise, the sequence of sections has no effect on the preference of settings. Exceptions for specific groups do not replace global exceptions but extend them.

Further information and links