While the ongoing implementation of DNSSEC (Domain Name System Security Extensions) continued to drive the growth of DNS Amplification attacks in 3Q 2019, the sharp rise in TCP SYN flood attacks is also worthy of considerable attention. TCP SYN flood isn’t new, but our findings suggest that the techniques behind the latest round of attacks have become ever-more sophisticated. 

How TCP SYN flood attacks work

To start, let’s review how TCP SYN flood attacks work: In order to establish a TCP connection, the three-way TCP handshake must be completed. It begins with the client requesting a connection by sending a SYN message to the server. Then, the server acknowledges by replying with a SYN-ACK message to the client. Finally, the client responds with an ACK message to establish the connection.

During an attack, an attacker sends repeated SYN packets to every port on a targeted server, often using a spoofed IP address. The server, unaware of the attack, receives multiple, apparently legitimate requests to establish communication. It responds to each request with a SYN-ACK packet from each open port.

The malicious client doesn’t send the expected ACK, or, if the IP address is spoofed, never receives the SYN-ACK. Either way, the server under attack will wait for acknowledgement of its SYN-ACK packet. While waiting, the server cannot close down the connection by sending an RST packet. Therefore, the connection remains open. Before the connection times out, another SYN packet comes in. Over time, a large number of half-open connections accumulate until they overflow, denying legitimate clients the ability to establish connections. 

Types of SYN flood attacks

Type 1: Multiple, randomized spoofed-source IPs abusing one destination IP

In Type 1 (56.36% of SYN flood attacks in Q3), an attacker mobilizes a huge number of random, spoofed IP addresses to send an enormous volume of SYN requests to a single IP, causing the victim server to respond with SYN-ACK packets to voluminous malicious requests. Type 1 attacks are easy to mitigate, since most source IPs are only used a few times, but they all target the same destination. Because of this pattern, a TCP authentication filter can easily flag and drop malicious SYN packets from spoofed source IPs. Also, ISPs deploying preemptive measures are likely to drop malicious source IPs that do not belong to them.

Type 2: Multiple, fixed real-source IPs abusing one destination IP

In Type 2 (33.24% of SYN flood attacks in Q3), an attacker leverages a large, fixed pool of real IP addresses (e.g., servers, routers, IoT devices) to generate malicious SYN packets to hit one destination IP per attack. Most Type 2 attacks were smaller than 1Mbps, but in some cases attack sizes were 100Mbps. One extreme case where traffic was diverted from a cloud service provider reached 424.2Mbps.

When targeting an Internet host, an attacker typically prefers to maintain anonymity by spoofing the source IP address. But using real IP addresses of hijacked machines or devices offers certain advantages. Here are the reasons Nexusguard believes that real IP addresses were used in some of the SYN flood attacks we observed: 

• To bypass ISP filters: Packet filtering is ineffective if an attack comes from real IP addresses, especially when the IP addresses come from within the same ASN network.
  
  
• To bypass TCP authentication: TCP authentication uses various methods to check if a client is real or a bot. During authentication, the first and/or first two TCP SYN packets are dropped, until the client sends the second or third packet. If the client passes authentication, the IP is flagged as that of a real user and granted access. If the attacker uses the same pool of IPs to keep sending TCP SYN packets, some will inevitably survive TCP authentication.
  
  
• To leverage IoT botnets: Traffic sent by IoT botnets isn’t spoofed; it corresponds to real IP addresses. Such attacks can have a huge impact on networks and servers. If an attack is large enough, it can incur hefty charges for massive outbound malicious traffic. In some Q3 incidents, botnet-driven SYN flood attacks bypassed TCP authentication and hit the backend directly.

If malicious SYN traffic threatens to break the defence and hit the target server directly, SYN cookie, a technique used to resist IP spoofing attacks, can be the second layer of defence, which is more effective in mitigating Type 1 attacks. But it is much less so in mitigating Type 2 attacks due to a high volume of malicious traffic.

Type 3: Multiple, fixed real-source IPs abusing two different destination IPs

In Type 3 (10.40% of SYN flood attacks in Q3), multiple, fixed spoofed-source IPs are used to abuse two destination IPs. After tracking their sources Nexusguard found that most source IP addresses were valid, leading us to believe that such attacks were Distributed Reflection Denial of Service (DRDoS) attacks. Here, an attacker sends a spoofed SYN packet with the original source IP replaced by the victim’s IP address to random or pre-selected reflection IP addresses.

The service ports at the reflection addresses reply with a SYN-ACK packet to the victim of the spoofed attack. When the victim does not respond with the last ACK packet, the reflection service will continue to retransmit the SYN-ACK packet, resulting in continued reflection.

When the attack is distributed through multiple reflectors, the attack vector is called a distributed reflection denial-of-service (DRDoS) attack. From the attacker’s perspective, this DRDoS is an extremely cost-effective way to launch denial-of-service attacks to the victim by taking advantage of a wide range of innocent addresses to reflect attack traffic. Any server with an open TCP port, which are widely available and accessible, can be leveraged as reflectors, making DRDoS attacks difficult to mitigate.Download the Q3 2019 Threat Report here.