rodsec 0.0.1

data/lib/rodsec/version.rb

@@ -0,0 +1,3 @@
+module Rodsec
+  VERSION = '0.0.1'
+end

data/lib/rodsec/wrapper.rb

@@ -0,0 +1,136 @@
+require 'fiddle'
+require 'fiddle/import'
+
+module Rodsec
+  module Wrapper
+    extend Fiddle::Importer
+
+    dlext = RbConfig::CONFIG['DLEXT']
+    msc_intervention = dlopen File.join __dir__, "msc_intervention.#{dlext}"
+    dlload msc_intervention, "libmodsecurity.#{dlext}"
+
+    ###########################
+    # from modsecurity/modsecurity.h
+    typealias 'ModSecurity', 'void'
+
+    # ModSecurity *msc_init();
+    extern 'ModSecurity *msc_init()'
+    extern 'void msc_cleanup(ModSecurity *msc)'
+
+    extern 'void msc_set_connector_info(ModSecurity *msc, const char *connector)'
+    extern 'const char *msc_who_am_i(ModSecurity *msc)'
+
+    # logging callback
+    # see ModSecurity/headers/modsecurity/modsecurity.h:221
+    typealias 'ModSecLogCb', 'void (*) (void *, const void *)'
+    extern 'void msc_set_log_cb(ModSecurity *msc, ModSecLogCb cb)'
+
+    ###########################
+    # from modsecurity/rules.h
+    typealias 'Rules', 'void'
+
+    extern 'Rules *msc_create_rules_set()'
+    extern 'int msc_rules_cleanup(Rules *rules)'
+
+    extern 'int msc_rules_add(Rules *rules, const char *plain_rules, const char **error)'
+    extern 'int msc_rules_add_file(Rules *rules, const char *file, const char **error)'
+    extern 'int msc_rules_add_remote(Rules *rules, const char *key, const char *uri, const char **error)'
+
+    extern 'int msc_rules_merge(Rules *rules_dst, Rules *rules_from, const char **error)'
+    extern 'void msc_rules_dump(Rules *rules)'
+
+    ###########################
+    # from modsecurity/transaction.h
+    # Phase documentation in src/transaction.cc
+    # A bit more phase documentation in modsecurity/modsecurity.h near enum Phases
+    typealias 'Transaction', 'void'
+
+    extern 'Transaction *msc_new_transaction(ModSecurity *ms, Rules *rules, void *logCbData)'
+    extern 'void msc_transaction_cleanup(Transaction *transaction)'
+
+    # Phase CONNECTION / SecRules  0
+    extern 'int msc_process_connection(Transaction *transaction, const char *client, int cPort, const char *server, int sPort)'
+
+    # Phase URI / 1.5
+    extern 'int msc_process_uri(Transaction *transaction, const char *uri, const char *protocol, const char *http_version)'
+
+    # Phase REQUEST_HEADERS.  SecRules 1
+    extern 'int msc_add_request_header(Transaction *transaction, const unsigned char *key, const unsigned char *value)'
+    extern 'int msc_add_n_request_header(Transaction *transaction, const unsigned char *key, size_t len_key, const unsigned char *value, size_t len_value)'
+    extern 'int msc_process_request_headers(Transaction *transaction)'
+
+    # Phase REQUEST_BODY.  SecRules 2
+    extern 'int msc_append_request_body(Transaction *transaction, const unsigned char *body, size_t size)'
+    extern 'int msc_request_body_from_file(Transaction *transaction, const char *path)'
+    extern 'int msc_process_request_body(Transaction *transaction)'
+    extern 'size_t msc_get_request_body_length(Transaction *transaction)'
+
+    # Phase RESPONSE_HEADERS. SecRules 3
+    extern 'int msc_add_response_header(Transaction *transaction, const unsigned char *key, const unsigned char *value)'
+    extern 'int msc_add_n_response_header(Transaction *transaction, const unsigned char *key, size_t len_key, const unsigned char *value, size_t len_value)'
+    extern 'int msc_process_response_headers(Transaction *transaction, int code, const char* protocol)'
+
+    # Called after msc_process_response_headers "to inform a new response code"
+    # Not mandatory. Not sure what it means really.
+    extern 'int msc_update_status_code(Transaction *transaction, int status)'
+
+    # Phase RESPONSE_BODY. SecRules 4
+    extern 'int msc_append_response_body(Transaction *transaction, const unsigned char *body, size_t size)'
+    extern 'int msc_process_response_body(Transaction *transaction)'
+
+    extern 'const char *msc_get_response_body(Transaction *transaction)'
+    extern 'size_t msc_get_response_body_length(Transaction *transaction)'
+
+    # Phase LOGGING. SecRules 5. Just log the transaction to the registered logger.
+    extern 'int msc_process_logging(Transaction *transaction)'
+
+    # Phase INTERVENTIONS (interleaved)
+    #
+    extern 'int msc_intervention(Transaction *transaction, ModSecurityIntervention *it)'
+
+    ###############################
+    # And now we need a little cpp work to access this struct without without spectacularly leaking memory.
+
+    # This isn't used. But ah kept it cos it's purty.
+    def self.free_fn_ptr
+      @free_fn_ptr ||= Fiddle::Function.new Fiddle::RUBY_FREE, [Fiddle::TYPE_VOIDP], Fiddle::TYPE_VOID
+    end
+
+    # from modsecurity/intervention.h
+    # typedef struct ModSecurityIntervention_t {
+    #     int status;
+    #     int pause;
+    #     char *url;
+    #     char *log;
+    #     int disruptive;
+    # } ModSecurityIntervention;
+    ModSecurityIntervention_t = struct ['int status', 'int pause', 'char *url', 'char *log', 'int disruptive']
+
+    class ModSecurityIntervention < ModSecurityIntervention_t
+      def initialize( *args )
+        super
+        to_ptr.free = Wrapper['msc_free_intervention']
+      end
+
+      def log
+        ptr = super
+        ptr.to_s unless ptr.null?
+      end
+
+      def url
+        ptr = super
+        ptr.to_s unless ptr.null?
+      end
+
+      def to_h
+        @entity.instance_variable_get(:@members).map do |member|
+          [member, (send member)]
+        end.to_h
+      end
+    end
+
+    # These two are defined in the msc_intervention extension
+    extern 'ModSecurityIntervention_t * msc_new_intervention()'
+    extern 'int msc_free_intervention(ModSecurityIntervention *it)'
+  end
+end

