Web Application Firewall:Custom rules

How custom rules work

Custom rules operate on a simple hierarchy: Rules are grouped into protection templates (or simply templates), which are then applied to protected objects.

• Rule: The basic building block that defines a security check. The main components are as follows:

  • Match condition: The if of the rule. It defines the request characteristics to be inspected, such as the request path or client IP address.

  • Rule action: The then of the rule. It defines what to do when a request matches. The rule actions are prioritized from high to low as follows: Block, Strict Slider CAPTCHA, Slider CAPTCHA, JavaScript Validation, and Monitor.

• Template: A collection of rules that define the specific content and scope of the rules. Think of it as a reusable policy. It consists of three parts: template type, protection rules, and the objects to which it applies. You can create the following types. Note that the type cannot be changed after creation.

  • Default Template: Automatically applied everywhere for applying universal protection rules that are enforced globally.

  • Custom Template: Applied only to specific services you choose for applying granular protection rules to specific, high-risk services, such as login portals, payment APIs.

• Protected object: The target of your protection, such as your domain name or API. You can group multiple objects into a Protected Object Group for easier management.

Step 1: Navigate to the custom rule area

1. Log on to the Web Application Firewall 3.0 console.

2. In the top menu bar, select the resource group and region for the WAF instance (Chinese Mainland or Outside Chinese Mainland).

3. In the navigation pane on the left, select Protection Configuration > Core Web Protection.

Step 2: Create a protection template

On the Core Web Protection page, in the Custom Rule area, click Create Template. In the Create Template - Custom Rule panel, complete the following configuration.

• Template Name: Enter a name for the template.

• Save as Default Template: Specifies whether this template should be the default for the custom rules module. You can only have one default template, and this setting is permanent and cannot be changed after creation.

  • Yes. The template is automatically applied to all protected objects. You do not need to configure the Apply To setting, but you can manually exclude specific objects later.

  • No: The template is not applied to any objects by default. You must manually configure the Apply To setting to select the specific protected objects or groups where it will be enforced.

Step 3: Add protection rules to the protection template

In the Rule Configuration area, click Create Rule and configure the following parameters.

• Rule Name: Enter a name for the rule.

• Match Condition: Specify the conditions to match requests. Click Add Condition to add a condition. Each condition consists of a Match Field, a Logical Operator, and a Match Content. See the configuration examples below:

  Note

  If a rule contains multiple conditions, a request must meet all conditions (logical AND) to match the rule. For details about match fields and logic operators, see Match conditions.

  Match Field	Logical Operator	Match Content	Description
  URI Path	Contains	/login.php	The request matches the rule if the request path contains /login.php.
  IP	BelongsTo	192.1.XX.XX	The request matches the rule if the client IP address is 192.1.XX.XX.

• Protection Rule Type: Supports two types: Access Control and Rate Limiting.

  • Access Control: Suitable for scenarios that require precise control over specific types of requests.

  • Rate Limiting: Suitable for scenarios that are based on request rate, such as preventing credential stuffing and brute-force attacks. This feature is available only for subscription-based Enterprise and Ultimate instances, and pay-as-you-go instances.

  Access Control

  Configure an access control rule to apply a specified action to requests that meet specific conditions.

  Rate Limiting

  Configure a rate limiting rule to mitigate excessive access from clients.

  • Rate Limiting Conditions: A blacklist action is triggered if the number of times a single Statistical Object matches the rule within the specified Statistical Interval (Seconds) exceeds the set Threshold (Times).

    Parameter	Description
    Statistical Object	Select the object for which to measure request rate. Options: IP: Measures the request rate from the same IP address. Custom Header: Groups requests based on the value of a custom request header, such as Referer, and measures the request rate for each group of identical header values within a specified period. Custom Parameter: Measures the request rate that contains a specified parameter in the URL. For example, if the parameter is user_id, WAF measures the request rate with the same user_id value. Custom Cookie: Measures the rate of HTTP requests that contain a specific cookie within a specified period. For example, if the custom cookie name is User, WAF counts the number of occurrences for each User value within the period. Session: WAF establishes a session ID by setting a cookie named acw_tc in the response and measures the client request rate based on this cookie's value. Account: Measures the request rate from the same account. You must configure User Identification on the Protected Objects page before you can use this option. For more details, see Configure protected objects and protected object groups.
    Statistical Interval (Seconds)	Set the statistical period in seconds.
    Threshold (Times)	Set the maximum number of times the Statistical Object can match the Match Condition within the Statistical Interval (Seconds).

  • Status code detection conditions: If the Quantity or Percentage (%) of a specific Status Code exceeds the set threshold, a blacklist action is triggered. If you enable status code detection, a statistical object must meet both the rate limiting conditions and the status code conditions to trigger a blacklist action.

    Parameter	Description
    Status Code	Set the status code to be monitored.
    Quantity	Set the maximum number of times the specified Status Code can appear in request responses within the statistical period.
    Percentage (%)	Set the maximum percentage of responses that can contain the specified Status Code within the statistical period.

  • Blacklist action conditions: Adds the statistical object that meets the above detection conditions to a blacklist. For the duration of the Timeout Period, WAF applies the configured Rule Action to requests from this object that fall within the blacklist's Apply To scope.

    Parameter	Description
    Apply To	Set the scope for the blacklist action. Options: Current Match Condition: Processes only requests that meet the Match Condition of the current rule. Protected Object: Processes all requests from the statistical object (such as an IP address) to access the current protected object.
    Timeout Period	Set the duration for which the blacklist action is effective. Unit: seconds. Value range: 60 to 86,400.

