Produced by: Siqi GUO, Qiwen LUO
Increasingly Serious Reflection Attacks
Reflection attacks, as nothing new, have become one of the most troublesome and common DDoS attacks and are dominant in bandwidth consumption DDoS attacks. According to NSFOCUS’s latest 2020 DDoS Attack Landscape, reflection attacks made up 34% of all DDoS attacks in 2020. Compared with 2019, 2020 saw a significant increase in the number and proportion of reflection attacks. From the attack source type, the proportion of reflectors increased to 14% in 2020.
TCP Reflection Attacks like an Assassin
NTP (Network Time Protocol) reflection, SSDP (Simple Service Discovery Protocol) reflection, and Memcached reflection attacks familiar to us are based on the User Datagram Protocol (UDP). In the analysis of attack types, it is rare to discover reflection attacks based on the Transmission Control Protocol (TCP).
It is true that TCP reflection attacks are uncommon. Attackers tend to choose UDP that can amplify attack traffic by dozens or even hundreds of times to achieve high profits at low costs.
In the offensive-defensive battle, though TCP reflection attacks cannot achieve the same amplification effects as UDP reflection attacks, they are covert and difficult to protect against. If UDP reflection attacks are a cannon, TCP reflection attacks are like an assassin.
TCP Reflection Attacks
By conducting in-depth analysis of a large number of attack flow packets and attempting to perform reverse detection on various reflection servers, we have already figured out usual practices of TCP reflection attacks. Here, we elaborate on principles and characteristics of TCP reflection attacks, with a view to helping you have a better idea of such attacks.
An attacker obtains large quantities of open ports of public network servers as reflectors in advance. When launching an attack, the attacker sends lots of SYN packets, source IP addresses of which are spoofed as the IP address of the intended target. After receiving these SYN packets, public network servers send back response packets to the target, thus generating reflection attack flows and eventually causing a denial of service.
After receiving SYN packets, the servers reply with SYN-ACK packets and initiate a half-open connection. Usually, however, the attacker sends the same server multiple SYN packets carrying the same quintuplet (source IP address, destination IP address, source port, destination port, and protocol type) within a short time. Then, session conflicts occur between subsequent SYN packets and the first SYN packet. Methods of handling such a situation vary from server to server.
Here, we classify common TCP reflection flows into the following types:
- Standard reflection flows
- SYN cookies
- Anti-portscan
- Windows server reflection
1.1 Standard Reflection Flows
Linux kernel protocol stacks handle SYN packets in accordance with standard TCP protocol specifications. Attack flows reflected by this type of server are the most common TCP reflection attack flows. Such reflection flows are usually composed of SYN-ACK packets, ACK packets, and a small number of RST packets, as shown in the following figure.
Upon the receipt of the first SYN packet, Linux protocol stacks reply with a SYN-ACK packet. The way Linux protocol stacks handle subsequent SYN packets carrying the same quintuplet is related to SEQ1 of the first SYN packet, WIN (size of server windows), and SEQ2 of the current SYN packet. Details are as follows:
(1) If SEQ1 is the same as SEQ2, a SYN-ACK packet identical to the previous one is returned.
(2) If SEQ2 is smaller than SEQ1 or SEQ2 is greater than SEQ1 + WIN, an ACK packet is returned. If the SEQ number of the ACK packet is that of the first SYN-ACK packet plus 1, the ack_seq number is the SEQ number of the first SYN packet plus 1.
(3) If SEQ2 is greater than SEQ1, but smaller than or equal to SEQ1 + WIN, an RST packet is returned, and the half-open connection is closed.
1.2 SYN Cookie
If a server receives huge quantities of SYN packets carrying different quintuplets within a short time, it initiates massive half-open connections in a very short time. As a result, the half-open connection queue will be used up, and the server cannot handle new connection requests any more. This is especially the case with SYN flood attacks.
To cope with this situation, some servers use the SYN cookie algorithm. Currently, most mainstream operating systems allow configuration of the SYN cookie algorithm. After the algorithm is enabled, when the half-open connection queue is used up and another SYN packet is received, the server will let the SYN cookie algorithm handle half-open connections instead of assigning a half-open connection to the packet.
After receiving an arbitrary SYN packet, the SYN cookie algorithm calculates a special SEQ number based on the quintuplet information, time stamp, and maximum segment size (MSS) of this SYN packet. Besides, it returns the SEQ number in a SYN-ACK packet to the client. If the client is a normal visitor, it will reply with an ACK packet. Then, the server obtains the SEQ number of the SYN-ACK packet from the ack_seq number of the ACK packet and recovers some of the above-mentioned information to verify the reliability of the ACK packet. Only after the ACK packet is confirmed to be reliable can connections be actually assigned to the appropriate client.
Therefore, the reflection packets sent by the server are SYN-ACK packets that are different from those in normal times. Since servers implement the SYN cookie algorithm in different ways, the SEQ numbers of these SYN-ACK packets have different characteristics.
1.2.1 Standard Implementation
In standard implementation, the SEQ number of a SYN-ACK packet is calculated in the following way:
- Let t represent a time stamp that is slowly incremental (usually moved to 6 bits to the right and increasing every 64 seconds).
- Let m represent the MSS informed by the client. Due to the data length limit, MSS is encoded into a 3-bit value.
- Let s represent a 24-bit value calculated from the quintuplet information through an encrypted hash function.
- Rule for calculating the SEQ number: t mod 32 for the most significant five bits, m for the next three bits, and s for the least significant 24 bits.
Thus, if a server receives multiple SYN packets with the same quintuplet and MSS within a short time, it will reply with multiple identical SYN-ACK packets.
1.2.2 Linux Implementation
The Linux implementation is basically aligned with the standard implementation in the main ways of handling the SYN cookie algorithm but differs in how to calculate the SEQ number. Following is the way to calculate the SEQ number:
In the preceding calculation formula, sseq is the number of a SYN packet on the client, count is the time stamp, and data is the MSS value that is informed by the client and expressed in four forms in new kernels.
Obviously, in Linux servers, SEQ numbers of SYN-ACK packets returned by the SYN cookie algorithm are correlated with those of SYN packets received by the algorithm. , SEQ numbers of SYN-ACK packets change with those of SYN packets.
1.3 Anti-Portscan
By observing attack flows, we found that after receiving an arbitrary SYN packet, some servers just reply with SYN-ACK packets with random SEQ numbers.
Through analysis and tests, we basically confirmed that this type of servers is a kind of honeypot or that the servers themselves run a certain anti-portscan protection program. After receiving typical port sniffing packets, such servers reply with some response packets indiscriminately, thus causing scanners to be unable to confirm whether the ports have been opened.
In addition, such servers reply with SYN-ACK packets to arbitrary SYN packets they receive. SEQ numbers of these SYN-ACK packets may have their own distinctive characteristics due to different implementation ways.
In order to prevent malware from scanning port information, such servers reply with SYN-ACK packets indiscriminately after receiving SYN packets directed to arbitrary ports. Consequently, when these servers are used for reflection attacks, attackers can choose arbitrary port numbers as reflectors. Some traditional algorithms that prevent reflection attacks apply protection policies to specific ports, and such servers invalidate the policies, making protection more difficult.
1.4 Window Servers
Windows servers are similar to Linux servers to some degree in the way of handling SYN packets. By conducting a reflection test on a Win7 and Win10 server respectively, we found that the way they handle SYN packets is basically the same and is also related to SEQ1, SEQ2, and WIN. However, the handling way is different from Linux servers:
- If SEQ2 is smaller than SEQ1 or greater than SEQ1 + WIN, the server will again send the same SYN-ACK packet as the previous one.
- If SEQ2 is no less than SEQ1, but smaller than SEQ1 + WIN, the server will not reply with any packets. Instead, it waits for the SYN-ACK packet to be retransmitted.
- In addition, there is a special case, that is, if SEQ2 = SEQ1 + 1, the server will reply with an RST packet and close the session.
Protection Roadmap for TCP Reflection Attacks
Reflection flows generated by TCP reflection attacks have complex characteristics and are difficult to protect against. Traditional protection algorithms are difficult to deliver effective protection.
- Attack flows generated by TCP reflection attacks can perform certain protocol stack behaviors and are more confusing than the attacks launched by using traditional attack tools. Therefore, they are more difficult to defend against.
- It is not easy to differentiate packets of TCP reflection attacks from those of normal communication processes, for they are similarly composed of SYN-ACK packets, ACK packets, and small quantities of RST packets.
- Diverse server types and configurations on the Internet lead to more complex reflection attack flows.
At present, traditional defense methods are mainly to block TCP packets with a source port of 0–1024 and a destination port of 0–1024 through rules, or block the source port of TCP reflection based on packet capture. Since more and more service ports are opened on the Internet, this method of using static rules usually cannot adapt to changes in the attack landscape, thus failing to work to the best effect.
Based on in-depth research on various reflectors and continuous offensive and defensive practices, NSFOCUS has developed a set of multidimensional comprehensive algorithms that integrate dynamic identification and behavior analysis, which can effectively defend against TCP reflection attacks and have achieved a good protection effect in the international cloud cleaning environment.
