New slow-motion DoS attack

By

Qualys Security Labs researcher Sergey Shekyan has created a proof-of-concept tool that could be used to essentially shut down websites from a single computer with little fear of detection. The attack exploits the nature of the Internet's Transmission Control Protocol (TCP), forcing the target server to keep a network connection open by performing a "slow read" of the server's responses.

The Slow Read attack, which is now part of Shekyan's open-source slowhttptest tool, takes a different approach than previous "slow" attacks such as the infamous Slowloris—a tool most notably used in 2009 to attack Iranian government websites during the protests that followed the Iranian presidential election. Slowloris clogs up Web servers' network ports by making partial HTTP requests, continuing to send pieces of a page request at intervals to prevent the connection from being dropped by the Web server.

Slow Read, on the other hand, sends a full request to the server, but then holds up the server's response by reading it very slowly from the buffer. Using a known vulnerability in the TCP protocol, the attacker could use TCP's window size field, which controls the flow of data, to slow the transmission to a crawl. The server will keep polling the connection to see if the client—the attacker—is ready for more data, clogging up memory with unsent data. With enough simultaneous attacks like this, there would be no resources left on the server to connect to legitimate users.

Shekyan said in his post about the tool that this type of attack could be prevented by setting up rules in the Web server's configuration that refuse connections from clients with abnormally small data window settings, and limit the lifetime of an individual request.

 

Actual Test Example: https://community.qualys.com/blogs/securitylabs/2012/01/05/slow-read

 

Protection Strategies....Taken from the source found here: https://community.qualys.com/blogs/securitylabs/2011/11/02/how-to-protect-against-slow-http-attacks

To protect your Web server against slow HTTP attacks, I recommend the following:

  • Reject / drop connections with HTTP methods (verbs) not supported by the URL.
  • Limit the header and message body to a minimal reasonable length. Set tighter 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 risk dropping legitimate slow connections; and if it’s too long, you don’t get any protection from attacks. I recommend a timeout value based on your connection length statistics, e.g. a timeout slightly greater than median lifetime of connections should satisfy most of the legitimate clients.
  • The backlog of pending connections allows the server to hold connections it’s not ready to accept, and this allows it to withstand a larger slow HTTP attack, as well as gives legitimate users a chance to be served under high load. However, a large backlog also prolongs the attack, since it backlogs all connection requests regardless of whether they’re legitimate. If the server supports a backlog, I recommend making it reasonably large to so your HTTP server can handle 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 legitimate connections.

 

Server-Specific Recommendations

 

Applying the above steps to the HTTP servers tested in the previous article indicates the following server-specific settings:

 

Apache

  • Using the <Limit> and <LimitExcept> directives to drop requests with methods not supported by the URL alone won’t help, because Apache waits for the entire request to complete before applying these directives. Therefore, use these parameters in conjunction with the LimitRequestFields, LimitRequestFieldSize, LimitRequestBody, LimitRequestLine, LimitXMLRequestBody directives as appropriate. For example, it is unlikely that your web app requires an 8190 byte header, or an unlimited body size, or 100 headers per request, as most default configurations have. 
  • Set reasonable TimeOut and KeepAliveTimeOut directive values. The default value of 300 seconds for TimeOut is overkill for most situations.
  • ListenBackLog’s default value of 511 could be increased, which is helpful when the server can’t accept connections fast enough.
  • Increase the MaxRequestWorkers directive to allow the server to handle the maximum number of simultaneous connections.
  • Adjust the AcceptFilter directive, which is supported on FreeBSD and Linux, and enables operating 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. For example, mod_reqtimeout’s RequestReadTimeout directive helps to control slow connections by setting timeout and minimum data rate for receiving requests.

 

I also recommend switching apache2 to experimental Event MPM mode where available.  This uses a dedicated thread to handle the listening sockets and all sockets that are in a Keep Alive state, which means incomplete connections use fewer resources while being polled.

 

Nginx

 

lighttpd

  • Restrict request verbs using the $HTTP["request-method"] field in the configuration file for the core 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

 

IIS 7

  • Limit request attributes is through the <RequestLimits> element, specifically the maxAllowedContentLength, 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 the Web server configuration is effective to an extent, although there is always a tradeoff between limiting slow HTTP attacks and dropping legitimately slow requests. This means you can never prevent attacks simply using the above techniques.

 

Beyond configuring the web server, it’s possible to implement other layers of protection like event-driven software load balancers, hardware load balancers to perform delayed binding, and intrusion detection/prevention systems to drop connections with suspicious patterns.

 

However, today, it probably makes more sense to defend against specific tools rather than slow HTTP attacks in general. Tools have weaknesses that can be identified and and exploited when tailoring your protection. For example, slowhttptest doesn’t change the user-agent string once the test has begun, and it requests the same URL in every HTTP request. If a web server receives thousands of connections from the same IP with the same user-agent requesting the same resource within short period of time, it obviously hints that something is not legitimate. These kinds of patterns can be gleaned from the log files, therefore monitoring log files to detect the attack still remains the most effective countermeasure.

Subscribe to our Newsletter

Search ALL Articles

Managed V. Non-Managed

 
NON-MANAGED=REACTIVE
MANAGED=PROACTIVE
 
 

ourprivacy.org

US-CERT Latest Warnings

Latest US-CERT Released Warnings