Was können Administratoren tun?
Was können Endnutzer tun?
Wettlauf zwischen Hackern und System-Administratoren
Seit die Sicherheitslücke Log4j / Log4Shell entdeckt, beschrieben und im Internet veröffentlicht wurde, ist der Wettlauf zwischen Angreifern und Administratoren eröffnet. Wer ist schneller, Angreifer, die diese Sicherheitslücke jetzt seit Bekanntwerden ausnutzen, oder die System-Administratoren mit dem Einspielen eines geeigneten Log4j-Schutzes bzw. mit dem Einspielen von Updates aller angreifbaren Anwendungen?
Was können Administratoren tun?
Im Apache Log4j Baustein der Programmiersprache Java ist eine seit Jahren bestehende Sicherheitslücke entdeckt worden, die es Angreifern ermöglicht, manipulierte Anfragen an Server oder angreifbare Anwendungen zu schicken. Im Server wird dann die Schadsoftware ausgeführt, um den Server zu kompromittieren, zu kontrollieren oder zu kapern. Da in diesem Fall die Reaktionszeit der Systemadministratoren hoch-kritisch ist, bleibt einfach keine Zeit, auf Updates von allen angreifbaren Anwendungen zu warten, um diese dann einzuspielen. Denn erst mit dem Einspielen des letzten Updates einer angreifbaren Anwendung ist die Sicherheitslücke geschlossen.
Wann aber die Hersteller der unterschiedlichen Serverapplikationen jeweils selbst eine Korrektur der Sicherheitslücke herausbringen, ist unterschiedlich, und jede einzelne Lücke ist eine Gefahr.
Die einzige praktikable Lösung in diesem zeitkritischen Wettlauf ist ein genereller Log4j-Schutz, der für alle Server-Applikationen einsetzbar ist.
Diesen Log4j-Schutz bieten wir hier kostenfrei als Open Source an.
Laut der Stellungnahme des Apache Log4 Projects (https://logging.apache.org/log4j/2.x/security.html) zur CVE-2021-44228 (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-44228), lässt sich diese Sicherheitslücke blockieren, indem der Java Virtual Machine beim Start das System-Property log4j2.formatMsgNoLookups auf true gesetzt wird.
Das Problem dieser einfach scheinenden Lösung ist: wo tut man das? An welcher Stelle kann man unterbringen, dass diese Parameter die jeweiligen Dienste erreichen? Komplexe Skriptszenarien beim Start von Services machen es undurchsichtig, und jeder Hersteller hat dafür andere Strukturen.
Nachfolgend bieten wir eine einfache, generelle und universell auf Linux-Systemen mit systemd-Services anwendbare Lösung an. Wir stellen unsere Lösung im Sinne der CC-BY-SA Lizenz zur Verfügung. Unsere Lösung darf also frei weitergegeben, kommerziell verwendet und weiterentwickelt werden, solange unser Name - Tarja - weiterhin genannt wird.Haftung, Support usw. sind wie bei dieser Lizenz üblich ausgeschlossen.
Mit der Nutzung des folgenden Links stimmen Sie der genannten Lizenz zu.
Was können Endnutzer tun?
Es wurde eine Sicherheitslücke in einer weit verbreiteten Java-Komponente entdeckt, welche Angreifern bereits seit Jahren ermöglicht, fremde Computerserver zu infizieren bzw. zu kontrollieren. Betroffen sind tausende Anwendungen wie Amazon, Apple iCloud, Steam oder Twitter.
Endnutzer sind mit ihren Endgeräten von dieser Sicherheitslücke im Normalfall nicht betroffen.
Die Systemadministratoren müssen reagieren.
Die Auswirkungen dieser Sicherheitslücke sind weltweit gravierend. Durch die enorme Menge an gefährdeten Servern und Anwendungen müssen Systemadministratoren schneller sein als die Angreifer, die diese jetzt allen bekannte Sicherheitslücke ausnutzen.
Alle Server und alle angreifbaren Anwendungen müssen durch Einspielen von Software-Updates geschützt werden und erst mit dem Einspielen des Software-Updates der letzten angreifbaren Anwendung ist die Sicherheitslücke geschlossen. Zeit ist hier für Systemadministratoren der kritische Faktor. Das Einspielen so vieler Updates dauert einfach zu lange. Um Zeit zu gewinnen, nutzen Systemadministratoren einen anwendungsunabhängigen Schutz, um ihre Server möglichst schnell zu schützen und installieren dann nach und nach Updates von allen gefährdeten Anwendungen.