Access via a forged auth cookie, unless somehow stolen from a valid logged in user, would be incredibly unlikely. Access by password guessing would be much more fruitful. I personally don’t think it’s a vector to worry about.
If you wanted to, you could hook the “auth_cookie_valid” action and check the remote IP stored in the $_SERVER array. If it’s not an IP to your liking, you can call wp_die() to terminate the request.
Thread Starter
gxxaxx
(@gxxaxx)
bcworkz,
Thanks for the reply. I will think about implementing the auth_cookie_valid. However, since I haven’t touched php for about 10 years not sure I want to jump into that puddle. No telling how deep it is. By the way I do appreciate how complete the hint was — giving the name of the server array and best practice for jumping ship with the wp_die. Thanks.
From the sounds of your reply it seems that the password guessing that is happening on my site is not through the cookie mechanism.
Does it seem like these password guessers are somehow getting around the .htaccess instructions? Or, does it there some other mechanism for the password guessing?
Your .htaccess restriction applies to wp-login.php only, but there are other ways to gain access without requiring wp-login.php. The vast majority of attacks I’ve seen are either probing for known vulnerabilities (unpatched plugins, etc.) or are attempting to brute force guess passwords. I’ve seen brute force attacks against xmlrpc.php. I’m not sure how that is supposed to work. Unless there is good reason not to, I would limit access to this file by IP as well as wp-login.php. There may be other attack vectors, though I’ve not seen any such alternative attacks in the wild. I don’t make a big study over request logs, so it’s not like I’ve seen everything. For example, I don’t know where the login modal comes from when we request /wp-admin/ with an expired auth cookie. That could be exploited if it is not due to wp-login.php.
You might consider using one of the many security plugins available, with or in place of .htaccess rules. At the very least, I would use a plugin that locks out access for a time period after so many wrong password guesses. It will not stop brute force attacks outright, but it sure slows them down significantly, such that success with guessing even weak passwords is either unlikely or going to take a very long time. Not that it would be an excuse for not using strong passwords 🙂
Of course, if you are sure you’ve locked out all login vectors in .htaccess, there is no need for guess limiting. I don’t know how we can be sure all vectors are covered. Even if someone knows now, the situation can change with future releases. There’s no harm in doing both. You might also look through other measures in Hardening WordPress. There could be something mentioned that would be of benefit.
Thread Starter
gxxaxx
(@gxxaxx)
Thank you for the reply.
I will look into also blocking xmlrpc.php
Might help.
FYI, I am currently using a limit on login attempts plugin and a security monitor.
The whole .htaccess thing is an attempt to add an additional layer of protection.
Thanks again.
