Unlike hacks that focus on vulnerabilities in software, a Brute Force Attack aims at being the simplest kind of method to gain access to a site: it tries usernames and passwords, over and over again, until it gets in. Often deemed 'inelegant', they can be very successful when people use passwords like '123456' and usernames like 'admin.'
They are, in short, an attack on the weakest link in any website's security: You.
Due to the nature of these attacks, you may find your server's memory goes through the roof, causing performance problems. This is because the number of http requests (that is the number of times someone visits your site) is so high that servers run out of memory.
This sort of attack is not endemic to WordPress, it happens with every webapp out there, but WordPress is popular and thus a frequent target.
A common attack point on WordPress is to hammer the wp-login.php file over and over until they get in or the server dies. You can do some things to protect yourself.
The majority of attacks assume people are using the username 'admin' due to the fact that early versions of WordPress defaulted to this. If you are still using this username, make a new account, transfer all the posts to that account, and change 'admin' to a subscriber (or delete it entirely).
You can use the plugin Admin Renamed Extended to change the username in-place.
The goal with your password is to make it hard for other people to guess and hard for a brute force attack to succeed. Many automatic password generators are available that can be used to create secure passwords.
WordPress also features a password strength meter which is shown when changing your password in WordPress. Use this when changing your password to ensure its strength is adequate.
You can use the * Enforce Strong Password plugin to force users to set strong passwords.
Things to avoid when choosing a password:
A strong password is necessary not just to protect your blog content. A hacker who gains access to your administrator account is able to install malicious scripts that can potentially compromise your entire server.
Plugins can be used to limit the number of login attempts made on your site, or block people from accessing wp-admin:
If you decide to lock down wp-login.php or wp-admin, you may find you get a 404 or 401 error when accessing those pages. To avoid that, you will need to add the following to your .htaccess file.
ErrorDocument 401 default
You can have the 401 point to 401.html, but the point is to aim it at not WordPress.
Password protecting your wp-login.php file (and wp-admin folder) can add an extra layer to your server. Because password protecting wp-admin can break any plugin that uses ajax on the front end, it's usually sufficient to just protect wp-login.
To do this, you will need to create a .htpasswds file. Many hosts have tools to do this for you, but if you have to do it manually, you can use this htpasswd generator. Much like your .htaccess file (which is a file that is only an extension), .htpasswd will also have no prefix.
You can either put this file outside of your public web folder (i.e. not in /public_html/ or /domain.com/, depending on your host), or you can put it in the same folder, but you'll want to do some extra security work in your .htaccess file if you do.
Speaking of, once you've uploaded the .htpasswd file, you need to tell .htaccess where it's at. Assuming you've put .htpasswd in your user's home directory and your htpasswd username is mysecretuser, then you put this in your .htaccess:
# Stop Apache from serving .ht* files <Files ~ "^\.ht"> Order allow,deny Deny from all </Files> # Protect wp-login <Files wp-login.php> AuthUserFile ~/.htpasswd AuthName “Private access” AuthType Basic require user mysecretuser </Files>
The actual location of AuthUserFile depends on your server, and the 'require user' will change based on what username you pick.
If you use ModSecurity, you can follow the advice from Frameloss - Stopping brute force logins against WordPress. This requires root level access to your server, and may need the assistance of your webhost.
If you're using ModSecurity 2.7.3, you can add the rules into your .htaccess file instead.
Services like CloudFlare and Sucuri CloudProxy can also help mitigate these attacks by blocking the IPs before they reach your server.