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
To protect your Web server against slow HTTP attacks, I recommend the following:
Applying the above steps to the HTTP servers tested in the previous article indicates the following server-specific settings:
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.
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.
Latest US-CERT Released Warnings