Configuring Custom Precise Protection Rules

Prerequisites

• You have connected a website to WAF.
• You have created a policy and added the domain name to it. For details, see Creating a Protection Policy and Adding a Domain Name to a Policy.
• If you use a dedicated WAF instance, make sure it has been upgraded to the latest version. For details, see Managing Dedicated WAF Engines.

Constraints

• Only professional and enterprise editions for the cloud mode support reference table management. This function is not supported by standard edition for cloud mode.
• Full Detection is not included in the WAF standard edition or cloud WAF billed on a pay-per-use basis.
• The reference table function is not included in the WAF standard edition or cloud WAF billed on a pay-per-use basis.

• The Cloud Mode - Load balancer access mode does not support the Response Code, Response Length, Response Time, Response Header, and Response Body fields. You can apply for the Cloud Mode - CNAME and Dedicated Mode access modes by referring to Submitting a Service Ticket.
• If you configure Protective Action to Block for a precise protection rule, you can configure a known attack source rule by referring to Configuring a Known Attack Source Rule to Block Specific Visitors for a Specified Duration. WAF will block requests matching the configured IP address, Cookie, or Params for a length of time configured as part of the rule.
• The path content cannot contain the following special characters: (<>*)
• It takes several minutes for a new rule to take effect. After the rule takes effect, protection events triggered by the rule will be displayed on the Events page.
• 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.

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, click Policies.
5. Click the name of the target policy to go to the protection rule configuration page.

   Before configuring protection rules, ensure that the target protection policy has been applied to a domain name. A protection policy can be applied to multiple protected domain names, but a protected domain name can have only one protection policy.

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 finishes its scan first and then blocks all requests that match the configured precise protection rule.

8. In the upper left corner above the Precise Protection rule list, click Add Rule.
9. In the displayed dialog box, add a precise protection rule by referring to .

   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
   Rule Description (Optional)	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. Condition parameter description: Field: 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. Block: Requests that match the rule will be blocked. Block Page for the Block action. The default value of Block Page is Default. 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. Redirection: Requests to the protected website are redirected to a specified URL. The root domain name of the redirection URL must be the same as the currently protected domain name (including a wildcard domain name). For example, if the protected domain name is www.example.com and the port is 8080, the redirection URL can be set to http://www.example.com:8080/error.html. 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.

    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

Analysis of a specific type of WordPress pingback attack shows that the User Agent field contains WordPress.

Figure 2 WordPress pingback attack

A precise rule as shown in the figure can block this type of attack.

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, configure the following protection rule to block such requests to reduce resource usage on the origin server. Figure 4 shows an example.

Figure 4 Blocking requests to a specific URL

Blocking Requests with null Fields

You can configure precise protection rules to block requests having null fields. Figure 5 shows an example.

Figure 5 Blocking requests with empty Referer

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

You can configure file types that match the path field to block specific files of certain types. For example, if you want to block .zip files, you can configure a precise protection rule as shown in Figure 6 to block access requests of .zip files.

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 a Specified IP Address to Access Your Website

You can configure two precise protection rules, one to block all requests, as shown in Figure 8, but then another one to allow the access from a specific IP address, as shown in Figure 9.

Figure 8 Blocking all requests

Figure 9 Allowing the access of a specified IP address

Configuration Example: Allowing a Specific IP Address to Access a Certain URL

You can configure multiple conditions in the Condition List field. If an access request meets the conditions in the list, WAF will allow the request from a specific IP address to access a specified URL.

Figure 10 Allowing specific IP addresses to access specified URLs