Cloudflare Kosten sparen: 5 Security Rules im Free-Plan

Mit diesem Kundenprojekt wollte ich vor allem eines zeigen: Gute Absicherung muss nicht teuer sein. Deshalb habe ich das Regelwerk vollständig im Cloudflare Free Plan aufgebaut. Das Ziel war klar. Das System sollte typische Angriffe, Scanner und unerwünschte Bots zuverlässig stoppen. Gleichzeitig durften echte Nutzer, notwendige Hintergrundprozesse und legitime technische Requests nicht versehentlich blockiert werden.

Genau an diesem Punkt wird ein Setup interessant. Denn viele Regeln sehen auf den ersten Blick stark aus, sind in der Praxis aber zu grob. Dann blockieren sie zwar Bots, aber eben auch nützliche Prozesse. Deshalb habe ich dieses Projekt bewusst so aufgebaut, dass Sicherheit und Stabilität zusammenpassen. Zudem war es wichtig, die Cloudflare Kosten niedrig zu halten. Der Kunde sollte keine teuren Zusatzfunktionen buchen müssen, wenn sich ein sauberer Schutz bereits im kostenlosen Plan erreichen lässt.

Zu Beginn stand keine leere Testumgebung, sondern ein reales Projekt mit wiederkehrendem Bot-Traffic, verdächtigen Dateizugriffen und sensiblen Backend-Pfaden. Dazu kamen technische Sonderfälle wie SSL-Erneuerungen, asynchrone Prozesse und definierte Infrastruktur-IPs. Genau deshalb durfte die Lösung nicht nur hart, sondern vor allem präzise sein.

Die Anforderungen waren überschaubar, aber klar:

• offensichtliche Exploit-Scans früh blockieren
• sensible Pfade zusätzlich absichern
• unerwünschte Crawler reduzieren
• vertrauenswürdige Infrastruktur gezielt durchlassen
• Zertifikats- und Systemprozesse bewusst freihalten

Außerdem sollte das gesamte Setup dokumentierbar bleiben. Deshalb war der Hinweis Save with API call im Cloudflare-Dashboard für mich mehr als nur eine Komfortfunktion. Er macht das Regelwerk nachvollziehbar. Damit wird api cloudflare auch für spätere Änderungen oder ähnliche Projekte relevant.

Das wichtigste Ziel in diesem Kundenprojekt war nicht maximale Härte, sondern maximale Kontrolle. Ich wollte kein Regelwerk bauen, das auf gut Glück alles sperrt. Stattdessen sollte jede Regel eine klare Aufgabe haben. Und ebenso wichtig: Die Reihenfolge der Regeln musste sauber geplant sein. Denn eine gute Security Rule wirkt nicht isoliert. Sie wirkt im Zusammenspiel mit den Regeln davor und danach.

Genau daraus entstand ein kompakter Aufbau mit fünf Regeln:

1. ALLOWLIST | Trusted Infra
2. ACME | HTTP-01 Challenge
3. BLOCK | Exploits & Secrets
4. BLOCK | Unwanted Crawlers
5. WP-ADMIN | Backend Geo-Schutz

Dieses Modell war bewusst einfach. Trotzdem ist es stark. Denn zuerst kommen enge Ausnahmen für legitime technische Requests. Danach folgen gezielte Block-Regeln. Zum Schluss wird der sensible Backend-Bereich zusätzlich mit einer Challenge abgesichert.

Die erste Regel war eine kontrollierte Allowlist für bekannte Infrastruktur. Das klingt unspektakulär, ist aber in der Praxis oft die wichtigste Regel von allen. Ohne sie laufen spätere Block-Regeln schnell in False Positives. Genau das wollte ich vermeiden.

Deshalb habe ich nicht ganze Bereiche freigeschaltet, sondern nur sehr enge Kombinationen aus:

• klar definierten IP-Adressen
• konkreten HTTP-Methoden
• exakt passenden Pfaden
• technisch bekannten Spezialfällen

So konnten legitime Requests für definierte Prozesse sauber durchlaufen. Gleichzeitig blieb der Rest des Systems weiterhin geschützt. Diese Regel stand deshalb ganz bewusst an erster Stelle.

(
  (
    ip.src in {144.76.24.196 2a01:4f8:c17:ac10::1}
    and http.request.method in {"GET" "HEAD"}
    and lower(http.request.uri.path) eq "/"
    and http.request.uri.query eq ""
  )
  or
  (
    ip.src in {86.56.28.155 2a01:4f8:191:ea::2}
    and http.request.method eq "POST"
    and lower(http.request.uri.path) eq "/wp-admin/admin-ajax.php"
  )
)

