Malware-Alarm: So schützt du dein Heimnetz vor infizierten npm-Paketen

Moin zusammen! Als langjähriger Linux-Admin und Home Lab-Enthusiast, der schon so manchen Sturm erlebt hat, weiß ich: Die digitale Welt ist ein Dschungel. Und ab und zu lauert da ein Raubtier, das uns überrascht. Der jüngste Vorfall rund um das beliebte npm-Paket axios ist genau so ein Fall, der uns alle aufhorchen lassen sollte – von der kleinen privaten Anwendung bis zum produktiven Server.

Die Nachricht, dass der Maintainer-Account von axios auf npm gekapert wurde, um einen Remote-Access-Trojaner (RAT) in die Version 1.6.0 einzuschleusen, hat bei mir sofort die Alarmglocken schrillen lassen. Ein RAT in einem so weit verbreiteten HTTP-Client? Das ist ein Worst-Case-Szenario, das potenziell Millionen von Systemen betreffen könnte – inklusive unserer geliebten Home Labs, Docker-Container und n8n-Instanzen.

In diesem Guide teile ich meine Erfahrungen und zeige dir Schritt für Schritt, wie du vorgehen solltest, um deine Systeme zu überprüfen, zu bereinigen und für die Zukunft besser abzusichern. Das ist kein theoretischer Kram, sondern pure Praxis, so wie ich es auch bei mir zu Hause und bei Kunden umsetzen würde.

Voraussetzungen: Was du mitbringen solltest

Bevor wir ins Detail gehen, hier ein paar Dinge, die dir das Leben leichter machen, wenn du diesen Guide durcharbeitest:

Grundlegendes Linux-Verständnis: Du solltest dich auf der Kommandozeile wohlfühlen, wissen, wie man SSH nutzt und grundlegende Befehle wie ls, cd, grep beherrscht.
Node.js- und npm-Kenntnisse: Wenn du axios nutzt, hast du wahrscheinlich auch schon mit Node.js und npm gearbeitet. Das ist essenziell, um die hier beschriebenen Schritte zu verstehen und anzuwenden.
Docker-Grundlagen: Falls du Node.js-Anwendungen in Docker-Containern betreibst (was ich wärmstens empfehlen würde!), ist es wichtig zu wissen, wie du in Container gelangst oder Images neu baust.
Zugriff auf deine Systeme: Das klingt trivial, ist aber wichtig. Du brauchst administrative Zugriffsrechte (SSH, Root/sudo) auf alle potenziell betroffenen Server, VMs oder Container.
Bereitschaft zur Fehlersuche: Nicht immer läuft alles glatt. Sei bereit, Logs zu prüfen und bei Problemen methodisch vorzugehen.

Die Bedrohung verstehen: Was ist passiert und warum ist es so ernst?

Der Heise-Artikel fasst es prägnant zusammen: Der offizielle Maintainer-Account des axios-Pakets auf npm wurde kompromittiert. Das bedeutet, ein Angreifer konnte eine manipulierte Version des Pakets veröffentlichen. Konkret wurde die Version 1.6.0 mit einem Remote-Access-Trojaner (RAT) versehen, der für Windows, macOS und Linux ausführbar ist.

Wichtig zu wissen: Ein RAT gibt dem Angreifer die Kontrolle über dein System. Das kann bedeuten:

Datenklau: Passwörter, API-Keys, persönliche Daten – alles, was auf dem System liegt oder verarbeitet wird, ist potenziell in Gefahr.
Systemkontrolle: Der Angreifer kann weitere Malware installieren, Dienste manipulieren, deine Infrastruktur für weitere Angriffe nutzen (z.B. DDoS, Krypto-Mining) oder einfach deine Daten löschen.
Persistenz: RATs sind oft darauf ausgelegt, auch nach einem Neustart aktiv zu bleiben und sich im System zu verankern.

