The log4j exploit is now old news. But there are always addition mitigations that we can put in place.
This doesn't remove the need for vigilant patching and keeping platforms up to date.
Developers/Platform owners shouldn't just rely on network security to solve the difficult problems, but I know that there are plenty of platforms out there that can't or won't be patched for some reason.
As always, defense in depth is a useful approach.
Mitigation 1 - Block Outbound
Don't allow unrestricted outbound from your servers! The log4j vulnerability is exploited by tricking the server in making a JNDI connection to a malicious LDAP server.
Your servers have no business is initiating LDAP connections to untrusted servers, so stop them from doing so.
Over a year ago I wrote a blog saying outbound ANY-ANY rules are bad. My thought here have not changed. You can implement this in one of 2 ways.
1) Create block rule ahead of the allow rules, DENY all traffic to LDAP or LDAPS services.
2) Follow the best practice of only allowing your specific outbound traffic that you need.
Mitigation 2 - IPS
It is marked as critical - so if you have a generic IPS rule that is set to block high and critical level events - then you are already covered (as long as your UTM subscription is up to date)
If you are not using IPS and want to only block this today then search for 'Apache' in the application field and add the log4j signatures and set to block.
And in case if anyone wonders whether this is being actively targeted - yes, yes it is...
There are too many instances where "just get it to work and open the firewall" fundamentally defeats the purpose of having a FW in the first place. Stick to your guns IT security people. The internet is still the wild west and opening enterprises up due to increased cloud adoption requires a pragmatic approach, understanding your expected traffic flows, and balance risk versus reward. Don't just open the flood gates.