DDoS-Schutz testen: ein Leitfaden für regulierte Institute

Die meisten Teams lernen die Grenzen ihres DDoS-Schutzes im Ernstfall kennen. Das ist der denkbar schlechteste Zeitpunkt, um festzustellen, dass eine WAF-Regel zu locker gefasst war oder ein Ursprungsserver nie abgeschirmt wurde. Wer seinen DDoS-Schutz vorher prüft, steht am Ende mit einem kontrollierten Befund da und nicht mit einem öffentlichen Ausfall.

Dieser Leitfaden richtet sich an diejenigen, die dieses Risiko in einem regulierten Institut verantworten: Security-Engineers, Betreiber von WAF und Load Balancern sowie Compliance-Verantwortliche, die Resilienz gegenüber der Aufsicht belegen müssen. Er beschreibt, was ein sauberer Testlauf misst, wie Sie ihn durchführen, ohne den eigenen Dienst lahmzulegen, und wie aus dem Ergebnis ein prüffähiger Nachweis wird.

Was ein Test des DDoS-Schutzes tatsächlich leistet

Ein DDoS-Test schickt kontrollierten, realistischen Angriffsverkehr auf Infrastruktur, die Ihnen gehört, und misst, ob Ihre Abwehr ihn auffängt und wie sich der Dienst unter Last verhält. Es geht nicht darum, die Website lahmzulegen, sondern darum, die Bruchstelle zu finden, an der der Schutz nachgibt – damit Sie sie nach Ihrem eigenen Zeitplan beheben können.

Zwei Abgrenzungen gehören dazu:

• Ein DDoS-Test ist kein Booter und kein Stresser. Solche Dienste feuern anonymen Datenverkehr auf beliebige Ziele. Sie sind illegal, sobald sie auf etwas gerichtet werden, das Ihnen nicht gehört, und sie liefern weder eine Messung noch einen Autorisierungsnachweis noch einen Bericht.
• Er ist auch kein gewöhnlicher Lasttest. Ein Lasttest fragt: «Können wir 10’000 legitime Nutzer bedienen?» Ein DDoS-Test fragt: «Was passiert, wenn der Verkehr bösartig oder fehlerhaft ist oder gezielt darauf ausgelegt, eine Ressource zu erschöpfen, die unser Lasttest nie berührt?» Anderer Verkehr, andere Fehlerbilder.

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

Die Autorisierung steht vor dem ersten Paket

Was legitimes Resilienztesting von einem Angriff trennt, ist die Autorisierung. Geprüft wird ausschliesslich, was Ihnen gehört oder wozu Sie ausdrücklich beauftragt sind, und die Inhaberschaft wird nachgewiesen, bevor das erste Paket fliesst.

Obsidio erzwingt das über einen DNS-TXT-Eintrag als Nachweis der Domain-Inhaberschaft. Sie hinterlegen den Eintrag auf der Domain, die Sie prüfen wollen; solange er nicht bestätigt ist, startet keine Simulation. Jeder Durchlauf ist kontrolliert, wird schrittweise hochgefahren und lässt sich im Betrieb abbrechen. Das macht die Übung für eine Rechtsabteilung vertretbar und für eine Compliance-Akte wiederholbar: Die Autorisierung ist dokumentiert und nicht bloss vorausgesetzt.

Behandeln Sie das als die erste Schutzmassnahme, die auf dem Prüfstand steht, nicht als Formalie. Wenn Ihr eigenes Change-Management für einen Test keine unterzeichnete, zeitlich befristete Autorisierung hervorbringt, wird es das im Ernstfall ebenso wenig tun.

Die Angriffstypen, gegen die sich ein Test lohnt

DDoS ist keine einzelne Angriffsform, und ein Schutz, der eine Klasse abwehrt, kann für die nächste blind sein. Ein Testprogramm sollte die verschiedenen Arten durchspielen, auf die ein Dienst ausfällt. Der Simulationskatalog von Obsidio verteilt sich auf vier Kategorien, die jeweils einen anderen Teil Ihres Stacks belasten:

• Angriffe auf der Anwendungsschicht (Layer 7). Der HTTP-Flood treibt grosse Mengen wohlgeformter Anfragen gegen den Anwendungspfad: die Request-Queue, die Anwendungs-Threads und die Datenbank dahinter. GoldenEye hängt jeder Anfrage einen zufälligen Query-String an, sodass sie am Cache vorbeigeht und den Ursprungsserver erreicht, dazu wechselnde, browserähnliche Header. Der Browser Flood arbeitet mit echten Browser-Sitzungen, die die ganze Seite samt allen Unterressourcen laden und dabei Verkehr erzeugen, der sich kaum von dem echter Nutzer trennen lässt. Apache Killer schickt überlappende Range-Header (CVE-2011-3192), die einen verwundbaren Apache-Build zwingen, den Inhalt der Antwort vielfach im Arbeitsspeicher vorzuhalten – Anfragen mit geringer Rate, die einen ungepatchten Server erschöpfen können.
• Langsame Angriffe. Slowloris hält viele Verbindungen offen, indem er unvollständige Anfragen häppchenweise nachschickt, und erschöpft so den Verbindungspool bei nahezu null Bandbreite. RUDY öffnet langsame POST-Anfragen, kündigt eine korrekte Content-Length an und sendet den Body dann Byte für Byte; das bindet die Worker, die die Anfrage bearbeiten. Beide setzen am Verbindungs-Handling und an den Timeout-Einstellungen an – ein verbreiteter blinder Fleck bei Schutzmassnahmen, die auf Volumen ausgelegt sind.
• Verbindungserschöpfung. Der TLS-Flood führt den vollständigen TLS-Handshake durch, bürdet dem Server damit die Rechenkosten der asymmetrischen Kryptografie auf und kappt die Verbindung anschliessend. Der TCP Connection Flood öffnet reine TCP-Verbindungen und hält sie im Leerlauf, bis Verbindungstabelle, Dateideskriptoren und Accept-Queue erschöpft sind. Damit geraten Kapazitätsgrenzen in den Blick, die eine ratenbasierte Abwehr nie zu sehen bekommt.
• Protokollspezifisch und skriptgesteuert. Der DNS-Flood sendet reine DNS-Anfragen über TCP, eine Verbindung je Anfrage, und belastet damit die CPU des Resolvers und die Ressourcen des TCP-Listeners. Puppeteer Script fährt einen skriptgesteuerten Ablauf in echten Browsern – Login, Formularabsendung, ein durchgehender Prozess – mit hoher Parallelität; dabei geht es um funktionale und synthetische Nutzerlast, nicht um die blosse Anfragerate.

