Contents
Preface
Among the many functions provided by CF for free, in addition to WAF, the DDoS protection function is the most practical. In fact, from some perspectives, DDoS protection is the most practical function provided by CF for free (mainly for those friends in China who are suffering from DDos attacks that consume the CDN traffic purchased from cloud suppliers. Website owners who use static sites and host them on free foreign clouds please ignore this).
Therefore, after WAF, I will talk about DDoS protection as the second function separately. However, before that, we need to understand what DDoS attacks are.
Introduction to DDoS Attacks
What is a DOS attack?
Before formally introducing DDoS attacks, we must first understand what DOS attacks are.
A DoS (Denial of Service) attack is a network attack that exhausts the resources of a target system, making it unable to provide services normally. DoS attacks are usually initiated from a single source.
Characteristics of DoS attacks
- Single attack source: DoS attacks usually come 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 power: 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 resources of the web server and making it unable to process other requests.
• RUDY (RU-Dead-Yet): Similar to Slowloris, but uses HTTP POST requests. The attacker sends a large number of POST requests, keeping the connection open and gradually consuming the target server's resources.
• HOIC (High Orbit Ion Cannon): Mainly by sending a large number of HTTP GET requests to exploit the resources of the target server. Although HOIC is not exactly a slow attack, it can achieve a similar effect by sending a large number of requests.
• Slow Read: The attacker sends a slow HTTP request and then slowly reads the data when the server responds, causing the server to maintain the connection for a long time and consume resources.
• Slow POST: The attacker sends a slow POST request to keep the server connected while responding, gradually exhausting the server resources. The amount of data sent by the attacker is large, but the request and response process is slow.
Generally speaking, DoS is like a general single weapon (such as a revolver), not a weapon of mass destruction, so it does not have coverage and killing capabilities, and its direct killing power is not strong. Therefore, it generally takes a technical route and carries out targeted attacks on applications (slowloris, RUDY, HOIC, Slow Read, Slow POST, etc.), which is highly concealed and has certain killing power.
In addition: In fact, flooding attacks are also a type of DoS. However, with the increasing performance of servers and the increasing network bandwidth, the flooding capability caused by a single source of DoS is far from enough and can be easily blocked by security policies. Therefore, it is basically not adopted.
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, aiming to make the target system, service or network unable to work properly. Unlike traditional DoS attacks, DDoS attacks utilize multiple attack sources, increasing the scale and complexity of the attack, making defense more difficult and complex.
The main characteristics of DDoS attacks:
- Distributed sources:The attack traffic comes from multiple different computers or devices, usually a controlled botnet.
- Large-scale attacks: Due to the wide distribution of attack sources, the attack traffic is usually very large and can quickly exhaust the target's bandwidth and resources.
- Hard to defend: Since the attack sources are dispersed, a single defense measure is difficult to effectively prevent the attack, and a combination of multiple protection measures is needed.
Common types of DDoS attacks:
- Flood Attack:
• SYN Flood: Send a large number of TCP SYN requests to exhaust the connection resources of the target server.
• UDP Flood: Send a large number of UDP packets to exhaust the target server's network bandwidth and resources.
• ICMP Flood: Send a large number of ICMP Echo requests to exhaust the target's bandwidth and processing power. - Resource Exhaustion Attack:
• DNS Amplification Attacks: Take advantage of the response amplification feature of the DNS server, send forged requests, amplify the response traffic, and attack the target DNS server.
• NTP Amplification Attack: Exploit the response amplification feature of the NTP server, send forged requests, amplify the response traffic, and attack the target's network bandwidth. - Application Layer Attack:
• HTTP Flood: Sending a large number of HTTP requests exhausts the processing capacity of the Web server and causes service unavailability.
• Slowloris: The attacker maintains a large number of incomplete HTTP request connections, consuming the resources of the web server and making it unable to process other requests.
• RUDY (RU-Dead-Yet): Similar to Slowloris, but uses HTTP POST requests. The attacker sends a large number of POST requests, keeping the connection open and gradually consuming the target server's resources.
• HOIC (High Orbit Ion Cannon): Mainly by sending a large number of HTTP GET requests to exploit the resources of the target server. Although HOIC is not exactly a slow attack, it can achieve a similar effect by sending a large number of requests.
• Slow Read: The attacker sends a slow HTTP request and then slowly reads the data when the server responds, causing the server to maintain the connection for a long time and consume resources.
• Slow POST: The attacker sends a slow POST request to keep the server connected while responding, gradually exhausting the server resources. The amount of data sent by the attacker is large, but the request and response process is slow.
Compared with DoS, DDoS has no restrictions on the attack types that can be selected. In addition to the slow attack types commonly used by DoS, flood attacks are the representative attack methods of DDoS. If DoS denial of service relies on slow attacks (using loopholes in TCP and http protocols) to consume user application resources, which is a bit technical, DDoS denial of service directly uses flood attacks to consume user network export bandwidth resources, application server CPU, memory and other system resources. It can be said to be simple and crude, and there is no technical content at all.
How destructive is a DDoS attack?
If the scale of a DDoS attack is not too large, and it 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 protected by using security devices and reasonable security strategies.
The most terrifying thing is a large-scale DDoS attack, which can completely overwhelm the egress bandwidth of a traditional "point" deployment architecture (such as a self-built data center). How large can the so-called large-scale attack be? Take the attack I encountered as an example.
Total attack traffic is 2.13T, and peak bandwidth is 541.75G:
The total number of requests was 651 million, and the peak RPS (requests per second) was 171 million:
The attacks originated from multiple countries:
Just ask, how many traditional "point" deployment architectures can withstand attacks of this scale?
How to protect against DDoS attacks?
I won't elaborate on this question, otherwise we could write a book to explain all the various attack methods one by one (the anti-D products we sold before had manuals of dozens of megabytes each introducing the principles of each attack and the protection configuration. I'll have the opportunity to talk about this in a special security series of articles in the future). In short, they can be divided into two categories: application resource consumption and bandwidth consumption.
Application resource consumption type: mainly application layer attacks, such as Slowloris, Slow Read, Slow POST, plus some flood attacks targeting application resources: SYN Flood, HTTP Flood.
Bandwidth consumption type: mainly flood attacks, such as UDP Flood, ICMP Flood, DNS amplification attack, and NTP amplification attack.
Note: Although SYN Flood and HTTP Flood are classified as application resource consumption types, they can also have the effect of bandwidth consumption when they are large-scale. For example, the attack I encountered earlier was actually of the HTTP Flood type.
The protection against application resource consumption attacks mainly relies on application firewalls, which is the work of WAF in CF. Of course, the application server can also be optimized for related configurations, such as enabling SYN Cookies, limiting the number of half-open connections, shortening the connection timeout, or using load balancing devices to load access requests to multiple servers and limit the number of connections per server.
As for the protection against bandwidth-consuming attacks, it is not enough to rely solely on "point" protection. Generally, there are the following options:
- The site establishes redundant backups (such as disaster recovery data centers, active-active or multi-active data centers), which can greatly improve application throughput. If the bandwidth of a node is exhausted, the request can be quickly redirected to other nodes by modifying the domain name resolution results. However, this method can only be used by large organizations.
- By putting the application on CDN, due to the working mechanism of CDN, the access user is resolved to multiple IPs instead of a single IP (achieving the effect of hiding the source station IP), so the access request is also distributed to multiple IPs. In addition, the application content is cached on CDN and can respond directly. Therefore, if an attack occurs, the actual access traffic that finally reaches the source station is greatly reduced, and the purpose of flooding the source station bandwidth cannot be achieved (provided that the source station IP is not exposed).
- External traffic cleaning uses a variety of technologies (such as BGP routing, DNS redirection, API calls, etc.) to pull suspicious traffic to specialized equipment for processing before it reaches the source network exit when an attack occurs, filters malicious traffic and only re-delivers legitimate traffic back to the target server, thereby protecting the source network and applications from attacks. It is generally provided by broadband providers (if the application is deployed in a cloud environment, it is provided by a cloud provider) or a professional security provider.
In addition to the first point, there are corresponding solutions for CDN and external traffic cleaning in China. However, CDN traffic has to be purchased (plus some methods have pitfalls), and DDoS costs money separately (and it is very, very expensive). As a result, individual webmasters have to worry all the time, fearing that they will be bankrupted (or disconnected from the Internet) by DDos attacks if they are not careful. This is one of the most important reasons why I decided to switch to CF at the beginning of the year: free CDN, free basic DDoS protection, and free basic WAF functions, which directly made me no longer worry about DDoS attacks (whether they are application resource consumption or bandwidth consumption).
In addition: Since the WAF function of the Free plan only provides a basic rule set, it is actually unable to prevent many application resource consumption attacks. However, since there is also a WAF inside my "home data center", I am relatively assured under the dual protection of this "heterogeneous" structure. Of course, the most important thing is that the traffic is small.
Configuration of CF DDoS protection
In fact, although so much basic knowledge has been covered in the previous section, in fact, the DDoS-related configuration of CF is very simple. You can complete basic protection by following the steps below. Of course, the premise is that the domain name has been hosted on CF and the appropriate method has been selected to complete the website building (for the choice of website building method, please refer to the article:).
Configure website security level:
Note: There is a special option in the security level calledI'm Under Attack!
When a website is attacked and normal access is seriously affected, the security level can be set to this mode. After this setting, JS challenge will be enabled for all requests to access 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 accessing the website, it can ensure that most abnormal access is blocked. It is one of the last resorts when the website is attacked.
This mode can also be quickly enabled on the CF overview page:
If the website is built using WordPress, you can also enable it directly in the Cloudflare plug-in without logging into the Cloudflare website:
Deploy DDoS alternatives:
Note: The CF HTTP DDoS Attack Protection Rule Set is a set of pre-configured rules that match known DDoS attack vectors at Layer 7 (application layer, mainly HTTP) of the CF global network. These rules match known attack patterns and tools, suspicious patterns, protocol violations, requests that cause a large number of origin errors, excessive traffic hitting the origin/cache, and other attack vectors at the application layer. CF will periodically update the list of rules in the rule set.
Blocked attacks can be viewed in "Security" - "Events". The log format is as follows:
Automatic procedures:
Rate Limiting:
After completing the above configuration, the "normal" scale DDoS attack can be ignored. Combined with the correct configuration of WAF (see article:Home Data Center Series CloudFlare Tutorial (IV) CF WAF Function and Detailed Configuration Tutorial), for individual webmasters, security is no longer a problem to worry about.
Note: Why do we say that "normal" sized DDoS attacks are negligible?
Although CF's DDoS protection is powerful and can block 99% of attack traffic (or number of requests), if the scale is too large, even if only 1% of attack traffic (or number of requests) is left, it is enough to kill the application of an average personal webmaster. Taking the highest instantaneous bandwidth of 541.75G and 171 million RPS (requests per second) of the attack mentioned in the previous article as an example, 5.41G instantaneous bandwidth and 1.71 million RPS, if they enter the intranet, are enough to kill regular applications. Therefore, if you want to prevent large-scale DDoS attacks, CF alone is not enough. You must rely on further traffic control and shaping in the intranet, such as further IP-based access rate limiting and the maximum number of connections of the load balancing device.
Interested friends can refer to my previous three articles about real-time records of attacks and how to adjust the internal architecture of home data centers to cope with large-scale attacks:Home Data Center Series was tragically broken! Recording the first time a blogger was attacked by DDOS,Second attack on home data center series! Optimization of internal blog access process under the new situation,The home data center series stress test was successfully completed! Thanks to my brother for your help, it's now OK!, 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 Process Optimization.
Summarize
The biggest advantages of CF's DDoS protection over other competitors include the following aspects:
- Global large-scale network infrastructureCF has a global edge network covering more than 200 cities. This enables it to disperse 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 manufacturer can spread its backbone network all over the world. This results in 100G attack traffic for other manufacturers, but for CF, it may only be 100 nodes with 1G of drizzle traffic per node. How can this be compared? - Intelligent threat detection and automated response: CF uses 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 human intervention, thereby shortening response time and improving protection efficiency.
Note: CF's real-time analysis and detection technology is indeed impressive. How many malicious crawlers are plagued by the 5-second shield? - Integrated multi-layer protection: In addition to DDoS protection, CF also provides multi-layer protection such as WAF, CDN, SSL/TLS encryption, etc. This comprehensive protection strategy can comprehensively improve the security of websites and applications. It is precisely because of the independent provision of multi-layer protection that it can respond quickly when encountering attacks at any level.
- No additional hardware or software requiredCF'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 use a suitable back-to-source method (through the public network or tunnel. For details, see the article:Home Data Center Series CloudFlare Tutorial (Part 3) How to enter CF's edge network and how to choose the appropriate back-to-source method) You can enjoy comprehensive DDoS protection by connecting your application to the CF network. This simplifies the deployment and maintenance process and lowers the threshold for use.
- Transparent pricing and cost-effectivenessCF provides a transparent pricing strategy and provides basic but practical protection services (WAF and DDOS protection) in the Free plan without additional charge. This makes its services have a significant advantage in cost performance, especially suitable for small and medium-sized enterprises and individual users. People in the industry call it a great benefactor.
- Full flow protectionCF’s DDoS protection is not limited to HTTP/HTTPS traffic, but also includes traffic from multiple protocols such as DNS, TCP, UDP, etc. This comprehensive protection capability ensures that all types of attacks can be effectively dealt with.
- Real-time data sharing and collaboration at scale: CF works with multiple security organizations and companies around the world to share real-time threat intelligence and attack data. This collaboration and data sharing enables CF to identify and respond to emerging threats more quickly and improve overall protection capabilities.
Compared with the domestic model where you have to buy CDN traffic and pay for DDoS services separately, the DDoS protection provided by CF can really be called "good news" for individual webmasters.
Note: I just post the price of "High Defense CDN" found by searching DDoS protection prices on Google:
According to this charging standard, how much money do I need to pay to protect the 2.13T traffic I suffered? ? I instantly felt like I made tens of thousands of dollars!
If you are just using it yourself, I suggest you use a VPN
As for a personal blog, it is definitely for everyone to use together.
Recently, I saw a DDos traffic cleaning solution based on CF front-end + load balancing + home broadband. When entering the defense state, CF is used to block the attack of 99%, and the traffic is then load balanced to home broadband nodes located in multiple provinces and cities. A major feature of home broadband is that it has high downlink and low uplink, which is just suitable for the state of DDOS traffic cleaning. Use home broadband to create a cleaning traffic entrance with a load of over 100G. Adding the CF in front, it is equivalent to achieving more than 10T of protection. However, the final delay is really high and is only suitable for HTTP applications.
This method doesn't seem to make much sense. First, CF has blocked 99%, and the remaining 1% are not very lethal (unless the attack is really large, but no matter how large it is, can it be larger than what I have encountered? I still doubt it). General DDoS attacks (taking the commonly used http flood as an example) can produce the dual results of application resource consumption and bandwidth consumption at the same time. After the bandwidth consumption is processed by CDN and rate limiting, it is no longer a threat. The remaining key is not the attack bandwidth but the control of the number of RPS requests. At this time, as long as the source station uses traffic shaping (local speed limit and maximum connection number control) to handle the traffic locally, there will be no harm (as mentioned in the article, I have verified that the peak attack bandwidth of 541G per second and the number of requests per second of 171 million can't make any waves).
As for the home broadband nodes in multiple provinces and cities, the deployment is simple, but this method is troublesome and feels counterproductive, unless multiple nodes are used for load balancing under normal circumstances (otherwise, they will be used again when needed). However, for individual users, when the performance of a single node is sufficient, there is not much meaning in using multiple nodes, and it will also cost more electricity or money~, unless it is coordinated with the attack detection mechanism: when an attack is detected, multiple nodes are remotely started using API or scripts to share the traffic, and redundant nodes are shut down when there is no attack, but this requires trouble (how much traffic can it actually share? The traffic entering the internal is generally only a few hundred megabytes, which is actually a small matter with the current gigabit home broadband everywhere, and I suspect that 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 culprit that is most likely to jam the application, but sharing the number of requests actually only requires running a load balancing locally). Now, the redundant nodes on the cloud host will only be automatically enabled to take over when there is a power outage or network outage at home.
每个省买个房子才有这效果吧