Cloudflare ist aktiv, trotzdem geht die Seite down: die häufigsten Gründe

Dass Cloudflare aktiv ist, heißt nicht, dass Ihr Server geschützt ist: Er fällt trotzdem aus, wenn die Last an Cloudflare vorbeiläuft, wenn jede Anfrage eine Cache-Lücke trifft oder wenn der Angriff zu klein für die automatische Erkennung ist. Cloudflare schützt unbegrenzt vor DDoS auf den Schichten 3, 4 und 7¹, das bedeutet aber nicht, dass jede gültig aussehende Anfrage abgefangen wird: Die Dokumentation räumt ein, dass Angriffsverkehr als legitim eingestuft werden kann, wenn er „not sufficiently high to trigger mitigation actions" ist oder keine Regel passt². HTML wird zudem nicht standardmäßig gecacht³, jede Seitenansicht kann also beim Origin landen. Prüfen Sie deshalb in dieser Reihenfolge: Kommt die Last über Cloudflare? Ist der Origin für alle anderen gesperrt? Trifft sie den Cache? Fehlt eine Regel für den teuren Pfad?

Ob Anfragen am Proxy vorbeikommen, entscheidet die Adresse, von der die TCP-Verbindung zu Ihrem Server aufgebaut wird, nicht der Header CF-Connecting-IP: Einen Header kann jeder Client, der den Origin direkt anspricht, selbst setzen. Außerdem ersetzt nginx $remote_addr durch die Besucheradresse, sobald das Modul realip mit set_real_ip_from und real_ip_header CF-Connecting-IP eingerichtet ist; dann sehen alle Zeilen aus, als kämen sie direkt. Protokollieren Sie deshalb beide Adressen und die Antwortzeit:

log_format diag '$time_iso8601 $remote_addr $realip_remote_addr '
                '$status $request_time "$request"';
access_log /var/log/nginx/diag.log diag;

$realip_remote_addr behält laut nginx-Dokumentation die ursprüngliche Verbindungsadresse⁴. Meldet nginx -t die Variable als unbekannt, ist das Modul nicht eingebaut; dann ist $remote_addr bereits die Verbindungsadresse. Die Verbindungsadresse steht also in der dritten Spalte, wenn das Modul eingebaut ist, sonst in der zweiten. Vergleichen Sie sie mit den veröffentlichten Cloudflare-Bereichen⁵. Ein Beispielskript:

for l in ips-v4 ips-v6; do curl -s https://www.cloudflare.com/$l; echo; done > cf-ranges.txt
python3 -I - <<'PY'
import ipaddress
netze = [ipaddress.ip_network(z.strip()) for z in open('cf-ranges.txt') if z.strip()]
gesamt = direkt = 0
for zeile in open('diag.log'):
    peer = ipaddress.ip_address(zeile.split()[2])   # Spalte 3; ohne realip-Modul: [1]
    gesamt += 1
    direkt += not any(peer in n for n in netze)
print(direkt, "von", gesamt, "Zeilen kamen nicht von Cloudflare-Adressen")
PY

Das Ergebnis des Skripts ist so zu lesen: Kommen die Verbindungen zu Ihrem Server aus Cloudflare-Bereichen, läuft die Last über den Proxy, und Cache und Regeln sind der richtige Ansatzpunkt. Kommen viele Verbindungen von anderen Adressen, sprechen diese Clients Ihren Server direkt an. Cloudflare formuliert das Risiko so: Wer die IP-Adresse des Origin-Servers kennt, kann Anfragen „directly, bypassing Cloudflare and all its protections" senden⁶. Wie die Adresse bekannt wird, ist oft banal, etwa durch einen DNS-Eintrag ohne Proxy-Status oder einen alten Eintrag; prüfen Sie Ihre DNS-Zone auf Einträge, die nicht über Cloudflare laufen. Einzelne Absenderadressen direkter Verbindungen zu sperren lohnt nicht, weil sie leicht wechseln. Sinnvoll ist, den Origin für alle Adressen außer Cloudflare zu schließen.

Der Origin sollte nur Anfragen von Cloudflare annehmen. Cloudflare rät, „Explicitly block all traffic that does not come from Cloudflare IP addresses" zu sperren, ergänzt um Adressen vertrauenswürdiger Partner⁷. Die offiziellen Listen liegen unter https://www.cloudflare.com/ips-v4 und https://www.cloudflare.com/ips-v6⁵. Tragen Sie diese Bereiche in die Firewall Ihres Hosters oder des Servers ein, nicht erst in der Webserver-Konfiguration; dort kostet jede abgewiesene Verbindung noch Arbeit. Die Listen ändern sich gelegentlich, automatisieren Sie den Abgleich.

Zusätzlich gibt es Authenticated Origin Pulls: Der Origin verlangt ein Client-Zertifikat, das nur Cloudflare vorlegt. Das gibt es laut Dokumentation in allen Tarifen⁶. Zwei Einschränkungen stehen in derselben Dokumentation: Bei SSL-Modus Off oder Flexible greift es nicht, und bei Hostnamen über Cloudflare Tunnel haben die AOP-Einstellungen „no effect", weil Tunnel nur ausgehend verbindet⁶. Mit Tunnel brauchen Sie keine offene Origin-Adresse mehr, die Sie sperren müssten.

Selbst wenn alles über Cloudflare läuft, rechnet Ihr Server mit, sobald eine Antwort nicht im Cache liegt. Bei einem Cache-Miss sendet Cloudflare einen „origin pull" an Ihren Webserver⁸. Cloudflare cacht nach Dateiendung, nicht nach MIME-Typ, und HTML sowie JSON standardmäßig gar nicht³. Für dynamische Seiten ist der Origin also der Normalfall, nicht die Ausnahme.

Der Cache-Schlüssel enthält standardmäßig alle Query-Parameter (include: "*"), verschiedene Query-Strings erzeugen daher getrennte Einträge und Fehlschläge⁹. Wer Suche oder Filter durchprobiert, trifft so bei jeder Anfrage den Origin. In einem von uns dokumentierten Fall, einer von IT4OWL selbst betriebenen Vergleichsplattform hinter Cloudflare, kamen auf 100 Filteranfragen rund 64 verschiedene URLs. Am 4. bis 6. Oktober traf 99,7 % der Datensätze (Stichprobe) eine URL, die höchstens zweimal vorkam; ein Cache hatte dort kaum etwas, das er hätte wiederverwenden können.

Ob eine Anfrage den Origin erreicht hat, steht im Antwort-Header CF-Cache-Status. Bei MISS war die Antwort cachefähig, lag aber nicht im Cache und kam vom Origin; bei DYNAMIC hat Cloudflare vorab entschieden, nicht zu cachen¹⁰. Prüfen Sie zwei Varianten derselben Seite:

curl -sI 'https://www.example.de/kategorie/?x=1' | grep -i cf-cache-status
curl -sI 'https://www.example.de/kategorie/?x=2' | grep -i cf-cache-status

Die HTTP-DDoS-Regeln sind immer aktiv und erkennen bekannte Angriffsmuster auf Schicht 7. Cloudflare beschreibt selbst, dass Angriffsverkehr „mistakenly classified as legitimate traffic and is not mitigated" werden kann, wenn er nicht hoch genug ist oder keine Regel passt². Als Gegenmittel nennt Cloudflare, eigene WAF-Regeln und Rate-Limiting-Regeln einzusetzen¹¹.

Dass die automatische Erkennung bei Layer-7-Last nichts meldet, ist kein Sonderfall. Im von uns dokumentierten Fall lag die stärkste Stunde des erfassten Zeitraums bei rund 74.400 Anfragen, im Schnitt etwa 21 pro Sekunde (Cloudflare-Schätzung), und die ausgelieferte Datenmenge nie über durchschnittlich 2,9 Mbit/s. Das ist wenig Volumen, und es reichte trotzdem für einen Ausfall von gut drei Stunden, weil jede Anfrage den Origin bis in die Datenbank beschäftigte. Cloudflares Standard-Bot-Challenges waren aktiv und bearbeiteten nur einen kleinen Teil des Verkehrs (einige tausend Anfragen pro Tag). Wie Sie eine erste Regel schreiben, steht in Cloudflare Rate Limiting Rules, die wirklich greifen.

Sperre des Origin, Cache-Prüfung und Regeln verkleinern die Angriffsfläche, sie machen den teuren Pfad aber nicht billig. Wenn jede Anfrage eine neue, gültige Kombination ist, hilft weder ein gesperrter Origin noch ein Cache. Im von uns dokumentierten Fall kamen am 6. Oktober rund 470.000 filterförmige Datensätze von rund 367.000 verschiedenen Quelladressen, im Schnitt 1,28 Anfragen pro Adresse; IP-basierte Regeln laufen dabei ins Leere. Eine schmale Edge-Regel hielt dort etwa die Hälfte der filterförmigen Datensätze ab (50,6 %, 5. Oktober 18:00 bis 6. Oktober 16:59 UTC), die andere Hälfte erreichte den Origin. Erst als der Webserver vor der Anwendung erkannte Anfragen mit einer vorgerenderten statischen Seite beantwortete, endeten die Fehler: In den folgenden rund 23 Stunden Angriff gab es einen Upstream-Fehler. Die Konsequenz lautet, die Anfrage am Origin billig zu machen, nicht nur sie zu erkennen.

Wenn Ihre Seite gerade ausfällt und Sie nicht sicher sind, welcher dieser Fälle zutrifft, grenzen wir das gemeinsam mit Ihnen ein.