What is new in Wallarm node 3.6¶
This page lists the changes available when upgrading the node 3.4 or 3.2 up to version 3.6. Listed changes are available for both the regular (client) and multi-tenant Wallarm nodes. Before upgrading the modules, please carefully review the list of changes and general recommendations.
If upgrading Wallarm node 2.18 or lower, learn available changes from the separate list.
When upgrading node 3.4¶
There are the following changes available in Wallarm node 3.6:
-
New method for the serverless Wallarm node deployment.
The new deployment method lets you configure the Wallarm CDN node outside your infrastructure in 15 minutes. You need to just point to the domain to be protected and add the Wallarm CNAME record to the domain’s DNS records.
-
Wallarm Ingress controller based on the latest version of Community Ingress NGINX Controller, 1.1.3.
Instructions on migrating to the Wallarm Ingress controller 3.6 →
-
Added support for AlmaLinux, Rocky Linux and Oracle Linux 8.x instead of the deprecated CentOS 8.x.
Wallarm node packages for the alternative operating systems will be stored in the CentOS 8.x repository.
-
We have introduced the new rule allowing the
overlimit_res
attack detection fine-tuning.The
overlimit_res
attack detection fine-tuning via the NGINX and Envoy configuration files is considered to be the deprecated way:- The rule allows setting up a single request processing time limit as the
wallarm_process_time_limit
NGINX directive andprocess_time_limit
Envoy parameter did before. - The rule allows to block or pass the
overlimit_res
attacks in accordance with the node filtration mode instead of thewallarm_process_time_limit_block
NGINX directive andprocess_time_limit_block
Envoy parameter configuration.
The listed directives and parameters have been deprecated and will be deleted in future releases. It is recommended to transfer the
overlimit_res
attack detection configuration from directives to the rule before. Relevant instructions are provided for each node deployment option.If the listed parameters are explicitly specified in the configuration files and the rule is not created yet, the node processes requests as set in the configuration files.
- The rule allows setting up a single request processing time limit as the
-
New layout and customization options of the blocking page
/usr/share/nginx/html/wallarm_blocked.html
. In the new node version, you can customize the logo and support email displayed on the page.The sample blocking page with the new layout looks as follows:
-
The new
wallarm_acl_access_phase
directive enables you to increase the Wallarm node performance by omitting the attack search stage during the analysis of requests from denylisted IPs. This configuration option is useful if there are many denylisted IPs (e.g. the whole countries) producing high traffic that heavily loads the working machine CPU. -
The following NGINX directives and Envoy parameters have been renamed:
- NGINX:
wallarm_instance
→wallarm_application
- NGINX:
wallarm_local_trainingset_path
→wallarm_custom_ruleset_path
- NGINX:
wallarm_global_trainingset_path
→wallarm_protondb_path
- Envoy:
lom
→custom_ruleset
- Envoy:
instance
→application
Parameters with previous names are still supported but will be deprecated in future releases. The parameter logic has not changed.
- NGINX:
-
The Ingress annotation
nginx.ingress.kubernetes.io/wallarm-instance
has been renamed tonginx.ingress.kubernetes.io/wallarm-application
.The annotation with the previous name is still supported but will be deprecated in future releases. The annotation logic has not changed.
-
The file with the custom ruleset build
/etc/wallarm/lom
has been renamed to/etc/wallarm/custom_ruleset
. In the file system of new node versions, there is only the file with the new name.Default values of the NGINX directive
wallarm_custom_ruleset_path
and Envoy parametercustom_ruleset
have been changed appropriately. New default value is/etc/wallarm/custom_ruleset
. -
The following node statistics parameters have been renamed:
lom_apply_time
→custom_ruleset_apply_time
lom_id
→custom_ruleset_id
In new node versions, the
http://127.0.0.8/wallarm-status
endpoint temporarily returns both the deprecated and new parameters. The deprecated parameters will be removed from the service output in future releases. -
The collectd metric
gauge-lom_id
has been renamed togauge-custom_ruleset_id
.In new node versions, the collectd service collects both the deprecated and new metrics. The deprecated metric collection will be stopped in future releases.
-
New environment variable
NGINX_PORT
to be passed to the Wallarm NGINX‑based Docker container.This variable sets a port that NGINX will use inside the Docker container. This allows avoiding port collision when using this Docker container as a sidecar container within a pod of Kubernetes cluster.
Instructions on deploying the Wallarm NGINX‑based Docker container →
When upgrading node 3.2¶
Wallarm node 3.6 provides all changes listed above as well as the following:
-
Support for CloudLinux OS 6.x
-
Support for Debian 11 Bullseye
-
Version of Envoy used in Wallarm Envoy-based Docker image has been increased to 1.18.4
-
New environment variable
WALLARM_APPLICATION
to be passed to the Wallarm NGINX‑based Docker container. This variable sets the identifier of the protected application to be used in the Wallarm Cloud.Instructions on deploying the Wallarm NGINX‑based Docker container →
Which Wallarm nodes are recommended to be upgraded?¶
-
Regular (client) Wallarm node of version 3.x to stay up to date with Wallarm releases and prevent installed module deprecation.
-
Regular (client) and multi-tenant Wallarm nodes of the deprecated versions (2.18 and lower). Changes available in Wallarm node 3.x simplifies the node configuration and improves traffic filtration. Please note that some settings of node 3.x are incompatible with the node of older versions.
Upgrade process¶
-
Upgrade installed modules following the instructions for your Wallarm node deployment option: