Jetpack 3.4 Adds Protection Against Brute Force Attacks

Last August, Automattic acquired Parka, LLC, the makers of the BruteProtect security tool for WordPress, with the goal of integrating its features into Jetpack. The services provided in BruteProtect Pro were subsequently offered for free.

Jetpack 3.4 was released today with brute force protection available to users via a new module called Protect. You can find it under the Jetpack settings page or within your centralized dashboard on

Enabling protection against botnet attacks is as simple as checking a box:


The new module protects your login form from brute force attempts and allows you to scan your site for malicious code in Jetpack. It also allows you to manage a whitelist of IP addresses if you ever need to prevent Jetpack from blocking one.

At the bottom of your Jetpack stats summary, where you find the number of spam comments blocked by Akismet, you’ll also now see the number of blocked malicious login attempts.

As of February 2015, the BruteProtect plugin has defended over 225,000 sites from more than 350 million botnet attacks. The plan is to phase out the independent plugin by the end of 2015 in favor of maintaining its features via Jetpack.

Jetpack Protect is a truly compelling new addition to the plugin. Its inclusion means that millions of WordPress sites will now have free access to protection against brute force attacks, making a large portion of the web more secure.

With the addition of Protect, the plugin has grown to include 36 modules, which can be a bit overwhelming for new users. Jetpack 3.4 introduces a new “Jump Start” feature that will activate a curated set of modules to get you started. This release also includes a list of 43 enhancements and 11 bug fixes, which you can view on the plugin’s changelog.


37 responses to “Jetpack 3.4 Adds Protection Against Brute Force Attacks”

  1. OK so question, I have my admin password protected so you need to enter a login name and password just to get to the admin login… will jetpack still be able to protect my login from brute force?

    Also I block all IP’s excepts those I whitelist in my htaccess file, which is a pain bc/ most IP’s myself and clients work from are dynamic and change. I would assume with the new brute force protection it is ok to stop this practice?

    Not understanding the new Whitelist IP box, why would I ever need to whitelist my IP? and how the heck can I whitelist it if there is an issue and I can’t even get to the login page? Thanks!

      • Noticed that myself. Kind of scary that if you have a false positive that you would have to deactivate the entire suite of plugins within JetPack to be able to access your site. Not sure if I’m sold yet. No to mention, if you somehow blocked your own IP there’s really no way to enter it into the approved list once it is blocked. ?

      • Dan, it doesn’t allow you to specify how many logins before a block because that’s not how it works.

        The idea isn’t to block based on how many times they try to log into your site, but based on them logging into *everybody’s* sites. For every login attempt performed, the IP is sent back to a central service. That service analyses the pattern as a whole, and blocks accordingly.

        These mass login attempts come from botnets. And while each individual computer on some big bot net may try to log into your particular site only once or twice, it will still go and try to log into other sites all around the world. When this starts happening, that mass pattern of failed logins coming from the IPs of the botnet machines can be seen by the service, and it can then take steps to block them on all the rest quickly, frustrating the effort of the botnet.

        Think of it like Limit Login Attempts, but with the login attempt info shared amongst all participants. Some will still get hit, but once the service as a whole determines that it’s a bot, then it can block it amongst all the rest immediately.

        • Thanks, that makes sense. I was thinking more about IPs that haven’t been seen before and how they’re handled once identified — are they permanently blocked, blocked for a certain time period, or blocked until someone passes a CAPTCHA? If an IP gets on the ban list, what are the conditions for its removal?

  2. Jetpack does it again..
    “The following new modules have been activated..”

    This is might be a good thing for some users, perhaps even the majority of Jetpack users, and judging by Samuel’s explanation above it certainly sounds like a clever approach to the problem. But personally I’d appreciate if a plugin asked me before changing the settings on my site.

    At the very least check if there is another Brute Force Protect plugin around, which there are in many cases.

  3. I read the thread fairly thoroughly, generally pleased to see this functionality in JetPack, but I need to know if the brute force protection is likely to cause any issues with an existing installation of the latest BPS login protection. This seems to be a simple limit on the number of attempts, so my guess is that it should be OK with the JP approach.

    • So what happens when you are under attack.

      In my experience, you’re almost always under attack. If your WordPress site is public, some folks will be trying to log in.

      Jetpack Protect doesn’t have different modes, it always protects your site, as long as the module is active.

      Jetpack will only block IPs that failed to log in multiple times. If one provides the right username / password combination, they’ll be able to get in, as long as they didn’t fail to provide the right credentials multiple times in a row before that.

      The whitelist is only there to allow some IPs to never be considered as malicious on your own site. If you never remember your password on your own site and usually have to try a lot of username/password combinations before to be able to get in, then the whitelist is for you!

      The whitelist is also useful when you always access your site from the same IP. It allows you to make sure that you’ll never be blocked by mistake.

  4. How does the Protect module define “malicious login attempts”? I see the module reporting on my dashboard that several attempts have been blocked, but I do not see any login attempts in my server’s logfiles.


Subscribe Via Email

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

%d bloggers like this: