Cloudflare-Firewall-Regeln für Einsteiger: 5 kostenlose Regeln filtern 80 % bösartigen Traffic (mit Vorlagen)

Einleitung

Server-Logs voller Scan-Anfragen – täglich tausende bösartige Zugriffe. Cloudflare Free im Einsatz, aber keine einzige Firewall-Regel konfiguriert – praktisch ungeschützt. Tutorials aus dem Netz kopiert, Regeln greifen nicht – Priorität war verkehrt.

Bei Ausdrücken wie (ip.src.country eq "CN") wird es unübersichtlich. Nach ein paar Tagen Experimentieren zeigt sich: 5 Regeln im Free-Tier reichen wirklich. Sinnvoll konfiguriert filtern sie über 80 % bösartiger Anfragen ohne False Positives. Dieser Artikel zeigt die 5 Regeln: Prinzip, Priorität – in 30 Minuten einsatzbereit.

Kapitel 1: Warum 5 Regeln im Free-Tier ausreichen

Viele sehen „nur 5 benutzerdefinierte Regeln” im Cloudflare Free-Tier und denken: „Das reicht nie.” Pro hat 20 – Upgrade nötig?

Erst die Fakten.

Der Großteil bösartigen Traffics stammt aus wenigen Quellen: Scanner aus Rechenzentren, IPs mit hohem Threat Score, anomale User-Agents. Laut Cloudflare-Community filtern 5 sinnvoll konfigurierte Regeln über 80 % der Angriffe.

Das klassische 80/20-Prinzip.

Neben 5 benutzerdefinierten Regeln liefert die Free-Version das Cloudflare Free Managed Ruleset. Standardmäßig aktiv, Schutz vor kritischen Schwachstellen wie Shellshock und Log4J. Managed Ruleset plus 5 benutzerdefinierte Regeln – für kleinere und mittlere Websites ausreichend.

Die 15 zusätzlichen Pro-Regeln dienen eher der Feinsteuerung: mehrere Subdomains, unterschiedliche API-Strategien. Ist Ihre Site nicht so komplex, decken 5 Regeln den Kernschutz ab.

Voraussetzung: Die 5 Regeln richtig einsetzen. Falsche Priorität – dann helfen auch 10 Regeln nicht.

Kapitel 2: Das Geheimnis der Regelpriorität

Hier lauern die meisten Fallen. Beim ersten Setup stand bei mir die Reihenfolge falsch – keine Regel wirkte.

Cloudflare-Firewall-Regeln werden von oben nach unten ausgeführt – wie eine Fließbandprüfung. Regel 1, dann Regel 2, usw. Bei Treffer wird die Aktion ausgeführt (Allow, Block, Challenge usw.) und gestoppt (Allow ausgenommen – weitere Regeln werden geprüft).

Analogie: Sicherheitskontrolle am Eingang:

1. Bekannte Gesichter: Familie – sofort durch (Whitelist)
2. Fremde: Ausweis prüfen (Challenge)
3. Verdächtige: Abweisen (Block)

Ist die Reihenfolge verkehrt – erst Block, dann Prüfung – kommen normale Besucher nicht mehr rein.

Typischer Fehler: Länder-Sperre vor der Whitelist. UptimeRobot als Monitoring, Regel 1 lautet „Alle Nicht-CN-IPs blockieren” – Monitoring fällt aus, Ausfall unbemerkt.

Richtig: Whitelist immer an erster Stelle. Zuerst bekannte gute Quellen (Suchmaschinen-Crawler, Monitoring, eigene IPs), dann schrittweise verschärfen.

Wichtig: Aktionen haben Priorität. Bei gleicher Regelpriorität gilt:

• Allow (Erlauben) > Skip (Überspringen) > Challenge (Herausforderung) > Block (Blockieren) > Log (Protokollieren)

Trifft eine Anfrage Allow- und Block-Regeln zu, gilt Allow. Deshalb Whitelist ganz oben – höchste Priorität, keine Fehlblockierung.

Kapitel 3: Die 5 Goldregeln

Direkt zur Sache. Die 5 Regeln nach Priorität – zum Kopieren und Anpassen.

Regel 1 (höchste Priorität): Whitelist – Verbündete schützen

Zweck: Bekannten normalen Traffic durchlassen, False Positives vermeiden.

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

Jetzt testen →Anzeige

Anwendungsfälle:

• Suchmaschinen-Crawler (Google, Bing, Baidu u. a.)
• Monitoring-Dienste (UptimeRobot, StatusCake u. a.)
• Büro- und Heim-IP

Regelausdruck:

(cf.client.bot) or (ip.src in {1.2.3.4 5.6.7.8})

Aktion: Allow

Hinweise:

• cf.client.bot – von Cloudflare verifizierte legitime Crawler, u. a. Google und Bing
• {1.2.3.4 5.6.7.8} durch eigene IPs ersetzen, mehrere IPs mit Leerzeichen trennen
• Ohne IP-Whitelist vereinfachen: (cf.client.bot)

Regel 2: Rechenzentrum-ASN-Challenge – Traffic aus Rechenzentren

Zweck: Traffic aus Rechenzentren per CAPTCHA/Herausforderung prüfen.

Anwendungsfälle:

Scanner und Crawler-Tools laufen oft auf VPS und Cloud-Servern; normale Nutzer kommen selten direkt aus Rechenzentrum-IPs. Eine Challenge – Bots geben auf.

Regelausdruck:

(ip.geoip.asnum in {13335 15169 16509 14618 45090})

Aktion: Managed Challenge

ASN-Referenz (gängige Rechenzentren):

ASN-Liste je nach Site anpassen. Nicht direkt Block – VPN-Nutzer könnten betroffen sein. Managed Challenge reicht: Menschen bestehen die Prüfung, Bots bleiben hängen.

Regel 3: Threat Score + Risiko-IP-Filter

Zweck: Hochriskante IPs anhand von Cloudflare-Threat-Intelligence blockieren.

Anwendungsfälle:

Cloudflare vergibt pro IP einen Score (0–100), je höher, desto riskanter. Über 10: mögliche Spammer; über 40: eher böswillig; über 50: direkt blockieren.

Regelausdruck:

(cf.threat_score gt 10)

Aktion: Challenge (Score 10–40) oder Block (Score über 50)

Empfohlene Schwellen:

Optimierung:

Segmentiert mit zwei Regeln:

• Regel 3A: (cf.threat_score gt 10 and cf.threat_score le 50) → Challenge
• Regel 3B: (cf.threat_score gt 50) → Block

Das verbraucht 2 Regel-Slots. Bei knappen Slots: einheitlich gt 10 + Challenge, eine Woche beobachten, dann anpassen.

Regel 4: Anomale User-Agent-Blockierung

Zweck: Leere UA, bösartige Crawler und Automatisierungstools filtern.

Anwendungsfälle:

Normale Browser senden einen User-Agent (z. B. „Chrome”). Leerer UA oder python-requests, curl – typisch für Skripte, nicht für Menschen.

Regelausdruck:

(http.user_agent eq "") or (http.user_agent contains "python-requests") or (http.user_agent contains "curl") or (http.user_agent contains "sqlmap") or (http.user_agent contains "nikto") or (http.user_agent contains "MJ12bot")

Aktion: Block

Häufige bösartige UAs:

• python-requests – Python-Skripte
• curl – Kommandozeilen-Tool
• sqlmap – SQL-Injection-Tool
• nikto – Schwachstellen-Scanner
• MJ12bot – Majestic-SEO-Crawler (ignoriert robots.txt)
• masscan – Port-Scanner
• ZmEu – Scanner

Hinweise:

• Nicht Mozilla, Chrome, Safari blockieren
• Zuerst Log-Aktion eine Woche, anomale UAs in Logs identifizieren, dann ergänzen
• Bei eigener API ggf. eigenen API-Client-UA ausschließen

Regel 5: Schutz sensibler Pfade

Zweck: Admin-Login, sensible APIs und Konfigurationsdateien schützen.

Anwendungsfälle:

KiloClaw - Managed OpenClaw für Unternehmen: AI-Agent-Orchestrierung und smartes Modell-Routing

Jetzt starten →Anzeige

WordPress /wp-admin, /wp-login.php – beliebte Scan-Ziele. .env, .git – bei Leak kritisch.

Regelausdruck:

(http.request.uri.path contains "/wp-login" or http.request.uri.path contains "/wp-admin" or http.request.uri.path contains "/.env" or http.request.uri.path contains "/.git") and not (ip.src in {1.2.3.4})

Aktion: Block oder Challenge

Hinweise:

• {1.2.3.4} durch eigene IP ersetzen – Admin-Zugriff unbeeinträchtigt
• Ohne IP-Whitelist: and not (ip.src in {1.2.3.4}) entfernen, stattdessen Challenge

Weitere sensible Pfade:

• /xmlrpc.php (WordPress XML-RPC, oft für DDoS missbraucht)
• /phpMyAdmin (Datenbank-Admin)
• /config.php
• /.sql (Datenbank-Backup)

Je nach Tech-Stack eigene Pfade ergänzen.

Vollständiger Regelablauf

Nach Konfiguration aller 5 Regeln:

Anfrage
   ↓
Regel 1: Legitimer Crawler oder Whitelist-IP? → Ja → Durchlassen
   ↓ Nein
Regel 2: Rechenzentrum-ASN? → Ja → Challenge → Bestanden/Blockiert
   ↓ Nein
Regel 3: Threat Score über 10? → Ja → Challenge/Block
   ↓ Nein
Regel 4: Anomaler User-Agent? → Ja → Block
   ↓ Nein
Regel 5: Sensibler Pfad? → Ja → Block/Challenge
   ↓ Nein
Durchlassen zum Origin

Dieser Ablauf filtert den Großteil automatisierter Angriffe ohne normale Nutzer zu treffen.

Kapitel 4: Praktische Konfiguration

Regeln allein reichen nicht – jetzt konfigurieren.

Schritt 1: Firewall-Konfiguration öffnen

Cloudflare Dashboard → Domain wählen → links „Security” → „WAF” → Tab „Custom rules”.

Schritt 2: Erste Regel (Whitelist) erstellen

1. Oben rechts „Create rule”

2. Regelname: z. B. Whitelist-Legitime-Crawler-und-Monitoring

3. Expression Editor: Standard ist Expression Builder. Für Code: „Edit expression”

4. Ausdruck einfügen:

   (cf.client.bot) or (ip.src in {1.2.3.4})

   IP anpassen

5. Aktion: „Allow”

6. „Deploy”

Schritt 3: Regeln 2–5 erstellen

Gleiches Vorgehen für Regeln 2–5. Name, Ausdruck und Aktion siehe Kapitel 3.

Schritt 4: Reihenfolge anpassen

Nach Erstellung aller 5 Regeln: Sechs-Punkte-Icon links ziehen, Reihenfolge sicherstellen:

• Whitelist oben (Priorität 1)
• ASN-Challenge zweitens
• Threat Score drittens
• Anomale UA viertens
• Sensible Pfade fünftens

Schritt 5: Regeln testen

Nach der Konfiguration testen:

1. Whitelist: Eigene IP – Site normal erreichbar

2. UA-Blockierung: Terminal:

   curl -A "sqlmap" https://ihre-domain.com

   Blockierseite erwartet

3. Blockier-Logs: Cloudflare Dashboard → Security → Events

Regeln greifen nicht – prüfen:

• Syntaxfehler in der Expression
• Prioritätsreihenfolge
• Richtige Aktion gewählt

Kapitel 5: Fortgeschrittene Tipps und FAQ

Mit den 5 Basisregeln sind die meisten Angriffe abgedeckt. Einige Details lohnen sich.

Wirksamkeit prüfen

Cloudflare liefert CSR (Challenge Solve Rate – Herausforderungs-Lösungsrate).

Formel: CSR = erfolgreich gelöste Challenges / ausgegebene Challenges gesamt

Je niedriger, desto besser. CSR nahe 0 % – fast nur Bots, keine bestandene Validierung. Dann Challenge auf Block umstellen, Serverressourcen sparen.

CSR hoch (z. B. über 50 %) – mögliche False Positives, Bedingungen anpassen.

CSR ansehen: Security → Events → Regel anklicken → Detailstatistiken.

False Positives vermeiden

Das Wichtigste:

Alibaba Cloud - Top-Wahl für Entwickler, exklusiv 15 % Rabatt auf Lighthouse-Server

15 % Rabatt sichern →Anzeige

1. Neue Regeln 7 Tage im Log-Modus
   • Aktion „Log” (nur protokollieren)
   • Nach einer Woche Security Events prüfen, dann Challenge oder Block
2. Eigene IPs und Monitoring whitelisten
   • Eigene IPs in Regel 1
   • UptimeRobot-IP-Bereiche laut Herstellerangaben
3. Nicht sofort Block
   • Erst Challenge, CSR beobachten
   • CSR nahe 0 %, dann Block erwägen
4. Ungewöhnlichen Traffic-Rückgang beachten
   • Starker Rückgang normalen Traffics nach Regeländerung
   • Security Events auf Fehlblockierungen prüfen

Plötzliche Angriffe

Bei CC- oder DDoS-Angriffen mit Traffic-Spitze temporär Under Attack Mode (umgangssprachlich „5-Sekunden-Schild”):

Security → Settings → Security Level → „I’m Under Attack”

5-Sekunden-Ladebildschirm mit JS-Validierung. Bots scheitern, echte Nutzer warten 5 Sekunden. Nach dem Angriff zurück auf Medium oder Low.

Regeln temporär verschärfen:

• Challenge auf Block
• Geo-Sperre bei Angriffen aus einem Land

5 Regeln reichen nicht

Manchmal knapp – Optionen:

1. Mit or gleichartige Regeln zusammenfassen
   • Regel 4 nutzt or für mehrere anomale UAs
   • Eine Regel pro Szenario
2. IP-Listen zentral verwalten
   • Cloudflare-IP-Listen (tausende Einträge)
   • In Regeln: ip.src in $blacklist
   • Eine Regel, viele IPs, kein Regel-Slot verbraucht
3. Pro-Plan erwägen
   • 20 Regeln, mehr Funktionen
   • Lohnt sich bei monetarisierten Sites

Häufige Fragen

F: Regeln wirken nicht?

A: Prüfen:

• Syntaxfehler (Cloudflare zeigt Hinweise)
• Priorität (Whitelist oben)
• Bereits von höherer Allow- oder Skip-Regel erfasst?

F: Eigene IP blockiert?

A: In Regel 1 Whitelist ergänzen:

(cf.client.bot) or (ip.src in {Ihre-IP})

F: Welcher Threat Score?

A: Empfehlung:

• Konservativ: cf.threat_score gt 30 (weniger Blockierungen)
• Ausgewogen: cf.threat_score gt 10 (empfohlen)
• Aggressiv: cf.threat_score gt 5 (mehr Blockierungen, VPN-Risiko)

Mit 10 starten, eine Woche beobachten, nach CSR und False Positives anpassen.

F: Google-Crawler blockiert?

A: Regel 1 (Whitelist) muss höchste Priorität haben. cf.client.bot erkennt Google, Bing u. a. – Whitelist an erster Stelle, dann kein Problem.

Fazit

Kurz zusammengefasst:

5 Firewall-Regeln im Free-Tier reichen – mit richtiger Priorität:

1. Whitelist zuerst – Verbündete schützen
2. ASN-Challenge – Rechenzentrum-Traffic
3. Threat-Score-Filter – Hochrisiko-IPs
4. Anomale UA – Automatisierung blockieren
5. Sensible Pfade – Hintertüren schließen

Nach der Konfiguration ca. 30 Minuten bis zur Wirkung. Nach einer Woche Security Events prüfen – Scanner, die früher Traffic und Bandbreite fraßen, bleiben draußen.

Jetzt konfigurieren. Cloudflare Dashboard, Vorlagen oben – kopieren, IPs anpassen, in einer halben Stunde fertig.

Nach einer Woche Blockierdaten prüfen. Bei gutem Ergebnis Artikel bookmarken für spätere Anpassungen. Bei Problemen Kapitel 5 FAQ nachschlagen.

Ihre Website verdient besseren Schutz.