Preventing Brute Force Attacks Against WordPress Websites

Originally published at: http://www.sitepoint.com/preventing-brute-force-attacks-against-wordpress-websites/

A ‘brute force’ login attack is a type of attack against a website to gain access to the site by guessing the username and password, over and over again. Other kinds of hacks rely on website vulnerabilities whereas a brute force attack is a simple hit and miss method and can be tried on any site.

In this tutorial, we will cover some methods and plugins we can use to prevent brute force attacks against WordPress sites. WordPress is the most popular CMS and therefore it’s a frequent target of these type of attacks.

What’s the Difference Between a Brute Force Attack and a DDoS Attack?

A brute force attack is performed to gain access to someone else’s account on the site, whereas a DDoS attack is usually launched to take a site down (typically by consuming resources). That said, a large scale brute force attack can also take a site down.

A DDoS attack is usually performed using a bot, whereas a brute force attack can be made using a bot or by a human. Humans can launch more targeted attacks, especially if they know usernames or have other intelligence to narrow down possible credentials.

Neither of these kinds of attacks rely on the website vulnerabilities and can be applied to any website.

WordPress doesn’t have any built in feature to prevent these two types of attacks. Therefore, it’s your responsibility to prevent them on your own sites.

This tutorial will show you how you can prevent brute force attacks.

Continue reading this article on SitePoint

They also haven't written in even the most basic protection against this type of attack leaving you having to use third-party addons and htaccess passwords to try to do their job for them. Having the user pick an admin page name on blog install, AYAH-type captcha after x login attempts, dynamically generated form input names after so many failures... etc. There's a lot Automattic could be doing to put a damper on the issue but aren't.

I've dealt with a lot of client's hosts that simply disallow WP installs because it's so completely incapable of slowing down the deluge of BF hits.

We will typically use apache config to block requests from all IP addresses except for ours. It's super easy to do, and our IP only changes once every few months. You can't brute force attack a login form that you can't access.

it worth reading this article. need a post about wordpress file permission demystification as lots of people confuse about that and its also an important security hole.

Thanks for the suggestion @arkaindas

We will have a article on that soon.

We've tried all the suggested methods in this article. Anything using a plugin usually ends up consuming too many resources and brings the site down (and sometimes the server if memory is exhausted by MySQL activity). In the end, we've protected all our sites in the same way as Oscar_Blank using htaccess rules blocking all IP requests except ours (fixed IP) and the customers (some are fixed IP). If the customer doesn't want this IP protection then we just refuse to host the WP website. Since we did that, we've had no more problems like this.

@GrahamS You are right. That's what I have mentioned in the article.

Blocking all IPs accept one i.e., admin's is possible if the admin has a static IP. Most WordPress users don't have that therefore I have mentioned many other ways of blocking attacks.

@narayanprusty, have you tried 2 step authentication like Google Authenticator for WordPress ( https://wordpress.org/plugins/wp-google-authenticator/)? I'm wondering would brute force attempts with this installed still consume memory and CPU. I'm assuming it would as Wordpress is still being served and it is not the server protecting the site.

@studioK You're right. It would consume memory and kill your site if brute force attack is made on large scale.

Sucuri's Website Firewall does a grand job of stopping both Brute Force and DDoS attacks against WordPress sites.

This topic was automatically closed 91 days after the last reply. New replies are no longer allowed.