A DDoS amplification attack’s Anatomy

Amplification assaults are among the most popular types of distributed denial of service (DDoS) attacks. These assaults are often classified as flooding or volumetric attacks, in which the attacker generates more traffic than the target can process, causing the target to exhaust its resources owing to the volume of traffic it receives.

What exactly are DDoS amplification attacks?

An attacker, a reflector, and a victim are all involved in a reflection attack. The attacker spoofs the target’s IP address to request a reflector (e.g., open server, middlebox) that responds to the target, in this instance a virtual machine (VM). The answer should be bigger than the request for the assault to be amplified, resulting in a reflected amplification attack. The attacker’s objective is to build the greatest possible reflection from the fewest possible requests. Attackers achieve this aim by locating a large number of reflectors and creating requests that result in the greatest amplification.

The primary cause of reflected amplification attacks is that an attacker may fake the source IP address and force reflectors to react to targets. This attack vector would be minimized if spoofing was not possible. Much effort has consequently been expended in preventing IP source address spoofing, and many businesses now block spoofing so that attackers cannot use their networks for amplification assaults. Unfortunately, a large number of enterprises still permit source spoofing. According to the Spoofer Project, one-third of IPv4 autonomous systems enable or partially allow spoofing.

Amplification attacks on UDP and TCP

Because the reflection of traffic with a spoofed IP source address is feasible due to the lack of a proper handshake, most attackers use UDP to perform amplification attacks.

While UDP makes reflected amplification attacks simple, TCP’s three-way handshake complicates spoofing attempts. As a result, IP source address spoofing is limited to the handshake’s first stages. Although the TCP handshake allows for reflection, it does not allow for easy amplification because the TCP SYN+ACK response is not larger than the TCP SYN response. Furthermore, because the TCP SYN+ACK response is sent to the target, the attacker never receives it and cannot learn critical information contained in the TCP SYN+ACK required to complete the 3-way handshake and continue making requests on behalf of the target.

Reflection and amplification attacks based on TCP, on the other hand, have emerged in recent years.

An Independent study discovered additional TCP reflected amplification channels that launch volumetric floods using middleboxes such as nation-state censorship firewalls and other deep packet inspection devices. Middleboxes can be used in asymmetric routing setups, where they only observe one side of a TCP connection (e.g., packets from clients to servers). To compensate for this imbalance, such middleboxes frequently use a non-compliant TCP stack. Attackers take advantage of this mistake by not completing the 3-way handshake. They can produce a series of requests that elicit amplified answers from middleboxes and, in some situations, can achieve infinite amplification. The industry has begun to see these types of assaults from censorship and enterprise middleboxes, such as firewalls and IDPS devices, and we anticipate that this trend will continue as attackers seek new methods to wreak havoc using DDoS as a primary weapon.

Another example of a reflected amplification attack is carpet bombing. It frequently employs UDP reflection and, in recent years, TCP reflection as well. Instead of concentrating the assault on a single or few targets, the attacker targets several targets inside a certain subnet or classless inter-domain routing (CIDR) block (for example, /22). Because such assaults might fly beyond popular baseline-based detection systems, it will be more difficult to identify and counteract them.

TCP SYN+ACK reflection is an example of TCP carpet bombing, in which the attacker transmits faked SYN to a large number of random or pre-selected reflectors. Amplification occurs in this attack as a result of reflectors that retransmit the TCP SYN+ACK when they do not receive a response. The amplification of the TCP SYN+ACK response may be small, depending on the number of retransmissions delivered by the reflector. The mirrored attack traffic towards each of the target virtual machines (VMs) in Figure 3 may not be enough to knock them down individually, but together, the traffic may overwhelm the targets’ network.

UDP and TCP amplification attacks in Azure

We are always working to reduce inbound (from the internet to Azure) and outbound (from Azure to the internet) amplification threats in Azure. We prevented over 175,000 UDP reflected amplification attacks in the previous 12 months. We observed over ten attack vectors, the most prevalent of which are NTP (49,700 attacks), DNS (42,600 attacks), SSDP (27,100 attacks), and Memcached (18,200 attacks). These techniques can achieve amplification factors of up to x4,670, x98, x76, and x9,000.

Across all attack vectors, we measured the highest assault throughput in packets per second. The largest throughput was a 58 million packets per second (PPS) SSDP flood in August last year, during a 20-minute attack campaign on a single Azure server.

TCP reflected amplification attacks are growing increasingly common, and new attack avenues are being uncovered. We see these assaults on Azure resources using a variety of reflectors and attack paths.

A TCP reflected amplification attack of TCP SYN+ACK against an Azure resource in Asia is one such example. The attack lasted 15 minutes and reached 30 million PPS. Although the attack throughput was low, there were around 900 reflectors engaged, each with retransmissions, resulting in a high PPS rate that can knock the host and other network infrastructure parts down.

Many TCP SYN+ACK retransmissions are associated with the reflector that does not receive an ACK response from the spoofed source. Here’s an example of retransmission:

The retransmitted packet arrived 60 seconds after the original.

Azure amplification attack mitigation

Reflected amplification assaults are here to stay and provide a significant threat to the internet community. To avoid traditional countermeasures, they continue to innovate and exploit new weaknesses in protocols and software implementations. To mitigate the impact of amplification assaults, industry coordination is required. Mitigating such assaults at a specific site using a precise mitigation method is insufficient. It necessitates the integration of network and DDoS mitigation capabilities.

Azure’s network is one of the world’s biggest. To counteract reflected amplification DDOS assaults, we employ numerous DDoS methods across our network and DDoS mitigation pipeline.

On the network, we are constantly optimizing and implementing different traffic monitoring, traffic engineering, and quality of service (QoS) approaches to prevent reflected amplification assaults at the routing infrastructure. These techniques are implemented at the edge and core of our wide area network (WAN) network, as well as within data centers. It enables us to neutralize assaults on inbound traffic (from the Internet) right at the network’s edge. Similarly, outbound assaults (those that begin within our network) will be halted immediately at the data center, without the need to exhaust our WAN and leave our network.

Additionally, our dedicated DDoS mitigation pipeline is constantly evolving to provide better mitigation solutions against such attacks. This mitigation pipeline adds another layer of defense to our DDoS networking solutions. Together, these two levels of security provide full coverage against the most sophisticated and huge reflected amplification threats.

Because reflected amplification assaults are often volumetric, it is not enough to employ advanced mitigation measures; a highly scalable mitigation pipeline must also be maintained to deal with the greatest attacks. Our mitigation pipeline has a worldwide mitigation capacity of more than 60Tbps, and we are constantly expanding it by adding mitigation capacity across all network tiers.

Different attack vectors require different treatment

For all attack vectors, UDP-based reflected amplification assaults are tracked, monitored, identified, and neutralized. To prevent these attacks, many mitigating mechanisms are available, such as anomaly detection across attacked IP addresses, L4 protocols, and monitoring of faked source IPs. Because UDP reflected amplification attacks frequently result in fragmented packets, we monitor IP fragments to properly mitigate them.

To launch such attacks, TCP-based reflected amplification attacks make use of inadequate TCP stack implementations and a vast variety of reflectors and targets. We use mitigation measures to identify and prevent assaults from attackers and reflectors. To address TCP SYN, TCP SYN+ACK, TCP ACK, and other TCP-based assaults, we deploy a series of mitigations. When data is attached to TCP packets to trigger amplification using reflectors, mitigation combines TCP authentication techniques that recognize faked packets with anomaly detection to stop attack traffic.

Begin using Azure DDoS Protection to defend against amplification assaults

Azure’s DDoS mitigation infrastructure neutralized the world’s greatest DDoS attacks by deploying a globally distributed DDoS protection platform that scales beyond 60Tbps. We make certain that our platform and our customers’ workloads are always secured against DDoS assaults. We constantly engage with other industry participants to combat reflected amplification assaults in order to improve our DDoS posture.

As part of defending our infrastructure and cloud platform, Azure clients are secured against Layer 3 and Layer 4 DDoS assaults. However, Azure DDoS Protection Standard offers clients with full protection by auto-tuning the detection policy to the covered application’s individual traffic patterns. This guarantees that anytime traffic patterns change, such as during a flash crowd event, the DDoS policy is instantly adjusted to reflect those changes for the best protection. As part of defending our infrastructure and cloud platform, Azure clients are secured against Layer 3 and Layer 4 DDoS assaults. However, Azure DDoS Protection Standard offers clients with full protection by auto-tuning the detection policy to the covered application’s individual traffic patterns. This guarantees that anytime traffic patterns change, such as during a flash crowd event, the DDoS policy is instantly adjusted to reflect those changes for the best protection.

Protection is easy to set up on any new or existing virtual network and requires no application or resource modifications. Our freshly introduced Azure built-in rules enable improved network security compliance management by facilitating onboarding across all of your virtual network resources and log setup.

Azure’s network security services may operate in combination to protect your workloads, with DDoS protection being one of the tools we give, to boost the security posture of apps. Organizations pursuing zero trust architecture might benefit from our services to improve their security.

Here at CourseMonster, we know how hard it may be to find the right time and funds for training. We provide effective training programs that enable you to select the training option that best meets the demands of your company.

For more information, please get in touch with one of our course advisers today or contact us at training@coursemonster.com