iis: New improvements on the Wix installer

- Now the installation is divided in modules: ModSecurity and CRS.
- Added default configuration
- Configuration was moved to "Program Files" folder
- Build_msi script now using candle available in %PATH%

iis/build_msi.bat

@@ -1,19 +1,20 @@
 
-set WIX=C:\Program Files (x86)\WiX Toolset v3.7\bin
+
+set PATH="%PATH%;C:\Program Files (x86)\WiX Toolset v3.8\bin;C:\Program Files (x86)\WiX Toolset v3.7\bin;"
 set CURRENT_DIR=%cd%
 
 del installer.wix*
 
-"%WIX%\candle.exe" -ext WixUtilExtension -ext WixUIExtension "%CURRENT_DIR%\installer.wxs" -out "%CURRENT_DIR%\installer.wixobj" -dPlatform="x64"
+"candle.exe" -ext WixUtilExtension -ext WixUIExtension "%CURRENT_DIR%\installer.wxs" -out "%CURRENT_DIR%\installer.wixobj" -dPlatform="x64"
 @if NOT (%ERRORLEVEL%) == (0) goto build_failed
 
-"%WIX%\light.exe" -ext WixUtilExtension -ext WixUIExtension "%CURRENT_DIR%\installer.wixobj" -out "%CURRENT_DIR%\installer-64.msi" -dPlatform="x64"
+"light.exe" -ext WixUtilExtension -ext WixUIExtension "%CURRENT_DIR%\installer.wixobj" -out "%CURRENT_DIR%\installer-64.msi" -dPlatform="x64"
 @if NOT (%ERRORLEVEL%) == (0) goto build_failed
 
-"%WIX%\candle.exe" -ext WixUtilExtension -ext WixUIExtension "%CURRENT_DIR%\installer.wxs" -out "%CURRENT_DIR%\installer.wixobj" -dPlatform="x86"
+"candle.exe" -ext WixUtilExtension -ext WixUIExtension "%CURRENT_DIR%\installer.wxs" -out "%CURRENT_DIR%\installer.wixobj" -dPlatform="x86"
 @if NOT (%ERRORLEVEL%) == (0) goto build_failed
 
-"%WIX%\light.exe" -ext WixUtilExtension -ext WixUIExtension "%CURRENT_DIR%\installer.wixobj" -out "%CURRENT_DIR%\installer-32.msi" -dPlatform="x86"
+"light.exe" -ext WixUtilExtension -ext WixUIExtension "%CURRENT_DIR%\installer.wixobj" -out "%CURRENT_DIR%\installer-32.msi" -dPlatform="x86"
 @if NOT (%ERRORLEVEL%) == (0) goto build_failed
 
 exit /B 0

iis/wix/modsecurity.conf

