HTML cachen und Notbetrieb: den Angriff in den Cache laufen lassen

Cloudflare speichert HTML nicht von selbst: Es cacht nach Dateiendung, nicht nach MIME-Typ, und laut Dokumentation „does not cache HTML or JSON by default“.¹ Damit Ihre Startseite oder Ihre Artikel bei einem Ansturm vom Edge kommen statt aus PHP oder Node, legen Sie eine Cache Rule mit der Einstellung „Eligible for cache“ und einer Edge-TTL an.² Das funktioniert nur für Seiten, die für alle Besucher gleich aussehen. Login, Konto, Warenkorb und Kasse müssen draußen bleiben.³ Und es hilft nicht, wenn der Angriff aus ständig neuen URLs besteht; dann braucht der Origin einen eigenen, billigen Notpfad.

Cachen Sie nur, was jeder Besucher identisch sieht. Das sind meist Startseite, Kategorie-Übersichten ohne Personalisierung und redaktionelle Artikel. Cloudflare warnt beim Beispiel „Cache Everything“ ausdrücklich, dass Besucher bei zu breiter Konfiguration Informationen erhalten können, die nicht für sie bestimmt sind.⁴ Als Pfade, die Sie umgehen sollten, nennt die Dokumentation Routen wie /login, /account, /cart, /checkout und API-Pfade der Anwendung.³ Welche Ausnahmen Ihre Anwendung braucht, hängt von ihr ab. Prüfen Sie auch Seiten, die im Header den Warenkorb-Zähler oder einen Gruß mit Namen anzeigen: Rufen Sie sie angemeldet und mit gefülltem Warenkorb auf, bevor Sie sie freigeben.

Im Dashboard finden Sie die Regeln unter Cache, Cache Rules, Create rule.² Cache Rules gibt es in allen vier Tarifen, im Free-Tarif bis zu 10 Regeln (Pro 25, Business 50, Enterprise 300).⁵ Die Einstellung heißt „Cache eligibility: Eligible for cache“; für die Dauer wählen Sie bei Edge TTL „Ignore cache-control header and use this TTL“.² Eine Bedingung, die nur gleichbleibende Seiten ohne Query-String und ohne Sitzungs-Cookie trifft, sieht so aus:

(http.host eq "shop.example.de"
 and http.request.uri.query eq ""
 and (http.request.uri.path eq "/" or starts_with(http.request.uri.path, "/magazin/"))
 and not http.cookie contains "session")

Ersetzen Sie Host, Pfade und den Cookie-Namen durch Ihre eigenen; den Namen Ihres Sitzungs-Cookies lesen Sie in den Entwicklerwerkzeugen des Browsers ab. Die Bedingung baut die Ausnahmen in die Regel ein, statt sich auf die Reihenfolge mehrerer Regeln zu verlassen.

Achten Sie auf die TTL. Cloudflares Tabelle zum Edge Cache TTL nennt ein Minimum je nach Tarif: Free 2 Stunden, Pro 1 Stunde, Business und Enterprise 1 Sekunde.⁶ Für einen Shop mit wechselnden Preisen oder Beständen sind zwei Stunden alte Seiten womöglich zu lang. Prüfen Sie im Dashboard, welchen Wert Ihre Regel annimmt, bevor Sie sich auf ein Cachen im Sekundenbereich verlassen.

Kontrollieren Sie das Ergebnis am Header cf-cache-status:

curl -sI https://shop.example.de/ | grep -i cf-cache-status

Beim ersten Abruf steht dort MISS, beim zweiten HIT; DYNAMIC bedeutet, Cloudflare hält die Anfrage für nicht cachefähig und schickt sie direkt zum Origin.⁷

