Zwei Vorfälle können in derselben Statistik als DDoS geführt werden und haben trotzdem fast nichts gemeinsam. Der eine sättigt einen Uplink mit Terabit pro Sekunde an gefälschten UDP-Paketen. Der andere hält von einem einzigen Laptop aus ein paar hundert Sockets offen und sendet wenige Kilobyte pro Minute.

Die Schutzmassnahme, die den ersten stoppt, bekommt den zweiten gar nicht zu sehen. Deshalb lohnt sich eine saubere Taxonomie. Wer Angriffe danach ordnet, wie sie einen Ausfall herbeiführen, und nicht nach ihren Namen, erkennt, welcher Teil des eigenen Stacks im Ernstfall den Ausschlag gibt – und welche Angriffsklasse noch nie unter Last stand.

Dieser Beitrag liefert die Übersicht. Die zehn Simulationstypen, die Obsidio durchführt, stehen unten, gruppiert wie auf der Plattform. Wie Sie einen ersten Durchlauf über die Klassen hinweg aufbauen, zeigt unser Leitfaden DDoS-Schutz testen.

Wie werden DDoS-Angriffe klassifiziert?

Ob jemand von einem DDoS-Angriff oder einer DDoS-Attacke spricht, ändert nichts an der Sache. Entscheidend ist die Einteilung darunter, und die folgt in der Branche den OSI-Schichten. Für den Einstieg taugt das.

Volumetrische Angriffe setzen an Layer 3 und 4 an und versuchen, eine Leitung zu füllen. Protokollangriffe und Zustandserschöpfung sitzen ebenfalls auf Layer 3 und 4, zielen aber auf eine Tabelle statt auf die Leitung. Angriffe auf der Anwendungsschicht spielen sich auf Layer 7 ab, wo jede Anfrage dem Ziel echte Rechenarbeit abverlangt.

Langsame Angriffe sind technisch ebenfalls Layer 7 und werden deshalb oft unter der Anwendungsschicht einsortiert. Im Betrieb ist das ein Fehler.

Ein Flood auf der Anwendungsschicht ist laut: Jede ratenbasierte Schutzmassnahme hat einen Messwert, der ausschlägt. Ein langsamer Angriff sendet weniger Datenverkehr als ein einzelner echter Nutzer und unterläuft genau diese Massnahmen, indem er unter jedem Schwellenwert bleibt, den sie messen. Wer beide in eine Klasse steckt, hält am Ende einen Flood-Test für die Abdeckung beider.

Also vier Klassen: volumetrisch, Protokoll und Zustandserschöpfung, Anwendungsschicht, langsam. Obsidios öffentliche Produktseite gruppiert die zehn Simulationstypen in vier Plattform-Kategorien, die dieser Einteilung eng folgen; DNS-Last und skriptgesteuerte Browser-Last bilden dort eine eigene Gruppe, statt volumetrische Floods als testbar auszuweisen.

Die Vier steht in beiden Fällen für die Gruppierung. Der Katalog selbst umfasst zehn Typen.

Volumetrische Angriffe: Hält Ihre Leitung den Datenverkehr aus?

Einem volumetrischen Angriff ist gleichgültig, was Ihre Applikation tut. Er sendet mehr Bit pro Sekunde, als Ihr Uplink, Ihr Router am Netzrand oder das im Scrubbing-Vertrag zugesicherte Volumen verkraften; alles hinter diesem Engpass ist dann unerreichbar, so einwandfrei es dort auch laufen mag. Der Erfolg bemisst sich in Gigabit oder Terabit pro Sekunde.

Die wichtigsten Techniken dieser Klasse:

