Content-Delivery-Netzwerke: DDoS-Schutz und schnelle Auslieferung kombiniert

Mini-Intro: Ein reales Szenario in 90 Sekunden

Montag, 9:01. Ein Sale geht live. Ihr Team sieht Peaks. TTFB steigt. Fehler häufen sich. Eine Bot-Welle mischt echte Nutzer unter. In den Logs knallt die Rate pro Sekunde nach oben. Die App atmet schwer. Jetzt greift das CDN.

Anycast verteilt die Flut. Edge-Knoten cachen Assets. Regeln drosseln verdächtige Muster. Das WAF blockt bekannte Signaturen. Die Origin bleibt ruhig. Kunden sehen eine schnelle Seite. Ihr Team behält die Kontrolle. Dass so ein Bild real ist, belegen aktuelle DDoS-Trends. Peaks kommen. Das zählt: gute Kanten, klare Policies, sauberes Messen.

Warum CDNs DDoS nicht “lösen” – und dennoch unverzichtbar sind

Ein CDN ist ein Netz aus vielen Knoten (PoPs) nahe bei Nutzern. Es schickt Inhalte schnell zum Browser. Es nimmt Last von Ihrem Ursprung. Es kann auch Angriffe dämpfen. Aber: Ein CDN ist kein Allheilmittel.

Erst das Grundwissen: Was ist ein CDN? Ein CDN puffert Dateien. Es nutzt Caching, gutes Routing und moderne Protokolle. Es spart Zeit bei Handshakes. Es senkt Latenz. Es schützt, indem es Traffic schlau sortiert.

Was ein CDN gut kann: Layer 7 (Anwendung) prüfen, Raten limitieren, Bots herausfordern, Caches steuern. Was es begrenzt kann: riesige Layer‑3/4‑Fluten (Netz/Transport) komplett schlucken. Dort hilft oft ein Upstream‑Schutz beim ISP oder Cloud. Mehr dazu zeigt Akamai in einem Überblick zu L3/4 vs. L7 DDoS. Fazit: Ein CDN ist die erste starke Schicht. Für sehr große Volumen brauchen Sie zusätzliches Scrubbing.

Feldnotizen aus dem Betrieb: typische Stolperfallen

Viele Probleme sind hausgemacht. Falsche Cache‑Header. HTML, das pro User anders ist, aber kein Vary nutzt. Bilder ohne lange TTL. Kein Origin Shield, obwohl mehrere Regionen zuschlagen. Dann kippt die Origin in die Knie, obwohl das CDN da ist.

Auch Protokolle werden zum Vektor. Ein Beispiel ist das HTTP/2 „Rapid Reset“. Es erzeugt sehr viele abgebrochene Streams. Das geht schnell durch. Lesen Sie die technische Analyse bei Imperva. Ein gutes CDN erkennt Frames, begrenzt Verbindungen pro IP/ASN und bricht Muster ab.

Vergessen Sie die Basics nicht: Formulare ohne Schutz laden Credential‑Stuffing ein. Offene APIs ziehen Scraper an. Setzen Sie Bot‑Schutz, Device-Signale und Challenges sparsam, aber gezielt. Ein Blick in die OWASP Top 10 schärft den Blick für häufige Fehler.

Exkurs: So verkürzt das CDN echte Ladezeiten

Geschwindigkeit ist nicht nur Cache. Ein CDN spart Zeit bei Verbindungen. Es setzt auf TLS 1.3, 0‑RTT (vorsichtig), und gute Kompression wie Brotli oder Zstd. Es nutzt HTTP/3 über QUIC. Das reduziert Latenz, gerade bei mobilen Netzen.

Wichtig für SEO und Nutzer sind Core Web Vitals. Ein CDN hilft beim TTFB (Time to First Byte) und oft beim LCP (Largest Contentful Paint), wenn Bilder und kritische Assets am Rand liegen. Lesen Sie Grundlagen zu Core Web Vitals. Messen Sie mit echten Nutzern (RUM) und nicht nur mit Tools.

