The content of this page has been automatically translated by AI. If you encounter any problems while reading, you can view the corresponding content in Chinese.
CC Protection provides access protection for specific URLs of websites. CC Protection 2.0 has been revamped to support Emergency Mode CC Protection and Custom CC Protection policies. Emergency Mode CC Protection combines origin server anomaly responses (timeouts, response delays) and historical web access big data analysis to generate defense policies in real-time, intercepting high-frequency access requests. Custom CC Protection allows the user to formulate protection rules based on the access source IP or SESSION frequency, implementing disposal measures which include alarms, CAPTCHA, and blocking.
Note:
Emergency CC protection and custom CC rules cannot be enabled at the same time.
To use a SESSION-based CC Protection policy, you need to set up SESSION first, before setting up the SESSION-based CC Protection policy.
Slow Attacks Protection: When forwarding traffic, WAF will perform aggregated cleaning of slow requests, possessing a certain capability for slow attack protection.
Slow Attacks Protection
Slow attacks like Slowloris, RUDY, etc., are techniques that slow down server response speeds, usually by sending numerous slow or incomplete requests to consume server resources, thereby causing normal users to be unable to access web applications.
1. When forwarding traffic, WAF defaults to aggregating and cleaning slow requests, having the ability to protect against slow attacks, cleaning similar slow attacks like Slowloris.
2. When WAF cleans slow requests, HTTP protocol requests will return a status code 400, and TCP protocol requests will return a TCP RST.
CC Protection Operation Steps
Example 1: Emergency Mode CC Protection Settings
Emergency CC protection is disabled by default. Before enabling it, make sure that the custom CC rule feature is disabled.
1. Log in to WAF Console and select Configuration Center > Basic Security on the left sidebar to enter the Basic Security page.
2. On the Basic Security page, select the target domain name in the top-left corner and click CC Protection to enter the CC Protection page.
3. Click the
module and confirm the operation to enable emergency mode CC protection.
Note for Configuration Items:
Status Switch: When emergency mode CC protection is enabled, the system will automatically trigger protection if the website is under massive CC attacks (with a website QPS of 1000 or above), without the need for manual intervention. If there are no specific protection paths, we recommend enabling emergency mode CC protection, although there may be some false alarms. You can enter IP Query in the console to check blocked IP information and handle it promptly.
Note:
If there are specific attack traffic characteristics, we recommend using custom CC rules for protection.
Example 2: Access source IP-based CC protection settings
For IP-based CC protection policies, there is no need to set the SESSION dimension and you can directly configure it.
1. Log in to the WAF Console and select Configuration Center > Basic Security from the left sidebar to enter the Basic Security page.
2. On the Basic Security page, select the target domain name in the top-left corner and click CC Protection to enter the CC Protection page.
3. On the CC Protection page, click Add rule, and the CC Protection rule adding window will pop up.
4. In the CC Protection rule adding window, fill in the corresponding parameters and click OK.
Field Descriptions:
Rule name: CC Protection Rule Name, which can contain up to 50 characters.
Identification method: Both IP and SESSION identification modes are supported. The default is IP. SESSION mode requires pre-setting SESSION location information.
Matching Method: Frequency Control matching criteria for CC Protection rules. The default is URL. Supports setting multiple matching criteria. Multiple criteria under the same rule are in the "AND" relationship, which means all conditions must be met to perform the action. You can configure up to 10 criteria, with at least one URL required. Detailed field descriptions are as follows:
Match Field
Matching parameters
Logical symbols
Match content description
URL
No
Equal to
Include
Prefix Match
Required field. Starts with /. Supports directories and specific paths within 128 characters.
Method
No
Equal to
Include
Not equal to
Supports HEAD, GET, POST, PUT, OPTIONS, TRACE, DELETE, PATCH, CONNECT, and allows one value per input each time.
Query
Key value in Query parameters
Equal to
Query requires filling in key-value pairs, specific value needs to be filled in within 512 characters, configurable multiple times.
Referer
No
Equal to
Include
Prefix Match
Fill in the value within 512 characters.
Cookie
Key value in Cookie parameters
Equal to
Include
Not equal to
Cookie requires filling in key-value pairs, specific value needs to be filled in within 512 characters.
User-Agent
No
Equal to
Include
Not equal to
Fill in the value within 512 characters.
Custom request header
Enter the request header key, e.g., Accept, Accept-Language, Accept-Encoding, Connection, etc
Equal to
Include
Not equal to
Content is empty
Not exist
Fill in the specific value, within 512 characters. You can configure it multiple times; if the content is empty or does not exist, there will be no matching input box. Just fill in the matching parameter.
Access Frequency: Set the access frequency according to the business scenario. It is recommended to input 3 to 10 times the normal access count. For example, if the average visits per person are 20 times per minute, it can be configured to 60 to 200 times per minute, adjustable based on the severity of attacks.
Recommended action: Default is interception. It can be set as needed. Detailed explanations of each action are as follows:
Action Type
Description
Observation
Session requests that meet the matching criteria will be monitored and logged. The observation results can be viewed in Attack Logs.
Interception
Requests that meet the frequency control conditions will be intercepted, blocking the IP from accessing all URLs of the website. The punishment duration can be set between 5 minutes and 10080 minutes (7 days). The interception results can be viewed in the Attack Logs, and real-time information of the intercepted IPs can be checked in IP Query.
Human-Machine Recognition
This is only 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 carried out. If the challenge succeeds, normal access is allowed within the punishment duration. Captcha logs are recorded under observation.
Precise Interception
Requests qualifying for frequency control conditions will be precisely intercepted, blocking access from that IP to the protected URL. This differs from blocking the entire domain name. You can set the penalty duration between 5 minutes and 10080 minutes (7 days). The interception results can be viewed in the Attack Logs .
Accurate CAPTCHA
Requests that meet frequency control conditions will trigger an accurate CAPTCHA action, challenging the IP's access to the protected URL. If the challenge fails, interception will occur. If the challenge succeeds, normal access is allowed during the penalty duration. CAPTCHA records are logged for observation.
Penalty duration: Default is 10 minutes, with a minimum of 1 minute and a maximum of one week.
Priority: Default is 50. You can enter an integer between 1 and 100. The smaller the number, the higher the execution priority of this rule. Rules with the same priority are prioritized by their creation time, with newer rules taking precedence.
5. Rule Operation: Select the created rule and you can close, modify or delete the rule.
6. Configured according to the rules, triggering CC attacks.
7. In the Allowlist page, you can whitelist or blacklist IPs. In the IP Query page , you can view blocking information.
Example 3: Session-based CC protection settings
CC protection based on SESSION access rate can effectively solve the problem of misinterception caused by users using the same IP exit in office networks, supermarkets and public WIFI scenarios.
1. Log in to the WAF Console and select Configuration Center > Basic Security from the left sidebar to enter the Basic Security page.
2. On the Basic Security page, select the target domain name in the top-left corner and click CC Protection to enter the CC Protection page.
3. Click the Settings button in the SESSION settings section to open the SESSION settings popup.
4. In the SESSION settings popup, this example selects COOKIE as the test content, labeled as security, with the start position at 0 and the end position at 9. After configuration, click OK .
Field Descriptions:
SESSION Position: You can choose COOKIE, GET, HEADER, or POST. GET or POST refers to the HTTP request content parameters, not the HTTP header information.
Matching Pattern: Position matching or string matching.
SESSION ID: Value identifier.
Starting position: The string or position where the match starts.
End position: The end position of the string or position match.
5. SESSION dimension information testing. After adding, click Test. After filling in the content, click OK to test it.
6. Enter the SESSION testing page. Set the content to security = 0123456789… WAF will then use the 10-digit string following 'security' as the SESSION identification. The SESSION information can also be deleted and reconfigured.
7. Set a CC protection policy based on SESSION. The configuration process is consistent with Example 1. Select SESSION as the identification mode.
8. Once the configuration is completed, the session-based CC protection policy will take effect.
Note:
If you use session-based CC protection, you cannot view IP blocking information in the IP blocking status section.
