Configuring CC Attack Protection Rules to Defend Against CC Attacks

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.
• 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, select an existing reference table. For details, see Creating a Reference Table to Configure Protection Metrics in Batches.
• Counting requests to All WAF instances is only supported by cloud CNAME access mode.
  

  In the CN East-Shanghai1 or CN North-Ulanqab1 region, you need to submit a ticket to enable All WAF instances for all dedicated WAF instances. For details, see Submitting a Service Ticket.

• If you are using a cloud WAF edition and your website uses proxies such as anti-DDoS, Content Delivery Network (CDN), and cloud acceleration services, select Source for Rate Limit Mode and then Per user and enable All WAF instances.
  If a website has used other proxy services, such as CDN and advanced anti-DDoS in front of WAF, the access requests to WAF will be distributed to each WAF instance for traffic forwarding. By default, WAF counts requests on each WAF instance separately. To set a proper rate limit frequency, follow the following principles:

  • Cloud mode - CNAME access: This mode supports counting requests to All WAF instances. That means WAF aggregates requests to all WAF nodes for rate limiting. You can just enable this function during configuration.
  • Dedicated mode:
    • Generally, this mode does not support global counting for all WAF instances. The Rate Limit can be set to the maximum access requests allowed for a website visitor divided by the number of WAF instances used to protect the website.

      For example, if you use two WAF dedicated instances to protect you website, and want to limit the requests for a single web visitor to no more than 1,000, set Rate Limit to 500, which is obtained by dividing 1,000 by 2.

    • This mode supports All WAF instances. If you want to enable this function, submit a service ticket. Before using this function, note that the global counting (All WAF instances) is not an accurate rate limit. In some cases, a delay may occur as it may take several seconds for the internal counter to update. Due to this type of delay, part of requests exceeding the threshold may still reach the origin server before WAF protective actions (such as block) work.
• 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.
• It takes several minutes for a new rule to take effect. After a rule takes effect, protection events triggered by the rule will be displayed on the Events page.

Configuring a CC Attack 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 CC Attack Protection configuration area and ensure that the CC attack protection is enabled.

   : enabled.

