Wordpress (Pre VirtualHost Include) protection not working anymore
Hello,
since last cPanel update, my hack to protect Wordpress sites is not working anymore. Worked for years.
Scenario: avoid robots to reach Wordpress/PHP (CPU/memory intensive, password brute-force to WP-Admin). So, I do a simple basic authentication before the real WP login screen. User must basic-authentication "wp"/"wp" before reach the real login screen.
How: Pre VirtualHost Include
Now, WP shows a "page not found" error:
AuthUserFile /usr/local/apache/conf/wordpress.password
AuthName "TYPE USER wp AND PASSWORD wp"
AuthType Basic
require valid-user
Now, WP shows a "page not found" error:
-
Hey there! When I tested this on my end I found the wp-login.php page wasn't redirecting properly due to the default .htaccess page that is created by Wordpress. I can't say how this was working before, but I setup the password file and include and also received an error until I removed the redirect to index.php from my .htaccess file in the public_html. 0 -
Hi @cPRex, yes, but we cannot touch the users original WP .htaccess file. It's correct and works in normal situations. The Pre VirtualHost Include hack/code forces wp-login.php to do basic authentication globally, to all users, to any file named wp-login.php. This hack protect the server from scans (won't run PHP, so, not overload the server). Robots stop on the basic authentication, protecting the server. This worked for years... for some reason stopped to work in latest cPanel upcp run. Server was 92.0.6 before this, so, not related to cPanel version directly. But I realized that all .htaccess files were touched, but I don't think this is related, because the problem occurs even if I install the original WP .htaccess file. Maybe something to Easy Apache that was updated? [2020-12-26 02:17:02 -0300] [/usr/local/cpanel/scripts/rpmup] ---> Package ea-apache24.x86_64 0:2.4.46-2.4.4.cpanel will be updated [2020-12-26 02:17:02 -0300] [/usr/local/cpanel/scripts/rpmup] ---> Package ea-apache24.x86_64 0:2.4.46-3.7.1.cpanel will be an update [2020-12-26 02:17:02 -0300] [/usr/local/cpanel/scripts/rpmup] ---> Package ea-apache24-config.noarch 0:1.0-167.167.5.cpanel will be updated [2020-12-26 02:17:02 -0300] [/usr/local/cpanel/scripts/rpmup] ---> Package ea-apache24-config.noarch 0:1.0-168.168.6.cpanel will be an update [2020-12-26 02:17:02 -0300] [/usr/local/cpanel/scripts/rpmup] ---> Package ea-apache24-config-runtime.noarch 0:1.0-167.167.5.cpanel will be updated [2020-12-26 02:17:02 -0300] [/usr/local/cpanel/scripts/rpmup] ---> Package ea-apache24-config-runtime.noarch 0:1.0-168.168.6.cpanel will be an update0 -
Thanks for the additional details. I didn't mean the .htaccess was an issue, but the only way I could get things working on my end was my removing the standard redirects that Wordpress does. If you downgrade the RPMs, do things work how you expect? 0 -
Probably yes... I cannot downgrade, server has about 200 accounts, I don't feel comfortable and don't want to have problems in these days (time to enjoy holidays). My main concern is why FilesMatch is not working anymore after so many years... Not related with permissions or file location (wordpress.password). [CODE=apacheconf] AuthUserFile /etc/wordpress.password AuthName "TYPE USER wp AND PASSWORD wp" AuthType Basic require valid-user
I had to remove the code and now my server is receiving those wp-login.php attacks. CPU average changed from 9% to 31% since then. :rolleyes:0 -
I checked my personal system and received those packages back in September. It might be best to open a ticket with our team so we can look at one of these systems directly and see what configurations may be coming into play. If you do that, please post the number here so I can keep the community updated with our findings. 0 -
Well, now I'm lost :( I did a test in a Non-Wordpress site. I just created a dummy wp-login.php file. And... the basic authentication worked fine, and let me run the dummy PHP after insert the correct user and password. So, the Pre VirtualHost Include hack is working, not related to the last weekend updates... I realized that all .htaccess files, in all accounts, were touched. All have the same datetime: 2020-12-26 04:51 UTC. Now I need to check what changed, and what is happening only in .htaccess created by WordPress... 0 -
The plot thickens!!!! Let us know what you find! 0 -
If I rename .htaccess to .htaccessX, Pre VirtualHost Include hack works on a Wordpress site! With it, I get a 404 error. But we need it, due to the Wordpress "path mask" feature (ie: /foo/bar/ in the address bar instead of /index.php?id=9999). Wordpress is redirecting based on: [CODE=apacheconf] RewriteEngine On RewriteBase / RewriteRule ^index\.php$ - [L] RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /index.php [L]
So, something happened this weekend that: - Before: the Pre VirtualHost Include hack was running and ignoring .htaccess. - Now: .htaccess has priority over the Pre VirtualHost Include hack. Note: tested in 2 cPanel servers. All updated this weekend, all with the same behavior. That's where I'm stuck.0 -
Still no idea how to fix this. In a non-cPanel server, the hack works. Only stopped to work after the latest cPanel update, maybe the EasyApache 4 update. Can I open a ticket about this? Now my server is being scanned 24/7 after I removed the hack (to allow users to login). 0 -
Absolutely - feel free to open a ticket at any time! Please share the ticket number here so I can follow along and keep the community updated. 0 -
Hi @cPRex, ticket created, internal reference is: #94094532 Thanks. 0 -
I'm following along with this now, although it's possible they split this into two separate tickets. 0 -
Probably the FilesMatch and the Basic Authentication are the same problem. Because both are related to Wordpress + Basic Authentication. I think my FilesMatch hack is not directly related. 0 -
SOLVED! Eric Delorme (cPanel) wrote: "This occurs because WordPress rewrites everything and anything accessing the site's public_html to index.php as you have shown in the mod_rewrite rules set by WordPress. In order to work around this .shtml files need to be excluded so that 401.shtml can be loaded along with the Apache Basic AuthType. Unfortunately, there isn't a work around." But he gave a tip: .shtml files. So, to fix, I just reverted 401/403 errors to its defaults, so, the hack is now: post_virtualhost_global.conf: [CODE=apacheconf]ErrorDocument 401 default ErrorDocument 403 default AuthUserFile /usr/local/apache/conf/wordpress.password AuthName "TYPE USER wp AND PASSWORD wp" AuthType Basic require valid-user
Now the server is protected again. Thanks @cPRex for your help!!0
Please sign in to leave a comment.
Comments
15 comments