Server gehackt: Sofortmaßnahmen und sauberer Neuaufbau

Wenn Ihr Server gehackt wurde, trennen Sie ihn zuerst vom Netz, ohne ihn auszuschalten, und sichern Sie einen Snapshot samt Logs als Beweis. Danach grenzen Sie den Einfallsweg ein, setzen das System auf sauberer Basis neu auf, statt es zu bereinigen, und tauschen alle Zugangsdaten, die auf dem Server lagen oder dort verwendet wurden. Sind personenbezogene Daten betroffen, prüfen Sie parallel die Meldepflicht nach DSGVO, die innerhalb von 72 Stunden greifen kann.

Dieser Beitrag führt Sie durch die einzelnen Schritte, zeigt Befehle für die erste Analyse unter Linux und erklärt, welche Fehler in den ersten Stunden am meisten Schaden anrichten.

Woran erkennen Sie, dass ein Server gehackt wurde?

Ein Einbruch kündigt sich selten mit einer eindeutigen Meldung an. Meist sind es Auffälligkeiten, die einzeln harmlos wirken und erst zusammen ein Bild ergeben.

Dauerhaft hohe CPU-Last ohne erkennbaren Grund, oft durch Krypto-Miner
Ungewöhnlicher ausgehender Datenverkehr, etwa Massenversand von E-Mails oder Verbindungen zu unbekannten Zielen
Neue Benutzerkonten, unbekannte SSH-Schlüssel in authorized_keys oder neue Cronjobs
Geänderte Dateien im Webverzeichnis, fremde PHP-Dateien in Upload-Ordnern
Hinweise von außen: Abuse-Meldungen, Einträge auf Blacklists, Warnungen von Suchmaschinen
Lücken oder Brüche in Logdateien, also Zeiträume ohne Einträge

Gerade der letzte Punkt wird oft übersehen. Angreifer löschen oder kürzen Logs, um ihre Spuren zu verwischen. Fehlende Einträge sind deshalb selbst ein Befund.

Server gehackt: Die ersten Schritte in der richtigen Reihenfolge

In den ersten Stunden entscheidet die Reihenfolge darüber, ob Sie den Vorfall später nachvollziehen können. Hektisches Aufräumen zerstört genau die Spuren, die Sie für die Ursachenanalyse brauchen.

Ruhe bewahren und dokumentieren: Notieren Sie ab jetzt jede Beobachtung und jede Maßnahme mit Uhrzeit. Das hilft bei der Analyse und ist Grundlage für eine mögliche Meldung an die Behörde.
Snapshot erstellen: Lassen Sie über die Verwaltungsoberfläche Ihres Anbieters einen Snapshot des laufenden Systems anfertigen, bevor Sie etwas verändern.
Netzwerk isolieren: Sperren Sie ein- und ausgehenden Verkehr über eine Firewall vor dem Server, idealerweise beim Anbieter. Erlauben Sie nur Ihren eigenen Administrationszugang von einer festen IP-Adresse.
Nicht ausschalten: Ein Neustart löscht den Arbeitsspeicher mit laufenden Prozessen und offenen Verbindungen. Manche Schadsoftware ist nur dort zu finden.
Verantwortliche informieren: Geschäftsführung, Datenschutzbeauftragte und gegebenenfalls Ihren Dienstleister. Klären Sie, wer entscheidet und wer nach außen kommuniziert.
Abhängige Systeme prüfen: Welche anderen Server, Datenbanken oder Dienste waren von diesem Server aus erreichbar? Dort können Angreifer bereits weitergezogen sein.

Ändern Sie Passwörter in dieser Phase nicht vom betroffenen Server aus. Ein Keylogger oder manipulierte Programme würden die neuen Zugangsdaten sofort mitlesen.

Was Sie vor dem Neuaufbau sichern sollten

Die Beweissicherung klingt nach Forensiklabor, ist im KMU-Alltag aber überschaubar. Ziel ist, später rekonstruieren zu können, wann und wie der Angreifer eingedrungen ist.

Den Snapshot der Festplatte, unverändert und schreibgeschützt aufbewahrt
Logdateien aus /var/log, Webserver-Logs und Anwendungslogs
Logs, die außerhalb des Servers gespeichert sind, etwa in einem zentralen Logsystem oder beim Anbieter
Eine Liste laufender Prozesse und offener Netzwerkverbindungen zum Zeitpunkt der Entdeckung

Logs, die bereits vor dem Vorfall auf ein anderes System geschrieben wurden, sind besonders wertvoll. Ein Angreifer mit Root-Rechten kann lokale Logs beliebig verändern, entfernte Kopien aber nicht nachträglich manipulieren.

Wie Sie den Einfallsweg eingrenzen

Bevor Sie neu aufsetzen, sollten Sie wissen, wie der Angreifer hereingekommen ist. Sonst steht das neue System mit derselben Lücke im Netz und wird erneut kompromittiert.

Die folgenden Befehle liefern einen ersten Überblick. Beachten Sie dabei: Auf einem kompromittierten System können Programme wie ps oder ls manipuliert sein. Belastbarer ist die Analyse des Snapshots, eingehängt auf einem sauberen System.

