Log4Shell unter Linux

Wichtiger Hinweis

Apache.org hat einen frühen Patch veröffentlicht, um die Log4Shell (Version Apache Log4j 2.15.0) zu reparieren, der sich als unvollständig erwiesen hat und unter bestimmten Betriebskonfigurationen immer noch anfällig ist. Wenn Sie den oben genannten Patch angewendet haben, ist Ihr System immer noch gefährdet. Sie müssen ein weiteres Mal auf die neueste sichere Version aktualisieren. Weitere Informationen finden Sie auf dieser Seite von Apache.org.

Gibt es weitere Maßnahmen, die wir ergreifen können, um unsere Systeme noch sicherer zu machen?

Ja, es gibt einige Dinge, die Sie tun können, um die Sicherheit Ihres Systems zu verbessern. Hier sind einige Ideen:

1. Verwenden Sie iptables-Regeln, um Verbindungen auf bekannte sichere IPs zu beschränken.

Dies ist ein RCE-Exploit (Remote Code Execution). Er beruht darauf, dass das angegriffene System in der Lage ist, bösartigen Code von einem entfernten Server abzurufen, den der Angreifer kontrolliert. Die Beschränkung der Kommunikation auf eine Liste vertrauenswürdiger IPs kann diesen Exploit aufhalten. Sie können dies tun, indem Sie ein paar Regeln zu Ihrem iptables hinzufügen. Wenn Ihre Anwendung auf einem Linux-Rechner läuft, können Sie die folgenden Befehle ausführen:

Beginnen Sie damit, Ihren aktuellen iptables-Regelsatz zu speichern:

Debian/Ubuntu

$ iptables-save > /etc/iptables/rules.v4 (dies speichert Ihren aktuellen iptables IPv4-Regelsatz)
$ ip6tables-save > /etc/iptables/rules.v6 (dies speichert Ihren aktuellen iptables IPv6-Regelsatz)

CentOS/Red Hat/Fedora

$ iptables-speichern > /etc/sysconfig/iptables
$ ip6tables-save > /etc/sysconfig/ip6tables

Wichtig: Wenn Sie diesen Server aus der Ferne verwalten, müssen Sie zunächst SSH-Verbindungen zulassen. Andernfalls werden Sie möglicherweise vom Server blockiert. Angenommen, Sie verwenden den Standard-SSH-Port, dann tun Sie das;

$ iptables -A INPUT -p tcp –dport 22 -j ACCEPT

Jetzt können Sie anfangen, Regeln hinzuzufügen:

$ iptables -A INPUT -i lo -j ACCEPT
$ iptables -A INPUT -m state –state RELATED,ESTABLISHED -j ACCEPT
$ iptables -A INPUT -s 10.0.0.XXX/24 -j ACCEPT (Wiederholen Sie diesen Schritt für alle Ihre vertrauenswürdigen IPs. Bearbeiten Sie IP/Subnetz)
$ iptables -A INPUT -m state –state INVALID -j DROP
$ iptables -P FORWARD DROP
$ iptables -P INPUT DROP

Damit weisen Sie die in Ihrem System eingebaute Firewall an: Pakete von der Local-Loop-Adresse anzunehmen, gültige und relevante Pakete zu akzeptieren, Pakete von einer bestimmten IP zu erlauben, die Weiterleitung von Paketen an andere Systeme innerhalb und außerhalb Ihres Netzwerks zu stoppen sowie alles andere zu verwerfen.

Wenn Sie die oben genannten Regeln anwenden, überwachen Sie Ihr System/Ihre Anwendung, um sicherzustellen, dass alles wie vorgesehen mit anderen Systemen interagiert, mit denen es/sie eine Verbindung herstellen oder von denen es/sie Verbindungen annehmen soll. Ändern Sie die Regeln entsprechend. Wenn Sie Ihren vorherigen Regelsatz wiederherstellen müssen, tun Sie das;

Debian/Ubuntu

$ iptables /sbin/iptables-restore < /etc/iptables/rules.v4
$ ip6tables-restore < /etc/iptables/rules.v6

CentOS/Red Hat/Fedora

$ iptables-restore < /etc/sysconfig/iptables
$ ip6tables-restore < /etc/sysconfig/ip6tables

2. Beschränken Sie den Zugriff nur auf die erforderlichen Ports

Auch hier gilt, dass der Exploit über einen einzigen offenen Port kommunizieren muss. Wenn Sie alle Ports abschalten, außer denen, die Ihr Server unbedingt benötigt, haben Sie eine bessere Chance, nicht kompromittiert zu werden. Wenn Sie davon ausgehen, dass Ihr System nur die Ports 80/TCP und 443/TCP benötigt, um zu funktionieren, können Sie wie folgt vorgehen:

$ -A INPUT -p tcp -m tcp –dport 80 -j ACCEPT
$ -A INPUT -p tcp -m tcp –dport 443 -j ACCEPT

3. Sichern Sie Ihre JVM

Der Exploit beruht auch auf einer lockeren Konfiguration Ihrer Java-Umgebung. Sie können die Java-Eigenschaft ändern, die für die JNDI-URL-Lookups von log4j verantwortlich ist. Hier wird empfohlen, die Eigenschaft auf „false“ zu setzen.

com.sun.jndi.ldap.object.trustURLCodebase = false

Sie sollten auch den Konfigurationswert log4j2.formatMsgNoLookups auf true setzen. Dadurch werden die LDAP-Abfragen deaktiviert.

4. Verwendung von NGINX mit ModSecurity WAF und LUA-Skripten

Dies ist eine radikalere und aufwändigere Lösung. Aber der Sicherheits- und Leistungsgewinn könnte sich auf lange Sicht tatsächlich lohnen.

NGINX ist ein beliebter, schneller und leichtgewichtiger Open-Source-Webserver. NGINX ist nicht anfällig für den Log4Shell-Exploit, da er vollständig in C geschrieben ist und weder Java noch Java-basierte Bibliotheken verwendet. ModSecurity ist ein Open Source Web Application Firewall (WAF) Modul, das für NGINX und andere Webserver verfügbar ist. Es verwendet eine Reihe von generischen Angriffserkennungsregeln, die Core Rule Set (CSR) genannt werden, um Webanwendungen vor einer Vielzahl von Angriffen zu schützen, mit einem Minimum an Fehlalarmen.

Es gibt auch einige nützliche LUA-Skripte, die die Widerstandsfähigkeit von NGINX gegen solche Angriffe verbessern können. LUA-Skripte erfordern das NGINX-Modul. Die Experten von Infiniroot Hosting haben ihre nützlichen LUA-Skripte auf dieser Github-Seite veröffentlicht, begleitet von diesem ausgezeichneten Blogbeitrag.

Die Umstellung auf NGINX könnte allerdings eine Weile dauern, da die Konfigurationen von Websites zwischen Apache und NGINX nicht kompatibel sind. Es könnte sinnvoll sein, zunächst mit einem lokalen Testserver zu experimentieren, um sicherzustellen, dass Ihre Website/Anwendung mit NGINX reibungslos läuft.