Understanding Log4j

Log4j stands as an open source Java utility designed to manage logging capabilities, originating from the collaborative endeavors of the Apache Foundation. This toolkit finds its place in a multitude of global Java applications, serving as an essential cog in the operational machinery of several Apache Frameworks, among them Apache Struts2, Apache Solr, Apache Druid, Apache Flink, and Apache Swift. Additionally, its realm extends to the likes of Netty, MyBatis, and the esteemed Spring Framework.

Delving into the Log4j Vulnerability

An exploitable chink emerges within applications when unvetted input from users trickles into the clutches of the Log4j logging utility, tainting versions that range from 2.0-beta9 to 2.14.1. In this realm of vulnerability, the Log4j breach empowers unauthorized remote code execution. The following elucidation delves into the mechanics of leveraging the Log4j vulnerability.

Key Measures for Log4j Safeguarding

Implementation of the most recent updates is paramount, specifically in instances affected by Log4j. Commence by removing any vestiges of Log4j within your organization, subsequently fortifying your security via the installation of the latest updates sourced from the official repositories.

Employ WAF policy regulations to shield your deployed applications. Integration of Web Application Firewalls within your organizational framework enhances the oversight and prevention of vulnerability exploitation. It’s essential to obstruct requests containing URL strings like “jndi:ldap”. Be mindful that deviations might circumvent existing WAF regulations or render applications utilizing the LDAP feature inoperable. Regular updates are imperative to maintain efficacy.

Consider adopting of SKUDONET as your Web Application Firewall of choice for your Log4j defense strategy.

Does the Log4j vulnerability impact SKUDONET?

SKUDONET appliances or public services remain unaffected, as Apache frameworks are not in use.

Securing your applications from the Log4j vulnerability using the SKUDONET Web Application Firewall involves the following steps:

After setting up a virtual service or farm for your application, proceed to implement the subsequent actions to craft the WAF rule:

Create a new ruleset
Create a new Action rule in the new ruleset. The rule configuration should be:

     Resolution: Deny (Cut the request and not execute rules left)
     Phase: Request headers are received

Generate a Condition in the rule with the following parameters:

     Variables: REQUEST_URI, REQUEST_HEADERS
     Transformations: lowercase, urlDecodeUni
     Operator: strContains
     Operating: jndi:ldap

Concludingly, initiate the ruleset and apply it onto the designated farms.

It’s noteworthy that this ruleset scrutinizes each HTTP request, parsing through URLs and headers to identify any vulnerable strings.