DDoS-Angriffe erklärt: Häufige Formen und wie Sie sich dagegen schützen

Vorab die Antwort: Keine einzelne Schicht stoppt einen DDoS-Angriff

Ein Distributed-Denial-of-Service-Angriff ist der Versuch, eine Ressource zu erschöpfen, auf die Sie angewiesen sind (Ihre Bandbreite, die Verbindungstabelle Ihres Servers oder die Kapazität Ihrer Anwendung, Anfragen zu beantworten), mit Traffic aus vielen Quellen gleichzeitig. Das Wichtigste zu verstehen ist, dass unterschiedliche Angriffsformen unterschiedliche Ressourcen erschöpfen und eine Verteidigung, die gegen eine Familie wirkt, bei einer anderen nichts bringt:

• Volumetrische Angriffe füllen Ihre Netzwerkanbindung. Sobald Ihr Uplink gesättigt ist, spielt es keine Rolle mehr, was Sie auf dem Server konfigurieren; der Traffic muss upstream absorbiert oder verworfen werden, durch die Mitigation Ihres Hosting-Providers oder einen Scrubbing-Dienst.
• Protokollangriffe (State Exhaustion) füllen die Connection-Tracking-Tabellen von Servern, Firewalls und Load Balancern. Dagegen helfen SYN cookies, sinnvolle Timeouts und Rate Limits, teils auf dem Host selbst, teils an der Edge.
• Angriffe auf Anwendungsebene erschöpfen Ihre Anwendung selbst mit Anfragen, die legitim aussehen. Dafür braucht es Layer-7-Verteidigung: Caching, Rate Limiting, eine WAF oder ein CDN und Application Hardening.

Wirksamer Schutz ist deshalb mehrschichtig: Scrubbing auf Provider-Ebene gegen Volumen, Edge- und Kernel-Einstellungen gegen State-Angriffe, Maßnahmen auf Anwendungsebene gegen Layer 7, dazu eine Firewall-Baseline, die Ihre Angriffsfläche von vornherein verkleinert. Der Rest dieses Artikels behandelt jede Familie im Detail und fügt die Schichten anschließend zu einer praktischen Verteidigung zusammen.

Die drei Familien von DDoS-Angriffen

Security-Anbieter klassifizieren DDoS-Angriffe auf ein Dutzend verschiedene Arten, aber fast alles, was Ihnen in der Praxis begegnet, fällt in drei Familien, unterschieden nach der Ressource, die sie erschöpfen.

Volumetrische Angriffe: die Anbindung verstopfen

Das Ziel ist rohe Gewalt: mehr Traffic senden, als die Leitung tragen kann. Die häufigste Form ist ein simpler UDP flood (bedeutungslose Datagramme mit Line Rate), der laut Telemetrie von Cloudflare Ende 2025 die Liste der Network-Layer-Vektoren anführte, mit einem Wachstum von 231% im Quartalsvergleich.

Die interessantere Variante ist der Reflection-/Amplification-Angriff. Der Angreifer schickt kleine Anfragen an offene Internetdienste (DNS-Resolver, NTP-Server, exponierte memcached-Instanzen) mit einer Quelladresse, die auf Ihren Server gefälscht ist. Diese Dienste "antworten" dann Ihnen, und bei der richtigen Anfrage ist die Antwort um ein Vielfaches größer als die Anfrage selbst. Die klassischen Amplification-Faktoren aus CISAs Advisory zu UDP-basierter Amplification zeigen, warum Angreifer diese Technik so lieben:

Bei memcached kann ein Megabit Upstream-Traffic des Angreifers zu zweistelligen Gigabit-Werten werden, die an Ihrer Adresse ankommen. Reflection-Angriffe sind auch der Grund, warum der Traffic, den Sie während eines Angriffs mitschneiden, oft von Port 53, 123, 389 oder 11211 zu kommen scheint; die Reflektoren sind legitime Server, die auf das antworten, was sie für Ihre Anfragen halten. (Unser ergänzender Leitfaden zum Analysieren eines DDoS-Angriffs mit Wireshark zeigt, wie Sie diese Signaturen in einem Mitschnitt erkennen.)

