Reading about Slowloris attack:

Slowloris tries to keep many connections to the target web server open and hold them open as long as possible. It accomplishes this by opening connections to the target web server and sending a partial request. Periodically, it will send subsequent HTTP headers, adding to—but never completing—the request.

Looking at some examples, and writing one myself, it's quite easy to DOS the target by simply keeping the maximum connection limit open, recreating connections as the target times them out.

What is the point of sending subsequent HTTP headers after opening a connection with a partial request? Sending subsequent headers doesn't seem to reset the connection timeout.

  • The point is to keep the connection as long as possible to waste server resources. If the process is speed up then server would release the resources sooner, so slowing it is the point.
    – Xaqron
    May 14 '17 at 11:01
  • Sending subsequent headers doesn't seem to reset the connection timeout. - how do you come to this conclusion? And, if true in your specific case, how do you know that this is not a behavior specific to your setup and used web server only? In general new traffic will reset the timer for the idle timeout of a connection but it might be that your specific server has a timeout specifically for getting the HTTP header or a timeout for getting the full request. May 14 '17 at 11:36
  • Wikipedia covers this well. Using a scalable firewall, CDN, or proxy can mitigate this attack. For example Amazon AWS ELB and CloudFront both protect against Slowloris, as would most similar technologies.
    – Tim
    May 14 '17 at 19:50
  • @Xaqron - Yes, keeping the maximum number of connections open causes denial to subsequent requests; my question is specifically about why sending subsequent HTTP headers after making the initial partial request is noted as the general behaviour during the attack.
    – wulfgarpro
    May 15 '17 at 9:36
  • 1
    Once you understand that your statement "Sending subsequent headers doesn't seem to reset the connection timeout." is incorrect everything else will make sense. A timeout is typically reset when a new packet is received. This attack keeps all available sockets busy with a low bandwidth attack.
    – Tim
    May 15 '17 at 18:50

As pointed out in the comments, there is in fact a degree of variability amongst different servers. I was wrong to assume the connection timeout wasn't reset when sending subsequent headers.

I've implemented a basic Slowloris with nodejs here, and tested it against Ubuntu Apache2 (2.4.18-2ubuntu4.1) to prove this.

I tuned the Timeout variable down from 300 to 10 seconds for this test. After doing this, Apache reported many 408 Request Timeout errors in the error log if the interval set for sending subsequent headers was greater-than 10 seconds (line 54). By reducing this interval to less-than or equal to 10 seconds, Apache infrequently, if ever, reported any timeout errors.

  • If anyone finds a convenient way of having Apache log the active timeout value for a request, please share.
    – wulfgarpro
    May 23 '17 at 6:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.