In these situation it's time to unite with the server admins and not let them figure out all the patching. It's possible to see it live crawling in your network. Why let something harmful continue to crawl and spread? Jean -----Original Message----- From: Saku Ytti <saku@ytti.fi> Sent: December 13, 2021 6:26 AM To: Jean St-Laurent <jean@ddostest.me> Cc: Jörg Kost <jk@ip-clear.de>; nanog@nanog.org Subject: Re: Log4j mitigation I don't think the implication made that solution space contains only Snake Oil and panic. There is also an alternative to update the log4j package, which deserves review before deciding between snake oil and panic. On Mon, 13 Dec 2021 at 13:14, Jean St-Laurent via NANOG <nanog@nanog.org> wrote:
You are right, but it's still a good place to start looking.
What do you recommend? Panic?
It won't help you.
Jean
-----Original Message----- From: Jörg Kost <jk@ip-clear.de> Sent: December 13, 2021 6:01 AM To: Jean St-Laurent <jean@ddostest.me> Cc: Nick Hilliard <nick@foobar.org>; Andy Ringsmuth <andy@andyring.com>; nanog@nanog.org Subject: Re: Log4j mitigation
It's not true. It can pull from other ports, URLs, make DNS calls, and seems to evaluate even from environment variables. It's a "virtual machine".
On 13 Dec 2021, at 11:54, Jean St-Laurent via NANOG wrote:
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
-- ++ytti