• UDP-Flood. Reine UDP-Datagramme an zufällige oder feste Ports, ohne Verbindungsaufbau und ohne Zustand auf der Senderseite. Für den Angreifer billig, und genau deshalb dominant: Cloudflares DDoS-Bedrohungsbericht für das dritte Quartal 2025 führt UDP-Floods als häufigsten Vektor auf der Netzwerkschicht in diesem Quartal, ein Plus von 231 Prozent gegenüber dem Vorquartal.
• ICMP-Flood. Der klassische Ping-Flood. Im selben Cloudflare-Quartal der vierthäufigste Vektor auf der Netzwerkschicht und an einem sauber betriebenen Netzrand weitgehend erledigt.
• Reflection und Amplification. Der Angreifer schickt kleine Anfragen an offene Server Dritter und fälscht dabei Ihre Adresse als Absender; die viel grösseren Antworten treffen dann Sie. DNS, NTP, SSDP, CharGEN und memcached wurden alle so missbraucht. Gefährlich wird die Technik durch die Verstärkungsfaktoren: Cloudflares Analyse der memcached-Angriffe vom 27. Februar 2018 dokumentiert eine Anfrage von 15 Byte, die eine Antwort von 750 Kilobyte auslöste – ein Verstärkungsfaktor von 51’200.
• Carpet Bombing. Statt auf eine einzelne Zieladresse verteilt sich der Datenverkehr dünn über ein ganzes Präfix. Kein einzelner Host überschreitet eine Erkennungsschwelle, die Summe sättigt die Leitung trotzdem.

Die Grössenordnungen dieser Klasse wachsen schnell. Cloudflares Bericht zum vierten Quartal 2025 beschreibt einen Rekordangriff von 31,4 Terabit pro Sekunde, der 35 Sekunden dauerte, und NETSCOUTs DDoS Threat Intelligence Report für das zweite Halbjahr 2025 zählt allein in diesem Zeitraum über 8 Millionen DDoS-Angriffe in 203 Ländern.

Was über den Ausgang entscheidet. Nicht Ihre Server, sondern die Kapazität im Upstream, Ihre Transit-Provider und die Frage, ob Ihr Scrubbing-Anbieter früh genug erkennt und umleitet. Alles, was Sie auf dem Host einstellen, liegt hinter dem Engpass und bleibt für diese Klasse folgenlos.

Testbarkeit. Obsidio stellt weder Angriffe mit gefälschten Absenderadressen noch Reflection nach, und das sollte auch sonst niemand tun. Wer Absenderadressen fälscht und fremde Server auf Ihr Netz richtet, missbraucht Infrastruktur, über die andere verfügen. Dem können Sie nicht zustimmen, und deshalb bieten wir es auch nicht an.

Prüfen lässt sich dagegen der Erkennungs- und Umleitungspfad: ob Ihr Provider den Vorfall bemerkt, wie lange die Umleitung dauert und ob auf Ihrer Seite jemand informiert wird. Ein Teil davon lässt sich mit autorisierter Last auf der Anwendungsschicht beantworten, der Rest gehört in eine Tabletop-Übung mit Ihrem Provider.

Protokollangriffe und Zustandserschöpfung: Wie viele Verbindungen halten Sie?

Diese Klasse zielt nicht auf Ihre Bandbreite. Sie füllt eine Tabelle.

Jede aufgebaute oder halb aufgebaute Verbindung belegt irgendwo einen Platz: einen Kernel-Socket, einen Conntrack-Eintrag, einen File Descriptor, eine Load-Balancer-Session, einen Eintrag im TLS-Session-Cache. Diese Plätze sind endlich und meist deutlich knapper, als man annimmt.

• SYN-Flood. Sendet das erste Paket des TCP-Handshakes und schliesst ihn nie ab; die Backlog-Queue füllt sich mit halboffenen Verbindungen. Nach drei Jahrzehnten immer noch der Referenzangriff dieser Klasse.
• ACK-, RST- und TCP-Flag-Floods. Pakete, die zu keiner bekannten Session gehören und das Ziel zwingen, jedes einzelne in seiner Zustandstabelle nachzuschlagen und über sein Schicksal zu entscheiden. Das Nachschlagen selbst ist die Last.
• TCP Connection Flood. Vollständig aufgebaute Verbindungen, geöffnet und dann untätig gehalten. Ohne Spoofing, denn der Handshake muss zustande kommen. Das ist ein anderer Ausfallmechanismus als beim SYN-Flood, und er unterläuft andere Schutzmassnahmen; deshalb ist der TCP Connection Flood ein eigener Simulationstyp.
• TLS-Handshake-Flood. Schliesst den Handshake vollständig ab, lässt den Server die Kosten der asymmetrischen Kryptografie aufwenden und wirft die Verbindung dann weg. Serverseitig kostet ein Handshake grob das Fünfzehnfache der Clientseite; diese Asymmetrie arbeitet für den Angreifer.
• Fragmentierungsangriffe. Fehlerhafte oder unvollständige IP-Fragmente, die das Ziel zwingen, Reassembly-Puffer für Fragmente vorzuhalten, die nie eintreffen.

SYN-Floods stehen in Cloudflares Bericht zum dritten Quartal 2025 auf Platz drei der Vektoren auf der Netzwerkschicht, hinter UDP- und DNS-Floods; zusammen machen diese vier Vektoren gut die Hälfte aller Angriffe auf der Netzwerkschicht in diesem Quartal aus.

Was über den Ausgang entscheidet. SYN-Cookies, die Dimensionierung von Backlog und Conntrack, Verbindungslimits pro Quelle und die Frage, ob Ihr Load Balancer Verbindungen terminiert oder durchreicht. Ein vorgeschaltetes CDN hilft nur, wenn Ihr Ursprungsserver nicht direkt erreichbar ist.

Testbarkeit. Teilweise. Obsidios TCP Connection Flood und TLS Flood decken den Teil dieser Klasse, der mit vollständig aufgebauten Verbindungen arbeitet, direkt und gründlich ab – von echten, verteilten Geräten aus, sodass Verbindungslimits pro Quelle auf dieselbe Quellenvielfalt treffen wie bei einem echten Angriff. Halboffene SYN-Floods sind eine andere Sache: Sie brauchen gefälschte Absenderadressen und liegen damit ausserhalb dessen, was ein autorisierter Test nachstellen darf.

Angriffe auf der Anwendungsschicht: Was kostet Sie eine einzelne Anfrage?

Auf Layer 7 ändert sich die Rechnung. Jede Anfrage ist gültig, kommt über einen abgeschlossenen TCP- und TLS-Handshake herein und verlangt dem Ziel echte Arbeit ab: eine Query ausführen, eine Seite rendern, eine Session prüfen. Ein paar tausend Anfragen pro Sekunde auf einen Such-Endpunkt können weit mehr Schaden anrichten als das Hundertfache an Paketen auf einen Router.

Von Kundenverkehr sind diese Angriffe auch deshalb schwer zu trennen, weil ihr Verkehr sich technisch nicht davon unterscheidet. In Cloudflares Bericht zum dritten Quartal 2025 stammten knapp 70 Prozent der HTTP-DDoS-Angriffe aus Botnetzen, die Cloudflare bereits kannte; rund 20 Prozent kamen von gefälschten oder Headless Browsern oder wiesen auffällige HTTP-Attribute auf. Der Rest fiel durch nichts auf.

• HTTP-Flood. Wohlgeformte Anfragen mit hoher Parallelität gegen einen echten Endpunkt, gerichtet auf den Verarbeitungspfad und nicht auf das Netz.
• Cache-Busting-Floods. Dieselbe Idee, aber mit zufälligen Query-Strings und wechselnden, browserähnlichen Headern, sodass jede Anfrage am CDN-Cache vorbei bis zum Ursprungsserver durchschlägt. GoldenEye setzt genau dieses Muster um.
• Floods aus echten Browsern. Datenverkehr aus echten Browser-Engines, die Ihr JavaScript ausführen und jede Sub-Ressource nachladen – deshalb helfen die Challenges der Bot-Erkennung deutlich weniger, als ihre Datenblätter versprechen.
• Teure Einzelanfragen. Anfragen, die so gebaut sind, dass der Server pro Anfrage unverhältnismässig viel Arbeit leistet. Apache Killer ist der Musterfall: überlappende Range-Header gegen CVE-2011-3192, sodass eine kleine Anfrage den Server zwingt, die Antwort vielfach im Speicher anzulegen.
• Protokollmissbrauch. HTTP/2 Rapid Reset (CVE-2023-44487), im Oktober 2023 gemeinsam von Cloudflare, Google und AWS offengelegt, öffnete Streams und brach sie sofort wieder ab: Die Arbeit blieb beim Server, der Client tat fast nichts. Cloudflare berichtete, 201 Millionen Anfragen pro Sekunde aus einem Botnetz von rund 20’000 Maschinen abgewehrt zu haben.
• Gezielter Missbrauch einzelner Endpunkte. Login-Seiten, Passwort-Resets, Suche, Warenkorb und Checkout, Berichtsgenerierung, jeder API-Pfad, der in eine Datenbank schreibt. Niedrige Anfrageraten, hohe Kosten je Anfrage.

Was über den Ausgang entscheidet. Wie fein Ihr Rate Limiting greift, das Bot-Management, die WAF-Regeln – und wie weit der Schaden reicht, sobald eine Anfrage angenommen ist. Angriffe auf der Anwendungsschicht erreichen Teile Ihres Systems, die ein Netzwerkangriff nie berührt. Meistens trifft es den Connection Pool der Datenbank.

Testbarkeit. Vollständig. Vier der zehn Simulationstypen von Obsidio gehören in diese Klasse, und Puppeteer Script zeigt zusätzlich, wie sich eine echte User Journey verhält, während das System unter Last steht.

Langsame Angriffe: Was passiert, wenn eine Anfrage nie fertig wird?

Die vierte Klasse dreht jede Annahme um, auf der die anderen drei beruhen. Ein langsamer Angriff sendet so wenig wie möglich, so langsam wie möglich, so lange wie möglich. Die ratenbasierte Abwehr findet nichts zum Zählen, die volumetrische Erkennung sieht keine Spitze, und die Kurve der Anfragen bleibt flach, während der Dienst längst nicht mehr erreichbar ist.

• Slow Headers. Die Request-Zeile senden, danach einzelne Header-Zeilen in grossen Abständen nachschicken und die abschliessende Leerzeile nie senden. Der Server wartet endlos auf das Ende der Request-Header. Das Original-Tool Slowloris erschien am 17. Juni 2009 und funktioniert bis heute, weil das ausgenutzte Verhalten kein Fehler ist.
• Slow Body. Bei einem POST eine korrekte Content-Length ankündigen und den Body dann Byte für Byte nachschicken. Die Header sind vollständig, ein Timeout für das Header-Lesen greift also nicht.
• Slow Read. Eine einwandfreie Anfrage senden und dann aufhören, die Antwort zu lesen: Der eigene Empfangspuffer läuft voll, der Sendepuffer des Servers staut sich. An der Anfrage selbst ist nichts auszusetzen; der Angriff findet auf der Leseseite statt.
• Connection Churn. Gültige Keep-Alive-Anfragen, die untätig bleiben und dann abrupt zurückgesetzt werden – das belastet den Verbindungsabbau und die Buchführung über die Verbindungen, nicht die Kapazität.

Was über den Ausgang entscheidet. Timeouts mit einer Mindestdatenrate statt einer blossen Frist, Verbindungslimits pro Quelle und die Frage, ob Ihr Reverse Proxy Anfragen vollständig puffert, bevor er sie weiterreicht. Über diese Klasse entscheiden Konfigurationswerte in Dateien – und genau deshalb weichen sie mit der Zeit ab.

Testbarkeit. Vollständig, und diese Klasse lohnt den Test am ehesten: Ein Konfigurations-Review sagt Ihnen, dass die Einstellung existiert, aber nichts darüber, ob der Pool hält, wenn viele Verbindungen gleichzeitig offen stehen.

Welche Typen lassen sich tatsächlich testen?

Klarheit nützt hier mehr als ein möglichst langer Funktionskatalog. Für die vier Klassen gilt:

• Direkt testbar mit Obsidios zehn Simulationstypen. Floods auf der Anwendungsschicht einschliesslich Cache-Busting und echtem Browser-Verkehr, Anfrage-Exploits mit Speicherverstärkung, langsame Angriffe in beide Richtungen, die Erschöpfung aufgebauter Verbindungen, TLS-Handshake-Last, DNS-Resolver-Last über TCP und geskriptete User Journeys unter gleichzeitiger Last.
• Teilweise testbar. Erkennung und Eskalation bei volumetrischen Ereignissen. Einen Terabit-Flood mit gefälschten Absendern können Sie nicht autorisieren, aber Sie können herausfinden, ob Ihr Monitoring und Ihr Pikettdienst auf ein echtes, verteiltes Verkehrsereignis überhaupt reagieren. Ob jemand alarmiert wurde, ist ein Befund – unabhängig davon, welche Klasse den Verkehr erzeugt hat.
• Bewusst nicht testbar. Reflection und Amplification über fremde Server sowie jeder Angriff mit gefälschten Absenderadressen, SYN-Floods eingeschlossen. Dafür braucht es Infrastruktur, die Ihnen nicht gehört, und eine Adressfälschung, in die Sie nicht stellvertretend für das übrige Internet einwilligen können. Prüfen Sie diese Punkte über ein Konfigurations-Review, über das Übungsprogramm Ihres Providers und mit einem Blick auf Ihre Filter auf der Netzwerkschicht.

