Configure Credential Stuffing and Brute Force Detection

Web Security Manager (WSM) Web Application Firewall (WAF) inline customers can activate detection and prevention of brute force password guessing and credential stuffing by upgrading to appliance version 4.6.2.0 or version 5.0.2.0, both available as of August 04, 2022. Detected activity will be blocked and added to the deny log for the website.

Brute Force Attacks and Credential Stuffing

Credential stuffing and brute force attacks are some of the most common methods for website compromise today. Brute force attacks attempt to guess passwords with no context or clues, using characters at random combined with common password suggestions. Credential stuffing typically uses usernames and passwords obtained from a breach or a phishing attack with the hope that users reuse passwords across platforms. This dramatically increases the opportunity for success.

Detection of these attacks is based on tracking activity on one or more URL paths against a learned baseline. When abnormal increases in activity are detected, WSM challenges the client with a CAPTCHA. The baseline is granular and reflects activity in different days/timeslots. To configure these detection controls, you must define URLs to monitor and how to track HTTP clients (based on source IP). This configuration will decide which clients are asked to solve a CAPTCHA.

The following information describes how to enable several features related to the detection and prevention of credentials stuffing and brute force detection activity.

Solution – Enable Credential Stuffing and Brute Force Detection

1. In the Alert Logic console, navigate to > Configure > WAF > Websites.
   
   
2. Select Manage Website to the right of the website that you want to enable the header for.
   
   
3. Select WAF > Policy, and ensure that the Display preset in the top right corner is set to Advanced.
   
   
4. In the Website global policy section, click to expand Credentials stuffing and Brute Force protection.
   
   
5. At the top right corner of the section, toggle the module status to Active.
   
   
6. To enable CAPTCHA, check the Alert Logic (zero configuration) box under CAPTCHA service.
   
   Note: An activation threshold must be selected below before this is viewable for users, despite this box being checked.
   
   
7. Use the Login URLs text box under Tracking and Enforcement to list any URL paths – such as /path/to/login.php, /api/v1/some-call – for monitor and protection. URL paths must be a full match; regex match or partial URLs will not be accepted.
   
   
8. Click Save to record the module changes.
   
   
9. Click Apply Changes at the top right of the screen to save the policy change(s) made.

Additional Credential Stuffing and Brute Force Detection Configurations

The following options can also be found by following the above steps to the Credentials stuffing and Brute Force protection console and allow you to further configure your credential stuffing and brute force detection.

Note: You must save and apply all changes made in these areas as described above in steps 9 and 10.

Activation Threshold

The activation threshold defines the threshold for when the CAPTCHA service activates and the HTTP client (browser) is required to solve the CAPTCHA in order to continue. The possible values are:

• Off (disabled) – CAPTCHA is never activated.
• Permanent – CAPTCHA is always activated (regardless of the URL accessed).
• 2/3/4/5x increase – CAPTCHA is activated when there is a 2/3/4/5 times increase in login requests compared to the prior seven days calculated Median Absolute Deviation (MAD) value for the website.

MAD is automatically calculated by WSM behind the scenes and once the seven days' worth of login data is collected, WSM will start to enforce the CAPTCHA dynamically, depending on the activation threshold configuration.

Source IP Precision

The Source IP precision option should be set to Off if an attack scenario involves credential stuffing or brute force attacks from a large number of source IPs from different subnets. This scenario will activate the control based on a general surge in activity above an automatically calculated high water mark.

The possible values for source IP precision are:

• Off (default) – all HTTP client IPs are treated the same, meaning they all contribute to the internal score that will dynamically activate the CAPTCHA.
• /24 – /32 – CIDRs block to normalize the HTTP client IP to track connections and login URL requests from clients based on these groups. For example, if several bots all come from a single /24 range and try to brute force a login page, only those clients will be asked to solve a CAPTCHA, leaving other clients uninterrupted.