Cidram: Please explain "Signatures Reference: functions.php"

[eurobank]

I have only TOR block active and nothing else (for now). I see some like this:

ID: 1620907790-129565-2241386072 »
Date/Time: Thu, 13 May 2021 15:09:50 +0300 »
IP Address: 42.236.10.84 »
Hostname: hn.kd.ny.adsl »
Referrer: http://baidu.com/ »
Signatures Count: 1 »
Signatures Reference: functions.php:L1552 »
Why Blocked: Fake Baiduspider/百度! »
User Agent: Mozilla/5.0 (Linux; U; Android 8.1.0; zh-CN; EML-AL00 Build/HUAWEIEML-AL00) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/57.0.2987.108 baidu.sogo.uc.UCBrowser/11.9.4.974 UWS/2.13.1.48 Mobile Safari/537.36 AliApp(DingTalk/4.5.11) com.alibaba.android.rimet/10487439 Channel/227200 language/zh-CN »

__

What exactly is "functions.php" and why this is blocked?

[Maikuolan]

and why this is blocked?

This block was triggered by "search engine verification" (note the "Fake Baiduspider/百度" cited for "why blocked"). If necessary, search engine verification can be disabled through the configuration.

What exactly is "functions.php"

Normally, "signatures reference" should provide a "reference" to which "signature" is responsible for causing a block event. In the case of signature files and modules, it'll refer to that particular file, and to which particular line in that file that the signature in question can be found. However, because the internal mechanism for it is tied into and handled by the "trigger" closure, for search engine verification (and also for social media verification), it instead ends up just referring to the specific line in the CIDRAM codebase where those specific calls to the trigger closure are located (which, in this case, is CIDRAM's main functions file).

I've considered making changes in order for the provided information to become a little more useful (e.g., by pointing to the search engine verification file instead of the functions file), and will most likely still make some changes at some point, but it hasn't been a relatively high priority on the to-do list against everything else, and combined with time constraints, hasn't happened just yet.

However, that all said.. This particular block event we see here is a false positive (looking at that user agent, I believe that's a request from an Android device using UC Browser 11.9, not actually a request from Baidu). So, thanks for sharing this here (I can immediately see here exactly why the false positive occurred, but I hadn't been aware of the possibility of this particular false positive occurring until now). Fix should be quick and easy, but I'll push out a fix for this tomorrow (currently after midnight and less likely to make any dangerous typos or mistakes in the code when properly awake and not feeling tired).

[eurobank]

Are you sure it is not a fake bot or something?

https://www.abuseipdb.com/check/42.236.10.84?page=1#report

[Maikuolan]

Are you sure it is not a fake bot or something?

Not sure at all, since that range belongs to a network notorious for that kind of thing.

Also taking note of the huge number of active reports at AbuseIPDB for the address in question, and the fact that when googling the /24 for the address in question (42.236.10.0/24), one of the very first results I found was a discussion at the Cloudflare community forums titled "DDOS from China Botnet" (not related to the exact IP in question here, but both IPs belong to the same /24, and the discussion itself being from all the way back in November 2019, so more than a year old now, and also a little one-sided since only two users were participating in it, but new enough to be potentially still vaguely relevant for the network in question overall, and though not really too notable by itself, when taken in consideration alongside the AbuseIPDB records.. maybe looking a little more notable).

I would wager that there's a strong possibility of it actually being a fake bot. However, bot or not, the user agent cited is an actual, legitimate user agent for UC Browser 11.9, and the IP in question does belong to an actual, legitimate ISP based in China, providing actual, legitimate human endpoints and ADSL service (though that shouldn't really matter too much if serving websites/content intended only for users from specific regions/countries, and if those targeted areas are not China or surrounding countries/regions/etc), so it could be a legitimate user (if you've got any from China, or maybe if any of your users are visiting China at the moment).

Or, it could also just be a fake bot, and nothing to worry about. Since many bots nowadays operate from zombie machines (e.g., compromised computers belonging to actual, real people, with actual, real internet connections, but no longer entirely under their control due to it being infected by malware or backdoors, allowing bots to utilise their connection for whatever purposes those bots have, or compromised routers, modems, and so on), and since many bots also mimic the user agents from real, legitimate browsers (in order to appear as being those browsers, to hide their true identity), there are always going to be some cases where we can't always be entirely certain as to which it is, bot or human.

The reason why I call it a false positive though, is that the reason cited for the block event is inherently wrong (i.e., blocking it on the basis of being a faked Baidu request, when what it possibly is faking as, is not the Baidu search engine, but the UC Browser 11.9), so I'll need to fix that (since it poses the possibility of other requests being similarly blocked, some of which we mightn't want being blocked). Regardless though, even after fixing that, there still already exists other signatures within CIDRAM specifically for blocking that particular network:

That particular network is one of the networks that I regularly update signatures for within the default CIDRAM signature files, as well as also including it within the ignore.dat file by default, since it's one of those more awkward networks, which we have very good reason and solid justifications for blocking, but which also might result in numerous innocent users being unwantedly blocked (thus leaving it up to the discretion of CIDRAM users as to whether they want it blocked or not, but providing an easy way for them to do so if they so choose, since the signatures are already there, but just ignored by default).

I block it myself at most websites where I've personally installed CIDRAM and where I regularly maintain those installations, and would generally encourage blocking it for any websites not catering towards China, but at the same time, wouldn't necessarily recommend blocking it across the board, at every CIDRAM installation, and would particularly recommend not blocking it for any websites which do cater towards China. Ultimately though, this one is at the discretion of CIDRAM users.

[eurobank]

You mean that IP could be malice BUT not in the way the block i reported is done from CIDRAM?

It should belong/blocked to/from some ip/cloud or whatever signatures?

[Maikuolan]

Yep, correct. :-)

[Maikuolan]

Fixed. :-)

[eurobank]

This is AFTER i updated:

ID: 1621036513-123007-5917671170 »
Date/Time: Sat, 15 May 2021 02:55:13 +0300 »
IP Address: 104.140.103.39 »
Hostname: 103.140.104-static.rdns.serverhub.com »
Referrer: http : // removed »
Signatures Count: 1 »
Signatures Reference: functions.php:L1552 »
Why Blocked: Fake Baiduspider/百度! »
User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.170 Safari/537.36 OPR/53.0.2907.68 (Edition Baidu) »

(btw: It would be usefull a log entry in the block list for Updating the script or/and the signatures, because right now i'm 99% sure that i updated before the issue.......)

[Maikuolan]

I guess, my changes must've not been tight enough. :-/

Thanks for letting me know. I'll update again shortly, to make it a little tighter, and hopefully resolve the problem for good.

(btw: It would be usefull a log entry in the block list for Updating the script or/and the signatures, because right now i'm 99% sure that i updated before the issue.......)

You mean, to add something to the logs whenever the signatures are updated? Or something else? (That can definitely be done, but just asking to make sure that I'm understanding correctly).

[Maikuolan]

I'll update again shortly, to make it a little tighter, and ...

Done.

[eurobank]

You mean, to add something to the logs whenever the signatures are updated? Or something else? (That can definitely be done, but just asking to make sure that I'm understanding correctly).

Yes. Just a notice that the update happened.

[Maikuolan]

Yes. Just a notice that the update happened.

Done. :-)

It should be possible now to include such a notice by populating the newly added signatures_update_event_log configuration directive. To add the notice to the existing logs, just make sure that it's populated with the same value as whichever is used to determine the name of said existing logs.