F5 BIG-IP Advanced WAF – DOS profile configuration options.

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 the web applications, and the F5 SIRT publish public documentation of those mitigations.  This article describes the available options in the BIG IP Advance WAF when a web app is under a DDoS attack.

F5 BIG-IP Advanced WAF is the perfect tool for detection and prevention of application Distributed Denial-of-Service (DDoS) attacks against a web application. This article will review the possible configurations of the DOS profile, also known as Advanced WAF anti-DDoS feature to stop those attacks.

 

DOS profile: general settings

The first page of the DOS profile is the general settings, which include configuration that applies to the entire DOS profile. Here are a few good-to-know settings:

• Source IP address whitelist – Link to a page for adding source IPs to a list that will be exempt from any DOS profile mitigations.
• Geolocations – Allow and deny options to exempt or block entire countries based on source IP geolocation. 
• CAPTHCA response – Editing the CAPTCHA response page that will be presented to the end user when CAPTHCA mitigation is activated.
• Single Page Application – this option should be enabled if the web application is built with a client-side framework that is sending a JSON payload to render the web pages. The DOS profile uses java script injections in HTML pages as mitigation and since applications that use JSON responses, java script can’t be injected.  Enabling this option provides the functionality to inject in web applications that are built with client-side frameworks.

DOS profile includes two main mitigations:  

• TPS-based detection – Measures the ingress traffic on various entities. (Measure RPS)
• Behavioral & stress-based detection – measure backend stress and uses machine learning models. (Measure TPS)

This article focuses on TPS-based detection.

Note* The GUI indicates TPS, but it is actually measuring RPS.

Operations mode allows the option to run the DOS profile in detection mode or in detection and mitigation mode:

• Transparent mode means detection only with no active mitigation applied to the traffic. Choosing transparent mode will populate the reporting and provide an idea on the right thresholds, which is useful for fine-tuning thresholds and avoiding blocking due to false positives.
• Blocking mode will activate the system’s mitigations and will block traffic according to the configuration. This is the actual value of the system, preventing offending traffic from reaching the web application.

Thresholds Mode Specifies the method by which the detection is measured. We will keep it in manual mode as we want to control the settings to have the ability to fine-tune on what is being done by the system.

 

DOS profile: TPS-based Detection

Before reviewing the configuration, let’s examine the concept of the DOS profile with TPS-based detection. The “dos profile” is an anomaly engine that measures the amount of requests per second (RPS) arriving at the virtual server. By monitoring various points along the HTTP transaction and detecting increases in traffic, the engine presents the entity on which the RPS exceeded the defined threshold. The system considers traffic increases as an indication of a possible attack on the entity. Once the RPS exceeds the defined values, the configured mitigation will be activated on the specific entity.

The general concepts of detection and mitigation is about:   Slide 14

1. Monitoring entities: Source IPs, Geo IP, App URL’s & objects and FQDN
2. Detecting Increase: RPS *
3. Activating Mitigation: CSID, CAPTHCA, Rate limiting or Request blocking

Note* The GUI indicates TPS, but it is actually measuring RPS.

Detection Criteria: By Source IP

The first type of detection in the configuration page is “by source IP” where the anomaly engine measures the amount of request per second from any source IP that arrives the virtual server.  The idea is simple, any IPs that send too many RPS consider to be an offending source.  Standard users will have a normal browsing pattern with few RPS arriving from a single source IP, but source IP’s that are part of a DDoS attack will send many RPS as this is what dos is all about, flooding with many requests.

The configuration is divided into two sections: detection and mitigation

1. Detection includes the thresholds configuration
2. Ratio - relative threshold
3. Fixed - absolute Threshold
4. Mitigation methods: include check boxes with mitigation options.

Detection: ratio 

The detection configuration consists of two lines. The first line is the relative threshold that is based on the RPS increase ratio that is calculated with two time intervals:

• Long - accumulates an average RPS of 1 hour, which is measured every 10 seconds
• Short - accumulates an average RPS of 10 seconds, which is measured every 10 seconds

In other words, the engine measures historical (long) RPS and current (short) RPS and calculates the percentage of growth in the RPS over time. Any increase in RPS that exceeds the 500% default value will activate the enabled mitigations.

But since RPS from single-source IP can grow from low number to big numbers at any time and the ratio calculation will be reached, we need to have another value that will be the minimum condition and act as a safety net to prevent such false positives.

For this reason, the “TPS increase by” is AND with “Minimum TPS thresholds for detection”: at least 40 transactions per second.

For example, if the TPS % is 640% and reached at least 40 TPS, then the condition is true and the mitigation can be activated.

Detection: fixed

In addition to the percentage (ratio) of RPS increases, we also have a fixed number of TPS that anything above it will be considered an attack. This is the second line of the detection section with “Absolute Threshold”. The relative thresholds and the absolute thresholds are OR’ed. Which means the first one to reach the threshold will activate the mitigations

Detection section summary 

• Percentage condition – over-time growth
• AND Percentage grow with minimum reached to prevent false positive
• OR fixed number growth.

Having a percentage-based TPS increase and a fixed number increase makes it very useful to find the right threshold so that anything below it is not an attack and traffic above it will be considered an attack.

Mitigation methods

The mitigations section is where the prevention happens. When the DOS profile mode is in blocking mode, those mitigations will be activated once the detection thresholds are reached.

There are three mitigation methods:

• Client-Side Integrity Defense
• CAPTCHA challenge
• Rate limiting / Request Blocking

Client-Side Integrity Defense 

Client-side mitigation is a simple by effective test to understand who is the HTTP client that sends the most requests. Any request from a source IP that will pass the threshold will get a java script in the response that will reach the HTTP client and perform actions to determine if this is a bot or a browser.

This is the main point of actions that happen when CSID is activated:

• Any request arrive to the virtual server will be held by the Adv WAF engine
• A fake response, including a JavaScript challenge is sent to HTTP client
• The JavaScript reach the HTTP client and check the nature of the client with some basic capabilities. A client is considered legitimate if it meets the following criteria:

o   The client supports JavaScript

o   The client supports HTTP cookies

o   The client executes computational challenge inside the JS

• The response arrives at the Advanced WAF and is evaluated. If satisfied, it is considered a legitimate client that can access the site.
• The original request is then sent to the backed servers.

Key value points:

• CSID provides a fast way to filter simple bots and prevent them from flooding the app.
• CSID is used to identify offending HTTP clients behind source IPs that include both good clients and attacking clients.
• Transparent to the user and done “under the hood”
• If the HTTP clients access a resource file such as images that Java script can’t be injected into the response without passing the challenge, the request will be reset on the TCP/IP level.

Mitigation 

• If the client didn’t pass the challenge, any additional requests will be blocked with a reset connection on the IP level.
• If it did pass the challenge and is still sending requests that exceed the defined, DOS profile will change the mitigation to the one below.

CAPTCHA Challenge  

The second mitigation is CAPTCHA that is considered the ultimate tool to verify if the HTTP client is being used by a human or not. The idea is to send a response to the originating HTTP client and ask them to answer a question that only humans can solve. Once the question is answered correctly, it is assumed that the source is a true person.

Key points:

• The CAPTCHA challenge can be customized and supports HTML and Java scripts. The response edit includes “first response” and “failure response” types since the messages are different on a first attempt and a later attempt.
• The flow of the CAPTHCA is similar to the CSID
• Works at the HTTP level (above IP). Any source IP that includes many clients behind it (NAT’ed IP) will get this CAPTCHA. So instead of blocking IP, we will block the request and keep the other valid clients working.
• Note about CAPTCHA:

CAPTCHA challenges can also be automated using CAPTCHA farms, solvers and other types of automation. However, even if the CAPTCHA is solved automatically, it acts as a smoking gun to  incriminate a client. HTTP clients that send too many RPS and will get a CAPTCHA and the challenge is solved BUT still sending many RPS is a clear indication of an offending source, i.e. if solved and still flooding, this is an offending source which is a smoking gun for this source.

Mitigation 

• If answered and not sending many RPS, this is a human with valid usage.
• If answered and still sends many RPS – smoking gun for bot
• If not answers and still sends many RPS – smoking gun for bot move to the next mitigation.

Request Blocking

The last mitigation is Request Blocking, which is the most effective method when under a DDoS  attack. Despite of the fact that app DDoS is a layer 7 attack, dropping the request at the network layer is the good way to reduce the amount of traffic hitting the web application.  Request blocking has two options:

• Rate limit: will limit the amount of allowed request
• Blocking: will block all IP’s

Key point

• Rate limiting is about reducing the amount of traffic
• Rate limiting can also drop valid users, but when there is an emergency, keeping the site up is more important than dropping the connection for a few valid users.
• Rate limits are calculated by using the long and short time frames. For example if the long time interval was 50 TPS and now there is an increase to 150 TPS (slide 19) Rate limit will reduce the source to 50 TPS.
• Any request that exists on this connection will be reset as well.
• Request blocking is done on the source IP level and not on layer 7.
• The Blocking option allows to block ALL traffic arriving from the source. (Therefore, there is no blocking on URL / site-wide)

While CSID and CAPTCHA try to understand who is the offending source, bots or browsers,  request blocking (rate limiting, ad blocking all) is indifferent to the “identity” and limits the amount of requests for any sources that exceed the threshold.

Mitigation  

• Rate limiting is used when you can’t block all the traffic, but you can still limit the amount of traffic that arrives.
• Blocking is the most aggressive mitigation since it kills the TCP IP connection, which also makes it to most effective mitigation for offloading the flood.

