From 941b882bc89ef3f8b8c934cd4e6e165b58197acf Mon Sep 17 00:00:00 2001 From: Esad Cetiner <104706115+EsadCetiner@users.noreply.github.com> Date: Wed, 5 Jun 2024 20:54:56 +1000 Subject: [PATCH 1/5] feat: conditionally enable plugins for multi-app environments --- content/concepts/plugins.md | 40 +++++++++++++++++++++++++++++++++++++ 1 file changed, 40 insertions(+) diff --git a/content/concepts/plugins.md b/content/concepts/plugins.md index 42a8ef88..f34374fc 100644 --- a/content/concepts/plugins.md +++ b/content/concepts/plugins.md @@ -106,6 +106,46 @@ Disabling a plugin is simple. Either remove the plugin files in the plugins fold Alternatively, it is also valid to disable a plugin by renaming a plugin file from `plugin-before.conf` to `plugin-before.conf.disabled`. +## Conditionally enable plugins for multi-application environments + +If CRS is installed on a reverse-proxy or a web server with multiple web applications, then you may wish to only enable certain plugins (such as rule exclusion plugins) for certain VirtualHosts. This ensures that rules designed for a specific web application are only enabled for the intended web application, reducing the scope of any possible bypasses within a plugin. + +Most plugins provide an example to disable the plugin in the file `plugin-config.conf`, you can define the WebAppID variable for each virtualhosts and then disable the plugin if the WebAppID variable doesn't equal, for example WordPress. + +See: https://github.com/owasp-modsecurity/ModSecurity/wiki/Reference-Manual-(v2.x)#secwebappid + +Below is an example for only enabling the WordPress plugin for WordPress VirtualHosts: + +``` +SecRule &TX:wordpress-rule-exclusions-plugin_enabled "@eq 0" \ + "id:9507010,\ + phase:1,\ + pass,\ + nolog,\ + ver:'wordpress-rule-exclusions-plugin/1.0.0',\ + chain" + SecRule WebAppID "!@streq wordpress" \ + "t:none,\ + setvar:'tx.wordpress-rule-exclusions-plugin_enabled=0'" +``` + +⚠️ Warning: As of 05/06/2024, Coraza doesn't support the use of WebAppID, you can use the host header instead of the WebAppID variable: + +``` +SecRule &TX:wordpress-rule-exclusions-plugin_enabled "@eq 0" \ + "id:9507010,\ + phase:1,\ + pass,\ + nolog,\ + ver:'wordpress-rule-exclusions-plugin/1.0.0',\ + chain" + SecRule REQUEST_HEADERS:Host "!@streq wordpress.example.com" \ + "t:none,\ + setvar:'tx.wordpress-rule-exclusions-plugin_enabled=0'" +``` + +See: https://coraza.io/docs/seclang/variables/#webappid + ## What Plugins are Available? All official plugins are listed on GitHub in the CRS plugin registry repository: https://github.com/coreruleset/plugin-registry. From 0d797b2d247625c34a4f28badce5efab36ba2f13 Mon Sep 17 00:00:00 2001 From: Esad Cetiner <104706115+EsadCetiner@users.noreply.github.com> Date: Sun, 9 Jun 2024 19:25:05 +1000 Subject: [PATCH 2/5] Apply suggestions from code review Co-authored-by: Max Leske <250711+theseion@users.noreply.github.com> --- content/concepts/plugins.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/content/concepts/plugins.md b/content/concepts/plugins.md index f34374fc..b71bbf8a 100644 --- a/content/concepts/plugins.md +++ b/content/concepts/plugins.md @@ -108,13 +108,13 @@ Alternatively, it is also valid to disable a plugin by renaming a plugin file fr ## Conditionally enable plugins for multi-application environments -If CRS is installed on a reverse-proxy or a web server with multiple web applications, then you may wish to only enable certain plugins (such as rule exclusion plugins) for certain VirtualHosts. This ensures that rules designed for a specific web application are only enabled for the intended web application, reducing the scope of any possible bypasses within a plugin. +If CRS is installed on a reverse-proxy or a web server with multiple web applications, then you may wish to only enable certain plugins (such as rule exclusion plugins) for certain `VirtualHosts`. This ensures that rules designed for a specific web application are only enabled for the intended web application, reducing the scope of any possible bypasses within a plugin. -Most plugins provide an example to disable the plugin in the file `plugin-config.conf`, you can define the WebAppID variable for each virtualhosts and then disable the plugin if the WebAppID variable doesn't equal, for example WordPress. +Most plugins provide an example to disable the plugin in the file `plugin-config.conf`, you can define the `WebAppID` variable for each `VirtualHost` and then disable the plugin when the `WebAppID` variable doesn't match. See: https://github.com/owasp-modsecurity/ModSecurity/wiki/Reference-Manual-(v2.x)#secwebappid -Below is an example for only enabling the WordPress plugin for WordPress VirtualHosts: +Below is an example for enabling only the WordPress plugin for WordPress `VirtualHost`s: ``` SecRule &TX:wordpress-rule-exclusions-plugin_enabled "@eq 0" \ @@ -129,7 +129,7 @@ SecRule &TX:wordpress-rule-exclusions-plugin_enabled "@eq 0" \ setvar:'tx.wordpress-rule-exclusions-plugin_enabled=0'" ``` -⚠️ Warning: As of 05/06/2024, Coraza doesn't support the use of WebAppID, you can use the host header instead of the WebAppID variable: +⚠️ Warning: As of 05/06/2024, Coraza doesn't support the use of WebAppID, you can use the`Host` header instead of the `WebAppID` variable: ``` SecRule &TX:wordpress-rule-exclusions-plugin_enabled "@eq 0" \ From ef57f0c9d87951a01f4cb452abf2ed0dee82debf Mon Sep 17 00:00:00 2001 From: Esad Cetiner <104706115+EsadCetiner@users.noreply.github.com> Date: Sun, 9 Jun 2024 20:44:05 +1000 Subject: [PATCH 3/5] Apply suggestions from code review Co-authored-by: Max Leske <250711+theseion@users.noreply.github.com> --- content/concepts/plugins.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/content/concepts/plugins.md b/content/concepts/plugins.md index b71bbf8a..8288f7f7 100644 --- a/content/concepts/plugins.md +++ b/content/concepts/plugins.md @@ -110,11 +110,11 @@ Alternatively, it is also valid to disable a plugin by renaming a plugin file fr If CRS is installed on a reverse-proxy or a web server with multiple web applications, then you may wish to only enable certain plugins (such as rule exclusion plugins) for certain `VirtualHosts`. This ensures that rules designed for a specific web application are only enabled for the intended web application, reducing the scope of any possible bypasses within a plugin. -Most plugins provide an example to disable the plugin in the file `plugin-config.conf`, you can define the `WebAppID` variable for each `VirtualHost` and then disable the plugin when the `WebAppID` variable doesn't match. +Most plugins provide an example to disable the plugin in the file `plugin-config.conf`, you can define the `WebAppID` variable for each virtual host and then disable the plugin when the `WebAppID` variable doesn't match. See: https://github.com/owasp-modsecurity/ModSecurity/wiki/Reference-Manual-(v2.x)#secwebappid -Below is an example for enabling only the WordPress plugin for WordPress `VirtualHost`s: +Below is an example for enabling only the WordPress plugin for WordPress virtual hosts: ``` SecRule &TX:wordpress-rule-exclusions-plugin_enabled "@eq 0" \ From 9bc044902a1ea415eaef23ac9ff16d4e37d8e716 Mon Sep 17 00:00:00 2001 From: Esad Cetiner <104706115+EsadCetiner@users.noreply.github.com> Date: Sun, 9 Jun 2024 22:25:10 +1000 Subject: [PATCH 4/5] fix: clarify term virualhost --- content/concepts/plugins.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/concepts/plugins.md b/content/concepts/plugins.md index 8288f7f7..4384fce5 100644 --- a/content/concepts/plugins.md +++ b/content/concepts/plugins.md @@ -108,7 +108,7 @@ Alternatively, it is also valid to disable a plugin by renaming a plugin file fr ## Conditionally enable plugins for multi-application environments -If CRS is installed on a reverse-proxy or a web server with multiple web applications, then you may wish to only enable certain plugins (such as rule exclusion plugins) for certain `VirtualHosts`. This ensures that rules designed for a specific web application are only enabled for the intended web application, reducing the scope of any possible bypasses within a plugin. +If CRS is installed on a reverse-proxy or a web server with multiple web applications, then you may wish to only enable certain plugins (such as rule exclusion plugins) for certain VirtualHosts (`VirtualHost` for Apache httpd, `Server` context for Nginx). This ensures that rules designed for a specific web application are only enabled for the intended web application, reducing the scope of any possible bypasses within a plugin. Most plugins provide an example to disable the plugin in the file `plugin-config.conf`, you can define the `WebAppID` variable for each virtual host and then disable the plugin when the `WebAppID` variable doesn't match. From 59d96225f4c7e296781c74f5daffed23da21454d Mon Sep 17 00:00:00 2001 From: Esad Cetiner <104706115+EsadCetiner@users.noreply.github.com> Date: Sun, 9 Jun 2024 22:57:34 +1000 Subject: [PATCH 5/5] Apply suggestions from code review Co-authored-by: Max Leske <250711+theseion@users.noreply.github.com> --- content/concepts/plugins.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/content/concepts/plugins.md b/content/concepts/plugins.md index 4384fce5..1e8f93b7 100644 --- a/content/concepts/plugins.md +++ b/content/concepts/plugins.md @@ -108,7 +108,7 @@ Alternatively, it is also valid to disable a plugin by renaming a plugin file fr ## Conditionally enable plugins for multi-application environments -If CRS is installed on a reverse-proxy or a web server with multiple web applications, then you may wish to only enable certain plugins (such as rule exclusion plugins) for certain VirtualHosts (`VirtualHost` for Apache httpd, `Server` context for Nginx). This ensures that rules designed for a specific web application are only enabled for the intended web application, reducing the scope of any possible bypasses within a plugin. +If CRS is installed on a reverse-proxy or a web server with multiple web applications, then you may wish to only enable certain plugins (such as rule exclusion plugins) for certain virtual hosts (`VirtualHost` for Apache httpd, `Server` context for Nginx). This ensures that rules designed for a specific web application are only enabled for the intended web application, reducing the scope of any possible bypasses within a plugin. Most plugins provide an example to disable the plugin in the file `plugin-config.conf`, you can define the `WebAppID` variable for each virtual host and then disable the plugin when the `WebAppID` variable doesn't match.