# Please put all your custom IPv6 CIDR signatures in this file.
# To activate this file, please rename this file from "ipv6_custom.dat.RenameMe" to "ipv6_custom.dat".
# The reason for the ".RenameMe" appended onto the end of the names of the custom signature files is to prevent
# accidentally overwriting these files whenever someone updates CIDRAM blindly (such as via a dependency manager,
# installer or auto-updater).
# All signatures follow the format: xxxx:xxxx:xxxx:xxxx::xxxx/yy %Function% %Param%
# Where:
# - "xxxx:xxxx:xxxx:xxxx::xxxx" represents the beginning of the CIDR block (the octets of the initial IP address in the
# block). Complete notation and abbreviated notation are both acceptable (and each MUST follow the appropriate and
# relevant standards of IPv6 notation, but with one exception: an IPv6 address can never begin with an abbreviation
# when used in a signature for this script, due to the way in which CIDRs are reconstructed by the script; For
# example, "::1/128" should be expressed, when used in a signature, as "0::1/128", and "::0/128" expressed as
# "0::/128").
# - "yy" represents the CIDR block size [1-128].
# - %Function% instructs the script what to do with the signature (how the signature should be regarded).
# - %Param% represents whatever additional information may be required by %Function%.
# The signature files for CIDRAM SHOULD use Unix-style linebreaks (`%0A`, or `\n`)! Other types/styles of linebreaks
# (e.g., Windows `%0D%0A` or `\r\n` linebreaks, Mac `%0D` or `\r` linebreaks, etc) MAY be used, but are NOT preferred.
# Non-Unix-style linebreaks will be normalised to Unix-style linebreaks by the script.
# Precise and correct CIDR notation is required, otherwise the script will NOT recognise the signatures. Additionally,
# all the CIDR signatures of this script MUST begin with an IP address whose IP number can divide evenly into the block
# division represented by its CIDR block size (e.g., if you wanted to block all IPs from "ff01::2" to "ff01::11",
# "ff01::2/124" would NOT be recognised by the script, but "ff01::2/127", "ff01::4/126", "ff01::8/125" and
# "ff01::10/127" used in conjunction, WOULD be recognised by the script).
# Anything in the signature files not recognised as a signature nor as signature-related syntax by the script will be
# IGNORED, therefore meaning that you can safely put any non-signature data that you want into the signature files
# without breaking them and without breaking the script. Comments are acceptable in the signature files, and no special
# formatting is required for them. Shell-style hashing for comments is preferred, but not enforced; Functionally, it
# makes no difference to the script whether or not you choose to use Shell-style hashing for comments, but using
# Shell-style hashing helps IDEs and plain-text editors to correctly highlight the various parts of the signature files
# (and so, Shell-style hashing can assist as a visual aid while editing).
# The possible values of %Function% are as follows:
# - Run
# - Whitelist
# - Greylist
# - Deny
# If "Run" is used, when the signature is triggered, the script will attempt to execute (using a `require_once`
# statement) an external PHP script, specified by the %Param% value (the working directory should be the "/vault/"
# directory of the script, and the scope of execution is within the IPv6 test function).
# Example: 2001:db8::/32 Run example.php
# This can be useful if you want to execute some specific PHP code for some specific IPs and/or CIDRs.
# If "Whitelist" is used, when the signature is triggered, the script will reset all detections (if there's been any
# detections) and break the test function. %Param% is ignored. This function is the equivalent of whitelisting a
# particular IP or CIDR from being detected.
# Example: 0::1/128 Whitelist
# If "Greylist" is used, when the signature is triggered, the script will reset all detections (if there's been any
# detections) and skip to the next signature file to continue processing. %Param% is ignored.
# Example: 0::1/128 Greylist
# If "Deny" is used, when the signature is triggered, assuming no whitelist signature has been triggered for the given
# IP address and/or given CIDR, access to the protected page will be denied. "Deny" is what you'll want to use to
# actually block an IP address and/or CIDR range. When any signatures are triggered that make use of "Deny", the
# "Access Denied" page of the script will be generated and the request to the protected page killed.
# The %Param% value accepted by "Deny" will be parsed to the "Access Denied" page output, supplied to the client/user
# as the cited reason for their access to the requested page being denied. It can be either a short and simple
# sentence, explaining why you've chosen to block them (anything should suffice, even a simple "I don't want you on my
# website"), or one of a small handful of shorthand words supplied by the script, that if used, will be replaced by the
# script with a pre-prepared explanation of why the client/user has been blocked.
# The pre-prepared explanations have L10N support and can be translated by the script based upon the language you
# specify to the `lang` directive of the script configuration. Additionally, you can instruct the script to ignore
# "Deny" signatures based upon their %Param% value (if they're using these shorthand words) via the directives
# specified by the script configuration (each shorthand word has a corresponding directive to either process the
# corresponding signatures or to ignore them). %Param% values that don't use these shorthand words, however, don't
# have L10N support and therefore WON'T be translated by the script, and additionally, aren't directly controllable by
# the script configuration.
# The available shorthand words are:
# - Bogon
# - Cloud
# - Generic
# - Proxy
# - Spam
# - Legal
# - Malware
# These available shorthand words (these examples assume that you've specified English as your desired language to the
# `lang` directive of the script configuration) will be replaced by the script with:
# - Bogon: "Your access to this page was denied because your IP address is recognised as a bogon address, and
# connecting from bogons to this website isn't permitted by the website owner."
# - Cloud: "Your access to this page was denied because your IP address is recognised as belonging to a cloud
# service, and connecting to this website from cloud services isn't permitted by the website owner."
# - Generic: "Your access to this page was denied because your IP address belongs to a network listed on a blacklist
# used by this website."
# - Proxy: "Your access to this page was denied because your IP address is recognised as belonging to a proxy
# service or VPN, and connecting to this website from proxy services or VPNs isn't permitted by the
# website owner."
# - Spam: "Your access to this page was denied because your IP address belongs to a network considered high-risk
# for spam."
# - Legal: "Your access to this page was denied due to legal obligations."
# - Malware: "Your access to this page was denied due to malware concerns relating to your IP address."
# Example 1: 2001:db8::/32 Deny Bogon
# Example 2: 2001:db8::/32 Deny Cloud
# Example 3: 2001:db8::/32 Deny Generic
# Example 4: 2001:db8::/32 Deny Spam
# Example 5: 2001:db8::/32 Deny Your access to this page was denied because (of some other reason)...
# More possible %Function% values and more possible %Param% values for "Deny" may, and likely will, be added at a
# future date. For now, what has been documented is what is available, and at such a future time where new possible
# values are added, they will be added, also, to the documentation.
# Optional: If you want to split your custom signatures into individual sections, you can identify these individual
# sections to the script by adding a "Tag:" label immediately after the signatures of each section, along with the name
# of your signature section.
# Example:
# # "Section 1."
# 1.2.3.4/32 Deny Bogon
# 2.3.4.5/32 Deny Cloud
# 4.5.6.7/32 Deny Generic
# 5.6.7.8/32 Deny Spam
# 6.7.8.9/32 Deny Proxy
# Tag: Section 1
# To break section tagging and to ensure that tags aren't incorrectly identified to signature sections from earlier in
# the signature files, simply ensure that there are at least two consecutive linebreaks between your tag and your
# earlier signature sections. Any untagged signatures will default to either "IPv4" or "IPv6" (depending on which types
# of signatures are being triggered).
# Example:
# 1.2.3.4/32 Deny Bogon
# 2.3.4.5/32 Deny Cloud
#
# 4.5.6.7/32 Deny Generic
# 5.6.7.8/32 Deny Spam
# Tag: Section 1
# In the above example "1.2.3.4/32" and "2.3.4.5/32" will be tagged as "IPv4", whereas "4.5.6.7/32" and "5.6.7.8/32"
# will be tagged as "Section 1".
# If you want signatures to expire after some time, in a similar manner to section tags, you can use an "expiry tag" to
# specify when signatures should cease to be valid. Expiry tags use the format "YYYY.MM.DD".
# Example:
# # "Section 1."
# 1.2.3.4/32 Deny Generic
# 2.3.4.5/32 Deny Generic
# Expires: 2016.12.31
# Section tags and expiry tags may be used in conjunction, and both are optional.
# A simplified form of YAML markup may be used in signature files for the purpose of defining behaviours and settings
# specific to individual signature sections. This may be useful if you want the value of your configuration directives
# to differ on the basis of individual signatures and signature sections (for example; if you want to supply an email
# address for support tickets for any users blocked by one particular signature, but don't want to supply an email
# address for support tickets for users blocked by any other signatures; if you want some specific signatures to
# trigger a page redirect; if you want to mark a signature section for use with reCAPTCHA; if you want to log blocked
# access attempts to separate files on the basis of individual signatures and/or signature sections).
# Use of YAML markup in the signature files is entirely optional (ie, you may use it if you wish to do so, but you are
# not required to do so), and is able to leverage most (but not all) configuration directives.
# Note: YAML markup implementation in CIDRAM is very simplistic and very limited; It is intended to fulfill
# requirements specific to CIDRAM in a manner that has the familiarity of YAML markup, but neither follows nor complies
# with official specifications (and therefore won't behave in the same way as more thorough implementations elsewhere,
# and may not be appropriate for other projects elsewhere).
# In CIDRAM, YAML markup segments are identified to the script by three dashes ("---"), and terminate alongside their
# containing signature sections by double-linebreaks. A typical YAML markup segment within a signature section consists
# of three dashes on a line immediately after the list of CIDRS and any tags, followed by a two dimensional list of
# key-value pairs (first dimension, configuration directive categories; second dimension, configuration directives) for
# which configuration directives should be modified (and to which values) whenever a signature within that signature
# section is triggered.
# Refer to the documentation for more information regarding what you've read thus far.
# Everything above this line is purely informative, included here for your benefit, to help you better understand how
# to write and how to manage custom signatures for CIDRAM. If you want to reduce file bloat, and/or if you feel that
# you don't need the above information, you may remove it from this file (doing so won't negatively impact the script).
# ---
# > ADD YOUR CUSTOM SIGNATURES AFTER THIS LINE <
# > ADD YOUR CUSTOM SIGNATURES BEFORE THIS LINE <
|
Download
