Detecting and Preventing Log4j attacks with NSX Advanced Load Balancer

In my homelab I'm running a few services behind the NSX Advanced Load Balancer (Avi Vantage) and I wanted to check if Avi could detect, and hopefully stop, attempts to exploit the new Apache Log4j vulnerability.

Note that the functionality used in this blog post requires the Enterprise Edition of the NSX Advanced Load Balancer

The setup

First let's take a quick look at the setup and what I'll use to test this.

I have a Grafana instance running in the lab which we'll use and while Grafana is not impacted by the vulnerability, and by that might not be the best use case for this, the focus is how to detect the traffic and then block it.

So, my Grafana server is sitting behind a virtual service running in Avi

The virtual service is set up as a HTTPS service and we're using the default TCP and Application profiles

And to verify that things are working let's check that we can access the UI

Test JNDI lookup

Now, let's try to do a http call to the Grafana server with a JNDI lookup included. I've used an example found in this LunaSec blog post

1curl https://grafana.rhmlab.local -H 'X-Api-Version: ${jndi:ldap://127.0.0.1/a}'

So, we can see that this request got passed on to our web server. We can verify this by taking a look at the request in Avi and check out the headers

Note that Grafana is not vulnerable and will not be impacted by this.

Detect with WAF

The Avi Vantage Platform comes with a pretty awesome Web Application Firewall so now we'll use this to detect attempts to pass in a JNDI lookup.

VMware has a KB article on how to utilize the WAF which explains the steps needed to accomplish this.

In this example we'll upload a new Custom Rule Set (CRS) which is one of the recommended ways of implementing this.

Upload ruleset

Rulesets can be downloaded from the Avi Pulse customer portal. You can also find this site by following the NSX Advanced Load Balancer downloads from MyVMware

In the Avi controller UI we'll upload the downloaded CRS file and verify that we see the rule set

Create WAF Policy

Now we'll create a new WAF policy in detection mode and utilize the new CRS

We'll select the CRS-2021-4 rule set and we can also see that this has the Log4j rule added

Add WAF policy to Virtual service

With our WAF policy in place let's add this to our Virtual service

We can verify that a WAF has been added to the Virtual service when we see the little badge on the health score of the service

Test JNDI lookup

Now we'll run a JNDI lookup "attack" and see what we get in Avi

We can see that our http request got flagged by WAF, but it went through

In the WAF tab of our Virtual Service we can get more details about the match/hit

Block with WAF

Now, detecting is nice, but this is a critical vulnerability so we'll of course want to block this traffic altogether.

Create WAF enforce policy and add to service

We'll do that by using a WAF policy and the same CRS as before, but this time we'll set it to Enforce mode

Note that we could also have done a manual override of a detect mode policy on the specific rule if an enforcement of all rules is not possible/wanted

Now we'll set this policy as the WAF policy for the virtual service

Test JNDI lookup

Let's test a new http request

And we can see that this is blocked by Avi

Over in the Avi controller we can see that the request was rejected

And checking the headers for this request we can verify that nothing was sent to our Web server

Summary

This post has shown how we can detect and (optionally) block traffic by utilizing the Web Application Firewall in the NSX Advanced Load Balancer.

There's much more functionality that can be used in the WAF, but that's for a different post..

And, although we can block this traffic through the firewall this is not a reason for not patching your software!

Thanks for reading (and patch your stuff)!