VPS gehackt: Was Sie jetzt tun sollten

Keinen gehackten VPS bereinigen

Wenn Ihr VPS gehackt wurde, muss die wichtigste Entscheidung fallen, bevor Sie einen Befehl ausführen. Versuchen Sie nicht, den Server zu bereinigen. Isolieren Sie ihn beim Provider, erstellen Sie einen Snapshot des Datenträgers als Beweismittel, tauschen Sie alle dort verwendeten Zugangsdaten aus und erstellen Sie anschließend auf einem frischen Server aus vertrauenswürdigen Quellen ein neues System.

Sie können nicht beweisen, dass ein Rootkit entfernt wurde, weil die Werkzeuge, mit denen Sie das beweisen könnten, vom Angreifer kontrolliert werden.

Das ist das gesamte Argument. Der Mechanismus dahinter ist folgender: Ein Angreifer mit root-Zugriff kann ps so ersetzen, dass eine Prozess-ID in der Ausgabe nie erscheint. Eine Zeile in /etc/ld.so.preload lädt Angreifercode in jedes dynamisch gelinkte Programm auf dem Server. Dadurch liefern ls, ss und find auf konsistente Weise falsche Ergebnisse. Ein ladbares Kernelmodul kann Dateien unterhalb der Systemaufrufebene verbergen. Dadurch sieht selbst eine frisch heruntergeladene Binärdatei einen sauberen Datenträger. Sie löschen den Miner, die CPU-Auslastung sinkt und der Server wird still. Ein stiller Server kann jedoch auch auf eine funktionierende Backdoor hindeuten.

Ein Neuaufbau kostet weniger, als es zunächst wirkt. Ein typischer VPS besteht aus einer überschaubaren Anzahl von Paketen, einem Konfigurationsverzeichnis und einem Datensatz. Der Neuaufbau ist daher eine begrenzte Aufgabe mit einem klaren Ende. Die Suche nach jeder Änderung, die ein Angreifer vorgenommen hat, ist dagegen nicht abgeschlossen. Einen Beweis liefert sie nie.

Bestätigen, dass tatsächlich ein Sicherheitsvorfall vorliegt

Viele Server, die als gehackt gemeldet werden, sind es nicht. Tausende fehlgeschlagene SSH-Anmeldeversuche pro Tag sind Hintergrundrauschen des Internets, weil jede öffentliche IPv4-Adresse kontinuierlich gescannt wird. Eine lastb-Ausgabe mit zahlreichen root- und admin-Versuchen bedeutet, dass die Scanner Ihren Port gefunden haben. Das bedeutet nicht, dass jemand Zugriff erhalten hat.

Diese Signale haben dagegen eine konkrete Bedeutung:

• Eine erfolgreiche Anmeldung, die Sie nicht erklären können, etwa Accepted password for root from 203.0.113.7.
• Ein Schlüssel in authorized_keys, den Sie nicht hinzugefügt haben.
• Eine Missbrauchsmeldung Ihres Hosters über Netzwerkverkehr, der Ihren Server verlässt.
• Ein Prozess mit 100% CPU-Auslastung, der den Namen eines Kernel-Threads trägt. Miner, die über offene Redis- und Docker-Sockets eingeschleust wurden, werden häufig unter Namen wie kdevtmpfsi und kinsing gemeldet.
• Ausgehende Verbindungen zu Adressen, die von keinem Ihrer Dienste verwendet werden.

Die Täuschung durch einen Kernel-Thread-Namen lässt sich schnell prüfen. Echte Kernel-Threads werden in eckigen Klammern angezeigt und haben keine ausführbare Datei. Daher schlägt sudo ls -l /proc/<pid>/exe bei ihnen mit No such file or directory fehl. Wenn ein als [kworker/0:2] angezeigter Prozess über einen exe-Link verfügt, der auf etwas unter /tmp verweist, handelt es sich um ein normales Benutzerprogramm, das den Namen eines Kernels trägt.

Führen Sie diese Prüfungen mit dem Wissen durch, dass der Server Sie möglicherweise täuscht. Sie reichen aus, um festzustellen, dass etwas nicht stimmt. Sie reichen nicht aus, um festzustellen, dass alles in Ordnung ist.

Netzwerk beim Provider trennen, nicht im Server

Die Isolation hat Vorrang, weil jeder weitere Schritt vergeblich ist, solange ein anderer noch eine Shell besitzt. Logs zu lesen, Schlüssel zu rotieren und Daten wiederherzustellen ist sinnlos, solange ein aktiver Angreifer zusieht.

Führen Sie die Trennung im Control Panel Ihres Providers durch, in der Netzwerk-Firewall außerhalb Ihres Betriebssystems. Sperren Sie eingehenden und ausgehenden Netzwerkverkehr, und behalten Sie die Webkonsole als Zugang. Die dort durchgesetzten Regeln bleiben unabhängig von allen Vorgängen auf der Festplatte wirksam.

Es gibt zwei Gründe, dies nicht innerhalb des Servers zu tun. Eine Firewall, die Sie innerhalb eines kompromittierten Kernels konfigurieren, wird von diesem Kernel durchgesetzt. Außerdem kann root nftables genauso einfach leeren, wie Sie die Regeln schreiben können. Und sudo ip link set enp1s0 down über SSH beendet zuerst Ihre eigene Sitzung. Dadurch verlieren Sie den Zugriff auf einen Rechner, den Sie gerade untersuchen.

Sperren Sie ausgehenden ebenso wie eingehenden Netzwerkverkehr. Eine Reverse Shell baut von Ihrem Server aus eine Verbindung zum Angreifer auf. Eine Sperre nur für eingehenden Verkehr lässt eine bereits bestehende Verbindung daher weiterhin uneingeschränkt funktionieren. Wenn Ihr Provider nur Regeln für eingehenden Verkehr anbietet, bleiben das Trennen der Netzwerkschnittstelle oder das Ausschalten der Instanz als Optionen.

Starten Sie den Server noch nicht neu. Prüfen Sie zuerst, ob /var/log/journal vorhanden ist. Fehlt dieses Verzeichnis, schreibt journald nach /run/log/journal. Dieses Verzeichnis liegt im Arbeitsspeicher. Ein Neustart löscht daher den Datensatz des Eindringens. Auch laufende Prozesse verschwinden beim Neustart. Ihre Kommandozeilen sind häufig die aussagekräftigsten Beweise, die Sie erhalten werden.

Erstellen Sie einen Snapshot der Festplatte, bevor Sie Änderungen vornehmen

Ein Snapshot und ein Backup erfüllen hier unterschiedliche Aufgaben. Der Snapshot, den Sie jetzt erstellen, ist eine Kopie einer kompromittierten Festplatte. Er dient als Beweismittel und ist die einzige Möglichkeit, zu einem späteren Zeitpunkt zurückzukehren, falls Sie versehentlich etwas überschreiben. Ihre älteren Backups dienen der Wiederherstellung. Wenn das Panel Ihres Providers die beiden Begriffe nicht eindeutig verwendet, lesen Sie zuerst wie sich VPS-Snapshots von echten Backups unterscheiden. Die Aufbewahrungsregeln und das Wiederherstellungsverhalten sind nicht identisch.

Erstellen Sie den Snapshot im Panel des Providers, bevor Sie sich erneut anmelden. Ein Live-Snapshot ist crash-konsistent. Er erfasst die Festplatte in dem Zustand, den sie in diesem Moment hatte, ähnlich wie beim Trennen der Stromversorgung. Für Beweissicherungszwecke ist das ausreichend. Benennen Sie den Snapshot so, dass ihn niemand versehentlich wiederherstellt. Eine unmissverständliche Bezeichnung wie COMPROMISED-do-not-restore-2026-08-12 ist angemessen. Bewahren Sie ihn auf, bis Ihre Untersuchung abgeschlossen und jedes Abuse-Ticket bei Ihrem Hoster geschlossen ist.

