Stop Layer 7 DDoS Attacks with Multilayered Security

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.

Anatomy of the Attack

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.

How We Stopped It

The attack was mitigated by the Bot Management module of the Oracle Cloud Infrastructure WAF, using a defense mechanism called the JavaScript Challenge. By design, the security platform automatically engaged the defense mechanism after it had automatically confirmed the attack.

The security platform injects a small bit of JavaScript into each request from end users via a reverse proxy, by using Oracle Cloud Infrastructure’s high-capacity Edge Network. The JavaScript interrogates and verifies that an end user’s browser has a full JavaScript engine. It eliminates traffic that seems to come from incomplete browsers—which is typical of botnets that specialize in DDoS—while permitting traffic coming from regular browsers.

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.

All About Automation

Automation was key to successfully protecting the site against this attack. When the Bot Manager noticed a spike in requests, it automatically selected and activated one of its countermeasure defenses (the JavaScript Challenge) and blocked requests that failed the challenge. Security operations center (SOC) analysts didn't need to do anything to block the attack, which is good news because the attack happened in the middle of the night.

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:

A Multilayered Approach

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:

  • To improve performance. If we already know the content of the page, we don't need to ask the origin server for it.
  • To protect against these kinds of attacks. Caching is often overlooked by security teams, but it is an essential component of Layer 7 DDoS protection.

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.

Join the discussion

Comments ( 1 )
  • Jason Lackey Thursday, April 4, 2019
    Laurent - great post. DDoS has been a real concern for a long time. I recall the days of Anon and script kiddies discovering that running LOIC through a proxy like HideMyAss sometimes didn't hide them. Oops. I thought that the Javascript Challenge was a simple but elegant approach - learned something today.

    I think I may have found a typo in this line "The purpose of Layer 7 DDoS attacks is to overwhelm an application server, rendering the application unavailable or at least reducing its response time." - I think that you may have intended to say that it would increase response time.

    Great post, thanks!
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha