4/14/2015 Security Labs: How to Protect Against Slow HTTP... | Qualys Community

https://community.qualys.com/blogs/securitylabs/2011/11/02/how­to­protect­against­slow­http­attacks 1/4

Security Labs

Slow HTTP attacks are denial-of-service (DoS) attacks in which the attacker sends HTTP requests inpieces slowly, one at a time to a Web server. If an HTTP request is not complete, or if the transferrate is very low, the server keeps its resources busy waiting for the rest of the data. When theserver’s concurrent connection pool reaches its maximum, this creates a DoS. Slow HTTP attacksare easy to execute because they require only minimal resources from the attacker. In this article, I describe several simple steps to protect against slow HTTP attacks and to make theattacks more difficult to execute. Previous articles in the series cover:

Identifying Slow HTTP Attack Vulnerabilities on Web Application

New Open-Source Tool for Slow HTTP DoS Attack Vulnerabilities

Testing Web Servers for Slow HTTP Attacks

 Protection Strategies To protect your Web server against slow HTTP attacks, I recommend thefollowing:

Reject / drop connections with HTTP methods (verbs) not supported by theURL.

Limit the header and message body to a minimal reasonable length. Settighter URL-specific limits as appropriate for every resource that accepts a message body.

Set an absolute connection timeout, if possible. Of course, if the timeout is too short, you riskdropping legitimate slow connections; and if it’s too long, you don’t get any protection fromattacks. I recommend a timeout value based on your connection length statistics, e.g. atimeout slightly greater than median lifetime of connections should satisfy most of thelegitimate clients.

The backlog of pending connections allows the server to hold connections it’s not ready toaccept, and this allows it to withstand a larger slow HTTP attack, as well as gives legitimateusers a chance to be served under high load. However, a large backlog also prolongs the

How to Protect Against Slow HTTP AttacksPosted by Sergey Shekyan in Security Labs on Nov 2, 2011 9:08:06 AM

4/14/2015 Security Labs: How to Protect Against Slow HTTP... | Qualys Community

https://community.qualys.com/blogs/securitylabs/2011/11/02/how­to­protect­against­slow­http­attacks 2/4

attack, since it backlogs all connection requests regardless of whether they’re legitimate. If theserver supports a backlog, I recommend making it reasonably large to so your HTTP server canhandle a small attack.

Define the minimum incoming data rate, and drop connections that are slower than that rate.Care must be taken not to set the minimum too low, or you risk dropping legitimateconnections.

 Server-Specific Recommendations Applying the above steps to the HTTP servers tested in the previous article indicates the followingserver-specific settings: Apache

Using the <Limit> and <LimitExcept> directives to drop requests with methods not supportedby the URL alone won’t help, because Apache waits for the entire request to complete beforeapplying these directives. Therefore, use these parameters in conjunction with theLimitRequestFields, LimitRequestFieldSize, LimitRequestBody, LimitRequestLine,LimitXMLRequestBody directives as appropriate. For example, it is unlikely that your web apprequires an 8190 byte header, or an unlimited body size, or 100 headers per request, as mostdefault configurations have. 

Set reasonable TimeOut and KeepAliveTimeOut directive values. The default value of 300seconds for TimeOut is overkill for most situations.

ListenBackLog’s default value of 511 could be increased, which is helpful when the server can’taccept connections fast enough.

Increase the MaxRequestWorkers directive to allow the server to handle the maximum numberof simultaneous connections.

Adjust the AcceptFilter directive, which is supported on FreeBSD and Linux, and enablesoperating system specific optimizations for a listening socket by protocol type. For example,the httpready Accept Filter buffers entire HTTP requests at the kernel level.

 A number of Apache modules are available to minimize the threat of slow HTTP attacks. Forexample, mod_reqtimeout’s RequestReadTimeout directive helps to control slow connections bysetting timeout and minimum data rate for receiving requests. I also recommend switching apache2 to experimental Event MPM mode where available.  Thisuses a dedicated thread to handle the listening sockets and all sockets that are in a Keep Alivestate, which means incomplete connections use fewer resources while being polled. Nginx

