Erfahrungsbericht Cloudflare

Seit Januar 2021 nutzen wir für https://www.aphorismen.de die Dienste von Cloudflare. Aphorismen.de hat am Tag etwa 30.000 Besucher, die zu 90% aus dem DACH Raum kommen. Unser früherer Webserver war ein in Deutschland gehosteter vServer mit 8 Kernen, nginx Proxy und Antwortzeiten deutlich unter 100ms.
Performance oder CDN waren für uns also kein Grund für Cloudflare. Mich interessierte vor allem die Möglichkeit, die Webserver hinter Firewall und Proxy quasi unsichtbar zu machen.

Anfangs war ich skeptisch, da sich bei meinen Tests die Latenz erhöhte. Die Webseiten wurden mit Cloudflare deutlich langsamer geladen als ohne. Logisch, es dauert halt länger, wenn eine Station in der Kette hinzukommt.
Doch wie funktioniert das nun mit Cloudflare und warum nutzen wir es?

Caching, CDN und Reverse Proxy

Bei der Nutzung von Cloudflare gelangt eine Anfrage nicht mehr direkt zum Webserver, sondern zu einem der weltweit über 200 Cloudflare Datacenter, welches sich im Idealfall nahe am Client befindet.
Im Standard-Setup von Cloudflare werden nur Assets wie Bilder, jedoch keine html-Seiten gecached. Das kann aber mittels Pagerules verändert und angepasst werden.

Sollte sich die angefragte Ressource nicht im Cache des Datacenters befinden, wird sie vom Ursprungsserver (also dem Webserver) geholt. Der SSL- verschlüsselte Netzwerkverkehr wird bei Cloudflare entschlüsselt, Firewall-, Pagerule-, oder Worker- Aktionen durchgeführt, wieder verschlüsselt und je nach Regel gecached.

Im Idealfall befindet sich die Resource jetzt im Cache des Datacenter und wird bei der nächsten Anfrage direkt an den Client gesendet, ohne den Ursprungsserver zu belasten.
Das bringt besonders dann Vorteile, wenn sich das Datacenter näher am Client befindet als der Ursprungsserver.
Es ist wichtig zu wissen, dass jedes Data-Center seinen eigenen Cache hat, d.h. hat z.B. das Datacenter in Berlin eine Datei im Cache, muss sie das Datacenter in Frankfurt vielleicht erst noch vom Ursprungsserver abrufen. Das ist erstmal nicht so günstig für uns, denn durch die große Menge an Zitaten und Suchkriterien ergeben sich für Aphorismen.de hunderttausende unterschiedliche Seiten mit einer Lebensdauer von Minuten bis wenigen Tagen.

Es kommt sogar mitunter vor, dass mir als Client aus Dresden oder Forst Seiten vom Datacenter London oder Amsterdam geliefert werden. Das ist natürlich nicht wirklich optimal. Die Response-Zeiten wären aus Frankfurt oder wenigstens Berlin deutlich kürzer, da sich unser Ursprungsserver in Frankfurt befindet. Woher die Dateien kommen, sieht man übrigens am cf-ray Header der Antwort. Weitere Informationen im Header zeigen, ob die Datei aus dem Cache kommt und seit wann sie sich dort befindet.
Den Grund für diese zum Teil deutlich längeren Wege kenne ich nicht. Zumal es auch bei dynamischen Dateien ohne caching auftritt.
Möglicherweise routed Cloudflare die Daten je nach Auslastung ihrer Datacenter.

Es wäre toll, wenn sich die Caches der 200 Datacenter automatisch synchronisieren würden, so dass die ca. 30000 Seiten, die Google täglich von Aphorismen.de abruft, sich nicht nur im Cache des Datacenters von San Jose befinden, sondern allen Clients weltweit zur Verfügung stehen.
Etwas Ähnliches lässt sich mit ARGO Routing und Tiered-Cache aktivieren. Dann wird innerhalb des Cloudflare Netzwerks geprüft, ob sich eine Ressource schneller aus einem anderen Datacenter als vom Ursprungsserver holen lässt. Dieser interne Traffic kostet 0.1$ je Gigabyte. Das klingt zunächst nicht viel, würde sich aber im Falle von Aphorismen.de auf 50 EUR/Monat summieren. Wenn man jedoch eine überschaubare statische Webseite (wie diesen Blog) hat, werden die verteilten Caches keine Rolle spielen und auch ARGO wird nur ein paar Cent kosten.

Damit unsere PHP-Seiten gecached werden, sende ich eigene Cache-Header für Cloudflare.
Als Seitenbetreiber weiß man selbst am besten, wie lange dynamische Seiten gültig sind. Auf einigen Seiten ändern sich Inhalte alle paar Minuten, andere könnte man wochenlang im Cache behalten.

Beispiel Cache Header für eine kurzlebige Seite:

public, max-age=300, s-maxage=900, stale-while-revalidate=3600

• Der Browser des Clients soll die Seite 300 Sekunden im Cache halten
• Cloudflare soll die Seite 900 Sekunden cachen
• Bei der nächsten Anfrage, die zwischen 900 und 3600 Sekunden im Datacenter eintrifft, soll Cloudflare die alte Seite aus dem Cache liefern und im Hintergrund eine aktuelle Version vom Ursprungsserver holen. Das führt zu einer nahtloseren Aktualisierung des Caches

Die Vorteile von Cloudflare für uns

Da durch Cloudflare 80% weniger Requests auf dem Server ankommen und wir keinen eigenen Proxy Cache mehr benötigen, konnten wir auf einen kleineren vServer umsteigen. Über meine ersten Erfahrungen mit Google Compute Engine habe ich auch einen Artikel geschrieben.

Ein wichtiges Argument für Cloudflare war für mich jedoch die Security durch deren Firewall mit vielen Optionen und Einstellungsmöglichkeiten.
Zuvor hatten wir eine eigene Firewall mit Ratenbregrenzer, Blacklist, Whitelist, Anbindung an abuseipdb.com etc., doch der Pflegeaufwand wurde immer größer und es nervte. DDoS Angriffe und SPAM Attacken kommen meist überraschend und zu ungünstigen Zeiten, am Wochenende oder wenn man gerade im Urlaub ist ;-( (Natürlich!) Oder aber Google streicht plötzlich einen Teil der Werbeeinnahmen, wegen ungültiger Klicks durch Bots. Doch gerade gegen Bots mit wechselnden IP-Adressen und Signaturen kann man mit einer normalen Firewall wenig ausrichten.

Mit Cloudflare kann ich einfach allen Clients eines Landes ein Captcha senden oder ein komplettes ASN sperren. Dazu kommen Funktionen wie Spectrum, Zone Lockdown oder Access. Über Cloudflare Access kann man quasi den Zugriff auf ein Intranet steuern, ohne das Firmennetz per VPN öffnen zu müssen.

Wie man am täglichen Bot-Bericht sehen kann, sind nur 50% unserer Besucher menschlich. Oder anders ausgedrückt: 50% des Netzwerkverkehrs, der Serverlast und der damit verbundenen Kosten werden durch Bots verursacht.

Nutzt man Cloudflare als DNS-Server und Proxy, gibt eine dig-Anfrage auf die Domain nicht die IP-Adresse des Ursprungsserver zurück. Daher ist es nicht mehr so einfach, die IP-Adresse des Ursprungsservers zu ermitteln, um dort nach Schwachstellen zu suchen.

Zudem ist es möglich, in der Firewall des Ursprungsserver nur die IP-Adressen von Cloudflare zuzulassen. Oder man konfiguriert den Ursprungsserver so, dass er nur SSL Anfragen mit Client Zertifikat von Cloudflare akzeptiert. Die entsprechenden SSL Zertifikate und Anleitungen findet man im Dashboard von Cloudflare.
Durch diese Konfiguration kommen Angreifer nicht mehr direkt, sondern nur noch über Cloudflare auf den Ursprungsserver.

Bild oben: Firewall bei der Arbeit.
Innerhalb von 24 Stunden wurden über 28.000 Anfragen abgelehnt. Auffällig ist die Durchsatzbegrenzung ab ca. 13 Uhr, die von einem einzigen Bot verursacht wurde. Die Firewall-Berichte lassen sich nach verschiedenen Kriterien wie Land, IP oder Pfad filtern. Doch nicht nur für die Firewall, sondern auch für Traffic, Cache oder DNS gibt es Statistiken. Für welchen Zeitraum die Berichte vorliegen, ist vom gewählten Tarif abhängig, in unserem Fall gehen die Berichte jeweils eine Woche zurück. Für einfache Ansprüche könnte man damit also fast Google Analytics ersetzen, v.a. weil die Statistiken ohne die Hilfe von Cookies erstellt werden.

Die Funktionalität der WAF konnte ich selbst (eher ungewollt) testen, als ich über den Browser in unserem Backend ein PHP Template ändern wollte. Das wurde von der Firewall erkannt und verhindert.

Um Spammer herauszufiltern, fragen wir zusätzlich mit einem Worker die Datenbank von abuseipdb.com ab. Hat die IP-Adresse des Clients einen hohen Abuse-Score, wird eine Firewall-Regel generiert.
All das passiert im Hintergrund, ohne den Webserver zu belasten.
Zukünftig möchte ich einen eigenen Ratenbegrenzer und die Funktion "Bypass Cache on Cookie" mittels Worker Funktionen abbilden. Diese wären dann individuell an unsere Bedürfnisse angepasst und preiswerter.

Edge Computing mit Cloudflare Workers & Co.

Über Cloudflare Pages, Workers, KV und Durable Objects lohnt es sich, eigene Artikel zu schreiben. Damit ergeben sich ganz neue Möglichkeiten! Daher sollen hier nur einige kurze Worte verloren werden.

Workers sind Funktionen, die direkt an der "Edge", also am Rande der Cloud, nahe am Client ausgeführt werden. Worker Funktionen sind zustandslos, ähnlich den Google Cloud Functions oder AWS Lambda, allerdings mit geringerer Kaltstartzeit.
Zur Speicherung von Werten kann man Workers KV und neuerdings Durable Objects zur weltweit konsistenten Bereitstellung ganzer Objekte einsetzen.

Es ist möglich, eine komplette Anwendung mit Cloudflare Workers zu erstellen. Ein eigener Webserver würde sich damit erübrigen und die Anwendung würde automatisch relativ nahe am Client ausgeführt werden.

Kosten

Ein Ausschnitt der Tarife von der Cloudflare-Webseite (Stand 05.2021)

Mit dem kostenlosen Free Plan kann man schon gut starten, muss allerdings wissen, dass einige sinnvolle Features erst ab dem Professional Tarif verfügbar sind. Weitere Kosten entstehen für uns durch das Rate Limiting und das Workers Paket. In Summe liegen wir momentan bei ca. 30 EUR/Monat.

Da ich sowieso mit unserem Webserver zu einem Cloud-Anbieter wie Google Cloud oder AWS umzuziehen wollte, wäre es natürlich schön gewesen, alles unter einem Dach zu haben, also sowohl eine gute Firewall als auch das Cloud Hosting. Leider habe ich bei den großen Cloud-Anbietern keine bezahlbare WAF gefunden. Sollte Google etwas Vergleichbares wie Cloudflare rausbringen, werde ich mir das sicherlich ansehen.

Kritikpunkte aus meiner Sicht

• eine Funktion für dynamische Seiten zum Cache umgehen ala "Bypass Cache on Cookie" gib es nur für Business und Enterprise Tarif
• Cache Inhalte löschen kann man nur entweder alles löschen oder einzelne URL. Keine Präfixes, Platzhalter oder rekursives Löschen
• der neue Bot Fight Modus lässt sich nur beim Enterprise Plan auf einzelne URL einschränken. Damit sperrt man auch Bots wie Feed Reader, Amazon Alexa oder Facebook aus
• für Ratenbegrenzung und Firewall Regeln sind nur Pfade und keine URL Parameter möglich
• wichtige Funktionen wie Ratenbegrenzung oder Tiered Cache kosten extra

Fazit

Der Artikel ist nun doch etwas länger geworden ;-)
Mein erstes Fazit nach 4 Monaten: Ich bin zufrieden mit dem Einsatz von Cloudflare.
Mein erstes Ziel, mehr Sicherheit für den Webserver, habe ich erreicht. Zudem halte ich das derzeitige Preis-Leistungs-Verhältnis von Cloudflare für sehr gut, auch wenn ich mir als Anwender natürlich einige wichtige Funktionen der teureren Tarife in meinem Pro Plan wünschen würde. In den letzten Wochen hat Cloudflare mit Pages und Durable Objects weitere Innovationen gelauncht. Ich bin gespannt, was die Zukunft bringen wird...

Schreib mir Deine Meinung auf Twitter