What is new in Wallarm node 4.10¶

The new version of the Wallarm node has been released! This update introduces an advanced feature for credential stuffing detection and specification-based security policies, further enhancing the security of your APIs.

Selected artifacts enhanced in release 4.10

Several artifacts, including individual DEB/RPM packages for NGINX, a Helm chart for the Kong Ingress Controller, and an Envoy-based Docker image, have NOT been released as part of version 4.10 and therefore do not support the newly introduced capabilities.

Credential stuffing detection ¶

Beginning with release 4.10, Wallarm introduces real-time detection and notifications for credential stuffing attempts. Credential stuffing, the automated submission of stolen or weak username/email and password pairs into website login forms to illegitimately access user accounts, is now closely monitored. This feature allows you to identify accounts with compromised credentials and take action to secure them, such as notifying account owners and temporarily suspending account access.

Learn how to configure Credential Stuffing Detection

API response discovery (node 4.10.1 and higher)¶

With the 4.10.1 release, we are enhancing Wallarm API Discovery now giving you in-depth information about your API responses. This functionality will discover your API endpoint response structures, highlighting changes, detecting new and unused parameters, and identifying sensitive data.

Optimized and more secure NGINX-based Docker image¶

The Docker image of Wallarm's NGINX-based filtering node has been revamped for enhanced security and optimization. Key updates include:

The Docker image is now built on Alpine Linux, replacing Debian, to provide a more secure and lightweight artifact. Please note that the auth-pam and subs-filter NGINX modules, previously included, are no longer packaged with the Docker image.
Updated to the latest stable version of NGINX, 1.24.0, replacing the previous 1.14.x version. Although most vulnerabilities in 1.14.x were patched by the Debian team (the prior image was based on Debian 10.x), upgrading to 1.24.0 addresses remaining vulnerabilities for improved security.

The NGINX upgrade, along with the switch to Alpine Linux, resolves the HTTP/2 Rapid Reset Vulnerability (CVE-2023-44487), due to the Alpine-specific patch implemented in NGINX 1.24.0.
Support for processors with ARM64 architecture, which is automatically identified during the installation process.
Inside the Docker container, all operations now utilize the non-root user wallarm, a change from the previous root user setup. It affects the NGINX process as well.
The /wallarm-status endpoint has been updated to export metrics in the Prometheus format, instead of JSON. This applies specifically when accessing the endpoint from outside the Docker container. Note that the WALLARM_STATUS_ALLOW environment variable must be set appropriately for this functionality.
The Docker image is now built using the all-in-one installer, which changes its internal directory structure:
- Log file directory: /var/log/wallarm → /opt/wallarm/var/log/wallarm.
- Directory with files containing credentials for the Wallarm node to connect to the Cloud: /etc/wallarm → /opt/wallarm/etc/wallarm.
- The path to the /usr/share directory → /opt/wallarm/usr/share.
  
  This introduces the new path to the sample blocking page, located at /opt/wallarm/usr/share/nginx/html/wallarm_blocked.html, and to the diagnostic script, found at /opt/wallarm/usr/share/wallarm-common/collect-info.sh.

The newly released product features are also supported by the new NGINX-based Docker image of the new format.

Optimized cloud images¶

The Amazon Machine Image (AMI) and Google Cloud Machine Image have been optimized. Key updates include:

The cloud images now use Debian 12.x (bookworm), the latest stable release, replacing the deprecated Debian 10.x (buster) for enhanced security.
Updated to the newer version of NGINX, 1.22.0, replacing the previous 1.14.x version.
Support for processors with ARM64 architecture, which is automatically identified during the installation process.
The cloud images are now built using the all-in-one installer, which changes its internal directory structure:
- Node registration script: /usr/share/wallarm-common/register-node → /opt/wallarm/usr/share/wallarm-common/cloud-init.py.
- Log file directory: /var/log/wallarm → /opt/wallarm/var/log/wallarm.
- Directory with files containing credentials for the Wallarm node to connect to the Cloud: /etc/wallarm → /opt/wallarm/etc/wallarm.
- The path to the /usr/share directory → /opt/wallarm/usr/share.
  
  This introduces the new path to the sample blocking page, located at /opt/wallarm/usr/share/nginx/html/wallarm_blocked.html, and to the diagnostic script, found at /opt/wallarm/usr/share/wallarm-common/collect-info.sh.
- The /etc/nginx/conf.d/wallarm.conf file with the global Wallarm filtering node settings has been removed.

The newly released product features are also supported by the cloud images of the new format.

Addressed vulnerabilities¶

The 4.10.1 release addresses multiple high and critical severity vulnerabilities in Wallarm deployment artifacts, enhancing the software's security posture by replacing previously vulnerable components.

Among the vulnerabilities addressed are those identified by CVE-2020-36327, CVE-2023-37920, and several others. A full list of resolved vulnerabilities, along with their corresponding CVEs specific to each node deployment artifact, can be found within the inventory of node artifact versions.

When upgrading node 3.6 and lower¶

If upgrading from the version 3.6 or lower, learn all changes from the separate list.

Which Wallarm nodes are recommended to be upgraded?¶

Client and multi-tenant Wallarm nodes of version 4.6 and 4.8 to stay up to date with Wallarm releases and prevent installed module deprecation.
Client and multi-tenant Wallarm nodes of the unsupported versions (4.4 and lower). Changes available in Wallarm node 4.10 simplify the node configuration and improve traffic filtration. Please note that some settings of node 4.10 are incompatible with the nodes of older versions.

Upgrade process¶

Review recommendations for the module upgrade.
Upgrade installed modules following the instructions for your Wallarm node deployment option:

Other updates in Wallarm products and components →