Realistically, mod_evasive isn't going to prevent a real DDoS.
It will prevent a badly behaved scraper/spider from potentially bringing apache to its knees, however. It might even help prevent the kind of issue that got be banned from Google AdSense, where an unknown third-party goes nuts following all links and Google decides you are a bad guy.
Because of this, I think it is useful to have it.
Incidentally, I note that when mod_evasive triggers, the ossec rule is level 6 or 7, and typically won't be seen by the admin. In addition, the mod_evasive config file isn't changed by ASL to have an email sent when it triggers.
One of the things I did was to change the rule to level 12 so that I get clear email alerts when it triggers.
p.s., from the README. My keepalive timeout was very low - 15s.
Code:
340 TWEAKING APACHE
341
342 The keep-alive settings for your children should be reasonable enough to
343 keep each child up long enough to resist a DOS attack (or at least part of
344 one). Remember, it is the child processes that maintain their own internal
345 IP address tables, and so when one exits, so does all of the IP information it
346 had. For every child that exits, another 5-10 copies of the page may get
347 through before putting the attacker back into '403 Land'. With this said,
348 you should have a very high MaxRequestsPerChild, but not unlimited as this
349 will prevent cleanup.
350
351 You'll want to have a MaxRequestsPerChild set to a non-zero value, as
352 DosEvasive cleans up its internal hashes only on exit. The default
353 MaxRequestsPerChild is usually 10000. This should suffice in only allowing
354 a few requests per 10000 per child through in the event of an attack (although
355 if you use DOSSystemCommand to firewall the IP address, a hole will no
356 longer be open in between child cycles).
Login
Register
FAQ
Search
I've upped the limits on it but still getting quite a number of IPs (including totally legis, non-crawler ones) blocked. May have to turn it off.
