Woran Sie erkennen, ob Ihre Schutzmaßnahmen wirklich greifen

Eine Sicherheitsfunktion lässt sich in fünf Minuten „fertig” machen: Häkchen setzen, Anzeige wird grün, Thema erledigt. Ob sie im Ernstfall tatsächlich etwas verhindert, sagt diese Anzeige nicht. Das habe ich an einem eigenen Sicherheitsmodul gelernt, das ich für unsere Kundenseiten baue — und zwar auf die unangenehme Art.

Der Moment, in dem eine grüne Anzeige log

Ich baue seit einiger Zeit an einem Sicherheitsmodul, das WordPress-Seiten unserer Wartungskunden künftig zusätzlich absichern soll: Malware-Scan, Integritäts-Scan gegen den WordPress-Kern, Zwei-Faktor-Login, Kontenüberwachung, Härtung der Zugänge. Vor dem ersten Rollout habe ich es geprüft, wie ich jeden Code prüfe, der später auf Kundenseiten läuft — auf einer eigens dafür eingerichteten Testinstallation, nicht auf einer echten Kundenseite.

Dabei fiel eine Zeile auf, die harmlos aussah: Das Scan-Kommando legte bei jedem Aufruf brav einen neuen Scan-Datensatz an. Nur — es prüfte dabei keine einzige Datei. Die eigentliche Verarbeitung hing komplett an einem geplanten Hintergrund-Job, den niemand einzeln getestet hatte.

Auf dem Dashboard stand „Scan abgeschlossen”. Die Wahrheit war: Es gab nichts abzuschließen, weil es nie angefangen hatte.

Warum „aktiviert” nichts beweist

Das ist kein Einzelfall einer schlampigen Implementierung — es ist ein strukturelles Problem. Eine Sicherheitsfunktion besteht aus zwei getrennten Teilen: der Oberfläche, die sagt, dass sie läuft, und der tatsächlichen Verarbeitung dahinter. Beide sind unabhängig voneinander kaputt gehbar. Eine Oberfläche kann fehlerfrei „grün” anzeigen, während der eigentliche Mechanismus seit Wochen nichts tut — ein stiller Fehler, ein vergessener Hook, eine Berechtigung, die im Hintergrund fehlt.

Wer eine Schutzfunktion nur konfiguriert und der Anzeige vertraut, prüft am Ende nur die Oberfläche. Ob der Mechanismus dahinter im Ernstfall greift, bleibt unbeantwortet — bis zu dem Tag, an dem der Ernstfall eintritt und die Antwort zu spät kommt.

Die Gegenprobe: vier simulierte Angriffe statt vier Häkchen

Nach der Korrektur wollte ich nicht nur sehen, dass der Scan jetzt Dateien zählt. Ich wollte sehen, dass er das Richtige findet. Also habe ich auf der Testinstallation vier realistische Angriffsmuster nachgestellt, jedes einzelne so, wie es bei einem echten Angriff vorkäme:

Eine Web-Shell, versteckt im Uploads-Ordner, mit verschleiertem Code über eine base64-codierte eval-Anweisung — ein Muster, wie es bei echten Angriffen dieser Art vorkommt.

Ein getarntes Muss-Plugin, das beim Laden automatisch mitläuft, ganz ohne Aktivierung im Backend.

Ein versteckter Administrator-Account, per direktem Eintrag in die Datenbank erzeugt — bewusst an jedem Hook vorbei, den eine normale Kontenüberwachung beobachtet.

Eine manipulierte Kern-Datei von WordPress selbst, mit einer einzelnen veränderten Zeile im Prüfsummen-Hash.

Das Ergebnis nach der Korrektur: 19.152 Dateien im Malware-Scan geprüft in rund acht Sekunden, 29.704 Dateien im Integritäts-Scan — und alle vier simulierten Angriffe wurden gefunden, mit der jeweils richtigen Einstufung. Die Web-Shell als kritischer Fund über zwei unabhängige Erkennungswege gleichzeitig, der versteckte Administrator über die Differenz zwischen Datenbank und normalem Anlegeweg, die Kern-Manipulation über den veränderten Hash.

Erst an diesem Punkt war die Funktion für mich „fertig” — nicht, als die Checkbox grün wurde.

Was das für jede Schutzfunktion bedeutet, die Sie einsetzen

Der Maßstab gilt nicht nur für ein Plugin, das ich selbst entwickle. Er gilt für jede Sicherheitsfunktion, auf die ein Unternehmen sich verlässt:

Eine Firewall ist erst geprüft, wenn ein bekanntes Angriffsmuster tatsächlich blockiert wurde — nicht, wenn sie im Panel als „aktiv” markiert ist.

Ein Backup ist erst eines, wenn eine Rücksicherung tatsächlich durchgespielt wurde — eine Sicherungsdatei, die nie zurückgespielt wurde, ist eine Behauptung.

Ein Zwei-Faktor-Login ist erst wirksam, wenn jemand versucht hat, ihn zu umgehen, und daran gescheitert ist.

Eine Kontenüberwachung ist erst eine Überwachung, wenn ein an der Oberfläche vorbei angelegtes Test-Konto tatsächlich eine Meldung ausgelöst hat.

In jedem dieser Fälle ist der Unterschied zwischen „konfiguriert” und „geprüft” genau der Unterschied, der im Ernstfall zählt. Für Technikentscheider heißt das konkret: Bei der nächsten Frage an einen Dienstleister oder an die eigene IT nicht fragen „ist das aktiviert?”, sondern „wann wurde das zuletzt mit einem echten Testfall geprüft, und was war das Ergebnis?”.

Was ich nicht verspreche

Ein bestandener Test ist eine Momentaufnahme, keine Garantie auf Dauer. Jede Änderung am Code, jedes Update einer Abhängigkeit, jede neue Konfiguration kann eine geprüfte Funktion wieder stumm schalten — auf genau die Art, wie es beim ersten Mal passiert ist. Deshalb gehört die Gegenprobe nicht einmalig vor den Rollout, sondern wiederkehrend nach jeder relevanten Änderung in den Ablauf.

Und: Eine geprüfte Erkennung ersetzt keine Reaktion. Dass ein Angriff gefunden wird, ist die Voraussetzung dafür, dass jemand handelt — nicht der Ersatz dafür. Wer Meldungen bekommt und sie ignoriert, hat vom Test nichts gewonnen.

Wenn Sie das bei sich prüfen wollen

Wenn Sie sich gerade fragen, ob eine Ihrer Schutzfunktionen wirklich das tut, was das Dashboard behauptet: Der ehrlichste Weg, das herauszufinden, ist ein kontrollierter Testfall — nicht noch eine weitere Anzeige. Wenn Sie dabei Unterstützung möchten oder einfach zweite Augen auf Ihre bestehende Absicherung brauchen, schreiben Sie mir.