[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]
that has to be shooped.
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..
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
“i was under the impression that even by default apache caps the number of open sockets per IP”
Yes, but that doesn’t help, because these are *incomplete* requests, so they tie up a thread up to max_threads.
@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
colecago – http://www.youtube.com/watch?v=rLdQ3UhLoD4
Hilarious and cute little buggers.
@octelcogopod: not by default. Although some sysadmins might fix it, most won’t.
@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.
Hack-A-Day, don’t you think posting this is rather irresponsible.
This is what hackaday should be telling us about, not all these DIY tinkerers…thats not hacking, this is hacking.
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
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
almostthere: Look up “full disclosure” on wikipedia. Intense debate rages over what is responsible when documenting and fixing vulnerabilities.
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.
This is nothing new. Most server stress testing scripts include a mode whereby multiple sessions are left open to do just this. Lame.
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.
This may not be widespread knowledge, but its no news.
I was thinking “reverse tarpit”… Interesting (ab)use though…
no noose is good noose (leave us alone mel brooks!)
ehm, this can easily be fixed by reusing idle connections. keep on walking, people, nothing to see here.
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.
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.
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.
Wait. Isnt this what a basic connect flooder does? This is known since the nineties you can flood a systems socket descriptors.
There is absolutely nothing new about this.
Wow, so much confidence.
Maybe one of you should try it against your “solutions”.
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.
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
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).
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.
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.
@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.
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.
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
^
this seems exactly like another user making assumptions without at least spending two minutes glancing at the code.
tried taking down one of my servers and didn’t work
78.90.242.1 and 78.90.242.6
any news about preventing attacks?
To stop the attack you can use a Load balancer to check for http header completeness
Hey is this a free design or a paid one?
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