Skip to content

Upgrading the Docker NGINX- or Envoy-based image

These instructions describe the steps to upgrade the running Docker NGINX- or Envoy-based image 3.x to the version 4.0.

Using credentials of already existing Wallarm node

We do not recommend using the already existing Wallarm node of the previous version. Please follow these instructions to create a new filtering node of the version 4.0 and deploy it as the Docker container.

To upgrade the node 2.18 or lower, please use the different instructions.

Requirements

  • Access to the account with the Administrator role in Wallarm Console in the EU Cloud or US Cloud

  • Access to https://api.wallarm.com if working with EU Wallarm Cloud or to https://us1.api.wallarm.com if working with US Wallarm Cloud. Please ensure the access is not blocked by a firewall

Step 1: Update API port

Starting with version 4.0, the filtering node uploads data to the Cloud using the api.wallarm.com:443 (EU Cloud) and us1.api.wallarm.com:443 (US Cloud) API endpoints instead of api.wallarm.com:444 and us1.api.wallarm.com:444.

If your server with the deployed node has a limited access to the external resources and the access is granted to each resource separately, then after upgrade to version 4.0 the synchronization between the filtering node and the Cloud will stop.

To restore the synchronization, in your configuration, change port 444 to 443 for API endpoint for each resource.

Step 2: Download the updated filtering node image

docker pull wallarm/node:4.0.1-1
docker pull wallarm/envoy:4.0.1-1

Step 3: Switch to the token-based connection to the Wallarm Cloud

The approach to connect the container to the Wallarm Cloud has been upgraded as follows:

  • The "email and password"-based approach has been deprecated. In this approach, the node was registered in the Wallarm Cloud automatically once the container started with correct credentials passed in the DEPLOY_USER and DEPLOY_PASSWORD variables.

  • The token-based approach has been included. To connect the container to the Cloud, run the container with the WALLARM_API_TOKEN variable containing the Wallarm node token copied from the Wallarm Console UI.

It is recommended to use the new approach to run the image 4.0. The "email and password"-based approach will be deleted in future releases, please migrate before.

To create a new Wallarm node and get its token:

  1. Open Wallarm Console → Nodes in the EU Cloud or US Cloud and create the node of the Wallarm node type.

    Wallarm node creation

  2. Copy the generated token.

Step 4: Switch from deprecated configuration options

The following configuration options have been deprecated:

  • The NGINX directive wallarm_ts_request_memory_limit has been renamed to wallarm_general_ruleset_memory_limit.

    We only changed the directive name, its logic remains the same. Directive with former name will be deleted in future releases, so you are recommended to rename it before.

    Please check if the directive with former name is explicitly specified in the mounted configuration files. If so, rename it.

  • The wallarm_request_time logging variable has been renamed to wallarm_request_cpu_time.

    We only changed the variable name, its logic remains the same. The old name is temporarily supported as well, but still it is recommended to rename the variable.

  • The following Envoy parameters have been renamed:

    We only changed parameter names, their logic remains the same. Parameters with former names will be deleted in future releases, so you are recommended to rename them before.

    Please check if the parameters with former names are explicitly specified in the mounted configuration files. If so, rename them.

If you upgrade the node from version 3.4 or lower, there are more renamed directives and parameters:

Step 5: Update the Wallarm blocking page (if upgrading NGINX-based image from version 3.4 or lower)

In node 3.6, the Wallarm sample blocking page has been changed. The logo and support email on the page are now empty by default.

If you upgrade the node from version 3.4 or lower and the node is configured to return the &/usr/share/nginx/html/wallarm_blocked.html page in response to the blocked requests, transfer this configuration as follows:

  1. Copy and customize the new version of a sample page.

  2. Mount the new customized or previously used page and the NGINX configuration file to a new Docker container in the next step.

Step 6: Transfer the overlimit_res attack detection configuration from directives to the rule

Starting from the version 3.6, you can fine-tune the overlimit_res attack detection using the rule in Wallarm Console.

Earlier, the following options have been used:

The listed directives and parameters are considered to be deprecated with the new rule release and will be deleted in future releases.

If the overlimit_res attack detection settings are customized via the listed parameters, it is recommended to transfer them to the rule as follows:

  1. Open Wallarm Console → Rules and proceed to the Fine-tune the overlimit_res attack detection rule setup.

  2. Configure the rule as done in the mounted configuration files:

    • The rule condition should match the NGINX or Envoy configuration block with the wallarm_process_time_limit and wallarm_process_time_limit_block directives or the process_time_limit and process_time_limit_block parameters specified.
    • The time limit for the node to process a single request (milliseconds): the value of wallarm_process_time_limit or process_time_limit.
    • Request processing: the Stop processing option is recommended.

      Risk of running out of system memory

      The high time limit and/or continuation of request processing after the limit is exceeded can trigger memory exhaustion or out-of-time request processing.

    • Register the overlimit_res attack: the Register and display in the events option is recommended.

      If the wallarm_process_time_limit_block or process_time_limit_block value is off, choose the Do not create attack event option.

    • The rule does not have the explicit equivalent option for the wallarm_process_time_limit_block (process_time_limit_block in Envoy) directive. If the rule sets Register and display in the events, the node will either block or pass the overlimit_res attack depending on the node filtration mode:

      • In the monitoring mode, the node forwards the original request to the application address. The application has the risk to be exploited by the attacks included in both processed and unprocessed request parts.
      • In the safe blocking mode, the node blocks the request if it is originated from the greylisted IP address. Otherwise, the node forwards the original request to the application address. The application has the risk to be exploited by the attacks included in both processed and unprocessed request parts.
      • In the block mode, the node blocks the request.
  3. Delete the wallarm_process_time_limit, wallarm_process_time_limit_block NGINX directives and the process_time_limit, process_time_limit_block Envoy parameters from the mounted configuration file.

    If the overlimit_res attack detection is fine-tuned using both the parameters and the rule, the node will process requests as the rule sets.

Step 7: Stop the running container

docker stop <RUNNING_CONTAINER_NAME>

Step 8: Run the container using the new image

Run the container using the updated image. You can pass the same configuration parameters that were passed when running a previous image version except for the ones listed in the previous steps.

There are two options for running the container using the updated image:

Step 9: Test the filtering node operation

  1. Send the request with test SQLI and XSS attacks to the application address:

    curl http://localhost/?id='or+1=1--a-<script>prompt(1)</script>'
    
  2. Make sure the node of the new type processes the request in the same way as the regular node did, e.g.:

  3. Open Wallarm Console → Events in the EU Cloud or US Cloud and make sure that:

    • Attacks are displayed in the list.
    • Hit details display the Wallarm node UUID.

    Attacks in the interface

Step 10: Delete the filtering node of the previous version

If the deployed image of the version 4.0 operates correctly, you can delete the filtering node of the previous version in Wallarm Console → Nodes.

Back to top