How to Install ModSecurity and OWASP CRS with Apache on Ubuntu (26.04, 24.04, 22.04)

ModSecurity is an open-source web application firewall (WAF) that monitors HTTP traffic and blocks common attack patterns. If you run WordPress, phpMyAdmin, custom PHP applications, or any web service exposed to the internet, ModSecurity with the OWASP Core Rule Set provides protection against SQL injection, cross-site scripting (XSS), and command injection attacks without requiring application code changes.

By the end of this guide, you will have ModSecurity configured with the OWASP CRS protecting your Apache server, real-time request filtering that blocks malicious payloads before they reach your application, and configurable rule sets you can tune to reduce false positives. For production deployments, combine this setup with SSL/TLS encryption using Let’s Encrypt for complete transport security.

This guide covers Ubuntu 26.04, 24.04, and 22.04 LTS. The installation method varies depending on your Ubuntu version and whether you want to use the latest CRS 4.x rules.

ModSecurity and CRS Version Compatibility

Understanding version compatibility is essential before choosing an installation method. OWASP CRS 4.x requires ModSecurity 2.9.6 or newer because it uses the @within operator, which was introduced in that version. Ubuntu’s default repositories provide different ModSecurity versions depending on your release:

Ubuntu Release	Default ModSecurity	Default CRS	CRS 4.x Compatible
Ubuntu 26.04 LTS	2.9.12	3.3.x	Yes (native)
Ubuntu 24.04 LTS	2.9.7	3.3.x	Yes (native)
Ubuntu 22.04 LTS	2.9.5	3.3.x	No (requires 2.9.6+)

Ubuntu 22.04 users who want CRS 4.x must use the Digitalwave third-party repository, which provides ModSecurity 2.9.13. Ubuntu 24.04 and 26.04 users can install CRS 4.x directly from GitHub using their default ModSecurity packages.

Choose Your Installation Method

This guide provides three installation paths based on your requirements:

Method	Ubuntu Versions	CRS Version	Best For
Default Repositories	26.04, 24.04, 22.04	3.3.x (packaged)	Simple setup, automatic updates via APT
GitHub CRS 4.x	26.04, 24.04	4.x (latest)	Newest detection rules, manual updates
Digitalwave Repository	24.04, 22.04	3.3.x or 4.x	Ubuntu 22.04 users who need CRS 4.x

Both CRS 3.x and 4.x branches are actively maintained by the OWASP project. CRS 3.x receives continued security updates alongside CRS 4.x, so using the packaged version still provides strong protection. The main advantage of CRS 4.x is access to newer detection rules and features.

Update Ubuntu System Packages

Before installing new software, update your package lists and upgrade existing packages to their latest versions:

sudo apt update && sudo apt upgrade

Install Apache HTTP Server

ModSecurity requires Apache as the underlying web server. If Apache is not already installed, install it with:

sudo apt install apache2

Verify Apache installed correctly and check its status:

sudo systemctl status apache2 --no-pager

Expected output shows Apache as active and running:

● apache2.service - The Apache HTTP Server
     Loaded: loaded (/usr/lib/systemd/system/apache2.service; enabled; preset: enabled)
     Active: active (running) since Sat 2026-01-25 07:53:41 UTC; 5min ago
   Main PID: 1234 (apache2)
...

For a detailed Apache setup, see our Apache installation guide for Ubuntu.

Install ModSecurity Apache Module

Choose one of the following installation methods based on the compatibility table above. Most users should start with the default repository method. Ubuntu 22.04 users who specifically need CRS 4.x should use the Digitalwave repository method.

Method 1: Install from Default Ubuntu Repositories

This method works on all supported Ubuntu releases and provides automatic security updates through APT:

sudo apt install libapache2-mod-security2

Verify the installed version:

dpkg -l libapache2-mod-security2 | grep ^ii

Example output on Ubuntu 24.04:

ii  libapache2-mod-security2  2.9.7-1build3  amd64  Apache web application firewall module

Method 2: Install from Digitalwave Repository (Ubuntu 22.04/24.04)

