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...

 

[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.

 

[ttremain]

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

Still no such luck.

 

[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.

 

[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--

 

[ttremain]

So I'm still puzzled and cannot actually find where to shut this off.

 

[cPRex]

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.

 

[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

 

[cPRex]

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.

 

[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.

 

[cPRex]

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.

 

[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.

 

[cPRex]

Thanks for sharing the result!

 

[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.

 

[cPRex]

@ttremain - do you have that ticket number so I can look into this a bit more?