Enabling the Block Mode for Web Basic Protection

Application Scenarios

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.

Step 1: Configure Web Basic 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 Website Settings 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. Configure basic web protection rules by referring to Table 1.
   Figure 1 Configuring protection rules
   

   Table 1 Basic web protection parameters

   Parameter		Description	Recommended 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. You are advised to retain the default setting and enable General Check.
   	Protection Level	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 minimal effect on normal requests, observe your workloads for a period first. Then, configure a global protection whitelist rule and select the tight level. You are advised to retain the default settings and select Default rule set (medium).	Default rule set (medium)
   	Detection Scope	You can enable or disable checks in basic web protection as needed. The following check items are supported: 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. You can configure the parameters based on your actual service. If there is no special detection requirement, you are advised to retain the default settings. This means you keep these checks disabled.	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. You can configure the parameters based on your actual service. If there is no special detection requirement, you are advised to retain the default settings. This means you keep the check disabled.
   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 you set Protective Action to Block, you can configure known attack source rules. For details, see Configuring a Known Attack Source Rule. Then, WAF will block requests matching the configured IP address, Cookie, or Params for a length of time configured as part of the rule. You are advised to set Protective Action to Block.	Block

Step 2: Handle False Alarms

After Block is enabled, if a normal service request matches a basic web protection rule, the request will be blocked by WAF. As a result, the website access is abnormal. During routine operations, you can analyze attack logs and handle false alarms so that WAF does not block legitimate requests.

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 Security Operations > Events.
5. View the protection details of a specified domain name, instance, and time range. For details, see Querying a Protection Event.
6. In the Events list, locate the target protection event and click Details in the Operation column to check whether the event is a false alarm. If yes, click Handle as False Alarm in the Operation column.
7. In the Handle as False Alarm dialog box, handle the event.

   In the Handle as False Alarm dialog box, check the default information about the protection event. If the information is correct, click OK to add the protection event as a false alarm. WAF will not block the matched request next time it arrives.

   For details about the parameters, see Table 2.

   Table 2 Parameters

   Parameter	Description	Example Value
   Scope	Domain name that the policy is applied to. All domain names: By default, this rule will be applied to all domain names that are protected by the current policy. Specified domain names: The rule will be applied to specified domain names that are protected by the current policy.	Specified domain names
   Domain Name	If Scope is set to Specified domain names, select or enter the domain names for the rule. You can click Add to add more domain names. The domain name format varies depending on the access mode. Cloud CNAME access: Enter a complete domain name. Cloud load balancer access: Enter Domain_name:ELB_load_balancer_ID. If the protected domain name is a single domain name, select or enter Domain_name:ELB_load_balancer_ID. If the domain name is a wildcard domain name, select or enter *:ELB_load_balancer_ID. For example, if you need to add wildcard domain name * and the ELB ID is c8c5fbd9-XXXX-XXXX-XXXX-d6f341a46ee5, enter *:c8c5fbd9-XXXX-XXXX-XXXX-d6f341a46ee5. Dedicated mode: Enter a complete domain name or IP address.	Cloud CNAME access: www.example.com Cloud load balancer access: *:c8c5fbd9-XXXX-XXXX-XXXX-d6f341a46ee5 Dedicated mode: Enter www.example.com or 192.168.2.3.
   Condition List	Request features to be matched by the rule. If a request matches the features, WAF handles the request according to the configured rule. At least one condition is required for the rule to take effect. Click Add Condition in the condition box to add a condition in the group. You can add up to 30 conditions. If multiple conditions are configured, the rule takes effect only when all conditions are met. Click Add Condition outside the condition box to add a condition group. You can add up to three condition groups. The relationship between multiple condition groups is OR. This rule takes effect when one of the condition groups is met. Condition parameter description: Field: For more details, see Condition Field Description. Subfield: Configure this field only when IPv4, IPv6, Params, Cookie, Header or Response Header is selected for Field. A subfield cannot exceed 2,048 characters. If Field is set to Response Header or Header, and Subfield is not All or Any, Case Sensitive is supported. Logic: Select the desired logical relationship from the drop-down list. Content: Enter or select the content that matches the condition. If you set Logic to Include any value, Exclude any value, Equal to any value, Not equal to any value, Prefix is any value, Prefix is not any of them, Suffix is any value, or Suffix is not any of them, you need to select a reference table.	Field is set to Path. Logic is set to Include. Content is set to /product.
   Ignore WAF Protection	Select how you want WAF to whitelist protection. All protection: All WAF rules do not take effect, and WAF allows all request traffic to the domain names in the rule. Basic web protection: You can ignore the entire basic web protection or specific protection type by rule ID or attack type. For example, if you do not want to check a specific URL for XSS attacks, you can configure a false alarm masking rule to mask XSS checks for the URL. ID: Protection modules will be whitelisted based on protection rule IDs. If you select this option, you need to configure Rule ID. Use commas (,) to separate multiple IDs. You can enter a maximum of 100 IDs. After entering a rule ID, press Enter to view the added rule ID, rule description, and risk level. You can also click Handle as False Alarm in the Operation column of the rule ID, and click Handle Now in the displayed dialog box. Then, if you select ID for Ignored Protection Type and click OK, this rule ID will be added to the global protection whitelist. Attack type: Protection modules will be whitelisted based on the attack type. One type contains one or more rule IDs. After selecting this option, you need to specify Rule Type. You can specify multiple rule types. The options are Cross Site Scripting, Webshell, Others, SQL Injection, Scanner & Crawler, Remote File Inclusion, Local File Inclusion, and Command Injection. All built-in rules: All protection rules enabled in Basic Web Protection. Invalid requests: You can allow certain invalid requests. A request is invalid if: The request header contains more than 512 parameters. The URL contains more than 2,048 parameters. The request header contains "Content-Type:application/x-www-form-urlencoded", and the request body contains more than 8,192 parameters.	Ignore WAF Protection: Basic web protection Ignored Protection Type: ID Rule ID: 041046
   Rule Description	A brief description of the rule. This parameter is optional.	SQL injection attacks are not intercepted.
   Ignore Field	If you select Basic web protection for Ignore WAF Protection, you can enable Ignore Field and configure a specific field to ignore attacks against the specified field. You can ignore the fields you do not want WAF to check. If you configure ignored fields, you can leave the condition list blank. WAF can ignore the following fields: Params, Cookie, Header, Body, and Multipart. You can ignore all fields or a specified field. All fields: Params, Cookie, Header, Body, and Multipart. If All is selected, WAF will not block any attack events matching the selected field. Field: Only the Params, Cookie, and Header fields are supported. If Field is selected, you need to enter a subfield. If you select Cookie, the Domain Name box for the rule can be empty.	Params All

   After the preceding configurations are complete, WAF automatically generates a global protection whitelist rule under the protection policy that blocks the protection event. You can view, modify, and delete the added rule. For more details, see Configuring a Global Protection Whitelist Rule to Ignore False Alarms.

