DDoS-Test planen: Was muss vor einer Simulation vereinbart sein?

Vor einer DDoS-Simulation müssen Ziel, autorisierte Systeme, beteiligte Netze, Verkehrsgrenzen, Testfenster, Messung und Abbruchregeln schriftlich feststehen. Der Eigentümer einer Anwendung kann nicht automatisch für Cloud-, Transit-, CDN- oder Fremdsysteme mitentscheiden. Erst wenn alle betroffenen Betreiber den konkreten Umfang freigegeben haben, darf kontrollierter Testverkehr beginnen.

Zuerst klären: Übung, Lasttest oder DDoS-Simulation?

Drei Formate beantworten unterschiedliche Fragen. Eine Tabletop-Übung geht Alarmierung, Entscheidungen und Kommunikation ohne zusätzlichen Netzverkehr durch. Ein funktionaler Abnahmetest prüft mit legitimen Anfragen, ob Anmeldung, neue und laufende Sitzungen sowie Wiederverbindung funktionieren. Ein Lasttest erzeugt erwarteten oder erhöhten legitimen Verkehr. Eine DDoS-Simulation versucht dagegen bewusst, Schutzmechanismen mit einem kontrollierten Angriffsmuster auszulösen. Sie braucht deshalb eine eigene Freigabe und darf nicht als normaler Lasttest bezeichnet werden.

AWS: Abgrenzung von Netzlasttest und DDoS-Simulation

Eine eigene IP-Adresse ist noch keine vollständige Autorisierung

Der geplante Verkehr durchläuft meist Systeme mehrerer Parteien. Dazu können Testanbieter, Internetzugänge, Transitprovider, DDoS-Mitigation, CDN, Cloud-Plattform, Rechenzentrum und die eigentliche Anwendung gehören. Für jede Station ist zu prüfen, welche Nutzungsbedingungen und Freigaben gelten. Microsoft erlaubt Azure-DDoS-Simulationen beispielsweise nur über zugelassene Testpartner und gegen bestimmte eigene, geschützte Ressourcen. AWS definiert ebenfalls zugelassene Partner, Zielressourcen und technische Grenzen. Diese Regeln sind anbieterspezifisch; ihre Zahlen oder Freigaben lassen sich nicht auf ein anderes Netz übertragen.

Microsoft Azure: DDoS-Schutz durch autorisierte Simulationen testen

AWS: Richtlinie für DDoS-Simulationstests

• Der Dienstverantwortliche bestätigt, welche eigene Anwendung geprüft werden darf und welche Geschäftsfunktionen geschützt werden müssen.
• Der Inhaber der Zielressourcen bestätigt die exakten IP-Adressen, Präfixe, Hostnamen und Konten; gemeinsam genutzte oder fremde Ziele bleiben ausgeschlossen.
• Netz-, Cloud-, Hosting-, CDN- und Schutzanbieter geben nur den Teil frei, für den ihre Bedingungen eine Freigabe verlangen.
• Der Testanbieter weist seine Quellnetze, Ansprechpartner und Berechtigung nach und akzeptiert die vereinbarten Grenzen.
• Ein benannter Testleiter besitzt Start-, Pausen- und Abbruchbefugnis; die Gegenseite bestätigt einen jederzeit erreichbaren Kontakt.

Die Freigabe sollte Zeitraum, Zeitzone, Ziele, Quellen, zulässige Testarten und Höchstgrenzen enthalten. Dieser Beitrag ist eine technische Planungshilfe und keine Rechtsberatung. Eine Produktanfrage, ein Testzugang oder der Besitz eines Servers ist für sich allein keine Erlaubnis zur DDoS-Simulation.

Was in das Testblatt gehört

• Ziel und Entscheidung: Welche Annahme soll geprüft werden, und welche betriebliche Entscheidung folgt aus dem Ergebnis?
• Positiver Umfang: exakte Zieladressen, Dienste, Ports, Protokolle, IP-Versionen und die vorgesehenen Verkehrswege.
• Negativer Umfang: DNS, Verwaltungszugänge, gemeinsam genutzte Plattformen, Partner-APIs oder andere ausdrücklich nicht zu prüfende Systeme.
• Quellen und Erzeuger: Testanbieter, Quellpräfixe und die für den Verkehr verantwortliche Organisation.
• Verkehrshülle: zulässige Kategorien, Stufen, Dauer und Obergrenzen getrennt nach Bitrate, Paketrate, Anfragen oder Verbindungen – soweit für den Test relevant.
• Zeitplan: Beginn, Ende, Zeitzone, stufenweiser Anstieg, Haltepunkte und reservierte Zeit für Wiederherstellung.
• Beobachtung: Netzwerk-, Schutz- und Anwendungsmetriken, Zeitsynchronisation, Log-Aufbewahrung und Verantwortliche für die Auswertung.
• Steuerung: Startfreigabe, Kommunikationskanäle, Abbruchwort, erreichbare Kontakte und die Person mit letzter Entscheidungsbefugnis.

Produktionsnetze sind kein neutrales Labor. RFC 6815 warnt ausdrücklich davor, isolierte Netzwerk-Benchmarkmethoden aus RFC 2544 in Produktionsnetzen einzusetzen, weil die Testverfahren selbst störend wirken können. Ein vereinbartes DDoS-Szenario ist zwar kein RFC-2544-Benchmark, die operative Folgerung bleibt wichtig: Methodik und Grenzwerte müssen zur Umgebung passen und dürfen nicht aus einem Laborleitfaden kopiert werden.

