From 2f0dd539f1710c0ce0dc4f235d8b93f48e6460ed Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Felipe=20Zipitr=C3=ADa?= <3012076+fzipi@users.noreply.github.com> Date: Sat, 7 Dec 2024 11:54:58 -0300 Subject: [PATCH] docs: add rfdos warning (#166) * docs: add rfdos warning Signed-off-by: Felipe Zipitria * Apply suggestions from code review Co-authored-by: Max Leske <250711+theseion@users.noreply.github.com> --------- Signed-off-by: Felipe Zipitria Co-authored-by: Max Leske <250711+theseion@users.noreply.github.com> --- content/_index.md | 2 +- content/deployment/install.md | 10 ++++++++++ 2 files changed, 11 insertions(+), 1 deletion(-) diff --git a/content/_index.md b/content/_index.md index 0f5d938e..d817b9ac 100644 --- a/content/_index.md +++ b/content/_index.md @@ -23,7 +23,7 @@ The project endeavors not to make breaking changes in **minor releases** (i.e., New functionality and breaking changes are made in **major releases** (i.e., 3.3). -For information about what has changed in recent versions of the software, refer to the project's [CHANGES](https://github.com/coreruleset/coreruleset/blob/v4.0/dev/CHANGES.md) file on GitHub. +For information about what has changed in recent versions of the software, refer to the project's [CHANGES](https://github.com/coreruleset/coreruleset/blob/main/CHANGES.md) file on GitHub. ## Documentation Source diff --git a/content/deployment/install.md b/content/deployment/install.md index be579f9a..8533146a 100644 --- a/content/deployment/install.md +++ b/content/deployment/install.md @@ -94,6 +94,16 @@ Other aspects of ModSecurity, particularly engine-specific parameters, are contr In many scenarios, the default example CRS configuration will be a good enough starting point. It is, however, a good idea to take the time to look through the example configuration file *before* deploying it to make sure it's right for a given environment. +{{% notice warning %}} +In particular, _Response_ rules are enabled by default. You must be aware that you may be vulnerable to RFDoS attacks, depending on the responses your application is sending back to the client. You could be vulnerable, if your responses from your application can contain user input. If an attacker can submit user input that is returned as part of a response, the attacker can craft the input in such a way that the response rules of the WAF will block responses containing that input _for all_ clients. For example, a blog post might no longer be accessible because of the contents of a comment on the post. See [this blog post](https://blog.sicuranext.com/response-filter-denial-of-service-a-new-way-to-shutdown-a-website/) about the problems you could face. +There is an [experimental scanner](https://github.com/edoardottt/RFDos-Scanner) that uses [nuclei](https://github.com/projectdiscovery/nuclei?tab=readme-ov-file#install-nuclei) to find out if are affected. So if +you are unsure, first test your application before enabling the response rules, or risk accidentally blocking some valid responses. +Response rules can be easily disabled by uncommenting the rule with id `900500` in the `crs-setup.conf` file, +since CRS version 4.10.0. + +**The CRS team believes that the damage that can be caused by webshells and information leakage outweighs the damage of RFDos attacks, in general. Thus, the response rules remain active in the default configuration for now.** +{{% /notice %}} + Once any settings have been changed within the example configuration file, as needed, it should be renamed to remove the .example portion, like so: ```bash