Recently, there are always buddies ask me, high defense CDN is not really able to prevent CC attacks? This is a good question, but the answer is not so simple. I've seen too many people think that buying a high defense package will be all right, the results of the CC attack penetrated after the face of confusion. Today, let's talk about this matter.
A CC attack is, frankly speaking, a simulation of a massive number of normal requests, exhausting your server resources. It is not like DDoS directly rushing bandwidth, but a slow knife to cut meat, specializing in screwing up the CPU, database connections and these weak links. I have suffered losses in the early years, when I thought the firewall rules hard enough on the line, the results of the other side with low-frequency slow request + random Referer easily bypass the rule base - these days, even the CDN have to ‘defense teammates', after all, some attack traffic looks more than a real person! also like a real person.
Why can't ordinary CDNs handle it? The fundamental reason is that the static caching strategy fails. CC attacks often target dynamic interfaces, such as the login page, search interface, API gateway, these paths are basically unable to cache. Last year to help me do an e-commerce station emergency, found that the attackers specifically focus on the product comment loading interface to play, 3000 requests per second are all with a random SessionID “legitimate users”, the traditional WAF can not distinguish between the enemy and me.
The core value of high-defense CDN is here: it's not just piling up bandwidth, but relying on behavioral analysis + frequency constraints to do intelligent interception. Take CDN5 for example, their fingerprint tracking algorithm is really something - I found that the same IP even if the frequent replacement of UserAgent, as long as the TCP fingerprints and TLS handshake characteristics are the same, the system can still be associated with the same attack subject.
The real practical configuration has to be combined with the business characteristics. For example, for API interface protection, I generally recommend doing this:
Of course pure Nginx rules aren't enough. Nowadays, advanced attacks are colored by machine learning - the other side will use reinforcement learning to adjust the request interval, so that you think it is the user browsing the page. This time it is necessary to rely on the CDN global intelligence network. 08Host in this piece to do more ruthless, they real-time sharing of attack characteristics of the whole network: as long as any node identified a new CC mode, within 15 minutes all the edge nodes automatically update the detection rules.
I am most annoyed that some people blow “unlimited defense”. Really encountered advanced CC attacks, just rely on hardware to carry is looking for death. Last year, a customer used a certain CDN called T-level protection, the results were CC penetration of the database. Later found that the problem in the architecture - the attacker bypassed the CDN to directly resolve the source station IP, 20,000 login requests per second directly to the MySQL connection pool full. So don't believe in the ghost of “one key protection”, the source station hiding, port filtering, database connection pool to limit the flow of these basic skills are not in place, buy more expensive CDN is also useless.
In practice, you also have to pay attention to the false positive rate. Some CDN vendors in order to data look good directly across the board, normal users are popping CAPTCHA. Good protection should be like an old Chinese doctor's pulse - have to distinguish between search behavior and malicious brush interface. I usually put a bucket first to sample a week's traffic, and statistically determine the baseline access frequency of each URL. For example, the user details page of the normal access peak is 50 times per second, suddenly rushed to 2000 times certainly have a problem, but if the big promotion during the product list page ran to 3000 times / second, this may be normal traffic.
Finally, a lesson in tears: high defense CDN is not a silver bullet. Once there was a financial site by the CC attack, the attacker each request with real stolen cookies, look and normal session exactly the same. At this point the frequency analysis alone is useless, the last is to rely on business rules to stop the loss - such as the same user failed to log in more than 3 times in 5 minutes to force the lock, or verify the balance of the inquiry interface must go to the MFA verification. So the real protection is a three-dimensional war, CDN is only the first line of defense.
Now back to the beginning of the question: high defense CDN can prevent CC? Yes, but it depends on how it is used. Pick vendors focus on three points: the frequency of updates to the intelligent fingerprint library, the granularity of customization rules, and whether the source station to hide thoroughly.CDN5 deep learning model of slow CC recognition rate can reach 92%, but the price is high; CDN07 API protection template out of the box, suitable for small and medium-sized projects; 08Host's low latency of the global Anycast network for cross-border e-commerce. In the end, there is no best CDN, only the most appropriate architecture design.
The real masters are doing defense in depth. My current program is usually: CDN front to do traffic cleaning ¡ú middle layer with OpenResty to do business logic flow limiting ¡ú source station kernel tuning TCP connection parameters. These three layers of sieve down, can rush to the database of malicious requests less than 0.1%. Remember ah, security is a systematic project, do not expect a single product can give you the bottom.
