Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a web hosting that does not allow to edit iptables. From to time I have light (about 300 requests/sec) DoS attacks (usually not distributed). I decided to write a PHP script that will block those ips. First I tried to store all requests for last 10 secs in database and look up abusing addresses for every request. But I quickly realized that this way I have to do at least 1 request to database for every DoS request, and it's not good. Then I optimized this approach as follows:

Read 'deny.txt' with blocked ip's
If it contains request ip, then die()
--- at this point we have filtered out all known attacking ips ---
store requesting ip in database
clean all requests older than 10 secs
count requests from this ip, if it is greater than threshold, add it to 'deny.txt'

This way, new attacking ip will make only Threshold requests to database and then gets blocked.

So, the question is, does this approach have optimal performance? Is there a better way to do this task?

share|improve this question
I don't think there will be an efficient way to do this when you are not allowed to change the iptables rules/ install some additional software... – Bart De Vos Nov 5 '11 at 12:12
up vote 3 down vote accepted

If the request can hit your server in any way (even if you could edit iptables) it's still chewing up the bandwidth. If your server can handle 300 requests per second, then don't worry about it. If you get choked for bandwidth, then you'll have to handle it upstream. If you can't edit iptables on your server, you've probably got shared hosting, so chances are your host will see an attack and hopefully limit it upstream before it gets out of hand.

share|improve this answer
Yes, I have shared hosting and I'm hitting 2% CPU limit, not bandwidth – Poma Nov 5 '11 at 13:01

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.