I have been in the cybersecurity industry for 20 years, with 15 years of DDoS defense experience. I have been cheated many times (they all claimed to defend against 300G or 500G, but failed after purchase). This article will explain what DDoS attacks are, how small and medium-sized enterprises can defend against them, and the costs involved.
Back in 2004, I remember going to the data center at 2 AM with a screwdriver for maintenance due to a DDoS attack. The police mistook me for a thief. At that time, the Huaxia Hacker Alliance faced attacks daily. Remote connections were impossible, so we had to go to the data center physically. The data center didn’t even know what DDoS was—they only knew there was high traffic. In one sentence: “You’ve got a virus.” This was at the China Telecom HP Tower data center.
Now, let’s get to the point.
First, let’s talk about DDoS attack methods. Remember this: This is a world-class problem with no solution—it can only be mitigated.
DDoS (Distributed Denial of Service) attacks aim to prevent the target from providing normal services or even make it disappear from the internet. It is one of the most powerful and hardest-to-defend attacks. This is a world-class problem with no solution—it can only be mitigated.
Based on how they are launched, DDoS attacks can be simply divided into three categories.
The first type wins by brute force. Massive data packets swarm in from all corners of the internet, clogging the IDC entrance and rendering powerful hardware defense systems and efficient emergency procedures useless. Typical representatives of this type are ICMP Flood and UDP Flood, which are now uncommon.
The second type wins by finesse—agile and hard to detect. Sending one packet every few minutes, or even just a single packet, can render a luxury-configured server unresponsive. These attacks mainly exploit protocol or software vulnerabilities, such as Slowloris attacks and Hash collision attacks, which require specific conditions to occur.
The third type is a hybrid of the above two, combining both agility and brute force. It exploits protocol and system flaws while also generating massive traffic, such as SYN Flood attacks and DNS Query Flood attacks. This is the current mainstream attack method.
This article will describe each of these most common and representative attack methods and introduce their defense solutions.
SYN Flood
SYN Flood is one of the most classic DDoS attack methods on the internet, first appearing around 1999, with Yahoo being the most famous victim at the time. SYN Flood exploits a flaw in the TCP three-way handshake, allowing attackers to render the target server unresponsive at relatively low cost while being hard to trace.
The standard TCP three-way handshake process is as follows:
1. The client sends a TCP packet containing the SYN flag. SYN stands for Synchronize; the synchronization packet specifies the client’s port and the initial sequence number for the TCP connection. 2. Upon receiving the client’s SYN packet, the server returns a SYN+ACK (Acknowledgement) packet, indicating that the client’s request has been accepted, and the TCP initial sequence number is automatically incremented by 1. 3. The client also returns an ACK confirmation packet to the server, with the TCP sequence number likewise incremented by 1.
After these three steps, the TCP connection is established. To achieve reliable transmission, the TCP protocol includes some exception handling mechanisms during the three-way handshake. In step three, if the server does not receive the client’s final ACK confirmation packet, it will remain in the SYN_RECV state, add the client’s IP to a waiting list, and resend the SYN+ACK packet from step two. Retransmission typically occurs 3-5 times, polling the waiting list roughly every 30 seconds to retry all clients. On the other hand, after sending the SYN+ACK packet, the server pre-allocates resources to store information for the upcoming TCP connection, and these resources remain reserved during the retry waiting period. More importantly, server resources are limited. Once the SYN_RECV state queue exceeds its limit, the server will no longer accept new SYN packets—that is, it will refuse new TCP connection establishment.
SYN Flood exploits precisely the TCP protocol design described above to achieve its attack goal. The attacker spoofs a large number of IP addresses and sends SYN packets to the server. Since the forged IP addresses are almost certainly non-existent, virtually no device will return any response to the server. Consequently, the server maintains a huge waiting list, continuously retrying to send SYN+ACK packets while occupying substantial resources that cannot be released. Even more critically, the target server’s SYN_RECV queue is filled with malicious packets, no longer accepting new SYN requests, so legitimate users cannot complete the three-way handshake to establish a TCP connection. In other words, the server has been subjected to a SYN Flood denial of service.
For those interested in SYN Flood DDoS attack software, you can take a look at
http://www.77169.org/hack/201508/205870.shtm which I wrote.
DNS Query Flood
As the most fundamental and core service of the internet, DNS is naturally one of the primary targets of DDoS attacks. Taking down DNS services can indirectly bring down a company’s entire business or cripple network services across an entire region. The once-prominent hacker group Anonymous also once announced plans to attack the 13 root DNS servers worldwide, though they ultimately failed.
UDP attacks are the easiest means of launching massive traffic attacks, and source IPs can be randomly spoofed, making them hard to trace. However, filtering is relatively easy because most IPs do not provide UDP services—simply dropping UDP traffic will suffice. So pure UDP traffic attacks are now relatively rare, replaced by DNS Query Flood attacks carried over the UDP protocol. Simply put, the higher the protocol layer at which a DDoS attack is launched, the harder it is to defend against, because the higher the protocol layer, the closer it is tied to the business, and the more complex the situation the defense system faces.
DNS Query Flood involves an attacker controlling a large number of zombie machines to launch massive domain name query requests against the target. To prevent ACL-based filtering, the randomness of data packets must be increased. Common practices include randomly spoofing source IP addresses and source ports at the UDP layer. At the DNS protocol layer, the query ID and the domain name to be resolved are randomly forged. Randomly forging the domain name to be resolved, besides preventing filtering, also reduces the likelihood of hitting the DNS cache, consuming as much of the DNS server’s CPU resources as possible.
Regarding DNS Query Flood code, I once wrote a piece of code in July 2011 to test server performance. The link is http://www.icylife.net/yunshu/show.php?id=832. Likewise, this code artificially reduces its attack capability and is only for testing purposes.
HTTP Flood
The SYN Flood and DNS Query Flood described above can now be effectively defended against. What truly troubles major vendors and internet enterprises is HTTP Flood attacks. HTTP Flood targets web services at the Layer 7 protocol. Its enormous harm manifests in three main aspects: easy to launch, hard to filter, and far-reaching impact.
SYN Flood and DNS Query Flood both require attackers to control a large number of zombie machines with root privileges. Collecting a large number of root-privilege zombie machines takes a lot of time and effort. Moreover, during the attack, zombie machines will be discovered by administrators due to abnormal traffic, causing the attacker’s resources to deplete quickly and replenish slowly, leading to significantly reduced attack intensity that cannot be sustained long-term. HTTP Flood attacks are different. Attackers do not need to control large numbers of zombie machines; instead, they use port scanning programs to search the internet for anonymous HTTP proxies or SOCKS proxies, through which they launch HTTP requests against the target. Anonymous proxies are a relatively abundant resource—spending a few days acquiring proxies is not difficult, so attacks are easy to launch and can be sustained at high intensity for long periods.
On the other hand, HTTP Flood attacks are launched at the HTTP layer, closely mimicking normal users’ web request behavior and tightly coupled with website business. It is very difficult for security vendors to provide a universal solution that does not affect user experience. A rule that works well in one scenario may cause massive false positives in another.
Finally, HTTP Flood attacks cause serious chain reactions, not only directly slowing down the targeted web front-end but also indirectly attacking backend Java and other business-layer logic as well as further-back database services, increasing their pressure, and even affecting log storage servers.
Interestingly, HTTP Flood has a historically significant nickname called CC attack. CC stands for Challenge Collapsar, and Collapsar is a DDoS defense device from a well-known domestic security company. Judging from the current situation, not only Collapsar but all hardware defense devices are still being challenged, and the risk remains unresolved.
Slow Connection Attacks
When mentioning attacks, the first reaction is massive traffic and massive packets. But there is one type of attack that takes the opposite approach, known for its slowness—so much so that some targets are beaten to death without knowing how they died. This is the slow connection attack, the most representative being Slowloris invented by rsnake.
The HTTP protocol stipulates that an HTTP Request ending with /r/n/r/n indicates the client has finished sending and the server begins processing. So what happens if /r/n/r/n is never sent? Slowloris exploits this to carry out DDoS attacks. The attacker sets Connection to Keep-Alive in the HTTP request header, asking the Web Server to keep the TCP connection open, then slowly sends one key-value format data to the server every few minutes, such as a:b/r/n, causing the server to think the HTTP header has not been fully received and keep waiting. If the attacker uses multiple threads or zombie machines to do the same, the server’s web container will quickly be filled up with TCP connections by the attacker and no longer accept new requests.
Soon, various variants of Slowloris began to appear. For example, using the POST method to submit data to the Web Server, padding a large Content-Length but slowly sending actual POST data byte by byte, etc. Regarding Slowloris attacks, rsnake also provided a test code. See http://ha.ckers.org/slowloris/slowloris.pl.
Advanced DDoS Attacks Hybrid Attacks
The above introduces several basic attack methods, any one of which can be used to attack a network, even bringing down giant websites like Alibaba, Baidu, or Tencent. But these are not all. Attackers at different levels can launch completely different DDoS attacks—the artistry lies in how they are combined.
Advanced attackers never use a single method to attack; they flexibly combine methods based on the target environment. Ordinary SYN Flood can be easily filtered out by traffic scrubbing devices through reverse probing, SYN Cookie, and other techniques. But if SYN+ACK packets are mixed into the SYN Flood, so that every forged SYN packet has a corresponding forged client confirmation packet—where “corresponding” means the source IP address, source port, destination IP, destination port, TCP window size, TTL, etc., all match the characteristics of the same host and the same TCP Flow—the reverse probing and SYN Cookie performance pressure on traffic scrubbing devices will increase significantly. In fact, SYN packets combined with various other flag bits all have special attack effects, which will not be detailed here. DNS Query Flood also has its unique tricks.
First, DNS can be divided into ordinary DNS and authoritative domain DNS. When attacking ordinary DNS, IP addresses need to be randomly forged, and the server must be instructed to perform recursive resolution. But when attacking authoritative domain DNS, the forged source IP addresses should not be purely random; instead, they should be DNS addresses of ISPs around the world collected in advance, to achieve maximum attack effect, putting the traffic scrubbing device in an awkward position of whether to add IPs to the blacklist or not. Adding them would cause massive false positives; not adding them means every packet needs reverse probing, increasing performance pressure.
On the other hand, as mentioned earlier, to increase pressure on scrubbing devices and avoid cache hits, the requested domain names need to be randomized. However, it should be noted that the domain names to be resolved must have a certain regularity within the forgery. For example, only a certain part of the domain name is forged while another part is fixed, used to bypass the whitelist set by the scrubbing device. The logic is simple: Tencent’s servers can only resolve Tencent’s domain names, so completely random domain names may be directly discarded and need to be partially fixed. But if completely fixed, they may also be easily discarded, so part of the domain name still needs to be forged.
Secondly, DNS attacks should not only focus on the UDP port. According to the DNS protocol, the TCP port is also a standard service. During an attack, UDP and TCP attacks can be carried out simultaneously.
The focus of HTTP Flood is to bypass the front-end cache and reach the Web Server itself through field settings in the HTTP header. Additionally, the choice of target for HTTP Flood is also very critical. Ordinary attackers would choose pages like search that require extensive data queries as attack targets, which is very correct as it can consume as many server resources as possible. However, this type of attack can be easily identified by scrubbing devices through human-machine recognition. So how to solve this problem? It’s simple: try to choose pages that normal users also access through apps, generally various Web APIs. Normal users and malicious traffic both come from apps, with very little difference between humans and machines, making them nearly indistinguishable.
Slow attacks like these achieve their goal by cleverly holding connections without releasing them. But this is also a double-edged sword—every TCP connection exists on both the server side and the attacker’s own side, and the attacker also needs to consume resources to maintain the TCP state, so connections cannot be kept in too large numbers. If this point could be resolved, the attack capability would be greatly enhanced. That is, Slowloris can launch attacks in a stateless manner, capturing TCP sequence numbers and acknowledgments on the client side through sniffing to maintain TCP connections, without the system kernel needing to track various TCP state transitions. A single laptop can generate up to 65,535 TCP connections.
What has been described above are all technical-level attack enhancements. On the human side, there are other tricks. If SYN Flood sends a massive number of packets for a frontal assault, supplemented by Slowloris slow connections, how many people would discover the secret? Even if the server goes down, perhaps only the SYN attack is discovered, and efforts focus on strengthening TCP-layer scrubbing while ignoring the application-layer behavior. Various attacks can be combined to achieve maximum effect. The choice of attack timing is also a key factor—for example, when maintenance staff are having lunch, when they are stuck in traffic after work or on the subway with no wireless signal, or when the target enterprise is running a large-scale event and traffic surges, etc.
What is described here is purely attack behavior, so no code is provided, and no in-depth introduction is given.
Attacks from P2P Networks
The attack methods described above all require some zombie machines to varying degrees—even HTTP Flood requires searching for a large number of anonymous proxies. If there were an attack that only required issuing some commands and machines would automatically come up to execute, that would be the perfect solution. Such an attack has already emerged: attacks from P2P networks.
As everyone knows, P2P users and traffic on the internet are both enormously large numbers. If they all went to a specified location to download data, causing tens of thousands of real IP addresses to connect, no device could withstand it. Take BT downloads, for example: forging torrents for popular videos and publishing them to search engines is enough to trick many users and generate traffic. But this is only the basic attack.
Advanced P2P attacks directly deceive resource management servers. For example, the Xunlei client uploads resources it discovers to the resource management server, which then pushes them to other users who need to download the same resources. In this way, a link is disseminated. Through protocol reverse engineering, attackers can forge large amounts of popular resource information and distribute it through the resource management center, instantly spreading across the entire P2P network. Even more terrifying is that this type of attack cannot be stopped—even the attacker themselves cannot stop it. The attack continues until P2P officials discover the problem, update the server, and download users restart their download software.
CC (Challenge Collapsar)
The name Challenge Collapsar originates from challenging the anti-DDoS device “Black Hole” (Collapsar) from the well-known domestic security vendor NSFOCUS. Through botnet zombie hosts or by finding anonymous proxy servers, it launches massive numbers of real HTTP requests against the target, ultimately exhausting concurrent resources, slowing down the entire website, or even completely denying service.
The internet’s architectural pursuit of scalability is essentially to improve concurrency. Various SQL performance optimization measures—eliminating slow queries, sharding databases and tables, indexing, optimizing data structures, limiting search frequency, etc.—are all fundamentally aimed at resolving resource consumption. CC, however, takes the opposite approach: filling up the server’s concurrent connections, making requests bypass the cache as much as possible to directly hit the database, targeting the most resource-intensive queries in the database, preferably ones that cannot use indexes, with each query doing a full table scan. This way, minimal attack resources achieve maximum denial-of-service effect.
Internet products and services rely on data analysis to drive improvement and continuous operation. So beyond front-end apps, middleware, and databases—the OLTP systems—there are also OLAP systems behind them: the big data platform spanning log collection, storage, data processing, and analysis. When a CC attack occurs, not only is the OLTP part affected, but CC actually generates massive logs that directly impact the backend OLAP, affecting two aspects: first, the day’s data statistics are completely wrong; second, the dramatic increase in access logs during the CC period also increases the burden on backend data processing.
CC is currently one of the main methods of application-layer attacks. There are some defense methods, but they cannot perfectly solve this problem.
Reflection Attacks
DRDOS was first disclosed in 2004. By setting the source address of SYN packets to the target address and then sending them to a large number of
real TCP servers, the TCP servers that receive these SYN packets send SYN|ACK packets back to the target address to complete the three-way handshake, achieving a “reflection” attack. The attacker hides themselves, but one problem is that the traffic generated by the attacker and the attack traffic received by the target is at a 1:1 ratio, and the SYN|ACK packets are immediately responded to with RST packets upon reaching the target. The overall return on investment for the attack is not high.
The essence of reflection attacks is to exploit “challenge-response” protocols. By setting the source address of the challenge packet to the target address through raw sockets, the response “reply packets” are all sent to the target. If the reply packet is relatively large or the protocol supports recursive effects, the attack traffic is amplified, becoming a cost-effective traffic-based attack.
Protocols currently exploited by reflection attacks include NTP, Chargen, SSDP, DNS, RPC portmap, and others.
Traffic Amplification Attacks
Taking the SSDP protocol commonly used in the DRDOS mentioned above as an example, the attacker sets Searchtype to ALL, searching for all available devices and services. The amplification factor produced by this recursive effect is very large. The attacker only needs a small amount of query traffic with forged source addresses to generate dozens or even hundreds of times the response traffic sent to the target.
Defense Basics
How large is the attack traffic? This is a critical question. The defense method used depends on the attack volume. Below I will explain defense methods for attacks under 1G. Cost: less than 10,000 yuan per month.
When talking about DDoS defense, the first thing is to know exactly how large the attack is. This question seems simple but actually involves many lesser-known details.
Taking SYN Flood as an example, to improve sending efficiency and generate more SYN waiting queues on the server side, the attack program does not fill optional fields in either the IP header or TCP header when constructing packets. Therefore, the IP header length is exactly 20 bytes, and the TCP header is also 20 bytes, totaling 40 bytes.
For Ethernet, the minimum packet data segment must reach 46 bytes, but the attack packet is only 40 bytes. Therefore, when the network card sends, it does some processing, padding 6 zeros at the end of the TCP header to meet the minimum packet length requirement. At this point, the entire packet length is: 14 bytes for the Ethernet header, 20 bytes for the IP header, 20 bytes for the TCP header, plus 6 bytes of zeros padded for the minimum packet length requirement—a total of 60 bytes.
But this is not the end. Ethernet also has CRC check requirements during data transmission. The network card performs a CRC check on the data packet before sending, appending a 4-byte CRC value to the end of the packet header. At this point, the data packet length is no longer 40 bytes but has become 64 bytes. This is what is commonly called a SYN small-packet attack. The packet structure is as follows:
|14-byte Ethernet Header|20-byte IP Header|20-byte TCP|6-byte Padding|4-byte CRC|
|Destination MAC|Source MAC|Protocol Type| IP Header |TCP Header|Ethernet Padding | CRC Check |
At 64 bytes, the SYN packet is fully padded and ready for transmission. The attack packets are very small, far below the Maximum Transmission Unit (MTU) of 1500 bytes, so they will not be fragmented. So do these packets travel tightly packed together like cans on a production line? In fact, that is not the case.
During Ethernet transmission, there are also preamble and inter-frame gap. The preamble occupies 8 bytes, i.e., 64 bits. The first 7 bytes of the preamble are all 10101010, alternating 1s and 0s. But the eighth byte becomes 10101011. When the host detects two consecutive 1s, it knows that data follows. During network transmission, the data structure is as follows:
|8-byte Preamble|6-byte Destination MAC|6-byte Source MAC|2-byte Upper Layer Protocol Type|20-byte IP Header|20-byte TCP Header|6-byte Ethernet Padding|4-byte CRC|12-byte Inter-frame Gap|
In other words, a SYN packet that is originally only 40 bytes actually occupies 84 bytes of bandwidth during network transmission.
With the above foundation, we can now begin calculating attack traffic and network device wire-speed issues. When the minimum SYN packet with only IP and TCP headers filled runs on an Ethernet network, a 100Mbit network can support a maximum PPS (Packet Per Second) of 100×10^6 / (8 * (64+8+12)) = 148,809. A 1000Mbit network can support a maximum PPS of 1,488,090.
SYN Flood Defense
As described earlier, SYN Flood attacks heavily consume the server’s CPU and memory resources and fill up the SYN waiting queue. Correspondingly, we can effectively mitigate this by modifying kernel parameters. The main parameters are as follows:
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 8192
net.ipv4.tcp_synack_retries = 2
These are respectively: enabling SYN Cookie, setting the maximum SYN queue length, and setting the maximum SYN+ACK retry count.
The role of SYN Cookie is to alleviate server resource pressure. Before enabling it, upon receiving a SYN packet, the server immediately allocates storage space, randomizes a number as the SYN number, and sends a SYN+ACK packet. It then saves the connection state information and waits for client confirmation. After enabling SYN Cookie, the server no longer allocates storage space; instead, it uses a time-seed-based random number algorithm to set a SYN number, replacing the fully random SYN number. After sending the SYN+ACK confirmation packet, it clears resources without saving any state information. Only when the server receives the client’s final ACK packet does it use the Cookie verification algorithm to determine whether it matches the sequence number of the sent SYN+ACK packet. If matched, the handshake is completed; if not, it is discarded. Of course, the advanced attack method of mixing SYN with ACK mentioned earlier is a countermeasure against this defense method, with the outcome determined by the hardware configurations of both sides.
tcp_max_syn_backlog uses the server’s memory resources to trade for a larger waiting queue length, so that attack packets do not fill up all connections and prevent normal users from completing the handshake. net.ipv4.tcp_synack_retries reduces the server’s SYN+ACK packet retry count, releasing waiting resources more quickly. These three measures correspond one-to-one with the three harms of the attack, precisely targeting the symptoms. However, these measures are also double-edged swords—they may consume more server memory resources and even affect normal users’ TCP connection establishment. They need to be set cautiously after evaluating server hardware resources and attack magnitude.
In addition to customizing the TCP/IP protocol stack, another common approach is the TCP first-packet drop scheme, which uses the TCP protocol’s retransmission mechanism to distinguish normal users from attack packets. When the defense device receives a SYN packet from an IP address, it simply checks whether that IP exists in the whitelist. If so, it forwards to the backend. If not in the whitelist, it checks whether this is the first SYN packet from that IP within a certain time period. If not, it checks whether it is a retransmission packet. If it is a retransmission, it forwards and adds to the whitelist. If not, it drops and adds to the blacklist. If it is the first SYN packet, it drops and waits for a period to attempt to receive a SYN retransmission packet from that IP. If the wait times out, it is determined to be an attack packet and added to the blacklist.
The first-packet drop scheme slightly affects user experience because dropping the first packet and retransmitting increases business response time. In light of this, a better TCP Proxy scheme has been developed. All SYN packets are received by the scrubbing device and processed according to the SYN Cookie scheme. IP addresses that successfully complete the TCP three-way handshake with the device are determined to be legitimate users and added to the whitelist. The device then masquerades as the real client IP address and completes the three-way handshake with the real server, subsequently forwarding data. IP addresses that fail to complete the three-way handshake with the device within the specified time are determined to be malicious IP addresses and blocked for a certain period. Besides SYN Cookie combined with TCP Proxy, scrubbing devices also have the capability to detect various malformed TCP flag packets, distinguishing normal access from malicious behavior by returning unexpected responses to SYN packets and testing the client’s reaction.
The hardware of scrubbing devices features specialized network processor chips and specially optimized operating systems and TCP/IP protocol stacks, capable of handling extremely large traffic and SYN queues.
HTTP Flood Defense
HTTP Flood attack defense is primarily carried out through caching, with the device’s cache directly returning results as much as possible to protect backend services. Large internet enterprises have massive CDN nodes caching content.
When advanced attackers penetrate the cache, scrubbing devices intercept HTTP requests for special processing. The simplest method is to count the HTTP request frequency from source IPs, adding IPs exceeding a certain frequency to the blacklist. This method is too simplistic, prone to false positives, and cannot block attacks from proxy servers, so it has gradually been phased out, replaced by the JavaScript redirect human-machine recognition scheme.
HTTP Flood is simulated by programs sending HTTP requests, which generally do not parse server return data, let alone parse JS code. Therefore, when a scrubbing device intercepts an HTTP request, it returns a special piece of JavaScript code. Normal users’ browsers will process it and redirect normally without affecting usage, while attack programs will attack empty space.
DNS Flood Defense
DNS attack defense also has similar methods to HTTP defense. The first solution is caching. The second is retransmission, which can be directly dropping DNS packets to cause UDP-level request retransmission, or returning special responses forcing clients to use the TCP protocol to resend DNS query requests.
Specifically, for the protection of authoritative domain DNS, the device extracts received DNS domain name lists and ISP DNS IP lists during normal business periods for backup. During an attack, requests not in this list are uniformly discarded, significantly reducing performance pressure. For domain names, the same domain name whitelist mechanism is implemented—resolution requests for domain names not in the whitelist are discarded.
Slow Connection Attack Defense
Slowloris attack defense is relatively simple, with two main solutions.
The first is to count the duration of each TCP connection and calculate the number of packets passing through per unit time for accurate identification. In a TCP connection, too few HTTP packets and too many are both abnormal. Too few may be a slow connection attack; too many may be an HTTP Flood attack using the HTTP 1.1 protocol, sending multiple HTTP requests in a single TCP connection.
The second is to limit the maximum allowed time for HTTP header transmission. If the HTTP Header has not completed transmission within the specified time, the source IP address is directly determined to be a slow connection attack, the connection is terminated, and the IP is added to the blacklist.
～～～～～～～～～～～～～～～～～～～～～·
Now let’s discuss in detail the corresponding approaches for different attack volumes.
If it exceeds >10G attack, software protection is useless for attacks above 10G.
Remember this: DDoS defense capability depends on the size of your bandwidth, not on software.
In China, 100M bandwidth now costs from 8,000 yuan for the cheap option to over 20,000 yuan per month. 1G bandwidth costs 80,000 yuan. 10G bandwidth costs 800,000 yuan. Are you sure you want to defend on your own?
There are many types of business logic, and each company is different.
WEB type: this is the most attacked, with broader defense options. You can choose domestic, overseas, CDN acceleration, etc.
Game type: this must be hosted domestically. Hosting overseas is too laggy, causing disconnections, and no one will play.
The solution is to find a third-party DDoS defense provider.
For 10-50G protection, many domestic data centers can provide it. The question is whether the money you pay is enough for the IDC data center to protect you. Here’s their protection diagram:
The data center has a total bandwidth. If your attack bandwidth is too large, it will affect their normal customers, and they will find various excuses to block your IP.
Many attacks last for a very short time, usually within 5 minutes, appearing as spike-shaped pulses on the traffic graph.
In reality, this has little impact on the data center, but the data center still blocks your IP. This is used to attack gaming websites—causing intermittent disconnections, making all users drop off.
For attacks up to 50G, single-machine protection from Zhejiang, Jiangsu, or Guangdong can all handle it. Monthly cost: around 20,000 yuan (any price below 10,000 yuan is a scam—I’ve tested this).
Many online claims of “ignoring” 320G protection are all bragging. Their so-called 320G is probably just UDP attacks, because China Telecom’s upper layer blocks UDP bandwidth.
Guangdong has dual-line, suitable for hosting gaming websites—fast speed and decent protection.
Some Guangdong IPs block overseas traffic and also block China Unicom traffic, meaning traffic from anywhere other than China Telecom cannot get through.
Like this ISP near-source scrubbing.
For 100-200G, this is now the critical range—currently the most common attack volume. For gaming websites facing this level of attack hosted domestically, the data centers that can provide this level of protection include: China Telecom in Guangdong, Fuzhou, Guangxi, and China Unicom in Dalian.
I bought from Fuzhou at over 20,000 yuan/month, claimed 300G protection, but got blocked at 130G—scammers. DNS protection was also useless; a DNS attack around 10G killed it directly.
I bought from a Guangdong data center at 30,000 yuan/month, got blocked at 100G. But Guangdong can unblock instantly. Buying 200 IPs can still hold for a while. Guangdong’s DNS couldn’t be accessed directly—the data center implemented policies.
Guangxi—currently testing. A few days ago I put DNS in the Guangxi data center and it got killed.
DNS attack protection is also critical. I bought DNSPod’s most expensive version at over 30,000 yuan/year and it got blocked. DNSPod too—isn’t Old Wu no longer there? He went off to do other things. Now it’s really garbage. Relying on DNSPod for protection is far from enough. Let me introduce: Google has DNS protection, which works well and is much cheaper than DNSPod. Also CloudFlare, very good, $200/month, never been knocked down.
The above cost me over a hundred thousand yuan testing DNS and 100G protection. Here’s the experience I’ve gathered.
Gaming must be hosted domestically, and you also need to consider whether it’s UDP or TCP, so the protection scope is limited.
WEB has more protection options and can consider overseas hosting.
Now, the overseas ones that boast a lot:
US SK data center, claims 100G protection. I bought it. It took 2 days to set up the machine. After an attack, the IP gets blocked for 1 hour. Honestly, it’s no good. The data center also has frequent disconnections. Cost about 10,000 yuan, maybe per month.
US HS data center, claims 80G protection at 80,000 yuan/month. I bought it and it got killed. They block you around 40G, pretty much scammers too. They said they could add up to 200G protection—never saw it.
US CD data center. Finally spent over 100,000 yuan/month and contacted their boss—they held up. But DNS protection was no good.
One more data center I can recommend: Canada data center. Single-machine 160G protection, cluster 480G, no IP blocking, protection is decent. Downside: laggy, domestic ping drops packets. Around 8,000 yuan/month, 20 yuan per IP.
Among the above, the fastest is the HS data center domestically, around 150ms latency. It’s okay when there’s no attack, but the protection is somewhat lacking during attacks.
I’m not advertising for data centers. I’m just summarizing my recent protection experience. There are also domestic data centers that don’t require ICP filing, and resources for DNS protection up to 500G are all available. Contact me. I can give you these resource contacts for free.
～～～～～～～～～～～～～～～～～～～～～～～～～～
Finally, let’s talk about cloud acceleration.
Domestic Cloud Shield: ridiculously expensive, protection is useless. Don’t bother looking at theirs.
Alibaba Cloud Protection: single-machine 4G protection, not expensive. Small businesses can use it. Downside: requires ICP filing, and if you have illegal content, they can directly report you to the authorities (this is the worst part).
Baidu Cloud Acceleration: claims 1T protection. I researched it carefully. They partnered with overseas CloudFlare cloud acceleration and China Telecom’s CloudLeak (near-source scrubbing), claiming 1T protection. Attacks up to 400G get redirected to CloudFlare overseas; domestic attacks up to 600G are all protected by CloudLeak.
What is near-source scrubbing? When there’s an attack from Jiangsu, at the Jiangsu China Telecom exit, the ISP—China Telecom—directly blocks it from exiting.
Currently, China Telecom’s dedicated anti-DDoS CloudLeak provides [near-source scrubbing] and [traffic suppression] services. For vendors that purchase its services, they can customize blackhole-routed IPs to link with China Telecom’s devices. Blackhole routing is a crude method—besides attack traffic, some real user access is also blackholed, which compromises user experience. Essentially, it’s a sacrifice-one-to-save-the-rest approach to preserve link bandwidth for remaining users. The reason such a paid service still exists is that without it, the entire website service would become completely inaccessible to all users. For cloud scrubbing vendors, they actually also need to leverage blackhole routing to link with China Telecom.
Baidu Cloud Acceleration—haven’t tested it yet, no comment. To summarize, most domestic vendors are all about bragging; that’s just how the industry is. Overseas ones are more reliable, but they are indeed not cheap.
Three recommendations:
Amazon: ignores attacks up to 30G. If the attack gets too large, they’ll block you too. Its biggest advantage: pay-per-traffic, billed hourly, no ICP filing needed. Domestically you need filing first. I bought 6 nodes and they died in three days.
CloudFlare: their DNS protection is invincible. Baidu Cloud Acceleration partners with them.
Akamai: this company provides protection for Apple. They say it only went down once during an Apple launch event. I haven’t tried it—too expensive. 3.5 yuan per 1G, estimated about 5,000 yuan per day.
CDN acceleration is a primary means of defending against CC attacks.
CDN/Internet-layer CDN is not an anti-DDoS product per se, but for web services, it happens to have a certain anti-DDoS capability. Take flash sales on large e-commerce platforms as an example: the traffic volume is enormous, rivaling DDoS CC attacks by many metrics. On the platform side, CAPTCHAs at the CDN layer actually filter out the vast majority of requests, and the requests that finally reach the database account for only a very small portion of the total.
For HTTP CC-type DDoS, it won’t directly reach the origin server. CDN will first absorb it with its own bandwidth. Requests that can’t be absorbed or that penetrate the CDN as dynamic requests will reach the origin server. If the origin server’s front-end anti-DDoS capability or bandwidth is relatively limited, it will be completely DDoS’d.
～～～～～～～～～～～～～～～
If you’re a legitimate website, don’t worry about attacks—you won’t face that level of attack. Nowadays, hackers mainly target illegitimate websites—porn sites, chess/card gambling sites, sports betting—all for extortion. Legitimate websites won’t be attacked daily; your attackers are your competitors.
If one day someone attacks you demanding money, here’s what you need to do.
Filing a Case and Tracing
Currently, attacks with traffic above 100G can be filed as a case, which is much better than in the past. Before, without domestically-characteristic resources, you couldn’t even file a case. But filing a case is only the first step of a long journey. If you want to find the person, you must successfully complete the following steps:
• Among the massive attack traffic, search for backtracking clues to identify IPs or related domain names that may be C&C servers
• “Hacker” vs “hacker”—take down the C&C server
• Physically locate the attacker through login IPs or with the help of third-party APT big data resources (if you can obtain them)
• Accompany the officers for on-site arrest
• Go to court for litigation
If this person has no special status, you might get what you want. But if you encounter someone special, months of your effort will be in vain. The ability to “hack a hacker” depends on the security team’s own strong penetration capabilities and having the time and inclination to do this. This process is still quite costly for many enterprises—the threshold of having a capable security team alone eliminates the vast majority of companies. I happened to encounter such a team by chance in the past.
There are successful cases. In Yanjiao, Mr. Huang—someone attacked him demanding money, he paid a few thousand, reported it to the police, and they caught the person. But it’s not like you report it and someone will handle it for you—you still need connections (you know how things work in China). But hey, you can contact me. I can tell you what to do. Haha.
To summarize:
For WEB website attacks at normal traffic levels: direct SYN and UDP won’t kill you, so they attack your DNS. If that fails, they can also report you. For gaming websites: they won’t directly kill you—they’ll make you keep disconnecting so no one can play. That achieves their goal. So this type of website needs protection deployed in advance. Also payment websites and SMEs—the choice of solution mainly depends on the attack volume. If your company has money to burn, don’t read further.
Now I’m going to reveal industry insider information:
<30G attack: around 3,000 yuan/month, for non-continuous attacks, usable with single-machine protection.
<50G attack: around 10,000 yuan/month, for non-continuous attacks, usable with dual-machine protection.
<100G attack: 20,000-30,000 yuan, continuous attacks/day, requires cluster protection.
<300G attack: 50,000-80,000 yuan, continuous attacks/day, requires cluster plus CDN. Learn from Baidu Cloud Acceleration: let CloudFlare handle overseas protection, and use CloudLeak for domestic protection.
So, to summarize which companies are scammers—you don’t need to waste money testing anymore. I’ve already tested them.
I was pressed for time, so many points weren’t fully written or elaborated. I’ll find time later to summarize and categorize more thoroughly.
September 2015
Original: http://www.ijiandao.com/safe/cto/15952.html