Learnings of the log4j vulnerability

This is no post about how the vulnerability works and how to fix it. There is plenty of information about this available. This post is more about the learnings in the companies I and my friends work for.

Get your internal stuff behind a VPN

Do you run elasticsearch, grafana, or something similar? Great! It’s publicly available for easy access especially in the time of home office? Not so great. log4j took a lot of time of DevOps and developers checking and patching the services which need to be public (online shop i.g.) and now you also have to check if the login or search forms of your other services are also affected.

Even if you are full on Kubernetes on GCP or Azure which does not offer a VPN service (except site to site VPN) you can do this yourself with solutions like OpenVPN. In combination with cloud features like internal DNS load balancer and internal DNS zones, you can run services in kubernetes available via internal domain names which are automatically accessible to the users connected to your VPN.

Automate your build and patch processes

The 3rd party provider of a service used by your company delivered an update after a short time? Great! No Feedback from other providers or do you need to patch your own services manually? Damn! DevOps + Devs did a great job in a lot of companies building+deploying patched packages and containers but a lot of them did that on their notebook because there was no CI/CD job for that kind of job and a lot of time was lost. Don’t forget about this work. Put it in a CI/CD pipeline and you are prepared for the next time…which will be definitely come.

Keep track of software versions

“Oh version xy of software z is vulnerable! Which version are we running? Uhm…..?” One of the first things I did was creating a list of used software, version and a link to official sources like:

Of course a list you have to update manually will not be accurate after some time so get something that can do this for your software in an automated way.