Log4j mitigation

Saku Ytti saku at ytti.fi
Mon Dec 13 11:26:11 UTC 2021


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


More information about the NANOG mailing list