When I first took over the operation and maintenance of the company's official website, it was not unusual for me to be woken up by alarm messages in the middle of the night. A blood-red downtime alert on the screen, the background can not be logged on, the business is completely paralyzed - no need to guess, it is SYN Flood again. This thing is like the network world's zombie army, with half-connection pile up your server, but also the damn do not leave complete evidence. The most pitiful thing is that traditional firewalls often mistakenly kill real users, this side of the attack did not stop, the other side of the customer complaint phone has been broken.
Later I put the market mainstream high-defense CDN are tested once, found that can prevent SYN Flood key to look at two points: TCP connection detection accuracy and source IP verification mechanism. Some vendors blowing sky-high, the actual encounter with heavy traffic attacks directly lying flat, not as good as their own iptables hard to carry.
Where is the SYN Flood nausea? It utilizes the TCP three times handshake flaw to frantically send half-connection requests. Normal handshake requires the Client to send SYN, Server back to SYN-ACK, Client back to ACK, but the attacker is always stuck in the second step does not reply. Server resources are occupied by these ”zombie connections”, new users simply can not squeeze in. What's even worse is that the source IP of the attack is all forged, so you can't even find where the real enemy is.
In the early years we barely coped with this with Linux kernel parameter tuning:
But this can only withstand the attack volume of tens of thousands of packets per second, encountered more than 300Gbps DDoS simply white. Once after being penetrated I squatted in the server room while restarting the server while cursing, completely understand that must be on the professional program.
TCP Connection Detection of High Defense CDN is the Real DealThe algorithm gap is heavenly and earthly. Don't look at all called ”intelligent cleaning”, the algorithm gap between heaven and earth. I tested CDN07's system, which can recognize abnormal SYN packet characteristics within 3 seconds:
But the most ruthless is 08Host's protocol stack simulation technology - they use adaptive algorithms to dynamically adjust the size of the TCP window, the real user will follow the protocol specification to complete the handshake, and the attack tool to send a malformed packet directly exposed.
The source IP verification piece is even more of a crapshoot.The CDN5 approach is smarter. Some vendors simply and roughly block IP segments, often the carrier gateway address is also mistakenly killed. CDN5's approach is smarter: instead of immediately intercepting suspicious IPs when they are found, they first divert the flow to the sandbox environment to complete the challenge verification:
The actual test found that this set of combination can filter 99% forged IP, the remaining 1% through the TCP fingerprint library secondary screening. Last year, we carried 5.8 million QPS of SYN Flood on double eleven, and the business latency only increased by 3 milliseconds.
Now look at the essence of SYN Flood protection is the cost game between attackers and defenders. Attackers rent botnets for dozens of dollars per hour, and high-defense CDNs have to use massive bandwidth and arithmetic to carry hard.08Host recently engaged in blockchain node collaboration, global edge nodes to jointly verify the authenticity of the source IP, the cost of the attack to thousands of dollars per hour, directly dissuade the vast majority of hackers.
Of course there is no perfect program. Once we blocked the IP segment of a large enterprise by mistake because their employees' computers were infected with Trojan horses and turned into zombie nodes. Later, we added an intelligent learning module, and adopted a lenient policy for IP segments of multinational companies to reduce the false positive rate through behavioral analysis instead of just IP filtering.
Heartfelt advice for your peersThe best thing to do is to pick a high-defense CDN and don't just look at the bandwidth numbers, but focus on testing the compatibility of their TCP stack and the accuracy of the source IP verification. It's best to simulate the attack scenario yourself: use hping3 to send SYN packets with random source IPs and see how often the protection rules are triggered. Don't forget to check whether HTTPS services are affected, some vendors' challenge pages will break the SSL handshake.
These days even the CDN have to ”prevent teammates” - a large factory boasts of ”AI protection” is actually a manual background switching lines, the attack came to fumble to adjust the route. Still have to prepare a few more service providers, we use CDN5 to do daily acceleration, 08Host specializing in carrying heavy traffic attacks, critical moments can really save lives.
At the end of the day SYN Flood protection is a continuous gaming process. Algorithms that work today may be cracked by hackers next month, so we must keep the technology iterative. Recently we've been testing a zero-trust architecture combined with TCP port randomization, which turns server listening ports into moving targets so that attackers can't even find a handshake. There's no way to go into detail on some of these things, but remember one thing: always think two steps ahead of the attacker.