In meiner Erfahrung sind solche Supply-Chain-Angriffe besonders tückisch, weil wir als Entwickler und Admins auf die Integrität unserer Abhängigkeiten vertrauen müssen. Wenn eine so grundlegende Bibliothek wie axios betroffen ist, die in unzähligen Projekten verwendet wird, ist das Vertrauen massiv erschüttert und erfordert sofortiges Handeln.

Schritt-für-Schritt-Anleitung: Dein Notfallplan

1. Ruhe bewahren und Informieren

Der erste Schritt bei jeder Sicherheitswarnung ist immer: Ruhe bewahren. Panik führt zu Fehlern. Informiere dich zusätzlich zu dieser Warnung bei offiziellen Quellen. Prüfe das GitHub-Repository von axios, die npm-Seite des Pakets und offizielle Sicherheits-Advisories (z.B. von Snyk, OWASP oder deinem Distribution-Vendor).

Im Fall von axios wurde die betroffene Version 1.6.0 schnell entfernt und eine saubere Version 1.6.1 veröffentlicht. Das ist ein gutes Zeichen, zeigt aber auch, wie schnell man reagieren muss.

2. Identifikation potenziell betroffener Systeme

Jetzt wird's detektivisch. Wo könntest du axios einsetzen? Denk an alles!

Deine Node.js-Projekte: Egal ob ein kleines Skript, ein Webserver oder eine API.
Home Assistant: Nutzt du Custom Components oder Add-ons, die Node.js-basiert sind und axios verwenden könnten?
n8n-Instanzen: Obwohl n8n selbst viele HTTP-Anfragen intern verarbeitet, könnten Custom Nodes oder Workflows, die über npm install zusätzliche Pakete ziehen, betroffen sein.
Docker-Container: Jedes Dockerfile, das npm install ausführt, ist ein Kandidat. Das ist in meinen Labs der häufigste Berührungspunkt.
Entwicklungsumgebungen: Deine lokalen Rechner, auf denen du entwickelst.
CI/CD-Pipelines: Build-Server, die automatisiert Dependencies installieren.

Mein Tipp: Mach dir eine Liste. Überleg, welche Server oder VMs du hast, die Node.js-Anwendungen hosten könnten. Bei Proxmox-Nutzern wie uns ist das oft eine eigene VM oder ein LXC-Container.

3. Prüfung auf die betroffene Version (1.6.0)

Das ist der Kern der Erkennung. Du musst herausfinden, ob du die infizierte Version 1.6.0 installiert hast. Das Vorgehen variiert je nach Umgebung.

Für lokale Node.js-Projekte und VMs/LXC-Container:

Wechsle in jedes Projektverzeichnis, in dem eine package.json liegt, und führe folgenden Befehl aus:

cd /pfad/zum/deinem/projekt
npm list axios

Dieser Befehl listet axios und seine Version auf, falls es direkt oder als Sub-Dependency installiert ist. Achte auf die Versionsnummer. Wenn du 1.6.0 siehst, hast du ein Problem.

Ein Beispiel für die Ausgabe, wenn du betroffen bist:

my-node-app@1.0.0 /path/to/my-node-app
└── axios@1.6.0

Wenn du viele Projekte hast, kannst du auch einen systemweiten Scan durchführen (Vorsicht bei großen Dateisystemen):

find / -name "package.json" -exec grep -l '"axios": "1.6.0"' {} \; 2>/dev/null

Dieser Befehl sucht nach package.json-Dateien, die explizit axios in Version 1.6.0 referenzieren. Allerdings findest du damit keine transitive Dependencies. Die npm list-Methode pro Projekt ist zuverlässiger.

Für Docker-Container:

Hier wird es etwas kniffliger, da die Dependencies im Image oder Container liegen. Du hast mehrere Optionen:

Im laufenden Container prüfen: Wenn der Container läuft und npm installiert hat (was bei Node.js-Containern oft der Fall ist), kannst du hineinspringen und prüfen:

