Hallo zusammen, wenn ich das richtig sehe, ist der Backup-Client auch betroffen: rpm -qlp TIVsm-BA.x86_64.rpm |grep log4j /opt/tivoli/tsm/client/ba/bin/plugins/vcloudsuite/sdk/log4j-api-2.13.3.jar /opt/tivoli/tsm/client/ba/bin/plugins/vcloudsuite/sdk/log4j-core-2.13.3.jar /opt/tivoli/tsm/client/ba/bin/plugins/vcloudsuite/sdk/log4j-jcl-2.13.3.jar /opt/tivoli/tsm/client/ba/bin/plugins/vcloudsuite/sdk/log4j-slf4j-impl-2.13.3.jar /opt/tivoli/tsm/client/ba/bin/plugins/vcloudsuite/sdk/log4j.properties Sollte ich mir deswegen Sorgen machen, oder ist das unproblematisch, weil der eh nur mit den ITC-Servern spricht? Irgendwie habe ich das Problem noch nicht mit all seinen Facetten verstanden. Generell wird als Mitigation empfohlen, die Systemeigenschaft "log4j2.formatMsgNoLookups" auf “true” zu setzen, aber wo mache ich das in dem Fall? Danke und Grüße, René [1] https://public.dhe.ibm.com/storage/tivoli-storage-management/maintenance/cli... Am 11.12.21, 00:05 schrieb "Jens Hektor" <hektor@itc.rwth-aachen.de>: Am 10.12.21 um 12:14 schrieb Jan Niehusmann: > Moin! N'abend! > Ich bin eben über folgenden Artikel gestolpert: > https://www.lunasec.io/docs/blog/log4j-zero-day/ > > TL;DR: Wenn man log4j2 benutzt, und irgendwelche Sachen loggt, die ein > potentieller Angreifer gesendet hat, dann sollte man dringend auf > Version 2.15.0 updaten oder eine der angegebenen Mitigations anwenden. > > Das könnte einen signifikanten Anteil aller in Java geschriebener > Server-Software betreffen. Nach dem, was man mittlerweile so liest, stimmt das. Und: die gaaanz Großen sind dabei, nicht nur die "Excellenz" ;-) Leider sind tatsächlich auch Systeme bei uns betroffen und ein prominentes haben wir temporär aus der Schußlinie genommen. Insgesamt ist die Bedrohungssituation aber überschaubar. Weltweit wird ca. von 150 scannenden Systemen berichtet, der hier gesehene Anteil liegt derzeit bei <50 Angreifern, dies Gesamtzahl gesehener "Events" ist auch noch <100. Dazu muß man folgendes anmerken: a) wir sehen nur HTTP, also keine Angriffe auf HTTPS, da wir derzeit nur 1 (in Worten: eins) System haben, beim dem HTTPS in der Firewall deep inspected werden kann. b) wir sehen es überhaupt, weil unser Firewallhersteler gegen 14:00 begann, entsprechende Signaturen ("Situations") bereitzustellen (es gab noch zwei Updates danach) c) neben dem oben erwähnten "prominentem" System gehen wir von einer größeren Zahl dem IT Center nur teils bekannter Systeme in der RWTH aus Es wurde folgendes umgesetzt: Systeme, die die Signaturen triggern, werden für einen Tag geblacklistet. Die bisher gesehene IP der "ldap URL", die zum Code Nachladen benutzt wird, ist für eine Woche auf der Blacklist. > Grüße, > Jan Gruß, Jens <private>wann gehen wir zwei endlich mal wieder ein Bierchen trinken?</private>