Failed login attempts with login page and XML-RPC disabled

@sugarcane
1) Do you have “Enable login security” checked in options?

2) Assuming yes, how many login attempts do you allow before blocking an IP.

3) When you say your login page is “being blocked by IP”, do you mean…
– because attempts were made to login and they reached the limit in question #2 above?…Thereby blocking the IP for X amount of time.
– or are you using the feature under Options>Live Traffic View>”List of comma separated IP addresses to ignore”? …note, this feature does not block IP, but rather it’s supposed to PREVENT showing you that IP under “live view”. (eg…ignore your own IP address)

4) Assuming you have login security active, and an IP has been blocked automatically by this WF feature, then WF should be blocking any further login attempts to that IP for the amount of “time” that you have chosen. BUT…this doesn’t stop the offending IP from knocking on the door over and over again.

@themadproducer
1) Yes
2) 3
3) What I meant is my wp login page is blocked at the server level (Apache) to only allow access to my own IP. No other IPs have access to the login page.
4) Amount of time a user is locked out is set and is working as expected

I am trying to understand why, if both login avenues are blocked (wp login page and XML-RPC), how is it possible for anyone to have the opportunity to attempt a login in the first place?

The fact I am getting warnings from Wordfence that a login attempt has been attempted and blocked indicates that either one of those 2 login avenues are open (but they’re not) or there is a 3rd avenue available that I am not aware of.

Thank you for your reply and ideas to help unravel this mystery!

@sugarcane
Great answers.

Your answer in #3 should basically override #2 and #3 unless you your self make an error logging in. I use htaccess right now to prevent access to wp-login.php from all IP address except my own single IP address. (set up like a white list)

As soon as I implemented this, WF has yet to record a single login attempt across any of my 4 websites that I am testing with. In a way, WF has become a fail safe 2nd layer not to mention all the other good features.

So, that being said, I am going to guess that your code may be incorrect. Are you using htaccess at the root level of your website?

You could share the BLOCKING portion of the code here and we could look at it? This is what I use and it has worked wonders:

<files wp-login.php>
Order Allow,Deny
Allow from 12.34.567.89
ErrorDocument 403 “no”
</files>

@themadproducer

My hosting provider providers a feature in their settings panel to block access to the login page, which I have activated. I will followup up with them and check if it is blocking the login completely. When I check from another IP in a web browser I am blocked with a 403 forbidden error. However, in my apache access logs I see an entry from the offending IP showing:

“POST /wp-login.php HTTP/1.0” 200 3970
“POST /wp-login.php HTTP/1.0” 200 3970
“POST /wp-login.php HTTP/1.0” 200 1646 …

To my understanding the 200 codes indicates a successful post to the login page?

I will also try the apache block code you posted. Many thanks for you help!

@sugarcane
Typo… I meant “Your answer in #3 should basically override #2 and #1” (i think you understood anyway)

I believe those POST 200 lines mean that the bad IP REACHED the login page.
Correct me if I’m wrong (anyone) but it’s when it reads GET 200 that means they have successfully logged in. That’s what my raw access logs shows.

But now that I have the white list code in htaccess…the bad IP never gets Post 200…instead it’s Post 403…which means they don’t even arrive at the login page whether it actually exists or not…which in my tests…greatly reduces server load.

Another way to tell that they have NOT succeed, is the time stamps of those attempts you quoted. If they are all only seconds apart, then you know that they are failing to actually login and they keep retrying over and over. And lastly, are they all the same IP or different? If they are different but still seconds apart, then it’s a Botnet attack rather than just a Bot attack…which is harder to stop with WF since each IP only tries ONCE rather than 3 times or more. That’s where htaccess comes in…or some of WF request rate limit settings.

@themadproducer: Thanks for your input on this post! It’s correct that the POST with a “200” response on wp-login.php usually means that an attempt was made to log in. The GET with a “200” can mean that a login was successful if it’s on /wp-admin/, but might not always appear depending on how the login was done, if there is a redirect or another plugin involved (for example, site membership plugins).

@sugarcane: Was your host able to help with the logins that were getting through? If the host is supposed to be blocking the login page altogether, it doesn’t look like that was happening, but Wordfence seems to be working correctly when the attempts are made. Let us know if you have any other questions on the Wordfence side of this. Thanks!

-Matt R