data/rodsec.gemspec

@@ -0,0 +1,40 @@
+# coding: utf-8
+lib = File.expand_path('../lib', __FILE__)
+$LOAD_PATH.unshift(lib) unless $LOAD_PATH.include?(lib)
+require 'rodsec/version'
+
+Gem::Specification.new do |spec|
+  spec.name          = 'rodsec'
+  spec.version       = Rodsec::VERSION
+  spec.authors       = ['John Anderson']
+  spec.email         = ['panic@semiosix.com']
+
+  spec.summary       = %q{Wrapper for ModSecurity with Rack middleware}
+  spec.description   = %q{A ruby ffi wrapper for ModSecurity that also provides a Rack middleware}
+  spec.homepage      = 'http://github.com/djellemah/rodsec'
+  spec.license       = 'MIT'
+
+  # Prevent pushing this gem to RubyGems.org. To allow pushes either set the 'allowed_push_host'
+  # to allow pushing to a single host or delete this section to allow pushing to any host.
+  if spec.respond_to?(:metadata)
+    spec.metadata['allowed_push_host'] = "https://rubygems.org"
+  else
+    raise 'RubyGems 2.0 or newer is required to protect against public gem pushes.'
+  end
+
+  spec.files         = `git ls-files -z`.split("\x0").reject do |f|
+    f.match(%r{^(test|spec(?!/config)|features)/})
+  end
+  spec.bindir        = 'exe'
+  spec.executables   = spec.files.grep(%r{^exe/}) { |f| File.basename(f) }
+  spec.require_paths = ['lib']
+
+  spec.extensions << %q[ext/msc_intervention/extconf.rb]
+
+  spec.add_development_dependency 'bundler', '~> 1.15'
+  spec.add_development_dependency 'rake', '~> 10.0'
+  spec.add_development_dependency 'rspec', '~> 3.0'
+  spec.add_development_dependency 'pry'
+  spec.add_development_dependency 'rack', '~> 2'
+  spec.add_development_dependency 'rake-compiler', '>= 1.0.5'
+end

data/spec/config/crs-setup.conf