docker ps # Container-ID oder Name finden
docker exec -it  bash # Oder sh
npm list axios
exit

Image inspizieren (ohne Start): Das ist etwas komplexer und erfordert, das Image zu entpacken oder mit Tools wie dive zu analysieren. Für den schnellen Check würde ich die obige Methode bevorzugen.
Dockerfile prüfen: Suche in deinen Dockerfiles nach RUN npm install und überlege, ob diese Images axios ziehen könnten.

4. Maßnahmen bei Fund der Malware

Du hast axios@1.6.0 gefunden? Dann ist jetzt schnelles und entschlossenes Handeln angesagt!

a) Isolierung

Sofortige Isolation! Trenne das betroffene System vom Netzwerk. Das kann bedeuten, die VM in Proxmox zu stoppen, den Container zu beenden oder die Netzwerkkarte zu deaktivieren. Das verhindert, dass der RAT weiter kommuniziert oder sich im Netzwerk ausbreitet.

b) Bereinigung der Dependencies

Hier ist eine bewährte Methode, um sicherzustellen, dass keine Reste der infizierten Version zurückbleiben:

cd /pfad/zum/deinem/projekt

# Node_modules und package-lock.json löschen
# Das stellt sicher, dass npm die Dependencies komplett neu herunterlädt.
rm -rf node_modules package-lock.json

# npm Cache leeren (wichtig, um keine alte, infizierte Version aus dem Cache zu ziehen)
npm cache clean --force

# package.json anpassen (optional, aber empfohlen für kritische Pakete)
# Öffne deine package.json und ändere die axios-Version.
# Wenn dort "^1.0.0" oder "~1.6.0" stand, ändere es auf eine explizit sichere Version.
# Empfohlen: "axios": "1.6.1" (wenn diese als sauber bestätigt wurde) oder "axios": "1.5.1"
# Beispiel:
# Vorher: "axios": "^1.6.0"
# Nachher: "axios": "1.6.1" oder "axios": "1.5.1"
nano package.json 

# Dependencies neu installieren
npm install

# Sicherheitsaudit durchführen
npm audit

Der npm audit-Befehl ist dein Freund. Er prüft auf bekannte Schwachstellen in deinen Dependencies. Auch wenn er die spezifische Backdoor nicht unbedingt erkennt, ist er ein guter Indikator für allgemeine Sicherheitsprobleme.

c) Für Docker-Container: Rebuild der Images

Wenn ein Docker-Container betroffen ist, reicht es nicht, nur den Container neu zu starten. Du musst das Image neu bauen! Stell sicher, dass dein Dockerfile die Schritte zur Bereinigung und Neuinstallation der Dependencies enthält oder führe sie explizit aus.

# Beispiel für ein Dockerfile, das du anpassen müsstest
# ...
# RUN rm -rf node_modules package-lock.json && npm cache clean --force
# RUN npm install
# ...

# Oder einfach neu bauen, nachdem du die package.json im Build-Kontext angepasst hast
docker build -t mein-betroffenes-image:latest .

Wichtig ist, dass du den Build-Cache von Docker nicht nutzt, der eventuell die alte, infizierte node_modules-Schicht wiederverwenden würde. Du könntest docker build --no-cache ... verwenden, aber das ist oft zu drastisch. Besser ist es, die Schritte im Dockerfile so zu gestalten, dass sie immer eine frische Installation erzwingen, z.B. durch Entfernen von node_modules vor npm install.

d) Systemweite Überprüfung und Bereinigung

Der RAT ist plattformübergreifend. Das bedeutet, er könnte sich außerhalb des Node.js-Projektverzeichnisses eingenistet haben. Das ist der heikelste Teil und erfordert tiefergehende Forensik. Ohne spezifische Informationen über die Dateinamen der Backdoor wird es schwierig. Meine Empfehlung:

