Website vom Netz genommen: der geordnete Wiederanlauf

Von Metehan KurtFachlich geprüft von Seamand Mala21. Oktober 20266 Min. Lesezeit

TeilenLinkedIn Xing X Facebook WhatsApp E-Mail

Ein aus dem Switch gezogenes Netzwerkkabel liegt in der Hand eines Technikers vor dem Serverschrank, der Port daneben ist unbelegt — Symbolbild, künstlich erzeugtStand der Angaben: Oktober 2026

Sie haben heute den Stecker gezogen – Website offline, Shop geschlossen, vielleicht auch das Ticketsystem abgeklemmt. Das war in vielen Fällen richtig; das BSI nennt das Trennen vom Internet ausdrücklich als Alternative zum sofortigen Patch. Nur stellt sich jetzt die nächste Frage, und auf die ist kaum jemand vorbereitet: Wie kommt man geordnet zurück, ohne das Problem wieder mit online zu nehmen? Dieser Beitrag beschreibt den Wiederanlauf in der Reihenfolge, die sich im Incident Response bewährt hat.

Der teuerste Fehler kommt jetzt

Der Druck steigt mit jeder Stunde. Vertrieb fragt, Kunden rufen an, die Geschäftsführung will eine Ansage. Die naheliegende Reaktion: Patch einspielen, Dienst starten, fertig.

Das ist genau dann falsch, wenn zwischen dem 20. Oktober und Ihrem Abschalten ein verwundbares System erreichbar war. Denn der Patch schließt die Lücke – er entfernt nicht, was in der Zwischenzeit hereingekommen sein könnte. Wer einen übernommenen Server patcht und wieder anschaltet, hat einen gepatchten übernommenen Server.

Die Reihenfolge lautet deshalb: erst klären, dann bereinigen, dann starten. Nicht umgekehrt.

Schritt 1: Den Zustand einfrieren, bevor etwas verändert wird

Solange das System aus ist, arbeitet die Zeit für Sie. Nutzen Sie das.

Sichern Sie, bevor Sie anfassen: die Protokolle von Webserver und PHP, den Dateibestand des Website-Verzeichnisses, die Konfiguration und – wenn es sich um eine virtuelle Maschine handelt – am besten einen vollständigen Schnappschuss. Legen Sie diese Sicherung getrennt ab, nicht auf demselben System.

Das klingt nach Aufwand für den Fall, dass nichts war. Ist aber billig: Wenn sich in zwei Wochen herausstellt, dass doch etwas passiert ist, haben Sie dann noch Material. Ohne diesen Schritt ist der Zeitraum unwiederbringlich weg.

Schritt 2: Den Zeitraum bestimmen

Zwei Daten brauchen Sie:

Ab wann war das System verwundbar erreichbar? Technisch waren die Lücken schon lange vorhanden, praktisch wird seit dem vorzeitigen Bekanntwerden am 20. Oktober 2026 gesucht; Angriffsverkehr wurde am 21. Oktober ab 07:43 Uhr UTC beobachtet. Rechnen Sie ab dem 20. Oktober.

Wann haben Sie abgeschaltet? Das ist das Ende des Fensters.

Alles dazwischen ist der Zeitraum, den Sie prüfen. Bei den meisten Unternehmen sind das wenige Stunden bis zwei Tage – überschaubar.

Schritt 3: Nachsehen, ob etwas passiert ist

Jetzt wird geprüft. Worauf dabei im Einzelnen zu achten ist – auffällige Kindprozesse des Webservers, Muster für Gegenverbindungen, neue Dateien, neue Cronjobs, neue Konten –, steht ausführlich in PHP2Shell-Angriff erkennen.

Entscheidend ist, dass Sie das Ergebnis sauber formulieren. Es gibt drei mögliche Ausgänge, und sie führen zu verschiedenen Wegen:

Nichts gefunden. Dann heißt das: In den vorhandenen Aufzeichnungen des geprüften Zeitraums gibt es keine Hinweise. Das ist eine belastbare Aussage und reicht in aller Regel für den Wiederanlauf.
Auffälligkeiten ohne Beweis. Ein Prozess, den niemand erklären kann; eine Datei mit seltsamem Zeitstempel. Dann gehört das geklärt, bevor das System wieder ans Netz geht.
Bestätigter Zugriff. Dann ist der Wiederanlauf ein anderes Projekt – siehe weiter unten.

Schritt 4: Patchen, und zwar vollständig

Erst jetzt. Behoben ist die Lücke in PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35.

Vollständig heißt: nicht nur der eine Server, an den alle denken. Prüfen Sie Test- und Entwicklungssysteme, das alte Projekt unter der Subdomain, das Webmail, die Verwaltungsoberfläche des Netzwerkgeräts. Ein nachgezogenes Zweitsystem hilft wenig, wenn das vergessene Erstsystem weiter offen steht.

Für PHP-Versionen älter als 8.2 erscheint kein Patch mehr. Diese Systeme gehen nicht wieder ans Netz, bevor die Anwendung auf eine unterstützte Version gehoben ist.

Schritt 5: Zugangsdaten erneuern

Wenn ein Angreifer Code auf dem Webserver ausführen konnte, hatte er Zugriff auf alles, was dort lesbar ist. Dazu gehören typischerweise die Zugangsdaten zur Datenbank, Schlüssel für Schnittstellen und Zugänge zu Mailversand oder Zahlungsdienstleistern.

Diese Daten gehören erneuert, bevor der Dienst wieder erreichbar ist – nicht, weil ein Zugriff bewiesen wäre, sondern weil es danach ungleich aufwendiger ist. Denken Sie dabei auch an die Administratorkonten im CMS und an API-Schlüssel, die in Konfigurationsdateien stehen.

