Anti-DDoS:Configure HTTP flood protection

Background

An HTTP flood attack (also known as a Challenge Collapsar, or CC, attack) is a type of distributed denial-of-service (DDoS) attack that operates at the application layer. Attackers use multiple controlled hosts to continuously send forged HTTP or HTTPS requests to a target server — for example, repeatedly requesting resource-intensive pages such as search or login. This exhausts server resources or network bandwidth, causing the website to respond slowly or become unavailable.

Unlike traditional network-layer DDoS attacks, HTTP flood attacks are harder to detect because they mimic legitimate user behavior. Alibaba Cloud provides two complementary products to defend against them:

• Anti-DDoS Pro and Anti-DDoS Premium: Deployed at the network edge to protect against volumetric attacks. Recommended when the attack volume is high enough to make your website inaccessible.

• Web Application Firewall (WAF): Deployed close to the server to analyze application-layer traffic and protect against malicious patterns. Recommended when the attack volume is lower — for example, when your website is only responding slowly.

For the best protection, deploy both products together.

How it works

HTTP flood mitigation provides two rule types, determined by whether Rate Limiting is enabled:

• Accurate access control rules (Rate Limiting off): trigger immediately when a request matches all conditions. Use these to block or allow traffic based on fixed characteristics such as specific IP addresses, User-Agent strings, or Referer values.

• Frequency control rules (Rate Limiting on): trigger only when a statistical object (for example, a source IP) exceeds a request frequency threshold within a defined period. Use these to block high-frequency request patterns that individually appear legitimate.

The engine evaluates accurate access control rules first, then frequency control rules. Once a request matches a rule, evaluation stops — no subsequent rules are checked.

Intelligent protection automatically generates accurate access control rules prefixed with smartcc_. These rules follow the same matching logic and are deleted automatically when they expire. No manual action is needed.

When to use HTTP flood mitigation

Configure these rules only when your website is under an HTTP flood attack. This feature is not a substitute for daily protection — use it to strengthen defenses by allowing or filtering traffic with specific characteristics.

Before creating rules, identify the attack characteristics. Look for patterns such as repeated source IP addresses or a specific URI pattern:

• Attack Analysis page: view Web Resource Exhaustion events including source IP, User-Agent, Referer, HTTP method, and client fingerprint.

• Log Analysis page: search fields such as real_client_ip, http_user_agent, http_referer, and request_method. For field descriptions, see Full log fields.

Cookie insertion

For Layer 7 services, Anti-DDoS Pro and Anti-DDoS Premium insert cookies in two scenarios:

Scenario 1 — HTTP flood protection is enabled in the Protection for Website Services policy: a cookie is inserted to differentiate and count clients. The service uses the statistical results to determine whether HTTP flood attack traffic is present and activates the scrubbing policy.

Scenario 2 — The rule action is set to JavaScript Challenge: a cookie captures the client browser fingerprint (host field, browser height and width). When a request hits the rule, the service initiates a challenge probe and uses browser fingerprint statistics to identify abnormal clients.

To disable cookie insertion, go to Provisioning > Website Config, click Edit, and turn off the Cookie Settings switch. Disabling this setting also disables active HTTP flood attack detection and protection.

Prerequisites

Before you begin, ensure that you have:

• A website service added to Anti-DDoS Proxy. See Add websites.

Create an HTTP flood mitigation rule

1. Log on to the Anti-DDoS Proxy console.Anti-DDoS Proxy console

2. In the top navigation bar, select the region of your instance:

   • Anti-DDoS Proxy (Chinese Mainland): select Chinese Mainland.

   • Anti-DDoS Proxy (Outside Chinese Mainland): select Outside Chinese Mainland.

3. In the left-side navigation pane, choose Mitigation Settings > General Policies.

4. On the General Policies page, click the Protection for Website Services tab and select the domain name to configure from the list on the left.

5. In the HTTP Flood Mitigation section, click Settings, then click Create Rule in the upper-right corner.

6. Configure the rule parameters: Action reference:

   When Rate Limiting is on, Allow is not available.

   Parameter	Description
   Rule name	A name for the rule. Supports letters, digits, and underscores (_). Maximum 128 characters.
   Match conditions	Up to five conditions. A request matches only if it meets all conditions. Field value cannot be blank. Matching for accurate access control rules is case-sensitive; matching for frequency control rules is not. For supported fields, see Supported HTTP request fields.
   Rate Limiting	Off: creates an accurate access control rule. On: creates a frequency control rule. When on, also configure Statistical Object (supports IP, Custom Header, Session, Custom Cookie, Custom Request Parameter), Statistical Period (s), and Threshold (times). Optionally, add conditions based on response code count or proportion.
   Action	The action to execute when the rule is triggered. See the action reference table below.
   Validity Period	For accurate access control rules: permanent or a custom duration from 5 to 120 minutes (the rule is deleted when it expires). For frequency control rules: the duration the action is enforced after the rule is triggered, from 1 to 1440 minutes.
   Advanced Settings	Available when Rate Limiting is on. Configures deduplication for the statistical object (IP, Header, or URI). See Deduplication below.

   Action	Behavior	When to use
   Allow	Permits the request.	Whitelist known-good traffic to prevent it from being blocked by other rules.
   Block	Drops the request.	Use when the attack characteristics are clear and you are confident no legitimate traffic matches.
   JavaScript Challenge	Validates the source IP using a challenge algorithm.	Use when you cannot rule out legitimate traffic — challenges real browsers while blocking most bots.
   Monitor	Logs the request and allows it.	Use first to validate a new rule without affecting live traffic. Switch to Block or JavaScript Challenge after confirming no false positives.

