Wordpress 403 permission denied

Where did you place ? as the position and order matters

Code (Text):

location ~ ^/wp-content/themes/plugin-hunt-theme-2/ {
include /usr/local/nginx/conf/php.conf;
allow all;
}

Details are at Wordpress - Wordpress 403 Permission Denied Errors it's my way of attempting to make end users like yourself be more aware of exactly what is running on your server so to speak. Afterall, Wordpress is most commonly hacked web app out there.

for autoprotect bypass, as per Beta Branch - autoprotect.sh - apache .htaccess check & migration to nginx deny all

you can inspect your generated nginx vhost include file for /usr/local/nginx/conf/autoprotect/domain.com/autoprotect-domain.com.conf to see what has been blocked

use cat command to output contents of /usr/local/nginx/conf/autoprotect/domain.com/autoprotect-domain.com.conf to your SSH session display

Code (Text):

cat /usr/local/nginx/conf/autoprotect/domain.com/autoprotect-domain.com.conf

then copy and paste that contents and post here wrapped in CODE tags.

that will tell you what autoprotect.sh sees .htaccess 'deny all' wise and what it is attempting to block and alert you do

if you want to disable autoprotect completely, in nginx vhost just comment out (do not delete), the include file for /usr/local/nginx/conf/autoprotect/domain.com/autoprotect-domain.com.conf where domain.com is your domain and then restart nginx and php-fpm

Code (Text):

nprestart

Note, that does leave you sort of vulnerable as nginx doesn't support htaccess protections so any wp plugin's author intended private directories they protect with htaccess will be left wide open for public access i.e. lots of backup WP plugins store backups with publicly web accessible directories protected by htaccess by the WP author. Under Nginx, that means your WP site backup files are publicly accessible to all ! Unless, you manually create a deny all equivalent nginx location match rule in your nginx vhost. But how do you know a WP plugin is doing this ? That is how autoprotect.sh helps, it auto checks for .htaccess and reports it in include file for /usr/local/nginx/conf/autoprotect/domain.com/autoprotect-domain.com.conf so you can see immediately which directories need a closer inspection to either manually create a deny all equivalent nginx location match rule in your nginx vhost OR let autoprotect.sh handle it for you.

That will then rule out autoprotect.sh as cause of 403 and leave wpsecure include file as possible cause of any left over 403 permission denied errors as outlined at Wordpress - Wordpress 403 Permission Denied Errors. The wpsecure include file only tries to block PHP file execution in where normally WP plugins shouldn't be running PHP in general - as it's how WP hackers drop PHP shell scripts in to compromise servers from. So if you get 403 errors related to wpsecure include, then figure out which WP plugin is triggering 403 via nginx access/error logs, then inspect any htacces files the WP plugin has. It would be WP plugin has htaccess to allow static files but deny PHP or allow specific PHP. But since Nginx doesn't support htaccess, you'd have to whitelist and/or make an nginx location match rule equivalent.

So imagine if you eventually got all whitelistings done for WP site and no 403 errors. Then a hacker via WP plugin drops a php based php command shell malware into your WP wp-content or plugin directories and tries to access the PHP file. They will get 403 errors

It maybe frustrating to do all this extra autoprotect and wpsecure whitelisting security. But trust me it will be 100x times more frustrating trying to recover from a WP hacker getting full access to your installation, wiping data or inserting malware which further compromises all sites and even your server. You'd have to wipe OS, reinstall centmin mod and restore all data from known clean backups of all your site(s) data and files. And even then you'd have to be 100% sure those backups don't have any inserted malware or backdoors left by the hackers.

I know which situation is more frustrating for me

 

Ah i see - yes some themes add their own php files which would need whitelisting.