So greifen Sie zu, wenn SSH nicht mehr verfügbar ist

Dafür gibt es zwei Möglichkeiten, beide im Provider-Panel. Die Webkonsole (VNC oder seriell) verbindet sich mit der Maschine, als hätten Sie eine Tastatur angeschlossen. Sie funktioniert, wenn sshd nicht läuft, die Firewall falsch konfiguriert ist oder der Angreifer den SSH-Port geändert hat. Die Authentifizierung erfolgt mit einem lokalen Passwort. Bei einem Server, der ausschließlich Schlüssel verwendet, müssen Sie daher möglicherweise zuerst das Root-Passwort zurücksetzen, bevor die Konsole nutzbar ist.

Der Rescue-Modus ist die bessere Option. Er startet ein kleines Live-System und bindet Ihre Festplatte ein, ohne das installierte System zu starten. Dadurch sind Ihre Befehle vertrauenswürdig: Der kompromittierte Kernel und die kompromittierten Binärdateien werden nicht ausgeführt. Binden Sie die Festplatte schreibgeschützt ein.

lsblk -f
sudo mkdir -p /mnt/victim
sudo mount -o ro /dev/vda1 /mnt/victim

Wenn lsblk LVM-Volumes (Logical Volume Manager) statt einer normalen Partition anzeigt, aktivieren Sie sie zuerst mit sudo vgchange -ay. Mounten Sie anschließend das Gerät, das unter /dev/mapper/ angezeigt wird.

Führen Sie keinen chroot auf der eingebundenen Festplatte aus, um sich dort umzusehen. Ein chroot führt die Binärdateien des Angreifers mit Ihren Berechtigungen aus. Damit verlieren Sie den gesamten Grund, aus dem Sie den Rescue-Modus gestartet haben.

Noch vertrauenswürdige Belege sichern

Führen Sie diese Befehle im Rescue-Modus aus, während das Laufwerk unter /mnt/victim schreibgeschützt eingebunden ist. Beginnen Sie mit den Anmeldungen, weil sie den Zeitpunkt des Eindringens eingrenzen. Danach lassen sich alle weiteren Befunde leichter in ein Zeitfenster einordnen.

sudo grep -aE 'Accepted (password|publickey)' /mnt/victim/var/log/auth.log
sudo last -f /mnt/victim/var/log/wtmp
sudo lastb -f /mnt/victim/var/log/btmp
sudo journalctl -D /mnt/victim/var/log/journal -u ssh --since "2026-07-01"

Ein fehlendes /var/log/auth.log ist allein kein verdächtiger Befund. Einige aktuelle Ubuntu-Images werden ohne rsyslog ausgeliefert. Daher schreibt sshd nur in das Journal. Genau das zeigt die Zeile journalctl -D. Achten Sie auf eine Lücke in ansonsten durchgängigen Logs oder auf eine Logdatei mit einer Größe von 0 Bytes. Das Löschen von Logs kommt häufig vor und wird meist unsauber durchgeführt.

Prüfen Sie als Nächstes die Konten und Schlüssel.

sudo find /mnt/victim/root /mnt/victim/home -name 'authorized_keys*' -exec ls -l {} +
sudo awk -F: '$3 == 0 {print $1}' /mnt/victim/etc/passwd
sudo lsattr /mnt/victim/root/.ssh/authorized_keys

Die Zeile awk gibt jedes Konto mit der Benutzer-ID 0 aus. Jeder Eintrag außer root in dieser Ausgabe ist ein weiteres root-Konto. Das Muster find berücksichtigt absichtlich auch authorized_keys2. OpenSSH liest standardmäßig beide Dateinamen, und die zweite Datei wird leicht übersehen. Wenn lsattr in der Attributliste ein i ausgibt, ist die Datei unveränderlich. Ein Angreifer setzt dieses Attribut, damit Ihr Löschversuch mit Operation not permitted fehlschlägt und Sie als überlasteter Administrator annehmen, die Änderung sei erfolgreich gewesen.

Persistenzmechanismen befinden sich an wenigen Stellen. Prüfen Sie daher alle diese Stellen.

sudo ls -lt /mnt/victim/etc/systemd/system
sudo ls -l /mnt/victim/etc/cron.d /mnt/victim/var/spool/cron/crontabs
sudo cat /mnt/victim/etc/ld.so.preload
sudo grep -rnE 'curl|wget|base64|/dev/tcp' /mnt/victim/etc/update-motd.d /mnt/victim/etc/rc.local /mnt/victim/root/.bashrc /mnt/victim/root/.profile

/etc/ld.so.preload existiert auf einem normalen Ubuntu- oder Debian-System nicht. Daher ist No such file or directory das erwartete Ergebnis. Jeder Inhalt verdient Ihre Aufmerksamkeit. Eine Login-Datei, die die Ausgabe von base64 -d an eine Shell weiterleitet, ist ebenfalls verdächtig. Eine legitime Konfiguration muss ihren eigenen Text nicht verbergen.

Erstellen Sie die Zeitleiste anhand der Änderungszeit und nicht anhand der Modifikationszeit.

sudo find /mnt/victim -xdev -newerct '2026-08-01' -type f -printf '%TF %TT %p\n' | sort

touch setzt die Modifikationszeit auf einen beliebigen Wert. Ein Angreifer kann die mtime daher einfach fälschen. Die Änderungszeit (ctime) wird bei jeder Änderung am Inode aktualisiert. touch kann sie nicht rückwärts verschieben. Daher liefert -newerct eine zuverlässigere Liste der Dateien, in die kürzlich geschrieben wurde. Das ist trotzdem kein Beweis. root kann die Systemzeit ändern oder direkt auf das Blockgerät schreiben.

Die Integrität der Pakete lässt sich mit einem Befehl prüfen, allerdings mit einer wichtigen Einschränkung. Auf einem laufenden System gibt sudo dpkg --verify für jede paketierte Datei eine Zeile aus, deren Prüfsumme nicht mehr übereinstimmt. In der Prüfsummenspalte steht dann ein 5. sudo debsums -ac erledigt dieselbe Aufgabe und berücksichtigt zusätzlich Konfigurationsdateien, wenn das Paket debsums installiert ist. Werten Sie das Ergebnis nur in eine Richtung aus. Eine geänderte /usr/sbin/sshd ist ein echter Beleg. Ein sauberer Bericht beweist nichts, weil dasselbe root-Konto, das die Binärdatei ersetzt hat, auch die Prüfsummenlisten unter /var/lib/dpkg/info/ ändern kann. Rootkit-Scanner wie rkhunter und chkrootkit folgen derselben Regel: Ein Treffer liefert Informationen, ein sauberer Lauf ist keine Entlastung.

Kopieren Sie die gesammelten Daten vom System, bevor Sie destruktive Maßnahmen durchführen.

sudo tar --ignore-failed-read -C /mnt/victim -czf /root/evidence-2026-08-12.tgz \
  var/log etc root/.ssh root/.bash_history home
sha256sum /root/evidence-2026-08-12.tgz

Notieren Sie diesen Hash außerhalb des Servers. Falls daraus ein Versicherungsfall oder eine Strafanzeige wird, können Sie damit nachweisen, dass sich das Archiv seit der Erfassung nicht verändert hat. Das ist der Unterschied zwischen Beweismaterial und einem Ordner voller Dateien. Versehentliches Löschen während einer Untersuchung kommt häufig vor. Der Snapshot zusammen mit diesem Archiv macht den Vorgang beherrschbar. Das Rückgängigmachen eines fehlerhaften rm ist danach deutlich schwieriger als erwartet, wie Dateien wiederherstellen, die mit rm -rf gelöscht wurden erklärt.

Den Zugangsweg ermitteln

Ein Neuaufbau, der den ursprünglichen Zugangsweg nicht schließt, führt häufig innerhalb weniger Tage zu einer erneuten Kompromittierung. Der Scan, durch den der Server erstmals entdeckt wurde, läuft weiterhin. Bei Kompromittierungen einzelner Server sind meist vier Zugangswege relevant.

SSH-Anmeldung mit Passwort. Eine Accepted password for root-Zeile von einer Ihnen unbekannten Adresse ist bereits ein ausreichender Hinweis. Prüfen Sie PasswordAuthentication in /etc/ssh/sshd_config und in jeder Datei unter /etc/ssh/sshd_config.d/. sshd verwendet für ein Schlüsselwort den ersten gefundenen Wert. Unter Ubuntu steht die Include-Zeile am Anfang der Hauptdatei. Daher kann eine zusätzlich eingebundene Konfigurationsdatei die weiter unten geänderte Einstellung unbemerkt außer Kraft setzen.

Ein Dienst ohne Authentifizierung im Internet veröffentlicht. Beispiele sind Redis auf 6379, die Docker-API auf 2375 oder eine Datenbank, die an 0.0.0.0 statt an 127.0.0.1 gebunden ist. Docker sorgt dabei häufig für Überraschungen. Durch die Veröffentlichung eines Container-Ports werden DNAT-Regeln (Destination Network Address Translation) eingefügt. Diese werden vor den ufw-Ketten ausgewertet. Daher kann ufw status einen Port als blockiert melden, während der dahinterliegende Container aus dem gesamten Internet antwortet. Klären Sie diesen Punkt vor dem Neuaufbau: warum veröffentlichte Docker-Ports ufw umgehen beschreibt die Reihenfolge der Regeln und die Lösung.

Eine nicht aktualisierte Webanwendung. Durchsuchen Sie das Access-Log des Webservers rund um den frühesten verdächtigen Zeitstempel nach einem POST an einen Upload- oder Administrationspfad. Suchen Sie anschließend im Webroot nach Dateien mit einer passenden Änderungszeit. Eine PHP-Datei in einem Upload-Verzeichnis ist das typische Ergebnis.

Ein offengelegtes Zugangsmittel. Beispiele sind ein in ein Repository eingecheckter Schlüssel, ein in einen Chat eingefügtes Token oder eine .env-Datei, die ein falsch konfigurierter Webserver als statische Datei ausliefert. Durch Automatisierung kann dies leicht versehentlich geschehen. Deshalb sollten Sie Secrets von AI-Agenten und ihren Konfigurationsdateien fernhalten.

Wenn Sie den Zugangsweg danach nicht benennen können, gehen Sie von einem offengelegten Zugangsmittel aus. Behandeln Sie jedes Secret, das auf dem System gespeichert war, als öffentlich.

Jede Anmeldedaten rotieren, auf die der Rechner zugreifen konnte

Rotieren Sie die Anmeldedaten erst, nachdem das Netzwerk getrennt wurde, niemals vorher. Wenn Sie sie ändern, während der Angreifer noch verbunden ist, geben Sie ihm einfach die neuen Geheimnisse.

• Alle auf dem Server gespeicherten privaten SSH-Schlüssel sowie jedes Konto auf anderen Systemen, das dem zugehörigen öffentlichen Schlüssel vertraut hat.
• Jeden Schlüssel, den Sie mit ssh -A an den Rechner weitergeleitet haben. Agent Forwarding hinterlässt einen Socket unter /tmp. root auf diesem Rechner kann ihn verwenden, um sich überall dort als Sie zu authentifizieren, wo Ihr Schlüssel akzeptiert wird, solange Ihre Sitzung geöffnet bleibt.
• API-Tokens in .env-Dateien, in systemd-Environment=-Zeilen, in der CI-Konfiguration und in Provider-Anmeldedaten.
• Datenbankpasswörter und die Anwendungskonten, die sie verwenden.
• Private TLS-Schlüssel (Transport Layer Security), die auf dem Server gespeichert waren. Stellen Sie das Zertifikat neu aus und widerrufen Sie das alte.
• Das Passwort Ihres Hosting-Kontos, und aktivieren Sie die Zwei-Faktor-Authentifizierung. Über dieses Panel können Sie jeden Server, den Sie besitzen, neu erstellen, als Snapshot sichern und über die Konsole darauf zugreifen. Es bildet daher die eigentliche Perimeter-Grenze.
• Jedes Passwort, das auf diesem Host während der Kompromittierung in einer Shell-Sitzung eingegeben wurde, weil root eine Terminalsitzung während ihrer Ausführung aufzeichnen kann.

Wenn ein Passwort auf diesem Rechner auch an anderer Stelle verwendet wird, ändern Sie es auch dort. Wiederverwendung ist der Grund, warum aus einem kompromittierten VPS ein kompromittiertes E-Mail-Konto wird.

Die Checkliste für den Neuaufbau

1. Erstellen Sie einen neuen Server aus einem frischen Distributions-Image. Verwenden Sie weder den Snapshot des kompromittierten Systems noch eine Wiederherstellung des gesamten Root-Dateisystems.
2. Installieren Sie Pakete aus den Distributions-Repositories. Kopieren Sie niemals eine Binärdatei von der alten Festplatte.
3. Stellen Sie ausschließlich Daten aus einer Sicherung wieder her, die vor dem frühesten Beleg in Ihrer Zeitleiste erstellt wurde. Dazu gehören Datenbank-Dumps, Uploads und der Anwendungsstatus. Lassen Sie /etc, /usr und die alten Unit-Dateien zurück.
4. Tragen Sie die neu erzeugten Secrets manuell ein. Kopieren Sie das alte .env nicht.
5. Prüfen Sie wiederhergestellte Webinhalte auf Dateien, die während des Einbruchszeitraums hinzugefügt wurden, bevor Sie diese erneut bereitstellen.
6. Sichern Sie das System ab, bevor Sie es erreichbar machen: SSH nur mit kryptografischen Schlüsseln, ein Arbeitskonto ohne root-Rechte, eine eingehende Firewall mit standardmäßigem Verweigern und keine Veröffentlichung eines Dienstes über den tatsächlich erforderlichen Umfang hinaus. Arbeiten Sie zunächst die ersten zehn Minuten auf einem neuen VPS durch, sichern Sie danach SSH ordnungsgemäß ab und richten Sie anschließend fail2ban unter Ubuntu 24.04 ein, um die Anmeldeversuche zu reduzieren. Geben Sie jedem Dienst ein eigenes Konto mit den geringstmöglichen Rechten, damit ein zukünftiger Zugriff nicht als root erfolgt.
7. Schalten Sie den alten Server aus und bewahren Sie seinen Snapshot auf, bis die Untersuchung und alle Abuse-Tickets abgeschlossen sind.
8. Überarbeiten Sie die Backups. Wenn Schritt 3 auf Vermutungen beruhte, besteht die eigentliche Erkenntnis darin, dass Ihre Backup-Historie nicht weit genug zurückreichte, um einen Stand vor dem Einbruch zu erreichen. Versionierte Backups außerhalb des Servers mit langer Aufbewahrung liefern beim nächsten Mal einen sauberen Wiederherstellungspunkt: restic-Backups auf einem VPS bietet beides.

Wenn Sie den Zeitpunkt des Einbruchs nicht bestimmen können, können Sie keine sichere Sicherung auswählen. Stellen Sie in diesem Fall nur Daten wieder her, die Sie manuell prüfen können: einen lesbaren SQL-Dump oder ein auflistbares Bildverzeichnis. Behandeln Sie alles Ausführbare als verdächtig und installieren Sie es erneut aus den Repositories.

Was die Missbrauchsmeldung Ihres Hosters bedeutet

