Re: Log4j mitigation

[Saku Ytti <saku () ytti fi>]

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