Ein SYN-Flood-Angriff bringt keine einzige Verbindung zustande. Er schickt das erste Paket des TCP-Handshakes, tausendfach pro Sekunde, von Absenderadressen, die es nicht gibt, und meldet sich danach nie wieder. Jedes dieser Pakete zwingt den Server, einen Platz für einen Client freizuhalten, der nie antworten wird.

Er gehört zu den ältesten Angriffen im Internet und ist noch immer einer der häufigsten. Cloudflares DDoS-Bericht für das zweite Quartal 2025, veröffentlicht am 15. Juli 2025, führt SYN-Floods mit 27 Prozent aller Angriffe auf Netzwerkebene auf Platz zwei der Vektoren, nach 31 Prozent im Quartal davor.

Dieser Beitrag ist ein Erklärstück und kein Teil unserer zehnteiligen Simulationsserie: Ein SYN-Flood gehört nicht zu den zehn Typen, die Obsidio ausführt, und der Grund dafür ist die nützlichste Erkenntnis dieses Textes. Wie die Vektorfamilien zusammenhängen, zeigt unser Überblick über die Arten von DDoS-Angriffen; wie Sie einen ersten autorisierten Durchlauf aufsetzen, beschreibt der Leitfaden zum Thema DDoS-Schutz testen.

Wie ein SYN-Flood technisch abläuft

Jede TCP-Verbindung beginnt mit einem Austausch in drei Schritten. Der Client sendet ein SYN und meldet damit an, dass er reden will. Der Server antwortet mit einem SYN-ACK, signalisiert Bereitschaft und reserviert Speicher für die kommende Verbindung. Der Client bestätigt mit einem abschliessenden ACK, und die Verbindung steht.

Zwischen Schritt zwei und Schritt drei ist die Verbindung halboffen: Der Server hat Zustand angelegt und wartet. Dieser Zustand liegt in einer Warteschlange pro Listener, üblicherweise SYN-Backlog genannt; unter Linux steht jeder Eintrag im Zustand SYN_RECV, bis das ACK eintrifft oder der Eintrag verfällt.

Ein SYN-Flood sendet Schritt eins und niemals Schritt drei. Jedes Paket umfasst rund 40 Byte und kostet den Absender praktisch nichts. Den Server kostet es einen Backlog-Eintrag, der so lange belegt bleibt, wie der Kernel das SYN-ACK wiederholt.

Unter Linux ist tcp_synack_retries die zuständige Stellschraube. Die Sysctl-Referenz des Kernels nennt den Standardwert 5; das entspricht 31 Sekunden bis zur letzten Wiederholung, bei einer anfänglichen RTO von 1 Sekunde («which corresponds to 31 seconds till the last retransmission with the current initial RTO of 1 second»). Eine halbe Minute Belegung pro Paket, ohne Aufwand für den Angreifer – und die Pakete kommen zu Tausenden.

Ist der Backlog voll, verwirft der Kernel weitere SYN-Pakete. Von aussen ist die Site schlicht nicht erreichbar. Von innen betrachtet: CPU niedrig, Bandbreite niedrig, Anwendungslogs ruhig. Defekt ist nichts – der Server nimmt nur keine neuen Verbindungen mehr an.

Stellen Sie sich einen Empfang vor, auf dessen Pult zwanzig Notizzettel Platz haben. Zwanzig Anrufer sagen «Moment, ich nenne Ihnen gleich meinen Namen» und melden sich nie wieder. Der Empfang ist nicht ausgelastet; das Pult ist voll, und der einundzwanzigste Anrufer wird abgewiesen.

Warum gefälschte Absenderadressen den Ausschlag geben

Der Angriff steht und fällt damit, dass die Antwort des Servers ins Leere geht. RFC 4987, «TCP SYN Flooding Attacks and Common Mitigations», veröffentlicht im August 2007, formuliert das unmissverständlich: «For an effective attack, it is important that the spoofed IP addresses be unresponsive to the SYN-ACK segments.» Gehört die gefälschte Adresse einem laufenden Host, erhält dieser ein SYN-ACK, das er nicht angefordert hat, kann es nicht zuordnen und schickt einen Reset. Der Reset gibt den Backlog-Eintrag sofort frei, und der Angriff bricht in sich zusammen.

Angreifer fälschen deshalb Adressen, hinter denen nichts steht: nicht zugewiesener Adressraum oder Bereiche, in denen kein Host lauscht. Daraus folgt dreierlei, das man im Kopf behalten sollte.

• Ratenbegrenzung pro Quelle findet nichts zum Zählen. Jedes Paket scheint von einer anderen Adresse zu kommen, und keine dieser Adressen sendet je ein zweites.
• Blocklisten sind nutzlos und obendrein riskant. Die Adressen in Ihren Logs haben den Verkehr nie gesendet. Wer sie sperrt, trifft unbeteiligte Netze und mitunter die eigenen Nutzer.
• Der Angriff setzt voraus, dass sich Absenderadressen überhaupt fälschen lassen. Das hängt von dem Netz ab, aus dem der Angreifer sendet, nicht von Ihrer Abwehr.

Die älteste strukturelle Gegenmassnahme liegt deshalb nicht beim Opfer. RFC 2827, besser bekannt als BCP 38, veröffentlicht im Mai 2000, verlangt von jedem Netz, den ausgehenden Verkehr so zu filtern, dass darin nur Absenderadressen aus den Bereichen vorkommen, die dem Netz tatsächlich zugeteilt sind. Nach einem Vierteljahrhundert ist die Umsetzung lückenhaft. Das Spoofer-Projekt von CAIDA misst laufend von freiwilligen Messpunkten aus, ob Netze gefälschte Absenderadressen durchlassen; seine Übersichtsseite wies am 29. Juli 2026 aus, dass sich aus 233 von 1’430 getesteten IPv4-Blöcken gefälschte Pakete versenden liessen, rund jeder sechste Block, wenn man die NAT-Fälle herausrechnet.

Ein Satz zur Vorgeschichte: Das CERT-Advisory CA-1996-21 dokumentierte SYN-Flooding und IP-Spoofing im September 1996, ausgelöst unter anderem von einem Angriff, der die Mailserver des New Yorker Providers Panix lahmlegte.

Dreissig Jahre später führt Cloudflares Bericht zum dritten Quartal 2025 vom 3. Dezember 2025 SYN-Floods weiterhin auf Platz drei der Netzwerkvektoren, hinter UDP- und DNS-Floods und vor ICMP. Zusammen machten diese vier gut die Hälfte aller Angriffe auf Netzwerkebene aus, in einem Quartal, in dem Cloudflare insgesamt 8,3 Millionen Angriffe abwehrte.

Welche Ihrer Schutzmassnahmen hätte das abfangen müssen?

Es lohnt sich, die ganze Kette abzuschreiten, auf die eine solche Last trifft. Bei den meisten Angriffen dieser Serie fällt die Antwort unbequem aus; hier fällt sie überwiegend beruhigend aus, und das klar zu sagen ist wichtiger, als jede Schutzschicht schlecht aussehen zu lassen.

Vergleichen Sie dieses Raster mit dem im Beitrag zu Slowloris: Die Urteile kehren sich weitgehend um. Volumenbasiertes Scrubbing ist gegen einen langsamen Angriff blind und gegen einen SYN-Flood entscheidend. Genau diese Umkehrung ist das Argument dafür, über die Vektorfamilien hinweg zu testen.

Wie wehrt man einen SYN-Flood ab?

Vier Massnahmen tragen fast das ganze Gewicht, und drei davon sind in einer aktuellen Standardinstallation bereits aktiv.

• SYN-Cookies. Statt Zustand für eine halboffene Verbindung zu speichern, codiert der Server das Nötige in die Sequenznummer seines eigenen SYN-ACK und vergisst die Verbindung. Trifft ein legitimes ACK ein, rekonstruiert er den Zustand aus der Zahl, die der Client zurückspiegelt. RFC 4987 nennt auch die Grenzen: Einige TCP-Optionen vertragen sich damit nicht, und Daten, die huckepack auf dem SYN mitkommen, werden nicht behandelt. Unter Linux steht tcp_syncookies standardmässig auf 1; die Kernel-Dokumentation beschreibt das so, dass Cookies verschickt werden, sobald die SYN-Backlog-Queue eines Sockets überläuft («when the syn backlog queue of a socket overflows») – normale Verbindungen bleiben also unberührt.
• Backlog-Dimensionierung. tcp_max_syn_backlog begrenzt pro Listener, wie viele SYN_RECV-Anfragen sich der Kernel merkt. Die Kernel-Dokumentation nennt ein Minimum von 128 auf Maschinen mit wenig Speicher, ansteigend mit dem verfügbaren Speicher. Den Wert zu erhöhen verschafft Spielraum, und nur Spielraum: Eine grosse Warteschlange läuft langsamer voll als eine kleine, aber sie läuft voll. Dass typische Standardwerte damals zwischen einem halben Dutzend und mehreren Dutzend lagen («from a half-dozen to several dozen»), wie es RFC 4987 anmerkt, erinnert daran, wie viel sich hier bereits verbessert hat.
• Schnelleres Verfallen halboffener Einträge. Ein niedrigeres tcp_synack_retries verkürzt, wie lange jeder unbeantwortete Handshake einen Platz belegt. Der Preis ist real: Clients in wirklich verlustreichen Mobilfunknetzen brauchen diese Wiederholungen mitunter. Das ist ein Kompromiss, kein Gewinn.
• SYN-Proxying am Netzrand. Ein Scrubbing-Dienst oder eine geeignete Appliance schliesst den Handshake stellvertretend ab und leitet nur Verbindungen weiter, die ein Client tatsächlich fertiggestellt hat. Das ist die stärkste Massnahme, weil die Flut auf Infrastruktur endet, die dafür dimensioniert ist. Sie hat dieselbe Voraussetzung wie jede andere Abwehr am Netzrand: eine Adresse des Ursprungsservers, die sich nicht daran vorbei erreichen lässt.

An genau dieser Voraussetzung scheitern reale Installationen. Ein geschützter Hostname vor einem Ursprungsserver, dessen Adresse weiterhin auf Port 443 antwortet, ist nicht geschützt, und kein Konfigurations-Review macht das sichtbar.

Warum ein SYN-Flood-Angriff die Verbindungskapazität nicht prüft

Jetzt zu dem Teil, der zählt, wenn Sie einen Resilienztest planen und kein Glossar lesen. Ein SYN-Flood misst genau eines: ob das erste Gerät, das TCP terminiert, es übersteht, sich Handshakes merken zu müssen, die nie fertig werden. 2026 lautet die Antwort meistens Ja, weil es SYN-Cookies gibt und Proxying am Netzrand funktioniert.

Vollständig aufgebaute Verbindungen sind ein anderes Problem. Eine etablierte, untätige TCP-Verbindung belegt auf dem Server einen Socket und einen File Descriptor, dazu einen Eintrag in der Connection-Tracking-Tabelle jedes zustandsbehafteten Geräts auf dem Pfad und einen Platz in jedem Verbindungslimit, ob pro IP oder global. Dagegen helfen SYN-Cookies nicht, denn aus Sicht des Stacks sind diese Verbindungen völlig legitim: Echte Hosts haben sie geöffnet und tatsächlich geantwortet.

Deshalb enthält Obsidios Katalog den TCP Connection Flood und keinen SYN-Flood. Die Simulation öffnet reine TCP-Verbindungen, schliesst den Handshake ab und hält jeden Socket bis zum konfigurierten Timeout untätig offen, bevor sie ihn durch einen neuen ersetzt, standardmässig zehn Minuten lang und mit bis zu hundert Sockets pro Worker. Weil der Verkehr von über 100’000 weltweit verteilten echten Geräten mit echten, routbaren Adressen stammt, treffen Verbindungslimits pro IP auf echte Quellenvielfalt statt auf eine Handvoll Rechenzentrums-Hosts, und die Conntrack-Tabellen aller Geräte auf dem Pfad füllen sich mit Einträgen, die kein Cookie-Trick wieder loswird.

Ein TLS-Flood geht eine Schicht weiter: Er schliesst die TLS-Aushandlung ab und lässt den Server rund das Fünfzehnfache der Kryptokosten des Clients aufwenden, bevor er die Verbindung abreisst. Halboffen, vollständig offen und vollständig ausgehandelt prüfen drei verschiedene Ressourcen.

Was Sie selbst prüfen können und wo die Prüfung täuscht

Zwei dieser Fragen können Sie heute ohne jeden Testverkehr beantworten. Es lohnt sich zu wissen, welche.

Lesen Sie die Konfiguration. Prüfen Sie, ob tcp_syncookies aktiv ist, sehen Sie sich Ihre tatsächlichen Backlog- und Retry-Werte an, und nehmen Sie die Limits der Zustandstabellen auf jedem zustandsbehafteten Gerät im Pfad dazu, nicht nur auf dem Server. Damit wissen Sie, dass die Einstellungen existieren. Sie wissen nicht, welches Limit das kleinste ist, und das kleinste entscheidet den Ausgang.

Sorgen Sie dafür, dass Ihr Ursprungsserver nicht direkt erreichbar ist. Wenn ein Dienst am Netzrand die Massnahme ist, auf die Sie sich verlassen, prüfen Sie von aussen, ob die Adresse des Ursprungsservers antwortet. Das ist ein echter Test einer echten Abhängigkeit, und er kommt ohne Angriffsverkehr aus.

Testen Sie die Alarmkette für sich. Lösen Sie einen synthetischen Alarm an den Pikettdienst aus und sehen Sie nach, ob jemand reagiert. Das prüft den Meldeweg. Ob es einen Schwellenwert für den TCP-Verbindungszustand gibt, also für das Signal, das sich hier bewegt hätte, sagt es nicht.

Interessanter ist, was ein kleiner Eigenversuch falsch einschätzt. Verkehr von ein oder zwei Hosts fangen quellenbasierte Massnahmen sofort ab, und der vordere Teil der Kette wirkt tadellos. Dieser Schluss steht auf dem Kopf: Gerade diese Massnahmen verhalten sich gegenüber echter Quellenvielfalt anders.

Wie Obsidio die Verbindungsschicht prüft

Obsidio führt Simulationen zur Verbindungserschöpfung als kontrollierte, autorisierte Tests gegen Infrastruktur aus, die dem Kunden gehört. Die Domain-Inhaberschaft wird per DNS-TXT-Eintrag verifiziert, bevor das erste Paket fliesst. Laut Plattform-FAQ beginnen die meisten Institute in einem kontrollierten Zeitfenster mit bewusst niedrig gesetzten Limits und steigern die Last schrittweise; über Live-Metriken lässt sich ein Durchlauf jederzeit sofort abbrechen.

Bei einem TCP-Connection-Flood-Test ist die Kurve der Anfragerate der falsche Ort zum Hinschauen: Sie zählt Socket-Öffnungen statt Durchsatz und bleibt gerade dann unscheinbar, wenn der Test gelingt. Beobachten Sie aktive und maximale gleichzeitige Verbindungen, und zwar zusammen mit der Auslastung der Verbindungstabellen auf Ihrem eigenen Load Balancer und Ihrer Firewall. Erst diese Kombination zeigt, welches Limit zuerst greift.

Zwei Antworten kann nur Ihre eigene Seite liefern. Obsidio kann berichten, was Ihre Abwehr am Netzrand getan hat und wie viele Verbindungen gehalten wurden; das ist von aussen beobachtbar. Ob Ihr SIEM etwas aufgezeichnet hat und ob jemand alarmiert wurde, steht nur in Ihren eigenen Konsolen, also muss während des Zeitfensters jemand hineinschauen.

Stärke wird bewiesen, nicht versprochen. Ein SYN-Flood fragt, ob Ihr Kernel einen Handshake vergessen kann. Die härtere Frage lautet, was geschieht, wenn hunderttausend echte Geräte einen abschliessen und sich weigern aufzulegen – und genau die misst Obsidio.

Wo der SYN-Flood in ein Testprogramm gehört

Behandeln Sie den klassischen SYN-Flood als Massnahme, die Sie verifizieren, und nicht als Szenario, das Sie proben. Prüfen Sie, ob Cookies aktiv sind, ob Ihr Netzrand Handshakes stellvertretend beantwortet und ob Ihr Ursprungsserver daran vorbei erreichbar ist, und gehen Sie weiter. Cloudflares Bericht zum vierten Quartal 2025 vom 5. Februar 2026 zählte 47,1 Millionen DDoS-Angriffe im Jahr; die Angriffe auf Netzwerkebene stiegen auf 34,4 Millionen, nach 11,4 Millionen im Jahr 2024. Das Volumen ist also real. Die Abwehr ist aber ebenso ausgereift, und ein Testfenster ist hier schlecht investiert.

Die Erschöpfungstests, die ein Zeitfenster wert sind, setzen an legitimen Verbindungen an, denn kein Cookie, keine Challenge und keine Reputationsliste kann sie von Ihren Kunden unterscheiden. In solchen Durchläufen zeigt sich, ob ein Limit pro IP, ein Conntrack-Limit oder die Session-Tabelle eines Load Balancers die Zahl ist, an der die Verfügbarkeit Ihres Dienstes hängt.

Für regulierte Institute muss der Durchlauf zudem eine Spur hinterlassen. Obsidio erstellt kryptografisch attestierte Berichte, bei denen jede nachträgliche Änderung erkennbar ist, erzeugt in Trusted Execution Environments und mit Zuordnung zu FINMA, DORA und NIS2. Das Ergebnis eines Tests ist damit ein Nachweis zum Ablegen und kein Screenshot, für den jemand bürgen muss.

Wenn Sie eine autorisierte Simulation zur Verbindungserschöpfung gegen Ihre eigene Infrastruktur planen möchten, finden Sie mehr zur Obsidio-Plattform, oder nehmen Sie Kontakt mit dem Team auf. Unabhängig, neutral, überprüfbar: Resilienz, die Sie belegen können.

Der Digital Operational Resilience Act gilt seit dem 17. Januar 2025 – und er ist eine Verordnung, keine Richtlinie. Die Verordnung (EU) 2022/2554 bindet Finanzunternehmen in jedem EU-Mitgliedstaat unmittelbar. Es gibt keine nationale Umsetzung, auf die sich warten liesse, und keinen Spielraum, den Text als blosse Empfehlung zu lesen.

Der grösste Teil von DORA lässt sich mit Dokumenten erfüllen: Richtlinien, Register, Vertragsklauseln, Meldeformulare. Ein Teil nicht. Artikel 24(6) verlangt, dass Tests tatsächlich durchgeführt werden – mindestens jährlich und auf jedem IKT-System, das eine kritische oder wichtige Funktion unterstützt.

Genau hier hilft ein Ordner voller Richtlinien nicht weiter, und genau diesem Teil widmet sich dieser Leitfaden.

Was ist der Digital Operational Resilience Act?

DORA ist die Antwort der EU auf eine schlichte Beobachtung: Ein Finanzinstitut kann vollkommen solvent und trotzdem nicht erreichbar sein. Kapitalpuffer sagen nichts darüber aus, ob das E-Banking-Frontend eine Lastspitze übersteht oder ob der Ausfall eines zentralen Dienstleisters eine Kettenreaktion durch den ganzen Sektor auslöst.

Verabschiedet wurde die Verordnung am 14. Dezember 2022; Artikel 64 setzt den Geltungsbeginn auf den 17. Januar 2025. Seither kann die Aufsicht jedes erfasste Unternehmen am vollständigen Anforderungskatalog messen.

