Tech, Web, Work

Defending against WordPress brute-force attacks using built in features of IIS

Throughout the past week, a very large network of compromised computers has been pounding away at sites using the WordPress content management platform, attempting to access those sites by continually attempting logins using default WordPress usernames, along with a combination of passwords.

For these attacks to work, the attacking machines have to continually try various combinations of passwords, throwing request after request at your system, until they find a combination that works.

One of the best ways to defend against such an attack is to make sure that you’re not using default usernames.  Even if you’re doing that, though, it doesn’t prevent the attackers from throwing posts at your WordPress points of entry.  This forces WordPress to have to process these attempted logins before determining that the username is invalid.

While there’s no major security vulnerability, when attackers are throwing post after post at your installation, it can hamper performance dramatically.

There’s plenty of advice online for people who’ve installed WordPress using an Apache web server, but not as much for people using IIS. Fortunately, IIS has some features that can help mitigate the problem.

Dynamic IP Restrictions

A great first line of defense is available by installing the Dynamic IP Restrictions extension (link).

Once installed, you’ll can configure your site to deny requests from any IP address that is sending too many requests to your server too quickly, based on the criteria you define in the configuration.























Inbound Rewrite Rule

Another great idea is placing a rewrite rule on your wp-login.php file that checks for certain conditions prior to processing a user login.  When a bot attempts to login to your site using an automated routine, you will usually see a post of attempted credentials directly to your wp-login.php file.  This allows for rapid automation of multiple login attempts.

This looks different than someone actually visiting your WordPress admin, and clicking the “Login” button after supplying credentials.  Specifically, when a post is coming directly from a bot, the header sent along with the post will be usually be missing the HTTP_REFERER header.  Knowing this can help you construct a rewrite rule that will prevent these attempted logins from being processed.

In Features view, click on the “URL Rewrite” icon, and click “Add Rule” in the Actions pane on the right.

Give your rule a name, and in the Requested URL drop down, choose “Matches the Pattern”. Choose “Wildcard” under “Using”.

In the pattern box, enter *wp-login.php*.  This pattern allows you to also catch any redirects caused by someone visiting a site at the /wp-admin/ URL.

Under “Conditions” choose “Match All”, and add the following two conditions:

1. {HTTP_REFERER} Does Not Match the Pattern *wp-login.php*

2. {REQUEST_METHOD} Matches the Pattern POST

Under “Action”, choose “Abort Request”

This rule should catch any automated attempt to post directly to wp-login.php, and stop the request before WordPress actually attempts to process it, allowing for improved performance.


Leave a Reply

Your email address will not be published. Required fields are marked *

Connect with Facebook

12 − 4 =