How to Install the ModSecurity Apache Module

The Apache web server software can be customized to suit your needs with many third party modules. One of the most popular Apache security modules is ModSecurity. It operates as a signature-based firewall, capable of blocking cross-site scripting (XSS), brute force attacks, and known code injection attacks for dynamic websites that depend on SQL and PHP. Some even use ModSecurity for PCI compliance.

Instead of siphoning sensitive data, attempted cyber attackers will be blocked by ModSecurity with a 403 error.

ModSecurity can process events as a host-based intrusion detection system (HIDS) or intrusion prevention system (IPS) application depending on how you configure it.

ModSecurity is pre-configured on our cPanel server hosting so you don’t need to when securing your dedicated server or VPS. Many cPanel administrators rarely modify ModSecurity unless they need to temporarily disable it for a system administration task. Meanwhile, non-cPanel servers may not include ModSecurity, especially if you have to install Apache manually on CentOS or Debian/Ubuntu. This provides flexibility with how you secure your cloud server.

Although not covered in this article, ModSecurity is also natively available for NGINX web server.

SSH into your server. Then we’ll cover:

• Installing ModSecurity
  • CentOS
  • Debian
  • Ubuntu
• Configuring ModSecurity
• OWASP Core Rule Set (CRS) for ModSecurity
• Test ModSecurity Configuration

Installing ModSecurity

CentOS

1. Update software repositories:

   sudo yum update -y

2. Download and install the ModSecurity Apache module:

   sudo yum install mod_security 

3. Type y.
4. Restart the Apache service:

   sudo systemctl restart httpd

5. Ensure the installed software version is at least 2.9:

   yum info mod_security

Debian

1. Update software repos:

   sudo apt update -y

2. Download and install the ModSecurity Apache module:

   sudo apt install libapache2-mod-security2

3. Type Y.
4. Restart the Apache service:

   sudo systemctl restart apache2 

5. Ensure the installed software version is at least 2.9:

   apt-cache show libapache2-mod-security2 | grep -E '(Version|Package)

   This command will grep for 2 things at once

Ubuntu

1. Update software repos:

   sudo apt update -y

2. Download and install the ModSecurity Apache module:

   sudo apt install libapache2-mod-security2

3. Type Y.
4. Restart the Apache service:

   sudo systemctl restart apache2 

5. Ensure the installed software version is at least 2.9:

   apt-cache show libapache2-mod-security2 

Configure ModSecurity

ModSecurity is set to detect and log suspicious events only by default. Below we’ll configure it to detect and block suspicious activity.

1. Copy the default ModSecurity configuration file to a new file:

   sudo cp /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf

2. Edit the ModSecurity configuration file with Vi, Vim, Emacs, or Nano.

   sudo nano /etc/modsecurity/modsecurity.conf

3. Near the top of the file, you’ll see SecRuleEngine DetectionOnly. Change DetectionOnly to On.
4. Save changes.
5. Restart Apache:

   systemctl restart apache2 

Download OWASP Core Rule Set

To ensure you have the latest ModSecurity rules, you can download the latest ModSecurity Core Rule Set (CRS) from Open Web Application Security Project (OWASP) at CoreRuleSet.org.

1. While logged into your server, download the latest CRS from CoreRuleSet.org/installation, replacing the GitHub URL as needed:

   wget https://github.com/coreruleset/coreruleset/archive/v3.3.0.zip

2. Verify the checksum (Windows, MacOS, *nix) of your downloaded file against the provided message digest, replacing “vFileName” with the actual file name (e.g. v3.3.0.zip). For example:
   Windows:

   certutil -hashfile vFileName.zip sha1; echo ProvidedChecksum

   
   Mac:

   shasum vFileName.zip && echo ProvidedChecksum

   
   *nix:

   sha1sum vFileName.zip && echo ProvidedChecksum 

3. If the checksums differ, troubleshoot why the checksums don’t match before continuing to ensure you don’t execute a corrupted or malicious file.
4. Unzip the file:

   unzip FileName.zip

5. Move the CRS setup file from the new directory into your ModSecurity directory:

   mv coreruleset-3.3.0/crs-setup.conf.example /etc/modsecurity/crs-setup.conf

6. (Optional but recommended) Move the rules directory from the new directory to your ModSecurity directory:

   mv coreruleset-3.3.0/rules/ /etc/modsecurity/

7. Edit your Apache security2.conf file to ensure it’ll load ModSecurity rules:

   nano /etc/apache2/mods-enabled/security2.conf

8. Ensure both the default ModSecurity and new CRS configuration files are listed. The first line conf file path may already be included. The second file path should be wherever you moved the /rules directory.
   

   IncludeOptional /etc/modsecurity/*.conf
   Include /etc/modsecurity/rules/*.conf

9. Restart Apache:

   systemctl restart apache2

Can’t Restart Apache

1. If Apache fails to restart, check the status for error information:

   systemctl status apache 

2. For this example, I received the error: AH00526: Syntax error on line 845 of /etc/modsecurity/crs/crs-setup.conf. To resolve this error, edit the Apache security configuration file again:

   /etc/apahc2/mods-enabled/security2.conf

3. Comment out this file path by adding a # in the beginning of the line: # IncludeOptional /usr/share/modsecurity-crs/owasp-crs.load.
4. Save changes.
5. Apache should now restart successful:

   systemctl restart apache2

If you continue to have issues, contact Live Support directly.

Test ModSecurity Configuration

Afterwards, you should test your ModSecurity setup to ensure it blocks suspicious network traffic. Below we’ll create a test blocking rule and check if we receive a 403 error and a ModSecurity log entry.

1. Edit your default Apache configuration file:

   sudo nano /etc/apache2/sites-available/000-default.conf

2. At the bottom of the file, above </VirtualHost>, add the following custom ModSecurity rule:

   SecRuleEngine On
   SecRule ARGS:testparam "@contains test" "id:999,deny,status:403,msg:'Test Successful'"

   Change the id number and message (msg) as desired.
3. Save changes.
4. Restart Apache:

   systemctl restart apache2

5. In your browser, attempt to access a URL on that server with ?testparam=test on the end (e.g. domain.com/?testparam=test.
6. You should receive a 403 Forbidden error.
7. You can confirm this by searching your Apache error log for ModSecurity errors using your error message (“Test Successful”) or id number (999):

   cat /var/log/apache2/error.log | grep ‘Test Successful’

You can remove the rule afterwards if you wish.

ModSecurity is capable of so much more. However, it’s still not a complete security solution regardless of how many rule sets you integrate with it. You still need other types of security controls to secure your business data including:

• Scheduled anti-virus scanning to protect file integrity (we recommend ClamAV or Imunify)
• Server firewalls for port managment (e.g. CSF, Firewalld, and UFW) and software firewalls for web applications including the WordPress content management systems (CMS)
• Recent, verified backups for disaster recovery
• Website analytics for auditing the effectiveness of the aforementioned technical controls

Protect your website from denial-of-service (DoS) attacks and boost website performance with the Sucuri web application firewall (WAF).

Do you have a security information and event management (SIEM) solution for your network? Learn more about how to get the most out of your ModSecurity application by integrating your ModSecurity logs into the Splunk Enterprise (SIEM) suite.