ManageWP Backups Blocked by BPS Pro

[Living Miracles]

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.

[AITpro Admin]

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.

[Living Miracles]

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.

[Living Miracles]

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!

[AITpro Admin]

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.

[Living Miracles]

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.

[Living Miracles]

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

[AITpro Admin]

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.

[Living Miracles]

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! 🙂

[AITpro Admin]

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

[Living Miracles]

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.

[AITpro Admin]

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.

[Living Miracles]

Hi,

I’ve been continuing to troubleshoot the issue we’re having with our sites no longer backing up via ManageWP. We ended up whitelisted ManageWP’s IPs in our server firewall, our databases, our CDN, as well as in the POST REQUEST ATTACK PROTECTION code like so:

# BPS POST REQUEST ATTACK PROTECTION
RewriteCond %{REQUEST_METHOD} POST [NC]
# Whitelist/Skip the ManageWP API server POST Request
RewriteCond %{REMOTE_ADDR} ^(54.191.137.17|34.211.180.66|54.70.65.107|34.210.224.7|52.41.5.108|52.35.72.129|35.162.254.253|52.11.12.231|52.11.29.70|52.11.54.161|52.24.142.159|52.25.191.255|52.27.181.126|52.34.126.117|52.34.254.47|52.35.82.99|52.36.28.80|52.38.106.97|52.39.177.152|52.41.230.148|52.41.237.12|52.42.126.166|52.43.13.71|52.43.76.224|52.88.96.110|52.89.155.51|54.148.73.118|54.186.37.105|54.187.92.57|54.191.32.65|54.191.67.23|54.191.80.119|54.191.135.209|54.191.136.176|54.191.148.85|54.191.149.8|52.26.122.21|52.24.187.29|52.89.85.107|54.186.128.167|54.191.40.136|52.24.62.11|52.88.119.122|54.191.148.225|54.191.151.18|52.89.94.121|52.25.116.116|52.88.215.225|54.186.143.184|52.88.197.180|52.27.171.126|52.11.12.231|34.211.178.241|52.11.29.70|52.24.232.158|52.26.187.210|52.35.82.99|52.36.28.80|52.42.189.119|54.186.244.128|54.71.54.102|34.210.35.214|34.213.77.188|34.218.121.176|52.10.190.191|52.10.225.96|52.11.187.168|52.25.139.76|52.43.127.200|54.191.108.9|54.70.201.228|44.225.177.160|34.223.186.249|44.224.135.238|44.226.111.14|44.225.203.104|44.226.100.122|44.224.250.144|44.225.118.211) [NC]
# NEVER COMMENT OUT THIS LINE OF CODE BELOW FOR ANY REASON
RewriteCond %{REQUEST_URI} !^.*/wp-admin/ [NC]
# NEVER COMMENT OUT THIS LINE OF CODE BELOW FOR ANY REASON
RewriteCond %{REQUEST_URI} !^.*/wp-cron.php [NC]
# NEVER COMMENT OUT THIS LINE OF CODE BELOW FOR ANY REASON
RewriteCond %{REQUEST_URI} !^.*/wp-login.php [NC]
# Whitelist the WordPress Theme Customizer
RewriteCond %{HTTP_REFERER} !^.*/wp-admin/customize.php [NC]
# Whitelist XML-RPC Pingbacks, JetPack and Remote Posting POST Requests
# RewriteCond %{REQUEST_URI} !^.*/xmlrpc.php [NC]
# Whitelist Network|Multisite Signup POST Form Requests
RewriteCond %{REQUEST_URI} !^.*/wp-signup.php [NC]
# Whitelist Network|Multisite Activate POST Form Requests
RewriteCond %{REQUEST_URI} !^.*/wp-activate.php [NC]
# Whitelist Trackback POST Requests
# RewriteCond %{REQUEST_URI} !^.*/wp-trackback.php [NC]
# Whitelist Comments POST Form Requests
RewriteCond %{REQUEST_URI} !^.*/wp-comments-post.php [NC]
# Whitelist ManageWP POST Request to wp-load.php by Query String
RewriteCond %{QUERY_STRING} !^mwprid=(.*) [NC]
RewriteRule ^(.*)$ - [F]

Even with all this in place, the backups continue not working.

At this point, the only way to get the backups to work again is to remove the # BPS POST REQUEST ATTACK PROTECTION from our sites. Can you tell us what, if any, negative implications it could have for our sites if we remove this code?

Thank you!
Jutta

[AITpro Admin]

The IP address whitelist rule is incorrect.  It should be IS NOT instead of IS.  Try adding an exclamation point ! in your whitelist rules as shown below.  Are you seeing any 403 errors logged in the BPS Security Log?  If MainWP is using JavaScript to do part of their remote backup then that would probably not be logged in the BPS Security Log.  If you remove the POST Attack Protection Bonus Custom Code then that just means any POST Request attacks against your site will not be blocked. Let’s say a POST attack against your website was successful and a file was uploaded to your hosting account – AutoRestore|Quarantine would kick in and quarantine that uploaded file.  So basically the POST Attack Protection Bonus Custom Code is an outer layer of website security.

# Whitelist/Skip the ManageWP API server POST Request
RewriteCond %{REMOTE_ADDR} !^(54.191.137.17|34.211.180.66|54.70.65.107|34.210.224.7|52.41.5.108|52.35.72.129|35.162.254.253|52.11.12.231|52.11.29.70|52.11.54.161|52.24.142.159|52.25.191.255|52.27.181.126|52.34.126.117|52.34.254.47|52.35.82.99|52.36.28.80|52.38.106.97|52.39.177.152|52.41.230.148|52.41.237.12|52.42.126.166|52.43.13.71|52.43.76.224|52.88.96.110|52.89.155.51|54.148.73.118|54.186.37.105|54.187.92.57|54.191.32.65|54.191.67.23|54.191.80.119|54.191.135.209|54.191.136.176|54.191.148.85|54.191.149.8|52.26.122.21|52.24.187.29|52.89.85.107|54.186.128.167|54.191.40.136|52.24.62.11|52.88.119.122|54.191.148.225|54.191.151.18|52.89.94.121|52.25.116.116|52.88.215.225|54.186.143.184|52.88.197.180|52.27.171.126|52.11.12.231|34.211.178.241|52.11.29.70|52.24.232.158|52.26.187.210|52.35.82.99|52.36.28.80|52.42.189.119|54.186.244.128|54.71.54.102|34.210.35.214|34.213.77.188|34.218.121.176|52.10.190.191|52.10.225.96|52.11.187.168|52.25.139.76|52.43.127.200|54.191.108.9|54.70.201.228|44.225.177.160|34.223.186.249|44.224.135.238|44.226.111.14|44.225.203.104|44.226.100.122|44.224.250.144|44.225.118.211) [NC]

[Author]

Posts