Comprehensive Guide to ModSecurity: Logs, Configuration, and Important Limits

ModSecurity is the web application firewall (WAF) that sits inside the web server and checks every request before your website sees it. It stops a lot of automated attacks, and now and then it also blocks something legitimate. This guide explains how it works, what it does on Domain India shared hosting, how to report a false positive, and how to configure its logs and limits on your own VPS.

1. What ModSecurity does

ModSecurity is an open-source WAF engine. It runs as a module in Apache (version 2, mod_security2) or as a library with a connector for nginx (version 3, libmodsecurity). Since 2024 the project has been maintained under OWASP.

On its own the engine does nothing. It needs a ruleset: a list of patterns that describe attacks such as SQL injection, cross-site scripting, remote file inclusion and path traversal. The best-known free ruleset is the OWASP Core Rule Set (CRS). Commercial rulesets, such as the one that ships with Imunify360, are also common on hosting servers.

ModSecurity checks a request in five phases:

When a rule matches, ModSecurity can log the request, block it (usually with a 403), or add to an anomaly score that blocks the request only when the total passes a threshold. The CRS works this way.

2. ModSecurity on Domain India shared hosting

We checked our shared servers directly (measured on our servers, 20 and 23 September 2026):

• The cPanel servers run Apache with the security2_module (ModSecurity 2) loaded.
• The ruleset is Imunify360's full Apache ruleset, set to FULL, with application-specific rules for common CMSs switched on.
• It is configured server-wide. Every account on a server gets the same protection, whatever plan it is on.
• The ModSecurity switch is disabled in the cPanel interface for customer accounts, so you cannot turn it off per domain or edit rules yourself.

This is deliberate: on a shared server, one site with its firewall off is an easy way in for attackers.

3. How to recognise a ModSecurity block

A WAF block has a typical pattern: the site works, but one action fails.

• You save a long post or a page-builder layout and get 403 Forbidden.
• A contact form or checkout fails only when the message contains code, SQL-like words or unusual characters.
• An upload or an import fails with a 403 while normal pages load fine.
• An admin plugin or an API call to your own site is refused.

If the whole site is down, or it times out rather than showing a 403, it is not a WAF rule. Look at Understanding and resolving HTTP error 403 Forbidden, which covers permissions, .htaccess rules and IP blocks by the server firewall.

4. Report a false positive on shared hosting

A false positive is a legitimate request that a rule mistook for an attack. We can find the exact rule in the server logs, but only if you tell us which request to look for.

Don't disable security plugins or loosen file permissions to get round a block. It rarely helps and weakens the site.

5. Where ModSecurity logs live (VPS and your own servers)

On a server you manage, ModSecurity writes to two places.

Paths differ by distribution and control panel, so check the SecAuditLog line in your configuration.

To find recent blocks and the rules behind them:

# Recent ModSecurity matches in the Apache error log (Debian/Ubuntu)
sudo grep -i "ModSecurity" /var/log/apache2/error.log | tail -n 20

# Only the rule IDs, most frequent first
sudo grep -o 'id "[0-9]*"' /var/log/apache2/error.log | sort | uniq -c | sort -rn | head

# Everything logged for one request, using its unique_id
sudo grep -A 40 "UNIQUE_ID_HERE" /var/log/apache2/modsec_audit.log

Each audit entry is split into lettered parts: A (time, IPs, unique ID), B (request headers), C (request body), F (response headers), H (the rules that matched and the action taken) and Z (end of entry). SecAuditLogParts controls which parts are written. The H part tells you which rule fired.

Rotate the audit log with logrotate: it grows quickly, and request bodies can contain personal data.

6. Key directives and their default limits

These come from the modsecurity.conf-recommended file that ships with ModSecurity 2. Your distribution may set different values, so read the actual file before changing anything.

Note that a new ModSecurity install on Debian or Ubuntu starts in DetectionOnly. It logs but blocks nothing until you set SecRuleEngine On.

A common real problem is a large upload or a big JSON form being refused. Raise the matching limit, then reload the web server:

# Allow uploads up to 64 MB and form data up to 1 MB
SecRequestBodyLimit 67108864
SecRequestBodyNoFilesLimit 1048576

sudo apachectl configtest && sudo systemctl reload apache2   # Debian/Ubuntu
sudo apachectl configtest && sudo systemctl reload httpd     # AlmaLinux/RHEL

PHP has its own limits (upload_max_filesize, post_max_size) and so does nginx (client_max_body_size). All of them must allow the size you need.

7. Tuning false positives on your own server

Never switch the whole engine off to fix one false positive. Remove the smallest thing that solves the problem, and put your exclusions in a file that loads after the ruleset.

# 1. Turn off one rule for one URL only
<LocationMatch "^/wp-admin/post\.php">
    SecRuleRemoveById 941100
</LocationMatch>

# 2. Keep the rule, but stop it checking one field
SecRuleUpdateTargetById 942100 "!ARGS:content"

# 3. Remove a rule everywhere (last resort)
SecRuleRemoveById 941100

With the OWASP CRS, also consider the paranoia level (1 is the default and gives the fewest false positives) and the anomaly threshold. Test changes with the engine in DetectionOnly for a few days, read the logs, then switch to On.

8. Installing ModSecurity on a VPS

On current Linux distributions, ModSecurity 2 for Apache and the OWASP CRS come from the normal package repositories.

# Debian / Ubuntu
sudo apt install libapache2-mod-security2 modsecurity-crs
sudo cp /etc/modsecurity/modsecurity.conf-recommended /etc/modsecurity/modsecurity.conf
sudo a2enmod security2 && sudo systemctl restart apache2

# AlmaLinux / Rocky / RHEL
sudo dnf install mod_security mod_security_crs
sudo systemctl restart httpd

nginx needs ModSecurity 3 plus a connector module built for your exact nginx version, which is more work to maintain. If your VPS runs a control panel, use the panel's own WAF settings instead. Check the module is loaded with sudo apachectl -M | grep -i security.

9. Where Domain India fits

• Shared hosting (cPanel, DirectAdmin or Webuzo) is for people who want the WAF managed for them. The ruleset, updates and exceptions are our job; you report false positives by ticket. Domain India list prices on 19 September 2026, excluding 18% GST: DirectAdmin Starter ₹100 a month and cPanel Starter ₹125 a month.
• A VPS (VPS servers, from ₹552 a month) gives you root access, so you install, tune and log ModSecurity yourself using sections 5 to 8. Security on a VPS is your responsibility; see the VPS security checklist.

For the wider picture of what a WAF can and cannot stop, read Understanding and implementing a web application firewall.

Ready to get started? Compare cPanel hosting with a managed firewall, choose a VPS if you want to run ModSecurity yourself, or open a ticket if a rule is blocking your site.