Was ist ein DDoS-Angriff?

Ein Distributed Denial-of-Service-Angriff (DDoS-Angriff) ist ein böswilliger Versuch, die normale Verfügbarkeit eines Servers, Dienstes, Netzwerks oder einer Infrastruktur zu stören, indem er mit einer Flut von Internetverkehr überlastet wird. Im Gegensatz zu einem einfachen DoS-Angriff (Denial-of-Service), der von einem einzelnen System ausgeht, nutzt ein DDoS-Angriff eine Vielzahl kompromittierter Computersysteme – ein sogenanntes Botnetz – als Angriffsquelle. Diese verteilte Natur macht die Angriffe viel mächtiger und schwerer abzuwehren. DDoS-Schutz ist eine Kernfunktion von Infrastrukturdiensten wie Cloudflare, die als Puffer zwischen dem Angriff und dem geschützten Origin Server fungieren. Die jüngsten Cloudflare-Störungen haben jedoch ein paradoxes Szenario aufgezeigt: Während Cloudflare zum Schutz vor DDoS-Angriffen dient, kann ein interner Fehler in dessen globaler Plattform ähnlich verheerende Auswirkungen haben – und das System selbst zu einem unbeabsichtigten, globalen Single Point of Failure (SPOF) machen.

Arten von DDoS-Angriffen

DDoS-Angriffe zielen auf verschiedene Schichten des Netzwerk- und Anwendungsstacks ab. Die gängigsten Typen sind:

1. Volumetrische Angriffe (Layer 3 & 4)

Ziel ist die Überflutung der Netzwerkbandbreite oder der Infrastruktur des Ziels.

• UDP-Floods: Senden einer großen Anzahl von UDP-Paketen (z.B. über DNS- oder NTP-Reflexion) an zufällige Ports des Ziels.
• ICMP-Floods (Ping Floods): Überlastung des Ziels mit ICMP Echo-Request-Paketen (Pings).
• DNS-Amplification: Ein besonders tückischer Angriff, bei dem kleine Anfragen an offene DNS-Server gesendet werden, die mit sehr großen Antworten an die Ziel-IP antworten („Amplification“).

2. Protokollangriffe (Layer 3 & 4)

Sie nutzen Schwächen in Protokollen aus, um Serverressourcen zu erschöpfen.

• SYN-Flood: Der Angreifer sendet eine Flut von TCP-SYN-Paketen (Verbindungsanfragen), antwortet aber nie auf die SYN-ACK-Antworten des Servers. Dadurch bleiben halboffene Verbindungen bestehen und blockieren Ressourcen.
• Ping of Death: Senden manipulierter, überdimensional großer ICMP-Pakete, die das Zielsystem zum Absturz bringen können.
• Slowloris: Hält möglichst viele Verbindungen zum Zielserver offen, indem nur sehr langsam HTTP-Header gesendet werden. Dies erschöpft die maximale Anzahl gleichzeitiger Verbindungen des Servers.

3. Anwendungsschicht-Angriffe (Layer 7)

Diese Angriffe zielen direkt auf Webanwendungen (HTTP/HTTPS) und sind besonders schwer von legitimem Traffic zu unterscheiden.

• HTTP-Flood: Eine Flut von HTTP-GET- oder POST-Anfragen, die ressourcenintensive Seiten oder Aktionen aufrufen (z.B. Suchanfragen, Login-Versuche). Sie können von einfachen Bots oder komplexen Botnetzen durchgeführt werden.
• Zielgerichtete Angriffe auf APIs: Überlastung von API-Endpunkten, die für Mobile Apps oder Partnerintegrationen kritisch sind.
• Low-and-Slow-Angriffe: Ähnlich wie Slowloris, aber auf Anwendungsebene, z.B. durch extrem langsames Lesen einer herunterladbaren Datei.

Wie DDoS-Schutz funktioniert: Die Rolle von Cloudflare

Dienste wie Cloudflare agieren als eine Art „Schutzschild“ oder „Waschmaschine“ für bösartigen Traffic. Ihre Funktionsweise basiert auf mehreren Prinzipien:

1. Anycast-Netzwerk und hohe Kapazität: Cloudflare betreibt ein globales Anycast-Netzwerk. Jede ihrer IP-Adressen wird von allen Rechenzentren weltweit aus advertiert. Angriffstraffic wird so automatisch auf das gesamte, extrem kapazitätsstarke Netzwerk verteilt und „verdünnt“. Dies allein kann viele volumetrische Angriffe absorbieren.

2. Intelligente Filterung und Analyse: An der „Edge“ des Netzwerks (in den Points of Presence) analysieren Maschinenlernmodelle und Regelwerke den eingehenden Traffic in Echtzeit.

   • Reputationsdatenbanken: Bekannte bösartige IP-Adressen und Botnetze werden blockiert.
   • Verhaltensanalyse: Abweichungen vom normalen Traffic-Muster werden erkannt (z.B. plötzlicher, massiver Traffic aus einer Region).
   • Challenge-Mechanismen: Verdächtiger Traffic wird mit JavaScript-Challenges oder Captchas konfrontiert. Echte Browser/Benutzer bestehen diese, einfache Bot-Skripte scheitern.