Logs prüfen: Schau in System-Logs (syslog, auth.log, journalctl) nach ungewöhnlichen Prozessen, Netzwerkverbindungen oder Fehlern.
Netzwerkaktivität: Wenn das System nicht isoliert ist, nutze Tools wie netstat -tulpen oder lsof -i, um offene Ports und Verbindungen zu prüfen.
Autostart-Einträge: Überprüfe systemd-Units, Cronjobs, /etc/rc.local, oder ähnliche Mechanismen, die einen Start nach Reboot ermöglichen könnten.
Dateisystem-Scan: Suche nach kürzlich geänderten, unbekannten ausführbaren Dateien, besonders in temporären Verzeichnissen oder Benutzerverzeichnissen.

Mein persönlicher Rat: Wenn es sich um einen kritischen Server handelt und du den Verdacht hast, dass der RAT persistiert hat, ist eine komplette Neuinstallation oft der sicherste Weg. Ja, das ist aufwendig, aber die Gewissheit, ein sauberes System zu haben, ist unbezahlbar.

e) Passwörter und Tokens wechseln

Wenn ein System kompromittiert war, müssen alle darauf verwendeten Zugangsdaten als unsicher betrachtet werden. Wechsle sofort alle Passwörter, API-Keys, SSH-Schlüssel und Tokens, die auf dem betroffenen System gespeichert waren oder von dort aus verwendet wurden (z.B. npm-Tokens, GitHub-Tokens, Cloud-API-Keys, Datenbank-Passwörter).

5. Präventive Maßnahmen für die Zukunft

Aus Fehlern lernen wir. Solche Vorfälle sind eine harte, aber wichtige Lektion. Hier sind Maßnahmen, die ich in meinen Labs etabliert habe:

Regelmäßige Updates und Audits: Führe npm audit regelmäßig aus. Integriere es in deine CI/CD-Pipeline. Halte deine Pakete aktuell, aber sei vorsichtig bei Major-Version-Updates.
Dependency Pinning: Für kritische Pakete pinne die exakte Version in deiner package.json (z.B. "axios": "1.6.1" statt "^1.6.1"). Das verhindert, dass unerwartete Minor/Patch-Updates automatisch hereinfliegen.
Automatisierte Dependency-Updates (mit Bedacht): Tools wie Dependabot oder Renovate können dir helfen, Abhängigkeiten auf dem neuesten Stand zu halten und dich auf Schwachstellen aufmerksam zu machen. Aber immer mit Review!
Netzwerksegmentierung: Isoliere deine Dienste so gut es geht. Ein kompromittierter n8n-Container sollte nicht direkten Zugriff auf deine Proxmox-API oder sensible Datenbanken haben. Nutze VLANs, Firewall-Regeln und Docker-Netzwerke.
Minimalprinzip: Installiere nur, was wirklich nötig ist. Weniger Angriffsfläche bedeutet weniger Risiko.
Build-Prozesse absichern: Stelle sicher, dass deine Build-Server selbst sauber sind und keine unnötigen Rechte haben. Überwache ihre Netzwerkaktivität.
Private npm-Registry (für Profis): Für sehr kritische Umgebungen kann eine private npm-Registry wie Verdaccio sinnvoll sein. Dort kannst du Pakete cachen und bei Bedarf sogar manuell prüfen, bevor sie in deine Builds gelangen.
Intrusion Detection Systems (IDS): Tools wie Suricata oder Snort können ungewöhnliche Netzwerkaktivität erkennen, die auf einen RAT hindeuten könnte.

Häufige Fehler und Lösungen

Problem 1: `npm update` aktualisiert nicht die Major-Version oder bleibt bei der infizierten Version hängen.

Wer das zum ersten Mal einrichtet, stolpert oft über die Tücken von Semver (Semantic Versioning) und dem npm update-Befehl. Standardmäßig aktualisiert npm update nur innerhalb der im package.json definierten Major-Version (z.B. ^1.0.0 aktualisiert auf 1.x.x, aber nicht auf 2.0.0).

