Configure HTTP flood protection - Web Application Firewall

HTTP flood protection in Web Application Firewall (WAF) defends against application-layer HTTP flood (CC) attacks. You can choose a built-in protection mode for routine defense or emergency response to ensure service continuity.

Key concepts

HTTP flood protection: A module within Core Web Protection. To enable this feature, create one or more protection templates.

Protection template: Defines protection rules and their scope. A template consists of Template Information, Rule Configuration, and Apply To.

Template Information: Defines the template type. The type cannot be changed after the template is created. WAF supports the following two template types:

Template type	Description	Use cases
Default protection template	An initial default protection template is provided for WAF Pro Edition, WAF Enterprise Edition, and WAF Ultimate Edition subscriptions. When created, the template automatically applies to protected objects and object groups that are not associated with a custom protection template. Newly added objects are also automatically protected. You can manually exclude specific objects by setting their status to Not Applied. You can create only one default protection template for the HTTP flood protection module. When a protected object is removed from a custom template, it is automatically added back to the default template.	Deploy general protection rules that need to be applied globally.
Custom protection template	You must manually specify the protected objects or object groups to which the template applies. When you add a protected object to a custom template, the object is automatically removed from the default template.	Deploy fine-grained protection rules for specific services.

Rule Configuration: Built-in detection rules based on an attack signature database. Select a Protection Mode and a response Action; no custom rule writing is required.
Apply To: The protected objects or object groups to which the protection rules apply. Each protected object or object group can be associated with only one protection template.
- Protected object: Automatically created when you add a domain name or cloud service instance to WAF.
- Object group: Add multiple protected objects to an object group for centralized management.

Procedure

Note

Prerequisites: Before you begin, make sure that you have added your web service to WAF to create a protected object. If you have not added your web service, see Add a service.
Initial configuration: These steps explain how to create a new HTTP flood protection template, which is useful if no templates exist or if you need separate configurations for different objects. For WAF Pro Edition, WAF Enterprise Edition, and WAF Ultimate Edition subscriptions, the system provides a default protection template that meets routine protection needs. If the default protection is ineffective, see Handle false positives and false negatives.

Navigate to the WAF console:
Log on to the Web Application Firewall 3.0 console. In the top navigation bar, select the resource group and region (Chinese Mainland or Outside Chinese Mainland) for your WAF instance. Then, in the left-side navigation pane, choose Protection Config > Core Web Protection and click Create Template in the HTTP Flood Protection section.
Configure Template Information:
- Template Name: Enter a descriptive name for the template.
- Save as Default Template: The system provides an initial default protection template for WAF Pro Edition, WAF Enterprise Edition, and WAF Ultimate Edition subscriptions. You can create only one default protection template for the HTTP flood protection module. If the initial default template exists, you cannot set this parameter to Yes.
  - Yes: You do not need to specify Apply To. When the template is created, it automatically applies to protected objects and object groups that are not associated with a custom protection template. Newly added objects are also automatically protected. Manually exclude specific objects by setting their status to Not Applied.
  - No: Manually specify the Apply To or object groups to which the template applies.
Rule Configuration:
- Protection Mode: Select Standard Mode or Strict Mode. Each mode contains multiple built-in protection rules.
  - Standard Mode: Blocks only requests with obvious attack signatures. This mode has a low false positive rate and is suitable for routine operations and stable traffic scenarios.
  - Strict Mode: Uses high-intensity detection algorithms to block HTTP flood attacks, but has a higher false positive rate. Enable this mode only when Normal mode is ineffective and you observe service degradation such as response delays or high CPU or memory usage.
    Note
    Strict Mode is suitable only for web pages, including HTML5 pages. Do not use it for APIs or native apps to avoid a large number of false positives. For API or native app scenarios, use a custom rule protection template.
- Action: The action to take on requests that match a protection rule.
  - JavaScript Validation: Sends a JavaScript validation challenge to the client. Suitable for general protection scenarios.
  - Monitor: Logs the event without blocking the request. Suitable for policy validation, service testing, or trial runs.
Select Apply To:
Select the protected objects and object groups for this template. The protected objects of the template depend on the configuration in Step 2:
- If you use the system-created default protection template or set the new template as the default: You do not need to select protected objects. The template automatically applies to all protected objects and object groups that are not associated with a custom template, including newly added ones. Manually exclude specific objects by setting their status to Not Applied.
- If the template is not set as the default: Manually select the protected objects and object groups to which the template applies.
  Note
  Adjust the application status of protected objects or object groups during or after template creation.

Handle false positives and false negatives

If the protection template fails to block HTTP flood attacks or incorrectly blocks legitimate traffic, use the following steps to diagnose and resolve the issue.

In Standard Mode, attack not blocked

If WAF fails to block attack requests, check the following common causes and solutions.

Requests are not processed by WAF
- Cause: The SSL certificate or listener port configured in WAF does not match the origin server's configuration.
- Cause: In CNAME record mode, the DNS record was not correctly modified to direct traffic to WAF.
- Cause: In CNAME record mode, attackers bypass WAF by directly accessing the IP address of the origin server.
  Recommendation: Configure the security group of your origin server to allow traffic only from the back-to-origin CIDR blocks of WAF.
- Cause: When a cloud service is added, the instance added for WAF protection is not the one to which the domain name actually resolves.
  Recommendation: Ensure the correct cloud service instance is added to WAF.
