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.

Improve this question
5
  • 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, 2011 at 9:11
  • Thanks ! 1. we're using this: dominia.org/djao/limitipconn.html 2. how could we do this with iptables ?
    – Adr
    May 15, 2011 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, 2011 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, 2011 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, 2011 at 14:51

1 Answer 1

Reset to default
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.

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .