What is new in Wallarm node 4.2¶
The new minor version of the Wallarm node has been released! Wallarm node 4.2 has new features making attack mitigation even more powerful and usable including BOLA protection and dangerous JWT neutralization.
Detection of the new attack type IDOR / BOLA¶
Broken Object Level Authorization (BOLA), also known as Insecure Direct Object References (or IDOR), became one of the most common API vulnerabilities. When an application includes an IDOR / BOLA vulnerability, it has a strong probability of exposing sensitive information or data to attackers. All the attackers need to do is exchange the ID of their own resource in the API call with an ID of a resource belonging to another user. The absence of proper authorization checks enables attackers to access the specified resource. Thus, every API endpoint that receives an ID of an object and performs any type of action on the object can be an attack target.
To prevent exploitation of this vulnerability, Wallarm node 4.2 contains a new trigger which you can use to protect your endpoints from BOLA attacks. The trigger monitors the number of requests to a specified endpoint and creates a BOLA attack event when thresholds from the trigger are exceeded.
Checking JSON Web Tokens for attacks¶
JSON Web Token (JWT) is one of the most popular authentication methods. This makes it a favorite tool to perform attacks (for example SQLi or RCE) that are very difficult to find because the data in the JWT is encoded and it can be located anywhere in the request.
Wallarm node 4.2 finds the JWT anywhere in the request, decodes it and blocks (in the appropriate filtration mode) any attack attempts through this authentication method.
For example, an attacker can encode the malicious payload or+1=1--a-<script>prompt(1)</script> as a JWT payload part and send the request with this JWT in the Authorization header.
Wallarm node will decode received JWT and detect the mentioned payload pointing to the SQLi and XSS attack attempts. Attack attempts will be displayed in Wallarm Console:
Blocking requests from denylisted IPs in any filtration mode¶
Request source denylisting enables you to define distrusted IP addresses for the node to block any requests from them in any mode. Wallarm node 4.0 and lower does not meet this standard denylist behavior.
In Wallarm node 4.2, we improved the denylist logic to work as expected by default. Now, it blocks any requests originating from denylisted IPs in any filtration mode.
The new behavior has been implemented by setting wallarm_acl_access_phase on by default.
The CentOS 6.x (CloudLinux 6.x) and Debian 9.x distributions are no longer supported¶
Starting from Wallarm node 4.2, we do not publish Wallarm distributions for CentOS 6.x (CloudLinux 6.x) and Debian 9.x since these OS went EOL.
Disabling IPv6 connections for the NGINX-based Wallarm Docker container¶
The NGINX-based Wallarm Docker image 4.2 and above supports the new environment variable DISABLE_IPV6. This variable enables you to prevent NGINX from IPv6 connection processing, so that it only can process IPv4 connections.
Renamed register-node script log file¶
The /var/log/wallarm/addnode_loop.log log file in the Docker containers has been renamed to /var/log/wallarm/registernode_loop.log.
When upgrading node 3.6¶
If upgrading from the version 3.6 or lower, please also learn other changes available starting from the major Wallarm node 4.0 release.
When upgrading node 2.18¶
If upgrading Wallarm node 2.18 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.0 and 3.x to stay up to date with Wallarm releases and prevent installed module deprecation.
-
Client and multi-tenant Wallarm nodes of the unsupported versions (2.18 and lower). Changes available in Wallarm node 4.2 simplify the node configuration and improve traffic filtration. Please note that some settings of node 4.2 are incompatible with the nodes of older versions.
Upgrade process¶
-
Upgrade installed modules following the instructions for your Wallarm node deployment option: