ManageWP Backups Blocked by BPS Pro

Home Forums BulletProof Security Pro ManageWP Backups Blocked by BPS Pro

This topic contains 26 replies, has 2 voices, and was last updated by  AITpro Admin 1 week, 3 days ago.

Viewing 12 posts - 16 through 27 (of 27 total)
  • Author
    Posts
  • #38289

    Living Miracles
    Participant

    I tried my above code but the site reported a 403 Forbidden error on the front-end and was basically down—got an UptimeRobot notification too reporting the site was down. So, I guess the way I implemented the code isn’t correct. Awaiting further instructions from you 😉

    However, good to note: The ManageWP backup managed to complete with that code implemented. But of course, it’s no good, if the site is inaccessible for everyone except ManageWP.

    #38291

    AITpro Admin
    Keymaster

    I guess the best thing to do would be to remove the BPS POST Attack protection code and hope that ManageWP will be more willing to tell you how they are making a connection.  Seems like they feel that is some kind of breach of security to give you the exact URI they use.  Maybe it contains account info or other sensitive info.

    #38301

    Living Miracles
    Participant

    Thank you! I’ve written to ManageWP again to see if they can’t provide a more solid solution for us. They ended up sharing earlier that we should ideally whitelist all of their IPs in BPS Pro, but as far as I know BPS Pro doesn’t have that capability. So, I asked again if they can share the Query String they use to do their POST request during the backup process.

    It’s a pretty weird issue, because there isn’t an issue with the backups through ManageWP on all of our websites—it’s only affecting about 10 out of 45 (we have a LOT of websites!).

    I’ll let you know if they give me a Query String so that we can whitelist that. They shared with me that they’re talking to their developers to get us the right information.

    #38311

    Living Miracles
    Participant

    Hi there,

    I got an update from ManageWP about the backup issues. They wrote:

    I just got the word from our developers, we use wp-load.php?mwprid=* a unique key to access your website, from these IPs: https://managewp.com/<wbr />troubleshooting/general/<wbr />managewp-ips-can-white-list on standard port 80.

    As far as I can see I’ve already taken steps to allow ManageWP to make POST requests to this string, using this code:

    # Whitelist ManageWP POST Request to wp-load.php by Query String
    RewriteCond %{QUERY_STRING} !^mwprid=(.*) [NC]

    Is something not correct about that whitelist rule (from box 8 root .htaccess Custom Code)?

    Thank you!

    #38312

    AITpro Admin
    Keymaster

    Yep, you are correct that you already have a working whitelist rule and however you are staging your website(s) is the root cause of the problem.  It’s probably some weird routing or redirect problem with your staged site(s). So the best solution is just to remove the POST Attack Protection code until your site(s) are Live/completed.  Even better would be to develop future sites using XAMP. MAMP, WAMP, etc.

    #38313

    Living Miracles
    Participant

    Hi,

    Thanks, however, although this issue is occuring in some staging sites, it is also occuring on some of our production sites—on two different servers. Most of the sites are on SiteGround, however, one is located on a GoDaddy server.

    #38314

    Living Miracles
    Participant

    To clarify: This ticket is not just about staging sites (I do have another ticket at the moment that is all about staging sites).

    #38315

    AITpro Admin
    Keymaster

    You’ve heard me mention this a few times before…

    Intermittent problems or problems that start happening all of a sudden are typically going to be related to things like: php memory/cache/caching plugins/CDN’s/VPN’s/Proxy’s/Load Balancers/Host server problems (new security measures added on Host server (Mod Security, etc.), DNS server/DNS configuration problem, MySQL server timeout, server overloaded, etc.), /Browser problems (corrupt cache, Sessions, Cookies, add-on, extension)/ISP (connectivity)/CloudFlare, Incapsula, etc.

    It sounds more like whatever you are doing differently on the sites that have the problem occurring with ManageWP have something in common that is the root cause or related in some way to whatever is causing this problem. It could even be something with the ManageWP API server connection itself and not a problem on your end. I recommend that you remove the BPS POST Attack Protection bonus custom code. It is after all extra protection. Your sites are already securely protected by all of the other standard BPS Pro security measures/features.

    #38316

    Living Miracles
    Participant

    Ok, fair enough. Thank you! I’ve really appreciated all the support.

    One last thing I’d like to ask you about is something you brought up earlier in this ticket about some of our code in Box 8 actually needing to go into Box 14. This is the code:

    # WP AUTHOR ENUMERATION BOT PROBE PROTECTION
    # Rewrites to author=999999 that does not actually exist
    # which results in a standard 404 error. To the hacker bot
    # it appears that this author does not exist without giving
    # any clues that the author does actually exist.
    RewriteCond %{QUERY_STRING} ^author=([0-9]){1,}$ [NC]
    RewriteRule ^(.*)$ $1?author=999999 [L]

    I told my colleague about this, and he reminded me that, according to BPS Pro’s documentation, even the “POST REQUEST ATTACK PROTECTION” code is supposed to be in Box 14. He also reminded me that after some time of having the code in Box 14, we discovered that the Post Attack Protection code needed to go into Box 8 in order to work. When that happened, the findings were that, according to an exchange with one of your support staff via email, “something in WordPress had changed with internal WordPress Rewriting done in the WordPress database.” And it seemed to be affecting all RewriteRule code that was placed outside of the WordPress Rewrite loop. So, that applies to the WP Author Enumeration Bot Probe Protection code too. No one from BPS Pro ever specifically confirmed this at the time but, when we mentioned it, they did write: “…someone is going to check all other code to see if the same thing is now happening to any/all other Bonus custom code that should work as stand-alone code, but probably no longer works with WP 4.8.”

    So, I just wanted to bring this up, and see if you could shed some light on this for me! 🙂

    #38317

    AITpro Admin
    Keymaster

    Yeah I’m leaning more towards the origin of the problem being on the ManagWP API server’s end.  The reason for that is htaccess code/rules are all or nothing.  Either something is consistently blocked or it isn’t.  There isn’t anything about the htaccess security rules/code that would not be consistent since the htaccess rules/code are rules that your server follows.  Either they will work 100% of the time or 0% of the time – there is no in-between with htaccess code. 😉

    #38318

    Living Miracles
    Participant

    Right, that also makes sense to me and I will be responding back to ManageWP about why this issue doesn’t occur on all of our sites—at least consistently on all sites on either server we own.

    #38319

    AITpro Admin
    Keymaster

    Nope the WP AUTHOR ENUMERATION BOT PROBE PROTECTION bonus custom code is stand alone code that does need to be inside the WordPress Rewrite Loop.  The POST Attack Protection bonus code on the other hand definitely needs be inside the WP Rewrite Loop because a lot of plugins and themes ping the root site URI. So in order to create a whitelist rule for that type of Request you have to move the POST Attack Protection bonus custom code inside the WP rewrite loop.

Viewing 12 posts - 16 through 27 (of 27 total)

You must be logged in to reply to this topic.