Closing the log4j attack surface beyond the WAF
The critical remote code execution vulnerability in the Java logging library log4j (CVE-2021-44228) lets an attacker execute code on a vulnerable server by injecting a crafted string into any input that gets logged. Cloudflare has already updated its Web Application Firewall (WAF) to block those malicious strings at the edge. Patching log4j deployments remains the first priority, but the attack also depends on a second condition: the compromised server must be able to make arbitrary outbound connections to the public Internet.
Once the malicious string is logged, the vulnerability tricks the server into sending a request to an attacker-controlled LDAP server at an arbitrary URL. The attacker responds with code the server executes. Early analysis shows no consistent patterns in the malicious hostnames used, unlike the SUNBURST attack, so blocking known bad domains is not sufficient on its own. Any environment that permits unrestricted outbound connectivity is exposed, not just to this flaw but to other attacks that exploit the same weakness.
Layer one: filter and log DNS queries
A simple, fast first step is to route all DNS queries from your infrastructure through Cloudflare Gateway. When a server looks up a hostname, the query hits a nearby Cloudflare data center first, where the network can:
- block resolution of queries to known malicious destinations, and
- log every query for later audit and investigation.
This adds visibility in minutes without sacrificing performance, since Cloudflare operates one of the fastest DNS resolvers. For stricter environments, Gateway supports a positive security model: you can specify the only domains your servers are allowed to resolve, and all other queries—including newly-registered attack domains—are blocked by default.
Layer two: filter outbound network traffic
DNS filtering alone does not cover every vector. Servers can be exploited through direct IP connections, and attackers may target other protocols. Traditional network firewalls require hardware procurement, capacity planning, and ongoing management, even when virtualized. Cloudflare One’s cloud-native firewall applies filtering at the network layer without any appliances. Traffic can be routed to Cloudflare via GRE or IPsec tunnels, direct interconnect, or the device client.
Once connected, outbound traffic passes through a Cloudflare data center where administrators can apply stateless or stateful policies based on IP, port, and protocol. Threat intelligence gathered from Cloudflare’s network is available as one-click managed lists to block known malicious sources.
As with DNS, you can enforce a positive security model with allow-list rules that restrict outbound connections to only the IPs and ports your services genuinely need. Logs are generated automatically and can be exported to a SIEM for retention or deeper analysis.
Layer three: inspect HTTP egress traffic
Some attacks use HTTP requests to exfiltrate data or download malware onto internal systems. The same on-ramp used for network-level filtering can be upgraded to apply Secure Web Gateway controls, which inspect and log outbound HTTP traffic, including virus scanning. For finer-grained control, the Cloudflare device client allows policies to be scoped to specific endpoints.
Here too, a default-deny model is available: servers may only connect to an approved list of destinations, and attempts to reach anything else are blocked and logged.
Patch first, then harden egress paths
Deploying layered egress filtering and logging will reduce exposure to this attack and future ones that rely on unrestricted outbound connectivity. But the immediate action for any organization running log4j is to patch those instances. Cloudflare is also updating its managed rulesets as new malicious destinations used in ongoing exploit attempts are identified, so existing WAF protections will continue to improve without manual intervention.
