Log4j mitigation

Mon Dec 13 11:31:37 UTC 2021

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 at ytti.fi> 
Sent: December 13, 2021 6:26 AM
To: Jean St-Laurent <jean at ddostest.me>
Cc: Jörg Kost <jk at ip-clear.de>; nanog at 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 at 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 at ip-clear.de>
> Sent: December 13, 2021 6:01 AM
> To: Jean St-Laurent <jean at ddostest.me>
> Cc: Nick Hilliard <nick at foobar.org>; Andy Ringsmuth 
> <andy at andyring.com>; nanog at 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