Incapsula – Error: Your Whitelist rules have a /bulletproof-security/admin/js/ script whitelisted

[Living Miracles]

Hi,

Following up on this. I’m wondering if you have any input about this… I’m getting the same “Error: Your Whitelist rules have a /bulletproof-security/admin/js/ script whitelisted” error since BPS Pro 13 on 3 other sites, https://acim.biz, https://acim.me, and https://awakening-mind.org. Those are single WordPress installations on SiteGround Cloud Hosting and none of them user SiteLock/Incapsula. Why would those 3 sites also have this error? Any idea? All three also have the /bulletproof-security/405.php in the whitelist.

[AITpro Admin]

Lately I have been seeing a lot of bots (good and bad bots) making HEAD Requests directly to the 405.php Security Logging template file.  Why that is happening all of a sudden recently I am not really sure.  The only negative impact is the nuisance problem with AutoPilot Mode trying to create whitelist rules for these Security Log entries.  An additional filter was created for Plugin Firewall AutoPilot Mode to prevent AutoPilot Mode from trying to create whitelist rules for these types of Security Log entries.  This has already been completed/added in BPS Pro 13.2 (no eta yet).  You can just ignore this issue for now.

[Living Miracles]

Awesome! Thank you, that’s good to know! Is there an ETA for 13.2?

[AITpro Admin]

Oops the reason is listed in the Task completion explanation:  These 405 errors are occuring because of changes to the BPS HEAD Request htaccess code in 13.  So the additional new AutoPilotMode filter is basically nuisance prevention.  Nope, no ETA yet.  We are creating a new Malware Scanner, but may release 13.2 without that new scanner code.  It just depends on how quickly the Malware Scanner can be completed.  ie if it looks like the scanner will take more than 14 more days to complete than BPS Pro 13.2 will be released earlier and BPS Pro 13.3 will have the new scanner in it.

[Living Miracles]

Thank you!

[Living Miracles]

Hi,

I’d like to know if I should continue seeing massive amounts of 405 HEAD request entries in my security logs since the most recent BPS Pro update? I’m getting about 200 new 405 HEAD requests (mostly Uptime Robot) a day which means pretty frequent security log emails. The changelog notes seem to indicate that maybe I shouldn’t still be seeing this, but please correct me if I misunderstood this changelog note:

Revert Change: Root htaccess file|Custom Code: The R flag causes duplicate Security Log entries for 405 HEAD Requests made on some web hosts. Remove R from 405 HEAD Request RewriteRule in REQUEST METHODS FILTERED code block and other areas. Automatically fixed on BPS upgrade in Root htaccess file and Root Custom Code.

Thanks so much!

[AITpro Admin]

You would need to allow/not block HEAD Requests if you are using Uptime Robot.  See this forum topic for how to do that:  https://forum.ait-pro.com/forums/topic/split-uptimerobot-whitelist-uptimerobot-bot/#post-3578 The Revert change that was made is for duplicate 405 HEAD Requests being logged, which is a different thing.

[Living Miracles]

Thanks for clarifying. Could you point out in the below security log entry, what I would add to the # REQUEST METHODS FILTERED code?

[405 HEAD Request: June 27, 2017 - 10:59 am]
BPS Pro: 13
WP: 4.8
Event Code: BFHS-HEAD - HEAD Request Blocked
Solution: https://forum.ait-pro.com/forums/topic/security-log-event-codes/
REMOTE_ADDR: 69.162.124.236
Host Name: engine15.uptimerobot.com
SERVER_PROTOCOL: HTTP/1.1
HTTP_CLIENT_IP:
HTTP_FORWARDED:
HTTP_X_FORWARDED_FOR:
HTTP_X_CLUSTER_CLIENT_IP:
REQUEST_METHOD: HEAD
HTTP_REFERER: http://livingmiraclestv.org
REQUEST_URI: /
QUERY_STRING:
HTTP_USER_AGENT: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/31.0.1650.63 Safari/537.36

Thank you!

[AITpro Admin]

You would not be able to add any conditions since there are none available that you could use based on the Security Log entry. You would instead have to allow all HEAD Requests.

# REQUEST METHODS FILTERED
# If you want to allow HEAD Requests use BPS Custom Code and copy
# this entire REQUEST METHODS FILTERED section of code to this BPS Custom Code
# text box: CUSTOM CODE REQUEST METHODS FILTERED.
# See the CUSTOM CODE REQUEST METHODS FILTERED help text for additional steps.
RewriteCond %{REQUEST_METHOD} ^(TRACE|DELETE|TRACK|DEBUG) [NC]
RewriteRule ^(.*)$ - [F]
#RewriteCond %{REQUEST_METHOD} ^(HEAD) [NC]
#RewriteRule ^(.*)$ /wp-content/plugins/bulletproof-security/405.php [L]

[Living Miracles]

Hm, that seems to defeat the purpose of the HEAD request attack protection though, doesn’t it? It seems like most of the Uptime Robot request come from the same IP address. Is there any way to use the IP address in some way for whitelisting? Any other suggestions from you for decreasing the security log entries a bit is really appreciated!

Also, it seems like these large amounts of 405 HEAD request entries in our security logs didn’t show up until the BPS Pro 13/13.1 update. If you have any thoughts about that, I’d love to hear them.

We updated all our sites to BPS Pro 13 on June 27, 2017 and that day/the day after is when we started seeing all those 405 HEAD request entries in our security logs.

Thank you!

[AITpro Admin]

Blocking HEAD Requests it not a security protection thing.  It is a nuisance prevention thing.  You could try using a REMOTE_ADDR address condition, but that would only work if wpengine has dedicated uptimerobot servers that are making these requests.  Nothing is different or was changed in the way BPS Pro handles HEAD Requests in any versions of BPS Pro. The only thing that changed was the logging method, which was changed back to the old logging method that has been used for several years.

# REQUEST METHODS FILTERED
# If you want to allow HEAD Requests use BPS Custom Code and copy
# this entire REQUEST METHODS FILTERED section of code to this BPS Custom Code
# text box: CUSTOM CODE REQUEST METHODS FILTERED.
# See the CUSTOM CODE REQUEST METHODS FILTERED help text for additional steps.
RewriteCond %{REQUEST_METHOD} ^(TRACE|DELETE|TRACK|DEBUG) [NC]
RewriteRule ^(.*)$ - [F]
RewriteCond %{REQUEST_METHOD} ^(HEAD) [NC]
RewriteCond %{REMOTE_ADDR} !^69.162.[0-9]{1,3}.[0-9]{1,3}$
RewriteRule ^(.*)$ /wp-content/plugins/bulletproof-security/405.php [L]

[Living Miracles]

Thanks for explaining. So, you’re saying I’m simply seeing more entries because the logging process was changed “back to the old logging method that has been used for several years”? I.e., all those 405 HEAD request were being made all along, but now I see more entries because the logging method was changed? Just trying to wrap my mind around it 🙂

[AITpro Admin]

Nope, I’m saying nothing has changed about how BPS handles 405 HEAD Requests.  So that means whatever changed was something else and the timing is coincidental.  Most likely wpengine changed how they are making uptimerobot HEAD Requests.  That change on wpengine may have happened a long time ago and you are just now noticing it.

[Living Miracles]

Ah. Interesting. You keep mentioning “wpengine”. Could you tell me more about that? I’m not sure what that means or how that is relevant to my situation. Again, just want to get a better understanding. Please let me know if this exceeds your support.

[AITpro Admin]

If you have saved old HEAD Request custom code to BPS Custom Code then you would need to change the old code to the new code otherwise you would see the old duplicate HEAD Requests being logged.  Try the custom code I posted above and see if it works or not.  If it does not work then simply allow all HEAD Requests using the previous code that I posted for that.

I assumed this Hostname: engine15.uptimerobot.com was something wpengine is now doing, but if your host is not wpengine then this is something new that the Uptime Robot website is now doing.  Things change constantly…

[Author]

Posts