Recently, a friend complained to me that after their business on the high defense CDN, the security protection effect is up, but the rate of false blocking is also ridiculously high, not moving to the normal user to stop outside. I laughed after listening to this problem I encountered three years ago, when the customer was almost scolded to doubt life.
To be honest, many high-defense CDN service providers on the market now, simply do not take the “false block rate” as the core indicators to deal with. They are more willing to brag about how strong their protection ability, how many nodes, cleaning ability, but the actual use, the probability of a normal request to be intercepted than the probability of being attacked is higher. This is like you installed a security door, the result is that your own family is locked out every day.
I have tested a number of services, including CDN5, CDN07 and 08Host, and found that behind the high blocking rate is actually the result of a series of problems. For example, the rule base is outdated, behavioral analysis model is rough, and even some service providers in order to save trouble directly across the board - a certain IP segment a little bit abnormal traffic, the entire segment to you blocked. This kind of rough practice, in today's era of refined operation, is simply joking.
A really good intelligent recognition rule should be like an old hunter hunting, which can accurately aim at the target without accidentally injuring the surrounding vegetation. It must be able to distinguish between “malicious attacks” and “normal business peaks”, identify “crawler behavior” and “sudden operations of human users”, and even adapt to the traffic characteristics of different industries and scenarios. "It even has to be able to adapt to the traffic characteristics of different industries and scenarios.
First of all, I would like to say the most common misunderstanding: many teams come up with a crazy pile of rules, hate all the WAF rules, IP blacklist, CC protection strategy open, the result is that the normal request is also beaten up. I have seen an e-commerce station, because the CC protection is too strict, during the promotion of one-third of the order request was misjudged as an attack, heavy losses.
In fact, the key to reducing the false-blocking rate does not lie in the number of rules, but in the quality and intelligence of the rules. For example, CDN5 has done a more detailed job in this area. Instead of relying solely on frequency thresholds to judge, they combine multi-dimensional information such as JA3 fingerprints, TCP window sizes, and traffic timing characteristics to do behavioral modeling. In this way, even if an IP has a large number of requests in a short period of time, it will not be easily blocked as long as other characteristics are normal.
Another thing worth mentioning is 08Host's “Learning Mode”. They allow customers to open a period of observation, so that the system can learn the normal traffic pattern, and then gradually enable the protection rules. This feature is especially suitable for projects with special business traffic patterns, such as game servers, API interface services and so on. Several of my own projects have used this approach to suppress the false positive rate to below 0.5%.
Of course, it's not enough to rely on the default rules provided by your service provider. You have to make customized adjustments according to your business characteristics. For example, if you are doing international business, then you have to pay special attention to avoid blocking overseas IPs by mistake; if your users are mainly concentrated on mobile, then you have to focus on the fluctuation of the operator's IP pool.
I usually recommend the team to deploy a set of traffic log analysis system in the background to record all the blocked requests and do backtracking analysis on a regular basis. Very often you will find that certain false blocking is actually regular - for example, users in a certain region always trigger the rules, or a certain API interface is easy to be ruled anomalous because of its special design.
For example, we have a client APP before, every upgrade will focus on a batch of requests, the traditional frequency-based protection rules are very easy to beat this wave of traffic into an attack. Later we configured the following rules on CDN07:
Such a simple combination of rules solves our 90% misblocking problem. Note that we didn't directly use the frequency limit here, but combined it with the threat score and User-Agent characteristics to make a judgment, which not only ensures the security, but also avoids false kills.
Going a little deeper, the core of intelligent rule recognition is “dynamic adjustment”. A good protection system should be able to learn traffic patterns in real time and automatically relax or tighten rules. For example, CDN5's algorithm can automatically adjust the threshold during peak business hours, rather than sticking to a fixed value.
There are also some scenarios that require special care, such as video streaming, file uploads, WebSocket long connections and such businesses, whose traffic patterns are inherently different from ordinary HTTP requests. If you directly use the default rules to protect, the probability will be overturned. I usually configure a separate protection policy for this type of business, or even a separate subdomain to avoid interference.
Speaking of which have to spit a word, these days even CDN have to “defense teammates”. Some service providers in order to show their own protection effect looks good, deliberately adjust the rules to be particularly sensitive, anyway, mistakenly blocked the user is not necessarily found. This mentality is really harmful. So when you choose a service provider, you must see whether they provide detailed interception logs and analysis tools, or how you die do not know.
Finally share a combat data: we have a daily PV ten million projects, in the optimization of the false seal rate as high as 7%, after three weeks of rule tuning and strategy customization, and ultimately the false seal rate to 0.3% below. This does not use any black technology, is to honestly analyze the logs, adjust the rules, AB test and then iterate. The specific optimized configuration fragments are as follows:
Of course, each business situation is different, this set of configurations may not be suitable for you, but the idea is the same: refine the scene, combined with business, dynamic adjustment. Do not believe those who claim that “a key to protect” publicity, security this matter is never a silver bullet.
Overall, reducing the false positive rate is an engineering task that requires continuous investment. It tests both the technical strength of the service provider, but also the degree of care of the operation and maintenance team. Now I am most afraid to hear someone say “we on the high-defense CDN on the security”, in fact, on the only the beginning, the back of the optimization is the main event.
If you are suffering from the headache of misblocking, it is recommended to start with log analysis to sort out the characteristics of misblocked requests before adjusting the rules in a targeted manner. Remember, a good protection strategy should be like a surgical knife, accurately removing threats while preserving the maximum amount of healthy tissue. That kind of broad-brush, one-size-fits-all program should have been eliminated long ago.
After all, it's hard enough to do business these days, don't let security become the last straw that crushes the user experience.
