Mod Security blocking wordpress - php

I have a wordpress site with Modsecurity and apache. When I try to access wordpress it throws a 403 Forbidden error. Neither the admin panel nor the frontend is accessible. Here are the logs:
[Tue Mar 18 08:17:41 2014] [error] [client 122.170.1.216] ModSecurity: Access denied with code 403 (phase 4). Pattern match "^5\\\\d{2}$" at RESPONSE_STATUS. [file "/etc/httpd/modsecurity.d/activated_rules/modsecurity_crs_50_outbound.conf"] [line "53"] [id "970901"] [rev "2"] [msg "The application is not available"] [data "Matched Data: 500 found within RESPONSE_STATUS: 500"] [severity "ERROR"] [ver "OWASP_CRS/2.2.6"] [maturity "9"] [accuracy "9"] [tag "WASCTC/WASC-13"] [tag "OWASP_TOP_10/A6"] [tag "PCI/6.5.6"] [hostname "www.bullion.ambab.com"] [uri "/research/wp-admin/index.php"] [unique_id "UygBJQoLkgUAABXkL-8AAAAX"]
[Tue Mar 18 08:17:41 2014] [error] [client 122.170.1.216] ModSecurity: Warning. Operator GE matched 4 at TX:outbound_anomaly_score. [file "/etc/httpd/modsecurity.d/activated_rules/modsecurity_crs_60_correlation.conf"] [line "40"] [id "981205"] [msg "Outbound Anomaly Score Exceeded (score 4): The application is not available"] [hostname "www.bullion.ambab.com"] [uri "/research/wp-admin/index.php"] [unique_id "UygBJQoLkgUAABXkL-8AAAAX"]
This can be solved by disabling RuleByID 981205. But I do not want those rules to be bypassed because it might open a door for an attack.
Is there a way to solve this problem by modifying wordpress source?

Modifying the WordPress sources is highly not recommended, because after update the modified files will be overwritten again.
Better approach is to refine your mod_security rules by allowing some more requests to be sent to the WordPress system.
ModSecurity (also known as “modsec”) has proven itself useful in a variety of situations, and again this is true in assisting with WordPress brute force attempts resulting in a Denial of Service (DoS) attack. While a number of WordPress plugins exist to prevent such attacks, custom modsec rules can prevent such attacks for all WordPress installations on a server. Modsec immediately filters incoming HTTP requests, which assists against taxing server resources.
These rules will block access for the offending IP address for 5 minutes upon 10 failed login attempts over a 3 minute duration. These rules have been automatically updated in the custom rules for Liquid Web’s ServerSecure service. For customers without ServerSecure, these rules can be added to their custom modsec rules. To accomplish this, edit your custom modsec user rules and append the file with the rules provided below. For CPanel servers, this file is likely located at /usr/local/apache/conf/
Below are the examples:
SecAction phase:1,nolog,pass,initcol:ip=%{REMOTE_ADDR},initcol:user=%{REMOTE_ADDR},id:5000134
<Locationmatch "/wp-login.php">
# Setup brute force detection.
# React if block flag has been set.
SecRule user:bf_block "#gt 0" "deny,status:401,log,id:5000135,msg:'ip address blocked for 5 minutes, more than 10 login attempts in 3 minutes.'"
# Setup Tracking. On a successful login, a 302 redirect is performed, a 200 indicates login failed.
SecRule RESPONSE_STATUS "^302" "phase:5,t:none,nolog,pass,setvar:ip.bf_counter=0,id:5000136"
SecRule RESPONSE_STATUS "^200" "phase:5,chain,t:none,nolog,pass,setvar:ip.bf_counter=+1,deprecatevar:ip.bf_counter=1/180,id:5000137"
SecRule ip:bf_counter "#gt 10" "t:none,setvar:user.bf_block=1,expirevar:user.bf_block=300,setvar:ip.bf_counter=0"
</Locationmatch>

Related

Why I get Error log messages "REQUEST_FILENAME"?

