DDoS-Schutz mit Cloudflare: Einrichtung und Grenzen

Die meisten Seiten, die trotz Cloudflare unter einem DDoS zusammenbrechen, haben keinen Cloudflare-Fehler. Sie haben eine Origin-IP, die irgendwo öffentlich steht. Der Angreifer schickt seinen Traffic dann einfach an Cloudflare vorbei, direkt an den Server, und die schönste Edge-Konfiguration bleibt wirkungslos.

Was der DDoS-Schutz von Cloudflare im Free-Plan leistet

Cloudflare schreibt in seiner DDoS-Protection-Dokumentation, dass der Standard-Schutz für Layer 3 bis 7 in allen Plänen enthalten und nicht mengenbegrenzt ist. Das betrifft zwei verwaltete Regelsätze: einen für Netzwerk-Angriffe (Layer 3/4, etwa SYN- oder UDP-Floods) und einen für HTTP-Angriffe auf Layer 7. Beide laufen automatisch, ohne dass du etwas einschalten musst.

Was sich zwischen den Plänen unterscheidet, ist die Feinsteuerung:

Für eine kleine bis mittlere Website reicht der Free-Plan oft aus. Wo er eng wird: Du hast genau eine Rate-Limiting-Regel mit festem Zählzeitraum von 10 Sekunden, die nur auf IP-Basis zählt und nur nach Pfad filtern kann. Für die DDoS-Regelsätze erlaubt der Free-Plan einen Override. Eine Login-Seite schützt du damit gut, eine komplexe API mit verschiedenen Endpunkten eher nicht.

Cloudflare einrichten: Nameserver, Proxy, DNSSEC

Der Umzug selbst dauert eine halbe Stunde, wenn die Zone sauber ist. Cloudflare scannt deine bestehenden DNS-Einträge und schlägt sie zur Übernahme vor. Dieser Import ist nie vollständig. Vergleiche die Liste mit dem Export deiner alten Zone, vor allem TXT-Einträge für SPF, DKIM und Domain-Verifizierungen.

Dann trägst du beim Registrar die zwei Cloudflare-Nameserver ein. Läuft deine Domain bei einem Registrar mit DNSSEC, musst du die Reihenfolge einhalten: DNSSEC beim alten DNS-Anbieter abschalten, warten bis der DS-Eintrag aus der übergeordneten Zone verschwunden ist, Nameserver wechseln, in Cloudflare DNSSEC aktivieren und den neuen DS-Eintrag beim Registrar hinterlegen. Wer das überspringt, produziert SERVFAIL bei allen validierenden Resolvern.

Die orange Wolke entscheidet über den Schutz. Nur Einträge im Modus „Proxied“ laufen durch Cloudflare. Ein A-Eintrag für www auf „DNS only“ veröffentlicht deine Server-IP für jeden, der dig tippen kann.

Origin-IP schützen: der Teil, den fast alle vergessen

Cloudflare kann nur filtern, was bei Cloudflare ankommt. Wer deine echte Server-IP kennt, umgeht den Schutz komplett. Typische Lecks:

• MX- und Mail-Einträge, die auf denselben Server zeigen wie die Website
• Subdomains auf „DNS only“, etwa ftp., cpanel., staging. oder dev.
• DNS-Historie: Wer die Seite vor Cloudflare betrieben hat, findet die alte IP in öffentlichen DNS-Archiven
• Ausgehende Verbindungen: Webhooks, Pingbacks oder Mails, die der Server selbst verschickt, tragen seine IP im Header
• TLS-Zertifikate in Certificate-Transparency-Logs, wenn ein Hostname direkt auf den Server zeigt

Wenn die IP schon bekannt war, hilft nur ein Wechsel. Bei VPS-Anbietern ist das meist eine neue IP gegen kleinen Aufpreis oder ein neuer Server.

Danach sperrst du den Webserver für alles außer Cloudflare. Mit nftables oder ufw lässt du Port 80 und 443 nur aus den IP-Bereichen zu, die Cloudflare unter https://www.cloudflare.com/ips-v4 und https://www.cloudflare.com/ips-v6 veröffentlicht:

for net in $(curl -s https://www.cloudflare.com/ips-v4) $(curl -s https://www.cloudflare.com/ips-v6); do
  ufw allow proto tcp from "$net" to any port 80,443
done
ufw deny 80/tcp
ufw deny 443/tcp

Die Listen ändern sich selten, aber sie ändern sich. Ein monatlicher Cronjob, der sie neu lädt, erspart dir einen rätselhaften Ausfall.

Damit deine Logs und dein Rate Limiting wieder echte Besucher-IPs sehen, braucht nginx das Real-IP-Modul:

set_real_ip_from 173.245.48.0/20;
set_real_ip_from 103.21.244.0/22;
set_real_ip_from 2400:cb00::/32;
real_ip_header CF-Connecting-IP;

Die Datei legst du zum Beispiel als /etc/nginx/conf.d/cloudflare-realip.conf an und trägst dort alle Bereiche ein, das Beispiel ist gekürzt. Ohne diesen Schritt steht in jeder Logzeile eine Cloudflare-Adresse. Wie du an echten Daten erkennst, ob gerade ein Angriff läuft, beschreibt die Anleitung DDoS-Attacke erkennen.

Cloudflare Under Attack Mode: wann einschalten, wann nicht

Der Under Attack Mode setzt vor jede Seite eine JavaScript-Prüfung. Besucher sehen kurz „Checking your browser before accessing…“, die Entscheidung fällt laut Cloudflare innerhalb von fünf Sekunden. Wer durchkommt, wird bis zum Ablauf der Challenge Passage nicht erneut geprüft.

Einschalten kannst du ihn zonenweit über die Quick Actions in der Übersicht der Domain. Eleganter ist eine Configuration Rule, die ihn nur für bestimmte Pfade aktiviert, zum Beispiel /wp-login.php oder /suche.

Meine Einschätzung: Für Browser-Traffic ist er ein gutes Notfallwerkzeug, für alles andere ein Problem. API-Clients, Apps, Monitoring-Dienste, Webhooks von Zahlungsanbietern und RSS-Reader führen kein JavaScript aus und bleiben hängen. Cloudflare selbst nennt den Modus ein „last resort“ und weist darauf hin, dass er Analytics beeinträchtigt. Wenn du ihn zonenweit einschaltest, nimm /api/ und Webhook-Pfade per Regel aus.

Rate Limiting und WAF-Regeln bei Cloudflare

Die automatischen DDoS-Regeln erkennen große, auffällige Floods. Einen langsamen HTTP-Angriff mit ein paar hundert Requests pro Sekunde auf deine Suchfunktion sehen sie womöglich nicht als Angriff, dein Datenbankserver aber sehr wohl.

Dafür ist die eine Rate-Limiting-Regel im Free-Plan gedacht. Ein brauchbarer Startpunkt:

Die Zahl musst du an deine Seite anpassen. Wie du Schwellenwerte aus echten Logs ableitest, steht im Artikel zu Rate Limiting. Ergänzend lohnt eine kostenlose Custom Rule, die Länder oder ASNs mit Managed Challenge belegt, aus denen du sonst keinen Traffic bekommst. Das ist grob, kann aber in der ersten Stunde eines Angriffs viel Last wegnehmen.

Unter Security Events siehst du, welche Regel welche Requests blockiert hat. Schau dort nach jedem Vorfall rein. Häufig blockiert man nebenbei den eigenen Uptime-Monitor.

Wo Cloudflare nicht hilft

• Nicht-HTTP-Dienste: SSH, Mail, Game-Server und eigene UDP-Protokolle laufen ohne Spectrum (Bezahlprodukt) nicht durch den Proxy.
• Angriffe auf deine Nameserver, wenn du DNS woanders betreibst. Dazu mehr unter DNS-DDoS.
• Teure Requests unter der Erkennungsschwelle: Eine ungecachte Seite, die zwei Sekunden Rechenzeit braucht, legt deinen Server schon bei moderatem Traffic lahm. Hier hilft Caching mehr als jede Firewall.
• Bekannte Origin-IP, siehe oben.

Wer gerade mitten in einem Angriff steckt und noch keinen Schutz hat, findet die Reihenfolge der Sofortmaßnahmen unter DDoS-Attacke: was tun.

Nameserver-Wechsel ohne Ausfall vorbereiten

Der Nameserver-Wechsel ist der einzige Schritt, der deine Domain kurz instabil machen kann. Deshalb gehört er in eine ruhige Woche und nicht in die Nacht des Angriffs. Prüfe vorher, ob du beim Registrar Zugriff auf die Nameserver-Verwaltung hast, ob DNSSEC aktiv ist und ob ein Registrar-Lock Änderungen blockiert. Die alte Zone lässt du nach dem Wechsel mindestens zwei TTL-Zyklen weiterlaufen.

Wenn deine Domain noch bei einem Hoster liegt, der dir Nameserver-Änderungen schwer macht, lohnt der Blick auf die aktuelle Preisliste von betadomain: fester Jahrespreis, DNSSEC und freie Nameserver-Wahl, damit du im Ernstfall in Minuten statt Tagen umstellen kannst.

Schritt für Schritt

1. Domain zu Cloudflare hinzufügenIm Cloudflare-Dashboard die Domain anlegen, den Free-Plan wählen und die importierten DNS-Einträge mit der bestehenden Zone vergleichen.
2. Nameserver beim Registrar umstellenDie zwei von Cloudflare zugewiesenen Nameserver beim Registrar eintragen. Ein aktives DNSSEC vorher deaktivieren und später mit dem DS-Eintrag von Cloudflare neu einrichten.
3. Webseiten-Einträge auf Proxy stellenA-, AAAA- und CNAME-Einträge für Website und www auf die orange Wolke (Proxied) setzen. Mail-Einträge bleiben DNS only.
4. Origin-Server abschottenAuf dem Server Port 80 und 443 nur für die IP-Bereiche von cloudflare.com/ips öffnen und die echte Besucher-IP per CF-Connecting-IP auswerten.
5. Regeln für den Ernstfall vorbereitenEine Rate-Limiting-Regel für teure Pfade anlegen, Security Events prüfen und wissen, wo der Under Attack Mode in den Quick Actions sitzt.