Preface
Among the many free features provided by CF, besides WAF, the DDoS protection feature is the most practical. In fact, from certain perspectives, DDoS protection is the most practical of the free features provided by CF (mainly for those in China who suffer from DDoS attacks consuming their purchased cloud provider CDN traffic; webmasters using static sites hosted on foreign free clouds can ignore this~).
Therefore, following the WAF, I will introduce the DDoS protection feature as the second standalone topic. However, before that, we need to clarify what a DDoS attack actually is.
Introduction to DDoS Attacks
What is a DoS Attack?
Before formally introducing DDoS attacks, we must first understand what a DoS attack is.
A DoS (Denial of Service) attack is a network attack method that exhausts the resources of the target system, making it unable to provide services normally. DoS attacks are typically initiated from a single source.
Characteristics of DoS Attacks
- Single Attack Source: DoS attacks usually originate from a single source or a single computer, rather than multiple distributed sources.
- Relatively Easy to Detect: Since the attack traffic comes from a single source, it is relatively easy to detect and defend against.
- Limited Attack Intensity: The attack capability of a single source is limited and usually cannot reach the scale and destructive power of a DDoS attack.
Common Types of DoS Attacks
• Slowloris: The attacker maintains a large number of incomplete HTTP request connections, consuming the Web server's resources and making it unable to process other requests.
• RUDY (R-U-Dead-Yet): Similar to Slowloris, but using HTTP POST requests. The attacker sends a large number of POST requests and keeps the connections open, gradually exhausting the target server's resources.
• HOIC (High Orbit Ion Cannon): Primarily utilizes the target server's resources by sending a large number of HTTP GET requests. Although HOIC is not strictly a slow attack, it can achieve a similar effect by sending a massive volume of requests.
• Slow Read: The attacker sends a slow HTTP request and then reads the data slowly when the server responds, causing the server to keep the connection open for a long time and consume resources.
• Slow POST: The attacker sends a slow POST request, keeping the server connected during the response and gradually exhausting server resources. The volume of data sent by the attacker is large, but the request and response process is very slow.
Overall, DoS is like a general single-target weapon (such as a revolver), not a weapon of mass destruction, so it lacks area-of-effect damage capabilities, and its direct lethality is not strong. Therefore, it usually takes a technical route, targeting applications with specific attacks (such as Slowloris, RUDY, HOIC, Slow Read, Slow POST, etc.), which offers high stealth and a certain level of destructiveness.
Note: In fact, flood attacks originally fell under the category of DoS. However, with server performance becoming increasingly powerful and network bandwidth growing larger, the flooding capability of a single DoS source is far from sufficient and can easily be targeted and blocked by security policies, so it is rarely used nowadays.
What is a DDoS Attack?
A DDoS (Distributed Denial of Service) attack is an attack launched through a large number of computers or devices distributed in different locations, aimed at making the target system, service, or network unable to function normally. Unlike traditional DoS attacks, DDoS attacks utilize multiple attack sources, increasing the scale and complexity of the attack, making defense much more difficult and complex.
Main Characteristics of DDoS Attacks:
- Distributed Sources: Attack traffic comes from multiple different computers or devices, typically a controlled botnet.
- Large-Scale Attacks: Due to the wide distribution of attack sources, the attack traffic is usually massive, capable of quickly exhausting the target's bandwidth and resources.
- Difficult to Defend Against: Because the attack sources are dispersed, a single defense measure is difficult to effectively stop the attack, requiring a combination of multiple protection methods.
Common Types of DDoS Attacks:
- Flood Attacks:
• SYN Flood: Sends a large number of TCP SYN requests, exhausting the connection resources of the target server.
• UDP Flood: Sends a large volume of UDP packets, exhausting the network bandwidth and resources of the target server.
• ICMP Flood: Sends a large number of ICMP Echo requests, exhausting the target's bandwidth and processing capacity. - Resource Exhaustion Attacks:
• DNS Amplification Attack: Exploits the response amplification characteristics of DNS servers by sending spoofed requests to amplify response traffic, attacking the target's DNS server.
• NTP Amplification Attack: Leverages the response amplification characteristics of NTP servers to send forged requests, amplifying response traffic and attacking the target's network bandwidth. - Application Layer Attack:
• HTTP Flood: Sends a large number of HTTP requests to exhaust the processing capacity of the Web server, resulting in service unavailability.
• Slowloris: The attacker maintains a large number of incomplete HTTP request connections, consuming the Web server's resources and making it unable to process other requests.
• RUDY (R-U-Dead-Yet): Similar to Slowloris, but using HTTP POST requests. The attacker sends a large number of POST requests and keeps the connections open, gradually exhausting the target server's resources.
• HOIC (High Orbit Ion Cannon): Primarily utilizes the target server's resources by sending a large number of HTTP GET requests. Although HOIC is not strictly a slow attack, it can achieve a similar effect by sending a massive volume of requests.
• Slow Read: The attacker sends a slow HTTP request and then reads the data slowly when the server responds, causing the server to keep the connection open for a long time and consume resources.
• Slow POST: The attacker sends a slow POST request, keeping the server connected during the response and gradually exhausting server resources. The volume of data sent by the attacker is large, but the request and response process is very slow.
Compared to DoS, there are no restrictions on the types of attacks available for DDoS. In addition to the slow attacks commonly used in DoS, flood attacks are the representative attack method of DDoS. If DoS denial of service relies on slow attacks (exploiting vulnerabilities in TCP and HTTP protocols) to exhaust user application resources, which still has some technical content, DDoS denial of service directly uses flood attacks to exhaust the bandwidth resources of the user's network egress, as well as system resources such as the CPU and memory of the application server. It can be described as simple and brutal, with absolutely no technical content to speak of.
How Destructive is a DDoS Attack?
If the scale of the DDoS attack is not too large and mainly uses application layer attacks to consume application resources, then it can only be considered an enhanced version of a DoS attack. The threat is not too great, and it can still be defended against using reasonable security policies through security devices.
The most terrifying is large-scale DDoS attacks, which can directly and completely submerge the egress bandwidth of traditional "point-based" deployed architectures (such as self-built data centers). How large can the so-called large-scale be? Take the attack I personally encountered as an example.
Total attack traffic of 2.13T, peak bandwidth of 541.75G:

Total number of requests of 651 million, peak RPS (Requests Per Second) of 171 million:

Attacks originated from multiple countries:

Just ask, how many traditional "point-based" deployed architectures can withstand an attack of this scale?
How to Protect Against DDoS Attacks?
I won't expand on this question, otherwise, explaining each of the various attack methods one by one could fill a book (the anti-DDoS products sold in the past had manuals on the principles of each attack and protection configurations that were dozens of megabytes in size; I will have the opportunity to cover this in a dedicated security series in the future). Simply put, they can be divided into two categories: application resource consumption and bandwidth consumption.
Application resource consumption: Mainly dominated by application layer attacks, such as Slowloris, Slow Read, and Slow POST, plus some flood attacks targeting application resources: SYN Flood and HTTP Flood.
Bandwidth consumption: Mainly dominated by flood attacks, such as UDP Flood, ICMP Flood, DNS amplification attacks, and NTP amplification attacks.
Note: Although SYN Flood and HTTP Flood are classified as application resource consumption, they can still achieve the effect of bandwidth consumption in large-scale scenarios. For example, the attack I encountered earlier was actually of the HTTP Flood type.
Protection against application resource consumption attacks mainly relies on application firewalls, which in Cloudflare (CF) is the job of the WAF. Of course, relevant configuration optimizations can also be made on the application server side, such as enabling SYN Cookies, limiting the number of half-open connections, shortening connection timeout periods, or using load balancing equipment to distribute access requests across multiple servers and limit the number of connections per server.
As for protection against bandwidth consumption attacks, relying solely on "point-based" protection is not enough. Generally, the following options are available:
- Establish redundant backups for the site (such as disaster recovery data centers, active-active, or multi-active data centers). This can greatly increase application throughput, and if the bandwidth of a certain node is exhausted, requests can be quickly redirected to other nodes by modifying DNS resolution results. However, this method can only be used by large organizations.
- "Wrap" the application with a CDN. Due to the working mechanism of CDNs, visiting users resolve to multiple IPs instead of a single IP (achieving the effect of hiding the origin server IP), so access requests are also distributed to multiple IPs. Additionally, since the CDN caches application content and can respond directly, if an attack is encountered, the actual access traffic that ultimately reaches the origin server is greatly reduced, thereby failing to achieve the purpose of submerging the origin server's bandwidth (provided that the origin server IP is not exposed).
- External traffic scrubbing protects the origin network and applications from attacks by using various technologies (such as BGP routing, DNS redirection, API calls, etc.) to divert suspicious traffic to specialized equipment for processing before it reaches the origin network egress when an attack occurs, filtering out malicious traffic and only forwarding legitimate traffic back to the target server. This is generally provided by broadband providers (or cloud providers if the application is deployed in a cloud environment) or professional security vendors.
In addition to the first point, there are corresponding domestic solutions for both CDN and external traffic scrubbing. However, CDN traffic has to be purchased (plus some methods have pitfalls), and DDoS protection costs extra money (and is extremely expensive). As a result, individual webmasters are constantly living in fear, deeply afraid of being bankrupted (or disconnected) by a DDoS attack if they are not careful. This is also one of the most important reasons why I resolutely turned to CF at the beginning of the year: free CDN, free basic DDoS protection, and free basic WAF features have completely relieved me of worrying about DDoS attacks (whether they are application resource-consuming or bandwidth-consuming).
Note: Since the WAF feature of the Free plan only provides a basic rule set, it actually cannot prevent many application resource-consuming attacks. However, because my "home data center" also has an internal WAF, under the dual protection of this "heterogeneous" structure, I feel relatively safe. Of course, the main reason is that the traffic is small~~.
Configuration of CF DDoS Protection
Although I have laid down so much basic knowledge as a foundation, in reality, CF's DDoS-related configuration is very simple. You can complete the basic protection by following the steps below. Of course, the prerequisite is that you have already hosted your domain on CF and have completed building your website using an appropriate method (for the choice of website building methods, please refer to the article: ).
Configure website security level:

Note: There is a special option in the security level calledI'm Under Attack!

When the website is under attack and normal access is severely affected, you can set the security level to this mode. Once set, JS challenge will be enabled for all requests accessing the website (including normal access and attack traffic). Only requests that pass the JS challenge will be allowed to access the website content. Although this will affect the experience of normal users visiting the website, it guarantees the interception of the vast majority of abnormal access, making it one of the last resorts when a website is under attack.
This mode can also be quickly enabled on CF's Overview page:

If the website is built using WordPress, it can also be enabled directly in the Cloudflare plugin without logging into the Cloudflare website:

Deploy DDoS overrides:


Note: The CF HTTP DDoS Attack Protection ruleset is a set of pre-configured rules used to match known DDoS attack vectors at Layer 7 (application layer, mainly HTTP) of CF's global network. These rules match known attack patterns and tools, suspicious patterns, protocol violations, requests causing high rates of origin errors, excessive traffic hitting the origin/cache, and other attack vectors at the application layer. CF regularly updates the list of rules in the ruleset.
Blocked attacks can be viewed in "Security" - "Events", and the log format is as follows:

Bots:

Rate limiting:


After completing the above configurations, "normal" scale DDoS attacks can already be ignored. Combined with the correct configuration of WAF (refer to the article:Home Data Center Series Cloudflare Tutorial (4) CF WAF Features and Detailed Configuration Tutorial), security is no longer a concern for individual webmasters.
Note: Why say that "normal" scale DDoS attacks can be ignored?
Because although CF's DDoS protection is powerful and can block 99% of attack traffic (or requests), if the scale is too large, even the remaining 1% of attack traffic (or requests) is enough to overwhelm the applications of average individual webmasters. Taking the peak instantaneous bandwidth of 541.75G and 171 million RPS (requests per second) mentioned earlier in my article as an example, an instantaneous bandwidth of 5.41G and 1.71 million RPS, if they enter the intranet, are enough to crash conventional applications. Therefore, to defend against large-scale DDoS attacks, relying solely on CF is not enough; it must rely on further traffic control and shaping within the intranet, such as further IP-based access rate limiting combined with features like the maximum connection limit of load balancing equipment.
Interested readers can refer to my three previous real-time records written when under attack, as well as the article on how to adjust the internal architecture of the home data center to cope with large-scale attacks:Home Data Center Series: Tragically Deflowered! Recording the blog's first DDoS attack、Home Data Center Series: Second Attack! Optimization of the internal blog access workflow under the new situation、Home Data Center Series: Stress test successfully completed! Thanks for the help, bro, we're good to go!, and the detailed topology of the home data center can be found in the article:Home Data Center Series: Home Data Center IPv4/IPv6 Dual-Stack Network Architecture and Application Access Flow Optimization。
Summary
CF's DDoS protection's greatest advantages over other competitors include the following aspects:
- Massive Global Network Infrastructure: CF has a global edge network spanning more than 200 cities. This allows it to distribute traffic across multiple geographic locations, quickly respond to and mitigate DDoS attacks, and provide lower latency and higher availability.
Note: This advantage is the biggest advantage. No other vendor can spread their backbone network globally. This means that while it might be a 100G attack traffic for other vendors, for CF, it might just be a drizzle of 1G traffic per node across 100 nodes. How can they compete? - Intelligent Threat Detection and Automated Response: CF utilizes advanced machine learning and AI technologies to analyze and detect abnormal behaviors and attack patterns in traffic in real time. Its automated system can quickly identify and respond to DDoS attacks without manual intervention, thereby shortening response times and improving protection efficiency.
Note: CF's real-time analysis and detection technologies are indeed impressive. How many malicious crawlers has the "5-second shield" been a nightmare for? - Integrated Multi-Layer Protection: In addition to DDoS protection, CF also provides multi-layer protection such as WAF, CDN, and SSL/TLS encryption. This comprehensive protection strategy can comprehensively improve the security of websites and applications. It is precisely because it independently provides multi-layer protection that it can respond quickly when an attack is encountered at any level.
- No Extra Hardware or Software Required: CF's DDoS protection service is based on its cloud platform. Users do not need to purchase or install additional hardware or software. They only need to adopt a suitable origin-pull method (via public network or Tunnel, see the article for details:Home Data Center Series Cloudflare Tutorial (Part 3): How to Enter CF's Edge Network and How to Choose a Suitable Origin Pull Method) to connect the application to CF's network to enjoy comprehensive DDoS protection. This simplifies the deployment and maintenance process and lowers the barrier to entry.
- Transparent Pricing and High Cost-Effectiveness: CF provides a transparent pricing strategy and offers basic yet practical protection services (WAF and DDoS protection) in its Free plan at no extra cost. This gives its services a significant advantage in terms of cost-effectiveness, making it especially suitable for small and medium-sized enterprises and individual users, earning it the nickname "The Great Philanthropist" in the community.
- Full-Traffic Protection: CF's DDoS protection is not limited to HTTP/HTTPS traffic, but also includes traffic of various protocols such as DNS, TCP, and UDP. This comprehensive protection capability ensures that all types of attacks can be effectively countered.
- Large-Scale Real-Time Data Sharing and Cooperation: CF cooperates with multiple security organizations and enterprises worldwide to share real-time threat intelligence and attack data. This cooperation and data sharing enable CF to identify and respond to emerging threats faster, improving overall protection capabilities.
Compared to the domestic model where CDN traffic must be purchased and DDoS services are paid for separately, the DDoS protection provided by CF can truly be called a "godsend" for individual webmasters.
Note: Here is a price list of "High-Defense CDN" found by casually searching for DDoS protection prices on Google:

