Help Center> Web Application Firewall> Best Practices> Configuring Protection Policies> Configuring CC Attack Protection> Configuring CC Attack Protection for Common Scenarios
Updated on 2024-02-05 GMT+08:00
View PDF

Configuring CC Attack Protection for Common Scenarios

This topic introduces how CC attack protection rules are used in certain scenarios.

Overview

You can have a quick glance to learn how to set WAF protection in the similar scenarios to protect your services.

Heavy-traffic 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 against this type of CC attacks. We recommend IP address-based rate limiting CC attack protection rules. For details, see IP Address-based Rate Limiting.

Configuration example: You can configure such a CC rule to mitigate CC attacks. If an IP address accessed any path under the current domain name more than 1000 times within 30 seconds, this rule will block requests from the IP address for 10 hours. This rule can be used as a preventive configuration for common small and medium-sized websites

To get improved and refined protection, you need to adjust rate limit settings and specify an appropriate protective action based on your service requirements. For example, if you need to prevent the login interface from being affected by crazy credential stuffing attacks, use the prefix is logical operator and set the matching content to the specific login path, such as /login.php.

  • Request Aggregation: 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 to WAF, requests to all matched domain names such as b.a.com and c.a.com are counted.
  • All WAF instances: This parameter is supported only in cloud mode. By default, requests to each WAF instance are counted. If you enable this, WAF will count requests to all your WAF instances for triggering this rule.

The request features are malformed or improper.

Many CC attack requests are constructed by attackers. After analyzing logs, it is found that these requests have many malformed packet features that do not match normal requests. The following protection rules are recommended to defend against requests having common malformed packets:

The following protection configurations are implemented through precise protection rules. For details, see Configuring a Precise Protection Rule.

  • Abnormal or malformed User-Agent: Invalid User-Agent (for example, Mozilla///), improper User-Agent (for example, www.example.com), and User Agent containing automation tool features If a request matches the features, it will be blocked.

    Configuration example: Blocking requests with User Agent containing Mozilla///.

  • Improper User-Agent: For example, for HTML5 pages promoted by WeChat, normal users should initiate access through WeChat. It obviously does not make sense if the request User-Agent comes from a Windows desktop browser (for example, MSIE 6.0). If a request matches the features, it will be blocked.

    Configuration example: Blocking requests with User Agent containing MSIE 6.0.

  • Abnormal Referer: For example, if a request does not contain a Referer or the Referer is fixed and comes from an unauthorized website, the request can be blocked (except when the website home page is accessed or the page is accessed for the first time). For URLs that can be accessed only through an internal address, you can analyze the behavior by checking the Referer field and determine whether to block the URLs.

    Configuration example: Blocking requests having no Referer

  • Abnormal Cookie: A normal request usually carries cookies that belong to the service set of the website (except when the user accesses the page for the first time). In most cases, CC attack packets do not carry any cookie. So you can block access requests having no cookies.

    Configuration example: Blocking requests having no cookies

  • Lack of some HTTP headers. For example, a common user will have the authentication header required by some services carried in the request, but attack packets do not.

    Configuration example: Blocking requests with no authorization headers included.

  • Incorrect request method: For example, if an interface designed for only POST requests is attacked by a large number of GET requests, you can directly block GET requests.

    Configuration example: Blocking GET requests