Projektübersicht

Für die öffentlich erreichbare Portfolio-Website wurden Cloudflare Security Rules konfiguriert. Neben einer funktionierenden Rate-Limiting-Regel für das Kontaktformular gab es einen gescheiterten Versuch, direkten Zugriff auf den Origin-Server zu blockieren. Der Fehler wurde analysiert, die Regel gelöscht und die Erkenntnis dokumentiert.

1. Situation (Ausgangslage)

Die Portfolio-Website ist öffentlich erreichbar. Jede öffentliche Domain wird kontinuierlich von automatisierten Scannern und Bots abgetastet. Das Kontaktformular (Web3Forms, Free Plan) hat ein monatliches Limit von 250 Submissions, das ein einfacher Bot in Sekunden ausschöpfen kann. Ausserdem fehlte eine explizite Schicht die HTTP-Anfragen auf Inhaltsebene prüft, nicht nur auf IP- und Port-Ebene wie OPNsense es tut.

2. Task (Zielsetzung)

• Formular-Schutz: Das Kontaktformular vor automatisierten Spam-Angriffen schützen.
• Versuch: Origin-Schutz: Direkten Zugriff auf den Origin-Server blockieren, für den Fall dass jemand die Heimnetz-IP herausfindet.
• Verständnis aufbauen: Den Unterschied zwischen Netzwerk-Firewall (Layer 3/4) und WAF (Layer 7) praktisch erfahren.

3. Action (Umsetzung)

A. Rate Limiting Rule für das Kontaktformular

Im Cloudflare Dashboard wurde eine Rate Limiting Rule konfiguriert, die auf HTTP-POST-Requests greift. POST ist die Methode die Formulare beim Absenden verwenden. Die Regel erlaubt 2 Submissions pro 10 Sekunden pro IP. Wer dieses Limit überschreitet, wird für 10 Sekunden blockiert.

GET-Requests sind bewusst ausgenommen: jeder Seitenaufruf, jedes Bild, jede CSS-Datei wird per GET geladen. Rate Limiting auf GET würde normale Besucher treffen.

B. Versuch: Block non-Cloudflare IPs (gescheitert)

Cloudflare veröffentlicht alle seine IP-Ranges öffentlich. Die Idee war: eine Regel die alles blockiert was nicht von einer Cloudflare-IP kommt, würde direkten Zugriff auf den Origin-Server verhindern.

Die Regel wurde mit allen Cloudflare-IP-Ranges als Whitelist formuliert und aktiviert. Sie blockierte sofort legitime Besucher, darunter auch den eigenen Laptop.

Ursache des Fehlers: Das Feld ip.src in Cloudflare WAF-Regeln zeigt die echte Besucher-IP, nicht die Cloudflare-Edge-IP. Cloudflare stellt der WAF die originale Absender-IP zur Verfügung. Eine normale Heimnetz-IP liegt nie in den Cloudflare-Ranges, also wurde jeder Besucher geblockt.

Zusätzliche Erkenntnis: Die Regel wäre auch dann unnötig, weil die Architektur direkten Zugriff bereits auf Netzwerkebene verhindert. Der Cloudflare Tunnel ist eine ausgehende Verbindung vom Server zu Cloudflare, kein eingehender Port. In OPNsense sind keine eingehenden Ports für Port 80 oder 443 geöffnet. Es gibt keinen direkten Weg auf den Origin-Server. Die Regel hätte ein Problem gelöst das nicht existiert.

Die Regel wurde gelöscht.

4. Result (Ergebnis & Verifikation)

Die Rate Limiting Rule ist aktiv und hat kurz nach der Einrichtung den ersten Treffer geliefert: ein automatisierter Bot suchte nach einer WordPress-Installationsseite. Die Website läuft auf Flask, kein WordPress vorhanden. Der Bot wurde geblockt, der Eintrag erschien im Cloudflare Security Analytics Event-Log mit Quell-IP, angefragtem Pfad und Herkunftsland.

Das zeigt zweierlei: automatisierte Scans passieren kontinuierlich auf jeder öffentlichen Domain, und Monitoring macht sie erst sichtbar.

Die gescheiterte Regel wurde vollständig analysiert und dokumentiert. Das freie Custom-Rule-Kontingent ist damit unverändert verfügbar.

Lessons Learned

• WAF vs. Netzwerk-Firewall: Eine Netzwerk-Firewall prüft IP-Adressen und Ports. Eine WAF prüft den HTTP-Inhalt: URL, Methode, Header, User-Agent, Herkunftsland. Beides ergänzt sich, ersetzt sich aber nicht.
• ip.src in Cloudflare WAF zeigt die Besucher-IP: Cloudflare ist ein Proxy, aber die WAF bekommt trotzdem die echte Absender-IP zu sehen. Wer darauf nicht achtet, formuliert Regeln die das Gegenteil von dem tun was beabsichtigt war.
• Architektur vor Regeln verstehen: Bevor eine Sicherheitsregel konfiguriert wird, lohnt es sich zu prüfen ob das Problem überhaupt existiert. Ein ausgehender Tunnel ohne offene Ports ist bereits eine Absicherung, keine zusätzliche WAF-Regel verbessert das weiter.
• Gescheiterte Versuche dokumentieren: Ein Fehler der analysiert und erklärt wird, zeigt mehr technisches Verständnis als eine Liste von Erfolgen.