Ein neueres volumetrisches Muster, das man kennen sollte, ist Carpet Bombing: Statt sich auf eine IP zu konzentrieren, verteilt der Angreifer moderate Volumen über ein ganzes Subnetz oder über Tausende Zielports, bleibt dabei unter den Erkennungsschwellen pro IP und sättigt trotzdem die Gesamtkapazität. NETSCOUT zählte in der zweiten Hälfte von 2025 täglich 750 bis 830 Carpet-Bombing-Angriffe.

Wie groß können volumetrische Angriffe werden? Der öffentliche Rekord ist in einem erstaunlichen Tempo gestiegen: von 3.8 Tbps Ende 2024 über einen Angriff mit 7.3 Tbps im Juni 2025 bis zu einem Angriff mit 31.4 Tbps und 14.1 Milliarden Paketen pro Sekunde im Dezember 2025, angetrieben von Mirai-Abkömmlingen unter den IoT-Botnetzen (Aisuru und seine Ableger), aufgebaut aus gekaperten Routern, Kameras und Android-TV-Boxen. Das sind Rekorde gegen die größten Mitigation-Netzwerke der Welt, keine alltäglichen Ereignisse, aber selbst eine unauffällige Multi-Gigabit-Flood übersteigt den Uplink der meisten einzelnen Server, und genau darum geht es bei der „Upstream zuerst"-Regel im nächsten Abschnitt.

Protokollangriffe: den Verbindungsstatus erschöpfen

Statt roher Bandbreite zielen diese Angriffe auf die Statustabellen, die Server, Firewalls und Load Balancer für jede Verbindung führen.

Der Klassiker ist der SYN flood. Der TCP-Handshake veranlasst den Server, Status zu reservieren, sobald ein SYN eintrifft, während er auf das finale ACK wartet, das nie kommt. Genug halboffene Verbindungen und die Listen-Queue ist voll: Legitime Clients können sich nicht mehr verbinden, obwohl Bandbreite und CPU völlig in Ordnung sind. SYN floods gehören laut Cloudflares Daten immer noch zu den Top drei der Network-Layer-Vektoren, Jahrzehnte nachdem sie erstmals beschrieben wurden; sie sind billig, wirksam und mit gefälschten Quellen leicht zu erzeugen.

Die Standardverteidigung, SYN cookies, kodiert den Verbindungsstatus direkt in die Sequenznummer des SYN-ACK, sodass der Server nichts reserviert, bevor der Handshake abgeschlossen ist. Linux aktiviert sie standardmäßig (net.ipv4.tcp_syncookies = 1), und sie sollten bei jedem mit dem Internet verbundenen Server aktiviert bleiben.

Verwandte in dieser Familie sind ACK/RST floods (Müllpakete, die Conntrack-Lookups erzwingen), Fragmentierungsangriffe (unvollständige Fragmente, die Reassembly-Buffer blockieren) und Connection floods, die den Handshake abschließen und dann untätig verharren, um Slots zu belegen. Zu beachten: Eine Stateful Firewall (einschließlich der Conntrack-basierten Regeln auf Ihrem eigenen Server) ist selbst eine Statustabelle, auf die ein Angreifer zielen kann, was einer der Gründe ist, warum Firewall-Regeln für stark exponierte Server bestimmten Traffic bewusst nicht tracken. Unser Leitfaden zu Standard-Firewall-Regeln beschreibt, wo dieser Kompromiss liegt.

Angriffe auf Anwendungsebene: Anfragen, die legitim aussehen

