CC protection can safeguard the access to website. CC protection settings 2.0 is upgraded with emergency CC protection and custom CC rules. Emergency CC protection can perform big data analysis on websites' access history and their real servers' exceptional response such as timeout and response delay, to generate protection policies for emergencies, blocking frequent access requests in real time. Custom CC rules support customizing protection based on user source IPs or session frequency, with actions including blocking, precise blocking, JS validation, observing, CAPTCHA, or precise CAPTCHA.
Note:
Emergency CC protection and custom CC rules cannot be enabled at the same time.
SESSION must be set before using the session-based CC protection policy.
Slow Attack Protection: When forwarding traffic, web application firewalls aggregate and clean slow requests, providing a certain level of slow attack protection capabilities.
Slow Attack Protection
Slowloris, RUDY, and other slow attacks are techniques that slow down server response times, typically by sending a large number of slow or incomplete requests to consume server resources, preventing normal users from accessing web applications.
When forwarding traffic, web application firewalls aggregate and clean slow requests by default, providing slow attack protection capabilities and the ability to clean slow attacks similar to Slowloris.
When a web application firewall cleans slow requests, HTTP protocol type requests will return a status code of 400, while TCP protocol type requests will return a TCP RST.
Directions
Log in to the Web Application Firewall console, and at the top of the left sidebar, switch the console to the instance location (Chinese mainland/non-Chinese mainland).
Example 1: Emergency CC protection settings
Emergency CC protection is disabled by default. Before enabling it, please make sure that the custom CC rule feature is disabled.
1. Log in to the WAF console and select Protection Policies > Basic Security on the left sidebar.
2. On the basic security page, select the target domain name in the top-left corner and click CC Protection.
3. Click
in the emergency CC protection module and confirm the operation to configure emergency CC protection.
Configuration item description:Status switch: After emergency CC protection is enabled, if a website is under massive CC attacks (with a website QPS of 1000 or above), the protection will be automatically triggered. If there are no specific protection paths, we recommend enabling emergency CC protection. As there may be some false alarms, you can click IP Query on the left sidebar to view the information of blocked IPs and handle them in time.
Note:
If there are specific protection paths, we recommend using custom CC rules.
Example 2: Access source IP-based CC protection settings
An IP-based CC protection policy can be directly configured without setting SESSION.
1. Log in to the WAF console and select Protection Policies > Basic Security on the left sidebar.
2. On the basic security page, select the target domain name in the top-left corner and click CC Protection.
3. On the CC protection page, click Add rule, and the rule adding window will pop up.
4. In the pop-up window, configure relevant parameters and click OK.
Field description:
Rule name: Name of the CC protection rule. It can contain up to 50 characters.
Recognition mode: It supports two modes: IP recognition (default) and SESSION recognition. To use SESSION recognition, you need to set the SESSION position first.
Condition: It specifies the match parameter, logical operator and match content to control access frequency. The match parameter defaults to URL. For the same rule, you can set up to 10 conditions with the logical AND operator. Refer to Match Mode Field Description for more details.
Frequency limiting method：You can choose between Penalty QPS and Traffic throttling and frequency Limiting. Penalty QPS: It applies a custom - duration action to clients that trigger the frequency rule, and the action is executed for requests initiated within the set time period. Traffic throttling and frequency Limiting: It strictly controls the number of requests from clients that trigger the frequency rule, and the action limits the maximum number of requests per unit of time. Note that Traffic throttling and frequency Limiting is only available for instances that have purchased BOT Protection or API Security.
Access frequency: sets the access frequency based on actual business requirements. We recommend setting a value 3 to 10 times the normal access frequency. For example, if your website is accessed 20 times per minute per visitor, you can set the access frequency to 60 to 200 times per minute, which can be further adjusted based on the attack severity.
Action: Defaults to "Block". You can set this field as needed. The detailed field description is as follows:
Action Type
Description
Observe
Requests that meet the matching conditions will be monitored and logged.
Block
Requests that meet the rate - limiting conditions will trigger the block action, preventing the IP or Session from accessing all pages of the website.
Precise block
Requests that meet the rate - limiting conditions will trigger the precision block action. Unlike regular blocking, precision block only intercepts requests from the IP or Session that meet the conditions within the effective scope, rather than blocking the entire website.
CAPTCHA
Only applicable in browser - based access scenarios. Requests that meet the matching conditions will be challenged with a CAPTCHA. If the challenge fails, the block action will be executed. If the challenge succeeds, normal access will be allowed within the punishment duration. CAPTCHA logs are recorded as Monitor.
Precise CAPTCHA
Requests that meet the rate - limiting conditions will execute the precision CAPTCHA challenge action. A CAPTCHA verification challenge will be initiated for the IP or Session's access requests to the website. If the challenge fails, the block action will be executed. If the challenge succeeds, normal access will be allowed within the punishment duration. CAPTCHA logs are recorded as Monitor.
JS validation
Requests that meet the matching conditions will be executed with JavaScript validation and logged.
Penalty duration: It ranges from 1 minute to 1 week. Default: 10 minutes.
Priority: Enter an integer from 1 to 100 (default: 50). The smaller the value, the higher the priority of this rule. For rules with the same priority, the last created one will be used.
5. You can select a created rule to disable, edit, or delete it.
6. Requests that match the rules will execute the corresponding protection actions as configured. The execution results of Observe, Block, and Precision Block actions can be viewed in the Attack Logs. On the IP Query page, you can view the IP information intercepted by Block and Precision Block actions in real - time. Additionally, you can add these IPs to the allowlist or blocklist on the Blocklist/Allowlist page.
Example 3: CC Protection Settings Based on SESSION
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, select Protection Policies > Basic Security in the left sidebar, and enter the basic security page.
2. On the basic security page, select the domain requiring protection in the upper left corner, click CC Protection, and enter the CC protection page.
3. Click New in the SESSION settings, and a pop-up for adding a new SESSION will appear.
4. In the SESSION Popup Settings, this example selects COOKIE as the test content, identified as security, with a start position of 0 and an end position of 9. After completing the configuration, click Next.
Field Descriptions:
Session name: Custom SESSION name, up to 32 characters.
Session position: Available options are COOKIE, GET, HEADER or POST, among them GET or POST refer to HTTP request content parameters, not http header information.
Match mode: String pattern matching or position match.
Session ID: Value identifier.
Start position: The string or position where the match starts.
End position: The end position of the string or position match.
5. Enter the SESSION test page, set the content as security = 0123456789... The subsequent WAF will use the 10-digit string following security as the SESSION identifier. The SESSION information can also be deleted and reconfigured.
6. Set a CC protection policy based on SESSION. The configuration process is consistent with Example 1. Select SESSION as the identification method and choose the application target as needed.
7. Configuration complete. CC protection policy based on SESSION takes effect.
Note:
Use SESSION-based CC protection mechanism. Cannot view blocking information in IP blocking status.
