In-depth analysis of DDoS attack defense principles

1. DDoS attack basics
The main purpose of a DDoS (Distributed Denial of Service) attack is to make the specified target unable to provide normal services, or even disappear from the Internet, is currently one of the most powerful and difficult to defend against attacks.
DDoS attacks can be divided into three types according to the method of initiation.
The first type is to win the competition. Massive data packets are flocking from every corner of the Internet, blocking the IDC entry, and making various powerful hardware defense systems and fast and efficient emergency response processes useless. The typical examples of such attacks are ICMP Flood and UDP Flood, which are no longer common.
The second type wins by coincidence, which is smart and hard to detect. Sending a package every few minutes or even only one package can make the luxury configuration server no longer respond. This type of attacks are initiated by exploiting protocol or software vulnerabilities, such as Slowloris attacks and Hash conflict attacks, which can only happen in a coincidence of a specific environment.
The third type is the combination of the above two types. They both have the advantages of protocol and system defects and possess massive traffic, such as SYN Flood attacks and DNS Query Flood attacks, is the current mainstream attack method.
This article describes the most common and representative attack methods and introduces their defense solutions.

1.1. SYN Flood
SYN Flood is one of the most classic DDoS attacks on the internet. It first appeared around 1999, and Yahoo was the most famous victim at that time. SYN Flood attacks use the three-way handshake of TCP to make the target server unable to respond at a low cost and are difficult to trace.
The standard TCP three-way handshake process is as follows:
1) the client sends a TCP packet containing the SYN sign, Synchronize. The synchronous packet specifies the port used by the client and the initial serial number of the TCP connection;
2) after receiving the SYN packet from the client, the server will return a SYN + ACK (I .e. confirm Acknowledgement) message, indicating that the client's request is accepted, and the initial TCP serial number is automatically added with 1;
3) The client also returns an ACK message to the server, and the TCP serial number is also added with 1.
After these three steps, the TCP connection is established. To achieve reliable transmission, TCP sets some exception handling mechanisms during the three-way handshake process. In step 3, if the server does not receive the final ACK message from the client, it will remain in the SYN_RECV status. Add the client IP address to the waiting list and resend the SYN + ACK packet in step 2. Resend is generally performed 3-5 times, round-robin about 30 seconds, wait for the list to retry all clients. On the other hand, after the server sends a SYN + ACK packet, it will pre-allocate resources to prepare for the TCP connection storage information to be established, which will be retained during the retry period. More importantly, the server resources are limited. If the SYN_RECV status that can be maintained exceeds the limit, new SYN packets are no longer accepted, that is, new TCP connections are denied.
SYN Flood uses the TCP protocol settings above to achieve the attack. Attackers disguise a large number of IP addresses to send SYN packets to the server. Because the forged IP address is almost impossible, almost no device will return any response to the server. Therefore, the server will maintain a large waiting list, retry sending SYN + ACK packets without stopping, and occupy a large amount of resources to release. More importantly, the SYN_RECV queue of the attacked server is filled with malicious packets and no new SYN requests are accepted. Valid users cannot complete three handshakes to establish a TCP connection. That is to say, the server is denied by SYN Flood.
For SYN Flood interested can look at the http://www.icylife.net/yunshu/show.php? Id = 367. This is the code I wrote in 2006. Later I made several modifications, modified the Bug, and reduced the attack. It was used only for testing.

1.2. DNS Query Flood
As the most basic and core service of the Internet, DNS is naturally one of the important targets of DDoS attacks. The DNS service can break down all the services of a company or the network services of a region. Previously, anonymous, a popular hacker group, also announced that it would attack 13 DNS servers on the global Internet, but it was not successful.
UDP attacks are the easiest way to initiate massive traffic attacks, and it is difficult to trace the random forgery of source IP addresses. But it is easy to filter, because most IP addresses do not provide UDP services, and UDP traffic can be directly discarded. Therefore, pure UDP traffic attacks are rare, and are replaced by DNS Query Flood attacks carried by UDP. Simply put, the higher the upper-layer protocol, the more difficult it is to defend against DDoS attacks, because the higher the protocol, the more associated with the business, the more complex the defense system is facing.
DNS Query Flood is a massive number of zombie machines manipulated by attackers to initiate massive domain name Query requests to the target. To prevent ACL-based filtering, the randomness of data packets must be improved. The common practice is to randomly forge source IP addresses, randomly forge source ports, and other parameters at the UDP layer. At the DNS protocol layer, the query ID and the domain name to be resolved are randomly forged. The random forgery of domain names to be resolved can not only prevent filtering, but also reduce the possibility of hitting the DNS cache and consume as many CPU resources as possible on the DNS server.
About the DNS Query Flood code, I wrote a code in July 2011 to test the server performance, the link is http://www.icylife.net/yunshu/show.php? Id = 832. Similarly, the code is used only for testing purposes to reduce the attacks.