@@ -0,0 +1,787 @@
+# ------------------------------------------------------------------------
+# OWASP ModSecurity Core Rule Set ver.3.0.2
+# Copyright (c) 2006-2016 Trustwave and contributors. All rights reserved.
+#
+# The OWASP ModSecurity Core Rule Set is distributed under
+# Apache Software License (ASL) version 2
+# Please see the enclosed LICENSE file for full details.
+# ------------------------------------------------------------------------
+
+
+#
+# -- [[ Introduction ]] --------------------------------------------------------
+#
+# The OWASP ModSecurity Core Rule Set (CRS) is a set of generic attack
+# detection rules that provide a base level of protection for any web
+# application. They are written for the open source, cross-platform
+# ModSecurity Web Application Firewall.
+#
+# See also:
+# https://modsecurity.org/crs/
+# https://github.com/SpiderLabs/owasp-modsecurity-crs
+# https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project
+#
+
+
+#
+# -- [[ System Requirements ]] -------------------------------------------------
+#
+# CRS requires ModSecurity version 2.8.0 or above.
+# We recommend to always use the newest ModSecurity version.
+#
+# The configuration directives/settings in this file are used to control
+# the OWASP ModSecurity CRS. These settings do **NOT** configure the main
+# ModSecurity settings (modsecurity.conf) such as SecRuleEngine,
+# SecRequestBodyAccess, SecAuditEngine, SecDebugLog, and XML processing.
+#
+# The CRS assumes that modsecurity.conf has been loaded. If you don't have this
+# file, you can get it from:
+# https://github.com/SpiderLabs/ModSecurity/blob/master/modsecurity.conf-recommended
+#
+# The order of file inclusion in your webserver configuration should always be:
+# 1. modsecurity.conf
+# 2. crs-setup.conf (this file)
+# 3. rules/*.conf (the CRS rule files)
+#
+# Please refer to the INSTALL file for detailed installation instructions.
+#
+
+
+#
+# -- [[ Mode of Operation: Anomaly Scoring vs. Self-Contained ]] ---------------
+#
+# The CRS can run in two modes:
+#
+# -- [[ Anomaly Scoring Mode (default) ]] --
+# In CRS3, anomaly mode is the default and recommended mode, since it gives the
+# most accurate log information and offers the most flexibility in setting your
+# blocking policies. It is also called "collaborative detection mode".
+# In this mode, each matching rule increases an 'anomaly score'.
+# At the conclusion of the inbound rules, and again at the conclusion of the
+# outbound rules, the anomaly score is checked, and the blocking evaluation
+# rules apply a disruptive action, by default returning an error 403.
+#
+# -- [[ Self-Contained Mode ]] --
+# In this mode, rules apply an action instantly. This was the CRS2 default.
+# It can lower resource usage, at the cost of less flexibility in blocking policy
+# and less informative audit logs (only the first detected threat is logged).
+# Rules inherit the disruptive action that you specify (i.e. deny, drop, etc).
+# The first rule that matches will execute this action. In most cases this will
+# cause evaluation to stop after the first rule has matched, similar to how many
+# IDSs function.
+#
+# -- [[ Alert Logging Control ]] --
+# In the mode configuration, you must also adjust the desired logging options.
+# There are three common options for dealing with logging. By default CRS enables
+# logging to the webserver error log (or Event viewer) plus detailed logging to
+# the ModSecurity audit log (configured under SecAuditLog in modsecurity.conf).
+#
+# - To log to both error log and ModSecurity audit log file, use: "log,auditlog"
+# - To log *only* to the ModSecurity audit log file, use: "nolog,auditlog"
+# - To log *only* to the error log file, use: "log,noauditlog"
+#
+# Examples for the various modes follow.
+# You must leave one of the following options enabled.
+# Note that you must specify the same line for phase:1 and phase:2.
+#
+
+# Default: Anomaly Scoring mode, log to error log, log to ModSecurity audit log
+# - By default, offending requests are blocked with an error 403 response.
+# - To change the disruptive action, see RESPONSE-999-EXCEPTIONS.conf.example
+#   and review section 'Changing the Disruptive Action for Anomaly Mode'.
+# - In Apache, you can use ErrorDocument to show a friendly error page or
+#   perform a redirect: https://httpd.apache.org/docs/2.4/custom-error.html
+#
+# SecDefaultAction "phase:1,log,auditlog,pass"
+# SecDefaultAction "phase:2,log,auditlog,pass"
+
+# this works better for rodsec because it does write an audit file, and sends
+# all log messages to Rodsec's logging
+SecDefaultAction "phase:1,log,noauditlog,pass"
+SecDefaultAction "phase:2,log,noauditlog,pass"
+
+# Example: Anomaly Scoring mode, log only to ModSecurity audit log
+# - By default, offending requests are blocked with an error 403 response.
+# - To change the disruptive action, see RESPONSE-999-EXCEPTIONS.conf.example
+#   and review section 'Changing the Disruptive Action for Anomaly Mode'.
+# - In Apache, you can use ErrorDocument to show a friendly error page or
+#   perform a redirect: https://httpd.apache.org/docs/2.4/custom-error.html
+#
+# SecDefaultAction "phase:1,nolog,auditlog,pass"
+# SecDefaultAction "phase:2,nolog,auditlog,pass"
+
+# Example: Self-contained mode, return error 403 on blocking
+# - In this configuration the default disruptive action becomes 'deny'. After a
+#   rule triggers, it will stop processing the request and return an error 403.
+# - You can also use a different error status, such as 404, 406, et cetera.
+# - In Apache, you can use ErrorDocument to show a friendly error page or
+#   perform a redirect: https://httpd.apache.org/docs/2.4/custom-error.html
+#
+# SecDefaultAction "phase:1,log,auditlog,deny,status:403"
+# SecDefaultAction "phase:2,log,auditlog,deny,status:403"
+
+# Example: Self-contained mode, redirect back to homepage on blocking
+# - In this configuration the 'tag' action includes the Host header data in the
+#   log. This helps to identify which virtual host triggered the rule (if any).
+# - Note that this might cause redirect loops in some situations; for example
+#   if a Cookie or User-Agent header is blocked, it will also be blocked when
+#   the client subsequently tries to access the homepage. You can also redirect
+#   to another custom URL.
+# SecDefaultAction "phase:1,log,auditlog,redirect:'http://%{request_headers.host}/',tag:'Host: %{request_headers.host}'"
+# SecDefaultAction "phase:2,log,auditlog,redirect:'http://%{request_headers.host}/',tag:'Host: %{request_headers.host}'"
+
+
+#
+# -- [[ Paranoia Level Initialization ]] ---------------------------------------
+#
+# The Paranoia Level (PL) setting allows you to choose the desired level
+# of rule checks.
+#
+# With each paranoia level increase, the CRS enables additional rules
+# giving you a higher level of security. However, higher paranoia levels
+# also increase the possibility of blocking some legitimate traffic due to
+# false alarms (also named false positives or FPs). If you use higher
+# paranoia levels, it is likely that you will need to add some exclusion
+# rules for certain requests and applications receiving complex input.
+#
+# - A paranoia level of 1 is default. In this level, most core rules
+#   are enabled. PL1 is advised for beginners, installations
+#   covering many different sites and applications, and for setups
+#   with standard security requirements.
+#   At PL1 you should face FPs rarely. If you encounter FPs, please
+#   open an issue on the CRS GitHub site and don't forget to attach your
+#   complete Audit Log record for the request with the issue.
+# - Paranoia level 2 includes many extra rules, for instance enabling
+#   many regexp-based SQL and XSS injection protections, and adding
+#   extra keywords checked for code injections. PL2 is advised
+#   for moderate to experienced users desiring more complete coverage
+#   and for installations with elevated security requirements.
+#   PL2 comes with some FPs which you need to handle.
+# - Paranoia level 3 enables more rules and keyword lists, and tweaks
+#   limits on special characters used. PL3 is aimed at users experienced
+#   at the handling of FPs and at installations with a high security
+#   requirement.
+# - Paranoia level 4 further restricts special characters.
+#   The highest level is advised for experienced users protecting
+#   installations with very high security requirements. Running PL4 will
+#   likely produce a very high number of FPs which have to be
+#   treated before the site can go productive.
+#
+# Rules in paranoia level 2 or higher will log their PL to the audit log;
+# example: [tag "paranoia-level/2"]. This allows you to deduct from the
+# audit log how the WAF behavior is affected by paranoia level.
+#
+# Uncomment this rule to change the default:
+#
+#SecAction \
+#  "id:900000,\
+#   phase:1,\
+#   nolog,\
+#   pass,\
+#   t:none,\
+#   setvar:tx.paranoia_level=1"
+
+# for testing, we want to see more rules broken
+SecAction \
+  "id:900000,\
+   phase:1,\
+   nolog,\
+   pass,\
+   t:none,\
+   setvar:tx.paranoia_level=3"
+
+#
+# -- [[ Anomaly Mode Severity Levels ]] ----------------------------------------
+#
+# Each rule in the CRS has an associated severity level.
+# These are the default scoring points for each severity level.
+# These settings will be used to increment the anomaly score if a rule matches.
+# You may adjust these points to your liking, but this is usually not needed.
+#
+# - CRITICAL severity: Anomaly Score of 5.
+#       Mostly generated by the application attack rules (93x and 94x files).
+# - ERROR severity: Anomaly Score of 4.
+#       Generated mostly from outbound leakage rules (95x files).
+# - WARNING severity: Anomaly Score of 3.
+#       Generated mostly by malicious client rules (91x files).
+# - NOTICE severity: Anomaly Score of 2.
+#       Generated mostly by the protocol rules (92x files).
+#
+# In anomaly mode, these scores are cumulative.
+# So it's possible for a request to hit multiple rules.
+#
+# (Note: In this file, we use 'phase:1' to set CRS configuration variables.
+# In general, 'phase:request' is used. However, we want to make absolutely sure
+# that all configuration variables are set before the CRS rules are processed.)
+#
+#SecAction \
+# "id:900100,\
+#  phase:1,\
+#  nolog,\
+#  pass,\
+#  t:none,\
+#  setvar:tx.critical_anomaly_score=5,\
+#  setvar:tx.error_anomaly_score=4,\
+#  setvar:tx.warning_anomaly_score=3,\
+#  setvar:tx.notice_anomaly_score=2"
+
+
+#
+# -- [[ Anomaly Mode Blocking Threshold Levels ]] ------------------------------
+#
+# Here, you can specify at which cumulative anomaly score an inbound request,
+# or outbound response, gets blocked.
+#
+# Most detected inbound threats will give a critical score of 5.
+# Smaller violations, like violations of protocol/standards, carry lower scores.
+#
+# [ At default value ]
+# If you keep the blocking thresholds at the defaults, the CRS will work
+# similarly to previous CRS versions: a single critical rule match will cause
+# the request to be blocked and logged.
+#
+# [ Using higher values ]
+# If you want to make the CRS less sensitive, you can increase the blocking
+# thresholds, for instance to 7 (which would require multiple rule matches
+# before blocking) or 10 (which would require at least two critical alerts - or
+# a combination of many lesser alerts), or even higher. However, increasing the
+# thresholds might cause some attacks to bypass the CRS rules or your policies.
+#
+# [ New deployment strategy: Starting high and decreasing ]
+# It is a common practice to start a fresh CRS installation with elevated
+# anomaly scoring thresholds (>100) and then lower the limits as your
+# confidence in the setup grows. You may also look into the Sampling
+# Percentage section below for a different strategy to ease into a new
+# CRS installation.
+#
+# [ Anomaly Threshold / Paranoia Level Quadrant ]
+#
+#     High Anomaly Limit   |   High Anomaly Limit
+#     Low Paranoia Level   |   High Paranoia Level
+#     -> Fresh Site        |   -> Experimental Site
+# ------------------------------------------------------
+#     Low Anomaly Limit    |   Low Anomaly Limit
+#     Low Paranoia Level   |   High Paranoia Level
+#     -> Standard Site     |   -> High Security Site
+#
+# Uncomment this rule to change the defaults:
+#
+#SecAction \
+# "id:900110,\
+#  phase:1,\
+#  nolog,\
+#  pass,\
+#  t:none,\
+#  setvar:tx.inbound_anomaly_score_threshold=5,\
+#  setvar:tx.outbound_anomaly_score_threshold=4"
+
+#
+# -- [[ Application Specific Rule Exclusions ]] ----------------------------------------
+#
+# Some well-known applications may undertake actions that appear to be
+# malicious. This includes actions such as allowing HTML or Javascript within
+# parameters. In such cases the CRS aims to prevent false positives by allowing
+# administrators to enable prebuilt, application specific exclusions on an
+# application by application basis.
+# These application specific exclusions are distinct from the rules that would
+# be placed in the REQUEST-900-EXCLUSION-RULES-BEFORE-CRS configuration file as
+# they are prebuilt for specific applications. The 'REQUEST-900' file is
+# designed for users to add their own custom exclusions. Note, using these
+# application specific exclusions may loosen restrictions of the CRS,
+# especially if used with an application they weren't designed for. As a result
+# they should be applied with care.
+# To use this functionality you must specify a supported application. To do so
+# uncomment rule 900130. In addition to uncommenting the rule you will need to
+# specify which application(s) you'd like to enable exclusions for. Only a
+# (very) limited set of applications are currently supported, please use the
+# filenames prefixed with 'REQUEST-903' to guide you in your selection.
+# Such filenames use the following convention:
+# REQUEST-903.9XXX-{APPNAME}-EXCLUSIONS-RULES.conf
+#
+# It is recommended if you run multiple web applications on your site to limit
+# the effects of the exclusion to only the path where the excluded webapp
+# resides using a rule similar to the following example:
+# SecRule REQUEST_URI "@beginsWith /wordpress/" setvar:crs_exclusions_wordpress=1
+
+#
+# Modify and uncomment this rule to select which application:
+#
+#SecAction \
+# "id:900130,\
+#  phase:1,\
+#  nolog,\
+#  pass,\
+#  t:none,\
+#  setvar:tx.crs_exclusions_drupal=1,\
+#  setvar:tx.crs_exclusions_wordpress=1"
+
+#
+# -- [[ HTTP Policy Settings ]] ------------------------------------------------
+#
+# This section defines your policies for the HTTP protocol, such as:
+# - allowed HTTP versions, HTTP methods, allowed request Content-Types
+# - forbidden file extensions (e.g. .bak, .sql) and request headers (e.g. Proxy)
+#
+# These variables are used in the following rule files:
+# - REQUEST-911-METHOD-ENFORCEMENT.conf
+# - REQUEST-912-DOS-PROTECTION.conf
+# - REQUEST-920-PROTOCOL-ENFORCEMENT.conf
+
+# HTTP methods that a client is allowed to use.
+# Default: GET HEAD POST OPTIONS
+# Example: for RESTful APIs, add the following methods: PUT PATCH DELETE
+# Example: for WebDAV, add the following methods: CHECKOUT COPY DELETE LOCK
+#          MERGE MKACTIVITY MKCOL MOVE PROPFIND PROPPATCH PUT UNLOCK
+# Uncomment this rule to change the default.
+#SecAction \
+# "id:900200,\
+#  phase:1,\
+#  nolog,\
+#  pass,\
+#  t:none,\
+#  setvar:'tx.allowed_methods=GET HEAD POST OPTIONS'"
+
+# Content-Types that a client is allowed to send in a request.
+# Default: application/x-www-form-urlencoded|multipart/form-data|text/xml|\
+# application/xml|application/soap+xml|application/x-amf|application/json|\
+# application/octet-stream|text/plain
+# Uncomment this rule to change the default.
+#SecAction \
+# "id:900220,\
+#  phase:1,\
+#  nolog,\
+#  pass,\
+#  t:none,\
+#  setvar:'tx.allowed_request_content_type=application/x-www-form-urlencoded|multipart/form-data|text/xml|application/xml|application/soap+xml|application/x-amf|application/json|application/octet-stream|text/plain'"
+
+# Allowed HTTP versions.
+# Default: HTTP/1.0 HTTP/1.1 HTTP/2 HTTP/2.0
+# Example for legacy clients: HTTP/0.9 HTTP/1.0 HTTP/1.1 HTTP/2 HTTP/2.0
+# Note that some web server versions use 'HTTP/2', some 'HTTP/2.0', so
+# we include both version strings by default.
+# Uncomment this rule to change the default.
+#SecAction \
+# "id:900230,\
+#  phase:1,\
+#  nolog,\
+#  pass,\
+#  t:none,\
+#  setvar:'tx.allowed_http_versions=HTTP/1.0 HTTP/1.1 HTTP/2 HTTP/2.0'"
+
+# Forbidden file extensions.
+# Guards against unintended exposure of development/configuration files.
+# Default: .asa/ .asax/ .ascx/ .axd/ .backup/ .bak/ .bat/ .cdx/ .cer/ .cfg/ .cmd/ .com/ .config/ .conf/ .cs/ .csproj/ .csr/ .dat/ .db/ .dbf/ .dll/ .dos/ .htr/ .htw/ .ida/ .idc/ .idq/ .inc/ .ini/ .key/ .licx/ .lnk/ .log/ .mdb/ .old/ .pass/ .pdb/ .pol/ .printer/ .pwd/ .resources/ .resx/ .sql/ .sys/ .vb/ .vbs/ .vbproj/ .vsdisco/ .webinfo/ .xsd/ .xsx/
+# Example: .bak/ .config/ .conf/ .db/ .ini/ .log/ .old/ .pass/ .pdb/ .sql/
+# Uncomment this rule to change the default.
+#SecAction \
+# "id:900240,\
+#  phase:1,\
+#  nolog,\
+#  pass,\
+#  t:none,\
+#  setvar:'tx.restricted_extensions=.asa/ .asax/ .ascx/ .axd/ .backup/ .bak/ .bat/ .cdx/ .cer/ .cfg/ .cmd/ .com/ .config/ .conf/ .cs/ .csproj/ .csr/ .dat/ .db/ .dbf/ .dll/ .dos/ .htr/ .htw/ .ida/ .idc/ .idq/ .inc/ .ini/ .key/ .licx/ .lnk/ .log/ .mdb/ .old/ .pass/ .pdb/ .pol/ .printer/ .pwd/ .resources/ .resx/ .sql/ .sys/ .vb/ .vbs/ .vbproj/ .vsdisco/ .webinfo/ .xsd/ .xsx/'"
+
+# Forbidden request headers.
+# Header names should be lowercase, enclosed by /slashes/ as delimiters.
+# Blocking Proxy header prevents 'httpoxy' vulnerability: https://httpoxy.org
+# Default: /proxy/ /lock-token/ /content-range/ /translate/ /if/
+# Uncomment this rule to change the default.
+#SecAction \
+# "id:900250,\
+#  phase:1,\
+#  nolog,\
+#  pass,\
+#  t:none,\
+#  setvar:'tx.restricted_headers=/proxy/ /lock-token/ /content-range/ /translate/ /if/'"
+
+# File extensions considered static files.
+# Extensions include the dot, lowercase, enclosed by /slashes/ as delimiters.
+# Used in DoS protection rule. See section "Anti-Automation / DoS Protection".
+# Default: /.jpg/ /.jpeg/ /.png/ /.gif/ /.js/ /.css/ /.ico/ /.svg/ /.webp/
+# Uncomment this rule to change the default.
+#SecAction \
+# "id:900260,\
+#  phase:1,\
+#  nolog,\
+#  pass,\
+#  t:none,\
+#  setvar:'tx.static_extensions=/.jpg/ /.jpeg/ /.png/ /.gif/ /.js/ /.css/ /.ico/ /.svg/ /.webp/'"
+
+
+#
+# -- [[ HTTP Argument/Upload Limits ]] -----------------------------------------
+#
+# Here you can define optional limits on HTTP get/post parameters and uploads.
+# This can help to prevent application specific DoS attacks.
+#
+# These values are checked in REQUEST-920-PROTOCOL-ENFORCEMENT.conf.
+# Beware of blocking legitimate traffic when enabling these limits.
+#
+
+# Block request if number of arguments is too high
+# Default: unlimited
+# Example: 255
+# Uncomment this rule to set a limit.
+#SecAction \
+# "id:900300,\
+#  phase:1,\
+#  nolog,\
+#  pass,\
+#  t:none,\
+#  setvar:tx.max_num_args=255"
+
+# Block request if the length of any argument name is too high
+# Default: unlimited
+# Example: 100
+# Uncomment this rule to set a limit.
+#SecAction \
+# "id:900310,\
+#  phase:1,\
+#  nolog,\
+#  pass,\
+#  t:none,\
+#  setvar:tx.arg_name_length=100"
+
+# Block request if the length of any argument value is too high
+# Default: unlimited
+# Example: 400
+# Uncomment this rule to set a limit.
+#SecAction \
+# "id:900320,\
+#  phase:1,\
+#  nolog,\
+#  pass,\
+#  t:none,\
+#  setvar:tx.arg_length=400"
+
+# Block request if the total length of all combined arguments is too high
+# Default: unlimited
+# Example: 64000
+# Uncomment this rule to set a limit.
+#SecAction \
+# "id:900330,\
+#  phase:1,\
+#  nolog,\
+#  pass,\
+#  t:none,\
+#  setvar:tx.total_arg_length=64000"
+
+# Block request if the file size of any individual uploaded file is too high
+# Default: unlimited
+# Example: 1048576
+# Uncomment this rule to set a limit.
+#SecAction \
+# "id:900340,\
+#  phase:1,\
+#  nolog,\
+#  pass,\
+#  t:none,\
+#  setvar:tx.max_file_size=1048576"
+
+# Block request if the total size of all combined uploaded files is too high
+# Default: unlimited
+# Example: 1048576
+# Uncomment this rule to set a limit.
+#SecAction \
+# "id:900350,\
+#  phase:1,\
+#  nolog,\
+#  pass,\
+#  t:none,\
+#  setvar:tx.combined_file_sizes=1048576"
+
+
+#
+# -- [[ Easing In / Sampling Percentage ]] -------------------------------------
+#
+# Adding the Core Rule Set to an existing productive site can lead to false
+# positives, unexpected performance issues and other undesired side effects.
+#
+# It can be beneficial to test the water first by enabling the CRS for a
+# limited number of requests only and then, when you have solved the issues (if
+# any) and you have confidence in the setup, to raise the ratio of requests
+# being sent into the ruleset.
+#
+# Adjust the percentage of requests that are funnelled into the Core Rules by
+# setting TX.sampling_percentage below. The default is 100, meaning that every
+# request gets checked by the CRS.  The selection of requests, which are going
+# to be checked, is based on a pseudo random number generated by ModSecurity.
+#
+# If a request is allowed to pass without being checked by the CRS, there is no
+# entry in the audit log (for performance reasons), but an error log entry is
+# written.  If you want to disable the error log entry, then issue the
+# following directive somewhere after the inclusion of the CRS
+# (E.g., RESPONSE-999-EXCEPTIONS.conf).
+#
+# SecRuleUpdateActionById 901150 "nolog"
+#
+# ATTENTION: If this TX.sampling_percentage is below 100, then some of the
+# requests will bypass the Core Rules completely and you lose the ability to
+# protect your service with ModSecurity.
+#
+# Uncomment this rule to enable this feature:
+#
+#SecAction "id:900400,\
+#  phase:1,\
+#  pass,\
+#  nolog,\
+#  setvar:tx.sampling_percentage=100"
+
+
+#
+# -- [[ Project Honey Pot HTTP Blacklist ]] ------------------------------------
+#
+# Optionally, you can check the client IP address against the Project Honey Pot
+# HTTPBL (dnsbl.httpbl.org). In order to use this, you need to register to get a
+# free API key. Set it here with SecHttpBlKey.
+#
+# Project Honeypot returns multiple different malicious IP types.
+# You may specify which you want to block by enabling or disabling them below.
+#
+# Ref: https://www.projecthoneypot.org/httpbl.php
+# Ref: https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#wiki-SecHttpBlKey
+#
+# Uncomment these rules to use this feature:
+#
+#SecHttpBlKey XXXXXXXXXXXXXXXXX
+#SecAction "id:900500,\
+#  phase:1,\
+#  nolog,\
+#  pass,\
+#  t:none,\
+#  setvar:tx.block_search_ip=1,\
+#  setvar:tx.block_suspicious_ip=1,\
+#  setvar:tx.block_harvester_ip=1,\
+#  setvar:tx.block_spammer_ip=1"
+
+
+#
+# -- [[ GeoIP Database ]] ------------------------------------------------------
+#
+# There are some rulesets that inspect geolocation data of the client IP address
+# (geoLookup). The CRS uses geoLookup to implement optional country blocking.
+#
+# To use geolocation, we make use of the MaxMind GeoIP database.
+# This database is not included with the CRS and must be downloaded.
+# You should also update the database regularly, for instance every month.
+# The CRS contains a tool to download it to util/geo-location/GeoIP.dat:
+#   util/upgrade.py --geoip
+#
+# This product includes GeoLite data created by MaxMind, available from:
+# http://www.maxmind.com.
+#
+# Ref: http://blog.spiderlabs.com/2010/10/detecting-malice-with-modsecurity-geolocation-data.html
+# Ref: http://blog.spiderlabs.com/2010/11/detecting-malice-with-modsecurity-ip-forensics.html
+#
+# Uncomment this rule to use this feature:
+#
+#SecGeoLookupDB util/geo-location/GeoIP.dat
+
+
+#
+# -=[ Block Countries ]=-
+#
+# Rules in the IP Reputation file can check the client against a list of high
+# risk country codes. These countries have to be defined in the variable
+# tx.high_risk_country_codes via their ISO 3166 two-letter country code:
+# https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2#Officially_assigned_code_elements
+#
+# If you are sure that you are not getting any legitimate requests from a given
+# country, then you can disable all access from that country via this variable.
+# The rule performing the test has the rule id 910100.
+#
+# This rule requires SecGeoLookupDB to be enabled and the GeoIP database to be
+# downloaded (see the section "GeoIP Database" above.)
+#
+# By default, the list is empty. A list used by some sites was the following:
+# setvar:'tx.high_risk_country_codes=UA ID YU LT EG RO BG TR RU PK MY CN'"
+#
+# Uncomment this rule to use this feature:
+#
+#SecAction \
+# "id:900600,\
+#  phase:1,\
+#  nolog,\
+#  pass,\
+#  t:none,\
+#  setvar:'tx.high_risk_country_codes='"
+
+
+#
+# -- [[ Anti-Automation / DoS Protection ]] ------------------------------------
+#
+# Optional DoS protection against clients making requests too quickly.
+#
+# When a client is making more than 100 requests (excluding static files) within
+# 60 seconds, this is considered a 'burst'. After two bursts, the client is
+# blocked for 600 seconds.
+#
+# Requests to static files are not counted towards DoS; they are listed in the
+# 'tx.static_extensions' setting, which you can change in this file (see
+# section "HTTP Policy Settings").
+#
+# For a detailed description, see rule file REQUEST-912-DOS-PROTECTION.conf.
+#
+# Uncomment this rule to use this feature:
+#
+#SecAction \
+# "id:900700,\
+#  phase:1,\
+#  nolog,\
+#  pass,\
+#  t:none,\
+#  setvar:'tx.dos_burst_time_slice=60',\
+#  setvar:'tx.dos_counter_threshold=100',\
+#  setvar:'tx.dos_block_timeout=600'"
+
+
+#
+# -- [[ Check UTF-8 encoding ]] ------------------------------------------------
+#
+# The CRS can optionally check request contents for invalid UTF-8 encoding.
+# We only want to apply this check if UTF-8 encoding is actually used by the
+# site; otherwise it will result in false positives.
+#
+# Uncomment this rule to use this feature:
+#
+#SecAction \
+# "id:900950,\
+#  phase:1,\
+#  nolog,\
+#  pass,\
+#  t:none,\
+#  setvar:tx.crs_validate_utf8_encoding=1"
+
+
+#
+# -- [[ Blocking Based on IP Reputation ]] ------------------------------------
+#
+# Blocking based on reputation is permanent in the CRS. Unlike other rules,
+# which look at the indvidual request, the blocking of IPs is based on
+# a persistent record in the IP collection, which remains active for a 
+# certain amount of time.
+#
+# There are two ways an individual client can become flagged for blocking:
+# - External information (RBL, GeoIP, etc.)
+# - Internal information (Core Rules)
+#
+# The record in the IP collection carries a flag, which tags requests from
+# individual clients with a flag named IP.reput_block_flag.
+# But the flag alone is not enough to have a client blocked. There is also
+# a global switch named tx.do_reput_block. This is off by default. If you set
+# it to 1 (=On), requests from clients with the IP.reput_block_flag will
+# be blocked for a certain duration.
+#
+# Variables
+# ip.reput_block_flag      Blocking flag for the IP collection record
+# ip.reput_block_reason    Reason (= rule message) that caused to blocking flag
+# tx.do_reput_block        Switch deciding if we really block based on flag
+# tx.reput_block_duration  Setting to define the duration of a block
+#
+# It may be important to know, that all the other core rules are skipped for
+# requests, when it is clear that they carry the blocking flag in question.
+#
+# Uncomment this rule to use this feature:
+#
+#SecAction \
+# "id:900960,\
+#  phase:1,\
+#  nolog,\
+#  pass,\
+#  t:none,\
+#  setvar:tx.do_reput_block=1"
+#
+# Uncomment this rule to change the blocking time:
+# Default: 300 (5 minutes)
+#
+#SecAction \
+# "id:900970,\
+#  phase:1,\
+#  nolog,\
+#  pass,\
+#  t:none,\
+#  setvar:tx.reput_block_duration=300"
+
+
+#
+# -- [[ Collection timeout ]] --------------------------------------------------
+#
+# Set the SecCollectionTimeout directive from the ModSecurity default (1 hour)
+# to a lower setting which is appropriate to most sites.
+# This increases performance by cleaning out stale collection (block) entries.
+#
+# This value should be greater than or equal to:
+# tx.reput_block_duration (see section "Blocking Based on IP Reputation") and
+# tx.dos_block_timeout (see section "Anti-Automation / DoS Protection").
+#
+# Ref: https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#wiki-SecCollectionTimeout
+
+# Please keep this directive uncommented.
+# Default: 600 (10 minutes)
+SecCollectionTimeout 600
+
+
+#
+# -- [[ Debug Mode ]] ----------------------------------------------------------
+#
+# To enable rule development and debugging, CRS has an optional debug mode
+# that does not block a request, but instead sends detection information
+# back to the HTTP client.
+#
+# This functionality is currently only supported with the Apache web server.
+# The Apache mod_headers module is required.
+#
+# In debug mode, the webserver inserts "X-WAF-Events" / "X-WAF-Score"
+# response headers whenever a debug client makes a request. Example:
+#
+#   # curl -v 'http://192.168.1.100/?foo=../etc/passwd'
+#   X-WAF-Events: TX:930110-OWASP_CRS/WEB_ATTACK/DIR_TRAVERSAL-REQUEST_URI,
+#                TX:930120-OWASP_CRS/WEB_ATTACK/FILE_INJECTION-ARGS:foo,
+#                TX:932160-OWASP_CRS/WEB_ATTACK/RCE-ARGS:foo
+#   X-WAF-Score: Total=15; sqli=0; xss=0; rfi=0; lfi=10; rce=5; php=0; http=0; ses=0
+#
+# To enable debug mode, include the RESPONSE-981-DEBUG.conf file.
+# This file resides in a separate folder, as it is not compatible with
+# nginx and IIS.
+#
+# You must specify the source IP address/network where you will be running the
+# tests from. The source IP will BYPASS all CRS blocking, and will be sent the
+# response headers as specified above. Be careful to only list your private
+# IP addresses/networks here.
+#
+# Tip: for regression testing of CRS or your own ModSecurity rules, you may
+# be interested in using the OWASP CRS regression testing suite instead.
+# View the file util/regression-tests/README for more information.
+#
+# Uncomment these rules, filling in your CRS path and the source IP address,
+# to enable debug mode:
+#
+#Include /path/to/crs/util/debug/RESPONSE-981-DEBUG.conf
+#SecRule REMOTE_ADDR "@ipMatch 192.168.1.100" \
+# "id:900980,\
+#  phase:1,\
+#  nolog,\
+#  pass,\
+#  t:none,\
+#  ctl:ruleEngine=DetectionOnly,\
+#  setvar:tx.crs_debug_mode=1"
+
+
+#
+# -- [[ End of setup ]] --------------------------------------------------------
+#
+# The CRS checks the tx.crs_setup_version variable to ensure that the setup
+# has been loaded. If you are not planning to use this setup template,
+# you must manually set the tx.crs_setup_version variable before including
+# the CRS rules/* files.
+#
+# The variable is a numerical representation of the CRS version number.
+# E.g., v3.0.0 is represented as 300.
+#
+SecAction \
+ "id:900990,\
+  phase:1,\
+  nolog,\
+  pass,\
+  t:none,\
+  setvar:tx.crs_setup_version=302"