DOCS-2409 Docs on release 0.7.0

docs/configuration-guides/allowlist.md

@@ -33,7 +33,7 @@ docker run --rm -it --network api-firewall-network --network-alias api-firewall
     -e APIFW_URL=<API_FIREWALL_URL> -e APIFW_SERVER_URL=<PROTECTED_APP_URL> \
     -e APIFW_REQUEST_VALIDATION=<REQUEST_VALIDATION_MODE> -e APIFW_RESPONSE_VALIDATION=<RESPONSE_VALIDATION_MODE> \
     -e APIFW_ALLOW_IP_FILE=/opt/ip-allowlist.txt -e APIFW_ALLOW_IP_HEADER_NAME="X-Real-IP" \
-    -p 8088:8088 wallarm/api-firewall:v0.6.17
+    -p 8088:8088 wallarm/api-firewall:v0.7.0
 ```
 
 | Environment variable | Description |

docs/installation-guides/api-mode.md

@@ -38,7 +38,7 @@ Use the following command to run the API Firewall container:
 
 ```
 docker run --rm -it -v <PATH_TO_SQLITE_DATABASE>:/var/lib/wallarm-api/1/wallarm_api.db \
-    -e APIFW_MODE=API -p 8282:8282 wallarm/api-firewall:v0.6.17
+    -e APIFW_MODE=API -p 8282:8282 wallarm/api-firewall:v0.7.0
 ```
 
 You can pass to the container the following variables:

docs/installation-guides/docker-container.md

@@ -27,7 +27,7 @@ networks:
 services:
   api-firewall:
     container_name: api-firewall
-    image: wallarm/api-firewall:v0.6.17
+    image: wallarm/api-firewall:v0.7.0
     restart: on-failure
     volumes:
       - <HOST_PATH_TO_SPEC>:<CONTAINER_PATH_TO_SPEC>
@@ -96,6 +96,9 @@ Pass API Firewall configuration in **docker-compose.yml** → `services.api-fire
 | `APIFW_MODE` | Sets the general API Firewall mode. Possible values are `PROXY` (default), [`graphql`](graphql/docker-container.md) and [`API`](api-mode.md). | No |
 | `APIFW_PASS_OPTIONS` | When set to `true`, the API Firewall allows `OPTIONS` requests to endpoints in the specification, even if the `OPTIONS` method is not described. The default value is `false`. | No |
 | `APIFW_SHADOW_API_UNKNOWN_PARAMETERS_DETECTION` | This specifies whether requests are identified as non-matching the specification if their parameters do not align with those defined in the OpenAPI specification. The default value is `true`.<br><br>If running API Firewall in the [`API` mode](api-mode.md), this variable takes on a different name `APIFW_API_MODE_UNKNOWN_PARAMETERS_DETECTION`. | No |
+| `APIFW_MODSEC_CONF_FILES` | Allows to set the list of [ModSecurity](../migrating/modseс-to-apif.md) configuration files. The delimiter is ;. The default value is [] (empty). Example: `APIFW_MODSEC_CONF_FILES=modsec.conf;crs-setup.conf.example`. | No |
+| `APIFW_MODSEC_RULES_DIR` | Allows to set the [ModSecurity](../migrating/modseс-to-apif.md) directory with the rules that should be loaded. The files with the following wildcard *.conf will be loaded from the dir. The default value is “”. | No |
+
 
 **With `services.api-firewall.ports` and `services.api-firewall.networks`**, set the API Firewall container port and connect the container to the created network. The provided **docker-compose.yml** instructs Docker to start API Firewall connected to the `api-firewall-network` [network](https://docs.docker.com/network/) on the port 8088.
 
@@ -153,6 +156,6 @@ To start API Firewall on Docker, you can also use regular Docker commands as in
         -v <HOST_PATH_TO_SPEC>:<CONTAINER_PATH_TO_SPEC> -e APIFW_API_SPECS=<PATH_TO_MOUNTED_SPEC> \
         -e APIFW_URL=<API_FIREWALL_URL> -e APIFW_SERVER_URL=<PROTECTED_APP_URL> \
         -e APIFW_REQUEST_VALIDATION=<REQUEST_VALIDATION_MODE> -e APIFW_RESPONSE_VALIDATION=<RESPONSE_VALIDATION_MODE> \
-        -p 8088:8088 wallarm/api-firewall:v0.6.17
+        -p 8088:8088 wallarm/api-firewall:v0.7.0
     ```
 4. When the environment is started, test it and enable traffic on API Firewall following steps 6 and 7.

docs/installation-guides/graphql/docker-container.md

@@ -29,7 +29,7 @@ networks:
 services:
   api-firewall:
     container_name: api-firewall
-    image: wallarm/api-firewall:v0.6.17
+    image: wallarm/api-firewall:v0.7.0
     restart: on-failure
     volumes:
       - <HOST_PATH_TO_SPEC>:<CONTAINER_PATH_TO_SPEC>
@@ -199,6 +199,6 @@ To start API Firewall on Docker, you can also use regular Docker commands as in
         -e APIFW_GRAPHQL_MAX_QUERY_COMPLEXITY=<MAX_QUERY_COMPLEXITY> \
         -e APIFW_GRAPHQL_MAX_QUERY_DEPTH=<MAX_QUERY_DEPTH> -e APIFW_GRAPHQL_NODE_COUNT_LIMIT=<NODE_COUNT_LIMIT> \
         -e APIFW_GRAPHQL_INTROSPECTION=<ALLOW_INTROSPECTION_OR_NOT> \
-        -p 8088:8088 wallarm/api-firewall:v0.6.17
+        -p 8088:8088 wallarm/api-firewall:v0.7.0
     ```
 4. When the environment is started, test it and enable traffic on API Firewall following steps 6 and 7.

docs/migrating/modseс-to-apif.md

@@ -0,0 +1,63 @@
+# Migrating to API Firewall from ModSecurity
+
+This guide walks through migrating from [ModSecurity](https://github.com/owasp-modsecurity/ModSecurity) to Wallarm's API Firewall by explaining how to import the ModSecurity rules to API Firewall and set API Firewall to perform protection in accordance with these rules.
+
+## Problem and solution
+
+In August 2021, Trustwave [announced](https://www.trustwave.com/en-us/resources/security-resources/software-updates/end-of-sale-and-trustwave-support-for-modsecurity-web-application-firewall/) the end-of-sale for ModSecurity support, and the subsequent end-of-life date for their support of ModSecurity of July 2024. Trustwave has been providing regular updates to the standard rules for ModSecurity, supporting what was effectively an open source community tool with commercial quality detection rules. Reaching the end-of-life date and support ending may quickly put any organizations using ModSecurity rules at risk by quickly becoming out-of-date with their attack detection.
+
+Wallarm supports easy transitioning from ModSecurity to Wallarm's API Firewall: ModSecurity rules can be effortlessly connected to API Firewall and continued to be used without additional configuration.
+
+## ModSecurity rules support
+
+API Firewall's ModSecurity Rules Support module allows parsing and applying ModSecurity rules (secLang) to the traffic. The module is implemented using the [Coraza](https://github.com/corazawaf/coraza) project.
+
+The module works for REST API both in the [API](../installation-guides/api-mode.md) and [PROXY](../installation-guides/docker-container.md) modes. In the API mode, only requests are checked.
+
+Supported response actions: 
+
+* `drop`, `deny` - respond to the client by error message with APIFW_CUSTOM_BLOCK_STATUS_CODE code or status value (if configured in the rule).
+* `redirect` - responds by status code and target which were specified in the rule.
+
+GraphQL API is currently not supported.
+
+## Running API Firewall on ModSecurity rules
+
+To run API Firewall on ModSecurity rules:
+
+1. Prepare ModSecurity configuration and rule files.
+1. Run API Firewall for REST API as described [here](../installation-guides/docker-container.md) using the [ModSecurity configuration parameters](#modsecurity-configuration-parameters) to connect the prepared configuration and rule files.
+
+### ModSecurity configuration parameters
+
+To start API Firewall on ModSecurity rules, you will need the set of configuration parameters that allow connecting and using ModSecurity rules:
+
+* `APIFW_MODSEC_CONF_FILES`: allows to set the list of ModSecurity configuration files. The delimiter is ;. The default value is [] (empty). Example: `APIFW_MODSEC_CONF_FILES=modsec.conf;crs-setup.conf`
+* `APIFW_MODSEC_RULES_DIR`: allows to set the ModSecurity directory with the rules that should be loaded. The files with the following wildcard *.conf will be loaded from the dir. The default value is “”.
+
+### Example: Starting API Firewall on OWASP CRS with Coraza recommended configuration
+
+You can start API Firewall on [OWASP ModSecurity Core Rule Set (CRS)](https://owasp.org/www-project-modsecurity-core-rule-set/) with Coraza [recommended configuration](https://github.com/corazawaf/coraza/blob/main/coraza.conf-recommended) (copy in included into API Firewall's `./resources/` folder):
+
+1. Clone the repo with the OWASP CRS:
+
+    ```
+    git clone https://github.com/coreruleset/coreruleset.git
+    ```
+
+1. Start the APIFW v0.7.0 with the provided API specification and OWASP CRS:
+
+    ```
+    docker docker run --rm -it --network api-firewall-network --network-alias api-firewall \
+        -v <HOST_PATH_TO_SPEC>:<CONTAINER_PATH_TO_SPEC> \
+        -v ./resources/coraza.conf-recommended:/opt/coraza.conf \
+        -v ./coreruleset/:/opt/coreruleset/ \
+        -e APIFW_API_SPECS=<CONTAINER_PATH_TO_SPEC> \
+        -e APIFW_URL=<API_FIREWALL_URL> \
+        -e APIFW_SERVER_URL=<PROTECTED_APP_URL> \
+        -e APIFW_REQUEST_VALIDATION=BLOCK \
+        -e APIFW_RESPONSE_VALIDATION=BLOCK \
+        -e APIFW_MODSEC_CONF_FILES=/opt/coraza.conf;/opt/coreruleset/crs-setup.conf.example \
+        -e APIFW_MODSEC_RULES_DIR=/opt/coreruleset/rules/ \
+        -p 8088:8088 wallarm/api-firewall:v0.7.0
+    ```

docs/release-notes.md

@@ -2,6 +2,12 @@
 
 This page describes new releases of Wallarm API Firewall.
 
+## v0.7.0 (2024-04-03)
+
+* Added [ModSecurity rules support](migrating/modseс-to-apif.md) (based on the [Coraza](https://github.com/corazawaf/coraza) project)
+* Fixed processing issues for the requests with the OPTIONS method
+* Added additional info to the log message of the Shadow API module
+
 ## v0.6.17 (2024-03-28)
 
 * Added [IP allowlisting](configuration-guides/allowlist.md) support in the `API` mode

mkdocs.yml

@@ -87,6 +87,8 @@ nav:
     - GraphQL Limits Compliance: installation-guides/graphql/limit-compliance.md
     - WebSocket Origin Validation: installation-guides/graphql/websocket-origin-check.md
     - GraphQL Playground: installation-guides/graphql/playground.md
+  - Migrating from Other WAFs:
+    - Migrating from ModSecurity: migrating/modseс-to-apif.md
   - Additional Configuration:
     - Validating Request Authentication Tokens: configuration-guides/validate-tokens.md
     - Blocking Requests with Compromised Tokens: configuration-guides/denylist-leaked-tokens.md