Ein kritisches Update am Freitagnachmittag, der Shop muss Montag früh wieder Bestellungen annehmen, und niemand hat die Zahlungsschnittstelle gegen die neue Version geprüft. Das ist kein Einzelfall mehr. Es ist der Alltag von Admins, die WordPress, Magento, Shopware, PHP oder den Linux-Kernel betreuen. Wir nennen das die Patchokalypse: Lücken werden so schnell bekannt und ausgenutzt, dass das eigentliche Update zwar nötig ist, in der verfügbaren Zeit aber nicht mehr verantwortbar getestet werden kann.

Das Dilemma ist einfach und unbequem. Wer wartet, lässt ein bekanntes Loch offen. Wer sofort patcht, riskiert einen Ausfall, den die Lücke selbst nicht verursacht hätte. Beides ist teuer. Der Unterschied ist nur, wer hinterher erklärt, warum der Shop lag.

Warum das Tempo nicht mehr zu einem Testfenster passt

Sicherheitslücken gab es schon immer. Geändert hat sich, wie schnell aus einem Hinweis ein brauchbarer Angriff wird. Forscher setzen KI ein, um Codepfade zu durchsuchen und Varianten einer Schwachstelle zu finden. Dieselbe Klasse von Werkzeugen hilft auf der anderen Seite, aus einer kurzen Beschreibung ein lauffähiges Angriffsmuster zu bauen und es an viele Ziele gleichzeitig zu schicken. Sobald ein Muster öffentlich ist, bleibt es nicht bei einem einzelnen Ziel. Es taucht innerhalb von Stunden bei Shops auf, die sich nie als besonders lohnend gegolten hätten.

Für den Betrieb heißt das: Die Frist zwischen „bekannt“ und „aktiv ausgenutzt“ ist kürzer als ein ordentlicher Test. Ein Magento- oder Shopware-Patch berührt Checkout, Zahlarten, eigene Module und oft die PHP-Version. Ein WordPress-Update kann Themes und Plugins aus der Bahn werfen, die seit Jahren still mitgelaufen sind. Ein PHP- oder Kernel-Update braucht zusätzlich ein Wartungsfenster und manchmal einen Neustart. Wer das an einem Nachmittag einfach einspielt, testet in Produktion. Wer es auf die nächste Woche schiebt, testet die Geduld der Angreifer.

• Die Lücke ist konkret. Sobald ein Muster bekannt ist, wird es automatisiert gegen viele Systeme probiert, nicht nur gegen die großen.
• Der Patch ist selten isoliert. Er zieht Abhängigkeiten mit, die im Staging anders aussehen als live.
• Das Staging ist selten vollständig. Zahlungsanbieter, Cronjobs und echte Datenmengen fehlen dort oft.
• Das Team ist klein. Im Mittelstand ist die Person, die patcht, häufig dieselbe, die den Shop am Laufen hält.

Was ein virtueller Patch ist und was er nicht ist

Ein virtueller Patch ändert nicht den fehlerhaften Code. Er erkennt den Angriff, der die Lücke ausnutzen will, und weist ihn ab, bevor die Anwendung ihn verarbeitet. Die Software bleibt verwundbar, der konkrete Weg hinein ist aber zu. Das kauft Zeit. Es ersetzt das Update nicht.

Genau diese Ehrlichkeit ist der Punkt. Wer einen virtuellen Patch als Dauerlösung verkauft, verschiebt die Arbeit nur. Wer ihn als Brücke nutzt, kann das echte Update auf einen Termin legen, an dem Staging, Zahlung und die eigenen Anpassungen geprüft sind. Dazwischen läuft der Shop, und die bekannten Muster kommen nicht durch.

SiteGuard: die Lücke an der Anwendung schließen

SiteGuard sitzt im Request-Weg von WordPress, Magento, Shopware und individuellen PHP-Systemen. Jeder Aufruf wird gegen Angriffsmuster geprüft, noch bevor Shop oder Website richtig starten. Für bekannte Lücken, etwa aus Magento-Advisories, in WordPress oder bei PHP, lassen sich Regeln ausrollen, die genau das Muster blocken, mit dem die Lücke ausgenutzt wird. Der signierte Regel-Feed bringt diese virtuellen Patches auf die verbundenen Systeme, ohne dass jede Installation einzeln bearbeitet werden muss.

Zwei Grenzen gehören dazu, sonst wird aus Schutz ein Blindflug:

• Erst beobachten, dann blocken. Im Monitor-Modus sehen Sie Treffer, ohne dass legitime Anfragen abgewiesen werden. Breite Regeln, die theoretisch auch normale Requests treffen können, werden nur nach ausdrücklicher Bestätigung aktiv.
• Die Brücke hat ein Ende. Virtuelle Patches aus Hersteller-Advisories, etwa für Magento, lassen sich so setzen, dass sie sich abschalten, sobald kein verbundenes System mehr die verwundbare Version meldet. Sie sollen die Zwischenzeit abdecken und nicht dauerhaft im Regelwerk liegen bleiben.

SiteGuard überschreibt keine Core-Dateien und nimmt die Seite bei einem Fehler im Schutz selbst nicht vom Netz. Der eigentliche Patch bleibt Ihre Aufgabe. Der virtuelle Patch sorgt dafür, dass diese Aufgabe nicht im selben Atemzug wie die Veröffentlichung der Lücke erledigt werden muss.

ServerGuard: dieselbe Zwischenzeit auf dem Server

Viele Lücken sitzen nicht im Shop, sondern darunter: in PHP, im Webserver, im Kernel, in Diensten, die per SSH, Mail oder FTP erreichbar sind. ServerGuard zeigt zuerst, welche Server überhaupt betroffen sind. Installierte Pakete und Laufzeiten werden mit bekannten Lücken und End-of-Life-Daten abgeglichen. Sie patchen die Maschinen, die das Update brauchen, und nicht pauschal alles in der Hoffnung, irgendwo richtig zu liegen.

Bis das Paket getestet und eingespielt ist, greifen die vorübergehenden Schutzregeln. ServerGuard erkennt typische Angriffsspuren in den Logs, zum Beispiel Exploit-Versuche gegen PHP, und sperrt die zugehörige IP über fail2ban. Empfohlene Härtungen lassen sich per signierter Richtlinie ausrollen, ohne freie Kommandos auf den Server zu schicken. Das ist der virtuelle Patch auf Betriebssystemebene: Das Einfallstor für dieses Muster geht zu, das Paket-Update folgt, wenn Wartungsfenster und Test stehen. Auch hier gilt: Diese Maßnahmen ersetzen kein Update.

Updates und Neustarts aus dem Dashboard sind möglich, aber nur, wenn Sie das auf dem Server ausdrücklich freigeben. Standard ist aus. Ein Schutzwerkzeug, das ungefragt Pakete einspielt, würde genau den Test überspringen, um den es hier geht.

Globale Blocklisten: den Angreifer stoppen, bevor er bei Ihnen ankommt

Virtuelle Patches zielen auf ein Muster. Die Blockliste zielt auf die Adresse, die das Muster schon woanders ausprobiert hat. SiteGuard und ServerGuard teilen sich dafür eine Verbund-Liste: IP-Adressen, die auf mehreren geschützten Systemen auffallen, werden an die übrigen verteilt.

Auf der Website prüft SiteGuard diese Liste bei jedem Request, zusätzlich zur lokalen Sperre für Angreifer, die sich an Ihrem eigenen System festbeißen. Echte Besucher hinter einer geteilten Adresse, etwa aus einem Büro oder einem Mobilfunknetz, lösen eine kurze Prüfung im Browser aus und kommen danach durch. Die Adresse bleibt für alle anderen gesperrt. Auf dem Server setzt ServerGuard dieselbe Liste per Firewall um, wahlweise nur zählend oder blockierend. Eigene Adressen, private Netze und aktive SSH-Verbindungen sind ausgenommen. Ist die Liste veraltet oder nicht abrufbar, wird sie geleert, statt weiter zu blocken. Lieber kurz ohne diese eine Schicht als ein Server, der legitimen Verkehr verwirft, weil ein Feed hängt.

Zusammen ergibt das zwei verschiedene Zeitgewinne. Die Regel hält das bekannte Angriffsmuster vom Anwendungscode fern. Die Liste hält Adressen fern, die dieses oder ein ähnliches Muster bereits gegen andere Systeme gefahren haben. Beides ist schneller aktiv als ein getestetes Release.

Wie Sie die gewonnene Zeit nutzen

Die Zwischenzeit ist kein Freifahrtschein. Sie ist das Fenster, in dem der Test stattfinden kann, der am Freitag nicht mehr ging.

1. Betroffene Systeme benennen, statt jedes System gleich zu behandeln.
2. Den virtuellen Patch oder die Sperrregel zuerst im Beobachten-Modus laufen lassen, wenn die Regel breit ist.
3. Das echte Update im Staging gegen Zahlung, eigene Module und die Jobs prüfen, die live anders laufen als in der Kopie.
4. Im Wartungsfenster patchen und danach prüfen, ob der virtuelle Patch sich erledigt hat.
5. Die Blockliste anlassen. Der nächste Versuch kommt selten allein.

Wenn Sie SiteGuard und ServerGuard gemeinsam einsetzen, decken Sie beide Ebenen ab: den Request an den Shop und den Server, auf dem er läuft. Beides liegt in der WebsiteSuite, betrieben in Deutschland. Wer die Zwischenzeit nicht allein organisieren will, erreicht uns über die Kontaktseite.