7. In the upper left corner above the CC Attack Protection rule list, click Add Rule.
8. On the Add CC Attack Protection Rule panel, configure a CC attack protection rule by referring to Table 1.

   For example, you can configure a CC attack protection rule to block requests from a visit for 600 seconds by identifying their cookie (name field) if the visitor accessed a URL (for example, /admin) of your website over 10 times within 60 seconds.

   Figure 2 Adding a CC attack protection rule
   

   Table 1 Rule parameters

   Parameter	Description	Example Value
   Rule Name	Name of the rule.	waftest
   Rule Description (Optional)	Description of the rule.	--
   Rate Limit Mode	Select the object for rate limiting. Source and Destination rate limiting are supported. Source: The source end rate is limited based on configured conditions. The source end rate can be limited by IP address, user (Cookie, Header), and Referer. Destination: The destination end rate is limited based on configured conditions. The destination end rate can be limited by rule, domain name, and URL.	Source
   Rate Limit Type	Set the rate limit type based on the rate limit mode. If Rate Limit Mode is set to Source, Rate Limit Type can be set to Per IP address, Per user, or Other. Per IP address: A website visitor is identified by the IP address. Per user: A website visitor is identified by the cookie or header key value. If Per user is selected, you need to configure User Identifier of the cookie or header. Cookie: A cookie field name. You need to configure an attribute variable name in the cookie that can uniquely identify a web visitor based on your website requirements. Cookie field names do not support regular expressions. Only exact matches are supported. For example, if a website uses the name field in the cookie to uniquely identify a web visitor, enter name. If no cookie field exists, BENSESSCC_TAG is used for counting by default. A request is counted as long as the cookie field exists, even if it is empty. Header: Set the user-defined HTTP header you want to protect. You need to configure the HTTP header that can identify web visitors based on your website requirements. If no header field exists, the request is not counted. A request is counted as long as the cookie field exists, even if it is empty. Other: A website visitor is identified by the Referer field (user-defined request source). If you select Per user for Rate Limit Type, you need to configure Referer. The Referer field must be a complete URL link that contains the domain name. Only prefix matching and exact matching are supported. The URL cannot contain consecutive slashes (for example, ///admin) because WAF engine will convert /// to /. For example, if you do not want visitors to access www.test.com, set Referer to http://www.test.com. If Rate Limiting Mode is set to Destination, Rate Limiting Type can be set to By rule, By domain name, or By URL. By rule: If a request reaches the rate limit configured for a rule, the request hit the rule and will be limited according to the rule. If multiple domain names share a policy, the number of requests for all domain names in the policy are counted for triggering the rule. Access IP addresses will not be considered. If the protected domain name is a wildcard domain name, the requests for all subdomain names matched to the wildcard domain name are counted for triggering the rule. Access IP addresses will not be considered. By domain name: If the frequency of access requests for a domain name reaches the rate limit, the protective action configured in the hit rule will be triggered to handle corresponding requests. The total number of requests are counted by domain name for triggering the rule. Access IP addresses will not be considered. By URL: If the frequency of access requests for a URL reaches the rate limit, the protective action configured in this rule will be triggered to handle corresponding requests. The total number of requests are counted by URL for triggering the rule. Access IP addresses will not be considered.	Rate Limit Type: By user User Identifier and set Cookie to name.
   Request Aggregation	If the protected domain name is a wildcard domain name, this feature determines whether to aggregate and count the requests for all subdomain names for triggering the rule. You can enable this if Rate Limit Type is set to Per IP address, Per user, Other, By domain name, or By URL. Disabled (default): Requests of all subdomains are not counted together for triggering the rule. Enabled: Requests to all domain names that match a protected wildcard domain are counted for triggering the rule. For example, if you added *.a.com to WAF, requests to all matched domain names such as b.a.com and c.a.com are counted.
   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. Subfield: If IPv4, IPv6, Cookie, Header, or Params is selected for Field, configure this field based on site requirements. A subfield cannot exceed 2,048 characters. 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, select an existing reference table. For details, see Creating a Reference Table to Configure Protection Metrics in Batches. 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 for Field, Include for Logic, and /admin for Content
   Rate Limit	The maximum number of valid accesses that can be made by a web visitor within the rate limit period. If the number of accesses exceeded the limit, WAF takes the action you have configured for Protective Action. Times (Unit: request): The value ranges from 1 to 2,147,483,647. Duration (unit: second): The value ranges from 1 to 3,600.	10 requests allowed in 60 seconds
   All WAF Instances	This feature enables WAF to count identified requests to one or more WAF instances according to the rate limit type you select. This feature can be enabled when Rate Limit Mode is set to Source. Disabled (default): Requests for each WAF instance are counted separately for triggering the rule. Enabled: Requests for all WAF instances in the region are counted together for triggering the rule. If IP address-based rate limiting cannot limit the access rate of a specific user, you can select Per user or Other for Rate Limit Mode to enable user-based rate limiting. Referer must be configured. However, with user-based rate limiting, requests may be forwarded to one or more WAF instances. So All WAF instances must be enabled for triggering the rule precisely. NOTE: Global counting (All WAF Instances) is supported in the following access modes: Cloud mode - CNAME access: supported Cloud mode - Load balancer access: not supported Dedicated mode: You can submit a service ticket to enable this feature in CN East-Shanghai1 and CN North-Ulanqab1. Configuration suggestions: If a website has used other proxy services, such as CDN and advanced anti-DDoS in front of WAF, the access requests to WAF will be distributed to each WAF instance for traffic forwarding. By default, WAF counts requests on each WAF instance separately. To set a proper rate limit frequency, follow the following principles: Cloud mode - CNAME access: This mode supports counting requests to All WAF instances. That means WAF aggregates requests to all WAF nodes for rate limiting. You can just enable this function during configuration. Dedicated mode: Generally, this mode does not support global counting for all WAF instances. The Rate Limit can be set to the maximum access requests allowed for a website visitor divided by the number of WAF instances used to protect the website. For example, if you use two WAF dedicated instances to protect you website, and want to limit the requests for a single web visitor to no more than 1,000, set Rate Limit to 500, which is obtained by dividing 1,000 by 2. This mode supports All WAF instances. If you want to enable this function, submit a service ticket. Before using this function, note that the global counting (All WAF instances) is not an accurate rate limit. In some cases, a delay may occur as it may take several seconds for the internal counter to update. Due to this type of delay, part of requests exceeding the threshold may still reach the origin server before WAF protective actions (such as block) work.
   Protective Action	Action to be taken when the request frequency exceeded Rate Limit you configure: Block: If the request frequency exceeded the rate limit, the request will be directly blocked. For Block action, by default, Blocking Method is set to Block duration, Block Duration set to 0 seconds , and Block Page to Default settings. You can customize the blocking method and block page. Blocking Method Known attack source: WAF automatically blocks requests based on the IP addresses, cookies, or parameters of the requests. For more details, see Configuring a Known Attack Source Rule to Block Specific Visitors for a Specified Duration. Block duration (default): Duration for blocking a request after the request reaches the rate limit threshold within the rate limit period. The duration ranges from 0 to 65,535 seconds. A block duration that longer than the rate limit period is recommended. Block Page The page displayed if the request limit has been reached. This parameter is configured only when Protective Action is set to Block. 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. Block dynamically: WAF blocks requests that trigger the rule based on Rate Limit first. Then, in the following rate limit period, WAF blocks requests that trigger the rule based on Allowable Frequency you configure. Block dynamically: Allowable Frequency is 0 and Block Page is Default by default. You can customize the allowable frequency and block page. Allowable Frequency 0: WAF blocks all requests that trigger the rule in the next rate limit period. Custom: The value cannot be greater than Rate Limit you configure. Block Page The page displayed if the request limit has been reached. This parameter is configured only when Protective Action is set to Block. 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. Verification code: WAF allows requests that trigger the rule as long as your website visitors complete the required verification. Currently, verification code is only used for static pages, so it cannot protect asynchronous interfaces such as Ajax and Fetch APIs. Verification code: You need to set a lockout duration in Lock Verification for this action. If the verification code failed, the user will be locked for the specified duration. The default value for Lock Verification is 0 seconds. You can set a custom value ranging from 0 to 3,600 seconds. Log only: WAF only logs requests that trigger Rate Limit set in the rule. 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.	Log only
   Application Schedule	Time when the rule takes effect. Immediate: The rule works immediately after it is enabled. Periodic: You can specify a time range in a time zone to let the rule work at the time range every day. Gray release: In the specified period, the probability that client requests trigger the rule increases linearly from 0% to 100%. Custom: You can select a time range for the rule to work. NOTE: Periodic and gray application schedules are under OBT now. You need to submit a service ticket to enable them.	Immediate

9. Click OK. You can then view the added CC attack protection rule in the CC 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, enter http://www.example.com/admin in the address bar, and refresh the page 10 times within 60 seconds. In normal cases, the custom block page will be displayed the eleventh time you refresh the page, and the requested page will be accessible when you refresh the page 60 seconds later.
     2. On the Events page, check the protection logs.

Configuration Example - Verification Code

You can take the following steps to verify that CAPTCHA verification is enabled for your website (www.example.com) protected by WAF.

1. Click the CC Attack Protection configuration area and ensure that the CC attack protection is enabled.

   : enabled.

2. Add a CC attack protection rule with Protection Action set to Verification code.
   Figure 3 Verification code
   

3. Clear the browser cache and access http://www.example.com/admin/.

   If you access the page 10 times within 60 seconds, a verification code is required when you attempt to access the page for the eleventh time. You need to enter the verification code to continue the access.

   Figure 4 Verification code
   

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

FAQs

Why Cannot the Verification Code Be Refreshed When Verification Code Is Configured in a CC Attack Protection Rule?