1.3. HTTP Flood
At this stage, the SYN Flood and DNS Query Flood described above have been able to effectively defend against HTTP Flood attacks. HTTP Flood is an attack on Web services in Layer 7 protocol. Its major harm is manifested in three aspects: convenient launch, difficult filtering, and far-reaching impact.
Both SYN Flood and DNS Query Flood require attackers to control a large number of bots with root permissions. It takes a lot of time and effort to collect a large number of root permissions. In the course of the attack, the hacker finds a zombie opportunity due to abnormal traffic, and the attacker's resources are quickly lost, as a result, the attack intensity is significantly reduced and cannot be sustained for a long time. HTTP Flood attacks are different. Attackers do not need to control a large number of bots. Instead, they use port scanning programs to search for anonymous HTTP proxies or SOCKS proxies on the Internet, an attacker uses an anonymous proxy to initiate an HTTP request to the target. Anonymous proxy is a rich resource. It is not difficult to obtain the proxy in a few days. Therefore, the attack is easy to initiate and can be sustained in a long time.
On the other hand, HTTP Flood attacks are initiated at the HTTP layer, which are closely related to website businesses and try to imitate the webpage request behavior of normal users, it is difficult for security vendors to provide a set of general solutions that do not affect user experience. Working well in one place can lead to a large number of false positives in another scenario.
Finally, HTTP Flood attacks will cause serious chain reactions, not only directly leading to slow Web front-end responses, it also indirectly attacks business-layer logic such as backend Java and more backend database services, increasing their pressure and even affecting log storage servers.
Interestingly, HTTP Flood also has a historical nickname called CC attack. CC is short for Challenge Collapsar, and Collapsar is a DDoS defense device of a famous security company in China. From the current situation, not only Collapsar, but all hardware defense devices are still being challenged and the risks are not eliminated.

1.4. Slow connection attack
When an attack is initiated, the first response is massive traffic and massive packets. However, there is an attack that does the opposite. It is known as slow, so that some attack targets are killed and do not know how to die. This is a slow connection attack, the most representative is the Slowloris invented by rsnake.
The HTTP protocol stipulates that the end of an HTTP Request indicates that the client has ended sending and the server has started to process the Request. So what if I never send it? Slowloris uses this to defend against DDoS attacks. The attacker sets the Connection as Keep-Alive in the HTTP request header, and requires the Web Server to Keep the TCP Connection intact. Then, the attacker slowly sends a key-value format data to the Server every several minutes, for example, a: B. The server waits until the HTTP header is received. If the attacker uses multiple threads or a slave machine to perform the same operation, the Web container of the server will soon be occupied by the attacker with TCP connections and will not accept new requests.
Soon, Slowloris began to show various variants. For example, the POST method submits data to the Web Server, fills in a large Content-Length but slow one byte and one byte of POST real data Content, and so on. Rsnake also provides a test code for Slowloris attacks. For details, see http://ha.ckers.org/slowloris/slowloris.pl.

2. Advanced DDoS attack

