CC Protection safeguards websites. The newly revamped CC Protection 2.0 supports both Emergency Mode CC Protection and Custom CC Protection policies. Emergency Mode CC Protection synthesizes origin server abnormal response conditions (such as timeouts and response delays) and analyzes historical website access big data. Based on this synthesis, the emergency mode makes decisions to generate defense policies, which then intercept high-frequency access requests in real time. Custom CC Protection allows you to formulate protection rules based on the frequency of user access source IPs or SESSIONs. It then handles the access according to these rules, with handling measures including observation, human-machine verification, precise human-machine verification, JS validation, blocking, and precise blocking.
Note:
Emergency Mode CC Protection policy and Custom CC Rule Protection policy cannot be enabled simultaneously.
To use a SESSION-based CC protection policy, you must first configure SESSION before you can configure the SESSION-based CC protection policy.
Slow Attack Protection: When forwarding traffic, the WAF aggregates and cleanses slow requests, providing a certain level of protection against slow attacks.
Slow Attack Protection
Slow attacks, such as Slowloris and RUDY, are attack techniques that slow down server response. They typically consume server resources by sending a large volume of slow or incomplete requests, thereby preventing normal users from accessing the Web application.
1. When forwarding traffic, the WAF aggregates and cleanses slow requests by default. This provides protection against slow attacks, enabling it to cleanse slow attacks of types such as Slowloris.
2. When the WAF cleanses slow requests, HTTP protocol requests are returned a status code 400, and TCP protocol requests are returned a TCP RST.
Operation Step
Log in to the WAF console. At the top of the left sidebar, switch the console to the region where your instance is located (Chinese mainland/Non-Chinese mainland).
Example 1: Emergency CC protection Setting
Emergency CC protection is disabled by default. Before enabling it, confirm that the Custom CC Protection rules are not enabled.
1. Log in to the WAF console. In the left sidebar, choose Protection Policies > Basic Security.
2. On the Basic Security page, select the domain to protect in the top-left corner, and then click CC protection.
3. Click
in the Emergency CC protection module. After a secondary confirmation, you can configure Emergency CC protection.
Configuration item description:
Status Switch: When Emergency Mode CC Protection is enabled, protection is automatically triggered if the website suffers a large-volume CC attack (website QPS is not less than 1000 QPS), without requiring manual intervention. If no clear protection path is identified, it is recommended to enable Emergency Mode CC Protection, although this may result in some false positives. You can go to IP and Block Query in the console to view the blocked IP address information and handle it promptly.
Note:
If clear attack traffic characteristics are identified, it is recommended to use custom CC rules for protection.
Example 2: CC Protection Setting Based on Source IP
For IP-based CC protection policies, you can directly configure them without the need to set the SESSION dimension.
1. Log in to the WAF console. In the left sidebar, choose Protection Policies > Basic Security.
2. On the Basic Security page, select the domain to protect in the top-left corner, and then click CC protection.
3. On the CC Protection page, click Add rule. A dialog box for adding a CC protection rule will pop up.
4. In the Add CC protection rules dialog box, fill in the corresponding parameters and click OK.
Field description:
Rule name: The name of the CC protection rule, up to 50 characters.
Recognition mode: It supports IP address and SESSION identification modes, with IP address as the default. For the SESSION mode, the SESSION location information must be configured in advance.
Condition: The matching condition for CC protection rule frequency control is URL by default. You can configure multiple matching conditions. For a single rule, multiple conditions are in an AND relationship, meaning the action is executed only when all conditions are met. A maximum of 10 conditions can be configured. For detailed field descriptions, see Matching Method Field Description.
Frequency limiting method: You can choose between Penalty QPS and Traffic throttling and frequency limiting.
Penalty QPS: It imposes a custom-duration penalty on clients that trigger the frequency rule, preventing them from initiating requests within the set time based on the enforcement action.
Traffic throttling and frequency limiting: It strictly controls the number of requests from clients that trigger the frequency rule, limiting their maximum request volume per unit time based on the enforcement action. Throttling frequency limiting is available only for instances that have purchased BOT protection or API security.
Access frequency: Set the access frequency based on your business needs. It is recommended to enter a value 3 to 10 times the normal number of accesses. For example, if the average website visit rate is 20 times per minute, you can configure it to 60 to 200 times per minute. You can adjust this value based on the severity of the attack.
Action: The default action is Block. You can change it as needed. The detailed descriptions of each action are as follows:
Action Type
Description
Observe
Session requests that meet the matching conditions will be monitored and logged.
Block
Requests that meet the frequency control conditions will trigger the interception action, blocking the IP address or Session from accessing all pages of the website.
Precise block
Requests that meet the frequency control conditions will trigger the precise interception action. Unlike regular interception, precise interception only blocks the IP address or Session requests that match the conditions within the effective scope, rather than blocking the entire website.
CAPTCHA
Only used for browser access scenarios. Session requests that meet the matching conditions will undergo a Captcha challenge. If the challenge fails, the interception action will be executed. If the challenge succeeds, normal access is allowed within the penalty duration, and the Captcha result will be recorded in the log, with the status marked as Observation.
Precise Captcha
Requests that meet the frequency control conditions will trigger the precise human-machine identification action, initiating a human-machine verification challenge against the access requests from that IP address or Session to the website. If the challenge fails, the interception action will be executed. If the challenge succeeds, normal access is allowed within the penalty duration. The Captcha result is recorded in the log with the status marked as Observation.
JS validation
Requests that meet the matching conditions will undergo JavaScript validation and be logged.
Note:
JS Validation is supported only in the Enterprise edition and above. If your current edition does not support it, upgrade your WAF edition first. For details, see WAF Plan Upgrade Method.
Blocking page: You can choose between System Default Page and Custom. You can manage custom pages in System Settings> Custom Pages.
Gray Release Configuration: The default value is 100%. It can be set to any integer between 1% and 100%. After the gray release is configured, traffic at this proportion will be applied and take effect.
Penalty duration: The default is 10 minutes, with a minimum of 1 minute and a maximum of one week.
Effective Mode: You can choose from Permanent, Scheduled, Weekly, and Monthly.
Priority: The default value is 50. You can enter an integer from 1 - 100. A smaller number indicates a higher execution priority for this rule. For rules with the same priority value, the later the creation time, the higher the priority.
5. For rule operations, select an existing rule. You can then disable, edit, or delete it.
6. Requests matching the rule will be subjected to the configured protection action. You can view the execution results of Observe, Block, and Precise Block actions in Attack Logs. On the IP and Block Query page, you can view the IP address information blocked by Block and Precise Block actions in real time. You can also add IP addresses to the allowlist or blocklist on the Allowlist and Blocklist page.
Example 3: CC Protection Setting Based on SESSION
CC protection based on SESSION access rate can effectively solve the problem of false blocking that occurs in office networks, shopping malls, and public Wi-Fi environments, where users share the same IP address egress.
1. Log in to the WAF console. In the left sidebar, choose Protection Policies > Basic Security.
2. On the Basic Security page, select the domain to protect in the top-left corner, and then click CC protection.
3. Click Add in the SESSION settings. The Add SESSION dialog box pops up.
4. In the Add New SESSION dialog box, enter the corresponding parameters. After the configuration is complete, click Next.
Field description:
Session identifier name: A custom session name with a maximum of 32 characters.
Session identifier location: Specify the parameter name at a specific location to be used as the session identifier. The value corresponding to this parameter name serves as the session ID. You can select COOKIE, BODY, HEADERS, or QUERY.
Matching mode: Select Precision Match, String match, or Position match.
Match Mode
Configuration Item
Precision Match
Session Identifier Parameter Name: Enter a session ID, which must be 64 characters or less. Supports using the "." character to separate parameters at different levels. Example:
test: Identify the value of the test parameter in the JSON string as the session ID.
test1.test2: Identify the value of the test2 parameter contained within test1 in the JSON string as the session ID.
String match
Session Identifier: The starting position for string matching, with a maximum of 32 characters.
End position: The ending position for string matching, with a maximum of 32 characters.
Position match
Session Identifier: The matching start position for position matching, with a maximum of 32 characters.
Session position: The length of the matching range. Enter two integers between 0 and 2048.
5. Go to the SESSION test page, check whether the test results meet expectations, and click Save. Subsequently, the WAF will use the 10-character string following "security" as the SESSION identifier. SESSION information can also be deleted and reconfigured.
Example: If the complete parameter content of a request is key_a=124&key_b=456&key_c=789
Precision Match: If the Session Identifier Parameter Name is key_b, the matched content is 456.
String match: If the Session Identifier is key_b= and the End position is &, the matched content is 456.
Position match: If the Session Identifier is key_b, the start position is 0, and the end position is 2, the matched content is 456.
6. Configure a SESSION-based CC protection policy. Keep the configuration process consistent with Example 1. Select SESSION as the identification method and choose the application objects as needed. For descriptions of other fields, see Example 2: CC Protection Settings Based on Access Source IP address.
7. After the configuration is completed, the SESSION-based CC protection policy takes effect.
Note:
When using the SESSION-based CC protection mechanism, you cannot view blocking information in the IP address blocking state.
