Log4Shell How to close the Log4j gap

Important note

Apache.org released an early patch to fix the Log4Shell (version Apache Log4j 2.15.0) which was proved to be incomplete and is still vulnerable under specific running configurations. If you applied the above patch your system is still exposed. You must update once more to the latest secure version. Please check this Apache.org page for more information.

Are there any other steps we could take to further secure our systems?

Yes, there are some things you could do to improve the security of your system. Here are some ideas: Here are some ideas:

1. Use iptables rules to restrict connections to known safe IPs

This is a remote code execution (RCE) exploit. It relies on the compromised system being able to fetch malicious code from a remote server, which the attacker controls. Restricting communication to a list of Trusted IPs can stop this exploit in tracks. You can do so by adding a few rules to your iptables. If your application is running on a Linux machine you could run the following commands:

Start by saving your current iptables rule set:

Debian/Ubuntu

$ iptables-save > /etc/iptables/rules.v4 (this stores your current iptables IPv4 ruleset)
$ ip6tables-save > /etc/iptables/rules.v6 (this saves your current iptables IPv6 ruleset)

CentOS/Red Hat/Fedora

$ iptables-store > /etc/sysconfig/iptables
$ ip6tables-save > /etc/sysconfig/ip6tables

Important: If you are managing this server remotely you must allow SSH connections first. Otherwise you might get blocked from the server. Assuming you are using the defualt SSH port, do;

$ iptables -A INPUT -p tcp –dport 22 -j ACCEPT

Now you can start adding rules:

$ iptables -A INPUT -i lo -j ACCEPT
$ iptables -A INPUT -m state –state RELATED,ESTABLISHED -j ACCEPT
$ iptables -A INPUT -s 10.0.0.XXX/24 -j ACCEPT (Repeat this step for all your Trusted IPs. Edit IP/Subnet)
$ iptables -A INPUT -m state –state INVALID -j DROP
$ iptables -P FORWARD DROP
$ iptables -P INPUT DROP

What you are doing here is telling your system’s built-in firewall to: accept packets from the local loop address, accept valid and relevant packets, accept packets from a specific IP, stop forwarding packets to other systems within and outside your network, and to drop everything else.

If you apply the above rules please monitor your system/application to make sure it is interacting as intended with other systems it should connect to or accept connections from. Modify the rules accordingly. If you have to restore your previous rule set do;

Debian/Ubuntu

$ iptables /sbin/iptables-restore < /etc/iptables/rules.v4
$ ip6tables-restore < /etc/iptables/rules.v6

CentOS/Red Hat/Fedora

$ iptables-restore < /etc/sysconfig/iptables
$ ip6tables-restore < /etc/sysconfig/ip6tables

Restrict access to required ports only

Again, the exploit needs to communicate over a unique open port. If you shut off all ports, except those strictly required by your server, you have a better chance to avoid being compromised. Assuming you system needs only ports 80/TCP and 443/TCP to function you can do the following:

$ -A INPUT -p tcp -m tcp –dport 80 -j ACCEPT
$ -A INPUT -p tcp -m tcp –dport 443 -j ACCEPT

3. Secure your JVM

The exploit also relies on relaxed configuration of your Java environment. You can modify the Java property responsible for log4j’s JNDI URL look ups. Setting the property to “false” is recommended here.

com.sun.jndi.ldap.object.trustURLCodebase = false

You should also set the configuration value log4j2.formatMsgNoLookups to true. This will disable the LDAP queries.

4. Use NGINX with ModSecurity WAF and LUA scripts

This is a more radical and involving solution. But security and performance gains might actually be worth it on the long run.

NGINXis a popular Open Source, fast and lightweight web server. NGINX is not vulnerable to the Log4Shell exploit because it is written fully in C language, does not use Java, or any Java‑based libraries. ModSecurity is an Open Source Web Application Firewall (WAF) module available for NGINX and other web servers. It uses a set of generic attack detectionrules called Core Rule Set (CSR) to protect web applications from a wide range of attacks, with a minimum of false alerts.

There are also some useful LUA scripts that can improve NGINX’s resistance to such attacks. LUA scripts require the NGINX module.The good guys at Infiniroot hosting have published their useful LUA scripts on this Github page accompanied by this excellent blog post.

Transition to NGINX might take you a while though because site configurations are not corss-compatible between Apache and NGINX. It might be useful to first experiment with a local lab server to make sure your site/application will run smoothly with NGINX.