Diese Logik zeigt gut, worauf es ankommt: nicht pauschal erlauben, sondern nur exakt das, was wirklich notwendig ist.

Ein häufiger Fehler in restriktiven WAF-Setups ist das unbeabsichtigte Stören der Zertifikatsprüfung. Sobald Requests für /.well-known/acme-challenge/ in harte Regeln laufen, kann die Erneuerung scheitern. Das passiert schneller, als viele denken.

Deshalb bekam dieser Fall eine eigene Skip-Regel. Diese Regel war eng formuliert. Erlaubt wurden nur GET und HEAD. Außerdem wurden verdächtige Varianten mit .php oder .. explizit ausgeschlossen.

Die Wirkung ist einfach, aber wichtig: Zertifikatsprozesse funktionieren sauber weiter. Gleichzeitig entsteht dadurch keine unnötig große Ausnahmefläche.

starts_with(lower(http.request.uri.path), "/.well-known/acme-challenge/")
and http.request.method in {"GET" "HEAD"}
and not lower(http.request.uri.path) contains ".php"
and not lower(http.request.uri.path) contains ".."

Gerade solche kleinen Regeln machen ein Sicherheitskonzept belastbar. Denn sie schützen nicht nur vor Angriffen, sondern auch vor selbst verursachten Problemen.

Die dritte Regel war die stärkste Block-Regel im gesamten Projekt. Hier ging es um typische Exploit-Muster, verdächtige Dateinamen und Zugriffe auf sensible Pfade. Dazu gehörten unter anderem:

• /.env
• /.git/config
• xmlrpc.php
• bekannte Backdoor-Dateien
• verdächtige Plugin- und Theme-Pfade
• Dateiendungen wie .sql, .bak, .log, .zip oder .gz

Wichtig war dabei vor allem die Kombination aus Listen und Mustern. Viele Angriffe laufen nicht nur über exakt bekannte Pfade, sondern über kleine Varianten und Suchmuster in der URL oder Query. Deshalb habe ich nicht nur einzelne Ziele, sondern auch typische Fragmente berücksichtigt.

Gleichzeitig wurden interne Cloudflare-Pfade und die ACME-Challenge bewusst ausgeschlossen. So greift die Regel hart, aber eben nur dort, wo sie auch greifen soll.

Nicht jeder Bot ist automatisch schädlich. Aber nicht jeder Bot ist auch nützlich. In diesem Projekt gab es klare Kandidaten, die Last erzeugen, Daten absaugen oder nur Monitoring und Scans fahren, ohne für das Projekt echten Nutzen zu bringen. Genau deshalb wurde eine eigene Regel für unerwünschte Crawler aufgebaut.

Die Regel kombinierte zwei Ansätze:

• bekannte Quell-IP-Adressen
• spezifische User-Agent-Muster

Dabei wurden legitime technische Ziele bewusst ausgenommen, etwa:

• /robots.txt
• /sitemap.xml
• /sitemap_index.xml
• definierte API- oder Schema-Endpunkte

Zu den geblockten Mustern gehörten beispielsweise:

• semrushbot
• ahrefsbot
• mj12bot
• dotbot
• bytespider
• claudebot
• gptbot

Für mich war dabei wichtig, den Beitrag nicht ideologisch zu führen. Es geht nicht darum, pauschal „alle Bots“ zu stoppen. Es geht darum, projektspezifisch zu entscheiden, welche Zugriffe Ressourcen kosten, aber keinen Mehrwert liefern. Genau dadurch bleibt das Regelwerk glaubwürdig und praxisnah.

Der sensibelste Bereich war das Backend. Hier wollte ich nicht blind blockieren. Denn Backend-Zugriffe können legitim sein, auch wenn sie nicht immer gleich aussehen. Deshalb war Managed Challenge die bessere Wahl als ein pauschaler Block.

Die Regel zielte auf:

• /wp-login.php
• /wp-admin
• /wp-admin/...

Ausgenommen blieben bewusst technische Pfade wie:

• /wp-admin/admin-ajax.php
• /wp-admin/admin-post.php

Zusätzlich wurden bekannte vertrauenswürdige IPs ausgenommen. Ebenso wurden nur definierte Länder für direkte Zugriffe auf das Backend zugelassen. Alles andere lief in eine Managed Challenge.

Gerade hier zeigt sich, warum ich das Projekt nicht nur als reines Block-Setup sehe. Gute Sicherheit bedeutet oft, dass man einen Schritt dazwischen setzt. Nicht jeder ungewöhnliche Request ist automatisch ein Angreifer. Eine Challenge filtert in solchen Fällen deutlich eleganter.

Viele verbinden Sicherheit sofort mit Zusatzkosten. In diesem Projekt war genau das Gegenteil spannend. Denn der Cloudflare Free Plan hat bereits genug Werkzeuge, um ein solides Grundsetup zu bauen, wenn die Regeln klar gedacht sind.

Das Projekt zeigt deshalb sehr gut, was cloudflare kostenlos schon leisten kann:

• Ausnahmen für vertrauenswürdige Prozesse
• gezielte Block-Regeln
• Managed Challenge für sensible Bereiche
• klare Reihenfolge für ein stabiles Zusammenspiel

Für mich war das der wichtigste Beweis im Projekt: Man muss nicht sofort in teure Pläne springen, wenn das eigentliche Problem sauber analysiert und präzise gelöst wird.

Ein weiterer Vorteil lag in der Verwaltung. Die Regeln wurden zwar im Dashboard aufgebaut, aber nicht nur als einmaliger Klickpfad verstanden. Durch Save with API call lässt sich das Setup auch technisch sauber dokumentieren. Genau deshalb ist api cloudflare als Nebenkeyword und als Praxisaspekt in diesem Projekt sinnvoll.

Das bringt mehrere Vorteile:

• Regeln bleiben nachvollziehbar
• Setups lassen sich später reproduzieren
• Änderungen können kontrolliert versioniert werden
• ähnliche Projekte lassen sich schneller umsetzen

Gerade bei Kundenprojekten ist das ein echter Gewinn. Denn saubere Dokumentation spart später Zeit und reduziert Fehler bei Änderungen.

Immer wieder kommt in solchen Projekten die Frage auf, ob man nicht einfach alles mit Fail2ban auf Serverebene lösen sollte. Für mich ist das kein Gegensatz. Die spannendere Frage lautet: Was stoppe ich besser direkt am Edge und was gehört bewusst auf den Server?

Genau hier liegt der Vorteil von Cloudflare. Requests werden schon vorher gefiltert. Dadurch erreicht weniger unnötige Last den Origin. Exploit-Scans, Bot-Traffic und auffällige Pfadmuster können früh geblockt werden.

Deshalb ist die Kombination cloudflare fail2ban bzw. fail2ban cloudflare eher eine Architekturfrage als ein Wettbewerb. In diesem Projekt lag der Schwerpunkt bewusst auf einer starken ersten Schutzschicht am Edge. Das war sinnvoll, weil sich damit viele Probleme schon vor dem eigentlichen System entschärfen ließen.

Am Ende stand kein überkomplexes Enterprise-Konstrukt, sondern ein sehr bewusst aufgebautes Regelwerk mit klaren Zuständigkeiten. Genau das macht dieses Kundenprojekt für mich so wertvoll. Es zeigt nicht nur, dass Schutz funktioniert. Es zeigt auch, dass Schutz ohne unnötige Nebenwirkungen funktionieren kann.

Das Ergebnis im Überblick:

• vertrauenswürdige Infrastruktur wurde sauber freigehalten
• ACME-Challenges liefen ohne Störung weiter
• Exploits und Secret-Scans wurden früh geblockt
• unerwünschte Crawler wurden reduziert
• Backend-Zugriffe wurden sinnvoll abgesichert

Dadurch wurde das System robuster, ohne wichtige Prozesse zu beschädigen. Genau das war das eigentliche Projektziel.

Dieses Projekt zeigt sehr klar, dass sich Cloudflare Kosten sparen lassen, ohne Sicherheit zu opfern. Entscheidend ist nicht der größte Tarif, sondern die Qualität des Regelwerks. Wenn Regeln präzise formuliert, richtig sortiert und mit realen Sonderfällen abgestimmt werden, lässt sich auch im kostenlosen Plan ein belastbares Setup aufbauen.

Für mich ist das die wichtigste Erkenntnis aus dem Kundenprojekt: Gute Security Rules blockieren nicht einfach möglichst viel. Sie blockieren gezielt das Richtige. Und sie lassen alles durch, was für Betrieb, Nutzer und Infrastruktur weiter funktionieren muss.

• 5 Security Rules im Cloudflare Free Plan umgesetzt
• Trusted Infra und ACME sauber berücksichtigt
• Exploits, Secrets und unerwünschte Crawler wirksam reduziert
• Backend-Zugriffe mit Managed Challenge abgesichert
• Sicherheit erhöht, ohne legitime Requests zu beschädigen

Interessiert an einem ähnlichen Cloudflare-Setup für dein Projekt?