Skip to main content

Looks like mod_security is blocking a file but cannot find where or find it in logs

ttremain
We have a developer installing WP in one of the prescribed methods, uploading files and running to get setup prompts for the wp-config.php file. This redirects to wp-admin/setup-config.php which is blocked with a 403 error. If I rename the file it runs just fine. The page doesn't show up in the mod security hits list. There is a mod_security rule that MAY affect this but I've disabled it anyway. comodo_apache 210685 SecRule REQUEST_FILENAME "@endsWith /wp-admin/setup-config.php" \ "id:210685,chain,phase:2,pass,nolog,t:none,rev:3,severity:2,tag:'CWAF',tag:'Generic'" SecRule ARGS:step "@streq 2" \ "ctl:ruleRemoveTargetByTag=CWAF;ARGS:pwd,t:none"
The WP install is in a subdirectory of public_html, and I've even emptied the public_html/.htaccess entirely. I've been puzzled on this one way too long. Please advise...

Comments

14 comments

Date Votes
  • quietFinn
    The page doesn't show up in the mod security hits list.

    I'd suggest you look for your IP address in the hit list instead.
    0
  • ttremain
    I'd suggest you look for your IP address in the hit list instead.

    Still no such luck.
    0
  • quietFinn
    Then that 403 it's probably not caused by Modsecurity. If you search for your IP in Apache error log you should get more info. Btw Comodo's ModSec rules are not supported by the current ModSec version any more.
    0
  • ttremain
    Since then, I found this: --2a8a6226-B-- GET /gravity/wp-admin/setup-config.php HTTP/1.1 Host: XXXXXXXXXX.com User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:109.0) Gecko/20100101 Firefox/110.0 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,*/*;q=0.8 Accept-Language: en-US,en;q=0.5 Accept-Encoding: gzip, deflate, br DNT: 1 Connection: keep-alive Upgrade-Insecure-Requests: 1 Sec-Fetch-Dest: document Sec-Fetch-Mode: navigate Sec-Fetch-Site: none Sec-Fetch-User: ?1 --2a8a6226-F-- HTTP/1.1 403 Forbidden Content-Length: 318 Keep-Alive: timeout=10, max=198 Connection: Keep-Alive Content-Type: text/html; charset=iso-8859-1 --2a8a6226-H-- Apache-Error: [file "mod_authz_core.c"> [line 882] [level 3] AH01630: client denied by server configuration: /home/XXXXXXXX/public_html/gravity/wp-admin/setup-config.php Stopwatch: 1678566593582601 378 (- - -) Stopwatch2: 1678566593582601 378; combined=1, p1=0, p2=0, p3=0, p4=0, p5=1, sr=0, sw=0, l=0, gc=0 Producer: ModSecurity for Apache/2.9.6 (http://www.modsecurity.org/). Server: Apache Engine-Mode: "ENABLED" --2a8a6226-Z--
    0
  • ttremain
    So I'm still puzzled and cannot actually find where to shut this off.
    0
  • cPRex Jurassic Moderator
    If you are able to reproduce the 403 error at will, do you see that being logged to the main Apache error log? This is located at /etc/apache2/logs/error_log, and I would expect ModSecurity hits to be logged there. As a test, you could also disable ModSecurity completely and see if the issue still happens, which would eliminate that tool completely from your troubleshooting.
    0
  • ttremain
    If you are able to reproduce the 403 error at will, do you see that being logged to the main Apache error log? This is located at /etc/apache2/logs/error_log, and I would expect ModSecurity hits to be logged there. As a test, you could also disable ModSecurity completely and see if the issue still happens, which would eliminate that tool completely from your troubleshooting.

    Apache error log just gives me: [Mon Mar 13 11:54:13.059719 2023] [authz_core:error] [pid 732639:tid 47492335494912] [client 188.74.209.118:56494] AH01630: client denied by server configuration: /home/XXXXXXXX/public_html/gravity/wp-admin/setup-config.php Same result if I disable mod_security for the domain, within cPanel
    0
  • cPRex Jurassic Moderator
    That doesn't sound like a ModSecurity issue, then, if the same error happens even with ModSecurity disabled. Do you have any other rules in the .htaccess file for the domain? As a test, you could rename the .htaccess file to .htaccess.bak so it can't be read by the server and see if the error continues, although that might interfere with normal WordPress functions.
    0
  • ttremain
    Do you have any other rules in the .htaccess file for the domain? As a test, you could rename the .htaccess file to .htaccess.bak so it can't be read by the server and see if the error continues, although that might interfere with normal WordPress functions.

    .htaccess in the document root is back to default (was emptied, then written again as the PHP version had been changed) problem persisted. There is no .htaceess in this sub folder, but there is a WordPress install in other subfolders, but those shouldn't come into play.
    0
  • cPRex Jurassic Moderator
    I'm not totally sure what could be causing that behavior. Since you have root access to the server, feel free to open a ticket with our team so we can check this directly on the system.
    0
  • ttremain
    Result of the support ticket is that since WP Toolkit created at least one other install on the domain, in another folder, it was preventing the setup-config.php from running. Solution is to either create additional WP installs in the domain also using WP Toolkit, or deleting the toolkit config file.
    0
  • cPRex Jurassic Moderator
    Thanks for sharing the result!
    0
  • Rodrigo Gomes
    This caused me a huge headache to diagnose. Thank you for sharing the solution. cPanel should fix this urgently; it's a very annoying error that has been causing confusion among customers who don't use WP-Toolkit.
    0
  • cPRex Jurassic Moderator
    @ttremain - do you have that ticket number so I can look into this a bit more?
    0

Please sign in to leave a comment.

Didn't find what you were looking for?

New post