F5 AWAF includes a robust brute force protection feature that employs multiple layers of security measures, such as CAPTCHA integration and IP blocking, to safeguard web applications from unauthorized access attempts. In this section, we will demonstrate how these security measures effectively protect against brute force attacks.

Table of Contents

F5 AWAF Brute Force Mitigation Methods

To begin the demonstration, I will use the security policy created in the previous lesson. This policy is based on the comprehensive security template and is assigned to the Hack-It-Yourself web application, with the enforcement mode set to blocking to block brute force attacks if necessary.

security policy assigned to hack-it-yourself web application
security policy assigned to hack-it-yourself web application

The learning and blocking settings were also configured in the previous lesson. For reference, under “Sessions and Logins” in the learning and blocking settings, there is a violation titled “Brute Force: Maximum login attempts are exceeded,” which is relevant to this demonstration. Ensure that both alarm and block options are enabled for this violation.

enable alarm and block for brute force in learning and blocking settings
enable alarm and block for brute force in learning and blocking settings

Configure Login Page

To configure brute force protection, we also need to inform F5 AWAF of the web application’s login pages. Although this was configured in the previous section, I will review it for clarity.

In the “AUCTION” security policy, under “Sessions and Logins” and “Login Page” properties, we have specified the login page URL address “/user_login.php”, as well as the username and password parameter names, which are “username” and “password” respectively for this web application. We identified these parameters name by inspecting the login page in the previous section.

Additionally, we have configured how F5 AWAF verifies a successful login process. If the login is successful, the user will receive an HTTP response status code 302, indicating a redirection to another page, which signifies successful authentication.

configured login page properties
configured login page properties

Configure brute force prevention page

The core of brute force protection configuration takes place under the security policy settings, specifically in “Advanced Protection” and “Brute Force Prevention“. Here, you can configure brute force detection and prevention methods for each login page.

configure brute force protection and set action to alarm and captcha
configure brute force protection and set action to alarm and captcha

This section offers three main capabilities: “Leaked Credential Detection,” which I will not discuss here, and the focus of this demonstration, “Source-based Brute Force Protection” and “Distributed Brute Force Protection“.

You can configure the number of failed attempts per “username,” “Device ID,” and “IP Address” within a specific “Detection Period” that are considered a brute force attack.

Additionally, you can set how long preventive measures, such as CAPTCHA, will be enforced once a brute force attack, known as the “Maximum Prevention Duration is detected.

For simplicity, I will disable brute force detection based on ‘username‘ and ‘device ID‘ and enable detection solely based on ‘IP Address‘ to simplify understanding. Additionally, I will adjust the number of allowed failed attempts to ‘3’ to make the demonstration easier.

When a brute force attack is detected, we have a few options available to mitigate against the attack, all of which we will demonstrate in this section.

With the “Alarm” action, an event log is generated to notify administrators of a detected brute force attack.

The “Blocking Page” action redirects the attacker to a blocking page, informing them that their access has been temporarily blocked.

The “CAPTCHA” action challenges the suspected attacker with a CAPTCHA to prevent automated scripts from continuing their brute force attack.

The “Client Side Integrity” action runs JavaScript code in your browser to ensure that interactions between your browser and the server haven’t been tampered with by malicious scripts. As a user, you typically won’t notice anything directly, but if there’s an issue such as a failed integrity check, you might encounter CAPTCHA or blocked actions.

The “Drop” action discards brute force attack traffic, preventing it from reaching the web application.

The “Honeypot Page” action redirects the attacker to a honeypot page instead of the actual login or target page. This fake page is designed to look legitimate to deceive attackers and gather information on their activities.

Demonstrate Brute Force Attack Mitigations

Alarm and CAPTCHA

Now we will test each of these actions, starting with “Alarm and CAPTCHA“. For each action, we will also change the client’s IP address since we are monitoring brute force attacks based on IP address. To simulate login failures, we will send empty username and password fields.

login with empty username and password
login with empty username and password

Now, we will submit an empty username and password multiple times to observe the result of the “Alarm and CAPTCHA” action. As expected, the user is prompted to complete a CAPTCHA. Additionally, if we check the event log and filter the logs based on brute force attacks, we can see that the violation “Brute Force: Maximum login attempts are exceeded” has been triggered, and the enforcement action taken is “CAPTCHA.”

the result of faild logins with alarm and captcha as brute force mitigation action
the result of faild logins with alarm and captcha as brute force mitigation action

Alarm and Blocking page

For the next demonstration, we will change the action to “Alarm and Blocking Page.”

After changing the client’s IP address, we will simulate a brute force attack by attempting to log in multiple times with an empty username and password.

As expected, the result of the brute force attack is a blocking page. We can verify this outcome also by checking the application event log.

the result of faild logins with alarm and blocking page as brute force mitigation action
the result of faild logins with alarm and blocking page as brute force mitigation action

Alarm and Drop

Next, we’ll demonstrate “Alarm and Drop“. After changing the client’s IP address, we’ll attempt a brute force attack by submitting multiple empty usernames and passwords on the login page. The result will be that you cannot access the web application because the brute force traffic is dropped.

In the event log, you can observe that the “enforcement action” taken is sending a “TCP Reset” to the client.

the result of faild logins with alarm and drop as brute force mitigation action
the result of faild logins with alarm and drop as brute force mitigation action

Alarm and Honeypot Page

For the next demonstration, we’ll select the “Alarm and Honeypot Page” as brute fore mitigation action and change the client’s IP address accordingly. We will then attempt a brute force attack by submitting multiple empty usernames and passwords on the login page.

As a result, you’ll encounter a page displaying the message “Username or password is incorrect. Please try to log in again“. It’s important to note that this page is not generated by the web application but rather by the honeypot functionality of F5 AWAF.

To verify this, we can check the application event log, where we should see the “enforcement action” listed as “Honeypot Page“.

the result of faild logins with alarm and honeypot page as brute force mitigation action
the result of faild logins with alarm and honeypot page as brute force mitigation action

Alarm and Client Side Integrity

As the final demonstration, we will change the brute force mitigation action to “Alarm and Client Side Integrity“. Before simulating the brute force attack, we will also change the client’s IP address.

The result may not be as visible as with other methods. Typically, you might notice the page pausing briefly without displaying anything, indicating that security measures are actively working in the background.

To confirm this, we can check the event log where the “enforcement action” should be logged as “Client Side Integrity“.

the result of faild logins with alarm and client side Integrity as brute force mitigation action
the result of faild logins with alarm and client side Integrity as brute force mitigation action
Back to: F5 BIG-IP AWAF (formerly ASM) (in Progress) > F5 AWAF Security Policy

Leave a Reply

Your email address will not be published. Required fields are marked *


Post comment