Defense and Analysis of DDoS attacks in CentOS

1 DDoS: Distributed Denial of Service

DDoS attacks, that is, distributed denial-of-service attacks, are common attacks that are difficult to prevent. Hackers generally attack domain names by creating botnets, that is, embedding specific malicious programs in computers to control a large number of bots (machines that can be remotely controlled by hackers ), then, attackers send attack commands to a relatively large number of "bots" through a relatively concentrated number of computers, resulting in a sharp increase in traffic in a short period of time. The main purpose is to make the specified target unable to provide normal services, or even disappear from the Internet. It is one of the most powerful and difficult to defend against attacks.

According to the method of initiation, there are three types:

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. Typical examples of such attacks are ICMPFlood and UDPFlood, 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, which both have advantages and disadvantages. It not only utilizes protocol and system defects, but also has massive traffic, such as SYNFlood attacks and DNSQuery Flood attacks, is the current mainstream attack method.

2. attack methods

2.1 SYN Flood

SYN Flood attacks exploit the three-way handshake of TCP: 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.

2.2 DNS Query Flood

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. Random forgery of domain names to be resolved can not only prevent filtering, but also reduce the hit rate.The possibility of DNS caching will consume as many CPU resources as possible on the DNS server.

2.3 HTTP Flood

HTTP Flood is an attack on Web Services at the Layer 7 protocol (Application Layer. Its major harm is manifested in three aspects: convenient launch, difficult filtering, and far-reaching impact.

HTTP Flood attacks search for anonymous HTTP proxies or SOCKS proxies on the Internet through port scanning programs. Attackers can use anonymous proxies to initiate HTTP requests to attack targets. 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.

HTTP Flood attacks are initiated at the HTTP layer. They try to imitate the webpage request behavior of normal users and are closely related to WebSite Services. It is difficult for security vendors to provide a set of common solutions that do not affect user experience.

HTTP Flood attacks can cause serious chain reactions, not only directly lead to slow Web Front-end responses, but also indirectly attack business layer logic such as backend Java and more back-end database services, they increase the pressure and even affect log storage servers.

2.4 slow connection attack: Sloworis

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.

3 Defense

3.1 SYN Flood defense

SYN Flood attacks consume a lot of server CPU and memory resources, and occupy a full SYN waiting queue. Correspondingly, we can modify the kernel parameters to effectively alleviate this problem. The main parameters are as follows:

Net. ipv4.tcp _ syncookies = 1 # enable SYN cookies

Net. ipv4.tcp _ max_syn_backlog = 8192 # set the maximum SYN queue length

Net. ipv4.tcp _ synack_retries = 2 # set the maximum number of Retries for 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.

Tcp_max_syn_backlog uses 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.

Ps: It may consume more memory resources on the server, or even affect normal users to establish TCP connections. Therefore, you need to evaluate the server hardware resources and attack size and set them with caution.

3.2 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.

3.3 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.

3.4 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 HTTP1.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 is exceeded, the HTTPHeader has not been transmitted yet. The source IP address is regarded as a slow connection attack, and the connection is interrupted and added to the blacklist.

4. New attack methods

DNS reflection/amplification attacks use the DNS infrastructure on the Internet to enlarge the traffic generated by attacks. DNS is an important part of the Internet infrastructure for host name to IP Address Resolution. DNS reflection/amplification attacks send queries to multiple open DNS Resolvers by using multiple client bots (bots botnets, as a result, a large amount of attack traffic is generated from a wide range of sources (over 30 K open parser is used during the Spamhaus attack ).

-- Rango Chen