Layer-7-Angriffe überspringen die Infrastruktur darunter und erschöpfen die Anwendung selbst: HTTP request floods gegen teure Endpoints, Cache-Busting (zufällige Query-Strings, die jede Anfrage bis zum Origin durchzwingen), Slowloris-artige Angriffe, die Verbindungen offenhalten, indem sie Header byteweise senden, und Tricks auf Protokollebene wie HTTP/2 Rapid Reset (CVE-2023-44487), das die Stream-Cancellation missbrauchte, um 2023 Hunderte Millionen Requests pro Sekunde zu erzeugen, bevor Implementierungen Reset-Rate-Kontrollen einbauten.

Das sind die am schwersten zu filternden Angriffe, weil jede einzelne Anfrage für sich genommen gültig ist; die Bösartigkeit steckt im Volumen und in der Verteilung. Moderne HTTP floods stammen überwiegend von Botnetzen und Headless-Browsern, die plausible TLS-Fingerprints und User-Agents vorweisen. Die Mitigation ist entsprechend anwendungsbewusst: aggressives Caching, damit Anfragen nie den Origin erreichen, Rate Limits pro Client und pro Endpoint, eine WAF oder ein CDN, das Clients anhand ihres Verhaltens bewertet, und dafür sorgen, dass Ihre teuren Endpoints (Suche, Login, Report-Erstellung) günstig oder abgesichert sind.

Wie häufig ist das alles?

Häufig genug, dass Sie es als operative Gewissheit behandeln sollten und nicht als Restrisiko. Allein Cloudflare blockierte 2025 47.1 Millionen DDoS-Angriffe, ein Anstieg von 121% im Jahresvergleich, und NETSCOUT zählte weltweit über 16 Millionen Angriffe im Jahresverlauf, mehr als die Hälfte davon multivektoriell: gleichzeitig eingesetzte Kombinationen der oben genannten Familien.

Zwei Statistiken sind für die Planung Ihrer Verteidigung am wichtigsten:

• Angriffe sind kurz. 89% der Network-Layer-Angriffe und 71% der HTTP-Angriffe enden innerhalb von zehn Minuten; selbst der Rekord von 31.4 Tbps dauerte 35 Sekunden. Eine Mitigation, die einen Menschen braucht, der den Angriff bemerkt, ein Ticket öffnet und Scrubbing aktiviert, ist regelmäßig erst fertig ausgerollt, wenn der Angriff schon vorbei ist. Always-on automatisierte Mitigation ist heute der maßgebliche Standard, nicht On-Demand-Scrubbing.
• Angriffe sind multivektoriell. NETSCOUT stellte fest, dass rund 42% der Angriffe zwei bis fünf Vektoren nutzten. Wenn Sie sich gegen eine Familie verteidigen und die anderen ignorieren, verraten Sie dem Angreifer nur, welchen Knopf er drücken muss.

Der Mitigation-Stack, Schicht für Schicht

Betrachten Sie die Verteidigung als vier Schichten, vom Internet nach innen. Jede Schicht stoppt, was die Schichten darunter nicht können.

Schicht 1: Upstream-Mitigation (die einzige Antwort auf Volumen)

Die unausweichliche Physik: Wenn der Angriff größer ist als Ihre Anbindung, kann ihn nur jemand stoppen, der dieser Anbindung vorgelagert ist. Ein Server an einem 10-Gbit/s-Port kann sich nicht aus einer 50-Gbit/s-Flood herausfirewallen; die Pakete haben schon gewonnen, wenn sie die Schnittstelle erreichen, auf der Ihre Regeln laufen.

Upstream-Verteidigungen funktionieren, weil sie über mehr Kapazität und einen besseren Überblick verfügen als jeder einzelne Server:

