Using Wordfence as a login hacker honey trap

Thanks for the input — I have heard of a couple other people renaming the login form with another plugin, and blocking the original this way, and it seemed to work well for them.

For your questions at the bottom of the post, yes, it would have a lower impact on resources to block wp-login.php directly in .htaccess — but of course, then the IPs wouldn’t be blocked from other parts of the site. When blocking access to a page, the attackers’ IPs won’t be sent in to the security network, since it is a custom URL block, rather than an actual login failure.

For the request to rename wp-login.php within Wordfence, I have added your input to a feature request we have open already (reference number FB567). I can’t say when or if it will be implemented for certain, but I think this one has a good chance.

Thanks!

-Matt R

Thanks for the reply Matt, really appreciate it.

My setup seems to be working in that I’m not having any trouble with my site, but I’m wondering if the bots and hackers trying to access wp-login.php are really being IP blocked. On second glance I noticed on the Wordfence documentation that the user is supposed to only specify “pages” that _do not_ exist.

So, wp-login.php indeed exists but has a redirect due to my use of the obfuscation plugin. But it’s a file, not a page. Confusing. Below is the WF documentation, quoted.

“Immediately block IP’s that access these URLs
This allows you to set a kind of trap for bad guys. You can enter a URL that does not exist, for example: /vulnerabilityLivesHere
Then if someone tries to access that URL they are instantly locked out. You have to specify a relative URL, in other words it must start with a forward slash. It also must be a page that does not exist on your website.
We only recommend this feature if you are trying to catch a specific hacker and block them or if you are trying to catch hackers that are trying to exploit a known vulnerability or page on your site.”

Yes, this isn’t exactly the intended use for the feature, but it does seem to work correctly. I think the main reason the documentation says that the page must not exist on the site is that if it were a page that regular visitors would see, they would be blocked. It may be possible other plugins could cause conflicts, and make the blocking not work in those cases, as well.

To confirm that it is working, you can look at the Blocked IPs page, and you should see any of these with the Reason field showing “Accessed a banned URL”. If your blocking time is short, you might not see them unless you set “How long is an IP address blocked when it breaks a rule” to a longer time.

Alternately, if you have any way to visit the original login page from different IP (say, from a phone that isn’t using your local WiFi), you can see the blocking message yourself. Just be certain you’re visiting from a different IP, especially if you have set the blocking to last a long time!

-Matt R

Thanks, yeah, WF did a block on IP 68.64.170.74 due to my setup, which is a known bad IP I found on a couple of blacklists. What I don’t understand is why that IP was not already being blocked by the WF network?

Can you direct me to a white paper or other that explains how WordFence acquires bad IPs that it blocks re Real-Time WordPress Security Network?

Thanks, MTN

Brief documentation on the feature is available here:
Wordfence options: Participate in the Real-Time WordPress Security Network

Blocks expire periodically, and may have different criteria from some of the other blacklists. The expiration is useful when bots are abusing VPN services that are also used by real users, so the service’s IPs wouldn’t stay blocked forever, and the valid users will be more likely to be able to still use the service — but if malicious login attempts are still occurring, they’re generally blocked again soon afterward. (VPN services are useful to protect your traffic when you’re using an untrusted network, like free wifi at a coffee shop or hotel, but unfortunately, since they’re cheap, they’re often abused by people running bots, too.)

-Matt R

Thanks Matt

Hey guys:

Adding the wp-login.php to the Immediately Block in WF options didn’t work.
(I did this obviously after changing my login url using the WPS Hide Login plugin).

Those users simply get a 404 error.

But adding a fake non-existing page like /test123 is working, i.e. any IP that tries to access this non-existing page is being immediately blocked by WF.

Any help please on how to immediately block wp-login.php visits?