The Digitalwave repository provides newer ModSecurity packages that support CRS 4.x on Ubuntu 22.04. This method is also available for Ubuntu 24.04 users who want the latest backported packages.

The Digitalwave repository does not currently support Ubuntu 26.04 (resolute). Ubuntu 26.04 users should use the default repositories, which already include ModSecurity 2.9.12.

Install the required dependencies for repository management:

sudo apt install lsb-release ca-certificates curl -y

Import the repository GPG key:

curl -fsSL https://modsecurity.digitalwave.hu/archive.key | sudo gpg --dearmor -o /usr/share/keyrings/digitalwave-modsecurity.gpg

Add the repository using the modern DEB822 format:

cat <<EOF | sudo tee /etc/apt/sources.list.d/digitalwave-modsecurity.sources
Types: deb
URIs: http://modsecurity.digitalwave.hu/ubuntu/
Suites: $(lsb_release -cs) $(lsb_release -cs)-backports
Components: main
Architectures: $(dpkg --print-architecture)
Signed-By: /usr/share/keyrings/digitalwave-modsecurity.gpg
EOF

Configure APT pinning to prioritize the Digitalwave packages over default Ubuntu packages:

cat <<EOF | sudo tee /etc/apt/preferences.d/99modsecurity
Package: *libapache2-mod-security2*
Pin: origin modsecurity.digitalwave.hu
Pin-Priority: 900

Package: *modsecurity-crs*
Pin: origin modsecurity.digitalwave.hu
Pin-Priority: 900

Package: *libmodsecurity*
Pin: origin modsecurity.digitalwave.hu
Pin-Priority: 900
EOF

Update the package list and install ModSecurity:

sudo apt update
sudo apt install libapache2-mod-security2

Verify the Digitalwave version is installed:

apt-cache policy libapache2-mod-security2

Expected output shows the Digitalwave repository with priority 900:

libapache2-mod-security2:
  Installed: 2.9.13-1~pre1+0~20250805~bpo22.04+18cae50
  Candidate: 2.9.13-1~pre1+0~20250805~bpo22.04+18cae50
  Version table:
 *** 2.9.13-1~pre1+0~20250805~bpo22.04+18cae50 900
        900 http://modsecurity.digitalwave.hu/ubuntu jammy-backports/main amd64 Packages
        100 /var/lib/dpkg/status
     2.9.5-1 500
        500 http://archive.ubuntu.com/ubuntu jammy/universe amd64 Packages

Verify the Module Is Enabled

Regardless of which installation method you used, verify the security2 module is enabled in Apache:

sudo apachectl -M | grep security

Expected output:

 security2_module (shared)

If the module is not listed, enable it manually:

sudo a2enmod security2
sudo systemctl restart apache2

Configure ModSecurity

ModSecurity comes with a recommended configuration file that you need to activate. Copy the sample configuration to create the active configuration file:

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

Open the configuration file for editing:

sudo nano /etc/modsecurity/modsecurity.conf

Enable Active Blocking Mode

By default, ModSecurity runs in DetectionOnly mode, which logs suspicious requests but does not block them. This is useful for initial deployment to identify false positives before enabling active blocking.

To enable active blocking, find this line near the top of the file (around line 7):

SecRuleEngine DetectionOnly

Change it to:

SecRuleEngine On

Consider running in DetectionOnly mode for a few days after initial deployment. This allows you to review logs at /var/log/apache2/modsec_audit.log and identify false positives before enabling active blocking. Once you are confident the rules are not blocking legitimate traffic, switch to On.

Configure Audit Logging

The default SecAuditLogParts setting does not log all useful information for troubleshooting. Find the SecAuditLogParts directive (around line 224):

SecAuditLogParts ABDEFHIJZ

Change it to include request body, response body, and matched rules:

SecAuditLogParts ABCEFHJKZ

Each letter represents a section of the audit log:

• A – Audit log header (timestamp, unique ID)
• B – Request headers
• C – Request body (useful for POST data analysis)
• E – Response body
• F – Final response headers
• H – Audit log trailer with additional data
• J – Upload file information
• K – Matched rules (essential for debugging)
• Z – Final boundary marker