Maybe someone had the same problem? I'm using Wordpress sites and getting this following error in my metrics. I've already deactivated Auto Updates on Softacolous so now I get less errors, but those ones still couldn't understand:
[Fri Apr 16 11:57:30.115119 2021] [:error] [pid 4189499:tid 47071174346496] [client 193.106.30.100:51380] [client 193.106.30.100] ModSecurity: Warning. Match of "pmFromFile path_excludes" against "REQUEST_FILENAME" required. [file "/etc/apache2/conf.d/modsec_vendor_configs/imunify360-full-apache/004_i360_4_custom.conf"] [line "905"] [id "77140992"] [msg "IM360 WAF: Suspicious access attempt (WP folders)!||SC:/home/optim085/rshestakov.com/wp-content/plugins/wp-file-manager||T:APACHE||REQUEST_URI:/wp-content/plugins/wp-file-manager/lib/files/hardfork.php||"] [severity "NOTICE"] [tag "service_i360custom"] [tag "noshow"] [hostname "rshestakov.com"] [uri "/wp-content/plugins/wp-file-manager/lib/files/hardfork.php"] [unique_id "YHlfii5NrBxmL1xubinBiwAAANE"]
Thanks in advice!
OWASP ModSecurity Core Rule Set project here.
This is an alert or a false positive alert from your commercial Imunify360 web application firewall. You should get in touch with the Imunify support to solve this for you. It's a paid service after all.
Like dune73 allready mentioned this is a message generated by immunify360. It might well be legitimate so first you need to check if it was you who triggered it or some unauthorized source.
Check if your ip-address is the same as the ip-address mentioned in the error message. If this is the case it might be a false positive.
Check whether there is a PHP warning in your error log saying something like:
PHP Warning: POST Content-Length of 9852139 bytes exceeds the limit
of 8388608 bytes
Over the last few weeks I've seen this happening to several people who were trying to install a wordpress theme. If this is the case with you as well you should probably check if upping the php limits helps to solve it. (to people who haven't done this before: you can do this by either creating a .user.ini file or by altering a .php.ini file - depending on the setup of your server)
If this still fails you could try looking for the incident in the Immunify360 interface. If it's in there you can whitelist it.
I hope this helps. If you have any more questions please let me know!

Why would an uploaded Xerox PDF cause a 418 error?

I am trying to upload a pdf generated by the scanner on a Xerox AltaLink 8055. The upload works as expected with every PDF I have found with the exception of the ones generated by the Xerox. I am getting a 418 error and find this in the logs:
[Tue Mar 12 13:04:24 2019] [error] [client IP_ADDRESS] ModSecurity: Access denied with code 418 (phase 2). Matched phrase "GLOBALS" at ARGS:artworkfile64. [file "/dh/apache2/template/etc/mod_sec2/99_dreamhost_rules.conf"] [line "256"] [id "1990070"] [msg "Common known arguments for backdoor shell present in ARGS:artworkfile64"] [hostname "DOMAIN_NAME"] [uri "/srom/orders-details-submit.php"] [unique_id "XIgQx0Wj##AAAFN90ZAAAAAB"]
I am using a Dreamhost VPS. If I open the file and re-save it with Preview or Acrobat then the upload works as expected.
Does anyone know what would cause this?
This is caused by a mod_security rule on your VPS, specifically line 256 /dh/apache2/template/etc/mod_sec2/99_dreamhost_rules.conf. (This information is in the log line you pasted.)
You can try to disable this specific rule by commenting it out in the configuration file, or disable mod_security entirely for your site.

Access denied with code 403 (Parallel Plesk)

I've made a website working fine on localhost with wamp. I've put it online on my client's hosting solution.
It's in Php with a very simple MySql database.
The problem comes when I try to update or create some "events" from the admin interface I've created (a simple SQL update or create command) : "Forbidden You do not have permission to access this document.
Web Server at guymarin.com"
And the whole server seems to be stuck for about 20 minutes each time!
The error log says :
[Wed Jul 02 06:24:38 2014] [error] [client 70.81.162.225]
ModSecurity: [file "/etc/httpd/modsecurity.d/10_asl_rules.conf"] [line "1018"] [id `"350147"] [rev "147"] [msg "Atomicorp.com WAF Rules: Potentially Untrusted Web Content
Detected"] [data "336"] [severity "CRITICAL"] Access denied with code 403 (phase 2).`
`Match of "rx ((?:submit(?:\\\\+| )?(request)?(?:\\\\+| )?>+|<<(?:\\\\+| )remove|(?:sign ?in|log ?(?:in|out)|next|modifier|envoyer|add|continue|wei ter|account|results|select)(?:\\\\+| )?>+)$|^< ?\\\\??(?: |\\\\+)?xml|^<samlp|^>> ?$)" against "REQUEST_URI" required. [hostname "www.guymarin.com"] [uri "/admin/create_even.php"] [unique_id` "U7Pr9risJLQAAGsYcfUAAAAO"]
What do you think I should do in this case?
Thank you for your help!
Looks like you have activated WAF (mod_security) from Plesk security core. You can disable it or switch to non-blocking mode.

