At the beginning of January, Gcore faced an incident involving several L3/L4 DDoS attacks with a peak volume of 650 Gbps. Attackers exploited over 2000 servers belonging to one of the top three cloud providers worldwide and targeted a client who was using a free CDN plan. However, due to Gcore’s distribution of infrastructure and a large number of peering partners, the attacks were mitigated, and the client’s web application remained available.
Why was mitigating these attacks so significant?
1. These attacks were significant because they exceeded the average bandwidth of similar attacks by 60×. The performed attacks relate to volume-based attacks targeted to saturate the attacked application’s bandwidth in order to overflow it. Measuring total volume (bps)—rather than the number of requests—is the way these attacks are usually tabulated.
The average bandwidth of this attack type is generally in the tens of Gbps (about 10 Gbps). Therefore, the specified attacks (at 650 Gbps) exceeded the average value by 60 times. Attacks of this volume are rare and are of particular interest to security experts.
Additionally, this value (650 Gbps) is comparable to the record DDoS attack on the largest Minecraft server (2.4 Tbps), only one-fourth as massive.
2. The client being attacked was using a CDN plan without additional DDoS protection. When clients use Gcore’s CDN (as part of the Edge Network), the malicious traffic of the L3/L4 attacks directly affects only its infrastructure (it serves as a filter), not the targeted clients’ servers. The negative impact falls on the capacity and connectivity of the infrastructure When a CDN is powerful enough, it can protect clients against L3/L4 attacks—even when accessed using a free plan.
What were the technical specifications of the attacks?
The duration of the incident was 15 minutes, and at its peak, it reached over 650 Gbps. A possible reason why the incident took so long is that the attackers weighed the ineffectiveness of the attacks (the client application kept running) against their high cost.
The incident consisted of three attacks with different vectors. They are marked with traffic peaks on the diagram below:
- UDP flood attack (~650 Gbps). Hundreds of millions of UDP packets were sent to the target server to consume the bandwidth of the application and cause its unavailability. Attacks of this vector use a lack of requirements of UDP connection establishment: the attackers can send packets with any data (it increases the volume) and use spoofed IP addresses (it makes it difficult to find the sender).
- TCP ACK flood attack (~600 Gbps). A large number of packets with the ACK flag were sent to the target server to overflow it. Attacks of this vector are based on the fact that the junk TCP packets do not include a payload, but the server is forced to process them, and it may not have enough resources to handle requests from real end users. A CDN’s protection system is capable of filtering packets and not forwarding them to the server if they do not contain payloads and are not bound to an open TCP session.
- A mix of TCP and UDP (~600 Gbps). A custom variation of the previous two types of attacks.
The distinctiveness of the incident was that the attacks were performed from multiple non-spoofed IP addresses. This allowed specialists to identify that the attackers used 2,143 servers in 44 different regions, and all of the servers belonged to a single public cloud provider. Utilizing Anycast allowed Gcore to absorb the attack 100% over peering connections with this provider.
Sankey diagram showing the source and flow of the attack. Names of the locations from the first column are associated with one of the top 3 cloud providers.
Why did the attacks not affect the client?
1. Gcore’s connectivity through peering with many locations played a key role in mitigating the attacks. Gcore has over 11,000 peering partners (ISPs), and these partners connect their networks using cables and provide each other with access to traffic originating from their networks. These connections allow for bypassing the public internet and directly absorbing traffic from the peering partners. Additionally, this traffic is either free of charge or costs much less than traffic on the public internet. This low cost makes it possible to protect customer traffic on a free plan.
In the context of the DDoS attack that occurred, the level of connectivity greatly benefited the efficacy of mitigation. Gcore and the cloud provider used to launch the attack are peering partners, so while the attack was happening, Gcore was able to ingest most of the traffic over the cloud provider’s private network. This greatly reduced the amount of traffic that needed to be handled by the public internet.
Private peering also enables more accurate filtering and better attack visibility, which leads to more efficient attack mitigation.
2. Gcore’s large capacity, due to the placement of servers in many data centers, also played a role. Gcore’s edge servers are present in over 140 points of presence and are based on high-performance 3rd generation Intel® Xeon® Scalable processors.
The overall network capacity is over 110 Tbps. With over 500 servers located in data centers worldwide, the company is able to withstand large-scale DDoS attacks. So, the 650 Gbps of traffic could be distributed across the network, and each particular server would only receive 1-2 Gbps, which is an insignificant load.
Security trends
According to Gcore’s experience, DDoS attacks will continue to grow year over year. In 2021, the attacks reached 300 Gbps, and by 2022, they had increased to 700 Gbps. Therefore, even small and medium-sized businesses need to use distributed content delivery networks such as the CDN and Cloud to protect against DDoS attacks.