Artikel 3(1) definiert die digitale operationale Resilienz über die Fähigkeit eines Finanzunternehmens, seine operative Integrität aufzubauen, sicherzustellen und zu überprüfen. Das entscheidende Wort in dieser Definition ist «überprüfen».

DORA verlangt nicht, dass Sie resilient sind. DORA verlangt, dass Sie sich fortlaufend davon überzeugen – und die Prüfung dokumentieren.

Für wen gilt DORA?

Artikel 2(1) führt einundzwanzig Kategorien von Unternehmen auf, Buchstabe (a) bis (u). Kreditinstitute, Zahlungsinstitute, E-Geld-Institute und Wertpapierfirmen liegen auf der Hand. Die Liste reicht aber weiter: Anbieter von Krypto-Dienstleistungen, zentrale Gegenparteien, Handelsplätze, Fondsverwalter, Versicherungs- und Rückversicherungsunternehmen, Einrichtungen der betrieblichen Altersversorgung, Ratingagenturen, Schwarmfinanzierungsdienstleister, Verbriefungsregister.

Ein Detail in Artikel 2(2) überliest man leicht: Die Buchstaben (a) bis (t) werden gemeinsam als «Finanzunternehmen» definiert, während Buchstabe (u) – die IKT-Drittdienstleister – gesondert im Geltungsbereich steht. Wer als kritischer Anbieter eingestuft wird, unterliegt einem eigenen EU-Überwachungsregime. Ein Cloud- oder Softwareanbieter mit Kunden im Finanzsektor kann also in den Blick der Aufsicht geraten, ohne selbst ein Finanzunternehmen zu sein.

Für Mikrounternehmen gilt der Grundsatz der Verhältnismässigkeit. Mehrere Testpflichten in Kapitel IV beginnen mit «Finanzunternehmen, die keine Mikrounternehmen sind», und Artikel 25(3) erlaubt Mikrounternehmen stattdessen, einen risikobasierten Ansatz mit einer strategischen Planung ihrer Tests zu verbinden.

Schweizer Institute sind nicht unmittelbar erfasst. Schweizer Gruppen erfüllen DORA dennoch über ihre EU-Tochtergesellschaften und -Niederlassungen, Schweizer Anbieter über die Anforderungen an das IKT-Drittparteirisiko, sobald ein EU-Finanzunternehmen von ihnen abhängt. Zur Schweizer Lage weiter unten mehr.

Was sind die fünf Säulen von DORA?

Die Anforderungen von DORA gliedern sich in fünf Blöcke, üblicherweise die fünf Säulen genannt:

• IKT-Risikomanagement. Ein dokumentierter Risikomanagementrahmen in der Verantwortung des Leitungsorgans: identifizieren, schützen, erkennen, reagieren, wiederherstellen, lernen.
• Behandlung und Meldung IKT-bezogener Vorfälle. Vorfälle nach einheitlichen Kriterien klassifizieren und schwerwiegende Fälle innerhalb fester Fristen an die zuständige Behörde melden.
• Tests der digitalen operationalen Resilienz. Kapitel IV, Artikel 24 bis 27. Ein dauerhaft verankertes Testprogramm, jährliche Tests der Systeme hinter kritischen oder wichtigen Funktionen und erweiterte bedrohungsorientierte Tests für benannte Unternehmen.
• IKT-Drittparteirisiko. Vertragliche Mindestinhalte, ein Register sämtlicher IKT-Dienstleistungsvereinbarungen, die Analyse von Konzentrationsrisiken und eine EU-weite Überwachung kritischer Anbieter.
• Informationsaustausch. Eine Rechtsgrundlage, auf der Finanzunternehmen Erkenntnisse zu Cyberbedrohungen in vertrauenswürdigen Kreisen austauschen können – freiwillig.

Vier der fünf Säulen sind überwiegend Governance-Arbeit. Sie bringen Dokumente, Register und Meldewege hervor; eine gut aufgestellte Compliance-Funktion kann sie tragen.

Der Testteil ist von anderer Art. Er verlangt, dass auf produktionsrelevanten Systemen nach Plan etwas geschieht, und er bringt Befunde hervor, die jemand beheben und deren Behebung jemand belegen muss.

Was verlangt DORA für Resilienztests?

Artikel 24 steckt den Rahmen ab. Finanzunternehmen, die keine Mikrounternehmen sind, müssen ein solides und umfassendes Programm für Tests der digitalen operationalen Resilienz aufstellen, unterhalten und überprüfen – als integralen Bestandteil des IKT-Risikomanagementrahmens. Der Zweck steht ausdrücklich im Text: die Abwehrbereitschaft bewerten, Schwächen und Lücken erkennen und Korrekturmassnahmen zügig umsetzen.

Vier Bedingungen kommen hinzu; an ihnen entscheidet sich, ob ein Programm einer aufsichtlichen Prüfung standhält:

• Bandbreite. Das Programm muss eine Reihe von Bewertungen, Tests, Methoden, Verfahren und Werkzeugen umfassen, angewendet wie in den Artikeln 25 und 26 beschrieben (Artikel 24(2)). Ein einzelner jährlicher Penetrationstest ergibt noch kein Programm.
• Risikobasis. Die Tests folgen einem risikobasierten Ansatz, der die sich wandelnde IKT-Risikolage und die Kritikalität der betroffenen Systeme berücksichtigt (Artikel 24(3)).
• Unabhängigkeit. Getestet wird durch unabhängige Parteien, intern oder extern; bei internen Testern braucht es Vorkehrungen gegen Interessenkonflikte (Artikel 24(4)).
• Behebung. Unternehmen brauchen Verfahren, um jeden Befund aus einem Test zu priorisieren, zu klassifizieren und zu beheben, dazu eine interne Validierung, dass die Schwächen vollständig ausgeräumt sind (Artikel 24(5)). Ein Befund, der unbearbeitet im Bericht liegen bleibt, ist für sich genommen bereits ein Verstoss.

Dann folgt der Satz, der die meisten Testkalender im EU-Finanzsektor bestimmt. Artikel 24(6): Finanzunternehmen, die keine Mikrounternehmen sind, stellen sicher, dass mindestens jährlich geeignete Tests auf allen IKT-Systemen und -Anwendungen durchgeführt werden, die kritische oder wichtige Funktionen unterstützen.

Gemeint ist keine Stichprobe, sondern jedes einzelne System, Jahr für Jahr.

Artikel 25(1) zählt auf, was als Test gilt, und fasst den Begriff weit: Schwachstellenbewertungen und -scans, Open-Source-Analysen, Bewertungen der Netzwerksicherheit, Lückenanalysen, Überprüfungen der physischen Sicherheit, Fragebögen und Scans von Softwarelösungen, Quellcodeprüfungen soweit durchführbar, szenariobasierte Tests, Kompatibilitätstests, Leistungstests, End-to-End-Tests und Penetrationstests. Eingeleitet wird die Aufzählung mit «wie»; sie ist damit beispielhaft und nicht abschliessend. Eines macht sie gleichwohl deutlich: Was DORA unter Testen versteht, geht weit über den jährlichen Penetrationstest hinaus. Die Verfügbarkeit unter Last gehört ebenso dazu wie ausnutzbare Schwachstellen im Code.

Eine schärfere Regel enthält Artikel 25(2): Zentralverwahrer und zentrale Gegenparteien müssen vor jeder Bereitstellung oder erneuten Bereitstellung von Anwendungen, Infrastrukturkomponenten oder IKT-Diensten, die kritische oder wichtige Funktionen unterstützen, Schwachstellenbewertungen durchführen. Für Marktinfrastrukturen ist der Test damit fester Bestandteil des Release-Prozesses.

Was sind bedrohungsorientierte Penetrationstests unter DORA?

Artikel 3(17) definiert TLPT als Regelwerk, das Taktiken, Techniken und Verfahren realer Angreifer nachbildet. In der Praxis ist das eine beaufsichtigte Red-Team-Übung auf Grundlage aktueller Bedrohungsanalysen – und für einen Teil des Sektors macht DORA daraus eine Pflicht statt einer Kür.

Artikel 26 legt die Bedingungen fest. Benannte Finanzunternehmen müssen mindestens alle drei Jahre erweiterte Tests mittels TLPT durchführen; die zuständige Behörde kann diese Häufigkeit je nach Risikoprofil des Unternehmens herauf- oder herabsetzen.

Wer dazugehört, entscheidet die Aufsicht – nach Auswirkungsfaktoren, Erwägungen der Finanzstabilität sowie dem IKT-Risikoprofil und dem Reifegrad des Unternehmens. TLPT trifft nicht alle; die Anforderung zielt auf jene Unternehmen, deren Ausfall am schwersten wöge.

Der Test selbst ist bewusst unbequem angelegt. Er muss mehrere oder alle kritischen oder wichtigen Funktionen abdecken und auf Live-Produktionssystemen stattfinden.

Laufen diese Funktionen auf ausgelagerter IKT, gehören die Drittdienstleister in den Prüfumfang; die volle Verantwortung bleibt beim Finanzunternehmen. Würde eine direkte Teilnahme die Servicequalität oder die Vertraulichkeit gefährden, bleibt als Ausweg gepooltes TLPT über mehrere Finanzunternehmen hinweg. Die Regulierungsstandards für die Durchführung dieser Tests haben die Europäischen Aufsichtsbehörden im Einklang mit TIBER-EU entwickelt, dem von der EZB stammenden Regelwerk für Threat-Intelligence-basiertes Red Teaming.

Artikel 27 regelt, wer testen darf. Tester brauchen nachgewiesene Expertise in Bedrohungsanalyse, Penetrationstests und Red-Team-Operationen, Zertifizierungen oder die Bindung an formelle Verhaltenskodizes, eine unabhängige Prüfbestätigung zu ihrem eigenen Risikomanagement und eine Berufshaftpflichtversicherung.

Interne Tester sind zulässig, doch Artikel 27 verlangt dafür die Zustimmung der zuständigen Behörde und einen externen Anbieter von Bedrohungsanalysen; Artikel 26(8) ergänzt, dass bei jedem dritten Test ein externer Tester zu beauftragen ist. Bedeutende Kreditinstitute müssen ausschliesslich externe Tester einsetzen.

Nach dem Test stellt die Behörde eine Bescheinigung darüber aus, dass er anforderungsgemäss durchgeführt wurde; andere EU-Aufsichtsbehörden erkennen sie an. Dieses Detail verrät viel über die Denkweise hinter DORA: Das Ergebnis eines Tests ist ein überprüfbarer Nachweis, den eine Aufsichtsbehörde an die nächste weiterreicht – keine interne Foliensammlung.

Welche Nachweise erwartet die Aufsicht?

Wer die Artikel 24 bis 27 mit den Augen eines Prüfers liest, erkennt ein Muster. Das Programm muss dokumentiert sein. Befunde müssen klassifiziert und priorisiert werden.

Die Behebung muss validiert sein, nicht bloss behauptet. Genau deshalb gehört zu TLPT-Ergebnissen eine förmliche Bescheinigung: Eine zweite Behörde kann sich darauf stützen, ohne die Übung zu wiederholen.

Die praktische Frage für einen Compliance-Verantwortlichen lautet deshalb nicht «Haben wir getestet?», sondern «Können wir belegen, was wir getestet, was wir gefunden und was wir behoben haben?». Der Screenshot eines Monitoring-Dashboards beantwortet davon nichts. Er stammt aus keiner unabhängigen Quelle, ist gegen nachträgliche Änderungen nicht geschützt und sagt nichts darüber aus, wie der Test abgelaufen ist.

Nachweise, die einer aufsichtlichen Prüfung standhalten, entstehen im Test selbst, durch eine Partei ohne Interesse am Ergebnis, in einer Form, die sich nachträglich nicht unbemerkt ändern lässt. Diesen Massstab sollten Sie an jeden Anbieter in Ihrem Testprogramm anlegen, unabhängig davon, was er prüft. Fragen Sie, woran sein Bericht belegt, dass der Test wie beschrieben stattgefunden hat – und was verhindert, dass zwischen Durchführung und Ablage jemand an den Zahlen dreht.

Wo gehören DDoS-Resilienztests in die DORA-Compliance?

Verfügbarkeit ist die Resilienzeigenschaft, auf die Denial-of-Service-Angriffe zielen, und die Bedrohungslage verschärft sich weiter. Cloudflares Threat Report 2026, veröffentlicht im März 2026, weist für das Jahr 2025 insgesamt 47,1 Millionen abgewehrte DDoS-Angriffe im Netz des Anbieters aus – ein Plus von 121 Prozent gegenüber dem Vorjahr. Bereits der DDoS-Bedrohungsbericht desselben Anbieters für das erste Quartal 2025 verzeichnete 20,5 Millionen blockierte Angriffe in einem einzigen Quartal, ein Anstieg von 358 Prozent im Jahresvergleich – und Banken und Finanzdienstleister rückten in der Rangliste der meistangegriffenen Sektoren weiter nach oben.

Bei einer Bank zielen diese Angriffe auf genau die Systeme, die Artikel 24(6) im Blick hat: das E-Banking-Portal, das Zahlungs-Gateway, das Trading-Frontend. Systeme also, die kritische oder wichtige Funktionen unterstützen und mindestens jährlich mit geeigneten Tests zu prüfen sind.

Ein Blick zurück auf die Aufzählung in Artikel 25(1) zeigt, wie genau ein solcher Test dort hineinpasst. Eine kontrollierte DDoS-Simulation gegen die eigene Infrastruktur ist szenariobasierter Test, Leistungstest und End-to-End-Test der Verfügbarkeit in einem. Sie beantwortet die Frage, an der jede Schreibtischübung scheitert: Hält der Abwehr-Stack, für den Sie bezahlen, tatsächlich stand, wenn realistischer Angriffsverkehr eintrifft?

Unser Leitfaden zum Testen Ihres DDoS-Schutzes zeigt, wie Sie den ersten Durchlauf aufbauen; unser Beitrag zum DDoS-Stresstest beschreibt, wie ein kontrollierter Testlauf in der Praxis abläuft.

Obsidio führt Tests genau dieser Art durch, zugeschnitten auf die Rahmenbedingungen, unter denen regulierte Unternehmen arbeiten. Die Domain-Inhaberschaft wird vor dem ersten Paket über einen DNS-TXT-Eintrag geprüft; eine Simulation kann also nie Infrastruktur treffen, über die Sie keine Verfügungsgewalt haben. Jeder Durchlauf steigert die Intensität schrittweise und lässt sich jederzeit live abbrechen.

Der Angriffsverkehr stammt von über 100’000 weltweit verteilten echten Geräten und nicht von einer Handvoll Rechenzentrums-IPs. Genau das macht das Ergebnis aussagekräftig: Abwehrmechanismen, die die Konzentration der Quellen als Schlüssel verwenden, verhalten sich gegen eine einzelne Maschine völlig anders als gegen ein realistisch verteiltes Muster. Zehn Simulationstypen decken Floods auf der Anwendungsschicht, langsame Angriffe, das Erschöpfen von Verbindungen und protokollspezifische Vektoren ab; im Jahresprogramm lassen sich die Szenarien also durchwechseln, statt immer dasselbe zu wiederholen.

Beim Nachweis wird der DORA-Bezug konkret. Obsidio erzeugt kryptografisch attestierte Berichte, die sich nachträglich nicht unbemerkt ändern lassen: Sie entstehen in Trusted Execution Environments und sind DORA, FINMA und NIS2 zugeordnet.

Der Bericht eines Durchlaufs taugt zur Vorlage bei der Aufsicht – ein unabhängiger, überprüfbarer Nachweis darüber, was wann, mit welcher Intensität und mit welchem Ergebnis getestet wurde. Genau diese Form von Nachweis setzen die Artikel 24(5) und 24(6) voraus. Ein erneuter Test nach der Behebung liefert anschliessend die Validierung, die die Verordnung verlangt.

Stärke wird bewiesen, nicht versprochen. DORA hat diesen Grundsatz in geltendes Recht überführt: Seit dem 17. Januar 2025 fragt die Aufsicht nicht, ob Sie Ihre kritischen Systeme für resilient halten, sondern welche Nachweise Sie vorlegen können.

Was gilt für Schweizer Institute?

Die Schweiz ist kein EU-Mitgliedstaat; DORA gilt für Schweizer Unternehmen also nicht unmittelbar. Die Schweizer Aufsicht ist auf eigenem Weg am selben Punkt angelangt: Das FINMA-Rundschreiben 2023/1 zu operationellen Risiken und Resilienz bei Banken, in Kraft seit dem 1. Januar 2024, verankert die Grundsätze des Basler Ausschusses zur operationellen Resilienz – mit Übergangsfristen für die Resilienzbestimmungen bis Anfang 2026. Die aufsichtliche Erwartung weist damit beidseits der Grenze in dieselbe Richtung: kritische Funktionen identifizieren, die Systeme dahinter testen und die Ergebnisse belegen.

Die NIS2-Richtlinie der EU (Richtlinie (EU) 2022/2555) rundet das Bild ab. Die Mitgliedstaaten mussten sie bis zum 17. Oktober 2024 umsetzen; sie erfasst wesentliche und wichtige Sektoren weit über den Finanzbereich hinaus. Für Finanzunternehmen geht DORA als spezifischeres Regime vor – die IKT-Risiko- und Testpflichten einer Bank laufen also über DORA und nicht über NIS2, während Gruppengesellschaften ausserhalb des Finanzperimeters durchaus unter NIS2 selbst fallen können.

Für ein Schweizer Institut mit EU-Geschäft sind das drei Regime mit einem gemeinsamen Nenner. Ein Resilienztest, der den Aufwand lohnt, sollte Nachweise liefern, die sich in allen dreien verwenden lassen. Deshalb ordnet Obsidio jeden attestierten Bericht gleichzeitig FINMA, DORA und NIS2 zu statt nur einem einzelnen Regelwerk.

Wie wird ein Testprogramm DORA-tauglich?

Die Reihenfolge ergibt sich aus den Artikeln selbst:

• Zuerst die kritischen oder wichtigen Funktionen identifizieren. Artikel 24(6) setzt an den Systemen an, die sie unterstützen; die Funktionsübersicht entscheidet also darüber, was überhaupt zu testen ist.
• Diese Systeme inventarisieren, einschliesslich derer, die bei Dritten laufen.
• Einen Jahreskalender aufsetzen, der die Bandbreite aus Artikel 25(1) ausschöpft, statt einen einzelnen Testtyp zu wiederholen – mit Verfügbarkeitsszenarien neben den klassischen Schwachstellenprüfungen.
• Jeden Befund in einen dokumentierten Behebungsprozess überführen, mit Validierung am Schluss. Artikel 24(5) behandelt einen unbehobenen Befund als offene Pflicht.
• Den TLPT-Zyklus früh planen, falls Ihre Aufsicht Sie zu den benannten Unternehmen zählt. Artikel 27 macht qualifizierte Tester zur zwingenden Voraussetzung, und für den Dreijahresrhythmus müssen die Verträge mit den Testern rechtzeitig stehen.

Um einen autorisierten DDoS-Resilienztest in diesen Kalender aufzunehmen – mit Nachweisen, die Sie der Aufsicht vorlegen können, statt auf Zusagen angewiesen zu sein, für die jemand bürgen muss –, sehen Sie sich die Obsidio-Plattform an oder nehmen Sie Kontakt mit dem Team auf. Unabhängig, neutral, überprüfbar: Resilienz, die Sie belegen können.

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.

Die anderen neun Simulationstypen dieser Serie beantworten eine Frage: Hält Ihr Netzrand stand, wenn bösartiger Datenverkehr eintrifft? Das ist wichtig zu wissen, nur ist es nicht die einzige Frage. Eine zweite kann kein Flood klären: Funktioniert Ihr Login noch, wenn sich tausend Personen gleichzeitig anmelden, und verkraftet der Session-Store das?

Für genau diese Frage steht Puppeteer Script im Obsidio-Katalog. Der Typ ist kein Flood, und gemessen wird er nicht in Anfragen pro Sekunde. Der Test führt ein Script, das Sie selbst geschrieben haben, auf jedem Worker gleichzeitig in einem echten Browser aus und meldet, ob jeder Durchlauf zu Ende gekommen ist. Synthetische Nutzertests unter echter Parallelität erreichen damit Schichten eines Banken-Stacks, an die blosser Angriffsverkehr nie herankommt.

Dieser Beitrag gehört zu einer Serie über die zehn Simulationstypen, die Obsidio ausführt – ein Beitrag je Typ. Neun davon sind Angriffssimulationen. Dieser nicht, und genau deshalb gehört er in die Reihe: Er deckt ab, was die anderen neun ungeprüft lassen. Wie die Kategorien zusammenhängen, erklärt unser Leitfaden dazu, wie Sie Ihren DDoS-Schutz testen.

Was Puppeteer-Script-Tests tatsächlich tun

Jeder Worker startet einen einzelnen Chromium-Tab und verbindet Puppeteer damit. Die Puppeteer-Dokumentation beschreibt das nüchtern: connect() hängt Puppeteer an eine bereits laufende Browser-Instanz an («attaches Puppeteer to an existing browser instance»). Zurück erhält der Worker ein page-Objekt, das laut Dokumentation die Methoden bereitstellt, um mit einem einzelnen Tab im Browser zu arbeiten («methods to interact with a single tab or extension background page in the browser»). Navigieren, Klicken, Tippen, JavaScript im Seitenkontext auswerten: alles verfügbar, denn hier läuft ein echter Browser – kein Lastgenerator, der sich über den User-Agent als Browser ausgibt.

Ihr Script läuft als Rumpf einer async-Funktion, einmal je Iteration, in einer Schleife, bis die Laufzeit des Testlaufs endet. Jede Iteration ist ein eigener Versuch mit eigenem Timeout; überzieht eine Iteration, wird sie abgebrochen und mit Begründung als Fehlschlag protokolliert. Ein Syntaxfehler wirft schon beim Start eine Exception und bringt den gesamten Durchlauf zu Fall.

Ein Verkehrsmuster gibt es hier nicht zu beschreiben – genau das unterscheidet diesen Typ von allen anderen im Katalog. Ein Flood folgt einem festen Muster; dieser Test folgt Ihrem Ablauf. Eine Zahlungsauslösung kann ein Dutzend Aufrufe umfassen, zwei davon an Systeme, die Ihnen nicht gehören.

Einfach gesagt: Sie schreiben einen kleinen Browser-Bot, der eine Aufgabe erledigt – anmelden, Formular ausfüllen, Schaltfläche klicken –, und die Plattform verteilt ihn auf jeden Worker und lässt ihn für die Dauer der Simulation in Dauerschleife laufen.

Wozu synthetische Nutzertests gut sind

Floods beantworten Fragen zu Kapazität und Filterung. Gescriptete Abläufe zeigen dagegen, ob die Anwendung unter Last noch korrekt arbeitet – eine Eigenschaft, die unabhängig von der Kapazität wegbrechen kann. Das k6-Projekt von Grafana, das neben Lasttests auf Protokollebene auch Tests auf Browser-Ebene anbietet, formuliert denselben Gedanken: Tests auf Browser-Ebene machen die Nutzererfahrung messbar und decken Probleme auf, die sich auf Protokollebene nur schwer greifen lassen («provides a way to measure user experience and find issues that are difficult to catch on the protocol level»). Vier Fragen lassen sich auf diese Weise sinnvoll klären.

Geschäftsabläufe unter Parallelität prüfen. Die Frage ist nicht, ob die Seite eine Antwort geliefert hat, sondern ob die Überweisung angelegt wurde und die Bestätigung den richtigen Betrag zeigt. Assertions im Script halten das je Iteration fest – das Ergebnis ist eine Erfolgsquote für den Ablauf, keine Latenzkurve.

Authentifizierung und Session-Verhalten. Kaum ein Pfad in einer Bank ist so verwinkelt und so fehleranfällig wie die Anmeldung: Token-Ausgabe, Session-Speicher, Step-up-Verifikation, Limits gegen Credential Stuffing. Bei tausend gleichzeitigen Anmeldungen greifen diese Komponenten auf eine Weise ineinander, die so nie geplant war – und ein Test auf Protokollebene, der ein mitgeschnittenes Token wieder einspielt, prüft davon nichts.

Die Teile des Stacks, die ein Flood nie berührt. Ein langsamer Angriff wie Slowloris endet am Webserver und erreicht Ihre Anwendung nie. Ein gescripteter Ablauf schreibt in Ihre Datenbank, belegt Ihren Session-Store und ruft die nachgelagerten Dienste auf, von denen er abhängt.

Ihre eigenen Schutzmassnahmen, aus Sicht des Kunden. Stellt die Bot-Erkennung den Ablauf vor eine Challenge, oder blockiert Ihre WAF ein Formular ab einem gewissen Aufkommen, dann wissen Sie, wie Ihre Schutzmassnahmen mit legitimem automatisiertem Datenverkehr umgehen – den jede Bank in ihren Partner-Integrationen hat.

Welche Teile Ihres Stacks dieser Test belastet

Bei den Angriffssimulationen lautet die nützliche Frage, welche Schutzmassnahme den Angriff hätte abfangen müssen. Hier ist es umgekehrt: Der Test versucht gar nicht erst, an einer Massnahme vorbeizukommen. Es geht stattdessen um Abdeckung – welche Schichten dieser Test wirklich erreicht und welche er auslässt.

Die Parameter – und der Unterschied zu Browser Flood

Vier Parameter lassen sich konfigurieren; auf einen davon kommt es am meisten an.

• Das Script. Der Haupthebel. Es erhält das page-Objekt, ein Kontextobjekt mit Ziel-URL und Ihren Parametern sowie Helfer für Verzögerungen, Logging, benannte Assertions und eigene Metriken. Ein langsameres Script bedeutet weniger Iterationen je Worker in derselben Laufzeit.
• Iterations-Delay. Die Pause zwischen zwei Iterationen, standardmässig eine Sekunde, einstellbar von 100 Millisekunden bis 10 Sekunden. Sie bestimmt zugleich den Timeout je Iteration: das Fünffache des Delays oder 30 Sekunden, je nachdem, was grösser ist. Ein höherer Wert verlangsamt die Schleife und gibt jeder Iteration mehr Spielraum, bevor sie abgebrochen wird.
• User Agent. Für den Durchlauf fest vorgegeben, wenn Sie ihn setzen; andernfalls das, was die Browser-Laufzeit mitbringt.
• Header. Zusätzliche HTTP-Header, die mit jeder Anfrage der Seite mitgeschickt werden. Die Puppeteer-Dokumentation hält fest, dass sie bei jeder von der Seite ausgelösten Anfrage gesendet werden («with every request the page initiates») – genau das macht sie brauchbar für ein Auth-Token oder einen Bypass-Header, den es nur im Test gibt.

Zwei Einschränkungen sollten Sie kennen. Ein Browser je Worker, ohne Parallelität innerhalb eines Workers: Iterationen laufen nacheinander, die Parallelität ergibt sich also allein aus der Worker-Zahl. Und der Test setzt die Browser-Laufzeit auf dem Worker-Gerät voraus, ohne HTTP-Fallback. Fehlt sie, bricht er sofort mit einem Fehler ab, statt stillschweigend auf etwas weniger Realistisches auszuweichen – genau das erwartet man von einem Test, dessen ganzer Wert im echten Browser liegt.

Browser Flood wird häufig mit diesem Typ verwechselt, denn beide steuern echtes Chromium. Der Unterschied liegt darin, was sie laden. Browser Flood ruft Ihre Seite wieder und wieder auf und zählt jede Unterressource, die die Engine holt – die Last besteht aus dem HTML, dem CSS und dem JavaScript, den Bildern und den Hintergrundaufrufen Ihrer Seite. Puppeteer Script lässt die Unterressourcen ausser Acht und folgt stattdessen dem Ablauf: navigieren, tippen, absenden, Ergebnis prüfen. Das eine erzeugt realistisches Volumen, das andere realistisches Verhalten.

Was Sie selbst prüfen können – und wo die Lücke liegt

Die Antwort fällt hier anders aus als in den übrigen neun Beiträgen. Ihr Team kann diese Abläufe scripten. Wer bereits Lasttests für Webanwendungen mit den gängigen Werkzeugen fährt oder End-to-End-Browser-Suiten in der Pipeline pflegt, hat das Können und den grössten Teil des Codes bereits im Haus. Die Lücke liegt an zwei anderen Stellen.

Parallelität in realistischem Massstab. Jede Browser-Session verbraucht spürbar Arbeitsspeicher und CPU-Zeit auf der Maschine, die sie steuert. Die k6-Dokumentation benennt die Folge direkt: Das Hochfahren eines Browser-VU koste zusätzliche Leistung («an additional performance overhead when it comes to spinning up a browser VU»); als ressourcenschonendere Alternative empfiehlt sie, eine kleine Zahl virtueller Nutzer für den Browser-Test mit einer grossen Zahl virtueller Nutzer für einen Test auf Protokollebene zu kombinieren («combining a small number of virtual users for a browser test with a large number of virtual users for a protocol-level test»). Für ein CI-Budget ist dieser Kompromiss vernünftig. Ihre ursprüngliche Frage bleibt damit trotzdem offen: was Ihr Session-Store bei tausend gleichzeitigen echten Abläufen tut.

Geografische Verteilung und Netzvielfalt. Hundert Browser-Sessions aus einer Cloud-Region teilen sich eine Handvoll Adressen, einen Netzwerkpfad und ein Latenzprofil. Ein Montagmorgen mit Hochbetrieb sieht völlig anders aus – und ein solcher Aufbau kann nicht zeigen, wie Ihre Geo-Regeln, Ihr Bot-Scoring oder Ihr Fraud-Monitoring reagieren, wenn derselbe Ablauf gleichzeitig aus dreissig Ländern eintrifft.

Fahren Sie Ihre eigenen gescripteten Abläufe also durchaus gegen Staging. Nur: Ein sauberes Ergebnis bei niedriger Parallelität von einem einzigen Standort ist kein Beleg dafür, dass der Ablauf auch im grossen Massstab hält.

Wie Sie diesen Test sicher gegen die Produktion fahren

Am Anfang steht die Autorisierung – und die ist mehr als ein gesetztes Häkchen. Obsidio prüft die Domain-Inhaberschaft über einen DNS-TXT-Eintrag, bevor Datenverkehr fliesst, fährt die Last schrittweise hoch, statt mit voller Worker-Zahl zu beginnen, und jeder Durchlauf lässt sich live abbrechen. Ein gescripteter Ablauf verlangt darüber hinaus eigene Vorbereitung: Ihr Script erzeugt echte Datensätze. Legen Sie vorab fest, welches Konto es verwendet, was es schreibt und wer hinterher aufräumt. Ein Ablauf, der tausend Überweisungsaufträge einreicht, braucht dieselbe Freigabe im Change-Management wie jede andere Aktivität in der Produktion.

Die Herkunft der Worker schliesst genau die Lücke aus dem vorigen Abschnitt. Obsidio führt Simulationen über 100’000 weltweit verteilte echte Geräte aus – ein gescripteter Ablauf trifft dadurch gleichzeitig aus vielen Ländern und Netzen ein statt aus einer gemieteten Region.

Achten Sie anschliessend auf die richtigen Zahlen, denn zwei Gewohnheiten aus Flood-Tests führen hier in die Irre.

• Lassen Sie die Anfragerate ausser Acht. Für diesen Typ wird bewusst keine Durchsatzschätzung ausgewiesen. Lesen Sie stattdessen Erfolgsquote und Dauer je Iteration. Die Dauer ist hier die tatsächlich verstrichene Zeit des gesamten Ablaufs und nicht die Zeit bis zum ersten Byte einer einzelnen Anfrage – sie ist also mit dem vergleichbar, was ein Kunde erlebt.
• Prüfen Sie mit Assertions, statt sich auf Annahmen zu verlassen. Eine Seite, die lädt, ist noch kein Ablauf, der funktioniert hat. Hinterlegen Sie im Script benannte Assertions für alles, was stimmen muss – Bestätigungstext, Saldo, Weiterleitungsziel – und werten Sie die Pass- und Fail-Zähler aus. Eigene Werte, die Sie je Iteration melden, kommen mit den Ergebnissen zurück: Extrahieren Sie also die Referenznummer, die belegt, dass die Transaktion stattgefunden hat.

Die Arbeitsteilung bei der Auswertung ist dieselbe wie bei allen anderen Typen. Obsidio misst, was von aussen sichtbar ist: ob jede Iteration abgeschlossen wurde, wie lange sie gedauert hat, welche Assertions bestanden haben und wie Ihre vorgelagerten Schutzmassnahmen reagiert haben. Ob Ihr Datenbank-Connection-Pool gesättigt war, ob Ihr SIEM etwas korreliert hat und ob der Pikettdienst alarmiert wurde, zeigen nur Ihre eigenen Konsolen. Während des Testfensters sollte deshalb jemand mitschauen – sonst liefert der Durchlauf nur den halben Befund.

Stärke wird bewiesen, nicht versprochen. Ein Flood zeigt, ob Ihre Abwehr standhält. Ein gescripteter Ablauf zeigt, ob Ihre Bank währenddessen noch funktioniert.

Wo dieser Test in ein Testprogramm gehört

Ein Programm, das nur aus Angriffssimulationen besteht, hat einen grossen blinden Fleck. Jeder der anderen neun Typen sagt etwas über Kapazität, Filterung oder Verbindungsverarbeitung aus. Keiner sagt, ob die Überweisung durchgegangen ist. Für ein reguliertes Institut heisst Resilienz: Die Kunden konnten weiterhin erledigen, wozu sie gekommen sind – und um das zu belegen, braucht es einen Test, der genau das nachstellt.

Konkret heisst das: einen Flood gegen die vorgelagerten Schichten fahren, parallel dazu einen gescripteten Ablauf – und dann prüfen, ob der Ablauf während des Floods noch durchläuft. Näher kommt eine kontrollierte Simulation der Frage nicht, die ein Verwaltungsrat nach einem Vorfall stellt. Es ist zudem die Kombination, die auch die k6-Dokumentation empfiehlt: eine kleine Browser-Last neben einer grossen auf Protokollebene, statt sich zwischen beiden entscheiden zu müssen.

Für regulierte Institute zählt der Nachweis ebenso viel wie das Ergebnis. Obsidio erstellt kryptografisch attestierte Berichte, bei denen jede nachträgliche Änderung erkennbar wäre, FINMA, DORA und NIS2 zugeordnet und in Trusted Execution Environments erzeugt. Ein autorisierter funktionaler Testlauf hinterlässt damit einen Beleg für die Akten statt eines Screenshots, für den jemand bürgen muss.

Wenn Sie einen autorisierten synthetischen Nutzertest gegen die eigene Infrastruktur planen möchten, sehen Sie sich die Obsidio-Plattform an oder nehmen Sie Kontakt auf. Unabhängig, neutral, überprüfbar: Resilienz, die Sie belegen können.

Bevor der Browser eines Kunden Ihre Login-Seite laden kann, bevor ein Zahlungspartner Ihre API aufruft, bevor Ihre eigenen Mitarbeitenden ein internes System öffnen, muss aus einem Namen eine Adresse werden. Diese Abfrage steht ausnahmslos am Anfang, und solange die Antwort aussteht, kommt dahinter nichts in Gang.

Damit ist DNS die eine Abhängigkeit, bei der es nichts nützt, wenn alles andere einwandfrei läuft. Ein DNS-Flood-Angriff berührt Ihre Webserver nie. Er richtet sich gegen den Resolver, der Anfragen nach Ihren Domains beantwortet, und fällt dieser Resolver aus, laufen alle Ihre Server weiter, nur erreicht sie niemand mehr. Ihre Dashboards melden, dass alles in Ordnung ist, und damit haben sie sogar recht. Es kommt nur niemand mehr durch, der etwas anderes berichten könnte.

Dieser Beitrag gehört zu einer Serie über die zehn Simulationstypen, die Obsidio durchführt, einer je Angriff. Sie setzen an ganz unterschiedlichen Stellen an; ein Testprogramm muss deshalb alle Kategorien abdecken, statt in einer einzigen das Volumen hochzudrehen. Wie sie zusammenspielen, zeigt unser Leitfaden dazu, wie Sie Ihren DDoS-Schutz testen.

Was bei einem DNS-Flood-Angriff tatsächlich passiert

Obsidios DNS Flood baut reine DNS-Anfragepakete und schickt sie über TCP an den Ziel-Resolver, formatiert, wie es das Protokoll verlangt: zwei Byte Längenfeld, zwölf Byte DNS-Header, dann die Frage. Dieses Präfix ist keine Designentscheidung. RFC 1035 Abschnitt 4.2.2 legt für TCP fest: «the message is prefixed with a two byte length field which gives the message length, excluding the two byte length field.»

Jede parallele Schleife wiederholt danach pausenlos denselben kurzen Ablauf: Sie öffnet eine neue TCP-Verbindung, schreibt eine Anfrage, wartet auf das erste Byte der Antwort, baut den Socket ab und beginnt von vorn. Die Last landet an zwei Stellen: bei CPU und Speicher des Resolvers, der die Anfrage parst und die Rekursion erledigt, und bei den TCP-Listener-Ressourcen, also Filedeskriptoren und der Tiefe der Accept-Queue.

Stellen Sie sich einen Schwarm von Anrufern vor, die bei der Telefonauskunft eine Nummer erfragen, auflegen und sofort wieder wählen. Jeder Anruf ist eine neue Verbindung, und die Zentrale ist längst voll, bevor der Auskunft die Nummern ausgehen.

Warum TCP und nicht UDP

Die meisten öffentlichen Texte über DNS-Floods gehen von UDP aus, weil echte Angreifer darauf setzen. UDP braucht keinen Handshake, deshalb lässt sich die Absenderadresse fälschen, und genau das macht Reflection und Amplification möglich. Obsidio nutzt keines von beiden, und TCP ist der Grund dafür. Ein abgeschlossener Handshake bedeutet, dass jede Anfrage von einem echten, erreichbaren Gerät kommt, das der Teilnahme zugestimmt hat. Keine Absenderadresse ist gefälscht, und es wird nie Verkehr auf Dritte gelenkt.

TCP bringt zudem etwas, das UDP nicht leisten kann. Weil die Schleife auf das erste Antwortbyte wartet, bevor sie schliesst, liefert jeder Versuch eine Antwort oder das Ausbleiben einer Antwort. Sie messen damit die Auflösungszeit von Ende zu Ende und nicht bloss die Kosten eines Handshakes. Ein Handshake pro Anfrage verteuert jede einzelne, deshalb liegen die erreichbaren Raten niedriger als bei einem UDP-Flood mit gefälschten Absenderadressen. Dafür begrenzt sich die Last von selbst.

Ein Randfall ist TCP damit nicht. RFC 9210 ist deutlich: «All DNS resolvers and servers MUST support and service both UDP and TCP queries». Das Dokument hält zudem fest, dass es zu einer verbreiteten Reaktion auf DNS-Denial-of-Service-Angriffe mit gefälschten Absenderadressen geworden ist, Clients über eine gekürzte UDP-Antwort zu einem erneuten Versuch über TCP zu bewegen («has become a common response to source-address-spoofed, DNS denial-of-service attacks»). Unter Angriffslast schiebt Ihr Rate Limiting legitime Clients also auf den TCP-Pfad, und genau diesen Pfad misst dieser Test.

Welche Ihrer Schutzmassnahmen hätten das abfangen müssen

Gehen Sie die ganze Kette durch, die eine Anfrage passiert, dann lautet die ehrliche Antwort für die erste Zone: Das meiste davon liegt gar nicht im Pfad. Ihre Website steht hinter einer WAF und einem Scrubbing-Dienst. Ihr DNS antwortet auf Port 53 an Ihren Nameservern, häufig bei einer ganz anderen Firma, und Verkehr an diese Nameserver läuft an den Schutzmassnahmen Ihrer Website vollständig vorbei. Diese vordere Zone wird durch die Architektur umgangen, nicht durch eine Technik.

Dass die erste Zone nichts sieht, ist kein Konfigurationsfehler, sondern eine Folge davon, wo DNS in der Architektur steht. Die Frage nach der Abdeckung stellt sich hier deshalb anders: Am eigenen Netzrand lässt sich das nicht beheben, Sie müssen also die Grenzen Ihres Anbieters kennen, und zwar gemessen statt vermutet.

Die Parameter – und wer den Resolver tatsächlich betreibt

Vier Einstellungen prägen einen Durchlauf:

• Parallele Anfragen pro Worker. Standard 20, einstellbar von 1 bis 100. So viele Anfragen hält ein Worker gleichzeitig offen; das entspricht unmittelbar der Zahl offener Sockets zum Resolver.
• Port. Standard 53. Ein abweichender Port erreicht Shims, die woanders lauschen, mit einer Einschränkung: Diese Simulation sendet reines DNS und prüft damit keinen DoH- oder DoT-Endpunkt.
• Zufällige Subdomains. Standardmässig aktiv. Jeder Anfrage wird ein zwölf Zeichen langes zufälliges Label vorangestellt, sodass keine gecachte Antwort existieren kann und der Resolver den vollen Lookup machen muss. Abgeschaltet fangen die Caches nahezu alles ab.
• Query-Typen. Standard sind A, AAAA, MX und ANY, dazu verfügbar sind TXT, CNAME, NS und SOA. Pro Anfrage wird einer zufällig gewählt, weil Record-Typen unterschiedliche Codepfade auslösen und unterschiedlich grosse Antworten erzeugen. Viele Resolver verweigern oder begrenzen ANY; eine Ablehnung ist deshalb ein Ergebnis und kein Fehler.

Die Plattform rechnet mit 20 Anfragen pro Sekunde je paralleler Schleife, unter der Annahme, dass der Resolver innerhalb von 50 ms antwortet. Die Berichte enthalten die Zahl der aktuell offenen Sockets und eine Aufschlüsselung, wie viele Anfragen je Record-Typ hinausgingen.

Bleibt die Frage nach dem Ziel, und an dieser Stelle wird DNS-Testing organisatorisch heikel. Autoritative Server halten Ihre Zonen und beantworten Anfragen von aussen nach Ihren Domains. Rekursive Resolver lösen für Ihre eigenen Clients die Namen aller anderen auf. Fällt die autoritative Seite aus, erreichen Kunden und Partner Sie nicht mehr. Fällt die Rekursion aus, kommen Ihre Mitarbeitenden und Anwendungen nicht mehr nach draussen, Zahlungsnetze und Marktdaten-Feeds eingeschlossen.

In einer typischen Bank betreiben zwei verschiedene Teams diese beiden Dienste. Das autoritative DNS liegt meist bei einem Managed-Provider, aus Redundanzgründen manchmal bei zweien, ausgewählt von denen, die das Domainportfolio verwalten. Die Rekursion läuft in der Regel intern auf der Directory-Plattform und gehört zur Infrastruktur, nicht zur Security. Keines der beiden Teams sieht sich zwangsläufig für eine DDoS-Schutzmassnahme zuständig. Klären Sie vor jeder Festlegung des Prüfumfangs, welchen der beiden Dienste Sie testen, denn davon hängt ab, welche Teams Sie einbeziehen müssen.

Wie Sie sich gegen einen DNS-Flood-Angriff verteidigen

Die Schutzmassnahmen, die hier zählen, sitzen meist nicht am Netzrand vor Ihrer Website.

• Response Rate Limiting, sobald es jemand einschaltet. ISC hält klar fest, dass RRL in BIND 9 standardmässig ausgeschaltet ist («is turned off by default»), und für NSDs rrl-ratelimit gilt dasselbe: «default is off (with a suggested 200 qps)». Verstehen Sie die Funktion, bevor Sie sich darauf verlassen: RRL bremst übermässig viele, fast identische UDP-Antworten, und das Standardverhalten drängt den Client zu einem neuen Versuch über TCP. Gegen UDP-Floods mit gefälschten Absenderadressen ist das eine echte Schutzmassnahme. Gegen Anfragen, die schon über TCP eintreffen und nach durchweg verschiedenen Namen fragen, bewirkt es sehr wenig.
• Kapazität und Anycast. RFC 4786 formuliert es genau: Ein Knoten könne als Senke für Angriffsverkehr aus seinem Einflussbereich dienen und damit verhindern, dass sich Knoten andernorts mit diesem Verkehr befassen müssen («can act as a sink for attack traffic originated within its sphere of influence, preventing nodes elsewhere from having to deal with that traffic»); die Aufgabe, breit gestreuten Angriffsverkehr zu bewältigen, verteile sich dann ihrerseits auf alle Knoten, die den Dienst erbringen («the task of dealing with attack traffic whose sources are widely distributed is itself distributed across all the nodes that contribute to the service»). Achten Sie auf die Bedingung im zweiten Satz. Anycast verteilt eine breit gestreute Last über mehrere Knoten, das hilft; zugleich bedeutet es, dass ein wirklich globaler Angriff an vielen Knoten gleichzeitig eintrifft, statt von einem aufgefangen zu werden.
• Resolver-Grenzen, die Sie sich angesehen haben. Die Standardwerte sind niedrig angesetzt. NSD dokumentiert tcp-count als maximale Zahl gleichzeitiger aktiver TCP-Verbindungen je Server, standardmässig 100 («the maximum number of concurrent, active TCP connections by each server. Default is 100»), bei einem tcp-timeout von 120 Sekunden. Unbound reserviert 10 incoming-num-tcp-Puffer pro Thread und setzt tcp-idle-timeout standardmässig auf 30 Sekunden. RFC 7766 erlaubt die naheliegende Gegenmassnahme: Server dürfen die Zahl gleichzeitiger TCP-Verbindungen je Client-IP oder Subnetz begrenzen («MAY impose limits on the number of concurrent TCP connections being handled for any particular client IP address or subnet»). Gegen eine einzelne Quelle funktioniert das, gegen eine verteilte fällt es deutlich schwächer aus.
• Rekursion nur für Ihre eigenen Clients. Ein Resolver, der dem ganzen Internet antwortet, ist ein weit grösseres Ziel, und er lässt sich gegen andere missbrauchen. Unbound macht das von Haus aus richtig: «by default only localhost (the 127.0.0.0/8 IP netblock, not the loopback interface) is implicitly allowed, the rest is refused.» Konfigurationen verändern sich mit der Zeit; prüfen Sie es also nach, statt sich darauf zu verlassen.
• Anbieterseitige Schutzmassnahmen, schriftlich. Wenn jemand anderes Ihr DNS betreibt, steht das meiste davon in seiner Konfigurationsdatei. Fragen Sie nach den Grenzwerten pro Quelle und in der Summe, nach dem Anycast-Footprint und danach, wie Sie im Ernstfall jemanden ans Telefon bekommen. Eines können Sie allein tun: an einen zweiten, unabhängigen Anbieter delegieren.

Was sich als vermeintlich einfache Lösung verbietet: DNS über TCP zu blockieren. RFC 9210 ist eindeutig, dass das Filtern von DNS über TCP im Allgemeinen schädlich ist («the filtering of DNS over TCP is harmful in the general case»); Netze, die TCP-Port 53 blockieren, riskieren, den Zugang zu erheblichen oder wichtigen Teilen des DNS-Namensraums zu verlieren («risk losing access to significant or important pieces of the DNS namespace»).

Was Sie selbst prüfen können und wo die Ergebnisse täuschen

Einiges davon können Sie heute beantworten. Es lohnt sich zu wissen, welche Teile das sind und wo eine billige Prüfung in die Irre führt.

Lesen Sie die Konfiguration, oder fordern Sie sie an. Notieren Sie die Obergrenze für gleichzeitige Verbindungen, die Timeouts, ob die Rekursion eingeschränkt ist, ob Rate Limiting überhaupt aktiv ist. Betreibt ein Anbieter den Dienst, tritt dieses Gespräch an die Stelle der eigenen Prüfung. Damit wissen Sie, wo die Grenzen liegen. Sie wissen aber nicht, was geschieht, wenn Sie sich ihnen nähern, denn die Leistung eines Resolvers bricht nicht linear ein.

Testen Sie die Alarmierungswege für sich. Lösen Sie einen synthetischen Alarm aus und sehen Sie nach, ob er beim richtigen Pikettdienst landet und ob jemand handelt. Das prüft die Kette bis zum Menschen und braucht keinen Angriffsverkehr. Ob ein DNS-Ausfall überhaupt einen Alarm auslösen würde, sagt es nicht, und genau das ist die Lücke in der dritten Zone.

Fragen Sie Ihren eigenen Resolver von einer einzelnen Maschine ab, mit Freigabe und gegen Infrastruktur, die Ihnen gehört. Das ist nützlich für eine Latenz-Baseline und um zu bestätigen, welche Record-Typen beantwortet werden. Und genau hier liegt die Falle.

Eine einzelne Quelle lässt die offenen Fragen nicht nur unbeantwortet; sie beantwortet mehrere davon falsch, und zwar beruhigend falsch. Ein Verbindungslimit pro Quelle greift bei einer einzelnen Adresse sofort. Ihr Anbieter filtert sie vielleicht als offensichtlichen Missbrauch heraus, bevor sie überhaupt als Last registriert wird. Nichts kommt einer Kapazitätsgrenze nahe, der Durchlauf endet ohne Befund, die Latenz bleibt unauffällig, und das Fazit lautet: DNS hält. So sieht ein echter verteilter Angriff nicht aus. Tausende einzelner IP-Adressen aus Privathaushalten öffnen je eine überschaubare Zahl von Verbindungen, keine Quelle überschreitet einen Schwellenwert, und die Summe kommt am Resolver trotzdem an.

Wie Obsidio einen DNS-Flood-Angriff testet

Die Autorisierung steht am Anfang, und diese Simulation hat einen Haken, den die anderen neun nicht haben.

Obsidio weist die Domain-Inhaberschaft über einen DNS-TXT-Eintrag nach, bevor der erste Verkehr fliesst, fährt die Last stufenweise hoch, und jeder Durchlauf lässt sich live abbrechen. Das deckt Infrastruktur ab, die Ihnen gehört. Einen Resolver, den jemand anderes betreibt, deckt es damit noch nicht ab. Ist Ihr autoritatives DNS an einen Anbieter delegiert, sind dessen Nameserver geteilte Infrastruktur, die weitere Kunden bedient, und dass die Domain Ihnen gehört, berechtigt Sie nicht, Last gegen Maschinen zu autorisieren, die Ihnen nicht gehören. Legen Sie den Prüfumfang ausdrücklich mit Ihrem Anbieter fest und holen Sie sein schriftliches Einverständnis ein, bevor der Durchlauf gebucht wird. Manche Anbieter unterstützen autorisierte Tests auf Anfrage, manche führen sie in Ihrem Auftrag selbst durch. Beides ist ein legitimer Weg. Stillschweigend voraussetzen dürfen Sie es nicht. Wo Sie die Rekursion auf eigenen Resolvern betreiben, gilt der übliche Autorisierungsweg, und der Prüfumfang ist rasch bestimmt.

Ist das geklärt, wählen Sie das Ziel, die Parallelität pro Worker, die Record-Typen und ob zufällige Subdomains den Cache aushebeln. Die Last kommt von über 100’000 weltweit verteilten echten Geräten und nicht von einer Handvoll Instanzen im Rechenzentrum, sodass Verbindungslimits pro Quelle so geprüft werden, wie ein verteilter Angriff sie prüfen würde.

Zwei Grössen sollten Sie während des Durchlaufs beobachten:

• Auflösungszeit und Fehlerrate, in dieser Reihenfolge. Weil jede Anfrage auf eine echte Antwort wartet, messen Sie genau das, was Ihre Kunden erleben. Ein Resolver unter Druck wird langsam, lange bevor er Anfragen ablehnt, und schon in dieser Phase beginnt der Schaden für die Nutzer.
• Offene Verbindungen gegen die dokumentierte Obergrenze. Bleibt die Parallelität bei einer runden Zahl stehen, während die Latenz steigt, haben Sie die Grenze gefunden. Sie kennen sie dann als Messwert und nicht als Standardwert in einem Handbuch.

Klären Sie vorab nüchtern, was der Test zeigen kann und was nicht. Obsidio kann messen, was von aussen sichtbar ist: Auflösungszeit, Fehlerrate, wie viele Verbindungen offen gehalten wurden und wie Ihre Infrastruktur am Netzrand darauf reagiert hat. Ob das Team Ihres Anbieters etwas bemerkt hat, ob Ihr SIEM etwas aufgezeichnet hat und ob jemand alarmiert wurde, zeigt sich nur in Ihren Konsolen und in denen des Anbieters. Sorgen Sie dafür, dass während des Zeitfensters jemand beide im Blick hat.

Stärke wird bewiesen, nicht versprochen. Bei einem DNS-Flood-Angriff zählt nicht, wie viel Bandbreite Sie eingekauft haben. Entscheidend ist, ob den einen Dienst, von dem alle anderen abhängen, je jemand geprüft hat, die Firma eingeschlossen, die Sie für seinen Betrieb bezahlen.

Wo das in ein Testprogramm gehört

Der DNS Flood ist die protokollspezifische Kategorie. Jede andere Simulation zielt auf Ihren Anwendungs-Stack, ihre Befunde betreffen also Ihre Server, Ihre Timeouts und Ihre Schwellenwerte. Diese zielt auf eine Abhängigkeit, und deshalb ist es meist der Durchlauf, der eine Zuständigkeit sichtbar macht, die vorher niemand benannt hatte. Am nächsten verwandt ist der TCP-Connection-Flood, der ebenfalls über ständig neue Verbindungen ansetzt, dort aber untätige Sockets auf einem Server offen hält, über den Sie selbst verfügen. Hier transportiert jeder Socket eine echte Anfrage an einen Resolver, der Ihnen möglicherweise gar nicht gehört, und gemessen wird die Antwort, auf die er wartet.

Die zehn Simulationstypen führen an ganz unterschiedlichen Stellen zum Ausfall. Slowloris prüft, ob sich je jemand Ihre Verbindungs-Timeouts angesehen hat. Ein HTTP-Flood-Angriff findet das knappste Limit in Ihrem Stack. Ein DNS-Flood-Angriff prüft etwas, das Sie vielleicht nicht im Prüfumfang vermutet hätten. Entscheidend ist die Abdeckung aller Kategorien, nicht das Volumen in einer einzelnen.

Für regulierte Institute muss ein Test auch einen Nachweis hinterlassen. Obsidio erzeugt kryptografisch attestierte, manipulationssichere Berichte mit Zuordnung zu FINMA, DORA und NIS2, generiert in Trusted Execution Environments. Das Ergebnis eines Durchlaufs ist damit ein Beleg, den Sie ablegen können, und kein Screenshot, für den Sie sich verbürgen müssen.

Die DNS-Simulation gibt es auf Anfrage und nicht als Standardoption, unter anderem weil das oben beschriebene Gespräch über den Prüfumfang vorher stattfinden muss. Um einen Durchlauf gegen Infrastruktur zu vereinbaren, die Sie testen dürfen, sehen Sie sich die Obsidio-Plattform an oder nehmen Sie Kontakt mit dem Team auf. Unabhängig, neutral, überprüfbar: Resilienz, die Sie belegen können.

Ein TCP-Connection-Flood sendet zu keinem Zeitpunkt Daten. Er baut Verbindungen auf, lässt den Handshake abschliessen und schweigt danach so lange, wie der Socket bestehen darf. Es gibt keine Anfrage, die man prüfen könnte, keine Nutzlast zum Filtern und keine Signatur zum Abgleichen – oberhalb der Transportschicht geschieht schlicht nichts.

Deshalb ist er unangenehm abzuwehren und fällt kaum auf. Die Bandbreite bleibt flach, die Anfragen pro Sekunde bleiben flach. Was sich füllt, sind Zähler, die die meisten Teams nie in ein Dashboard aufgenommen haben: Einträge in der Verbindungstabelle, File Descriptors, Slots im Connection Tracking und die Warteschlange der Verbindungen, die auf ihre Annahme warten. Der Dienst antwortet nicht mehr, während jede Grafik, die gerade jemand im Blick hat, unauffällig aussieht.

Dieser Beitrag gehört zu einer Serie über alle zehn Simulationstypen, die Obsidio durchführt. Jeder von ihnen legt eine andere Bruchstelle frei, und deshalb braucht ein Testprogramm Abdeckung über die Kategorien hinweg statt Volumen in einer einzigen. Wie sie zusammenspielen, steht in unserem Leitfaden dazu, wie Sie Ihren DDoS-Schutz testen.

Was bei einem TCP-Connection-Flood tatsächlich passiert

Jeder parallele Slot baut eine einzelne TCP-Verbindung auf, lässt den Handshake abschliessen und hält den Socket im Leerlauf, bis ein konfigurierter Timeout abläuft. Danach schliesst er ihn und öffnet den nächsten. Darüber liegt weder eine HTTP- noch eine TLS-Schicht, und in keiner Richtung werden Anwendungsdaten geschrieben. Bei einem TCP-Flood dieser Art geht es um Belegung und nicht um Paketvolumen, und die gehaltenen Verbindungen sind vollständig aufgebaut, nicht halb offen.

Verbraucht werden dabei endliche Plätze. Jede aufgebaute Verbindung belegt einen Eintrag in der Verbindungstabelle des Servers, einen offenen File Descriptor im Prozess, der sie hält, einen Eintrag im Connection Tracking jedes zustandsbehafteten Geräts auf dem Weg und einen Anteil am geltenden Socket-Limit pro Quelle. Verbindungen, die eintreffen, während sich die Accept-Queue staut, warten darin; ist sie voll, werden sie abgewiesen. Nichts davon ist CPU-Zeit oder Bandbreite, und genau deshalb bleibt der Angriff so leise.

Zwanzig Leute rufen im Laden an und sagen kein Wort. Alle Leitungen sind belegt, das Personal sitzt bereit, und die echten Kunden hören das Besetztzeichen.

Ein Socket, der verbunden ist und noch nichts gesagt hat, ist für sich genommen nicht verdächtig; ein Mobilgerät mit schlechtem Empfang sieht genauso aus. Deshalb legen Server nicht einfach auf, und deshalb muss die Abwehr in einem Limit bestehen und nicht in einer Regel.

Welche Ihrer Schutzmassnahmen hätte das abfangen müssen

Es lohnt sich, die ganze Kette abzugehen, die eine Verbindung durchläuft, denn die Antwort fällt hier schmaler aus, als die meisten Teams erwarten. Drei Gruppen zählen: was vorgelagert ist, was das Durchgekommene auffängt, und ob Ihnen überhaupt jemand meldet, dass es passiert ist.