• Rule Action: Select the action to perform when a request matches the rule.

  Parameter	Description
  JavaScript Validation	WAF returns a JavaScript snippet to the client. A standard browser automatically executes this code. If the client executes it successfully, WAF allows all requests from that client for a period of time (default is 30 minutes); otherwise, it blocks the request.
  Block	Blocks requests that match the rule and returns a block page to the client. Note By default, WAF uses a standard block page. You can also customize the block page by using custom response.
  Monitor	Allows requests that match the rule to pass but logs the match event. When you test a rule, first set its action to Monitor and analyze WAF logs to ensure no legitimate traffic is blocked before changing the action.
  Slider CAPTCHA	WAF returns a slider CAPTCHA page to the client. If the client successfully completes the challenge, WAF allows all requests from that client for a period of time (default is 30 minutes); otherwise, it blocks the request.
  Strict Slider CAPTCHA Verification	WAF returns a slider CAPTCHA page to the client. If the client successfully completes the challenge, the request is allowed; otherwise, it is blocked. In this mode, the client must complete a slider challenge for every request that matches the rule.

  Note

  • The Slider CAPTCHA verification is available only for subscription-based Enterprise and Ultimate instances, and pay-as-you-go instances.

  • JavaScript Validation and Slider CAPTCHA are applicable only to synchronous requests. To ensure features function correctly with asynchronous requests, such as those using XMLHttpRequest or the Fetch API, inject the web SDK. For more details, see the JS Challenge and Slider CAPTCHA sections in Bot Management.

  • When JavaScript Validation or Slider CAPTCHA is enabled, WAF sets a cookie in the response header via Set-Cookie after the client passes the validation. The cookie is named acw_sc__v2 for JavaScript Validation or acw_sc__v3 for Slider CAPTCHA. The client will include this identifier in the Cookie header of subsequent requests.

• Advanced Settings (Optional): The following advanced features are available only for subscription-based Enterprise and Ultimate instances, and pay-as-you-go instances.

  Parameter	Description
  Canary Release	Configure the percentage of objects to which the rule applies, based on different dimensions. After enabling canary release, set the Dimension and Canary Release Proportion. The Dimension can be IP, Custom Header, Custom Parameter, Custom Cookie, or Session.
  Effective Mode	Permanently Effective (default): The rule is always active when the protection template is enabled. Fixed Schedule: The protection rule is active only during a specified time range. Recurring Schedule: The protection rule is active only during a specified recurring cycle.

Step 4: Specify where the protection template applies

In the Apply To area, select the protected objects and protected object groups for this template.

How the template is applied depends on the configuration in Step 2:

• Set Save as Default Template to Yes: Do not need to specify objects. The template automatically applies to all current and future protected objects and protected object groups. You can manually exclude specific objects.

• Set Save as Default Template to No: Manually select the protected objects and object groups to which the template applies.

Protection rule configuration examples

Restrict access to the admin backend to specific IPs

Block all access to the /wp-admin path except for access from the administrator's IP address 192.1.XX.XX.

• Match Condition:

  • Match Field: IP, Logical Operator: Is not, Match Content: Whitelisted administrator IP address 192.1.XX.XX.

  • Match Field: URI, Logical Operator : Contains, Match Content: The restricted web path /wp-admin.

• Protection Rule Type: Access Control.

• Rule Action: Block.

Block malicious crawlers and scanners

Block HTTP requests where the User-Agent (UA) field contains bot.

• Match Condition: Match Field: User-Agent, Logical Operator: Contains, Match Content: bot.

• Protection Rule Type: Access Control.

• Rule Action: Block.

Enable CAPTCHA or JavaScript validation for web pages

Apply CAPTCHA or JavaScript validation to all pages except API endpoints. This example assumes all API endpoint URIs contain the string /api.

• Match Condition: Match Field: URI, Logical Operator: Does not contain, Match Content: /api.

• Protection Rule Type: Access Control.

• Rule Action: Slider CAPTCHA or JavaScript Validation.

Apply rate limiting to API endpoints

Enable rate limiting for all API endpoints except example.com/api/pay. In this example, all API interface URIs contain the string /api.

• Match Condition:

  • Match Field: URI, Logical Operator: Is not, Match Content: /api/pay.

  • Match Field: URI, Logical Operator: Contains, Match Content: /api.

• Protection Rule Type: Rate Limiting.

• Statistical Object: IP.

• Statistical Interval (Seconds): 10.

• Threshold (Times): 5.

• Apply To: Current Match Condition.

• Timeout Period: 1800.

• Rule Action: Block.

Apply in production

To avoid service disruptions, do not apply new rules with a Block action directly to a production environment. We recommend following the deployment process below.

1. Analyze request characteristics: Use WAF security reports and logs to identify the characteristics of normal service requests and malicious attacks, such as IP address, User-Agent, header, and URI. If you plan to configure a rate limiting rule, you must also determine the request rate baseline for your normal services.

2. Configure a whitelist: Before creating a custom rule template, create a whitelist rule and add trusted IP addresses to the whitelist. This prevents trusted requests from being mistakenly blocked by the new rule.

3. Do canary release testing: After creating a custom rule, you can use one of the following three methods to test and observe its behavior before deploying it to production.

   • Apply the rule to a non-production environment for testing.

   • Set Rule Action to Monitor.

   • Enable Canary Release in Advanced Settings.

4. Analyze test results: After a testing period, review security reports and logs for false positives among the requests that match the rule.

5. Apply to the production: Once you confirm that the false positive rate is within an acceptable range, change the rule's action to the intended action and apply it to your production environment.

6. Continuously monitor and optimize: Continuously monitor security reports and logs, and dynamically adjust and optimize rules based on business changes and protection effectiveness.

More operations

• Slider CAPTCHA, Rate Limiting, and Advanced Settings are available only for subscription-based Enterprise and Ultimate instances, and pay-as-you-go instances.

• A single protection rule can have a maximum of 5 match conditions.

Why is my rule not taking effect?

If a rule is not taking effect, check the following items in order:

• Template status: Confirm that the protection template and the rule both have their status set to enabled.

• Applicable objects: Confirm that the application status for the protected object is Effective.

• Rule configuration: Verify the rule's configuration, especially the Match Conditions, to ensure it targets the intended requests.

• Other rules: Check for conflicting rules or modules. For example, a whitelist rule will allow a request to bypass other checks.

How do I configure rate limiting when multiple domains resolve to a single cloud service instance?

Rate limiting rules restrict the request rate of a statistical object at the protected object level. If a single cloud service instance handles traffic for multiple domains, WAF calculates the request rate by aggregating the traffic from all associated domains. If you only need to limit the request rate for a specific domain, choose one of the following two methods:

• Method 1: Create a dedicated protected object

  Add the domain name as a protected object in WAF and apply a rate limiting rule to that domain name object. For more information, see Configure protected objects and protected object groups.

• Method 2: Use the Host header in a match condition

  In the Match Condition section of the rate limiting rule, use the Host field to specify the exact domain for which you want to limit the request rate.

Why does the rule not take effect after I configure the match field to Body Parameter?

This can happen if the match content is too short. When using the Body Parameter field, ensure the match content is at least 5 characters long; otherwise, WAF cannot inspect the traffic.