The case for mod_evasive

by Chris Josephes

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.


Matthew Sporleder
2007-10-16 06:33:23
But, if your environment is relatively small, or if application abuse does not have a high impact, mod_environment is a pretty good tool to have around.

Is that a typo?

Chris J
2007-10-16 07:55:13
Is that a typo?

Yes. Fixed.


2008-04-27 15:44:23
I just wanted to say that, mod_evasive is a godsend to System Administrators that know there way around re-codding a program or system to benefit the servers overall.

mod_evasive: Has the ability to do any type of system commands an Admin dreams of, or in my case add attackers IPs to our FreeBSD IPFW firewall on breaching mod_evasive's configured limits.

LoadModule evasive20_module modules/

DOSLogDir "/usr/local/apache/dos"
DOSHashTableSize 3097
DOSPageCount 2
DOSSiteCount 50
DOSPageInterval 1
DOSSiteInterval 1
DOSBlockingPeriod 10
DOSSystemCommand "sudo -u root /sbin/ipfw -q add 51000 deny ip from %s to any in via rl0 // HTTP DOS"


[SNIP sudo config]
nobody ALL=(ALL) NOPASSWD: /sbin/ipfw -q add 51000 deny ip from *.*.*.* to any in via rl0 // HTTP DOS
[/SNIP sudo config]

As you can imagine, we as well have been subjected to the same type of script kiddy activity since September of 2007 by a group under the name of CyberAgThoR by agthor.

We've never had system wide breach but they keep managing to gain access to user accounts after brute forcing attack for several hours. We have now installed latest modsecurity2.x and mod_evasive and have noticed good results.

Regretfully, the attackers were able to steel username(s) and password(s) by scanning all server html directories for php config files. All there scripts used fopen to open files via non webbased URL and that feature has been turned off in PHP.ini for non-valid URLs.

Chris Josephes
2008-04-28 06:01:48
That works fine if you have one server, but your probably going to want to block confirmed attack traffic at your firewall/router layer.

At the same time, I really, really, hope the mod_security/mod_evasive guys are 100% sure that the string argument they pass can only be an IP address in doted quad notation. A workaround for a sanity check could be a good thing. Or, I wonder if there's a way to modify the IPFW rules without direct root shell access.

2008-05-04 15:25:50
mod_evasive works pretty good in load balanced environments, actually, and for the reason that it doesn't use shared memory between child processes, as Chris mentioned. You don't want to start blocking things like proxies and natted networks, and so mod_evasive works on a per-Apache child process, meaning that you get a listener-based scope of intelligence. In other words, you'll fend off an attach on a load balanced machine if and only if it's a real attack, and that attack will be limited to just the nodes and listener processes that are being hammered. It's designed to fend off attacks without interrupting the existing traffic. And if you do get a really bad attack, it can be configured to call ipf or some script to add the IP to a firewall for more global blocking.