Home › Forums › BulletProof Security Pro › Running Setup Wizard after Installing New Plugins Is Blocking Crons
- This topic has 4 replies, 2 voices, and was last updated 4 years ago by Living Miracles.
-
AuthorPosts
-
Living MiraclesParticipant
Hello,
We’ve recently installed a few new plugins to one of our sites and after doing so, there was a notification at the top of the page in the back-end from BPS Pro that said:
BPS Setup Wizard AutoFix (AutoWhitelist|AutoSetup|AutoCleanup) Notice
One or more of your plugins or your theme requires a BPS Custom Code whitelist rule to be automatically created by the Setup Wizard.So we went ahead with running the setup wizard. However, we just noticed that since running the wizard that we’ve been getting entries like the following in our Security Log of the Cron job getting blocked each time it tried to run:
[403 GET Request:] BPS Pro: 14.4 WP: 5.3.2 Event Code: BFHS - Blocked/Forbidden Hacker or Spammer Solution: N/A - Hacker/Spammer Blocked/Forbidden REMOTE_ADDR: Server_IP_Address Host Name: Server_Host_Name SERVER_PROTOCOL: HTTP/1.0 HTTP_CLIENT_IP: HTTP_FORWARDED: HTTP_X_FORWARDED_FOR: HTTP_X_CLUSTER_CLIENT_IP: REQUEST_METHOD: GET HTTP_REFERER: REQUEST_URI: /wp-cron.php?doing_wp_cron QUERY_STRING: doing_wp_cron HTTP_USER_AGENT: Wget/1.16.3 (linux-gnu)
Seeing that our Crons are getting blocked, I just wanted to double-check whether ARQ was still functioning or not. I can now confirm that it isn’t at the moment.
We also noticed that code in Custom Code > Root htaccess File Custom Code > CUSTOM CODE BPSQSE BPS QUERY STRING EXPLOITS > RewriteCond %{HTTP_USER_AGENT} area was changed to the following:
RewriteCond %{HTTP_USER_AGENT} (havij|libwww-perl|wget|python|nikto|curl|scan|winhttp|clshttp|loader) [NC,OR] RewriteCond %{HTTP_USER_AGENT} (%0A|%0D|%27|%3C|%3E|%00) [NC,OR] RewriteCond %{HTTP_USER_AGENT} (;|<|>|'|"|\)|\(|%0A|%0D|%22|%27|%28|%3C|%3E|%00).*(libwww-perl|wget|python|nikto|curl|scan|winhttp|HTTrack|clshttp|archiver|loader|email|harvest|extract|grab|miner) [NC,OR]
This area of the code normally looks like the following for the rest of our sites in the same hosting environment:
RewriteCond %{HTTP_USER_AGENT} (havij|libwww-perl|python|nikto|curl|scan|java|winhttp|clshttp|loader) [NC,OR] RewriteCond %{HTTP_USER_AGENT} (%0A|%0D|%27|%3C|%3E|%00) [NC,OR] RewriteCond %{HTTP_USER_AGENT} (;|<|>|'|"|\)|\(|%0A|%0D|%22|%27|%28|%3C|%3E|%00).*(libwww-perl|python|nikto|curl|scan|java|winhttp|HTTrack|clshttp|archiver|loader|email|harvest|extract|grab|miner) [NC,OR]
We have tried manually adding what would be the more “standard” code to that area but then after saving and activating the code, we get the BPS Pro notice again and if we run the setup wizard it changes the code in that area again.
Having ARQ not work properly right now due to the Crons getting blocked feels like our biggest concern due to that security risk. So, ideally, we would like to find a simple solution to having the Crons not get blocked/to have ARQ properly work, making sure our new plugins still function correctly, having the setup wizard not change that code in the “CUSTOM CODE BPSQSE BPS QUERY STRING EXPLOITS” box each time where we would then need to manually change it afterward, and, lastly, to not have that notice keep showing up.
Can you suggest or share anything with the information provided to help us resolve this issue?
Thank you and looking forward to your response,
Living MiraclesAITpro AdminKeymasterHmm not sure why Setup Wizard AutoFix is changing that nuisance rule. I’ll look into why that is happening when I get some spare time. It’s not really a security rule and is intended to block general probes and scans. That nuisance rule can be safely commented out.
Try doing these steps and let me know if that takes care of the problem.
1. Go to the BPS Custom Code Query String Exploits Custom Code text box.
2. Comment out the nuisance rule by adding a # sign in front of that nuisance rule as shown below. And also delete the wget condition.#RewriteCond %{HTTP_USER_AGENT} (havij|libwww-perl|python|nikto|curl|scan|winhttp|clshttp|loader) [NC,OR]
3. Click the Save Root Custom Code button.
4. Run the Setup Wizard again and let me know what happens.Living MiraclesParticipantHello,
Thank you for your response and for the steps you provided! We followed through with them yesterday and we believe it may have solved our issues from what we can tell at this point! After saving and activating the code and then running the setup wizard, our plugins were still functioning properly, there weren’t any more entries in the Security Log of Crons getting blocked, and that BPS Pro notice didn’t show up again.
One thing to mention, however, was that after running the setup wizard, the “nuisance rule” reverted back slightly and repopulated the “wget” condition:
#RewriteCond %{HTTP_USER_AGENT} (havij|libwww-perl|wget|python|nikto|curl|scan|winhttp|clshttp|loader) [NC,OR]
So our question at this point would be, is commenting out or even removing (if that’s possible) this “nuisance rule” a security risk/concern?
Thank you,
Living MiraclesAITpro AdminKeymasterYep, thought that the wget condition might be added again, but since the nuisance rule is commented out then that is a moot point. 😉 Nope, that particular rule is not a security rule or security risk. It is simply a rule that blocks general nuisance scans and probes. This rule below could be considered more of a security rule and does block malicious scraping, harvesting and scanning.
RewriteCond %{HTTP_USER_AGENT} (;|<|>|'|"|\)|\(|%0A|%0D|%22|%27|%28|%3C|%3E|%00).*(libwww-perl|python|nikto|curl|scan|java|winhttp|HTTrack|clshttp|archiver|loader|email|harvest|extract|grab|miner) [NC,OR]
Living MiraclesParticipantThat’s great, thank you for confirming that for us! This feels resolved for now.
Take care,
Living Miracles -
AuthorPosts
- You must be logged in to reply to this topic.