Applies To:

Show Versions Show Versions

Manual Chapter: Preventing DoS Attacks for Layer 7 Traffic
Manual Chapter
Table of Contents   |   Next Chapter >>

What is a DoS attack?

A denial-of-service attack (DoS attack) makes a computer resource unavailable to its intended users, or obstructs the communication media between the intended users and the victim so that they can no longer communicate adequately. Perpetrators of DoS attacks typically target sites or services, such as banks, credit card payment gateways, and e-commerce web sites.

Application Security Manager (ASM) helps protect web applications from DoS attacks aimed at the resources that are used for serving the application: the web server, web framework, and the application logic. Advanced Firewall Manager (AFM) helps prevent network, SIP, and DNS DoS attacks.

HTTP-GET attacks and page flood attacks are typical examples of application DoS attacks. HTTP-GET attacks are initiated either from a single user (single IP address) or from thousands of computers (distributed DoS attack), which overwhelms the target system. In page flood attacks, the attacker downloads all the resources on the page (images, scripts, and so on) while an HTTP-GET flood repeatedly requests specific URLs regardless of their place in the application.

About recognizing DoS attacks

Application Security Manager determines that traffic is 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 detect attacks on both the client side and server side. Whichever method detects the attack handles DoS protection.

In addition, the system can protect web applications against DoS attacks on heavy URLs. Heavy URL protection implies that during a DoS attack, the system protects the heavy URLs using the methods configured in the DoS profile.

You can view details about DoS attacks that the system detected and logged in the event logs and DoS reports. You can also configure remote logging support for DoS attacks when creating a logging profile.

About configuring TPS-based DoS protection

When setting up DoS protection, you can configure the system to prevent DoS attacks based on transaction rates (TPS-based anomaly detection). If you choose TPS-based anomaly 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: The averages for IP address and URL counts are done for each site, that is, for each virtual server and associated DoS profile. If one virtual server has multiple DoS profiles (implemented using a local traffic policy), then each DoS profile has its own statistics within the context of the virtual server.
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 percentage indicated in the TPS increased by setting, the system considers the URL to be under attack, or the IP address to be suspicious. In addition, if the transaction rate during the detection interval is absolutely higher than the TPS reached setting (regardless of the history interval), then also the respective IP address is suspicious or the URL is being attacked.

Note that TPS-based protection might detect a DoS attack simply because many users are trying to access the server all at once, such as during a busy time or when a new product comes out. In this case, the attack might be a false positive because the users are legitimate. But the advantage of TPS-based DoS protection is that attacks can be detected earlier than when using latency-based protection. So you need to understand the typical maximum peak loads on your system when setting up DoS protection.

About configuring latency-based DoS protection

When setting up DoS protection, you can configure the system to prevent DoS attacks based on the server side (latency-based anomaly detection). In latency-based detection, it takes a latency increase and at least one suspicious IP address, URL, or heavy URL to consider the activity an attack.

Note: The average latency is measured for each site, that is, for each virtual server and associated DoS profile. If one virtual server has multiple DoS profiles (implemented using a local traffic policy), then each DoS profile has its own statistics within the context of the virtual server.

If the ratio of recent versus historical values is greater than the Latency increased by setting, then a prerequisite for the presence of an attack is satisfied, but that is not sufficient. It also takes at least one suspicious IP address, one attacked URL based on TPS criteria, or one heavy URL for the system to declare an attack and start mitigation. In addition, if the transaction rate during the detection interval is absolutely higher than the Latency reached setting (regardless of the history interval), then also the respective IP address is suspicious or the URL is being attacked.

Latency-based protection is less prone to false positives than TPS-based protection because in a DoS attack, the server is reaching capacity and service/response time is slow: this is impacting all users. Increased latency can be used as a trigger step for detecting an L7 attack. Following the detection of a significant latency increase, it is important to determine whether you need further action. After examining the increase in the requests per second and by comparing these numbers with past activity, you can identify suspicious versus normal latency increases.

About heavy URL protection

Heavy URLs are URLs that may consume considerable server resources per request. Heavy URLs respond with low latency most of the time, but can easily reach high latency under specific conditions. Heavy URLs are not necessarily heavy all the time, but tend to get heavy especially during attacks. Therefore, low rate requests to those URLs can cause significant DoS attacks and be hard to distinguish from legitimate clients.

Typically, heavy URLs involve complex database queries; for example, retrieving historical stock quotes. In most cases, users request recent quotes with weekly resolution, and those queries quickly yield responses. However, an attack might involve requesting five years of quotes with day-by-day resolution, which requires retrieval of large amounts of data, and consumes considerably more resources.

Application Security Manager allows you to configure protection from heavy URLs in a DoS profile. You can specify a latency threshold for automatically detecting heavy URLs. If some of the web site's URLs could potentially become heavy URLs, you can add them so the system will keep an eye on them, and you can add URLs that should be ignored and not considered heavy.

About site-wide DoS mitigation

In order to mitigate highly distributed DoS attacks, such as those instigated using large scale botnets attacking multiple URLs, you can include site-wide mitigation in a DoS profile. You can use site-wide mitigation as part of the prevention policy for either TPS-based or latency-based DoS protection. In this case, the whole site can be considered suspicious as opposed to a particular URL or IP address. Site-wide mitigation goes into effect when the system determines that the whole site is experiencing high-volume traffic but is not able to pinpoint and handle the problem.

The system implements site-wide mitigation method only as a last resort because it may cause the system to drop legitimate requests. However, it maintains, at least partially, the availability of the web site, even when it is under attack. When the system applies site-wide mitigation, it is because all other active detection methods were unable to stop the attack.

The whole site is considered suspicious when configured thresholds are crossed, and in parallel, specific IP addresses and URLs could also be found to be suspicious. The mitigation continues until the maximum duration elapses or when the whole site stops being suspicious. That is, there are no suspicious URLs, no suspicious IP addresses, and the whole site is no longer suspicious.

Overview: Preventing DoS attacks for applications

You can configure the Application Security Manager to protect against DoS attacks on web applications. Depending on your configuration, the system detects DoS attacks based on transactions per second (TPS) on the client side, server latency, or heavy URLs.

You configure DoS protection for Layer 7 by creating a DoS profile with Application Security enabled. You then associate the DoS profile with one or more virtual servers representing applications that you want to protect. DoS protection is not part of a security policy.

Task Summary

Configuring DoS protection for applications

You can configure Application Security Manager to protect against and mitigate DoS attacks, and increase system security.
  1. On the Main tab, click Security > DoS Protection > DoS Profiles. The DoS Profiles list screen opens.
  2. Click Create. The Create New DoS Profile screen opens.
  3. In the Profile Name field, type the name for the profile.
  4. Select the Application Security check box. The screen refreshes and displays additional configuration settings.
  5. If you have written an application DoS iRule to specify how the system handles a DoS attack and recovers afterwards, select the Trigger iRule setting.
  6. If you want to set up DoS protection from the client side, in the TPS-based Anomaly area, select an Operation Mode and set up TPS-based DoS protection. Another task describes how to configure the settings.
  7. If you want to set up DoS protection from the server side, in the Latency-based Anomaly area, select an Operation Mode and set up latency-based DoS protection. Another task describes how to configure the settings.
  8. If you want to set up protection for heavy URLs, in the Heavy URL Protection area, select Heavy URL Protection and configure the protection settings. Another task describes how to configure the settings.
  9. To omit certain addresses, for the IP Address Whitelist setting, type IP addresses or subnets that do not need to be examined for DoS attacks, and click Add.
    Note: You can add up to 20 IP addresses.
  10. To record traffic (perform a TCP dump) during DoS attacks, select the Record Traffic During Attacks check box, and specify the options to determine the conditions and how often to perform the dump. This option allows you to diagnose the attack vectors and attackers and observe whether it was mitigated. If a DoS attack occurs, the system creates a TCP dump in /shared/dosl7/tcpdumps on the virtual server where the attack was detected.
  11. Click Finished to save the DoS profile.
You have created a DoS profile.
Next, configure TPS-based, latency-based, or heavy URL DoS protection settings, or all three.

Configuring TPS-based DoS protection settings

You can configure Application Security Manager to mitigate DoS attacks based on transaction rates using TPS-based DoS protection.
  1. On the Main tab, click Security > DoS Protection > DoS Profiles. The DoS Profiles list screen opens.
  2. Click the name of an existing DoS profile (or create a new one). The DoS Profile Properties screen opens.
  3. Select the Application Security check box. The screen refreshes and displays additional configuration settings.
  4. In the TPS-based Anomaly area, for Operation Mode, select an operation mode.
    Option Description
    Transparent Displays information about DoS attacks on the DoS: Application reporting screen but does not block requests.
    Blocking Drops connections coming from an attacking IP address and requests to attacked URLs. Also displays information about DoS attacks on the DoS: Application reporting screen.
    The screen refreshes to display additional configuration settings when you select an operation mode.
  5. For the Prevention Policy setting, select one or more options to determine how the system handles a DoS 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. This setting enforces strong protection and prevents distributed DoS attacks but affects more clients. The default is disabled.
    Site-wide Client-Side Integrity Defense Determines whether the client is a legal browser or an illegal script by sending a JavaScript challenge to all URLs for each suspicious site and waiting for a response. (Legal browsers are able to respond, while 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.
    Site-wide Rate Limiting Indicates that the system drops transactions for suspicious sites. The system allows requests for that site when the request rate per second is less than the legitimate history interval (before the attack started), or less than the threshold you configure in the TPS reached setting. The default is enabled.
  6. For IP Detection Criteria, modify the threshold values as needed.
    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.
    If any of these criteria is met, the system handles the attack according to the Prevention Policy settings.
    Option Description
    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, and the detected TPS is greater than the Minimum TPS Threshold for detection. 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 value. 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.
  7. For URL Detection Criteria, modify the threshold values as needed.
    Note: This setting appears only if Prevention Policy is set to URL-Based Client Side Integrity Defense and/or URL-Based Rate Limiting.
    Option Description
    TPS increased by Specifies that the system considers a URL to be that of an attacker if the transactions sent per second to the URL have increased by this percentage, and the detected TPS is greater than the Minimum TPS Threshold for detection. The default value is 500%.
    TPS reached Specifies that the system considers a URL to be suspicious if the number of transactions 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 value. 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.
    If any of these criteria is met, the system handles the attack according to the Prevention Policy settings.
  8. For Site-Wide Detection Criteria, modify the threshold values as needed.
    Note: This setting appears only if using site-wide prevention policies.
    Option Description
    TPS increased by Specifies that the system considers a whole site to be under attack if the transactions sent per second have increased by this percentage, and the detected TPS is greater than the Minimum TPS Threshold for detection. . The default value is 500%.
    TPS reached Specifies that the system considers a whole site to be under attack if the number of requests sent per second is equal to or greater than this number. The default value is 10000 TPS.
    Minimum TPS Threshold for detection Specifies that the system considers a whole site to be under attack if the detected TPS is equal to or greater than this number, and the TPS increased by number was reached. The default setting is 2000 TPS.
    If any of these criteria is met, the system handles the attack according to the Prevention Policy settings.
  9. For the Prevention Duration setting, specify the time spent in each mitigation step until deciding to move to the next mitigation step.
    Option Description
    Escalation Period Specifies the minimum time spent in each mitigation step before the system moves to the next step when preventing attacks against an attacker IP address or attacked URL. During a DoS attack, the system performs attack prevention for the amount of time configured here for methods enabled in the Prevention Policy. If after this period the attack is not stopped, the system enforces the next enabled prevention step. Type a number between 1 and 3600. The default is 120 seconds.
    De-escalation Period Specifies the time spent in the final escalation step until retrying the steps using the methods enabled in the Prevention Policy. Type a number (greater than the escalation period) between 0 (meaning no de-escalation) and 7200 seconds. The default value is 7200 seconds (2 hours).
    DoS mitigation is reset after 2 hours even if the detection criteria still hold regardless of the value set for the De-escalation Period. If the attack is still taking place, a new attack occurs and mitigation starts over retrying the steps in the Prevention Policy. If you set the De-escalation Period to less than 2 hours, the reset occurs more frequently.
  10. Click Update to save the DoS profile.
You have now configured a DoS profile to prevent DoS attacks based on the client side (TPS-based Detection Mode).
Next, you need to associate the DoS profile with the application’s virtual server. You also have the option of configuring heavy URL protection.

Configuring latency-based DoS protection

You can configure Application Security Manager to mitigate Layer 7 DoS attacks based on server latency.
  1. On the Main tab, click Security > DoS Protection > DoS Profiles. The DoS Profiles list screen opens.
  2. Click the name of an existing DoS profile (or create a new one). The DoS Profile Properties screen opens.
  3. Select the Application Security check box. The screen refreshes and displays additional configuration settings.
  4. In the Latency-based Anomaly area, for Operation Mode, select an operation mode.
    Option Description
    Transparent Displays information about DoS attacks on the DoS: Application reporting screen but does not block requests.
    Blocking Drops connections coming from an attacking IP address and requests to attacked URLs. Also displays information about DoS attacks on the DoS: Application reporting screen.
    The screen refreshes to display additional configuration settings when you select an operation mode.
  5. For Detection Criteria, modify the threshold values as needed. If any of these criteria is met, the system handles the attack according to the Prevention Policy settings.
    Option Description
    Latency increased by Specifies that the system considers traffic to be an attack if the latency has increased by this percentage, and the minimum latency threshold has been reached. 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 value. 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 numbers was reached. The default setting is 200 ms.
    Tip: Click the Set default criteria link to reset these settings to their default values.
  6. For the Prevention Policy setting, select one or more options to determine how the system handles a DoS 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. This setting enforces strong protection and prevents distributed DoS attacks but affects more clients. The default is disabled.
    Site-wide Client-Side Integrity Defense Determines whether the client is a legal browser or an illegal script by sending a JavaScript challenge to all URLs for each suspicious site and waiting for a response. (Legal browsers are able to respond, while 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.
    Site-wide Rate Limiting Indicates that the system drops transactions for suspicious sites. The system allows requests for that site when the request rate per second is less than the legitimate history interval (before the attack started), or less than the threshold you configure in the TPS reached setting. The default is enabled.
  7. For Suspicious IP Criteria, modify the threshold values as needed.
    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.
    Option Description
    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, and the detected TPS for a specific IP address is equal to or greater than the Minimum TPS Threshold. 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 value. 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.
    If any of these criteria is met, the system handles the attack according to the Prevention Policy settings.
  8. For Suspicious URL Criteria, modify the threshold values as needed.
    Note: This setting appears only if Prevention Policy is set to URL-Based Client Side Integrity Defense and/or URL-Based Rate Limiting.
    Option Description
    TPS increased by Specifies that the system considers a URL to be an attacker if the transactions sent per second sent to the URL have increased by this percentage, and the detected TPS for a specific IP address is equal to or greater than the Minimum TPS Threshold. The default value is 500%.
    TPS reached Specifies that the system considers a URL to be suspicious if the number of transactions 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 value. 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 40 transactions per second.
    If any of these criteria is met, the system handles the attack according to the Prevention Policy settings.
  9. For Suspicious Site-Wide Criteria, modify the threshold values as needed.
    Note: This setting appears only if using site-wide prevention policies.
    Option Description
    TPS increased by Specifies that the system considers a whole site to be under attack if the transactions sent per second have increased by this percentage, and the detected TPS for a specific IP address is equal to or greater than the Minimum TPS Threshold. . The default value is 500%.
    TPS reached Specifies that the system considers a whole site to be under attack if the number of requests sent per second is equal to or greater than this number. The default value is 10000 TPS.
    Minimum TPS Threshold for detection Specifies that the system considers a whole site to be under attack if the detected TPS is equal to or greater than this number, and the TPS increased by number was reached. The default setting is 2000 TPS.
    If any of these criteria is met, the system handles the attack according to the Prevention Policy settings.
  10. For the Prevention Duration setting, specify the time spent in each mitigation step until deciding to move to the next mitigation step.
    Option Description
    Escalation Period Specifies the minimum time spent in each mitigation step before the system moves to the next step when preventing attacks against an attacker IP address or attacked URL. During a DoS attack, the system performs attack prevention for the amount of time configured here for methods enabled in the Prevention Policy. If after this period the attack is not stopped, the system enforces the next enabled prevention step. Type a number between 1 and 3600. The default is 120 seconds.
    De-escalation Period Specifies the time spent in the final escalation step until retrying the steps using the methods enabled in the Prevention Policy. Type a number (greater than the escalation period) between 0 (meaning no de-escalation) and 7200 seconds. The default value is 7200 seconds (2 hours).
    DoS mitigation is reset after 2 hours even if the detection criteria still hold regardless of the value set for the De-escalation Period. If the attack is still taking place, a new attack occurs and mitigation starts over retrying the steps in the Prevention Policy. If you set the De-escalation Period to less than 2 hours, the reset occurs more frequently.
  11. Click Update to save the DoS profile.
You have now configured a DoS profile to prevent DoS attacks based on server latency.
Next, associate the DoS profile with the application’s virtual server. You also have the option of configuring heavy URL protection.

Configuring heavy URL protection

To use heavy URL protection, F5 recommends that you configure latency-based anomaly settings in the DoS profile. That way the system can detect low-volume attacks on heavy URLs when no other high-volume attacks are underway. Also, you must enable at least one of the URL-based prevention policy methods in the TPS-based Anomaly or Latency-based Anomaly settings in the DoS profile.
You can configure Application Security Manager (ASM) to prevent DoS attacks on heavy URLs. Heavy URLs are URLs on your application web site that may consume considerable resources under certain conditions. By tracking URLs that are potentially heavy, you can mitigate DoS attacks on these URLs before response latency exceeds a specific threshold.
  1. On the Main tab, click Security > DoS Protection > DoS Profiles. The DoS Profiles list screen opens.
  2. Click the name of an existing DoS profile (or create a new one). The DoS Profile Properties screen opens.
  3. Select the Application Security check box. The screen refreshes and displays additional configuration settings.
  4. Select the Heavy URL Protection check box. The screen displays additional configuration settings.
  5. To automatically detect heavy URLs, select the Automatic Detection check box.
    Tip: You may want to hold off selecting this option until after observing normal traffic for a day or two so you can assign a reasonable latency threshold value.
    The system detects heavy URLs by measuring the latency tail ratio, which is the number of transactions whose latency is consistently greater than the latency threshold. A URL is considered heavy if its latency tail ratio is considerably above the global average, in the long run (default of 24 hours).
  6. In the Heavy URLs setting, add the URLs that you expect to be heavy (have high latency) at times in the form /query.html. If you are not sure which URLs to add, leave this list blank and let the system automatically detect heavy URLs by using automatic detection.
  7. In the Ignored URLs (Wildcards Supported) setting, add the URLs that you never want the system to consider heavy. The URLs in this list may include wildcards.
  8. If using automatic detection, in the Latency Threshold field, type the number of milliseconds for the system to use as the threshold for automatically detecting heavy URLs. The default value is 1000 milliseconds.
  9. Click Update to save the DoS profile.
You have now configured a DoS profile that includes heavy URL protection. Heavy URLs are detected based on latency. ASM tracks the probability distribution of server latency which is called heavy tailed.
To validate automatic detection, you can view the URL Latencies report periodically to check that the latency threshold that you used is close to the value in the latency histogram column for all traffic. By reviewing the report and sorting the URLs listed by latency, you can make sure that the URLs that you expect to be heavy are listed in the DoS profile. Also, if the system detects too many (or too few) heavy URLs, you can increase (or decrease) the latency threshold.

Recording traffic during DoS attacks

If you have DoS protection enabled, you can configure the system to record traffic during DoS attacks. By reviewing the recorded traffic in the form of a TCP dump, you can diagnose the attack vectors and attackers, observe whether and how the attack was mitigated, and determine whether you need to change the DoS protection configuration.
  1. On the Main tab, click Security > DoS Protection > DoS Profiles. The DoS Profiles list screen opens.
  2. Click the name of an existing DoS profile (or create a new one). The DoS Profile Properties screen opens.
  3. Select the Application Security check box. The screen refreshes and displays additional configuration settings.
  4. Toward the bottom of the screen, select the Record Traffic During Attacks check box. The screen refreshes and displays additional configuration settings.
  5. For Maximum TCP Dump Duration, type the maximum number of seconds (from 1 - 300) for the system to record traffic during a DoS attack. The default value is 30 seconds.
  6. For Maximum TCP Dump Size, type the maximum size (from 1 - 50) allowed for the TCP dump. When the maximum size is reached, the dump is complete. The default value is 10 MB.
  7. For TCP Dump Repetition, specify how often to perform TCP dumps during a DoS attack:
    • To record traffic once during an attack, select Dump once per attack.
    • To record traffic periodically during an attack, select Repeat dump after and type the number of seconds (between 1 - 3600) for how long to wait after completing a TCP dump before starting the next one.
  8. Click Update to save the DoS profile.
When the system detects a DoS attack, it performs a TCP dump to record the traffic on the virtual server where the attack occurred. The files are located on the system in /shared/dosl7/tcpdumps. The name of the file has the format: <yyyy_mm_dd_hh:mm:ss>-<attack_ID>-<seq_num>.pcap, including the time the dump started, the ID of the attack in logs and reports, and the number of the TCP dump since the attack started. If traffic being recorded is SSL traffic, it is recorded encrypted.
If working with F5 support, you can collect the TCP dump files into a QuickView file so that support personnel can help determine the cause of the DoS attack, and recommend ways of preventing future attacks.

Associating a DoS profile with a virtual server

You must first create a DoS profile separately, to configure denial-of-service protection for applications, the DNS protocol, or the SIP protocol.
You add denial-of-service protection to a virtual server to provide enhanced protection from DoS attacks, and track anomalous activity on the BIG-IP system.
  1. On the Main tab, click Local Traffic > Virtual Servers. The Virtual Server List screen opens.
  2. Click the name of the virtual server you want to modify.
  3. For the Destination setting, select Host and in the Address field, type the IP address for the virtual server.
  4. From the Security menu, choose Policies.
  5. To enable denial-of-service protection, from the DoS Protection Profile list, select Enabled, and then, from the Profile list, select the DoS profile to associate with the virtual server.
  6. Click Update to save the changes.
DoS protection is now enabled, and the DoS Protection profile is associated with the virtual server.

Displaying DoS event logs

You can display DoS Application event logs to see whether L7 DoS attacks have occurred, and view information about the attacks.
  1. On the Main tab, click Security > Event Logs > DoS > Application. The DoS Application event log opens.
  2. Review the list of DoS attacks to see what has occurred, what mitigation is in place, and what caused the attacks.
  3. Click the Attack ID link for an attack to display additional information in a chart form.

Sample DoS event log

This figure shows a sample DoS event log for a system (IP address 10.0.5.201) that has had quite a few DoS attacks over the past week. You can see that they have been mitigated using various prevention methods.

Sample DoS event log Sample DoS event log

Viewing DoS attack statistics

Before you can look at the DoS attack statistics, you need to have created a DoS profile so that the system is capturing the analytics on the BIG-IP system. You must associate the DoS profile with one or more virtual servers. If your browser is IE8 or earlier, you need to have Adobe Flash Player installed on the computer where you plan to review the data.
You can display charts that show information about DoS attacks on applications. The charts provide visibility into what caused the attack, IP addresses of the attackers, which applications are being attacked, and how the attacks are being mitigated.
  1. On the Main tab, click Security > Reporting > DoS. The DoS Application Statistics reporting screen opens.
  2. From the View By list, select the way you want to view information about DoS attacks. For example, click Client IP Addresses to see the IP addresses from which the attacks are emanating.
  3. If you want to filter the information that displays further, click Expand Advanced Filters and select the details you want to see.
  4. 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.
You can continue to review the details about DoS attacks on the reporting screens. As a result, you become more familiar with what caused the attacks, what applications are most vulnerable, and see the mitigation methods that are in place.
If you are recording traffic during attacks, you can view the TCP dumps related to the DoS attacks in /shared/dosl7/tcpdumps.

Sample DoS Statistics report

This figure shows a sample DoS Statistics report showing a number of DoS attacks listed by attack ID. The report shows the number of transactions that were dropped during these attacks which were all mitigated using source IP-based rate limiting. With this method of rate limiting, the system noticed a spike in requests coming from certain IP addresses and considered them to be suspicious IP addresses. The system limited the number of requests from these suspicious IP addresses to a reasonable number (before the attack started) or to the threshold configured in the TPS reached setting.

Sample DoS statistics report Sample DoS Statistics report

Viewing URL Latencies reports

For the URL Latencies report to include useful information, you need to have created a DoS profile with heavy URL protection so that the system is capturing the latency statistics. You must associate the DoS profile with one or more virtual servers.
You can display a report that shows information about the latency of traffic to specific web pages in your application. The report lists the latency for each URL separately and one row lists the latency for all URLs combined. You can use this report to check that the latency threshold that you used is close to the value in the latency histogram column for all traffic.
  1. On the Main tab, click Security > Reporting > DoS > Application > URL Latencies. The URL Latencies reporting screen opens.
  2. From the Time Period list, select the time period for which you want to view URL latency, or specify a custom time range.
  3. If you want to filter the information by DoS profile, virtual server, URL, or detection criteria, specify the ones for which you want to view the URL latency. By default, the report displays information for all items.
  4. Adjust the chart display options as you want.
    Display Option Description
    Display Mode Select whether to display the information as Cumulative or as related to the respective latency range, Per Interval.
    Unified Scale Select this check box to display all histograms using a single scale for all URLs, rather than a separate scale for each one.
    Order by Select the order in which to display the statistics: by the average server latency, the number of transactions, the histogram latency ranges (in milliseconds), or by how heavy URLs were detected.
  5. Review the latency statistics.
    • The report shows the latency for the most active URLs.
    • The Aggregated row summarizes the statistics for the URLs not included in the report.
    • If there is only one DoS profile or virtual server on the system, the chart does not include these columns.
    • The Overall Summary shows the latency of all traffic
  6. To focus in on the specific latency details for one row, click the latency histogram. A magnified view of the histogram is displayed in a separate window. The latency histogram shows the percentage of transactions for each range of latency (0-2 ms, 2-4 ms, and so on up to 10000 ms or 10 seconds).

The URL Latencies report shows how fast your web application returns web pages and can show typical latency for applications (meaning virtual servers associated with a DoS profile) on your system. It can help you to identify slow pages with latency problems that may require additional troubleshooting by application developers.

You can also use the URL Latencies report for the following purposes:

  • To determine the threshold latencies, especially the heaviness threshold.
    Tip: Set the heaviness threshold to approximately 90-95% of the latency distribution for the site. Filter the data by site (that is, by virtual server and DoS profile), and check the latency distribution in the histogram of the Total row.
  • To track the current heavy URLs. You can add or remove manually configured heavy URLs depending on the information in the report.
  • To monitor the latency distribution.

Sample URL Latencies report

This figure shows a sample URL Latencies report for a system with one DoS profile and one virtual server. It shows the latency for three web pages. One page (/) is performing within reasonable ranges displaying pages in 4 to 22 ms. However, two of the URLs, /dos_1.php and /dos_5.php, have much higher latency and might require some troubleshooting. While checking into the latency of those URLs, you can add them to the list of heavy URLs in the DoS profile so they do not trigger DoS mitigation.

Sample URL Latencies report Sample URL Latencies report

Implementation Result

When you have completed the steps in this implementation, you have configured the Application Security Manager to protect against L7 DoS attacks. Depending on your configuration, the system detects DoS attacks based on transactions per second (TPS) on the client side, server latency, or both.

In TPS-based detection mode, if the ratio of the transaction rate during the history interval is greater than the TPS increased by percentage, the system considers the URL to be under attack, the IP address to be suspicious, or possibly the whole site to be suspicious.

In latency-based detection mode, if there is a latency increase and and at least one suspicious IP address, URL, or heavy URL, the system considers the URL to be under attack, the IP address to be suspicious, or possibly the whole site to be suspicious.

If you enabled heavy URL protection, the system tracks URLs that consume higher than average resources and mitigates traffic that is going to those URLs.

If you chose the blocking operation mode, the system drops requests from suspicious IP addresses and URLs. If using the transparent operation mode, the system reports DoS attacks but does not block them.

If using iRules, when the system detects a DoS attack based on the configured conditions, it triggers an iRule and responds to the attack as specified in the iRule code.

After traffic is flowing to the system, you can check whether DoS attacks are being prevented, and investigate them by viewing DoS event logs and reports.

Table of Contents   |   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)