We at F5 SIRT assist F5 customers when they are under attack to detect and mitigate the attacks they are facing. The F5 BIG IP product suite can mitigate many attacks against web applications, and the F5 SIRT publishes public documentation of those mitigations. 

This article describes the available options in the BIG IP Advance WAF when a web app is under a Distributed Denial-of-Service (DDoS) attack. 

Part 1 includes an overview of BIG IP Advanced WAF dos profile configuration and explains how it works. 

Part 2 is about reading the DoS profile reporting and what are the common mitigations we use to stop Application DDoS using BIG IP Adv WAF.

 

Application DDoS overview

Web Application Distributed Denial-of-Service (ADDoS) attacks have been around for many years due to their ease of execution and the immediate, visible damage they cause. While they damage “only” the service, they can be tricky to mitigate. Here are some facts on Application DDoS attacks:

• They are based on legitimate Layer 7 requests, with many clients “asking” a web page thousands and tens of thousands of times.
• The load of the requests exhausting backend server and consuming web application resources such as memory, CPU, Disk etc
• They are relatively easy to execute with simple tools and many offerings, including DoS As A Service.
• It is also easy to hide attacker trails and there is no one to complain to.
• Mitigating ADDoS can be easy when they are noisy but can be tricky to detect and mitigate when they use valuable exit points to flood from or execute low and slow attacks that add permanent load on the web application.

The impact of these attacks ranges from performance degradation—where users experience slow load times or browser timeouts—to severe cases where the web application becomes completely inaccessible, e.g. site down.

Modern applications, designed to scale up or out to handle increased load, can unintentionally worsen the problem, leading to what is known as a "cost attack," where the attacker’s goal is to increase the operational costs for the web application owner by forcing them to allocate additional resources, thus increasing money spending.

 

F5 Anti DDoS: Detection and prevention

BIG IP Adv WAF is an inline device, which means that it sees all the traffic. By applying different thresholds on the traffic path with "dos profile", we can find anomalies that indicate the increase of load.  Those anomalies will then be reflected in the "dos profile" reporting to understand if we are mitigating the attack load and are we mitigating the right sources.  

The previous chapter described the available configuration in the doc profile. This chapter will describe the reporting for those configurations.

 

Reporting for "dos profile"

Reporting is vital for security products. It provides the feedback loop to understand if the current policy definition mitigating the attack or refinement is needed to effectively stop the attack.  Any changes in the policy configuration are reflected in the reporting and provide a clear picture and understanding of if the attack is truly mitigated. 

The BIGIP Advance WAF “dos profile” reporting can be found under:

Security  ››  Event Logs : DoS : Application Events

The report includes the following items:

Time – Time of the event occurred, time stamp of when dos profile entered attack started of the measurement.

Virtual server – Shows which virtual server the entry belongs to. Since you can use "dos profile" on several virtual servers, you need to make sure you are looking at the right virtual server. You can filter to a specific virtual server which is currently under attack by using customer search.

Profile name – You can create several "dos profile"  with different settings and assign a specific one to the virtual server.

Event: This field provides the details on the actions performed by the “dos profile” due to exceeding the configured thresholds and includes the following options:

• Attack started – Threshold activated start time. "dos profile" measures it, and, at this time, the relevant threshold has been reached.
• Attack ended – Traffic threshold on this entity is below the configured threshold. Note that this is an internal time stamp. End time doesn’t mean the attack ended. It means that the engine’s threshold is reduced.
• Suspicious entity – Specify the relevant entity that the threshold activated on

o   E.g. measuring RPS on: Source IP, Device ID, Geo Location, URL, Site-wide.

• Change mitigation – Changing the current mitigation due to the prevention duration settings. Changing means the attack didn’t go below the threshold – i.e. attack is still occurring

 

Mitigation: Transparent

Transparent mode is a good visibility tool to examine traffic loads before the attack and without applying any mitigation that can affect traffic. Transparent operation mode will not mitigate (block) offending requests

*We will cover the blocking in the blocking section.

 

TPS 

Displays the current site TPS in any of the events started, change mitigation, ended or suspicious entities events; remember that while the GUI says TPS, those are actually RPS.

 

Detection Threshold

Displays the TPS number (threshold) that triggered the event “attack started”. that is the configured threshold in the "dos profile".

 

Mitigate To Threshold

Displays the TPS number threshold that will allow the system to generate the event “attack stopped”

Display the RPS that is reduced to by the mitigation. This is the number of RPS that are below the threshold and will change the event to “attack ended”

 

Threshold Condition

Provides an important indication on two aspects of the "dos profile" configuration:

Thresholds Mode:

• Manual Threshold
• Auto-calculated Threshold

Referring to the setting Thresholds Mode that determines if the thresholds are manually defined or calculated automatically. I recommend using “Manual Threshold” setting for better controlling the threshold refinement. Part 1 describes those settings.

Threshold measurement types:

• Relative – ratio of TPS percentages
• Absolute – fixed number of TPS

Part 1 describes this in detail for each of the measurements, which provides us with a way to “catch” the attack by identifying a ratio increased or a fixed increase. These files describe the method that “caught” the traffic spike.

