Mitigate Attacks With mod_evasive

Learn how to deploy Apache's mod_evasive module to help reduce the impact of denial of service attacks.

Recent “Tech Support” articles have shown a variety of “LAMP” optimization tips, from tweaking PHP, to installing a PHP opcode cache, to ensuring MySQL is firing on all cylinders. If your Web site traffic merits these efforts, you can glean real benefits — but remember that premature optimizations is the root of all evil.

Now that you have a tuned, well-trafficked site, what should you think about next? High on your list should be security. Hopefully, you’ve adopted the best practices for locking down your Apache and PHP installations, but beyond that, there are many Apache modules that can further bolster a hardened configuration and therefore increase uptime. One module that comes to mind is mod_security, an embeddable Web application firewall. Another is mod_evasive.

Available from http://www.zdziarski.com/projects/mod_evasive/ and licensed under the GNU Public License, mod_evasive is an Apache module that provides evasive action in the event of an HTTP denial of service (DoS), distributed denial of service (DDoS), or brute force attack. mod_evasive is also designed to be a detection and network management tool, and can be easily configured to talk to ipchains, firewalls, and routers. Moreover, it can report abuses via email and syslog.

To detect potential problems, mod_evasive creates an internal dynamic hash table of IP Addresses and URIs and denies any single IP address if it requests the same page more than X times per Y seconds, makes more than N concurrent requests per X seconds, or makes any requests while temporarily blacklisted. If any of these conditions are met, mod_evasive sends a 403 Forbidden response (the server understood the request, but refuses to fulfill it) and stops processing the request.

While refusal to comply serves to conserve bandwidth and resources, mod_evasive can only help up to the point that your bandwidth and other resources are saturated. Once a 403 is sent, the offending IP is automatically blocked for a configurable amount of time (the default is ten seconds). Additionally, you can send an email and/or run a system command to integrate the solution into your existing security infrastructure.

mod_evasive can be installed statically or as a DSO module, and supports both Apache 1.3 and Apache 2.x. The README has detailed instructions for both configurations. Here, let’s install mod_evasive as an Apache 2.x DSO.

After you’ve unpacked the download, apxs makes installing as a DSO trivial. Run the following command:

 $ $APACHE_ROOT/bin/apxs -i -a -c mod_evasive20.c

This builds the module, copies it to the appropriate directory, and loads it in your httpd.conf file using the LoadModule directive. If you restart httpd immediately after apxs, mod_evasive will run with its default settings. However, for clarity, add the following, which are all defaults, to httpd.conf.

 <IfModule mod_evasive>
     DOSHashTableSize    3097
     DOSPageCount        2
     DOSSiteCount        50
     DOSPageInterval     1
     DOSSiteInterval     1
     DOSBlockingPeriod   10
 </IfModule>

Explicitly spelling out the defaults provides a baseline to start from. Busy sites will likely need to raise some of the defaults, specifically the DOSPageCount, DOSPageInterval, DOSSiteCount, and DOSSiteInterval directives. There is a detailed description of each directive in the README, but to summarize, the trigger for blocking is X count per Y interval. The default is to block after 2 requests for the exact same URI from the same IP in under 1 second.

Once you implement mod_evasive, watch your logs extremely closely and modify your settings as necessary. You don’t want to block legitimate traffic, especially if that traffic is Googlebot or some other search engine spider that can bring welcome traffic. You can easily validate your setup with the included test.pl script. If you have legitimate reasons for specific IP’s to exceed your general thresholds, you can use the DOSWhitelist directive to ensure those never get blocked.

Once you have things working to your satisfaction, use the DOSSystemCommand directive to run commands to integrate mod_evasive into your existing infrastructure. Any application or device that can be controlled by a script or command running on the machine you have mod_evasive installed on can be integrated in this manner.

Optimization is only the first step in tuning a popular site. Protecting yourself from attacks using mod_evasive is yet another piece in the seemingly unending puzzle.

Jeremy Garcia is the founder and administrator of LinuxQuestions.org, a free, friendly, and active Linux community that filters its email with SpamAssassin. Please send questions and feedback to jeremy@linuxquestions.org.

Comments on "Mitigate Attacks With mod_evasive"

registerhater

What’s DOS? Denial of Service? Why are all the configuration options prepended with that stupid TLA?

Reply
rcbarnett

Mod_evasive does work relatively well for small to medium sized brute force or HTTP level DoS attacks. There is, however, an important limitation that mod_evasive has that you should be aware of. The mod_evasive module is not as good as it could be because it does not use shared memory in Apache to keep information about previous requests persistent. Instead, the information is kept with each child process or thread. Other Apache children that are then spawned know nothing about abuse against one of them. When a child serves the maximum number of requests and dies, the DoS information goes with it. So, what does this mean? This means that if an attacker sends their HTTP DoS requests and they do not use HTTP Keep-Alives, then Apache will spawn a new child process for every request and it will never trigger the mod_evasive thresholds. This is not good…

It is for this reason that Ivan Ristic (ModSecurity creator) created the script called httpd-guardian. It essentially monitors the Apache access_log data through piped logging and therefore can see requests across all child processes. Here is a good article that Ivan wrote on the subject for Oreilly OnLamp – http://www.onlamp.com/pub/a/apache/2005/12/01/modsecurity.html?page=last. For more information, check out Ivan’s site at – http://www.apachesecurity.net


Ryan C. Barnett
ModSecurity Community Manager
Breach Security: Director of Application Security Training
Web Application Security Consortium (WASC) Member
CIS Apache Benchmark Project Lead
SANS Instructor, GCIA, GCFA, GCIH, GSNA, GCUX, GSEC
Author: Preventing Web Attacks with Apache

Reply
sourceview

for me as a small businessperson, i would not select a GPL module for an Apache licensed piece of software. To me this smacks of programming imperialism by the programmer. Why not keep Apache “pure” Apache license? One of the reasons software like all of the Apache Foundation stuff, and such quality databases as postgresql work so well and persist over the decade is because of the lesser restrictive licenses. At the kernel level perhaps, since my small company doesn’t intend to re-write and improve the kernel, I believe the GPL may be less viral, but now it is possible to create (the kernel and filing systems being the only exceptions, a completly non-gpl distro! This model is much more fruitful for small businesses.

Reply
jgarcia

Ryan,
Thanks for the info!

Michael,
The GPL is only triggered on distribution, so I’m not sure where you draw the “small business” implications from.

Thanks for the feedback,
–jeremy
http://jeremy.linuxquestions.org/

Reply
juangiordana

“i”>

That’s a nice formatting rule :-/

Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>