Die meisten Teams lernen die Grenzen ihres DDoS-Schutzes erst während eines echten Angriffs kennen. Das ist der denkbar schlechteste Zeitpunkt, um festzustellen, dass eine WAF-Regel zu locker war oder ein Origin-Server nie abgeschirmt wurde. Zu wissen, wie Sie Ihren DDoS-Schutz vor einem Vorfall testen, ist der Unterschied zwischen einem kontrollierten Befund und einem öffentlichen Ausfall.

Dieser Leitfaden richtet sich an die Menschen, die dieses Risiko in einem regulierten Institut verantworten: Security-Engineers, Betreiber von WAF und Load Balancern sowie Compliance-Verantwortliche, die Resilienz gegenüber einer Aufsichtsbehörde nachweisen müssen. Er zeigt, was ein sauberer Test misst, wie Sie ihn durchführen, ohne sich selbst offline zu nehmen, und wie Sie das Ergebnis in prüffähige Nachweise verwandeln.

Was das Testen Ihres DDoS-Schutzes wirklich bedeutet

Ein DDoS-Test sendet kontrollierten, realistischen Angriffsverkehr an eine Infrastruktur, die Ihnen gehört, und misst dann, ob Ihre Abwehr ihn absorbiert und wie sich Ihr Dienst unter Last verhält. Ziel ist nicht, die Website lahmzulegen. Ziel ist, den Punkt zu finden, an dem der Schutz nachgibt, damit Sie ihn nach Ihrem eigenen Zeitplan beheben können.

Zwei Dinge ist er nicht:

• Er ist kein Booter oder Stresser. Solche Dienste feuern anonymen Traffic auf beliebige Ziele. Sie sind illegal, sobald sie auf etwas gerichtet werden, das Ihnen nicht gehört, und liefern keine Messung, keinen Autorisierungsnachweis und keinen Bericht.
• Er ist kein gewöhnlicher Lasttest. Ein Lasttest fragt: „Können wir 10.000 legitime Nutzer bedienen?” Ein DDoS-Test fragt: „Was passiert, wenn der Verkehr feindlich, fehlerhaft oder gezielt darauf ausgelegt ist, eine Ressource zu erschöpfen, die unser Lasttest nie berührt?” Anderer Verkehr, andere Fehlerbilder.

Der Wert liegt in der Genauigkeit. Ein guter Test sagt Ihnen, welche Schicht versagt hat, bei welchem Volumen und ob Ihre Mitigation rechtzeitig ausgelöst hat.

Autorisierung kommt vor dem ersten Paket

Die eine Regel, die legitimes Resilienztesting von einem Angriff trennt, ist die Autorisierung. Sie testen nur Assets, die Ihnen gehören oder für die Sie ausdrücklich beauftragt sind, und Sie weisen dieses Eigentum nach, bevor Verkehr fließt.

Obsidio erzwingt das über eine DNS-TXT-Eigentumsverifizierung. Sie hinterlegen einen Eintrag auf der Domain, die Sie testen wollen, und keine Simulation startet, bevor dieser Eintrag bestätigt ist. Läufe sind kontrolliert, werden schrittweise hochgefahren und lassen sich live abbrechen. Das macht die Übung für eine Rechtsabteilung vertretbar und für eine Compliance-Akte wiederholbar: Die Autorisierung ist dokumentiert, nicht unterstellt.

Behandeln Sie das als die erste Kontrolle, die Sie testen, nicht als Formalie. Wenn Ihr eigener Change-Management-Prozess keine unterschriebene, zeitlich begrenzte Autorisierung für einen Test hervorbringt, wird er das auch für einen Vorfall nicht tun.

Die Angriffstypen, gegen die es sich zu testen lohnt

DDoS ist nicht eine einzige Sache, und ein Schutz, der eine Klasse abwehrt, kann für eine andere blind sein. Ein Testprogramm sollte die verschiedenen Arten durchspielen, auf die ein Dienst versagt. Der Simulationskatalog von Obsidio umfasst vier Kategorien, die jeweils einen anderen Teil Ihres Stacks belasten:

• Angriffe auf der Anwendungsschicht (Layer 7). HTTP Flood treibt hohe Mengen wohlgeformter Anfragen gegen den Anwendungspfad: die Request-Queue, die Anwendungs-Threads und die dahinterliegende Datenbank. Goldeneye hängt zufällige Query-Strings an, sodass jede Anfrage den Cache umgeht und den Origin erreicht, mit rotierenden browserähnlichen Headern. Browser Flood nutzt echte Browser-Sitzungen, die die vollständige Seite samt aller Unterressourcen laden und dabei Verkehr erzeugen, der kaum von echten Nutzern zu unterscheiden ist. Apache Killer sendet überlappende Range-Header (CVE-2011-3192), die einen verwundbaren Apache-Build zwingen, den Antwortkörper vielfach im Speicher zu belegen, eine Anfrage mit geringer Rate, die einen ungepatchten Server erschöpfen kann.
• Langsame Angriffe. Slowloris hält viele Verbindungen offen, indem es Teilanfragen tröpfelt und so den Verbindungspool bei nahezu null Bandbreite erschöpft. RUDY öffnet langsame POSTs, die eine wahrheitsgemäße Content-Length ankündigen und den Body dann Byte für Byte senden, wodurch Request-Handler-Worker blockiert werden. Beide prüfen das Verbindungs-Handling und die Timeout-Konfiguration, einen häufigen blinden Fleck bei volumenfokussierten Abwehrmechanismen.
• Verbindungserschöpfung. TLS Flood schließt den vollständigen TLS-Handshake ab und lässt den Server die Kosten der asymmetrischen Kryptografie tragen, um die Verbindung dann fallen zu lassen. TCP Connection Flood öffnet rohe Verbindungen und hält sie im Leerlauf, um die Verbindungstabelle, Dateideskriptoren und die Accept-Queue zu erschöpfen. Diese testen Kapazitätsgrenzen, die eine ratenbasierte Abwehr nie zu sehen bekommt.
• Protokollspezifisch und skriptgesteuert. DNS Flood sendet rohe DNS-Anfragen über TCP, eine Verbindung pro Anfrage, und belastet damit Resolver-CPU und TCP-Listener-Ressourcen. Puppeteer Script führt eine skriptgesteuerte, echte Browser-Nutzerreise (Login, Formularabsendung, ein End-to-End-Ablauf) unter Nebenläufigkeit aus, für funktionale und synthetische Nutzerlast statt für rohe Anfragerate.

Der Katalog wächst mit den Techniken der Angreifer. Zielen Sie für einen ersten Test auf Abdeckung über die Kategorien hinweg: mindestens ein Flood auf Anwendungsebene und ein langsamer oder Verbindungserschöpfungs-Angriff, weil sie unterschiedliche Teile Ihres Stacks zum Versagen bringen.

Eine wiederholbare Methode: Konfigurieren, Testen, Anpassen, Erneut testen

Ein einzelner Test ist eine Momentaufnahme. Resilienz wird durch die Schleife bewiesen. Obsidio gliedert jeden Lauf in vier Phasen:

• Autorisieren. Domain-Eigentum per DNS TXT verifizieren, bevor irgendetwas läuft.
• Konfigurieren. Simulationstyp, Umfang, geografische Verteilung und Dauer wählen. Klein anfangen: Ein Lauf mit geringer Intensität bestätigt, dass Ihr Monitoring und Ihr Abbruchpfad funktionieren, bevor Sie das Volumen erhöhen.
• Simulieren. Den kontrollierten Test aus der verteilten Flotte fahren und dabei Live-Metriken beobachten: Anfragen pro Sekunde, Erfolgsquote und übertragene Daten.
• Berichten. Das Ergebnis als attestierten Nachweis dessen exportieren, was passiert ist.

Dann passen Sie an. Eine WAF-Regel justieren, ein Rate-Limit anpassen, ein Timeout erhöhen und erneut testen, um zu belegen, dass die Korrektur wirkt. Der erneute Test ist der Teil, den Teams überspringen, und der Teil, der am meisten zählt. Eine Korrektur, die Sie nicht unter Last verifiziert haben, ist eine Hypothese, keine Kontrolle.

Was realistischer Verkehr erfordert

Ein Test ist nur so ehrlich wie der Verkehr dahinter. Abwehrmechanismen, die sich an offensichtlichen Signaturen orientieren, etwa einem einzelnen Quell-Subnetz, einem festen User-Agent oder Rechenzentrums-IP-Bereichen, „bestehen” einen Test, der dieselben Merkmale nutzt, und versagen dann gegen ein echtes Botnetz, das das nicht tut.

Obsidio erzeugt Last aus über 100.000 global verteilten, echten Geräten statt aus virtualisierten Instanzen, bezogen von ethisch einwandfreien Anbietern. Der Verkehr kommt von echter Hardware und Smartphones über viele Netze und Regionen hinweg. Sie testen Ihre Abwehr damit gegen etwas, das wie ein echter verteilter Angriff aussieht, und nicht gegen ein Laborartefakt, das Ihre WAF trivial filtern kann.

Einen Test in Compliance-Nachweise verwandeln

Für ein reguliertes Institut ist ein bestandener Test, der keine Spur hinterlässt, wenig wert. Die regulatorischen Rahmenwerke erwarten heute den Nachweis, nicht nur die Bemühung.

Nach dem Digital Operational Resilience Act (DORA) der EU müssen Finanzunternehmen ein Programm für digitale operationale Resilienz betreiben und mindestens jährlich angemessene Tests der IKT-Systeme durchführen, die kritische oder wichtige Funktionen unterstützen (Artikel 24). Bedeutende Institute müssen zusätzlich mindestens alle drei Jahre erweiterte, bedrohungsgeleitete Penetrationstests (TLPT) durchlaufen (Artikel 26). NIS2 verpflichtet wesentliche und wichtige Einrichtungen, Risikomanagementmaßnahmen zu ergreifen und zu testen, und die FINMA erwartet von Schweizer Instituten, operationelle Resilienz auf vergleichbarer Grundlage zu steuern.

Was diese Rahmenwerke gemeinsam haben, ist die Forderung nach nachweisbarem, wiederholbarem Testen, also der Art von Sicherheit, die Sie einem Prüfer oder einem Vorstand vorlegen können. Obsidio erzeugt kryptografisch attestierte, manipulationssichere Berichte, die auf FINMA, DORA und NIS2 abgebildet sind und innerhalb von Trusted Execution Environments erstellt werden, sodass das Ergebnis nicht nachträglich stillschweigend verändert werden kann. Das Ergebnis eines Tests wird zum Beleg in Ihrer Compliance-Akte.

Stärke wird bewiesen, nicht versprochen. Ein Test, den Sie attestieren können, macht aus „Wir sind resilient” etwas, das ein Prüfer überprüfen kann.

Wo Sie anfangen

Wenn Sie Ihren DDoS-Schutz noch nie getestet haben, beginnen Sie mit einem einzelnen autorisierten Lauf geringer Intensität auf Anwendungsebene gegen eine Staging-Umgebung oder ein geplantes Zeitfenster. Beobachten Sie, wie Ihr Monitoring und Ihre Mitigation reagieren, und weiten Sie den Umfang von dort aus. Der erste Test liefert selten ein sauberes Bestehen, und genau deshalb führen Sie ihn durch, bevor es ein Angreifer tut.

Um eine kontrollierte Simulation gegen Ihre eigene Infrastruktur zu planen, nehmen Sie Kontakt mit dem Obsidio-Team auf oder fordern Sie eine Demo an. Unabhängig, neutral, überprüfbar: Resilienz, die Sie beweisen können.