RE: Log4j mitigation

[Jean St-Laurent via NANOG <nanog () nanog org>]

Well if you look to the right you won't see it, but if you look to the left you will see it.

Meaning, that for a successful attack to work, the infected host needs to first download a payload from ldap.

And ldap runs on port 389/636. 

You probably can't see the log4j vulnerability in the https, but you should be able to see your servers querying weird 
stuff on internet on port 389/636. 

Just don't allow your important hosts to fetch payload on internet on port 389/636.

Et voila! Look to the left, not to the right.

Jean

-----Original Message-----
From: NANOG <nanog-bounces+jean=ddostest.me () nanog org> On Behalf Of Nick Hilliard
Sent: December 11, 2021 7:12 AM
To: Andy Ringsmuth <andy () andyring com>
Cc: nanog () nanog org
Subject: Re: Log4j mitigation

Andy Ringsmuth wrote on 11/12/2021 03:54:
> The intricacies of Java are over my head, but I’ve been reading about this Log4j issue that sounds pretty bad.
>
> What do we know about this? What, if anything, can a network operator do to help mitigate this? Or even an end user?

The payload can be contained in https, so there is no way of detecting / stopping this at the network level.  
Installations need to be upgraded / fixed.

https://logging.apache.org/log4j/2.x/security.html

1. upgrade log4j to 2.15.0 and restart all java apps 2. start java with "-D log4j2.formatMsgNoLookups=true" (v2.10+ 
only) 3. start java with "LOG4J_FORMAT_MSG_NO_LOOKUPS=true" environment variable (v2.10+ only) 4. zip -q -d 
log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class

There's a lot of scanning going on at the moment, so if you have an exposed java instance running something which 
includes log4j2, you may already be compromised.

Nick