F5 Logo MyF5
Search
  1. MyF5 Home
  2. Knowledge Centers
  3. BIG-IP ASM
  4. BIG-IP Application Security Manager: Implementations
  5. Mitigating Brute Force Attacks
Manual Chapter : Mitigating Brute Force Attacks

Applies To:

Show Versions Show Versions

BIG-IP ASM

  • 13.1.5, 13.1.4, 13.1.3, 13.1.1, 13.1.0
Manual Chapter
Table of Contents | << Previous Chapter | Next Chapter >>
 

About brute force attacks

Brute force attacks are attempts to break in to secured areas of a web application by trying exhaustive, systematic, user name/password combinations to discover legitimate authentication credentials.

To prevent brute force attacks, the Application Security Manager™ tracks the number of failed attempts to reach the configured login URLs. The system considers it to be an attack if the failed logon rate increased at a very high rate or if failed logins reached a certain number.

About configuring brute force protection

You can add default brute force protection when creating a security policy. If you do, the policy simply needs to know for which login pages to enforce brute force protection. The system creates a default brute force configuration that applies to all defined login URLs that are not associated with any other brute force configuration.

You can have the system detect and create login pages automatically, or you can create them manually. But at least one login URL must be defined in the security policy to protect against brute force attacks. Then you can either use the default brute force configuration or create a new configuration.

Brute force security includes both session-based and dynamic brute force protection.

Session-based mitigation
Counts the number of failed login attempts that occur during one session, based on a session cookie. When the number of login attempts during a session exceeds the number specified, the system triggers the Brute Force: Maximum login attempts are exceeded violation, and applies the blocking policy. If the violation is set to block and too many login attempts are made, the client is blocked for a number of seconds.
Dynamic mitigation
Detects and mitigates brute force attacks based on statistical analysis of the traffic. You configure dynamic mitigation to determine when the system should consider the login URL to be under attack, and how to react to an attack. The system mitigates attacks when the volume of unsuccessful login attempts is significantly greater than the typical number of failed logins. You activate this method by setting the operation mode to either alarm or alarm and block.

Overview: Mitigating brute force attacks

You can configure Application Security Manager™ (ASM) to protect against brute force attacks. The system detects brute force attacks based on failed login rates. Therefore, the security policy needs to have login pages for the web applications you want to protect. ASM can create login pages automatically by observing traffic, or you can create them yourself.

Task summary

Creating login pages automatically

Login pages specify a login URL that presents a site that users must pass through to gain access to the web application. Your existing security policy can detect and create login pages automatically if you use certain options.
Note: If you are creating a security policy automatically and selected Comprehensive as the policy template, the default options are already set to create login pages automatically. If you are using the Fundamental policy template, the steps here explain the options to configure ASM™ to automatically detect and create login pages for your application.
  1. On the Main tab, click Security > Application Security > Policy Building > Learning and Blocking Settings .
    The Learning and Blocking Settings screen opens.
  2. Ensure that the Learning Mode is set to Automatic.
    The system examines the traffic to the web application, and after processing sufficient legitimate traffic, the system builds the security policy automatically by adding and enforcing elements with minimal manual intervention. A few learning suggestions require your review before they are added.
  3. In the Policy Building Settings area, expand Sessions and Logins and ensure that Detect login pages is selected.
    This setting must be selected if you want to automatically detect login pages.
  4. In the Policy Building Process area, expand Options and ensure that Learn from responses is selected.
  5. Click Save to save your settings.
  6. In the editing context area, click Apply Policy to put the changes into effect.
The security policy looks for login pages by examining traffic to the web application. When a login page is found, the Policy Builder suggests adding the login form to the security policy. Because the suggestion is learned from responses and responses are considered trusted, if the Learning Mode is Automatic, the login page is typically added to the policy right away.

If the Learning Mode is Manual, the login page is added to the learning suggestions on the Traffic Learning screen where you can add it to the policy. The login pages in the security policy are included in the Login Pages List.

You can use the login pages for login enforcement, brute force protection, or session awareness.

Creating login pages manually

Before you can create a login page manually, you need to be familiar with the login URL or URLs the application the security policy is protecting.
In your security policy, you can create a login page manually to specify a login URL that presents a site that users must pass through to gain access to the web application. The login URL commonly leads to the login page of the web application.
Note: You can also have the system create login pages automatically by selecting Detect login pages on the Learning and Blocking Settings screen.
  1. On the Main tab, click Security > Application Security > Sessions and Logins .
    The Login Pages List screen opens.
  2. In the Current edited security policy list near the top of the screen, verify that the security policy shown is the one you want to work on.
  3. Click Create.
    The New Login Page screen opens.
  4. For the Login URL setting, specify a URL that users must pass through to get to the application.
    1. From the list, select the type of URL: Explicit or Wildcard.
    2. Select either HTTP or HTTPS based on the type of traffic the web application accepts.
    3. Type an explicit URL or wildcard expression in the field.
       
      When you click in the field, the system lists URLs that it has seen, and you can select a URL from the list. Or, you can type explicit URLs in the format /login, and wildcard URLs without the slash, such as *.php.
      Wildcard syntax is based on shell-style wildcard characters. This table lists the wildcard characters that you can use so that the entity name can match multiple objects.
      Wildcard Character Matches
      * All characters
      ? Any single character.
      [abcde] Exactly one of the characters listed.
      [!abcde] Any character not listed.
      [a-e] Exactly one character in the range.
      [!a-e} Any character not in the range.
      Note that wildcards do not match regular expressions.
  5. From the Authentication Type list, select the method the web server uses to authenticate the login URL's credentials with a web user.
    Option Description
    None The web server does not authenticate users trying to access the web application through the login URL. This is the default setting.
    HTML Form The web application uses a form to collect and authenticate user credentials. If using this option, you also need to type the user name and password parameters written in the code of the HTML form.
    HTTP Basic Authentication The user name and password are transmitted in Base64 and stored on the server in plain text.
    HTTP Digest Authentication The web server performs the authentication; user names and passwords are not transmitted over the network, nor are they stored in plain text.
    NTLM Microsoft LAN Manager authentication (also called Integrated Windows Authentication) does not transmit credentials in plain text, but requires a continuous TCP connection between the server and client.
    JSON/AJAX Request The web server uses JSON and AJAX requests to authenticate users trying to access the web application through the login URL. For this option, you also need to type the name of the JSON element containing the user name and password.
  6. In the Access Validation area, define at least one validation criteria for the login page response.
    If you define more than one validation criteria, the response must meet all the criteria before the system allows the user to access the application login URL.
    Note: The system checks the access validation criteria on the response according to the content-type of the login URL. Supported content-types are text/*, application/x-javascript, application/sgml, application/xml, application/x-asp, application/x-aspx, application/xhtml+xml, application/json,application/x-shockwave-flash.  You can use the internal parameter user_defined_accum_type to add supported content-types. 
  7. Click Create to add the login page to the security policy.
    The new login page is added to the login pages list.
  8. Add as many login pages as needed for your web application.
  9. In the editing context area, click Apply Policy to put the changes into effect.
The security policy now has one or more login pages associated with it. They are included in the Login Pages List.
You can use the login pages you created for login enforcement, brute force protection, or session awareness.

Configuring automatic brute force protection

For brute force attack prevention to work, at least one login URL has to be defined. You can define login URLs, or you can let the system detect them automatically (see the sections on creating login pages).

To prevent hackers from gaining access to a web application by performing multiple login attempts, you can add brute force protection to a security policy. You can use a default configuration that is easy to set up, as explained here, or create a custom configuration. The Default brute force configuration implements automatic brute force protection.
  1. On the Main tab, click Security > Application Security > Anomaly Detection > Brute Force Attack Prevention .
    The Brute Force Attack Prevention screen opens where you can view a list of the login URLs that are protected against brute force attacks. The system includes a default configuration that protects all login pages except those which have custom configurations.
  2. In the Current edited security policy list near the top of the screen, verify that the security policy shown is the one you want to work on.
  3. To protect all login pages that are included in your security policy, you can use the Default brute force configuration provided. Click the Login URL to enable the login URL named Default.
  4. To verify the configuration, click the Default login page.
    The default Brute Force Protection Configuration screen opens.
  5. Select the Brute Force Protection check box.
  6. Review the remaining settings. However, using the default values is recommended.
  7. If you made changes, click Save to save them.
  8. To put the security policy changes into effect immediately, click Apply Policy.

The system detects and mitigates brute force attacks based on statistical analysis of failed login attempts. The system protects all defined login pages in the security policy. If you create a custom configuration, the system protects that particular login URL as specified in the configuration. All other login URLs use the default configuration unless you disable it.

Creating a custom brute force protection

Before brute force attack prevention can work, at least one login URL must be defined. You can define login URLs, or you can let the system detect them automatically (see the sections on creating login pages). For brute force protection to work, the Brute Force: Maximum login attempts are exceeded violation must be set to Block and Alarmon the Learning and Blocking Settings screen. The policy's enforecement mode must also be set to Blocking. For selected mitigation actions to work, the mitigation response pages must be configured in Security > Application Security > Policy > Response Pages .

To prevent hackers from gaining access to a web application by performing multiple login attempts, you can add brute force protection to a security policy. Brute force attacks may originate from a single source (Source IP or Device ID) or from multiple sources (a distributed attack). ASM brute force protection detects single source and distributed attacks. Credential stuffing attacks are detected by looking up credentials used in login attempt in a credentials stuffing dictionary.

There are

  1. On the Main tab, click Security > Application Security > Anomaly Detection > Brute Force Attack Prevention .
    The Brute Force Attack Prevention screen opens where you can view a list of the login URLs that are protected against brute force attacks. The system includes a default configuration that protects all login pages except those which have custom configurations.
  2. In the Current edited security policy list near the top of the screen, verify that the security policy shown is the one you want to work on.
  3. To create a custom configuration for a particular login URL, click the Create button.
    Note: Custom configuration of explicit logins for brute force protection is recommended only in cases where your application requires different thresholds for each login URL.
    The New Brute Force Protection Configuration screen opens.
  4. For the Login Page setting, select a previously created login page from the list (or create a new one). If you need to manually create a login page in the security policy, click the Create button.
    The login page specifies the URL that you want to protect against brute force attacks using a configuration different from the default.
  5. For the IP Address Whitelist setting, click the arrow to go to a screen where you can add the IP addresses and subnets from which traffic is known to be safe.
    Important: The system adds any whitelist IP addresses to the centralized IP address exceptions list. The exceptions list is common to both brute force prevention and web scraping detection configurations.
  6. In the Source-based Brute Force Protection area, set the Detection Period.
    The default value is 10 minutes.
  7. Set the Maximum Prevention Duration.
    The default value is 10 minutes.
  8. Set a threshold trigger for a Username and the action to take when the threshold is reached. Use Never to disable monitoring of this element.
    The default failed login attempts is 3. The default action is Alarm and CAPTCHA.
  9. Set a threshold trigger for a Device ID and the action to take when the threshold is reached. Use Never to disable monitoring of this element.
    Note: To use Device ID for tracking, client browsers accessing your web site must be able to accept JavaScript.
    The default failed login attempts is 3. The default action is Alarm and CAPTCHA.
  10. Set a threshold trigger for an IP Address. and the action to take when the threshold is reached. Use Never to disable monitoring of this element.
    The default failed login attempts is 20. The default action is Alarm and CAPTCHA.
    Important: A threshold which is too low will erroneously trigger mitigation on legitimate traffic behind a NAT. If you have a really large NAT, consider adding it to the Whitelist to prevent traffic blockage.
  11. Set the threshold trigger for Client Side Integrity Bypass Mitigation and the action to takewhen the threshold is reached.
    The default successful challenges with failed logins for an IP Address / Device ID / Username is 3. The default action is Alarm and CAPTCHA.
    Important: Legitimate users who have disabled JavaScripting on their browsers for security reasons will fail a client side integrity challenge.
  12. Set a threshold for CAPTCHA Bypass Mitigation and the action to take when the threshold is reached. Use Never to disable monitoring of this element.
    The default CAPTCHA bypass mitigation threshold is 5 successful challenges with failed login attempts from an IP Address / Device ID.
    Note: If CAPTCHA mitigation is not enabled, there is no point in configuring CAPTCHA bypass mitigation. Mitigation responses are configured in Security > Application Security > Policy > Response Pages
  13. In the Distributed Brute Force Protection area, set the Detection Period.
    The default detection period is 15 minutes.
  14. Set the Maximum Prevention Duration.
    The default detection period is 60 minutes.
  15. Set the number of failed login attempts to trigger a Detected Distributed Attack. Use Never to disable monitoring of this element.
    The default number of failed login attempts is 100.
  16. Set the number of login attempts that match known leaked credentials dictionaries to trigger a Detect Crednetial Stuffing attack. Use Never to disable monitoring of this element.
    The default number of login attempts with leaked credentials is 100.
  17. Select the Distributed Brute Force Protection Mitigation option. The default action is Alarm and CAPTCHA.

If a source-based and a distributed brute force attack are simultaneously taking place, the system will take the most severe mitigation action between all the actions that were triggered. This includes actions configured for Username, Device ID, Source IP, Client Side Integrity bypass detection, CAPTCHA bypass detection, and distributed attack detection. For example, a distributed brute force attack has reached its threshold and is set to Alarm and CAPTCHA while a Device ID has reached its threshold and is set to Alarm and Blocking Page, the attacks will be mitigated with Alarm and Blocking Page.

Viewing brute force attack reports

Before you can look at the brute force attack statistics, you need to have configured source-based or dynamic brute force protection.
You can display charts that show information about brute force attacks. A single brute force attack can have hundreds of event logs. The charts provide visibility into what applications are being attacked, the login URL, and start and end times of an attack.
  1. On the Main tab, click Security > Reporting > Application > Brute Force Attacks .
    The Brute Force Attacks reporting screen opens.
  2. From the Time Period list, select the time period for which you want to view information about brute force attacks.
  3. To focus in on the specific details you want more information about, point to the chart or click it.
    The system displays information about the item.
  4. If you want to export the report to a file or send it by email, click Export and select the options.
    To send reports by email, you need to specify an SMTP configuration ( System > Configuration > Device > SMTP ).
You can continue to review the details about brute force attacks on the report screen. As a result, you become more familiar with what caused the attacks and what applications are most vulnerable, and you see the mitigation methods that are in place.

Displaying brute force event logs

You can display event logs to see whether brute force attacks have occurred, and view information about the attacks.
  1. On the Main tab, click Security > Event Logs > Application > Brute Force Attacks .
    The Brute Force Attacks event log opens.
  2. If the log is long, use the Attack Start Time, Number of Login Attempts and/or Newest column heading to filter the list and show more specific entries. For more targeted filtering, open the Filter dialog box (magnifying glass icon).
  3. Review the list of brute force attacks to see which security policy detected the attack, which login URLs were attacked, and the start and end times of the attack.
Table of Contents | << Previous Chapter | Next Chapter >>
Contact Support Contact Support

Have a Question?

Support and Sales >

About F5

Education

F5 Sites

Support Tasks




©2023 F5 Networks, Inc. All rights reserved.


Trademarks Policies Privacy California Privacy Do Not Sell My Personal Information