Limit accepted verbs by checking the $request_method variable.

Set reasonably small client_max_body_size, client_body_buffer_size, client_header_buffer_size,large_client_header_buffers, and increase where necessary.

Set client_body_timeout, client_header_timeout to reasonably low values.

4/14/2015 Security Labs: How to Protect Against Slow HTTP... | Qualys Community

https://community.qualys.com/blogs/securitylabs/2011/11/02/how­to­protect­against­slow­http­attacks 3/4

Consider using HttpLimitReqModule and HttpLimitZoneModule to limit the number of requestsor the number of simultaneous connections for a given session, or as a special case, with sameaddress.

Configure worker_processes and worker_connections based on the number of CPU / cores,content and load. The formula is max_clients = worker_processes * worker_connections.

 lighttpd

Restrict request verbs using the $HTTP["request-method"] field in the configuration file for thecore module (available since version 1.4.19).

Use server.max_request-size to limit the size of the entire request including headers.

Set server.max-read-idle to a reasonable minimum so that the server closes slow connections.No absolute connection timeout option was found.

 IIS 6

Set connectionTimeout, HeaderWaitTimeout and MaxConnections properties in Metabase tominimize the impact of slow HTTP attacks. Working with Metabase can be complicated, so Irecommend Microsoft’s Working with the Metabase reference guide.

 IIS 7

Limit request attributes is through the <RequestLimits> element, specifically themaxAllowedContentLength, maxQueryString, and maxUrl attributes.

Set <headerLimits> to configure the type and size of header your web server will accept.

Tune the connectionTimeout, headerWaitTimeout, and minBytesPerSecond attributes of the<limits> and <WebLimits> elements to minimize the impact of slow HTTP attacks.

 What’s Next The above are the simplest and most generic countermeasures to minimize the threat. Tuning theWeb server configuration is effective to an extent, although there is always a tradeoff betweenlimiting slow HTTP attacks and dropping legitimately slow requests. This means you can neverprevent attacks simply using the above techniques. Beyond configuring the web server, it’s possible to implement other layers of protection likeevent-driven software load balancers, hardware load balancers to perform delayed binding, andintrusion detection/prevention systems to drop connections with suspicious patterns. However, today, it probably makes more sense to defend against specific tools rather than slowHTTP attacks in general. Tools have weaknesses that can be identified and and exploited whentailoring your protection. For example, slowhttptest doesn’t change the user-agent string once thetest has begun, and it requests the same URL in every HTTP request. If a web server receivesthousands of connections from the same IP with the same user-agent requesting the sameresource within short period of time, it obviously hints that something is not legitimate. These

4/14/2015 Security Labs: How to Protect Against Slow HTTP... | Qualys Community

https://community.qualys.com/blogs/securitylabs/2011/11/02/how­to­protect­against­slow­http­attacks 4/4

kinds of patterns can be gleaned from the log files, therefore monitoring log files to detect theattack still remains the most effective countermeasure.

 

Like (0)

Hi! I would like to know if you have references of how to fix this vulnerability in glassfish?. thanks.

Juan Ruiz Jun 24, 2013 7:43 AM

Like (0)

Never looked at glassfish, but I found this reference a good starting point. I guess if youapply all concepts like minimizing timeout, limit POST body, etc to glassfish configuration,it should improve handling slow DoS attacks.

Sergey Shekyan Jun 28, 2013 10:58 AM (in response to Juan Ruiz)

Like (0)

Hi Sergey, Thanks for sharing this info.  Well documented here. In regards to your lighttpd suggestions, I understand this would reduce the chancesof DOS, but they are not bullet-proof IMHO. With reduced interval between sending the data ( less than max-read-idle), it canstill do the same effect. Regards.

Chang Im Aug 1, 2013 5:40 PM (in response to Sergey Shekyan)