@@ -0,0 +1,214 @@
+# based on modsecurity.conf-recommended
+# -- Rule engine initialization ----------------------------------------------
+
+# Enable ModSecurity, attaching it to every transaction. Use detection
+# only to start with, because that minimises the chances of post-installation
+# disruption.
+#
+SecRuleEngine DetectionOnly
+
+
+# -- Request body handling ---------------------------------------------------
+
+# Allow ModSecurity to access request bodies. If you don't, ModSecurity
+# won't be able to see any POST parameters, which opens a large security
+# hole for attackers to exploit.
+#
+SecRequestBodyAccess On
+
+
+# Enable XML request body parser.
+# Initiate XML Processor in case of xml content-type
+#
+SecRule REQUEST_HEADERS:Content-Type "text/xml" \
+     "id:'200000',phase:1,t:none,t:lowercase,pass,nolog,ctl:requestBodyProcessor=XML"
+
+
+# Maximum request body size we will accept for buffering. If you support
+# file uploads then the value given on the first line has to be as large
+# as the largest file you are willing to accept. The second value refers
+# to the size of data, with files excluded. You want to keep that value as
+# low as practical.
+#
+SecRequestBodyLimit 13107200
+SecRequestBodyNoFilesLimit 131072
+
+# Store up to 128 KB of request body data in memory. When the multipart
+# parser reachers this limit, it will start using your hard disk for
+# storage. That is slow, but unavoidable.
+#
+SecRequestBodyInMemoryLimit 131072
+
+# What do do if the request body size is above our configured limit.
+# Keep in mind that this setting will automatically be set to ProcessPartial
+# when SecRuleEngine is set to DetectionOnly mode in order to minimize
+# disruptions when initially deploying ModSecurity.
+#
+SecRequestBodyLimitAction Reject
+
+# Verify that we've correctly processed the request body.
+# As a rule of thumb, when failing to process a request body
+# you should reject the request (when deployed in blocking mode)
+# or log a high-severity alert (when deployed in detection-only mode).
+#
+SecRule REQBODY_ERROR "!@eq 0" \
+"id:'200001', phase:2,t:none,log,deny,status:400,msg:'Failed to parse request body.',logdata:'%{reqbody_error_msg}',severity:2"
+
+# By default be strict with what we accept in the multipart/form-data
+# request body. If the rule below proves to be too strict for your
+# environment consider changing it to detection-only. You are encouraged
+# _not_ to remove it altogether.
+#
+SecRule MULTIPART_STRICT_ERROR "!@eq 0" \
+"id:'200002',phase:2,t:none,log,deny,status:44, \
+msg:'Multipart request body failed strict validation: \
+PE %{REQBODY_PROCESSOR_ERROR}, \
+BQ %{MULTIPART_BOUNDARY_QUOTED}, \
+BW %{MULTIPART_BOUNDARY_WHITESPACE}, \
+DB %{MULTIPART_DATA_BEFORE}, \
+DA %{MULTIPART_DATA_AFTER}, \
+HF %{MULTIPART_HEADER_FOLDING}, \
+LF %{MULTIPART_LF_LINE}, \
+SM %{MULTIPART_MISSING_SEMICOLON}, \
+IQ %{MULTIPART_INVALID_QUOTING}, \
+IP %{MULTIPART_INVALID_PART}, \
+IH %{MULTIPART_INVALID_HEADER_FOLDING}, \
+FL %{MULTIPART_FILE_LIMIT_EXCEEDED}'"
+
+# Did we see anything that might be a boundary?
+#
+SecRule MULTIPART_UNMATCHED_BOUNDARY "!@eq 0" \
+"id:'200003',phase:2,t:none,log,deny,status:44,msg:'Multipart parser detected a possible unmatched boundary.'"
+
+# PCRE Tuning
+# We want to avoid a potential RegEx DoS condition
+#
+SecPcreMatchLimit 1000
+SecPcreMatchLimitRecursion 1000
+
+# Some internal errors will set flags in TX and we will need to look for these.
+# All of these are prefixed with "MSC_".  The following flags currently exist:
+#
+# MSC_PCRE_LIMITS_EXCEEDED: PCRE match limits were exceeded.
+#
+SecRule TX:/^MSC_/ "!@streq 0" \
+        "id:'200004',phase:2,t:none,deny,msg:'ModSecurity internal error flagged: %{MATCHED_VAR_NAME}'"
+
+
+# -- Response body handling --------------------------------------------------
+
+# Allow ModSecurity to access response bodies. 
+# You should have this directive enabled in order to identify errors
+# and data leakage issues.
+# 
+# Do keep in mind that enabling this directive does increases both
+# memory consumption and response latency.
+#
+#SecResponseBodyAccess On
+
+# Which response MIME types do you want to inspect? You should adjust the
+# configuration below to catch documents but avoid static files
+# (e.g., images and archives).
+#
+SecResponseBodyMimeType text/plain text/html text/xml
+
+# Buffer response bodies of up to 512 KB in length.
+SecResponseBodyLimit 524288
+
+# What happens when we encounter a response body larger than the configured
+# limit? By default, we process what we have and let the rest through.
+# That's somewhat less secure, but does not break any legitimate pages.
+#
+SecResponseBodyLimitAction ProcessPartial
+
+
+# -- Filesystem configuration ------------------------------------------------
+
+# The location where ModSecurity stores temporary files (for example, when
+# it needs to handle a file upload that is larger than the configured limit).
+# 
+# This default setting is chosen due to all systems have /tmp available however, 
+# this is less than ideal. It is recommended that you specify a location that's private.
+#
+SecTmpDir c:\inetpub\temp\
+
+# The location where ModSecurity will keep its persistent data.  This default setting 
+# is chosen due to all systems have /tmp available however, it
+# too should be updated to a place that other users can't access.
+#
+SecDataDir c:\inetpub\temp\
+
+
+# -- File uploads handling configuration -------------------------------------
+
+# The location where ModSecurity stores intercepted uploaded files. This
+# location must be private to ModSecurity. You don't want other users on
+# the server to access the files, do you?
+#
+#SecUploadDir /opt/modsecurity/var/upload/
+
+# By default, only keep the files that were determined to be unusual
+# in some way (by an external inspection script). For this to work you
+# will also need at least one file inspection rule.
+#
+#SecUploadKeepFiles RelevantOnly
+
+# Uploaded files are by default created with permissions that do not allow
+# any other user to access them. You may need to relax that if you want to
+# interface ModSecurity to an external program (e.g., an anti-virus).
+#
+#SecUploadFileMode 0600
+
+
+# -- Debug log configuration -------------------------------------------------
+
+# The default debug log configuration is to duplicate the error, warning
+# and notice messages from the error log.
+#
+#SecDebugLog /opt/modsecurity/var/log/debug.log
+#SecDebugLogLevel 3
+
+
+# -- Audit log configuration -------------------------------------------------
+
+# Log the transactions that are marked by a rule, as well as those that
+# trigger a server error (determined by a 5xx or 4xx, excluding 404,  
+# level response status codes).
+#
+#SecAuditEngine RelevantOnly
+#SecAuditLogRelevantStatus "^(?:5|4(?!04))"
+
+# Log everything we know about a transaction.
+#SecAuditLogParts ABIJDEFHZ
+
+# Use a single file for logging. This is much easier to look at, but
+# assumes that you will use the audit log only ocassionally.
+#
+#SecAuditLogType Serial
+#SecAuditLog c:\inetpub\log\modsec_audit.log
+
+# Specify the path for concurrent audit logging.
+#SecAuditLogStorageDir c:\inetpub\log\
+
+
+# -- Miscellaneous -----------------------------------------------------------
+
+# Use the most commonly used application/x-www-form-urlencoded parameter
+# separator. There's probably only one application somewhere that uses
+# something else so don't expect to change this value.
+#
+SecArgumentSeparator &
+
+# Settle on version 0 (zero) cookies, as that is what most applications
+# use. Using an incorrect cookie version may open your installation to
+# evasion attacks (against the rules that examine named cookies).
+#
+SecCookieFormat 0
+
+# Specify your Unicode Code Point.
+# This mapping is used by the t:urlDecodeUni transformation function
+# to properly map encoded data to your language. Properly setting
+# these directives helps to reduce false positives and negatives.
+#
+#SecUnicodeCodePage 20127
+#SecUnicodeMapFile unicode.mapping

