WP Hide & Security Rewrite Rule

[Neo]

I am using “WP Hide & Security Pro” in tandem with BPS Pro. The following conditions exist as a part of “Custom Code” in section 1.

RewriteCond %{REQUEST_URI} /site-admin$
RewriteRule ^(.*)$ /site-admin/ [R=301,END]
RewriteRule ^site-admin(.*) /wp-admin$1 [END,QSA]

RewriteCond %{ENV:REDIRECT_STATUS} ^$
RewriteRule ^wp-admin(.+) /index.php?wph-throw-404 [L]

However, attempts to access /wp-admin still simply forward to /site-admin, and if not logged in it simply goes to the login page. Is BPS overriding something here and forwarding to login / admin instead of throwing to 404?

[AITpro Admin]

Your htaccess code says if the URI is /site-admin then redirect to /wp-admin/, which will automatically redirect to the WordPress wp-login.php page if you are not logged into your website.  That is the default WordPress login behavior.  I tested your htaccess code and was not redirected to the /site-admin/ URI from the wp-admin dashboard.  Maybe this htaccess code needs to be incorporated into the BPS Rewrite Loop htaccess code?  Not really sure.

You don’t need to hide your WordPress Login page if you have BPS Pro installed.  BPS Pro has 2 security features that protect the WordPress Login page > JTC Anti-Spam|Anti-Hacker and Login Security & Monitoring.

[AITpro Admin]

Hmm interesting.  I attempted to login once – nothing happened. I attempted to login twice – nothing happened. I manually removed your htaccess code from the BPS root htaccess file. I successfully logged in and was redirected to the /site-admin URI. That was left over from Google cache. I can obviously see that there are too many rewriterules in your htaccess code, which is probably causing rewrite looping problems. There is a better way to write/create that htaccess code. 😉

[Neo]

Probably the more troubling thing is that you are able to remove the .htaccess code and log in bypassing BPS security measures. What am I missing here?

[AITpro Admin]

Honestly it would be a terrible mistake to rewrite the /wp-admin/ directory. You would most likely run into endless problems with WordPress, Plugins and Themes. The approach you would want to take instead is to do a “one-time” URI security method for your Login page vs messing around with rewriting the /wp-admin/ directory.

I tried to find the htaccess code you posted above and I did not find it anywhere.  I found similar htaccess code for the WP Hide plugin, but the htaccess code is designed to work for the wp-content directory and cannot be used for the wp-admin directory.  You can hide your login page very easily by doing something like this in your theme’s function.php file > https://forum.ait-pro.com/forums/topic/protect-login-page-from-brute-force-login-attacks/

Another method to allow your Login page to be only accessible to you…

…would be to add this function to your Theme’s functions.php file.  In this example you would need to enter:  http://www.example.com/wp-login.php?mySecretString=foobar to gain access to your login page.  You would of course change “mySecretString=foobar” to whatever you want for your secret Query String.

// Simple Query String Login page protection
function example_simple_query_string_protection_for_login_page() {
$QS = '?mySecretString=foobar';
$theRequest = 'http://' . $_SERVER['HTTP_HOST'] . '/' . 'wp-login.php' . '?'. $_SERVER['QUERY_STRING'];
$allowed_hosts = array( 'example.com' );

	if ( ! isset( $_SERVER['HTTP_HOST']) || ! in_array( $_SERVER['HTTP_HOST'], $allowed_hosts ) ) {
    	header( $_SERVER['SERVER_PROTOCOL'] . ' 400 Bad Request' );
    	exit;
	}

	if ( site_url('/wp-login.php'.$QS ) == $theRequest ) {
		echo 'Query string matches';
	} else {
		header( 'Location: http://' . $_SERVER['HTTP_HOST'] . '/' );
	}
}
add_action('login_head', 'example_simple_query_string_protection_for_login_page');

[Neo]

Thank you. I will try these as well.

Regarding why it was happening to begin with–it appears that when WBM Status is “deactivated”, then wp-admin pushes to 404 with the other code in tact. Does this leave the folder vulnerable?

[AITpro Admin]

The BPS wp-admin htaccess file is no longer important and can be deactivated permanently.  Originally it protected against known vulnerabilities with the admin-ajax.php WordPress file and a couple other WP files, but that was many years ago.  WP has since “fixed” those file vulnerabilities.

[Ger Pol]

Neo,

Did you manage having both WP Hide and BPS working together?  Any lessons learned?

Regards.

 

[Author]

Posts