Save the file and exit the editor (Ctrl+O to save, Ctrl+X to exit in nano).

Restart Apache to apply the configuration changes:

sudo systemctl restart apache2

Install OWASP Core Rule Set (CRS)

ModSecurity provides the firewall engine, but it needs rules to detect attacks. The OWASP Core Rule Set (CRS) is the industry-standard rule set that protects against common web attacks including SQL injection, XSS, remote code execution, and more.

Choose your CRS installation method based on your requirements:

Option 1: Install CRS from Ubuntu Repositories

This is the simplest method and works on all Ubuntu releases. It provides CRS 3.x with automatic updates through APT:

sudo apt install modsecurity-crs

This package automatically configures itself with ModSecurity. Verify the installation:

dpkg -l modsecurity-crs | grep ^ii

Example output on Ubuntu 24.04:

ii  modsecurity-crs  3.3.5-2  all  OWASP ModSecurity Core Rule Set

Restart Apache to load the rules:

sudo systemctl restart apache2

Skip to the “Verify ModSecurity Is Working” section to test your installation.

Option 2: Install Latest CRS 4.x from GitHub (Ubuntu 24.04/26.04)

This option requires Ubuntu 24.04 or 26.04 with the default repositories, or Ubuntu 22.04 with ModSecurity installed from the Digitalwave repository. Ubuntu 22.04 users with default packages cannot use CRS 4.x because it uses the @within operator which requires ModSecurity 2.9.6 or newer.

This method automatically detects and downloads the latest CRS release from the official GitHub repository, providing access to CRS 4.x with the most current security rules.

First, ensure curl is installed for downloading:

sudo apt install curl -y

Create the CRS directory:

sudo mkdir -p /etc/apache2/modsec

Download and install the latest CRS release automatically:

CRS_VERSION=$(curl -s https://api.github.com/repos/coreruleset/coreruleset/releases/latest | grep '"tag_name"' | cut -d'"' -f4)
echo "Downloading OWASP CRS $CRS_VERSION..."
curl -fSL "https://github.com/coreruleset/coreruleset/archive/refs/tags/${CRS_VERSION}.tar.gz" -o /tmp/crs.tar.gz
sudo tar xzf /tmp/crs.tar.gz -C /etc/apache2/modsec --strip-components=1
rm /tmp/crs.tar.gz
echo "OWASP CRS $CRS_VERSION installed to /etc/apache2/modsec/"

This script uses curl -fSL to download the archive (-f fails silently on HTTP errors, -S shows errors, -L follows redirects). The --strip-components=1 flag removes the top-level directory from the archive so files extract directly into /etc/apache2/modsec/.

Copy the example configuration file to create the active CRS configuration:

sudo cp /etc/apache2/modsec/crs-setup.conf.example /etc/apache2/modsec/crs-setup.conf

Copy the rule exclusion templates so you can add custom exclusions later:

sudo cp /etc/apache2/modsec/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example /etc/apache2/modsec/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf
sudo cp /etc/apache2/modsec/rules/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf.example /etc/apache2/modsec/rules/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf

Now configure Apache to load the CRS rules. Edit the ModSecurity module configuration:

sudo nano /etc/apache2/mods-available/security2.conf

Replace the entire contents with:

    SecDataDir /var/cache/modsecurity

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

    # Include OWASP CRS configuration and rules
    Include /etc/apache2/modsec/crs-setup.conf
    Include /etc/apache2/modsec/rules/*.conf

On Ubuntu 26.04, remove the default CRS configuration to prevent rule ID conflicts:

sudo rm -f /etc/modsecurity/crs/crs-setup.conf 2>/dev/null

Test the Apache configuration for syntax errors:

sudo apachectl configtest

Expected output:

Syntax OK

Restart Apache to load the rules:

sudo systemctl restart apache2

Verify ModSecurity Is Working

Test that ModSecurity correctly blocks malicious requests by sending a request that triggers a rule. Open a terminal and run:

curl -I "http://localhost/?exec=/bin/bash"

If ModSecurity is working correctly with the CRS, you should receive a 403 Forbidden response:

HTTP/1.1 403 Forbidden
Date: Sat, 25 Jan 2026 08:00:00 GMT
Server: Apache/2.4.65 (Ubuntu)
Content-Type: text/html; charset=iso-8859-1

If you receive a 200 OK response instead, verify that:

• SecRuleEngine is set to On (not DetectionOnly)
• The CRS rules are properly included in security2.conf
• Apache was restarted after configuration changes

You can also test via your web browser by visiting https://yourdomain.com/?exec=/bin/bash (replace with your actual domain). A 403 Forbidden error page confirms ModSecurity is actively protecting your server.

Understanding OWASP CRS Configuration

The CRS provides extensive configuration options in the crs-setup.conf file. This section covers the most important settings you should understand.

Open the CRS configuration file:

sudo nano /etc/apache2/modsec/crs-setup.conf

Anomaly Scoring Mode

CRS operates in anomaly scoring mode by default. Instead of blocking on the first matched rule, each rule adds points to an “anomaly score.” When the score exceeds a threshold, the request is blocked. This approach reduces false positives by requiring multiple indicators before blocking.

The default thresholds are:

• Inbound anomaly threshold: 5 points (blocks requests with 5+ points)
• Outbound anomaly threshold: 4 points (blocks responses with 4+ points)

Higher thresholds allow more potentially suspicious traffic through but reduce false positives.

Paranoia Levels

CRS has four paranoia levels that control how aggressively rules detect threats:

1. Paranoia Level 1 (default): Core rules with minimal false positives. Suitable for most websites.
2. Paranoia Level 2: Enables additional rules. May require tuning for some applications.
3. Paranoia Level 3: Strict rules intended for high-security applications. Expect false positives.
4. Paranoia Level 4: Maximum security, high false positive rate. Only for specialized use cases.

Start with level 1 and only increase after monitoring your logs for a few weeks to understand your traffic patterns.

Handling False Positives

False positives (legitimate requests blocked incorrectly) are common when first deploying a WAF. The CRS provides several methods to handle them.

Enable Application-Specific Exclusions

CRS includes pre-built exclusions for popular applications. In crs-setup.conf, find and uncomment the exclusions for applications you use:

SecAction \
 "id:900130,\
  phase:1,\
  nolog,\
  pass,\
  t:none,\
  setvar:tx.crs_exclusions_wordpress=1,\
  setvar:tx.crs_exclusions_phpmyadmin=1"

Available exclusions include: cpanel, dokuwiki, drupal, nextcloud, phpbb, phpmyadmin, wordpress, and xenforo.

Create Custom Rule Exclusions

For custom exclusions, edit the before-CRS exclusion file:

sudo nano /etc/apache2/modsec/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf

Each exclusion rule needs a unique ID. Here are common exclusion patterns:

Disable rules for a specific URL path:

SecRule REQUEST_URI "@beginsWith /admin/api/" "id:1000,phase:1,pass,nolog,ctl:ruleRemoveById=941000-942999"

Whitelist an IP address from all rules:

SecRule REMOTE_ADDR "@ipMatch 192.168.1.100" "id:1001,phase:1,allow,nolog,ctl:ruleEngine=off"

Whitelist a subnet:

SecRule REMOTE_ADDR "@ipMatch 10.0.0.0/8" "id:1002,phase:1,allow,nolog,ctl:ruleEngine=off"

Disable a specific rule globally:

SecRuleRemoveById 942100

To identify which rule is causing false positives, check the ModSecurity audit log:

sudo tail -f /var/log/apache2/modsec_audit.log

Look for lines containing the rule ID (e.g., [id "942100"]) that triggered the block.

Configure Log Rotation

ModSecurity logs can grow large quickly on busy servers. Configure log rotation to manage disk space:

sudo nano /etc/logrotate.d/modsecurity

Add the following configuration:

/var/log/apache2/modsec_audit.log {
    rotate 14
    daily
    missingok
    compress
    delaycompress
    notifempty
    create 640 root adm
}

This configuration keeps 14 days of logs, compresses old logs, and creates new log files with appropriate permissions.

Update OWASP CRS

If you installed CRS from GitHub, periodically update to get new rules and security fixes. The following script automates this process:

sudo nano /usr/local/bin/update-owasp-crs.sh

Add the following content:

#!/bin/bash
# OWASP CRS Update Script for ModSecurity on Apache

set -e

CRS_DIR="/etc/apache2/modsec"
BACKUP_DIR="/etc/apache2/modsec-backup-$(date +%Y%m%d)"

# Get current and latest versions
CURRENT_VERSION=""
if [ -f "$CRS_DIR/CHANGES.md" ]; then
    CURRENT_VERSION=$(grep -m1 "^## Version" "$CRS_DIR/CHANGES.md" | awk '{print $3}')
fi

LATEST_VERSION=$(curl -s https://api.github.com/repos/coreruleset/coreruleset/releases/latest | grep '"tag_name"' | cut -d'"' -f4)

echo "Current CRS version: ${CURRENT_VERSION:-Not installed}"
echo "Latest CRS version: $LATEST_VERSION"

if [ "$CURRENT_VERSION" = "${LATEST_VERSION#v}" ]; then
    echo "CRS is already up to date."
    exit 0
fi

echo "Updating to $LATEST_VERSION..."

# Backup current installation
if [ -d "$CRS_DIR" ]; then
    echo "Backing up current installation to $BACKUP_DIR"
    sudo cp -r "$CRS_DIR" "$BACKUP_DIR"
fi

# Preserve custom configuration
CUSTOM_SETUP=""
if [ -f "$CRS_DIR/crs-setup.conf" ]; then
    CUSTOM_SETUP=$(cat "$CRS_DIR/crs-setup.conf")
fi

# Download and extract new version
curl -fSL "https://github.com/coreruleset/coreruleset/archive/refs/tags/${LATEST_VERSION}.tar.gz" -o /tmp/crs.tar.gz
sudo rm -rf "$CRS_DIR"/*
sudo tar xzf /tmp/crs.tar.gz -C "$CRS_DIR" --strip-components=1
rm /tmp/crs.tar.gz

# Restore or create configuration
if [ -n "$CUSTOM_SETUP" ]; then
    echo "$CUSTOM_SETUP" | sudo tee "$CRS_DIR/crs-setup.conf" > /dev/null
    echo "Restored custom crs-setup.conf"
else
    sudo cp "$CRS_DIR/crs-setup.conf.example" "$CRS_DIR/crs-setup.conf"
fi

# Setup exclusion files
sudo cp "$CRS_DIR/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example" "$CRS_DIR/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf" 2>/dev/null || true
sudo cp "$CRS_DIR/rules/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf.example" "$CRS_DIR/rules/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf" 2>/dev/null || true

# Test Apache configuration
echo "Testing Apache configuration..."
if sudo apachectl configtest; then
    echo "Configuration test passed. Reloading Apache..."
    sudo systemctl reload apache2
    echo "CRS updated successfully to $LATEST_VERSION"
else
    echo "Configuration test failed! Restoring backup..."
    sudo rm -rf "$CRS_DIR"/*
    sudo cp -r "$BACKUP_DIR"/* "$CRS_DIR"/
    echo "Backup restored. Please check the error above."
    exit 1
fi

Make the script executable:

sudo chmod +x /usr/local/bin/update-owasp-crs.sh

Run the script to update CRS:

sudo /usr/local/bin/update-owasp-crs.sh

Expected output when an update is available:

Current CRS version: 4.22.0
Latest CRS version:  v4.23.0
Updating to v4.23.0...
Backing up current installation to /etc/apache2/modsec-backup-20260125
Configuration test passed. Reloading Apache...
CRS updated successfully to v4.23.0

If already up to date:

Current CRS version: 4.22.0
Latest CRS version:  v4.22.0
CRS is already up to date.

Run this script periodically (monthly is usually sufficient) to keep your rules current with the latest security updates.

Troubleshooting

Apache Fails to Start After Configuration Changes

If Apache fails to start, check the configuration syntax:

sudo apachectl configtest

Common errors include:

• Duplicate rule IDs: If you see “Found another rule with the same id”, remove conflicting CRS configurations (e.g., /etc/modsecurity/crs/crs-setup.conf on Ubuntu 26.04)
• Missing include files: Verify the paths in security2.conf point to existing files
• Syntax errors in exclusion rules: Each custom rule needs a unique id: value

ModSecurity Not Blocking Attacks

If ModSecurity doesn’t block test attacks:

1. Verify SecRuleEngine is set to On in /etc/modsecurity/modsecurity.conf
2. Check that CRS rules are being loaded: sudo apachectl -t -D DUMP_INCLUDES | grep -i modsec
3. Review the error log for issues: sudo tail /var/log/apache2/error.log
4. Ensure Apache was restarted after changes: sudo systemctl restart apache2

Legitimate Requests Being Blocked

To identify why a request was blocked:

sudo grep "$(date +%d/%b/%Y)" /var/log/apache2/modsec_audit.log | grep -A 10 "403"

Look for the [id "XXXXXX"] pattern to identify the blocking rule, then create an exclusion as described in the false positives section.

High Server Load After Enabling ModSecurity

ModSecurity adds processing overhead. If you notice performance issues:

• Reduce the paranoia level to 1 if it’s higher
• Disable response body scanning in modsecurity.conf: SecResponseBodyAccess Off
• Limit which file types are scanned by configuring SecRequestBodyLimit and SecResponseBodyLimit

CRS 4.x Rules Not Working on Ubuntu 22.04

If you installed CRS 4.x from GitHub on Ubuntu 22.04 with the default ModSecurity 2.9.5, you will see errors like:

Unknown operator: @within

This occurs because CRS 4.x uses the @within operator which requires ModSecurity 2.9.6 or newer. To resolve this:

1. Install ModSecurity from the Digitalwave repository (provides 2.9.13)
2. Or use the packaged CRS 3.x from Ubuntu repositories instead

Remove ModSecurity

If you need to remove ModSecurity from your system, follow these steps.

First, disable the ModSecurity module:

sudo a2dismod security2
sudo systemctl restart apache2

Remove the ModSecurity packages:

sudo apt remove --purge libapache2-mod-security2 modsecurity-crs

Remove configuration files and CRS rules:

The following commands permanently delete all ModSecurity configuration files and OWASP CRS rules. If you have custom rule exclusions you want to preserve, back them up first with sudo cp -r /etc/apache2/modsec ~/modsec-backup.

sudo rm -rf /etc/modsecurity
sudo rm -rf /etc/apache2/modsec
sudo rm -f /etc/logrotate.d/modsecurity
sudo rm -f /usr/local/bin/update-owasp-crs.sh

If you used the Digitalwave repository, remove those configuration files as well:

sudo rm -f /etc/apt/sources.list.d/digitalwave-modsecurity.*
sudo rm -f /etc/apt/preferences.d/99modsecurity
sudo rm -f /usr/share/keyrings/digitalwave-modsecurity.gpg

Clean up unused dependencies:

sudo apt autoremove

Verify ModSecurity is removed:

sudo apachectl -M | grep security

This command should return no output if ModSecurity was successfully removed.

Additional Security Recommendations

ModSecurity with CRS provides application-layer protection. For comprehensive server security, consider implementing additional measures:

• Firewall: Configure UFW to restrict network access. See our UFW firewall guide for Ubuntu.
• Intrusion prevention: Use Fail2Ban to block repeated attack attempts. See our Fail2Ban installation guide.
• SSL/TLS: Enable HTTPS with a valid certificate from Let’s Encrypt. See our Certbot guide for Ubuntu.
• Regular updates: Keep your system and CRS rules updated to protect against new vulnerabilities

Frequently Asked Questions

Conclusion

You now have ModSecurity with OWASP CRS protecting your Apache server on Ubuntu. The web application firewall monitors all HTTP traffic and blocks common attack patterns including SQL injection, XSS, and command injection attempts. If you installed CRS from GitHub, use the provided update script monthly to keep your rules current. Monitor your audit logs at /var/log/apache2/modsec_audit.log and tune the rule exclusions to match your application’s needs.