Skip to content

Upgrading the cloud node image

These instructions describe the steps to upgrade the cloud node image 4.0 or 3.x deployed on AWS or GCP up to 4.2.

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 US Cloud or EU Cloud

  • Access to https://us1.api.wallarm.com if working with US Wallarm Cloud or to https://api.wallarm.com if working with EU 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 us1.api.wallarm.com:443 (US Cloud) and api.wallarm.com:443 (EU Cloud) API endpoints instead of us1.api.wallarm.com:444 and api.wallarm.com:444.

If you upgrade the node from the version 3.x or lower and 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 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: Launch a new instance with the filtering node 4.2

  1. Open the Wallarm filtering node image on the cloud platform marketplace and proceed to the image launch:

  2. At the launch step, set the following settings:

    • Select the image version 4.2.x
    • For AWS, select the created security group in the field Security Group Settings
    • For AWS, select the name of the created key pair in the field Key Pair Settings

  3. Confirm the instance launch.

  4. For GCP, configure the instance following these instructions.

Step 3: Connect the filtering node to Wallarm Cloud

  1. Connect to the filtering node instance via SSH. More detailed instructions for connecting to the instances are available in the cloud platform documentation:

  2. Create a new Wallarm node and connect it to the Wallarm Cloud using the generated token as described in the instructions for the cloud platform:

Step 4: Copy the filtering node settings from the previous version to the new version

  1. Copy the settings for processing and proxying requests from the following configuration files of the previous Wallarm node version to the files of the filtering node 4.2:

    • /etc/nginx/nginx.conf and other files with NGINX settings
    • /etc/nginx/conf.d/wallarm.conf with global filtering node settings
    • /etc/nginx/conf.d/wallarm-status.conf with the filtering node monitoring service settings
    • /etc/environment with environment variables
    • /etc/default/wallarm-tarantool with Tarantool settings
    • other files with custom settings for processing and proxying requests

  2. If you upgrade the node from version 3.6, rename the following NGINX directive if it is explicitly specified in configuration files:

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

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

  3. If you upgrade the node from version 3.6 or lower and have the extended logging format configured, please check if the wallarm_request_time variable is explicitly specified in the configuration.

    If so, please rename it 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.

  4. 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 to blocked requests, copy and customize its new version.

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

Detailed information about working with NGINX configuration files is available in the official NGINX documentation.

The list of filtering node directives is available here.

Step 5: 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 wallarm_process_time_limit and wallarm_process_time_limit_block NGINX directives have been used. The listed directives 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 directives, 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 via the NGINX directives:

    • The rule condition should match the NGINX configuration block with the wallarm_process_time_limit and wallarm_process_time_limit_block directives specified.
    • The time limit for the node to process a single request (milliseconds): the value of wallarm_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 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 graylisted 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 and wallarm_process_time_limit_block NGINX directives from the NGINX configuration file.

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

Step 6: Restart NGINX

Restart NGINX to apply the settings:

sudo systemctl restart nginx

Step 7: Test Wallarm 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. Open the Wallarm Console → Events section in the US Cloud or EU Cloud and ensure attacks are displayed in the list.

    Attacks in the interface

Step 8: Create the virtual machine image based on the filtering node 4.2 in AWS or GCP

To create the virtual machine image based on the filtering node 4.2, please follow the instructions for AWS or GCP.

Step 9: Delete the previous Wallarm node instance

If the new version of the filtering node is successfully configured and tested, remove the instance and virtual machine image with the previous version of the filtering node using the AWS or GCP management console.