I admin a server with lots of wordpress installations on it. Searching a solution to prevent high CPU on bruteforce attacks, this make the server unusable some hours a day.
These are the targets:
I admin a server with lots of wordpress installations on it. Searching a solution to prevent high CPU on bruteforce attacks, this make the server unusable some hours a day.
These are the targets:
There are plenty of things you can do to stop the attackers chewing up your resources.
You may have valid reasons not to use this on all or some sites, but please don't underestimate the usefulness of this technique. Use wherever possible.
By requiring users to login at the web server level you minimise the damage attackers can do, limit the resources required to deal with these attacks, and further protect your websites that may have vulnerabilities.
You can deny access to parts of your website. Even if you have to open up a rather large subnet of IPs, it's better than letting the whole world in!
In nginx it might look something like this:
location /wp-admin {
# block one workstation
deny 192.168.1.1;
# allow anyone in 192.168.1.0/24
allow 192.168.1.0/24;
# drop rest of the world
deny all;
}
Brute-force attacks make a number of assumptions. If you can rename your wp-admin folder, rename wp-login.php or run wp-admin on a non-standard port then you won't have to spend your precious resources trying to valid these brute force logins.
http://wordpress.org/plugins/wp-fail2ban/
fail2ban is one of the simplest and most effective security measures you can implement to prevent brute-force password-guessing attacks.
fail2ban has some interesting features:
Many attackers attempt to login with common usernames, such as admin. It's good practice not to use these usernames, in which case you can block anyone who attempts to login with them.
WPf2b now allows you to specify a regex that will shortcut the login process if the requested username matches
define('WP_FAIL2BAN_BLOCKED_USERS','^admin$');
The idea here is to list the IP addresses of the trusted proxies that will appear as the remote IP for the request.
define('WP_FAIL2BAN_PROXIES','192.168.0.42,192.168.0.43');
I can think of a few possibilities right off the top of my head; in order of roughly increasing invasiveness to legitimate users:
wp-login.php
to something else? (Needs to be maintained when upgrading, relies on security through obscurity, but should stop most non-targetted scripted attacks with a minimum of trouble for legitimate users.)wp-login.php
in a front-side load balancer or firewall? (Will give legitimate users trouble during a request flood, but at least the rest of the server including public access to blog content should keep churning along happily.)I wrote a WordPress plugin which you will probably find helpful.
Bad Behavior has a good track record of stopping these sorts of brute-force attacks. It's sort of a minimalist web application firewall which blocks link spam and some other malicious traffic very early, before all of WordPress is loaded, saving CPU and other resources. (I say minimalist because what can be done only at this layer is minimal compared to what you can do in the web server or even with a separate appliance, though it was designed for people with no other option.)
You'll find it in the WordPress plugin repository.
Since you run the server, you may also want to use ModSecurity with the Core Rule Set. Many of Bad Behavior's rules are reimplemented here (look for my name and/or Bad Behavior's name in them) and the ruleset also contains many other rules which may be helpful to you.