Step 3: Analyzing Attack Logs

You can also interconnect WAF with Log Tank Service (LTS) to check WAF access logs and check whether there are any attacks that are not blocked. Then, you can further harden the security based on the request behavior and characteristics. For more details, see Using LTS to Record WAF Logs.

Step 4: Configure an IP Address Blacklist or Whitelist Rule

• If you identify persistent attacks from a specific IP address, you can add it to a blacklist rule and set Protective Action of the rule to Block.
• If an IP address is used for normal services and a large number of false alarms are generated for it, you can add it to a whitelist rule and set Protective Action of the rule to Log only or Allow.

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 Security Operations > Events.
5. In the Event list, locate the target protection event and choose More > Add to Blacklist/Whitelist in the Operation column.
6. In the Add to Blacklist/Whitelist dialog box, add the client IP address to an existing rule or a new rule. For more details about a blacklist/whitelist rule, see Table 3.
   Figure 2 Add to Blacklist/Whitelist
   

   Table 3 Parameter descriptions

   Parameter	Description
   Add to	Existing rule: Add the client IP address to an existing blacklist or whitelist rule used for the protected domain name. New rule: Create a blacklist or whitelist rule for the protected domain name and add the client IP address to the rule.
   Rule Name	If you select Existing rule for Add to, select a rule name from the drop-down list. If you select New rule for Add to, customize a blacklist or whitelist rule.
   IP Address/Range/Group	Add an IP address, IP address range, or address group. This parameter is mandatory only when you select New rule for Add to. IP address/range: Add the client IP address to the blacklist or whitelist. Address group: Add the client IP address to the address group associated with the blacklist or whitelist rule. If you select Address Group, you need to select an existing address group or add a new address group. For details, see Adding a Blacklist or Whitelist IP Address Group.
   Protective Action	Select the protective action for the rule. This parameter is mandatory only when you select New rule for Add to. Block: Select Block if you want to block the IP address or IP address range you configured previously. Allow: Select Allow if you want to allow the IP address or IP address range you configured previously. Log only: Select Log only if you want to observe the traffic from the IP address or IP address range you configured previously.
   Known Attack Source	If you select Block for Protective Action, you can configure a known attack source rule. Then, WAF blocks the requests matching the configured IP, Cookie, or Params for a period configured by the known attack source rule. For details, see Configuring a Known Attack Source Rule.
   Rule Description	Description of the rule.

   After the preceding configurations are complete, WAF blocks or allows client IP addresses based on the blacklist and whitelist rule you configure.