0

Description of incident:

I notice in my MRTG panel that httpd processes have climbed to 800 ( our maximum ), but all other parameters are normal ( cpu, memory, traffic )

I immediately ran a nestat command ( netstat -ntu | awk '{print $5}' | cut -d: -f1 | sort | uniq -c | sort -n ) to see which IPs were generating the most connections.

A single IP had opened 500 + connections.

We used iptables to ban the ip, everything went back to normal.

We use an apache module that limits the number of concurrent requests per IP. it has been tested so it works, but here it did not do anything. somehow, the limit was avoided.

Please help me tu understand how the limit was avoided.

user9517
  • 114,104
  • 20
  • 206
  • 289
Adr
  • 9
  • 1
  • What Apache module did you use to limit the number of requests and how dit you configure it? I would limit the number of requests at the "gate" of your server with iptables. – i.amniels May 15 '11 at 09:11
  • Thanks ! 1. we're using this: http://dominia.org/djao/limitipconn.html 2. how could we do this with iptables ? – Adr May 15 '11 at 11:35
  • Any ideas on how we can tell if this is a server problem, a site design/programming flaw or a DDOS attack ? – Adr May 15 '11 at 11:37
  • Certainly your description seems to indicate that you got hit by a DOS - you've now provided what module you thought would limit connections but provided NO DETAILS of how you configured it. Also, were these 500 open connections? Or in other states? – symcbean May 15 '11 at 13:42
  • Hi, the limitipconn limits concurrent downloads. We have it setup for 20 concurrent downloads. We believe that the attacker bypassed this system: i.e. he did not do multiple concurrent downloads ( his IP only appeared 20 times in access log ). – Adr May 15 '11 at 14:51

1 Answers1

0

This is known (at least recently) as the slowloris attack. Basically, it works by sending headers very very slowly to apache. Depending on how the module you were using works, it may not function until an entire request header is received, which could be a long time.

The most reliable fix to this attack (and the one I'd suggest) is to stick some type of other web server/proxy in front of apache. Nginx and HAProxy are good choices here. These would completely defeat this type of attack, and there would be no way to evade them.

devicenull
  • 5,572
  • 1
  • 25
  • 31