Hidden login page is comprimised

Reply to myself!

Found out that plugin left old slug in .htaccess:

RewriteRule ^(/)?<strong>oldslug</strong>/?$ /wp-login.php [QSA,L]
RewriteRule ^(/)?wp-register-php/?$ /wplogin?action=register [QSA,L]

So both old and new worked! Probably robots still remember the old one.

After few cycles of turn “hide backend” on, save, refresh, turn off, save, refresh, etc I found out that these two lines appear in .htaccess only when “hide backend” feature is switched OFF!!!

What’s the sence? How it works when turned on, and why these lines needed when turned off?

@dvascheta

Do anyone have an idea how robots detect login url?

You are assuming invalid login attempts are the result of bots performing wp-login.php POST requests while using your secret/hidden login slug.

Did you verify this in the web server logs ?

There are other ways of performing login attempts …

The web server logs will tell you.

dwinden

Thanks, dwinden, seems that I found the reason, wrote above. I forgot about Meta widget and then plugin left old slug in .htaccess.

I’d like to believe the plugin protects wp-login.php from all kind of requests.

I didn’t examine logs, think I should turn it on first. Thanks, if the problem will not be solved, I will follow your advice!

@dvascheta

With all due respect, the problem will probably not be solved.

The only way to know for sure how invalid login attempts are done is by monitoring the web server logs.

Your “solution” is still focusing on invalid login attempts triggered by wp-login.php POST requests using your secret/hidden login slug …

Without verification from the web server logs that this is the actual brute force method being used you are only guessing …

No criticism. Just trying to help to get it right ??

dwinden

dwinden, really thanks! I’ve not thought about logs before your message and now think this is really good idea. I’m not well familiar with logging mechanism so it will take time to set it up and I’m not sure what exactly to look for in logs.

So I will need extra time to find all this out. At the same time today I have no more messages about brut force and just decided to do all this later, for example as soon as I receive next message.

But now I know where to look for, so thanks once again!

@dvascheta

A default Apache install includes logging. Unless you have explicitly disabled it. So I don’t think you need to set up anything. Just look in the existing logs.

Anyway I think this topic can be marked as ‘resolved’.

Goodluck !

dwinden

I use virtual hosting and need to find logging there.

Thank! Mark topic as resolved.

@dwinden, hello again! You were right! Two more attempts today. Found and turned on loggin, now waiting for next robot. And two more questions to you please:

1) Do you mean that plugin’s protection doesn’t cover wp-login.php when it is called with POST request? Only GET request? Why? Then it seems to bet not a real protection!

2) What to do after I look in logs and know how they really attack?

Thanks in advance!

@dvascheta

1. No, both will be blocked by the Hide Backend feature.
However the Away Mode feature will only block (actually redirect to the homepage) wp-login.php GET requests. So the Away Mode feature is useless for stopping (automated) brute force attacks.
And that is ok, because this feature was never designed to stop (automated) brute force attacks.

2. You will know when you identify which brute force method is being used from the logs. Simply identify which http request is logged by the webserver at the same timestamp that the invalid login attempt is registered in the iTSec plugin log.

The iTSec plugin includes another option to secure your site from those brute force attempts. I think I know which one but we need the confirmation from the web server log.

dwinden

Hi, @dwinden

I’ve caught it!

182.50.130.188 - - [30/Jun/2016:23:18:47 +0300] "POST /xmlrpc.php HTTP/1.0" 403 5 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:23.0) Gecko/20100101 Firefox/23.0"

So attackers are not accessing wp-login, it is xmlrpc! Xmlrpc was enabled in plugin and I disabled it now. So waiting again to find out if this was the only reason.

Thanks again!

Just wanted to say that the discussion here was very helpful. I came here looking for how one would discover a hidden WP login slug, then realized XMPRPC was the culprit. Thanks guys.

@zehawk, welcome!

I’ve already forgot I had this problem, so probably XMLRPC was the true reason.