Traditional cyberattacks are increasingly automated, and this is particularly true of distributed denial-of-service (DDoS) and similar attacks. The responses to these attacks must be automated as well.
At the end of 2018, the Oracle Cloud Infrastructure Web Application Firewall (WAF) used automation and a multilayered detection and mitigation approach to prevent a botnet-driven DDoS attack against an organization that runs a critical SaaS website used by major technology infrastructure companies.
The Oracle Cloud Infrastructure heterogenous Edge Network, which is a combination of globally distributed high-capacity application points of presence and ultra high-capacity DDoS scrubbing centers, played an important role in mitigating this Layer 7 DDoS attack. DDoS scrubbing centers kick in when an attack reaches a specific threshold.
Application-layer (Layer 7) DDoS attacks use a network of bots (also known as a botnet) to send massive amounts of garbage traffic to a website. This only purpose of this traffic is to flood a web server with requests. Typically, especially for a Layer 7 DDoS attack, bots attempt to access a site by simulating human activity, sometimes through something as simple as an Apache Benchmark command line. This behavior is unlike humans, who access sites through real web browsers.
The purpose of Layer 7 DDoS attacks is to overwhelm an application server, rendering the application unavailable or at least reducing its response time. Sometimes this kind of attack is performed to hide other nefarious, more sophisticated attacks, or to test application defenses as a prelude to much larger events.
In this particular attack, the website, which typically receives 50 requests per second, received more than 2,800 requests per second for several minutes. This amounted to 1 million requests in a few minutes and about 150 Mbps of traffic—two orders of magnitude more than usual.
One million overall requests and 2,800 requests per second are not huge numbers—the Oracle Cloud Infrastructure WAF once protected a customer against an attack that generated more than 500,000 HTTP requests per second—but they are often enough to bring down a site.
The following graph shows the number of requests per second to the site on a normal day (Oct. 31, the day before the attack):
The following graph shows the number of requests per second on the day of the attack:
Overall, the botnet used well-distributed IP addresses across several countries to make 1 million requests within a few minutes. Such an attack, if undefeated, would have been more than enough to bring down the site.
The following image shows that 1,071,261 requests (99.9 percent of the attack) were automatically detected and mitigated by the Oracle Cloud Infrastructure WAF:
The Oracle Cloud Infrastructure WAF also has other sophisticated capabilities for identifying and blocking bot traffic, including real-time behavior-based analysis.
Without automation, the site would have gone down as the number of requests increased so dramatically and so quickly. A typical site built for an average of 50 requests per second can't survive 2,800 requests per second.
Further, had the site been brought down, it would have been challenging to identify the botnet. SOC analysts would have had to look at the logs, but they would have seen nothing wrong other than a significant increase in traffic. They'd know that it was probably a botnet, but they'd have no way to retroactively identify which traffic came from bots and which was legitimate, or how to block it.
If the attack had come from only a few bots, IP rate limiting would have been an effective countermeasure, by blocking addresses making more than a few requests per second. During this attack, however, the botnet used a large number of bots and IP addresses, and the number of requests coming from each individual address was quite low.
Note the distribution of geolocations from some of the botnet's IP addresses:
It's important to note that the time it takes to confirm an attack often results in a small attack leakage. In this attack, about 60,000 requests out of 1 million were not blocked by the Bot Manager.
This happened by design. Bot Manager engages only when an attack has been confirmed. That is, it waits for a number of consecutive failed requests before it automatically starts blocking traffic.
All of these 60,000 requests were served by the Bot Manager caching layer, from the Oracle Cloud Infrastructure Edge Network; none of the requests were sent to the origin. As a result, the origin server was not affected by the attack, and the web assets of the company were not affected.
The Oracle Cloud Infrastructure WAF caches customers' website content for two reasons:
Layer 7 DDoS attacks are prolific. For an attacker, they can serve many purposes: eliminate e-commerce competition during an important period, extort site owners, or in some cases, provide a smokescreen for more serious attacks.
Mitigating Layer 7 DDoS attacks is possible by using cascading challenges delivered from a unified, distributed platform. Site owners can ensure that botnet traffic is stopped at the edge, before origin resources are affected and sites go offline.