Lösung: Du musst die Version in deiner package.json explizit anpassen, z.B. von "^1.6.0" auf "1.6.1" oder "1.5.1". Danach ist der wichtigste Schritt, die bestehenden node_modules und die package-lock.json zu löschen und den npm-Cache zu leeren. Nur so erzwingst du, dass npm die Abhängigkeiten wirklich frisch herunterlädt und die neue Version auflöst.

# package.json bearbeiten
nano package.json 
# Sicherstellen, dass die axios-Zeile so aussieht:
# "axios": "1.6.1",

# Dann:
rm -rf node_modules package-lock.json
npm cache clean --force
npm install

Problem 2: Übersehen von Docker-Containern oder CI/CD-Pipelines.

Oft konzentriert man sich nur auf die direkt auf dem Host installierten Projekte und vergisst die isolierten Umgebungen.

Lösung: Erstelle eine vollständige Inventarliste aller Orte, an denen Node.js-Anwendungen laufen könnten. Das beinhaltet auch temporäre Build-Container. Für CI/CD-Pipelines musst du sicherstellen, dass alle Images neu gebaut und nicht aus einem älteren Cache gezogen werden. Überprüfe die Build-Logs auf die npm install-Ausgabe, um sicherzustellen, dass die korrekten Versionen installiert wurden.

# Beispiel für eine Docker Compose-Datei, die einen Node.js-Dienst nutzt
# Hier müsstest du den Build-Kontext überprüfen und ggf. neu bauen
# oder das Image von Grund auf neu erstellen, wenn es auf einem Basis-Image basiert.
version: '3.8'
services:
  my-nodejs-app:
    build: . # Hier wird das Dockerfile im aktuellen Verzeichnis gebaut
    # oder
    # image: my-registry/my-nodejs-app:latest # Hier müsstest du das Image neu pushen
    ports:
      - "3000:3000"
    volumes:
      - ./app:/app
    # ... weitere Konfigurationen

Wenn du Docker Compose verwendest, ist ein docker compose build --no-cache (oder docker-compose build --no-cache bei älteren Versionen) oft notwendig, um sicherzustellen, dass alle Schichten neu gebaut werden.

Problem 3: Nicht alle Spuren des RATs beseitigt.

Selbst nach der Bereinigung der Dependencies kann ein hartnäckiger RAT im System persistiert haben, wenn er sich bereits eingenistet hat.

Lösung: Führe eine gründliche manuelle Überprüfung durch. Schau dir die Dateisysteme auf ungewöhnliche, kürzlich geänderte Dateien an, besonders in /tmp, /var/tmp, Benutzer-Home-Verzeichnissen (z.B. ~/.config oder ~/.local/share) oder versteckten Verzeichnissen. Überprüfe systemd-Services, Cronjobs (crontab -l für Benutzer, /etc/crontab und /etc/cron.* für System) und andere Autostart-Mechanismen. Im Zweifelsfall, wie oben erwähnt, ist eine Neuinstallation des Systems die sicherste Option. Das ist hart, aber manchmal unumgänglich.

Fazit: Wachsamkeit ist der beste Schutz

Der Vorfall um axios ist ein weiteres klares Signal: Sicherheit ist ein kontinuierlicher Prozess, kein einmaliges Projekt. Besonders in unseren Home Labs, wo wir oft experimentieren und viele verschiedene Dienste laufen lassen, ist Wachsamkeit das A und O.

Ich hoffe, dieser Guide hilft dir dabei, deine Systeme sicher zu halten und aus diesem Vorfall zu lernen. Nächste Schritte könnten sein, eine feste Routine für Sicherheitsaudits zu etablieren, deine Netzwerksegmentierung zu optimieren oder dich intensiver mit Intrusion Detection Systems zu beschäftigen. Bleib dran, bleib sicher, und denk immer daran: Dein Home Lab ist ein Spiegelbild deiner Fähigkeiten – und dazu gehört auch, es zu schützen!