Manual Chapter : Mitigating Brute Force Attacks

Applies To:

Show Versions Show Versions

BIG-IP ASM

  • 12.1.6, 12.1.5, 12.1.4, 12.1.3, 12.1.2, 12.1.1, 12.1.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 using the Deployment wizard. 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 Enhanced or Comprehensive as the policy type, the default options are already set to create login pages automatically. If you are using the Fundamental or Custom policy types, 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 policy list near the top of the screen, verify that the edited security policy 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 policy list near the top of the screen, verify that the edited security policy 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. Ensure that the Brute Force Protection check box is selected.
  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). To use session-based protection settings, the Brute Force: Maximum login attempts are exceeded violation must be set to block on the Learning and Blocking Settings screen.

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 create a custom configuration for specific URLs and use the system-provided default configuration for the rest.
  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 policy list near the top of the screen, verify that the edited security policy 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, 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 Session-based Brute Force Protection area, for the Login Attempts From The Same Client setting, type the number of times a user can attempt to log in before the system blocks the request.
    The default value is 5.
  7. For Re-enable Login After, type the number of seconds the user must wait to attempt to log in after they have been blocked.
    The default value is 600 seconds.
  8. If you want to track failed login attempts by device ID, select the Use Device ID check box.
    Note: To use device ID for tracking, client browsers accessing your web site must be able to accept JavaScript.
  9. In the Dynamic Brute Force Protection area, for Operation Mode, select how the system handles dynamic brute force attacks.
    Option Description
    Off The system does not check for brute force attacks.
    Alarm The system logs brute force attack data.
    Alarm and Block In addition to logging the attack data, the system drops requests from the offending IP address, or requests to attacked URLs, depending on how the attack was detected.
  10. If the security policy is in transparent mode, the system displays a note under the Operation Mode setting. If you want the system to block brute force attacks, in the note, click the Learning and Blocking Settings link to go to that screen.
    1. In the General Settings, set the Enforcement Mode to Blocking.
      This setting blocks all requests that cause violations, which are set to block.
    2. In the Policy Building Settings, under Sessions and Logins, verify that the Brute Force: Maximum login attempts are exceeded violation is set to Learn, Alarm, and Block.
    3. If you changed the learning and blocking settings, click Save.
    4. Click the browser back button to return to the Brute Force Protection Configuration screen.
  11. For the Measurement Period, type the number of seconds (from 1-60) within which to measure failed login attempts.
    For example, define a brute force attack as 8 login attempts in 5 seconds, type 5 as the Measurement Period and in the Detection Criteria, for Failed Login Attempts Rate reached, type 8.
    Important: If the Measurement Period is greater than 1, the system uses only the Failed Login Attempts Rate reached value to detect an attack, and not the Failed Login Attempts increased by percentage. Also, all traffic from suspicious IP addresses is blocked.
  12. For the Detection Criteria setting, specify when to consider login attempts to be an attack.
    Option Description
    Minimum Failed Login Attempts Indicates an attack if, for all IP addresses tracked, the number of login attempts is equal to, or greater than, this number. This setting prevents false positive attack detection. The default value is 20 login attempts per second.
    Failed Logins Attempts increased by Indicates an attack if, for all IP addresses tracked, the ratio between the detection interval and the history interval is greater than this number. The default value is 500 %.
    Failed Login Attempts Rate reached The system considers unsuccessful login attempts to be an attack if, for all IP addresses tracked, the login attempt rate reaches this number. The default value is 100 login attempts per second.
    Here's how it works:
    • First, the Minimum Failed Login Attempts has to be reached.
    • Then either the Failed Logins Attempts increased by percent or the Failed Login Attempts Rate reached number must be reached.
    • When both conditions are met, ASM™ considers the attempts to be a brute force attack.
  13. For Suspicious Criteria (per IP address), specify how to identify a potential attacker’s IP address. If at least one of the criteria is met, the system treats the IP address as an attacker, and prevents the attacker from trying to guess the password. The system also limits the number of login attempts to the normal level.
    1. Type a number for Failed Login Attempts increased by criteria. An individual IP address is suspicious if the number of login attempts has increased by this percentage over the normal number of failed logins. The default setting is 500 percent.
    2. Type a number for Failed Login Attempts Rate reached. An individual IP address is suspicious if the number of login attempts per second from that IP address is equal to or greater than this number. The default setting is 20 login attempts per second.
    If either of these numbers is reached, the system limits the number of login attempts to the history interval.
  14. For the Prevention Policy setting, select one or more options to determine how you want the system to handle a brute force attack.
    Note: If you enable more than one option, the system uses the options in the order in which they are listed.
    Option Description
    Source IP-Based Client-Side Integrity Defense Determines whether a client is a legal browser or an illegal script by injecting JavaScript into responses when suspicious IP addresses are requested. Legal browsers can process JavaScript and respond properly, whereas illegal scripts cannot. The default is disabled.
    URL-Based Client-Side Integrity Defense Determines whether a client is a legal browser or an illegal script by injecting JavaScript into responses when suspicious URLs are requested. Legal browsers can process JavaScript and respond properly, whereas illegal scripts cannot. The default is disabled.
    Source IP-Based Rate Limiting Drops requests from suspicious IP addresses. The system limits the rate of requests to the average rate prior to the attack, or lower than the absolute threshold specified by the IP detection TPS reached setting. The default is enabled.
    URL-Based Rate Limiting Indicates that when the system detects a URL under attack, Application Security Manager™ drops connections to limit the rate of requests to the URL to the average rate prior to the attack. The default is enabled.
  15. For Prevention Duration, specify how long the system should mitigate brute force attacks.
    • To perform attack prevention until the end of the attack, select Unlimited .
    • To limit attack prevention to the amount of time configured here (even if the attack continues) or until the system detects the end of the attack, select Maximum and type the number of seconds to perform attack prevention.
  16. To add the custom brute force configuration to the security policy, click Create.
    The screen refreshes, and you see the protected login URL in the list.
  17. 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 to the specified login URL. The system protects that particular login URL as specified in the custom configuration. All other login URLs associated with the security policy are protected using the default configuration unless you disable it.

Viewing brute force attack reports

Before you can look at the brute force attack statistics, you need to have configured session-based or dynamic brute force protection.
You can display charts that show information about brute force attacks. 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 Security Policy and/or Time Period settings to filter the list and show more specific entries.
  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.