# Wer ist angemeldet, wer war zuletzt angemeldet?
w
last -a | head -50
lastb -a | head -50

# Konten mit UID 0 (Root-Rechte)
awk -F: '$3 == 0' /etc/passwd

# SSH-Schlüssel aller Benutzer
find / -name authorized_keys -exec ls -l {} \; -exec cat {} \; 2>/dev/null

# Cronjobs aller Benutzer und systemweit
for u in $(cut -d: -f1 /etc/passwd); do crontab -l -u "$u" 2>/dev/null; done
ls -la /etc/cron.* /var/spool/cron 2>/dev/null

# Offene Ports und Verbindungen mit Prozess
ss -tulpn
ss -tnp state established

# Prozessbaum
ps auxf

# In den letzten 7 Tagen geänderte Dateien im Webverzeichnis
find /var/www -type f -mtime -7 -ls

# Aktivierte systemd-Dienste
systemctl list-unit-files --state=enabled

Typische Einfallswege in KMU-Umgebungen sind veraltete Webanwendungen und Plugins, ungepatchte Dienste, schwache oder wiederverwendete Passwörter, offen erreichbare Administrationsoberflächen und abgeflossene Zugangsdaten. Prüfen Sie Webserver-Logs auf auffällige Anfragen rund um den Zeitpunkt der ersten Datei-Änderung, etwa POST-Anfragen auf Upload-Skripte oder unbekannte PHP-Dateien.

Wenn auf dem Server PHP-Anwendungen laufen, lohnt ein Blick auf bekannte Lücken der eingesetzten Version. Der kostenlose PHP-Sicherheitscheck prüft eine Domain samt Subdomains auf zwei aktuelle kritische PHP-Schwachstellen und nennt je Host die nächsten Schritte.

Bereinigen oder neu aufsetzen?

Die Versuchung ist groß, die gefundene Schadsoftware zu löschen und weiterzumachen. Davon ist abzuraten. Sie wissen nie sicher, ob Sie alle Hintertüren gefunden haben, zumal Angreifer gezielt mehrere Zugänge anlegen: einen auffälligen, der gefunden werden soll, und einen unauffälligen, der bleibt.

Ein kompromittiertes System gilt als nicht mehr vertrauenswürdig und wird neu aufgesetzt, nicht repariert. Daten übernehmen Sie geprüft, Programme und Konfiguration bauen Sie frisch auf.

Für den Neuaufbau gilt:

Betriebssystem aus offizieller Quelle neu installieren, nicht aus einem Image des befallenen Systems
Anwendungen in aktueller Version frisch installieren, Plugins und Themes nur aus vertrauenswürdigen Quellen
Konfigurationsdateien einzeln prüfen und übernehmen, nicht pauschal kopieren
Nutzdaten wie Datenbankinhalte und Uploads auf eingeschleuste Skripte prüfen, bevor sie zurückgespielt werden
Die gefundene Lücke schließen, bevor der neue Server ans Netz geht

Bei der Wahl des Backups ist der Zeitpunkt des Einbruchs entscheidend, nicht der Zeitpunkt der Entdeckung. Zwischen beiden liegen oft Tage oder Wochen. Ein Backup aus diesem Zeitraum enthält die Hintertür bereits. Wie Sie Wiederherstellungen vorab testen und realistische Ziele für Datenverlust und Ausfallzeit festlegen, beschreibt der Beitrag Backup ist nicht Restore.

Eine Anleitung für die Grundhärtung des neuen Systems finden Sie in der Checkliste zum Härten von Linux-Servern.

Welche Zugangsdaten Sie jetzt ändern müssen

Gehen Sie davon aus, dass alles, was auf dem Server gespeichert war oder dort eingegeben wurde, dem Angreifer bekannt ist. Ändern Sie die Zugangsdaten von einem sauberen Gerät aus und erst, wenn das neue System bereitsteht.

Root- und Benutzerpasswörter, SSH-Schlüssel (neue Schlüsselpaare erzeugen, alte überall entfernen)
Datenbankpasswörter und Anwendungskonten
API-Schlüssel und Tokens für Zahlungsanbieter, Mailversand, Cloud-Speicher oder Schnittstellen
Zugänge zur Verwaltungsoberfläche des Hosters, zum Domain- und DNS-Konto
Private Schlüssel von TLS-Zertifikaten: neu erzeugen und das alte Zertifikat widerrufen
Passwörter, die Mitarbeitende auch an anderer Stelle verwenden

Das DNS-Konto verdient besondere Aufmerksamkeit. Wer dort Zugriff hat, kann Mail- und Webverkehr umleiten, auch wenn der Server selbst längst sauber ist. Aktivieren Sie bei allen Konten, die es anbieten, eine Zwei-Faktor-Authentifizierung.

Meldepflichten: Wann die DSGVO greift

Lagen auf dem Server personenbezogene Daten, etwa Kundendaten, Bestellungen oder Bewerbungen, ist der Vorfall in der Regel eine Datenschutzverletzung im Sinne der DSGVO. Nach Art. 33 DSGVO müssen Sie diese innerhalb von 72 Stunden nach Bekanntwerden an die zuständige Aufsichtsbehörde melden, es sei denn, sie führt voraussichtlich nicht zu einem Risiko für die Betroffenen.

Besteht ein hohes Risiko, etwa weil Passwörter, Bankdaten oder Gesundheitsdaten abgeflossen sein könnten, müssen nach Art. 34 DSGVO zusätzlich die Betroffenen informiert werden. Die Frist läuft auch dann, wenn die Analyse noch nicht abgeschlossen ist. Eine Meldung kann nachträglich ergänzt werden.

Beziehen Sie Ihre Datenschutzbeauftragten früh ein und dokumentieren Sie auch dann, wenn Sie zu dem Schluss kommen, dass keine Meldung nötig ist. Die Begründung müssen Sie auf Nachfrage vorlegen können. Wird der Server von einem Dienstleister betrieben, regelt der Auftragsverarbeitungsvertrag, wie schnell dieser Sie über einen Vorfall informieren muss.

Nach dem Vorfall: Was sich dauerhaft ändern sollte

Ein Einbruch zeigt fast immer eine Lücke im Betrieb, nicht nur eine technische Schwachstelle. Die wichtigste Frage im Rückblick lautet deshalb nicht nur, wie der Angreifer hereinkam, sondern warum es niemand früher bemerkt hat.

Updates: Gibt es feste Wartungsfenster und eine Übersicht, welche Software auf welchem Stand ist?
Monitoring: Wären hohe Last, neue Prozesse oder ungewöhnlicher Ausgangsverkehr aufgefallen?
Logging: Werden Logs auf ein separates System geschrieben, damit sie einen Einbruch überdauern?
Backups: Gibt es Sicherungen, die vom Server aus nicht verändert oder gelöscht werden können?
Zugänge: Wer hat Zugriff, und werden Konten ausgeschiedener Mitarbeitender entfernt?

Halten Sie die Ergebnisse schriftlich fest, mit konkreten Maßnahmen und Verantwortlichen. Ein solches Dokument ist im Wiederholungsfall der beste Beleg dafür, dass Sie aus dem Vorfall gelernt haben.

Wann externe Unterstützung sinnvoll ist

Kleinere Vorfälle, etwa ein kompromittiertes Kontaktformular auf einem einzelnen Webserver, lassen sich mit internem Wissen gut bewältigen. Externe Hilfe ist ratsam, wenn sensible Daten betroffen sind, mehrere Systeme befallen sein könnten, eine Erpressung im Raum steht oder rechtliche Schritte geplant sind. Bei Erpressung und Datendiebstahl kommt auch eine Anzeige bei der Polizei in Betracht.

Für die Zeit nach dem Vorfall gibt es verschiedene Wege. NETARO bietet zum Beispiel eine unabhängige IT-Beratung mit Prüfung von Sicherheit und Datenschutz an, deren Ergebnis ein schriftliches Dokument mit nächsten Schritten ist. Wer den laufenden Betrieb nicht mehr selbst stemmen möchte, kann Server als Managed Hosting mit Härtung, Updates, 24/7-Monitoring und Backups mit geprüfter Rücksicherung betreiben lassen. Ebenso möglich ist ein anderer Dienstleister oder der Aufbau eigener Kompetenz im Team.

FAQ

Soll ich einen gehackten Server sofort ausschalten?

Nein, isolieren Sie ihn besser über eine Firewall vom Netz und erstellen Sie einen Snapshot. Beim Ausschalten gehen laufende Prozesse, offene Verbindungen und Schadcode im Arbeitsspeicher verloren, die für die Analyse wichtig sein können. Nur wenn der Server aktiv weiteren Schaden anrichtet und sich nicht isolieren lässt, ist das Abschalten das kleinere Übel.

Reicht es, die gefundene Schadsoftware zu löschen?

In der Regel nicht. Angreifer hinterlassen häufig mehrere Hintertüren, und mit Root-Rechten können sie Systemprogramme so verändern, dass ihre Spuren verborgen bleiben. Sicher ist nur ein Neuaufbau auf frischer Basis mit geprüften Daten und geschlossener Lücke.

Welches Backup kann ich nach einem Hack verwenden?

Nur ein Backup aus der Zeit vor dem Einbruch, nicht vor der Entdeckung. Ermitteln Sie anhand von Logs und Dateizeitstempeln den frühesten Hinweis auf den Angreifer. Spielen Sie bevorzugt nur Nutzdaten zurück und installieren Sie System und Anwendungen neu.

Muss ich einen gehackten Server der Datenschutzbehörde melden?

Wenn personenbezogene Daten betroffen sind und ein Risiko für die Betroffenen nicht auszuschließen ist, ja, innerhalb von 72 Stunden nach Art. 33 DSGVO. Bei hohem Risiko müssen zusätzlich die Betroffenen informiert werden. Dokumentieren Sie den Vorfall und Ihre Entscheidung in jedem Fall.

Server gehackt: Was tun? Sofortmaßnahmen, Beweissicherung und sauberer Neuaufbau für KMU