We rolled out mod_evasive across a pool of servers the other day. Since we already had Apache running, you can rightfully assume that installing this module was done in response to user bahavior.

No, we weren’t selling Hannah Montana tickets, or seeing if Ron Paul would make a nice president; but we did attract a regional based script kiddie. If you give teenagers an online poll asking who has the better football team, and the winner of that poll will be announced on television; it’s a good bet that a few people are going to stuff the ballot box in their favor.

Ironically, nobody even cares about the results; but we have to deal with the people running libwww-perl, or specially crafted JavaScript pages that resubmit form values hundreds of times. Since this isn’t online banking, we decided that using captcha wasn’t worth the effort, so the goal was to block excessive attempts.

The case for mod_evasive is pretty clear. In most cases, it’ll stop successive hits repeatedly sent to the same URL multiple times. Fifty hits enter, one hit leaves. The hit per second parameters are fully configurable. It also logs to syslog; so its behavior can be monitored.

The case against mod_evasive is scalability. Mod_evasive does not use shared memory between child processes. It also won’t work in a load balanced server pool unless the client IP is persistently tied to the same web server in the pool. For larger web server environments, a better solution should be implemented into the load balancing front-end. Finally, in some cases, mod_evasive may not be enough; because even though it still returns 403s, you’re still dealing with a hit and an open TCP socket connection on your server. If your infrastructure is under attack, mod_evasive will never replace firewall blocking or upstream filtering.

But, if your environment is relatively small, or if application abuse does not have a high impact, mod_evasive is a pretty good tool to have around.