Thread Starter
AITpro
(@aitpro)
Or maybe a better approach would be to create a separate Whitelist rule such as this and to add this above skip/bypass rule #12. This would logically allow full access to all website files from IP 107.22.153.142 and would skip to RewriteRule . /index.php [L] and skip/bypass all BPS security filters.
# Whitelist wpremote skip/bypass
RewriteCond %{REMOTE_ADDR} ^107.22.153.142
RewriteRule . - [S=13]
Thread Starter
AITpro
(@aitpro)
And i had a similar issue with another type of remote plugin and just adding a typical plugin skip/bypass rule worked fine so actually try this first.
# wpremote skip/bypass rule
RewriteCond %{REQUEST_URI} ^/wp-content/plugins/wpremote/ [NC]
RewriteRule . - [S=13]
Thread Starter
AITpro
(@aitpro)
Never mind this was a false alarm. 😉
This is not a new problem and is a very old issue. I got thrown off by several folks telling me this was a new problem and it is not. This is of course my fault for not checking that first. That was my first thought, but 3 people telling me this was a new issue got me going down the stupid road. 😉
here is the old solution >>> http://www.ait-pro.com/aitpro-blog/2252/bulletproof-security-plugin-support/checking-plugin-compatibility-with-bps-plugin-testing-to-do-list/#wpremote
Hi There,
I am the main developer of WP Remote, we have seen quite a few issues with WordPress Security plugins, recently we released an update which added some extra query params to a URL, specifically it seems it was blocking anything passing an array via get such as:
?excludes[]=foo&excludes[]=bar
WP Remote sends a request to the homepage, so whitelisting via REQUEST_URI to plugins/wpremote won’t do anything in this case.
We are certainly interested in plying to get compatibility with security plugins, but it seems to be somewhat of an uphill battle with lots of different plugins, and those plugins changing methods from version to version.
To get compatibility with BPS, what would you recommend we could do from WP Remote or the WP Remote WordPress Plugin to get things future proof?
For this specific error, I am reluctant to remove the use of arrays via GET requests, as a principle, GET supports this, and would be the ideal method for GETing data, if you follow me.
Maybe of worth not, the WP Remote requests will always include a query param: wpr_api_key, so if we could skip the .htaccess blocking based off that, it would help. Currently the IP of WP Remote is not guaranteed to stay the same.
Thread Starter
AITpro
(@aitpro)
We were posting at the same time. The issue was actually the same old issue with the square brackets in the Query String. Anyway i think i will be getting rid of the square brackets in that security filter. The amount of attack strings that actually use those particular code characters is almost nil and versus the headaches this filter causes it is time to modify it and ditch the square brackets altogether from that filter.
Ok cool, sounds good, if we also get a dedicated IP for the WP Remote server, would you consider whitelisting the IP from the BPS plugin, for possible future changes in out request to maintain compatibility?
THanks
Thread Starter
AITpro
(@aitpro)
Yep i am working on creating Master Whitelisting .htaccess code as we speak just in case this is ever needed in the future. Currently the way the BPS filters are integrated into the WordPress .htaccess rewrite loop it creates a sort of “override” condition that i have been meaning to dig into deeper. And in order to add protection beyond the root URL BPS must be integrated into that loop. 😉 Working on it.
I’m adding the root .htaccess with this..
# wpremote skip/bypass rule
RewriteCond %{REQUEST_URI} ^/wp-content/plugins/wpremote/ [NC]
RewriteRule . – [S=14]
# Whitelist wpremote skip/bypass
RewriteCond %{REMOTE_ADDR} ^107.22.153.142
RewriteRule . – [S=13]
above [s=12] “# Adminer MySQL management tool data populate”
but, it not solve the problem.
any workaround ? or i did not whitelist the plugin/ip correctly ?
Joe Hoyle, Thankyou! it’s working now!
Thread Starter
AITpro
(@aitpro)
Ok this is the direction we are going in which adds additional security protection to individual plugin folders, but also allows for Whitelisting those plugins. We will not be automatically populating the plugin folder names as this would undoubtedly result in complaints not smiles. This will be up to end user to make the decision of what plugins they want to protect or not protect. In any case this code has been tested and is working perfectly and also for you guys this creates Whitelist capability by either using HTTP_REFFERER or i imagine REMOTE_HOST would work fine as well – RewriteCond %{REMOTE_HOST} ^88\.77\.66\.55.
# BLOCK ALL REQUESTS/ACCESS TO BPS PLUGIN FILES AND OTHER PLUGIN FILES
# Whitelist AITpro.com - this is only for BPS Pro folks
# to continue to allow them to connect to the AITpro API Server.
# You can add additional plugins that you would like to protect by
# adding the plugin folder name as shown below.
# NOTE: Some plugins utilize an index.php file in their plugin folder
# that will negate the REQUEST_URI filter below.
RewriteCond %{THE_REQUEST} ^(GET|POST|PUT)
RewriteCond %{HTTP_REFERER} !^.*example.com.* [NC,OR]
RewriteCond %{HTTP_REFERER} !^.*ait-pro.com.*
RewriteCond %{REQUEST_URI} ^plugins/(bulletproof-security|example-plugin-name1|example-plugin-name2)/(.*)$ [NC]
RewriteRule ^(.*)$ - [F,L]
Thread Starter
AITpro
(@aitpro)
oops had this right the first time and changed it. 😉 RewriteCond %{REMOTE_HOST} !^88\.77\.66\.55.
Is “NOT” – not “IS” 😉
Thread Starter
AITpro
(@aitpro)
Thread Starter
AITpro
(@aitpro)
Square Brackets have been removed in all BPS .htaccess filters as of BPS .47.7 so this will no longer be an issue/problem for wpremote. Thank you.