Firewall und WAF sind hier sauber auseinanderzuhalten, denn dies ist der Angriff, bei dem es teuer wird, beide für dasselbe Gerät zu halten. Eine Web Application Firewall liest HTTP: Request-Zeilen, Header, Query-Strings, Bodies. Eine Verbindung, die den Handshake abschliesst und danach schweigt, liefert ihr nichts davon, und ein Client, der noch nicht gesprochen hat, ist keine Auffälligkeit, gegen die sich eine Regel schreiben liesse. Die WAF ist nicht falsch konfiguriert; der Verkehr liegt unterhalb der Schicht, an der sie ansetzt.

Eine Netzwerk-Firewall arbeitet mit Adressen, Ports und Verbindungszustand – also mit genau dem, was dieser Angriff ausnutzt. Sie kann zählen, wie viele aufgebaute Verbindungen eine Quelle hält, und die nächste abweisen. In netfilter ist das das Match connlimit, bei dem --connlimit-above den Schwellenwert setzt und --connlimit-mask Quellen nach Präfixlänge gruppiert; nftables kennt dafür ct count. Ihre Mitwirkung hat allerdings einen Preis: Jede Verbindung, die sie verfolgt, kostet einen Eintrag in ihrer eigenen Tabelle. Die Massnahme, die den Angriff am ehesten sieht, ist damit selbst eine Ressource, die er verbraucht.

Die Parameter, und was das hier nicht ist

Vier Einstellungen, jede mit einer Ressource auf Ihrer Seite verknüpft:

• Gehaltene Sockets pro Worker. Standard 20, Bereich 1 bis 100. Mit der Anzahl Worker multipliziert ergibt das die Zahl der Einträge, die Sie der Verbindungstabelle des Ziels zumuten. Die tatsächliche Obergrenze ist der kleinere Wert aus diesem Produkt und den Socket-Limits des Ziels pro Quelle und insgesamt.
• Idle-Timeout. Standard 600’000 Millisekunden, also zehn Minuten; einstellbar von 100 Millisekunden bis zu einer Stunde und durch die Laufzeit des Durchlaufs begrenzt. Ein höherer Wert hält die Sockets länger, der Druck bleibt bestehen und die Öffnungsrate sinkt. Ein niedrigerer Wert sorgt für schnelleren Wechsel und verlagert die Last vom Belegen auf das Annehmen und Abbauen von Verbindungen.
• Denkzeit. Standard 0. Wie lange ein Slot nach dem Schliessen eines Sockets wartet, bevor er den nächsten öffnet; das bestimmt die Nachbesetzungsrate.
• Port. Standardmässig 443 oder 80, abgeleitet aus dem Schema der Ziel-URL. Das Schema legt nur die Nummer fest; die Verbindung ist in beiden Fällen reines TCP.

Ein TLS-Flood gibt Verbindungen ebenfalls auf, zwingt den Server aber zuvor durch einen vollständigen Handshake mit Schlüsselaustausch, Zertifikat und Sitzungsaufbau; diese asymmetrische Kryptografie kostet den Server rund fünfzehnmal so viel wie den Client. Sein Ziel ist die CPU. Ein TCP-Connection-Flood wendet auf keiner Seite Kryptografie auf, und er kostet das Ziel einen Tabelleneintrag und einen File Descriptor.

Slowloris geht wieder anders vor. Er spricht HTTP, sendet eine unvollständige Anfrage und schickt den Rest danach häppchenweise nach – deshalb fangen ihn Timeouts beim Lesen der Header und ein puffernder Proxy ab. Ein TCP-Connection-Flood sendet überhaupt kein HTTP; alles, was über den Inhalt von Anfragen urteilt, ist hier deshalb nicht bloss schwach, sondern gar nicht im Spiel.

Wie Sie sich gegen einen TCP-Connection-Flood verteidigen

Alles Nützliche ist hier eine Zahl, und jede Zahl kann veraltet sein, falsch sein oder niedriger liegen als angenommen. Das sind die Zahlen, die Sie prüfen sollten, mit den dokumentierten Standardwerten, wo es welche gibt:

• Limits für gleichzeitige Verbindungen pro Quelle, auf der Netzwerkschicht. Das Match connlimit von netfilter mit --connlimit-above ist das direkte Werkzeug, und --connlimit-mask fasst statt einer einzelnen Adresse ein ganzes Quellnetz zusammen. Eine Warnung: limit_conn in nginx deckt diesen Fall nicht ab. Die Dokumentation sagt es ausdrücklich: Eine Verbindung wird erst gezählt, wenn der Server eine Anfrage aus ihr bearbeitet und der vollständige Request-Header gelesen ist («a connection is counted only if it has a request being processed by the server and the whole request header has already been read»). Ein Socket, der nie eine Anfrage sendet, wird nie gezählt.
• Kapazität des Connection Tracking. Im Connection Tracker von Linux liegt nf_conntrack_max standardmässig beim Vierfachen der Bucket-Anzahl, und auf einer Maschine mit mehr als 4 GB Speicher liegt die Bucket-Anzahl standardmässig bei 65’536. Wichtiger noch: nf_conntrack_tcp_timeout_established steht standardmässig auf 432’000 Sekunden, also fünf Tage. Eine aufgebaute Verbindung im Leerlauf behält ihren Eintrag tagelang, solange nicht etwas anderes den Socket schliesst.
• Limits für File Descriptors. Jeder Socket ist eine offene Datei. fs.file-max begrenzt die Handles, die der Kernel systemweit vergibt – ohne dokumentierten Standardwert, weil er pro System bemessen wird. Meist greifen die Limits pro Prozess zuerst: nginx setzt worker_connections auf 512 pro Worker, zählt Verbindungen zu Upstreams ebenso mit wie die von Clients und hält fest, dass der Wert das geltende Limit für offene Dateien nicht überschreiten kann («cannot exceed the current limit on the maximum number of open files»); angehoben wird dieses Limit mit worker_rlimit_nofile, das keinen Standardwert hat. Verlassen Sie sich auf die kleinere Zahl.
• Tiefe der Accept-Queue. nginx setzt das Listen-Backlog unter Linux standardmässig auf 511, und was ein Dienst anfordert, wird stillschweigend auf net.core.somaxconn begrenzt – seit Linux 5.4 standardmässig 4096, auf älteren Kerneln 128. Eine kurze Warteschlange macht aus gehaltenen Verbindungen früher abgewiesene.
• Idle-Timeouts, auf einer Schicht, die welche kennt. Die Transportschicht hilft standardmässig nicht: tcp_keepalive_time steht auf zwei Stunden, danach folgen neun Probes im Abstand von 75 Sekunden. nginx macht es besser, mit client_header_timeout von 60 Sekunden für das Lesen eines Request-Headers und keepalive_timeout von 75. Zu prüfen ist, ob jeder Listener in Ihrem Stack ein Gegenstück dazu hat – viele haben keins.

Ein Listener mit einem Header-Timeout von 60 Sekunden schliesst diese Sockets, weil die Simulation sie standardmässig zehn Minuten hält. Das verschiebt die interessante Frage, statt sie zu beantworten. Entschieden wird der Durchlauf davor: in der Tabelle der Firewall, im Load Balancer und in der Accept-Queue.

Was Sie selbst prüfen können, und wo es Sie täuscht

Zwei davon erledigen Sie an einem Nachmittag. Das dritte führt in die Irre.

Lesen Sie die Zahlen aus und rechnen Sie nach. Holen Sie sich das Maximum des Connection Tracking, die Descriptor-Limits, die Verbindungsobergrenze pro Worker, das Listen-Backlog und somaxconn. Der kleinste Wert ist Ihre tatsächliche Kapazität. Das kostet nichts, dauert eine Stunde und überrascht viele. Es sagt Ihnen, wo die Obergrenze liegt – nicht, was geschieht, wenn Sie sie erreichen.

Prüfen Sie die Alarmierungswege für sich allein. Lösen Sie einen synthetischen Alarm aus und prüfen Sie, ob er den richtigen Pikettdienst erreicht und ob jemand darauf reagiert. Dafür braucht es keinen Angriffsverkehr.

Öffnen Sie viele Verbindungen von einer einzelnen Maschine aus, gegen eine Staging-Umgebung, die Ihnen gehört, mit Freigabe aus dem Change-Management. Legitim – und genau hier liegt die Falle.

Die Rechnung sollte man einmal ausschreiben. Nehmen wir an, Ihr Limit pro Quelle liegt bei 100 gleichzeitigen Verbindungen. Eine Maschine versucht fünftausend zu öffnen und wird bei 100 gestoppt. In den Zählern der Firewall erscheinen Abweisungen, die Zahl der Verbindungen bewegt sich kaum, der Dienst bleibt stabil, und der Test wird als bestanden protokolliert. Das Ergebnis stimmt. Der Schluss daraus ist falsch, denn die Massnahme, die sich gerade bewährt hat, ist für das Szenario, vor dem Sie sich fürchten, fast die unwichtigste.

Verteilen Sie dasselbe nun. Zehntausend Quellen halten je zwanzig Verbindungen. Jede Quelle bleibt weit unter dem Limit, keine einzige verletzt eine Regel, und Ihre Tabelle enthält zweihunderttausend aufgebaute Verbindungen. Gleiche Firewall, gleiche Konfiguration, umgekehrtes Ergebnis. Ein Limit pro Quelle senkt nicht die Gesamtkapazität, die verbraucht werden kann; es begrenzt nur den Anteil einer einzelnen Quelle. Bei genügend Quellen wandert die entscheidende Grenze zu Ihrer Tracking-Tabelle und Ihrem Descriptor-Limit – also zu den Zahlen, an die der Test von einer Maschine nie herankam, weil ihn das Limit vorher bei 100 gestoppt hat. Mit Präfixmasken stellt sich dasselbe Problem: Die Gruppierung nach Netz erfasst einen gemieteten Adressblock bei einem Hoster und richtet gegen IP-Adressen aus Privathaushalten wenig aus, die über Tausende unabhängiger Netze verstreut sind.

Sobald das Limit wie die Abwehr aussieht, hebt niemand die dahinterliegenden Grenzwerte an und niemand verfolgt die Tracking-Tabelle in einer Grafik; der Befund, auf den es angekommen wäre, entsteht also nie. Und keine Konfigurationsprüfung sagt Ihnen, wie sich der Stack an seiner Obergrenze verhält. Manche Dienste weisen neue Verbindungen sauber ab, manche bleiben hängen, manche fallen durch ihren Health Check und werden aus dem Verbund genommen, obwohl sie noch laufen.

Wie Obsidio einen TCP-Connection-Flood testet

Obsidio führt das als kontrollierte, autorisierte Simulation gegen Infrastruktur durch, die Ihnen gehört. Die Domain-Inhaberschaft wird über einen DNS-TXT-Eintrag geprüft, bevor überhaupt Verkehr fliesst; die Last steigt stufenweise an, statt auf voller Höhe zu beginnen, und jeder Durchlauf lässt sich im Betrieb abbrechen. Sie wählen die Sockets pro Worker, den Idle-Timeout, die Denkzeit und den Port.

Die Last kommt von über 100’000 weltweit verteilten echten Geräten und nicht von einer Handvoll Instanzen im Rechenzentrum. Genau das kann ein Selbsttest nicht nachbilden: Ein Limit pro Quelle wird so beansprucht, wie eine verteilte Flut es beansprucht – über viele Netze hinweg, wobei jede einzelne Quelle unauffällig bleibt.

• Ignorieren Sie die Anfragerate. Der angezeigte Wert zählt Socket-Öffnungen und nicht Durchsatz, und die Schätzung liegt bei einer Öffnung pro Slot. Er wirkt unscheinbar niedrig, gerade während der Durchlauf greift. Schauen Sie stattdessen auf die gleichzeitigen Verbindungen und den Spitzenwert, dazu auf die Rate der Öffnungsversuche, wenn Sie den Wechsel statt der Belegung prüfen.
• Messen Sie die Erreichbarkeit von aussen. Was Nutzer erleben, ist eine Verbindung, die nicht angenommen wird; serverseitige Messwerte können das verdecken.

Klären Sie die Aufteilung vorher. Obsidio misst, wie viele Verbindungen gehalten wurden, den Spitzenwert, die Öffnungsrate und ob der Dienst von aussen erreichbar blieb – all das ist von aussen sichtbar. Ob Ihr Descriptor-Limit oder Ihre Tracking-Tabelle tatsächlich vollgelaufen ist, was Ihr Error-Log festgehalten hat und ob jemand alarmiert wurde, sehen Sie nur auf Ihren eigenen Konsolen. Sorgen Sie dafür, dass während des Zeitfensters jemand darauf schaut.

Stärke wird bewiesen, nicht versprochen. Ein TCP-Connection-Flood prüft weder Ihre Bandbreite noch Ihre Regeln. Er prüft, ob die Grenzwerte, mit denen Ihr Stack bemessen wurde, noch die Grenzwerte sind, mit denen er läuft.

Wo das in ein Testprogramm gehört

Der TCP-Connection-Flood gehört zur Kategorie Verbindungserschöpfung, gemeinsam mit dem TLS-Flood. Beide zielen auf die Verbindung statt auf die Anfrage: Der eine verbraucht CPU-Zeit über die Kryptografie des Servers, der andere Tabellenplatz durch blosses Schweigen. Ein Stack, der den einen wegsteckt, kann am anderen scheitern; deshalb braucht die Kategorie beide.

Über die zehn Simulationstypen hinweg verschiebt sich die Bruchstelle erheblich. Eine Flut auf der Anwendungsschicht gibt Ihren vorgelagerten Schutzmassnahmen etwas, worauf sie reagieren können, reicht bis zum Connection Pool Ihrer Datenbank und macht aus dem Erkennungsproblem statt Schweigen Lärm. Dieser hier endet auf der Transportschicht, bleibt für Ihre WAF unsichtbar und wird von fünf oder sechs Ganzzahlen in Konfigurationsdateien entschieden.

Für regulierte Institute muss der Durchlauf zudem einen Nachweis hinterlassen. Obsidio erzeugt kryptografisch attestierte, manipulationssichere Berichte mit Zuordnung zu FINMA, DORA und NIS2, erstellt in Trusted Execution Environments. Das Ergebnis ist damit ein Beleg, den Sie ablegen können, und kein Screenshot, für den Sie bürgen müssen.

Um eine autorisierte TCP-Connection-Flood-Simulation gegen Ihre eigene Infrastruktur zu planen, sehen Sie sich die Obsidio-Plattform an oder sprechen Sie mit dem Team. Unabhängig, neutral, überprüfbar: Resilienz, die Sie belegen können.

Ein TLS-Flood-Angriff verlangt von Ihrem Server nichts. Er baut eine Verbindung auf, lässt den Server den vollständigen kryptografischen Handshake abschliessen und reisst die Verbindung dann ab. Keine Request-Zeile, kein Host-Header, kein Pfad. Nichts, was Ihre Web Application Firewall lesen könnte – eine Firewall, die Anfragen prüft, braucht eine Anfrage, die es gibt.

Genau das macht diesen Angriff unangenehm. Der Verkehr ist korrekt aufgebaut. Jede Verbindung ist eine legitime TLS-Verhandlung, die Ihr Server selbst zu Ende geführt hat. Die Kosten sind real, und sie fallen auf Ihrer Seite an, weil sich die Rechenarbeit der Public-Key-Kryptografie ungleich verteilt: Der Client wendet für die Anfrage kaum etwas auf, der Server für die Antwort sehr viel.

Dieser Beitrag gehört zu einer Serie über alle zehn Simulationstypen, die Obsidio durchführt, ein Beitrag pro Angriff. Sie führen an ganz unterschiedlichen Stellen zum Ausfall, und deshalb braucht ein Testprogramm Abdeckung über die Kategorien hinweg statt Volumen in einer einzigen. Wie sie zusammenspielen, steht in unserem Leitfaden dazu, wie Sie Ihren DDoS-Schutz testen.

Was bei einem TLS-Flood-Angriff tatsächlich passiert

Der Client baut eine TLS-Verbindung auf und lässt den Server die Verhandlung zu Ende führen: Schlüsselaustausch, Zertifikat, Sitzungsaufbau. In dem Moment, in dem die gesicherte Verbindung steht, läuft ein sehr kurzer Idle-Timeout ab, und die Verbindung wird abgerissen. Dann öffnet derselbe Slot die nächste. Der Server hat den teuren Teil erledigt und nichts darüber erfahren, was der Client wollte – der Client hat es nie gesagt.

Dieser Aufwand lässt sich genau benennen. Bei einem vollständigen TLS-1.3-Handshake sendet der Server seinen Key Share, sein Zertifikat und eine CertificateVerify-Nachricht, die RFC 8446 als Signatur über den gesamten Handshake mit dem privaten Schlüssel beschreibt («a signature over the entire handshake using the private key»). TLS 1.3 hat zudem die Cipher Suites mit statischem RSA und statischem Diffie-Hellman gestrichen; jeder vollständige Handshake enthält also einen ephemeren Schlüsselaustausch. Signieren mit dem privaten Schlüssel plus ephemere Schlüsselvereinbarung, einmal pro Verbindung – und das, bevor der Server irgendeine Vorstellung davon hat, ob die Verbindung es wert ist, bedient zu werden.

Der Client hat es leicht. Er erledigt seinen Teil des Schlüsselaustauschs, signiert nichts und verwirft die Sitzung Mikrosekunden später, ohne das Zertifikat zu prüfen. Eigene Messungen von Obsidio setzen die CPU-Kosten des Servers bei etwa dem Fünfzehnfachen der Client-Kosten an. Diese Zahl stammt aus unserer eigenen Instrumentierung und nicht aus einem veröffentlichten Standard; der Faktor verschiebt sich mit Schlüsseltyp, Cipher-Auswahl und der Frage, ob Offload-Hardware im Pfad sitzt. Die Richtung verschiebt sich nie.

Zwanzig Personen treten an eine Hochsicherheitstür. Die Wache führt bei jeder die vollständige Identitätsprüfung durch, jedes Dokument, jede Unterschrift. Jede dreht sich danach um und geht. Die Wache arbeitet sich an Besuchern ab, die nie eintreten, und hinterher gibt es keinen einzigen Besuchereintrag, weil niemand eingelassen wurde.

Die Benennung ist historisch gewachsen. Die interne Kennung bei Obsidio lautet ssl-flood, und breit diskutiert wird der Angriff weiterhin als SSL Flood. Umgesetzt ist er aber mit modernem TLS, mit Server Name Indication auf den Zielhost gesetzt.

Welche Ihrer Schutzmassnahmen das hätte abfangen müssen

Es lohnt sich, die ganze Kette abzugehen, die eine Verbindung durchläuft, denn die Antwort ist selten die Massnahme, die man erwartet. Drei Gruppen zählen: was vorgelagert ist, was das Durchgekommene auffängt, und ob Ihnen überhaupt jemand meldet, dass es passiert ist.

Zone 3 fällt hier aus dem Rahmen. Das Signal existiert, auf einer CPU-Kurve, die die meisten Teams längst haben. Die Frage ist, ob es je jemand mit einem Alarm verknüpft hat.

Was Sie steuern, und worin sich das von einem TCP-Connection-Flood unterscheidet

Obsidio gibt vier Parameter frei; zwei davon verändern den Charakter des Durchlaufs:

