Configure the core protection rule module - Web Application Firewall

After you add web services to Web Application Firewall (WAF) 3.0, you can configure engine settings and manage rule libraries to protect your web services from common web application attacks, such as SQL injection attacks, cross-site scripting (XSS) attacks, code executions, webshell uploads, and command injection attacks. This topic describes how to configure the core protection rule module.

Important

On November 7, 2024 (UTC+8), the core protection rule module was upgraded. For more information, see Upgrade the basic protection rule module in WAF 3.0. This topic describes the new version of the core protection rule module. If you use the old version, you can configure the module by following the instructions provided in Configure protection rules and rule groups for the core protection rule module.

Module function overview

Each protection template of the core protection rule module uses an independent detection engine. Various protection rules are incorporated into different detection modules based on business experience. Different detection modules identify different types of attacks. The following figure shows the relationships among protection templates, detection engines, detection modules, and rules.

Public cloud protection scenario	Hybrid cloud protection scenario

Features

Support for multiple decoding formats

The core protection rule module supports multiple decoding formats, including the following:

The module can parse data in various formats to improve detection accuracy. The data formats include JSON, XML, and Multipart.
The module can identify data that is encoded to bypass WAF. This improves the detection rate of attacks. The encoding formats include Unicode encoding and HTML entity encoding.

Support for intelligent whitelist engine

To reduce the risks of false positives, WAF performs AI learning based on historical service traffic and identifies rules that may not be suitable at the URL level, then automatically adds them to the whitelist.

Support for custom protection rules in hybrid cloud scenarios

Custom protection rules take effect only for protected objects that are generated when you add services to WAF in hybrid cloud mode. This type of protected object is referred to as hybrid cloud protected objects. For more information about how to create a custom protection rule and add the rule to a protection template, see Manage rule libraries.

Prerequisites

A WAF 3.0 instance is purchased. If you want to apply custom protection rules to hybrid cloud protected objects, you must purchase a subscription WAF instance that runs the Enterprise or Ultimate edition. For more information, see Purchase a WAF 3.0 subscription instance and Activate a pay-as-you-go WAF 3.0 instance.
Web services are added to WAF 3.0 as protected objects. For more information, see Configure protected objects and protected object groups.

Template type

The core protection rule module has the following two types of protection templates.

Protection template	Description	Effective objects
Default protection template	The initial default protection template provided by WAF, which contains the core protection rule set of WAF. No configuration is required if there are no specific protection requirements.	When created, it is automatically applied to protected objects/groups that are not associated with custom protection templates. Newly added protected objects will also be automatically added to the default protection template. You can manually adjust this.
Custom protection template	A protection template customized according to business needs. It needs to be manually created and is suitable for scenarios where a single default protection template cannot meet business requirements.	You need to set Apply to. The template only takes effect for protected objects and object groups that are associated with the protection template.

Create a protection template

Log on to the WAF 3.0 console. In the top navigation bar, select the resource group and region of the WAF instance. You can select Chinese Mainland or Outside Chinese Mainland for the region. In the left-side navigation pane, choose Protection Configuration > Core Web Protection, in the Core Protection Rule section, click Create Template.

In the Create Template - Core Protection Rule panel, complete the template configuration by following these steps, and then click OK.

Step 1: Configure Template Information

Parameter

Configuration field

Description

Template Information

Template Name

The name can contain letters, digits, periods (.), underscores (_), and hyphens (-).

Save as Default Template

The default protection template does not require setting effective objects. It is automatically applied to all protected objects and object groups that are not associated with custom protection templates (including those newly added or removed from custom protection templates). You can also manually remove them from the default template. You can specify only one default template for a protection module, and it can only be set when creating a template.

Step 2: Engine Configuration

