Running Setup Wizard after Installing New Plugins Is Blocking Crons

Home Forums BulletProof Security Pro Running Setup Wizard after Installing New Plugins Is Blocking Crons

Viewing 5 posts - 1 through 5 (of 5 total)
  • Author
    Posts
  • #38847
    Living Miracles
    Participant

    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 Miracles

    #38849
    AITpro Admin
    Keymaster

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

    #38855
    Living Miracles
    Participant

    Hello,

    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 Miracles

    #38856
    AITpro Admin
    Keymaster

    Yep, 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]
    #38858
    Living Miracles
    Participant

    That’s great, thank you for confirming that for us! This feels resolved for now.

    Take care,
    Living Miracles

Viewing 5 posts - 1 through 5 (of 5 total)
  • You must be logged in to reply to this topic.