Reminder: Each measurement has two configuration lines. The first is a ratio-based measurement with an increase of percentage

The second line is a fixed threshold which anything above this limit is considered an attack and this is being reflected in the Threshold Condition

 

Entity Type

Indicates which entity we measure on exceeds the defined thresholds. The options reflect the type of measurements we have configured in the "dos profile":

• By Source IP
• By Geo-Location
• By URL
• By Site-Wide

If heavy URL adds a URL due to slow processing time (load) it will also be displayed here.

 

Entity 

The actual entity of the “Entity Type” that the thresholds were activated on, for example:

The actual Source IP addresses, the actual country name for Geolocation or the actual URL name that by URL detection.

• By Sources IP’s – the IP address
• By Geolocation – the state
• By URL – the URL name URL
• Heavy URL – URL name

 

Filtering

The reporting page includes the option to filter on any of these fields. The basic search option is to sort by past time. Advance filtering is done by clicking “Custom Search” then drag and drop the field to the search box. Common filters to use are:

• Filter by virtual to see only entities that apply to a specific web application
• Filter by Entity type and chose specific type such as source IP.

Note: only fields that are underlined when the mouse is hovering over them can be filtered.

Note: concept  - The anomaly engine measures RPS and any defined threshold that exceeds are considered an attack. This is how the system works to detect loads on various entities. But that is not how a ADDoS attack executes. The threshold can be exceeded few times during a ADDoS flood. The system is deciding when to end an attack and start one. We don’t want never ending attacks sate, so we cut it into chunks while a ADDoS is about continues load over time

 

Transparent

While transport mode provides visibility before and during an attack, the only way to mitigate ADDoS attack is by mitigating the offending sources. When the "dos profile" is in blocking mode, more data will be shown in the mitigation field.

You can find yourself with too low thresholds – false positives. Or too high thresholds – false negative. So know your app traffic and fine-tune the threshold in transparent mode.

When the dos profile is in transparent mode, you can see the load in the reporting charts:

Security  ››  Reporting : Application : Charts

When in blocking, the traffic will not be logged in this report. Only the "dos profile" report mentioned above.

 

Blocking

Mitigation:

• Transparent – in operation mode transparent there will be not mitigations applied.
• In blocking mode, the mitigation methods will be displayed with the following possibilities:
• Client-Side Integrity Defense – was applied on the entity
• CAPTCHA Challenge – was applied on the entity
• Request Blocking – was applied on the entity

Blocking- in most of the ADDoS, the attacks are noisy and clear to notice, therefore the thresholds will apply and block the attacks.

Possible mitigations:

• CSID – will block – request will not be sent to the backend
• CPATHCA – will block – request will not be sent to the backend

Requests that get sent will be blocked with a reset TCP flag on the connection.

• Rate limiting – reducing the traffic by half of current configured criteria with TCP reset flag.
• Block all- eliminate all traffic from this source IP with TCP reset flag on the connections arriving.

 

Understanding "dos profile" reporting

The "dos profile" generates lots of valuable information to provide you with as much detail as possible to understand the current state of the ADDoS attacks and how they affect the backend application.

This report will help us with:

• What are the current thresholds to catch the attack? Is this the attack?
• Do we have the right thresholds? Or should we fine-tune?
• What additional information can we get from the reporting that assists us with blocking the offending sources?
• Are we mitigating the attack successfully?

 

Big picture graphs 

If the load continues, that means we need to expand mitigation and recommended escalation can be:

• Blocking source IP is good, but blocking entire counties is better
• Rate limiting / blocking all on URL
• Rate limiting on entire site. If the site is down, it is ok
• CAPTHCA to all sites – is an effective way to bring sites down.

It will filter all the bots, including the offending bots sources

Always look at the dashboard that provides the big picture and provides valuable data at:

Security  ››  Reporting : DoS : Dashboard

 

 

Summary

Application DDoS is still popular and can cause damage to your service. With F5 BIG-IP Advance WAF, you can detect and mitigate such attacks with the build for ADDoS detection and prevention. Keep in mind the following:

• Out-of-the-box thresholds are good for most web sites
• Depending on the web site traffic fine-tuning thresholds might be needed.
• Start with CSID: this will scrap some of the sources that are not browsers
• Use CAPTHCA: Remember, CAPTHCA is used for identifying a human but also for incrementing a source being the smoking gun. E.g. answer/ not answer CAPTHCA but still sending many RPS
• Blocking IP: don’t hesitate to block IP’s when you are under ADDoS. Blocking a few legitimate users is better than having the site down.
• Using IP intelligence to filter traffic is always good practice and useful mitigation.
• Use "dos profile" for detecting and mitigating Application DDoS. This is its purpose!

 

Additional F5 Resources:

• Open ESRP ticket with the F5 SIRT. https://my.f5.com/manage/s/article/K000135931
• Leveraging mitigation, the F5 cloud services with their top-of-the-line ADDoS mitigation on all layer 3,4 and layer 7.  https://www.f5.com/products/distributed-cloud-services