Cloudflare Rate Limiting: CC-Angriffe in 5 Minuten abwehren – auch im Free-Tier

3 Uhr nachts. Server-Alarm – CPU bei 100 %, Site offline. Logs: Dutzende IPs fluten APIs mit hunderten Anfragen pro Sekunde – ein CC-Angriff.

IPs manuell sperren? Sofort kommen neue dazu. Zwei Stunden später fällt mir Cloudflare Rate Limiting ein – im Free-Tier verfügbar. Eine Regel: max. 20 Anfragen/Minute pro IP, danach 10 Minuten Sperre. Fünf Minuten Konfiguration, Angriff abgewehrt.

CC-Schutz ist kein Hexenwerk – entscheidend ist die Vorbereitung. Dieser Artikel erklärt Cloudflare Rate Limiting: Free-Tier, Schwellenwerte, Szenarien und typische Fallstricke.

Was ist ein CC-Angriff? Warum hilft Rate Limiting?

CC steht für Challenge Collapsar – simuliert viele normale Besucher und erschöpft Serverressourcen.

Ist das nicht DDoS? Nicht ganz. Klassisches DDoS schickt offensichtliche Junk-Pakete – Cloudflare-DDoS-Schutz fängt das ab. CC sendet normale HTTP-Anfragen wie echte Nutzer – schwerer zu erkennen.

Normale Besucher: etwa 5–10 Anfragen pro Minute. CC: eine IP kann in 30 Sekunden über 1.000 Anfragen schicken – oft verteilt über viele Maschinen oder Proxy-IPs.

Rate Limiting nutzt genau dieses Muster. Es überwacht die Anfragefrequenz pro IP (oder Session, API-Key) und reagiert bei Überschreitung – CAPTCHA, Challenge oder temporäre Sperre.

Praxisbeispiel: Angreifer 200–300 Anfragen/Sekunde, Schwellenwert 20/Minute – Limit greift in Sekunde 1–2. Normale Nutzer bleiben unberührt.

Laut Aliyun-WAF-Best-Practices: typische CC-Botnetze >1.000 Anfragen in 30 Sekunden pro Maschine; normale Nutzer meist <10 pro Minute.

Der Unterschied ist deutlich.

Sorge vor False Positives bei schnellen API-Nutzern? Berechtigt – deshalb sind Schwellenwerte entscheidend (siehe unten).

Free-Tier: Cloudflare Rate Limiting im Überblick

Viele halten Rate Limiting für kostenpflichtig – seit Oktober 2022 ist es für alle Pläne kostenlos (Free, Pro, Business).

Vor 2022: 5 USD pro Million Anfragen – bei hohem Traffic spürbar. Heute: im offiziellen Blog bestätigt, in allen Plänen enthalten. Free: 1 Regel, Pro und Business: mehr.

Reicht 1 Regel? Für kleinere Sites oft ja. Setzen Sie die Regel dort ein, wo Angriffe am wahrscheinlichsten sind – Login, Registrierung, zentrale API.

Eigene kleine Projekte: 1 Regel für Login, fast ein Jahr ohne Probleme. Gelegentliche Scan-Angriffe werden abgefangen.

🔥 Verschwende keine Monate für ungenutzte Produkte! Teste deine SaaS-Nutzenversprechen mit Adsterra bei kleinem Budget →

Jetzt testen →Anzeige

Mehrere kritische Endpunkte? Pro (ca. 20 USD/Monat, 10 Regeln) oder Business (ca. 200 USD/Monat, 15 Regeln). Für persönliche Sites und KMU reicht Free meist.

Hinweis: Basis-DDoS-Schutz ist unbegrenzt in allen Plänen. Rate Limiting zielt auf verdecktere CC-Angriffe und API-Missbrauch.

Free vs. Paid:

• Regelanzahl: Free 1, Pro 10, Business 15
• Erweiterte Merkmale: Bot Score, JA3-Fingerprint (Paid)
• Reaktionszeit: Paid schneller bei Spitzenlast

Tipp: Mit Free starten, wichtigsten Endpunkt schützen, bei Bedarf upgraden.

Schwellenwerte: Empfehlungen nach Szenario

Beim ersten Mal starrt man auf „Requests per period”: 10 oder 100? Zu niedrig → False Positives, zu hoch → schwacher Schutz.

Nach Cloudflare-Doku, Best Practices und eigenen Tests – Referenzwerte, an Ihren Traffic anpassen.

Login/Registrierung (häufigstes Ziel)

Login-Endpunkte sind Angriffsziel Nr. 1 – Brute-Force und Credential Stuffing. Normale Nutzer: selten, Angreifer: massiv.

Empfohlen (drei Stufen, Cloudflare):

• Stufe 1: 4/Minute → JavaScript Challenge
• Stufe 2: 10/10 Minuten → CAPTCHA
• Stufe 3: 20/Stunde → 1 Tag Sperre

Free (1 Regel) – vereinfacht:

• Einzelregel: 20/60 Sekunden → 10 Minuten Sperre

Begründung: Logs zeigen <5 Login-Versuche/Minute bei echten Nutzern (auch mit falschem Passwort); Skripte: hunderte. Strenger Modus: 10/60s → 1 Stunde Sperre.

API (nach Geschäftslogik)

Query-APIs:

• Empfohlen: 30/10 Sekunden → JavaScript Challenge (~3/s – für normale Frontends ausreichend)

Rechenintensive APIs (Bildverarbeitung, Analyse):

• Empfohlen: 10/60 Sekunden → Drosselung

Öffentliche APIs:

• Nach Billing und Kapazität – z. B. 100/Stunde kostenlos, gestaffelt nach Tarif

Google Cloud Armor als Referenz: 2.000/20 Minuten, danach 20 % Drosselung – progressives Modell.

Normale Webseiten (Anti-Scraping)

• Standardseiten: 100/30 Sekunden → JavaScript Challenge
• Suche/Download: 50/60 Sekunden → CAPTCHA

Warum so hoch? Eine Seite erzeugt durch CSS, JS und Bilder viele Requests – schnelles Klicken bleibt unter 100/30s. Crawler bei dieser Rate fallen auf.

Wichtig: Keine strenge Regel auf der Startseite – Google/Bing-Crawler und SEO leiden sonst.

Praxisreferenz

Aliyun WAF (kleine Sites, präventiv): >1.000 Anfragen/30 Sekunden pro IP → 10 Stunden Sperre – lockerer Fallback.

Tipp: Zuerst Managed Challenge statt Block – bei zu niedrigem Schwellenwert können echte Nutzer die Challenge bestehen. Nach Beobachtung auf Block wechseln.

5-Minuten-Tutorial: Schritt für Schritt

Schritt 1: Rate-Limiting-Seite

Cloudflare-Dashboard → Domain → Security → WAF → Rate limiting rules

„Create rule” – Free zeigt „0/1 rules”.

Schritt 2: Grunddaten

Rule name: z. B. „Login-Rate-Limit” oder „API-Protection”.

Schritt 3: Match-Bedingung (Expression)

Login schützen:

Vultr - Hochleistungs-NVMe-Cloud-Server mit 32 Standorten weltweit, Docker per Klick

Preise ansehen →Anzeige

Field: URI Path
Operator: equals
Value: /api/login

Gesamte API:

Field: URI Path
Operator: contains
Value: /api/

Optional User-Agent ausschließen (Monitoring-Bot):

Field: User Agent
Operator: does not equal
Value: MyMonitorBot

Schritt 4: Rate-Limit-Parameter (Kern)

Characteristics:

• IP Address: nach IP zählen (empfohlen für CC)
• Session: Cookie-Session-ID (eingeloggte Nutzer)
• Headers: z. B. API-Key

Für Login: IP Address.

Period: meist 60 Sekunden – zu kurz (10s) → False Positives, zu lang → schwächerer Schutz.

Requests per period: Login 20, API 30.

Duration: meist 10 Minuten – Balance zwischen Wiederholungsangriff und False Positives.

Beispiel Login:

• Characteristics: IP Address
• Period: 60 seconds
• Requests: 20
• Duration: 10 minutes

→ Mehr als 20 Login-Anfragen/Minute pro IP → 10 Minuten Sperre.

Schritt 5: Aktion (Action)

Managed Challenge (empfohlen): Cloudflare prüft Mensch vs. Bot – beste UX bei False Positives.

Block: 403 – stärkster Schutz, schwerer rückgängig zu machen.

Legacy CAPTCHA: klassisches Captcha.

JS Challenge: JavaScript-Test – gut gegen Crawler, für Nutzer fast unsichtbar.

Start mit Managed Challenge, nach Testphase optional Block.

Schritt 6: Deploy

Unten Deploy – sofort aktiv.

Schritt 7: Verifizieren

for i in {1..30}; do curl https://yourdomain.com/api/login; done

Anfragen 1–20 normal, ab 21: 429 oder Challenge. Security → Events für Logs.

Vollständiges Beispiel

Login /api/auth/login:

• Rule name: Login-Rate-Limit
• URI Path equals /api/auth/login
• IP Address, 60s, 20 Requests, 10 Min Duration
• Action: Managed Challenge

Deploy – fertig in 5 Minuten.

Fortgeschrittene Techniken und typische Fallen

Falle 1: SEO-Crawler

Keine zu strenge Regel site-weit oder auf der Startseite!

Beispiel: 50/30s site-weit → nach einer Woche GSC-Crawl-Fehler – Google lädt parallel CSS, JS, Bilder.

Railway - Moderne Deployment-Plattform, ohne DevOps-Aufwand, in Minuten live

Jetzt starten →Anzeige

Lösung: Nur Login/API streng, Content locker oder ohne Limit, Startseite ohne harte Regel. Bot Management (Paid) für differenzierten Crawler-Schutz.

Falle 2: Bypass über Origin-IP

Rate Limiting konfiguriert – trotzdem CC? Angreifer trifft Origin direkt.

Cloudflare ist Reverse Proxy. Kennt man die Origin-IP, umgeht man den Schutz.

Lösungen:

1. Firewall nur Cloudflare-IPs (80/443):

# Nur Cloudflare-IPs erlauben
for i in `curl https://www.cloudflare.com/ips-v4`; do
  ufw allow from $i to any port 443 proto tcp
  ufw allow from $i to any port 80 proto tcp
done

2. Origin-IP rotieren – nicht in DNS exponieren
3. Authenticated Origin Pulls – Client-Zertifikat von Cloudflare

Falle 3: Kein Monitoring

Regeln brauchen Pflege:

• Schwellen zu niedrig → Nutzerbeschwerden
• Traffic wächst → Schwellen veralten
• Angriffsmuster ändern sich

Monatlich Security Analytics: Blockierungen, False Positives, 429-Rate. Wenig 429 → senken, viele 429 → anheben.

Technik 1: Verteilte Angriffe

Viele Proxy-IPs, je IP niedrige Frequenz – reines IP-Limit reicht nicht.

1. Session/Cookie-Zählung – Characteristics: Cookie + Session-Name
2. User-Agent-Filter – Python, curl etc. in Expression
3. Bot Management (Paid) – Regel nur für Bot Score < 30

Technik 2: Progressive Strategie (Paid)

Stufe 1 (locker): 30/Minute → JS Challenge
Stufe 2 (mittel): 50/10 Min → Managed Challenge
Stufe 3 (streng): 100/Stunde → Block 24h

Technik 3: Geo-Filter

Hauptgeschäft in China – strengere Regeln für Auslandstraffic:

(ip.geoip.country ne "CN") and (http.request.uri.path eq "/api/login")

VPN-Nutzer beachten – Challenge statt Block.

Abschluss

Kernbotschaft: Rate Limiting ist einfach – entscheidend ist, es vor dem Angriff einzurichten.

Viele reagieren erst nach dem Alarm um 3 Uhr nachts. Fünf Minuten Vorbereitung sparen Stunden Stress.

Empfehlungen:

1. Jetzt eine Regel anlegen – auch ohne bisherigen Angriff
2. Mit Login starten – bei 1 Free-Regel der wichtigste Endpunkt
3. Testen – curl/Browser, dann Security Events prüfen
4. Monatlich anpassen – Security Analytics

Origin-Firewall: nur Cloudflare-IPs – sonst umgeht der Angreifer alles.

Bei Fragen: Cloudflare-Dokumentation und Community. Viel Erfolg beim Schutz vor CC-Angriffen.