Filtration mode configuration¶

Filtration mode defines the filtering node behavior when processing incoming requests. These instructions describe available filtration modes and their configuration methods.

Available filtration modes¶

The Wallarm filtering node can process incoming requests in the following modes (from the mildest to the strictest):

• Disabled (off) → the filtering node:

  • Does not analyze whether incoming requests contain malicious payloads of the following types: input validation attacks, vpatch attacks, or attacks detected based on regular expressions.
  • Does not block requests containing malicious payloads.
  • Does not analyze request sources (does not use IP address lists).

• Monitoring (monitoring) → the filtering node:

  • Analyzes whether incoming requests contain malicious payloads of the following types: input validation attacks, vpatch attacks, or attacks detected based on regular expressions. If malicious requests are detected, the filtering node uploads them to the Wallarm Cloud.
  • Does not block requests containing malicious payloads.
  • Does not analyze request sources (does not use IP address lists).

• Safe blocking (safe_blocking) → the filtering node:

  • Analyzes whether incoming requests contain malicious payloads of the following types: input validation attacks, vpatch attacks, or attacks detected based on regular expressions. If malicious requests are detected, the filtering node uploads them to the Wallarm Cloud.
  • Blocks all requests originated from blacklisted IP addresses.
  • Blocks requests containing malicious payloads if they are originated from greylisted IP addresses.
  • Allows requests originated from whitelisted IP addresses even those containing attack signs. If the whitelisted IP address is duplicated in the blacklist or greylist, the node still allows the request.

• Blocking (block) → the filtering node:

  • Analyzes whether incoming requests contain malicious payloads of the following types: input validation attacks, vpatch attacks, or attacks detected based on regular expressions. If malicious requests are detected, the filtering node uploads them to the Wallarm Cloud.
  • Blocks requests containing malicious payloads.
  • Blocks all requests originated from blacklisted IP addresses.
  • Allows requests originated from whitelisted IP addresses even those containing attack signs. If the whitelisted IP address is duplicated in the blacklist or greylist, the node still allows the request.

Methods of the filtration mode configuration¶

The filtration mode can be configured in the following ways:

• Assign a value to the wallarm_mode directive in the filtering node configuration file

• Define the general filtration rule in the Wallarm Console

• Create a filtration mode rule in the Rules section of the Wallarm Console

Priorities of the filtration mode configuration methods are determined in the wallarm_mode_allow_override directive. By default, the settings specified in the Wallarm Console have a higher priority than the walalrm_mode directive regardless of its value severity.

Specifying the filtration mode in the wallarm_mode directive¶

Using the wallarm_mode directive in the filtering node configuration file, you can define filtration modes for different contexts. These contexts are ordered from the most global to the most local in the following list:

• http: the directives inside the http block are applied to the requests sent to the HTTP server.

• server: the directives inside the server block are applied to the requests sent to the virtual server.

• location: the directives inside the location block are only applied to the requests containing that particular path.

If different wallarm_mode directive values are defined for the http, server, and location blocks, the most local configuration has the highest priority.

The wallarm_mode directive usage example:

http {

    wallarm_mode monitoring;

    server {
        server_name SERVER_A;
    }

    server {
        server_name SERVER_B;
        wallarm_mode off;
    }

    server {
        server_name SERVER_C;
        wallarm_mode off;

        location /main/content {
            wallarm_mode monitoring;
        }

        location /main/login {
            wallarm_mode block;
        }

        location /main/reset-password {
            wallarm_mode safe_blocking;
        }
    }
}

In this example, the filtration modes are defined for the resources as follows:

1. The monitoring mode is applied to the requests sent to the HTTP server.

2. The monitoring mode is applied to the requests sent to the virtual server SERVER_A.

3. The off mode is applied to the requests sent to the virtual server SERVER_B.

4. The off mode is applied to the requests sent to the virtual server SERVER_C, except for the requests that contain the /main/content, /main/login, or the /main/reset-password path.

   1. The monitoring mode is applied to the requests sent to the virtual server SERVER_C that contain the /main/content path.
   2. The block mode is applied to the requests sent to the virtual server SERVER_C that contain the /main/login path.
   3. The safe_blocking mode is applied to the requests sent to the virtual server SERVER_C that contain the /main/reset-password path.

Setting up the general filtration rule in the Wallarm Console¶

The radio buttons on the General tab of the Wallarm Console settings in the EU Wallarm Cloud or US Wallarm Cloud define the general filtration mode for all incoming requests. The wallarm_mode directive value defined in the http block in the configuration file has the same action scope as these buttons.

The local filtration mode settings on the Rules tab of the Wallarm Console have higher priority than the global settings on the Global tab.

On the General tab, you can specify one of the following filtration modes:

• Local settings (default): filtration mode defined using the wallarm_mode directive is applied

• Monitoring

• Safe blocking

• Blocking

Setting up the filtration rules on the "Rules" tab¶

You can fine-tune the filtration mode for processing requests that meet your custom conditions on the Rules tab of the Wallarm Console. These rules have higher priority than the general filtration rule set in the Wallarm Console.

