Mitigating CC Attacks Using Frequency Control Policies

Enabling a Frequency Control Policy

1. Log in to the AAD console.
2. In the navigation pane on the left, choose Advanced Anti-DDoS > Protection Policies. The Protection Policies page is displayed.

3. Click the Web CC Protection tab.
4. After selecting the region and objects, click Create frequency control rules.
   Figure 1 Frequency control rules
   

5. Click Create frequency control rules.
6. Configure the frequency control rule, as shown in Figure 2.
   Figure 2 Creating a frequency control rule
   

   Table 1 Parameter description

   Parameter	Description
   Name	Name of the rule Enter a maximum of 128 characters. Only letters, digits, underscores (_), hyphens (-), colons (:), and periods (.) are allowed.
   Rate Limit Mode	Source: Requests from a specific source are limited. For example, if traffic from an IP address (or user) exceeds the rate limit you configure in this rule, traffic rate of the IP address (or user) will be limited in the way you configure. Per IP address: A web visitor is identified by the IP address. Per user: A website visitor is identified by the key value of Cookie or Header. Other: A web visitor is identified by the Referer field (user-defined request source). NOTE: If you set Rate Limit Mode to Other, set Content of Referer to a complete URL containing the domain name. The Content field supports prefix match and exact match only, but cannot contain two or more consecutive slashes, for example, ///admin. If you enter ///admin, the engine will convert it to /admin. For example, if you do not want visitors to access www.test.com, set Referer to http://www.test.com. Destination: Requests to a specific destination are limited. By rule: If this rule is used by multiple domain names, requests for all these domain names are counted for this rule no matter what IP addresses these requests originate from. If you have added a wildcard domain name, requests for all domain names matched the wildcard domain name are counted for triggering this rule no matter what IP addresses these requests originate from. By domain name: Requests for each domain name are counted separately. If the number exceeds the threshold you configure, the protective action is triggered no matter what IP addresses these requests originate from. By URL: Requests for each URL are counted separately. If the number exceeds the threshold you configure, the protective action is triggered no matter what IP addresses these requests originate from.
   Request Aggregation	This parameter is not required when you select Destination and By rule for Rate Limit Mode. This function is disabled by default. Keep this function enabled so that requests to all domain names that match a protected wildcard domain are counted for triggering this rule. For example, if you added *.a.com, requests to all matched domain names such as b.a.com and c.a.com are counted.
   User Identifier	This parameter is mandatory when you select Source and Per user for Rate Limit Mode. 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. This field does not support regular expressions. Only complete matches are supported. For example, if a website uses the name field in the cookie to uniquely identify a web visitor, enter name. 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.
   Trigger	Click Add to add conditions. At least one condition is required, but up to 30 conditions are allowed. If you add more than one condition, the rule will only take effect if all of the conditions are met. Field: Set this parameter based on the site requirements. Subfield: Configure this field only when IPv4, IPv6, Cookie, Header, or Params is selected for Field. Logic: Select the required logic from the drop-down list box. Content: Enter or select the content that matches the condition.
   Rate Limit	The number of requests allowed from a website visitor in the rate limit period. If the number of requests exceeds the rate limit, the system takes the action you configure for Protective Action. Global: Requests to one or more nodes will be aggregated according to the rate limit mode you select. By default, requests to each node are counted. If you enable this option, the system will count requests to all nodes for triggering this rule. To enable user-based rate limiting, select Per user or Other (Referer) instead of Per IP address for Rate Limit Mode. IP address-based rate limiting cannot restrict the access rate of a specific user. However, with user-based rate limiting, requests may be forwarded to one or more nodes. Select Global to count requests to all nodes.
   Protective Action	The action that the system will take if the number of requests exceeds Rate Limit you configured. The options are as follows: Verification code: The system allows requests that trigger the rule as long as your website visitors complete the required verification. Currently, verification code supports English. Block: The system blocks requests that trigger the rule. Block dynamically: The system blocks requests that trigger the rule based on Allowable Frequency, which you configure after the first rate limit period is over. Log only: The system only logs requests that trigger the rule. JS Challenge: AAD 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, AAD allows all requests from the client within a period of time (30 minutes by default). During this period, no verification is required. If the client fails to execute the code, AAD blocks the requests.
   Lock Verification	This parameter is mandatory if Protective Action is set to Verification code. If a visitor fails verification code authentication, verification is required for all access requests within the specified period.
   Allowable Frequency	This parameter can be set if you select Block dynamically for Protective Action. The system blocks requests that trigger the rule based on Rate Limit first. Then, in the following rate limit period, AAD blocks requests that trigger the rule based on Allowable Frequency you configure. The Allowable Frequency must be less than or equal to the Rate Limit.
   Notification Window	The default option is Immediately.
   Block Duration	Period of time for which to block the item when you set Protective Action to Block.
   Block Page	The page displayed if the request limit has been reached. This parameter is configured only when Protective Action is set to Block. If you select Default settings, the default block page is displayed. If you select Customize, customize a page to be displayed.
   Block Page Type	If you select Custom for Block Page, select a type of the block page among options application/json, text/html, and text/xml.
   Page Content	Specifies the content to be displayed on the page you will customize.

7. Click OK.

Fields of Rate Limiting Conditions

Example Configuration

Heavy-traffic high-frequency CC attacks: In large-scale CC attacks, a single zombie server can send far more packets than a common user does. In this scenario, a rate limiting rule is the most effective method to defend against this type of CC attacks.

Figure 3 Protection rule settings

Follow-up Operations

• Enable frequency control protection: On the Web Attack Protection page, set Frequency Control to .
• Disable frequency control protection: On the Web Attack Protection page, set Frequency Control to .

FAQ

• What Are the Differences Between DDoS Attacks and Challenge Collapsar Attacks?