How to Configure ModSecurity on Apache

Traducciones al Español
Estamos traduciendo nuestros guías y tutoriales al Español. Es posible que usted esté viendo una traducción generada automáticamente. Estamos trabajando con traductores profesionales para verificar las traducciones de nuestro sitio web. Este proyecto es un trabajo en curso.
Create a Linode account to try this guide with a $ credit.
This credit will be applied to any valid services used during your first  days.


ModSecurity is a web application firewall for the Apache web server. In addition to providing logging capabilities, ModSecurity can monitor HTTP traffic in real time in order to detect attacks. ModSecurity also operates as an intrusion detection tool, allowing you to react to suspicious events that take place on your web systems.

Although ModSecurity comes with a default configuration, this guide will use OWASP ModSecurity Core Rule Set (CRS) version 3.0.2. The OWASP project’s goal is to “provide an easily ‘pluggable’ set of generic attack detection rules that provide a base level of protection for any web application,” and the CRS is intended to “protect web applications from a wide range of attacks….with a minimum of false alerts.” This version of the CRS requires ModSecurity 2.8.0 or higher. Configuration is done through rule sets to prevent common attacks such as SQL injections, cross site scripting, and remote code execution. This guide will show how to set up the default rules. Advanced configurations are left as a challenge for the reader.

Install ModSecurity

Before you install ModSecurity, you will need to have Apache installed on your Linode. This guide will use a LAMP stack; for installation instructions, see the LAMP Guides.

Ubuntu or Debian

sudo apt-get install libapache2-mod-security2

Restart Apache:

/etc/init.d/apache2 restart

Verify the version of ModSecurity is 2.8.0 or higher:

apt-cache show libapache2-mod-security2
When listing all mods using apachectl -M, ModSecurity is listed under the name security2_module.


yum install mod_security

Restart Apache by entering the following command:

/etc/init.d/httpd restart

Verify the version of ModSecurity is 2.8.0 or higher:

yum info mod_security

OWASP ModSecurity Core Rule Set

The following steps are for Debian based distributions. File paths and commands for RHEL will differ slightly.

  1. Move and change the name of the default ModSecurity file:

    mv /etc/modsecurity/modsecurity.conf-recommended  modsecurity.conf
  2. Install git if needed:

    sudo apt install git
  3. Download the OWASP ModSecurity CRS from Github:

    git clone
  4. Navigate into the downloaded directory. Move and rename crs-setup.conf.example to crs-setup.conf. Then move rules/ as well.

    cd owasp-modsecurity-crs
    mv crs-setup.conf.example /etc/modsecurity/crs-setup.conf
    mv rules/ /etc/modsecurity/
  5. The configuration file should match the path above as defined in the IncludeOptional directive. Add another Include directive pointing to the rule set:

    File: etc/apache2/mods-available/security2.conf
    <IfModule security2_module>
            # Default Debian dir for modsecurity's persistent data
            SecDataDir /var/cache/modsecurity
            # Include all the *.conf files in /etc/modsecurity.
            # Keeping your local configuration in that directory
            # will allow for an easy upgrade of THIS file and
            # make your life easier
            IncludeOptional /etc/modsecurity/*.conf
            Include /etc/modsecurity/rules/*.conf
  6. Restart Apache so that the changes will take effect:

    /etc/init.d/apache2 restart

ModSecurity Test

OWASP CRS builds on top of ModSecurity so that existing rules can be extended.

  1. Navigate to the default Apache configuration and add two additional directives, using the default configuration as an example:

    File: /etc/apache2/sites-available/000-default.conf
    <VirtualHost *:80>
        ServerAdmin webmaster@localhost
        DocumentRoot /var/www/html
        ErrorLog ${APACHE_LOG_DIR}/error.log
        CustomLog ${APACHE_LOG_DIR}/access.log combined
        SecRuleEngine On
        SecRule ARGS:testparam "@contains test" "id:1234,deny,status:403,msg:'Our test rule has triggered'"
  2. Restart Apache then curl the index page to intentionally trigger the alarms:

    curl localhost/index.html?testparam=test

    The response code should be 403. There should be a message in the logs that shows the defined ModSecurity rule worked. You can check using: sudo tail -f /var/log/apache2/error.log

    ModSecurity: Access denied with code 403 (phase 2). String match "test" at ARGS:testparam. [file "/etc/apache2/sites-enabled/000-default.conf"] [line "24"] [id "1234"] [msg "Our test rule has triggered"] [hostname "localhost"] [uri "/index.html"] [unique_id "WfnEd38AAAEAAEnQyBAAAAAB"]
  3. Verify the OWASP CRS is in effect:

    curl localhost/index.html?exec=/bin/bash

    Check the error logs again: the rule has caught the attempted execution of an arbitrary bash script.

    ModSecurity: Warning. Matched phrase "bin/bash" at ARGS:. [file "/etc/modsecurity/rules/REQUEST-932-APPLICATION-ATTACK-RCE.conf"] [line "448"] [id "932160"] [rev "1"] [msg "Remote Command Execution: Unix Shell Code Found"] [data "Matched Data: bin/bash found within ARGS:: exec/bin/bash"] [severity "CRITICAL"] [ver "OWASP_CRS/3.0.0"] [maturity "1"] [accuracy "8"] [tag "application-multi"] [tag "language-shell"] [tag "platform-unix"] [tag "attack-rce"] [tag "OWASP_CRS/WEB_ATTACK/COMMAND_INJECTION"] [tag "WASCTC/WASC-31"] [tag "OWASP_TOP_10/A1"] [tag "PCI/6.5.2"] [hostname "localhost"] [uri "/index.html"] [unique_id "WfnVf38AAAEAAEqya3YAAAAC"]

Next Steps

Review the configuration files located in /etc/modsecurity/*.conf. Most of the files are commented with definitions of the available options. ModSecurity uses an Anomaly Scoring Level where the highest number (5) is most severe. Review the wiki for additional directives to update the rules when encountering false positives.

More Information

You may wish to consult the following resources for additional information on this topic. While these are provided in the hope that they will be useful, please note that we cannot vouch for the accuracy or timeliness of externally hosted materials.

This page was originally published on

Your Feedback Is Important

Let us know if this guide was helpful to you.

Join the conversation.
Read other comments or post your own below. Comments must be respectful, constructive, and relevant to the topic of the guide. Do not post external links or advertisements. Before posting, consider if your comment would be better addressed by contacting our Support team or asking on our Community Site.
The Disqus commenting system for Linode Docs requires the acceptance of Functional Cookies, which allow us to analyze site usage so we can measure and improve performance. To view and create comments for this article, please update your Cookie Preferences on this website and refresh this web page. Please note: You must have JavaScript enabled in your browser.