DDoS-Stresstest: Was er ist, wann er legal ist und wie ein sauberer Durchlauf aussieht

Die meisten Organisationen mit DDoS-Schutz haben nie gesehen, wie er sich in einem echten Angriff verhält. Die Appliance wurde installiert, der Scrubbing-Vertrag unterschrieben, die WAF-Regeln einmal justiert; seither wartet der ganze Stack auf seinen ersten Ernstfall. Cloudflares Threat Report 2026 zählt 47,1 Millionen abgewehrte DDoS-Angriffe im Jahr 2025, mehr als doppelt so viele wie im Vorjahr. Der erste Ernstfall ist damit eine Frage des Wann, nicht des Ob.

Ein DDoS-Stresstest klärt, ob die eigene Abwehr hält, bevor ein Angreifer es tut. Der Begriff hat allerdings zwei Seiten: Dieselben Worte bezeichnen eine legitime, von der Aufsicht erwartete Sicherheitsübung und eine Kategorie krimineller Dienstleistungen. Dieser Beitrag behandelt beide Bedeutungen, denn wo die Grenze verläuft, ist das Erste, was ein Sicherheitsteam, ein Compliance-Verantwortlicher oder ein Auditor wissen will.

Was ist ein DDoS-Stresstest?

Ein DDoS-Stresstest ist eine kontrollierte Simulation eines Distributed-Denial-of-Service-Angriffs gegen Systeme, die Sie besitzen oder betreiben – mit dokumentierter Autorisierung und mit dem Ziel zu messen, ob Ihre Abwehr den Angriff erkennt und auffängt. Der Verkehr ist echt. Die Quellen sind verteilt. Der einzige Unterschied zu einem tatsächlichen Angriff liegt in der Einwilligung, der Steuerbarkeit und einem Bericht am Ende.

Drei Begriffe in dieser Definition sind entscheidend. Kontrolliert heisst: Der Verkehr steigt nach einem Zeitplan, den Sie festlegen, und stoppt in dem Moment, in dem Sie ihn stoppen. Autorisiert heisst: Das Ziel hat überprüfbar nachgewiesen, dass die Infrastruktur ihm gehört. Messen heisst: Am Ende stehen Nachweise – welche Schutzmassnahmen gegriffen haben, welche blind blieben, ab welchem Lastniveau der Dienst einbrach und ob auf Ihrer Seite überhaupt jemand etwas bemerkt hat.

Streichen Sie eines dieser drei Elemente, und es ist kein Stresstest mehr. Verkehr ohne Steuerung ist ein Ausfall, den Sie sich selbst in den Kalender geschrieben haben. Verkehr ohne Autorisierung ist eine Straftat, gleich wer ihn auslöst. Und Verkehr ohne Messung bringt Ihnen nichts, was Sie umsetzen oder einem Auditor vorlegen könnten.

Ist ein DDoS-Stresstest legal?

Die eigene Infrastruktur mit dokumentierter Autorisierung zu testen, ist legal. Rechtlich steht das auf demselben Fundament wie ein Penetrationstest, und die Aufsichtsbehörden sind vom Dulden zum Erwarten übergegangen.

DORA, der Digital Operational Resilience Act der EU, verpflichtet Finanzunternehmen nach Artikel 24, IKT-Systeme, die kritische oder wichtige Funktionen unterstützen, mindestens jährlich zu testen; die Liste der Testarten nennt ausdrücklich szenariobasierte Tests, also genau das, was eine DDoS-Simulation liefert. Die FINMA erwartet von beaufsichtigten Schweizer Instituten, operationelle Resilienz mit Nachweisen zu belegen. NIS2 dehnt vergleichbare Testerwartungen auf wesentliche und wichtige Einrichtungen in der EU aus.

Angriffe auf fremde Infrastruktur sind dagegen in praktisch jeder Rechtsordnung strafbar, und die Dienste, die so etwas verkaufen, werden mit einer gewissen Regelmässigkeit zerschlagen. Booter- und Stresser-Sites – das Angebot, für ein paar Dollar ein beliebiges Ziel zu fluten – sind die Variante von «DDoS-Stresstest», die vor Gericht endet. Europol gab am 11. Dezember 2024 bekannt, dass die Operation PowerOFF, eine mehrjährige internationale Aktion gegen DDoS-Mietdienste, 27 der populärsten Plattformen in 15 Ländern vom Netz genommen hatte; drei Administratoren wurden in Frankreich und Deutschland verhaftet.

Was dabei oft übersehen wird: Die Strafverfolgung endet nicht bei den Betreibern. In derselben Aktion vom Dezember 2024 wurden über 300 Nutzer der beschlagnahmten Plattformen für weitere Massnahmen identifiziert, die niederländische Staatsanwaltschaft klagte vier Personen wegen Angriffen an, die über Booter liefen, und das US-Justizministerium erhob Anklage gegen Plattform-Administratoren. Mehrere nationale Polizeibehörden schalteten sogar Suchmaschinenanzeigen auf einschlägige Booter-Suchbegriffe: Wer heute nach einem solchen Dienst sucht, findet eine Warnung, wo früher der Shop stand.

Die Grenze, die das Recht zieht, verläuft entlang von Autorisierung und Inhaberschaft, sonst nirgends. Eine Bank, die eine Simulation mit 200’000 Anfragen pro Sekunde gegen ihr eigenes E-Banking-Portal beauftragt, mit Freigabe aus dem Change Management und unterschriebenem Prüfumfang, tut, was ihre Aufsicht verlangt. Eine Privatperson, die dafür bezahlt, einen Bruchteil dieses Verkehrs auf einen fremden Server zu richten, begeht eine Straftat. Dieselben Pakete, entgegengesetzte Rechtsfolgen.

Deshalb ist der Autorisierungsschritt in einem legitimen Test auch keine Formsache. Ein Anbieter, der Verkehr überallhin schickt, wohin der Kunde zeigt, ist ein Booter mit Rechnung. Ein Anbieter, der kein einziges Paket sendet, bevor die Domain-Inhaberschaft kryptografisch nachgewiesen ist, hat den Missbrauch strukturell ausgeschlossen – und genau diese Eigenschaft wollen Sie einem Auditor zeigen.

Worin unterscheidet sich ein Stresstest von einem Lasttest?

Viele Teams nehmen an, ihre Lasttests deckten dieses Feld bereits ab. Sie tun es nicht, und die Lücke lohnt eine genaue Betrachtung, denn hier entstehen teure Fehlannahmen.

Ein Lasttest beantwortet eine Kapazitätsfrage: Wie viele Nutzer mit normalem Verhalten verkraftet das System, bevor die Antwortzeiten einbrechen? Der Verkehr ist von der Anlage her legitim. Er folgt dem vorgesehenen Pfad, schliesst jede Anfrage ab, verwendet Verbindungen ordentlich wieder und kommt von einer Handvoll Cloud-Instanzen, die Ihre Firewall vermutlich auf der Ausnahmeliste führt.

Ein DDoS-Stresstest beantwortet eine Abwehrfrage: Was passiert, wenn der Verkehr darauf ausgelegt ist, Schaden anzurichten? Angriffsverkehr verhält sich so, wie sich legitime Nutzer nie verhalten. Er hält Verbindungen offen, ohne Anfragen abzuschliessen, umgeht Caches mit zufälligen Query-Strings, beansprucht die CPU mit Handshakes, die er nie nutzt, oder trifft als vollständige, gültige Anfrage von Zehntausenden Quellen gleichzeitig ein. Jedes dieser Verhalten setzt an einer anderen Schicht an, und keines davon taucht in einem Lasttest auf.

Die Folge: Die beiden Tests fördern Unterschiedliches zutage. Ein Lasttest findet einen zu knapp dimensionierten Datenbank-Pool oder einen langsamen Endpunkt. Ein Stresstest findet heraus, dass Ihr Rate Limiter Anfragen pro Sekunde als Schlüssel verwendet, während der Angriff fast keine sendet; dass Ihr Scrubbing-Anbieter zwölf Minuten brauchte, bis er eingriff; oder dass Ihre Dashboards während des gesamten Ausfalls unauffällig aussahen. Unser Beitrag zu den Arten von DDoS-Angriffen zeigt, warum jede Angriffsklasse eine andere Schutzmassnahme aushebelt – und der Grössenrekord klettert weiter: Der grösste Angriff in Cloudflares Threat Report 2026, eine Flut von 31,4 Terabit pro Sekunde aus dem Aisuru-Botnetz Ende 2025, war fast sechsmal so gross wie der grösste Angriff von 2024.

Ein weiterer Unterschied betrifft den Realismus. Lastgeneratoren laufen in wenigen Rechenzentrums-IP-Bereichen, die Limits pro IP und Reputationsfilter mühelos erkennen. Echte Angriffe kommen aus Botnetzen mit Zehntausenden Geräten in Privathaushalten und Mobilfunknetzen. Ein Test aus drei Cloud-Instanzen bestätigt Ihre Abwehr gegen drei Cloud-Instanzen und sonst nichts.

Das ist das Problem des trügerischen «Bestanden», und es ist der häufigste Weg, auf dem eine billige Prüfung zu einem gefährlichen Schluss führt. Unser Grundlagenbeitrag zum Testen des DDoS-Schutzes behandelt es im Detail.

Wie läuft ein autorisierter DDoS-Stresstest konkret ab?

Ein legitimer Test hat eine wiedererkennbare Form. Wer Anbieter prüft oder intern für einen ersten Testlauf argumentiert, sollte diese Schritte vorfinden. Fehlt einer, ist das ein Befund über den Anbieter.

