Slowloris HTTP denial of service

[RSnake] has developed a denial of service technique that can take down servers more effectively. Traditionally, performing a denial of service attack entailed sending thousands of requests to a server, these requests needlessly tie up resources until the server fails. This repetitive attack requires the requests to happen in quick succession, and is usually a distributed effort. However, [RSnake]‘s new technique has a client open several HTTP sessions and keeps them open for as long as possible. Most servers are configured to handle only a set number of connections; the infinite sessions prevent legitimate requests from being handled, shutting down the site. This vulnerability is present on webservers that use threading, such as Apache.

A positive side effect of the hack is that the server does not crash, only the HTTP server is affected. His example perl implementation, slowloris, is able to take down an average website using only one computer. Once the attack stops, the website will come back online immediately.

Update: Reader [Motoma] sent in a python implementation of slowloris called pyloris

[photo: cutebreak]

Comments

  1. colecago says:

    that has to be shooped.

  2. Alex says:

    Abusing the parallel requests setting in your browser can create similar results. I’ve seen it happen before; it seems that people think “well, two parallel requests is fast, so 500 should be great!” Of course, trying to open 500 connections to a server when you’re on dialup just ties up all the connections until it all times out..

  3. octelcogopod says:

    i was under the impression that even by default apache caps the number of open sockets per IP, regardless of what the client wants to do

  4. Haku says:

    @colecago: http://www.liveleak.com/view?i=7a4_1240434722

    as for the attack, botnets could really go to town on some major sites like google, microsoft, ebay etc.
    interesting times ahead methinks

  5. Cabe says:

    colecago – http://www.youtube.com/watch?v=rLdQ3UhLoD4

    Hilarious and cute little buggers.

  6. Zach Banks says:

    @octelcogopod: not by default. Although some sysadmins might fix it, most won’t.

  7. Arthur Grumbine says:

    @octelcogopod
    That can’t be true, because the image at the bottom of the page shows a slow loris after having devoured everything of an apache but the last feather.

  8. AlmostThere says:

    Hack-A-Day, don’t you think posting this is rather irresponsible.

  9. anon says:

    Hack-A-Day, don’t you think posting this is rather irresponsible.

    better to release it so people know and can fix it rather than get hit with an attack

  10. Daley says:

    hack-a-day criteria: it’s gotta be some sort of hack… check… it’s gotta be interesting… check… it should be something that isn’t common household knowledge (yet)… check… hmm, seems to me this one’s good. thanks h-a-d

  11. Arthur says:

    almostthere: Look up “full disclosure” on wikipedia. Intense debate rages over what is responsible when documenting and fixing vulnerabilities.

  12. LOL says:

    Apache has a Multi-Processing Module (MPM) that implements a non-threaded pre-forking web server.

    1997 called to tell you this issue was fixed =P

    52% of people admit to using apache — the rest insist the forged signature foobar is superior, or obscure the identity as a surprisingly stable Window’s Web server.

  13. David says:

    This is nothing new. Most server stress testing scripts include a mode whereby multiple sessions are left open to do just this. Lame.

  14. Apache can be configured A: not to allow multiple requests on the same socket (The docs tell you not to configure it that way for performance) and B: A timeout for keep alive’s. This attack would only really become a problem if the OS hits it’s socket limit.. it’s pretty low by default on most Linux machines, but easily rectified.
    Also this is nothing new.. the reverse, but same principle, is done for tarpit’ing spammers.

    N.B. If you really wanted to improve a DoS on a webserver you’d have your script find and attack parts of the site that are going to consume the most resources i.e. parts that apparently do lots of database lookups. Even better find parts of the site the rely on non-public backend machines thus push the attack further down into the infrastructure.

  15. defyboy says:

    This may not be widespread knowledge, but its no news.

  16. I was thinking “reverse tarpit”… Interesting (ab)use though…

  17. nubie says:

    no noose is good noose (leave us alone mel brooks!)

  18. tulcod says:

    ehm, this can easily be fixed by reusing idle connections. keep on walking, people, nothing to see here.

  19. michiel says:

    this has been around since 1998 or something. its plain stupid that apache hasnt fixed it in their default configuration since then but thats besides the point.

  20. TRB says:

    mod_cband can limit the number of connections per IP for the configured host. Will save you all the heartache the would-be script kiddies wish to inflict.

  21. mnt says:

    It’s _so_ obvious. Everyone tweaking an apache or IIS with keep alive and not enough slots open has seen this problem. Or a rough unittest that accidently triggers itself until all slots are filled.

    Advertising it as a “new form of DoS” is just plain silly and an insult to the reader. And there are even countermeasures in Apache (at least 2.0) that easily make this “attack” ineffective.

  22. Anonymous says:

    Wait. Isnt this what a basic connect flooder does? This is known since the nineties you can flood a systems socket descriptors.

  23. anonymous says:

    There is absolutely nothing new about this.

  24. id says:

    Wow, so much confidence.

    Maybe one of you should try it against your “solutions”.

  25. Chartreuse says:

    Well just as an experiment, me and a couple of friends decided to test this out on our own servers, first I attacked myself with a stock apache2 server, it went down in seconds. Next I went against a custom modified lighttpd server that was meant to resist this, it also went down in a flash (after a couple of tweaks to the command). The last test was one more apache2 server that was set up to supposedly limit connections per IP to 6, and it still went down surprisingly.

  26. LOL says:

    Indeed,
    as stated above the concurrent hammering fix needs more than just the ip limits.

    Tested proper Apache2 configuration with CentOS and it stays up.
    =p

  27. Harvie says:

    lol this kind of DoS is very old and often used in many ways for a long time.

    google for: portfuck, doshttp
    there are also many implementations for other operation systems. if you want C/perl/python implementation look for “http flood”, “process table attack” or “socket array” i had also implementet few of similar attacks in php-cli – each was about 5 lines.

    to protect your apache look for modules:
    cband, dosevasive, security and iptables (netfilter).

  28. TJHooker says:

    now 4chan hords can have each member use a perl script instead of a distributed request system and take down random websites more efficiently. thanks rsnake for posting a end user solution that is publicly down loadable.

  29. Wwhat says:

    I wonder if that statement that windows doesn’t open more than about 130 sockets is true, because that’s not what I know of, there are several p2p clients that open way more AFAIK.

  30. lol says:

    @Wwhat
    There is a dll patch for windows os that removes the concurrent open port limits.

    But anyone running windows as a server has their days numbered – the mean time to complete failure is 10 months.

    A lean services model dedicated *nix box almost always outlasts the hardware with a competent admin.

  31. alisonvuocolo says:

    I’m kinda irritated that so many people are saying “old news” and “easy to fix” without actually playing with the script on running servers.
    There really is nothing in apache’s default config (and not a single official apache module) that prevents this attack from occurring.
    This is NOT A STANDARD HTTP FLOOD by any means.
    Try it. Run slowloris (or similar) and tail your logs.
    Don’t see anything? Interesting, huh?
    The reason this works isn’t because the client is “taking up a bunch of sockets”, it’s because the client is beginning a (thousand or more) conversation(s)– actually more like beginning a word in a conversation– then stopping. Apache doesn’t know what to do whatsoever because it hasn’t even heard a word yet. Timeouts are worthless because the script (if the person running the script spent a bit of time finding the target server’s running config) will be run to spawn new processes before the timeout is reached. MaxKeepAlive can be easily configured around as well.
    The only way– that i’ve found after a full day of searching– to stop this attack is by using a third party. Best i’ve done is scripting something that passes rules to iptables.
    Even then, iptables counters filling up would be an obvious problem unless the counters are flushed periodically.
    Regardless, this is not “old news”, it’s two year old news at best, and this is the first time a user friendly implementation has been in the wild.
    I mean, shouldn’t you test (or at least LOOK at) the script before deciding it’s simple to defeat?

    That said, i bet it’s a matter of days before MaxConnPerIP or mod_limitipconn get lots and lots of attention from apache developers and are fast tracked into the default apache config…
    If this goes a week without an official response, the internet is going to have an interesting summer.

  32. ionbladez says:

    This seems EXACTLY like the program I made 2 months ago: SVP; Sniper Vantage Point;
    Loops a new instance of a TCP class and connects, in multiple threads.
    User has ability to choose how long to hold all connections, and block all data from being received.

    Any questions feel free to IM me on Yahoo.

    ID: ionbladez

  33. CarlosFromPhilly says:

    ^
    this seems exactly like another user making assumptions without at least spending two minutes glancing at the code.

  34. lbh says:

    tried taking down one of my servers and didn’t work

    78.90.242.1 and 78.90.242.6

  35. deejay says:

    any news about preventing attacks?

  36. slomo says:

    To stop the attack you can use a Load balancer to check for http header completeness

  37. Cody says:

    Hey is this a free design or a paid one?

  38. Raviv says:

    The R.U.D.Y attack tool also produces an application-layer attack in HTTP using POST parameters. Check it out:

    http://chaptersinwebsecurity.blogspot.com/2010/11/r-u-dead-yet-version-20.html

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 93,986 other followers