2.1. Hybrid attack
The above describes several basic attack methods, any of which can be used to attack the network, or even kill giant websites such as Alibaba, Baidu, and Tencent. However, these are not all. Different levels of attackers can launch completely different DDoS attacks.
Advanced attackers never use a single method to launch attacks, but flexibly combine them according to the target environment. Common SYN Flood is easily filtered out by traffic cleaning devices by reverse detection, SYN Cookie, and other technical means. However, if SYN Flood is mixed with SYN + ACK packets, each spoofed SYN packet has a corresponding spoofed client validation packet, the corresponding content indicates that the source IP address, source port, destination IP address, destination port, TCP window size, and TTL all comply with the same TCP Flow characteristics of the same host, the reverse detection and SYN Cookie performance pressure of traffic cleaning devices will increase significantly. In fact, SYN data packets with various other flag spaces have special attack effects, which are not described here. It also has unique techniques for DNS Query Flood.
First, DNS can be divided into common DNS and Authorized Domain DNS, attack common DNS, IP address needs to be randomly forged, and indicates that the server requires recursive resolution; but the attack authorization domain DNS, counterfeit source IP addresses should not be purely random, but should be the DNS addresses of ISPs around the world collected in advance, in order to achieve the maximum attack effect, make the traffic cleaning device in the embarrassing situation of adding an IP blacklist or not adding an IP blacklist. Adding a message will cause a large number of false positives. If you do not add a blacklist, you need to perform reverse detection for each message to increase the performance pressure.
On the other hand, the domain names that need to be randomly requested in order to increase the pressure on the cleaning equipment to hit the cache, but note that the domain names to be resolved must carry a certain regularity in forgery, for example, if a part of a domain name is forged and solidified, it is used to break through the whitelist set by the cleaning device. The principle is very simple. Tencent servers can resolve only Tencent's domain names, and completely random domain names may be discarded directly and need to be fixed. However, if it is completely fixed, it is easy to directly discard it. Therefore, it is necessary to forge part of it.
Second, the attack on DNS should not only focus on UDP ports. According to the DNS protocol, TCP ports are also standard services. During attacks, UDP and TCP attacks can be performed simultaneously.
The focus of HTTP Flood is to break through the front-end cache and directly reach the Web Server through the field settings in the HTTP header. In addition, HTTP Flood is also critical to the selection of targets. Generally, attackers can search for pages that require massive data queries as attack targets. This is very correct, it can consume as many resources as possible on the server. However, this type of attack is easily identified by cleaning devices through man-machine identification. How can this problem be solved? It is very simple. Try to select the pages that normal users access through the APP. Generally, they are various Web APIs. Both normal users and malicious traffic come from apps. The difference between humans and machines is very small. It is difficult to distinguish between normal users and malicious traffic.
Slow attacks, such as these, use clever means to occupy connections without releasing them, but they are also a double-edged sword. Every TCP connection exists on the server, you also need to consume resources to maintain the TCP status, so you cannot maintain too many connections. If this problem can be solved, the attack will be greatly enhanced. That is to say, Slowloris can launch an attack through stateless, capture the TCP serial number through sniffing on the client, and confirm to maintain the TCP connection, the system kernel does not need to pay attention to various TCP status changes. One notebook can generate up to 65535 TCP connections.
As described above, all attacks at the technical level are enhanced. In terms of people, there can also be some other means. If SYN Flood initiates a large number of front-end attacks, coupled with Slowloris slow connection, how many people can discover the secrets? Even if the server goes down, it may only find SYN attacks that want to strengthen TCP layer cleaning while ignoring the behavior at the application layer. All kinds of attacks can be combined to achieve the maximum effect. The selection of attack time is also a key, for example, when the maintenance personnel have lunch, the maintenance personnel are stuck on the road after work, when the wireless network adapter does not have signals in the subway, and when the target enterprises hold large-scale activity traffic spikes.
Here, we only describe purely attack behaviors. Therefore, we will not provide any code or introduce them in depth.

