Install ModSecurity with Apache on Debian 11 Bullseye

Got an Apache server on Debian 11 and you’re worried about the usual injection attacks? This quick run‑through will get ModSecurity up and running in a few minutes and show you how to test that it’s actually blocking stuff.

Update & Install Packages

sudo apt update
sudo apt install libapache2-mod-security2 apache2

If you skip the `apt update`, you’ll end up pulling an older package that might not line up with the rule set later. The `libapache2-mod-security2` package pulls in the core ModSecurity engine and a default Apache configuration file.

Grab the Core Rule Set

sudo mkdir -p /etc/modsecurity-crs
sudo cp /usr/share/modsecurity-crs/crs-setup.conf.example \
      /etc/modsecurity-crs/crs-setup.conf
sudo cp /usr/share/modsecurity-crs/*.conf /etc/modsecurity-crs/

The Core Rule Set (CRS) is what actually tells ModSecurity “don’t let this happen.” The sample config (`crs‑setup.conf.example`) needs to be renamed so the system will load it. Copying all `*.conf` files gives you a full rule base; without them, you’re running ModSecurity in a bare‑bones mode that won’t do much.

Enable the Module in Apache

sudo a2enmod security2

Then edit `/etc/apache2/mods-available/security2.conf` and change

SecRuleEngine DetectionOnly

to

SecRuleEngine On

`DetectionOnly` is the safe default that just logs hits. Switching to `On` turns on blocking. The `a2enmod` command makes sure Apache knows about the module; if you skip it, Apache will start but ModSecurity won’t load at all.

Tell Apache Where the Rules Live

Add this line at the bottom of `/etc/apache2/mods-available/security2.conf`:

IncludeOptional /etc/modsecurity-crs/*.conf

Without that include, Apache never reads any of the rule files you just copied. It’s like having a fire alarm system but not wiring any sensors.

Reload and Test

sudo systemctl restart apache2
# Check the audit log for activity
sudo tail -f /var/log/apache2/modsec_audit.log

Try sending a test payload:

curl -d "username=admin' OR '1'='1" http://localhost/login.php

You should see a `200` block in the audit log, and the request will be denied. If you don’t see any activity, double‑check that `SecRuleEngine On` is actually active (sometimes other config files override it).

There you go—your Apache should now be actively fighting off the usual web attacks on Debian 11 Bullseye. Keep the logs under eye and tweak the rules as your applications evolve.