3. Absorbtion und Weiterleitung von sauberem Traffic: Nur der als „sauber“ eingestufte Traffic wird durch das Cloudflare-Netzwerk an den Origin Server des Kunden weitergeleitet. Der Großteil des Angriffstraffics wird bereits an der Edge verworfen.

4. Verstecken der Origin-IP: Eine der wichtigsten Schutzmaßnahmen ist das Verbergen der echten IP-Adresse des Origin Servers. Alle Anfragen gehen an die IPs von Cloudflare. Dies macht es für Angreifer sehr viel schwerer, das eigentliche Ziel direkt zu attackieren.

Das Paradoxon: Wenn der Beschützer zum Problem wird

Die Cloudflare-Störungen der Vergangenheit haben eine beunruhigende Wahrheit offengelegt: Die zentrale Infrastruktur, die zum Schutz vor DDoS-Angriffen aufgebaut wurde, kann selbst zur Ursache einer internetweiten Dienstunterbrechung werden – mit ähnlichen Symptomen wie ein massiver Angriff.

• Interne Fehler statt externer Angriffe: Die Ausfälle wurden nicht durch externe DDoS-Angriffe verursacht, sondern durch interne Konfigurationsfehler, Software-Bugs oder Probleme bei Routinen im globalen Netzwerk.
• Globale Auswirkungen: Ein Fehler in einem so zentralisierten System wie Cloudflare trifft nicht ein einzelnes Ziel, sondern alle Kunden gleichzeitig, die diese Infrastruktur nutzen. Dies verwandelt den Schutzschild in einen massiven Single Point of Failure (SPOF).
• Symptom-Ähnlichkeit: Für Endnutzer und betroffene Unternehmen fühlte es sich an wie ein Ausfall ihrer eigenen Dienste oder ein großflächiger Angriff – tatsächlich war jedoch die vorgeschaltete Zugangsschicht blockiert.

Strategien für umfassenden Schutz und Resilienz

Die Lehre daraus ist, dass sich Unternehmen nicht allein auf einen externen DDoS-Schutzdienst verlassen sollten, sondern eine mehrschichtige Resilienzstrategie verfolgen müssen:

1. Basis-Schutz durch einen Cloud-Anbieter: Die Nutzung eines Anbieters wie Cloudflare, Akamai oder AWS Shield ist der wichtigste und effektivste erste Schritt. Er schützt vor den allermeisten Angriffen.
2. Überwachung und Alarmierung: Implementieren Sie ein eigenes, externes Monitoring, das die Verfügbarkeit Ihrer Dienste sowohl über das CDN als auch direkt über die Origin Server-IP testet. So erkennen Sie, ob ein Problem bei Ihrem Anbieter oder bei Ihnen liegt.
3. Vorbereitung auf den Anbieter-Ausfall: Entwickeln Sie einen Notfallplan für den Fall, dass Ihr primärer DDoS-Schutzanbieter selbst ausfällt.
   • DNS-Failover als Notfallventil: Konfigurieren Sie einen DNS-Failover-Dienst, der bei Ausfall der Cloudflare-Route automatisch auf eine Backup-Infrastruktur umschaltet. Dies könnte eine direkte Verbindung zu Ihrem Origin Server (der dann dem vollen Traffic ausgesetzt ist) oder ein sekundäres CDN bei einem anderen Anbieter sein.
   • Capacity Planning für den Origin: Ihr Origin Server oder Ihr Backup-Hosting sollte kurzfristig in der Lage sein, den gesamten Traffic ohne den CDN-Puffer zu verarbeiten, auch wenn die Performance leidet.
4. Eigenständige Sicherheitsmaßnahmen: Ergänzen Sie den Cloud-Schutz durch eigene Maßnahmen:
   • Rate Limiting / Throttling auf Anwendungsebene (z.B. in Ihrer Webanwendung oder API-Gateway).
   • Strikte Firewall-Regeln auf Server-Ebene.
   • Regelmäßige Sicherheitsaudits und Penetrationstests.
5. Klare Incident Response-Prozesse: Definieren Sie im Voraus, wer im Falle eines Angriffs oder eines Anbieterausfalls was tut. Wer kommuniziert mit Kunden? Wer aktiviert den Failover?

Fazit

DDoS-Angriffe bleiben eine der größten Bedrohungen für die Online-Verfügbarkeit. Die Nutzung eines spezialisierten Anbieters wie Cloudflare ist eine kluge und notwendige Verteidigungsstrategie. Doch die Ereignisse der jüngeren Vergangenheit zwingen zu einem umfassenderen Denken.

Die eigentliche Herausforderung besteht heute nicht mehr nur darin, sich vor externen Angreifern zu schützen, sondern auch die Resilienz gegenüber Ausfällen in der eigenen, oft externen Infrastrukturkette zu erhöhen. Ein robustes digitales Geschäft plant daher nicht nur für den Angriff von außen, sondern auch für den potenziellen Ausfall seiner eigenen Verteidigungslinie. Es kombiniert den starken Schutz eines Cloud-Dienstes mit strategischen Notfallventilen wie DNS-Failover, um auch dann handlungsfähig zu bleiben, wenn der zentrale Schutzschild – vorübergehend – versagt.