Configuring CC Attack Protection Rules to Defend Against CC Attacks

CC attack protection does not take effect by default. If your website is suddenly attacked by a large amount of abnormal traffic, you can configure CC attack protection rules to limit the rate of the source or destination to defend against CC attacks.

CC Attacks and Security Measures

Challenge Collapsar (CC) attacks are attacks on web servers or applications. Attackers use standard GET and POST requests to obtain information, for example, request for URIs involving database operations or other URIs that consume system resources. They send a large number of normal protocol data packets to the target server, exhausting server resources and causing the server to fail to respond to normal requests.

CC attack protection can limit the rate of the source (by policy, domain name, and URL) and destination (by IP address, cookie, header, and referer) to accurately identify and effectively mitigate CC attacks.

Figure 1 CC attack protection
Click to enlarge

Prerequisites

You have added the website you want to protect to WAF.

Constraints

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.
If Field in the Condition List is set to Method, Content cannot be set to TRACE or CONNECT. Otherwise, a parsing error will occur.
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

Log in to the WAF console.
Click in the upper left corner and select a region or project.
(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.
In the navigation pane on the left, click Policies.
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.
Click the CC Attack Protection configuration area and ensure that the CC attack protection is enabled.

: enabled.
In the upper left corner above the CC Attack Protection rule list, click Add Rule.

On the Add CC Attack Protection Rule panel, configure a CC attack protection rule by referring to Table 1.

Figure 2 Adding a CC attack protection rule
Click to enlarge

**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. Condition parameter description: Field: For details, see Condition Field Description. Subfield: If IPv4, 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.	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. Requests: The maximum number of valid accesses that can be made by a web visitor within the rate limit period. The value ranges from 1 to 2,147,483,647. Block Duration (unit: second): The value ranges from 1 to 3,600.	10 requests allowed in 60 seconds
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. 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. 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.	Log only

Click Confirm. 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.

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

: enabled.
Add a CC attack protection rule with Protection Action set to Verification code.

Figure 3 Verification code
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
Go to the WAF console. In the navigation pane on the left, choose Events. View the event on the Events page.