Parameter	Configuration field	Description
Engine Configuration	Automatic Update Of Detection Engine	By default, the switch is turned on. In this case, rules that are added to or removed from the default rule library of the Alibaba Cloud security team are automatically synchronized to the current detection engine. If the switch is turned on, WAF automatically updates rules. The rules are enabled and uses the Monitor or Block action. If the switch is turned off, WAF still synchronizes rules. The rules are disabled and uses the Monitor action.
	Configure Engine	System Protection Rules: WAF provides four levels of system protection rules based on the built-in detection modules of Alibaba Cloud Security. The rule levels are Super Strict, Strict, Medium, and Loose. By default, rules at the Super Strict and Strict levels are disabled, and rules at the Medium and Loose levels are enabled. Note For more information about the supported detection modules, see Detection module descriptions. You can configure the following parameters of a rule: Action: Specify the action that you want WAF to perform on the requests that match the rule. Block: blocks a request that matches the rule and returns a block page to the client that initiates the request. Note By default, WAF returns a preconfigured block page. You can use the custom response feature to configure a custom block page. Monitor: records a request that matches the rule in a log and does not block the request. You can query the logs of requests that match the rule and analyze the protection performance. For example, you can query logs to check whether normal requests are blocked. Important You can query logs only if the Simple Log Service for WAF feature is enabled. If you select Monitor, you can perform a dry run on the rule to check whether the rule blocks normal requests. If the rule passes the dry run, you can set the Action parameter to Block. Note On the Security Reports page, you can query the details of matched rules in Monitor or Block mode. For more information, see Security reports. Status: Turn on or turn off the switch. If a rule is disabled, WAF does not match requests against the rule.

	Adaptive Engine	Intelligent Whitelist Engine: By default, the switch is turned off. Protection rules of the whitelist module that are automatically created are displayed in the AutoTemplate protection template in the Whitelist section. For more information, see View whitelist. Note Only pay-as-you-go and subscription WAF instances of the Enterprise and Ultimate editions support this feature.

Step 3: Configure Effective Scope
Select the Protected Objects and Protected Object Groups to which you want to apply the template from the added protected objects and object groups.
You can apply only one core protection rule template to a protected object or object group. If you set a default protection template in Step 1, all protected objects and object groups that are not associated with custom protection templates are selected by default. If you do not set a default template, no protected objects or object groups are selected by default. You can manually modify the effective objects.

View protection templates

You can click the 展开图标 icon to the left of the protection template name to view the engine information of the template. You can also click Configure Engine to open the engine configuration page and view the action and status information of the detailed rules.

Edit protection templates

Enable and disable a protection template

After you create a protection template, you can turn on or turn off the switch in the Status column to enable or disable the template.

Modify a protection template

You can click Edit in the Actions column of the target template. After you make the adjustments, click OK to save the changes.

Note

For protection in hybrid cloud scenarios, you can configure the following parameters for a custom protection rule in the Configure Engine panel:

Action: Specify the action that you want WAF to perform on the requests that match the rule. Valid values: Monitor and Block.
Status: By default, the switch is turned off. You can turn on or turn off the switch. If you turn on the switch, the setting takes effect only on the protection template.

Delete a protection template

You can delete a protection template that you no longer require. Before you delete a protection template, make sure that the template is not associated with protected objects. To delete a protection template, find the template and click Delete in the Actions column. In the message that appears, click OK.

Important

After a protection template is deleted, the system automatically applies the default template to the protected objects that were previously associated with the deleted protection template.
If you delete a default template and the template is associated with protected objects, the protected objects are no longer protected by the core protection rule module.

View hit records

On the Core Protection Rule tab of the Security Reports page, you can view the hit records of specific protection rules. For more information, see Security reports. The Core Web Protection page does not support searching for specific core protection rules by rule ID. To query specific rule information, see Manage rule libraries.

Important

If you believe that a rule incorrectly blocks normal service traffic, you can configure a whitelist rule for that specific rule through the Whitelist module. For more information about how to configure whitelist rules, see Configure protection rules for the whitelist module to allow specific requests.

Related descriptions and references

Detection module descriptions

Detection modules can identify and block different types of web attacks based on the protection rules of the modules.

Supported attack types

