Project

General

Profile

Actions

Feature #1395

closed

request rate throttle (maybe extended mod_evasive?)

Added by ts77 over 16 years ago. Updated 3 months ago.

Status:
Obsolete
Priority:
Normal
Category:
mod_evasive
Target version:
-
ASK QUESTIONS IN Forums:
No

Description

I couldn't find a ticket for that request, even though I heard it a couple of times.

It would be great to have the possibility to limit the number of requests per second and ip. I'm using a home grown solution for that which is added to my php scripts but I'd like to see it in the webserver itself, even more if lighty should be reverse proxying requests to backends which won't see the ip-address at all.

It should work with some kind of sliding window (e.g. 10 seconds, configurable) and given number of requests which is allowed in that timeframe. After that has been reached the client (ip) should be blocked for a configured time.

I think it would be a great extension to the mod_evasive module.

Actions #1

Updated by darix over 16 years ago

  • Status changed from New to Fixed
  • Resolution set to worksforme
Actions #2

Updated by ts77 over 16 years ago

  • Status changed from Fixed to Need Feedback
  • Resolution deleted (worksforme)

thats not really the same.
the docs are only telling about traffic shaping by throughput, not by requests/s.
I don't want to limit the throughput they can achieve but the requests/s as e.g. a regular user usually doesn't request more than one dynamic page/s in a window of 10 seconds.

Actions #3

Updated by Anonymous over 15 years ago

I need this too, to prevent spiders which bomb my site with 40reqs/sec.

-- ludo

Actions #4

Updated by Anonymous over 15 years ago

This would be a great mod for lighttpd - right now I am using a PHP/MySQL solution which hinders itself with its own bottlenecks when things get hammered to quickly. I don't care about the controlling of speed, just the number of requests.

-- IzzyCreamcheese

Actions #5

Updated by stbuehler over 15 years ago

  1. Why the hell do you think it is a defect?
  2. http://trac.lighttpd.net/trac/wiki/Docs%3AModEvasive
  3. robots.txt

And btw: i think it is stupid to reevent the wheel in every application to block such dos attacks; this is something a firewall should be used for.

Actions #6

Updated by stbuehler over 15 years ago

  • Status changed from Need Feedback to Fixed
  • Resolution set to wontfix

Perhaps we will accept a good patch, but until then this is a wontfix.

Actions #7

Updated by Anonymous over 15 years ago

See #208, with a patch that probably does everything you need.

mod_evasive is useless for this (dropping connections is the wrong thing to do when you want to slow things down and not just block broken robots and DOS attacks; if mod_evasive ever trips for a regular, honest browser user, things break). Firewalls are similarly useless for this. This is definitely the job of the webserver.

Rails can't handle lots of parallel requests, and with no limiting, a couple IPs can clog every fcgi server. Reasonably intelligent request limiting is a basic requirement for many Rails apps. So, I agree this is a defect, as least for Rails use. (Rails needing to start a 50+-meg process for every parallel request is also a serious defect of its own, but anyway...)

This isn't just a matter of stopping DOS attacks. We have some requests that can take a long time; we limit each IP to making only one of these at a time. It's common and normal for a user to send several of these, and it's important that they not simply fail (as mod_evasive would do); mod_throttle simply buffers them up.

Actions #8

Updated by stbuehler over 15 years ago

Your firewall should be able to limit the number of concurrent connections; and if you think it shouldn't drop further ones, that too is a job a firewall could handle.

If you just want to slow down download, your firewall should be able to limit traffic per ip.

And i don't see the difference between a ddos with a "couple" ips and a ddos with a little bit more ips... that doesn't solve the problem.

Of course there is one thing the firewall cannot do: different limits for different resources; the patch in #208 tries this, but it fails imho (i don't think it works with mod_proxy for example). This is just something which is not possible to do in a clean way with the current config file syntax.

Actions #9

Updated by Anonymous over 15 years ago

Limiting based on the request is fundamental. Also, a firewall can't correctly limit keepalived (or worse, pipelined) requests, since it doesn't know where the requests and responses begin. This is a prerequisite for limiting the rate of requests.

Of course there is one thing the firewall cannot do: different limits for different resources; the patch in #208 tries this, but it fails imho

You mean the configuration syntax fails. As is, though, it works with the main use case (the OP's): fastcgi.

Actions #10

Updated by stbuehler over 15 years ago

You said nothing interesting, so... just stfu.

Actions #11

Updated by stbuehler over 15 years ago

  • Status changed from Fixed to Wontfix
Actions #12

Updated by gstrauss 3 months ago

  • Description updated (diff)
  • Status changed from Wontfix to Obsolete
  • ASK QUESTIONS IN Forums set to No

mod_evasive is no longer part of the lighttpd base
For replacement, see lua mod_evasive

Actions

Also available in: Atom