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

Applies To:

Show Versions Show Versions

BIG-IP ASM

  • 17.1.2, 17.1.1, 17.1.0, 17.0.0
Manual Chapter

Mitigating Brute Force Attacks

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 single source (Source IP or Device ID) and multiple source (a distributed attack) brute force protection.

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.

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.
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.
For brute force protection to work, ensure that the policy's enforcement mode is set to Blocking. If a policy's enforcement mode is set to Transparent, no brute force mitigation action will be performed.
  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
    Brute Force: Maximum login attempts are exceeded
     is enabled for both Alarm and Block.
  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.
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.
    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
    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
Alarm
on the Learning and Blocking Settings screen. The policy's enforcement 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.
  1. On the Main tab, click
    Security
    Application Security
    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.
    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.
    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.
    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
    .
    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
    .
    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.
    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.
Contact Support Contact Support

Have a Question?

Support and Sales >

About F5

Education

F5 Sites

Support Tasks




©2023 F5, Inc. All rights reserved.


Trademarks Policies Privacy California Privacy Do Not Sell My Personal Information