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 the following steps:
-
Optionally, set custom Title.
-
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. 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 childexample.com/login
(10 request in minute). This will result in restriction of 50 request in minute for all addresses underexample.com
, except addresses underexample.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 allexample.com
will be 50 request in minute, exceptexample.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:
-
BOLA (Broken Object Level Authorization) enumeration protection for user IDs, object IDs, and filenames
-
Brute force protection for passwords, OTPs, and authentication codes
-
Forced browsing protection (404 probing)
-
Enumeration attack protection, including:
- User/email enumeration
- SSRF (Server-Side Request Forgery) enumeration
- User-agent rotation
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.
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.
-
All traffic Real-time blocking mode 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.