Sam Hotchkiss

Hey Ari!

BruteProtect does protect against XML-RPC– we monitor and block login attempts there.

By the way, I’m really enjoying my Yubikey– thanks for the hook up ??

No, you will need individual API keys for each site, but they are free to obtain from within the plugin.

Did you send in the report from the debug page? We haven’t seen anything

The only reason I could see someone still being blocked after having their IP whitelisted would be from caching. Have you checked to make sure that caches are cleared?

Hi Abimelex– I completely appreciate your concern, however, we made a decision long ago to not regulate which sites may or may not use our plugin. Restricting who is and is not allowed to use our service becomes an extremely slippery slope.

At the end of the day, there are many sites that use BruteProtect that I do not personally agree with or condone (including some that I find to be downright awful), but I do strongly believe in individuals’ rights to free speech and to publish any content that they see fit. Part of the WordPress mission to democratize publishing is allowing everyone to have a voice, no matter what it is they have to say.

If you’d like to discuss this further, feel free to email me directly– sam at automattic dot com.

Yes, you are seeing things correctly, and you are protected!

Thanks,
Sam

Hi there–

First off, please refer to our most recent post on the subject:

https://bruteprotect.com/the-jetpack-bloat-myth/

Regarding forking BruteProtect– the plugin is GPL, and you’re welcome to fork it. Our server side code/algorithms are proprietary, so you would need to devise your own on that end. It’s worth noting, too, that running the server side of things isn’t cheap. We deal with millions of API calls a day, which is necessary to generate the amount of data necessary to provide good protection.

Hi There– BruteProtect has zero effect on your htaccess– if you block IPs in htaccess, they are blocked before they even get to the PHP layer.

If you’re looking at apache access logs, they’re going to show log in attempts that end up getting blocked by BruteProtect– I have checked to confirm and there is an active block against the IP you mentioned (167.114.42.112)

Thanks for using BP!

Hi Roy– this is interesting and not something we’ve seen before. I’d like to take a closer look at your server config– can you click the “Send Report” button? To get to it, click ‘Debug’ at the bottom of the BruteProtect configuration page in your WordPress dashboard.

Thanks!
Sam

Hey Tom!

Thanks for using BruteProtect! Some answers:

1) The only issue is that it prevents data on those IPs from being fed back into our DB– that said, if you’re seeing a high load from particular IPs, by all mean block away!

2) Nope, we run requests through our IP check at a couple different points to make sure your site never attempts to verify credentials from a blocked IP

3) There is none– everything happens automatically, your site is reporting that info back, and it gets processed through our algorithm.

4) Nope– this was an intentional decision focused around performance– there are hooks within BP so that you can add in your own logging if you’d like, but we don’t do anything out of the box, as we try to be very conscientious about our database interactions.

Happy holidays!

Makes sense to me, David– we have a new release coming today, I’ll make sure to get this in!

Hi Jeremy– Merry Christmas! Thanks for using BP and for your detailed report here!

I went through and spot checked the list of IPs that you provided, and all 10 that I checked were on our current block list, probably because they were contributed by your site! We don’t have any technical means to manually add IPs to our list, but they are cycling through all the time.

If you are seeing ongoing attacks from these IPs, then it could be useful to add them to your htaccess, but if the attack has subsided, it’s probably not worthwhile (and can have performance ramifications by adding this many IPs).

For additional tools to round out your security solution, I’d certainly recommend both iThemes Security (for closing up other potential holes in your armor) and Sucuri (for a premium firewall solution that will stop attacks before they even get to your server).

Good luck!

Best,
Sam

That’s not an issue that BruteProtect generates– sounds like a host generated error to me!

Hi Paul– unfortunately, this has exposed a deeper flaw in the way that WordPress handles site options in multisite installs. We’re working on developing a solution, but it’s not something that we can fix solely within BruteProtect at the moment.

Hi Ramon– we’re not yet sure what the attack vector is for the soaksoak attack– if they are gaining access via brute-forcing your site login, then yes, you would be protected, however, my first thought would be that this isn’t how they are gaining access.

Make sure to stay tuned to the news on the soaksoak front, once an attack vector has been found, it will be well publicized so that you can patch your site.

You can see more here:
https://blog.sucuri.net/2014/12/soaksoak-malware-compromises-100000-wordpress-websites.html