Filtration Mode¶

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)

• Monitoring (monitoring)

• Safe blocking (safe_blocking)

• Blocking (block)

Configuration methods¶

The filtration mode can be configured in the following ways:

• Set the wallarm_mode directive on the node side

• Define the general filtration rule in Wallarm Console

• Define the endpoint-targeted filtration rules in Wallarm Console

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

Setting wallarm_mode directive¶

You can set the node filtration mode on the node side using the wallarm_mode directive. Peculiarities of how the wallarm_mode directive is set in different deployments are described below.

Note that described configuration is applicable only for in-line deployments - for out-of-band (OOB) solutions only the monitoring mode can be active.

docker run -d -e WALLARM_API_TOKEN='XXXXXXX' -e WALLARM_LABELS='group=<GROUP>' -e NGINX_BACKEND='example.com' -e WALLARM_API_HOST='us1.api.wallarm.com' -e WALLARM_MODE='monitoring' -p 80:80 wallarm/node:5.0.2-1

docker run -d -e WALLARM_API_TOKEN='XXXXXXX' -e WALLARM_LABELS='group=<GROUP>' -e ENVOY_BACKEND='example.com' -e WALLARM_API_HOST='us1.api.wallarm.com' -e WALLARM_MODE='monitoring' -p 80:80 wallarm/envoy:4.8.0-1

kubectl annotate ingress <YOUR_INGRESS_NAME> -n <YOUR_INGRESS_NAMESPACE> nginx.ingress.kubernetes.io/wallarm-mode=monitoring

kubectl annotate ingress <KONG_INGRESS_NAME> -n <KONG_INGRESS_NAMESPACE> wallarm.com/wallarm-mode=monitoring

config:
wallarm:
    ...
    mode: monitoring
    modeAllowOverride: "on"

General filtration rule in Wallarm Console¶

You can define the general filtration mode for all incoming requests in Settings → General in the US or EU Cloud.

The general filtration mode setting is represented as Set filtration mode default rule in the Rules section. Note that endpoint-targeted filtration rules in this section have higher priority.

Endpoint-targeted filtration rules in Wallarm Console¶

You can set filtration mode for specific branches, endpoints and relying on other conditions. Wallarm provides the Set filtration mode rule to do this. Such rules have higher priority than the general filtration rule set in Wallarm Console.

To create a new filtration mode rule:

1. Proceed to Wallarm Console:

   • Rules → Add rule or your branch → Add rule.
   • Attacks / Incidents → attack/incident → hit → Rule.
   • API Discovery (if enabled) → your endpoint → Create rule.

2. In If request is, describe the scope to apply the rule to. If you initiated the rule for specific branch, hit or endpoint, they will define the scope - if necessary, you can add more conditions.

3. In Then, choose Set filtration mode and select a desired mode.

4. Save changes and wait for the rule compilation to complete.

Note that to create a filtration mode rule, you can also call the Wallarm API directly.

Prioritization of methods¶

The wallarm_mode_allow_override directive manages the ability to apply rules that are defined on 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 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 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, then 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 Wallarm Console:

1. The filtration mode rules defined in 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 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 Wallarm Console are only applied if they define a filtration mode that is stricter than the monitoring mode.

Configuration example¶

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

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;
        }

        location /main/feedback {
            wallarm_mode safe_blocking;
            wallarm_mode_allow_override off;
        }
    }
}

Rules in 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.

Request examples¶

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 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 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 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 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 Wallarm Console, and the wallarm_mode block; setting for the requests with the /main/apply path in the filtering node configuration file.

• The malicious request with the /main/feedback path is blocked only if it originates from a graylisted IP due to the wallarm_mode safe_blocking; setting for the requests with the /main/feedback path in the filtering node configuration file

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

Best practices on gradual filtration mode application¶

For a successful onboarding of a new Wallarm node, follow these step-by-step recommendations to switch filtration modes:

1. Deploy Wallarm filtering nodes in your non-production environments with the operation mode set to monitoring.

2. Deploy Wallarm filtering nodes in your production environment with the operation mode set to monitoring.

3. Keep the traffic flowing via the filtering nodes in all your environments (including testing and production) for 7‑14 days to give the Wallarm cloud-based backend some time to learn about your application.

4. Enable Wallarm block mode in all your non-production environments and use automated or manual tests to confirm that the protected application is working as expected.

5. Enable Wallarm block mode in the production environment and use available methods to confirm that the application is working as expected.

Was this page helpful?

How can we improve this article? (Optional)

Information is unclear or confusing

Insufficient information

Outdated or incorrect information

0/240

Send