Comments on: Slowloris HTTP denial of service

By: Raviv

Raviv — Tue, 30 Nov 2010 21:49:54 +0000

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

By: Cody

Cody — Tue, 23 Mar 2010 04:33:26 +0000

Hey is this a free design or a paid one?

By: slomo

slomo — Thu, 21 Jan 2010 21:17:09 +0000

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

By: deejay

deejay — Sun, 10 Jan 2010 17:35:13 +0000

any news about preventing attacks?

By: lbh

lbh — Sat, 01 Aug 2009 22:08:10 +0000

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

78.90.242.1 and 78.90.242.6

By: CarlosFromPhilly

CarlosFromPhilly — Mon, 22 Jun 2009 14:42:55 +0000

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

By: ionbladez

ionbladez — Sun, 21 Jun 2009 07:56:24 +0000

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

By: alisonvuocolo

alisonvuocolo — Sat, 20 Jun 2009 14:23:43 +0000

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.

By: lol

lol — Sat, 20 Jun 2009 07:15:43 +0000

@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.

By: Wwhat

Wwhat — Fri, 19 Jun 2009 12:58:14 +0000

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.

By: TJHooker

TJHooker — Thu, 18 Jun 2009 22:16:10 +0000

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.

By: Harvie

Harvie — Thu, 18 Jun 2009 20:25:36 +0000

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).

By: LOL

LOL — Thu, 18 Jun 2009 18:19:34 +0000

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

By: Chartreuse

Chartreuse — Thu, 18 Jun 2009 17:22:29 +0000

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.

By: id

id — Thu, 18 Jun 2009 15:32:56 +0000

Wow, so much confidence.

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