Brute Force Protection

About Brute Force Identity Attacks

Brute force attacks often target identities and their credentials by making multiple automated form submissions. A common attack is to systematically try multiple username/password combinations to brute force entry in to your application.

Common Identity Attacks:

  • Password spraying: Attackers try weak passwords like “Password123” across many different accounts to avoid triggering account lockouts.
  • Credential Stuffing: Attackers use stolen username-password pairs from previous breaches and try them on other services.

These brute force identity attacks are a major security risk because they can lead to account takeover, or to increased support costs caused by account lockouts. Brute force identity attacks can also overwhelm authentication services and cause service disruptions.

How Brute Force Protection works

A failure rate limit on critical paths (like login pages) can effectively mitigate these attacks:
For each IP source address, the number of failed requests are counted. As soon as the counter exceeds the limit during the configured time interval, the response and further requests from the same IP address are blocked (if the path matches).

A request is counted as failed if all of the following conditions are true:

  • The request path matches the Path pattern,
  • the response status code matches the HTTP status pattern (if enabled) and
  • any of the response headers matches the Header name pattern and Header value pattern (if enabled).

Whenever a response is blocked, the corresponding session is also terminated. This prevents an attacker from staying logged in if one of the many requests happen to contain the correct credentials.

Brute Force Protection works similarly to DoS Attack Prevention, but it also checks the response and only counts failed attempts. This means that the failure threshold can be set lower and an attacker can be blocked much earlier.

Configure Brute Force Protection

Steps to protect a login page:

  1. Set Brute Force Protection to ON to enforce the brute force policy.
  2. Configure the Path pattern to match the URL of the form submission.
  3.  
    Info

    To find the form submission URL, inspect the form's action attribute in the html source, or trace the request the browser sends when submitting the form.

    Example form action in html: <form action="/login/">

  4. Figure out how the backend logic distinguishes failed from successful logins. Adjust the HTTP status pattern and the Header name/value pattern to match failed logins.
  5. Reduce the Failure rate limit for testing. You might set the limit to 2 request within 30 seconds.
  6. Activate your changes and try triggering the limit with wrong credentials. You should get an error with status 503 on the third attempt, and further requests should be blocked.
  7. 30 seconds after your first request, you should be allowed to make at least one more attempt, just until you reach the failure limit again.
  8. Once you are certain that these types of brute force attacks are being blocked, reset the Failure rate to the default or to a value that makes sense for your environment.

UI

Description

Log only

If enabled, Airlock Gateway only logs potential attacks, it does not enforce the policy.

Log Message:

WR-SG-BLOCK-163: Brute force protection per client IP: Maximum number of failed responses (10) within 120 seconds exceeded

Source IP exception

Reference to a list of IP addresses that are never blocked. All source IPs matching this list will be excluded from the Brute Force Protection.

Path pattern

A regular expression pattern that must match the request path, e.g. the URL of the form submission. Only matching requests are counted for the failure rate limit.

You may use an entry or back-end path variable for static mappings (e.g. ^%ENTRYDIR%/, see article Entry path as Directory or Regular expression).

Max failed requests per interval

Sets the limit on the number of failed requests from the same IP address. Each time a matching request fails, the counter is incremented. If the counter exceeds this limit within the configured Interval, all requests from that IP address will be blocked.

Default: 10 failed requests

Interval (seconds)

Sets the length of the time interval (duration in seconds) for counting the failed requests. This interval is handled as a sliding window: As soon as the number of failed requests drops below the Max failed requests limit, further requests are allowed again.

Default: 120 seconds

HTTP status pattern

If the HTTP status code of the backend response matches this pattern, the request is counted as a failed request.

By default, status codes 400 and 403 are treated as failure: ^(?:400|403)$

Header name/value pattern

If the HTTP response contains a header matching both the name and value pattern, the request is counted as a failed request.

The default Header pattern matches all responses that redirect the browser to the /login path. In Airlock IAM, this means that the login has failed.

For the Header pattern to be effective, mark it as enabled .

 
Notice

Important: A request is treated as failed if both the HTTP status pattern and the Header name/value pattern match (assuming both are enabled).