Giter Club home page Giter Club logo

cidram's Introduction

v1: PHP >= 5.4 v2~v3: PHP >= 7.2 License: GPL v2 PRs Welcome

What is CIDRAM?

CIDRAM (Classless Inter-Domain Routing Access Manager) is a PHP script designed to protect websites by blocking requests originating from IP addresses regarded as being sources of undesirable traffic, including (but not limited to) traffic from non-human access endpoints, cloud services, spambots, scrapers, etc. It does this by calculating the possible CIDRs of the IP addresses supplied from inbound requests and then attempting to match these possible CIDRs against its signature files (these signature files contain lists of CIDRs of IP addresses regarded as being sources of undesirable traffic); If matches are found, the requests are blocked.


Features:

  • Licensed as GNU General Public License version 2.0 (GPLv2).
  • Easy to install, easy to customise, easy to use.
  • Works for any system with PHP+PCRE installed, regardless of OS (PHP+PCRE required).
  • Fully configurable based on your needs.
  • Ideal solution for websites and forum systems using shared hosting services.
  • Does NOT require shell access.
  • Does NOT require administrative privileges.
  • Good, strong, stable support base.

Documentation:

[CONTRIBUTING.md] Want to help?


Last Updated: 18 March 2024 (2024.03.18).

cidram's People

Contributors

andrulko avatar arnauinho avatar danielruf avatar dev-101 avatar divinity76 avatar elza3ym avatar frommmoritz avatar gitter-badger avatar iruy avatar m7mdtiger avatar maikuolan avatar naveen17797 avatar neufeind avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

cidram's Issues

Compatibility with multiple vHosts/domains

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.

Front-end system to-do list

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.

  • Alpha stage: Coming up with some new plans, ideas, etc; Syncing some initial commits (getting the bare bones of the front-end system working).
  • Beta stage: Fleshing it out a bit more; Trying to implement some of our plans, ideas, etc (the front-end system mightn't be completed, but should be at least more functional by this stage; this item should only be marked as completed upon thorough testing of all changes to ensure that everything is working as intended).
  • Configuration update.
  • Documentation update.
  • Access/login/sessions system.
  • Build a front-end updates manager.
  • Build a front-end configuration manager.
  • Build a CIDR calculator.

Hacktoberfest 2017

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.

v1.0.0 Goals

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.

  • [Added => v0.4.0] Add YAML-like support to signature files. Refer #6
  • [Added => v0.5.0] Implement reCAPTCHA solution to allow bypassing false positives.
  • [Added => v0.9.0] Completion of all items listed in the "front-end system to-do list" (#16).
  • Additional modules for improved security coverage.

Documentation/L10N.

  • [Added => v0.5.0] Missing documentation: reCAPTCHA.
  • [Added => v0.5.1] Missing documentation: Expiry tags.
  • [Added => v0.5.1] Missing documentation: Using YAML in the signature files.
  • [Added => v0.5.1] Add "Frequently Asked Questions" section to the READMEs.
  • [Fixed => v0.5.1] ignore.dat is currently missing from the "files included in this package" list included in the documentation.
  • [Completed => v0.6.1] Targeted translations for internal language data.
  • [Completed => v0.7.1] Targeted translations for README documentation.
  • [Completed => v0.9.0] Planned supplementary translations for internal language data.
  • [Completed => v0.7.0] Planned supplementary translations for README documentation.
  • [Completed => v0.7.0] Missing documentation: "CONTRIBUTING.md" file.

Bugs.

  • [Fixed => v0.4.0] Incorrect typecasting bug for configuration directives.

Final changes (v0.9.0 > v1.0.0).

  • [Resolved] "Compatibility with multiple vHosts/domains". #15
  • [Resolved] Expand themes, if possible.
  • New L10N/translations offered by some users. Not sure about progress. May arrive soon. A small delay period recommended prior to the final v1.0.0 release to accommodate the possibility of these being completed prior to the the final v1.0.0 release.

Wordpress

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

Organisation Membership

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.

Cloudflare IPs getting blocked

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.

reCaptcha not kicking in some cases.

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.

reCaptcha Settings
screenshot_14

reCaptcha not kicking in
screenshot_12

reCaptcha kicked in
screenshot_13

Cloud service is the reason signature of why the ip blocked in both cases, but why recaptcha shows in one & not the other?

Endurance Page Cache

Please use this template when reporting bugs, problems, issues, etc.

Server information.

CIDRAM version used (if known, please also include the exact commit hash).

1.4.1

Signatures version (if known).

PHP version installed (<?php echo phpversion(); ?>).

7.1.4


Issue

Fatal Error on website: https://loschaos.com/pics/Endurance-Conflict2.jpg

Expected behavior

Issue with fatal error on new site

Actual behavior

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!

Google search console could not show link preview - Access Denied page shown

Google search console could not show link preview as it gets blocked by CIDRAM.
search console access denied

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.

[Request] log rotation

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?

Showing Server IP address when loading loader.php

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.

v0.1.0 Goals (First Beta)

Core goals to be met for a v0.1.0 release (first beta release, end of alpha status).

  • Build core functionality for testing CIDRs (both IPv4 and IPv6), based upon the planned improved method (we can deal with peripheral functionality and additional testing methods later, after v0.1.0 has been released).
  • Build and populate initial CIDR databases (both IPv4 and IPv6).
  • Test core functionality for testing CIDRs, to confirm that it works as intended.
  • Build the necessary initial support structures (i18n support, configuration file, template file, etc) required in order for the script to function as intended.
  • Decide on a proper, permanent name for the project, in order to retire the temporary working name, "IPTestScript", and then change the repository name and address accordingly (any updates committed prior to meeting this goal will be considered alpha updates).
  • Update repository description, README information, etc (require the permanent name for this).
  • Write some initial documentation, describing what the project is, what it's for, how to install it, how to use it, etc. Initial documentation doesn't need to be comprehensive, but, must at least describe these basics.

CIDRs => Subnets (?)

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.

Range tables to-do list.

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.

  • Write the basic code for "range tables" (already done before issue was created).
  • Fix weird range tables UI bug.
  • Update documentation.

List of goals, suggestions and ideas for future releases.

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

  • v1.1.0: Configurable font size magnification (Implemented 2017.07.31).
  • v1.1.0: Directive to enable/disable number localisation (Implemented 2017.07.31).
  • v1.1.0: Improve hotfix mechanism for version reporting (Implemented 2017.07.31).
  • v1.1.0: More email options (Implemented 2017.08.15).
  • v1.1.0: Improved L10N for handling DAT files (Implemented 2017.08.16).
  • v1.1.0: ON/OFF switch (Implemented 2017.08.17).
  • v1.2.0: In-built IPv4+IPv6 aggregator (Implemented 2017.09.19).
  • v1.2.0: Add statistics page to the front-end (Implemented 2017.10.04).
  • v1.2.0: Metadata cleanup routine (Implemented 2017.10.07).
  • v1.2.0: Ability to fetch extended descriptions from L10N data (Implemented 2017.10.09).
  • v1.2.0: CI reports/tests on the front-end updates page (Implemented 2017.10.26).
  • v1.2.0: Split out front-end closures from the main functions file (Implemented 2017.10.26).
  • v1.2.0: Remove PHP < 5.4.0 syntax (Implemented 2017.10.27).
  • v1.2.0: Prepare Cronable API (Implemented 2017.10.28).
  • v1.3.0: Enable/Disable Hostname lookups as default (Implemented 2017.11.07).
  • v1.3.0: Expand documentation to properly describe and explain "infractions" (Implemented 2017.11.25).
  • v1.3.0: Expand documentation to include information about writing modules and about blocking hostnames (Implemented 2017.12.03).
  • v1.8.0: 2FA (Two-Factor Authentication) (Implemented 2018.08.12).
  • v1.8.0: Explore additional/alternative arrangements for custom bypasses and custom hostname blocks (Implemented 2018.09.25).
  • v1.13.0, v2.0.0: Implement mechanisms for platform contingencies/redundancies (Implemented 2019.05.31).
  • v1.13.0, v2.0.0: Remotes redirect for handling updates when primary update sources are unavailable (Implemented 2019.05.31).

Thoughts and concerns about a future proposed installer.

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.

  • Due to the numerous different software packages that exist to which CIDRAM might be attached, and thus, the difficulty in adequately and reliably predicting the environment to which it might be installed in regards to the needs of any one specific user, the task of establishing "hooks" between the target software package and CIDRAM upon installation in any automatic capacity (i.e., by way of an installer, installation wizard, etc) is one which may be difficult to complete in an adequately reliable way, and not accounting for any potential failure to install CIDRAM, may also be potentially dangerous in some circumstances, such as if a "hook" is incorrectly inserted, causing the target software package to break. Due to similar and shared goals, this problem relates to both CIDRAM and phpMussel.
  • Creating various plugins and extensions for CIDRAM and phpMussel is a solution which has been considered for some time, and in many cases, serves as a viable means to ensure safe, automatic installation for the specific software packages which these plugins and extensions are built for. Of course, it is limited to those specific software packages (i.e., providing no benefit for unrelated software packages), and an issue unrelated to that of building any manner of generic installer for CIDRAM and phpMussel.
  • Assuming that the insertion of "hooks" remains a manual step in the installation process, the installation process can otherwise be mostly automated, but the benefit of building an installer for this as opposed to continuing to rely on the currently available installation methods becomes questionable, I think, in that there isn't really all that many differences remaining anyhow, aside from the possibility of some future fancy GUI or the likes.
  • In the event of inadequate CHMOD permissions or other related restrictions, manual installation may be enforced in many cases anyhow, or at the very least, ensuring adequate CHMOD permissions may be another step which must remain manual in some cases.
  • At this point, I'm having doubts about the necessity of building an installer at all, and having some difficult conceptualising what form it may take.

Benefits.

  • People like installers. In many cases, people expect them to exist. They can create a sense of ease that it should be an easy task to get some piece of software up and running in an easy and timely manner. It can make things look a little nicer. Certainly, in many cases (e.g., when some piece of software relies on interacting with database connectors, need to install registration data, etc), installers do make things much easier. Not sure any of that applies in this case though; CIDRAM and phpMussel handle everything using their own files.
  • It's something which has been mentioned in the documentation for a very long time, and most users at this point will assume that I'm going to be building an installer at some point.

Suggestions

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

Configuration page UI broken on "Full Moon" theme.

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.

  • Fix configuration page UI for "Full Moon" theme.

CIDRAM log entries with no IPs

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

More search engine verification woes.

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.

CIDRAM behaviour when Cloudflare Cache Everything page rule is enabled

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)
    https___soumsps in_ _ gtmetrix

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.
cloudflare - web performance security

now when we check on GTMetrix domain document header we get cf-cache-status : HIT
latest performance report for_ https___soumsps in_ _ gtmetrix

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)

