Zwei Vorfälle können in derselben Statistik als DDoS auftauchen und haben trotzdem fast nichts gemeinsam. Der eine sättigt einen Uplink mit Terabits 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, sieht den zweiten gar nicht. Genau deshalb lohnt es sich, die Taxonomie richtig zu verstehen. Wer Angriffe danach sortiert, wie sie einen Ausfall herbeiführen, statt nach Namen, weiss, 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, sind unten aufgeführt und so gruppiert, wie die Plattform sie gruppiert. Wie Sie einen ersten Durchlauf über die Klassen hinweg aufbauen, zeigt unser Leitfaden zum Thema DDoS-Schutz testen.

Wie werden DDoS-Angriffe klassifiziert?

Ob jemand von einem DDoS-Angriff oder einer DDoS-Attacke spricht, macht keinen Unterschied – gemeint ist dasselbe. Entscheidend ist die Einteilung darunter, und der Branchenstandard folgt dabei den OSI-Schichten. Für den Anfang taugt das auch.

Volumetrische Angriffe arbeiten auf Layer 3 und 4 und versuchen, eine Leitung zu füllen. Protokoll- oder State-Exhaustion-Angriffe sitzen ebenfalls auf Layer 3 und 4, zielen aber auf eine Tabelle statt auf die Leitung. Angriffe auf der Anwendungsebene arbeiten auf Layer 7, wo jede Anfrage das Ziel echte Rechenarbeit kostet.

Slow-Angriffe sind technisch ebenfalls Layer 7 und werden oft unter der Anwendungsebene einsortiert. In der Praxis ist das ein Fehler.

Ein Flood auf der Anwendungsebene fällt sofort auf: Ratenbasierte Schutzmassnahmen bekommen einen Messwert, der ausschlägt. Ein Slow-Angriff sendet weniger Verkehr als ein einzelner echter Nutzer und unterläuft diese Schutzmassnahmen, indem er unter jedem Schwellwert bleibt, den sie messen. Wer beide als eine Klasse behandelt, glaubt am Ende, ein Flood-Test habe beide abgedeckt.

Also vier Klassen: volumetrisch, Protokoll- und State-Exhaustion, Anwendungsebene und Slow. Obsidios öffentliche Produktseite gruppiert die zehn Simulationstypen in vier Plattform-Kategorien, die dieser Einteilung eng folgen; DNS- und skriptbasierte Browser-Last bilden dort eine eigene Gruppe, statt dass volumetrische Floods als testbar ausgegeben würden.

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

Volumetrische Angriffe: Hält Ihre Leitung dem Verkehr stand?

Einem volumetrischen Angriff ist egal, was Ihre Applikation tut. Er sendet mehr Bits pro Sekunde, als Ihr Uplink, Ihr Edge-Router oder das im Scrubbing-Vertrag zugesicherte Volumen verkraften, und alles hinter diesem Engpass ist unerreichbar – ganz gleich, wie einwandfrei es läuft. Erfolg wird in Gigabit oder Terabit pro Sekunde gemessen.

Die wichtigsten Techniken dieser Klasse:

• UDP-Flood. Rohe UDP-Datagramme an zufällige oder feste Ports, ohne Verbindungsaufbau und ohne Zustand auf Senderseite. Für den Angreifer billig, und genau deshalb dominant: Cloudflares DDoS-Bedrohungsbericht für Q3 2025 nannte UDP-Floods den häufigsten Vektor auf Netzwerkebene in diesem Quartal, ein Plus von 231 Prozent gegenüber dem Vorquartal.
• ICMP-Flood. Der klassische Ping-Flood. Vierthäufigster Vektor auf Netzwerkebene im selben Cloudflare-Quartal und an jedem kompetent betriebenen Netzrand weitgehend gelöst.
• Reflection und Amplification. Der Angreifer schickt kleine Anfragen an offene Server Dritter, mit Ihrer Adresse als gefälschtem Absender – die viel grösseren Antworten treffen dann Sie. DNS, NTP, SSDP, CharGEN und memcached wurden alle so missbraucht. Gefährlich machen die Technik die Verstärkungsfaktoren: Cloudflares Analyse der memcached-Angriffe vom 27. Februar 2018 dokumentierte eine 15-Byte-Anfrage, die eine Antwort von 750 Kilobyte auslöste – ein Verstärkungsfaktor von 51’200.
• Carpet Bombing. Statt einer einzelnen Zieladresse wird der Verkehr dünn über ein ganzes Präfix verteilt. Kein einzelner Host überschreitet eine Erkennungsschwelle, die Summe sättigt die Leitung trotzdem.

Die Grössenordnungen in dieser Klasse wachsen schnell. Cloudflares Q4-Bericht 2025 beschreibt einen Rekordangriff mit 31,4 Terabit pro Sekunde, der 35 Sekunden dauerte, und NETSCOUTs DDoS Threat Intelligence Report für das zweite Halbjahr 2025 zählte 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 schnell genug erkennt und umleitet. Alles, was Sie auf dem Host konfigurieren, liegt hinter dem Engpass und spielt für diese Klasse deshalb keine Rolle.

Testbarkeit. Obsidio simuliert weder Angriffe mit gefälschten Absenderadressen noch Reflection-Angriffe – und das sollte auch sonst niemand tun. Wer Absenderadressen fälscht und fremde Server auf Ihr Netz richtet, missbraucht Infrastruktur, die anderen gehört. Das können Sie nicht autorisieren – und wir bieten es deshalb auch nicht an.

Testen 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. Teile davon lassen sich mit autorisierter Last auf der Anwendungsebene beantworten, der Rest gehört in eine Tabletop-Übung mit Ihrem Provider.

Protokoll- und State-Exhaustion-Angriffe: 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 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 zu entscheiden, was damit geschieht. Die Last entsteht durch das Nachschlagen selbst.
• TCP Connection Flood. Vollständig aufgebaute Verbindungen, geöffnet und dann untätig gehalten. Kein Spoofing, denn der Handshake muss zustande kommen. Das ist ein anderer Ausfallmechanismus als beim SYN-Flood und unterläuft andere Schutzmassnahmen – deshalb ist TCP Connection Flood ein eigener Simulationstyp.
• TLS-Handshake-Flood. Schliesst den vollständigen Handshake ab, lässt den Server die Kosten der asymmetrischen Kryptografie tragen und wirft die Verbindung dann weg. Die CPU-Kosten pro Handshake liegen serverseitig grob beim Fünfzehnfachen der Clientseite; die Asymmetrie spielt dem Angreifer klar in die Hände.
• Fragmentierungsangriffe. Fehlerhafte oder unvollständige IP-Fragmente, die das Ziel zwingen, Reassembly-Puffer für Fragmente vorzuhalten, die nie ankommen.

SYN-Floods lagen in Cloudflares Q3-Bericht 2025 auf Platz drei der Vektoren auf Netzwerkebene, hinter UDP- und DNS-Floods; zusammen machten diese vier Vektoren gut die Hälfte aller Angriffe auf Netzwerkebene 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 erfordern gefälschte Absenderadressen und liegen damit ausserhalb dessen, was ein autorisierter Test nachstellen kann.

Angriffe auf der Anwendungsebene: Wie viel Arbeit kostet Sie eine einzelne Anfrage?

Auf Layer 7 ändert sich die Kostenrechnung. Jede Anfrage ist gültig, kommt über einen abgeschlossenen TCP- und TLS-Handshake herein und verlangt vom Ziel echte Arbeit: 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.

Diese Angriffe sind auch deshalb so schwer von Kunden zu unterscheiden, weil ihr Verkehr sich technisch nicht von Kundenverkehr unterscheidet. Laut Cloudflares Q3-Bericht 2025 kamen knapp 70 Prozent der HTTP-DDoS-Angriffe von Botnetzen, die Cloudflare bereits kannte; rund 20 Prozent kamen von gefälschten oder Headless-Browsern oder trugen verdächtige HTTP-Attribute. Der Rest fiel durch nichts Besonderes auf.

• HTTP-Flood. Wohlgeformte Anfragen mit hoher Parallelität gegen einen echten Endpunkt, gerichtet auf den Verarbeitungspfad statt aufs Netz.
• Cache-Busting-Floods. Dieselbe Idee, aber mit zufälligen Query-Strings und rotierenden, browserähnlichen Headern, sodass jede Anfrage am CDN-Cache vorbei bis zum Ursprungsserver durchschlägt. GoldenEye setzt genau dieses Muster um.
• Real-Browser-Floods. Verkehr aus echten Browser-Engines, die Ihr JavaScript ausführen und jede Sub-Ressource laden – deshalb helfen Bot-Erkennungs-Challenges deutlich weniger, als ihre Datenblätter versprechen.
• Exploits mit teuren Anfragen. Anfragen, die so gebaut sind, dass der Server pro Anfrage unverhältnismässig viel Arbeit leistet. Apache Killer ist der kanonische Fall: ü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 von abgewehrten 201 Millionen Anfragen pro Sekunde aus einem Botnetz von rund 20’000 Maschinen.
• 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 pro Anfrage.