Die meisten Menschen erfahren von ihrem Provider, dass ihr Server kompromittiert wurde, und nicht durch ihre eigene Überwachung. Hoster sehen den ausgehenden Netzwerkverkehr: SSH-Brute-Force-Angriffe gegen andere Netzwerke, Spam über Port 25 oder einen Anteil an einem Reflection-Angriff. Das Ticket enthält normalerweise Zeitstempel, Ports und ein Beispiel der Datenströme sowie eine Frist in Stunden.

Antworten Sie darauf, selbst wenn Sie nur mitteilen können, dass der Server isoliert wurde und neu aufgebaut wird. Provider leiten den Datenverkehr eines Servers in eine Nullroute um oder sperren ihn, wenn auf ein Ticket keine Antwort erfolgt. Dadurch wird aus Ihrem Sicherheitsvorfall ein Ausfall. Bitten Sie anschließend um die ursprünglichen Logzeilen, auf denen der Bericht basiert. Diese Zeitstempel wurden außerhalb Ihres Systems erfasst. Sie sind daher der Teil der Zeitleiste, den der Angreifer nicht bearbeiten konnte. Außerdem datieren sie den Einbruch oft genauer als alle Informationen auf dem Datenträger.

Ein kompromittierter Kundenserver gehört für einen Hoster zum normalen Arbeitsaufwand. Eine sorgfältige Bearbeitung wird Ihnen nicht negativ angerechnet. Die übergeordnete Frage, ob VPS-Hosting sicher ist, hängt vor allem davon ab, was der Kunde konfiguriert. Genau diesen Teil können Sie nun von Grund auf neu einrichten.

Wann Sie einen professionellen Dienstleister hinzuziehen sollten

• Auf dem Server wurden personenbezogene Daten anderer Personen verarbeitet. Nach der DSGVO (Datenschutz-Grundverordnung) muss eine Verletzung des Schutzes personenbezogener Daten unverzüglich und, sofern dies möglich ist, innerhalb von 72 Stunden nach Bekanntwerden der zuständigen Aufsichtsbehörde gemeldet werden. Zu beurteilen, ob diese Frist begonnen hat, ist eine rechtliche Aufgabe und keine Aufgabe der Systemadministration.
• Zahlungskartendaten waren betroffen. Die Kartenorganisationen verlangen einen zugelassenen forensischen Ermittler. Eigene Untersuchungen können den Fall beeinträchtigen.
• Es liegt eine Erpressungsforderung vor oder Ihre Daten wurden verschlüsselt.
• Das System konnte andere Systeme erreichen: ein internes Netzwerk, einen Hypervisor oder einen CI-Runner mit Zugangsdaten für Produktionssysteme. Ein kompromittierter Host in einer Gruppe gilt als gruppenweiter Sicherheitsvorfall, bis das Gegenteil bewiesen ist.
• Die Beweise müssen für eine Versicherung oder Strafverfolgungsbehörden belastbar sein. Halten Sie beim Snapshot an, erstellen Sie ein vollständiges Festplattenabbild und dokumentieren Sie, wer es wann bearbeitet hat.

Für einen einzelnen VPS, auf dem nur Ihre eigenen Dienste laufen und keine Daten anderer Personen gespeichert sind, ist das oben beschriebene Vorgehen die vollständige Aufgabe. Isolieren Sie das System beim Provider. Erstellen Sie zur Beweissicherung einen Snapshot. Sammeln Sie die noch vertrauenswürdigen Daten. Ersetzen Sie alle Zugangsdaten und Schlüssel. Bauen Sie das System sauber neu auf.

FAQ

Kann ich einen gehackten VPS bereinigen, statt ihn neu aufzusetzen?

Nicht mit ausreichender Sicherheit, weil Sie das kompromittierte System auffordern würden, sich selbst zu überprüfen. Ein ersetztes ps verbirgt einen Prozess, eine Zeile in /etc/ld.so.preload schleust Code in jedes von Ihnen ausgeführte dynamisch gelinkte Tool ein, und ein Kernelmodul kann Dateien vor allen Programmen gleichzeitig verbergen. Sie können Funde machen, und ein Treffer ist aussagekräftig. Das Nichtvorhandensein von Schadsoftware können Sie jedoch nicht nachweisen. Ein unauffälliges Ergebnis ist daher kein Beleg für ein sauberes System. Eine Bereinigung ist nur vertretbar, wenn auf dem Server nichts liegt, was Ihnen wichtig ist, und Sie akzeptieren, dass er erneut kompromittiert werden kann.