Ein Anbieter, der behauptet, die ganze Taxonomie zu testen, nimmt es entweder mit den Begriffen nicht genau – oder er tut etwas, womit Sie nicht in Verbindung gebracht werden wollen.

Warum zählt die Klasse mehr als der Name?

Angriffsnamen kommen und gehen. Die Klassen bleiben, denn sie beschreiben, welche endliche Ressource ausgeht – und davon gibt es nur wenige.

Praktisch entscheidet die Abdeckung. Ein Team, das einmal im Jahr einen volumetrischen Test fährt, hat einen einzigen Engpass vermessen. Seine Timeouts, seine Verbindungslimits und sein Rate Limiting je Endpunkt bleiben ungeprüft – und jeder dieser Punkte kann für sich allein zum Ausfall führen.

Cloudflares Bericht zum dritten Quartal 2025 hält ausserdem fest, dass 71 Prozent der HTTP-DDoS-Angriffe und 89 Prozent der Angriffe auf der Netzwerkschicht nach weniger als zehn Minuten vorbei sind. Die Frage ist also selten, ob Sie eine lange Belagerung überstehen – sondern ob in den ersten zwei Minuten überhaupt etwas automatisch geschieht.

An der Klasse lässt sich auch ablesen, wo Ihre blinden Flecken liegen. Ein volumetrischer Angriff ist in jedem Ihrer Dashboards sofort zu sehen – über seinen Ausgang entscheidet aber allein Ihr Provider. Ein Flood auf der Anwendungsschicht löst so viele Alarme aus, dass das Signal darin untergeht.

Verbindungserschöpfung zeigt sich nur in Verbindungszählern, die kaum jemand in ein Dashboard aufnimmt, und ein langsamer Angriff lässt gar keine Kurve ausschlagen – oft fehlt sogar der Eintrag im Access-Log. Das sind vier verschiedene Lücken in der Erkennung; wer eine schliesst, hat für die anderen drei nichts getan.

Stärke wird bewiesen, nicht versprochen. Die Taxonomie sagt Ihnen, was Ihnen passieren könnte. Nur eine kontrollierte, autorisierte Simulation gegen die eigene Infrastruktur sagt Ihnen, was tatsächlich passiert.

Wo fangen Sie an, wenn eine Klasse nie geprüft wurde?

Wählen Sie die Klasse, für die Sie am wenigsten Nachweise haben, nicht die, die am bedrohlichsten klingt. In den meisten Organisationen sind das die langsamen Angriffe, gefolgt von der Erschöpfung aufgebauter Verbindungen: Über beide entscheiden Einstellungen, die seit der Installation niemand mehr angesehen hat.

Dann prüfen Sie diese Klasse mit realer Last. Obsidio führt jeden seiner zehn Simulationstypen als kontrollierte, autorisierte Simulation gegen Infrastruktur aus, die Ihnen gehört. Die Domain-Inhaberschaft wird per DNS-TXT-Eintrag geprüft, bevor das erste Paket fliesst; Durchläufe starten mit bewusst niedrig gesetzten Limits und steigern sich schrittweise, und Live-Metriken erlauben den sofortigen Abbruch.

Die Last kommt von über 100’000 weltweit verteilten echten Geräten und nicht von einer Handvoll Instanzen in Rechenzentren. Das ist der Unterschied zwischen dem Test eines Rate Limits pro Quelle und der Frage, ob dieses Limit gegen echte Quellenvielfalt überhaupt etwas ausrichtet. Unser Grundlagen-Leitfaden beschreibt den Zuschnitt eines ersten Programms.

Banken und Finanzdienstleister lagen in Cloudflares Bericht zum dritten Quartal 2025 auf Platz vier der am häufigsten angegriffenen Branchen, und für regulierte Institute muss das Ergebnis eines Durchlaufs den Prüfern vorgelegt werden können; ein Screenshot genügt nicht. Obsidio erzeugt kryptografisch attestierte, manipulationssichere Berichte mit Zuordnung zu FINMA, DORA und NIS2, erstellt in Trusted Execution Environments – ein Test hinterlässt einen Nachweis, den ein Auditor unabhängig prüfen kann.

Wenn Sie autorisierte Simulationen für die Klassen planen möchten, die Ihren Stack betreffen, sehen Sie sich die Obsidio-Plattform an oder nehmen Sie Kontakt mit dem Team auf. Unabhängig, neutral, überprüfbar: Resilienz, die Sie belegen können.