WpW: Brute Force Attack Protection
Welcome to another installment of WordPress Wednesday!
Today’s Topic: Brute Force Attack Protection for WordPress
Disclaimer: The information contained in this post is accurate for LSWS v5.2.3 [release log]. If you are using a newer version of LiteSpeed Enterprise, some details may have changed. Please refer to our wiki for the latest!
This week we are going to talk about brute force login attacks, and what you, as a site admin or hosting provider, can do to protect your WordPress site(s). Usually our WPW posts involve our popular cache plugin, but this week it’s all about the web server. You don’t need to be running LSCache for WordPress in order to benefit from LiteSpeed’s WordPress Protection. You only need a LiteSpeed Enterprise server or LiteSpeed Web ADC.
What is a Brute Force Login Attack?
During a brute force login attack, the attacker attempts to gain access to a website by repeatedly trying to guess a valid username and password. WordPress, being the most popular CMS, often finds itself the target of such shenanigans, and without any built-in protection, a third-party solution is needed.
Starting with version 5.2.3, LSWS has a built-in WordPress protection system. It covers shared hosting WordPress environments against large-scale brute force attacks. Such attacks usually target the
xmlrpc.php pages via POST, and have the potential to bring down entire servers!
How Brute Force Protection Works
So how, exactly, does LiteSpeed protect your WordPress sites? We’ve got you covered through a new directive known as
This directive may be used at the server level, the virtual host level, or the individual site level via
WordPressProtect [off|on|drop|deny|throttle, ] <limit>
WordPressProtect drop, 10– drop the connection after 10 login attempts.
WordPressProtect throttle, 20– throttle the connection after 20 login attempts.
WordPressProtect 12– after 12 login attempts, take the preferred action.
throttle parameters configure how the server is to react when the login limit is reached. By default, the connection will be throttled, however you may choose to drop the connection directly without any reply, or to deny the connection with a 403 response.
<limit> is the maximum number of
xmlrpc.php login attempts allowed within 5 minutes before the desired action is taken. Possible values are integers between
Values higher than 1000 will be treated as
1000, and values lower than 5 will be treated as
5, with two exceptions:
0is the same as
off. It disables WordPress Protection.
1is used at the virtual-host level to indicate that the server-level setting should be honored.
The quota system
The login limit is used to drive a quota system as follows:
- The quota starts at the specified login limit.
- Each POST attempt decreases the quota by 1
- Once the quota reaches half of the limit, the IP will be throttled, slowing more as the quota drops further.
- When the quota reaches 0, the IP is either throttled, denied, or dropped according to the settings.
A blocked IP, given time or a restart, may be redeemed:
- Over the course of 5 minutes without further POST attempts, the quota gradually increases back to the set limit.
- Restarting LiteSpeed Web Server will reset the quota back to the specified login limit.
- Assume the limit is set to
10, and the preferred action is to
- After the first POST attempt, the quota is decreased to 9.
- When there are more than 5 attempts within a short period of time, the IP will be throttled.
- Once the quota reaches 0, the client will be dropped.
- Every 30 seconds, if there are no further POST attempts, the quota will increase by 1. (Why 30 seconds? 5 minutes divided by 10 [the limit] = 30 seconds)
- Assume the limit is set to
300, and the preferred action is to
- After the first POST attempt, the quota is decreased to 299.
- When there are more than 150 attempts within a short period of time, the IP will be throttled.
- Once the quota reaches 0, the client will be denied with a 403 response from the server.
- Every second, if there are no further POST attempts, the quota will increase by 1. (Why every second? 5 minutes divided by 300 [the limit] = 1 second)
Why Use LiteSpeed’s WordPressProtect?
Security-conscious site admins have been protecting themselves with various WordPress plugins since the first time somebody got hacked. And while plugins have their place, nothing beats the speed and efficiency of stopping attackers at the server level.
To that end, some use the
mod_security WAF, but it can be slow. LiteSpeed’s WordPressProtect feature is fast.
There are a few scenarios where WordPressProtect will not activate:
- If you are using
deny from allin
.htaccessfor your WP login page, a 403 is immediately returned when access to that page is attempted. WordPressProtect is not necessary when all visitors are denied an opportunity for login.
- Some security plugins employ a tactic of renaming the login page to something that is less easily guessed by potential attackers. If your login page is named something other than
wp-login.php, WordPressProtect will not know about it, and the feature will not activate.
- If the user’s IP is on the trusted list, WordPressProtect will not block or throttle that IP.
Since you can set up WordPressProtect at a few different levels, it’s a good idea to understand how these settings relate to each other, and which ones take precedence over which other ones.
WordPressProtect is enabled by default at the server level with login limit 10 in LiteSpeed Web Server v5.2.3 and above. (It is disabled by default in LiteSpeed Web ADC.)
If you want to change anything, keep these facts in mind:
- Changing the settings at the Apache-server-level configuration will override the setting for any Apache-based virtual host, but will have no impact on LSWS-native virtual hosts, which can only be controlled by LSWS-native settings.
- Changing the settings at the Apache-virtual-host level configuration will override the server-level configuration as well as the
.htaccesslevel. This means that the server administrator’s virtual host setting will override the end user’s setting in
- No matter how the server level is set, the end user has the ability to enable or disable it through their
.htaccessfile. In other words, user level overrides server level.
- However, the end user’s preference does not override the virtual host level, if any setting is specified at that level. This means that if the feature is disabled in the virtual-host-level include file, then any directives in
.htaccesswill be ignored.
Here’s a handy chart that will help you visualize the priority rules. Assume A, B, and C refer to different WordPressProtect directives:
|A||not set||not set||A|
Please take a look at our wiki for some concrete examples for setting up WordPressProtect in a cPanel environment.
We ran a test with
WordPressProtect set to
drop, 10, and these are the results:
Round: 1 Fail 0.626 Round: 2 Fail 0.615 Round: 3 Fail 0.605 Round: 4 Fail 0.581 Round: 5 Fail 0.595 Round: 6 Fail 1.619 Round: 7 Fail 2.615 Round: 8 Fail 3.611 Round: 9 Fail 4.602 Round: 10 Fail 5.604 Round: 11 Erro MSG: ('Connection aborted.', RemoteDisconnected('Remote end closed connection without response',))
You can see that the server is responding fairly quickly for each login attempt until the sixth. At that point, the quota has surpassed the halfway point of the login limit, and so the server is starting to throttle its responses. Each attempt after that gets an even slower response. At the 10th attempt, the quota reaches 0. The server won’t even talk to us for attempt #11.
We’re locked out until we’ve behaved ourselves for a long enough period of time to regenerate our quota.
As you can see, this new tool will protect your WordPress sites from relentless login attempts, and the potential drain on your server that such attacks can cause. And of course, the fewer login attempts that are allowed, the less likely the attackers will actually have time to guess a valid login and password combination!
Upgrade to LiteSpeed Enterprise 5.2.3 today and all of your WordPress installations are automatically protected.
Have some of your own ideas for future WordPress Wednesday topics? Leave us a comment!
Don’t forget to meet us back here next week for the next installment. In the meantime, here are a few other things you can do:
- Subscribe to the WordPress Wednesday RSS feed
- Download LiteSpeed Cache for WordPress plugin
- Learn more about the plugin on our website