iis/wix/modsecurity_crs_10_setup.conf

@@ -0,0 +1,428 @@
+# ---------------------------------------------------------------
+# Core ModSecurity Rule Set ver.2.2.6
+# Copyright (C) 2006-2012 Trustwave All rights reserved.
+#
+# The OWASP ModSecurity Core Rule Set is distributed under 
+# Apache Software License (ASL) version 2
+# Please see the enclosed LICENCE file for full details.
+# ---------------------------------------------------------------
+
+
+#
+# -- [[ Recommended Base Configuration ]] ------------------------------------------------- 
+#
+# The configuration directives/settings in this file are used to control
+# the OWASP ModSecurity CRS. These settings do **NOT** configure the main
+# ModSecurity settings such as:
+# 
+# - SecRuleEngine
+# - SecRequestBodyAccess
+# - SecAuditEngine
+# - SecDebugLog
+#
+# You should use the modsecurity.conf-recommended file that comes with the
+# ModSecurity source code archive.
+#
+# Ref: http://mod-security.svn.sourceforge.net/viewvc/mod-security/m2/trunk/modsecurity.conf-recommended
+#
+
+
+#
+# -- [[ Rule Version ]] -------------------------------------------------------------------
+#
+# Rule version data is added to the "Producer" line of Section H of the Audit log:
+#
+# - Producer: ModSecurity for Apache/2.7.0-rc1 (http://www.modsecurity.org/); OWASP_CRS/2.2.4.
+#
+# Ref: https://sourceforge.net/apps/mediawiki/mod-security/index.php?title=Reference_Manual#SecComponentSignature
+#
+SecComponentSignature "OWASP_CRS/2.2.6"
+
+
+#
+# -- [[ Modes of Operation: Self-Contained vs. Collaborative Detection ]] -----------------
+#
+# Each detection rule uses the "block" action which will inherit the SecDefaultAction
+# specified below.  Your settings here will determine which mode of operation you use.
+#
+# -- [[ Self-Contained Mode ]] --
+# Rules inherit the "deny" disruptive action.  The first rule that matches will block.
+#
+# -- [[ Collaborative Detection Mode ]] --
+# This is a "delayed blocking" mode of operation where each matching rule will inherit
+# the "pass" action and will only contribute to anomaly scores.  Transactional blocking
+# can be applied 
+#
+# -- [[ Alert Logging Control ]] --
+# You have three options -
+#
+# - To log to both the Apache error_log and ModSecurity audit_log file use: "log"
+# - To log *only* to the ModSecurity audit_log file use: "nolog,auditlog"
+# - To log *only* to the Apache error_log file use: "log,noauditlog"
+#
+# Ref: http://blog.spiderlabs.com/2010/11/advanced-topic-of-the-week-traditional-vs-anomaly-scoring-detection-modes.html
+# Ref: https://sourceforge.net/apps/mediawiki/mod-security/index.php?title=Reference_Manual#SecDefaultAction
+#
+SecDefaultAction "phase:1,deny,log"
+
+
+#
+# -- [[ Collaborative Detection Severity Levels ]] ----------------------------------------
+#
+# These are the default scoring points for each severity level.  You may
+# adjust these to you liking.  These settings will be used in macro expansion
+# in the rules to increment the anomaly scores when rules match.
+#
+# These are the default Severity ratings (with anomaly scores) of the individual rules -
+#
+#    - 2: Critical - Anomaly Score of 5.
+#         Is the highest severity level possible without correlation.  It is
+#         normally generated by the web attack rules (40 level files).
+#    - 3: Error - Anomaly Score of 4.
+#         Is generated mostly from outbound leakage rules (50 level files).
+#    - 4: Warning - Anomaly Score of 3.
+#         Is generated by malicious client rules (35 level files).
+#    - 5: Notice - Anomaly Score of 2.
+#         Is generated by the Protocol policy and anomaly files.
+#
+SecAction \
+  "id:'900001', \
+  phase:1, \
+  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, \
+  nolog, \
+  pass"
+
+
+#
+# -- [[ Collaborative Detection Scoring Threshold Levels ]] ------------------------------
+#
+# These variables are used in macro expansion in the 49 inbound blocking and 59
+# outbound blocking files.
+#
+# **MUST HAVE** ModSecurity v2.5.12 or higher to use macro expansion in numeric
+# operators.  If you have an earlier version, edit the 49/59 files directly to
+# set the appropriate anomaly score levels.
+#
+# You should set the score to the proper threshold you would prefer. If set to "5"
+# it will work similarly to previous Mod CRS rules and will create an event in the error_log
+# file if there are any rules that match.  If you would like to lessen the number of events
+# generated in the error_log file, you should increase the anomaly score threshold to
+# something like "20".  This would only generate an event in the error_log file if
+# there are multiple lower severity rule matches or if any 1 higher severity item matches.
+#
+SecAction \
+  "id:'900002', \
+  phase:1, \
+  t:none, \
+  setvar:tx.inbound_anomaly_score_level=5, \
+  nolog, \
+  pass"
+
+
+SecAction \
+  "id:'900003', \
+  phase:1, \
+  t:none, \
+  setvar:tx.outbound_anomaly_score_level=4, \
+  nolog, \
+  pass"
+
+
+# 
+# -- [[ Collaborative Detection Blocking ]] -----------------------------------------------
+#
+# This is a collaborative detection mode where each rule will increment an overall
+# anomaly score for the transaction. The scores are then evaluated in the following files:
+#
+# Inbound anomaly score - checked in the modsecurity_crs_49_inbound_blocking.conf file
+# Outbound anomaly score - checked in the modsecurity_crs_59_outbound_blocking.conf file
+#
+# If you want to use anomaly scoring mode, then uncomment this line.
+#
+#SecAction \
+  "id:'900004', \
+  phase:1, \
+  t:none, \
+  setvar:tx.anomaly_score_blocking=on, \
+  nolog, \
+  pass"
+
+
+#
+# -- [[ GeoIP Database ]] -----------------------------------------------------------------
+#
+# There are some rulesets that need to inspect the GEO data of the REMOTE_ADDR data.
+# 
+# You must first download the MaxMind GeoIP Lite City DB -
+#
+#       http://geolite.maxmind.com/download/geoip/database/GeoLiteCity.dat.gz
+#
+# You then need to define the proper path for the SecGeoLookupDb directive
+#
+# 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
+#
+#SecGeoLookupDb /opt/modsecurity/lib/GeoLiteCity.dat
+
+#
+# -- [[ Regression Testing Mode ]] --------------------------------------------------------
+#
+# If you are going to run the regression testing mode, you should uncomment the
+# following rule. It will enable DetectionOnly mode for the SecRuleEngine and
+# will enable Response Header tagging so that the client testing script can see
+# which rule IDs have matched.
+#
+# You must specify the your source IP address where you will be running the tests
+# from.
+#
+#SecRule REMOTE_ADDR "@ipMatch 192.168.1.100" \
+  "id:'900005', \
+  phase:1, \
+  t:none, \
+  ctl:ruleEngine=DetectionOnly, \
+  setvar:tx.regression_testing=1, \
+  nolog, \
+  pass"
+
+
+#
+# -- [[ HTTP Policy Settings ]] ----------------------------------------------------------
+#
+# Set the following policy settings here and they will be propagated to the 23 rules
+# file (modsecurity_common_23_request_limits.conf) by using macro expansion.  
+# If you run into false positives, you can adjust the settings here.
+#
+# Only the max number of args is uncommented by default as there are a high rate
+# of false positives.  Uncomment the items you wish to set.
+# 
+#
+# -- Maximum number of arguments in request limited
+SecAction \
+  "id:'900006', \
+  phase:1, \
+  t:none, \
+  setvar:tx.max_num_args=255, \
+  nolog, \
+  pass"
+
+#
+# -- Limit argument name length
+#SecAction \
+  "id:'900007', \
+  phase:1, \
+  t:none, \
+  setvar:tx.arg_name_length=100, \
+  nolog, \
+  pass"
+
+#
+# -- Limit value name length
+#SecAction \
+  "id:'900008', \
+  phase:1, \
+  t:none, \
+  setvar:tx.arg_length=400, \
+  nolog, \
+  pass"
+
+#
+# -- Limit arguments total length
+#SecAction \
+  "id:'900009', \
+  phase:1, \
+  t:none, \
+  setvar:tx.total_arg_length=64000, \
+  nolog, \
+  pass"
+
+#
+# -- Individual file size is limited
+#SecAction \
+  "id:'900010', \
+  phase:1, \
+  t:none, \
+  setvar:tx.max_file_size=1048576, \
+  nolog, \
+  pass"
+
+#
+# -- Combined file size is limited
+#SecAction \
+  "id:'900011', \
+  phase:1, \
+  t:none, \
+  setvar:tx.combined_file_sizes=1048576, \
+  nolog, \
+  pass"
+
+
+#
+# Set the following policy settings here and they will be propagated to the 30 rules
+# file (modsecurity_crs_30_http_policy.conf) by using macro expansion.  
+# If you run into false positves, you can adjust the settings here.
+#
+SecAction \
+  "id:'900012', \
+  phase:1, \
+  t:none, \
+  setvar:'tx.allowed_methods=GET HEAD POST OPTIONS', \
+  setvar:'tx.allowed_request_content_type=application/x-www-form-urlencoded|multipart/form-data|text/xml|application/xml|application/x-amf|application/json', \
+  setvar:'tx.allowed_http_versions=HTTP/0.9 HTTP/1.0 HTTP/1.1', \
+  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/', \
+  setvar:'tx.restricted_headers=/Proxy-Connection/ /Lock-Token/ /Content-Range/ /Translate/ /via/ /if/', \
+  nolog, \
+  pass"
+
+
+#
+# -- [[ Content Security Policy (CSP) Settings ]] -----------------------------------------
+#
+# The purpose of these settings is to send CSP response headers to
+# Mozilla FireFox users so that you can enforce how dynamic content
+# is used. CSP usage helps to prevent XSS attacks against your users.
+#  
+# Reference Link:
+#
+#	https://developer.mozilla.org/en/Security/CSP
+#
+# Uncomment this SecAction line if you want use CSP enforcement.
+# You need to set the appropriate directives and settings for your site/domain and
+# and activate the CSP file in the experimental_rules directory.
+# 
+# Ref: http://blog.spiderlabs.com/2011/04/modsecurity-advanced-topic-of-the-week-integrating-content-security-policy-csp.html
+#
+#SecAction \
+  "id:'900013', \
+  phase:1, \
+  t:none, \
+  setvar:tx.csp_report_only=1, \
+  setvar:tx.csp_report_uri=/csp_violation_report, \
+  setenv:'csp_policy=allow \'self\'; img-src *.yoursite.com; media-src *.yoursite.com; style-src *.yoursite.com; frame-ancestors *.yoursite.com; script-src *.yoursite.com; report-uri %{tx.csp_report_uri}', \
+  nolog, \
+  pass"
+
+
+#
+# -- [[ Brute Force Protection ]] ---------------------------------------------------------
+#
+# If you are using the Brute Force Protection rule set, then uncomment the following
+# lines and set the following variables:
+# - Protected URLs: resources to protect (e.g. login pages) - set to your login page
+# - Burst Time Slice Interval: time interval window to monitor for bursts
+# - Request Threshold: request # threshold to trigger a burst
+# - Block Period: temporary block timeout
+#
+#SecAction \
+  "id:'900014', \
+  phase:1, \
+  t:none, \
+  setvar:'tx.brute_force_protected_urls=/login.jsp /partner_login.php', \
+  setvar:'tx.brute_force_burst_time_slice=60', \
+  setvar:'tx.brute_force_counter_threshold=10', \
+  setvar:'tx.brute_force_block_timeout=300', \
+  nolog, \
+  pass"
+
+
+#
+# -- [[ DoS Protection ]] ----------------------------------------------------------------
+#
+# If you are using the DoS Protection rule set, then uncomment the following
+# lines and set the following variables:
+# - Burst Time Slice Interval: time interval window to monitor for bursts
+# - Request Threshold: request # threshold to trigger a burst
+# - Block Period: temporary block timeout
+#
+#SecAction \
+  "id:'900015', \
+  phase:1, \
+  t:none, \
+  setvar:'tx.dos_burst_time_slice=60', \
+  setvar:'tx.dos_counter_threshold=100', \
+  setvar:'tx.dos_block_timeout=600', \
+  nolog, \
+  pass"
+
+
+#
+# -- [[ Check UTF enconding ]] -----------------------------------------------------------
+#
+# 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 line if your site uses UTF8 encoding
+#SecAction \
+  "id:'900016', \
+  phase:1, \
+  t:none, \
+  setvar:tx.crs_validate_utf8_encoding=1, \
+  nolog, \
+  pass"
+
+
+#
+# -- [[ Enable XML Body Parsing ]] -------------------------------------------------------
+#
+# The rules in this file will trigger the XML parser upon an XML request
+#
+# Initiate XML Processor in case of xml content-type
+#
+SecRule REQUEST_HEADERS:Content-Type "text/xml" \
+  "id:'900017', \
+  phase:1, \
+  t:none,t:lowercase, \
+  nolog, \
+  pass, \
+  chain"
+	SecRule REQBODY_PROCESSOR "!@streq XML" \
+	  "ctl:requestBodyProcessor=XML"
+
+
+#
+# -- [[ Global and IP Collections ]] -----------------------------------------------------
+#
+# Create both Global and IP collections for rules to use
+# There are some CRS rules that assume that these two collections
+# have already been initiated.
+#
+SecRule REQUEST_HEADERS:User-Agent "^(.*)$" \
+  "id:'900018', \
+  phase:1, \
+  t:none,t:sha1,t:hexEncode, \
+  setvar:tx.ua_hash=%{matched_var}, \
+  nolog, \
+  pass"
+
+
+SecRule REQUEST_HEADERS:x-forwarded-for "^\b(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})\b" \
+  "id:'900019', \
+  phase:1, \
+  t:none, \
+  capture, \
+  setvar:tx.real_ip=%{tx.1}, \
+  nolog, \
+  pass"
+
+
+SecRule &TX:REAL_IP "!@eq 0" \
+  "id:'900020', \
+  phase:1, \
+  t:none, \
+  initcol:global=global, \
+  initcol:ip=%{tx.real_ip}_%{tx.ua_hash}, \
+  nolog, \
+  pass"
+
+
+SecRule &TX:REAL_IP "@eq 0" \
+  "id:'900021', \
+  phase:1, \
+  t:none, \
+  initcol:global=global, \
+  initcol:ip=%{remote_addr}_%{tx.ua_hash}, \
+  nolog, \
+  pass"

iis/wix/modsecurity_iis.conf

@@ -0,0 +1,3 @@
+Include modsecurity.conf
+Include modsecurity_crs_10_setup.conf
+Include owasp_crs\activated_rules\*.conf