Zuerst der Prüfumfang

Sie legen fest, welche Domains und Dienste zum Prüfumfang gehören, welche Simulationstypen laufen, wie hoch der Verkehr maximal steigt, in welchem Zeitfenster der Durchlauf stattfindet und wer auf Ihrer Seite zuschaut. Ebenfalls vorab definiert: die Abbruchkriterien – ab welchem Punkt der Durchlauf stoppt, auch wenn niemand den Knopf drückt. Regulierte Institute führen das in der Regel durchs Change Management, und genau diese Dokumentation macht die Übung später prüffähig.

Nachweis der Inhaberschaft: kryptografisch statt vertraglich

Bevor Verkehr fliesst, weisen Sie nach, dass das Ziel Ihnen gehört. Auf der Obsidio-Plattform geschieht das über einen DNS-TXT-Eintrag: Sie hinterlegen ein Verifikationstoken in der DNS-Zone der zu testenden Domain – das kann nur, wer administrativ über diese Domain verfügt. Kein Token, kein Verkehr. Eine Unterschrift unter einem Vertrag behauptet die Inhaberschaft; ein DNS-Eintrag weist sie nach. Dieser eine Schritt trennt eine Plattform, die mit der Autorisierung beginnt, von einem Booter: Er macht es strukturell unmöglich – nicht bloss verboten –, den Verkehr auf Dritte zu richten.

Schrittweises Hochfahren, Live-Metriken, sofortiger Abbruch

Ein sauberer Durchlauf beginnt nicht bei voller Stärke. Er startet in einem kontrollierten Fenster mit bewusst niedrig gesetzten Limits und steigert sich, während Sie Echtzeit-Metriken verfolgen: Anfragen pro Sekunde, Erfolgsquote, übertragene Datenmenge und die Reaktion Ihrer Infrastruktur am Netzrand. Jeder Durchlauf lässt sich live abbrechen, in jeder Sekunde. Diese Kombination aus Rampe und Abbruch macht aus einem simulierten Angriff ein kontrolliertes Experiment. Sie finden das Niveau, ab dem die Degradation einsetzt, ohne sie aussitzen zu müssen.

Ein Bericht, den Sie einem Auditor vorlegen können

Am Ende steht ein Nachweis, kein Screenshot. Obsidio erzeugt kryptografisch attestierte Berichte, bei denen jede nachträgliche Änderung erkennbar wäre, erstellt in Trusted Execution Environments und zugeordnet zu den Erwartungen von FINMA, DORA und NIS2. Der Unterschied wiegt schwerer, als er zunächst wirkt: Ein attestierter Bericht ist ein Beleg, den Dritte überprüfen können. Ein internes Testprotokoll ist eine Behauptung, für die Ihr eigenes Team geradestehen muss. Auditoren kennen den Unterschied.

Was sollte ein Stresstest abdecken?

Ein einzelner Testtyp ist keine Abdeckung. Angriffsklassen setzen an grundverschiedenen Stellen an, und eine Abwehr, die auf eine Klasse eingestellt ist, kann für eine andere strukturell blind sein. Eine volumetrische Flut fordert Bandbreite und Scrubbing; ein langsamer Angriff wie Slowloris sendet fast keinen Verkehr und läuft an jeder ratenbasierten Massnahme vorbei; ein TLS-Flood beansprucht die CPU mit Handshakes, die er nie nutzt; eine Flut echter Browser-Sitzungen hebelt die Bot-Erkennung aus, weil es keinen Bot zu erkennen gibt.

Obsidio führt zehn Simulationstypen in vier Kategorien durch: Floods auf der Anwendungsschicht, langsame Angriffe, Verbindungserschöpfung sowie protokollspezifischen oder skriptgesteuerten Verkehr. Ein vernünftiges erstes Programm fährt nicht alle zehn auf einmal. Es beginnt mit den Klassen, die für Ihre Architektur am wichtigsten sind, und erweitert dann. Die Übersicht der Angriffstypen erklärt, welche Klasse welche Schicht belastet; die Produktseite listet den vollständigen Katalog.

Die Abdeckung hat eine zweite Achse, die Teams gern vergessen: die Erkennung. Jeder Durchlauf sollte nicht nur beantworten, ob die Abwehr gehalten hat, sondern auch, ob es jemand gemerkt hat. Ob Ihre Dashboards ausgeschlagen haben, ob das SIEM etwas protokolliert hat und ob der Pikettdienst alarmiert wurde – diese Antworten stehen auf Ihren eigenen Konsolen, also muss während des Fensters jemand auf Ihrer Seite hinschauen. Eine Massnahme, die still versagt, und eine, die unsichtbar funktioniert, sind beides Befunde.

Wie oft sollten Sie testen?

Ein einzelner Test ist eine Momentaufnahme, und Infrastruktur steht nicht still. Der CDN-Vertrag wird neu verhandelt, jemand lockert ein Timeout, um eine Kundenbeschwerde aus der Welt zu schaffen, eine neue API geht ausserhalb der WAF-Policy live. Jede dieser Änderungen kann ein Ergebnis, das vor sechs Monaten noch stimmte, unbemerkt entwerten.

Für regulierte Finanzunternehmen ist die Untergrenze extern gesetzt: DORA erwartet, dass IKT-Systeme, die kritische oder wichtige Funktionen unterstützen, mindestens jährlich getestet werden – unser Leitfaden zur DORA-Compliance beschreibt, welche Nachweise dieses Testen liefern muss. Behandeln Sie das als Minimum, nicht als Ziel.

Jenseits der regulatorischen Untergrenze zählen zwei Auslöser mehr als der Kalender. Testen Sie erneut, nachdem Sie etwas behoben haben: Eine Gegenmassnahme, die unter Druck konfiguriert und nie geprüft wurde, ist genau die Art Massnahme, die ein zweites Mal versagt. Und testen Sie erneut nach wesentlichen Änderungen am Netzrand – ein neues CDN, eine Migration, ein neuer öffentlich erreichbarer Dienst. Die Plattform folgt bewusst einem Zyklus, «Konfigurieren. Testen. Anpassen. Erneut testen.», weil sich erst im zweiten Durchlauf zeigt, ob der erste etwas verändert hat.

Was findet ein Stresstest, das ein Konfigurations-Review nicht findet?

Ein Konfigurations-Review stellt fest, dass Einstellungen vorhanden sind. Es kann nicht feststellen, ob diese Einstellungen halten, wenn viele Anfragen gleichzeitig eintreffen, ob Herstellerangaben den Kontakt mit realistischem Verkehr überstehen oder ob das Zusammenspiel von CDN, Load Balancer und Ursprungsserver sich so verhält, wie das Diagramm es behauptet. Diese Eigenschaften zeigen sich nur unter echtem Verkehr.

Die typischen Befunde eines ersten autorisierten Tests lauten selten «der Schutz fehlt». Sie sind leiser – und teurer.

Der Scrubbing-Dienst griff ein, aber erst Minuten nach Beginn der Degradation. Der Rate Limiter funktionierte und drosselte dabei auch den Zahlungs-Callback eines Partners. Das Failover funktionierte, und die Failover-Umgebung hatte ein Viertel der Produktionskapazität. Das Auto-Scaling skalierte, und die Rechnung kam. Nichts davon steht in einem Konfigurations-Review, und jeder einzelne Befund ändert, was Sie als Nächstes tun.

Stärke wird bewiesen, nicht versprochen. Der Kauf von DDoS-Schutz belegt, was Sie ausgegeben haben. Ein Stresstest belegt, was Sie aushalten.

Dazu kommt der organisatorische Befund. Ein Angriff um drei Uhr morgens fordert Menschen genauso wie Technik, und der erste autorisierte Durchlauf ist meist das erste Mal, dass der Eskalationspfad von Anfang bis Ende durchgespielt wird. Dass im Runbook eine Person steht, die letztes Jahr gegangen ist, kostet in einem geplanten Fenster wenig. Während eines echten Angriffs kostet es sehr viel.

Wo Sie anfangen

Fangen Sie klein und sauber an. Wählen Sie einen Dienst, holen Sie die Freigabe ein, weisen Sie die Inhaberschaft nach und fahren Sie eine Angriffsklasse in bewusst engem Umfang, in einem Fenster, das Ihr Team beobachtet. Beim ersten Durchlauf geht es weniger um die erreichte Last als darum zu belegen, dass der Zyklus funktioniert: autorisieren, konfigurieren, simulieren, berichten. Jeder spätere Durchlauf wird schneller und ambitionierter.

Obsidio führt DDoS-Stresstests als kontrollierte, autorisierte Simulationen von über 100’000 weltweit verteilten echten Geräten aus; Limits pro IP und Reputationsfilter werden also so geprüft, wie ein tatsächlicher verteilter Angriff sie prüfen würde. Die Domain-Inhaberschaft wird per DNS-TXT-Eintrag verifiziert, bevor eine einzige Anfrage gesendet wird, Durchläufe werden schrittweise hochgefahren, jeder Durchlauf lässt sich live abbrechen, und am Ende steht ein kryptografisch attestierter Bericht, zugeordnet zu FINMA, DORA und NIS2.

Um einen autorisierten Stresstest gegen Ihre eigene Infrastruktur zu planen, besuchen Sie die Obsidio-Plattform oder nehmen Sie Kontakt mit dem Team auf. Unabhängig, neutral, überprüfbar: Resilienz, die Sie belegen können.