• Anycast-Absorption und Scrubbing, der Ansatz großer Mitigation-Netzwerke und DDoS-geschützter Hosts: Angriffsverkehr wird zum nächstgelegenen von vielen Standorten gezogen, dünn verteilt, gefiltert, und nur sauberer Traffic wird zugestellt. So wurden die Multi-Terabit-Rekorde absorbiert, autonom und ohne menschliches Eingreifen.
• RTBH (Remotely Triggered Blackhole): ein Werkzeug für Netzbetreiber, das sämtlichen Traffic zu einem Ziel-Prefix am Netzwerkrand verwirft. Es schützt den Rest des Netzwerks, erledigt für den geblackholeten Host aber die Arbeit des Angreifers gleich mit; in der modernen Praxis gilt es als grobe Erstreaktion, die anschließend mit BGP-FlowSpec-Regeln verfeinert wird, die nur die Angriffssignatur (Protokoll, Ports, Paketgröße) statt alles abgleichen und verwerfen.

Als Kunde betreiben Sie das nicht selbst; Sie wählen einen Host oder Mitigation-Provider, der das übernimmt, und stellen sicher, dass der Schutz always-on ist statt reaktiv. Da neun von zehn Angriffen innerhalb von zehn Minuten vorbei sind, steckt in genau diesem Unterschied der größte Teil des Werts.

Schicht 2: Edge-Filtering und Rate Limiting

Zwischen dem Upstream-Scrubber und Ihrer Anwendung liegen Verteidigungen, die wenig kosten und die Mitte des Bedrohungsmodells abschwächen:

• Network-ACLs / Edge-Firewall-Regeln: Wenn Ihr Server nur HTTPS bedient, hat Traffic zu UDP 11211 oder TCP 23 dort nichts verloren. Non-Service-Traffic zu verwerfen, bevor er den Conntrack Ihres Servers berührt, eliminiert ganze Angriffsklassen. Eine Self-Service-Network-Edge-Firewall (die wir auf unseren dedizierten Servern bereitstellen) übernimmt dieses Filtern im Netzwerk, upstream Ihres Ports.
• Rate Limiting pro Quelle: Obergrenzen für neue Verbindungen pro Sekunde und IP fangen den unteren Bereich von Connection floods und Brute-Force-Rauschen ab. Grob, aber wirksam gegen unraffinierte Angriffe; wirkungslos gegen breit verteilte, was in Ordnung ist; dafür sind Schicht 1 und Schicht 4 da.

Schicht 3: der Host selbst

Einstellungen auf dem Host retten Sie nicht vor einer volumetrischen Flood, aber sie entscheiden, wie glimpflich Sie alles Kleinere überstehen:

• SYN cookies aktiviert (bei Linux Standard, prüfen mit sysctl net.ipv4.tcp_syncookies).
• Eine Default-Deny-Firewall-Baseline, sodass nur Ihre tatsächlichen Dienste Traffic annehmen; unser Artikel zu sinnvollen Standard-Firewall-Regeln liefert ein vollständiges, kommentiertes Regelwerk, und wenn Sie noch überlegen, mit welchem Tool Sie es schreiben, siehe iptables vs. nftables.
• Conntrack-Dimensionierung und Timeouts: Erhöhen Sie auf stark ausgelasteten Servern net.netfilter.nf_conntrack_max und verkürzen Sie aggressive Timeouts, damit Müll-Status schnell verfällt, oder nehmen Sie Ihre High-Volume-Serviceports komplett vom Tracking aus.
• Keine unbeabsichtigten Reflektoren. Die Kehrseite der Amplification-Tabelle oben: Stellen Sie sicher, dass nicht Ihr Server derjenige ist, der amplifiziert. Betreiben Sie keinen offenen Resolver, deaktivieren Sie NTP monlist (behoben ab ntpd 4.2.7, aber prüfen Sie alles Ältere), und exponieren Sie memcached niemals über UDP ins Internet.

Schicht 4: Verteidigung auf Anwendungsebene