Der Katalog wächst mit den Techniken der Angreifer. Decken Sie schon beim ersten Test mehrere Kategorien ab: mindestens einen Flood auf Anwendungsebene und einen langsamen oder verbindungserschöpfenden Angriff, weil sie an unterschiedlichen Stellen Ihres Stacks zum Ausfall führen.

Eine wiederholbare Methode: konfigurieren, testen, anpassen, erneut testen

Ein einzelner Test ist eine Momentaufnahme; Resilienz zeigt sich erst in der Wiederholung. Obsidio gliedert jeden Durchlauf in vier Phasen:

• Autorisieren. Die Domain-Inhaberschaft per DNS-TXT-Eintrag nachweisen, bevor irgendetwas läuft.
• Konfigurieren. Simulationstyp, Prüfumfang, geografische Verteilung und Dauer festlegen. Fangen Sie klein an: Ein Durchlauf 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 Geräteflotte fahren und dabei die Live-Metriken verfolgen: Anfragen pro Sekunde, Erfolgsquote und übertragene Datenmenge.
• Berichten. Das Ergebnis als attestierten Nachweis dessen exportieren, was tatsächlich passiert ist.

Dann wird angepasst: eine WAF-Regel justieren, ein Rate Limit nachziehen, ein Timeout erhöhen – und erneut testen, um zu belegen, dass die Korrektur greift. Den zweiten Durchlauf lassen Teams gern aus, und gerade er zählt am meisten. Eine Korrektur, die nie unter Last geprüft wurde, ist eine Hypothese und keine Schutzmassnahme.

Was realistischer Verkehr voraussetzt

Ein Test ist nur so aussagekräftig wie der Verkehr, der ihn erzeugt. Eine Abwehr, die sich an offensichtlichen Merkmalen orientiert – einem einzelnen Quell-Subnetz, einem festen User-Agent, IP-Bereichen von Rechenzentren –, «besteht» jeden Test, der dieselben Merkmale mitbringt, und versagt dann gegen ein echtes Botnetz, das sie nicht mitbringt.

Obsidio erzeugt die Last aus über 100’000 weltweit verteilten echten Geräten statt aus virtualisierten Instanzen; deren Besitzer stellen ihre Kapazität rechtmässig und mit ausdrücklicher Zustimmung zur Verfügung. Der Verkehr kommt von echter Hardware und von Smartphones, über viele Netze und Regionen hinweg. Sie prüfen Ihre Abwehr damit gegen etwas, das einem echten verteilten Angriff gleicht, und nicht gegen ein Laborkonstrukt, das Ihre WAF mühelos herausfiltert.

Aus einem Test einen Compliance-Nachweis machen

Für ein reguliertes Institut ist ein bestandener Test, der keine Spur hinterlässt, wenig wert. Die Regelwerke verlangen inzwischen den Nachweis und nicht nur das Bemühen.

Nach dem Digital Operational Resilience Act (DORA) der EU müssen Finanzunternehmen ein Programm für digitale operationale Resilienz unterhalten 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 bedrohungsorientierte Penetrationstests (TLPT) durchlaufen (Artikel 26). NIS2 verpflichtet wesentliche und wichtige Einrichtungen, Risikomanagementmassnahmen zu ergreifen und sie zu prüfen, und die FINMA erwartet von Schweizer Instituten, operationelle Resilienz auf vergleichbarer Grundlage zu steuern.

Gemeinsam ist diesen Regelwerken die Forderung nach belegbarem, wiederholbarem Testen – nach der Art von Prüfbestätigung, die Sie einem Prüfer oder dem Verwaltungsrat vorlegen können. Obsidio erzeugt kryptografisch attestierte, manipulationssichere Berichte, die FINMA, DORA und NIS2 zugeordnet sind und innerhalb von Trusted Execution Environments entstehen, sodass sich das Ergebnis nachträglich nicht stillschweigend ändern lässt. So wird aus dem Ergebnis eines Tests der Beleg in Ihrer Compliance-Akte.

Stärke wird belegt, nicht versprochen. Ein Test, den Sie attestieren können, macht aus der Behauptung «Wir sind resilient» eine Aussage, die ein Prüfer nachvollziehen kann.

Womit Sie anfangen

Wenn Sie Ihren DDoS-Schutz noch nie geprüft haben, beginnen Sie mit einem einzelnen autorisierten Durchlauf geringer Intensität auf Anwendungsebene, gegen eine Staging-Umgebung oder in einem geplanten Zeitfenster. Beobachten Sie, wie Monitoring und Mitigation reagieren, und weiten Sie den Prüfumfang von dort aus. Der erste Test geht selten ohne Befund aus – genau deshalb führen Sie ihn durch, bevor es ein Angreifer tut.

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