A DDoS Attack Explained: HTTP Flood

HTTP floods are one of the most devastating types of DDoS attacks currently available to an attacker. It is an attack at the application layer (Layer 7 of the OSI model), meant to exhaust a system’s application resources. It is very easy to execute, doesn’t require a massive botnet or any sort of tricks to generate volumetric amounts of data, and extremely difficult to block.

A server that is hosting a website is probably running Apache or Nginx. Depending on how strong the server is and how many servers are concurrently running hosting the website, it could support anywhere from just a few users at any given time to thousands of users. Whenever a user connects to a website, they establish a TCP connection using a three-way handshake:

– Client sends a SYN packet to the server
– Server sends a SYN ACK packet to the client
– Client sends an ACK packet to the server

Once this happens, a TCP connection is opened between the client and the server, allowing for free communication between the two. Data flows between the client and the server, the server sending the client the web data using TCP packets, and the client’s web browser translates these packets into a webpage.
HTTP floods involve opening up a valid TCP connection with a server, and then proceeding to send some sort of request to the server, such as download every object on page, or triggering some sort of call that would force a database query. There are many different ways an HTTP flood can overwhelm a server.

An example HTTP flood, in this case, a GET flood looks like this:

T 198.19.0.2:42728 -> 198.18.0.80:80 [AP] GET / HTTP/1.1. Host: example.com. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20100101 Firefox/8.0. . T 198.19.0.2:40962 -> 198.18.0.80:80 [AP] GET / HTTP/1.1. Host: example.com. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20100101 Firefox/8.0. . T 198.19.0.2:51486 -> 198.18.0.80:80 [AP] GET / HTTP/1.1. Host: example.com. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20100101 Firefox/8.0. . T 198.19.0.2:55300 -> 198.18.0.80:80 [AP] GET / HTTP/1.1. Host: example.com. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20100101 Firefox/8.0. . T 198.19.0.2:56396 -> 198.18.0.80:80 [AP] GET / HTTP/1.1. Host: example.com. User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:8.0) Gecko/20100101 Firefox/8.0. .

 

The GET flood above is legitimately downloading the index page of a website. By legitimately, I mean it establishes a full session and actually receives all the data from the webpage.
An HTTP flood accomplishes multiple goals. The simplest thing it does is it establishes a lot of TCP sessions. This on its own causes a huge amount of strain on web servers. The more complex part of it is that each session is requesting the server to send it data over and over again, so the server is constantly processing requests from the clients and trying to respond to them. This very easily exhausts the server’s resources.

This kind of flood is easy to execute. There are scripts online such as httpflooder.pl that allow a client to send a GET flood to a server. A single machine sending a GET flood to a server will not be enough to take the server down though. It requires a decent sized botnet. The reason a botnet is necessary is that in order for an HTTP flood to work, the client has to be able to respond to the server’s requests. This is much different than a SYN flood where packets just get sent but don’t send any sort of follow up packets. With enough zombies in a botnet, a server can easily be overwhelmed.

This kind of attack is very difficult to stop due to the fact that these systems are all sending what look like legitimate connections. Detecting the bad traffic requires deep packet inspection and a lot of logic around what seems to be legitimate and what does not. This introduces the problem of false-positive blocking, which is a major problem that DDoS protection providers have. The idea is the bad traffic has to be filtered out and the good traffic has to be let through, but when application layer floods occur, most DDoS protection providers fall short detecting what is good and what is bad.

Staminus SecurePort technology is at the forefront of application layer DDoS protection as well as very all other types of attacks. You can learn more about the Staminus filtering and mitigation process by visiting our technology page.

Leave a Reply

Your email address will not be published. Required fields are marked *