Die meisten Betreiber von WordPress-Websites haben Backups. Fast keiner hat Backups, die er tats\u00e4chlich 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\u00fcngsten Vorfall bei einer Sydney-Agentur, bei dem die Backup-Geschichte eine schwierige Wiederherstellung beinahe in ein Beinahe-Desaster verwandelt h\u00e4tte \u2013 und was wir ge\u00e4ndert haben, damit das nicht wieder passiert.<\/p>\n\n\n\n
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\u00e4dliche 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\u00fcckgesetzt werden sollte.<\/p>\n\n\n\n
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\u00fcr die Bereinigung \u00fcberlebt.<\/p>\n\n\n\n
Das Backup-Plugin war beim Start der Website vor zwei Jahren installiert und konfiguriert worden. Der Plan sah t\u00e4gliche Datenbank-Backups und w\u00f6chentliche 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\u00fcngste Backup im Cloud-Speicher war zw\u00f6lf Monate alt.<\/p>\n\n\n\n
Das Backup-Plugin war seit mindestens einem Jahr still gescheitert. Die Agentur hatte keine Ahnung. Die Benachrichtigungen \u00fcber die Fehler gingen an eine E-Mail-Adresse, die nicht mehr \u00fcberwacht wurde. Niemand war auf die Idee gekommen, den Zielspeicher zu pr\u00fcfen, um zu best\u00e4tigen, dass die Dateien tats\u00e4chlich ankamen. Das System war still weit l\u00e4nger kaputt als der eigentliche Sicherheitsvorfall.<\/p>\n\n\n\n
Die Agentur wandte sich zur Absicherung an den Hoster. Viele Managed-Hoster f\u00fchren eigene Backups, unabh\u00e4ngig 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.<\/p>\n\n\n\n
Jedes Backup, das der Host liefern konnte, enthielt mit hoher Wahrscheinlichkeit die Dateien des Angreifers. Eine Wiederherstellung daraus h\u00e4tte lediglich die Uhr zur\u00fcckgesetzt. Es gab keinen sauberen Punkt vor dem Vorfall, auf den man h\u00e4tte wiederherstellen k\u00f6nnen.<\/p>\n\n\n\n
Ohne sauberes Backup musste die Wiederherstellung Datei f\u00fcr 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\u00fcft, Plugins wurden aus ihren offiziellen Quellen neu installiert statt aus dem kompromittierten Code wiederverwendet, und die Datenbank wurde von bekannten Schadmustern bereinigt, ohne zur\u00fcckgesetzt zu werden.<\/p>\n\n\n\n
Das dauerte um ein Vielfaches l\u00e4nger als eine einfache Wiederherstellung. Jeder Schritt musste verifiziert werden. Die Gesamtkosten waren erheblich, und mehrere Verbesserungen an der Website gingen verloren, weil der j\u00fcngste verifizierbare Theme-Code aus einem Monate alten Export statt aus dem Live-Zustand stammte. Die Bereinigung funktionierte, aber die Kosten waren deutlich h\u00f6her, als sie h\u00e4tten sein m\u00fcssen.<\/p>\n\n\n\n
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.<\/p>\n\n\n\n
T\u00e4gliche inkrementelle Backups von Dateien und Datenbank. W\u00f6chentliche 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\u00f6schen kann.<\/p>\n\n\n\n
Die Aufbewahrung ist so eingestellt, dass Backups mindestens 90 Tage verf\u00fcgbar bleiben. Das bietet ein sauberes Fenster vor dem Vorfall, selbst bei langsam schwelenden Kompromittierungen.<\/p>\n\n\n\n
Alarmbenachrichtigungen f\u00fcr fehlgeschlagene Backups gehen an ein \u00fcberwachtes gesch\u00e4ftliches Postfach, nicht an eine private E-Mail. Zwei Personen erhalten die Alarme, damit der Urlaub einer einzelnen Person keinen Fehler verdecken kann.<\/p>\n\n\n\n
Ein viertelj\u00e4hrlicher Wiederherstellungstest l\u00e4uft gegen eine Staging-Umgebung. Das Backup wird heruntergeladen, wiederhergestellt und gegen die Live-Website verifiziert. Ist etwas defekt, wird es vor dem n\u00e4chsten Quartal behoben.<\/p>\n\n\n\n
Wenn Ihnen dieser Fall unangenehm vertraut vorkommt, hier eine kurze Liste von Schritten, die Sie diese Woche durchgehen k\u00f6nnen. Jeder dauert nur Minuten.<\/p>\n\n\n\n
Melden Sie sich bei dem Ziel an, an das Ihre Backups gehen, egal welches. Best\u00e4tigen Sie, dass die j\u00fcngste Datei von heute oder gestern ist. Best\u00e4tigen Sie, dass in den letzten 90 Tagen durchgehend Dateien angekommen sind. \u00d6ffnen Sie die E-Mail-Adresse, die Backup-Fehlerbenachrichtigungen erhalten sollte, und best\u00e4tigen Sie, dass sie noch \u00fcberwacht wird.<\/p>\n\n\n\n
W\u00e4hlen Sie das j\u00fcngste Backup. Laden Sie es herunter. Versuchen Sie, es auf einer Staging-Website oder in einer lokalen Umgebung wiederherzustellen. Vergewissern Sie sich, dass es tats\u00e4chlich als Backup funktioniert, nicht nur als Datei.<\/p>\n\n\n\n
Pr\u00fcfen Sie die Backup-Aufbewahrung Ihres Hosts. Ist das Aufbewahrungsfenster lang genug, um eine langsame Kompromittierung abzudecken? Wenn nicht, erg\u00e4nzen Sie es durch eine externe L\u00f6sung mit l\u00e4ngerer Aufbewahrung.<\/p>\n\n\n\n
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\u00df genug, um die Wiederherstellung selbst zu gef\u00e4hrden. Behandeln Sie die Backup-Verifizierung als Teil Ihrer Routine, nicht als etwas, zu dem Sie irgendwann k\u00e4men.<\/p>\n\n\n\n