Standardmäßig enthält der Cache-Schlüssel alle Query-Parameter. Jede neue Kombination ist deshalb ein eigener Eintrag und beim ersten Abruf ein Cache-Miss.⁸ In einem von uns dokumentierten Fall auf einer selbst betriebenen Vergleichsplattform bestand der Angriff aus Filter-Kombinationen: Auf 100 Filteranfragen kamen rund 64 verschiedene URLs (858.982 verschiedene URLs bei 1.338.251 ausgewerteten Datensätzen, einer Stichprobe der Cloudflare-Daten). Praktisch jede Kombination wurde höchstens zweimal abgerufen: Für den 4. bis 6. Oktober traf das auf 99,7 % der Datensätze zu. Für solche Anfragen findet ein Edge-Cache kaum Treffer: Selbst eine Kombination, die zweimal vorkommt, kann höchstens bei der zweiten Anfrage aus dem Cache kommen. Dabei war eine einzelne Filteranfrage kaum teurer als eine normale Seite (Median 678 ms gegenüber 623 ms unter Normallast). Teuer war, dass sehr viele Anfragen neue Kombinationen waren.

Wenn der Cache nicht greift, muss die Anfrage am Origin billig werden, bevor die Anwendung sie sieht. Das beendete im von uns dokumentierten Fall die Fehler der zweiten Welle: Der Webserver vor der Anwendung ordnete Anfragen mit der Angriffsform ein und lieferte eine vorgerenderte statische Seite, ohne Anwendung und ohne Datenbank. Die Antwort kam im Median nach 265 ms, gegenüber 678 ms für eine von der Anwendung gerenderte Filterseite. In den folgenden rund 23 Stunden Angriff zählte der Origin 295.587 statische Antworten und einen einzigen Fehler.

Die Regel, mit der wir im dokumentierten Fall Angriffsanfragen am Origin statisch beantworteten, war deutlich enger als jede Regel, die sich ohne Messdaten schreiben lässt; ihre Merkmale veröffentlichen wir nicht, damit sie nicht nachgebaut werden kann. Eine grobe Notfallvariante für nginx ersetzt jede Anfrage mit Query-String auf einer teuren Route durch eine Notseite, hier für die Route /produkte. Sie trifft auch echte Besucher, die filtern:

location = /produkte {
    if ($args != "") {
        rewrite ^ /notbetrieb.html? last;
    }
    proxy_pass http://app;
}

location = /notbetrieb.html {
    internal;
    root /var/www/fallback;
}

In der nginx-Notfallvariante oben enthält die Variable $args die Argumente der Anfragezeile,⁹ und rewrite … last startet die Suche nach einer neuen passenden Location;¹⁰ internal markiert, dass die Notseite nur über eine solche interne Umleitung erreichbar ist, nicht direkt von außen.⁹ Das abschließende ? in der Rewrite-Zeile verwirft die ursprüngliche Query, die sonst angehängt bliebe.¹⁰ Die Datei /var/www/fallback/notbetrieb.html muss existieren und für nginx lesbar sein. Prüfen Sie mit nginx -t, bevor Sie neu laden. Weil die Notseite auch echte Nutzer mit Query-String trifft, muss sie sagen, was passiert ist, und auf nützliche Seiten ohne Filter verlinken.

Always Online ist kein Notbetrieb für Ihre Anwendung. Es springt laut Cloudflare nur ein, wenn Cloudflare Ihren Origin nicht erreichen kann, nicht wenn der Origin erreichbar ist und Fehler zurückgibt, und es kann keine dynamischen Inhalte ausliefern.¹¹ Die Crawl-Intervalle betragen 30, 15, 5 und 5 Tage (Free, Pro, Business, Enterprise).¹¹ Außerdem ignoriert Always Online Bypass-Cache-Regeln und liefert seine eigenen gecachten Assets.¹² Cloudflare nennt zudem stale-while-revalidate als Weg, abgelaufene Inhalte während der Aktualisierung auszuliefern; das setzt voraus, dass Ihr Origin die Direktive sendet.¹³

Edge-Cache und Notseite senken die Kosten einer Anfrage, sie beheben nicht die Ursache. Stützt sich der Angriff auf Pfade, die nie gecacht werden dürfen (Login, Suche mit Sitzung, Kasse), braucht es Limits in der Anwendung, Sitzungs-Prüfung und Budgets. Wer Ihren Origin direkt anspricht, umgeht den Edge samt Cache. Und eine Notseite, die zu viele echte Nutzer trifft, ist selbst ein Ausfall; messen Sie, wie viele reguläre Anfragen sie bekommt, und lassen Sie die Regel nach dem Angriff wieder auslaufen.

Wenn Sie den Notpfad nicht unter Zeitdruck selbst bauen wollen, können wir das mit Ihnen tun.