4 Oct
2015
4 Oct
'15
8:09 p.m.
Rodrigo Campos said:
wp-fail2ban can be used with IPv4, IPv6 and
doesn't take into account the login
that worked ok. So, no need to the the trick described there with so many
disadvantages.
Pointing fail2ban at any access of wp-login.php?
Apart from expecting that people can get their own password right within
a few tries, I am not sure what the 'so many disadvantages' are.
If you are in control of all of the WordPress setups, fine, remember to
install a plugin on them all and hope the author(s) keep it up to date.
If you're not, trying to keep track of who's (un)installed it and who
hasn't is a never-ending source of fun.
In practice, you can set the maxretry to something like 20 which will
still catch the bots without any risk of catching any even vaguely
clueful real user.
I'm not sure where my login details are, or I'd update it to say that WP
has /finally/
a) Turned off comments by default on pages... but not posts
b) Stopped suggesting 'admin' as a username
c) Started generating strong passwords for new users.
They /are/ still having user privilege escalation exploits.
Oh, you can stop anyone changing the highly dangerous WordPress Address
(URL) and Site Address (URL) settings by having
define('WP_SITEURL', 'http://example.com');
define('WP_HOME', 'http://example.com');
in wp-config.php (do I need to say replace example.com with the real URL?)
Oh2, and having
define('DISALLOW_FILE_EDIT', true);
there no longer affects Quick Cache (now called ZenCache and a much
better option than their own cache plugin, especially if you splash a
few dollars for the Pro version...)
Ian