Skip to content

Configuration of brute force protection

There are the following classes of brute‑force attacks:

  • Passwords brute‑forcing

  • Session identifiers brute‑forcing

  • Forced browsing (dirbust)

  • Credential stuffing

Behavioral attacks are characterized by a large number of requests with different forced parameter values sent to a typical URL for a limited timeframe.

Detailed brute force description →

Brute force protection restrictions

When searching for brute‑force attack signs, Wallarm nodes analyze only HTTP requests that do not contain signs of other attack types. For example, the requests are not considered to be a part of brute-force attack in the following cases:

These instructions provide steps to configure brute force protection.

Configuration steps

  1. Add the module Brute-force protection to the Wallarm API Security subscription plan. To add the module, please send a request to sales@wallarm.com.

  2. If the filtering node is deployed behind a proxy server or load balancer, then configure displaying of a real IP address of the client.

  3. Configure the trigger Mark as brute force/dirbust.

  4. Test the configuration of brute force protection.

Configuring the trigger to identify brute force

  1. Open the Wallarm Console → section Triggers and open the window for trigger creation.

  2. Select the condition Number of requests and set the request number threshold or leave the default threshold value.

    • If the threshold is exceeded, then the requests will be marked as brute‑force attack.
    • If the threshold is exceeded and the code 404 is returned in the response to all requests, then the requests will be marked as dirbust (forced browsing) attack.
  3. Set the URL to filter all incoming requests by this URL and activate the trigger:

    • If you configure password brute‑forcing protection, then set the URL used for authentication.
    • If you configure dirbust protection, then set the URL of resource file directory.

    URL can be set in one of the following ways:

    • Via the rule defining attack counter for any port listening for incoming requests. The created counter should be selected in the trigger filter Counter name.
    • Via the URL trigger filter if the protected resource listens for incoming requests on port other than 80 or 443. The value should correspond to the format host:port/path (for example: example.com:8888/api/frontend/login).
  4. If required, set other trigger filters:

    • Application the requests are addressed to.
    • One or more IP the requests are sent from.
  5. Select trigger reactions:

    • Mark as brute force/dirbust to mark requests sent after the threshold was exceeded as the brute‑force or dirbust attack. Requests will be marked as an attack but will not be blocked. To block requests, it is required to select one more reaction Blacklist IP address.
    • Blacklist IP address and the period for IP address blocking to add IP addresses from which malicious requests were originated to the blacklist. All requests sent after the threshold was exceeded will be blocked by the filtering node.

Example of a configured rule defining attack counter and trigger:

Brute force/dirbust trigger example

Description of the provided example and other trigger examples used for brute force protection is available within this link.

You can configure several triggers for brute force protection.

Testing the configuration of brute force protection

  1. Send the number of requests that exceeds the configured threshold to the protected URL. For example, 50 requests to example.com/api/frontend/login:

    for (( i=0 ; $i<51 ; i++ )) ; do curl https://example.com/api/frontend/login ; done
    
  2. Open the Wallarm Console → section Blacklist and check that IP address from which the requests were originated is blocked for the period configured in the trigger.

  3. Open the section Events and check that requests are displayed in the list as the brute‑force or dirbust attack.

    Dirbust attack in the interface

    The number of displayed requests corresponds to the number of requests sent after the trigger threshold was exceeded (more details on detecting behavioral attacks). If this number is higher than 5, request sampling is applied and request details are displayed only for the first 5 hits (more details on requests sampling).

    To search for attacks, you can use the filters, for example: dirbust for dirbust attacks, brute for brute‑force attacks. All filters are described in the instructions on search using.

Demo videos