Skip to content

Mitigation Controls

Mitigation controls extend Wallarm's attack protection with additional security measures and allow fine-tuning of the Wallarm behavior.

What you can do with mitigation controls

Using mitigation controls, you can enable and configure:

Mitigation control branches

Mitigation controls are automatically grouped into nested branches by endpoint URIs and other conditions. This builds a tree-like structure in which mitigation control effects are inherited down. Principles:

  • All branches inherit all traffic mitigation controls.

  • In a branch, child endpoints inherit mitigation control effects from the parent.

  • Distinct has priority over inherited.

  • Directly specified has priority over regex.

  • Case sensitive has priority over insensitive.

Enabling

Mitigation controls require

If you have all of this and still, in Wallarm Console, do not see the Security controls → Mitigation Controls section, contact the Wallarm support team to enable them.

Configuration

Perform configuring in the Security controls → Mitigation Controls section of Wallarm Console. You can also access some mitigation control settings from other places in the system, for example, from API Sessions.

Mitigation Controls page in UI

Before configuring, get familiar with the idea of branches and check what already exists.

In general, configuring any mitigation control includes the following steps:

  1. Optionally, set custom Title.

  2. Set conditions (when all met → action).

  3. Set action (mitigation mode).

Scope

Scope defines which requests the control applies to (based on URI and other parameters). It’s configured the same way as request conditions in rules. See details here.

If you leave the Scope section blank, mitigation control is applied to all traffic and all applications; such controls are inherited by all branches.

Advanced conditions

Besides Scope, mitigation control may include other conditions that define whether it will or will not take action, for example:

  • For GraphQL API protection they are policy positions - control will act only if any of them is violated by request.

  • For Enumeration attack protection, they are multiple parameters of requests - control will act only if all specified parameters/values are met.

For some controls, like Enumeration attack protection or Rate abuse protection, in the Scope filters section, you can use the session context parameters to quickly select parameters from the list of ones, that were defined as important in API Sessions. Use the Add custom option in this section to add as filters the parameters that are currently not presented in API Sessions. If you do so, these parameters will be added to API Sessions' context parameters as well (hidden, meaning you will see these parameters in session details if they are presented in requests, but you will not see them in API Session context parameter configuration).

For specifying advanced conditions, you can use regular expressions.

Mitigation mode

When all conditions are met, mitigation control performs its action. The required action is selected in the Mitigation mode section:

Mitigation mode Description
Inherited Mode is inherited from the all-traffic Real-time blocking mode and the configuration of the Wallarm node.
Monitoring Only registers detected attacks; no blocking is performed. Registered attacks are displayed in API Sessions, in the corresponding session details.
For some controls, in this mode, you can also select additional option of adding source IP in the Graylist.
Blocking Registers and blocks attacks. Blocking methods vary by control type: real-time blocking, IP-based blocking, or session-based blocking*.
Excluding Stops this type of mitigation control for the specified scope. See details in Excluding mode vs. disabling.
Safe blocking Registers attacks but blocks them only if the originating IP is graylisted.

* The session-based blocking is not supported so far.

The list of available modes may vary depending on the particular control.

Excluding mode vs. disabling

You can use On/Off switcher to temporarily disable mitigation control and re-enable it when necessary. Consider the example below to understand the difference between disabled mitigation control and the one enabled in Excluding mitigation mode:

  • Consider the fact that controls work in branches.

  • Let's say you have Rate abuse protection control set for example.com (50 request in minute) and control of the same type for child example.com/login (10 request in minute). This will result in restriction of 50 request in minute for all addresses under example.com, except addresses under example.com/login where it will be stricter - 10 request in minute.

  • If you disable (switcher to Off) rate abuse protection control for example.com/login, it will stop doing anything (as if you deleted it) - restriction for all scope will be defined by parent control (50 request in minute).

  • If you re-enable rate abuse protection control for example.com/login and set its mitigation mode to Excluding, it will stop rate abuse protection for this branch - restriction for all example.com will be 50 request in minute, except example.com/login where there will be no restriction of rate abuse protection type at all.

