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 WordPress.com.

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

security

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.

Would you like to write for WP Tavern? We are always accepting guest posts from the community and are looking for new contributors. Get in touch with us and let's discuss your ideas.

37 Comments


  1. So now there is brute force attacks functionality, there is a contact form functionality…

    Should I delete the brute force plugin I have, same for contact form? What is better for my site?

    Report


    1. If you have the older BruteProtect plugin activated, updating to the new Jetpack will deactivate it for you, as this module is a direct replacement for it.

      The new functionality is not active by default, and you’ll find a button to activate it on your dashboard if you so choose.

      Report


  2. Ok so I tried it. I like it. It would of been better if it told me the IPs from the attackers, maybe even the location (city & country). I like those stats.

    Report


    1. I’ve tried it and I’m totaly dissapointed. It is full of bugs and extremely slow.
      I’ll stick with GoodBye Captcha for now! It is 10 times better and faster! There are reports/stats like I’ve never seen in any other plugin.
      https://wordpress.org/plugins/goodbye-captcha/

      Report


  3. Will i have a statistic somewhere that shows how many and which IPs got blocked? Didn’t find anything in the wp backend.

    Report


    1. Hello,
      I was on the BruteProtect team and am now work on Jetpack. You can see the total attack account on the Jetpack Dashboard Widget, though we don’t display specific blocked IPs.

      Report


  4. 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!

    Report


  5. Can this module be used with custom login pages?

    Report


  6. Anyone else getting the white screen of death when upgrading to 3.4? Keeps happening and it’s definitely Jet Pack.

    Report


      1. Could you check your server error logs around the time when you experienced the white screen of death, to find out more about the error?

        If you don’t know how to access your server error logs, your hosting provider should be able to help.

        Send us the results via this contact form:
        http://jetpack.me/contact-support/

        Report


  7. I take it I no longer need to use the Limit Login Attempts plugin with this Brute Protect feature?

    Report


    1. Same question here. It looks like JetPack Protect doesn’t let you specify the number of logins to block before creating a permanent ban nor does it indicate how long that ban will last.

      Report


      1. 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. ?

        Report


      2. Actually, if you fail the check, it shows a CAPTCHA for you to solve before allowing you to login. You don’t just get locked out with no options, it just asks you to solve a math problem. Correctly solve the math problem and it will let you log in.

        Report


      3. You can also whitelist your IP address by navigating to WordPress.com>My Sites>Settings>Security. This is one of the nice advantages to moving to Jetpack and connecting to WordPress.com.

        Report


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

        Report


      5. 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?

        Report


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

    Report


  9. Does this jetpack module has some sort of api/functions/hooks that can be used to integrate it’s functionalities within a custom login form? I’m using wp_login_form() and i’ve also added ajax login to it, so i was wondering if there’s any way to hook into it?

    Report


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

    Report


  11. Hi Sarah, I don’t understand the whitelist function really. So what happens when you are under attack. Does Jetpack fully shut down all attempts to log in, accept the one from the whitelist?

    Report


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

      Report


      1. Hi Jeremy, wow, thanks a lot for your extensive explanation!

        Report


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

    Report


    1. A malicious login attempt is logged whenever someone tries to log in to your site and fails to provide correct log in details multiple times in a row.

      Report

Comments are closed.