ModSecurity Rule Audit Guide

TL;DR

This guide shows you how to check your ModSecurity rules for problems like false positives and performance issues. We’ll cover checking syntax, testing with sample attacks, and using logs to find areas that need improvement.

1. Check Rule Syntax

Before anything else, make sure your rules are correctly written. Badly formed rules won’t work and can crash your web server.

1. Use the ModSecurity Configuration Tester: Most installations have a tool to check rule syntax. The location varies depending on how you installed it. Often it’s run from the command line.

   modsecurity -t /path/to/your/rules.conf

2. Look for Errors: Pay close attention to any error messages. These will tell you exactly where the problem is in your rule file(s). Common errors include missing operators, incorrect variable names, and unbalanced quotes.

2. Test with Known Attacks

Testing rules against known attack patterns helps identify false positives (blocking legitimate traffic) and ensure they actually block malicious requests.

1. OWASP ModSecurity Core Rule Set (CRS) Test Suite: This is a great starting point. It provides a set of attacks to test common vulnerabilities.
   • Download the suite from the CRS GitHub repository.
   • Follow the instructions in the documentation to run the tests against your ModSecurity installation.
2. Custom Attack Payloads: Create your own test payloads based on attacks relevant to your application.
   • For example, if you have a search form, try injecting SQL injection attempts into the query parameter.
   • Use tools like Burp Suite or Postman to send these requests.

3. Analyse ModSecurity Logs

Logs are your primary source of information for identifying issues in production.

1. Locate Your Logs: The location depends on your web server configuration (Apache, Nginx, etc.). Common locations include:
   • Apache: /var/log/apache2/error.log or a dedicated ModSecurity log file.
   • Nginx: Check your Nginx configuration for the access_log and error_log directives.
2. Look for Blocking Events: Search for entries that indicate rules were triggered.

   grep "ModSecurity" /var/log/apache2/error.log

3. Identify False Positives: If legitimate requests are being blocked, investigate the rule that caused the block.
   • Examine the request details in the log to understand why it was triggered.
   • Adjust the rule or create an exception for the specific case (see step 4).
4. Check Performance: Look for slow response times associated with ModSecurity rules.
   • Complex regular expressions can be resource-intensive.
   • Optimize rules to reduce their processing time.

4. Fine-Tune Rules

Adjusting existing rules or creating exceptions is often necessary.

1. Rule Adjustments: Modify the rule logic to be more specific and avoid blocking legitimate traffic.
   • Use more precise regular expressions.
   • Add conditions to only trigger the rule under certain circumstances.
2. Exceptions (Allow Rules): Create rules that explicitly allow specific requests that are being falsely blocked.

   SecRule REQUEST_URI "@streq /legitimate-url" id:12345 allow

3. Order of Rules: The order in which rules are processed matters. Ensure more specific rules are placed before general ones.
   • ModSecurity processes rules sequentially, so the first matching rule wins.

5. Regular Updates

Keep your ModSecurity core rule set and other rules up to date.

1. CRS Updates: The OWASP CRS is regularly updated with new attack signatures.
   • Use a tool like git to manage updates:

     git pull

2. Vendor Patches: Check for security patches from your ModSecurity vendor.