Top 5 ModSecurity Exceptions and Security Auditing Plugins for Apache to Minimize Server Costs and Load Overhead

Custom Rule for User Content Fields

Add to your `01-api-exceptions.conf` or a new file like `02-user-content.conf`:

# Exception for 'comment' field in review submissions
SecRule ARGS:comment "@contains <script>" \
    "id:1000003,phase:2,nolog,pass,ctl:ruleRemoveById=941100"

# If you have a specific form submission URI, you can narrow it down:
# SecRule REQUEST_URI "/submit-review.php" \
#    "id:1000004,phase:2,nolog,pass,ctl:ruleRemoveTargetById=941100;ARGS:comment"

# For dynamically named fields, you might need to target patterns
# Example: If custom fields are prefixed with 'custom_attr_'
# SecRule ARGS:/^custom_attr_/ "@contains <script>" \
#    "id:1000005,phase:2,nolog,pass,ctl:ruleRemoveById=941100"

Explanation:

• ARGS:comment: This targets the argument named `comment` in the request body (phase 2).
• "@contains <script>": This is a simplified check. In a real-world scenario, you might use more sophisticated regex or rely on ModSecurity’s built-in anomaly scoring to adjust if the content is truly malicious. However, for a direct bypass, targeting a known pattern that triggers the rule is effective.
• ctl:ruleRemoveById=941100: Removes the XSS rule for this specific argument.
• phase:2: The request body phase is crucial for inspecting POST data.

The commented-out examples show how to scope this to specific URIs or patterns of arguments, which is generally a more secure approach than a blanket exception.

3. Whitelisting Known Good User Agents

Certain legitimate bots (e.g., Googlebot, Bingbot, specific monitoring tools) or internal applications might have unusual User-Agent strings that trigger ModSecurity rules related to anomaly scoring or bot detection. While you want to block malicious bots, blocking legitimate ones can harm SEO and monitoring capabilities.

Scenario: Your internal monitoring service uses a custom User-Agent string like `MyInternalMonitor/1.0`. This string, lacking common browser identifiers, is causing rule `900000` (Anomaly Score Exceeded) to trigger, leading to monitoring failures.

Custom Rule for User Agent Whitelisting

# Whitelist specific User-Agents
SecRuleEngine On

SecAction \
    "id:1000006,phase:1,nolog,pass,t:none,setenv:MY_USER_AGENT_IS_TRUSTED=1" \
    "chain"
    SecRule HTTP_USER_AGENT "@pm (MyInternalMonitor/1.0|Googlebot|Bingbot)" "t:none"

# Now, use this variable to bypass certain rules
# Example: Bypass anomaly scoring for trusted user agents
SecRuleEngine On
SecAction \
    "id:1000007,phase:2,nolog,pass,t:none,ctl:ruleRemoveById=900000" \
    "chain"
    SecRule ENV:MY_USER_AGENT_IS_TRUSTED "@eq 1"

Explanation:

• The first `SecAction` and `SecRule` pair sets an environment variable `MY_USER_AGENT_IS_TRUSTED` to `1` if the `HTTP_USER_AGENT` matches any of the specified strings.
• The second `SecAction` and `SecRule` pair uses this environment variable. If `MY_USER_AGENT_IS_TRUSTED` is `1`, it removes rule `900000` (or any other rule you specify).
• @pm (pattern match) is efficient for checking against multiple strings.
• This approach is more robust than directly removing rules based on User-Agent, as it allows you to conditionally disable *multiple* rules for trusted agents.

4. Optimizing for Specific E-commerce Workflows (e.g., Checkout)

The checkout process is a critical path for any e-commerce site. It involves multiple steps, form submissions, and potentially complex data transfers. Certain fields or sequences of actions during checkout might be flagged by generic rules. For instance, passing sensitive but expected data in URLs (e.g., order IDs in redirects) or specific payment token formats could trigger alarms.

Scenario: After a successful payment, the user is redirected to an order confirmation page with an order ID in the URL: `/order/confirm?id=123456789`. Rule `950100` (Potential Command Injection) might flag the numeric ID, assuming it’s part of a command. However, this is a standard redirect.

Custom Rule for Checkout Workflow

# Exception for order confirmation URL parameter
SecRuleEngine On

SecRule REQUEST_URI "@beginsWith /order/confirm" \
    "id:1000008,phase:1,nolog,pass,ctl:ruleRemoveTargetById=950100;ARGS:id"

Explanation:

• This rule targets the specific URI `/order/confirm`.
• ctl:ruleRemoveTargetById=950100;ARGS:id: This is more precise than `ruleRemoveById`. It tells ModSecurity to disable rule `950100` *only* for the `id` argument within requests matching the specified URI. This prevents accidentally disabling the rule for other parts of your application where it might be necessary.

5. Security Auditing and Performance Monitoring with ModSecurity Audit Logs

