Akamai Diversity

The Akamai Blog

Slow DoS on the Rise

The following is a guest post from Senior Enterprise Architect David Senecal and Sr. Solutions Architect Aseem Ahmed


Recent years have been very dramatic in security landscape with emerging threats; the application layer is now a more prominent target.  The new (and deadly) Layer 7 attacks called slow HTTP Denial of Service (DoS) attacks are on the rise.  Although they are not as new as they might sound, anything that is not frequently spoken of in the security world is often new!


In my experience, the common perception of DoS is a volumetric attack that occurs quickly, not slowly.  Traditionally, DoS/DDoS attacks have been volumetric, required a large number of clients and could be geographically distributed.  But slow attacks that consume minimal resources/bandwidth from the attacker side can still bring down your Web server. 


Here are the results of using slowhttptest against a vulnerable apache server in our lab environment.  The snippet below shows the tool in action where new connections are established very quickly with the server.  The Web server becomes unavailable after 5 seconds of launching the attack.


SlowPost 1.png

The HTML screenshot below shows the results of the same test.  The tool opens 1000 connections with rate of 200 connections per second, and the server is able to concurrently process only 351 connections, leaving the remaining 649 connections pending. 


SlowPost 2.png


Why is this a problem?


  • These connections look like legitimate user connections.
  • Traditional rate detection techniques will skip them.
  • Existing IPS/IDS solutions that rely on signatures will generally not recognize them either.
  • They require very few resources and little bandwidth for execution.
  • Such attack can bring down a Web server, irrespective of its hardware capabilities.


How do these attack work?


Slow HTTP DoS attacks rely on the fact that a Web server will faithfully honor client requests.  The attacker's motive is to send a legitimate-looking request to keep the server resources busy handling said requests for the longest time possible. If the attacker keeps adding to such long-ended requests, the server can quickly run out of resources.


Slow HTTP Denial of service attacks have different variants, but before we get into the details, let's review the normal HTTP structure and flow:


Request

Headers

POST /account/login HTTP/1.1 CRLF

Accept: */* CRLF

Content-type:  application/x-www-form-urlencoded CRLF

Content-Lenngth: 60 CRLF

Connection: keep-alive CRLF

Host: www.customer.com CRLF

User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:22.0) Gecko/20100101 Firefox/22.0 CRLF

Body

email=customer%40account.com&password=mypasswrd

 

Response

Headers

HTTP/1.1 200 OK CRLF

Server: Apache/2.2.22 (Ubuntu) CRLF

Content-Type: Text/html CRLF

Content-Length: 200 CRLF

Date: Fri, 12 Jul 2013 05:31:32 GMT CRLF

Connection: Keep-Alive CRLF

Body

<html>

   <head>

   .....

  </head>

</html>




The different stages of the request flow can be exploited to craft different types of slow attacks:


  • Slow HTTP Headers (Slowloris): In this attack, an attacker sends partial HTTP headers at a very slow rate (less than the idle connection timeout value on the server), but never completes the request. The headers are sent at regular intervals to keep sockets from closing, thereby keeping the server resources occupied.  Below is an illustration of such an attack.
SlowPost 3.png

  • Slow HTTP Post (RUDY): As the name suggests, an attacker will slowly POST the data to Form fields. The request contains all the headers with a legitimate Content-Length header (usually with a high value) making the server aware of the amount of data expected. The attacker now injects the data in the Form at a very slow rate, forcing the server to keep its resources busy expecting more data to arrive. Eventually the server runs out of resources. Below is an illustration of such an attack.
SlowPost 4.png

  • Slow Read Attack: The client sends a full request, but when the server responds, it advertises a very small TCP window for accepting response data. Thus the server sends data slowly to the client keeping its sockets open. It keeps probing the client to check its receive windows size while the client always advertises a small window size, slowing down the transfer. The larger the file size, the more time it will take to complete such connections. Multiple such requests for a large file can potentially DoS the server quickly.
SlowPost 5.png

How Akamai and our Professional Services team can help protect against these attacks

  • SlowLoris: The Akamai platform natively protects against such attacks because our Edge servers always wait to receive the full headers from a client before it starts streaming the request forward to the origin Web server.  The attack is therefore absorbed at the edge, without ever affecting the origin Web server. 

  • Slow POST (Rudy) attacks: The Slow POST protection feature included in Kona Site Defender helps detect the attack by keeping track of the rate at which it receives the data from the client. It is possible to define the minimum bit rate and the number of intervals (5 seconds per intervals) the Edge server will wait before deciding that a client is too slow and is likely attempting an attack.  For example, if a client sends the POST body at a rate lower than 10 bits/second for more than 6 cycles (30s total), it will trigger an alert or abort the connection with the client.  When the edge aborts the connection with the client, it also aborts the data stream to the origin. 

  • Slow Read attacks:  Since the Akamai platform acts as a proxy between the client and the origin Web server, the TCP connections between the Akamai platform and the origin Web server will not have the same slow attributes.  The Akamai Edge server negotiates the TCP connection with the origin Web server independently from the connection with the client.  For better visibility on such attacks, Akamai is also working on a feature similar to the slow POST protection that would monitor the client read byte rate to detect and terminate connection with slow clients. 

Leave a comment