Configuring Custom Precise Protection Rules

Constraints

Prerequisites

• You have connected your website to WAF. For details, seeConnecting Your Website to WAF.
• If you use a dedicated WAF instance, make sure it has been upgraded to the latest version. For details, see Managing Dedicated WAF Engines.

Configuring a Precise Protection Rule

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.
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 Precise Protection configuration area and ensure that Precise Protection is enabled.

   : enabled.

7. On the Precise Protection page, set Detection Mode.
   Two detection modes are available:

   • Instant detection: If a request matches a configured precise protection rule, WAF immediately ends threat detection and blocks the request.
   • Full detection: If a request matches a configured precise protection rule, WAF does not block the request immediately. Instead, WAF continues to detect other possible attacks based on detection sequence of other protection rules (such as scan protection, anti-crawler, and CC attack protection) in the policy. WAF blocks the request after all protection rules in the policy are executed.

8. In the upper left corner above the Precise Protection rule list, click Add Rule.
9. Add a precise protection rule.

   The settings shown in Figure 1 are used as an example. If a visitor tries to access a URL containing /admin, WAF will block the request.

   To ensure that WAF blocks only attack requests, configure Protective Action to Log only first and check whether normal requests are blocked on the Events page. If no normal requests are blocked, configure Protective Action to Block.

   Figure 1 Add Precise Protection Rule
   

   Table 1 Rule parameters

   Parameter	Description	Example Value
   Rule Name	Name of the rule.	waftest
   Description	Description of the rule.	--
   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. If multiple conditions are configured, the rule takes effect only when all conditions are met. Click Add Condition to add a condition. You can add up to 30 conditions. You can add a rate limit condition group. This function is under open beta test (OBT). You can submit a service ticket to enable it. How a condition group takes effect: A condition group takes effect as long as one of the conditions in the group is met. Click Add Condition and add a rate limit condition in the group. How condition groups take effect: AND: The combination of an AND group takes effect when all AND groups are met. You can click Add AND Group to add an AND group. OR: The combination of an OR group takes effect as long as one group is met. You can click Add OR Group to add an OR group. The parameters in Condition List are as follows: Field: data dimension used to detect and match request content. For details, see Condition Field Description. With dedicated mode, if a layer-7 reverse proxy (for example, ELB load balancer) is deployed in front of WAF and the reverse proxy's fingerprints are transferred to WAF with request headers, you need to configure JA3/JA4 fingerprint tags for the protected domain name, or the rule with Condition set to TLS fingerprint (JA3) or TLS fingerprint (JA4) cannot work. SubfieldResponse HeaderField IPv4IPv6ParamsCookieHeader 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. If 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 is selected, select an existing reference table in the Content drop-down list. For details, see Creating a Reference Table to Configure Protection Metrics in Batches. Exclude any value, Not equal to any value, Prefix is not any of them, and Suffix is not any of them indicates, respectively, that WAF takes the protective action (Block, Allow, or Log only) when the field in an access request does not contain, is not equal to, or the prefix or suffix is not any value set in the reference table. For example, assume that Path field is set to Exclude any value and the test reference table is selected. If test1, test2, and test3 are set in the test reference table, WAF performs the protection action when the path of the access request does not contain test1, test2, or test3. Content: Enter or select the content that matches the condition. Case Sensitive: If Field is set to Path, User Agent, Params, Cookie, Referer, Header, Response Header, or Response Body, you can enable case-sensitive matching for conditions. If you enable this, the system matches the case-sensitive content. It helps the system precisely identify requests and respond to them accurately, making protection policies work better.	Path Include /admin User Agent Prefix is not mozilla/5.0 IP Equal to 192.168.2.3 Cookie key1 Prefix is not jsessionid
   Deep Inspection	Assume that you set Field in the condition list to one of the following: Path: Content supports Case-Sensitive. User Agent: Content supports Case-Sensitive. Params: Content supports Case-Sensitive. Cookie: Content supports Case-Sensitive. Cookie: Content supports Case-Sensitive. Header: Subfield supports Case-Sensitive, and Content also supports Case-Sensitive. If you enable Deep Inspection, the Subfield and Content will be decoded and matched conditions in a case-insensitive manner. Deep Inspection supports Base64 decoding.	-
   Protective Action	Protective action for the rule when a request matches the rule. NOTE: Before selecting a protective action, you need to consider the detection priority of the current protection rule to prevent protective actions of high-priority rules from affecting the execution of low-priority rules. Block: Requests that match the rule will be blocked. The default block page for the Block action is Default settings. You can customize the block page. Block Page This parameter is mandatory when Protective Action is set to Block. If a request meets the rule, the configured block page is returned. Default settings (default): The default block page is returned. Custom: You can customize the return code, response header, page type, and page content for the returned page. For more information, see Modifying the Alarm Page. Known Attack Source You can configure a long-term or short-term block rule based on the IP address, cookie, or parameter of a visitor. WAF will then automatically block the visitor if the request hits the rule. For more details, see Configuring a Known Attack Source Rule to Block Specific Visitors for a Specified Duration. Allow: Requests that hit the rule are forwarded to backend servers. Log only: Requests that hit the rule are not blocked but logged. JS Challenge: WAF returns a piece of JavaScript code that can be automatically executed by a normal browser to the client. If the client properly executes the JavaScript code, WAF allows all requests from the client within the validity period of the token. During this period, no verification is required. If the client fails to execute the code, WAF blocks the requests. The default validity period of a token is 30 minutes. You can customize the validity period from 60 to 86,400 seconds. CAUTION: If the initial page automatically loads an Ajax request, you need to configure a precise protection rule and configure the JS challenge action for pages containing Ajax requests, such as the referer page or homepage for the Ajax interface. This step prevents asynchronous interface requests, automatically triggered by JavaScript on the origin server, from executing before the WAF SDK. If the static page does not automatically trigger asynchronous interfaces, this issue does not apply. If the referer in the request is different from the current host, the JS challenge does not work.	Block
   Application Schedule	Time when the rule takes effect. Immediate: The rule works immediately after it is enabled. Custom: You can select a time range for the rule to work.	Immediate
   Priority	Rule priority. If you have added multiple rules, rules are matched by priority. The smaller the value you set, the higher the priority. You can use the priority function to rank all precise protection rules to get the optimal protection. If multiple precise access control rules have the same priority, WAF matches the rules in the sequence of time the rules are added.	5

