Der wirksamste Weg, DDoS-Schutz zu validieren, sind simulierte Angriffe, und diese werden häufig aus Rechenzentren heraus erzeugt. Doch echte Angriffe kommen nicht aus einem einzelnen Rechenzentrum. Sie kommen von Tausenden kompromittierten Geräten auf der ganzen Welt: Heimroutern, IoT-Geräten und Smartphones in privaten und mobilen Netzen. Sieht Ihr Test-Traffic nicht so aus, blockieren Ihre WAF, Ihr Load Balancer oder Ihr Scrubbing-Service ihn möglicherweise aus dem falschen Grund, und Sie beenden Ihre Tests mit einem falschen Gefühl der Sicherheit.
Heute stehen Organisationen drei Hauptquellen für Test-Traffic zur Verfügung, jede mit anderen Kompromissen bei Realitätsnähe, Aufwand und Beweiskraft: Lastgeneratoren in Rechenzentren, Server, die Sie selbst betreiben oder mieten, und verteilte echte Geräte wie Smartphones und Hardware-Endpunkte.
Das Wichtigste im Überblick
- DDoS-Test-Traffic kann aus drei Hauptquellen stammen: aus Rechenzentren, von Servern unter Ihrer Kontrolle oder von verteilten echten Geräten und Smartphones.
- Tests aus Rechenzentren bieten Volumen und Komfort, doch ihre IP-Bereiche sind für WAFs und Scrubbing-Services leicht zu erkennen und zu filtern.
- Serverbasierte Tests bieten volle Kontrolle, aber begrenzte Reichweite, wenig IP-Vielfalt und einen hohen Aufwand für interne Teams.
- Tests mit echten Geräten erzeugen Traffic, der wie ein echtes Botnetz aussieht, und sind damit die realistischste Testvariante. Allerdings benötigen Sie ein ausreichend großes Gerätenetzwerk, um eine aussagekräftige Last zu erzeugen.
1. Tests aus Rechenzentren
In diesem Modell erzeugen Lastgeneratoren den Angriffs-Traffic, die in Cloud- oder Hosting-Rechenzentren laufen, oft über mehrere Regionen hinweg. Es ist der gängigste Ansatz traditioneller Anbieter von DDoS-Tests, weil sich Cloud-Kapazität einfach bereitstellen, skalieren und wieder abschalten lässt.
Vorteile
- Volumen: Cloud-Infrastruktur kann schnell hohe Traffic-Volumen erzeugen. Das ist nützlich, um reine Bandbreite und Kapazitätsgrenzen zu testen.
- Reichweite über mehrere Regionen: Lastgeneratoren lassen sich in mehreren Cloud-Regionen platzieren, was eine gewisse geografische Verteilung ermöglicht.
- Geringer Einrichtungsaufwand: Auf Ihrer Seite ist keine Hardware nötig, und Testumgebungen lassen sich aus Standard-Images bereitstellen.
Nachteile
- Erkennbarkeit: Die IP-Bereiche von Rechenzentren sind bekannt. Viele WAFs, Bot-Management-Tools und Scrubbing-Services stufen sie standardmäßig als verdächtig ein, sodass Test-Traffic möglicherweise wegen seiner Herkunft blockiert wird und nicht wegen seines Verhaltens.
- Realitätsnähe: Ein echtes Botnetz läuft über private und mobile Anschlüsse. Traffic von einer Handvoll Cloud-Anbietern bildet diese Vielfalt an Netzen, Geräten und Verhalten nicht nach.
- Terminplanung: Von Anbietern durchgeführte Tests aus Rechenzentren erfordern meist Vorlaufzeit, Abstimmung und ein Wartungsfenster, sodass ein erneuter Test nach einer Regeländerung Tage dauern kann.
2. Serverbasierte Tests
Hier erzeugen interne IT- oder Security-Teams den Angriffs-Traffic von eigenen oder gemieteten Servern aus, mit Open-Source- oder kommerziellen Tools zur Traffic-Erzeugung. Die Verantwortung für den Test bleibt vollständig im Haus: Sie entscheiden, wann, wie und wogegen Sie testen.
Vorteile
- Kontrolle: Tests lassen sich vollständig nach Ihren eigenen Vorgaben und Ihrem eigenen Zeitplan konzipieren und durchführen.
- Kosten pro Test: Sind Server und Tools erst einmal eingerichtet, kostet jeder weitere Test relativ wenig.
Nachteile
- Begrenzte Verteilung: Einige wenige Server an ein oder zwei Standorten erzeugen Traffic aus einem kleinen Kreis von IP-Adressen. Echte Angriffe kommen von Tausenden Quellen gleichzeitig, daher werden Rate Limits und Geo-Regeln selten richtig getestet.
- Erkennbarkeit: Wie Traffic aus Rechenzentren stammt auch Server-Traffic aus Hosting-IP-Bereichen, die Abwehrsysteme leicht erkennen können.
- Aufwand und Risiko: Ihr Team muss die Tools installieren, warten und betreiben, die Angriffe konzipieren und sie sicher durchführen. Ohne tiefgehende DDoS-Expertise ist das Risiko von Fehlkonfigurationen, unbeabsichtigten Störungen und falsch interpretierten Ergebnissen hoch.
- Nachweis: Selbst durchgeführte Tests liefern selten Berichte, die Prüfer und Aufsichtsbehörden als unabhängigen Nachweis der Resilienz akzeptieren.
3. Echte Geräte und Smartphones
Die dritte Option führt Simulationen auf einem verteilten Netzwerk physischer Geräte wie Smartphones und anderer Hardware aus, die über private und mobile Netze auf der ganzen Welt verbunden sind. Virtuelle Maschinen oder IP-Adressen von Rechenzentren sind nicht beteiligt, daher ähnelt der Traffic dem eines echten Botnetzes.
Vorteile
- Realitätsnähe: Der Traffic kommt von echten Geräten in echten Netzen an echten Standorten. Ihre Abwehr muss ihn anhand seines Verhaltens beurteilen, genau wie bei einem echten Angriff.
- Keine Verzerrung durch die Herkunft: Da der Traffic nicht aus bekannten Hosting-Bereichen stammt, kann Ihre WAF den Test nicht einfach an seiner Quelle erkennen und ihn so mit Bravour bestehen.
- Tests auf Abruf: Plattformen dieser Art funktionieren oft per Self-Service, sodass Teams nach einer Regeländerung eine Simulation durchführen können, ohne auf ein geplantes Testfenster zu warten.
- Prüfungstaugliche Nachweise: Einige Anbieter erstellen manipulationssichere, überprüfbare Berichte, die für regulatorische Rahmenwerke wie FINMA, DORA und NIS2 gedacht sind.
- Keine Installation: Der Traffic wird extern erzeugt, daher sind in Ihrer Umgebung keine Sensoren oder Agenten erforderlich.
Nachteile
Spitzenvolumen: Traffic von verteilten Geräten ist auf Realitätsnähe und Verteilung optimiert, nicht auf maximale reine Bandbreite. Wenn Ihr einziges Ziel darin besteht, die absolute Bandbreitenobergrenze einer Leitung zu ermitteln, kann ein volumetrischer Test aus dem Rechenzentrum weiterhin sinnvoll sein.
Netzwerkgröße: Der Test ist nur so stark wie das Gerätenetzwerk dahinter. Ein kleines oder geografisch eng begrenztes Netzwerk kann das Ausmaß eines echten Angriffs nicht nachbilden. Fragen Sie Anbieter daher, wie viele Geräte sie nutzen und wo sich diese Geräte befinden.
Vorbereitung: Da der Traffic einem echten Angriff ähnelt, informieren Sie Ihren ISP oder Scrubbing-Anbieter im Voraus, damit der Test nicht als echter Vorfall behandelt wird.
DDoS-Tests im Vergleich
| Rechenzentren | Server | Echte Geräte & Smartphones | |
|---|---|---|---|
| Realitätsnähe der Testsimulation | ++ | + | +++ |
| Ähnlichkeit mit einem echten Botnetz | + | + | +++ |
| Risiko, dass die WAF den Test an seiner Herkunft erkennt | Hoch | Hoch | Niedrig |
| Geografische Verteilung | Mittel | Niedrig | Abhängig vom Anbieter |
| Prüfungstaugliche Nachweise (FINMA, DORA, NIS2) | + | + | Abhängig vom Anbieter |
| Aufwand für interne Teams | Mittel | Hoch | Niedrig |
| Anforderungen an die Softwareinstallation | Mittel | Hoch | Keine |
| Zeit bis zum erneuten Test nach einer Regeländerung | Tage | Stunden | Unter Umständen Minuten |
Welche Option sollten Sie wählen?
Tests aus Rechenzentren eignen sich für Organisationen, die vor allem die reine Kapazität prüfen möchten und mit regelmäßigen, vom Anbieter geplanten Tests gut zurechtkommen. Serverbasierte Tests funktionieren, wenn Sie über umfassende interne DDoS-Expertise verfügen, volle Kontrolle wünschen und keine unabhängigen Nachweise für Prüfer benötigen.
Wenn Sie wissen müssen, wie Ihre Abwehr gegen einen realistischen, weltweit verteilten Angriff besteht, und dies gegenüber Aufsichtsbehörden nachweisen wollen, sind Tests mit echten Geräten die beste Wahl. Das gilt insbesondere für Banken und Finanzinstitute, die unter FINMA, DORA oder NIS2 fallen, sowie für alle Teams, die WAF- oder Load-Balancer-Regeln häufig ändern und diese noch am selben Tag validieren möchten.
Sie möchten sehen, wie Ihre Abwehr einem realen DDoS-Angriff standhält? Mit Obsidio, einer Schweizer DDoS-Resilienzplattform, führen Sie DDoS-Simulationen auf Abruf über ein globales Netzwerk echter Smartphones durch, inklusive prüfungstauglicher Berichte für FINMA, DORA und NIS2. Fordern Sie eine Obsidio-Demo an.