From e2033c0b00c65c78c3b0b73a8b2f6f07367994ce Mon Sep 17 00:00:00 2001 From: Felipe Zipitria Date: Mon, 12 Feb 2024 10:26:28 -0300 Subject: [PATCH 1/2] feat: add well known deployment problems Signed-off-by: Felipe Zipitria --- content/deployment/problems.md | 27 +++++++++++++++++++++++++++ 1 file changed, 27 insertions(+) create mode 100644 content/deployment/problems.md diff --git a/content/deployment/problems.md b/content/deployment/problems.md new file mode 100644 index 0000000..8c15358 --- /dev/null +++ b/content/deployment/problems.md @@ -0,0 +1,27 @@ +--- +title: "Problems with installation" +menuTitle: "Problems" +chapter: false +weight: 30 +--- + +These have happened in some installs in the past. We are collecting them here for you to have them + +### Apache Line Continuation + +For really old versions of Apache, that come with some major distributions In Apache 2.4.x before 2.4.11 there is a bug where the use of linecontinuations in a config size may cause the line continuation to be truncated. This will lead to an error similar to the following: + +```bash +Syntax error on line 24 of /etc/httpd/modsecurity.d/activated_rules/RESPONSE-50-DATA-LEAKAGES-PHP.conf: +Error parsing actions: Unknown action: \ +``` + +This is not an error with ModSecurity or OWASP CRS. In order to fix this issue you can simply add a space before the continuation on the offending line. For more information see [apache bugzilla](https://bz.apache.org/bugzilla/show_bug.cgi?id=55910). + +### Anomaly Mode Doesn't Work + +Sometimes on IIS or Nginx users run into an instance where anomaly mode doesn't work as expected. In fact upon careful inspection of logs one would notice that rules don't fire in the order we would expect. In general this is a result of using the `'*'` operator within these environments as it does not act the same way as in Apache. In general within both Apache and IIS one should expliticly include the various files present within the OWASP CRS instead of using the `'*'`. + +### Webserver returns error after CRS install + +This is likley due to a rule triggering. For instance in some cases a rule is enabled that prohibits access via an IP address. Depending on your [SecDefaultAction]() and [SecRuleEngine]() configurations, this may result in a redirect loop or a status code. If this is the problem you are experiencing you should consult your error.log (or event viewer for IIS). From this location you candetermine the offending rule and add an exception if neccessary see [false positives and tuning]({{< ref "../concepts/false_positives_tuning.md" >}}). From 098f7ba297c856b5c9890d73c32c8903534e2003 Mon Sep 17 00:00:00 2001 From: Felipe Zipitria Date: Tue, 13 Feb 2024 18:30:40 -0300 Subject: [PATCH 2/2] fix: update known issues Signed-off-by: Felipe Zipitria --- content/deployment/problems.md | 27 -------- content/operation/known_issues.md | 104 ++++++++++++++++++------------ 2 files changed, 63 insertions(+), 68 deletions(-) delete mode 100644 content/deployment/problems.md diff --git a/content/deployment/problems.md b/content/deployment/problems.md deleted file mode 100644 index 8c15358..0000000 --- a/content/deployment/problems.md +++ /dev/null @@ -1,27 +0,0 @@ ---- -title: "Problems with installation" -menuTitle: "Problems" -chapter: false -weight: 30 ---- - -These have happened in some installs in the past. We are collecting them here for you to have them - -### Apache Line Continuation - -For really old versions of Apache, that come with some major distributions In Apache 2.4.x before 2.4.11 there is a bug where the use of linecontinuations in a config size may cause the line continuation to be truncated. This will lead to an error similar to the following: - -```bash -Syntax error on line 24 of /etc/httpd/modsecurity.d/activated_rules/RESPONSE-50-DATA-LEAKAGES-PHP.conf: -Error parsing actions: Unknown action: \ -``` - -This is not an error with ModSecurity or OWASP CRS. In order to fix this issue you can simply add a space before the continuation on the offending line. For more information see [apache bugzilla](https://bz.apache.org/bugzilla/show_bug.cgi?id=55910). - -### Anomaly Mode Doesn't Work - -Sometimes on IIS or Nginx users run into an instance where anomaly mode doesn't work as expected. In fact upon careful inspection of logs one would notice that rules don't fire in the order we would expect. In general this is a result of using the `'*'` operator within these environments as it does not act the same way as in Apache. In general within both Apache and IIS one should expliticly include the various files present within the OWASP CRS instead of using the `'*'`. - -### Webserver returns error after CRS install - -This is likley due to a rule triggering. For instance in some cases a rule is enabled that prohibits access via an IP address. Depending on your [SecDefaultAction]() and [SecRuleEngine]() configurations, this may result in a redirect loop or a status code. If this is the problem you are experiencing you should consult your error.log (or event viewer for IIS). From this location you candetermine the offending rule and add an exception if neccessary see [false positives and tuning]({{< ref "../concepts/false_positives_tuning.md" >}}). diff --git a/content/operation/known_issues.md b/content/operation/known_issues.md index 2329271..fb35f4f 100644 --- a/content/operation/known_issues.md +++ b/content/operation/known_issues.md @@ -7,64 +7,86 @@ chapter: false > There are some *known issues* with CRS and some of its compatible WAF engines. This page describes these issues. Get in touch if you think something is missing. -- There are still **false positives** for standard web applications in the default install (paranoia level 1). Please [report these on GitHub](https://github.com/coreruleset/coreruleset/issues/new/choose) if and when encountered. +{{% notice warning %}} +There are still **false positives** for standard web applications in the default install (paranoia level 1). Please [report these on GitHub](https://github.com/coreruleset/coreruleset/issues/new/choose) if and when encountered. +{{% /notice %}} - False positives from paranoia level 2 and higher are considered to be less interesting, as it is expected that users will write exclusion rules for their alerts in the higher paranoia levels. Nevertheless, false positives from higher paranoia levels can still be reported and the CRS project will try to find a generic solution for them. +👉 False positives from paranoia level 2 and higher are considered to be less interesting, as it is expected that users will write exclusion rules for their alerts in the higher paranoia levels. Nevertheless, false positives from higher paranoia levels can still be reported and the CRS project will try to find a generic solution for them. -- **Apache** may give an error on startup when the CRS is loaded: +### AH00111: Config variable ${...} is not defined - ``` - AH00111: Config variable ${[^} is not defined - ``` +**Apache** may give an error on startup when the CRS is loaded: - It appears that Apache tries to be smart by trying to evaluate a config variable. This notice should be a warning and can be safely ignored. The problem has been investigated and a solution has not been found yet. +``` +AH00111: Config variable ${[^} is not defined +``` -- **ModSecurity 3.0.0-3.0.2** will give an error: +It appears that Apache tries to be smart by trying to evaluate a config variable. This notice should be a warning and can be safely ignored. The problem has been investigated and a solution has not been found yet. - ``` - Expecting an action, got: ctl:requestBodyProcessor=URLENCODED"` - ``` +### **ModSecurity 3.0.0-3.0.2** will give an error - Support for the URLENCODED body processor was only added in ModSecurity 3.0.3. To resolve this, upgrade to ModSecurity 3.0.3 or higher. +``` +Expecting an action, got: ctl:requestBodyProcessor=URLENCODED"` +``` -- **Debian** releases up to and including Jessie lack YAJL/JSON support in ModSecurity. This causes the following error in the Apache ErrorLog or SecAuditLog: +Support for the URLENCODED body processor was only added in ModSecurity 3.0.3. To resolve this, upgrade to ModSecurity 3.0.3 or higher. - ``` - ModSecurity: JSON support was not enabled. - ``` +### Old Debian versions without YAJL - 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. +**Debian** releases up to and including Jessie lack YAJL/JSON support in ModSecurity. This causes the following error in the Apache ErrorLog or SecAuditLog: -- **Apache 2.4 prior to 2.4.11** is affected by a bug in parsing multi-line configuration directives, which causes Apache to fail during startup with an error such as: +``` +ModSecurity: JSON support was not enabled. +``` - ```plaintext - Error parsing actions: Unknown action: \\ - Action 'configtest' failed.` - ``` +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. - 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 https://bz.apache.org/bugzilla/show_bug.cgi?id=55910\). +### Apache 2.4 prior to 2.4.11 ### - It is advisable to upgrade an affected 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. +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: -- 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: +```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: + +``` +SecRule REQUEST_HEADERS:Content-Type "(?:application(?:/soap\+|/)|text/)xml" \ + "id:'200000',phase:1,t:none,t:lowercase,pass,nolog,ctl:requestBodyProcessor=XML" +``` + +### `SecDisableBackendCompression` not supported in libmodsecurity3 + +All versions of libmodsecurity3 [do not support](https://github.com/owasp-modsecurity/ModSecurity/wiki/Reference-Manual-(v3.x)#secdisablebackendcompression) the `SecDisableBackendCompression` directive at all ### - ``` - SecRule REQUEST_HEADERS:Content-Type "(?:application(?:/soap\+|/)|text/)xml" \ - "id:'200000',phase:1,t:none,t:lowercase,pass,nolog,ctl:requestBodyProcessor=XML" - ``` -- **All versions of libmodsecurity3** [do not support](https://github.com/owasp-modsecurity/ModSecurity/wiki/Reference-Manual-(v3.x)#secdisablebackendcompression) the `SecDisableBackendCompression` directive at all. If Nginx is acting as a proxy and the backend supports any type of compression, if the client sends an `Accept-Encoding: gzip,deflate,...` or `TE` header, the backend will return the response in a compressed format. Because of this, the engine cannot verify the response. As a workaround, you need to override the `Accept-Encoding` and `TE` headers in the proxy: - ``` - server { - server_name foo.com; +```nginx +server { + server_name foo.com; + ... + location / { + proxy_pass http://backend; ... - location / { - proxy_pass http://backend; - ... - proxy_set_header Accept-Encoding ""; - proxy_set_header TE ""; - } + proxy_set_header Accept-Encoding ""; + proxy_set_header TE ""; } - ``` +} +``` + +### Anomaly Mode Doesn't Work + +Sometimes on IIS or Nginx users run into an instance where anomaly mode doesn't work as expected. In fact upon careful inspection of logs one would notice that rules don't fire in the order we would expect. In general this is a result of using the `'*'` operator within these environments as it does not act the same way as in Apache. In general within both Apache and IIS one should expliticly include the various files present within the OWASP CRS instead of using the `'*'`. + +### Webserver returns error after CRS install + +This is likley due to a rule triggering. For instance in some cases a rule is enabled that prohibits access via an IP address. Depending on your [SecDefaultAction]() and [SecRuleEngine]() configurations, this may result in a redirect loop or a status code. If this is the problem you are experiencing you should consult your error.log (or event viewer for IIS). From this location you candetermine the offending rule and add an exception if neccessary see [false positives and tuning]({{< ref "../concepts/false_positives_tuning.md" >}}).