TPS-based: by source IP – Summary

 Source IP is measuring RPS on source IP. Any source IP that exceeds defined thresholds will activate  one of the three configured mitigations:

• Client-Side Integrity Check - filter bots
• CAPTCHA Challenge – incriminate sources
• Request Blocking – Reduce connections

 

Detection Criteria: By IP Geolocation

The next type of detection is measuring RPS per geolocation source IP’s which means measuring traffic in individual counties. Source IPs are allocated at the world level to countries, and BIG-IP has a list of those countries that map to source IPs. The detection method is the same concept of measuring an increase in requests per second arriving from a specific county with ratio-based calculations.

When the geolocation detection criteria are reached, the following mitigation can apply:

• If Client Side Integrity Check is checked- all clients coming from the specific country will get the Client Side Integrity Check.
• If CAPTCHA Challenge is checked – all clients coming from the specific country will get the CAPTCHA
• If Request Blocking is checked – all clients from this country will get rate limit. In case of “block all” then all users coming from this country will be blocked at the network level.

Key point

• DDoS arriving from a specific county that is not expected to get a service is easy.
• Remember the general setting page ? Once geolocation detection indicate an attack from a specific country is it easy to block specific countries from that page.
• Can be bypass with proxies exiting from a “good” country

 

Detection Criteria: By URL

The next detection method is “by URL” where the system monitors the request per second on all the URL’s in the site. The idea is to measure the load on the web application side and conclude which of the URL’s is being flooded. The detection concept is the similar to “by Source IP”  with the same formula of ratio based on long and short (relative) with a safety net of “minimum TPS” and a fixed-based (absolute). For example:

• Relative thresholds: TPS increase by 500%  AND   at least 200 TPS
• Absolute thresholds: OR  TPS reached 1000 TPS (default)

The Heavy URLs checkbox will add a measurement of latency time for each URL so that URL’s that their processing time is long, will be added to the mitigated URL in addition to the URL that exceeded the threshold. (No need to define any URL in the Policy URLs page)

When the URL detection criteria are reached, the following mitigation can apply:

• All clients that access the URL that exceeds RPS thresholds will get:

• Client-Side Integrity Check
• CAPTCHA Challenge

• All source IP’s that access the a URL that exceeds RPS thresholds will be rate-limit

• Request Blocking – Rate limit (No block all)

Note: there are no options to block all on URL since this will make the URL unavailable to anyone, which is not something we want to do.

Key points

• Since the system now measures RPS on the URL, we expect to see a higher threshold, hence the defaults are higher.
• By URL is a really good approach for detecting load-on URL from a DDoS attack that changes the source IPs every now and then (random IPs).
• Measuring RPS on the URL also helps us detect DoSing sensitive application points. For example flooding the login page to prevent users from logging in.
• Setting the right threshold for URL’s can be done by knowing the web site URL history. E.g. Max average RPS of +10%-20% can be a good starting point.

 

Detection Criteria: Site wide

The last detection is “by site wide” that provides a global RPS measurement. Sometimes the floods will avoid the thresholds of “by source IP” or “by URL  and measuring site-wide provides another layer to detect increases in RPS. Measuring RPS  is also a great performance problems detection tool or capacity planning reference.

The system will monitor the amount of requests arriving to the virtual server and thresholds are calculated with a ratio of long and short AND with minimum TPS thresholds for detection. They are ORed with a fixed number of TPS reached, which is the same concept of source IP’s and by URLs.

When the site-wide detection criteria are reached, the following mitigation measures can apply:

• If Client Side Integrity Check is checked- All clients that access the site will get CSID check.
• If CAPTCHA Challenge is checked – All clients accessing the web site will get CAPTCHA
• If Request Blocking is checked, clients accessing the web site will be rated limited to their historical values.

Key points:

• Since the system is now measuring the entire app (VS), the default threshold values are higher than URL’s based.
• Fast approach to filter bot bots on the entire site with CSID.
• Low and slow attacks are less likely to exceed the by URL and by source IP threshold, and the only way to notice them is to measure the entire web application.
• Rate limits apply to current and, or new connections that exceed the threshold.
• No block all, this will not make sense.

Prevention duration

An additional mitigation strategy that the system is doing is by switching between mitigations as long as the thresholds are exceeded.

• Escalate top-down every 120 seconds if thresholds are still exceeding thresholds.
• Prevention fall back, according to the order in the GUI.

• Client Side Integrity Check  -> if enabled switch to next one
• CAPTCHA Challenge -> if enabled, switch to next one
• Request Blocking

 

Summary

The BIG-IP Advanced WAF “dos profile” TPS-based is a powerful anomaly engine that can detect increases in RPS on source IP, Geolocation, URL and site-wide and then apply mitigations to stop the attack. The mitigations that apply to traffic range from transparent checks (CSID) human checks and incrimination tools (CAPTVCA) and aggressive load dropping with rate limiting and block-all.

Presentation attachedץ