According to this charging standard, how much would I have to pay to defend against the 2.13T traffic I suffered?? I instantly feel like I've saved tens of thousands, don't you think!
Daily reading self-correction: In DDoS protection, ‘Network-layer and SSL/TLS DDoS attack protection‘ is now enabled by default and does not need to be configured. Then in the rules column, the 'cr' security setting is gone, several have been changed, and a few betas have been added. I feel the newly added betas should be very strong, but I don't quite understand them 0.0. Well, but I still set up a protection rule following it, so I guess I'm not too bad 0.0(●ˇ∀ˇ●)
Cloudflare's GUI interface changes frequently, and I'm too lazy to track it. Now Cloudflare has been promoting its new dashboard interface for ”Security” features, which is very different from when I wrote the article. However, the core principles remain the same; once you understand the configuration logic, it doesn't matter how it changes.
If it's just for personal use, I suggest using a VPN.
It's a personal blog, so of course, it's for everyone to use together.
Recently, I saw a DDoS traffic scrubbing solution based on CF front-end + load balancing + home broadband. When entering the defense state, CF is used to block 99% of the attacks, and then the traffic is load-balanced to home broadband nodes located in multiple provinces and cities. A major characteristic of home broadband is high downlink and low uplink, which perfectly fits the state of DDoS traffic scrubbing. Use home broadband to piece together a scrubbing traffic ingress with a load of over 100G. Combined with the CF in front, it is roughly equivalent to achieving more than 10T of protection. However, the final latency is really high, making it only suitable for HTTP applications.
This approach doesn't seem to make much sense. First of all, CF has already blocked 99% of it, and the remaining 1% is actually not very lethal (unless the scale of the attack is truly massive, but no matter how big, could it be bigger than what I've encountered? I'm quite skeptical). A typical DDoS attack (taking the common HTTP flood as an example) can simultaneously result in both application resource consumption and bandwidth consumption. After the bandwidth consumption is processed by both CDN and rate limiting, it is no longer a threat. The remaining key is no longer the attack bandwidth but the control of the RPS request count. At this point, as long as the origin server locally uses traffic shaping (local rate limiting and maximum connection control) to handle the traffic, it will no longer cause any harm (as mentioned in the article, I have verified that a peak attack bandwidth of 541G per second and 171 million requests per second couldn't make even a ripple).
As for home broadband nodes in multiple provinces and cities, this deployment is simple, but this method is troublesome and feels like half the result with twice the effort, unless multiple nodes are used for load balancing during normal times (otherwise, do you start them only when needed?). But for individual users, when the performance of a single node is completely sufficient during normal times, using multiple nodes doesn't make much sense, and it also costs more electricity or money~, unless it is combined with an attack detection mechanism: when an attack is detected, use APIs or scripts to remotely start multiple nodes to share the traffic, and close redundant nodes when there is no attack. But this requires extra hassle (and actually, how much traffic can it share? The traffic entering the internal network is usually only a few hundred megabytes, which is a piece of cake given that gigabit home broadband is everywhere now. Moreover, I suspect the real purpose of multiple nodes is not to share bandwidth, but to share the number of requests. After all, the connections generated by the number of requests are the main culprit that easily freezes the application, but sharing the number of requests only requires running a local load balancer). Currently, I only have redundant nodes on the cloud host automatically enable and take over when there is a power outage or network disconnection at home.
You'd probably need to buy a house in every province to get this effect.