Evolution of a New DDoS Technique
TCP SYN Carpet Bombing Deep Dive
In October of 2019, high-impact TCP reflection/amplification DDoS attacks hit organizations in Scandinavia and Southern Europe. These attacks leveraged servers belonging to organizations unaffiliated with the actual targets of the attack, which were running well-known services such as telnet, HTTP, HTTPS, SMB, etc... The attackers utilized those servers as TCP reflectors/amplifiers and made use of carpet-bombing DDoS attack techniques to distribute amplified attack traffic across multiple network blocks of the targeted entities.
After the initial attacks, another series of related TCP reflection/amplification attacks using the same carpet-bombing DDoS attack technique hit organizations in Asia Minor. Consequently, the collateral damage caused by the abuse of open TCP-based services running on unaffiliated networks as reflectors/amplifiers resulted in significant disruption to fixed, mobile, and satellite wireless broadband access providers, and to their end-customers.
These attacks occur on a daily basis, likely due to the rapid-turnaround skills for new DDoS vectors and techniques in the booter/stresser community.
- The use of reconnaissance by DDoS attackers continues to increase as they ramp up sophistication in using one organizations resources and services against another.
- Leveraging carpet bombing with TCP SYN Reflection, attackers managed to successfully take down the targeted entities and consequently brought down the networks used to reach the target.
- Rapid evolution of DDoS techniques and methodology and their adoption by the booter/stresser community result in a significant increase in attacks that are harder to mitigate.
What is a “TCP SYN Reflection attack using carpet bombing techniques”?
A TCP SYN Reflection carpet bombing attack might initially look like a common spoofed TCP flooding attack with SYN-ACK flags set to the victim. However, in this case the attacker uses real services on the Internet as reflectors and the attack targets many destinations within the victims’ network. This makes the attack harder to detect and mitigate.
Reflection/Amplification attacks generally use services that do not validate the source IP of incoming packets (DNS, NTP, LDAP, etc). The attacker first generates a trigger packet such that the source IP points towards the victim and then sends it to these services, resulting in a large reply (amplification) sent towards the victim. (see https://www.netscout.com/what-is-ddos/volumetric-attacks for more details). TCP Reflection/Amplification attacks work in a similar fashion, sending spoofed TCP SYN packets to the reflector and relying on the reflector sending multiple SYN-ACK replies to the victim. The number of replies sent varies based on the OS used. For example, Linux devices send 3 replies while Windows devices send 5 by default.
Instead of using the actual IP address of the victim (usually a /32), the attacker targets the network block of the victim, resulting in the reflected packets directed to 100s or thousands of destinations within the victim’s network.
Why are these type of DDoS attacks more difficult to detect and mitigate than other attacks?
The carpet-bombing aspect of these attacks result in the attack spreading across entire network CIDR or network blocks. As many DDoS mitigation systems depend on specific host detection to monitor if the attack volume against a specific host goes above acceptable limits to trip an alarm, this type of attack often passes undetected and many times takes down all services in the network under attack.
The Reflective nature of these attacks causes additional issues as both the devices and services used as Reflectors struggle with the incoming flood of TCP SYN packets. Additionally, techniques which rely on sending challenge packets to detect spoofed sources, will in this case receive a reply from the Reflectors, resulting in the attack traffic passing through a dynamically created whitelist.
How to defend against these types of attacks?
A well-prepared organization in almost all cases, can stop TCP Reflection/Amplification attacks, whether they are a Reflector or a target of the reflected packets.
To defend against these attacks requires organizations to distinguish between the two attack types and configure defences such that they will not allow the attack through or drop legitimate packets.
The first step involves detecting the attack as it spreads over large network blocks. This requires monitoring traffic flows to specific subnets or across network devices, detecting when the traffic goes beyond learned values.
A typical SYN flood can be blocked using a challenge-response mechanism, ensuring that the client is responsive, not spoofed, and is capable of establishing a TCP three-way handshake. This will stop a SYN flood directed against an organization’s services. If an attacker leverages those services as a TCP Reflector, the victim will receive challenge-response (SYN/ACK) packets instead.
A SYN-ACK flood using spoofed IP addresses can be handled by replying with a TCP ACK packet using incorrect sequence numbers. Receiving a TCP-SYN ACK packet usually only happens when establishing outbound sessions, and legitimate destinations can therefore be verified using this method. However, when dealing with TCP SYN Reflection attacks, the TCP SYN-ACK packets sent to the victim originate from real services and depending on the exact parameters used for mitigation, this might actually result in allowing the attack traffic instead of filtering it.
It is therefore recommended to either:
- Separate inbound client traffic towards the services under protection from traffic which is outbound to other services, or
- Use a reverse-proxy for outbound sessions.
This allows for clean separation of inbound vs outbound traffic, ensuring that inbound TCP SYN Reflection attacks are quickly identified as attacks.
How large is this threat?
Mapping the precise number of vulnerable devices on the internet is implausible. Essentially, every device offering a TCP-based service (HTTP/ HTTPS, SSH, etc.) can be used as a TCP Reflector/Amplifier. The population of abusable TCP-enabled nodes is in excess of 1 billion devices.
Recently, these kinds of attacks impact the victim under attack and may, in many cases, also cause issues for the devices used as Reflectors. This means that it’s not only important to protect services against DDoS attacks but also stop attackers from using those services as Reflectors/Amplifiers as this will take up valuable resources and could block legitimate users from connecting.
Attackers are not only becoming more proficient in discovering new attack vectors, but also in combining older attack vectors into new attacks that are often difficult to mitigate.
To detect, classify, and mitigate these attacks it is necessary to use advanced DDoS mitigation solutions which rapidly identify the type of attack, enable the correct countermeasures, and filter these attacks with as little human intervention as possible.
To learn more about attackers changing their methodologies and tactics, read our fourth semi-annual Threat Report
- Arbor Networks - DDoS Experts
- Attacks and DDoS Attacks