How to Install and Configure ModSecurity (WAF) on Apache

Introduction: Why Do You Need a Web Application Firewall?

If you are hosting a web application, e-commerce store, or API on an Apache server, traditional firewalls like UFW or iptables are not enough. They protect your server at the network layer (ports and IP addresses) but cannot see malicious traffic hidden inside normal HTTP/HTTPS requests.

This is where ModSecurity comes in. ModSecurity is an open-source Web Application Firewall (WAF) that actively monitors your web traffic in real-time. When paired with the OWASP Core Rule Set (CRS), it automatically blocks SQL Injections (SQLi), Cross-Site Scripting (XSS), bad bots, and other zero-day exploits before they ever reach your application logic.

Because WAF packet inspection requires constant CPU cycles and fast memory access, running ModSecurity on a high-performance Bare Metal Server ensures your website remains fast and responsive, even while actively scrubbing malicious traffic.

In this 2026 guide, we will walk you through installing and configuring ModSecurity on an Ubuntu 24.04 LTS bare metal server running Apache.

Need a secure, high-performance server?

A powerful Web Application Firewall needs dedicated CPU cores. Deploy a high-speed GTZHost NVMe Dedicated Server today with full root access to securely host your enterprise applications:

Prerequisites

Before you begin, ensure you have the following:

  • Hardware: A dedicated Linux server or NVMe VPS.

  • Operating System: Ubuntu 24.04 LTS (or 22.04 LTS) with root or sudo privileges.

  • Web Server: Apache2 installed and running.

Step 1: Install ModSecurity for Apache

First, connect to your server via SSH. Update your system package list and install the Apache ModSecurity module (libapache2-mod-security2).

bash 
sudo apt update && sudo apt upgrade -y
sudo apt install libapache2-mod-security2 -y

Once the installation is complete, you must explicitly enable the security2 module in Apache so it loads upon startup.

bash 
sudo a2enmod security2
sudo systemctl restart apache2

Step 2: Configure the ModSecurity Engine

By default, ModSecurity is installed in "DetectionOnly" mode. This means it will log malicious attempts but will not actually block them. We need to activate the blocking engine.

ModSecurity includes a recommended configuration file. We will rename it to activate it:

bash 
sudo mv /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf

Next, open the configuration file in your preferred text editor (like Nano):

bash 
sudo nano /etc/modsecurity/modsecurity.conf

Find the following line (usually near the top): SecRuleEngine DetectionOnly. Change it to:

plaintext 
SecRuleEngine On

(Save and close the file by pressing Ctrl+O, Enter, Ctrl+X). Restart Apache to apply the new engine rules:

bash 
sudo systemctl restart apache2

Step 3: Download the OWASP Core Rule Set (CRS)

ModSecurity is just the engine; it needs a set of rules to know what a cyber attack looks like. The industry standard is the OWASP Core Rule Set (CRS).

We will download the latest stable version from GitHub, extract it, and move it to a dedicated Apache configuration directory.

bash 
cd /tmp
wget https://github.com/coreruleset/coreruleset/archive/v3.3.4.tar.gz
tar xvf v3.3.4.tar.gz

Create a directory for the rules and move the extracted files:

bash 
sudo mkdir /etc/apache2/modsecurity-crs/
sudo mv coreruleset-3.3.4/* /etc/apache2/modsecurity-crs/

Navigate to the new directory and rename the setup file to activate it:

bash 
cd /etc/apache2/modsecurity-crs/
sudo cp crs-setup.conf.example crs-setup.conf

Step 4: Link the Rules to Apache

Now we must tell Apache where to find the OWASP rules we just downloaded. We do this by editing the security2.conf file.

Open the file:

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

You will see <IfModule security2_module>. Modify the contents inside this block so it looks exactly like the code below, ensuring both the setup file and the rules folder are included:

apache 
<IfModule security2_module>
        # Default Debian dir for modsecurity's data
        SecDataDir /var/cache/modsecurity

        # Include ModSecurity configuration
        IncludeOptional /etc/modsecurity/*.conf

        # Include OWASP CRS
        IncludeOptional /etc/apache2/modsecurity-crs/crs-setup.conf
        IncludeOptional /etc/apache2/modsecurity-crs/rules/*.conf
</IfModule>

(Save and close the file). Test your Apache configuration to ensure there are no syntax errors:

bash 
sudo apache2ctl -t

(You should see "Syntax OK"). Restart Apache to load the new firewall rules:

bash 
sudo systemctl restart apache2

Step 5: Test the Web Application Firewall

Your WAF is now active! To verify that ModSecurity is actively blocking threats, we can simulate a malicious request—like a basic SQL Injection attack—from your terminal.

Run a curl command against your own server using a malicious query string:

bash 
curl "http://localhost/?id=1' OR 1=1"

Expected Output:
Instead of your website's HTML, you should receive a 403 Forbidden error page. This confirms that ModSecurity successfully intercepted the payload, identified the SQL Injection signature from the OWASP rules, and dropped the connection.

Frequently Asked Questions (FAQ)

Q: Where are the ModSecurity block logs located?

A: If a user is blocked, ModSecurity logs the exact rule that was triggered. You can inspect these logs to investigate attacks or troubleshoot issues by viewing the Apache error log: sudo tail -f /var/log/apache2/error.log.

Q: Why am I getting false positives (legitimate users being blocked)?

A: The OWASP CRS is very strict out of the box. If legitimate application traffic is being blocked (a "false positive"), check the error log to find the specific id of the rule that was triggered. You can then write a custom rule exclusion in your Apache virtual host configuration to bypass that specific rule ID.

Q: Will ModSecurity slow down my website?

A: Because ModSecurity inspects every incoming HTTP request against hundreds of regular expressions, it does consume CPU and RAM. On shared hosting, this can cause a noticeable delay. However, if you are hosting your application on a modern Bare Metal Dedicated Server, the performance impact is negligible.

Q: Can I use ModSecurity with Nginx?

A: Yes. While this guide covers Apache (which uses libapache2-mod-security2), you can compile ModSecurity v3 (libmodsecurity3) as a dynamic module for Nginx.

Conclusion

By installing ModSecurity and the OWASP Core Rule Set, you have transformed your basic Apache web server into a hardened fortress capable of deflecting the most common application-layer cyber attacks automatically.

Security requires resources. Don't let heavy WAF filtering slow down your user experience. Deploy an Enterprise Dedicated Server with GTZHost today and give your web applications the dedicated CPU and NVMe IOPS they need to stay secure and lightning-fast. Contact us today!