Web Application Firewall (WAF) provides out-of-the-box security. After you add your assets to WAF, a pre-configured set of core protection rules is automatically applied for instant defense against common web application attacks, such as SQL injection, cross-site scripting (XSS), and command injection, with no extra configuration needed. This topic explains how to manage and fine-tune these rules.
The Core Protection Rule feature is being rolled out. This topic describes the new version. If you are using the old version, see Core protection rules and rule groups. For the upgrade announcement, see [Notice] WAF 3.0 Basic Protection Rule Feature Upgrade. You can identify your version by the appearance of the Core Protection Rule section on the page in the WAF console.
New version |
|
Old version |
|
Key concepts
Core Protection Rule: A protection module within core web protection. This module is enabled through a protection template. After you activate WAF, the system automatically creates a default protection template. You can also manually create multiple protection templates.
Protection template: A protection template is a set of protection rules that defines their content and scope. When you create a protection template, you need to configure its Template Information, Engine Configuration, and Configure Effective Scope.
Template Information: Defines the template type, which cannot be changed after the template is created. There are two types of templates:
Template type
Description
Use cases
Default protection template
The system provides an initial default protection template.
The template is automatically applied to protected objects and object groups that are not associated with a custom protection template. It also applies to newly added objects.
You can manually exclude specific objects by setting their status to "Not applied".
Only one default protection template can exist within the core protection rules module.
When you remove a protected object from a custom protection template, it is automatically added to the default protection template.
Used for deploying general protection rules that apply globally. If your services have no special protection requirements, we recommend using the default protection template. No additional configuration is required.
Custom protection template
You must manually specify the protected objects or object groups to which it applies.
Used for deploying fine-grained protection rules for specific business needs.
Engine Configuration: Defines the protection rules. Based on security best practices, WAF provides multiple System Protection Rules, categorized by Detection Modules, to defend against different types of attacks. You can configure the Action for System Protection Rules. For assets in Custom Protection Rules, you can also configure Custom Protection Rules to meet your business requirements.
Configure Effective Scope: Specifies the targets for the protection template. By configuring the effective scope, you can apply protection rules to specific protected objects or protected object groups. A protected object or object group can be associated with only one protection template.
Protected object: The system automatically creates a protected object for each domain or cloud service instance that you add to WAF.
Protected object group: You can add multiple protected objects to a protected object group for centralized management.
Benefits
Out-of-the-box protection: The default system template includes multiple built-in protection rules. Newly added assets are automatically protected by these rules, meeting routine security needs without additional configuration.
Multiple decoding methods: WAF supports parsing and decoding data formats like JSON, XML, and Form, as well as various encoding methods like Base64 and HTML entities. This ensures the detection of malicious traffic hidden by multiple layers of encoding or compression.
Intelligent whitelist engine: WAF uses AI to learn from your historical traffic, identify protection rules that cause false positives for specific URLs, and automatically add them to a whitelist. This effectively reduces false positives.
Before you begin, ensure you have added your web services to WAF, which creates the required protected objects. If not, see Onboarding overview.
Create a fine-grained protection template
After you add your services to WAF, the system automatically applies the default protection template to all protected objects and enables protection. If your services have no special protection requirements, you do not need to create a protection template. Follow these steps only if you need to configure different rules for different protected objects.
If you only need to handle WAF false positives or false negatives, see Handling false positives and false negatives.
Go to the 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) of your WAF instance. In the left-side navigation pane, choose . In the Core Protection Rule section, click Create Template.
Configure Template Information:
Template Name: Enter a name that is easy to identify.
Save as Default Template: The system provides an initial default protection template, and only one can exist for the core protection rules module. Therefore, if the initial default template exists, you cannot set this to "Yes".
Yes: You do not need to configure the Configure Effective Scope. When created, the template is automatically applied to protected objects and object groups that are not associated with a custom protection template. It also applies to newly added objects. You can manually exclude specific objects by setting their status to "Not applied".
No: You must configure the Configure Effective Scope by manually specifying the protected objects or object groups to which it applies.
Engine Configuration:
Automatic Update of Detection Engine: This feature is enabled by default.
Enabled: Rule updates from the Alibaba Cloud security team are automatically synchronized to your detection engine. WAF automatically applies the new rules. The rule Status is set to "Enabled" or "Disabled", and the rule Action is set to "Monitor" or "Block".
Disabled: Rules are still synchronized, but their Status is set to "Disabled", and the Action is set to "Monitor".
Configure Engine: Click Configure Engine in the upper-right corner, or click Configure in the Actions column for a specific Detection Modules below to configure protection rules. For a list of supported detection modules, see Appendix.
System Protection Rules
System protection rules are based on Alibaba Cloud's built-in detection modules and are available at four strictness levels: Super Strict, Strict, Medium, and Loose. By default, rules at the Medium and Loose levels are enabled, while rules at the Super Strict and Strict levels are disabled.
You can configure the following settings for system protection rules:
Action: Select an action for requests that match the rule.
Block: Blocks matching requests and returns a block page to the client.
Monitor: Allows and logs matching requests. When testing a rule, you can first use Monitor mode and analyze WAF logs to confirm that no false positives are generated.
Status: You can enable or disable the rule. If disabled, the rule is not applied to requests.
NoteYou can view hit details for various protection rules in Security Reports.
Custom Protection Rules (hybrid cloud mode only)
Custom protection rules apply only to protected objects that are added to WAF in hybrid cloud mode. To add custom protection rules and use them in a protection template, see Rule Library Management.
Adaptive Engine: The Intelligent Whitelist Engine feature is disabled by default. When enabled, WAF uses AI to learn from historical traffic, identify rules that cause false positives at the URL level, and automatically create whitelist rules to reduce them.
The automatically created whitelist template is named AutoTemplate. For more information, see Whitelist.
NoteThis feature is available only for Pay-As-You-Go, Subscription Enterprise Edition, and Subscription Ultimate Edition instances.
Configure Configure Effective Scope:
Select the protected objects and protected object groups to which you want to apply this template. The effective scope of the template depends on the configuration in Step 2:
Using the system-created default template or setting it as default: You do not need to set the effective scope. When created, the template automatically applies to protected objects and object groups that are not associated with a custom protection template, as well as newly added objects. You can manually exclude specific objects by setting their status to "Not applied".
Not set as default: You need to manually specify the protected objects and object groups to which the template applies.
NoteYou can manually adjust the effective status of protected objects or object groups both during and after template creation.
Handling false positives and false negatives
When WAF blocks legitimate traffic (a false positive) or fails to block an attack (a false negative), follow these steps to identify the cause and adjust your configuration.
Handling false positives
In the left-side navigation pane, choose .
NoteIf you have enabled Log Service, you can also go to to view complete request logs.
Filter the logs by Time, Protected Objects (the accessed domain/cloud service instance), and Action to locate the specific blocked request.
If you confirm that a legitimate request was blocked, find it in the Logs, and click Suppress False Positive in the Actions column to create a whitelist rule and allow the request.
If you notice that requests share common characteristics (for example, a trusted IP address triggers multiple different protection rules), we recommend adding the IP address as a Match Condition in a single whitelist rule. This is more efficient than whitelisting each blocked log entry individually. For more information, see Whitelist.
Handling false negatives
If an attack is not blocked by WAF, consider the following common causes and recommended solutions:
The request is not processed by WAF
Cause: The SSL certificate or listening port configured in WAF does not match the one on the origin server.
Recommendation: Verify that the SSL certificate and port configurations in WAF and on the origin server are consistent.Cause: For CNAME onboarding, the DNS record was not correctly changed, so traffic is not directed to WAF.
Recommendation: Confirm that the DNS record correctly points to the CNAME address provided by WAF.Cause: For CNAME onboarding, the attacker bypasses WAF by directly accessing the origin server's IP address.
Recommendation: In your server's security group, allow traffic only from WAF's back-to-origin IP addresses.
Cause: For cloud service onboarding, the cloud service instance added to WAF is not the one to which the domain's traffic is actually routed.
Recommendation: Confirm that the correct cloud service instance has been added to WAF.
The request is processed by WAF, but no rule covers it
The default protection template cannot cover all attack types. You may need to enable other protection modules based on the attack characteristics:
For CC attacks (low-to-medium frequency HTTP floods): Use CC Protection or rate-limiting custom rules.
For network-layer DDoS attacks (high-frequency, high-volume): Use Anti-DDoS products.
For automated scripts or bot attacks: Use Bot Management.
For attacks with specific characteristics (such as a fixed User-Agent or URL path): Use custom rules.
For attacks from a fixed source IP address: Use an IP blocklist.
For attacks from non-business regions or countries: Use Region Block.
For attacks targeting APIs: Use API Security.
Routine maintenance
View a protection template: Click the
icon to the left of a template name to view the engine information it contains.Enable or disable a protection template: Use the Status switch to enable or disable a template.
Edit a protection template: Click Edit in the Actions column for a template to modify its Template Information, Engine Configuration, or Apply To.
Delete a protection template: When a template is no longer needed, click Delete in its Actions column, and then click Delete in the confirmation dialog box.
ImportantIf a custom protection template is deleted, any protected object that was associated with it will automatically be added to the default protection template.
If the default protection template is deleted while it still contains protected objects, those objects will no longer be protected by core protection rules.
Supported detection modules
Core protection rules support the following detection modules, which can identify and block various types of attacks against web applications.
Attack type | Description |
SQL Injection | An SQL injection attack involves injecting malicious SQL code into a query to execute unintended database commands. |
XSS | A cross-site scripting (XSS) attack involves embedding malicious scripts into a web page, causing them to be executed when other users view the page. |
Code Execution | Code execution attacks use injected malicious code that is executed by the server to achieve the attacker's objectives. |
CRLF Injection | A CRLF injection attack involves inserting a carriage return (CR, \r) and a line feed (LF, \n) into an HTTP header to manipulate HTTP responses or perform HTTP response splitting. |
Local File Inclusion | If the allow_url_include option is enabled on a server, an attacker can exploit PHP functions like include(), require(), include_once(), and require_once() to dynamically include files via a URL. If the file source is not strictly validated, this can lead to arbitrary file reads or command execution. |
Remote File Inclusion | A Remote File Inclusion (RFI) attack includes a file from a remote server, allowing an attacker to execute malicious code on the local server. |
Webshell | A webshell is a malicious script file that, when uploaded or injected, allows an attacker to remotely control the server. |
OS Command Injection | An OS command injection attack involves embedding malicious operating system commands into a program, causing the server to execute them. |
Scanning Behavior | This refers to the behavior and characteristics of web application scanners. These tools automatically scan web applications to find potential security vulnerabilities, such as SQL injection and XSS, by generating and sending a large number of requests to analyze the application's responses. |
Logic Defect | Business logic flaws are vulnerabilities in an application's implementation of its business processes. These flaws are often not preventable by traditional input validation and output encoding. They may allow an attacker to manipulate the application's normal workflow to gain unauthorized access or perform other malicious actions. |
Arbitrary File Read | An arbitrary file read vulnerability allows an attacker to read any file on the system, typically through a file path parameter in an HTTP request. By exploiting this vulnerability, an attacker can access sensitive information like configuration files, credentials, and personal data. |
Arbitrary File Download | An arbitrary file download vulnerability is similar to an arbitrary file read but allows an attacker to download any file from the system. This can lead to sensitive information leakage and may even allow an attacker to obtain a full system backup for offline analysis. |
XXE Injection | An XXE vulnerability exploits the way XML parsers process external entities, allowing an attacker to read system files, execute server-side requests (SSRF), or cause a denial-of-service (DoS). This attack is typically achieved through XML input that contains a malicious external entity. |
Cross-site Request Forgery | A CSRF attack tricks an authenticated user into sending an unauthorized request to a web application. Typically, the attacker entices the user to click a malicious link or visit a malicious page, which then executes an action in the user's name, such as changing a setting or submitting a form. |
Expression Injection | An expression injection attack involves embedding a malicious expression that is executed by the server. |
.NET Deserialization | Deserialization is the process of converting data from a format (such as JSON, XML, or binary) back into an object. In .NET applications, insecure deserialization can lead to arbitrary code execution. If an attacker can control the deserialized data, they may be able to inject malicious data and execute arbitrary code. |
Java Deserialization | A Java deserialization attack involves deserializing a malicious object, causing the server to execute malicious code in the process. |
PHP Deserialization | A PHP deserialization attack involves deserializing a malicious object, causing the server to execute malicious code in the process. |
SSRF | A Server-Side Request Forgery (SSRF) attack forges a server-side request, causing the server to access internal or external resources. |
Path Traversal | A path traversal attack involves injecting relative path sequences (such as ../) to access files on the server that should not be publicly accessible. |
Protocol Non-compliance | Protocol violation refers to maliciously manipulating protocols (such as HTTP or HTTPS) to launch an attack or bypass security mechanisms. |
Arbitrary File Upload | An arbitrary file upload attack involves uploading a malicious file that is then executed by the server. |