[Plugin: BulletProof Security] How to exclude a blocked user-agent?
-
How can I exclude a user-agent that is blocked by BPS-generated secure .htaccess file in a way that the exclusion will be kept after I regenerate the file in BPS?
We’re working to develop a mobile application for our website and it keeps getting blocked by the ‘python’ user-agent every time the .htaccess file is regenerated.
-
As of BPS .47.2 when you upgrade to a newer version of BPS, the upgrade will autoupdate your .htaccess files, but will not change any .htaccess code that you have modified or customized. So if you stay current with BPS Pro upgrades then you would not have to use AutoMagic again after upgrading BPS.
But if you are using AutoMagic for a new BPS installation on a new website or just using AutoMagic again on a site that already has BPS installed then the user-agent coding that blocks the python user-agent is standard BPS security code so either you would have to manually edit out python again or if you want to remove python from the user-agent filter in the BPS coding that creates your AutoMagic .htaccess code then that code is located on code lines 667 and 669 in the options.php file.
Also AutoMagic and Activating BulletProof Modes is intentionally broken into 2 steps for exactly this type of situation/scenario.
When you use AutoMagic a master .htaccess file is created that you can edit before activating it. You would edit the secure.htaccess file and make your modifications to that .htaccess file using the BPS built-in .htaccess editor and click on the secure.htaccess tab. Then go back to Security Modes and Activate BulletProof Mode for your Root folder.
Now if you are actually creating a python mobile app and you would like for me to create some sort of custom filter then i would need all the variables and query strings associated with the app so that i can make some sort of specific exception, but if it opens up a vulnerability that i feel is not safe in a general or mass way then i will not include it as a standard in BPS and will only provide that solution to you personally as a Custom Code solution.
Thanks for the reply. The intention is to not have BPS warnings displayed in WP-admin dashboard unless something unexpected has happened. Manually editing the .htaccess file had the result of triggering these warnings (as appropriate).
I’ll give a go to the editing of the master .htaccess file, and if it works, in other words, if that’s what BPS compares the active .htaccess file to before deciding whether to throw a warning or not, we’ll likely set up a cron script to periodically check the .htaccess and master file and modify them as warranted. This’ll let us see the BPS warnings if something unexpected happens, and doesn’t depend on plugin updates.
A less hackish solution would be if BPS offered the possibility to turn certain features on or off. There are several other user-agents, such as libwww-perl, that webmaster might want to enable temporarily or permanently. Having a GUI for this would be useful.
Thanks for the offer of creating a custom code snippet for us. The application is still under heavy development, so the query vars and so forth will change so fast that I don’t want to task you with this, at least until the main development effort is behind us.
The checks that will generate an Alert/Warning are these.
1. checks the version number of the .htaccess files you are using.
2. checks for this string “BPSQSE” in the .htaccess files. This string is inside the BEGIN WordPress to END WordPress coding so that if someone resaves permalinks settings then they will remove this string and also so that other plugins that add or modify the wordpress section of .htaccess code will also remove the “BPSQSE” string, which then indicates that your website is not actually protected because the BPS security filters have been removed or deleted.A less hackish solution would be if BPS offered the possibility to turn certain features on or off. There are several other user-agents, such as libwww-perl, that webmaster might want to enable temporarily or permanently. Having a GUI for this would be useful.
This approach was tried once and was quickly abandoned for this primary reason:
Once you start offering selectable options to folks who do not understand .htaccess code (completely understandable because most folks are not coders) then this creates a massive amount of questions and actually makes folks feel less secure and unsure about using BPS. What has worked much better is starting from the maximum website security settings with all options already pre-included and then having those folks who need to modify things do those modifications. Unfortunately, it is just one of those numbers things – 90% of folks will not need to modify anything and 10% will have to do some sort of modification or customization. 😉Since BPS has a built-in .htaccess editor I think the word you used – “hackish” is an incorrect word to use. Hacking a plugin implies that you have to edit the coding of a plugin (the php processing coding). And since BPS is intentionally designed to allow folks to edit or customize htaccess files with the built-in .htaccess editor then it is not really a plugin hack and is actually a procedural built-in feature/option. 😉
Thanks for the reply. With “hackish” I refer to that I don’t see a way to make the change update-safe. Each time I’ve updated BPS it has complained that the site doesn’t seem to be protected. After creating a new master .htaccess file and activating all the four deployment options below, the warnings have disappeared, but then it’s again time to go manually edit the .htaccess file. While that’s a lot better than having to edit the plugin code, anything that isn’t update-safe is something I’m hoping will change for the better one day 🙂
In addition to the .htaccess editor there could be an advanced settings screen. There’d be a short helper text saying “For expert users only. If you need to disable any of the included security measures below, uncheck its box from below, save the settings, create a new .htaccess master file and activate it.”
We might not be using it, though. For now we fixed our issue by manually defining a user agent in our mobile application.
The real question is why aren’t your htaccess files being automatically updated when you upgrade BPS?
What happens when you edit the version numbers in your root .htaccess file with the BPS built-in file editor to force check the autoupdate?
Change the version number to .47.3 in the 2 places shown below, refresh your Browser and then Refresh your Browser again. You should have seen the Dashboard alerts diplayed and then go away and the version number in your root htaccess file should have been changed to .47.4
# BULLETPROOF .47.3 >>>>>>> SECURE .HTACCESS
# If you edit the BULLETPROOF .47.3 >>>>>>> SECURE .HTACCESS text above
don’t take this the wrong way, but this would never work –
“For expert users only. If you need to disable any of the included security measures below, uncheck its box from below, save the settings, create a new .htaccess master file and activate it.”
Why? because everyone is an expert in their own eyes. LOL We did extensive testing and the problem is that when you give people choices about things they know nothing about then these things happen – they get worried, they feel uncomfortable, they make mistakes, they get pissed off, etc etc etc. 😉
What has been working very well is this:
Start from the pre-created/pre-made maximum security settings and then if someone needs to decrease their security (case by case) to allow some other plugin to do something then the formula already exists and they or we just use that simple formula to create a simple skip/bypass rule.Did the changes and got this in wp-admin:
…………….BPS Automatic htaccess File Update in Progress. Refresh Your Browser To Clear The BPS Alert.
—start Yellow box—
BPS Alert! Your site does not appear to be protected by BulletProof Security
…more text
—end yellow box—Refreshed, and it was gone. Earlier (when genuinely updating) refreshing didn’t help IIRC.
I think we will end up doing something like WordPress is doing now on upgrades – force page refreshes – instead of relying on the normal PHP code processing.
FYI – if i had it my way there would be a million option settings in BPS. I love options – the more the better, but apparently i am in the minority. 😉
I love convenience over configuration, in other words, the less need to change settings, the better. However, when something absolutely needs to be changed, changing it should be as convenient as possible. Second however, in the meanwhile all settings shouldn’t come in the way of day-to-day administration – and having a habit of seeing what all the available options are can be rather tedious when there are a lot of settings. However, after doing it once per plugin, all is well, and that same knowledge benefits the administration of all the sites we administer.
I’ll let you know what happens with the next update regarding the updating of .htaccess rules.
Yep most folks are convenience over configuration oriented. 😉 if i had my way there would realistically be around 50 new option settings in the public version of BPS like the private version (my personal version he he) of BPS has. 😉
Yep could not agree with you more that is why the Custom Code feature was added – so that custom coding could be saved permanently forever.
Then next came automatic updating of the .htaccess files when upgrading BPS. This means that only new security filters will be added and any custom code you have added will not be affected – basically means you install the upgrade and go about your business without having to do anything else. But yeah if you have first time/one time code additions to add then unfortunately that leaves adding them using the BPS built-in htaccess file editor.
Taking BPS to the next level would be detecting all plugins installed and then automatically adding the necessary skip/bypass rules for those plugins.
To date there are around 20-25 plugins (both free and premium) that require skip/bypass rules and there are a total of 21,597 WordPress plugins in the WP plugin Repository + Premium plugins so adding this detection for 20-25 plugins in BPS and automatically creating the skip/bypass rules would actually be a very simple, easy and realistic task. This has been noted and placed in review so once we have a chance to look at this from every possible angle and then the additional million other angles (LOL) hopefully we can set this motion if it is realistically feasible.
“Complexity is your enemy. Any fool can make something complicated. It is hard to make something simple.”
– Richard Branson.
Thumbs up for your development thoughts!
- The topic ‘[Plugin: BulletProof Security] How to exclude a blocked user-agent?’ is closed to new replies.