HTTP/3 bringt Gewinne bei Paketverlust. QUIC arbeitet über UDP und baut Verbindungen schneller auf. Ein guter Einstieg: Überblick zu HTTP/3 und QUIC. Tipp: Aktivieren Sie es, beobachten Sie Metriken pro Land und Gerät, und rollen Sie schrittweise aus.

Vor der Tabelle: Was passt zu welchem Vektor?

Viele Teams blocken „alles“ und verlieren echte Nutzer. Besser: erkennen, dämpfen, und gezielt prüfen. Dazu brauchen Sie Muster je Vektor, klare Limits, und eine Eskalation. Für Austausch mit Upstream‑Mitigation lohnt sich ein Standard wie IETF DOTS (RFC 8612). So teilen Systeme Signale und schalten schnell hoch.

Übersichtstabelle: DDoS‑Vektoren, Anzeichen, CDN‑Maßnahmen, Grenzen

SYN Flood (L3/4)	Sprung bei pps, viele halb offene Verbindungen	Anycast‑Streuung, Conn‑Limits pro IP/ASN, Proxy‑Stack	Oft Upstream‑Scrubbing nötig bei sehr hohen pps
UDP Amplification (DNS/NTP/SSDP/CLDAP)	Unerwartet hohe UDP‑Last, Source‑Spoofing‑Anzeichen	Anycast, Rate‑Limits, Drop unsicherer Ports am Edge	Spoofed Traffic erfordert Provider‑Filter (BCP38)
HTTP/2 Rapid Reset	Viele abgebrochene Streams, hohe RST‑Rate	Frame‑Anomalien erkennen, Conn‑Limits, dynamische Raten	Aufpassen bei legitimen Lasttests; fein justieren
Slowloris / Slow POST	Lange offene Requests, geringer Durchsatz pro Conn	Idle‑Timeouts, Header‑Timeouts, Mindest‑Durchsatz	Kann echte langsame Netze treffen; sanfte Schwellen setzen
L7 GET/POST Flood	rps‑Spike, viele gleiche Pfade/Parameter	WAF‑Regeln, Rate‑Limit pro Path/API‑Key, Caches	Personalisierte Seiten schwer zu cachen
Bot‑Scraping	Exotische UAs, seltene JA3‑Fingerprints, hohe 404‑Quote	Bot‑Scoring, JS‑Challenge, Tar‑Pits, Robots‑Härtung	Barrierefreiheit beachten; Ausnahmen pflegen
Credential Stuffing	Viele Login‑Fehler, Muster pro IP/ASN/Proxy‑Netz	Rate‑Limits am Login, CAPTCHA/Turnstile, 2FA‑Hinweise	Rechtliche Vorgaben pro Land beachten
IP‑Fragmentation	Fragmente, ungewöhnliche MTU‑Muster	Edge‑Reassembly Limits, Drop atypischer Fragmente	Feintuning nötig; Risiko für alte Geräte
XML‑RPC/GraphQL Abuse	Hohe Tiefe/Komplexität je Query, Zeit pro Call steigt	Query‑Kosten limitieren, Depth‑Limits, Schema‑WAF	Entwickler‑Team muss Regeln pflegen
Cache‑Bypass durch Query‑Noise	Viele Cache‑Misses, origin load hoch	Query‑Normalisierung, Ignore‑Params, Origin Shield	Prüfen, dass legitime Parameter bleiben

Auswahl in der Praxis: Kriterien, die über Marketing hinausgehen

Fragen Sie nicht nur nach „PoPs“. Fragen Sie nach echten Zielen und Messpunkten. Definieren Sie SLI/SLO. Das SRE‑Buch erklärt SLO sauber. Beispiel: „95% TTFB < 200 ms in DACH“, „Edge‑Hitrate > 80% für Bilder“, „API‑Fehler < 0,5%“.

Wichtig sind auch: Peering‑Qualität, Nähe zu großen ISPs, IX‑Anbindung, Egress‑Kosten, Log‑Zugriff in Echtzeit, gute API, flexible WAF/Bot‑Regeln, BYOIP, DSGVO‑Modus, Support‑Modell. Lesen Sie Basiswissen zu Peering beim RIPE NCC.

Checkliste kurz:

PoP‑Dichte dort, wo Ihre Nutzer sind (nicht nur „Weltkarte“).
Peering mit lokalen ISPs; Latenztests pro Land.
WAF/Bot‑Funktionen: Regeln, Scores, Anpassung.
HTTP/3, TLS 1.3, Brotli/Zstd, Image‑Optimierung.
Origin Shield, Stale‑while‑revalidate, Cache‑Keys.
Logs in Echtzeit, volle Request‑Samples, Export.
SLA/SLO transparent, Credits klar definiert.
DSGVO: Speicherorte, DPA, IP‑Maskierung.

Für den CFO: Rechnen Sie TCO. CDN‑Kosten vs. gesparte Origin‑CPU, weniger Bandbreite, weniger Ausfall. Kalkulieren Sie Egress bei großen Objekten und Preisstufen für Bot‑Features.

Branchen‑Zwischenruf: Peaks und Missbrauch sind Alltag

Im Ticketing knallt es zum Vorverkauf. Im Streaming bei Premieren. Im E‑Commerce am Black Friday. Im iGaming bei Bonus‑Aktionen. Hier ist L7 hart umkämpft. Bots lauern auf Formulare, Preise, Reviews.

Ein Beispiel aus der Praxis: Das unabhängige iGaming‑Review‑Portal ParhaatKasinot.biz erlebt bei neuen Tests und Publisher‑Deals kurze, starke Peaks. Parallel kommen Scraper auf Listen‑Seiten und Login‑Versuche auf Kommentar‑Formulare. Das Team setzt Edge‑Caching für Medien, straffes Rate‑Limiting auf Such‑ und API‑Routen und milde Challenges bei wiederkehrenden Mustern. So bleiben Seiten schnell, und echte Leser kommen ohne Hürden durch.

Sicherheitsstack klären: WAF, Bot‑Management, Rate Limiting

Ein CDN bremst und verteilt. Eine WAF filtert Anfragen nach Regeln. Bot‑Management bewertet Verhalten, Fingerprints und Kontext. Zusammen bilden sie Ihre Schutzschicht. Rollen Sie Regeln in Stufen aus: Log → Mitigate in „Preview“ → Enforce. Messen Sie Fehler pro Regel, nicht nur „geblockt“.

Wer Governance braucht, verankert Kontrollen in Standards. Ein Startpunkt sind die Controls in NIST SP 800‑53. Für APIs sind harte Limits Pflicht. Praxisleitfäden finden Sie in den Google Cloud Armor Docs zu Rate Limiting.

Recht & Compliance kurz erklärt (DSGVO, Logging, Standort)

Fragen Sie, wo Logs und Objekte liegen. Können IPs maskiert werden? Gibt es ein DPA? Sind EU‑PoPs bevorzugt? Wie lange speichert das CDN Daten? Gute Orientierung geben die ENISA‑Leitfäden zur Cloud‑Sicherheit.

Beim Transfer aus der EU beachten Sie die Leitlinien des EDPB (nach Schrems II). Prüfen Sie Standardvertragsklauseln, Verschlüsselung auf Transport‑ und Speicherebene, und Minimierung.

Messkonzept: vorher/nachher und laufendes Monitoring

Kein Schutz ohne Messung. Legen Sie Baselines fest. Messen Sie TTFB und LCP (p95) pro Land und Gerät. Tracken Sie Edge‑Hitrate, Origin‑Load, Fehlerquoten, Bot‑Scores, Conn‑Fehler. Richten Sie Alarme für Peaks und Drops ein.

Setzen Sie auf RUM für echte Nutzer. Startpunkte bietet die New Relic RUM‑Doku. Ergänzen Sie Synthetic‑Checks auf kritische Pfade und APIs. Dokumentieren Sie Änderungen an Regeln und Caches. Nur so sehen Sie Korrelationen zwischen „neue Regel“ und „mehr 429“.

FAQ aus echten Projekten

Brauche ich noch eine WAF, wenn ich ein CDN habe?
Ja. Das CDN verteilt und cached. Eine WAF prüft die Inhalte einer Anfrage. Beides zusammen fängt mehr ab, vor allem L7.