RFC 6815: RFC-2544-Benchmarks in Produktionsnetzen gelten als schädlich

Erfolg misst nicht nur, ob ein Filter auslöst

Ein Testziel sollte Netzwerk und Nutzerwirkung verbinden. Erfassen Sie dieselben repräsentativen Nutzerabläufe vor, während und nach dem Test. Legen Sie vorher fest, welche Abweichungen akzeptabel sind; universelle Grenzwerte gibt es dafür nicht. Ein ausgelöster Alarm ist kein ausreichender Erfolg, wenn legitime Sitzungen ausfallen oder der Betriebsprozess nicht funktioniert.

• Erkennung: Wird das Ereignis am vereinbarten Messpunkt erkannt und zeitlich korrekt zugeordnet?
• Alarmierung: Erreichen Meldungen die richtigen Rollen, und können diese den Test vom echten Vorfall unterscheiden?
• Schutzwirkung: Bleiben die vorher definierten legitimen Nutzerabläufe innerhalb der vereinbarten Kriterien nutzbar?
• Betriebsprozess: Funktionieren Eskalation, Statusmeldungen, Freigaben und Entscheidungen ohne improvisierte Nebenwege?
• Wiederherstellung: Kehren Routing, Schutzstatus, Anwendung und Monitoring nach dem Ende in den dokumentierten Ausgangszustand zurück?
• Nachweis: Lassen sich Teststufen, Maßnahmen, Nutzerwirkung und offene Punkte auf einer gemeinsamen Zeitachse erklären?

Abbruchkriterien müssen vor dem Start prüfbar sein

Eine Formulierung wie „bei Problemen stoppen“ ist zu ungenau. Definieren Sie beobachtbare Auslöser und wer sie feststellt. Ein Abbruch beendet die Verkehrserzeugung; parallel kann ein gesonderter Wiederherstellungsplan nötig sein. Der Kommunikationsweg zum Testanbieter darf nicht ausschließlich von der gerade geprüften Anwendung abhängen.

• Verkehr erreicht ein nicht autorisiertes Ziel oder beeinträchtigt einen ausdrücklich ausgeschlossenen Dienst.
• Eine vereinbarte Obergrenze, Stufe oder Zeitgrenze wird überschritten oder kann nicht verlässlich gemessen werden.
• Die Wirkung auf legitime Nutzer überschreitet das vorab festgelegte Akzeptanzkriterium.
• Monitoring, Zeitabgleich oder der unabhängige Kontakt zum Testleiter fällt aus.
• Ein beteiligter Betreiber fordert Pause oder Abbruch, oder ein paralleler echter Sicherheitsvorfall beginnt.
• Nach dem Stopp erholt sich ein Dienst nicht wie erwartet; weitere Teststufen bleiben dann gesperrt.

Illustratives Beispiel für einen Testauftrag

Das folgende Muster ist ausdrücklich illustrativ. Die Dokumentationsadresse 192.0.2.80 aus RFC 5737 ist kein reales Testziel; das Beispiel erteilt keine Freigabe und enthält bewusst keine nutzbaren Verkehrswerte.

Kontrollierter Ablauf am Testtag

1. 1Alle Beteiligten bestätigen Version, Freigaben, Ausgangslage, erreichbare Kontakte und Go/No-Go; ohne vollständige Bestätigung startet nichts.
2. 2Monitoring und repräsentative Nutzerabläufe werden im Normalzustand geprüft, damit ein aktueller Vergleich vorliegt.
3. 3Der Test beginnt mit der kleinsten vereinbarten Stufe. Nur der autorisierte Testleiter darf nach einem gemeinsamen Haltepunkt erhöhen.
4. 4Netzwerk-, Schutz- und Anwendungsteams führen eine gemeinsame Zeitachse und melden Abbruchsignale sofort.
5. 5Am Ende wird die Verkehrserzeugung bestätigt beendet; temporäre Änderungen werden nach Plan zurückgenommen und der Ausgangszustand geprüft.
6. 6Ergebnisse, Abweichungen und offene Maßnahmen werden dokumentiert. Eine Wiederholung erhält einen neuen freigegebenen Umfang statt einer stillen Verlängerung.

NIST SP 800-61 Rev. 3 ordnet Vorbereitung, Erkennung, Reaktion, Wiederherstellung und Verbesserung als zusammenhängende Aufgaben des Sicherheitsrisikomanagements ein. Für den Test heißt das: Nicht nur den Verkehr bewerten, sondern auch Entscheidungen, Kommunikation, Wiederherstellung und die anschließende Verbesserung des Plans.

NIST SP 800-61 Rev. 3: Empfehlungen zur Reaktion auf Sicherheitsvorfälle

Wenn der geplante Test einen über AS51202 geschützten Verkehrsweg berührt, nennen Sie in der Anfrage Zielpräfixe, Dienste, beteiligte Provider, Testziel, vorgeschlagenes Fenster, Verkehrsgrenzen und technische Kontakte. Damit lässt sich klären, ob und unter welchen Bedingungen der Test zum vereinbarten Schutzumfang passt. Die Anfrage selbst ist noch keine Startfreigabe; warten Sie auf die ausdrückliche Abstimmung aller Beteiligten.