Distributed denial-of-service (or DDoS) attacks “are increasing in frequency and growing in size exponentially,” reports Google Cloud’s blog.
Recently an attacker tried to hit one of their customers with 46 million requests per second. The blog post describes it as the largest attack of its kind reported to date, “at least 76% larger than the previously reported record. To give a sense of the scale of the attack, that is like receiving all the daily requests to Wikipedia (one of the top 10 trafficked websites in the world) in just 10 seconds.”
Starting around 9:45 a.m. PT on June 1, 2022, an attack of more than 10,000 requests per second (rps) began targeting our customer’s HTTP/S Load Balancer. Eight minutes later, the attack grew to 100,000 requests per second. Cloud Armor Adaptive Protection detected the attack and generated an alert containing the attack signature by assessing the traffic across several dozen features and attributes. The alert included a recommended rule to block on the malicious signature….
Our customer’s network security team deployed the Cloud Armor-recommended rule into their security policy, and it immediately started blocking the attack traffic. In the two minutes that followed, the attack began to ramp up, growing from 100,000 rps to a peak of 46 million rps. Since Cloud Armor was already blocking the attack traffic, the target workload continued to operate normally. Over the next few minutes, the attack started to decrease in size, ultimately ending 69 minutes later at 10:54 a.m.
Presumably the attacker likely determined they were not having the desired impact while incurring significant expenses to execute the attack…. The attack leveraged encrypted requests (HTTPS) which would have taken added computing resources to generate. Although terminating the encryption was necessary to inspect the traffic and effectively mitigate the attack, the use of HTTP Pipelining required Google to complete relatively few TLS handshakes…. The attack was stopped at the edge of Google’s network, with the malicious requests blocked upstream from the customer’s application.
While 22% of the source IPs corresponded to Tor exit nodes, the actual traffic coming from Tor nodes represented just 3% of attack traffic, the blog post points out.
And ultimately despite the attack, “the customer’s service stayed online and continued serving their end-users.”