What is new in Wallarm node 4.8¶
The new version of the Wallarm node has been released! It features logging of blocked requests from denylisted sources in the Attacks section. Learn all released changes from this document.
Collecting statistics on blocked requests from denylisted sources¶
Starting from the release 4.8, the Wallarm NGINX‑based filtering nodes now collect statistics on requests that have been blocked when their source is found in the denylist, enhancing your ability to evaluate attack strength. This includes access to the blocked request statistics and their samples, helping you minimize unnoticed activity. You can find this data in the Wallarm Console UI's Attacks section.
When using automatic IP blocking (e.g., with the brute force trigger configured), now you can analyze both the initial triggering requests and the samples of subsequent blocked requests. For requests blocked due to manual denylisting of their sources, the new functionality enhances visibility into blocked source actions.
We have introduced new search tags and filters within the Attacks section to effortlessly access the newly introduced data:
blocked_sourcesearch to identify requests that were blocked due to manual denylisting of IP addresses, subnets, countries, VPNs, and more.
multiple_payloadssearch to pinpoint requests blocked by the Number of malicious payloads trigger. This trigger is designed to denylist sources that originate malicious requests containing multiple payloads, a common characteristic of multi-attack perpetrators.
bolasearch tags now encompass requests whose sources were automatically added to the denylist by the relevant Wallarm triggers for their respective attack types.
This change introduces the new configuration parameters which by default are set to
on to enable the functionality but can be switched to
off to disable it:
controller.config.wallarm-acl-export-enablevalue for the NGINX Ingress controller chart.
Wallarm NGINX Ingress Controller for ARM64¶
We now support ARM64 processors with the Wallarm NGINX Ingress Controller. As ARM64 gains traction in server solutions, we are staying up-to-date to meet our customers' needs. This enables enhanced security for API environments, covering both x86 and ARM64 architectures, providing flexibility and protection.
In the deployment guide, we have provided the corresponding Helm chart configuration examples.
Excluding specific URLs and requests from bot checks¶
The API Abuse Prevention module is now more flexible. You can pick specific URLs and requests that should not be checked for malicious bot actions using the Set API Abuse Prevention mode rule. This is helpful for avoiding false positives and for times when you are testing your applications and need to turn off bot checks on some parts. For example, if you are using Klaviyo for marketing, you can set up the rule so it does not check the
Klaviyo/1.0 GET requests, allowing it to work smoothly without unnecessary blocks.
NGINX-based Docker image verification with official signature¶
Beginning with release 4.8, Wallarm is now signing its official NGINX‑based Docker image with its official public key.
This means you can now easily verify the authenticity of the image, enhancing security by guarding against compromised images and supply chain attacks.
Updated structure for the
wallarm_custom_ruleset_id Prometheus metric¶
The Prometheus metric
wallarm_custom_ruleset_id has been enhanced with the addition of a
format attribute. This new attribute represents the custom ruleset format. Meanwhile, the principal value continues to be the custom ruleset build version. Here is an example of the updated
API tokens support by Sidecar Controller¶
Now, during Sidecar controller deployment, you can use API tokens to create filtering nodes and connect them to the Cloud during solution deployment. With API tokens, you can control the lifetime of your tokens and enhance node organization in the UI by setting a node group name.
Node group names are set using the
config.wallarm.api.nodeGroup parameter in values.yaml, with
defaultSidecarGroup as the default name. Optionally, you can control the names of node groups based on the applications' pods using the
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.4 and 4.6 to stay up to date with Wallarm releases and prevent installed module deprecation.
Client and multi-tenant Wallarm nodes of the unsupported versions (4.2 and lower). Changes available in Wallarm node 4.8 simplify the node configuration and improve traffic filtration. Please note that some settings of node 4.8 are incompatible with the nodes of older versions.
Upgrade installed modules following the instructions for your Wallarm node deployment option:
- All-in-one installer
- Individual packages for NGINX, NGINX Plus, NGINX Distributive
- Docker container with the modules for NGINX or Envoy
- NGINX Ingress controller with integrated Wallarm modules
- Kong Ingress controller with integrated Wallarm modules
- Cloud node image
- CDN node
- Multi-tenant node