Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
By jeremy at 2007-06-07 15:35
Mitigate Attacks With mod_evasive
Written by Jeremy Garcia
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.
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.