Regular expressions

For specifying different mitigation control parameters, like Scope, Scope filters, and others, you can use regular expressions:

  • The Scope section uses PIRE regular expression library. See details on usage here.

  • Other sections use PCRE. Use the following operators to involve regular expression:

    Operator Description
    ~ (Aa) Find something by case insensitive regexp.
    !~ (Aa) Exclude something by case insensitive regexp.
    ~ Find something by case sensitive regexp.
    !~ Exclude something by case sensitive regexp.

Default controls

Wallarm provides a set of default mitigation controls that, when enabled, significantly enhance the detection capabilities of the Wallarm platform. These controls are pre-configured to offer robust protection against a variety of common attack patterns. The current default mitigation controls include:

All controls from the default set have the Default label. Such controls:

  • Added by Wallarm automatically and enabled (On) for the new clients, disabled (Off) for the rest.

    Absence of default controls

    If you do not see any default controls, except obligatory ones, and do want to explore and try them, contact the Wallarm support team to get them.

  • All are initially applied to all traffic (changeable).

  • All initially use Monitoring mitigation mode (changeable).

  • Cannot be deleted.

  • Can be disabled/re-enabled and edited like all others. Editing allows you to customize any default control based on the specific needs of the application, traffic patterns, or business context. For example, you may adjust default thresholds or exclude specific endpoints via the Scope filters section.

Default mitigation controls

Subject to change

The list of default mitigation controls is subject to change:

  • New controls may be introduced over time.
  • If a mitigation control is disabled, Wallarm may still update its parameters to improve quality and performance.

Obligatory default controls

Ruleset lifecycle

All created mitigation controls and rules form a custom ruleset. The Wallarm node relies on the custom ruleset during incoming requests analysis.

Changes of rules and mitigation controls do NOT take effect instantly. Changes are applied to the request analysis process only after the custom ruleset building and uploading to the filtering node are finished.

Custom ruleset building

Adding a new rule/mitigation control, deleting or changing existing ones in the Wallarm Console → Security Controls → Rules or Mitigation Controls launch a custom ruleset build. During the building process, rules and controls are optimized and compiled into a format adopted for the filtering node. The process of building a custom ruleset typically takes from a few seconds for a small number of rules to up to an hour for complex rule trees.

Uploading to filtering node

Custom ruleset build is uploaded to the filtering node during the filtering node and Wallarm Cloud synchronization. By default, synchronization of the filtering node and Wallarm Cloud is launched every 2‑4 minutes. More details on the filtering node and Wallarm Cloud synchronization configuration →

The status of uploading a custom ruleset to the filtering node is logged to the /opt/wallarm/var/log/wallarm/wcli-out.log file.

All Wallarm nodes connected to the same Wallarm account receive the same set of default and custom rules for traffic filtering. You still can apply different rules for different applications by using proper application IDs or unique HTTP request parameters like headers, query string parameters, etc.

Backup and restore

To protect yourself from accidentally misconfigured or deleted rules, you can backup your current custom ruleset.

There are the following rule backup options:

  • Automatic backup creation after each custom ruleset build. The number of automatic backups is limited to 7: for each day when you change the rules several times, only the last backup is kept.

  • Manual backup creation at any time. The number of manual backups is limited to 5 by default. If you need more, contact the Wallarm technical support team.

You can:

  • Access current backups: in the Rules section, click Backups.

  • Create a new backup manually: in the Backups window, click Create backup.

  • Set name and description for the manual backup and edit them at any moment.

    Naming for automatic backups

    The automatic backups are named by the system and cannot be renamed.

  • Load from existing backup: click Load for the required backup. When loading from the backup, your current rule configuration is deleted and replaced with the configuration from the backup.

  • Delete backup.

    Rules - Creating backup

Rule modification restrictions

You cannot create or modify rules or mitigation controls until creating backup or load from backup is complete.