cidram / cidram Goto Github PK
View Code? Open in Web Editor NEWCIDRAM: Classless Inter-Domain Routing Access Manager.
Home Page: https://cidram.github.io/
License: GNU General Public License v2.0
CIDRAM: Classless Inter-Domain Routing Access Manager.
Home Page: https://cidram.github.io/
License: GNU General Public License v2.0
Caught these:
ID: 1374
Script Version: CIDRAM v1.4.0
Date/Time: 2018.02.01 08:16:56 +0800
IP Address: 141.8.143.181
Hostname: 141-8-143-181.spider.yandex.com
Signatures Count: 1
Signatures Reference: outgen.php:L240
Why Blocked: Fake YandexBot!
User Agent: Mozilla/5.0 (compatible; YandexBot/3.0; +http://yandex.com/bots)
Reconstructed URI: http://www.[REDACTED].com/painting/still-life
reCAPTCHA State: Enabled.
ID: 1375
Script Version: CIDRAM v1.4.0
Date/Time: 2018.02.01 08:18:54 +0800
IP Address: 141.8.143.181
Hostname: 141-8-143-181.spider.yandex.com
Signatures Count: 1
Signatures Reference: outgen.php:L240
Why Blocked: Fake YandexBot!
User Agent: Mozilla/5.0 (compatible; YandexBot/3.0; +http://yandex.com/bots)
Reconstructed URI: http://www.[REDACTED].com/painting/abstract
reCAPTCHA State: Enabled.
ID: 1376
Script Version: CIDRAM v1.4.0
Date/Time: 2018.02.01 10:05:14 +0800
IP Address: 141.8.143.181
Hostname: 141-8-143-181.spider.yandex.com
Signatures Count: 1
Signatures Reference: outgen.php:L240
Why Blocked: Fake YandexBot!
User Agent: Mozilla/5.0 (compatible; YandexBot/3.0; +http://yandex.com/bots)
Reconstructed URI: http://www.[REDACTED].com/robots.txt
reCAPTCHA State: Enabled.
ID: 1380
Script Version: CIDRAM v1.4.0
Date/Time: 2018.02.01 13:04:47 +0800
IP Address: 141.8.143.181
Hostname: 141-8-143-181.spider.yandex.com
Signatures Count: 1
Signatures Reference: outgen.php:L240
Why Blocked: Fake YandexBot!
User Agent: Mozilla/5.0 (compatible; YandexBot/3.0; +http://yandex.com/bots)
Reconstructed URI: http://www.[REDACTED].com/
reCAPTCHA State: Enabled.
..And this:
ID: 786
Script Version: CIDRAM v1.4.0
Date/Time: 2018.02.01 00:12:08 +0800
IP Address: 157.55.39.56
Hostname: msnbot-157-55-39-56.search.msn.com
Signatures Count: 1
Signatures Reference: 157.55.38.0/23, xcldbyp_cidram.inc:L32, outgen.php:L219
Why Blocked: Cloud service ("msaz_cidram.inc-IPv4", L683:F5), BingBot MSAZ Bypass, Fake Bingbot!
User Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 7_0 like Mac OS X) AppleWebKit/537.51.1 (KHTML, like Gecko) Version/7.0 Mobile/11A465 Safari/9537.53 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)
Reconstructed URI: http://[REDACTED].com/
reCAPTCHA State: Enabled.
..today, via some CIDRAM installations running on two different websites that I'm helping to maintain at the moment.
Said blocked requests cite "Fake Bingbot" and "Fake YandexBot" in their Why Blocked fields. In short, these requests shouldn't have been blocked (false positives). I haven't yet investigated this thoroughly, and I'm not yet sure whether this is a bug in the code, some quirk of the hosting service that these websites use or whatever else, and I'm not yet sure why this has happened, but I'll investigate it shortly. Possible bug-fix inbound soon.
Hello,
I've been going over my CIDRAM logs and noticed a large amount of IPv6 "Invalid IP" entries that, at least according to the User-Agents and the IP look-up info, appear to be from mobile users or users from legit ISPs. Below is a sample of the IPs and AS that are being blocked.
Admittedly, I'm not an IT guy so I'm unable to conclusively verify these false positives myself, or verify that they are in IP ranges used for business (hosting, cloud, non-user end point etc) services.
From what I can tell, none of these ranges are applicable in my custom IPv6 config file (pastebin).
I'm using version 0.1.1 of CIDRAM with the IPv6.dat file that was updated March 12.
I appreciate any help you can give me. Thanks!
AS7922 2601::/20 Comcast IP Services, L.L.C.
AS20214 2601:580::/26 Comcast IP Services, L.L.C.
AS33650 2601:600::/26 Comcast IP Services, L.L.C.
2601:058b:8404:5830:3d16:faef:1293:d0ab
2601:0603:0601:0978:c92f:8bde:f35c:6aaf
2601:0589:0101:0f0c:fcd9:f351:1023:425f
AS852 2001:569::/33 TELUS Communications Inc.
AS852 2001:569:7530::/44 TELUS-HSIA-RCMDBC01
2001:0569:753f:0800:b531:2d7b:8715:ff6d
2001:056a:f6f0:0d00:a8d9:758f:f7a8:bbdc
AS10796 2607:fcc8::/32 Time Warner Cable Internet LLC
AS11426 2606:a000::/32 Time Warner Cable Internet LLC
2606:a000:674b:3800:3531:1784:2690:b775
2607:fcc8:e785:4a00:b966:af7a:0493:5bc6
AS6167 2600:1000::/28 Cellco Partnership DBA Verizon Wireless
AS22394 2600:1001::/32 Cellco Partnership DBA Verizon Wireless
AS22394 2600:1001:b110::/44 Cellco Partnership DBA Verizon Wireless
2600:1001:b11f:4ff5:c180:7036:6d7f:1e2f
We should create an issue template to ease support.
https://help.github.com/articles/creating-an-issue-template-for-your-repository/
Please use this template when reporting bugs, problems, issues, etc.
1.4.1
<?php echo phpversion(); ?>
).7.1.4
Fatal Error on website: https://loschaos.com/pics/Endurance-Conflict2.jpg
Issue with fatal error on new site
Hi - Starting up a new website and the host has caching as a part of the plan. After running for a day I got the fatal error shown in the screenshot. At the point where you see the screenshot if I tried to access the site the block for China would display for me, along with the error code below the CIDRAM block banner. I am not in China - I am in the US.
I disabled the server cache (endurance-page-cache) and all started functioning normally again.
Is there an issue with CIDRAM and endurance which I believe is Varnish caching?
(I have long used W3 Total Cache with CIDRAM with no issues)
I am busy building the site right now so I have not messed with it again, but if this server caching will speed up the site I will want to investigate it again in the future.
Anyway, wanted to drop in here and say hi! Will be strange not having the forums for support. This is nice–don't get me wrong–just does not have that homey feel. Will you be setting up a forum elsewhere?
Cheers!
Goals, suggestions and ideas for the CIDRAM v0.3.0 version/release.
This list isn't static; Entries may be added and/or removed without notice.
Code changes, features, etc.
Thoughts and concerns about a future proposed installer: Just creating this issue to share some thoughts. This issue doesn't describe any specific plans, intentions, promises, bugs, etc. Related thoughts and opinions from others is invited.
Problems.
Benefits.
Hi
Is it possible to block the Republic of Crimea?
If not, can you create a signature for it that can be installed on the Updates page?
Or perhaps the Republic of Crimea IPs are blocked via the Russia block lists?
Thanks!
Goals, suggestions and ideas for the CIDRAM v0.2.0 version/release.
This list isn't static; Entries may be added and/or removed without notice.
Code changes, features, etc.
INC
files to PHP
files and adjust all references accordingly. Refer #3ipaddr
doesn't exist or is empty (such as for REMOTE_ADDR
). Refer #4config.ini
-> config.ini.RenameMe
) to avoid overwriting during blind updates.Documentation.
Bugs.
@Maikuolan Found another bug.
I set HTTP_CF_CONNECTING_IP
in ipaddr
in the config.ini but in the front-end general->ipaddr: still shows REMOTE_ADDR
Also,
Updating general->ipaddr:
from the front-end does not work.
Google search console could not show link preview as it gets blocked by CIDRAM.
General log found :
ID: 293
Script Version: CIDRAM v1.5.0
Date/Time: Wed, 04 Apr 2018 17:03:41
IP Address: 233.163.105.222
Referrer: http://www.google.com/search
Signatures Count: 1
Signatures Reference: 224.0.0.0/3
Why Blocked: Bogon IP ("ipv4_bogons.dat-IPv4", L12:F1)!
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko; Google Web Preview) Chrome/41.0.2272.118 Safari/537.36
Reconstructed URI: -------
reCAPTCHA State: Enabled.
One suggestion: I think all kind of log files must be generated in a separate folder. As I used to make log file day by day basis, so for me now the main directory is filled with 15 log files.
I have implemented Cloudflare page rules that enable me to cache everything in there 115 Edge Locations.
I did this to reduce the TTFB time and got impressive result also.
** Result:**
TTFB 400ms (when page rule disabled) (GTmetrix value)
TTFB 64ms (when page rule enabled) (GTmetrix value)
So, this trick reduces the backend time drastically but makes our site static.
I know when we cache HTML also in Cloudflare that means the client request is not reaching to origin server where we have CIDRAM running.
But when I tested the setup with different VPNs then I was getting the accessed denied page and sometimes not. So the question how the whole system is working because Cloudflare is having 115 edge nodes they might be caching different HTML pages (including accessed denied page) that are generated by the origin server.
What happens if an accessed denied page is cached on Singapore edge node. Then all the client requests routed via Singapore node get accessed denied page ??
Steps to replicate scenario:
Setting the page rule in Cloudflare.
now when we check on GTMetrix domain document header we get cf-cache-status : HIT
CIDRAM is installed from Wordpress repo (without frontend and recaptcha is not enabled).
Sorry, I know this is a weird setup I am planning, all I want is behind the scene information.
After all the suggestion I will plan memcache, redis or varnish. (which ever play well with CIDRAM)
Today I have seen multiple instances in log where cloudflare IPs getting blocked.
To be noted : I have not enabled Cloudflare block list.
ID: 597
Script Version: CIDRAM v1.5.0
Date/Time: Sat, 07 Apr 2018 15:16:12
IP Address: 162.158.67.83
Signatures Count: 1
Signatures Reference: 162.158.64.0/20
Why Blocked: Cloud service ("CloudFlare, Inc", L797:F0, [US])!
User Agent: Mozilla/5.0 (compatible; CloudFlare-AlwaysOnline/1.0; +http://www.cloudflare.com/always-online) AppleWebKit/534.34
Reconstructed URI: https://example.com/
reCAPTCHA State: Enabled.
ID: 587
Script Version: CIDRAM v1.5.0
Date/Time: Sat, 07 Apr 2018 15:16:06
IP Address: 162.158.64.234
Signatures Count: 1
Signatures Reference: 162.158.64.0/20
Why Blocked: Cloud service ("CloudFlare, Inc", L797:F0, [US])!
User Agent: Mozilla/5.0 (compatible; CloudFlare-AlwaysOnline/1.0; +http://www.cloudflare.com/always-online) AppleWebKit/534.34
Reconstructed URI: https://example.com/
reCAPTCHA State: Enabled.
ID: 586
Script Version: CIDRAM v1.5.0
Date/Time: Sat, 07 Apr 2018 15:16:05
IP Address: 2400:cb00:36:1008:0:0:a29e:40ea
Signatures Count: 1
Signatures Reference: 2400:cb00:36::/48
Why Blocked: Cloud service ("CloudFlare, Inc", L180:F0, [US])!
User Agent: Mozilla/5.0 (compatible; CloudFlare-AlwaysOnline/1.0; +http://www.cloudflare.com/always-online)
Reconstructed URI: https://example.com/
reCAPTCHA State: Enabled.
I've managed to get CIDRAM listed in the plugins database for Wordpress, which I think is a step in the right direction for greater distribution/reach for CIDRAM. :-)
Quick question to the others that've contributed to the project: Do any/all of you have account IDs with Wordpress.org? (Note: It's a different account system to the Wordpress.com website). The reason that I ask this is due to that there's a "Contributors" field provided as part of the syntax for the metadata they derive from plugin READMEs for displaying on each plugin's page within their listings, and it could be good to get some of you listed there if you do (and assuming that you'd like to be listed, of course).
@DanielRuf @divinity76 @m7mdtiger @dev-101 @Gaffnet
(..Not sure the Github usernames for any of the others that've helped out).
Hi all,
If you used the front-end update facility to automatically update CIDRAM, after 25 September 2017 (2017.09.25) at 23:22 UTC±0000 (11:22PM), but before 27 September 2017 (2017.09.26) at 00:42 UTC±0000 (12:42AM), upon consequent attempts to update, you may notice the message appear, "Failed to update!
", and then no updates occurring for the affected components (CIDRAM core, L10N files, etc). This problem is due to some buggy code that I'd accidentally introduced during that period without realising, has now since been fixed, and only affects users that used the front-end update facility to automatically update CIDRAM during that particular period (if you didn't update anything during that particular period, please disregard this). Sorry about this problem.
If you're affected by this problem, follow these instructions exactly, in order to correct the problem (you should be able to update as per normal after correcting the problem).
Solution 1: Using FTP (if you would prefer to NOT use FTP, skip to solution 2; don't use both solutions; only one is needed):
Open the latest version of the functions.php file in your browser and save the file.
Open the latest version of the frontend.php file in your browser and save the file.
Open your preferred FTP client, go to your /cidram/vault/ directory, and replace the existing functions.php and frontend.php files there with the files you've just downloaded.
(1) Download /cidram/vault/fe_assets/frontend.dat, open it in a binary-safe text editor (e.g., Notepad++), and delete everything after:
CACHE
-----
Make sure the file has at least one empty newline at the end of it. Next, upload the modified frontend.dat file back to /cidram/vault/fe_assets/.
-- or --
(2) If you'd prefer to not mess around with the front-end cache file (somewhat safer), just wait an hour for the update cache to expire.
Go to the front-end update page, and attempt to "update all".
Solution 2: Using the front-end directly to fix the problem.
Open the latest version of the functions.php file in your browser, press Ctrl+A (or ⌘+A) to select everything on the page, and Ctrl+C (or ⌘+C) to copy it.
Go to the front-end file manager, locate functions.php, select "edit" from the options list and press "OK".
Select the text box containing the file contents, press Ctrl+A (or ⌘+A) to select it all, and backspace or delete to delete it. Press Ctrl+V (or ⌘+V) to paste the content from the latest version of the functions.php file copied previously. Press the "edit" button to confirm changes, saving the file.
Open the latest version of the frontend.php file in your browser, press Ctrl+A (or ⌘+A) to select everything on the page, and Ctrl+C (or ⌘+C) to copy it.
Go to the front-end file manager, locate frontend.php, select "edit" from the options list and press "OK".
Select the text box containing the file contents, press Ctrl+A (or ⌘+A) to select it all, and backspace or delete to delete it. Press Ctrl+V (or ⌘+V) to paste the content from the latest version of the frontend.php file copied previously. Press the "edit" button to confirm changes, saving the file.
(1) Go to the front-end file manager, locate frontend.dat, select "edit" from the options list and press "OK". Delete everything after:
CACHE
-----
Make sure the file has at least one empty newline at the end of it. Next, press the "edit" button to confirm changes, saving the file.
-- or --
(2) If you'd prefer to not mess around with the front-end cache file, just wait an hour for the update cache to expire.
Go to the front-end update page, and attempt to "update all".
The problem should at that point then disappear. Sorry about this! Just something missed during routine testing prior to committing the changes. '^^
This bug is does not affect security, or normal operation of the package in any way (aside from the ability to update some specific components). It only affects the update facility and nothing else.
Creating a new issue to notify any potential affected users about the problem. Will close it in a day or two, seeing as it's already fixed anyway.
While we were discussing about the issue #54 where legitimate BingBots were being blocked. I found myself in another issue. Before that let me explain the situation first.
Back in the December, 2017 I added some custom bypass rules for CIDRAM. But in January due to some misconception I sort of disabled CIDRAM (by enabling maintenance mode). But in February 25, 2018 I again enabled it.
Today when I was looking into my custom bypass rules, I found this.
/** Prevents execution from outside of CIDRAM. */
if (!defined('CIDRAM')) {
die('[CIDRAM] This should not be accessed directly.');
}
/** Inherit bypass closure (see functions.php). */
$Bypass = $CIDRAM['Bypass'];
/** Bingbot bypass. */
$Bypass(
$CIDRAM['BlockInfo']['SignatureCount'] &&
strpos($CIDRAM['BlockInfo']['UALC'], 'bingbot') !== false,
'Bingbot Bypass'
);
/** BingPreview bypass. */
$Bypass(
$CIDRAM['BlockInfo']['SignatureCount'] &&
strpos($CIDRAM['BlockInfo']['UALC'], 'bingpreview') !== false,
'BingPreview Bypass'
);
So, as you can probably guess any user-agents having bingbot or bingpreview will pass.
Today I reported several IPs which were blocked even they are legit bingbots.
Now, Let's assume they are not legit bingbots. But even they are not, my custom bypass rules should allow them pass, right? So, why it did not?
I also tested 1 of the ip with IP Tester, with user-agent of bingpreview, it showed me pass, but why it was blocked in real time?
ID: 113
Script Version: CIDRAM v1.3.0
Date/Time: Mon, 25 Dec 2017 13:37:14 +0530
IP Address: 65.55.210.175
Signatures Count: 1
Signatures Reference: 65.55.208.0/21
Why Blocked: Cloud service ("Azure", L18153:F0)!
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/534+ (KHTML, like Gecko) BingPreview/1.0b
More Information is here.
The IP is actually from Microsoft bingbot
Feature Request:
1.3.0-DEV
fpm-fcgi
7.1.11
Linux 4.4.0-98-generic #121-Ubuntu SMP Tue Oct 10 14:24:03 UTC 2017 x86_64
When using custom-module IP-Test does not check against the custom-module.
The IP Should show blocked.
The IP returning positive.
Enabled Hostname Blocking
Module - Hostname Added
IP Test Result - http://prntscr.com/hcquiq
The actual hostname blocking working fine, but the IP-Test does not check the IP with custom module.
Goals, suggestions and ideas for the CIDRAM v1.0.0 version/release.
This list isn't static; Entries may be added and/or removed without notice.
Code changes, features, etc.
Documentation/L10N.
ignore.dat
is currently missing from the "files included in this package" list included in the documentation.Bugs.
Final changes (v0.9.0 > v1.0.0).
Discussion duplicated at Spambot Security to maximise responses. Replying here or there, either way, should be fine.
Following on from the discussion earlier where it was mentioned about employing a two-tiered or multi-tiered stream for signature files and their updates, I had another possible idea which could be used as an additional measure of control for CIDRAM users to better self-determine what they do and don't block: Adopt a simple, numeric sliding scale for signature sections, to act as an indicator of the perceived threat rating of the ASNs/CIDRs being blocked by said signature sections, and as (for lack of a better term) a "paranoia threshold" for determining whether to honour said signature sections and their contained signatures when checking IPs against signature files.
A new directive could be added to the configuration to determine what minimum threshold an installation should use, and a corresponding value added to each signature section representative of the level of paranoia required in order for the section to be honoured; If the value in the signature section is higher than (or equal to) the corresponding configuration directive, the section is honoured, and is otherwise ignored. Alternatively (instead of a "paranoia threshold"), if we were to describe this as being a "threat rating" (representative of how imperative it is that the signatures contained therein are blocked), the corresponding configuration directive could possibly be described as something akin to an "DEFCON level", whereby the number of signatures honoured increases as our DEFCON level approaches 1, and decreases as our DEFCON level recedes to a higher number.
My thought was that the configuration directive could default to 1, and the level/threshold applied to individual signature sections could start at something higher (like maybe 5, or 10, or something like that), and then we could use a simple, predefined set of questions for determining how far to strip back that level/threshold, like, for example:
Note: The above are intended only as examples. If this idea is well-received, the criteria / set of questions used can be better developed, more well thought out, etc. For now, I'm just wanting to float the overall idea.
Thoughts?
Will be marked off upon completion/resolution. Issue will be closed upon completion/resolution of all listed items.
cidramblocklists.dat
file and some other strange behaviour; need to determine cause) - Fixed (c877892).ban_override
; need to investigate further) - Fixed (ba6e1ec).I set recaptcha->usermode = 1
so, CIDRAM supposed to offer captcha to every signature. But some cases captcha not kicking in. I'm not sure if it's a bug or I am doing anything wrong. Anyway I used Hostspot Sheild VPN to produce the behavior.
Cloud service is the reason signature of why the ip blocked in both cases, but why recaptcha shows in one & not the other?
Hi, Maikuolan
I've been seeing these CIDRAM log entries that have no IPs recorded:
ID: 1439
Script Version: CIDRAM v0.1.2
Date/Time: Thu, 17 Mar 2016 08:09:47 -0400
IP Address:
Query:
Referrer:
Signatures Count: 1
Signatures Reference: Invalid IP!
User Agent: Wget/1.15 (linux-gnu)
ID: 1442
Script Version: CIDRAM v0.1.2
Date/Time: Thu, 17 Mar 2016 08:18:54 -0400
IP Address:
Query:
Referrer:
Signatures Count: 1
Signatures Reference: Invalid IP!
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:21.0) Gecko/20100101 Firefox/21.0
I didn't find correlating entries in the web server logs that might give me a clue on what triggered these entries. I don't have any CRON events that correlate either.
I'm on a typical shared hosting plan so my investigative means are severely limited. My site is Wordpress-based and working through CloudFlare.
Any ideas on what these blank IPs might be?
Thanks
This is not an issue, just some thinking...
Could we add a simple php API, so to call it, in such a way that we can more easily integrate CIDRAM with existing systems in a stack, without actually modifying CIDRAM core (as that would require constant monitoring for changes etc.).
So, instead of placing CIDRAM the usual way, and make it work it's magic, we can call it's "external" function (verbose example follow):
me: "Hey, CIDRAM, can you check this IP (request) for me?"
CIDRAM: "Ok, here's what I found..."
It can then return result in json or whatever format, for example, if IP is clean, return something simple like "pass", "not blocked" or whatever (even blank result would be ok).
In case it has found something, it will return appropriate field, for example cloud:true, or bogon:true, sfs:true, you get the idea.
Then, we can, instead of usual call for loader.php, simply include CIDRAM as any other php file, and call it's testing (api) function instead. edit: in fact, we can leave that as it is, just set it to work in "api" mode (not blocking anything on it's own).
What do you think?
As I explained in recent (unrelated) issue, I do not use it yet, because I have to adapt it to my current stack in some way.
Thanks
@Maikuolan How about adding Browser Integrity Check?
is it possible? so, people cant retrieve data using some basic get contents functions, like
file_get_contents($url);
what do you think about this?
This might help you,
https://github.com/ItayRosen/Browser-Integrity-Check
I also worried about how Google, Bing, Yandex, Facebook will handle it.
@Dibbyo456 Sorry about the delayed reply here. Delay is because I've been looking into this, and I've been finding a few problems with the idea, but I'm not quite ready to write it off yet, because I do still think it's a good idea, and if it can be made to work, it could be useful for users, I think.
Creating a separate issue for this suggestion, to avoid bloating #34 too much.
The example linked to is pretty straightforward, and on the surface, this idea seems like this should be pretty simple and easy to implement. But I think you hit the nail on the head with your original concern about search engines.
Because the browser integrity check (at least, in the manner originally suggested, as well as mostly everything else I've been able to come up with) relies on an intermediary page to be served between the initial request from any particular source and serving the actually requested resource, I think there's a high probability that this will negatively impact PR and search engine listings as a whole. In particular, as the manner originally suggested and most alternatives tend to rely on JavaScript, it's likely that it'll trip up any bots that don't support JavaScript properly or at all, or can't properly handle JavaScript in the manner required, which in the case of spambots, hacktools and so on, is a good thing, but would likely also apply to a number of search engines too, which is obviously a bad thing.
I'd briefly considered maybe just checking all requests against a whitelist prior to serving the browser integrity check, as to not serve it at all for any search engines, good bots and such things. The problem there though is that the number of things we'd want to have on the whitelist is so large - not just by way of search engines, but also by way of other potentially good bots, social networking share bots, previewers, analytics tools, uptime checkers and so on - that I suspect it'd effectively double the workload required for maintaining CIDRAM, potentially be untenable in terms of false positives and the time required to fix them and prevent them, and potentially be better suited as a secondary project, or maybe an entirely separate package or something. Any such whitelist would likely be constantly evolving over time, as new services emerge on the web, old services go offline, brand names change, user agents change and so on, so a simpler solution would probably be preferable, I think.
Anyway, I'll keep this issue open, in case anyone has any suggestions, ideas, etc, that might be helpful in regards to the issue.
Hiya,
Finally got a VPN setup at home.
What is the best way to configure CIDRAM when using a VPN from home to access my CIDRAM protected sites.
Right now I am setting block_cloud=false
(Correction: I changed block_cloud=true after watching my logs fill with fear and loathing... ) 😨
Is there a way to access my sites using my VPN without opening the gates of hell...
Hello, in /vault/config.ini is variable "ipaddr":
ipaddr='REMOTE_ADDR'
and i have my site behind Cloudflare. Please what to enter into this variable?
It is not described in the config.ini
Is it: HTTP_CF_CONNECTING_IP
?
Refer: ffc567b#commitcomment-18789234
Creating issue to track progress regarding compatibility with multiple vHosts/domains.
Hi, I see a potential problem here. This will be fine for domains/vhosts and separate CIDRAM instances, but in case we use common/centralized single instance in stack or prepend mode, this will work for one domain only whose keys are matched, and all others will fail. We need to add support for multiple vHosts/domains and then check coming requests with HTTP_HOST to retrieve proper key pairs.
Hi, Maikuolan
I needed to whitelist a few EasyCron IPs that are hosted within OVH IP ranges but the whitelisted IPs specified in the ipv4_custom.dat doesn't seem to have precedence over blocked ranges in ipv4.dat.
In my case, I whitelisted 142.4.201.54/32 in ipv4_custom.dat but it remains blocked due to the 142.4.192.0/19. range specified in ipv4.dat.
Anyone up for reviewing the FAQ section of the documentation?
..Or any parts of the documentation, for that matter. Mostly just thinking of the FAQ at the moment due to that I added a new entry to it earlier today (about infractions), and so, it's fresh on my mind.
Would love to know whether others think it all makes sense, whether they think it needs improving, whether there's anything missing that they can think of that should be added and so on. Review and PRs are invited.
I propose adding XML support to the signature files, to allow some degree of extensibility to the signature files by way of allowing certain variables to be defined whenever relevant signatures are triggered.
My thinking was that, by leveraging the inbuilt PHP SimpleXMLElement class, CIDRAM could look for some predefined XML boundaries in the signature files following immediately after a triggered signature and then parse the data contained within any XML boundaries found to give CIDRAM a degree of extensibility based upon the relevant signatures being triggered.
So, say for example, if we had a signature section like this:
Signatures for Foo Bar.
1.2.3.4/32 Deny Generic
We could change it to this:
Signatures for Foo Bar.
1.2.3.4/32 Deny Generic
<section>
<tag>Foo Bar</tag>
</section>
Using the aforementioned inbuilt PHP class, we could then define "tag" (or other similar variables), which could be optionally used by CIDRAM for whatever purposes (I was thinking, in particular, this could be used to offer extended information about signatures originating from certain signature sections, and could help with the suggestion mentioned by dev-101 in #3 regarding adding a better "Why Reason" to the "Access Denied" page).
As another example:
Signatures for Foo Bar.
1.2.3.4/32 Deny Generic
<section>
<config>
<general>
<emailaddr>[email protected]</emailaddr>
</general>
</config>
</section>
..Could be used to define a custom email address to be used for support tickets for in the event of any potential false positives originating from a specific signature section (for if, perhaps, the CIDRAM user doesn't want to define an email address directly in their configuration file, because they only want to offer an email to IPs from certain ISPs, etc), and we could use a similar logic to change configuration elsewhere based on triggering specific signatures (although this should be used very minimally by default, if at all, because we shouldn't be overriding defined configuration unless we absolutely must, but it could be useful for custom signatures, if the user wants to override their own configuration for specific signatures).
Would like to know what you think about this idea.
Compatibility notes:
A option where we can set maximum numbers of logfiles cidram should store & the old log files will be automatically removed.
What do you think?
Since Zap's site is down again I'm commenting here. I just installed the update to the ancient UA blocks module and I changed my UA to a version 3 of Firefox and I still don't get blocked. Not sure what is going on here. ZBblock works to block me however.
Hi,
I created a CIDRAM organisation on GitHub tonight to help with better organising any new, future, related repositories and such that may possibly be created in the future. If anyone needed membership to it (such as, if you're a contributor, wanting to contribute, if you've written and/or are writing plugins for CIDRAM, helping with translations, etc, and if you'd like to be listed as a contributor there and/or if you need repo access), please let us know so that we can add you.
Currently listed organisation owners (people with the ability to accept/reject requests, send invites, etc), in case you needed to tag any of us: @Maikuolan @DanielRuf
Not really an "issue" per se, but I'll leave it open for a few days so that it can be seen by others before closing it.
Today, I was getting some enormous amount of clicks from Russia, so I decided to block the whole Russia country. But it surprised me that Yandex bot was also blocked!
Script Version: CIDRAM v1.3.0-DEV »
Date/Time: Wed, 13 Dec 2017 19:54:07 +0530 »
IP Address: 5.255.253.16 »
Hostname: 5-255-253-16.spider.yandex.com »
Signatures Count: 1 »
Signatures Reference: 5.255.252.0/22 »
Why Blocked: No access allowed from Russia ("RU_cidram.inc-IPv4", L219:F0)! »
User Agent: Mozilla/5.0 (compatible; YandexBot/3.0; +http://yandex.com/bots) »
I'm not sure, if it's a Bug or features. But I would love to unblock the search engines even the country was blocked! Because the country blocking might be temporary & I do wanna show up in SERP.
One more thing, you should consider having module_pinterest.php
enabled by default, many of newbie won't figure out what's wrong.
And does CIDRAM supports PHP 7.2?
Recently finished writing code for a new front-end page, "range tables". Bit of a fluff feature, but relatively simple to code and implement, and have had the idea sitting in the back of my mind for a while. This basically just tallies up all the CIDRs in the signature files by subnet size and country of origin, calculates the total number of IPs there, sorts it, and displays it in a simple table.
Creating this issue as a to-do list due to that I want to commit it today so that I can move onto some other work for a while, but I haven't had time to update the docs yet, and there's a weird UI bug there that still needs to be fixed (IPv4/14
to IPv4/32
doesn't display correctly for whitelist and greylist signature types; everything else seems okay already, and this UI bug doesn't break anything, and probably will be easy to fix, but I haven't looked at it too closely yet since finishing the basic code). Low priority.
0feffa0 - Early stage validator/fixer BETA implemented as CLI functionality.
Not yet documented and still a work-in-progress; I've tested my code prior to committing and it seemed to all work correctly for my tests, but it should nonetheless be regarded as "unstable", due to being an early work-in-progress and neither documented nor yet tested by others.
Both a "validator" and a "fixer" for signature files is available as of this commit; However, this commit offers only a CLI-mode implementation for the validator/fixer (alternative arrangements aren't yet available, but will be later).
Current usage for the validator is:
/path/to/php.exe /path/to/cidram/loader.php -v SignatureFile.dat
Current usage for the fixer is:
/path/to/php.exe /path/to/cidram/loader.php -f SignatureFile.dat
Usage assumes that the signature file to be validated/fixed is located as /path/to/cidram/vault/SignatureFile.dat
.
The "validator" will check the specified signature file against a set of rules and will issue a notice, a warning, an error, or a fatal error (depending on the nature of the rule) whenever a rule fails to be met or whenever the condition associated with a rule is met.
The "fixer" operates on the same set of rules as the validator, but rather than issuing notices, warnings and errors, the fixer will attempt to automatically correct the problem, saving the corrected signature file as /path/to/cidram/vault/SignatureFile.dat.fixed
.
For the purposes of providing an example of the validator at work, if we parse a signature file through it that looks like this:
# A hashed comment.
An unhashed comment.
# Some good signatures.
1.2.3.4/32 Deny Generic
2001::1/128 Deny Generic
127.0.0.1/32 Deny Bogon
10.0.0.0/8 Deny Bogon
Tag: Foobar1
# Some crappy broken signatures.
# (#1 is not a valid CIDR, #2 doesn't start at the beginning of its range, and #3/#4 are "accidentally" duplicated).
666.777.888.999/32 Deny Generic
127.0.0.1/31 Deny Bogon
10.0.0.0/8 Deny Bogon
10.0.0.0/8 Deny Bogon
Tag: Foobar2
# This comment has a bunch of annoying tabs
# This comment has excess trailing whitespace
# EoF
The validator will show us this:
If we parse that same signature file through the fixer, it will create a new file, SignatureFile.dat.fixed
, that looks like this:
# A hashed comment.
# An unhashed comment.
# Some good signatures.
1.2.3.4/32 Deny Generic
2001::1/128 Deny Generic
127.0.0.1/32 Deny Bogon
10.0.0.0/8 Deny Bogon
Tag: Foobar1
# Some crappy broken signatures.
# (#1 is not a valid CIDR, #2 doesn't start at the beginning of its range, and #3/#4 are "accidentally" duplicated).
#666.777.888.999/32 Deny Generic
127.0.0.0/31 Deny Bogon
Tag: Foobar2
# This comment has a bunch of annoying tabs
# This comment has excess trailing whitespace
# EoF
Core goals to be met for a v0.1.0 release (first beta release, end of alpha status).
Hi,
Not sure if I am doing everything fine, as there is no documentation, but from what I've figured out myself is that we first need to hit loader.php and login, to access frontend side.
Now, the problem is that after initial login with default user/pass, I get the homepage stating 'Hello, admin.', but past that point I am going in a login loop (e.g. cannot access any other page, being redirected to login form).
There is absolutely nothing in php error logs. Tested on 2 different apache-based servers with older php (5.4.x) and newer php versions. Again, nothing in the error logs. This could be something with sessions or authentication part. I have all my permission/ownership in order, all dirs are writable.
What am I missing? :)
Thanks!
List of goals, suggestions and ideas for future releases.
This list isn't static; Entries may be added and/or removed without notice. Listed order does not represent priority. List is not comprehensive (issues may exist that aren't listed).
Hi Caleb,
We (SSD Nodes) just acquired 172.93.48.0/21
As you can see here, the registration date is yesterday: https://whois.arin.net/rest/net/NET-172-93-48-0-1
Can we get this range delisted from your blacklist?
Thank you for your time,
Matt
PS I tried looking for your email address to message you directly, I apologize if this is the wrong place.
Hacktoberfest by Digital Ocean will be running again this year through the month of October 2017. If anyone sees any room for improvement to the codebase, has ideas, suggestions, bug-fixes, or whatever else, if you want to win a free Hacktoberfest t-shirt and some stickers, consider signing up for this year and sending some pull requests to this repository. :-)
For more details: https://hacktoberfest.digitalocean.com/#details
Issue will remain open until the end of October.
https://help.github.com/articles/about-repository-transfers/
composer/packagist#47
Currently collecting. Add any additional steps which you think are needed. I would suggest starting transition and first preparation in the next 3 months (Juni - Aug) and the final step with the transfer after this.
Will try to find and onboard some more developers (and get more licenses from IntelliJ) and would probably donate some test instance (can run Git on my server and write some script for testing purposes).
Any feedback is very welcome.
Hi Maik, here's few:
1) I think bogon (**edit/update:**
it is not caused by bogon, wp_cron is still being blocked from other rules/ranges) option should be set to false by default, because of this:
ID: 1
Script Version: CIDRAM v0.1.2
Date/Time: Wed, 16 Mar 2016 12:44:17 +0100
IP Address: 192.168.0.1 (modified, left for illustration purposes only)
Query: doing_wp_cron=1458128657.1168138980865478515625
Referrer:
Signatures Count: 1
Signatures Reference: 192.168.0.0/16 (modified, left for illustration purposes only)
User Agent: WordPress/4.4.2
Now, we could at least add bypass IPs to the list, so that they are excluded from the above rules.
Additionally, bogon description here sounds... well, martian/strange. If its main purpose is to block local range, shouldn't it be called more user-friendly, block_local perhaps? :)
2) outgen.inc (& others .inc) should be renamed to outgen.php, let's depart from the terrible practice of the past, and name files with proper extensions 😉
If .inc is so desperately needed, we could keep it, but append .php finally in the end.
My code editor & me likes it.
3) I might be missing something, but I don't see here Why? section 😕
It should be added as short as possible, but informative (e.g. "ONLINE S.A.S.")
ID: 2
Script Version: CIDRAM v0.1.2
Date/Time: Wed, 16 Mar 2016 13:11:42 +0100
IP Address: 212.129.56.230
Query:
Referrer:
Signatures Count: 1
Signatures Reference: 212.129.0.0/18
User Agent: PHP/5.3.56
4) Surely I am still catching up :) but is there a whitelist (ipwldb.csv) somewhere? Or do I need to use my good old wrapper? **edit/update:**
already did, had to copy ipwldb.csv and use it, to prevent wp_cron from not running.
5) Would be nice to have option in config.ini if we wish 403 or 503 headers. Just throwing my idea here first, should be easy to implement later.
Thanks
See below.
Front-end system to-do list
An issue for tracking progress made towards the front-end system for CIDRAM. Items will be added as they become relevant and marked off upon completion.
Hello,
Today I started using BunnyCDN for my websites, but unfortunately now I'm having problems.
BunnyCDN can't pull files due to CIDRAM.
Possible solutions?
CIDRAM is not getting my real IP address when i am trying to log into frontend of CIDRAM. As i am using cloud hosting so, every time i am trying to visit frontend "I get Access Denied page" to bypass that i enabled reCaptcha.
As a solution when i changed default value of general->ipaddr
from
REMOTE_ADDR
to HTTP_X_REAL_IP
after this tweak everything working good.
my question is should i do this? will it defeat the purpose of CIDRAM?
Waiting for your suggestion's before changing this thing.
Right now I am using REMOTE_ADDR and whitelisted my server IP.
Configuration page UI broken on "Full Moon" theme (discovered upon further testing of UI tonight due to some new things being implemented soon). Creating this issue mostly as a personal reminder. I'll get this fixed shortly.
talking about this code:
/** Attempts to parse the CIDRAM configuration file. */
$CIDRAM['Config'] =
(file_exists($CIDRAM['Vault'] . 'config.ini')) ?
parse_ini_file($CIDRAM['Vault'] . 'config.ini', true) :
array();
/** Fallback for any potential parse failure. */
if (!is_array($CIDRAM['Config'])) {
$CIDRAM['Config'] = array();
}
1: if the config file don't exist, assume the admin wanted an empty config? ... in my opinion, if the admin want an empty config, he should be explicit about it. it could be a security issue if the admin thought the config file was loaded, but in reality a permission error or whatever caused the config not to be loaded.
2: if the config file is corrupt, say, some typo, some unclosed string " in the .ini file, again, do we want to assume the config file was just empty? ... in my opinion, no, it'd be a security issue if the admin thought the config was loaded, but a syntax error or something caused parse_ini_file to fail.
ofc, changing this would be backwards-incompatible, but in a good way
I'm wondering whether all instances of "CIDRs" mentioned in the documentation and elsewhere should be changed to "subnets", to reduce any possible ambiguity caused by the way the term is being used currently. What do you reckon?
Currently, it's being used both as the acronym (Classless Inter-Domain Routing), and as a slang/lazy way to refer to subnets expressed using CIDR notation. Main reason for the latter use thereof instead of simply using "subnets" was due to that subnets can be expressed in other ways, and the specific intended meaning was for subnets expressed using CIDR notation, as opposed to other forms of expression, but that said, it's not really a technically accurate or concise way to convey this meaning, and does potentially carry some ambiguity. Wondering whether to just keep things as they are or to change it.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.