Attack type	Description
SQL Injection	SQL injection is an attack in which malicious code is inserted into query statements. Then, the statements are executed to perform the desired operations of attackers on databases.
XSS	XSS is an attack in which malicious scripts are embedded into web pages. The scripts are executed when common users browse the web pages.
Code Execution	Code execution is an attack in which malicious code is injected to deceive servers into executing the code.
CRLF Injection	Carriage Return Line Feed (CRLF) injection is an attack in which carriage returns (\r) and line feeds (\n) are inserted into HTTP headers to manipulate HTTP responses or implement HTTP response splitting.
Local File Inclusion (LFI)	Local file inclusion (LFI) is an attack in which URLs are used to dynamically include files. If the allow_url_include option is enabled on a server, the include(), require(), include_once(), and requir_once() functions can be used to enable dynamic file inclusion. If file sources are not properly sanitized, arbitrary file read or arbitrary command execution may occur.
Remote File Inclusion (RFI)	Remote file inclusion (RFI) is an attack in which files on remote servers are included. This can cause remote code execution on local servers.
Webshell	A webshell is a malicious script file. Attackers can upload or inject webshells to remotely control servers.
OS Command Injection	Operating system (OS) command injection is an attack in which malicious OS commands are injected into applications to deceive servers into executing the commands.
Scanning Behavior	Scanning behavior refers to the behavior and characteristics of scanners that automatically scan web applications to detect vulnerabilities, such as SQL injection and XSS. The scanners also generate and send many requests to analyze the responses of the web applications.
Logic Defect	A business logic vulnerability is a flaw in the implementation of an application. Traditional input validation or output encoding are inadequate to defend against this type of vulnerability. Attackers can exploit the business logic vulnerabilities of an application to manipulate the business logic to perform unauthorized access or other malicious behavior.
Arbitrary File Read	Arbitrary file read is a vulnerability that can be exploited to read any file in systems. Attackers can specify fuzzy file paths in HTTP requests to exploit the vulnerability. Then, attackers can access sensitive information, such as configuration files, credentials, and personnel data.
Arbitrary File Download	Arbitrary file download is a vulnerability that is similar to arbitrary file read. Arbitrary file download allows attackers to download any file in systems. This can lead to the disclosure of sensitive information. Attackers even can obtain a full backup of a system for offline analysis.
XXE Injection	XML External Entity (XXE) injection is an attack in which the features of XML are exploited to construct external entities and deceive XML parsers into parsing the entities. Attackers can read system files and launch Server-Side Request Forgery (SSRF) or Denial of Service (DoS) attacks. In most cases, XXE injection involves XML input that references malicious external entities.
Cross-site Request Forgery	Cross-Site Request Forgery (CSRF) is an attack in which authenticated users are deceived into sending unauthorized requests to web applications to perform malicious actions. Attackers may trick users into clicking a malicious link or accessing a malicious web page. Then, the attackers can perform operations such as modifying settings or submitting forms by using the identities of the users.
Expression Injection	Expression language (EL) injection is an attack in which malicious expressions are injected to deceive servers into executing the expressions.
.NET Deserialization	Deserialization is the process of converting data in a specific data format, such as JSON, XML, or binary, back to an object. In .NET applications, unsafe deserialization can lead to arbitrary code execution. If attackers can manipulate deserialized data, they may inject malicious data to execute arbitrary code.
Java Deserialization	Attackers construct serialized objects that contain malicious code to deceive servers into executing malicious code during deserialization.
PHP Deserialization	Attackers construct serialized objects that contain malicious code to deceive servers into executing malicious code during deserialization.
SSRF (server-side request forgery)	SSRF is an attack in which server requests are forged to deceive servers into accessing internal or external resources.
Path Traversal	Path traversal is an attack in which relative paths such as ../ are used to access files that are not intended to be accessible.
Protocol Non-compliance	Protocol non-compliance is an attack in which protocols such as HTTP and HTTPS are maliciously manipulated to bypass security mechanisms.
Arbitrary File Upload	Arbitrary file upload is a vulnerability that can be exploited to upload malicious files to deceive servers into executing the files.

References

For more information about the protected objects, protection modules, and protection process of WAF 3.0, see Protection configuration overview.
For more information about how to create a protection template by calling an API operation, see CreateDefenseTemplate.
For more information about how to create a core protection rule by using OpenAPI, see CreateDefenseRule.