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

The Advanced API Security subscription plan
(most controls) NGINX Node 6.0.1 or Native Node 0.14.1

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.

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

In general, configuring any mitigation control includes 2 steps:

Set conditions (when all met → action).
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.
Blocking	Registers and blocks attacks. Blocking methods vary by control type: real-time blocking, IP-based blocking, or session-based blocking^*.
Disabled	Mitigation control is temporarily turned off and is not applied.
Excluding	Disables this type of mitigation control for the specified scope.
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.

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.

Root controls¶

Some all traffic mitigation controls represent basic Wallarm protection mode and cannot be deleted. They are:

All traffic Real-time blocking mode control
All traffic GraphQL API protection control

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.

Rule modification restrictions

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