WAF: Hardening Options
With the Hardening Options section you are able to harden the way some basic WordPress features work. These are advanced settings, so please make sure you understand what each option does before you enable it.
WordPress is very verbose when a user fails to login. It tells the user if the username is not found or the password is wrong. While this is useful for forgetful users, it's like striking gold for hackers. They can abuse these messages to figure out which usernames are used on your site and then launch a brute force attack (try many different common passwords until they're in).
By setting some text in this option you will be replacing the login failure message with what you've entered, no matter if it's the username or the password which is wrong. We recommend setting it to something along the lines of "You have entered the wrong username, the wrong password or you don't have an account on our site".
Removes the RSS (feed) links from your site's pages. If someone knows, or guesses, the feed URL they can still access the RSS feed.
Removes the special links normally present on your site's pages which allow you to use third party blog editor applications. Obviously you should only enable this option if you're not using any such software.
WordPress keeps a user logged in for 48 hours or, if they have used the Remember Me feature, for 2 weeks. You can use this option to change the duration of the login session. It's recommended that you keep the regular login short, around 30 minutes, to contain the damage of any cookie stealing attacks against your device.
When enabled, trying to modify the settings of an existing or create a new user from WordPress' Users page will fail. You will need to disable this feature to create or edit WordPress users.
When enabled, failed login attempts of any kind of user (even simple users only allowed to comment on posts) count as security exceptions and are being logged in Admin Tools' Security Exceptions Log. There is a very useful implication to that. Since they count as security exceptions, they count towards the exceptions limit you set up in the automatic IP blocking. Therefore, after a number of failed login attempts, the user's IP will be automatically blocked for the duration you have set up. This will catch and block brute force attacks i.e. hackers trying different combinations of usernames and password against your site, in case they can guess a combination which lets them in.
WordPress 3.5 and later come with the XML-RPC services turned on by default, without any user controls to disable them. The XML-RPC services are used for remote control of your WordPress installation such as JetPack, the WordPress desktop and mobile apps, WP-CLI and remote blogging clients (think of something like Windows Live Writer or MarsEdit). They can also be extended by third party plugins to provide additional functionality which can be used to control aspects of your site remotely.
XML-RPC services have been long linked to security issues. They accept XML-formatted content which has its challenges with regards to parsing it in a safe manner. Moreover, there is a very common attack due to the very nature of the XML-RPC services which is still in use: password brute forcing. The XML-RPC services run much faster than your site, bypassing your theme and other parts of your site which take a long time to process. Moreover, they accept a plain text username and password. If the username and password combination is incorrect they quickly respond with an error. If it's correct they provide meaningful output. This is used by attackers to try tons of different passwords in an effort to guess the one you are using. This is called brute forcing. Since XML-RPC is really fast, bypasses any two factor authentication plugin you may have installed and most other kind of account protection they provide a viable and practical way to perform brute-forcing on your site. This attack is mostly dealt with by using the "Treat failed logins as security exceptions" feature explained above. However, if you do not absolutely need remote access to your site it's advisable to disable XML-RPC services altogether to close every small loophole which could be abused by an attacker to gain a foothold on your site.
Please note that activating this feature does NOT completely block access to the xmlrpc.php file on your site (the XML-RPC services endpoint). It does, however, cause it to always reply with error code 405 even if the username and password is correct. Since the XML-RPC services always fail without trying to parse the data sent in the request they can no longer be abused by attackers for any of the attacks which would otherwise be possible with the XML-RPC services enabled.
We need to clarify that XML-RPC services are not a security threat by themselves. They can be a security threat if you or any of your privileged users do not follow security best practices. If you are using only plugins with good quality code and the passwords of your privileged (Author and above) users are secure you are safe, within reason. Secure passwords in this context mean truly random passwords consisting of at least 32 characters which are a mix of lowercase and uppercase letters, digits and symbols. As a rule of thumb, if you can memorize the password and you do not have an eidetic memory then your password is not secure. Always use random, long passwords stored in a password manager application such as 1Password, KeePass, LastPass etc.
As a final point, no, just because you have an obscure blog with a handful of visitors per month does not mean hackers will leave you alone. Hackers typically take over sites to send spam, host malware or attack other high-value sites. The more obscure your site the least likely they are to get caught. Therefore your site's obscurity makes it a desirable target.
Enter one domain per line, without the at sign.
If a user tries to register an account with an email address that uses one of these email domains they will be blocked. This is useful to block free main services from certain countries which are commonly used by comment spammers.