7. Click OK.

8. Return to the HTTP Flood Protection section and turn on the Status switch to activate the rules.

Deduplication

When Rate Limiting is on, the Advanced Settings section lets you enable deduplication for the statistical object.

Deduplication on: counts unique values of the deduplication object. For example, if the statistical object is IP and the deduplication object is URI, a source IP that accesses 200 different URIs in 30 seconds triggers the rule — but 10 requests to the same URI count as one.

Deduplication off: counts total requests. For example, if the same source IP makes 200 or more requests in 30 seconds, the rule triggers — including repeated requests to the same URI.

Configuration examples

The following examples are based on common attack scenarios. Adjust the specific values to match your actual traffic patterns.

Block POST requests to the root directory

Legitimate traffic rarely includes POST requests to the root directory (/). If your website is under attack and you observe many such requests:

Field	Logic operator	Field value
Http-Method	is	POST
URI	is	/

Action: Block | Rate Limiting: off (accurate access control rule)

Block web crawlers

If you observe high-volume crawler traffic that may include attack bots impersonating legitimate crawlers:

Field	Logic operator	Field value
User-Agent	contains	<crawler-user-agent-string>

Action: Block | Rate Limiting: off (accurate access control rule)

Hotlink protection

When a browser requests a page, it includes a Referer field identifying the referring page. To block hotlinking from a specific domain (for example, https://example.aliyundoc.com):

Field	Logic operator	Field value
Referer	contains	https://example.aliyundoc.com

Action: Block | Rate Limiting: off (accurate access control rule)

Rate limit by User-Agent

To challenge a specific User-Agent that accesses URIs with the prefix /game/all_ more than 30 times in 10 seconds:

Field	Logic operator	Field value
User-Agent	is	<target-user-agent-string>
URI	prefix matches	/game/all_

Rate Limiting: on | Statistical object: IP | Statistical period: 10 s | Threshold: 30 | Action: JavaScript Challenge

Protect the login interface

To block dictionary attacks on your login interface — for example, more than 20 requests to /login in 60 seconds from the same IP:

Field	Logic operator	Field value
URI	is	/login

Rate Limiting: on | Statistical object: IP | Statistical period: 60 s | Threshold: 20 | Action: Block

Rate limit based on origin server response codes

Adding response code conditions to frequency control rules reduces false positives by triggering actions only when both the request frequency and the response code pattern are exceeded.

200

200 — origin server responds normally under high load

When the origin server has strong processing capacity and still returns 200 for attacker requests, rate-limit IPs that exceed normal request frequency:

404

404 — URI scanning attack

When attackers repeatedly request non-existent paths, the origin responds with 404. Add the attacking IP to a blacklist:

403

403 — upstream WAF blocks web attacks

When Anti-DDoS Pro or Anti-DDoS Premium is deployed in front of WAF, WAF responds with 403 for blocked web attacks. Use this response code to proactively add attacking IPs to a blacklist:

429

429 — origin rate-limiting is triggered

When the origin server returns 429 (Too Many Requests) for requests that exceed its own rate limits, add the attacking IP to a blacklist to reduce pressure on the origin:

502

502 — origin overload

When a sudden request surge causes the origin to respond slowly and return 502, add high-frequency request IPs to a blacklist to protect origin availability:

555

Custom status codes (example: 555)

When the origin uses a custom status code for unexpected requests, use that code to identify and manage the IPs sending those requests:

Block by client fingerprint

Attackers using the same script or tool produce requests with identical TLS, JA3, JA4, or HTTP/2.0 fingerprints. During a volumetric HTTP flood attack, the proportion of requests sharing a fingerprint value spikes suddenly.

To identify suspicious fingerprints:

1. On the Security Overview page, click the Domain Names tab and view the Client TLS Fingerprint top data.

2. On the Log Analysis page, check the proportion of top values for the ssl_client_tls_fingerprinting_md5 field.

Once you identify a suspicious fingerprint value, create an accurate access control rule:

Field	Logic operator	Field value
Tls-Fingerprint	Equal to	<fingerprint-value>

Action: Block | Rate Limiting: off (accurate access control rule)

Appendix 1: Supported HTTP request fields

Next steps

• Configure intelligent protection

• Attack analysis

• Quick start with full log analysis