ModSecurity: Access denied with code 406 in apache

The below error was generating when add Post on webpage the code developed by PHP.
[error] [client 1192.168.0.1] ModSecurity: Access denied With code 406(phase 2). Pattern match "(?:\\b(?:\\.(?:ht(?:access|passwd|group)|www_?acl)|global\\\.asa|httpd\\\.conf|boot\\\\.ini)\\\\b|\\\\/etc\\\\/|\\\\/root\\\\/|\\\\/public_html\\\\/)" at ARGS:content. [file "/usr/local/apache/conf/2.user.conf"] [line "134"] [id "1234123401"] [msg "Remote File Access Attempt"] [data "/etc/"] [severity "CRITICAL"] [tag "WEB_ATTACK/FILE_INJECTION"] [hostname "mydomain.com"] [uri "/admin/preview.php"] [unique_id "U36x7XyZeYcAAFVUXLsAAADC"]
I found the code from below file :
vim /usr/local/apache/conf/modsec2.user.conf
"phase:2,capture,t:none,t:htmlEntityDecode,t:lowercase,ctl:auditLogParts=+E,deny,log,auditlog,msg:'Remote File Access Attempt',id:'1234123401',tag:'WEB_ATTACK/FILE_INJECTION',logdata:'%{TX.0}',severity:'2'"
Is it secure may mod_security will be disabled?
As I see it the problem is that in one of the request parameters of the request to "/admin/preview.php" the string "/etc/" was used, which looks like an attack and therefore the rule with the id 1234123401 blocked the request.
If this was an attack than ModSecurity worked nicely.
If this was a legitimate request which needs to go through ModSecurity one could
1) Change the request so that it does not contain the string "/etc/" as a parameter value - maybe the PHP script has to be adapted for this
2) Modify the rule's regular expression and remove the /etc/ part
3) Change the rule action from deny to pass
I would not go with options 2 & 3 as you would lower the security level. Instead I would try to go with option one.
Best,
Ronald

ModSecurity maximum post limits (PCRE limit errors)

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 receiving 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.
I've just resolved a similar issue, with a large post triggering PCRE limit errors in multiple rules. I feel it's wrong for mod-security to then flag the request as malicious just because it blew up!
I raised the two settings you mentioned from the default to 500,000 from the default of 1,500 as advised in this post, and it solved my problem.
The default values for the PCRE Match limit are very, very low with
ModSecurity. You can got to 500K usually without harming your set. But
for your information: The PCRE Match limit is meant to reduce the
chance for a DoS attack via Regular Expressions. So by raising the
limit you raise your vulnerability in this regard, but the PCRE errors
are much worse from a security perspective. I run with 500K in prod
usually:
SecPcreMatchLimit 500000 SecPcreMatchLimitRecursion 500000
https://github.com/SpiderLabs/owasp-modsecurity-crs/issues/656
Also see
https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#SecPcreMatchLimit
I had a similar issue with PCRE module a few weeks ago and it was related to backtrack_limits.
I assume SecPcreMatchLimit and SecPcreMatchLimitRecursion are related to mod_security, but did you try upping the values for pcre module in your php.ini file or during PHP execution time?
pcre.backtrack_limit and pcre.recursion_limit
You could also confirm if the issue is related to PCRE limits with the following function preg_last_error()
You can see more here: http://php.net/manual/en/function.preg-last-error.php
and here: http://www.php.net/manual/en/pcre.constants.php
I hope this helps.

Categories