Apache mod_security module: A practical guide

Updated: January 21, 2024 By: Guest Contributor Post a comment

Introduction

Apache’s mod_security module is a powerful tool for enhancing web application security. It works as a Web Application Firewall (WAF) that can block malicious requests before they reach your application. In this tutorial, we’ll take a practical approach to setting up mod_security on an Apache web server.

Understanding mod_security

mod_security is an open-source, cross-platform web application firewall that enables monitoring, logging, and access control for HTTP transactions. It serves to protect your web applications from a variety of attacks, such as SQL injection, cross-site scripting (XSS), and other known vulnerabilities.

Installation

To begin with, mod_security requires Apache to be installed on your server. Once Apache is ready, you can install mod_security. For Debian-based systems, you can use:

sudo apt-get install libapache2-mod-security2

On Red Hat-based systems:

sudo yum install mod_security

Initial Configuration

After installation, the default configuration file will be placed at /etc/modsecurity/modsecurity.conf. You should backup the original configuration file, then open it in a text editor:

sudo cp /etc/modsecurity/modsecurity.conf /etc/modsecurity/modsecurity.conf.orig
sudo nano /etc/modsecurity/modsecurity.conf

Look for the following line to make sure mod_security is in detection-only mode:

SecRuleEngine DetectionOnly

Change DetectionOnly to On to make mod_security actively block malicious requests:

SecRuleEngine On

Core Rule Set (CRS)

mod_security by itself doesn’t protect your web applications – it’s the rules that define its behavior. The OWASP ModSecurity Core Rule Set (CRS) is a set of generic attack detection rules that provide a base level of protection for any web application and is recommended for use with mod_security.

To install OWASP CRS on Debian-based systems:

sudo apt-get install modsecurity-crs

On Red Hat-based systems:

sudo yum install mod_security_crs

After installing the Core Rule Set, you’ll need to include these rules within the mod_security module. To do this, create a symbolic link between the CRS configuration directory and the mod_security modules directory:

sudo ln -s /usr/share/modsecurity-crs/base_rules /etc/modsecurity

And include them in the configuration:

IncludeOptional /etc/modsecurity/*.conf
IncludeOptional /etc/modsecurity/base_rules/*.conf

Writing Custom Rules

Although the CRS provides a strong baseline of security, you may need to tailor the rules to better fit your application. mod_security rules are written using the following syntax:

SecRule VARIABLE:[collection] OPERATOR [transformation] ACTION

For example, to block requests with a specific User-Agent header:

SecRule REQUEST_HEADERS:User-Agent "bad-bot" "id:'123456',phase:1,deny,status:403,msg:'Blocked bad bot.'"

Testing Your Configuration

Before deploying mod_security into a production environment, you should thoroughly test your configuration to ensure that legitimate traffic isn’t accidentally blocked. One way to test is by sending a test request that you know should be blocked:

curl -H "User-Agent: bad-bot" http://yourserver.com

If you receive a 403 Forbidden response, then mod_security is working to block this request as expected.

Monitoring and Logging

Monitoring and analyzing mod_security’s logs are critical for understanding the types of attacks that your application is facing, as well as for troubleshooting any issues with legitimate traffic being blocked.

Log files are located by default at /var/log/apache2/modsec_audit.log. Be certain to regularly review these logs and adjust your rules accordingly.

Conclusion

mod_security is a highly flexible and essential tool for securing your web applications. Installation and base configuration can be completed quickly, but mastering its use takes time and a deep understanding of the threats your applications face. Regular updates to the CRS and vigilant monitoring of your logs will help you stay ahead of potential threats.

Remember that security is an ongoing process, so continuously review, update, and test your configurations to ensure robust security for your web applications.