Mitigate HTTP flood attacks by configuring accurate access control or frequency control rules - Anti-DDoS

After you add your website to Anti-DDoS Proxy for protection, if HTTP flood attacks occur, you can perform feature analysis and configure rules based on HTTP request headers to identify and block HTTP flood attacks. The HTTP flood mitigation feature can be used in different scenarios, such as hotlink protection and protection of the website management system. This topic describes how to configure the HTTP flood mitigation feature.

Services for defending against HTTP flood attacks

A Challenge Collapsar attack or HTTP flood attack is a type of distributed denial of service (DDoS) attack at the application layer. Attackers use hosts that they control to continuously send disguised HTTP or HTTPS requests to a specific web server. For example, these hosts may frequently request a web page or a logon page that consumes a large number of server resources to exhaust the server resources or network bandwidth. As a result, the server responds to normal requests more slowly or fails to process normal requests.

Unlike traditional network-layer DDoS attacks, HTTP flood attacks simulate normal requests so that they are harder to detect. To improve website security, Alibaba Cloud provides Anti-DDoS Proxy and Web Application Firewall (WAF) to defend against HTTP flood attacks.

Anti-DDoS Proxy

Anti-DDoS Proxy defends against volumetric attacks to ensure that bandwidth exhaustion and resource exhaustion do not affect network infrastructure. Anti-DDoS Proxy instances are usually deployed at the edge of a network. Anti-DDoS Proxy provides the intelligent protection feature and the HTTP flood mitigation feature to mitigate HTTP flood attacks. You can configure custom rules for the HTTP flood mitigation feature.

Intelligent protection: Based on the big data capabilities of Alibaba Cloud, the intelligent protection feature can learn website traffic patterns, use algorithms to analyze anomalies and attacks, automatically deliver accurate access control rules, and dynamically adjust protection models. This helps detect and block web attacks, such as malicious bots and HTTP flood attacks. After you add your website to an Anti-DDoS Proxy instance, the intelligent protection feature is enabled by default. For more information about the intelligent protection feature, see Use the intelligent protection feature.
HTTP flood mitigation: This topic describes the HTTP flood mitigation feature and how to configure custom rules for the feature. If your website suffers from HTTP flood attacks, you can perform feature analysis on HTTP request fields and configure accurate access control rules or frequency control rules for your website. You can use frequency control, behavior analysis, and IP address blacklists to mitigate DDoS attacks.

WAF

WAF analyzes the HTTP and HTTPS traffic at the application layer, and identifies and defends against malicious traffic to a website or app. This prevents performance issues of website servers caused by malicious intrusions. WAF uses a variety of methods to identify and defend against application-layer attacks. The methods include input validation, rule sets for specific vulnerabilities, session tracking, and other protection mechanisms, such as verification codes, JavaScript validation, and cookie-based authentication. WAF instances are usually deployed close to the server side. This way, WAF instances can better monitor the traffic to the server side and enforce security policies at the application layer.

You can choose between Anti-DDoS Proxy and WAF based on your security requirements. If you want to defend against only HTTP flood attacks and HTTP flood attacks severely affect your website, we recommend that you choose Anti-DDoS Proxy. For example, if HTTP flood attacks make your website inaccessible, we recommend that you choose Anti-DDoS Proxy. If HTTP flood attacks do not have a critical impact on your website, we recommend that you choose WAF. For example, if HTTP flood attacks slow the responses to normal requests, we recommend that you choose WAF. However, to achieve optimal protection effectiveness, we recommend that you deploy both Anti-DDoS Proxy and WAF to protect your website from malicious traffic and attackers.

Suggestion on configuring the HTTP flood mitigation feature

We recommend that you configure this feature to allow or filter out traffic that has specific characteristics when your website is under HTTP flood attacks. This feature is not recommended for routine protection.

You can use the following methods to check whether HTTP requests have specific characteristics, such as the same source IP address or the same field in the URIs. Then, you can configure custom rules based on these characteristics.

On the Attack Analysis page of the Anti-DDoS Proxy console, view the attack events of the Web Resource Exhaustion type. Go to the event details page to view the related information such as the attacker IP addresses, User-Agent, Referer, HTTP methods, and client fingerprints. For more information, see View information on the Attack Analysis page.
On the Log Analysis page, view the fields in the Anti-DDoS Proxy logs, such as real_client_ip, http_user_agent, http_referer, and request_method. For more information, see Fields included in full logs.

