Member Avatar for bops

Hey,

I've been having tonnes of issues with Mod Security. I am busy writing a CMS for a project at work and while developing a page to edit a certain database record I kept getting 403 errors. After hours of banging my head against my desk, adjusting bits of code I finally just changed the script to which my form was being posted, to contain a simple echo "test";. Even submitting to this simple page was kicking up a 403 error. I messed about with my form and I eventually found that if I reduced the amount of data I was posting the form submitted fine (In particular I reduce the amount of text within a textarea).

After checking the logs (Yep, this wasn't the first thing I did - sigh) I noticed that I was getting numerous errors from ModSecurity, such as:

[Mon Aug 12 16:34:45 2013] [error] [client XX.XXX.XXX.XXX] ModSecurity: Failed to access DBM file "/etc/httpd/logs//global": Permission denied [hostname "XXXXXXX.XXX"] [uri "/admin/index.php"] [unique_id "UgkAlW1shFcAAHTMK80AAAAF"]
[Mon Aug 12 16:34:45 2013] [error] [client XX.XXX.XXX.XXX] ModSecurity: Failed to access DBM file "/etc/httpd/logs//ip": Permission denied [hostname "XXXXXXX.XXX"] [uri "/admin/index.php"] [unique_id "UgkAlW1shFcAAHTMK80AAAAF"]
[Mon Aug 12 17:11:33 2013] [error] [client XX.XXX.XXX.XXX] ModSecurity: Rule execution error - PCRE limits exceeded (-8): (null). [hostname "XXXXXXX.XXX"] [uri "/admin/index.php"] [unique_id "UgkJNW1shFcAAHXUMHkAAAAH"]
[Mon Aug 12 17:11:33 2013] [error] [client XX.XXX.XXX.XXX] ModSecurity: Access denied with code 403 (phase 2). Match of "streq 0" against "TX:MSC_PCRE_LIMITS_EXCEEDED" required. [file "/etc/httpd/conf.d/mod_security.conf"] [line "93"] [msg "ModSecurity internal error flagged: TX:MSC_PCRE_LIMITS_EXCEEDED"] [hostname "XXXXXXX.XXX"] [uri "/admin/index.php"] [unique_id "UgkJNW1shFcAAHXUMHkAAAAH"]

I've been messing around, Googling and changing rules for days to no avail. The only thing I seem to be able to do is turn ModSecurity off for this vhost. This is fine by me while I'm developing the CMS, but in production this isn't really something I want to do. Does anyone have any ideas on what is causing this issue and how to sort it? The logs seem to point at some kind rules to do with regular expression limits, but since changing my post recieving script to just print out the word test I'm not doing anything with them (Though I have tried upping the limits through SecPcreMatchLimit and SecPcreMatchLimitRecursion). It seems rather that there's something wrong with the amount of data I am sending through.

Any insight appreciated.

Thanks

Edited by pritaeas because: Moved to Linux. Next time just use Flag Bad Post to get it moved.
  • 1 Contributor
  • 2 Replies
  • 263 Views
  • 1 Day Discussion Span
  • Latest Post Latest Post by bops

Dani AI

Generated

Short, practical checklist for based on the symptoms you posted (403 on large POSTs, ModSecurity errors about the PCRE limits and DBM access). Two independent problems commonly explain that behavior: (a) ModSecurity hitting PCRE work/recursion limits when evaluating large or complex POST bodies, and (b) ModSecurity failing to write its persistent DBM collections (ip/global) because of ownership/permission or MPM/user-switching issues. Treat each separately. (support.atomicorp.com)

Reproduce + debug (safe first steps). Reproduce the failing POST with curl so you can iterate. Turn on a temporary debug log (don’t leave it on in production) and scope it to your IP or URI if possible so you don’t flood the disk:

SecDebugLog /var/log/modsec_debug.log
SecDebugLogLevel 9
# OR (per-transaction) add a rule that raises debug only for your IP:
# SecRule REMOTE_ADDR "^1\.2\.3\.4$" "phase:1,pass,nolog,ctl:debugLogLevel=9"

Then watch modsec debug + Apache error log for the rule ID and the variable (ARGS) that triggered the PCRE failure. (github.com)

Fix the PCRE-limit problem carefully. SecPcreMatchLimit (and legacy SecPcreMatchLimitRecursion) are global-only directives — set them in the main modsecurity.conf and restart Apache. Start with a conservative increase (examples used in practice: 250000) but be aware raising them weakens protection against regex-based DoS — better first to tune rules. Example:

SecPcreMatchLimit 250000
SecPcreMatchLimitRecursion 250000

If a single CRS rule or a specific ARGS field causes the blowup, exclude that field from the rule instead of globally inflating limits. (github.com)

Fix the DBM/permission errors. Locate SecDataDir (or your distro’s modsec data directory), check the .pag/.dir files, and ensure they’re owned and writable by the Apache worker user (or the user used by mod_ruid2/suPHP). On cPanel/EasyApache systems the usual workaround is to chown to the webserver user or to disable the DBM-dependent rules (IP reputation/DOS) if you cannot safely change ownership. For production, prefer targeted rule exclusions (SecRuleRemoveById or ctl:ruleRemoveTargetById) and DetectionOnly mode while tuning. (support.cpanel.net)

Summary: (1) reproduce + debug to find the rule/ARGS, (2) either tune that rule (exclude the big textarea) or raise global PCRE limits, and (3) correct SecDataDir/DBM permissions (or disable DBM-dependent rules) so ModSecurity stops failing internally.

Member Avatar for bops

Nothing at all? :/

Member Avatar for bops

Reposting this in the Apache forum. Delete at will! Thanks.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.