• Parallele Handshakes pro Worker. Standardmässig zwanzig, einstellbar von eins bis hundert. Der Wert skaliert die gleichzeitige Handshake-Last linear.
• Idle-Timeout. Standardmässig eine Millisekunde. Bei dieser Einstellung wird die Verbindung praktisch im selben Moment abgerissen, in dem sie gesichert steht: Der Server zahlt die Kryptokosten, der Client geht. Erhöhen Sie den Wert, werden Sockets länger gehalten und belegen Ports und File Descriptors – zum Preis einer niedrigeren Handshake-Rate. Sie wählen damit zwischen Druck auf die CPU und Druck auf die Verbindungstabelle.
• Denkzeit. Eine Pause zwischen den Handshakes innerhalb jedes Slots, standardmässig null. Sie bremst den Durchlauf linear, wenn Sie ein gehaltenes Niveau statt einer Spitze wollen.
• Port. Standardmässig 443. Die Zertifikatsprüfung ist auf Client-Seite abgeschaltet; ein abgelaufenes oder selbst signiertes Zertifikat auf einem Test-Endpunkt bricht den Handshake also nicht ab.

Die beiden Angriffe stehen in derselben Kategorie und verhalten sich völlig unterschiedlich. Ein TCP-Connection-Flood-Angriff verhandelt über den TCP-Handshake hinaus nichts, sendet keine Nutzdaten und hält jeden untätigen Socket über Minuten; sein Ziel ist Ihre Verbindungstabelle, also File Descriptors, Einträge im Connection Tracking und die Accept-Queue. Ein TLS-Flood-Angriff ist das Spiegelbild: Seine Sockets leben Millisekunden, und sein Ziel ist Ihr Prozessor. Grosszügige Verbindungslimits bei schwacher CPU scheitern am TLS-Flood-Angriff und stecken einen Connection Flood problemlos weg; eine schnelle CPU hinter einem engen File-Descriptor-Limit verhält sich umgekehrt. Wer nur einen der beiden fährt und die Kategorie als abgedeckt verbucht, merkt das spät.

Wie Sie sich gegen einen TLS-Flood-Angriff verteidigen

Wo TLS terminiert wird, entscheidet fast alles. Fangen Sie dort an.

• Terminieren Sie TLS an einer Stelle, die auf Handshakes ausgelegt ist. Ein CDN oder ein Managed Load Balancer teilt den Pfad in zwei Hälften. Cloudflares Full-Modus dokumentiert genau diese Form: HTTPS zwischen Besucher und Cloudflare, wobei Cloudflare eine eigene Verbindung zum Ursprungsserver aufbaut. AWS dokumentiert dieselbe Struktur für einen Application Load Balancer, der zwei Verbindungen unterhält, eine zum Client und eine zum Ziel («maintains two connections: one connection with the client and one connection with a target»). Der übliche Vorbehalt gilt: Eine über Proxy geführte Website, deren Ursprungsserver weiterhin auf Port 443 antwortet, ist nicht geschützt, sondern nur verdeckt.
• Verbuchen Sie Session Resumption nicht als Gegenmassnahme. Sie ist ein Performance-Feature und leistet hier nichts. RFC 8446 erklärt, warum: Resumption nutzt eine Pre-Shared-Key-Identität, die der Server erst nach einem bereits abgeschlossenen Handshake ausgegeben hat, und nur dann kann der abgeleitete Schlüssel den kryptografischen Zustand anstelle eines vollständigen Handshakes aufsetzen («bootstrap the cryptographic state instead of a full handshake»). Eine Verbindung ohne vorherige Sitzung hat nichts vorzuweisen. nginx liefert ssl_session_cache none, ssl_session_timeout 5m und ssl_session_tickets on aus; all das betrifft wiederkehrende Nutzer, nicht Ihre Abwehrlage.
• Prüfen Sie, auf welcher Ebene Ihre Verbindungslimits liegen. Das ist die Einstellung, die am häufigsten unbemerkt falsch gesetzt ist. nginx liefert zwei Limiter für Verbindungen pro Quelle. Der HTTP-Limiter zählt eine Verbindung erst, wenn ein vollständiger Request-Header gelesen ist, und bekommt diesen Verkehr damit nie zu sehen. Das Gegenstück auf Stream-Ebene, verfügbar seit nginx 1.9.3, zählt Verbindungen pro Schlüssel ohne diese Bedingung. Ist Ihre einzige Obergrenze pro Quelle die HTTP-Variante, liegt sie nicht in diesem Pfad.
• Messen Sie Ihre Handshake-Reserve, weil sie Ihnen niemand nennen kann. Handshakes pro Sekunde hängen vom Schlüsseltyp Ihres Zertifikats ab, von der Cipher-Auswahl, vom Prozessor und davon, ob Offload-Hardware im Pfad sitzt. Wir haben keine veröffentlichte Zahl gefunden, die es wert wäre, wiederholt zu werden, und erfinden keine. Ein verwandter Standardwert: ssl_handshake_timeout im Stream-Modul von nginx liegt bei sechzig Sekunden – das begrenzt langsame Handshakes und richtet gegen schnelle nichts aus.

Was Sie selbst prüfen können, und wo das in die Irre führt

Einiges davon können Sie heute ohne fremde Hilfe beantworten. Es lohnt sich zu wissen, wo eine billige Prüfung Sie täuscht.

Lesen Sie die Konfiguration. Stellen Sie fest, wo TLS terminiert wird, ob Ihr Ursprungsserver direkt auf seiner eigenen IP-Adresse antwortet und ob Ihr Limit für Verbindungen pro Quelle auf HTTP-Ebene oder darunter sitzt. Das kostet einen Nachmittag und sagt Ihnen, dass das Design stimmt. Es sagt Ihnen nicht, dass der Prozessor durchhält.

Prüfen Sie die Alarmierungswege separat. Lösen Sie einen synthetischen CPU-Alarm aus und sehen Sie nach, ob er beim richtigen Pikettdienst ankommt und ob jemand handelt. Damit ist der Meldeweg geprüft, und Angriffsverkehr braucht es dafür nicht.

Fahren Sie einen Test aus einer einzigen Quelle gegen eine Staging-Umgebung, mit Freigabe aus dem Change-Management, auf Infrastruktur, die Ihnen gehört. Das ist legitim und nützlich. Und genau hier liegt die Falle.

Ein Test von einer Maschine beantwortet die Fragen aus Zone 1 nicht bloss nicht – er beantwortet mehrere davon falsch, und zwar beruhigend falsch. Ihr Limit für Verbindungen pro Quelle greift bei einer einzelnen Adresse sofort. Reputationsfilter erledigen eine Rechenzentrums-IP mühelos. Auch das Ungleichgewicht arbeitet gegen Sie: Der Prozessor eines einzelnen Clients begrenzt, wie viele Handshakes er anstossen kann; die erreichte Spitze sagt also mehr über Ihre Testmaschine aus als über Ihre Abwehr. Jede Massnahme in Zone 1 scheint zu halten, und Sie schliessen daraus, dass Sie abgedeckt sind.

Dann trifft echter Verkehr von Tausenden IP-Adressen aus Privathaushalten in Dutzenden Ländern ein, keine einzelne Quelle tut etwas Auffälliges, und dieselben Massnahmen verhalten sich völlig anders – weil sie an der Konzentration der Quellen und an der Realitätsnähe des Verkehrs ansetzen. Eine Maschine bildet weder das eine noch das andere ab. Die billige Prüfung bescheinigt damit genau jenen Massnahmen ein Bestehen, denen Sie am meisten vertrauen müssen; und ein synthetischer Alarm sagt Ihnen nicht, ob jemand eine steigende Prozessorkurve als Angriff gelesen hätte und nicht als fehlerhaftes Deployment.

Wie Obsidio einen TLS-Flood-Angriff testet

Am Anfang steht die Autorisierung. Die Domain-Inhaberschaft wird vor dem ersten Verkehr über einen DNS-TXT-Eintrag geprüft, Durchläufe fahren stufenweise hoch, und jeder Durchlauf lässt sich im Betrieb abbrechen. Sie wählen die Parallelität, den Idle-Timeout und die Taktung. Die Last kommt von über 100’000 weltweit verteilten echten Geräten und nicht von einer Handvoll Instanzen im Rechenzentrum; eine Obergrenze pro Quelle wird damit so geprüft, wie verteilter Verkehr sie prüfen würde.

Zwei Grössen, auf die Sie achten sollten:

• Handshakes pro Sekunde, nicht Anfragerate. Jeder abgeschlossene Handshake zählt im Bericht als eine Anfrage; die Ratenangabe ist hier also eine Handshake-Rate. Vergleichen Sie sie mit der Reserve, die Sie vorher gemessen haben.
• Verbindungszahlen nach dem Handshake. Aktive und maximale Verbindungen zeigen, wie viele Sockets zwischen abgeschlossenem Handshake und Abbau stehen. Beim Standard-Idle-Timeout bleibt das auch unter voller Last niedrig, und eine niedrige Zahl neben einer hohen Handshake-Rate ist die Signatur dieses Angriffs und nicht die eines Connection Floods.

Diese Aufteilung sollte man klar benennen. Obsidio berichtet, wie viele Handshakes abgeschlossen wurden, wie viele fehlgeschlagen sind, wie Ihre Schutzmassnahmen am Netzrand reagiert haben und was die Verbindungszahlen gemacht haben – all das ist von aussen sichtbar. Ob die Prozessoren auf Ihren TLS-Terminatoren ausgelastet waren, ob Ihr SIEM etwas aufgezeichnet hat und ob jemand alarmiert wurde, sehen Sie nur auf Ihren eigenen Konsolen. Lassen Sie während des Zeitfensters jemanden dort mitschauen, sonst bleiben diese Fragen offen.

Stärke wird bewiesen, nicht versprochen. Ein TLS-Flood-Angriff verlangt von Ihrem Server nichts. Er verlangt von ihm, tausendfach zu beweisen, wer er ist, und geht dann ohne ein Wort.

Wo das in ein Testprogramm gehört

Der TLS-Flood gehört in die Kategorie Verbindungserschöpfung, zusammen mit dem TCP-Connection-Flood. Beide umgehen die Anwendung vollständig, und zusammen trennen sie zwei Fehlermodi, die Teams gewohnheitsmässig vermischen: Der eine erschöpft den Kryptopfad, der andere die Verbindungstabelle. Wer nur den zweiten prüft, lässt seine Handshake-Kapazität ungeprüft, und kein Test mit einer Flut auf der Anwendungsschicht schliesst diese Lücke, weil ein HTTP-Flood-Angriff die Handshake-Kosten über wiederverwendete Verbindungen verteilt.

Die zehn Simulationstypen führen an ganz unterschiedlichen Stellen zum Ausfall. Langsame Angriffe wie Slowloris hungern Ihren Verbindungspool aus, indem sie eine Anfrage nie abschliessen. Ein TLS-Flood-Angriff schliesst alles ab, was er beginnt, und geht. Entscheidend ist die Abdeckung über die Kategorien hinweg, nicht das Volumen in einer davon.

Für regulierte Institute muss der Test zudem einen Nachweis hinterlassen. Obsidio erstellt kryptografisch attestierte, manipulationssichere Berichte mit Zuordnung zu FINMA, DORA und NIS2, erzeugt in Trusted Execution Environments. Das Ergebnis eines Durchlaufs ist damit ein Beleg, den Sie ablegen können, und kein Screenshot, für den Sie bürgen müssen.

Um eine autorisierte TLS-Flood-Simulation gegen Ihre eigene Infrastruktur zu planen, sehen Sie sich die Obsidio-Plattform an oder nehmen Sie Kontakt auf. Unabhängig, neutral, überprüfbar: Resilienz, die Sie belegen können.

Ein RUDY-Angriff sieht nicht nach einem Angriff aus. Die Anfragezeile ist gültig, der Header-Block sauber abgeschlossen, und Content-Length nennt dem Server genau die Zahl der Byte, die noch folgen. Diese Zahl stimmt sogar. Auffällig ist einzig das Tempo, in dem der Body eintrifft: ein Byte, dann eine lange Pause, dann das nächste.

Damit ist RUDY schwerer zu fassen als Slowloris. Slowloris sendet eine Anfrage, die er nie zu Ende bringt; wer auf eine vollständige Anfrage wartet, merkt also, dass etwas fehlt. RUDY liefert genau den Teil vollständig, den Ihre Schutzmassnahmen prüfen, und hält jenen zurück, den sie nie ansehen. Ihre WAF findet nichts Verdächtiges – nach allem, was ihr vorliegt, ist auch nichts verdächtig.

Dieser Beitrag gehört zu einer Reihe über alle zehn Simulationstypen, die Obsidio durchführt. Die Typen setzen an ganz unterschiedlichen Stellen an; ein Testprogramm braucht deshalb Abdeckung über alle Kategorien und nicht Volumen in einer einzigen. Wie sie zusammenspielen, steht in unserem Leitfaden dazu, wie Sie Ihren DDoS-Schutz testen.

Was ein RUDY-Angriff tatsächlich macht

RUDY, kurz für R-U-Dead-Yet, öffnet parallel mehrere HTTP-POST-Verbindungen und schickt auf jeder einen vollständigen Anfragekopf: Anfragezeile, Host, einen Content-Type und eine Content-Length mit der exakten Grösse des folgenden Bodys. Diesen Body liefert er anschliessend Byte für Byte.

Der Server verhält sich dabei völlig vernünftig. Er kennt die angekündigte Menge, er hat einen Teil davon erhalten, und der Client meldet sich weiterhin. Also bleibt der zuständige Handler der Verbindung zugewiesen und wartet. Dieser Handler – ein Thread oder ein Worker-Slot – bedient in dieser Zeit niemanden sonst. Bei einigen Hundert gleichzeitigen Verbindungen ist der Pool leer. Echte Nutzer bekommen keine Fehlerseite zu sehen, sondern laufen in ein Timeout.

Zum Vergleich: Zwanzig Leute füllen am Schalter ein langes Formular aus und schreiben alle zehn Sekunden einen Buchstaben. Der Sachbearbeiter muss warten. Weiter kommt er erst, wenn das Formular fertig ist – und ausgefüllt wird es ja, nur nicht in diesem Jahr.

Eine kurze Rechnung zeigt, warum kein Slot wieder frei wird. Voreingestellt sind eine Content-Length von 100’000 Byte und ein Abstand von 10 Sekunden zwischen zwei Byte. Der Body braucht damit 1’000’000 Sekunden, also rund 11,6 Tage; so lange dauert kein realistischer Durchlauf. Jeder Slot hält seinen Socket, bis der Server ihn abbaut oder der Durchlauf endet. Bei 20 Sockets pro Worker liegt die Zahl der festhängenden Anfragen somit beim Zwanzigfachen der Worker-Zahl – und dort bleibt sie.

Welche Ihrer Schutzmassnahmen hier greifen müssten

Es lohnt sich, die ganze Kette abzugehen, die eine Anfrage durchläuft, denn die Antwort liegt selten bei der Massnahme, die man zuerst vermutet. Drei Bereiche zählen: was vorgelagert ist, was die durchgelassene Last auffängt, und ob Ihnen überhaupt jemand meldet, dass etwas passiert ist.

In Zone 1 liegt der Unterschied zwischen diesem Angriff und Slowloris. Eine WAF, die auf eine vollständige Anfrage wartet, hat bei Slowloris einen guten Grund, den Verkehr zurückzuhalten: Die Anfrage ist unfertig. Genau diesen Grund nimmt RUDY ihr weg. Eine Massnahme, die entscheiden soll, ob diese Anfrage legitim ist, wird sie für legitim erklären – und liegt damit richtig. Als Signal bleibt allein, wie schnell der Body eintrifft, und diese Grösse werten die meisten Produkte zur Anfrageinspektion nicht aus.

Was RUDY von Slowloris unterscheidet

Fünf Unterschiede zählen. Jeder betrifft eine andere Schutzmassnahme.

• Wo die Anfrage unvollständig bleibt. Das klassische Slowloris hält die Leerzeile zurück, die den Header-Block abschliesst; der Server kommt also über das Lesen der Header nie hinaus. RUDY sendet diesen Block korrekt und hält stattdessen den Body zurück. Ein Timeout für das Lesen der Header fängt den ersten Fall ab und hat mit dem zweiten nichts zu tun.
• Ob das Ende des Bodys angekündigt ist. Slowloris kennt eine Variante mit langsamem Body; sie nutzt aber Chunked Transfer Encoding und sendet den abschliessenden Chunk der Länge null nie, sodass der Body kein angekündigtes Ende hat. RUDY nennt eine exakte Länge und hält sich daran, nur eben langsam. Hier fehlt kein Abschluss.
• Welche Ressource zuerst ausgeht. Slowloris zielt auf den Verbindungspool vor Ihrer Applikation, RUDY auf die Handler des Webservers – denn der Server hat die Anfrage angenommen und ihr einen Worker fest zugewiesen.
• Welches Timeout entscheidet. Bei Slowloris ist es ein Timeout für das Lesen der Header, bei RUDY eines für das Lesen des Bodys – und auch das nur, wenn es eine Mindestdatenrate durchsetzt.
• Wie es im Log aussieht. Eine unfertige Slowloris-Anfrage erzeugt oft gar keinen Eintrag. Eine RUDY-Anfrage sieht aus wie ein gewöhnlicher POST von einem Client mit schlechter Leitung.

Viel einzustellen gibt es nicht. Die Sockets pro Worker stehen standardmässig auf 20 und reichen von 1 bis 100; damit legen Sie fest, wie viele Handler Sie besetzen wollen. Der Abstand zwischen zwei Body-Byte steht standardmässig auf 10 Sekunden und reicht von 1 bis 60: Ein kürzeres Intervall baut Sockets häufiger neu auf; ein längeres erschwert es, den einzelnen Socket per Timeout loszuwerden, riskiert aber, dass der Server ihn wegen Inaktivität schliesst. Die angekündigte Content-Length steht standardmässig auf 100’000 Byte und reicht von 1’000 bis 10’000’000; zusammen mit dem Intervall bestimmt sie die Lebensdauer jedes Sockets.

Host, Content-Type und Content-Length sind fest vorgegeben und lassen sich nicht überschreiben. Die zutreffend angekündigte Länge ist der Kern des Angriffs; liesse man sie verändern, wäre es eine andere Simulation.

Wie Sie sich gegen einen RUDY-Angriff schützen

Entscheidend ist eine Regel dafür, wie langsam ein Client einen Body liefern darf, den er bereits angekündigt hat. Drei Massnahmen leisten das, zwei häufig genannte nicht.