Schritt 6: Kontrolliert hochfahren

Nicht alles auf einmal. Bewährt hat sich ein gestufter Start:

Dienst starten, aber nur aus dem eigenen Netz erreichbar. Grundfunktionen prüfen.
Protokollierung einschalten und mitlesen.
Öffentlich erreichbar machen.
Die ersten Stunden aufmerksam beobachten – vor allem auf neue Prozesse und ungewöhnliche ausgehende Verbindungen.

Der dritte Punkt ist der, der am häufigsten übersprungen wird. Wer gerade einen Angriffsversuch hinter sich hat, sollte die erste Nacht danach nicht blind laufen lassen.

Wenn sich ein Zugriff bestätigt

Dann gilt eine andere Regel: Ein kompromittiertes System wird nicht repariert, es wird ersetzt.

Der Grund ist unangenehm, aber klar. Sie wissen, was Sie gefunden haben. Sie wissen nicht, was Sie nicht gefunden haben. Jede Bereinigung ist eine Wette darauf, dass der Angreifer nichts hinterlassen hat, was Sie übersehen haben.

Der Weg führt dann über einen Neuaufbau auf sauberer Grundlage: frisches System, aktuelle PHP-Version, Anwendung aus einer geprüften Quelle, Inhalte und Datenbank aus einer Sicherung von vor dem Eintritt. Genau deshalb ist das Datum aus Schritt 2 so wichtig – ohne das wissen Sie nicht, welche Sicherung noch sauber ist.

Und dann gehört geklärt, ob personenbezogene Daten betroffen sind. In dem Fall gelten Fristen. Beziehen Sie Ihren Datenschutzbeauftragten oder Ihre Rechtsberatung früh ein, nicht erst nach dem Wiederanlauf.

Was Sie aus diesem Tag mitnehmen sollten

Zwei Fragen beantworten sich heute von selbst, und es lohnt sich, die Antwort schriftlich festzuhalten: Wie lange hat es gedauert, bis Sie wussten, wo überall PHP läuft? Und hätten Sie die Protokolle des kritischen Zeitraums überhaupt noch gehabt?

Wenn eine der Antworten unbefriedigend ist, ist das die eigentliche Aufgabe nach diesem Vorfall – nicht der Patch. Wie sich so ein Ablauf ohne Ernstfall üben lässt, beschreibt Ransomware-Krisenübung am Tisch. Und wer kommuniziert, während die halbe Infrastruktur steht, klärt man besser vorher: Notfallkommunikation.

Checkliste: erste Schritte

Protokolle, Dateibestand und möglichst ein Systemabbild sichern, bevor etwas verändert wird
Zeitfenster festlegen: ab 20. Oktober 2026 bis zum eigenen Abschalten
Zeitraum auf Spuren prüfen, Ergebnis mit Prüfumfang schriftlich festhalten
Alle PHP-Systeme patchen, auch Test-, Alt- und Nebensysteme
Datenbankzugänge, API-Schlüssel und Administratorkonten erneuern
Gestuft hochfahren: intern, dann mit Protokollierung, dann öffentlich
Erste 24 Stunden beobachten, besonders ausgehende Verbindungen
Bei bestätigtem Zugriff: Neuaufbau statt Bereinigung, Datenschutz einbeziehen

Wie DAVINCI unterstützt

Wir übernehmen den Wiederanlauf in der hier beschriebenen Reihenfolge: Beweise sichern, Zeitraum prüfen, patchen, Zugänge erneuern, kontrolliert hochfahren – und Sie bekommen schriftlich, was belegt ist und was offen bleibt. Bei bestätigten Vorfällen arbeitet unser Incident Response den Fall auf. Akut erreichen Sie uns rund um die Uhr über IT-Notfall, sonst über die Kontaktseite.

Häufige Fragen

Wie lange darf die Website offline bleiben?

So lange, wie die Prüfung dauert. In den meisten Fällen sind das Stunden, nicht Tage. Setzen Sie eine Hinweisseite, die sagt, dass Sie an einem Sicherheitsupdate arbeiten – das ist besser als eine Fehlermeldung und ehrlicher als Schweigen.

Können wir einfach die Sicherung von gestern einspielen?

Nur wenn Sie wissen, dass sie vor dem Eintritt liegt. Eine Sicherung vom 21. Oktober kann den Angreifer bereits enthalten. Deshalb steht die Bestimmung des Zeitfensters vor jeder Wiederherstellung.

Müssen wir wirklich alle Zugangsdaten tauschen?

Alle, die auf dem betroffenen System lesbar waren. Das sind in der Regel Datenbankzugang, Mailversand, Schnittstellenschlüssel und die Administratorkonten der Anwendung. Zugänge, die dort nie gespeichert waren, sind nicht betroffen.

Wir haben gar keine Protokolle. Was bedeutet das?

Dass Sie für den fraglichen Zeitraum keine Aussage treffen können – weder im Guten noch im Schlechten. Das ist unbefriedigend, aber es ist die ehrliche Lage. Richten Sie die Protokollierung beim Wiederanlauf ein, zentral und außerhalb des überwachten Systems.

Sollten wir Kunden informieren?

Wenn nur gepatcht wurde und nichts gefunden: nein, das ist normaler Betrieb. Bestätigt sich ein Zugriff auf Kundendaten, sieht es anders aus, und dann gelten Fristen. Die Entscheidung gehört mit Datenschutzbeauftragtem oder Rechtsberatung getroffen, nicht aus dem Bauch.

Verwandte Themen: Wer hier weiterdenkt, liest bei Remote Code Execution, WordPress-Sicherheit und PHP-Sicherheitslücke weiter.

Im Text erwähnt

Quellen