Layer 7 DDOS – Blocking HTTP Flood Attacks

There are many types of Distributed Denial of Service (DDOS) attacks that can affect and bring down a website, and they vary in complexity and size. The most well known attacks are the good old SYN-flood, followed by the Layer 3/4 UDP and DNS amplification attacks.

Today though, we’re going to spend a little time looking at Layer 7, or what we call an HTTP Flood Attack.

An HTTP flood attack is a type of Layer 7 application attack that utilizes the standard valid GET/POST requests used to fetch information, as in typical URL data retrievals (images, information, etc.) during SSL sessions. An HTTP GET/POST flood is a volumetric attack that does not use malformed packets, spoofing or reflection techniques. –

If you’re wondering, yes, we deal with these every day, and we protect our client websites via our Website Firewall.

Today I’m going to share with you some details on a rather large DDoS attack that leveraged the following HTTP request flood attack to wreak havoc on a clients website. I’ll also share the steps we took to mitigate the issue.

Layer 7 DDoS – HTTP Flood Attacks

The first thing to understand about Layer 7 attacks is that they require more understanding about the website and how it operates. The attacker has to do some homework and create a specially crafted attack to achieve their goal. Because of this, these types of DDoS attacks require less bandwidth to take the site down and are harder to detect and block.

Layer 7 DDoS – Part 1: Random URLs

This specific client came to us after his site was down for almost a week. They tried other services to protect their website with not much luck. As soon as he switched his DNS to us, we gained a much deeper appreciation and started to see why.

He was getting thousands of requests like these every second: - - [20/Jan/2014:19:32:06 -0500] "GET /?458739416183768700 HTTP/1.1" 200 440 "" "" - - [20/Jan/2014:19:32:06 -0500] "GET /?458726993617499500 HTTP/1.1" 200 440 "" "" - - [20/Jan/2014:19:32:06 -0500] "GET /?458741338856272200 HTTP/1.1" 200 440 "" "" - - [20/Jan/2014:19:32:06 -0500] "GET /?458722169268652700 HTTP/1.1" 200 440 "" "" - - [20/Jan/2014:19:32:06 -0500] "GET /?458741274224646000 HTTP/1.1" 200 440 "" ""

To be more exact, he was getting 5,233 HTTP requests every single second. From different IP addresses around the world.

What is important to note here is how this worked against the client’s platform. The client’s website was built on WordPress. The uniqueness of the requests were bypassing the caching system, forcing the system to render and respond to every request. This was bringing about system failures as the server quickly became overwhelmed by the requests.

For illustration purposes, here is a quick geographic distribution of the IP’s hitting the site. This is for 1 second in the attack. Yes, every second these IP’s were changing.

Website DDoS Attack Map

Stopping the DDoS: Once we identified the type of attack, blocking was easy enough. By default, they were not passing our anomaly check, causing the requests to get blocked at the firewall. One of the many anomalies we look for are valid user agents, and if you look carefully you see that the requests didn’t have one. Hopefully, you’ll also noticed that the referrers were dynamic and the packets were the same size, another very interesting signature. Needless to say, this triggered one of our rules, and within minutes his site was back and the attack blocked.

Layer 7 DDoS – Part 2: Random Searches

After we blocked the original requests and banned the IP addresses involved, everything went quiet, at least for a day. In less than 24 hours though the attacks resumed with a higher intensity. To be quite honest, they came back with a vengeance. This time however, they adapted their attack to hit the built-in WordPress search (i.e., leveraging the ?s option). It looked something like this:

Request 1:
Request 2:
Request 3:

Remember the caching bypass discussion above? Well, it happened again, and this time it wasn’t blocked automatically as it was operating as a wolf in sheep’s skin.

This is what it looked like in the logs: - - [20/Jan/2014:19:40:08 -0500] "GET /?s=wikipedia HTTP/1.1" 200 440 "" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.11 (KHTML, like Gecko) Chrome/23.0.1271.97 Safari/537.11" - - [20/Jan/2014:19:40:08 -0500] "GET /?s=joy HTTP/1.1" 200 440 "" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_5_8) AppleWebKit/537.1 (KHTML, like Gecko) Chrome/21.0.1180.90 Safari/537.1" - - [20/Jan/2014:19:40:08 -0500] "GET /?s=santander HTTP/1.1" 200 440 "" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.76 Safari/537.36" - - [20/Jan/2014:19:40:08 -0500] "GET /?s=news HTTP/1.1" 200 440 "" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.76 Safari/537.36" - - [20/Jan/2014:19:40:08 -0500] "GET /?s=gov HTTP/1.1" 200 440 "" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.76 Safari/537.36" - - [20/Jan/2014:19:40:08 -0500] "GET /?s=faith HTTP/1.1" 200 440 "" "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0" 

If you are not familiar with web logs, the first entry is the IP address, followed by the date, the page requested, the result (success or failure), the referrer, and then the browser.

What the logs show us is that the attack was doing random searches for dictionary keywords (eg: news, gov, faith, etc ). This time they were using a valid browser (Firefox, Chrome, Safari, etc), user agents, and a valid referrer.

