PHP Classes

File: vault/ipv4_custom.dat.RenameMe

Recommend this page to a friend!
  Classes of Caleb   CIDRAM   vault/ipv4_custom.dat.RenameMe   Download  
File: vault/ipv4_custom.dat.RenameMe
Role: Auxiliary data
Content type: text/plain
Description: Auxiliary data
Class: CIDRAM
Check if an IP address is a bad source of traffic
Author: By
Last change: Update of vault/ipv4_custom.dat.RenameMe
Date: 4 years ago
Size: 11,475 bytes
 

Contents

Class file image Download
# Please put all your custom IPv4 CIDR signatures in this file. # To activate this file, please rename this file from "ipv4_custom.dat.RenameMe" to "ipv4_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: xxx.xxx.xxx.xxx/yy %Function% %Param% # Where: # - "xxx.xxx.xxx.xxx" represents the beginning of the CIDR block (the octets of the initial IP address in the block). # - "yy" represents the CIDR block size [1-32]. # - %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 `10.128.0.0` to # `11.127.255.255`, `10.128.0.0/8` would NOT be recognised by the script, but `10.128.0.0/9` and `11.0.0.0/9` 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 IPv4 test function). # Example: 127.0.0.0/8 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: 127.0.0.1/32 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: 127.0.0.1/32 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: 127.0.0.0/8 Deny Bogon # Example 2: 127.0.0.0/8 Deny Cloud # Example 3: 127.0.0.0/8 Deny Generic # Example 4: 127.0.0.0/8 Deny Spam # Example 5: 127.0.0.0/8 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 <