Hilft ein CDN gegen sehr große L3/4‑Angriffe?
Teilweise. Anycast hilft. Aber bei massiven pps/rate brauchen Sie zusätzliches Scrubbing, z. B. Dienste wie AWS Shield in Cloud‑Setups.

Schadet HTTP/3 alten Geräten?
In der Regel nein. Gute CDNs fahren HTTP/3 parallel zu HTTP/2/1.1. Clients wählen. Rollout schrittweise testen.

Wie beeinflusst ein CDN Core Web Vitals?
Positiv, wenn kritische Assets am Edge liegen und Verbindungen schneller sind. Messen Sie TTFB/LCP vor und nach dem Rollout.

Ist Azure Front Door ein CDN oder ein WAF?
Es ist ein Edge‑Dienst, der beides kombiniert. Details stehen in den Azure Front Door Docs. Das Muster „Performance + Schutz“ ist heute Standard.

Kurzer Ausblick + Zusammenfassung für Eilige

Edge wird klüger: adaptives Bot‑Scoring, bessere Telemetrie, zstd, Bild‑Transcoding am Rand. HTTP/3 setzt sich durch. RPKI hilft beim Routing. Und Post‑Quantum‑TLS steht vor der Tür; ein guter Einstieg ist der PQC‑Überblick.

Kurzfazit: CDNs lösen Latenz und dämpfen Angriffe. Sie sind stark bei L7, gut bei Verteilung, und die Basis für saubere Core Web Vitals. Grenzen liegen bei massiven L3/4‑Fluten und bei personalisiertem HTML ohne Cache‑Strategie. Wählen Sie nach SLO, Peering und Funktionen, nicht nach Folien. Messen Sie laufend. Stimmen Sie Security und UX fein ab. Dann hält die Kante – auch am Montag um 9:01.

Link‑Index nach Abschnitten (Transparenz)

Mini‑Intro: NETSCOUT Threat Report – https://www.netscout.com/threatreport
CDN‑Grundlagen: MDN Glossar – https://developer.mozilla.org/de/docs/Glossary/CDN
L3/4 vs. L7 DDoS: Akamai Security Blog – https://www.akamai.com/blog/security
HTTP/2 Rapid Reset: Imperva Analyse – https://www.imperva.com/blog/http2-rapid-reset-attack/
Basisrisiken: OWASP Top 10 – https://owasp.org/www-project-top-ten/
Core Web Vitals: web.dev – https://web.dev/vitals/
HTTP/3/QUIC: Fastly Blog – https://www.fastly.com/blog/http3-and-quic
Signalaustausch: IETF DOTS (RFC 8612) – https://datatracker.ietf.org/doc/rfc8612/
SLO/SLI: Google SRE Book – https://sre.google/sre-book/service-level-objectives/
Peering: RIPE NCC – https://www.ripe.net/about-us/what-we-do
WAF‑Kontrollen: NIST SP 800‑53 – https://csrc.nist.gov/publications/detail/sp/800-53/rev-5/final
Rate Limiting: Google Cloud Armor – https://cloud.google.com/armor/docs
DSGVO/Cloud‑Sicherheit: ENISA – https://www.enisa.europa.eu/topics/cloud-and-big-data
Datentransfer EU: EDPB – https://edpb.europa.eu/
RUM‑Einstieg: New Relic – https://docs.newrelic.com/docs/browser/new-relic-browser/getting-started/introduction-browser-monitoring/
L3/4‑Schutzbeispiel: AWS Shield – https://aws.amazon.com/shield/
Architekturbeispiel: Azure Front Door – https://learn.microsoft.com/azure/frontdoor/
Ausblick PQC: Cloudflare Blog – https://blog.cloudflare.com/tag/post-quantum/
Branchen‑Beispiel (iGaming‑Review): ParhaatKasinot.biz – https://parhaatkasinot.biz/

Update‑Log

Aktualisiert am: 2026‑08‑18 – Abschnitt zu HTTP/2 Rapid Reset ergänzt; Tabelle um „XML‑RPC/GraphQL Abuse“ erweitert.

News