Sollte ich einen kompromittierten Server ausschalten oder weiterlaufen lassen?

Trennen Sie ihn zuerst beim Provider vom Netzwerk. Lassen Sie ihn dann lange genug laufen, um einen Snapshot zu erstellen und die laufenden Prozesse zu prüfen. Das Ausschalten zerstört die Prozessliste. Außerdem wird das Journal vollständig gelöscht, wenn /var/log/journal nicht vorhanden ist, weil journald dann in den Arbeitsspeicher unter /run schreibt. Schalten Sie den Server trotzdem aus, wenn er aktiv andere Netzwerke angreift und Sie seinen ausgehenden Datenverkehr nicht blockieren können. Die Schadensbegrenzung hat Vorrang vor dem Erhalt der Beweise.

Wie ermittle ich, wann der Angreifer eingedrungen ist?

Suchen Sie in /var/log/auth.log oder im Journal nach der frühesten Zeile mit Accepted password oder Accepted publickey, die Sie nicht erklären können. Vergleichen Sie das Ergebnis mit einer Auflistung der Änderungszeiten, find / -xdev -newerct 'YYYY-MM-DD' -type f, da ctime schwerer zu fälschen ist als mtime. Vergleichen Sie anschließend beide Werte mit den Zeitstempeln im Abuse-Ticket Ihres Providers. Diese wurden außerhalb des Systems erfasst und konnten nicht bearbeitet werden. Wählen Sie ein Backup, das älter ist als das früheste dieser drei Daten. Wenn die Zeitpunkte nicht zusammenpassen, gehen Sie davon aus, dass die Kompromittierung älter ist als Ihre Backup-Historie. Stellen Sie dann nur Daten wieder her, die Sie überprüfen können.

Sind meine Backups nach einer Kompromittierung sicher zur Wiederherstellung?

Die Daten sind es normalerweise, sofern Sie sie prüfen. Die Systemdateien sind es nicht. Ein Backup, das nach dem Eindringen erstellt wurde, enthält die Hintertür. Wenn Sie das gesamte Root-Dateisystem wiederherstellen, stellen Sie daher auch den Angreifer wieder her. Prüfen Sie auch das Backup-Repository selbst. Wenn dessen Zugangsdaten auf dem kompromittierten Server gespeichert waren, wurde die Historie möglicherweise gelöscht oder verändert. Das spricht für Append-only- oder Pull-basierte Backup-Ziele. Stellen Sie die Anwendungsdaten wieder her und installieren Sie die Software anschließend erneut aus den Distributions-Repositories.

Muss ich jemandem mitteilen, dass mein VPS kompromittiert wurde?

Antworten Sie immer auf die Abuse-Benachrichtigung Ihres Hosters. Darüber hinaus hängt es davon ab, wessen Daten auf dem System gespeichert waren. Personenbezogene Daten anderer Personen können eine gesetzliche Meldepflicht auslösen, beispielsweise die 72-stündige Meldung an eine Aufsichtsbehörde nach der DSGVO. Wenn Benutzerzugangsdaten auf dem Server gespeichert waren, informieren Sie die betreffenden Benutzer, damit sie ihre Passwörter auch an anderer Stelle ändern können. Wenn Schlüssel auf dem Server den Zugriff auf Systeme Dritter autorisierten, beispielsweise auf einen Code-Host oder ein Cloud-Konto, informieren Sie diese Anbieter, damit sie auf Missbrauch prüfen können. Ein rein persönlicher Server, auf dem keine Daten anderer Personen gespeichert sind, bringt über das Abuse-Ticket hinaus keine Verpflichtung mit sich.