2.2. Attacks from P2P networks
In the previous attack methods, more or less some machines are required. Even HTTP Flood requires a large number of anonymous proxies to be searched. If there is an attack, you only need to issue some instructions, and some machines will automatically execute the attack, which is the perfect solution. This attack has already appeared, that is, the P2P network attack.
As we all know, P2P users and traffic on the Internet are huge numbers. If they all download data from a specified location and connect thousands of real IP addresses, no device can support it. Taking BT downloading as an example, fake seeds of some popular videos and publish them to seo/seo.html "target =" _ blank "> The search engine is enough to cheat many users and traffic, however, this is only a basic attack.
Advanced P2P attacks directly fool the resource management server. For example, the Thunder client uploads the resources it finds to the resource management server and pushes them to other users who need to download the same resources. In this way, a link is published. Through reverse protocol, attackers can forge a large number of popular resource information and distribute it through the resource management center, which can spread across the P2P network in an instant. What's even more frightening is that such attacks cannot be stopped, and even the attackers themselves cannot be stopped. The attacks continue until the P2P official team finds a problem updating server and downloads the user to restart and download the software.

3. Summary
Due to the length constraints, I have written so much about the introduction of DDoS attacks, and I am not willing to elaborate on this. Understanding that so much defense is enough.
In general, DDoS attacks can be very clever and elegant. The best of luck

1. Defense basis

1.1. What is the attack traffic?
When talking about DDoS defense, you must first know how many attacks have been suffered. This problem seems simple, but there are actually many unknown details in it.
Taking SYN Flood as an example, in order to improve the sending efficiency and generate more SYN wait queues on the server, when the attack program fills the header, the IP header and TCP header do not fill in the optional fields, therefore, the length of the IP header is exactly 20 bytes, and the TCP header is also 20 bytes, a total of 40 bytes.
For Ethernet, the minimum packet length must be 46 bytes, and the attack packet is only 40 bytes. Therefore, when sending packets, the network adapter performs some processing at the end of the TCP header, fill 6 zeros to meet the minimum package length requirements. At this time, the entire data packet is a 14-byte Ethernet header, a 20-byte IP header, and a 20-byte TCP header, in addition, the six bytes of 0 filled due to minimum packet length requirements are 60 bytes in total. But this is not over yet. The CRC test is required for data transmission over Ethernet. The network adapter checks the CRC of the data packet before sending the data, and attaches the 4-byte CRC value to the end of the packet header. At this time, the packet length is no longer 40 bytes, but 64 bytes. This is the SYN packet attack. The packet structure is as follows:
| 14-byte Ethernet header | 20-byte IP header | 20-byte TCP | 6-byte padding | 4-byte check | target MAC | Source MAC | protocol type | IP header | TCP header | Ethernet fill | CRC test |
1
 
| 14-byte Ethernet header | 20-byte IP header | 20-byte TCP | 6-byte padding | 4-byte check | target MAC | Source MAC | protocol type | IP header | TCP header | Ethernet fill | CRC test |

To 64 bytes, the SYN packet has been filled and the transmission is ready. The attack packet is very small and far from the 1500 bytes of the maximum transmission unit (MTU), so it will not be split. So these data packets are like canned food in the production pipeline. Is one package tightly packed together with one package for transmission? In fact, this is not the case.
During transmission over Ethernet, there are also preamble and inter-frame gap ). The forward code occupies 8 bytes (bytes), that is, 64 bits. The first 7 bytes of the forward code are separated by 10, 10, and 1. However, the eighth byte is changed to 10101011. When the host detects two consecutive 1 bytes, it will know that the data starts later. During network transmission, the data structure is as follows:
| 8-byte authorization code | 6-byte MAC address | 6-byte source MAC address | 2-byte upper-layer protocol type | 20-byte IP header | 20-byte TCP header | 6-byte Ethernet padding | 4-byte CRC test | 12-byte frame spacing |
1
 
| 8-byte authorization code | 6-byte MAC address | 6-byte source MAC address | 2-byte upper-layer protocol type | 20-byte IP header | 20-byte TCP header | 6-byte Ethernet padding | 4-byte CRC test | 12-byte frame spacing |