Was über den Ausgang entscheidet. Die Granularität des Rate Limitings, Bot-Management, WAF-Regeln – und wie weit der Schaden reicht, sobald eine Anfrage angenommen ist. Angriffe auf der Anwendungsebene erreichen Teile Ihres Systems, die ein Netzwerkangriff nie berührt. Meistens trifft es den Connection Pool der Datenbank.

Testbarkeit. Vollständig. Vier von Obsidios zehn Simulationstypen 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.

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

Die vierte Klasse kehrt jede Annahme um, auf der die anderen drei beruhen. Ein Slow-Angriff sendet so wenig wie möglich, so langsam wie möglich, so lange wie möglich. Ratenbasierte Abwehr findet nichts, was sie zählen könnte, volumetrische Erkennung sieht keine Spitze, und die Anfragekurve bleibt flach, während der Dienst längst unerreichbar ist.

• Slow Headers. Die Request-Zeile senden, dann in grossen Abständen einzelne Header-Zeilen nachschieben 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 Bug ist.
• Slow Body. Bei einem POST eine korrekte Content-Length ankündigen und den Body dann Byte für Byte senden. Die Header sind vollständig, ein Timeout fürs Header-Lesen greift also nicht.
• Slow Read. Eine völlig gültige Anfrage senden und dann aufhören, die Antwort zu lesen – der eigene Empfangspuffer läuft voll, der Sendepuffer des Servers staut sich. Die Anfrage selbst ist einwandfrei; 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 Verwaltung der Verbindungstabellen statt der Kapazität.

Was über den Ausgang entscheidet. Timeouts mit einer Mindest-Transferrate 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 schleichen sich mit der Zeit Abweichungen ein.

Testbarkeit. Vollständig, und diese Klasse ist den Test am ehesten wert: Ein Konfigurations-Review sagt Ihnen nur, dass die Einstellung existiert, aber nichts darüber, ob der Pool unter realer Parallelität hält.

Welche Typen lassen sich tatsächlich testen?

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

• Direkt testbar mit Obsidios zehn Simulationstypen. Floods auf der Anwendungsebene inklusive Cache-Busting und echtem Browser-Verkehr, Anfrage-Exploits mit Speicherverstärkung, Slow-Angriffe in beide Richtungen, die Erschöpfung aufgebauter Verbindungen, TLS-Handshake-Last, DNS-Resolver-Last über TCP und geskriptete User Journeys unter paralleler 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 echter 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 Adressfälschung, in die Sie nicht stellvertretend für das ganze Internet einwilligen können. Prüfen Sie diese Punkte per Konfigurations-Review, über das Übungsprogramm Ihres Providers und mit einem Blick auf Ihre Filter auf Netzwerkebene.

Ein Anbieter, der behauptet, die ganze Taxonomie zu testen, nimmt es entweder mit den Begriffen nicht genau – oder tut Dinge, mit denen Sie nichts zu tun haben 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.

In der Praxis 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 pro Endpunkt bleiben dabei ungemessen – und jeder dieser Punkte kann für sich allein zum Ausfall führen.

Cloudflares Q3-Bericht 2025 hielt ausserdem fest, dass 71 Prozent der HTTP-DDoS-Angriffe und 89 Prozent der Angriffe auf Netzwerkebene nach weniger als zehn Minuten vorbei sind. Die Frage ist also selten, ob Sie eine lange Belagerung überstehen würden – sondern ob in den ersten zwei Minuten überhaupt irgendetwas automatisch passiert.

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

Verbindungserschöpfung zeigt sich nur in Verbindungszählern, die kaum jemand in ein Dashboard aufnimmt, und ein Slow-Angriff lässt gar keine Kurve ausschlagen – oft fehlt sogar der Eintrag im Access-Log. Das sind vier verschiedene Lücken in der Erkennung – und 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 getestet wurde?

Wählen Sie die Klasse, für die Sie am wenigsten Belege haben – nicht die, die am bedrohlichsten klingt. Für die meisten Organisationen ist das die Slow-Klasse, gefolgt von der Erschöpfung aufgebauter Verbindungen, denn ü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. Der Domain-Besitz wird per DNS-TXT-Record verifiziert, bevor das erste Paket fliesst; Läufe beginnen mit konservativen Limiten und steigern sich schrittweise, und Live-Metriken erlauben den sofortigen Abbruch.

Die Last kommt von über 100’000 global verteilten echten Geräten statt 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 Q3-Bericht 2025 auf Platz vier der am häufigsten angegriffenen Branchen, und für regulierte Institute muss das Ergebnis eines Laufs 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, generiert in Trusted Execution Environments – ein Test hinterlässt ein Artefakt, das 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.