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 the 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 (formerly known as the basic protection rule module).

Important

On November 7, 2024 (UTC+8), the basic 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 basic 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 basic protection rule module.

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 protection rules.

Protection in public cloud scenarios	Protection in hybrid cloud scenarios

Features

Decoding

The core protection rule module supports multiple decoding formats.

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.

Intelligent whitelist engine

To reduce the risks of false positives, WAF performs intelligent learning based on historical service traffic and identifies protection rules that may cause false positives. Then, WAF adds the URLs that are incorrectly blocked to the intelligent whitelist.

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 subscription WAF 3.0 instance and Purchase 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.

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. On the page that appears, find the Core Protection Rule section and click Create Template.

In the Create Template - Core Protection Rule panel, configure the parameters and click OK.

Configure the template.

Parameter

Description

Template Name

Specify a name for the template. The name can contain letters, digits, periods (.), underscores (_), and hyphens (-).

Save as Default Template

Specify whether to set the template as the default template for the protection module. If you turn on Save as Default Template, you do not need to configure settings in the Configure Effective Scope step. A default template is applied to all protected objects and protected object groups to which no custom protection templates are applied. You can specify only one default template for a protection module. You can specify a default template only when you create a template.

Configre the engine.

Parameter	Description
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.
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. For more information, see Configure protection rules for the custom response module to configure custom block pages. 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. For more information, see Enable or disable the Simple Log Service for WAF feature. 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.
Configure Engine
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 of the Core Web Protection page. For more information, see Configure protection rules for the whitelist module to allow specific requests. Note Only pay-as-you-go WAF instances and subscription WAF instances that run the Enterprise or Ultimate edition support this feature.

Configure the effective scope.
Select items to which you want to apply the template on the Protected Objects and Protected Object Group tabs.
You can apply only one protection template of the core protection rule module to a protected object or a protected object group. For more information about how to add protected objects and create protected object groups, see Configure protected objects and protected object groups.

View a protection template

After you create a protection template, you can click the 展开图标 icon to the left of the template name to view the engine information of the template. You can also click Configure Engine in the Actions column to open the Configure Engine panel. In this panel, you can view the action and status information of the protection rules in the template.

Modify a protection template

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.

Edit a protection template

Find the protection template that you want to manage and click Edit in the Actions column. After you modify the settings, click OK.

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: Turn on or turn off the switch. By default, the switch is turned off. If you turn on the switch, the setting takes effect only on the current 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 are 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 protection details of specific protection rules. For more information, see Basic protection rule module. You cannot search for a protection rule of the core protection rule module by rule ID on the Core Web Protection page. For more information about how to view the details of protection rules, see Manage rule libraries.

Important

If a protection rule blocks normal traffic, you can create a protection rule of the whitelist module based on the rule to reduce false positives. For more information, 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.
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.
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 a large number of requests to analyze the responses of the web applications.
Business logic vulnerability	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.
CSRF	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.
EL 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	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 protection rule by calling an API operation, see CreateDefenseRule.