HTTP flood mitigation rules

If you turn off Rate Limiting when you create a rule, an accurate access control rule is created. If you turn on Rate Limiting, a frequency control rule is created. The system matches a request against accurate access control rules first and then frequency control rules. If a rule is hit, the matching stops.
Note
The intelligent protection of Anti-DDoS Pro automatically generates precise access control rules starting with smartcc_, which also adhere to this matching logic.
To improve the default mitigation effectiveness against HTTP flood attacks, the mitigation engine of Anti-DDoS Proxy provides two built-in frequency control rules. The built-in rules are displayed in the Frequency Control Rules section. The names of the rules are Built-in HTTP Flood Mitigation Rule - Based on Request Frequency of Clients and Built-in HTTP Flood Mitigation Rule - Based on Response Codes of Origin Servers. You can only view or delete the built-in rules.

Rule name	Accurate access control rule	Frequency control rule
Description	When a request matches the condition of a rule, the request is processed based on the action that is specified by the rule. Note If the name of a rule starts with `smartcc_` in the list of accurate access control rules, the rule is automatically delivered by the intelligent protection feature of Anti-DDoS Proxy. After the rule expires, the rule is automatically deleted.	When a request matches the condition of a rule and reaches the specified threshold during the specified statistical period, the request is processed based on the action that is specified in the rule. Important If a built-in frequency control rule is deleted, you cannot restore the rule. Proceed with caution. If you want to delete a built-in frequency control rule, we recommend that you delete the built-in rule and then configure a custom frequency control rule based on the access frequency and characteristics of your key domain name or port to improve mitigation effectiveness against HTTP flood attacks.
Validity period	You can select Permanent or Custom Valid Period for a rule. Valid values of Custom Valid Period: 5 to 120. Unit: minutes. Note If you select Custom Valid Period, the rule is automatically deleted after the rule expires.	A rule never expires.
Matching logic	Matches all rules. If a request hits multiple rules, the request is processed based on the action specified in the rule that ranks highest. For example, if a request hits Rule 1 and Rule 2, the request is processed based on the action that is specified in Rule 1. Rule 1 is marked as 1 and Rule 2 is marked as 2 in the following figure.	Matches all rules. If a request hits multiple rules, the request is randomly processed based on the action specified in one of the rules.
Limit	You can configure up to 20 accurate access control rules for each domain name.	You can configure up to 20 frequency control rules for each domain name.

Cookie insertion

If you use Anti-DDoS Proxy to protect your website, cookies are inserted in the following scenarios:

Scenario 1: The HTTP flood mitigation feature is enabled.
After you enable the HTTP flood mitigation feature, Anti-DDoS Proxy inserts cookies into the client of your website, such as a browser, to distinguish your client from other clients and collect statistics on your client. When users visit your website, the inserted cookies are included in HTTP requests. Anti-DDoS Proxy checks whether HTTP flood attacks exist in traffic based on the statistics. If attacks occur, traffic scrubbing is triggered to mitigate the attacks. To disable the HTTP flood mitigation feature and prohibit cookies from being inserted, go to the Mitigation Settings > General Policies > Protection for Website Services tab. If you disable the HTTP flood mitigation feature, Anti-DDoS Proxy cannot proactively identify and mitigate HTTP flood attacks.
Scenario 2: The Action parameter of a mitigation rule is set to JavaScript Challenge.
After you set the Action parameter of a mitigation rule to JavaScript Challenge, cookies are inserted into HTTP request headers to obtain the fingerprint of the browser on the client. The collected fingerprint includes the host field and the height and width of the browser. If access traffic hits the mitigation rule, Anti-DDoS Proxy performs CAPTCHA verification and checks whether HTTP flood attacks are launched from the client. To prohibit cookies from being inserted, go to the Mitigation Settings > General Policies > Protection for Website Services tab to disable the HTTP flood mitigation feature. If you disable the HTTP flood mitigation feature, Anti-DDoS Proxy cannot proactively identify and mitigate HTTP flood attacks.

Configure an HTTP flood mitigation rule

Prerequisites

A website service is added to Anti-DDoS Proxy. For more information, see Add websites.

