BruteProtect – Protecting Against Brute Force Attacks

Brute Protect LogoI recently received a hat tip from a happy user of the BruteProtect plugin and decided to give it a try myself. The only configuration that is necessary for BruteProtect is to apply a free API key to communicate with the service. If you’re using the Limit Login Attempts plugin to block unsuccessful login attempts, you’ll need to disable it as there is no need to run both plugins. The idea behind BruteProtect is very similar to how Akismet operates. I got in touch with Sam Hotchkiss, one of the lead developers behind the plugin/service to describe how it works.

BruteProtect is sort of like Akismet, but for your WP login– we track failed logins across a large number of WordPress sites, then analyze that data to find patterns and identify attack bots.  The larger our installed base, the more data we have to work with– this results in more complete protection for site owners and fewer false positives.  To date, we’ve blocked over 1.3 million malicious login attempts from over 131,000 IP addresses.


The more people that use BruteProtect, the better protected its users are. The blocking and logging happens behind the scenes. However, there is a new dashboard widget that is created that shows off the number of blocked login attempts and just within the time span of writing this review, it’s blocked 72 of them. Sam has told me that they are working on big updates that will be available shortly.

BruteProtect comes from the same folks that are behind QuickForget gives you a secure way to send passwords, credit card numbers, SSNs, etc.


