ShieldCache in der Praxis: WordPress, Onlineshop und Apps mit WebSockets

Die folgenden Beispiele zeigen bewährte Einstellungen. Passen Sie sie an Ihre Website an und beobachten Sie nach jeder Änderung das WAF-Protokoll und die Statistik.

WordPress

1. Cache: Unter Cache > Regeln die Vorlage WordPress wählen und speichern. Sie nimmt /wp-admin, /wp-login.php, /wp-json, /xmlrpc.php und /wp-cron.php vom Cache aus und trägt die Anmelde-Cookies ein. Cookies von Plugins (etwa für Sprache oder Einwilligung) ergänzen Sie selbst.
2. HTML-Cache: Sind Ihre Seiten für alle Besucher gleich, setzen Sie unter Cache > Einstellungen eine Cache-Dauer für HTML, zum Beispiel 5 Minuten.
3. Firewall: Anwendungsprofil WordPress wählen, Dateischutz-Profil WordPress unter Einstellungen.
4. Rate-Limit: Vorlage Anmeldung für /wp-login.php (10 Anfragen je 60 Sekunden). Wer xmlrpc.php nicht braucht, begrenzt auch diesen Pfad.
5. Captcha-Prüfung: Auslöser Rate-Limit - so landen echte Nutzer nach zu vielen Versuchen bei einer Prüfung statt bei einer Fehlerseite.

Onlineshop mit WooCommerce oder Shopware 6

1. Cache: Vorlage WooCommerce bzw. Shopware 6. Sie nimmt Warenkorb, Kasse und Kundenkonto vom Cache aus und trägt Sitzungs- und Warenkorb-Cookies ein. Prüfen Sie den Bestellvorgang danach einmal komplett.
2. Firewall: Profil WooCommerce bzw. Shopware. Zahlungsanbieter melden sich oft per Schnittstelle zurück - erscheinen deren Aufrufe im WAF-Protokoll, legen Sie eine Ausnahme nur für diesen Pfad an, zuerst als „Freigeben & loggen“.
3. Rate-Limit: Vorlage Kasse für /checkout (30 Anfragen je 60 Sekunden).
4. Länderfilter: Mit „Nur gewählte erlauben“ vorsichtig sein - Zahlungsdienste und Suchmaschinen rufen oft aus anderen Ländern ab.

Apps mit WebSockets, SignalR oder Blazor Server

ShieldCache reicht WebSocket-Verbindungen durch, Sie müssen dafür nichts einschalten. Für Anwendungen mit dauerhaften Verbindungen wie SignalR oder Blazor Server empfehlen sich diese Einstellungen:

1. Pfad ohne Cache: Tragen Sie den Pfad der Verbindung unter Cache > Regeln > Pfade ohne Cache ein, bei Blazor Server /_blazor, bei SignalR den Pfad Ihres Hubs, zum Beispiel /hubs/.
2. Kein Rate-Limit auf diesem Pfad: Verbindungsaufbau, Wiederverbindung und Rückfallverfahren erzeugen viele Anfragen auf denselben Pfad. Ein Rate-Limit würde echte Nutzer trennen.
3. Firewall-Ausnahme bei Bedarf: Erscheinen Aufrufe dieses Pfads im WAF-Protokoll, legen Sie eine Ausnahme mit „Beginnt mit“ für genau diesen Pfad an - zuerst als „Freigeben & loggen“.
4. Leerlauf und Keep-Alive: Bei eingeschaltetem Cache endet eine WebSocket-Verbindung nach 60 Sekunden ohne Datenverkehr in beide Richtungen. Gängige Bibliotheken senden vorher Pings; bei SignalR und Blazor Server ist das standardmäßig der Fall. Haben Sie das Keep-Alive-Intervall verlängert, halten Sie es unter 60 Sekunden.
5. Mehrere Ursprünge: Blazor Server hält den Zustand jeder Verbindung im Arbeitsspeicher eines Servers. Wählen Sie bei weiteren Ursprüngen die Verteilung Ausfall, damit alle Anfragen beim selben Server bleiben.
6. Besucher-IP: Liest Ihre Anwendung die IP aus einer festen Kopfzeile eines früheren Schutzdienstes, tragen Sie diese unter Ursprung > Erweitert als eigene Kopfzeile ein - siehe Ursprungsserver einrichten.

Agenturen und mehrere Websites

Jede Website ist eine eigene Seite im Projekt, mit eigenen Domains, Regeln und Statistiken. Mit Professional schützen Sie drei, mit Enterprise zehn Websites. Die Regeln einer Seite gelten nur für diese Seite - so können Sie für einen Shop strengere Rate-Limits setzen als für eine Visitenkarten-Website.