Procedure

Log on to the Anti-DDoS Proxy console.
In the top navigation bar, select the region of your instance.
- Anti-DDoS Proxy (Chinese Mainland): If your instance is an Anti-DDoS Proxy (Chinese Mainland) instance, select Chinese Mainland.
- Anti-DDoS Proxy (Outside Chinese Mainland): If your instance is an Anti-DDoS Proxy (Outside Chinese Mainland) instance, select Outside Chinese Mainland.
In the left-side navigation pane, choose Mitigation Settings > General Policies.
On the General Policies page, click the Protection for Website Services tab. In the left-side list of domain names, select a domain name.

In the HTTP Flood Mitigation section, click Settings. On the page that appears, click Create Rule in the upper-right corner of the page. In the dialog box that appears, configure the parameters and click OK. The following table describes the parameters.

Parameter	Description
Rule Name	The name of the rule. The name can be up to 128 characters in length and can contain letters, digits, and underscores (_).
Match Conditions	The match condition of the rule. For more information, see Appendix 1: Supported HTTP request fields. Note You must configure the Field Value parameter. The value of the Field Value parameter for an accurate access control rule is case-sensitive. The value of the Field Value parameter for a frequency control rule is not case-sensitive. You can configure up to five conditions. If multiple conditions are specified, a request hits the rule only when all conditions are met.
Rate Limiting	Specifies whether to enable verification based on rate limiting. If the switch is turned off, the rule is an accurate access control rule. If the switch is turned on, the rule is a frequency control rule. After you turn on the switch, you must configure the Statistical Object, Duration (Seconds), and Threshold (Occurrences) parameters. Valid values of the Statistical Object parameter: IP and Custom Header. You can also select Status Code to configure the related settings based on the quantity or percentage of status codes.
Action	The operation that is performed when a request meets the conditions. Valid values: Allow: allows the request. Block: blocks the request. JavaScript Challenge: performs CAPTCHA verification to verify the source IP address of the request. Monitor: records the information about the request in logs and allows the request. Note If you turn on Rate Limiting, you can set the Action parameter only to Block, JavaScript Challenge, or Monitor.
Validity Period	If you turn off Rate Limiting, this parameter specifies the validity period of an accurate access control rule. Valid values: Permanent and Custom Valid Period. If you select Custom Valid Period, you must specify a value from 5 to 120. Unit: minutes. Note If you select Custom Valid Period, the rule is automatically deleted after the rule expires. If you turn on Rate Limiting, this parameter specifies the validity period of a frequency control rule. Valid value: Custom Valid Period. You must specify a value from 1 to 1440. Unit: minutes.
Advanced Settings	If you turn on Rate Limiting, deduplication is supported when statistics are collected. You can select IP, Header, or URI for the Statistical Object parameter. Scenario 1: The deduplication mode is enabled. The following figure shows an example. If the same source IP address uses the same URI to access servers no less than 200 times in 30 seconds, access requests from the IP address are blocked. In this case, if the same source IP address uses the same URI to access servers multiple times, the number of access requests is counted as one. Scenario 2: The deduplication mode is disabled. The following figure shows an example. If the same source IP address uses the same URI to access servers no less than 200 times in 30 seconds, access requests from the IP address are blocked. In this case, if the same source IP address uses the same URI to access servers 10 times, the number of access requests is counted as 10.

Go back to the HTTP Flood Mitigation section and turn on Status.

Appendix 1: Supported HTTP request fields