While exceptions are necessary, they must be implemented judiciously. Comprehensive auditing of ModSecurity’s actions is paramount to ensure you’re not creating security holes and to identify further optimization opportunities. The ModSecurity audit log is your primary tool here.

Configuration:

Audit Log Setup

Ensure your `modsecurity.conf` (or equivalent) has appropriate audit logging directives. For detailed analysis, you’ll want to log transactions that are blocked or flagged, and potentially even all transactions for a short period during tuning.

# Log all transactions, but only store details for anomalous ones
SecAuditEngine RelevantOnly
SecAuditLogRelevantStatus "^5..$" # Log 5xx errors (e.g., 500 Internal Server Error due to ModSecurity block)
SecAuditLogRelevantStatus "^4..(?!404$)" # Log 4xx errors, excluding 404 Not Found

# Or, for intensive tuning, log everything:
# SecAuditEngine PerRequest
# SecAuditLogRelevantStatus "^.*$"

# Specify the audit log file
SecAuditLog /var/log/apache2/modsec_audit.log

# Log only the response body for non-404s
SecAuditLogParts ABIFCZH
# A: Request Headers
# B: Response Headers
# I: Request Body (if not too large, or if relevant)
# F: The unique ID of the transaction
# C: The anomaly scoring
# H: The HTTP response body
# Z: The unique ID of the transaction (again, for correlation)

# Set anomaly scoring thresholds (adjust these based on your tuning)
SecAction "phase:5,id:1000009,nolog,pass,t:none,setenv:ANOMALY_SCORE=0"
SecAction "phase:5,id:1000010,nolog,pass,t:none,setenv:ANOMALY_SCORE_THRESHOLD=100"
SecAction "phase:5,id:1000011,nolog,pass,t:none,setenv:ANOMALY_SCORE_ACTION=block"

Analysis Workflow:

• Regular Review: Periodically (daily/weekly) review `/var/log/apache2/modsec_audit.log`. Look for patterns in `SecAuditLogRelevantStatus` entries.
• Identify False Positives: If you see legitimate user requests being logged with high anomaly scores or specific rule IDs triggering (e.g., `[id “941100”]`), this indicates a potential false positive.
• Correlate with Web Server Logs: Use the transaction ID (`[unique_id “xxxxxx”]`) from the audit log to find the corresponding entry in your Apache access logs (`/var/log/apache2/access.log`). This helps confirm if the request was blocked and what the final HTTP status code was.
• Tune Rules: Based on the identified false positives, create specific exceptions using the methods described above. Start with the most specific exceptions (e.g., targeting a specific argument on a specific URI) and broaden only if necessary.
• Monitor Performance: Use tools like `top`, `htop`, or `apachetop` to monitor Apache’s CPU and memory usage. Significant spikes correlating with traffic increases, especially after rule changes, warrant further investigation. ModSecurity’s overhead is directly proportional to the number and complexity of rules being evaluated.

Using `modsec-crs-setup.conf` for Global Settings

The `modsec-crs-setup.conf` file (or similar, depending on your CRS version) is crucial for global tuning. While not for specific exceptions, it controls the overall sensitivity of the CRS. Key variables include:

# Example from modsec-crs-setup.conf
# Set to '1' to enable anomaly scoring.
SecAction "phase:1,id:900001,nolog,pass,t:none,setenv:ANOMALY_SCORING=1"

# Define the anomaly score threshold.
SecAction "phase:1,id:900002,nolog,pass,t:none,setenv:ANOMALY_SCORE_THRESHOLD=100"

# Define the action for anomalous requests.
SecAction "phase:1,id:900003,nolog,pass,t:none,setenv:ANOMALY_SCORE_ACTION=block"

# Allow specific characters in URLs. Useful for internationalized domain names or specific parameters.
SecRuleUpdateTargetById 900100 "ARGS:url_param" # Example: Allow specific URL parameters
SecRuleUpdateTargetById 900100 "ARGS:non_standard_char_param"

# Disable specific rules globally if they are known to cause issues across the board.
# Use with extreme caution.
# SecRuleUpdateById 942100 "phase:2,t:none,block,log,msg:'Disabled SQLi rule globally'"

Adjusting `ANOMALY_SCORE_THRESHOLD` is a common way to reduce false positives. Increasing it (e.g., to 150 or 200) means more individual rule triggers are needed before an action is taken. However, this also means a more sophisticated attack might bypass detection. Always balance security with usability.

Conclusion: Iterative Tuning for E-commerce Resilience

Implementing ModSecurity exceptions is not a one-time task but an ongoing process. For e-commerce platforms, the cost of false positives (lost sales, frustrated customers) and performance degradation (higher server load, increased hosting bills) is significant. By strategically whitelisting known-good traffic patterns, API endpoints, and user-generated content, and by diligently auditing ModSecurity’s behavior through its logs, you can create a robust WAF that protects your site without hindering its growth or efficiency. Always prioritize granular exceptions over broad rule disabling, and continuously monitor your system’s performance and security posture.