Monitoring ModSecurity WAF with Vigilmon

ModSecurity is the world's most widely deployed open-source Web Application Firewall (WAF), integrated natively with Apache, Nginx, and IIS. It inspects every HTTP request and response against the OWASP Core Rule Set (CRS) to block SQL injection, XSS, remote code execution, and hundreds of other attack classes. When ModSecurity fails to load — or its rules become stale — your web applications lose their primary WAF protection layer. Vigilmon monitors the web server, WAF-protected endpoints, and rule update pipeline so you know the instant protection degrades.

What You'll Set Up

• HTTP monitor for the Nginx/Apache server with ModSecurity active
• WAF-protected endpoint health check with body keyword verification
• Heartbeat monitor for OWASP CRS rule update jobs
• SSL certificate alerts for HTTPS endpoints behind ModSecurity

Prerequisites

• Nginx or Apache running with ModSecurity v2 or v3 loaded
• OWASP Core Rule Set (CRS) installed
• A WAF-protected HTTPS endpoint
• A free Vigilmon account

Step 1: Monitor the Web Server with ModSecurity Loaded

The first check verifies that your web server is running and serving requests. If ModSecurity fails to load (syntax error in modsecurity.conf, missing rule files, memory allocation failure), Nginx or Apache typically refuse to start — meaning the entire server goes down.

1. Log in to vigilmon.online and click Add Monitor.
2. Set Type to HTTP / HTTPS.
3. Enter your server URL: https://YOUR_DOMAIN (the primary domain your WAF protects).
4. Set Check interval to 2 minutes.
5. Set Expected HTTP status to 200.
6. Click Save.

A 5xx response or connection refused means the web server has crashed or ModSecurity prevented startup — investigate nginx -t or apachectl configtest for configuration errors.

Step 2: WAF-Protected Endpoint Health Check

A running web server doesn't guarantee ModSecurity is actively filtering. Verify a specific protected endpoint returns the expected response body — if ModSecurity blocks a health check URL due to a misconfigured rule, you'll catch the false-positive immediately:

1. Add Monitor → HTTP / HTTPS.
2. URL: https://YOUR_DOMAIN/health (or any endpoint that returns a predictable body when healthy).
3. Set Expected HTTP status to 200.
4. Under Advanced, set Expected body contains to a string from your application's healthy response (e.g. {"status":"ok"} or a specific page title).
5. Set Check interval to 2 minutes.
6. Click Save.

If ModSecurity triggers on your health check URL (e.g. a rule matching query parameters), the endpoint returns 403 Forbidden — Vigilmon alerts you to a misconfigured WAF rule blocking legitimate traffic. This check also catches the web server returning 500 due to an application error behind the WAF.

Step 3: Monitor ModSecurity Audit Log Freshness

ModSecurity writes audit logs (/var/log/modsec_audit.log) for every intercepted request. A stale audit log (no writes for hours on a production server) may indicate ModSecurity has silently disabled itself or gone into detection-only mode. Use a heartbeat from a log rotation script:

# /usr/local/bin/modsec-log-check.sh
#!/bin/bash
AUDIT_LOG="/var/log/modsec_audit.log"
# Check if log was modified in the last 30 minutes (for active servers)
if find "$AUDIT_LOG" -mmin -30 | grep -q .; then
  /usr/bin/curl -fsS "https://vigilmon.online/api/heartbeat/YOUR_LOG_HEARTBEAT_ID" > /dev/null 2>&1
fi

Add to cron:

# /etc/cron.d/modsec-log-check
*/30 * * * * root /usr/local/bin/modsec-log-check.sh

In Vigilmon:

1. Add Monitor → Heartbeat.
2. Name it ModSecurity audit log activity.
3. Set Expected interval to 30 minutes.
4. Set Grace period to 15 minutes.
5. Paste the heartbeat URL into the script.
6. Click Save.

Adjust the freshness threshold to match your typical traffic volume — a low-traffic server may legitimately have quiet periods, while a production server should always have recent audit entries.

Step 4: Heartbeat for OWASP CRS Rule Updates

The OWASP Core Rule Set is updated regularly to address new attack patterns. If your automated CRS update script fails, ModSecurity keeps running with outdated rules — silently missing new attack signatures. A heartbeat monitors the update pipeline:

# /usr/local/bin/crs-update-heartbeat.sh
#!/bin/bash
set -euo pipefail

CRS_DIR="/etc/nginx/modsecurity-crs"

# Download and update CRS
cd "$CRS_DIR"
git pull origin main

# Test that the web server config is still valid after update
nginx -t 2>/dev/null || apache2ctl configtest 2>/dev/null

# Reload web server to pick up new rules
systemctl reload nginx || systemctl reload apache2

# Signal success to Vigilmon
/usr/bin/curl -fsS "https://vigilmon.online/api/heartbeat/YOUR_CRS_UPDATE_HEARTBEAT_ID" > /dev/null 2>&1

Schedule weekly updates:

# /etc/cron.d/crs-update
0 3 * * 0 root /usr/local/bin/crs-update-heartbeat.sh >> /var/log/crs-update.log 2>&1

In Vigilmon:

1. Add Monitor → Heartbeat.
2. Name it OWASP CRS rule update.
3. Set Expected interval to 7 days.
4. Set Grace period to 12 hours.
5. Paste the heartbeat URL into the script.
6. Click Save.

If git pull fails, the config test errors, or the web server reload fails, the script exits early without sending the heartbeat. Vigilmon alerts you to investigate the rule update failure.

Step 5: SSL Certificate Alerts for WAF-Protected HTTPS Endpoints

ModSecurity protects HTTPS endpoints — if those certificates expire, the entire protection layer becomes inaccessible to clients (and the WAF becomes irrelevant). Monitor every HTTPS domain:

1. Open the HTTP/HTTPS monitor for your WAF-protected endpoint (created in Step 1 or 2).
2. Enable Monitor SSL certificate in the SSL section.
3. Set Alert when certificate expires in less than 14 days.
4. Click Save.

Repeat for each HTTPS domain behind ModSecurity. With a two-week warning, you have time to investigate Let's Encrypt renewal failures, fix ACME challenge configuration, or manually renew before certificates expire and client requests begin failing.

Summary

| Monitor | Target | What It Catches | |---|---|---| | Web server HTTP | https://YOUR_DOMAIN | Server crash, ModSec load failure | | Protected endpoint | https://YOUR_DOMAIN/health | WAF false-positive block, app error | | Audit log heartbeat | cron log check | ModSec disabled or silent | | CRS update heartbeat | weekly cron | Stale rule set | | SSL certificate | Each HTTPS domain | Certificate expiry |

ModSecurity's WAF protection is transparent when working correctly — and catastrophically invisible when it fails. A server that crashes because of a bad rule update takes down your applications; stale CRS rules silently miss new attack classes. Vigilmon's layered monitoring catches both scenarios before attackers do.