Applies To:

Show Versions Show Versions

Manual Chapter: Implementing Anomaly Detection
Manual Chapter
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Anomaly detection is a way of detecting patterns in traffic that do not conform with normal behavior, such as an increase in latency or the transactions rate. Application Security Manager provides ways for you to configure the system to detect and mitigate anomalies, including:
Denial-of-service (DoS) attacks: Detects the spikes and anomalies in Layer 7 (application layer) traffic.
Brute force attacks: Protects against hackers forceful attempts to gain access to a web site.
Increased violations from certain IP addresses: Prevents attacks originating from specific IP addresses.
Bot detection and web scraping: Prevents automated extraction of data from web sites.
The remote logging formats for anomalies are predefined, and each remote logging type has a specific format in which it stores information about the anomaly. For details about the predefined remote logging formats for anomalies, refer to Appendix E, Remote Logging Formats for Anomalies.
A denial-of-service attack (DoS attack) is an attempt to make a computer resource unavailable to its intended users. A DoS attack generally consists of the concerted, malevolent efforts to prevent an Internet site or application from functioning efficiently or at all, temporarily or indefinitely. Perpetrators of DoS attacks typically target sites or services, such as banks, credit card payment gateways, and e-commerce web sites.
One common method of attack involves saturating the target (victim) machine with external communications requests, so that the target system cannot respond to legitimate traffic, or responds so slowly as to be rendered effectively unavailable. In general terms, DoS attacks are implemented by forcing the targeted computer to reset, or by consuming its resources so that it can no longer provide its intended service, or by obstructing the communication media between the intended users and the victim so that they can no longer communicate adequately.
Denial-of-service attacks are also known as HTTP-GET attacks or page flood attacks. The attacks can either be initiated from a single user (single IP address) or from thousands of computers (distributed DoS attack), which overwhelms the target system. A page flood attack (or HTTP flood attack) may resemble the patterns of normal Web surfing, making it harder for automated tools to differentiate between legitimate Web traffic and an attempted attack.
Application Security Manager considers traffic to be a DoS attack based on calculations for transaction rates on the client side (TPS-based) or latency on the server side (latency-based). You can specify the calculations that you want the system to use.
Note: You can set up both methods of detection to work independently or you can set them up to work concurrently to simultaneously detect attacks on either the client side and server side.
You can view details about DoS attacks that the system detected and logged. For information about the DoS Attacks reports, refer to Viewing L7 DoS Attacks reports. You can also configure remote logging support for DoS attacks when creating a logging profile. For information about creating remote logging profiles, refer to Creating logging profiles.
You can configure Application Security Manager to mitigate DoS attacks based on transaction rates using TPS-based DoS protection. If you choose TPS-based DoS protection, the system detects DoS attacks from the client side using the following calculations:
Transaction rate during detection interval
The average number of requests per second sent for a specific URL, or by a specific IP address. Every second, the system calculates the average TPS for the last minute. Note that the averages for IP address and URL counts are done for each virtual server, not each DoS L7 profile, in case one DoS L7 profile is assigned to more than one virtual servers
Transaction rate during history interval
The average number of requests per second sent for a specific URL, or by a specific IP address. The system calculates this number every minute.
If the ratio of the transaction rate during the detection interval to the transaction rate during the history interval is greater than the specific percentage you configure on the DoS Attack Prevention screen (the TPS increased by percentage), the system considers the URL to be under attack, or the IP address to be suspicious. To prevent further attacks, the system drops requests for this URL, and drops requests from the suspicious IP address.
1.
On the Main tab, expand Security, and click DoS Protection.
The DoS Profiles screen opens.
2.
Click Create.
The Create New DoS Profile screen opens.
4.
Select the Application Security check box.
The screen refreshes and displays additional configuration settings.
5.
Select the Trigger iRule setting only if you have written an application DoS iRule to specify how the system handles a DoS attack and recovers afterwards. (For complete iRules® information, visit https://devcentral.f5.com.)
6.
In the TPS-based Anomaly area, for Operation Mode, select the way you want the system to react to DoS attacks. The screen refreshes to display additional configuration settings once you select an operation mode.
Transparent
Displays information about DoS attacks on the DoS Attacks reporting screen.
Blocking
Drops connections coming from an attacking IP address or going to a URL being attacked. Also displays information about DoS attacks on the Reporting DoS Application screen.
7.
For the Prevention Policy setting, select the methods you want the system to use to mitigate an attack.
Note: If you enable more than one option, the system uses the options in the order in which they are listed.
Source IP-Based Client-Side Integrity Defense
Determines whether a client is a legitimate browser or an illegal script by generating JavaScript responses when suspicious IP addresses are requested. Legitimate 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 legitimate browser or an illegal script by generating JavaScript responses when suspicious URLs are requested. Legitimate browsers can process JavaScript and respond properly, whereas illegal scripts cannot. This setting enforces strong protection and prevents distributed DoS attacks but affects more clients. 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.
8.
For the IP Detection Criteria setting, modify the threshold values as needed. If any of these criteria are met, the system handles the attack according to the Prevention Policy settings.
Note: This setting appears only if Prevention Policy is set to Source IP-Based Client Side Integrity Defense and/or Source IP-Based Rate Limiting.
TPS increased by: Specifies that the system considers an IP address to be that of an attacker, if the transactions sent per second have increased by this percentage. The default value is 500%.
TPS reached: Specifies that the system considers an IP address to be suspicious if the number of transactions sent per second from an IP address equals, or is greater than, this value. This setting provides an absolute value, so, for example, if an attack increases the number of transactions gradually, the increase might not exceed the TPS increased by threshold and would not be detected. If the TPS reaches the TPS reached value, the system considers traffic to be an attack even if it did not meet the TPS increased by criterion. The default value is 200 TPS.
Minimum TPS Threshold for detection: Specifies that the system considers an IP address to be an attacker if the detected TPS for a specific IP address equals, or is greater than, this number, and the TPS increased by number was reached. The default setting is 40 transactions per second.
Tip: Click the Set default criteria link to reset these settings to their default values.
9.
For URL Detection Criteria, modify the threshold values as needed. If any of these criteria are met, the system handles the attack according to the Prevention Policy settings.
Note: This setting appears only if Prevention Policy is set to URL-Based Client Side Integrity Defense and/or URL-Based Rate Limiting.
TPS increased by: Specifies that the system considers a URL to be an attacker if the number of transactions (requests) sent per second to the URL have increased by this percentage. The default value is 500%.
TPS reached: Specifies that the system considers a URL to be suspicious if the number of transactions (requests) sent per second to the URL is equal to or greater than this value. This setting provides an absolute value, so, for example, if an attack increases the number of transactions gradually, the increase might not exceed the TPS Increased by threshold and would not be detected. If the TPS reaches the TPS reached value, the system considers traffic to be an attack even if it did not meet the TPS increased by criterion. The default value is 1000 TPS.
Minimum TPS Threshold for detection: Specifies that the system considers a URL to be an attacker if the detected TPS for a specific URL equals, or is greater than, this number, and the TPS increased by number was reached. The default setting is 200 transactions per second.
Tip: Click the Set default criteria link to reset these settings to their default values.
10.
For the Prevention Duration setting, specify the length of time for which the system mitigates a DoS attack:
Unlimited: Performs attack prevention until the system detects the end of the attack.
Maximum: Select and type a value, in seconds.
Prevents detected DoS attacks for the time configured here (even if the attack is still occurring), or until the system detects the end of the attack, whichever is sooner.
11.
In the IP Address Whitelist area, for the IP Address Whitelist setting, type IP address/subnet information that represents address spaces that do not need to be examined for DoS attacks, and click Add.
12.
Click Finished to save the TPS detection and prevention criteria.
You can configure Application Security Manager to mitigate layer 7 DoS attacks based on server latency. If you choose latency-based DoS detection, the system detects DoS attacks on the server side using the following calculations:
Latency during detection interval
The average time it takes for the system to respond to a request for a specific URL, for each web application, over the last minute. This average is updated every second.
Latency during history interval
The average time it takes for the system to respond to a request for a specific URL, for each web application, over the last hour. This average is updated every minute.
If the ratio of the latency during the detection interval to the latency during the history interval is greater than the percentage you configure on the DoS Attack Prevention screen (the Latency increased by percentage), the system detects that this URL is under attack.
1.
On the Main tab, expand Security, and click DoS Protection.
The DoS Profiles screen opens.
2.
Click Create.
The Create New DoS Profile screen opens.
4.
Select the Application Security check box.
The screen refreshes and displays additional configuration settings.
5.
Select the Trigger iRule setting only if you have written an application DoS iRule to specify how the system recovers after a DoS attack. (For complete iRules information, visit https://devcentral.f5.com.)
6.
In the Latency-based Anomaly area, for the Operation Mode setting, select the way you want the system to react to DoS attacks. The screen refreshes to display additional configuration settings once you select an operation mode.
Transparent
Displays information about DoS attacks on the DoS: Application reporting screen.
Blocking
Displays information about DoS attacks on the DoS: Application reporting screen, and drops connections coming from an attacking IP address or going to a URL being attacked.
7.
For the Detection Criteria setting, specify the threshold values:
Latency increased by: Specifies that the system considers traffic to be an attack if the minimum latency threshold was reached and the latency has increased by this percentage. The default value is 500%.
Latency reached: Specifies that the system considers traffic to be an attack if the latency is equal to or greater than this value. This setting provides an absolute value, so, for example, if an attack increases latency gradually, the increase might not exceed the Latency Increased by threshold and would not be detected. If server latency reaches the Latency reached value, the system considers traffic to be an attack even if it did not meet the Latency increased by criterion. The default value is 10000 ms.
Minimum Latency Threshold for detection: Specifies that the system considers traffic to be an attack if the detection interval for a specific URL equals, or is greater than, this number, and at least one of the Latency increased by number was reached. The default setting is 200 ms.
Tip: Click the Set default criteria link to reset these settings to their default values.
8.
For the Prevention Policy setting, select the methods you want the system to use to mitigate an attack (the methods are applied in the order listed).
Source IP-Based Client-Side Integrity Defense
Determines whether a client is a legitimate browser or an illegal script by injecting JavaScript into responses when suspicious IP addresses are requested. Legitimate 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 legitimate browser or an illegal script by injecting JavaScript into responses when suspicious URLs are requested. Legitimate browsers can process JavaScript and respond properly, whereas illegal scripts cannot. This setting enforces strong protection and prevents distributed DoS attacks but affects more clients. 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.
9.
For the Suspicious IP Criteria setting, modify the threshold values as needed. If any of these criteria are met, the system handles the attack according to the Prevention Policy settings.
Note: This setting appears only if Prevention Policy is set to Source IP-Based Client Side Integrity Defense and/or Source IP-Based Rate Limiting.
TPS increased by: Specifies that the system considers an IP address to be that of an attacker, if the transactions (requests) sent per second have increased by this percentage. The default value is 500%.
TPS reached: Specifies that the system considers an IP address to be suspicious if the number of transactions (requests) sent per second from an IP address is equal to or greater than this value. This setting provides an absolute value, so, for example, if an attack increases the number of transactions gradually, the increase might not exceed the TPS increased by threshold and would not be detected. If the TPS reaches the TPS reached value, the system considers traffic to be an attack even if it did not meet the TPS increased by criterion. The default value is 200 requests per second.
Minimum TPS Threshold for detection: Specifies that the system considers an IP address to be suspicious if the detected TPS for a specific IP address equals, or is greater than, this number, and the TPS increased by number was reached. The default setting is 40 transactions per second.
Tip: Click the Set default criteria link to reset these settings to their default values.
10.
For the Suspicious URL Criteria setting, modify the threshold values as needed. If any of these criteria are met, the system handles the attack according to the Prevention Policy settings.
Note: This setting appears only if Prevention Policy is set to URL-Based Client Side Integrity Defense and/or URL-Based Rate Limiting.
TPS increased by: Specifies that the system considers a URL to be an attack if the number of transactions (requests) sent per second to the URL have increased by this percentage. The default value is 500%.
TPS reached: Specifies that the system considers a URL to be suspicious if the number of transactions (requests) sent per second to the URL is equal to or greater than this value. This setting provides an absolute value, so, for example, if an attack increases the number of transactions gradually, the increase might not exceed the TPS Increased by threshold and would not be detected. If the TPS reaches the TPS reached value, the system considers traffic to be an attack even if it did not meet the TPS increased by criterion. The default value is 1000 TPS.
Minimum TPS Threshold for detection: Specifies that the system considers a URL to be suspicious if the detected TPS for a specific URL equals, or is greater than, this number, and the TPS increased by number was reached. The default setting is 200 transactions per second.
Tip: Click the Set default criteria link to reset these settings to their default values.
11.
For the Prevention Duration setting, specify the length of time for which the system mitigates DoS attacks:
Unlimited: Select if you want the system to perform attack prevention until it detects the end of the attack.
Maximum: Select and type a value, in seconds. The system prevents detected DoS attacks for the time configured here (even if the attack is still occurring), or until the system detects the end of the attack, whichever is sooner.
12.
In the IP Address Whitelist area, for the IP Address Whitelist setting, type IP address/subnet information that represents address spaces that do not need to be examined for DoS attacks, and click Add.
13.
Click Save to save the latency detection and prevention criteria.
Once you have created a Layer 7 DoS profile, you associate that profile with a virtual server that represents the application you want to protect. Note that you can associate one DoS profile with many virtual servers. However, you can associate only one DoS profile with a each virtual server.
1.
On the Main tab, select Local Traffic, point to Virtual Servers, and click Virtual Server List.
4.
In the Policy Settings area, for the DoS Protection Profile setting, select Enabled, and then select the DoS profile you created from the Profile list.
5.
Click Update to save the changes.
You can configure the Application Security Manager to detect, report on, and prevent Layer 7 brute force attack attempts. 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. Malicious users send high volumes of these combinations, often scripted, to avoid security mechanisms. In this automated scenario, one malicious user can make thousands of login attempts per minute.
In Application Security Manager, you can configure the login URL of a web application to indicate the mitigation methods and the access validation criteria for logon responses. With brute force protection, the system can monitor traffic to detect excessive failures to authenticate, monitor suspicious IP addresses (generating a high volume of login attempts), and detect other anomalies in the typical traffic pattern for the login URL.
Application Security Manager tracks the number of failed login attempts which were performed through the configured login URL, in two intervals:
History interval: The number of failed login attempts for the past hour (updated every minute).
Detection interval: The number of failed login attempts for the past minute (updated every second).
The system considers it to be a brute force attack if the failed login rate during the detection interval is extremely high and exceeds the configured failed login rate or exceeds the configured max failed login threshold.
1.
On the Main tab, expand Security, point to Application Security, Anomaly Detection, and click Brute Force Attack Prevention.
The Brute Force Attack Prevention screen opens.
2.
In the editing context area, ensure that the Current edited policy is the one you want to update.
3.
Click the Create button.
The New Brute Force Protection Configuration screen opens.
4.
For the Login Page setting, select an already configured login page from the list. This is the URL that you want to protect against brute force attacks. If you need to create a login page in the security policy, click the Create button (see Creating login pages, for help with the Create Login Page screen).
Session-based mitigation counts the number of failed login attempts that occur during one session, based on a session cookie. When the system detects a brute force attack, it triggers the Brute Force: Maximum login attempts are exceeded violation, and applies the blocking policy.
1.
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.
2.
For Re-enable Login After, type the number of seconds the user must wait to log in after they have been blocked. The default value is 600 seconds.
3.
Optionally, above the Session-based Brute Force Protection area, click the Blocking Settings link to open the Application Security: Blocking: Settings screen. Configure the blocking actions that the system takes when the Brute Force: Maximum login attempts are exceeded violation occurs.
Note: See Configuring policy blocking, for more information.
4.
To finalize the configuration, click Create.
The screen refreshes, and you see the protected login URL in the list.
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.
To configure dynamic brute force protection, use the settings in the Dynamic Brute Force Protection area of the New Brute Force Protection Configuration screen.
1.
For Operation Mode, select how the system handles brute force attacks:
Off
The system does not monitor traffic to detect brute force attacks.
Alarm
The system issues reporting data only on attacks, and does not drop illegal requests. This is the default setting.
Alarm and Block
The system mitigates some of the login attempts and logs reporting data.
2.
For the Detection Criteria setting, specify when to consider login attempts to be an attack (only one of the first two conditions must be met).
Failed Logins Attempts increased by
The system considers unsuccessful logon attempts to be 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 setting is 500 percent.
Failed Login Attempts Rate reached
The system considers unsuccessful logon attempts to be an attack if, for all IP addresses tracked, the logon attempt rate reaches this number. The default setting is 100 logon attempts per second.
Minimum Failed Login Attempts
The system considers unsuccessful logon attempts to be an attack if, for all IP addresses tracked, the number of logon attempts is equal to, or greater than, this number. This setting prevents false positive attack detection. The default setting is 20 logon attempts per second.
3.
For the Prevention Policy setting, select the methods you want the system to use to mitigate an attack (the methods are applied in the order listed).
Source IP-Based Client-Side Integrity Defense
Select to determine whether the client is a legitimate browser or an illegal script by injecting JavaScript into responses when suspicious IP addresses are requested. Legitimate browsers can process JavaScript and respond properly, whereas illegal scripts cannot. The default is disabled.
URL-Based Client-Side Integrity Defense
Select to determine whether the client is a legitimate browser or an illegal script by injecting JavaScript into responses when suspicious URLs are requested. Legitimate browsers can process JavaScript and respond properly, whereas illegal scripts cannot. The default is disabled.
Source IP-Based Rate Limiting
Select to drop requests from suspicious IP addresses. Application Security Manager drops connections to limit the rate of login attempts to the average rate prior to the attack. The default is enabled.
URL-Based Rate Limiting
Select to indicate that when the system detects a URL under attack, Application Security Manager performs rate limiting and limits the rate of all logon requests to the normal level. The default is enabled.
4.
For Suspicious Criteria (per IP address), specify how to identify a potential attackers 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.
Failed Login Attempts increased by
Type a number. 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.
Failed Login Attempts Rate reached
Type a number. 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.
5.
For the Prevention Duration setting, specify how long the system should mitigate brute force attacks.
Unlimited
Perform attack prevention until it detects the end of the attack.
Maximum
Perform attack prevention either for the time configured here (even if the system detects that the attack continues), or until the system detects the end of the attack, whichever is earlier. Type a value, in seconds, in the field.
6.
To finalize the configuration, click Create.
The screen refreshes, and you see the protected login URL in the list.
7.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
You can configure Application Security Manager to detect and prevent various web scraping activities on web sites that it is protecting. Web scraping is a technique for extracting information from web sites typically using automated programs, or bots (short for web robots).
Web scraping in Application Security Manager provides you with a number of ways to address different web scraping attack types. These features can work independently of each other, or work together to detect and prevent web scraping attacks.
Bot detection
Determines whether the web client source is human. Clients must have JavaScript enabled and support cookies.
Session Opening Anomaly detection
Detects IP addresses from which sessions are opened at high rates. This detection identifies an open session that sends a request without an ASM cookie as an attacker. Clients must support cookies.
Session Transaction Anomaly detection
Captures sessions that request too much traffic, compared to the average amount observed in the web application. This is based on counting the transactions per session and comparing that to the average transactions per second for all sessions. Clients must support cookies.
The system can accurately detect such anomalies only when response caching (the RAM cache and the Web Accelerator cache) is turned off.
You can configure the system to perform web scraping detection. If your environment uses legitimate automated tests, you can create a white list of IP addresses or address ranges from which to allow access. The system does not perform web scraping detection on traffic from those addresses or from the configured search engines.
Note: When you configure a white list of IP addresses for which to allow access, the list of those IP addresses are applicable and common to all web scraping and brute force mitigations.
1.
On the Main tab, expand Security, point to Application Security, Anomaly Detection, and then click Web Scraping.
The Web Scraping screen opens.
2.
In the editing context area, verify that the Current edited policy is the one you want to update.
3.
For the Bot Detection setting, select either Alarm or Alarm and Block, to indicate how you want the system to react to a suspected web scraping attack.
The Bot Detection tab opens.
4.
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.
5.
On the Bot Detection tab, for the Rapid Surfing setting, specify the maximum number of web pages that can be changed in the specified number of seconds before the system suspects a bot. For Maximum page changes, the default value is 5. For the number of milliseconds allowed, the default is 1000.
6.
For the Grace Interval setting, type the number of requests to allow while determining whether a client is human. The default value is 100.
7.
For the Unsafe Interval setting, type the number of requests that cause the Web Scraping Detected violation if no human activity was detected during the grace period. Reaching this interval causes the system to reactivate the grace period. The default value is 100.
8.
For Safe Interval, type the number of requests to allow after human activity is detected, and before reactivating the grace threshold to check again for non-human clients. The default value is 2000.
9.
Click Save.
10.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
You can configure how the system protects your web application against session opening anomalies from a specific IP address.
1.
On the Main tab, expand Security, point to Application Security, Anomaly Detection, and then click Web Scraping.
The Web Scraping configuration screen opens.
2.
In the editing context area, verify that the Current edited policy is the one you want to update.
3.
In the Web Scraping Configuration area, for the Session Opening Anomaly setting, select either Alarm or Alarm and Block.
The Sessions Opening Anomaly tab opens.
4.
In IP Address Whitelist, add the IP addresses or subnets that do not need to be examined for web scraping.
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.
5.
For the Prevention Policy setting, select one or more of the available options to direct how the system should handle a session opening anomaly attack.
Client Side Integrity Defense: When enabled, the system determines whether a client is a legitimate browser or an illegal script by sending a JavaScript® challenge to each new session request. Legitimate browsers can respond to the challenge; scripts cannot.
Rate Limiting: When enabled, the system drops requests from suspicious IP addresses.
Drop IP Addresses with bad reputation: When enabled, the system drops requests originating from IP addresses that are in the systems IP reputation database when the attack is detected; no rate limiting will occur. (Attacking IP addresses that do not have a bad reputation undergo rate limiting, as usual.) This option is available only if you have enabled the rate limiting prevention policy, and you have enabled IP Address Intelligence, and at least one of its categories has its Alarm flag enabled.
6.
For the Detection Criteria setting, specify the criteria under which the system considers traffic to be a session opening anomaly attack.
Sessions opened per second increased by: The system considers traffic to be an attack if the number of sessions opened per second increased by this percentage. The default value is 500%.
Sessions opened per second reached: The system considers traffic to be an attack if the number of sessions opened per second is equal to or greater than this number. The default value is 400 sessions opened per second.
Minimum sessions opened per second threshold for detection: The system only considers traffic to be an attack if this value plus one of the sessions opened values is exceeded. The default value is 200 sessions opened per second.
Note: The Detection Criteria values all work together. The minimum sessions value and one of the sessions opened values must be met for traffic to be considered an attack. However, if the minimum sessions value is not reached, traffic is never considered an attack even if the Sessions opened per second increased by value is met.
7.
For Prevention Duration, specify how long the system prevents a session opening anomaly attack.
Unlimited: The system continues to perform attack prevention until it detects the end of the attack. This is the default.
Maximum seconds: The maximum number of seconds for the system to perform attack prevention after detecting an attack. The system ceases attack prevention after the specified time duration, regardless of whether the attack continues to occur. If the attack ends before this number of seconds, the system also stops attack prevention.
8.
Click Save.
9.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
You can specify how the system protects your web application against harvesting by counting the number of transactions per session and comparing that to the average number of transactions per second for all sessions.
When the system detects a large number of transactions, all transactions from the attacking session cause the Web Scraping detected violation until the end of attack.
1.
On the Main tab, expand Security, point to Application Security, select Anomaly Detection, then click Web Scraping.
The Web Scraping Configuration screen opens.
2.
In the editing context area, verify that the Current edited policy is the one you want to update.
3.
For Session Transactions Anomaly, select one of the following:
Alarm: When the system detects an anomaly in the number of session transactions, it records the attack data.
Alarm and Block: When the system detects an anomaly in the number of session transactions, in addition to recording the attack data, the system also blocks the suspicious requests.
4.
In IP Address Whitelist, add the IP addresses or subnets that do not need to be examined for web scraping.
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.
5.
For Detection Criteria, specify the criteria under which the system considers traffic to be a session transactions anomaly attack.
Session transactions increased by: The percentage increase of the number of transactions per session after which the system considers traffic to be an attack. The default value is 500%.
Session transactions reached: The system considers traffic to be an attack if the number of transactions per session is equal to or greater than this number. The default value is 400 transactions..
Minimum session transactions threshold for detection: The system considers traffic to be an attack only if the number of transactions per session is equal to or greater than this number, and at least one of the Sessions transactions increased by or Session transactions reached numbers was attained. The default value is 200 transactions.
Note: The Detection Criteria values all work together. The Minimum sessions value and one of the Sessions values must be met for traffic to be considered an attack. However, if the Minimum sessions value is not reached, traffic is never considered an attack even if one of the Sessions values was reached.
6.
For Prevention Duration, specify how long the system will prevent a session transaction anomaly attack by blocking requests.
Unlimited: The system continues to perform attack prevention until it detects the end of the attack. This is the default.
Maximum seconds: The maximum number of seconds for the system to perform attack prevention after detecting an attack. The system will cease the attack prevention after the specified time duration, regardless of whether the attack continues to occur.
7.
Click Save.
8.
To put the security policy changes into effect immediately, click the Apply Policy button in the editing context area.
By default, Application Security Manager allows requests from well-known search engines and legitimate web robots including the following:
Ask (*.ask.com)
Bing (*.msn.com)
Google (*.googlebot.com)
Yahoo (*.yahoo.net)
You can add other search engines to the search engine list, for example, if your web application uses an additional search engine. The list applies globally to all security policies for which web scraping detection is enabled. The Application Security Manager does not perform web scraping detection on traffic from the search engines on the list.
1.
On the Main tab, click Security, point to Options, Application Security, and then click Advanced Configuration.
3.
Click Create.
The New Search Engine screen opens.
4.
For the Search Engine setting, type the name.
5.
For the Bot Name setting, type the search engine bot name, such as googlebot.
Tip: You can get this name from the user-agent header of a request that the search engine sends.
6.
For the Domain Name setting, type the search engine crawlers domain name; for example, yahoo.net.
7.
Click Create.
The system adds the search engine to the list.
Note: For this feature to work, the DNS server must be on the DNS lookup server list on the BIG-IP system (System > Configuration > Device > DNS). The system uses reverse DNS lookup to verify search engine requests.
Table of Contents   |   << Previous Chapter   |   Next Chapter >>

Was this resource helpful in solving your issue?




NOTE: Please do not provide personal information.



Incorrect answer. Please try again: Please enter the words to the right: Please enter the numbers you hear:

Additional Comments (optional)