Andrew Nevins
(@anevins)
WCLDN 2018 Contributor | Volunteer support
Have you talked to your hosting providers about this issue? They’re in a much more effective position to tackle this (assuming you’re referring to brute force attacks).
I use LiquidWeb and they think the best solution is to block by IP address and I have over 70 customers who log in from different devices so that’s not going to work.
I am also currently using WordFence which helps to mitigate the problem but I still have 3×70 attempts using ‘admin’ every so often and that’s just not good enough. I need to remove the door completely rather than allow three knocks.
meshmarketer – They’re not wrong. However ask them about mod_security and doing more rate limiting on wp-login (which I know they can do).
See these too:
http://halfelf.org/2013/wp-login-protection-modsec/
http://halfelf.org/2013/wp-login-protection-htaccess/
They do use ModSec already and it’s screwing up my efforts to use plugins to thwart Brute Force Attacks.
While I appreciate your viewpoint that “they’re not wrong” it really doesn’t help me. I have over 70 customers including ones who access their site via Hughes ISP and their IP address literally changes every five minutes. It is truly impossible to limit by IP with such customers.
I’m really amazed that there is no solution here for such an obvious vulnerability. If you have just ONE target page accessible via millions of addresses which creates millions of targets being hit continually, then you increase the target to millions TIMES millions and see if that doesn’t improve things a bit.
After all, the default “admin” name did get changed, right? Why can’t there be some instructions on how to make this more bulletproof?
Again, see the two links I posted.
You can also read this: https://codex.ww.wp.xz.cn/Brute_Force_Attacks
If you’re on their shared service, there’s a limit to what they can do. If you’re on a VPS, you should install CSF – https://www.liquidweb.com/kb/csf-config-server-firewall-installation/ – and it does a remarkable job 🙂
There isn’t ‘one’ fix because there just isn’t one size fits all. It’s just not possible yet given the myriad situations possible to have installed WP, and the billions of ways people use them. You’re on one kind of server, I’m on another, and someone else is on Windows or Nginx, and frankly the SAME fix won’t work for all of them. Yaaaay.
I appreciate your insistence that you have a solution, but as I had mentioned, I already talked with them about this AND with a little help from WordFence, I’m currently blocking those who fail to put in a password after three attempts as well as anyone using “admin” as a username. This helps to stem the flow, but really, what is needed is a sea-change strategy here. We can’t rely on workarounds to fix this for everyone (and by the way, you say there is no one fix and yet you seem insistent that yours is the way to go).
I’m saying there IS one fix for everyone and that is to eliminate the address where hackers go to.
I’m not a programmer, but it seems to me that having a URL to go to (accessible via email recovery) that will set a cookie which can make the login door visible would be a smart way to go.
If I knew how this “referral request” worked and I were a programmer then I would make my own plugin and then take every single Brute Force Attacker and redirect them to their own address via .htaccess.
If you’d read the links I gave you, you’d see that they are general advice with options and suggestions to possible solutions that work for you. There are TEN plugins posted there as options, three .htaccess possibilities, and more server possibilities.
If you don’t want to read them and experiement, that’s on you. We’re suggesting you try what fits your scenario.
I’m not a programmer, but it seems to me that having a URL to go to (accessible via email recovery) that will set a cookie which can make the login door visible would be a smart way to go.
Sure. And every single time these crackers hit that URL, or the wp-login.php/wp-admin one that they used to hit, and get an error, your site will be loading WP, which will cause it to slow down and have the same end result of a DDoS that you’re seeing now.
If I knew how this “referral request” worked and I were a programmer then I would make my own plugin and then take every single Brute Force Attacker and redirect them to their own address via .htaccess.
https://codex.ww.wp.xz.cn/Brute_Force_Attacks#Deny_Access_to_No_Referrer_Requests
Like that?
Ipstenu, I’m not asking for information other than some instructions on how to safely make my own login address.
I read what you sent, if it’s any consolation to you, and I have been testing SEVERAL plugins and what I have found is that none of them appear to work with multi-site. Even the fine folks at LiquidWeb who have been using a number of different approaches to stem the Brute Force Attacks have sent me links to plugins that are not multi-site compatible and they have also tried to get ones I have tried to work properly without throwing 500 errors.
I have no doubt you want to help, and thank you for that, but I really did know what I was requesting and I still am waiting for my request to be fulfilled and not redirected. If you don’t have those instructions, I’m really not sure why you think I should be given something else.
My advice, having been in this business for a long time, is you don’t need to do this. You will, as you already have, find yourself banging your head on the wall. Multisite makes everything harder, just hands down, and hiding wp-admin MAY break a lot of things because WordPress doesn’t want you to do this. It’s very close to putting leaded fuel in your car.
I’m not asking for information other than some instructions on how to safely make my own login address.
https://ww.wp.xz.cn/plugins/rename-wp-login/ (which you said was broken and didn’t look like would be fixed any time soon) was updated on the 8th. The very day you posted. So make sure that didn’t fix it for you too.
https://ww.wp.xz.cn/plugins/better-wp-security/ purports to do it.
I really did know what I was requesting
You do, but you don’t understand why it’s a bad idea, and why it’s hard, and why it’s the wrong road to travel down. Which is why we attempt to educate you so you don’t end up back here tomorrow complaining that the plugins don’t work right in your setup.
We will not be surprised, by the way, if that happens anyway. We’ve been there before.