It was a bit tricky blocking this attack. You see, they were leveraging normal user search habits. How do you block valid search requests without blocking valid users? We weren’t about to force JavaScript checks or anything like that, but at the same time we needed to avoid passing all the requests back to the clients server. If not, we would have ended up in the same predicament we were in when they first signed up.

Stopping this DDOS: After what felt like hours, but was actually seconds (OK, maybe minutes) we noticed another anomaly, or what we’d classify as a signature in the new DDoS pattern. The attacker was rotating IP’s within a few seconds of each other, rotating referrers and user agents, all the while performing search requests. Finally, something we could build a rule for, thanks for that. Now each time we see the same IP with a different user agent / referrer within a small period of time, we’re able to block access. Within minutes, the attack was contained.

How we’re able to do this comes down to the technology around our Website Firewall. Like an onion, we’ve built the Sucuri WAF with multiple layers that moves us away from traditional event based attacks, something most of today’s WAF products use. We have introduced new concepts around application profiling and correlation analysis, allowing intelligence to be built into protecting your website.

But enough of that boring stuff…

It’s All About Persistence

What kind of attacker would you be if you weren’t persistent? Well, this attacker obviously took that to heart; this specific attack lasted a little over 2 weeks. Every day thousands of IP addresses (likely compromised) were being used to DDoS this site.

Just in the block list created by our log correlation tool, we banned 9,673 IP Addresses in the first few hours. During the following days the list grew to almost 40,000 different IP addresses. That’s quite a respectable botnet.

Have you ever faced a DDOS like this? What techniques did you use to block it? Note that this type of DDOS blocking service is included in all our Website Firewall plans, and we’re here to protect you and your business!

  1. Great article, thanks! Are you, or have you already, covered the other types of DDOS attacks – syn-flood, and Layer 3/4 UDP and DNS amplification attacks?

  2. Appreciate that you guys focused on the Layer 7 side of things since that’s your wheel house. (side note: We were recently hit with a DNS amplification attack. Ugh.) Also love to hear that you’re focusing on application profiling and correlation analysis in your WAF. Much better than the good ol’ ports & protocols approach. I was curious what made Sucuri different than the other guys out there and this is a big part of that. This seems to take a cue from some of the NGFW vendors out there with their app control, etc.

  3. brilliant article! how do u apply these intelligent rules? on a linux box which acts as a inline firewal?? or are these dedicated network security devices like arbor?

  4. So in this scenario, the attack was not automated? Rather it was some hacker deliberately targeting the site and over-seeing the attack…is that correct? Scary 🙁

  5. I was under attack. I already enable the emergency ddos protection and the paranoid mode but the still the attack continues. I already blocked some countries even my own country but still my site is down.

  6. I have a site enabled the protection, however http-get attacks are still reaching to the server. I have solved my problem with free CSF.

    Sorry Sucuri, your protection is a complete mess, it does nothing.

    1. hello,

      could you tell me what settings did you use with csf to stop http get flood? i m under attack from 3 weeks now

  7. “each time we see the same IP with a different user agent / referrer within a small period of time, we’re able to block access”

    Legitimate users behind the same corporate firewall will fit this pattern, too, though.

  8. bonjour
    si vous former 5 firewall en cascade ( le 1 firewall un seul port ouvert sur tcp et udp les 65534 autre fermer) ( le 2 firewall avec juste le meme port tcp que le 1er firewall et le port udp fermer)
    (le 3 firewall avec la redirection tcp udp sur le port tcp du 2firewall) (le 4 firewall tous les ports tcp et udp que l on a besoin pour son site ou son pc) ( le 5 firewall doit ètre programmer afin que le firewall numéro 1,2,3,4 change de place et change de port udp tcp afin de blocker toute forme d intrusion je ne sais pas coder des algoritmes alors cela peut se faire manuellement
    je n est pas tester cette solution avec 5 firewall mais uniquement cela est une béta

    simplifier (firewall1 tcp 10 udp10 (1-9 fermer 11-65535 fermer(tcp-udp) (firewall 2 tcp 10 ouvert udp10 fermer (1-9 fermer 11-65535 fermer) tcp 10 ouvert udp 10 fermer ) (firewall 3 tcp 10 redirection -udp tcp sur 20 tcp udp (1-19 fermer 21-65535 fermer tcp udp ) (firewall 4 tcp udp 20-redirection sur udp tcp utiliser sur pc ou site web (firewall 5 réseau lier au port tcp10 et udp 20 afin de reformer une cascade de firewall sur de nouveau ports tcp udp pour rendre le firewall un snifer sur sont propre tcp ) peut ètre cela peut permetre de bloquer une intrusion qui na plus la meme route tcp udp programmer par sont attaquant et peut etre intercepter . je ne sais pas si cette technique marche sur un ver qui se déploit selon un algoritme
    je suis un amateur ne former pas se système sen étre sur de se que vous faite
    je ne garantie en rien cette solution

Comments are closed.

You May Also Like