Die meisten Betreiber von WordPress-Websites haben Backups. Fast keiner hat Backups, die er tatsächlich getestet hat. Der Unterschied wird zum denkbar schlechtesten Zeitpunkt brutal sichtbar: an dem Tag, an dem man sie braucht. Dieser Artikel schildert einen realen Fall aus einem jüngsten Vorfall bei einer Sydney-Agentur, bei dem die Backup-Geschichte eine schwierige Wiederherstellung beinahe in ein Beinahe-Desaster verwandelt hätte – und was wir geändert haben, damit das nicht wieder passiert.
Der Vorfall
Die Agentur betreibt ein Portfolio von Kunden-Websites kleiner Unternehmen auf einem einzigen Shared-Host. Eine davon, die eigene Website der Agentur, wurde kompromittiert. Ein SEO-Cloaking-Angriff hatte still schädliche Dateien in das Document-Root gelegt, die echte WordPress-Seitennamen mit vom Angreifer kontrolliertem Inhalt nachahmten. Die Bereinigung selbst war unkompliziert, sobald der Einstiegspunkt identifiziert war. Der schwierigere Teil war die Entscheidung, wie weit zurückgesetzt werden sollte.
Die forensische Analyse deutete darauf hin, dass der Angreifer mindestens einige Wochen vor der Entdeckung auf der Website war. Zur Sicherheit sah der Wiederherstellungsplan eine Wiederherstellung aus einem Backup vor, das vor dem vermuteten Eindringdatum erstellt wurde. Je sauberer die Ausgangsbasis vor dem Vorfall, desto geringer die Chance, dass eine subtile Hintertür die Bereinigung überlebt.
Die erste Überraschung
Das Backup-Plugin war beim Start der Website vor zwei Jahren installiert und konfiguriert worden. Der Plan sah tägliche Datenbank-Backups und wöchentliche Voll-Backups vor, beide in ein externes Cloud-Speicherkonto hochgeladen. Als der Agenturinhaber ein Backup von sechs Wochen vor dem Vorfall abrufen wollte, war die Antwort unbequem: Das jüngste Backup im Cloud-Speicher war zwölf Monate alt.
Das Backup-Plugin war seit mindestens einem Jahr still gescheitert. Die Agentur hatte keine Ahnung. Die Benachrichtigungen über die Fehler gingen an eine E-Mail-Adresse, die nicht mehr überwacht wurde. Niemand war auf die Idee gekommen, den Zielspeicher zu prüfen, um zu bestätigen, dass die Dateien tatsächlich ankamen. Das System war still weit länger kaputt als der eigentliche Sicherheitsvorfall.
Die zweite Überraschung
Die Agentur wandte sich zur Absicherung an den Hoster. Viele Managed-Hoster führen eigene Backups, unabhängig von jedem Plugin. In diesem Fall betrug die Aufbewahrung der Host-Backups 30 Tage. Es wurde vermutet, dass die Kompromittierung rund 45 Tage vor der Entdeckung begonnen hatte. Die Backups des Hosts lagen innerhalb des Kompromittierungsfensters, nicht davor.
Jedes Backup, das der Host liefern konnte, enthielt mit hoher Wahrscheinlichkeit die Dateien des Angreifers. Eine Wiederherstellung daraus hätte lediglich die Uhr zurückgesetzt. Es gab keinen sauberen Punkt vor dem Vorfall, auf den man hätte wiederherstellen können.
Der Wiederherstellungsweg, der funktionierte
Ohne sauberes Backup musste die Wiederherstellung Datei für Datei erfolgen. Der forensische Snapshot der aktuellen Website wurde mit einem frischen Download des WordPress-Kerns verglichen, Theme-Dateien wurden dort, wo Versionskontrolle vorhanden war, dagegen geprüft, Plugins wurden aus ihren offiziellen Quellen neu installiert statt aus dem kompromittierten Code wiederverwendet, und die Datenbank wurde von bekannten Schadmustern bereinigt, ohne zurückgesetzt zu werden.
Das dauerte um ein Vielfaches länger als eine einfache Wiederherstellung. Jeder Schritt musste verifiziert werden. Die Gesamtkosten waren erheblich, und mehrere Verbesserungen an der Website gingen verloren, weil der jüngste verifizierbare Theme-Code aus einem Monate alten Export statt aus dem Live-Zustand stammte. Die Bereinigung funktionierte, aber die Kosten waren deutlich höher, als sie hätten sein müssen.
Die neue Backup-Regelung
Nach dem Vorfall stellte die Agentur auf eine Backup-Regelung um, die wir auf den von uns betreuten WordPress-Websites einsetzen. Die Merkmale sind wichtig, daher lohnt es sich, konkret zu werden.
Tägliche inkrementelle Backups von Dateien und Datenbank. Wöchentliche Voll-Backups. Alle Backups extern in einem Speicherkonto abgelegt, das von der WordPress-Website selbst nicht erreichbar ist, damit eine Kompromittierung nicht die Backups zusammen mit der Live-Website löschen kann.
Die Aufbewahrung ist so eingestellt, dass Backups mindestens 90 Tage verfügbar bleiben. Das bietet ein sauberes Fenster vor dem Vorfall, selbst bei langsam schwelenden Kompromittierungen.
Alarmbenachrichtigungen für fehlgeschlagene Backups gehen an ein überwachtes geschäftliches Postfach, nicht an eine private E-Mail. Zwei Personen erhalten die Alarme, damit der Urlaub einer einzelnen Person keinen Fehler verdecken kann.
Ein vierteljährlicher Wiederherstellungstest läuft gegen eine Staging-Umgebung. Das Backup wird heruntergeladen, wiederhergestellt und gegen die Live-Website verifiziert. Ist etwas defekt, wird es vor dem nächsten Quartal behoben.
Was Sie heute tun können
Wenn Ihnen dieser Fall unangenehm vertraut vorkommt, hier eine kurze Liste von Schritten, die Sie diese Woche durchgehen können. Jeder dauert nur Minuten.
Melden Sie sich bei dem Ziel an, an das Ihre Backups gehen, egal welches. Bestätigen Sie, dass die jüngste Datei von heute oder gestern ist. Bestätigen Sie, dass in den letzten 90 Tagen durchgehend Dateien angekommen sind. Öffnen Sie die E-Mail-Adresse, die Backup-Fehlerbenachrichtigungen erhalten sollte, und bestätigen Sie, dass sie noch überwacht wird.
Wählen Sie das jüngste Backup. Laden Sie es herunter. Versuchen Sie, es auf einer Staging-Website oder in einer lokalen Umgebung wiederherzustellen. Vergewissern Sie sich, dass es tatsächlich als Backup funktioniert, nicht nur als Datei.
Prüfen Sie die Backup-Aufbewahrung Ihres Hosts. Ist das Aufbewahrungsfenster lang genug, um eine langsame Kompromittierung abzudecken? Wenn nicht, ergänzen Sie es durch eine externe Lösung mit längerer Aufbewahrung.
Das Prinzip
Ein Backup ist erst real, sobald Sie es wiederhergestellt haben. Bis dahin ist es eine Vermutung. Die Kosten des Testens sind gering. Die Kosten, es auf die harte Tour herauszufinden, sind groß genug, um die Wiederherstellung selbst zu gefährden. Behandeln Sie die Backup-Verifizierung als Teil Ihrer Routine, nicht als etwas, zu dem Sie irgendwann kämen.
Brauchen Sie Unterstützung?
Wenn Ihre WordPress-Backup-Regelung Lücken hat, kann Defyn sie prüfen, zuverlässige externe Backups mit angemessener Aufbewahrung einrichten, einen Wiederherstellungstest durchführen, um zu bestätigen, dass sie funktioniert, und sicherstellen, dass die Alarme an Menschen gehen, die sie sehen. Nehmen Sie Kontakt auf, und wir geben Ihnen eine Backup-Regelung, auf die Sie sich wirklich verlassen können.