Field	Description	Logical operator	Example
IP	The source IP address of the request. The value can be a single IP address or a CIDR block.	Belong To and Not Belong To	10.10.10.10
URI	The request URI. Example: `/action/member/id.php?id=1&td=2`.	Include, Not Include, Equal To, Not Equal To, Length Less Than, Length Equal To, Length Greater Than, Prefix Match, Equals to One of Multiple Values, and Not Equal To One of Multiple Values Note If the logical character is Equal To or Not Equal To, the value must start with a forward slash (`/`).	/action/member/id.php?id=1&td=2
User-Agent	The browser information about the client that initiates the request. The information includes the browser identifier, rendering engine, and version.	Include, Not Include, Equal To, Not Equal To, Length Less Than, Length Equal To, Length Greater Than, Equals to One of Multiple Values, and Not Equal To One of Multiple Values	Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.XX.XX Safari/537.36
Cookie	The cookie in the request.	Include, Not Include, Equal To, Not Equal To, Length Less Than, Length Equal To, Length Greater Than, Does Not Exist, Equals to One of Multiple Values, and Not Equal To One of Multiple Values	cna=Z87DHXX/jXIBASQBsYAimToU; sca=234ea940; yunpk=177699790****
Referer	The URL of the source page from which the request is redirected.	Include, Not Include, Equal To, Not Equal To, Length Less Than, Length Equal To, Length Greater Than, Does Not Exist, Equals to One of Multiple Values, and Not Equal To One of Multiple Values	https://example.aliyundoc.com/
Content-Type	The HTTP content type that is specified for the response. The HTTP content type is known as the Multipurpose Internet Mail Extensions (MIME) type.	Include, Not Include, Equal To, Not Equal To, Length Less Than, Length Equal To, Length Greater Than, Equals to One of Multiple Values, and Not Equal To One of Multiple Values	text/plain;charset=UTF-8
X-Forwarded-For	The originating IP address of the client that initiates the request. The originating IP address must be in the `<client>, <proxy1>, <proxy2>` format.	Include, Not Include, Equal To, Not Equal To, Length Less Than, Length Equal To, Length Greater Than, Does Not Exist, Equals to One of Multiple Values, and Not Equal To One of Multiple Values	36.18.XX.XX,192.18.XX.XX
Content-Length	The number of bytes in the request.	Value Less Than, Value Equal To, and Value Greater Than	806
Post-Body	The content of the request.	Include, Not Include, Equal To, Not Equal To, Equals to One of Multiple Values, and Not Equal To One of Multiple Values	Content-Type: application/x-www-form-urlencoded name=John&age=25&email=****
Http-Method	The request method. Valid values: GET, POST, DELETE, PUT, OPTIONS, CONNECT, HEAD, and TRACE.	Equal To, Not Equal To, Equals to One of Multiple Values, and Not Equal To One of Multiple Values	POST
Header	The request header that is used to specify custom HTTP header fields and values.	Include, Not Include, Equal To, Not Equal To, Length Less Than, Length Equal To, Length Greater Than, Does Not Exist, Equals to One of Multiple Values, and Not Equal To One of Multiple Values	text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/***
Params	The parameters in the request URL. The parameters follow the question mark (`?`) in the URL. For example, the URI `example.aliyundoc.com/index.html? action=login` contains a parameter `action=login`.	Include, Not Include, Equal To, Not Equal To, Length Less Than, Length Equal To, Length Greater Than, Equals to One of Multiple Values, and Not Equal To One of Multiple Values	action=login
Raw-URI	The URI that is not encoded and preserves the original sequence of characters. The Raw-URI field can contain special characters and spaces. However, the field must be encoded when the field is used. This ensures that no ambiguity or errors occur during transmission and parsing.	Include, Not Include, Equal To, Not Equal To, Length Less Than, Length Equal To, Length Greater Than, Regular Expression Match, Bytes Contain, Bytes Equal, Equals to One of Multiple Values, and Not Equal To One of Multiple Values	GET /images/logo.png HTTP/1.1
Tls-Fingerprint	The TLS fingerprint of the client that initiates the request. The fingerprint is identified and calculated by the self-developed algorithms of Alibaba Cloud. The fingerprint can be used for request matching and DDoS mitigation. You can use one of the following methods to view the fingerprint of the client: On the Security Overview page, click the Domain Names tab. In the lower part of the page, view the value on the Client Fingerprint tab. On the Log Analysis page, search for the ssl_client_tls_fingerprinting_md5 field. You must activate Simple Log Service before you can use this method. For more information, see Use the log analysis feature.	Equal To and Not Equal To	74dcbf6b790160370bb6b7bea98d5978
HTTP/HTTPS	The protocol type of the request. Valid values: HTTP and HTTPS.	Equal To and Not Equal To	HTTP
HTTP Version	The HTTP version. Valid values: HTTP/1.0, HTTP/1.1, and HTTP/2.	Equal To, Not Equal To, Equals to One of Multiple Values, and Not Equal To One of Multiple Values	HTTP/1.0
HTTP/2 Fingerprint	The HTTP/2 fingerprint that is generated by using the MD5 algorithm based on the original fingerprint of the HTTP/2 client. The HTTP/2 fingerprint is used to analyze and identify different clients for more secure and efficient communication.	Equal To and Not Equal To	ad8424af1cc590e09f7b0c499bf7fcdb

Appendix 2: Configuration examples

Note

The following examples provide configuration suggestions for common scenarios. You can configure the settings based on your business requirements.

Block specific attack requests

In most cases, the root directory of a website does not receive POST requests. If an HTTP flood attack occurs, your website may receive a large number of POST requests that access the root directory. We recommend that you check whether these requests are normal. If the requests are suspicious, you can configure a rule to block the requests based on the following figure.

Block web crawlers

If your website receives a large number of crawler requests within a period of time, an HTTP flood attack may be initiated from bots that simulate crawlers. You can configure rules to block these requests. The following figure shows the sample configuration.

Configure hotlink protection

When a browser accesses a web page, the Referer field is used to notify the server of the page from which the request is linked. You can configure a Referer-based accurate access control rule to block hotlinking from a specific website. For example, if the website https://example.aliyundoc.com uses a large number of pictures from your website, you can configure a rule based on the following figure.

Configure access frequency limits based on User-Agent

For example, if a specific User-Agent accesses any URI starting with /game/all_ more than 30 times within a 10-second period, the requests will be challenged.

Configure logon frequency limits

For example, to prevent credential stuffing on a logon endpoint, you can configure the path of the logon endpoint and block IP addresses that send more than 20 requests to access the path within 60 seconds.

Configure the status code-related settings for frequency control

You can set the quantity or percentage of a given status code returned by the origin server as a trigger condition to improve mitigation effectiveness and reduce adverse impacts on normal workloads. If the number of requests for a statistical object exceeds the threshold within the statistical period and the number of the specified status code returned by the origin server exceeds the specified quantity or percentage, the specified action is triggered.

200

If the origin server has a strong processing capability, it may be able to handle high-frequency requests initiated by attackers. As a result, the origin server returns the status code 200 to both attack requests and normal results. In this case, you can set the Action parameter to handle the IP addresses that initiate excessive requests based on your business requirements. This helps protect the origin server and ensure service availability. The following figure shows the sample configuration.

404

If an attacker initiates a URI scanning attack or continuously requests paths that do not exist on the origin server, the origin server returns the status code 404 to a large number of requests. Based on this status code, you can configure the settings to block the IP address of the attacker. The following figure shows the sample configuration.

403

If an attacker initiates a web attack and a security service such as WAF is deployed behind Anti-DDoS Proxy, you can configure the settings based on the status codes that are returned by the security services. For example, if a web attack occurs, a WAF instance blocks the attack and returns the status code 403. Based on this status code, you can configure the settings on the Anti-DDoS Proxy console to preemptively block the IP address of the attacker. The following figure shows the sample configuration.

429

If an attacker request hits the rate limiting or business verification configurations on the origin server, the origin server returns the status code 429 Too Many Requests or a custom status code. Based on this status code, you can configure the settings to block the IP address of the attacker to reduce loads on the origin server. The following figure shows the sample configuration.

502

If the origin server takes a long time to process requests due to a request surge, the status code 502 is returned. You can configure the settings to block the IP addresses from which requests are frequently sent. This ensures the availability of the origin server. The following figure shows the sample configuration.

555

If the origin server is designed to respond to unexpected requests with a custom status code such as 555, you can configure the settings to handle the unexpected requests that are sent from an IP address. The following figure shows the sample configuration.

Block illegal client fingerprints

An attacker simulates a real client by forging a client fingerprint to attempt to establish a large number of connections or send a large number of HTTP requests, causing your server to stop responding or refuse to provide services. In this case, you can reject the connections by checking and identifying the client fingerprint.

For example, if an attacker uses the same script or tool to launch volumetric HTTP flood attacks, the number or proportion of requests that contain the same fingerprint surges. You can view the top Client Fingerprint on the Domain Names tab of the Security Overview page. Then, you can calculate the percentages of the top client fingerprints that are queried by using the ssl_client_tls_fingerprinting_md5 field on the Log Analysis page. This way, you can analyze requests, identify suspicious fingerprints, and configure mitigation policies at the earliest opportunity.