• Details on working with rules on the Rules tab →

• Step-by-step guide for creating a rule that manages the filtration mode →

Setting up priorities of the filtration mode configuration methods using wallarm_mode_allow_override¶

The wallarm_mode_allow_override directive manages the ability to apply rules that are defined on the Wallarm Console instead of using the wallarm_mode directive values from the filtering node configuration file.

The following values are valid for the wallarm_mode_allow_override directive:

• off: rules specified in the Wallarm Console are ignored. Rules specified by the wallarm_mode directive in the configuration file are applied.

• strict: only the rules specified in the Wallarm Cloud that define stricter filtration modes than those defined by the wallarm_mode directive in the configuration file are applied.

  The available filtration modes ordered from the mildest to the strictest are listed above.

• on (by default): rules specified in the Wallarm Console are applied. Rules specified by the wallarm_mode directive in the configuration file are ignored.

The contexts in which the wallarm_mode_allow_override directive value can be defined, in order from the most global to the most local, are presented in the following list:

• http: the directives inside the http block are applied to the requests sent to the HTTP server.

• server: the directives inside the server block are applied to the requests sent to the virtual server.

• location: the directives inside the location block are only applied to the requests containing that particular path.

If different wallarm_mode_allow_override directive values are defined in the http, server, and location blocks, the most local configuration has the highest priority.

The wallarm_mode_allow_override directive usage example:

http {

    wallarm_mode monitoring;

    server {
        server_name SERVER_A;
        wallarm_mode_allow_override off;
    }

    server {
        server_name SERVER_B;
        wallarm_mode_allow_override on;

        location /main/login {
            wallarm_mode_allow_override strict;
        }
    }
}

This configuration example results in the following applications of the filtration mode rules from the Wallarm Console:

1. The filtration mode rules defined in the Wallarm Console are ignored for requests sent to the virtual server SERVER_A. There is no wallarm_mode directive specified in the server block that corresponds to the SERVER_A server, which is why the monitoring filtration mode specified in the http block is applied for such requests.

2. The filtration mode rules defined in the Wallarm Console are applied to the requests sent to the virtual server SERVER_B except for the requests that contain the /main/login path.

3. For those requests that are sent to the virtual server SERVER_B and contain the /main/login path, the filtration mode rules defined in the Wallarm Console are only applied if they define a filtration mode that is stricter than the monitoring mode.

Filtration mode configuration example¶

Let us consider the example of a filtration mode configuration that uses all of the methods mentioned above.

Setting up filtration mode in the filtering node configuration file¶

http {

    wallarm_mode block;

    server { 
        server_name SERVER_A;
        wallarm_mode monitoring;
        wallarm_mode_allow_override off;

        location /main/login {
            wallarm_mode block;
            wallarm_mode_allow_override strict;
        }

        location /main/signup {
            wallarm_mode_allow_override strict;
        }

        location /main/apply {
            wallarm_mode block;
            wallarm_mode_allow_override on;
        }
    }
}

Setting up filtration mode in the Wallarm Console¶

• General filtration rule: Monitoring.

• Filtration rules:

  • If the request meets the following conditions:

    • Method: POST
    • First part of the path: main
    • Second part of the path: apply,

    then apply the Default filtration mode.

  • If the request meets the following condition:

    • First part of the path: main,

    then apply the Blocking filtration mode.

  • If the request meets the following conditions:

    • First part of the path: main
    • Second part of the path: login,

    then apply the Monitoring filtration mode.

Examples of requests sent to the server SERVER_A¶

Examples of the requests sent to the configured server SERVER_A and the actions that the Wallarm filtering node applies to them are the following:

• The malicious request with the /news path is processed but not blocked due to the wallarm_mode monitoring; setting for the server SERVER_A.

• The malicious request with the /main path is processed but not blocked due to the wallarm_mode monitoring; setting for the server SERVER_A.

  The Blocking rule defined in the Wallarm Console is not applied to it due to the wallarm_mode_allow_override off; setting for the server SERVER_A.

• The malicious request with the /main/login path is blocked due to the wallarm_mode block; setting for the requests with the /main/login path.

  The Monitoring rule defined in the Wallarm Console is not applied to it due to the wallarm_mode_allow_override strict; setting in the filtering node configuration file.

• The malicious request with the /main/signup path is blocked due to the wallarm_mode_allow_override strict; setting for the requests with the /main/signup path and the Blocking rule defined in the Wallarm Console for the requests with the /main path.

• The malicious request with the /main/apply path and the GET method is blocked due to the wallarm_mode_allow_override on; setting for the requests with the /main/apply path and the Blocking rule defined in the Wallarm Console for the requests with the /main path.

• The malicious request with the /main/apply path and the POST method is blocked due to the wallarm_mode_allow_override on; setting for those requests with the /main/apply path, the Default rule defined in the Wallarm Console, and the wallarm_mode block; setting for the requests with the /main/apply path in the filtering node configuration file.