Requests are processed by WAF but are not matched by rules
If the Standard Mode HTTP flood protection template is still ineffective, take the following actions:
- Enable Strict Mode: This mode is suitable for emergency service recovery from an HTTP flood attack and applies only to web and HTML5 services. To avoid a large number of false positives, add legitimate users to a whitelist based on clustering analysis.
- Use the custom rule module: WAF lets you create protection policies based on fields such as the client IP address, URI, User-Agent, and region for precise defense against specific attack signatures. However, this requires analyzing access logs to identify attack patterns.
- Use Anti-DDoS Proxy: High-volume HTTP flood attacks may generate peak traffic that exceeds the blackhole threshold of Anti-DDoS Basic. If this occurs, WAF traffic is blackholed and becomes inaccessible. In this case, use Anti-DDoS Proxy. For more information, see Configure HTTP flood protection.

In Strict Mode, normal services are mistakenly blocked

If the HTTP flood protection template in Strict Mode causes excessive false positives, take the following measures:

Whitelist normal traffic: Add legitimate users to the whitelist based on clustering features.
Switch to Standard Mode and use the custom rule protection module: WAF lets you set protection policies based on fields such as client IP, access URI, User-Agent, and region to precisely defend against specific attack patterns. However, you must first analyze access logs to identify these patterns.
Use Anti-DDoS Pro: During high-frequency HTTP flood attacks, peak traffic may exceed the blackhole threshold of Anti-DDoS Origin. If this threshold is exceeded, traffic to WAF is blackholed and your service becomes inaccessible. In this case, use Anti-DDoS Pro for protection. For more information, see Configure HTTP flood attack protection.

Routine maintenance

New HTTP flood protection templates are enabled by default. You can perform the following actions in the protection template list:

View a protection template: Click the icon to the left of the protection template name to view the rules that the template contains.
Enable or disable a protection template: Use the Status to enable or disable the template.
Edit a protection template: In the Actions column for the protection template, click Edit to modify settings such as Template Information, Rule Configuration, and Apply To.
Delete a protection template: When you no longer need a template, click Delete in the Actions column for the template. In the dialog box that appears, click Delete to complete the action.
Important
- If the custom protection template for a protected object is deleted, the protected object is automatically added to the default protection template.
- If the default protection template is deleted while it contains protected objects, those protected objects are no longer protected by HTTP flood protection rules.

FAQ

Why is my server or database experiencing high CPU usage, increased load, and slow response times?

This can happen during a low-frequency CC attack. This type of attack simulates real user behavior by persistently accessing resource-intensive interfaces, such as logon, search, and order placement, at a low request frequency. This activity increases the server CPU load, exhausts the database connection pool, and leads to slower response times.

Common symptoms include:

An abnormal increase in service traffic or Queries per Second (QPS) over a short period.
The percentage of requests for a specific URI is significantly higher than normal.
An abnormal distribution of source IP addresses, such as a large number from outside China, from proxy IP pools, or from multiple new IP segments in a short period.
The percentage of traffic from an individual IP address suddenly increases.

Mitigation measures:

Option 1: Mitigation without WAF
Upgrade cloud resources, such as ECS instance specifications and bandwidth, to handle the attack traffic. Alternatively, identify the abnormal source IP addresses and add them to an ECS security group or the system firewall blacklist. However, because attack source IP addresses are often dynamic, manually maintaining a blacklist is inefficient.
Option 2: Connect to WAF (Recommended)
Connect your assets to WAF and configure the CC protection rules described in this topic for one-click protection. If the attack traffic has fixed features, you can also use rate limiting Custom rules or Region blocking rules for precise blocking. Although the source IP addresses of attacks are often dynamic, the URI, User-Agent, or source region of malicious requests may be fixed.

What are the differences among WAF Bot Management, Custom Rules, and HTTP Flood Protection?

The WAF HTTP Flood Protection, Custom Rules, and Bot Management modules help mitigate HTTP flood attacks in the following ways:

HTTP Flood Protection: Automatically detects attack traffic and uses CAPTCHA verification based on built-in algorithms. You can enable this feature with a single click for easy configuration. However, it does not support fine-grained custom settings.
Custom Rules: Allows you to define match conditions, protection types, and actions. Its rate limiting rules can precisely mitigate HTTP flood attacks. However, you must be familiar with your normal request baseline and other business context.
Bot Management: Focuses on detecting and managing traffic from automated programs (bots). It uses methods such as CAPTCHA verification to distinguish real users from malicious scripts.

What is the difference between ALB rate limiting and WAF for mitigating HTTP flood attacks?

ALB rate limiting: Controls traffic based only on request frequency thresholds, such as global queries per second (QPS) or source IP QPS. It cannot validate request content and may block legitimate traffic bursts. When triggered, it returns a 503 status code by default and does not support other actions, such as CAPTCHA verification.
WAF: Supports detection across multiple dimensions, such as the URI of the request, parameters, header fields, access behavior, and bot features. This enables fine-grained protection for specific URLs and interfaces, or against abnormal behavior patterns.

Does WAF block high-frequency access requests by default?

WAF does not block high-frequency access requests by default. To block these requests, you must configure rate limiting Custom rules.

Does configuring multiple mitigation rules or templates in WAF affect the cost?

Whether the number of WAF mitigation rules or templates affects your cost depends on the billing method of your instance:

Subscription: No extra fees are charged. You can add configurations up to the template and rule limits without incurring additional costs.
Pay-as-you-go: Extra fees apply. The cost is directly related to the number of rules you configure. Configuring more rules results in a higher cost.