Apply suggestions from code review

Co-authored-by: Max Leske <[email protected]>

content/deployment/install.md

@@ -15,18 +15,18 @@ Below you should find all the information you need to properly install CRS. If y
 Installing the CRS isn't very hard but it does have one major requirement: a compatible engine. The base reference engine shown here is ModSecurity.
 
 {{% notice warning %}}
-In order to run the CRS `3.x` using ModSecurity we recommend you to use the latest version available. For Nginx please use the `3.x` branch of ModSecurity, and for Apache use the latest `2.x` branch.
+In order to run the CRS `3.x` using ModSecurity, we recommend you use the latest version available. For Nginx please use the `3.x` branch of ModSecurity, and for Apache use the latest `2.x` branch.
 {{% /notice %}}
 
 ## How to install a compatible engine
 
-Here we will cover two different ways of getting your engine up and running: you can use your favorite engine provided by your OS distribution, or it can be compiled from source. Here we will cover ModSecurity installs, but you can see the Coraza install documents [here](https://www.coraza.io).
+Here we will cover two different ways of getting your engine up and running: you can use your favorite engine provided by your OS distribution, or it can be compiled from source. Here we will cover ModSecurity installs, but you may want to take a look at the [Coraza install documents](https://www.coraza.io).
 
 ### Installing ModSecurity
 
-Pre-packaged modsecurity can be get from major Linux distributions.
+Pre-packaged modsecurity is available for most major Linux distributions.
 
-- Debian: our friends at [DigitalWave](https://modsecurity.digitalwave.hu) package and most importantly **keep ModSecurity updated** for debian and derivatives, so check their repo!
+- Debian: our friends at [DigitalWave](https://modsecurity.digitalwave.hu) package and most importantly **keep ModSecurity updated** for Debian and derivatives, so check their repo!
 - Fedora:
   - `dnf install mod_security` for Apache + ModSecurity2
 - RHEL compatible: you will need to install EPEL and then `yum install mod_security`.
@@ -45,18 +45,18 @@ Examples of this `<web server config>/` are:
 - `/etc/apache2` in Debian and derivatives
 - `/etc/httpd` in RHEL and derivatives
 - `/usr/local/apache2` if you compiled apache from source with the default prefix
-- `C:\Program Files\ModSecurity IIS\` (or Program Files(x86) depending on your configuration) on Windows
+- `C:\Program Files\ModSecurity IIS\` (or `Program Files(x86)` depending on your configuration) on Windows
 - `/etc/nginx`
 
 ### Compiling ModSecurity
 
-Compiling ModSecurity is easy, but slightly outside the scope of this document. If you are interested in learning how to compile ModSecurity please go to the [ModSecurity documentation](https://github.com/SpiderLabs/ModSecurity/wiki). Having compiled ModSecurity there is a simple test to see if your installation is working. If you have compiled from source you would need to include the directive to **load your module** in your Web Server.
+Compiling ModSecurity is easy, but slightly outside the scope of this document. If you are interested in learning how to compile ModSecurity please go to the [ModSecurity documentation](https://github.com/SpiderLabs/ModSecurity/wiki). Having compiled ModSecurity, there is a simple test to see if your installation works. If you have compiled from source you would need to include the directive to **load your module** in your Web Server.
 
 Examples:
-- apache: `LoadModule security2_module modules/mod_security2.so`
-- nginx: `load_module modules/ngx_http_modsecurity_module.so;`
+- Apache: `LoadModule security2_module modules/mod_security2.so`
+- Nginx: `load_module modules/ngx_http_modsecurity_module.so;`
 
-Now you restart your server and modsecurity should output that it is being used. Examples:
+Now you restart your server and modsecurity should announce that it is being used in the log. Examples:
 ```
 2022/04/21 23:45:52 [notice] 1#1: ModSecurity-nginx v1.0.2 (rules loaded inline/local/remote: 0/6/0)
 ```
@@ -80,11 +80,11 @@ This is **not** supported. It doesn't work as expected. Our recommendation is to
 
 ### Nginx with ModSecurity 3.x (libmodsecurity) Compiled
 
-You can found the compilation recipe in the [ModSecurity wiki](https://github.com/SpiderLabs/ModSecurity/wiki/Compilation-recipes-for-v3.x). 
+You can find the compilation recipe in the [ModSecurity wiki](https://github.com/SpiderLabs/ModSecurity/wiki/Compilation-recipes-for-v3.x). 
 
 ### Microsoft IIS with ModSecurity 2.x
 
-The inital configuration file, is `modsecurity_iis.conf`. This file will be parsed by the ModSecurity for both ModSecurity and `'Include'` directives.
+The inital configuration file is `modsecurity_iis.conf`. This file will be parsed by ModSecurity for both ModSecurity and `'Include'` directives.
 
 Additionally, in your Event Viewer, under `Windows Logs\Application'`, we should see a new log that looks like the following:
 
@@ -147,23 +147,23 @@ Once you downloaded and verified the release, you are ready to continue with the
 
 ### Setting up OWASP CRS
 
-OWASP CRS contains one setup file that should be reviewed prior to completing setup. The setup file is the only configuration file within the root 'coreruleset-{{< param crs_latest_release >}}' folder and is named `csr-setup.conf.example`. Going through this configuration file and reading what the different options are is HIGHLY recommended. At minimum you should keep in mind the following.
+OWASP CRS contains one setup file that should be reviewed prior to completing setup. The setup file is the only configuration file within the root 'coreruleset-{{< param crs_latest_release >}}' folder and is named `csr-setup.conf.example`. Going through this configuration file and reading what the different options are is **HIGHLY** recommended. As a minimum, you should keep in mind the following:
 
-- CRS does not configure features such as the rule engine, the audit engine, logging etc. This task is part of your initial setup. For ModSecurity, if you haven't done this yet please check out the [recommended configuration](https://github.com/SpiderLabs/ModSecurity/blob/master/modsecurity.conf-recommended)
-- By default [SecDefaultAction](https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-%28v2.x%29#SecDefaultAction) CRS will redirect to your local domain when an alert is triggered. This may cause redirect loops depending on your configuration. Take some time to decide what you want ModSecurity it do (drop the packet, return a status:403, go to a custom page etc.) when it detects malicious activity.
-- Make sure to configure your anomaly scoring thresholds for more information see [Anomaly]({{< ref "anomaly_scoring.md" >}} "Anomaly")
-- By default our rules will consider many issues with different databases and languages. If you are running in a specific environment, you probably want to limit this behavior for performance reasons.
+- CRS does not configure features such as the rule engine, the audit engine, logging etc. These tasks are part of your initial setup. For ModSecurity, if you haven't done this yet, please check out the [recommended configuration](https://github.com/SpiderLabs/ModSecurity/blob/master/modsecurity.conf-recommended)
+- By default, CRS will redirect to your local domain when an alert is triggered (see [SecDefaultAction](https://github.com/SpiderLabs/ModSecurity/wiki/Reference-Manual-%28v2.x%29#SecDefaultAction)). This may cause redirect loops depending on your configuration. Take some time to decide what you want ModSecurity to do (drop the packet, return a HTTP status code of 403, go to a custom page etc.) when it detects malicious activity.
+- Make sure to configure your anomaly scoring thresholds. For detailed information see [Anomaly]({{< ref "anomaly_scoring.md" >}} "Anomaly")
+- By default, our rules will consider many issues with different databases and languages. If you are running in a specific environment, you probably want to limit this behavior for performance reasons or to avoid false positives.
 - ModSecurity supports [Project Honeypot](https://www.projecthoneypot.org/) blacklists. This is a great project and all you need to do to leverage it is sign up for an [API key](https://www.projecthoneypot.org/httpbl_api.php) (⚠️ it might be outdated)
 - Do make sure you have added any methods, static resources, content types, or file extensions that your site needs beyond the basic ones listed.
 
 For more information please see the page on [configuration]({{< ref "crs.md" >}} "configuration"). Once you have reviewed
-and configured CRS you should rename the file suffix from `.example` to `.conf`:
+and configured CRS, you need to remove the `.example`:
 
 ```bash
 mv csr-setup.conf.example csr-setup.conf
 ```
 
-In addition to `csr-setup.conf.example` there are two other .example files within our repository. These files are:
+In addition to `csr-setup.conf.example` there are two other `.example` files within our repository. These files are:
 `rules/REQUEST-900-EXCLUSION-RULES-BEFORE-CRS.conf.example` and `rules/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf.example`. These files are designed to provide the rule maintainer the capability to modify rules (see [false positives and tuning]({{< ref "../configuring/false_positives_tuning.md" >}}#rule-exclusions)) without breaking forward compatibility with updates. As such you should rename these two files, removing the `.example` suffix. This will make it so that even when updates are installed they do not overwrite your custom updates. To rename the files in Linux one would use a command similar to the
 following:
 
@@ -174,23 +174,28 @@ mv rules/RESPONSE-999-EXCLUSION-RULES-AFTER-CRS.conf.example rules/RESPONSE-999-
 
 ## Proceeding with the Installation
 
-The engine should support the `Include` directive out of the box. The directive tells the engine to parse additional files for directives. But where do you place this folder for it to be included? If you were to look at the CRS files, you'd note there are quite a few .conf files. While the names attempt to do a good job at describing what each file does additional information is available in the [rules](rules.md) section.
+The engine should support the `Include` directive out of the box. The directive tells the engine to parse additional files for directives. But where do you place this folder for it to be included? If you were to look at the CRS files, you'd note there are quite a few `.conf` files. While the names attempt to do a good job at describing what each file `does,` additional information is available in the [rules]({{< ref "rules.md" >}}) section.
 
 ### Includes for Apache
 
-We recommend you creating a folder specifically for the rules. In our example we have named this `modsecurity.d` and placed in within the root `<web server config>/` directory. When using Apache we can use the wildcard notation to vastly simplify our rules. Simply copying our cloned directory to our `modsecurity.d` folder and specifying the appropiate include directives will allow us to install OWASP CRS. In the example below we have also included our `modsecurity.conf` file which includes reccomended configurations for ModSecurity
+We recommend you create a directory specifically for the rules. In our example we have named it `modsecurity.d` and placed it in the root `<web server config>/` directory. When using Apache, we can use the wildcard notation to vastly simplify our rules. Simply copying our cloned directory to our `modsecurity.d` folder and specifying the appropriate include directives will allow us to install OWASP CRS. In the example below we have also included our `modsecurity.conf` file which includes recomended configurations for ModSecurity:
 
 ```apache
 <IfModule security2_module>
         Include modsecurity.d/modsecurity.conf
         Include modsecurity.d/coreruleset-{{< param crs_latest_release >}}/csr-setup.conf
+        
+        Include modsecurity.d/coreruleset-{{< param crs_latest_release >}}/plugins/*-config.conf
+        Include modsecurity.d/coreruleset-{{< param crs_latest_release >}}/plugins/*-before.conf           
         Include modsecurity.d/coreruleset-{{< param crs_latest_release >}}/rules/*.conf
+        
+        Include modsecurity.d/coreruleset-{{< param crs_latest_release >}}/plugins/*-after.conf
 </IfModule>
 ```
 
 ### Includes for Nginx
 
-Nginx will include from the Nginx conf directory (`/etc/nginx` or `/usr/local/nginx/conf/` depending on the environment). Because only one `ModSecurityConfig` directive can be specified within nginx.conf we recommend naming that file `modsec_includes.conf` and including additional files from there. In the example below we copied our cloned `owasp-modsecurity-crs` folder into our Nginx configuration directory. From there we specify the appropiate include directives which will include OWASP CRS when the server is restarted. In the example below we have also included our `modsecurity.conf` file which includes reccomended configurations for ModSecurity
+Nginx will include from the Nginx conf directory (`/etc/nginx` or `/usr/local/nginx/conf/` depending on the environment). Because only one `ModSecurityConfig` directive can be specified within `nginx.conf` we recommend naming that file `modsec_includes.conf` and including additional files from there. In the example below, we copied our cloned `owasp-modsecurity-crs` directory into our Nginx configuration directory. From there, we specify the appropriate include directives which will include OWASP CRS when the server is restarted. In the example below, we have also included our `modsecurity.conf` file which includes recomended configurations for ModSecurity:
 
 ```nginx
 include modsecurity.conf

content/deployment/quickstart.md

@@ -119,13 +119,13 @@ systemctl restart httpd.service
 
 ## Using Containers
 
-Another quick option is to leverage our pre-packaged containers. You can use docker, podman, or any container compatible engine. Our images are published in the docker hub. The one you probably want is the `owasp/modsecurity-crs`: it already has everything to get you up and running quickly.
+Another quick option is to leverage our pre-packaged containers. You can use docker, podman, or any container compatible engine. Our images are published on [Docker Hub](https://hub.docker.com/r/owasp/modsecurity-crs). The one you probably want is the `owasp/modsecurity-crs`: it already has everything to get you up and running quickly.
 
-We already pre-package both Apache and Nginx Web servers with the corresponding ModSecurity engine. More engines (like Coraza) will come later.
+We already pre-package both Apache and Nginx web servers with the corresponding ModSecurity engine. More engines (like Coraza) will come later.
 
-So to protect your running Web Server, just get the image and use these configuration variables to make the WAF receive the requests and proxy your server.
+So to protect your running web server, just get the image and use these configuration variables to make the WAF receive the requests and proxy your server.
 
-This is an example `docker-compose` that can be used to pull the container images. You just need to change the `BACKEND` server so it points to your own server:
+This is an example `docker-compose.yaml`, that can be used to pull the container images. You just need to change the `BACKEND` server so it points to your own server:
 
 ```docker-compose
 services: