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.

Enter LiteSpeed.

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 wp-login.php and 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 WordPressProtect.

The directive

This directive may be used at the server level, the virtual host level, or the individual site level via .htaccess.

Usage: WordPressProtect [off|on|drop|deny|throttle, ] <limit>

Examples:

• 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.

The drop, deny, and 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.

The login <limit> is the maximum number of wp-login.php and xmlrpc.php login attempts allowed within 5 minutes before the desired action is taken. Possible values are integers between 5 and 1000.

Values higher than 1000 will be treated as 1000, and values lower than 5 will be treated as 5, with two exceptions:

• 0 is the same as off. It disables WordPress Protection.
• 1 is 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.

Examples

• Assume the limit is set to 10, and the preferred action is to drop.
• 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 deny.
• 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 all in .htaccess for 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.

WordPressProtect Logic

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 .htaccess level. This means that the server administrator’s virtual host setting will override the end user’s setting in .htaccess.

Additionally:

• No matter how the server level is set, the end user has the ability to enable or disable it through their .htaccess file. 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 .htaccess will 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:

Please take a look at our wiki for some concrete examples for setting up WordPressProtect in a cPanel environment.

Testing

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