18 responses to “BruteProtect – Protecting Against Brute Force Attacks”

  1. Wow. I *REALLY* wish I would have known about this plugin a few weeks ago. We manage many blogs for many clients and while we have never lost a site (yet), some brute force hackers have been having a heyday on a couple of our sites…one in particular they have become extra fond of (I have no idea why, it’s nothing special, primarily a lead generation site).

    I use the WP Better Security plugin along with a visual captcha (and a couple .htaccess hacks of my own). The plugin is set to ban the IP after just 2 failed login attempts. So far it has blocked over 5,000 separate individual login attempts in less than 2 weeks (and the list is still growing as I type this). The plugin simply reports a “418” denial error to visitors of blocked IP’s and nothing further is logged in the admin area. They’ve been HAMMERING on this site for days and days, non-stop. Our server access logs are endless with thousands and thousands of “418” denial errors to IP’s trying to post to /wp-login.php …the site is still holding strong.

    There is an up-side to this…
    The up-side is I’ve now accumulated the list of IP’s for an elaborate global BOT-net. How wonderful it would be to the world if this IP list had been added to the BruteProtect data.

    Maybe there’s a way I can still make that happen.
    Thanks for sharing.

  2. This seems like a useful tool, however protecting from brute force logins is (in my experience) only a matter of setting uncommon login and password, the bots seem to be playing numbers game, they are trying most common login/password combinations on as many sites as possible.

  3. @Mike

    Your description of this pattern of activity sounds a lot like the recent high-profile reports of a large-scale bot-net attack on WordPress servers.

    These attacks are looking for WordPress sites that use ‘lazy’ usernames and passwords for their login. They just go down a list of common ‘stupid’ login words, trying them one after another, brute-force fashion.

    If they succeed, then they quietly go about infiltrating the server, and discretely integrate it into their bot-net. They may well do “nothing” with the newly-acquired zombie, right away.

    In the case of a related network of websites & servers, be aware that a standard tactic will be to continue to noisily hammer one site or server, after a different one has already been successfully compromised.

    The idea in this is, to keep Admin’s attention on the ongoing attack, and off the other server-logs …. where it might upon closer examination be noticed that weird things were or are going on.

    Logs for other sites should be examining, for a pattern of attempts that went on for awhile, but then stopped. Attempts that stop, may indicate success.

    There are now resources to scan servers for the embedded malware.

    (It is part of the ‘MO’ of these bad guys, that you don’t “lose” a site … that done right, you don’t notice anything. That’s exactly the intent.)

  4. I’ve read about the brute force attacks and understood, from the official write-ups, that it is no great problem. No lazy passwords with me!

    Even so, I’ve installed this plug-in and see that there have been attempts against my blog, none of which have been successful.

    Perhaps this plug-in needs a little more publicity, just writing that there is a problem – as others have done – and playing it down is not the answer. Defense is much better!

  5. Sorry, but against distributed brute force attacks this plugin is quite useless. We had exactly this kind of attack starting last April.

    So if you’re not a single user on your blog and if you therefore cannot protect yourself by BASIC AUTH and .htaccess (what I consider the most effective way), you will be able then to use e.g. the SI CAPTCHA Anti-Spam Plugin on your login form and you’ll be rather safe with even weaker login data of all your users.

  6. This plugin is designed exactly for the purpose of tracking and blocking distributed attacks. The plugin works by tracking invalid login attempts by ip’s across the entire network of sites using the plugin. Once an IP passes a preset threshold, it is then blocked from attempting logins on all of the sites that are part of the network.

    The stats say it all!

    BruteProtect has stopped 1,729 malicious attempts to access

    2,035 Sites Protected
    138,184 Bots (IP addresses) Blocked
    1,350,297 Attacks Thwarted
    39,955 Thwarted Today

  7. @bl968

    This plugin is designed exactly for the purpose of tracking and blocking distributed attacks.

    BruteProtect sounds like a good tool that the greater community can collectively get behind, to gradually erode the recent bot-net outbreak. It strikes me as a good investment.

    But my understanding of this kind of distributed IP-collection and blocking, is that it does not immediately confer ‘positive’ protection on sites using the service. With 90,000 or more bots in the attacking network, attacks on particular sites can continue, and the general menace, though steadily losing IPs to BruteProtect, continues to be a threat.

    I am concerned that some are getting the impression that BruteProtect actually stops the attack-pattern, and eliminates the hazard, as soon as it’s deployed. If I understand correctly, that is really not how this kind of response works at all.

    A good analogy for this service might be the community mosquito control programs that are launched in some places, to reduce the blood-sucker population that is spreading some infection. Drain unused swimming pools. Turn buckets upside down. Spray swampy areas, etc. Gradually, a heavy load of mosquitoes is reduced; the numbers of bites fall, and with that the number of people coming down with the disease declines.

    But being part of the mosquito-suppression campaign does not confer any “positive” protection from mosquito bites on any of us, individually. Nor are we in any way guaranteed that if we are bitten, we will not get sick, since we now have a good, responsible control-program up & working.

    To be really protected from ‘skeeters, we need to wear long-handled clothes, DEET, and possibly even netting. To provide ourselves with similarly direct, immediate, solid protection from the brute-force bot, we have to find those ‘lazy’ usernames & passwords, and get them changed to decent versions.

    The bots are still buzzing around, looking for a blood-meal, even with BruteProtect working on eventual control. And like with mosquitoes, all we will ever really have, is that “degree” of control that we’ve worked to establish. Both the insects and the bots will still be out there, just not as thick.

  8. The service has blocked 1,350,297 attacks from 138,184 ip addresses.

    With single site methods the hackers get to attack every new site they target with the same bots, and each site has to build up their own individual block lists.

    With Brute Protect once a bot is blocked from one site, it’s blocked from all sites using the service.

    With each additional wordpress installation using the service, it becomes harder and harder for the botnets to be able to attack new sites.

    Is this the only step you should take to protect your wordpress installations, no of course not; but it is certainly one of the first.

  9. @Jason Trommetter – Two-factor authentication is great, but in some ways it solves a different problem.

    Yes, there are brute force attacks trying to break into existing accounts, but many I see are attempts at registering new accounts to post spam comments.

    Plus, some of us run sites with many users where it would not be practical to force other means of authentication. For example, I have one site that uses bbPress for forums with thousands of non-technical users. bbPress accounts are just regular WordPress users. I do use two-factor authentication to protect my admin account, but that won’t help with the masses with their logins. And those regular accounts do get attacked sometimes.

  10. What most people don’t understand is that the main issue that most of us are seeing is not that our sites are getting hacked or that we’re in danger of them guessing our password. The issue is that there are 1,000+ login attempts in a couple of minutes. This crashes many servers with it accessing PHP and MySQL. All of the plugins that need to access PHP and MySQL to “check” an IP or perform any operation on the database doesn’t help against this.

    Does anyone know if this plugin has to check the database or use PHP in order to check the IP blacklist?

  11. @Jared – Hi Jared– we do store the IPs as transients in the DB, yes.

    Once BP checks the API to see if an IP is blocked, it then caches those results until the block expires, so you’re not not calling out to our API every time wp-login.php is loaded.

    For what it’s worth, the IP check code is very lightweight, and, while we do access the DB, loading wp-login.php while blocked should be significantly lighter than loading a normal site page. We have no loop, no images, no bloat, just a single DB call. All told, that log in logic is under 40 lines of PHP

    Sam Hotchkiss
    Lead Developer


Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.

%d bloggers like this: