Apache HTTP DoS tool released

[headout]

Apache HTTP DoS tool released

Yesterday an interesting HTTP DoS tool has been released. The tool performs a Denial of Service attack on Apache (and some other, see below) servers by exhausting available connections. While there are a lot of DoS tools available today, this one is particularly interesting because it holds the connection open while sending incomplete HTTP requests to the server.

In this case, the server will open the connection and wait for the complete header to be received. However, the client (the DoS tool) will not send it and will instead keep sending bogus header lines which will keep the connection allocated.
The initial part of the HTTP request is completely legitimate:

GET / HTTP/1.1\r\n
Host: host\r\n
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.503l3; .NET CLR 3.0.4506.2152; .NET CLR 3.5.30729; MSOffice 12)\r\n
Content-Length: 42\r\n

After sending this the client waits for certain time – notice that it is missing one CRLF to finish the header which is otherwise completely legitimate. The bogus header line the tools sends is currently:

X-a: b\r\n

Which obviously doesn't mean anything to the server so it keeps waiting for the rest of the header to arrive. Of course, this all can be changed so if you plan to create IDS signatures keep that in mind.

According to the web site where the tool was posted, Apache 1.x and 2.x are affected as well as Squid, so the potential impact of this tool could be quite high considering that it doesn't need to send a lot of traffic to exhaust available connections on a server (meaning, even a user on a slower line could possibly attack a fast server). Good news for Microsoft users is that IIS 6.0 or 7.0 are not affected.

At the moment I'm not sure what can be done in Apache's configuration to prevent this attack – increasing MaxClients will just increase requirements for the attacker as well but will not protect the server completely. One of our readers, Tomasz Miklas said that he was able to prevent the attack by using a reverse proxy called Perlbal in front of an Apache server.

We'll keep an eye on this, of course, and will post future diaries or update this one depending on what's happening. It will be interesting to see how/if other web servers as well as load balancers are resistant to this attack.

Great news

Anyway, how to prevent this from happening at cPanel servers?

 

[serversignature]

place your website behind ProxyShield mitigation system.

 

[brianoz]

I think CSF will protect against this; but I'm not sure, not having tested it ...

 

[zigzam]

No way to prevent against that. Only hope would be a hardware firewall.

 

[brianoz]

No way to prevent against that. Only hope would be a hardware firewall.

True, except that if it's all from one IP then CSF or mod_limitip will work.

 

[brianoz]

This is the thread from WHT - some good info there, some senior people posting with what can be used to defend against it (CSF, Apache KLM, haproxy, httpready sort-of) and discussing some of the issues.

Are we all in risk?? Apache DoS global attack - Web Hosting Talk

And yes, CSF will work if it's all from one IP.

The point to make here is that this is an old attack, that works against many web server types, and is hard to defend against. There's nothing particularly exciting about that, there are lots of attack types that are hard or even impossible to defend against!

Compared against a physical level, that's always going to be the case. If someone drives a truck into my office front door, I don't have defences against that. I could buy some concrete poles which would stop small trucks going slowly, but if I want to stop all trucks, I'd need solid buttresses and I'd need them further away. Then I wouldn't be protected against an angry mafia member wanting to tickle my staff's feet with pink feather dusters, so I'd have to set up a defence against that, or boy scouts with large water pistols, etc etc.

In my mind what we need to be looking at is whether this is a credible immediate threat, and I think the answer for that is no, it's not (credible yes, probably not immediate for most of us). And with any threat, we need to look at:

• is a simple defence possible?
• and/or, what is our strategy if the attack happens?

 

[Voltar]

CSF will protect against this. Check out CSF's readme, section 16, that option will help against this.

If you're using FreeBSD, load the accf_http and accf_data kernel modules, which should mitigate the attacks.