10. Click OK. You can then view the added precise protection rule in the protection rule list.

    To make the protection rule take effect, ensure that the protection policy that the protection rule belongs to has been applied to a 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 have only one protection policy.

    After completing the preceding configurations, you can:

    • Check the rule status: In the protection rule list, check the rule you added. Rule Status is Enabled by default.
    • Disable the rule: If you do not want the rule to take effect, click Disable in the Operation column of the rule.
    • Delete the rule: To delete a rule you no longer need, click Delete in the Operation column of the rule.
    • Modify or copy the rule: Click More > Modify or More > Copy in the Operation column of the target rule, respectively.
    • Verify the protection effect:
      1. Clear the browser cache and enter http://www.example.com/admin (or any page containing /admin) in the address bar. Normally, WAF blocks the requests that meet the conditions and returns the block page.
      2. On the Events page, check the protection logs.

Configuration Example: Blocking a Certain Type of Attack Requests

The following example shows how to block requests of a certain feature. As shown in Figure 2, the User-Agent field in each request contains WordPress. So we can configure a precise rule to block all reflected attack requests that contain WordPress.

Figure 2 WordPress reflected attacks

You can configure a rule as shown in Figure 3. Then, if the User-Agent field of a request contains WordPress, WAF blocks the request.

Figure 3 User Agent configuration

Configuration Example: Blocking Requests to a Certain URL

If a large number of IP addresses are accessing a URL that does not exist, you can configure precise protection rules to block such requests to reduce resource waste on the origin server. Assume that the path /xxxx does not exist. The following Figure 4 shows a precise rule configured to block all requests where the URL path contains /xxxx.

Figure 4 Blocking requests to a specific URL

Blocking Requests with null Fields

You can configure precise protection rules to block massive requests containing null or empty fields. As shown in Figure 5, the length of referer in the request Header is 0, so WAF identifies that the request does not contain the referer header and blocks the request.

Figure 5 Blocking requests with empty Referer

Blocking Specified File Types (ZIP, TAR, and DOCX)

You can configure precise protection rules to block access to specific file types based on their path suffix. As shown in Figure 6, WAF blocks access to files with the .zip suffix.

Figure 6 Blocking requests of specific file types

Configuration Example: Preventing Hotlinking

You can configure a protection rule based on the Referer field to enable WAF to block hotlinking from a specific website. If you find out that, for example, requests from https://abc.blog.com are stealing images from your site, you can configure a rule to block such requests.

Figure 7 Preventing hotlinking

Configuration Example: Allowing All Requests from Whitelisted IP Addresses

You can configure two precise protection rules, one to block all IP addresses, but then another one to allow a specific IP address. In this way, only whitelisted IP addresses (192.168.2.3 in this example) are allowed to access the website; WAF blocks all requests from other IP addresses.

Figure 8 Blocking all requests

Figure 9 Allowing the access of a specified IP address

Configuration Example: Allowing All Requests from Whitelisted IP Addresses That Carry a Specified URL Feature

Configure the following two conditions:

• One condition specifies a specific URL feature. The URL Path contains /admin, as shown in Figure 10.
• One condition specifies a whitelisted IP address. The whitelisted IP address is 192.168.2.3, as shown in Figure 10.

In this way, only whitelisted IP address 192.168.2.3 is allowed to access the path that contains /admin.

Figure 10 Allowing access from whitelisted IP addresses to a specific path