Cidram: BunnyCDN's IPs blocking in IP Test results

[Dibbyo456]

CIDRAM v2.4.0. The issue is similar to #134

If I test a bunnycdn ip with user-agent of googlebot, then the ip is blocked. I know it's a fake google bot but shouldn't cidram ignore it because of bunnycdn_compat moudle?

[Maikuolan]

The block reason, "Suspected bot or scraper probe detected!", is specific to Macmathan's "Bot Or Browser User Agent Module (BOBUAM)". I haven't looked closely at its signatures since the past few updates, and there's quite a few in there, with most of the regex's covering a multitude of different user agents, compacted down, and many of them sharing the same block reason, so I'm not entirely sure offhandedly which specific signature is the culprit here. I'll need to take a careful look through them and break them apart a little to narrow it down, I think. I'll get back to you soon.

[Dibbyo456]

But that's not the point. When a $Bypass rule is exists, shouldn't be the highest priority?

[Maikuolan]

But that's not the point. When a $Bypass rule is exists, shouldn't be the highest priority?

Nope. Not quite how $Bypass works, unfortunately. :-/

Probably, what we really want here, is to perform a whitelist action, rather than a bypass action. But, in regards to the best way to approach this, there's an alternative solution possible: Just allowing users to decide the appropriate action for themselves. :-)

I've pushed an update to the BunnyCDN compatibility module just now (https://github.com/CIDRAM/CIDRAM-Extras/commit/35399197813b1bb3fe898fb92bd1d11b5881d60e) which adds (after updating to the current latest available version) a new configuration directive to the configuration page, bunnycdn➡positive_action:

Which action should CIDRAM perform when it encounters a request from BunnyCDN (i.e., for positive matches)? A bypass action deducts from the total signature count for the particular request (the total number of triggered bypasses is deducted from the total number of triggered signatures when calculating the signature count for a request, and if the signature count is less than one, the request won't be blocked). A bypass action is recommended in cases when you want the service to not be blocked by the main signature files, but want it to still be possible for requests from the service to be blocked by modules, auxiliary rules, etc. A greylist action clears all current block information for the particular request and sets the total signature count to zero, but it still remains possible for any subsequently triggered signatures (e.g., other modules, auxiliary rules, etc) to cause the particular request to be blocked. A whitelist action also clears all current block information for the particular request and sets the total signature count to zero, but unlike a greylist action, a whitelist action also terminates any further processing of modules, auxiliary rules, etc for the particular request, guaranteeing that it won't be blocked. A whitelist action is recommended in cases where preferences demand that the service must absolutely not be blocked, no matter the nature of the request, effectively disabling any and all protections that CIDRAM provides for requests orginating from the service. Search engine and social media verification won't occur for the particular request when a positive match is made, regardless of the configured action. Default action = Bypass.

Possible values:

• Bypass.
• Greylist.
• Whitelist.

Give that a try (updating, and then changing the default value from "bypass" to "whitelist") and let me know how it goes. :-)

[Maikuolan]

Hm.. The output generator seems to be terminating the process a little later in the execution chain than it should, which allows a few extra modules to execute before it kicks in. I'll get that sorted out now.

[Maikuolan]

..and done. :-)

[Dibbyo456]

Yup. Works now. Thank you so much.