Enumeration Attack Protection ¶

Wallarm allows protecting your APIs from the enumeration attacks preventing the reveal of information highly valuable for malicious actors. By identifying valid usernames, email addresses, or system resources, attackers can significantly narrow their focus for subsequent attacks. This reconnaissance phase allows attackers to understand the target system better, potentially uncovering vulnerabilities and enabling the planning of more sophisticated and targeted attacks, ultimately increasing the likelihood of a successful breach.

Requires NGINX Node 6.0.1 or Native Node 0.14.1 or higher.

Mitigation controls¶

Wallarm provides several mitigation controls to configure protection from enumeration. When selecting which control to use, consider the following:

Thus:

• If you want to prevent enumeration of your non-public URLs, use the Forced browsing protection control.

• To prevent enumeration of any parameters you can use the Enumeration attack protection control (this is all-in-one solution).

• If you want to specifically highlight the attempts to get valid passwords by trying variants, use the Brute force protection control.

• If you want to specifically highlight the attempts to enumerate valid user or object ID - the BOLA protection control.

Configuration¶

Configure enumeration protection fulfilling the following steps:

• Define Scope to apply control to (endpoints, only specific requests).

• Select Enumerated parameters - ones to be tracked for enumeration attempts.

• Set Enumeration threshold - control will act if threshold is exceeded.

• If scope does not cover all your needs, set Scope filters.

• Set action in Mitigation mode.

Note that you can use regular expressions to set scope and advanced conditions and select parameters tracked for enumeration.

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.

Scope filters¶

If Scope does not cover all your needs, you can define other conditions that requests must meet to be covered by the protection mechanism.

As conditions, you can use values or value patters of:

• Built-in parameters of requests - elements of meta information presented in each request handled by Wallarm filtering node.

• Session context parameters - 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.

Enumerated parameters¶

In the Enumerated parameters section, you need to select parameters that will be monitored for enumeration. Select set of parameters to be monitored via exact or or regex match (only one approach can be used within single mitigation control).

If for regex you specify both Filter by parameter name and Filter by parameter value, they combine (AND operator), for example (?i)id for name and \d* for value will catch the userId parameter but only count requests having combination of digits as a parameter values.

When some request meets scope and advanced filters and contains unique value for the parameter monitored for enumeration, this parameter's counter gets +1.

Enumeration threshold¶

Brute force, BOLA and generic enumeration protection

These kinds of protection count the number of unique values seen for each enumerated parameter within a specified timeframe (in seconds). Each parameter listed in the Enumerated parameters section is tracked independently.

Once threshold is reached by any of parameters, Wallarm performs action in accordance with the Mitigation mode.

Forced browsing protection

This protection counts the number of unique endpoints accessed in a configured timeframe (in seconds). Once threshold is reached, Wallarm performs action in accordance with the Mitigation mode.

Mitigation mode¶

When any of the counters exceeds the threshold, the selected action is performed:

• Monitoring - the attack is registered, requests that are the part of this attack are marked in API Sessions as belonging to Brute force, Forced browsing, BOLA or generic Enum attack but the requests are not blocked.

• Blocking → Block IP address - the attack is registered, requests that are the part of this attack are marked in API Sessions as belonging to this attack, all source IPs of these requests are placed into denylist for the selected period of time.

Regular expressions¶

The Scope section uses PIRE regular expression library, while advanced conditions use PCRE. Use the following operators to involve regular expression:

Example¶

Let us say your e-commerce E-APPC application stores information about each user's orders under /users/*/orders. You want to prevent malicious actors from getting the list of IDs of that orders. Such list can be obtained via a script trying different combinations of digits. To prevent this, for routes storing orders under each user account, you can set a counter more than 2 unique values in minute - if exceeded, the activity should be marked as attempt to enumerate object's (user order's) IDs (BOLA attack) and source IP should be blocked for 1 hour.

To achieve that, configure the BOLA protection mitigation control as displayed on the screenshot:

In this example, the \d* regex in parameter values stands for zero or more digits - the attempt to enumerate object ID composed of digits.

Viewing detected attacks¶

When enumeration attacks are detected or blocked in accordance with the mitigation mode, they are displayed in the API Sessions section:

You can find sessions with corresponding attack types using the Attack filter; also, if necessary, filter inside session details to see only requests related to the enumeration attack.

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