Recently to help a few chess platform to do security reinforcement, found that this gang of CC attack grandson more and more refined. Do not hit your official website, do not touch the payment interface, specializing in staring at the game room and login interface to the dead brush. Last week, a customer called me at three o'clock in the morning, said that at the same time online on two hundred people, the server load directly soared to 90% - this is obviously the CC riding face output.
CC attacks in the chess industry have long since evolved to the "precision strike" stage. The attacker will first register an account to find out the business logic, which interface to create a room, which interface to verify the token, and even the heartbeat packet interval for you to calculate clearly. I've caught a few attack packets and found that they even simulate the rhythm of real user operations: first login, request a room list every 30 seconds, and then enter the room at random intervals of seconds. This kind of traffic can't be stopped by traditional firewalls, and each request carries a legitimate cookie.
Remember last year when a well-known chess platform was hammered through? The attackers used two thousand cloud function nodes to take turns brushing the room interface, 3000 requests per second to paralyze the room service. The most detrimental thing is that they picked the prime time at 10:00 p.m. to do it, and the ransom was 30% higher than that of their counterparts - this has formed an industrial chain.
Why can't ordinary high defense CDNs protect against this kind of attack? Because the traditional protection strategy mainly depends on the IP frequency. But people now use a large number of proxy IP + low-frequency requests, each IP requests more than a dozen times a minute, it looks better than the real user. I have tested a vendor's "intelligent protection" mode, people slowly brush the room interface for half an hour, CDN actually did not stop one, but instead of a few frequently refreshed the list of real users to block.
The real effective protection has to start from the business dimension. For example, the room interface of the board game, the frequency of normal user access is capped - who the hell can change ten rooms a second? But the default rules of many CDN vendors only mechanically limit the number of requests per second. Later, when I changed the WAF of CDN07 for my client, I directly wrote a custom rule:
The meaning of this set of combinations is: short bursts of 5 requests are allowed (to cope with fast clicks), but the total number of requests per minute cannot exceed 10. At the same time with the "IP + user ID" two-factor identification, to prevent attackers to change the account brush the same IP. real test down on the day of the blocking of 160,000 malicious requests, false blocking rate of only 0.2%.
Login interface protection is even more deadly. Many platforms think that adding a verification code is all right, but the result is that people use a coding platform + scripts to brush as usual. Last year, a platform was hit by the attack, the attacker with a million password dictionary slow trial and error, every hour to try six thousand times, specifically pick three or four o'clock in the morning operation. When the security team found out, there were already more than three hundred accounts cracked.
The reliable practice now is to deploy dynamic challenge mechanisms. For example, the intelligent verification module of CDN5 will trigger a three-level response to abnormal login behavior: first pop slider verification, upgrade to computational question verification upon detection of continued attack, and the final means is forced SMS verification. The key is that this switching process is completely dynamic - the attacker simply can't figure out the trigger rules. I let the test team simulate the attack, the highest record lasted until the 173rd request before triggering the highest level of verification, normal users will not touch the bottom line.
Another big killer is the behavioral analysis engine. 08Host's protection system is quite interesting, it will give each user session hundreds of tags: from the mouse track to the time between requests, and even includes TCP stack characteristics. Once caught an attack group, each request perfectly simulated the Chrome browser, but just because the initial TCP window size settings and the real Chrome difference of a few bytes, directly marked as malicious traffic.
The most damaging thing about board games is the TCP connection attacks. Some attackers don't send HTTP requests, they just establish TCP connections with you like crazy and then fill up the ports. For this scenario, you have to do a connection limit at the CDN level. It is recommended to divide the strategy by business type:
Don't forget WebSocket protection. Nowadays, boards with a little bit of scale use long connection communication, and the attackers specially pick the WebSocket channel to send garbage packets. A customer has been pitched - the attacker sends hundreds of compressed garbage packets per second, and the server decompresses the CPU directly. Later, I configured WebSocket-specific rules on CDN07:
To be honest, you can't just look at the bandwidth value to pick a high-defense CDN now. You have to see if the other side has experience in the chess industry protection, WAF rules can be customized, there is no API for you to dynamically adjust the strategy. Some vendors blow hundreds of T protection bandwidth, the result is that the rule base has not been updated for three years, and even Redis unauthorized access attacks can not be prevented.
Recently to help customers do migration compared to several vendors. CDN5's advantage lies in intelligent scheduling algorithms, when attacked by the second switching line; CDN07's WAF customization capabilities, even the depth of the JSON parameter detection support; 08Host's cost-effective Anycast network latency is stable. In the end, the customer got a hybrid program: 08Host to carry the daily traffic, CDN5 to do the attack on the backup scheduling, key business interfaces hanging CDN07 WAF. this set of combinations down, the monthly cost increase of less than 20%, but the protection ability to turn over more than five times.
Finally, a lesson in tears: do not think that the purchase of a high defense CDN will rest easy. Regularly check the protection statement is the basic operation, it is best to do a weekly attack and defense drills. I once found that a client's old API interface did not have access to the protection, the attacker squatted for three months and finally found this gap, a night to penetrate the server. Now I ask customers to strictly follow the principle of "online must be protected", and all new interfaces must undergo security testing before deployment.
Cybersecurity is a cat and mouse game these days. Rules deployed just last week may be bypassed the next week, so you have to maintain a 'continuous confrontation' mentality. An attack group even studied our protection strategy, using the Buddhist attack mode to slowly grind - every hour to fuck you for ten minutes, picking the security personnel meal time to start. Later, we wrote a script to automatically analyze the attack pattern, found anomalies directly switch protection mode, which is considered to be a stable position.
Let's be honest, building security in the chess industry is a bottomless pit. But think about the losses and payouts caused by attacks, these investments are really nothing. Last year, there was a platform because of three days of downtime by the players class action lawsuit, compensation money enough to buy five years of high defense services. Now customers have learned to be smart, security budget from "cost item" to "insurance item", which is a good phenomenon of the industry's progress.
(At the request of the customer part of the technical details have been fuzzy processing, the specific configuration please adjust according to the actual business)
