Skip to content

What is New in Wallarm Node 5.x and 0.x

This document describes the changelog for the NGINX Node 5.x and Native Node 0.x major versions. If upgrading from older major node versions, you can rely on this document.

For the detailed changelog on minor versions of the Wallarm Node, refer to the NGINX Node artifact inventory or Native Node artifact inventory.

API Sessions

NGINX Node 5.1.0 and higher and Native Node 0.8.1 and higher

We introduce a unique security feature tailored for the API economy - API Sessions. This addition gives you visibility into attacks, anomalies, and user behavior across your APIs, providing transparency into how users interact with your APIs and applications.

!API Sessions section - monitored sessions

Attackers often exploit vulnerable endpoints by blending their actions with legitimate user behavior. Without the full context of how those sessions unfold, identifying patterns or threats becomes a time-consuming process involving multiple tools and systems. Organizations do not have an appropriate visibility at the API level.

With API Sessions, security teams now have the ability to see all relevant activity grouped by user session, offering unparalleled visibility into attack sequences, user anomalies, and normal behaviors. Investigations that once took hours or days can now be conducted directly from the Wallarm Console in just minutes.

Key features:

  • Visibility into attacks, anomalies, and user behavior: View and analyze every request made in a session to track attack vectors and suspicious patterns.

  • Support for both legacy and modern sessions: Whether your applications rely on cookie-based sessions or JWT/OAuth, Wallarm API Sessions ensures full compatibility and visibility.

  • Seamlessly navigate between individual attacks and their sessions.

With API Sessions, security teams can now easily:

  • Investigate the full activity of threat actors to understand potential attack paths and compromised resources.

  • Identify how shadow or zombie APIs are being accessed, mitigating risks from undocumented or outdated APIs.

  • Share key insights with colleagues to foster collaboration during security investigations.

Read more

New in limiting request processing time

NGINX Node 5.1.0 and higher and Native Node 0.8.1 and higher

Wallarm limits the request processing time to avoid running out of system memory which can lead to the node being down to leave your applications unprotected. Now the transparency of this mechanism is increased:

  • All the cases of exceeding the limit are registered and immediately displayed in Attacks as overlimit_res events - you can easily locate and analyze them.

  • In all the cases of exceeding the limit, the processing of requests stops.

  • Configuring of system behavior is easier now - general configuration is displayed in Settings → General and can be modified there.

  • The Limit request processing time (former Fine-tune the overlimit_res attack detection) rule is simplified to set different configurations for specific endpoints.

Customizing sensitive data detection in API Discovery

NGINX Node 5.0.3 and higher and Native Node 0.7.0 and higher

API Discovery detects and highlights sensitive data consumed and carried by your APIs. Now you can fine-tune the existing detection process and add your own sensitive data patterns.

Patterns are used to define which sensitive data is detected and how. To modify default patterns and add your own, in Wallarm Console go to API Discovery → Configure API Discovery → Sensitive data.

Native Node for connectors and TCP traffic mirror

We are excited to introduce the Native Node, a new deployment option for the Wallarm Node that operates independently of NGINX. This solution was developed for environments where NGINX is not required or where a platform-agnostic approach is preferred.

Currently, it is tailored for the following deployments:

  • MuleSoft, Cloudflare, CloudFront, Broadcom Layer7 API Gateway, Fastly connectors with both request and response analysis

  • Kong API Gateway and Istio Ingress connectors

  • TCP traffic mirror analysis

Read more

NGINX Node technology stack changes

The Wallarm NGINX Node 5.x has been re-engineered, transitioning from a Ruby-based implementation to one based on the Go language. With this release, we focus on making the solution faster, more scalable, and more resource-efficient, both now and for the future development.

Metrics

Regarding the exact metrics, the following performance improvements have been made in the Wallarm postanalytics module:

  • CPU consumption has been decreased from 0.5 CPU cores to 0.1 CPU cores.

  • Memory consumption has been reduced by 400 MB at a traffic rate of 500 requests per second.

File system changes

With the technology stack changes, the file system of the NGINX Node artifacts has changed as follows:

  • Log file system: Previously, logs were recorded in multiple files, each for a dedicated script. Now, logs from almost all services are recorded into a single dedicated file, wcli-out.log. You can review the list of previous log files and the current one.

  • The diagnostic script path change: The /opt/wallarm/usr/share/wallarm-common/collect-info.sh file has been moved to /opt/wallarm/collect-info.sh.

Further feature introduction

Starting with NGINX Node release 5.2, new features will be introduced exclusively in the node with the new Go-based implementation. These new features will not be backported to the previous version (4.10).

Changes to versioning policy

With updates to the NGINX Node technology stack and the introduction of the Native Node, the Wallarm Node versioning policy has been updated:

  • Wallarm now supports the 2 most recent major versions, limited to their latest minor versions.

  • Support for versions two releases behind (e.g., 6.x → 4.x) ends 3 months after a new major version is released.

  • Major versions are released every 6 months or for significant new features and breaking changes.

  • Minor versions are released monthly, focusing on enhancements within existing functionality (+1 increment).

  • The Native Node now follows the same versioning pattern as the NGINX Node, with simultaneous releases and feature parity. However, the Native Node major version numbering starts from 0.

  • Client and multi-tenant Wallarm NGINX Nodes of version 4.8 and 4.10 to stay up to date with Wallarm releases and prevent installed module deprecation.

  • Client and multi-tenant Wallarm nodes of the unsupported versions (4.6 and lower).

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

Upgrade process

  1. Review recommendations for the module upgrade.

  2. Upgrade installed modules following the instructions for your Wallarm node deployment option:

Other updates in Wallarm products and components →