01 Ausgangslage
Der Hinweis kam von außen: Auf dem Server eines langjährigen Kunden lief eine Hintertür. Der Onlineshop — B2B und B2C, angebunden an die Warenwirtschaft — hatte seit Jahren keine Sicherheitsupdates mehr bekommen; nicht aus Nachlässigkeit, sondern weil niemand dafür zuständig war. Die Lücke, über die der Angreifer hineinkam, war öffentlich dokumentiert und seit Monaten geschlossen. Nur nicht auf diesem System.
Die Lage war typisch für solche Fälle: Der Shop lief, Bestellungen kamen herein, nach außen war nichts zu sehen. Erst die Analyse zeigte zwei Einstiegswege, Fremddateien an mehreren Stellen und Spuren älterer Zugriffe. Dazu kamen Altlasten, die mit dem Angriff nichts zu tun hatten, aber im selben Zug sichtbar wurden: ungeschützte Dienste, Zugangsdaten im Klartext, Erweiterungen, die seit dem letzten PHP-Wechsel still fehlerhaft liefen.
Der Kunde hatte zwei Fragen: Wie schnell ist der Shop wieder sicher online — und was muss passieren, damit das nicht wieder vorkommt.
02 Lösung
Zuerst sichern, dann verstehen: Shop vom Netz, Dateien, Datenbank und Protokolle mit Prüfsummen in Quarantäne, fremde Schlüssel entfernt, Passwörter getauscht. Die Protokolle rückwärts gelesen, bis beide Einstiegswege und der Zeitpunkt feststanden. Nichts wurde gelöscht, bevor es gesichert war — die Hintertür lag, wie fast immer, nicht dort, wo die erste auffällige Datei lag.
Dann der Neuaufbau: Shopsystem auf den aktuellen Sicherheitsstand gebracht, Fremddateien entfernt, alle Verwaltungskonten mit neuen Passwörtern und zweitem Faktor, Schnittstellen-Zugänge neu vergeben, Webserver gehärtet — Upload- und Installationspfade geschlossen, Verwaltung nur noch aus bekannten Netzen. Weniger als zwei Tage nach dem Hinweis war der Shop wieder online.
Davor eine Firewall: Beide Domains des Shops hinter Cloudflare, mit Regeln gegen die bekannten Angriffspfade, Rate-Limits für Anmeldung und Schnittstellen, Ausnahmen für Zahlungsanbieter und Warenwirtschaft, echte Besucheradressen am Server. In den folgenden Tagen zeigten die Sicherheitsereignisse weitere Sondierungen aus mehreren Ländern — alle liefen gegen die Regeln, keine erreichte den Server.
Und danach die unspektakuläre Hälfte: Wächter für Dateiänderungen, Schnittstellen und Herkunft der Zugriffe, ein tägliches Audit über beide Shop-Frontends, Backups mit Rücksicherungsprobe. Die bei der Analyse gefundenen Altlasten wurden in derselben Woche abgearbeitet. Der Shop steckt seitdem in einem Wartungsvertrag mit festen Prüfintervallen — die Form, in der der Vorfall gar nicht erst entstanden wäre.
03 Ergebnis
Der Shop läuft wieder — auf aktuellem Stand, hinter einer Firewall, mit Zugängen, die ihren Namen verdienen, und mit Wächtern, die melden, bevor Kunden etwas merken. Geschlossen ist die Ursache, nicht nur das Symptom.
Die wichtigste Erkenntnis ist unbequem: Der Patch gegen die genutzte Lücke war seit Monaten verfügbar. Ein Wartungsvertrag mit Sicherheitsupdates in festen Intervallen hätte den Vorfall verhindert — zu einem Bruchteil dessen, was Forensik, Neuaufbau und Nacharbeit gekostet haben. Laufende Pflege ist keine Komfortleistung, sondern die günstigste Form von Sicherheit.
Das gilt auch rechtlich: Artikel 32 DSGVO verlangt dem Risiko angemessene technische Maßnahmen, und regelmäßige Sicherheitsupdates gehören dazu. Wer sie nachweisbar einspielt, erfüllt diese Pflicht und steht im Ernstfall gegenüber Aufsichtsbehörde und Kunden anders da als ein Betreiber mit jahrelangem Rückstand. Ob und was zu melden ist, entscheidet im Einzelfall der Datenschutzbeauftragte — die technischen Fakten dafür liefert ein geordneter Ablauf wie dieser.