• Eine Mindestdatenrate beim Lesen des Bodys. Bei Apache ist das mod_reqtimeout; sein dokumentierter Standard lautet RequestReadTimeout handshake=0 header=20-40,MinRate=500 body=20,MinRate=500. Der Body-Wert räumt mindestens 20 Sekunden ein, und laut Dokumentation verlängert jeder Dateneingang das Timeout entsprechend der Mindestdatenrate: 500 Byte bringen eine Sekunde mehr. Ein Byte alle zehn Sekunden bringt eine Fünfhundertstelsekunde, das Zeitfenster wächst also kaum, und die Verbindung wird geschlossen. Zwei Einschränkungen: Das Modul hat den Status einer Erweiterung und bleibt untätig, solange es nicht geladen ist; und der Standardwert für den Body kennt keine Obergrenze, sodass ein Client, der tatsächlich 500 Byte pro Sekunde durchhält, sein Timeout beliebig weiter verlängert.
• Verlassen Sie sich nicht auf ein Idle-Timeout. nginx liefert client_body_timeout 60s aus, und die Dokumentation ist eindeutig: Der Wert gilt nur für die Spanne zwischen zwei aufeinanderfolgenden Leseoperationen, nicht für den gesamten Body. Ein Byte alle zehn Sekunden setzt ihn endlos zurück, und weil der Angreifer das Intervall wählt, gibt es keinen Wert, der echte Nutzer verschont und den Angriff trotzdem stoppt. Das Problem ist nicht die gewählte Zahl, sondern der Mechanismus: Er misst die falsche Grösse.
• Ein Reverse Proxy, der Bodys vollständig puffert. Bei nginx ist proxy_request_buffering on der Standard; laut Dokumentation liest er damit den kompletten Body vom Client, bevor er die Anfrage an den Backend-Server weitergibt. Ihr Upstream wird also erst kontaktiert, wenn der Body vollständig vorliegt. Das schützt wirksam, unter zwei Bedingungen: Der Ursprungsserver darf nicht direkt erreichbar sein, und der Proxy muss viele offene Verbindungen mit geringem Aufwand halten können.
• Grenzen für gleichzeitige Verbindungen je Quelle. Sie beenden einen Versuch aus einer einzelnen Quelle sofort, richten gegen Last aus Tausenden von Adressen aber wenig aus.
• Obergrenzen für die Body-Grösse helfen nicht. Apaches LimitRequestBody steht in aktuellen 2.4-Releases standardmässig auf 1’073’741’824 Byte und lag in 2.4.53 und früher bei 0, also unbegrenzt. nginx setzt client_max_body_size auf 1m. Angekündigte 100’000 Byte passieren beide Grenzen; eine strengere Grenze sorgt nur dafür, dass Sockets etwas früher wieder frei werden.

Was Sie selbst prüfen können – und wo die Prüfung täuscht

Einen Teil davon klären Sie heute ohne fremde Hilfe. Wichtig ist zu wissen, welchen Teil – und an welcher Stelle eine schnelle Prüfung in die Irre führt.

Lesen Sie die Konfiguration. Prüfen Sie, ob es ein Timeout für das Lesen des Bodys gibt, ob es eine Mindestdatenrate durchsetzt oder bloss eine Lücke zwischen zwei Lesevorgängen begrenzt, ob das Modul geladen und nicht nur vorhanden ist, und ob Ihr Proxy Bodys puffert. Das belegt, dass die Einstellung existiert – nicht, dass sie standhält, wenn Hunderte Verbindungen gleichzeitig offen sind.

Prüfen Sie die Alarmierungswege für sich. Lösen Sie einen synthetischen Alarm aus und verfolgen Sie, ob er beim richtigen Pikettdienst ankommt und ob jemand reagiert. Das prüft die Mechanik und kommt ohne Angriffsverkehr aus.

Führen Sie einen Test aus einer Quelle gegen eine Staging-Umgebung durch, mit Freigabe aus dem Change-Management und auf Infrastruktur, die Ihnen gehört. Das ist zulässig und nützlich – und genau hier liegt die Falle.

Ein Test von einer einzigen Maschine lässt die Fragen aus Zone 1 nicht nur offen. Er beantwortet mehrere davon falsch, und zwar in die beruhigende Richtung. Ihre Begrenzung der Verbindungen je Quelle erwischt eine Adresse mit zwanzig Sockets fast sofort, und mit einem einzelnen unbekannten Client wird die Reputationsprüfung ebenfalls fertig. Jede Massnahme in der vorderen Zone scheint zu greifen, also halten Sie sich für geschützt.

Dann kommt die verteilte Variante: Tausende Adressen aus Privathaushalten, jede mit ein paar Sockets. Dieselben Massnahmen verhalten sich nun anders, denn sie setzen an der Konzentration der Quellen an und nicht an dem Verhalten, das den Schaden anrichtet. Gerade die Massnahmen, denen Sie am meisten vertrauen müssen, bestehen die schnelle Prüfung zu Unrecht.

Wie Obsidio einen RUDY-Angriff testet

Ob Ihr Handler-Pool standhält, hängt davon ab, wie Proxy, Webserver, Applikationsserver und Verbindungsgrenzen bei echter Parallelität zusammenspielen, und das steht in keiner einzelnen Konfigurationsdatei. Obsidio führt RUDY als kontrollierte, autorisierte Simulation gegen Infrastruktur durch, die Ihnen gehört. Die Domain-Inhaberschaft wird über einen DNS-TXT-Eintrag geprüft, bevor überhaupt Datenverkehr fliesst; die Durchläufe werden schrittweise hochgefahren, und jeder Durchlauf lässt sich im laufenden Betrieb abbrechen. Sie legen die Sockets pro Worker, das Intervall zwischen den Byte und die angekündigte Content-Length fest und beobachten dabei Ihren Stack. Weil die Last von über 100’000 weltweit verteilten echten Geräten kommt und nicht von einer Handvoll Instanzen im Rechenzentrum, wird eine Verbindungsgrenze je Quelle so geprüft, wie ein verteilter Angriff sie prüfen würde.

Achten Sie auf die richtige Kennzahl. Bei RUDY sind das die aktiven und die maximal gehaltenen Verbindungen je Bucket, denn sie zeigen, wie viele Handler zu einem Zeitpunkt besetzt sind. Die Anfragerate zählt, wie oft ein Socket geöffnet wird; jeder Slot öffnet genau einen und behält ihn, also liegt die Rate nahe null. Ein Team, das auf die Ratenkurve schaut, hält den Test für wirkungslos, während der Handler-Pool längst leerläuft.

Klären Sie vorab, wer welche Nachweise liefert. Obsidio berichtet, wie viele Verbindungen gehalten wurden und wie die Systeme an Ihrem Netzrand reagiert haben, weil beides von aussen sichtbar ist. Ob Ihr SIEM etwas aufgezeichnet hat, ob ein Dashboard ausgeschlagen ist und ob jemand aufgeboten wurde, steht nur auf Ihren eigenen Konsolen. Lassen Sie also während des Zeitfensters jemanden mitschauen.

Stärke wird bewiesen, nicht versprochen. RUDY prüft nicht Ihre Bandbreite. Er prüft, ob irgendetwas in Ihrem Stack eine Regel dafür kennt, wie langsam ein Client liefern darf, was er bereits angekündigt hat.

Wo das in ein Testprogramm gehört

RUDY und Slowloris sind die beiden Hälften der Kategorie der langsamen Angriffe; wer nur den einen prüft, hat den anderen nicht abgedeckt. Gegen Slowloris hilft ein Timeout für das Lesen der Header, weil dort ein Header-Block offen bleibt. Gegen RUDY hilft eine Mindestdatenrate beim Lesen des Bodys, weil dort ein angekündigter Body offen bleibt. Das sind unterschiedliche Einstellungen, meist an anderer Stelle und oft in der Verantwortung anderer Teams. Ein Flood-Test auf der Anwendungsschicht prüft keine von beiden; ein Programm, das ausschliesslich HTTP-Floods fährt, lässt diese Klasse deshalb ungeprüft.

Die zehn Simulationstypen setzen an ganz unterschiedlichen Stellen an. Ein HTTP-Flood dreht fast alles bisher Beschriebene um: Die vorderen Abwehrmassnahmen haben endlich etwas, worauf sie reagieren können, der Schaden erreicht Ihren Datenbank-Verbindungspool, und das Erkennungsproblem kehrt sich um – statt völliger Stille gibt es eine Alarmflut, in der das Wesentliche untergeht. Entscheidend ist Abdeckung über alle Kategorien, nicht Volumen in einer einzigen.

Für regulierte Institute muss ein Test zudem einen Nachweis hinterlassen. Obsidio erstellt kryptografisch attestierte, manipulationssichere Berichte, die FINMA, DORA und NIS2 zugeordnet sind und in Trusted Execution Environments erzeugt werden. Ein Durchlauf hinterlässt damit einen Beleg, den Sie ablegen können, und nicht einen Screenshot, für den Sie bürgen müssen.

Um eine autorisierte RUDY-Simulation gegen Ihre eigene Infrastruktur zu planen, sehen Sie sich die Obsidio-Plattform an oder nehmen Sie Kontakt auf. Unabhängig, neutral, überprüfbar: Resilienz, die Sie belegen können.

Apache Killer gehört zu den wenigen Denial-of-Service-Angriffen, die fast ohne Datenverkehr auskommen. Eine einzige kleine GET-Anfrage mit einem Range-Header, der Dutzende überlappende Ausschnitte derselben Datei verlangt, bringt einen anfälligen Apache HTTP Server dazu, den Antwort-Body immer wieder neu im Speicher anzulegen, bis dem Prozess der Platz ausgeht. Die Schwachstelle ist alt, und sie hat einen Namen und eine Nummer: CVE-2011-3192, veröffentlicht im August 2011.

Genau dieses Alter macht sie für ein Testprogramm interessant. In jedem aktuellen Apache-Build ist die Lücke geschlossen. Die Frage lautet deshalb nicht mehr «Kann mich das treffen?», sondern «Läuft überall wirklich das, was ich glaube – auch auf der vergessenen Appliance und auf der Hersteller-Box, die seit Jahren niemand neu aufgesetzt hat?». Apache Killer beantwortet sie sauber, denn die Antwort des Servers ist bereits das Ergebnis.

Dieser Beitrag gehört zu einer Reihe über die zehn Simulationstypen, die Obsidio durchführt, ein Beitrag je Angriff. Sie setzen an ganz unterschiedlichen Stellen an, und deshalb braucht ein Testprogramm Abdeckung über alle Kategorien statt Volumen in einer einzigen. Wie sie zusammenspielen und wie Sie einen ersten Durchlauf aufbauen, steht in unserem Leitfaden dazu, wie Sie Ihren DDoS-Schutz testen.

Was ein Apache-Killer-Angriff tatsächlich macht

Den HTTP-Header Range gibt es aus gutem Grund. Er erlaubt einem Client, nur einen Teil einer Datei anzufordern statt der ganzen; so setzt ein abgebrochener Download wieder an, und so holt ein Videoplayer genau das Segment, das er als Nächstes abspielt. Eine wohlgeformte Anfrage lautet Range: bytes=0-1023 und erhält das erste Kilobyte zurück, und die Spezifikation erlaubt einem Client sogar, mehrere Bereiche auf einmal zu verlangen.

Genau diesen letzten Punkt missbraucht Apache Killer. Der Angriff sendet eine Anfrage, deren Range-Header viele überlappende Byte-Bereiche derselben Datei auflistet, etwa bytes=0-1,5-1,5-2,5-3, und so weiter. Ein anfälliger Server nimmt die Liste wörtlich und legt für jeden Bereich einen eigenen Puffer an. Weil sich die Bereiche überlappen und wiederholen, entsteht schon aus einer winzigen Datei ein Vielfaches davon im Speicher. Das Senden der Anfrage kostet den Angreifer fast nichts; das Zusammensetzen der Antwort kostet den Server ein Vielfaches der Dateigrösse an Heap- und Resident-Speicher.

Deshalb verhält sich der Angriff so anders als ein Flood. Er setzt nicht auf Bandbreite oder Anfragerate, sondern auf Speicher: Eine Handvoll solcher Anfragen parallel treibt einen ungepatchten httpd-Prozess in die Erschöpfung, während die Verkehrskurve kaum ausschlägt.

Anschaulich gesagt: Sie verlangen von einer Bibliothekarin eine einzige Seite, aber in fünfzig Stücken, die sich fast alle überlappen. Um Ihre Bestellung zu erfüllen, kopiert sie die Seite fünfzig Mal. Geben Sie ein paar solche Bestellungen gleichzeitig auf, geht ihr das Papier aus – und gefragt haben Sie immer nur nach einer einzigen Seite.

Welche Ihrer Schutzmassnahmen das hätte abfangen sollen

Es lohnt sich, die ganze Kette abzugehen, die eine Anfrage durchläuft, denn die Antwort fällt hier anders aus als sonst in dieser Reihe. Drei Bereiche zählen: was vorgelagert ist, was die durchgelassene Last auffängt, und ob Ihnen überhaupt jemand meldet, dass etwas passiert ist.

Das Bild fällt hier weniger düster aus als bei den meisten Angriffen dieser Reihe, und das gehört nüchtern festgehalten: Ein gepatchter Server und eine passende Regel am Netzrand stoppen den Angriff wirklich. Das Risiko besteht nicht darin, dass er unaufhaltsam wäre, sondern darin, dass Sie sich überall gepatcht glauben, ohne es je belegt zu haben.

Die eine Anfrage, die zeigt, ob Sie gepatcht sind

Apache Killer lässt sich ungewöhnlich sauber diagnostizieren. Sie müssen nichts überlasten, um Ihren Stand zu kennen: Senden Sie die präparierte Anfrage und lesen Sie die Antwort, denn die Antwortkategorie entspricht direkt Ihrem Zustand.

Ein gepatchter Server spielt nicht mit. Erhält er eine Liste überlappender Bereiche, deren Aufwand grösser wäre als die Datei selbst, ignoriert er sie und liefert die vollständige Datei mit einer normalen 200-Antwort, oder er weist die Anfrage direkt ab. Ein ungepatchter Server tut das Gefährliche: Er antwortet mit einer Multipart-Range-Antwort, die je angefordertem Bereich einen Teil enthält – die Vervielfachung in Aktion. Eine Ablehnung durch einen vorgelagerten Proxy oder einen gehärteten Stack, der den übergrossen Header abweist, bevor er den Ursprungsserver erreicht, ist ein dritter und genauso aussagekräftiger Ausgang. Jeder davon ist eine andere, klar lesbare Antwort auf dieselbe Frage.

In der Obsidio-Simulation steuern zwei Parameter das Verhalten. rangeCount ist der Regler für die Vervielfachung: Er legt fest, wie viele überlappende Byte-Bereiche jede Anfrage enthält, und ein anfälliger Server legt je Eintrag eine Kopie der Antwort an. Der Standardwert liegt bewusst milde bei 10 – genug, um den Effekt zu zeigen, ohne etwas zu belasten. Erhöhen Sie ihn in Schritten, statt gleich auf das Maximum zu gehen, und beobachten Sie, welche Antwortkategorie jeweils zurückkommt. Ein dreistelliger Wert setzt einen ungepatchten Server stark unter Druck; einen sehr hohen Wert weist ein moderner Stack womöglich schlicht ab, was für sich genommen ebenfalls ein nützliches Signal ist. Der zweite Parameter, parallelRequestsPerWorker, steht standardmässig auf 20 und bestimmt, wie viele Anfragen gleichzeitig laufen; er vervielfacht die Speicherkopien, die gleichzeitig unterwegs sind, ohne die Vervielfachung je Anfrage zu verändern.

Ein Detail ist für das Lesen der Ergebnisse wichtig: Der Range-Header wird aus rangeCount berechnet und jeder Anfrage zwingend mitgegeben. Überschreiben lässt er sich nicht, denn er ist der Angriff. Eigene Header kommen zusätzlich hinzu.

Wie Sie sich gegen Apache Killer schützen

Die Verteidigung beginnt bei der Versionsnummer und arbeitet sich von dort nach aussen. Jede Schicht lässt sich überprüfen, und das ist der nützliche Teil.

• Zuerst und immer: der Patch-Stand. Die Korrektur für CVE-2011-3192 erschien am 30. August 2011 mit Apache HTTP Server 2.2.20. Der Changelog-Eintrag ist präzise: Der Server verarbeitet Byte-Range-Anfragen nun mit weniger Speicher, und wenn die Summe aller Bereiche einer Anfrage grösser ist als die Originaldatei, ignoriert er die Bereiche und liefert die vollständige Datei («if the sum of all ranges in a request is larger than the original file, ignore the ranges and send the complete file»). Ein Nachtrag in 2.2.21 korrigierte eine Regression, die die erste Korrektur eingeführt hatte. Jede aktuelle Apache-Version enthält all das längst; die Arbeit besteht also darin, zu bestätigen, dass wirklich jeder Server aktuell ist, Appliances und vom Hersteller gelieferte Instanzen eingeschlossen.
• Grenzwerte für die Bereichsverarbeitung. Aktuelle Apache-Versionen bieten drei Direktiven, die masslose Bereichslisten direkt begrenzen. MaxRanges beschränkt die Zahl der Bereiche, ab der der Server stattdessen die vollständige Ressource ausliefert, Standardwert 200. MaxRangeOverlaps begrenzt überlappende Bereiche, MaxRangeReversals begrenzt Rückwärtssprünge in der Reihenfolge, beide mit Standardwert 20. Alle drei kamen mit der Entwicklungslinie 2.3.15 und stecken in aktuellen stabilen Builds. Überschreitet eine Anfrage ein Limit, sendet der Server die ganze Datei, statt die Bereiche zu bedienen – damit entfällt die Vervielfachung.
• Eine passend konfigurierte WAF-Regel. Weil das Muster der überlappenden Bereiche eine feste Signatur ist, kann eine Regel, die einen missbräuchlichen Range-Header erkennt, die Anfrage blockieren, bevor sie den Ursprungsserver erreicht. Genau das macht Apache Killer zur Ausnahme dieser Reihe. Auch auf gepatchten Servern lohnt sie sich als zweite Linie, sie ist aber nur so gut, wie sie aktuell ist.
• Zusammenfassen am Proxy oder CDN. Die HTTP-Spezifikation hält selbst fest, dass ein Server Bereichsanfragen ignorieren, zusammenfassen oder ablehnen darf, wenn sie mehr als zwei überlappende Bereiche oder viele kleine Bereiche in falscher Reihenfolge verlangen, weil das auf einen fehlerhaften Client oder einen absichtlichen Denial-of-Service-Versuch hindeutet. Ein Proxy oder CDN, der das für Sie übernimmt, schirmt den Ursprungsserver ab, sofern dieser nicht direkt erreichbar ist.

Jede dieser Massnahmen ist irgendwo eine Einstellung oder eine Versionsangabe. Das heisst: Jede kann veraltet sein, auf einem Host fehlen oder durch eine Änderung überschrieben worden sein, die niemand nachgeprüft hat.

Was Sie selbst prüfen können und was dabei offen bleibt

Apache Killer ist der eine Angriff dieser Reihe, bei dem eine Selbstprüfung wirklich viel bringt. Zwei Prüfungen können Sie heute durchführen:

Version und Konfiguration lesen. Stellen Sie auf jedem Host fest, welcher Apache-Build läuft, und prüfen Sie, ob die Direktiven zur Bereichsverarbeitung gesetzt sind. Für die Maschine, die Sie angesehen haben, wissen Sie damit: Die Einstellung existiert, und die Version ist aktuell.

Eine Anfrage an das Staging-System senden und die Antwort lesen, mit Freigabe durch das Change-Management und nur auf Infrastruktur, die Ihnen gehört. Der Befund steckt in der Antwort selbst und nicht darin, ob der Server umgefallen ist; den tatsächlichen Stand dieses einen Endpunkts kennen Sie also sofort.

Die Falle liegt nicht darin, dass die Selbstprüfung Sie über den geprüften Endpunkt täuscht, sondern in dem, was eine einzelne Quelle nicht sehen kann. Eine Anfrage von einer einzelnen Maschine sagt nichts über die Endpunkte, an die Sie nicht gedacht haben, und das Risiko tragen genau die Vergessenen: die alte Appliance, die nie neu aufgesetzte Hersteller-Box. Sie sagt auch nichts darüber, ob während eines längeren Durchlaufs jemand den steigenden Speicherverbrauch bemerken würde. Eine einzelne Anfrage beantwortet die Frage nach der Version. Sie beantwortet weder die Frage nach der Abdeckung noch die nach der Erkennung, und das sind die beiden, die ein ernsthaftes Programm schliessen muss.

Wie Obsidio das testet

Obsidio führt Apache Killer als kontrollierte, autorisierte Simulation gegen Infrastruktur durch, die Ihnen gehört. Die Domain-Inhaberschaft wird über einen DNS-TXT-Eintrag geprüft, bevor überhaupt Datenverkehr fliesst. Die Durchläufe steigern sich stufenweise, beginnend beim milden Standardwert für die Bereichszahl, und jeder Durchlauf lässt sich im laufenden Betrieb abbrechen. Sie legen Bereichszahl und Parallelität fest und beobachten, wie jeder Endpunkt antwortet, während der Druck steigt. Weil die Last von über 100’000 weltweit verteilten echten Geräten kommt und nicht von einer Handvoll Instanzen im Rechenzentrum, wird Ihre Umgebung so abgeklopft, wie es ein echter Angreifer täte, und nicht aus einer einzelnen vorhersehbaren Quelle, die Ihre Filter mühelos erwischen würden.

Zu beobachten ist die Antwortkategorie, nicht die Kurve der Anfragerate; die bleibt niedrig, auch während der Angriff wirkt. Entscheidend ist die Mischung der Antworten: Eine saubere Antwort mit der vollständigen Datei oder eine Ablehnung heisst, dieser Endpunkt hält. Eine Multipart-Range-Antwort heisst, er vervielfacht und ist angreifbar. Wie sich diese Mischung verschiebt, während die Bereichszahl steigt, ist der ganze Zweck des Durchlaufs.

Was ein Test messen kann, hat eine klare Grenze. Obsidio misst von aussen die Antwortkategorie und das Verhalten am Netzrand, weil beides von der Client-Seite der Verbindung aus sichtbar ist. Ob der Resident-Speicher auf dem Host tatsächlich gestiegen ist, ob Ihr SIEM die Serie von Range-Anfragen aufgezeichnet hat und ob jemand aufgeboten wurde, als ein Prozess neu startete: Diese Antworten stehen nur auf Ihren eigenen Konsolen. Lassen Sie sie während des Zeitfensters von jemandem beobachten, damit sich das innere und das äussere Bild zu einem Befund zusammenfügen.

Stärke wird bewiesen, nicht versprochen. Apache Killer prüft nicht Ihre Bandbreite. Er prüft, ob die Version, die Sie zu betreiben glauben, auch die Version ist, die die Anfrage beantwortet.

Wo das in ein Testprogramm passt

Apache Killer gehört zur Gruppe der Angriffe auf die Anwendungsschicht, zusammen mit HTTP-Flood, GoldenEye und Browser-Flood, ist dort aber der Sonderfall. Die Floods wirken über Volumen und treffen die Kapazität der Anfrageverarbeitung. Apache Killer wirkt über einen bestimmten Implementierungsfehler und trifft den Speicher, praktisch ohne Volumen. Ein Programm, das nur Floods fährt, misst, wie viel Verkehr Ihr Stack aushält, stellt aber nie die Frage nach Version und Abdeckung, die dieser Angriff beantwortet. Diese ganze Klasse von Angriffsfläche bleibt damit ungeprüft.

Für regulierte Institute muss der Test zudem eine Spur hinterlassen. Obsidio erstellt kryptografisch attestierte, manipulationssichere Berichte, die FINMA, DORA und NIS2 zugeordnet sind und in Trusted Execution Environments erzeugt werden. Das Ergebnis eines Durchlaufs ist damit ein Beleg, den Sie ablegen können, und kein Screenshot, für den Sie sich verbürgen müssen. Bei einem Angriff, dessen ganzer Befund darin besteht, welcher Ihrer Server wie geantwortet hat, ist ein überprüfbarer Nachweis genau dieser Antworten viel wert.

Um eine autorisierte Apache-Killer-Simulation gegen Ihre eigene Infrastruktur aufzusetzen, sehen Sie sich die Obsidio-Plattform an oder sprechen Sie mit dem Team. Unabhängig, neutral, überprüfbar: Resilienz, die Sie belegen können.

Die meisten Abwehrmechanismen gegen Layer-7-DDoS-Angriffe suchen nach etwas, das ein echter Browser nie tun würde. Ein fehlender Header. Ein TLS-Fingerprint, den kein ausgelieferter Chrome-Build erzeugt. Ein Client, der das HTML anfordert und das Stylesheet danach nie abholt. Wer diese Lücke findet, hat einen Ansatzpunkt.

Ein Browser-Flood schliesst diese Lücke. Er steuert einen echten Chromium-Tab: Der lädt Ihre Seite, parst das HTML, holt jedes Stylesheet, jedes Skript und jedes Bild, das die Seite anfordert, führt Ihr JavaScript aus, löst Ihre Analytics aus und scrollt anschliessend. Nichts daran ist gefälscht, also gibt es auch keine Lücke zu finden. Hier hat die Frage «Ist das ein echter Nutzer?» keine saubere Antwort mehr – und hier muss Ihre Bot-Mitigation beweisen, was sie leistet.

Dieser Beitrag gehört zu einer Serie über die zehn Simulationstypen, die Obsidio durchführt. Sie setzen an ganz unterschiedlichen Stellen an – deshalb braucht ein Testprogramm Abdeckung über alle Kategorien hinweg und nicht Volumen in einer einzigen. Wie die Typen zusammengehören, erklärt unser Leitfaden DDoS-Schutz testen.

Was ein Browser-Flood tatsächlich macht

Die Simulation lädt die Ziel-URL immer wieder mit voller Browser-Semantik. Nicht nur das Hauptdokument, sondern den gesamten Baum an Sub-Ressourcen: HTML, CSS, JavaScript, Bilder und jeden XHR- oder Fetch-Aufruf, den die Seite absetzt, sobald ihre Skripte laufen. Auf Workern mit WebView-Laufzeitumgebung steuert Obsidio über puppeteer-core.connect() einen echten Chromium-Tab und überlässt es der Seite, jede Anfrage zu stellen, die ein Browser von sich aus stellen würde.

Genau darin liegt der Unterschied zum HTTP-Flood: Dort ist eine Anfrage etwas, das das Werkzeug zusammengesetzt und abgeschickt hat. Hier ist eine Anfrage etwas, das der Browser von sich aus angefordert hat. Nach jedem Seitenaufruf führt der Worker eine gewichtete Aktion auf der Seite aus: in der Hälfte der Fälle scrollen, in drei von zehn Fällen klicken, sonst warten. Die Session in Ihren Analytics hat einen Page View, eine Verweildauer und eine Interaktion, weil alle drei tatsächlich stattgefunden haben.

Stellen Sie sich statt Bots, die auf einen einzelnen Endpunkt einhämmern, einen Raum voller unauffälliger Menschen vor, die Ihre Startseite immer wieder öffnen, scrollen, Links anklicken und Ihre Skripte ausführen.

Welche Ihrer Schutzmassnahmen das hätte auffangen müssen

Es lohnt sich, die ganze Kette durchzugehen, denn die Antwort liegt hier selten bei der Massnahme, an die man zuerst denkt.

Bei einem langsamen Angriff bleibt diese dritte Zone stumm. Hier schlägt dagegen alles an – die Frage ist nur, ob es innerhalb der ersten Stunde jemand richtig deutet.

Zwei Ausführungspfade, und warum sie nicht austauschbar sind

Ein Browser-Flood läuft auf einem von zwei Wegen, und zu wissen, welcher Ihren Bericht erzeugt hat, ist wichtiger als jeder Parameter im Formular.

• Der echte Browser-Pfad. Steht die WebView-Laufzeitumgebung zur Verfügung, läuft genau ein Chromium-Tab pro Worker, gesteuert über das DevTools-Protokoll. Jede gemeldete Anfrage ist eine Sub-Ressource, die der Browser geladen hat. Die Einstellungen für parallele Schleifen und Keep-Alive bleiben hier wirkungslos, weil der Browser seine Verbindungen selbst verwaltet.
• Der HTTP-Fallback. Fehlt diese Laufzeitumgebung, fällt die Simulation auf einen parallelen Pool einfacher GET-Anfragen gegen die Haupt-URL zurück, standardmässig zwanzig Schleifen pro Worker, mit Verbindungswiederverwendung. Keine Sub-Ressourcen, kein JavaScript, keine Aktionen auf der Seite. Eine vernünftige Rückfallebene – aber ein anderer Test: Er kann Ihnen nicht sagen, wie Ihre Bot-Mitigation echten Browser-Verkehr bewertet.

Jeder Worker hält eine laufende Chromium-Instanz, und Browser verbrauchen viel Arbeitsspeicher. Ein Browser-Flood setzt deshalb auf Realitätsnähe statt auf reines Volumen – gegenüber moderner Abwehr am Netzrand ist das der bessere Kompromiss.

Die Abgrenzung zu den benachbarten Typen ist sauber. Ein HTTP-Flood schickt Methode, URL und Body genau so, wie sie konfiguriert wurden, und zielt auf Ihren Verarbeitungspfad für Anfragen. GoldenEye erzwingt den Weg zum Ursprungsserver, indem er zufällige Cache-Buster-Parameter anhängt, damit der Cache am Netzrand nicht antworten kann. Ein Browser-Flood braucht keinen dieser Kniffe: Er fordert genau die Ressourcen an, die die Seite wirklich braucht, der Cache beantwortet davon, was er kann, und der Rest kommt am Ursprungsserver an – wie bei einem echten Besucher.

Wie man einen Layer-7-DDoS-Angriff mit echten Browsern abwehrt

Misstrauen Sie jedem, der hier eine einzige Antwort anbietet, uns eingeschlossen. Diesen Verkehr von echten Nutzern zu unterscheiden ist die ganze Schwierigkeit; jede Massnahme weiter unten bleibt deshalb unvollständig. Was folgt, ist das, was die Hersteller dokumentieren – einschliesslich der Grenzen, die sie selbst einräumen.

• Bot-Management: wissen, was es leistet. Cloudflares Bot-Score entsteht überwiegend aus Machine Learning über Header, Session-Merkmale und Browser-Signale, ergänzt um Heuristiken für bekannte Fingerprints. Er ist hier Ihre stärkste Massnahme – und liefert eine Wahrscheinlichkeit, kein Urteil. Cloudflare benennt die Grenzen offen: Die erste Anfrage eines neuen Clients enthält in der Regel keine Daten aus den JavaScript Detections, und die JavaScript Detections garantieren keinen bestimmten Bot-Score.
• Challenges: wissen, was sie prüfen. Eine Managed Challenge wählt ihren Typ anhand der Signale, die der Browser mitbringt. Eine nicht-interaktive Challenge löst der Browser, indem er das eingeschleuste JavaScript verarbeitet, meist in unter fünf Sekunden und ohne menschliches Zutun. Sie filtert damit Clients aus, die kein JavaScript ausführen können. Einen Browser unter Software-Steuerung von einem Browser unter menschlicher Bedienung unterscheidet sie nicht. Interaktive Challenges brauchen einen Menschen – Cloudflare rät davon ab, sie zum Standard zu machen.
• Wissen, was Ihr Schwellenwert für den Score bewirkt. reCAPTCHA v3 liefert für jede Anfrage einen Score, ohne den Nutzer zu behelligen; Google empfiehlt, im Hintergrund zu reagieren, statt Verkehr zu blockieren. Ein vernünftiger Rat – der die Entscheidung zu Ihnen verschiebt: Irgendjemand muss aufgeschrieben haben, was jedes Score-Band auf jeder Route auslöst.
• Rate Limiting an etwas Besserem festmachen als an einer IP-Adresse. Die Rate-Limiting-Regeln von Cloudflare können statt der Absenderadresse einen Cookie-Wert, einen Header-Wert oder einen JA3- oder JA4-TLS-Fingerprint zählen. Das ist stärker – mit dem Vorbehalt, dass ein echtes Chromium einen echten Chromium-Fingerprint mitbringt.
• So cachen, dass Ihr Ursprungsserver nur beantwortet, was nur er beantworten kann. Die standardmässig von Cloudflare gecachten Typen decken CSS, JS und die gängigen Bildformate ab; HTML und JSON sind ausgenommen. Der Grossteil eines Browser-Floods erreicht Sie also nie – die Dokumentrate und die API-Rate schon. Lässt sich Ihr HTML gefahrlos am Netzrand cachen, verändert das diesen Angriff grundlegend. Wenn nicht, dimensionieren Sie Ihren Ursprungsserver für die Dokumentrate; und Sie müssen diese Zahl vorher kennen.

Eines behaupten wir nicht: In keiner Herstellerdokumentation, die wir gefunden haben, steht, dass irgendeine einzelne Massnahme einen von Software gesteuerten echten Browser zuverlässig von einem von Menschen bedienten unterscheidet. Behauptet ein Hersteller das von seiner, ist das eine Aussage, die man prüfen sollte, und keine, die man abheftet.

Was Sie selbst prüfen können, und wo das Ergebnis täuscht

Lesen Sie die Konfiguration. Welcher Bot-Management-Modus aktiv ist, was jedes Score-Band auslöst, ob Challenges die relevanten Pfade abdecken und was Ihre Cache-Regeln mit HTML machen. Das sagt Ihnen, was die Einstellungen behaupten – nicht, wie sie echten Browser-Verkehr bewerten.

Proben Sie die Triage, nicht die Alarmierung. Das Problem ist hier die Deutung, nicht das Ausbleiben von Alarmen. Zeigen Sie Ihrem Pikettdienst eine Grafik mit vierzigfachem Verkehr bei normalen Fehlerraten und fragen Sie ihn, was er tun würde. Das kostet eine Stunde und keine einzige Anfrage.

Fahren Sie einen Lasttest gegen die Staging-Umgebung, mit Freigabe aus dem Change Management, auf Infrastruktur, die Ihnen gehört. Legitim und nützlich – und von allen Angriffstypen dieser Serie ist dies der, bei dem eine billige Prüfung am weitesten in die Irre führt.

Ein synthetischer Lastgenerator schickt die Anfragen, die Sie ihm auftragen: eine Liste von URLs, in der Rate Ihrer Wahl, mit einem eingetippten User-Agent-String. Er parst Ihr HTML nicht, um herauszufinden, was die Seite überhaupt braucht. Er führt Ihr JavaScript nicht aus, setzt also nie die XHR-Aufrufe ab, von denen Ihr Dashboard abhängt, und er erzeugt keines der Browser-Signale, auf die jede der oben genannten Erkennungen angewiesen ist.

Das Ergebnis ist deshalb in zwei Richtungen zugleich falsch. Bei der Erkennung fällt es zu pessimistisch aus: Ihr synthetischer Client ist genau das, wofür Bot-Management existiert, er wird erkannt, und Sie schliessen daraus, gegen etwas geschützt zu sein, das Sie nie geschickt haben. Bei der Kapazität fällt es zu optimistisch aus: Sie haben Ihren Ursprungsserver an Anfragen bemessen, die Ihren Rendering-Pfad nie berührt haben, während der echte Angriff sechzig Anfragen stellt, wo Sie eine geprüft haben – und die teure sechzigste ist eine Datenbankabfrage.

Zwei Fehler in entgegengesetzte Richtungen: Kein anderer Test dieser Serie täuscht ein Bestehen so gründlich vor. Das Ergebnis gilt als bestanden, beide Hälften der Begründung sind falsch, und nichts im Bericht weist darauf hin.

Wie Obsidio einen Browser-Flood testet

Die Autorisierung kommt vor dem Verkehr. Die Domain-Inhaberschaft wird per DNS-TXT-Eintrag verifiziert, bevor auch nur eine einzige Anfrage verschickt wird; Durchläufe steigern die Last schrittweise, statt bei Volllast zu beginnen, und jeder Durchlauf lässt sich im laufenden Betrieb abbrechen.

Die Last kommt von über 100’000 weltweit verteilten echten Geräten – echte Hardware in echten Endkundennetzen, rechtmässig und mit Zustimmung der Nutzer eingebunden. Realitätsnähe ist kein Trick, um Ihre Massnahmen zu umgehen; sie ist der einzige Weg herauszufinden, was diese Massnahmen tun, wenn der Verkehr echt ist. Eine Abwehr, die nur gegen offensichtlich synthetischen Verkehr validiert wurde, ist nicht validiert.

Worauf Sie während des Zeitfensters achten sollten:

• Trennen Sie Ihre Dokumentrate von der Gesamtanfragerate. Gecachte Sub-Ressourcen dominieren die Summe. Die Zahl, die einen Ausfall vorhersagt, sind ungecachte Dokumentanfragen pro Sekunde am Ursprungsserver.
• Beobachten Sie die Datenbank, nicht die Web-Schicht. Die Grenze liegt meist bei der Sättigung des Connection-Pools und bei der Latenz der Abfragen. Behalten Sie Cache-Trefferquote und Skalierungskosten daneben im Blick.
• Halten Sie fest, wie das Bot-Management entschieden hat. Nicht nur, ob Anfragen blockiert wurden, sondern auch die Verteilung der Scores und die ergriffene Massnahme.

Bleiben Sie realistisch, was ein Bericht belegen kann. Obsidio misst, wie Ihr Netzrand reagiert hat und wie sich die Verbindungszahlen verhalten haben, denn das ist von ausserhalb Ihres Perimeters sichtbar. Ob Ihr SIEM etwas korreliert hat, ob ein Alarm den richtigen Pikettdienst erreicht hat und ob die Person am anderen Ende den richtigen Schluss gezogen hat: Diese Antworten stehen nur in Ihren eigenen Konsolen. Lassen Sie während des Durchlaufs jemanden davorsitzen, denn diese Hälfte lässt sich später nicht rekonstruieren.

Stärke wird bewiesen, nicht versprochen. Ein Browser-Flood fragt nicht, ob Sie Verkehr absorbieren können. Er fragt, ob Sie den Unterschied erkennen – und ob es überhaupt jemandem auffiele, wenn nicht.

Wo der Browser-Flood in ein Testprogramm gehört

Der Browser-Flood gehört mit HTTP-Flood, GoldenEye und Apache Killer zur Kategorie der Floods auf der Anwendungsschicht, und zwar an deren realistischem Ende. Am nächsten verwandt ist ihm ein Typ aus einer anderen Kategorie: Puppeteer Script, die andere Simulation, die bis in Ihre Datenbank reicht, führt ein von Ihnen geschriebenes Skript in einem echten Browser aus und belastet damit einen einzelnen Ablauf, etwa einen Login. Ein Browser-Flood fragt, was passiert, wenn viele echte Browser Ihre Seite laden. Puppeteer Script stellt dieselbe Frage für einen einzelnen Ablauf.

Keiner der beiden ersetzt die übrigen. Ein HTTP-Flood konzentriert die Last auf Ihren Verarbeitungspfad für Anfragen, ohne den Overhead eines Browsers. Slowloris und RUDY erreichen Ihre Applikation gar nicht erst. Entscheidend ist die Abdeckung über alle zehn Simulationstypen hinweg, nicht das Volumen in einem davon.

Für regulierte Institute muss der Test ausserdem einen Nachweis hinterlassen. Obsidio erstellt kryptografisch attestierte Berichte, bei denen jede nachträgliche Änderung erkennbar ist, zugeordnet zu FINMA, DORA und NIS2 und erzeugt in Trusted Execution Environments – am Ende steht ein Beleg, den Sie ablegen können, und kein Screenshot, für den Sie bürgen müssen.

Um den Prüfumfang für eine autorisierte Browser-Flood-Simulation gegen Ihre eigene Infrastruktur festzulegen, sehen Sie sich die Obsidio-Plattform an oder nehmen Sie Kontakt auf. Unabhängig, neutral, überprüfbar: Resilienz, die Sie belegen können.