CIDRAM API

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

Blocking country also blocking search engines

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?

Browser Integrity Check

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

[Proposal] Add XML/YAML support to signature files.

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.

@DanielRuf @dev-101

Compatibility notes:

  • The logic currently employed and described in the signature files whereby anything not recognised as a signature is interpreted as a comment (or, in other words, ignored, and thus, not interpreted at all), would no longer be entirely true, and so, this described information would likely need to be reworded; However, as I doubt many users are likely to dump XML in their signature files with the intentions of it being a comment, the proposed change could be argued as being backwards-compatible.
  • Implementing this proposal shouldn't affect the format or structure of the signature files otherwise.

Frequently Asked Questions

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.

BingPreview being blocked

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:

  • option/button to clear logs file just like statics?

v0.3.0 Goals

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.

  • Use a configuration directive to specify which signature files should be used by the script. This way, to add new signature files, we can use this new directive instead of needing to edit the package core. Core script files should NOT need to be modified in order to add common or expected customisations.
  • Allow dated log filenames.
  • Allow signatures to be disabled or ignored on the basis of their section tags.

transfer to organization

https://help.github.com/articles/about-repository-transfers/
composer/packagist#47

  • fork repo to the org and disable PRs and issues
  • generate new GitHub pages
  • change GitHub paths in composer.json and other files
  • update links where needed
  • submit the new package to packagist / composer
  • update hooks and services if any are set (the original repo should get the settings of the new one)
  • delete org repo, transfer original repo to org

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.

