Commit 704cd96e authored by 53c70r's avatar 53c70r
Browse files

init base

parents
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.RaMKRs
Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.y0yxir
Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.o6FZ0r
Processing files: nginx-mod-modsecurity-crs-3.2.0-1.fc31.x86_64
Provides: nginx-mod-modsecurity-crs = 1:3.2.0-1.fc31 nginx-mod-modsecurity-crs(x86-64) = 1:3.2.0-1.fc31
Requires(rpmlib): rpmlib(CompressedFileNames) <= 3.0.4-1 rpmlib(FileDigests) <= 4.6.0-1 rpmlib(PayloadFilesHavePrefix) <= 4.0-1
Checking for unpackaged file(s): /usr/lib/rpm/check-files /home/user/rpmbuild/BUILDROOT/nginx-mod-modsecurity-crs-3.2.0-1.fc31.x86_64
Wrote: /home/user/git/nginx-mod-modsecurity-crs/nginx-mod-modsecurity-crs-3.2.0-1.fc31.src.rpm
Wrote: /home/user/git/nginx-mod-modsecurity-crs/x86_64/nginx-mod-modsecurity-crs-3.2.0-1.fc31.x86_64.rpm
Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.doLxBr
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.PtsCPg
RPM build errors:
Include /etc/nginx/modsecurity.d/owasp-modsecurity-crs/crs-setup.conf
Include /etc/nginx/modsecurity.d/owasp-modsecurity-crs/rules/*.conf
modsecurity on;
modsecurity_rules_file /etc/nginx/modsecurity.d/owasp-modsecurity-crs/load_file.conf;
modsecurity_rules "SecRuleEngine On";
<!--- For help and support please go to Stack Exchange: -->
<!--- https://security.stackexchange.com/questions/tagged/owasp-crs -->
<!--- Provide a general summary of the issue in the Title above -->
## Type of Issue
<!-- Incorrect blocking (false positive), incorrect bypass (false negative), -->
<!-- bug fix, feature suggestion -->
## Description
<!-- In case of a false positive, please provide a copy of the audit -->
<!-- log entry. You can usually find this at /var/log/modsec_audit.log. -->
<!-- In case of a false negative, please provide the payload you -->
<!-- are sending. For complex payloads with headers, please include -->
<!-- a curl command. -->
<!-- Include any relevant CVEs or research links. -->
## Your Environment
<!--- Include as many relevant details about the environment you -->
<!--- experienced the bug in: -->
* CRS version (e.g. v3.0.2):
* ModSecurity version (e.g. 2.9.2):
* Web Server and version (e.g. apache 2.4.27):
* Operating System and version:
## Confirmation
[ ] I have removed any personal data (email addresses, IP addresses,
passwords, domain names) from any logs posted.
*.swp
*.swo
# User configuration
crs-setup.conf
rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf
rules/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf
# The MaxMind GeoIP database can be downloaded or upgraded by running:
# util/upgrade.py geoip
util/geo-location/GeoIP.dat
# Unit test caches
.cache
# Byte-compiled / optimized / DLL files
__pycache__/
*.py[cod]
*$py.class
\ No newline at end of file
[submodule "documentation/OWASP-CRS-Documentation"]
path = documentation/OWASP-CRS-Documentation
url = https://github.com/SpiderLabs/OWASP-CRS-Documentation
branch = master
language: python
python:
- 2.7
sudo: required
services:
- docker
jobs:
allow_failures:
- env: CONFIG=3.0-apache LOGDIR=/var/log/apache2
- env: CONFIG=3.0-nginx LOGDIR=/var/log/nginx
fast_finish: true
include:
- &test-common
env: CONFIG=2.9-apache LOGDIR=/var/log/apache2
before_install:
- |
if [[ "$TRAVIS_PULL_REQUEST" != "false" ]]; then
docker build --build-arg REPO=$TRAVIS_PULL_REQUEST_SLUG \
--build-arg BRANCH=$TRAVIS_PULL_REQUEST_BRANCH \
--build-arg COMMIT=$TRAVIS_PULL_REQUEST_SHA \
-f ./util/docker/Dockerfile-$CONFIG \
-t modsecurity-crs-$CONFIG ./util/docker/
else
docker build -f ./util/docker/Dockerfile-$CONFIG \
-t modsecurity-crs-$CONFIG ./util/docker/
fi
- |
docker run -ti -e PARANOIA=5 -d -p 80:80 \
--volume $LOGDIR:$LOGDIR \
--name "$TRAVIS_BUILD_ID" modsecurity-crs-$CONFIG
- |
docker ps | grep -q modsecurity-crs
if [[ $? -ne 0 ]]; then
docker logs "$TRAVIS_BUILD_ID"
docker rm -f "$TRAVIS_BUILD_ID"
exit 1
fi
install:
- pip install -r util/integration/requirements.txt
- pip install -r util/regression-tests/requirements.txt
before_script:
- git clone https://github.com/CRS-support/secrules_parsing
- pip install -r secrules_parsing/requirements.txt
- python secrules_parsing/secrules_parser.py -c -f rules/*.conf
script:
- py.test -vs util/integration/format_tests.py
- |
py.test -vs util/regression-tests/CRS_Tests.py \
--config=$CONFIG --ruledir_recurse=util/regression-tests/tests
- docker rm -f "$TRAVIS_BUILD_ID"
- <<: *test-common
env: CONFIG=3.0-apache LOGDIR=/var/log/apache2
- <<: *test-common
env: CONFIG=3.0-nginx LOGDIR=/var/log/nginx
# safelist
branches:
only:
- v3.0/dev
- v3.0/master
- v3.1/dev
- v3.2/dev
notifications:
irc: "chat.freenode.net#modsecurity"
# Contributing to the CRS
We value third-party contributions. To keep things simple for you and us,
please adhere to the following contributing guidelines.
## Getting Started
* You will need a [GitHub account](https://github.com/signup/free).
* Submit a [ticket for your issue](https://github.com/SpiderLabs/owasp-modsecurity-crs/issues), assuming one does not already exist.
* Clearly describe the issue including steps to reproduce when it is a bug.
* Make sure you specify the version that you know has the issue.
* Bonus points for submitting a failing test along with the ticket.
* If you don't have push access, fork the repository on GitHub.
## Making Changes
* Please base your changes on branch ```v3.2/dev```
* Create a topic branch for your feature or bug fix.
* Please fix only one problem at a time; this will help to quickly test and merge your change. If you intend to fix multiple unrelated problems, please use a separate branch for each problem.
* Make commits of logical units.
* Make sure your commits adhere to the rules guidelines below.
* Make sure your commit messages are in the [proper format](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html): The first line of the message should have 50 characters or less, separated by a blank line from the (optional) body. The body should be wrapped at 70 characters and paragraphs separated by blank lines. Bulleted lists are also fine.
## General Formatting Guidelines for rules contributions
- 4 spaces per indentation level, no tabs
- no trailing whitespace at EOL or trailing blank lines at EOF
- comments are good, especially when they clearly explain the rule
- try to adhere to a 80 character line length limit
- if it is a [chained rule](https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual#chain), alignment should be like
```
SecRule .. ..\
"...."
SecRule .. ..\
"..."
SecRule .. ..\
".."
```
- use quotes even if there is only one action, it improves readability (e.g use `"chain"`, not `chain`, or `"ctl:requestBodyAccess=Off"` instead of `ctl:requestBodyAccess=Off`)
- always use numbers for phases, instead of names
- format your `SecMarker` between double quotes, using UPPERCASE and separating words using hyphens. Examples are
```
SecMarker "END-RESPONSE-959-BLOCKING-EVALUATION"
SecMarker "END-REQUEST-910-IP-REPUTATION"
```
- the proposed order for actions is:
```
id
phase
allow | block | deny | drop | pass | proxy | redirect
status
capture
t:xxx
log
nolog
auditlog
noauditlog
msg
logdata
tag
sanitiseArg
sanitiseRequestHeader
sanitiseMatched
sanitiseMatchedBytes
ctl
ver
severity
multiMatch
initcol
setenv
setvar
expirevar
chain
skip
skipAfter
```
## Variables naming conventions
* Variable names are lowercase using chars from `[a-z0-9_]`
* To somewhat reflect the fact that the syntax for variable usage is different when you define it (using setvar) and when you use it, we propose the following visual distinction:
* Lowercase letters for collection, dot as separator, variable name. E.g: `setvar:tx.foo_bar_variable`
* Capital letters for collection, colon as separator, variable name. E.g: `SecRule TX:foo_bar_variable`
## Rules compliance with each Paranoia Level (PL)
Rules in the CRS are organized in Paranoia Levels, which allows you to choose the desired level of rule checks.
Please read file ```crs-setup.conf.example``` for introduction and a more detailed explanation of Paranoia Levels in the section `# -- [[ Paranoia Level Initialization ]]`.
**PL0:**
* Modsec installed, but almost no rules
**PL1:**
* Default level, keep in mind that most installations will normally use this one.
* If there is a complex memory consuming/evaluation rule it surely will be on upper levels, not this one
* Normally we will use atomic checks in single rules
* Confirmed matches only, all scores are allowed
* No false positives / Low FP (Try to avoid adding rules with potential false positives!)
* False negatives could happen
**PL2:**
* Chains usage are OK
* Confirmed matches use score critical
* Matches that cause false positives are limited to use score notice or warning
* Low False positive rates
* False negatives are not desirable
**PL3:**
* Chains usage with complex regex look arounds and macro expansions
* Confirmed matches use score warning or critical
* Matches that cause false positives are limited to use score notice
* False positive rates increased but limited to multiple matches (not single string)
* False negatives should be a very unlikely accident
**PL4:**
* Every item is inspected
* Variable creations allowed to avoid engine limitations
* Confirmed matches use score notice, warning or critical
* Matches that cause false positives are limited to use score notice and warning
* False positive rates increased (even on single string)
* False negatives should not happen here
* Check everything against RFC and white listed values for most popular elements
## ID Numbering Scheme
The CRS project used the numerical id rule namespace from 900,000 to 999,999 for the CRS rules as well as 9,000,000 to 9,999,999 for default CRS rule exclusion packages.
Rules applying to the incoming request use the id range 900,000 to 949,999.
Rules applying to the outgoing response use the id range 950,000 to 999,999.
The rules are grouped by vulnerability class they address (SQLi, RCE, etc.) or functionality (initialization). These groups occupy blocks of thousands (e.g. SQLi: 942,000 - 942,999).
The grouped rules are defined in files dedicated to a single group or functionality. The filename takes up the first three digits of the rule ids defined within the file (e.g. SQLi: REQUEST-942-APPLICATION-ATTACK-SQLI.conf).
The individual rule files for the vulnerability classes are organized by the paranoia level of the rules. PL 1 is first, then PL 2 etc.
The block from 9XX000 - 9XX099 is reserved for use by CRS helper functionality. There are no blocking or filtering rules in this block.
Among the rules serving a CRS helper functionality are rules that skip rules depending on the paranoia level. These rules always use the following reserved rule ids: 9XX011-9XX018 with very few exceptions.
The blocking or filter rules start with 9XX100 with a step width of 10. E.g. 9XX100, 9XX110, 9XX120 etc. The rule id does not correspond directly with the paranoia level of a rule. Given the size of a rule group and the organization by lower PL rules first, PL2 and above tend to have rule IDs with higher numbers.
Within a rule file / block, there are sometimes smaller groups of rules that belong to together. They are closely linked and very often represent copies of the original rules with a stricter limit (alternatively, they can represent the same rule addressing a different target in a second rule where this was necessary). These are stricter siblings of the base rule. Stricter siblings usually share the first five digits of the rule ID and raise the rule ID by one. E.g. Base rule at 9XX160, stricter sibling at 9XX161.
Stricter siblings often have a different paranoia level. This means that the base rule and the stricter sibling do not reside next to one another in the rule file. Instead they are ordered in their appropriate paranoia level and can be linked via the first digits of the rule id. It is a good practice to introduce stricter siblings together with the base rule in the comments of the base rule and to reference the base rule with the keyword stricter sibling in the comments of the stricter sibling. E.g. "... This is
performed in two separate stricter siblings of this rule: 9XXXX1 and 9XXXX2", "This is a stricter sibling of rule 9XXXX0."
## Project Co-Leads:
- [Chaim Sanders](https://github.com/csanders-git)
- [Christian Folini](https://github.com/dune73)
- [Walter Hop](https://github.com/lifeforms)
## Developers:
- [Franziska Bühler](https://github.com/franbuehler)
- [Christoph Hansen](https://github.com/emphazer)
- [Ervin Hegedus](https://github.com/airween)
- [Victor Hora](https://github.com/victorhora)
- [Andrea Menin](https://github.com/theMiddleBlue)
- [Federico G. Schwindt](https://github.com/fgsch)
- [Manuel Spartan](https://github.com/spartantri)
- [Felipe Zimmerle](https://github.com/zimmerle)
- [Felipe Zipitría](https://github.com/fzipi)
## Contributors:
- [Zack Allen](https://github.com/zmallen)
- [azhao155](https://github.com/azhao155)
- [Matt Bagley](https://github.com/bagley)
- [Ryan Barnett](https://github.com/rcbarnett)
- [Peter Bittner](https://github.com/bittner)
- [Allan Boll](https://github.com/allanbomsft)
- [Jeremy Brown](https://github.com/jwbrown77)
- [Brent Clark](https://github.com/brentclark)
- [Jonathan Claudius](https://github.com/claudijd)
- [coolt](https://github.com/coolt)
- [Ashish Dixit](https://github.com/tundal45)
- [Padraig Doran](https://github.com/padraigdoran)
- [Dan Ehrlich](https://github.com/danehrlich1)
- [Umar Farook](https://github.com/umarfarook882)
- [FrozenSolid](https://github.com/frozenSolid)
- [Pásztor Gábor](https://github.com/gpasztor87)
- [Aaron Haaf](https://github.com/Everspace)
- [Michael Haas](https://github.com/MichaelHaas)
- [jamuse](https://github.com/jamuse)
- [jschleus](https://github.com/jschleus)
- [Krzysztof Kotowicz](https://github.com/koto)
- [Max Leske](https://github.com/theseion)
- Manuel Leos
- [Evgeny Marmalstein](https://github.com/shimshon70)
- [Christian Mehlmauer](https://github.com/FireFart)
- [Glyn Mooney](https://github.com/skidoosh)
- [na1ex](https://github.com/na1ex)
- [Jose Nazario](https://github.com/paralax)
- [Scott O'Neil](https://github.com/cPanelScott)
- [Robert Paprocki](https://github.com/p0pr0ck5)
- [Christian Peron](https://github.com/csjperon)
- [Elia Pinto](https://github.com/yersinia)
- [Brian Rectanus](https://github.com/b1v1r)
- [Rufus125](https://github.com/Rufus125)
- Ofer Shezaf
- Breno Silva
- siric\_
- [Marc Stern](https://github.com/marcstern)
- [Simon Studer](https://github.com/studersi)
- [supplient](https://github.com/supplient)
- [theMiddle](https://github.com/theMiddleBlue)
- [Ben Williams](https://github.com/benwilliams)
- [Avery Wong](https://github.com/4v3r9)
- [Greg Wroblewski](https://github.com/gwroblew)
- [XeroChen](https://github.com/XeroChen)
- [ygrek](https://github.com/ygrek)
- [Yu Yagihashi](https://github.com/yagihash)
- [Zino](https://github.com/zinoe)
- Josh Zlatin
- [Zou Guangxian](https://github.com/zouguangxian)
- [4ft35t](https://github.com/4ft35t)
_____ _____ _____ ____
/ ____| __ \ / ____| |___ \
| | | |__) | (___ __) |
| | | _ / \___ \ |__ <
| |____| | \ \ ____) | ___) |
\_____|_| \_\_____/ |____/
OWASP Core Rule Set 3.x
Installing ModSecurity
=====================
This document does NOT detail how to install ModSecurity. Rather,
only information pertaining to the installation of the OWASP Core
Rule Set (CRS) is provided. However, ModSecurity is a prerequisite
for the CRS installation. Information on installing ModSecurity
can be found within the ModSecurity project at
https://github.com/SpiderLabs/ModSecurity or at ModSecurity.org.
Installing From a Package Manager
=================================
The OWASP Core Rule Set (CRS) is available from many sources. On
multiple platforms this includes package managers. These packages are
maintained by independent packagers who package CRS in their own time.
Historically, many of these packages have been out of date. As such,
it is recommended that you install, where possible, from our GitHub
repository. The following CRS 3.x packages are known to exist:
modsecurity-crs - Debian
mod_security_crs - Fedora
modsecurity-crs - Gentoo
Packages of CRS 2.x are incompatible with CRS 3.x.
Installing
==========
You can download a copy of the CRS from the following URL:
https://coreruleset.org/installation/
Our release zip/tar.gz files are the preferred way to install CRS.
However, if you want to follow rule development closely and get
the newest protections quickly, you can also clone our GitHub
repository to get the current work-in-progress for the next release.
Prerequisites
-------------
CRS is designed to be used with ModSecurity (although many other
projects also use the provided rules). CRS version 3.x is designed for
ModSecurity 2.8 or above. CRS version 3.x makes use of libinjection
and libXML2. Failure to provide these prerequisites may result in
serious false negatives and CRS version 3.x should NOT be run without
these. Note, however, that libinjection is bundled with ModSecurity
since version 2.8. Additionally, if you are downloading from the
GitHub repo you will need to install 'git' on your system.
Upgrading from CRS 2.x
----------------------
CRS 3.x is a major release incompatible with CRS 2.x.
The rule IDs have changed. The file id_renumbering/IdNumbering.csv
contains a list with old and new rule IDs. However, a key feature
of the release 3.x is the reduction of false positives in the
default installation and we recommend you start with a fresh
install from scratch.
Key parameter variables have changed their name and new features
have been introduced. Your former modsecurity_crs_10_setup.conf
file is thus no longer usable.
We recommend you to start with a fresh install from scratch.
Installing on Apache
--------------------
1. Install ModSecurity for Apache
2. Ensure that ModSecurity is loading correctly by checking error.log
at start up for lines indicating ModSecurity is installed. An example
might appear as follows:
```ModSecurity for Apache/2.9.1 (http://www.modsecurity.org/) configured.```
3. The most common method of deploying ModSecurity we have seen is
to create a new folder underneath the Apache directory (typically
/usr/local/apache/, /etc/httpd/, or /etc/apache2). Often this folder
is called 'modsecurity.d'. Create this folder and cd into it.
4. Download our release from https://coreruleset.org/installation/
and unpack it into a new owasp-modsecurity-crs folder.
5. Move the crs-setup.conf.example file to crs-setup.conf.
Please take the time to go through this file and customize the settings
for your local environment. Failure to do so may result in false
negatives and false positives. See the section entitled OWASP CRS
Configuration for more detail.
6. Rename rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example and
rules/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf.example to remove the
'.example' extension. This will allow you to add exclusions without updates
overwriting them in the future.
7. Add the following line to your httpd.conf/apache2.conf (the following
assumes you've put CRS into modsecurity.d/owasp-modsecurity-crs). You
can alternatively place these in any config file included by Apache:
```
<IfModule security2_module>
Include modsecurity.d/owasp-modsecurity-crs/crs-setup.conf
Include modsecurity.d/owasp-modsecurity-crs/rules/*.conf
</IfModule>
```
8. Restart web server and ensure it starts without errors
9. Make sure your web sites are still running fine.
10. Proceed to the section "Testing the Installation" below.
Installing on Nginx
-------------------
1. Compile ModSecurity into Nginx
2. Ensure that ModSecurity is loading correctly by checking error.log
at start up for lines indicating ModSecurity is installed. An example
might appear as follows:
```ModSecurity for nginx (STABLE)/2.9.1 (http://www.modsecurity.org/) configured.```
3. The most common method of deploying ModSecurity we have seen is
to create a new folder underneath the Nginx directory (typically
/usr/local/nginx/conf/). Often this folder
is called 'owasp-modsecurity-crs'. Create this folder and cd into it.
4. Download our release from https://coreruleset.org/installation/
and unpack it into a new owasp-modsecurity-crs folder.
5. Move the crs-setup.conf.example file to crs-setup.conf.
Please take this time to go through this
file and customize the settings for your local environment. Failure to
do so may result in false negatives and false positives. See the
section entitled OWASP CRS Configuration for more detail.
6. Rename rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example and
rules/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf.example to remove the
'.example' extension. This will allow you to add exceptions without updates
overwriting them in the future.
7. Nginx requires the configuration of a single ModSecurity
configuration file within the nginx.conf file using the
'ModSecurityConfig' directive (when using ModSecurity 2.x).
Best practice is to set 'ModSecurityConfig' to a file from
which you will include your other ModSecurity configuration
files. In this example we will use:
```ModSecurityConfig modsec_includes.conf;```
7. Within modsec_includes.conf create your includes to the
CRS folder similar to as follows (The modsecurity.conf file from the
ModSecurity installation is included in this example):
```
include modsecurity.conf
include owasp-modsecurity-crs/crs-setup.conf
include owasp-modsecurity-crs/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf
include owasp-modsecurity-crs/rules/REQUEST-901-INITIALIZATION.conf
include owasp-modsecurity-crs/rules/REQUEST-903.9001-DRUPAL-EXCLUSION-RULES.conf
include owasp-modsecurity-crs/rules/REQUEST-903.9002-WORDPRESS-EXCLUSION-RULES.conf
include owasp-modsecurity-crs/rules/REQUEST-903.9003-NEXTCLOUD-EXCLUSION-RULES.conf
include owasp-modsecurity-crs/rules/REQUEST-903.9004-DOKUWIKI-EXCLUSION-RULES.conf
include owasp-modsecurity-crs/rules/REQUEST-903.9005-CPANEL-EXCLUSION-RULES.conf
include owasp-modsecurity-crs/rules/REQUEST-903.9006-XENFORO-EXCLUSION-RULES.conf
include owasp-modsecurity-crs/rules/REQUEST-905-COMMON-EXCEPTIONS.conf
include owasp-modsecurity-crs/rules/REQUEST-910-IP-REPUTATION.conf
include owasp-modsecurity-crs/rules/REQUEST-911-METHOD-ENFORCEMENT.conf
include owasp-modsecurity-crs/rules/REQUEST-912-DOS-PROTECTION.conf
include owasp-modsecurity-crs/rules/REQUEST-913-SCANNER-DETECTION.conf
include owasp-modsecurity-crs/rules/REQUEST-920-PROTOCOL-ENFORCEMENT.conf
include owasp-modsecurity-crs/rules/REQUEST-921-PROTOCOL-ATTACK.conf
include owasp-modsecurity-crs/rules/REQUEST-930-APPLICATION-ATTACK-LFI.conf
include owasp-modsecurity-crs/rules/REQUEST-931-APPLICATION-ATTACK-RFI.conf
include owasp-modsecurity-crs/rules/REQUEST-932-APPLICATION-ATTACK-RCE.conf
include owasp-modsecurity-crs/rules/REQUEST-933-APPLICATION-ATTACK-PHP.conf
include owasp-modsecurity-crs/rules/REQUEST-934-APPLICATION-ATTACK-NODEJS.conf
include owasp-modsecurity-crs/rules/REQUEST-941-APPLICATION-ATTACK-XSS.conf
include owasp-modsecurity-crs/rules/REQUEST-942-APPLICATION-ATTACK-SQLI.conf
include owasp-modsecurity-crs/rules/REQUEST-943-APPLICATION-ATTACK-SESSION-FIXATION.conf
include owasp-modsecurity-crs/rules/REQUEST-933-APPLICATION-ATTACK-JAVA.conf
include owasp-modsecurity-crs/rules/REQUEST-949-BLOCKING-EVALUATION.conf
include owasp-modsecurity-crs/rules/RESPONSE-950-DATA-LEAKAGES.conf
include owasp-modsecurity-crs/rules/RESPONSE-951-DATA-LEAKAGES-SQL.conf
include owasp-modsecurity-crs/rules/RESPONSE-952-DATA-LEAKAGES-JAVA.conf
include owasp-modsecurity-crs/rules/RESPONSE-953-DATA-LEAKAGES-PHP.conf
include owasp-modsecurity-crs/rules/RESPONSE-954-DATA-LEAKAGES-IIS.conf
include owasp-modsecurity-crs/rules/RESPONSE-959-BLOCKING-EVALUATION.conf
include owasp-modsecurity-crs/rules/RESPONSE-980-CORRELATION.conf
include owasp-modsecurity-crs/rules/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf
```
8. Restart web server and ensure it starts without errors
9. Make sure your web sites are still running fine.
10. Proceed to the section "Testing the Installation" below.
Installing on IIS
-----------------
The IIS installer comes with an optional version of CRS built in.
To upgrade or install this after the fact follow the following
steps.
1. Navigate to "[drive_letters]:\Program Files\ModSecurity IIS\"
2. Download our release from https://coreruleset.org/installation/
and unpack it into the current folder.
3. Move the crs-setup.conf.example file to crs-setup.conf.
Please take this time to go through this
file and customize the settings for your local environment. Failure to
do so may result in false negatives and false positives. See the
section entitled OWASP CRS Configuration for more detail.
4. Rename rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example and
rules/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf.example to remove the
'.example' extension. This will allow you to add exceptions without updates
overwriting them in the future.
5. Navigate back to the 'ModSecurity IIS' folder and modify the
'modsecurity_iis' to include the following:
```
include owasp-modsecurity-crs/crs-setup.conf
include owasp-modsecurity-crs/rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf
include owasp-modsecurity-crs/rules/REQUEST-901-INITIALIZATION.conf
include owasp-modsecurity-crs/rules/REQUEST-905-COMMON-EXCEPTIONS.conf
include owasp-modsecurity-crs/rules/REQUEST-910-IP-REPUTATION.conf
include owasp-modsecurity-crs/rules/REQUEST-911-METHOD-ENFORCEMENT.conf
include owasp-modsecurity-crs/rules/REQUEST-912-DOS-PROTECTION.conf
include owasp-modsecurity-crs/rules/REQUEST-913-SCANNER-DETECTION.conf