[Technical Analysis] In-depth and easy-to-understand: Introduction to the attack of network attack and defense

DDoS (Distributed Denial of Service) attacks are one of the most powerful and difficult attacks to defend against because the main purpose of DDoS attacks is to prevent a designated target from providing normal services or even disappear from the Internet.

DDoS can be simply divided into three categories according to the way they are initiated.

The first category wins by forceMassive data packets swarm from all corners of the Internet, blocking the entrance to IDC, rendering various powerful hardware defense systems and fast and efficient emergency processes useless. Typical examples of this type of attack are ICMP Flood and UDP Flood, which are now uncommon.

The second category wins by cleverness, smart and imperceptible, sending a package every few minutes or even only needs a package can make the luxurious configuration server no longer respond. This type of attack is mainly launched by exploiting vulnerabilities in protocols or software, such as Slowloris attacks, hash collision attacks, etc., and requires specific environmental coincidences.

The third category is a mixture of the above twoIt not only takes advantage of the defects of the protocol and system, but also has a large amount of traffic, such as SYN Flood attack and DNS Query Flood attack, which is the current mainstream attack method.

This article will describe these most common and representative attack methods one by one and introduce their defense options.

SYN Flood is one of the most classic DDoS attacks on the Internet, first appearing around 1999, with Yahoo being the most famous victim at the time. SYN Flood attacks exploit TCP triple handshake flaws that can render the target server unresponsive and difficult to trace at a small cost.

The standard TCP three-way handshake process is as follows:

• The client sends a TCP packet containing the SYN flag, SYN is synchronize, and the synchronization packet indicates the port used by the client and the initial serial number of the TCP connection.
• After receiving the SYN packet from the client, the server will return a SYN+ACK (i.e., Acknowledgement confirmation) packet, indicating that the client's request is accepted, and the TCP initial serial number is automatically added by 1.
• The client also returns an acknowledgment message ACK to the server, and the TCP serial number is also added by 1.
  

After these three steps, the TCP connection is established. In order to achieve reliable transmission, the TCP protocol has set up some exception handling mechanisms during the three handshakes. In the third step, if the server does not receive the final ACK acknowledgment packet from the client, the server will remain in the SYN_RECV state, add the client IP address to the waiting list, and resend the SYN+ACK packet in the second step. Reposts are usually performed 3-5 times, and the waitlist is polled once at intervals of about 30 seconds to retry all clients. On the other hand, after the server sends out the SYN+ACK packet, it pre-allocates resources to store information for the upcoming TCP connection, which is retained while waiting for the retry. More importantly, if the server resources are limited, the SYN_RECV state that can be maintained will no longer accept new SYN packets after exceeding the limit, that is, new TCP connections will be rejected.

SYN Flood uses the TCP protocol settings above to achieve the purpose of the attack. Attackers disguise a large number of IP addresses to send SYN packets to the server, and since the forged IP addresses are almost impossible to exist, almost no device will return any response to the server. As a result, the server maintains a huge waiting list and keeps retrying to send SYN+ACK packets, which consumes a lot of resources and cannot be released. More importantly, the SYN_RECV queue of the attacked server is filled with malicious packets, and new SYN requests are no longer accepted, and legitimate users cannot complete three handshakes to establish TCP connections. In other words, the server was denied service by SYN Flood.

If you are interested in SYN Flood, you can take a look at the http://www.icylife.net/yunshu/show.php?id=367, which I wrote in 2006, and later made several changes, fixed bugs, and reduced the aggressiveness, and was purely used for testing.

As the most basic and core service of the Internet, DNS is naturally one of the important targets of DDoS attacks. Bringing down a DNS service can indirectly bring down a company's entire business, or a network service in a region. Some time ago, the popular hacker group anonymous also announced that it would attack 13 DNS servers on the global Internet, but in the end it did not succeed.

UDP attacks are the easiest attack method to initiate massive traffic, and random source IP forgery is difficult to trace. However, filtering is easier because most IPs do not provide UDP services, so you can just discard UDP traffic. Therefore, pure UDP traffic attacks are relatively rare now, and they are replaced by DNS Query Flood attacks carried by the UDP protocol. Simply put, DDoS attacks launched on the higher the protocol, the more difficult it is to defend against because the higher the protocol, the more business-related it is, and the more complex the defense system faces.

DNS Query Flood is when an attacker manipulates a large number of sockpuppet machines to launch a large number of domain name query requests to the target. To prevent ACL-based filtering, packet randomness must be improved. A common practice is to randomly forge the source IP address, randomly forge the source port, and other parameters at the UDP layer. At the DNS protocol layer, the query ID is randomly forged along with the domain name to be resolved. In addition to preventing filtering, random forged domain names to be resolved can also reduce the likelihood of hitting the DNS cache and consume as much CPU resources as possible of the DNS server.

Regarding the code for DNS Query Flood, I wrote a code in July 2011 to test server performance, and the link is http://www.icylife.net/yunshu/show.php?id=832. Similarly, this code is artificially less aggressive and is only for testing purposes.

The SYN Flood and DNS Query Flood described above can be effectively defended against at this stage, and the real headache for major manufacturers and Internet companies is HTTP Flood attacks. HTTP Flood is an attack on a web service on a seventh-layer protocol. Its great harm is mainly manifested in three aspects: convenient initiation, difficult filtering, and far-reaching impact.

Both SYN Flood and DNS Query Flood require attackers to control a large number of bots with root privileges. It takes time and effort to collect a large number of root privileges, and during the attack, the puppet machine is slow to replenish due to the rapid loss of resources by the attacker due to abnormal traffic discovered by the administrator, resulting in a significant reduction in the attack intensity and cannot be sustained for a long time. HTTP Flood attacks are different, attackers do not need to control a large number of bots, but instead use port scanners to find anonymous HTTP proxies or SOCKS proxies on the Internet, through which the attacker initiates HTTP requests to the attack target. Anonymous proxies are a relatively rich resource, and it is not difficult to obtain proxies in a few days, so attacks are easy to initiate and can last for a long time.

On the other hand, HTTP flood attacks are launched at the HTTP layer, which vigorously mimics the web page request behavior of normal users, which is closely related to the website business, making it difficult for security vendors to provide a common solution that does not affect the user experience. Rules that work well in one place, changing scenarios can lead to a large number of manslaughter.

Finally, HTTP flood attacks can cause serious chain reactions, not only directly causing slow response from the attacked web front-end, but also indirectly attacking the back-end Java and other business layer logic and back-end database services, increasing their pressure and even affecting log storage servers.

Interestingly, HTTP Flood also has a historical nickname called CC attack. CC is an abbreviation for Challenge Collapsar, which is a DDoS protection device from a well-known security company in China. Judging from the current situation, not only Collapsar, but all hardware defense equipment is still being challenged, and the risk has not been lifted.

When it comes to attacks, the first reaction is massive traffic and massive packets. But there is an attack that does the opposite, known for being slow, so that some attack targets are killed without knowing how they die, which is the slow connection attack, the most representative is Slowloris invented by rsnake.

The HTTP protocol stipulates that HTTP requests end in \r\n\r\n, indicating that the client has finished sending and the server has started processing. So what happens if you never send \r\n\r\n? Slowloris uses this to its advantage in DDoS attacks. The attacker sets the Connection to Keep-Alive in the HTTP request header, asks the web server to keep the TCP connection not disconnected, and then slowly sends a key-value format to the server every few minutes, such as a:b\r\n, causing the server to think that the HTTP header has not been received and waits. If an attacker uses multithreading or a puppet to do the same, the server's web container will quickly become overwhelmed by the attacker and will no longer accept new requests.

Soon, various variants of Slowloris began to appear. For example, the POST method submits data to the Web Server, fills a large Content-Length but slow byte by byte POST real data content, etc. Regarding the Slowloris attack, rsnake also gives a test code, see http://ha.ckers.org/slowloris/slowloris.pl.

The above introduces several basic attack methods, any of which can be used to attack the network, and even defeat giant websites such as Alibaba, Baidu, and Tencent. But that's not all, different levels of attackers can launch completely different DDoS attacks, and the use of them is the same thing.

Advanced attackers never use a single vector to attack, but flexibly combine them based on the target environment. Ordinary SYN Flood is easy to be filtered out by traffic cleaning devices through reverse detection, SYN cookies and other technical means, but if SYN+ACK packets are mixed in SYN Flood, so that each forged SYN packet has a corresponding forged client confirmation packet, the corresponding here refers to the source IP address, source port, destination IP, destination port, TCP window size, TTL, etc. are all in line with the characteristics of the same host and the same TCP Flow. The pressure on the performance of reverse detection and SYN cookies of flow cleaning equipment will increase significantly. In fact, SYN data packets and various other flag bits have special attack effects, which are not introduced here. There are also unique techniques for DNS Query Flood.

First of all, DNS can be divided into ordinary DNS and authorized domain DNS, attacking ordinary DNS, the IP address needs to be randomly forged, and the server requires recursive resolution; However, when attacking the authorized domain DNS, the forged source IP address should not be purely random, but should be the DNS addresses of ISPs around the world collected in advance, so as to achieve the maximum attack effect, so that the traffic cleaning device is in the embarrassing situation of adding IP blacklist or not adding IP blacklist. Adding it will lead to a large number of manslaughters, and if you don't add a blacklist, each packet needs to be reverse-probed, which increases the performance pressure.

On the other hand, as mentioned earlier, in order to increase the pressure of cleaning the device, it is necessary to randomize the requested domain name without hitting the cache, but it should be noted that the domain name to be resolved must have a certain regularity in the forgery, such as forging only a certain part of the domain name and solidifying a part to break through the whitelist set by the cleaning device. The reason is simple, Tencent's servers can only resolve Tencent's domain names, and completely random domain names may be directly discarded and need to be solidified. But if it is completely fixed, it is easy to be discarded directly, so it needs to be forged.

Second, attacks on DNS should not focus solely on UDP ports, which are also standard services according to the DNS protocol. In the event of an attack, both UDP and TCP attacks can be carried out at the same time.

The focus of HTTP Flood is to break through the cache on the frontend and directly reach the Web Server itself through the field settings in the HTTP header. In addition, HTTP Flood is also very critical to the selection of targets, and ordinary attackers will choose pages that require a lot of data queries such as search as the attack target, which is very correct and can consume as many resources as possible of the server. But this attack is easy to be identified by cleaning equipment through human-machine identification, so how to solve this problem? It's very simple, try to choose pages that normal users also access through the APP, generally speaking, various Web APIs. Normal users and malicious traffic come from the APP, and the difference between man and machine is very small, and it is difficult to distinguish between basic integration.

Each TCP connection exists on the server side and on itself, and it also needs to consume resources to maintain the TCP state, so the connection cannot be maintained too much. If this can be solved, the aggressiveness will be greatly enhanced, that is, Slowloris can launch attacks in a stateless way, capture the TCP serial number and confirm the maintenance of TCP connections on the client by sniffing, and the system kernel does not need to pay attention to various state changes of TCP, and a notebook can generate up to 65,535 TCP connections.

The previous descriptions are all technical attack enhancements. On the human side, there are other means. If SYN Flood sends out a large number of packets and is accompanied by Slowloris slow connections, how many people will discover the secret? Even if the server goes down, only SYN attacks may be found, trying to strengthen TCP layer cleaning and ignoring the behavior of the application layer. All kinds of attacks can work together to achieve maximum effect. The choice of attack time is also a key point, such as choosing maintenance personnel when they are having lunch, when maintenance personnel are stuck on the road after get off work or when there is no signal on the wireless network card in the subway, and when the target enterprise is holding a large-scale event and the traffic surges.

This is a pure attack, so no code is provided or in-depth explanation.

The previous attack methods more or less require some bots, even HTTP Flood requires searching for a large number of anonymous proxies. If there is an attack, you only need to issue some instructions, and the machine will automatically come up to execute it, which is the perfect solution. This attack has already appeared, and that is from P2P networks.

As we all know, P2P users and traffic on the Internet are an extremely large number. If they all go to a designated place to download data and connect thousands of real IP addresses, no device can support it. Take BT download as an example, forging torrents of some popular videos and posting them to search engines is enough to deceive many users and traffic, but this is only a basic attack.

Advanced P2P attacks are direct spoofing of resource management servers. For example, the Thunder client will upload the resources it finds to the resource management server, and then push them to other users who need to download the same resources, so that a link will be published. Through protocol reversal, attackers forge a large amount of popular resource information and distribute it through the resource management center, which can be instantly spread throughout the entire P2P network. What's even more terrifying is that this attack cannot be stopped, even by the attacker himself, and the attack continues until the P2P official finds the problem and updates the server and the download user restarts the downloaded software.

That's all there is to the introduction to DDoS attacks, and I don't want to go any further—it's enough to understand that so much defense is enough.

In general, DDoS attacks can be dexterous and graceful. The beauty of application lies in the unity of the mind.