better checks for invalid configs

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

Delist 172.93.48.0/21

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.

front-end login loop

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!

Is it possible to block Republic of Crimea?

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!

v0.2.0 Goals

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.

  • Rename all INC files to PHP files and adjust all references accordingly. Refer #3
  • Bogon directive should be disabled by default.
  • Implement a "Why blocked" field for debugging, for logfiles and for users to better explain why users are blocked when they're blocked. Refer #3
  • Create fallback mechanism for when the specific ipaddr doesn't exist or is empty (such as for REMOTE_ADDR). Refer #4
  • Add support for multiple types of linebreaks (Windows/Unix/Linux/iOS/etc).
  • Add support for section tags.
  • Complete implementation of all section tags.
  • All comments should be hashed by default (not enforced on execution, but recommended by the validator). Refer #3
  • Rename custom signature files to avoid overwriting during blind updates.
  • Rename configuration file (config.ini -> config.ini.RenameMe) to avoid overwriting during blind updates.
  • Custom signature files and the configuration should all be optional (not mandatory).
  • Ability to display reconstructed URL to the user when they're blocked and add reconstructed URL to the logfiles.
  • Add support for multiple logfile formats.
  • Enhance flexibility for the output of custom error codes (options for 503, etc). Refer #3
  • Ability to use custom template files and custom CSS files for page output.
  • Complete CLI-mode implementation (i18n support, output defaults, directive to disable it, etc).
  • Add support for expiry tags.
  • Creation of an external validator/fixer. Refer #3

Documentation.

  • Update all README documentation to include the information currently available within the custom signature files (such as regarding signature format and structure, etc). Refer #3

Bugs.

  • [Fixed => v0.1.2] IPv6 CIDR generation bug. Refer #2
  • [Fixed => v0.2.0] Correct identification of PHP mode (CLI, CGI, Apache, etc) bug. Refer #4
  • [Fixed => v0.2.0] Whitelist signatures being ignored bug. Refer #7

Update bug ("Failed to update!")

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):

  1. Open the latest version of the functions.php file in your browser and save the file.

  2. Open the latest version of the frontend.php file in your browser and save the file.

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

  4. (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 --

  1. (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.

  2. Go to the front-end update page, and attempt to "update all".

Solution 2: Using the front-end directly to fix the problem.

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

  2. Go to the front-end file manager, locate functions.php, select "edit" from the options list and press "OK".

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

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

  5. Go to the front-end file manager, locate frontend.php, select "edit" from the options list and press "OK".

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

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

  1. (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.

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

False Positives?

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

UA blocks aren't working

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.

External issue tracking.

Will be marked off upon completion/resolution. Issue will be closed upon completion/resolution of all listed items.

Whitelisting in custom .dat not taking precedence

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.

Idea: Paranoia/Threat Threshold/Rating

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:

  1. Acts as, or contains known human endpoints? If so, drop rating by 2 points.
  2. Limited evidence to support the inclusion of the signature section (low number of negative reports, etc)? If so, drop rating by 1 point.
  3. Signature section is purely speculative, rather than based on evidence (or, if there isn't any current evidence, the existing evidence is outdated, etc)? If so, drop rating by 2 points.
  4. Could carry useful services and/or be a source of desirable traffic (good bots, etc)? If so, drop rating by 1 point.

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?

IP-Test does not return positive data, when custom-module in use.

Server information.

CIDRAM version used:

1.3.0-DEV

PHP SAPI used:

fpm-fcgi

PHP version installed:

7.1.11

Operating system used:

Linux 4.4.0-98-generic #121-Ubuntu SMP Tue Oct 10 14:24:03 UTC 2017 x86_64


Issue

When using custom-module IP-Test does not check against the custom-module.

Expected behavior

The IP Should show blocked.

Actual behavior

The IP returning positive.

Steps to reproduce the behavior

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.

VPN access of CIDRAM Protected Sites

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

Validator/Fixer BETA.

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

v

Current usage for the fixer is:

  • /path/to/php.exe /path/to/cidram/loader.php -f SignatureFile.dat

f

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:

vtest

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

Problems with CDN

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?

bypass rules not working anymore

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?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.