With the above Foundation, we can now start to calculate the attack traffic and the line rate of network devices. When the minimum SYN Packet that only fills the IP header and TCP header runs on the Ethernet, the maximum PPS (Packet Per Second) supported for the Mbit network) is 100 × 106/(8*(64 + 8 + 12) = 148809,100 0Mbit network, the maximum PPS supported is 1488090.

1.2. SYN Flood defense
As described above, SYN Flood attacks consume a lot of server CPU and memory resources and occupy the SYN wait queue. Correspondingly, we can modify the kernel parameters to effectively alleviate this problem. The main parameters are as follows:
Net. ipv4.tcp _ syncookies = 1net. ipv4.tcp _ max_syn_backlog = 8192 net. ipv4.tcp _ synack_retries = 2
1
2
 
Net. ipv4.tcp _ syncookies = 1net. ipv4.tcp _ max_syn_backlog = 8192
Net. ipv4.tcp _ synack_retries = 2

Enable SYN Cookie, set the maximum SYN queue length, and set the maximum number of retries of SYN + ACK.
SYN Cookie is used to relieve the pressure on server resources. Before enabling, the server immediately allocates storage space after receiving the SYN packet and Randomizes a number to send the SYN + ACK packet as the SYN number. Then, save the connection status information and wait for the client to confirm. When the SYN Cookie is enabled, the server no longer allocates storage space and uses the random number algorithm based on the time seed to set a SYN number to replace the completely random SYN number. After the SYN + ACK confirmation message is sent, the cleared resource does not save any status information. Until the server receives the final ACK packet from the client, it uses the Cookie test algorithm to identify whether it matches the serial number of the sent SYN + ACK Packets. If it matches the packet, it completes the handshake and discards the packet if it fails. Of course, the above advanced attacks include SYN hybrid ACK Attack methods, which are used to defend against such attacks. The advantages and disadvantages of these attacks are determined by the hardware configuration of both parties. tcp_max_syn_backlog is used by the server's memory resources, in exchange for a larger length of the waiting queue, so that the attack data packets do not occupy all connections and normal users cannot complete the handshake. Net. ipv4.tcp _ synack_retries is used to reduce the number of server SYN + ACK message retries and release the waiting resources as soon as possible. These three measures correspond to the three types of attacks, and completely remedy the problem. However, these measures are a double-edged sword. They may consume more memory resources on the server, or even affect normal users to establish TCP connections. Therefore, you must evaluate the server hardware resources and set the attack size with caution.
In addition to customizing the TCP/IP protocol stack, another common practice is to discard the first packet of TCP and identify normal users and attack packets using the retransmission mechanism of TCP. After the defense device receives a SYN packet from an IP address, it simply compares whether the IP address exists in the whitelist and forwards it to the backend. If the IP address does not exist in the whitelist, check whether the IP address is the first SYN packet in a certain period of time. If not, check whether the IP address is retransmitted. If the IP address is retransmitted, the request is forwarded and added to the whitelist, if not, it is discarded and added to the blacklist. If it is the first SYN packet, it is discarded and waited for a period of time to try to accept the SYN re-transmission packet of the IP address. If the request times out, the attack packet is blacklisted.
The first packet discard scheme has a slight impact on the user experience, because discarding the first packet re-transmission will increase the response time of the service. In view of this, a better TCP Proxy scheme is developed. All SYN data packets are accepted by the cleaning device and processed according to the SYN Cookie scheme. The IP address with TCP three-way handshake established with the device is determined as a valid user to be added to the whitelist, and the device performs three-way handshake with the real server to disguise the real client IP address, and then forwards the data. However, IP addresses that do not complete three handshakes with the device within the specified time are determined to be blocked by malicious IP addresses for a certain period of time. In addition to SYN cookies combined with TCP Proxy, cleaning devices also have the ability to detect malformed TCP flag data packets, normal access and malicious behavior are identified by testing the client response to the returned unexpected response to the SYN packet.
The hardware of the cleaning device has a special network processor chip, a specially optimized operating system, and a TCP/IP protocol stack, which can handle extremely large traffic and SYN queues.

1.3. HTTP Flood defense
HTTP Flood attack defense is mainly implemented through caching. As far as possible, the cache of the device directly returns results to protect the backend services. Large Internet enterprises may cache large CDN nodes.
When advanced Attackers penetrate the cache, the cleaning device intercepts HTTP requests for special processing. The simplest method is to make statistics on the HTTP request frequency of the source IP address. IP addresses that are more than a certain frequency are blacklisted. This method is too simple, easy to lead to false positives, and cannot block attacks from proxy servers, so it is gradually abolished and replaced by the JavaScript jump to human-machine identification solution.
HTTP Flood is a simulated HTTP request by a program. Generally, it does not parse the data returned by the server, nor parse JS and other code. Therefore, when the cleaning device intercepts an HTTP request, a special JavaScript code is returned. The normal user's browser will handle the request and the normal jump will not affect the use of the code, but the attack program will attack the blank area.

1.4. DNS Flood defense
DNS attack defense also provides defense methods similar to HTTP. The first solution is cache. The second is resend. It can directly discard the DNS message, resulting in UDP-level request resend. It can be a special response that forces the client to use the TCP protocol to resend the DNS query request.
In particular, for the protection of the Authorized Domain DNS, the device extracts the list of received DNS domain names and the list of isp dns ip addresses for backup during normal business periods. During attacks, all requests except this list are discarded, greatly reducing the performance pressure. For domain names, the same domain name whitelist mechanism is implemented. Domain name resolution requests in non-whitelist are discarded.

1.5. Defense against slow connection attacks
Slowloris is easy to defend against attacks. There are two main solutions.
The first is to calculate the length of each TCP connection and calculate the number of packets passed per unit time for precise identification. In a TCP connection, too few HTTP messages and too many packets are abnormal. Too few may be slow connection attacks, and too many may be HTTP Flood attacks using the HTTP 1.1 protocol, send multiple HTTP requests in a TCP connection.
The second is to limit the maximum allowed time for HTTP header transmission. After the specified time, the HTTP Header has not been transmitted. The source IP address is determined to be a slow connection attack, the connection is interrupted, and the request is blacklisted.

2. Enterprise-level defense
Internet enterprises mainly use the above basic defense methods to defend against DDoS attacks. The focus is on using monitoring, organization, and processes to ensure timely and correct use of these methods, the attack policy changes accordingly.

2.1. Exception monitoring
Monitoring requires the concept of multi-layer monitoring and in-depth defense, from the backbone network, IDC entry network BPS, PPS, protocol distribution, the number of VIP new connections, concurrent connections, BPS, CPU status from PPS to the host layer, TCP new connections status, and TCP concurrent connections status at the server load balancer layer, the monitoring system is deployed at multiple points, such as the business processing volume and business connectivity at the business layer. Even if one monitoring site fails, other monitoring sites can provide alarm information in a timely manner. The information of multiple points can be combined to help you accurately identify attack targets and methods.

2.2. Procedures and plans and exercises
Once an exception is found, immediately start the emergency process in the virtual defense organization. The defense organization should include enough comprehensive personnel, including at least the monitoring department, O & M Department, network department, Security Department, customer service department, and business department. All personnel must have 2-3 backups. After the process is started, in addition to manual processing, it should also contain certain automatic processing and semi-automatic processing capabilities. For example, automated attack analysis, determination of attack types, and automated and semi-automated defense policies. Before security personnel are in place, the department that first discovers the attack can take some mitigation measures.
In addition to the process at the arrival of DDoS, more work is done before the arrival of the attack. It mainly includes CDN node deployment, DNS settings, and process drills. For enterprises, having multiple CDN nodes is a key indicator of DDoS defense capacity. When a data center cannot bear massive data volumes, you can use DNS round robin to direct traffic to multiple distributed nodes and use defense devices to process traffic in different headers. Therefore, the TTL value of DNS needs to be set small enough for fast switchover, and various VIP settings for each CDN node need to be fully prepared.

3. Summary
In the era of virtualization, different services of massive users are on the same physical machine platform, and DDoS attacks are more and more likely. In addition, the attack on a user may involve a large number of other users, and the harm is significantly magnified. Therefore, defense is particularly important. Alibaba Cloud's virtualized cloud computing service suffered an average of about 200 DDoS attacks every day, and the maximum traffic reached nearly 80 Gbit/s. All these attacks were automatically handled within one minute, keep customers away from DDoS threats and focus on business development.
In general, the main task of DDoS defense is to accumulate behind the scenes. Ten minutes on the stage, ten years of success, insufficient resource preparation, insufficient emergency drills, and rich experience in handling, DDoS attacks will be a nightmare for everyone.