Warum eine Schutzmauer vor der Website keine Updates ersetzt

Ein Kunde hat mir vor Kurzem sein Sicherheits-Dashboard gezeigt, sichtlich zufrieden: Firewall aktiv, mehrere hundert Anfragen geblockt, alles grün. Meine erste Frage war trotzdem nicht „Wie viel wurde abgewehrt?”, sondern: „Wann wurde der Kern zuletzt aktualisiert?”

Die Antwort kannte er nicht. Und das Dashboard half ihm dabei auch nicht weiter — es zeigt, was draußen abgeprallt ist, nicht, was hinter der Mauer noch offensteht.

Ein Fund, der genau das zeigt

Vor Kurzem bin ich in einem Bestand, den ich betreue, auf genau dieses Muster gestoßen. Eine Verwaltungsoberfläche für mehrere Websites hatte eine Ansicht-Einstellung aktiv, die ausstehende Kern-Updates ausblendet — vermutlich einmal gesetzt, um die Übersicht aufzuräumen, und seither niemandem mehr aufgefallen. Auf dem Bildschirm stand: alles aktuell. Tatsächlich offen war eine kritische Lücke im WordPress-Kern, seit Tagen öffentlich bekannt, mit verfügbarer Korrektur.

Zwischen „Lücke wird öffentlich bekannt” und „automatisierte Angriffe laufen” liegen heute Stunden, nicht Wochen. Die Software meldete währenddessen: im grünen Bereich. Das war keine Lüge im technischen Sinn — die Anzeige tat genau das, wofür sie konfiguriert war. Sie hat nur die falsche Frage beantwortet.

Was eine Schutzschicht wirklich leistet

Eine Firewall, ein Sicherheitsplugin, eine Sperrliste bekannter Angreifer-IPs: Das sind sinnvolle, notwendige Bausteine. Sie fangen einen großen Teil des Grundrauschens ab — automatisierte Massenscans, bekannte Angriffsmuster, plumpe Versuche, die rund um die Uhr gegen jede erreichbare Website laufen.

Was sie nicht können: eine Schwachstelle schließen, die im System selbst steckt. Eine Firewall kennt keine neue Lücke, bevor jemand ihr Regeln dafür beibringt — und bei einer frisch veröffentlichten Kern-Lücke ist das Wettrennen zwischen „Regel geschrieben” und „erster erfolgreicher Angriff” keines, das die Regel zuverlässig gewinnt. Sie verkleinert das Zeitfenster. Sie schließt es nicht.

Der zweite blinde Fleck: Offline ist nicht immer offline

Bei einem anderen Fall im selben Zeitraum habe ich eine betroffene Seite über die Serverkonfiguration abgeriegelt — kein Zugriff mehr von außen, aus meiner Sicht sauber stillgelegt. Wenige Minuten später war der schädliche Code trotzdem wieder da.

Der Grund: Manche Hoster führen automatisierte Wartungsaufgaben nicht über den normalen Webserver aus, sondern direkt als eigenen Systemauftrag daneben. Eine Absperrung, die nur den Webserver betrifft, hält diese Aufgaben nicht auf. Der Schadcode hatte sich selbst wieder eingetragen — genau dorthin.

Auch das ist kein Einzelfall aus Bosheit der Technik. Es ist ein Beispiel dafür, dass „sich sicher fühlen” und „sicher sein” zwei verschiedene Zustände sind, und dass der Unterschied oft an einer Stelle liegt, die niemand von sich aus prüft.

Zwei Aufgaben, keine ersetzt die andere

Schutzschicht und Wartung lösen unterschiedliche Probleme, und beide braucht es:

Die Schutzschicht reduziert, was überhaupt an die Anwendung herankommt. Sie ist die erste Verteidigungslinie, arbeitet automatisch, rund um die Uhr, und fängt das Grundrauschen ab, bevor es zum Problem wird.

Die Wartung schließt die Lücke selbst. Kern, Erweiterungen und Themes werden aktualisiert, bevor eine bekannte Schwachstelle zum offenen Einfallstor wird — nicht im Monatsrhythmus nach Kalender, sondern nach Dringlichkeit der jeweiligen Korrektur.

Wer nur die erste Aufgabe erledigt, hat eine Mauer mit einer offenen Tür dahinter — und ein Dashboard, das grün bleibt, während jemand längst hindurchgeht. Wer nur die zweite erledigt, ohne Schutzschicht, lässt das Grundrauschen ungefiltert gegen jedes einzelne Update anrennen, das gerade aussteht.

Was das für die Entscheidung bedeutet

Als Geschäftsführung muss man die technischen Details nicht selbst prüfen können. Zwei Fragen reichen, um herauszufinden, woran man ist:

Erstens: Wer bestätigt aktiv, dass der Kern aktuell ist — nicht per Dashboard-Ampel, sondern per tatsächlicher Prüfung auf dem System? Zweitens: Wenn heute eine kritische Lücke bekannt würde, wie lange würde es dauern, bis jemand das bei Ihrer Website merkt und handelt?

Wenn die erste Antwort „das Dashboard sagt ja” ist und die zweite „keine Ahnung”, dann ist genau das die Lücke, die geschlossen werden sollte — bevor eine andere es tut.

Wenn Sie wissen möchten, wie das bei Ihrer Website aussieht: Schreiben Sie mir. Ein kurzer Blick zeigt meistens schnell, ob die Schutzschicht allein steht oder ob eine Wartung im Hintergrund tatsächlich mitläuft.