diff --git a/content/1-getting-started/1-1-crs-installation.md b/content/1-getting-started/1-1-crs-installation.md index 66b62e34..553662ee 100644 --- a/content/1-getting-started/1-1-crs-installation.md +++ b/content/1-getting-started/1-1-crs-installation.md @@ -196,7 +196,7 @@ Please note that we added a large number of new detections, and any new detectio In general, you can update by unzipping our new release over your older one, and updating the `crs-setup.conf` file with any new settings. However, CRS 3.0 is a major rewrite, incompatible with CRS 2.x. Key setup 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 crs-setup.conf file from scratch. -Most rule IDs have been changed to reorganize them into logical sections. This means that if you have written custom configuration with exclusion rules (e.g. `SecRuleRemoveById`, `SecRuleRemoveTargetById`, `ctl:ruleRemoveById` or `ctl:ruleRemoveTargetById`) you must renumber the rule numbers in that configuration. You can do this using the supplied utility util/id_renumbering/update.py or find the changes in util/id_renumbering/IdNumbering.csv. +Most rule IDs have been changed to reorganize them into logical sections. This means that if you have written custom configuration with exclusion rules (e.g. `SecRuleRemoveById`, `SecRuleRemoveTargetById`, `ctl:ruleRemoveById` or `ctl:ruleRemoveTargetById`) you must renumber the rule numbers in that configuration. You can do this using the utility id_renumbering/update.py or find the changes in id_renumbering/IdNumbering.csv, both shipped with [CRS 3.0.0](https://github.com/coreruleset/coreruleset/tree/v3.0.0/id_renumbering). However, a key feature of the CRS 3 is the reduction of false positives in the default installation, and many of your old exclusion rules may no longer be necessary. Therefore, it is a good option to start fresh without your old exclusion rules. diff --git a/content/7-known-issues/_index.md b/content/7-known-issues/_index.md index 5d49c872..720770d9 100644 --- a/content/7-known-issues/_index.md +++ b/content/7-known-issues/_index.md @@ -44,19 +44,6 @@ ModSecurity: JSON support was not enabled. JSON support was enabled in Debian's package version 2.8.0-4 (Nov 2014). To resolve this, it is possible to either use `backports.debian.org` to install the latest ModSecurity release or to disable the rule with ID 200001. -### Apache 2.4 prior to 2.4.11 - -Apache versions prior to 2.4.11 are affected by a bug in parsing multi-line configuration directives, which causes Apache to fail during startup with an error such as: - -```plaintext -Error parsing actions: Unknown action: \\ -Action 'configtest' failed.` -``` - -This bug is known to plague RHEL/Centos 7 below v7.4 or httpd v2.4.6 release 67 and Ubuntu 14.04 LTS users. (The original bug report can be found at ). - -By now you should not be using such an old web server. It is advisable to upgrade your Apache version. If upgrading is not possible, the CRS project provides a script in the `util/join-multiline-rules` directory which converts the rules into a format that works around the bug. This script must be re-run whenever the CRS rules are modified or updated. - ### Support for `application/soap+xml` As of CRS version 3.0.1, support has been added for the `application/soap+xml` MIME type by default, as specified in RFC 3902. **OF IMPORTANCE:** application/soap+xml is indicative that XML will be provided. In accordance with this, ModSecurity's XML request body processor should also be configured to support this MIME type. Within the ModSecurity project, [commit 5e4e2af](https://github.com/owasp-modsecurity/ModSecurity/commit/5e4e2af7a6f07854fee6ed36ef4a381d4e03960e) has been merged to support this endeavor. However, if running a modified or preexisting version of the modsecurity.conf file provided by this repository, it is a good idea to upgrade rule '200000' accordingly. The rule now appears as follows: