Zwischen der Veröffentlichung einer Schwachstelle und dem Einspielen des Fixes auf deiner Website liegt immer eine Lücke: Der Entwickler hat noch keine korrigierte Version veröffentlicht, das Update macht eine Funktion kaputt oder niemand hatte Zeit, es zu testen. Virtuelles Patching (manche Anbieter sprechen von einem „vPatch“) soll genau diese Zeitspanne überbrücken. OWASP beschreibt es als Schicht zur Durchsetzung von Regeln, die Versuche erkennt und blockiert, eine bekannte Schwachstelle auszunutzen, ohne die Lücke selbst zu beseitigen.
So funktioniert virtuelles Patching
Sobald die Schwachstelle analysiert ist (verwundbarer Parameter, betroffene Versionen, Bedingungen für die Ausnutzung), wird eine Regel geschrieben, die die gefährlichen Anfragen für genau diesen Fall erkennt. Dafür gibt es zwei Ansätze:
- Positivmodell (Allowlist): Du legst fest, was ein gültiger Wert für den betroffenen Parameter ist, zum Beispiel eine Ganzzahl, und alles andere wird abgewiesen. Das ist am robustesten, erfordert aber Handarbeit.
- Negativmodell (Blocklist): Du blockierst bekannte Angriffsmuster. Das ist schneller umgesetzt, lässt sich aber mit einer anderen Kodierung leichter umgehen.
OWASP empfiehlt, die Regel zunächst im reinen Protokollmodus zu testen, bevor sie blockiert, keine Regeln zu schreiben, die nur exakt den im Advisory veröffentlichten Payload erkennen, und den virtuellen Patch wieder zu entfernen, sobald der Code korrigiert ist.
Wo der virtuelle Patch greift
Ein virtueller Patch lässt sich an mehreren Stellen auf dem Weg einer Anfrage anwenden: in einer Web Application Firewall in der Cloud, im Webserver (ModSecurity unter Apache oder Nginx) oder in einem Agenten innerhalb der Anwendung. Für WordPress setzt Patchstack seine Regeln nur für die verwundbaren Komponenten ein, die auf der Website tatsächlich installiert sind, gestützt auf ein Inventar der Versionen, und führt sie in der Anwendung aus oder, je nach Schwachstelle, schon auf Ebene von Apache oder Nginx.
Wann es sinnvoll ist
- Eine Schwachstelle wird veröffentlicht, ohne dass es eine korrigierte Version gibt, oder der Entwickler reagiert langsam.
- Ein Plugin wird nicht mehr gepflegt, aber die Website hängt noch davon ab: eine Situation, die du beheben solltest, wie unser Beitrag über verwaiste Plugins erklärt, aber nicht über Nacht beheben kannst.
- Du betreust viele Websites, und Updates laufen zuerst über eine Staging-Umgebung.
- Eine Schwachstelle wird wenige Stunden nach der Veröffentlichung massenhaft ausgenutzt, schneller als dein Wartungszyklus.
Für WordPress: Werkzeuge und Grenzen
Patchstack (in den kostenpflichtigen Tarifen), Wordfence und Cloud-Firewalls wie Cloudflare veröffentlichen Regeln für bekannte WordPress-Schwachstellen, mit unterschiedlichen Reaktionszeiten und Modellen; unser Firewall-Vergleich zeigt diese Unterschiede. Ein paar Grenzen solltest du im Blick behalten:
- Eine Regel gibt es erst, wenn die Schwachstelle bekannt ist: Gegen eine Zero-Day-Lücke lässt sich nichts einspielen.
- Die Abdeckung hängt von der Datenbank des Anbieters ab, die bei Premium-Plugins außerhalb von wordpress.org oft dünner ist.
- Eine Anfrage, die nicht geprüft wird (etwa ein Angriff, der nicht über die Firewall läuft), ist nicht geschützt.
WP Masquerade ist keine Firewall und spielt keine virtuellen Patches ein. Es setzt davor und daneben an: Es erschwert die Bestandsaufnahme deiner Plugins von außen, und seine Schwachstellen-Warnungen sagen dir, welches installierte Plugin von einer CVE betroffen ist und in welcher Version sie behoben ist. Die Kombination mit Patchstack zeigt, wie sich die Rollen zwischen beiden aufteilen.