Third-party services and DDoS protection
Some Cloudflare customers choose to use a Content Delivery Network (CDN) in front of Cloudflare to cache and serve their resources.
Cloudflare recommends that you do not use a third-party CDN in front of Cloudflare. Some CDN providers may introduce subtleties into HTTP requests that deviate from protocol standards and/or protocol best practices. Additionally, because traffic to Cloudflare will originate from a limited set of IP addresses of the third-party CDN, in rare occasions — such as when using the Akamai CDN in front of Cloudflare — it may appear as if the CDN is launching a DDoS attack against Cloudflare due to the amount of traffic from these limited IP addresses.
Therefore, it is recommended that you use the Cloudflare CDN, which provides the following benefits:
- You remove an additional hop between vendor data centers, thus reducing latency for your users.
- You perform DDoS filtering in the first point of contact from the Internet, which is a recommended best practice.
Note that, if you are using a third-party CDN in front of Cloudflare and Cloudflare mitigates a DDoS attack, you will still pay your first-hop CDN provider for the attack traffic that they processed before it was mitigated by Cloudflare.
If you are using the Akamai CDN in front of Cloudflare, it is recommended that you change the action and/or sensitivity level of the DDoS rule named HTTP requests with unusual HTTP headers or URI path (signature #1) with rule ID 0b1e17bd25c74e38834f19043486aee1:
- Change the rule’s action to Log (only available on Enterprise plans) to view the flagged traffic in the analytics dashboard.
- Alternatively, change the rule’s Sensitivity Level to Essentially Off to prevent the rule from being triggered.
For more information, refer to HTTP DDoS Attack Protection managed ruleset: Ruleset configuration.
Some Cloudflare Magic Transit customers operate Virtual Private Networks (VPN) so that their remote employees can connect securely to the organization’s services. Additionally, larger organizations have Network Addressing Translation (NAT) systems that manage connections in and out of their network.
Cloudflare Magic Transit customers may also use third-party services such as Zoom, Webex, Microsoft Teams, and others for their internal organization communication. Because traffic to Cloudflare will be originating from a limited set of IP addresses belonging to these third-party services, it may appear as if the services are launching a DDoS attack against Cloudflare due to the amount of traffic from limited IP addresses.
Additionally, since this traffic may also be targeting a limited set of destinations (for example, the same designated service ports, VPN endpoints, or NAT IP addresses), it may appear as if the CDN is launching a DDoS attack against Cloudflare due to the amount of traffic from a limited set of IPs to a limited set of IPs.
If your organization uses VPNs, NATs, or third-party services at high rates of over 100 Mbps, it is recommended that you one of the following:
-
Change the Sensitivity Level of the relevant rules to a lower level. Changing the level to Essentially Off will prevent the rules from being triggered. Refer to HTTP DDoS Attack Protection managed ruleset and Network-layer DDoS Attack Protection managed ruleset for more information on the available adjustments per ruleset and how to perform them.
-
Exclude the desired traffic from the Managed DDoS rule using expression filters. You can exclude a combination of source ports, source IP addresses, destination ports, destination IP addresses, and protocol. For more information, refer to Configure Network-layer DDoS Attack Protection via API.
If you are on an Enterprise plan, you can change a rule’s action to Log to view the flagged traffic in the analytics dashboard. After gathering this information, you can later define rule adjustments as previously described.