Graham

@iiiiiiiv Yes, the slug is visible to people who are logged in – otherwise they could not have logged in in the first place.

But it is not known to anyone who does not have the permission to log in.

You are also not blocking xmlrpc, which will allow hackers to bypass the plugin.

You need to add this to the bottom of your .htaccess file:

# Block WordPress xmlrpc.php requests
<Files xmlrpc.php>
order deny,allow
deny from all
</Files>

Sorry, but I’ve installed an older version because 4.1.7 not only adds the home page to the block list, but also won’t ping Google.

It says to make a new post before it will ping Google, but that doesn’t happen. It just keeps saying the same thing.

So I’ve gone back to a version that works and modified the version number so it doesn’t prompt for an update.

You’re welcome.

@spade The order is also the wrong way round. Should be:

# Block WordPress xmlrpc.php requests
<Files xmlrpc.php>
order deny,allow
deny from all
</Files>

@spade

Going to your site and adding /xmlrpc.php returns:

XML-RPC server accepts POST requests only.

That means xmlrpc has not been disabled.

The files tag should be capitalized – Files, not files. May be reason?

• This reply was modified 1 year, 7 months ago by Graham.

@seinomedia We are not talking about the secret slug, but the page you set up to send hackers to.

Your plugin has always used that page for wp-admin/wp-admin.php but not for wp-login.php

To send hackers to that page for wp-login.php you need to create the redirect.

Maybe you could capture that page somehow and let the plugin do the redirect. It would solve the problem. Something to think about?

• This reply was modified 1 year, 7 months ago by Graham.

It’s the only way it will work. It doesn’t do any damage using redirects, so no need to panic.

@scarlywebs Yes, by default wp-admin goes to your page, but wp-login.php does not.

That’s why you need the redirect.

@scarlywebs No it’s not a file. By default the plugin goes to the error 404 page. You need to redirect it to your page instead.

Somewhere in Runcloud I would assume there is a function to set up redirects. In cPanel it’s under Domains>Redirects

Look for where you have the option to add a subdomain or addon domain and it will probably be around that area somewhere.

Or maybe there is a totally separate area where you can configure redirects. You’re not looking for a file or a way to modify the plugin, only a function in your account for that domain.

If your server supports .htaccess you could add this to the bottom, changing mysite and mypage to yours:

RewriteCond %{HTTP_HOST} ^mysite.com$ [OR]
RewriteCond %{HTTP_HOST} ^www.mysite.com$
RewriteRule ^wp-login.php$ "https\:\/\/mysite.com\/mypage" [R=301,L]
RewriteCond %{HTTP_HOST} ^mysite.com$ [OR]
RewriteCond %{HTTP_HOST} ^www.mysite.com$
RewriteRule ^wp-login.php\/$ "https\:\/\/mysite.com\/mypage" [R=301,L]

Yes, couldn’t is probably not the right word. “Most likely wasn’t” would be more correct.

I think they just tried to login through the back door and once they were blocked, couldn’t access the site any more.

Touch wood, I have never had a site hacked since I started making them in 1998. I use various methods to lock them down. No one method will cover everything.

@scarlywebs

You have to create a domain redirect for your new page. Needs to be 301 redirect in cPanel.

For example:

https://site.com/wp-login.php redirects to https://site.com/mypage

Depending on what control panel you are using, look for “Domain Redirects” as an option.

It has been my experience that if xmlrpc.php is not blocked, that is how a login is attempted. They do not try via the normal login screen at all.

With or without your plugin, they try to get in that way. I can see that in the raw access logs, which is why I realized my .htaccess wasn’t doing its job.

No the sites could not have been compromised, because I have brute force login protection that permanently blacklists an IP after 2 failed login attempts.

I unblocked that IP, but of course they came straight back because of the missing code.

I have just noticed my .htaccess files for my latest sites have dropped the code I put in to disable xmlrpc.php

I put it in when I created them, but it appears to have been stripped out since.

So the sites were vulnerable to xmlrpc attack. This means your plugin was probably not bypassed and is doing its job.

I am having the same problem. Despite using an unguessable slug, one IP is constantly hitting my brute force login plugin.

That is locking them out, but I don’t understand how they got to the login page in the first place.

I have used this plugin for years and every now and then someone gets through. So there is obviously a way to do it, one that we don’t know about.

There is no way anyone could guess the slug I’m using. There must be a black hat way to defeat this plugin. The fact it’s the same IP tells me they know something we don’t.