Für HTTP floods und verwandte Angriffe: Stellen Sie ein CDN oder einen Reverse Proxy mit Caching vor Ihre dynamischen Anwendungen, begrenzen Sie die Rate teurer Endpoints getrennt von günstigen, halten Sie HTTP/2-Implementierungen gepatcht (Rapid Reset und sein Nachfolger aus 2025, „MadeYouReset", werden beide durch aktualisierte Server entschärft), und gestalten Sie so, dass anonyme Anfragen standardmäßig cachefähig sind. Wenn Sie Ihren eigenen Reverse Proxy auf einem dedizierten Server betreiben, decken limit_req und limit_conn von nginx erstaunlich viel ab.

Einen Angriff erkennen: die Signale

Die meisten Angriffe kündigen sich als plötzliche Anomalie in genau einer Ressource an. Beobachtenswert (und alarmwürdig):

• Bandbreite: Eingehender Traffic, der an Ihrer Portgeschwindigkeit klebt, ist die volumetrische Signatur. Wenn Ihr Provider Traffic sowohl vor als auch nach der Mitigation grafisch darstellt, ist die Differenz der Angriff.
• Paketrate: Millionen kleiner Pakete pro Sekunde bei moderater Bandbreite deuten auf Paketraten-Angriffe (SYN/ACK floods) statt auf Bandbreitenangriffe hin.
• Halboffene Verbindungen: Zeigt ss -s synrecv-Werte im vierstelligen Bereich, läuft gerade ein SYN flood.
• Anwendungssättigung bei normaler Systemlast: Worker Pools voll, Antwortzeiten schnellen hoch, aber Netzwerk und CPU unauffällig, die L7-Signatur.
• Quellport-Muster: Eingehende Floods von Port 53/123/389/11211 bedeuten, dass Sie reflektierten Traffic empfangen.

Wenn Sie genau wissen müssen, womit Sie es zu tun haben (um einen FlowSpec-artigen Filter zu schreiben oder Ihrem Provider verwertbare Details zu liefern), schneiden Sie ein Sample mit und analysieren Sie es; das ist das Thema unseres Leitfadens zur DDoS-Analyse mit Wireshark.

Ein Incident-Response-Runbook

Wenn es so weit ist, zählt die Reihenfolge der Schritte mehr als Heldentum:

1. Bestätigen Sie, dass es ein Angriff ist, kein Ausfall und kein Launch. Prüfen Sie, ob der Traffic in seiner Art anomal ist (merkwürdige Ports, verdächtig aussehende Quellen, eine ständig gehämmerte URL) und nicht nur im Volumen.
2. Identifizieren Sie den Vektor: über das Mitigation-Dashboard Ihres Providers oder ein 30-sekündiges Paket-Sample. Die Familie bestimmt die Reaktion: volumetrisch → upstream; State → tunen und Rate-Limit; L7 → cachen und filtern.
3. Aktivieren Sie die Mitigation, die Sie bereits haben. Ist der Schutz Ihres Hosts always-on, prüfen Sie, ob er eingreift (Grafiken mit gescrubbtem Traffic); ist etwas Self-Service (Edge-Firewall-Regeln, Mitigation-Profile), wenden Sie die zum Vektor passende Regel an.
4. Verkleinern Sie Ihre Angriffsfläche mitten im Angriff. Deaktivieren Sie vorübergehend nicht-essenzielle Listener, aktivieren Sie aggressives Caching, stellen Sie teure Endpoints hinter eine Challenge, wenn Sie eine WAF haben.
5. Sprechen Sie mit Ihrem Provider in konkreten Angaben. „SYN flood, ~4 Mpps, gefälschte Quellen, Ziel 203.0.113.10:443" bringt eine nützliche Reaktion deutlich schneller als „wir werden angegriffen".
6. Halten Sie hinterher fest, was funktioniert hat. Angriffe wiederholen sich. Der Filter, der diesen gestoppt hat, sollte ein gespeichertes Profil sein, keine Erinnerung.

Häufig gestellte Fragen

Kann eine Firewall auf meinem Server einen DDoS-Angriff stoppen?

Manche Arten schon, andere nicht, und genau das zu wissen ist der entscheidende Punkt. Eine Firewall auf dem Server dämpft wirksam kleine SYN floods, connection floods und Störverkehr auf Ports, die Sie nicht bedienen. Bei einem volumetrischen Angriff, der Ihren Uplink sättigt, hilft sie nicht: Diese Pakete haben die Leitung vor Ihrer Firewall bereits passiert, das Filtern muss also upstream erfolgen, an der Edge oder der Scrubbing-Schicht Ihres Providers.

Was ist der Unterschied zwischen DoS und DDoS?

Ein DoS-Angriff kommt aus einer einzigen Quelle; das zusätzliche D steht für „distributed" (verteilt): viele Quellen gleichzeitig, heute meist ein IoT-Botnetz oder eine Flotte von Proxys. Diese Verteilung macht die Angriffe sowohl groß (ein Botnetz aus einer Million Android-TV-Boxen erzeugte den aktuellen Rekord von 31.4 Tbps) als auch schwer nach Quelladresse zu filtern, da es keine einzelne Adresse gibt, die sich blockieren lässt; die Mitigation muss sich stattdessen an der Form des Angriffs orientieren.

Wie lange dauern DDoS-Angriffe?

Kürzer, als die meisten erwarten: rund neun von zehn Angriffen auf Netzwerkebene enden innerhalb von zehn Minuten, und selbst Rekordangriffe dauerten weniger als eine Minute. Diese Kürze ist für Angreifer von Vorteil (kurze Ausbrüche entgehen einer On-Demand-Mitigation, die Minuten zum Eingreifen braucht), und deshalb hat Always-on-Schutz das Scrubbing nach dem Prinzip „Rufen Sie uns an, wenn es passiert" als Best Practice verdrängt.

Brauche ich DDoS-Schutz für eine kleine Website?

Ja, in dem Sinne, dass Sie eine Infrastruktur wählen sollten, bei der Schutz bereits inbegriffen ist, statt ihn später als Notlösung einzukaufen. Kleine Websites werden aus wenig glanzvollen Gründen angegriffen: ein verärgerter Nutzer mit einem $20-Abonnement bei einem Booter-Dienst, ein Wettbewerber, oder einfach ein zufälliger Nachbar im falschen Subnetz bei einem Carpet-Bombing-Angriff. Da Angriffe billig zu starten sind und Schutz mittlerweile von guten Hosts ohne Aufpreis mitgeliefert wird, spricht die Wirtschaftlichkeit dafür, ihn zu haben, bevor Sie ihn brauchen.

Bereitstellung bei Serverside

Jeder Server in unserem Netzwerk steht hinter einer always-on DDoS-Mitigation; Angriffe werden automatisch am Netzwerkrand erkannt und gescrubbt, was (wie dieser Artikel hoffentlich deutlich gemacht hat) der einzige Ort ist, an dem sich volumetrische Angriffe stoppen lassen. Darüber hinaus enthalten unsere dedizierten Server eine Self-Service-Firewall am Netzwerkrand, mit der Sie Non-Service-Traffic verwerfen können, bevor er überhaupt Ihren Port erreicht, sowie Self-Service-Mitigation-Kontrollen, um den Schutz auf Ihre Workload abzustimmen. Die Provisionierung dauert unter einer Minute, in unserem eigenen ASN-55285-Netzwerk.

Für die Hälfte der Verteidigung, die auf dem Host selbst stattfindet, beginnen Sie mit unseren Standard-Firewall-Regeln für einen Linux-Server, wählen Ihr Tooling mit iptables vs. nftables und lernen, genau zu identifizieren, was Sie trifft, mit So erfassen und analysieren Sie einen DDoS-Angriff in Wireshark. Wenn Sie eine neue Maschine aufsetzen, behandelt unser Leitfaden zur Linux-Distribution die Wahl des Basis-Betriebssystems.