- IT4OWL
- Wissen
Wissen
Hier stehen Artikel für alle, die eine Website betreiben und wissen wollen, warum sie unter Last zusammenbricht und was dagegen hilft. Jeder Artikel nennt seine Quellen und sagt, wo man erst messen muss.
- Cloudflare ist aktiv, trotzdem geht die Seite down: die häufigsten Gründe
Eine Seite hinter Cloudflare fällt bei Layer-7-Last meist aus, weil Anfragen den Server direkt erreichen, am Cache vorbeilaufen oder zu klein für die automatische Erkennung sind. Die Prüfung dauert eine Viertelstunde: Quelle der Anfragen im Origin-Log, Origin für fremde Adressen sperren, Cache-Status prüfen, Regeln ergänzen.
- Cloudflare Rate Limiting Rules, die wirklich greifen
Eine Cloudflare-Rate-Limiting-Regel greift nur, wenn sie den teuren Pfad trifft und ein Merkmal zählt, das der Angreifer nicht ständig wechselt. Im Free-Tarif sind das eine Regel, Zählung pro IP in 10 Sekunden und Abgleich nur nach Pfad; Query-String-Abgleich beginnt bei Pro.
- Cloudflare „I'm Under Attack“: was der Modus kann und was nicht
Der Under-Attack-Modus von Cloudflare schaltet jedem Besucher eine Prüfseite vor, die einen Browser mit JavaScript voraussetzt. Dadurch können API-Aufrufe, Webhooks und andere Nicht-Browser-Clients scheitern. Setzen Sie ihn deshalb nur während eines Angriffs ein und, wenn möglich, nur für die betroffenen Pfade; gegen Angriffe, die Cloudflare umgehen oder JavaScript ausführen, reicht er nicht.
- Nach dem Angriff: Beweise sichern und Anzeige erstatten
Nach einem Angriff auf Ihre Website kopieren Sie zuerst die Daten, die sich überschreiben: Server-Logs, Edge-Exporte und Screenshots mit Uhrzeit, dazu eine Zeitleiste in UTC und Prüfsummen. Angezeigt wird bei der Polizei, über die Onlinewache oder bei komplexen Sachverhalten direkt bei der Dienststelle oder der Zentralen Ansprechstelle Cybercrime (ZAC). Was Ihr Versicherer verlangt, steht in Ihrer Police. Das ist keine Rechtsberatung.
- HTML cachen und Notbetrieb: den Angriff in den Cache laufen lassen
Cloudflare cacht HTML nicht von selbst; eine Cache Rule mit „Eligible for cache“ und einer Edge-TTL macht gleichbleibende Seiten zu Treffern am Edge. Das hilft nur bei Seiten, die für alle Besucher gleich sind und nicht bei jeder Anfrage eine neue URL haben. Gegen Angriffe mit ständig neuen Query-Kombinationen braucht der Origin einen billigen Notpfad, der solche Anfragen ohne Anwendung und Datenbank beantwortet.
- Teure Endpunkte: warum Suche und Filter eine Anwendung schon bei kleiner Last lahmlegen
Suche und Filter können eine Anwendung schon bei kleiner Last lahmlegen, wenn jede Anfrage eine neue Kombination ist und serverseitig gerendert wird: Kein Cache greift, und die Arbeit jeder Anfrage landet in der Datenbank. In einem von uns dokumentierten Fall fiel die Anwendung in der stärksten Stunde des erfassten Zeitraums aus, bei im Schnitt rund 21 Anfragen pro Sekunde (Cloudflare-Schätzung). Der Artikel zeigt, wie Sie teure Pfade messen, begrenzen und in Next.js statisch ausliefern.
Wozu die Artikel gehören
Die Themen sind die Fragen, die uns in Notfällen begegnen:
- Cloudflare ist aktiv, trotzdem ist die Seite down
- teure Endpunkte: Filter, Suche und SSR als Ausfallgrund
- Cloudflare Rate Limiting Rules, die wirklich greifen
- der Under-Attack-Modus: was er kann und was nicht
- HTML cachen und Notbetrieb mit Cloudflare
- Beweise sichern und Anzeige erstatten
Die Liste der Artikel steht unter dieser Einleitung.