Configuring Basic Web Protection to Defend Against Common Web Attacks

Suggestions

• If you are not clear about your service traffic characteristics, you are advised to switch to the Log only mode first and observe the WAF protection for a period of time. Generally, you need to observe service running for one to two weeks, and then analyze the attack logs.
  • If no record of blocking legitimate requests is found, switch to the Block mode.
  • If legitimate requests are blocked, adjust the protection level or configure global protection whitelist rules to prevent legitimate requests from being blocked.
• If you change the protection level to Default rule set (strict), false positives may occur, affecting normal services. Before making such a change, complete the following operations:
  • Change Protective Action to Log only first. Then, change the protection level to Default rule set (strict) and check whether false positives occur. If there are false positives, handle them and then change Protective Action to Block.
  • If you have concerns about changing Protective Action to Log only in Solution 1, you can directly change the protection level to Default rule set (strict). However, you still need to observe the protection events and handle false positives in a timely manner to prevent impact on normal services.
  • If you use the enterprise edition for cloud mode or WI-500 dedicated instances, you can also create a custom rule set and set Protective Action of Default rule set [Tight] to Log only. After that, check whether there are false positives. If yes, handle them promptly. After confirming that no problem exists, change Protective Action to Block.
• Note the following points in your operations:
  • Do not transfer the original SQL statement or JavaScript code in a legitimate HTTP request.
  • Do not use special keywords (such as UPDATE and SET) in a legitimate URL. For example, https://www.example.com/abc/update/mod.php?set=1.
  • Use Object Storage Service (OBS) or other secure methods to upload files that exceed 50 MB rather than via a web browser.

Constraints

Prerequisites

• You have connected your website to WAF. For details, seeAccess Management.
• If you use a dedicated WAF instance, make sure it has been upgraded to the latest version. For details, see Upgrading the Version of a Dedicated WAF Instance.

Enabling Basic Web Protection Rules

1. Log in to the WAF console.
2. Click in the upper left corner and select a region or project.
3. (Optional) If you have enabled the enterprise project function, in the upper part of the navigation pane on the left, select your enterprise project from the Filter by enterprise project drop-down list. Then, WAF will display the related security data in the enterprise project on the page.
4. In the navigation pane on the left, choose Policies > WAF Core Protection.
5. In the policy list, click the name of the target policy to go to the protection rule configuration page.

   You can also go to the Assets > Protected Objects page, locate the target domain name, and click the number next to the protection policy in the Policy column to go to the protection rule configuration page.

6. Click the Basic Web Protection configuration box and ensure that the basic web protection rules are enabled.

   : enabled.

7. Configuring Basic Web Protection

   Table 1 Basic web protection parameters

   Parameter		Description	Example Value
   General Check	Function switch	General Check is enabled by default. WAF defends against attacks such as SQL injections, XSS, file inclusions, Bash vulnerabilities, remote command execution, directory traversal, sensitive file access, and command/code injections. SQL injection attacks are mainly detected based on semantics.
   	Select Rule Set	You can select the protection level of basic web protection based on your service requirements. The options are as follows: Default rule set (loose): Only requests with obvious attack characteristics are blocked. If a large number of false alarms are reported, the loose one is recommended. Default rule set (medium) (default): meets web protection requirements in most scenarios. If basic web protection is enabled, the protection level is medium by default. Default rule set (strict): At this level, WAF provides the finest granular protection and can block attacks with complex bypass features, such as Jolokia cyber attacks, common gateway interface (CGI) vulnerability detection, and Druid SQL injection attacks. To let WAF defend against more attacks but have minimum impact on normal requests, observe your workloads for a period of time first. Then, configure a global protection whitelist rule and select the tight level. You can click View Rule Set Details to view the details of all rules in the rule sets at the three protection levels. Table 2 describes the protection rules. You can set Start Date and End Date to search for the protection rules released within a specified period. You can select filter CVE ID, Rule ID, or Rule Description and enter a keyword to search for a specific protection rule. You can click next to CVE ID, Risk Severity, Application Type, or Protection Type to filter specified rules.	Default rule set (medium)
   	Check scope	You can enable or disable a specific check in basic web protection. The options are as follows: Deep Inspection (disabled by default): If you enable this, WAF identifies and blocks evasion attacks, such as the ones that use homomorphic character obfuscation, command injection with deformed wildcard characters, UTF-7, data URI scheme, and other techniques. Header Inspection (disabled by default): If you enable this, WAF checks all header fields in received requests. Shiro Decryption Check (disabled by default): If you enable this, WAF uses AES and Base64 to decrypt the rememberMe field in cookies and checks whether this field is attacked, with hundreds of known leaked keys included and checked for. NOTE: If your website uses Shiro 1.2.4 or earlier, or your website uses Shiro 1.2.5 or later but AES keys are not configured, it is strongly recommended that you enable Shiro decryption detection to prevent attackers from using leaked keys to construct attacks.	Deep Inspection: Header Inspection: Shiro Decryption Check:
   Webshell Detection		You can enable or disable webshell detection. If you enable it, WAF can protect web applications from web shells that are implanted through upload APIs. HTTP/2 packets do not support web shell detection.
   Protective Action		You can select the action taken by WAF if a web basic protection rule is triggered. Log only (default): WAF logs the request that triggers the rule but does not block it. Block: WAF logs and blocks the request that triggers the rule. Before changing the protective action to block, view the historical logs and confirm that no normal requests trigger the protection rule. If the protective action is set to Block, you can configure a known attack source. Then, WAF will block requests matching the configured IP address, Cookie, Header, or Params for a length of time configured as part of the rule.	Log only

   Table 2 Protection rule description

   Parameter	Description
   Rule ID	The protection rule ID, which is generated automatically.
   Rule Description	Details of attacks the protection rule is configured for.
   CVE ID	Common Vulnerabilities & Exposures (CVE) ID, which corresponds to the protection rule. For non-CVE vulnerabilities, a double dash (--) is displayed.
   Risk Severity	Risk severity of a vulnerability. The value can be High, Medium, or Low.
   Application Type	The application type the protection rule is used for. For details about applications types WAF can protect, see Application Types WAF Can Protect.
   Protection Type	The type of the protection rule. WAF can discover SQL injection, command injection, XSS attacks, XML external entity (XXE) injection, Expression Language (EL) Injection, SSRF, local file inclusion, remote file inclusion, website Trojans, malicious crawlers, session fixation attacks, deserialization vulnerabilities, remote command execution, information leakage, DoS attacks, source code/data leakage.

   To make the protection rule take effect, ensure that the protection policy to which the protection rule belongs has been applied to the target domain name. For details, see Adding a Domain Name to a Policy. A protection policy can be applied to multiple protected domain names, but a protected domain name can be added to only one protection policy.

   After the preceding configurations are complete, you can simulate SQL injection attacks to verify the protection effect. For details, see Configuration Example - Blocking SQL Injection Attacks in 4.

Configuration Example - Blocking SQL Injection Attacks

The following example shows how to configure WAF rules to protect domain name www.example.com from SQL injection attacks.

1. Click the Basic Web Protection configuration box and ensure that the basic web protection rules are enabled.

   : enabled.

2. Enable General Check in Basic Web Protection and set the protection mode to Block.
3. Add WAF-engine-IP-address www.example.com to the hosts file on the local host to configure the mapping.
4. Clear the browser cache and enter a simulated SQL injection (for example, http://www.example.com?id=' or 1=1) in the address box.

   WAF blocks the access request. Figure 1 shows an example block page.

   Figure 1 Block page
   

5. Go to the WAF console. In the navigation pane on the left, choose Events. View the event on the Events page.