Der Mirai-Angriff auf OVH 2016 machte DDoS-Scrubbing-Kapazität zum Prüfstein der Rechenschaft

Zusammenfassung

OVHcloud hat einen Angriff aus der ersten großen Mirai-Welle im September 2016 mit mehr als einem Terabit pro Sekunde beschrieben. Dieser Spitzenwert stammt vom betroffenen Betreiber; er ist keine unabhängige paketgenaue Prüfung sämtlicher Ziele, Geräte oder Kundenfolgen. [1][2]
Die auf der USENIX Security vorgestellte unabhängige Forschung rekonstruierte Wachstum und Angriffsgeschichte von Mirai aus mehreren Messperspektiven. Danach begannen Angriffe auf OVH-Infrastruktur am 18. September 2016. Die Studie beschreibt ein Botnetz mit zeitweise ungefähr 600.000 infizierten Geräten und analysiert mehr als 15.000 Angriffe im gesamten Beobachtungszeitraum. [3][4]
Der Vorfall bei OVH ist von den Angriffen auf KrebsOnSecurity und Dyn zu trennen. Gemeinsame Schadsoftware und eine zusammenhängende Botnetzgeschichte machen unterschiedliche Ziele, Zeitpunkte, Verkehrswege und Dienstauswirkungen nicht zu einem einzigen Ereignis.
Mirai konnte Verkehr direkt von kompromittierten Geräten mit regulär routbaren Quelladressen senden. Das unterscheidet den Kernmechanismus von Reflexions- und Verstärkungsangriffen, die gefälschte Absenderadressen voraussetzen. Quelladressvalidierung bleibt wichtig, doch BCP 38 allein hätte eine direkte Mirai-Flut nicht gestoppt. [15][16][19][20]
Belastbare DDoS-Kapazität ist keine einzelne Bandbreitenzahl. Sie umfasst die Messung von Bit- und Paketraten, die Belastbarkeit von Links und Weiterleitungshardware, ausreichende Scrubbing-Ressourcen, stabile Steuerungssysteme und einen funktionsfähigen Pfad für legitimen Verkehr.
Verantwortung verteilt sich auf mehrere kontrollierende Akteure: Gerätehersteller beeinflussen Zugangsschutz und Aktualisierbarkeit; Eigentümer und Zugangsnetze können auffälligen ausgehenden Verkehr erkennen; Transit- und Hosting-Anbieter steuern Filterung, Kapazität, Verkehrsführung und Wiederherstellung; Strafverfolgungsbehörden bearbeiten die Verantwortung der Botnetzbetreiber. [5][9][10][11][12]
Öffentlich nicht belegt sind OVHs vollständige Scrubbing-Topologie, konkrete Aktivierungsschwellen, betroffene Kundenzahlen, vertragliche Verpflichtungen, Kundenschäden und die Reaktion jedes Herkunftsnetzes. Diese Grenzen dürfen nicht durch Vermutungen ersetzt werden.
Der entscheidende Prüfmaßstab ist der laufende Dienst: Konnte die Abwehr den tatsächlichen Paketmix bewältigen, legitimen Verkehr weiterleiten, Nebenwirkungen begrenzen und einen Wiederherstellungsnachweis erzeugen, den Kunden und beteiligte Netzbetreiber nachvollziehen konnten?

Eine Warnzahl, kein vollständiger Kapazitätsnachweis

Im September 2016 meldete OVH während der ersten großen Mirai-Welle einen Angriff von mehr als einem Terabit pro Sekunde. OVHcloud ordnet das Ereignis heute in seine Darstellung großer DDoS-Angriffe ein; ein späterer technischer Beitrag des Unternehmens beschreibt Mirai als erstes Botnetz, das mehr als ein Terabit pro Sekunde erzeugt habe. [1][2] Der Wert markierte einen Wendepunkt, weil er zeigte, welche Verkehrsmenge eine große Zahl kompromittierter Alltagsgeräte gegen Hosting-Infrastruktur richten konnte. Zugleich ist diese Zahl enger auszulegen, als ihre häufige Wiederholung vermuten lässt.

Ein vom angegriffenen Betreiber gemessener Spitzenwert beantwortet nicht automatisch, wo die Messung erfolgte. Er sagt ohne zusätzliche Angaben weder, wie lange die Spitze anhielt, noch, welche Schnittstellen sie sahen, welche Paketgrößen vorherrschten oder wie viele einzelne Ziele betroffen waren. Ebenso bleibt offen, ob der Wert vor oder nach einer Filterstufe, an einem Standort oder über mehrere Standorte hinweg, am Netzrand oder weiter im Kernnetz erfasst wurde. Die belastbare Formulierung lautet deshalb: OVH meldete einen Spitzenwert von mehr als einem Terabit pro Sekunde.

Daraus folgt noch keine unabhängige Bestätigung jedes Pakets und keine genaue Bilanz der Kundenfolgen.

Diese Einschränkung ist keine sprachliche Spitzfindigkeit. Bei einem DDoS-Angriff hängt die Wirkung davon ab, welche Ressource zuerst an ihre Grenze gelangt. Eine Flut kann eine physische Verbindung auslasten, die Paketverarbeitungsrate eines Routers überschreiten, eine Filterplattform überfordern, zustandsbehaftete Tabellen erschöpfen, die Steuerungsebene destabilisieren oder nach erfolgreicher Passage durch das Netz die Anwendung selbst überlasten. Derselbe Durchsatz in Bit pro Sekunde kann je nach Paketgröße eine sehr unterschiedliche Zahl von Weiterleitungs-, Klassifizierungs- und Filterentscheidungen verlangen.

Bitrate, Paketrate, Leitungskapazität, Routerdurchsatz und Scrubbing-Leistung sind daher getrennte Größen. Auch eine ausreichend dimensionierte Filterplattform garantiert noch keine Dienstkontinuität. Der Verkehr muss die Plattform erreichen können, die Steuerung der Umleitung muss stabil bleiben, und der bereinigte Datenstrom benötigt anschließend einen ausreichend großen Rückweg zum Hosting-Netz. Eine Schwäche an einem dieser Übergänge kann die Wirkung der übrigen Kapazität zunichtemachen.

OVHs spätere technische Darstellung von Paketratenangriffen und ihrer Belastung für Kernrouter hilft, diese Mehrdimensionalität zu verstehen. [2] Sie darf jedoch nicht rückwirkend als vollständige Beschreibung des internen Netzes im September 2016 gelesen werden. Die veröffentlichten Unterlagen enthalten keine lückenlose Liste damaliger Schnittstellenwerte, Linecard-Grenzen, Filterregeln oder Reserven. Sie stützen die allgemeinere Schlussfolgerung, dass ein glaubwürdiger Betriebsnachweis sowohl Bit- als auch Paketraten enthalten muss.

Eine Kapazitätsaussage sollte deshalb immer an einen Messort und einen Betriebszustand gebunden sein. Entscheidend ist, an welcher Grenze die Last gemessen wurde, ob der Höchstwert nur kurz oder über einen relevanten Zeitraum bestand und welche Abwehrmaßnahmen zu diesem Zeitpunkt aktiv waren. Hinzukommen muss die Frage, wie viel legitimer Verkehr währenddessen sein Ziel erreichte. Wenn der Datenstrom auf einen anderen Pfad verlagert wurde, muss erkennbar sein, welche Ressource anschließend zum Engpass wurde.

Für Unternehmensleitungen und Kunden war die Terabit-Meldung dennoch ein wichtiges Warnsignal. Sie zeigte, dass frühere Annahmen über die maximale Angriffsstärke rasch veralten konnten. Daraus lässt sich aber weder ableiten, OVH sei vollständig vorbereitet gewesen, noch, das Unternehmen sei unvorbereitet oder rechtlich verantwortlich gewesen. Solche Bewertungen benötigen Betriebsdaten über Messung, Aktivierung, Filterwirkung, Nebenfolgen und Wiederherstellung. Die große Zahl eröffnet die Prüfung; sie ersetzt deren Ergebnis nicht.

Unabhängige Forschung belegt das Botnetz, nicht OVHs private Folgen

Die belastbarste unabhängige technische Rekonstruktion stammt aus der auf der USENIX Security 2017 vorgestellten Untersuchung zu Mirai. Die Forschenden kombinierten mehrere Datenquellen und Messperspektiven, um Wachstum, Infrastruktur und Angriffstätigkeit des Botnetzes nachzuzeichnen. Ihren Ergebnissen zufolge begann Mirai am 18. September 2016 mit Angriffen gegen OVH-Infrastruktur. Die Studie beschreibt eine Spitzenpopulation von ungefähr 600.000 infizierten Geräten und analysiert mehr als 15.000 Angriffe innerhalb des gesamten Beobachtungszeitraums. [3][4]

Der besondere Wert dieser Forschung liegt darin, dass sie über die Darstellung eines einzelnen angegriffenen Unternehmens hinausgeht. Sie verbindet Scanning, Infektion, Steuerungsinfrastruktur und Angriffe zu einer gemessenen Entwicklung. Dadurch wird nachvollziehbar, wie unzureichend geschützte internetfähige Geräte weltweit rekrutiert und anschließend als verteilte Verkehrsquellen eingesetzt werden konnten. Die Studie bietet zudem eine Grundlage, Mirais direkten Botnetzverkehr von späteren Erzählungen abzugrenzen, in denen sehr unterschiedliche DDoS-Mechanismen pauschal zusammengefasst werden.

Die Untersuchung liefert jedoch keine vollständige Liste der bei OVH betroffenen Kunden. Sie legt weder alle internen Verkehrswege noch die privaten Aktivierungsschwellen, Paketproben, Filterentscheidungen oder vertraglichen Zusagen des Betreibers offen. Sie kann ohne weitere Quellen nicht beantworten, welcher einzelne Kunde wann unerreichbar war, wie lange eine mögliche Beeinträchtigung dauerte oder welcher wirtschaftliche Schaden entstand. Ebenso wenig bedeutet eine Botnetzpopulation von rund 600.000 Geräten, dass jedes dieser Geräte an jedem Angriff teilnahm.

Die Grenze zwischen einer Botnetzrekonstruktion und einem betriebsinternen Ereignisbericht ist wesentlich. Die Forschenden konnten wichtige Teile des Mirai-Ökosystems beobachten. OVH verfügte über andere Belege: interne Router- und Schnittstellenwerte, Kundentelemetrie, Filterzustände, Entscheidungen der Einsatzleitung und den Zustand der eigenen Dienste. Gerätehalter und Herkunftsnetze besaßen wiederum Informationen über Anschlüsse und kompromittierte Systeme. Keine einzelne Quelle erfasst die gesamte Kontroll- und Beweiskette.

Auch die verschiedenen Mirai-Ereignisse müssen getrennt bleiben. Das Botnetz wurde unter anderem gegen KrebsOnSecurity, OVH und später Dyn eingesetzt. Die gemeinsame Schadsoftware und die teilweise zusammenhängende Betreiberhistorie ändern nichts daran, dass Ziele, Daten, Verkehrswege und Auswirkungen verschieden waren. Der Dyn-Angriff wurde zu einem Fall der Kontinuität autoritativer DNS-Dienste. Bei OVH steht die Belastbarkeit eines Hosting- und Abwehrnetzes im Mittelpunkt. Eine Vermischung würde eine dramatischere, aber technisch ungenauere Erzählung erzeugen.

Zeitgenössische Akamai-Unterlagen dokumentieren den allgemeinen DDoS-Kontext des dritten Quartals 2016. [7][8] Sie sind nützlich, um die damalige Bedrohungslage einzuordnen. Sie ersetzen jedoch weder die USENIX-Rekonstruktion von Mirai noch einen OVH-internen Nachweis. Branchenstatistiken über Angriffe bei anderen Anbietern dürfen nicht verwendet werden, um die Paketstruktur, Wirkung oder Abwehr eines konkreten OVH-Ereignisses zu behaupten.

Das US-Justizministerium veröffentlichte später Angaben zu Anklagen und Schuldbekenntnissen in Mirai-bezogenen Verfahren. [5] Diese Quelle kann die begrenzte Aussage stützen, dass identifizierte Beschuldigte strafrechtliche Verantwortung für bestimmte mit Mirai verbundene Handlungen übernahmen. Sie beweist nicht, wer jeden gegen OVH gerichteten Angriff veranlasste, mit welcher Absicht jedes beobachtete Paket gesendet wurde oder wie Gerätehalter und Netzbetreiber entlang des Pfades rechtlich zu bewerten wären.

Eine sachgerechte Beurteilung ordnet deshalb jeder Quelle eine begrenzte Rolle zu. Betreiberangaben stützen zugeschriebene Messwerte und veröffentlichte Betriebsbehauptungen. Unabhängige Forschung stützt Chronologie und Botnetzmechanik. Behördenunterlagen belegen eng umrissene rechtliche Tatsachen. Normen und spätere Leitfäden erklären mögliche Kontrollen. Keine dieser Quellen darf die Wissenslücken eines anderen Akteurs scheinbar schließen.

Direkter Botnetzverkehr ist nicht dasselbe wie Reflexionsverstärkung

Für die Wahl wirksamer Kontrollen ist die Unterscheidung zwischen direktem Botnetzverkehr und Reflexions- beziehungsweise Verstärkungsverkehr grundlegend. Bei einem Reflexionsangriff sendet der Angreifer eine Anfrage mit gefälschter Quelladresse an einen dritten Dienst. Dieser Dienst hält das Opfer für den Absender und schickt seine Antwort dorthin. Ist die Antwort größer als die Anfrage, verstärkt der fremde Dienst den ursprünglichen Datenstrom.

Gegen diesen Mechanismus kann eine Validierung der Quelladresse sehr wirksam sein. Wird die gefälschte Adresse nahe am Ursprung der Anfrage erkannt, verlässt das manipulierte Paket das Herkunftsnetz nicht. Zusätzlich kann die Absicherung oder Abschaltung offen missbrauchbarer Reflektoren den Verstärkungsfaktor beseitigen. Die Verantwortungskette umfasst dann den Anschluss, an dem gefälscht wird, das Netz, das diesen Verkehr weiterleitet, den reflektierenden Dienst und die Infrastruktur des Opfers.

Mirais grundlegende Angriffsfähigkeit benötigte diese Konstruktion nicht. Kompromittierte Kameras, Rekorder und andere internetfähige Geräte konnten Pakete direkt an ein Ziel senden und dabei ihre regulär routbaren Adressen verwenden. Die Verteilung entstand durch die große Zahl infizierter Geräte, nicht zwingend dadurch, dass jedes Paket an einem unbeteiligten Verstärkungsdienst gespiegelt wurde. Die USENIX-Forschung beschreibt diese Botnetzarchitektur und ihre Angriffstätigkeit. [3][4]

Deshalb ist BCP 38 relevant, aber keine vollständige Mirai-Abwehr. RFC 2827 beschreibt Eingangsfilterung, mit der Netze Pakete mit unzulässigen oder gefälschten Quelladressen einschränken sollen. RFC 3704 erweitert die betriebliche Betrachtung für mehrfach angebundene Netze, in denen legitime asymmetrische Wege einfache Prüfverfahren problematisch machen können. [15][16] RFC 7039 behandelt Verbesserungen der Quelladressvalidierung; MANRS stellt dazu praxisbezogene Empfehlungen für Netzbetreiber bereit. [19][20]

Diese Maßnahmen reduzieren Angriffe, die auf Adressfälschung angewiesen sind. Sie verbessern zugleich bestimmte Möglichkeiten der Zuordnung und erschweren weitere Missbrauchsformen. Sie hindern ein kompromittiertes Gerät aber nicht daran, mit seiner tatsächlich zugewiesenen Adresse einen direkten Datenstrom zu senden. Sie beseitigen keine schwachen Zugangsdaten, schließen keinen offen erreichbaren Verwaltungsdienst und erhöhen weder die Paketverarbeitungsleistung des Opfers noch die Kapazität seines bereinigten Rückwegs.

Eine direkte Flut verlangt daher andere zusätzliche Kontrollen. Betreiber benötigen eine Analyse der Quellverteilung, Verhaltenssignale, angemessene Ratenbegrenzungen, eine Zusammenarbeit mit vorgeschalteten Netzen und ausreichend genaue Filter. Eine pauschale Sperre eines ganzen Landes oder autonomen Systems kann zwar einen Teil des Angriffs reduzieren, zugleich aber zahlreiche legitime Nutzer treffen. Je breiter die Quellverteilung, desto wichtiger werden präzise Klassifikation und belastbare Informationen für Herkunftsnetze.

Bei Reflexionsverkehr kommen Protokollsignaturen, die Bereinigung offener Reflektoren und konsequente Quelladressvalidierung hinzu. Ein gemischter Angriff kann beide Kontrollgruppen erfordern. Genau deshalb muss ein Betreiber den beobachteten Paketmix dokumentieren, statt jede große DDoS-Welle mit derselben Kurzformel zu erklären.

NIST behandelt die Widerstandsfähigkeit des netzübergreifenden Verkehrs als geschichtete Aufgabe. Dazu gehören unter anderem Routing-Sicherheit, Quelladressvalidierung, Filterung, ferngesteuertes Blackholing, FlowSpec, Ratenbegrenzung, Erkennung und Koordination. [13][14] RFC 4732 betrachtet Denial-of-Service ebenfalls als breites technisches Problem und warnt vor Nebenwirkungen ungeeigneter Gegenmaßnahmen. [17] Diese späteren Leitlinien belegen nicht, welche konkrete Technik OVH 2016 einsetzte. Sie zeigen, warum keine Einzelmaßnahme über ihren tatsächlichen Mechanismus hinaus verallgemeinert werden darf.

Bei der Analyse des OVH-Ereignisses gehört Anti-Spoofing deshalb in den Vergleich der Angriffstypen und in die breitere Zuordnung von Pflichten. Es darf nicht als ein versäumter Universalschalter dargestellt werden, der Mirai sicher gestoppt hätte. Die korrekte Beschreibung des Verkehrsmechanismus ist selbst eine Form betrieblicher Verantwortlichkeit, weil sie festlegt, welcher Akteur wirksam handeln kann und welche Daten dafür benötigt werden.

Hosting-Kontinuität beginnt am Netzrand und endet beim nutzbaren Dienst

OVHs zentrale Kontrollfläche war das für Kunden betriebene Hosting-Netz. Ein Anbieter, der mit einer verteilten Flut konfrontiert ist, muss den ungewöhnlichen Verkehr erkennen, bevor ein vollständiger Ausfall eintritt. Er muss entscheiden, wann die Abwehr aktiviert wird, Pakete filtern oder umleiten, ohne das Routing zu destabilisieren, und für legitimen Verkehr einen funktionsfähigen Pfad erhalten. Diese Kette umfasst Randrouter, Backbone-Verbindungen, Filterplattformen, Kundennetze, Automatisierung und Einsatzleitung.

Die Erkennung kann nicht auf einem einzigen Messwert beruhen. Schnittstellenzähler zeigen Bit- und Paketraten. Flow-Daten können Protokolle, Ports, Quellverteilung und Zielkonzentration sichtbar machen. Routerzähler geben Hinweise auf Verwerfungen, Warteschlangen und Belastung der Steuerungsebene. Scrubbing-Systeme dokumentieren Klassifikationen und Filteraktionen. Externe sowie kundenseitige Prüfungen zeigen, ob tatsächlich nutzbare Verbindungen und Anwendungen funktionieren.

Jede Perspektive hat Grenzen. Ein starker Anstieg kann ein Angriff, ein legitimes Großereignis oder ein Messfehler sein. Eine weltweit verteilte Quellmenge kann auf ein Botnetz hindeuten, aber auch normale Nachfrage widerspiegeln. Eine Filterplattform kann Millionen verworfener Pakete melden, während Kunden weiterhin nicht erreichbar sind, weil der bereinigte Pfad überlastet ist. Eine Anwendung kann in einer Region funktionieren und in einer anderen wegen abweichender Transitwege ausfallen.

Verantwortungsfähiger Betrieb verlangt deshalb Korrelation statt eines einzelnen Diagramms. Zeitstempel müssen vergleichbar sein. Der Beginn eines Paketverlusts sollte mit Schnittstellenlast, Routenänderungen, Filteraktionen und Dienstprüfungen abgeglichen werden. Wenn Daten widersprechen, ist das keine Einladung, die unbequeme Messung zu verwerfen. Der Widerspruch kann auf unterschiedliche Messorte, Stichprobenverfahren oder regionale Effekte hinweisen.

Auch die Aktivierungsweise verändert das Risiko. Eine bedarfsgesteuerte Abwehr kann im Normalbetrieb direkte Verkehrswege erhalten und Kosten begrenzen, erzeugt aber einen Übergang, in dem Erkennung, Entscheidung und Umleitung funktionieren müssen. Eine ständig aktive Filterung beseitigt genau diesen Umschaltmoment, schafft jedoch eine dauerhafte Abhängigkeit von der Scrubbing-Infrastruktur und besitzt ebenfalls Klassifikations- und Kapazitätsgrenzen. Eine hybride Lösung verteilt diese Risiken neu, hebt sie aber nicht auf.

Nach der Aktivierung muss der Betreiber unerwünschte von erwünschten Paketen unterscheiden. Eine zu enge Signatur lässt einen Teil des Angriffs passieren. Eine zu breite Regel erzeugt einen selbst verursachten Ausfall. Ratenbegrenzung kann Kernressourcen schützen und zugleich legitime Hochlastkunden beeinträchtigen. Sperren nach Region oder autonomem System können missbräuchliche Quellen reduzieren, treffen aber möglicherweise Nutzer, deren Anschlüsse denselben Netzbereich teilen.

Der bereinigte Verkehr benötigt anschließend einen tragfähigen Lieferweg. Eine Filterung in einem vorgeschalteten Netz oder Scrubbing-Zentrum hilft wenig, wenn die Verbindung zurück zum Hosting-Netz zu klein, instabil oder falsch geroutet ist. Lokale Filterung hilft nicht, wenn die eingehende Leitung bereits vor dem Filter gesättigt ist. Eine geografisch verteilte Plattform muss außerdem wissen, ob Filterkapazität, standortübergreifender Transport und kundennahe Links einen gemeinsamen Engpass besitzen.

Zur Kontinuität gehört auch eine stabile Steuerungsebene. Routenänderungen, Filterinstallation, Telemetrieexport und Alarmierung beanspruchen Systeme, die während der Flut selbst belastet sein können. Ein Netz kann ausreichende Datenkapazität besitzen und dennoch ausfallen, wenn Steuerprozesse zu langsam reagieren, Sitzungen instabil werden oder konkurrierende Änderungen einander widersprechen. Reine Durchsatztests übersehen diesen Fehlerpfad.

Die öffentlichen Quellen legen OVHs vollständige Architektur von 2016 nicht offen. Es wäre daher unzulässig, eine bestimmte interne Topologie, private Reserve oder konkrete Filterschwelle zu behaupten. Bewertbar ist stattdessen, welche Nachweise ein Anbieter für seine eigene Architektur vorhalten sollte. Der praktische Maßstab lautet: Hat der während der Abwehr verbliebene Pfad legitimen Verkehr getragen, und konnte der Betreiber dieses Ergebnis belegen?

Bitrate und Paketrate legen unterschiedliche Engpässe offen

Große DDoS-Angriffe werden meist in Bit pro Sekunde beschrieben, weil Bandbreite leicht verständlich ist. Eine Verbindung hat eine nominelle Kapazität, und eine Flut nähert sich diesem Wert oder überschreitet ihn. Die Paketrate ist außerhalb technischer Betriebsteams weniger sichtbar, kann aber ebenso entscheidend sein. Jedes Paket muss gelesen, klassifiziert, in eine Warteschlange eingeordnet, weitergeleitet oder verworfen werden. Kleine Pakete können bei gleichem Datendurchsatz wesentlich mehr Einzelentscheidungen erzwingen.

Die Leistungsgrenze eines Routers ist nicht eindimensional. Linecards, Weiterleitungsbausteine, Switching-Fabric, Puffer, Routenprozessoren, Filtertabellen und Telemetriesysteme können auf unterschiedliche Weise erschöpft werden. Eine Regel, die für ein Protokoll billig ist, kann bei einem anderen erheblich mehr Verarbeitung verlangen. Detaillierter Flow-Export hilft der Analyse, beansprucht während eines Angriffs aber selbst Ressourcen. Ein Test, der ausschließlich Gesamtdurchsatz misst, kann den Fehlerpfad bei hoher Paketrate verfehlen.

OVHs spätere Erörterung von Paketratenangriffen ist deshalb als allgemeine Kontrollperspektive relevant. [2] Sie beweist nicht, welches Gerät oder welche Komponente die Abwehr im September 2016 begrenzte. Sie unterstützt vielmehr die Forderung, Kapazität als Matrix zu prüfen: Paketgrößen, Protokolle, Quellverteilungen, Zielmengen, Filterregeln und Betriebszustände müssen variiert werden.

Ein realistischer Test umfasst den Übergang in die Abwehr. Eine Infrastruktur kann eine Flut im stabilen Endzustand bewältigen und dennoch beim Installieren von Regeln, Ändern von Routen oder Hochfahren umfangreicher Telemetrie scheitern. Ebenso muss der Ausfall eines Scrubbing-Standorts oder eines Transitpfades betrachtet werden. Wenn die veröffentlichte Kapazität nur unter der Annahme funktioniert, dass alle Komponenten verfügbar bleiben, beschreibt sie keine belastbare Reserve.

Legitimer Verkehr muss im Lasttest enthalten sein. Eine reine Angriffssimulation kann zeigen, wie viele Pakete eine Plattform verwirft, aber nicht, wie gut sie erwünschte Sitzungen schützt. Unterschiedliche Kundendienste stellen unterschiedliche Anforderungen: Webverkehr, DNS, Sprachdienste, Spiele, APIs und dauerhafte Verbindungen reagieren verschieden auf Paketverlust, Verzögerung und Zustandsänderungen. Die Prüfung muss daher mehr als eine synthetische Standardanfrage umfassen.

Zum Nachweis gehören auch die Annahmen. Wird eine Plattform bis zu einer bestimmten Paketrate getestet, sollten Paketgrößenverteilung, Regelumfang, Präfixzahl und Protokollierung festgehalten werden. Wird Kapazität zwischen Standorten geteilt, muss erkennbar sein, welche Begrenzung verhindert, dass eine Region die Reserve einer anderen verbraucht. Stammt eine Zahl aus einem Labortest oder von einem Lieferanten, ist sie von einer Beobachtung im produktiven Betrieb zu unterscheiden.

Kunden und Aufsichtsgremien benötigen dafür keine Veröffentlichung jedes vertraulichen Konfigurationsdetails. Sie müssen aber erkennen können, ob die relevante Ressource getestet wurde, ob Aktivierung und Rückkehr geprobt sind, ob unabhängige Fehlerdomänen bestehen und ob belastbare Dienstmessungen erhalten bleiben. Eine einzelne Terabit-Angabe erfüllt diese Anforderungen nicht.

Scrubbing muss legitime Zustellung belegen, nicht nur verworfene Last

DDoS-Abwehr hat zwei Ergebnisse: Unerwünschter Verkehr wird zurückgewiesen, und erwünschter Verkehr erreicht weiterhin sein Ziel. Anbieter betonen häufig das erste Ergebnis, weil Angriffsvolumen und Drop-Zähler leicht quantifizierbar sind. Kunden erleben das zweite. Ein technisch bereinigter Datenstrom, mit dem keine nutzbare Transaktion abgeschlossen werden kann, ist keine erfolgreiche Dienstwiederherstellung.

Zur Klassifikation können Protokollgültigkeit, Quellverhalten, Reputation, Paketform, Zielkontext, Rate und Anwendungswissen beitragen. Jede Methode erzeugt Risiken falsch positiver und falsch negativer Entscheidungen. Eine umfassende UDP-Sperre kann eine Flut dämpfen und gleichzeitig legitime DNS-, Sprach-, Spiele- oder Überwachungsdienste unterbrechen. Eine Begrenzung pro Quelladresse kann viele Nutzer hinter gemeinsam genutzten Adressen benachteiligen. Eine Browserprüfung kann für Webseiten geeignet sein und APIs oder nicht interaktive Clients ausschließen.

Die zulässige Regelmenge hängt vom gehosteten Dienst ab. Ein Anbieter mit vielen Kunden kennt nicht zwangsläufig jedes legitime Protokollmuster im Voraus. Er benötigt daher kundenspezifische Richtlinien, klare Eskalationswege und eine Möglichkeit, Schutzregeln anzupassen, ohne den Backbone unkontrolliert zu öffnen. Kunden müssen ihrerseits korrekte Dienstanforderungen und erreichbare Notfallkontakte bereitstellen.

Wiederherstellungsnachweise sollten synthetische und reale Dienstprüfungen verbinden. Eine Route kann sichtbar sein, obwohl der Ursprungsdienst nicht antwortet. Ein erfolgreicher TCP-Verbindungsaufbau beweist nicht, dass die Anwendung korrekt arbeitet. Ein globaler Durchschnitt kann starken regionalen Verlust verdecken. Prüfungen sollten deshalb aus mehreren Netzen und Regionen erfolgen und mit Router-, Scrubbing- und Anwendungsdaten abgeglichen werden.

Auch die Zeit nach der ersten scheinbaren Erholung ist relevant. Wird die Abwehr zu früh zurückgenommen, kann eine zweite Angriffswelle den Dienst erneut treffen. Bleiben Filter zu lange bestehen, schädigen sie möglicherweise unbemerkt legitime Nutzer. Der Betreiber benötigt eine Beobachtungsphase, eine gestufte Rückkehr und klare Signale für eine erneute Aktivierung.

Nebenwirkungen dürfen im Abschlussbericht nicht hinter dem endgültigen Status verschwinden. Festzuhalten ist, welche Protokolle oder Netze eingeschränkt wurden, welche Kunden Ausnahmen benötigten und ob eine Regel ein Ziel schützte, während sie die Last auf ein anderes verlagerte. Ebenso wichtig ist die Dauer einer eingeschränkten legitimen Zustellung nach dem Rückgang des Gesamtverkehrs. Diese Aufzeichnungen helfen bei der Verbesserung künftiger Regeln und ermöglichen eine nachvollziehbare Kommunikation mit Betroffenen.

Das bedeutet nicht, dass jeder Filter, jede Signatur und jede Schwelle öffentlich gemacht werden sollte. Zu viele Einzelheiten könnten Angreifern helfen. Ein begrenzter öffentlicher Bericht kann dennoch Angriffsart, gemessene Größenordnung, wesentliche Abwehrmaßnahme, Zeitraum, Wiederherstellungssignal und verbleibende Unsicherheiten nennen. Kunden, Prüfer oder zuständige Stellen können unter angemessenem Schutz detailliertere Informationen erhalten.

Die öffentlichen OVH-Unterlagen belegen die gemeldete Größenordnung und die Bedeutung von DDoS-Abwehr. Sie enthalten keine kundenweise Bilanz der legitimen Zustellung. Aus dieser Lücke folgt weder, dass alle Kunden erreichbar blieben, noch, dass sie ausfielen. Sie bleibt eine ausdrücklich zu kennzeichnende Unbekannte.

Verantwortung beginnt vor dem Eintreffen der Pakete

Mirai machte kompromittierte Geräte zu einer verteilten Verkehrsinfrastruktur des Angreifers. Die Verantwortungskette beginnt deshalb lange vor dem Eingang bei einem Hosting-Anbieter. Sie lässt sich dennoch nicht auf einen einzigen Akteur reduzieren.

Gerätehersteller und Softwarelieferanten kontrollieren Standardeinstellungen, erreichbare Verwaltungsdienste, Aktualisierungswege, Zugangsdatenregeln und die Dauer des Produktsupports. Individuelle Zugangsdaten, eingeschränkte Administrationsschnittstellen und zuverlässig signierte Aktualisierungen können das Kompromittierungsrisiko reduzieren. ENISA warnte davor, dass alltägliche vernetzte Geräte zu Bestandteilen von Botnetzen werden können. [9] Spätere Berichte der US-Handels- und Heimatschutzbehörden forderten koordinierte Maßnahmen im gesamten Technologieökosystem. [10][11]

NIST verband in seinen Arbeiten zu IoT-basierten DDoS-Angriffen Gerätesicherheit und Netzresilienz. [12] Diese Quellen stützen eine systemische Zuordnung von Kontrollen. Sie beweisen nicht, dass ein bestimmter Hersteller wissentlich den OVH-Angriff verursachte oder dass sämtliche infizierten Geräte dieselbe Schwachstelle besaßen.

Geräteeigentümer kontrollieren Installation und Wartung innerhalb der Möglichkeiten, die ihnen das Produkt bietet. Sie können Zugangsdaten ändern, externe Erreichbarkeit begrenzen, Aktualisierungen installieren oder nicht mehr unterstützte Geräte ersetzen. Manche Eigentümer verfügen weder über das nötige Wissen noch über Herstellerunterstützung. Das beeinflusst die Gestaltung wirksamer Abhilfen, macht kompromittierte Geräte aber nicht zu neutralen Bestandteilen des Netzes.

Zugangsnetze können ausgehenden Verkehr beobachten und ungewöhnliches Scanning, starke Auffächerung oder länger anhaltende Angriffsmuster erkennen. Sie können funktionsfähige Missbrauchskontakte pflegen, Anschlussinhaber informieren und verhältnismäßige Beschränkungen anwenden. Die öffentlichen Unterlagen rechtfertigen jedoch nicht die Behauptung, ein bestimmtes Zugangsnetz habe den Angriff wissentlich ermöglicht. Eine Quelladresse allein zeigt weder, wer das Gerät kontrollierte, noch, ob die Adresse geteilt wurde oder wie der Anbieter auf Hinweise reagierte.

Transitbetreiber können Kapazität, Blackholing, FlowSpec oder koordinierte Filterung bereitstellen. Ihre Position ermöglicht unter Umständen, Verkehr zu begrenzen, bevor er die knappen Verbindungen des Opfers erreicht. Diese Eingriffe besitzen zugleich ein Nebenwirkungs- und Autorisierungsrisiko. Ein zu weit gefasstes Blackhole kann genau den Dienst entfernen, den es schützen soll. Ein Filter ohne ausreichende Quell- und Zielbindung kann andere Kunden treffen.

OVH kontrollierte den eigenen Hosting-Rand, interne Kapazitäten, die Aktivierung der Abwehr, Kundenkommunikation und Wiederherstellungsnachweise. Deshalb steht das Unternehmen im Zentrum dieser Untersuchung. Es kontrollierte weder die Firmware sämtlicher infizierter Geräte noch alle Herkunftsnetze. Strafverfolgungsbehörden wiederum konnten Ermittlungen und Strafverfahren führen, aber keine Pakete während des laufenden Angriffs filtern. [5]

Breitere Resilienzberichte betonen, dass Internet- und Kommunikationskontinuität von mehreren privat und öffentlich kontrollierten Schichten abhängt. [6] Diese Perspektive ist für die Verteilung von Zuständigkeiten hilfreich, aber kein Nachweis, dass eine bestimmte Empfehlung bei OVH im Jahr 2016 umgesetzt war.

Verantwortlichkeit folgt der tatsächlichen Kontrolle. Zu fragen ist, was ein Akteur beobachten und verändern konnte, welche Nachweise er behielt und wie sich seine Entscheidung auf den nächsten Betreiber in der Kette auswirkte. Die bekannteste Marke im Ereignis trägt nicht automatisch jede Ursache und jede Folge. Umgekehrt verliert sie ihre Verantwortung für die selbst betriebene Infrastruktur nicht dadurch, dass der Angriff außerhalb ihres Netzes entstand.

Herkunftsnachweise müssen nutzbar sein, ohne zur unbelegten Anschuldigung zu werden

Direkter Botnetzverkehr erzeugt ein besonderes Beweisproblem. Die Quelladresse kann echt sein und trotzdem lediglich einen Teilnehmeranschluss, ein Carrier-Grade-NAT-Gateway, einen Unternehmensrand oder ein kompromittiertes Gerät bezeichnen. Sie identifiziert nicht automatisch die Person, die den Angriff steuerte. Ein Betreiber benötigt ausreichend genaue Angaben, um wiederholten Missbrauch zu begrenzen, darf Adressdaten aber nicht in eine unbelegte Täterzuordnung verwandeln.

Ein brauchbarer Nachweis enthält mindestens einen Zeitstempel mit Zeitzone, Quell- und Zieladresse, Protokoll, Ports, Paket- und Bytezahl, Mess- oder Stichprobenmethode, Vertrauensniveau, getroffene Abwehrmaßnahme und eine Aussage dazu, ob Adressfälschung geprüft wurde. Wo rechtlich zulässig und verhältnismäßig, können eine kurze Paketprobe oder eine technische Signatur dem Herkunftsnetz helfen, den Verkehr von legitimer Nutzung zu unterscheiden. Kontaktinformationen müssen aktuell sein und ein tatsächlich handlungsfähiges Betriebsteam erreichen.

ASN- und IP-Registerdaten helfen dabei, den für einen Adressbereich eingetragenen Netzbetreiber und veröffentlichte Kontakte zu ermitteln. Sie sind Aufzeichnungen über delegierte Ressourcen und betriebliche Metadaten. Sie beweisen nicht, wer ein einzelnes Paket erzeugte. Ein Routenursprung zeigt, welches autonome System zu einem bestimmten Zeitpunkt Erreichbarkeit ankündigte. Er identifiziert weder den Eigentümer des kompromittierten Geräts noch beweist er, dass das ankündigende Netz den Angriff erkannt hatte.

Register- und Routingdaten entfalten ihren Wert deshalb erst in Verbindung mit laufendem Betrieb. Ein veralteter Missbrauchskontakt, eine ungenaue Zuordnung oder ein nicht bearbeitetes Ticket verhindert die praktische Reaktion, selbst wenn der formale Eintrag existiert. Umgekehrt kann eine aktuelle Meldung mit präzisem Zeitfenster und überprüfbarer Signatur ein Herkunftsnetz in die Lage versetzen, einen Anschluss oder ein Gerät zu finden.

Eine Missbrauchsmeldung sollte prüfbar und begrenzt formuliert sein. Der Empfänger benötigt genug Daten für eine interne Suche. Der Absender muss Messlücken benennen und darf keine Absicht unterstellen. Beide Seiten sollten Eingang, Maßnahme und Ergebnis festhalten. Wiederholte Meldungen können auf ein strukturelles Problem hinweisen; eine einzelne Beobachtung kann auch eine kurzfristige Kompromittierung oder einen Messfehler betreffen.

Brancheninitiativen wie MANRS konkretisieren Erwartungen an Anti-Spoofing und betriebliche Koordination. [20] Ihr Nutzen liegt in den beschriebenen Praktiken. Eine formale Teilnahme oder Selbstverpflichtung ersetzt keinen aktuellen Nachweis darüber, welche Filter und Reaktionen im konkreten Ereignis wirksam waren.

Für OVH konnten Herkunftsdaten gezielte Sperren und Benachrichtigungen unterstützen. Die öffentlichen Quellen enthalten jedoch weder die vollständige Menge beteiligter autonomer Systeme noch eine Bilanz ihrer jeweiligen Reaktionen. Es wäre daher unzulässig, einzelne Netze ohne zusätzliche Belege als wissentlich nachlässig zu bezeichnen.

Die Aktivierung der Abwehr braucht Befugnis, Übung und Rückkehrplan

Der Moment, in dem ein Betreiber während eines Großangriffs die Verkehrsbehandlung ändert, ist selbst gefährlich. Neue Filter können gültige Pakete blockieren. Eine Routenänderung kann das falsche Präfix zurückziehen. Ein Scrubbing-Pfad kann nicht verfügbar oder zu klein sein. Mehrere Einsatzkräfte können widersprüchliche Änderungen vornehmen. Die Kontrollgestaltung muss deshalb Geschwindigkeit mit begrenzter und nachvollziehbarer Befugnis verbinden.

Eine Aktivierungsrichtlinie sollte festlegen, wer handeln darf, welche Präfixe und Dienste betroffen sein können, welche Signale den Eingriff rechtfertigen und welche Messungen einen Erfolg bestätigen. Automatisierung kann Verzögerungen reduzieren, muss aber auf genehmigte Objekte und getestete Pfade beschränkt sein. Ungewöhnliche Situationen benötigen manuelle Entscheidungen; dafür sind geübte Abläufe und eine eindeutig verantwortliche Einsatzleitung erforderlich.

Vor einem Angriff sollten Routenautorisierung, Sitzungen, Communities, Präfixlisten, bereinigte Rückwege und Überwachung geprüft werden. Der Betreiber muss wissen, ob einzelne Ziele oder Regionen getrennt umgeleitet werden können und wie zustandsbehaftete Anwendungen auf asymmetrische Wege reagieren. Ein Test sollte auch den Ausfall eines Transitpartners oder Scrubbing-Standorts berücksichtigen, nicht nur den idealen Zustand mit vollständig verfügbarer Infrastruktur.

Während des Ereignisses gehört jede wesentliche Änderung in ein gemeinsames Änderungsprotokoll. Das ist kein Plädoyer für langsame Genehmigungsrituale, während der Dienst ausfällt. Es sorgt dafür, dass Beteiligte erkennen können, welche Regel aktiv ist, wer den nächsten Schritt verantwortet und was später zurückgenommen werden muss. Beobachtende Teams sollten Routen- und Dienstzustand prüfen können, ohne mit den Eingriffen der Einsatzkräfte zu konkurrieren.

Der Rückkehrplan ist genauso wichtig wie die Aktivierung. Ein nach dem Angriff verbleibender Filter kann Kunden dauerhaft und unbemerkt beeinträchtigen. Eine zu frühe Rücknahme kann den Dienst einer zweiten Welle aussetzen. Notwendig sind ein stabiler Beobachtungszeitraum, eine gestufte Rückführung und ein klarer Auslöser für die erneute Abwehr.

RFC 4732 warnt ausdrücklich davor, dass Schutzmaßnahmen gegen Denial-of-Service selbst schädliche Nebenwirkungen erzeugen können. [17] RFC 4948 ordnet DDoS in breitere Sicherheitsprobleme des Internets ein, darunter verteilte Zuständigkeiten und unvollständige Anreize. [18] Diese Dokumente beschreiben nicht OVHs privaten Einsatzplan. Sie stützen den Grundsatz, dass eine Gegenmaßnahme nach ihren tatsächlichen Betriebsfolgen beurteilt werden muss.

Ein schriftlich plausibler Plan ist noch kein Nachweis. Eine Route kann von einem Partner nicht akzeptiert werden, ein bereinigter Tunnel kann zu klein sein, oder eine Kundenabhängigkeit kann den Filterpfad umgehen. Überzeugend ist erst eine Übung oder ein Ereignisprotokoll, das zeigt, dass der vorgesehene Pfad den Dienst tatsächlich getragen hat.

Ein belastbares Nachweispaket trennt Aufzeichnungen von Ergebnissen

Ein verantwortungsvoller Abschluss verspricht nicht, dass derselbe Angriff niemals wiederkehrt. Er zeigt begrenzt und überprüfbar, was geschah, welche Kontrollen aktiv waren, wie ihre Wirkung geprüft wurde und welche Fragen offenbleiben.

Kontrollfläche	Aufzubewahrender Nachweis	Betrieblicher Test	Wesentliche Grenze
Verkehrserkennung	Zeitlich synchronisierte Schnittstellen-, Flow-, Paket- und Diensttelemetrie	Mehrere Signale erkennen die Flut vor dem vollständigen Ausfall	Stichproben und Aggregation können kurze oder lokale Effekte verdecken
Kapazitätsgrenze	Link-, Weiterleitungs-, Filter- und Rückweggrenzen für definierte Paketmischungen	Repräsentative Last bleibt innerhalb getesteter Ressourcen	Labor- oder Lieferantenwerte können vom produktiven Betrieb abweichen
Aktivierungsbefugnis	Genehmigte Präfixe, Eigentümer, Anbietersitzungen und Auslöser	Nur beabsichtigte Routen und Regeln ändern sich	Interne Freigabe beweist keine externe Konvergenz
Umleitung	Vorher-nachher-Routen, externe Beobachtungen und Annahme durch Partner	Der vorgesehene Verkehr erreicht den Abwehrpfad	Öffentliche Messpunkte sehen nicht jeden privaten Pfad
Angriffsklassifikation	Protokoll, Quellverteilung, Paketprobe und Vertrauensangabe	Regeln unterdrücken den beobachteten Vektor	Angreifer können den Vektor ändern; Signaturen können zu breit sein
Legitimer Verkehr	Regionale Prüfungen, Anwendungserfolg, Latenz und Ursprungszustand	Erwünschte Transaktionen funktionieren während der Abwehr	Synthetische Prüfungen erfassen nicht jedes Kundenmuster
Nebenwirkungen	Unbeabsichtigt verworfene Klassen, Ausnahmen und Kundenmeldungen	Schäden bleiben innerhalb ausdrücklich definierter Grenzen	Nicht jeder betroffene Nutzer meldet einen Fehler
Herkunftskoordinierung	Zeitlich begrenzte Missbrauchsmeldungen, Kontakte, Maßnahmen und Wiederholungen	Herkunftsnetze können kompromittierte Geräte eingrenzen	Adressdaten beweisen weder menschliche Identität noch Absicht
Rückkehr	Änderungsprotokoll, Eigentümer, Kriterien und gestufte Rückführung	Normaler Verkehr kehrt ohne unmittelbaren Rückfall zurück	Ein späterer Angriff kann erneute Abwehr verlangen
Nachhaltigkeit	Übungen, Ausnahmen, Kapazitätsprüfungen und aktuelle Einsatzunterlagen	Kontrollen bestehen wiederholte Prüfungen	Ein erfolgreiches Ereignis ist kein dauerhafter Beweis

Die Tabelle trennt dokumentarische Belege von funktionierenden Ergebnissen. Ein Ticket zeigt, dass eine Maßnahme beabsichtigt war. Ein Kapazitätsplan hält Annahmen fest. Ein ASN-Eintrag bezeichnet eine Routing-Domäne. Eine Filterkonfiguration dokumentiert eine Regel. Keines dieser Elemente beweist allein, dass Nutzer während des Angriffs erfolgreiche Anfragen abschließen konnten.

Das Nachweispaket sollte zwischen öffentlichen und geschützten Informationen unterscheiden. Öffentlich mitteilbar sind beispielsweise Zeitpunkt, Größenordnung, Angriffsart, wesentliche Abwehrschritte, Wiederherstellungssignale und bekannte Unsicherheiten. Kunden, Prüfer oder zuständige Stellen können unter Vertraulichkeit detaillierte Topologien, Schwellen, Paketproben, Vertragsdaten und interne Entscheidungen prüfen. Schutzwürdige Informationen müssen nicht allgemein veröffentlicht werden, um erhalten und überprüfbar zu sein.

Das leitende Prinzip ist der Abgleich. Schnittstellenzähler sollten zur Scrubbing-Telemetrie passen. Routenänderungen sollten mit externen Beobachtungen vereinbar sein. Filterwirkungen sollten sich im Zustand von Ursprung und Anwendung zeigen. Kundenmeldungen sollten mit regionalen Prüfungen verglichen werden. Abweichungen können Messgrenzen offenlegen und sind daher selbst wichtige Befunde.

Ein gutes Nachweispaket benennt auch fehlende Daten. Wenn kein unabhängiger Messpunkt den Spitzenwert bestätigen kann, wird das vermerkt. Wenn Stichproben keine zuverlässige Aussage über alle Quellen erlauben, bleibt die Grundgesamtheit offen. Wenn Kundeneffekte nur teilweise bekannt sind, darf eine regionale Beobachtung nicht zur globalen Entwarnung werden. Rechenschaft entsteht nicht durch vorgetäuschte Vollständigkeit, sondern durch nachvollziehbare Grenzen.

Was die öffentlichen Quellen nicht beweisen

Die Quellen stützen einen bedeutenden Mirai-Angriff gegen OVH-Infrastruktur und einen von OVH gemeldeten Spitzenwert oberhalb eines Terabits pro Sekunde. [1][2][3][4] Sie stützen die große verteilte Mirai-Population und die Fähigkeit kompromittierter Geräte, direkten Verkehr zu senden. Außerdem belegen sie die Relevanz geschichteter Kontrollen auf Geräte-, Netz-, Routing- und Abwehrebene.

Sie nennen jedoch nicht sämtliche OVH-Ziele, jeden betroffenen Kunden, die Dauer jeder möglichen Beeinträchtigung, die vollständige Scrubbing-Topologie, genaue Filterregeln, Aktivierungsschwellen, Reserven oder den gesamten Pfad des bereinigten Verkehrs. Eine unabhängige paketgenaue Prüfung des Betreiberwertes liegt in diesem Quellenpaket nicht vor.

Die Unterlagen belegen weder eine bestimmte Schadenshöhe noch Servicegutschriften, einen Vertragsbruch, Fahrlässigkeit oder einen rechtlichen Haftungsmaßstab. Auch die vollständige Menge infizierter Geräte und Herkunftssysteme für jeden einzelnen OVH-Angriff bleibt unbekannt. Aus einer beobachteten Adresse folgt nicht, dass ein Anbieter Missbrauch wissentlich zuließ.

Spätere technische und regulatorische Unterlagen erläutern geeignete Kontrollkategorien. [6][9][10][11][12][13][14][15][16][17][18][19][20] Sie dürfen nicht als Beweis dafür verwendet werden, dass OVH eine bestimmte Maßnahme im September 2016 bereits eingesetzt hatte. Gleiches gilt für OVHs spätere Darstellung der Paketratenproblematik. [2]

Die Justizunterlagen belegen begrenzte Tatsachen zu Mirai-bezogenen Schuldbekenntnissen. [5] Sie identifizieren nicht automatisch den Auftraggeber jedes bei OVH beobachteten Angriffs. Diese Grenzen schwächen die Untersuchung nicht. Sie bestimmen, welche Schlussfolgerung vertretbar ist: Bewertet werden kann, welche Betriebsnachweise ein Hosting-Anbieter und seine Partner liefern sollten. Ein privater Ereignisbericht darf aus öffentlichen Zusammenfassungen nicht erfunden werden.

Fragen an Betreiber, Kunden und Prüfer

Hosting- und Transitbetreiber sollten fragen:

Enthalten Verkehrsbaselines neben der Bitrate auch Paketrate, Protokollverteilung und Dienstzustand?
Welche Komponente wird bei kleinen, großen und gemischten Paketen zuerst zum Engpass?
Können einzelne Präfixe, Standorte, Dienste oder Kunden getrennt umgeleitet und gefiltert werden?
Sind Sitzungen, Routenautorisierung und bereinigte Rückwege praktisch erprobt?
Können Einsatzkräfte während des Angriffs Kapazitäts-, Routen- und Filterzustände gemeinsam sehen?
Welche legitimen Verkehrsklassen werden vor zu breiten Regeln geschützt?
Gibt es eine eindeutig verantwortliche Stelle für Aktivierung, Änderungen und Rückkehr?
Lassen sich präzise, zeitlich begrenzte und datenschutzgerechte Herkunftsmeldungen erzeugen?
Benötigt die Wiederherstellung dieselben Systeme, die während des Angriffs überlastet sein könnten?
Werden Kunden- und externe Messungen mit internen Anzeigen abgeglichen?
Ist nachvollziehbar, wann eine veröffentlichte Kapazitätszahl zuletzt unter realistischen Bedingungen geprüft wurde?
Bleibt bei Ausfall eines Scrubbing-Standorts oder Transitpartners eine unabhängige Reserve?

Gerätehersteller und Eigentümer sollten fragen:

Sind Zugangsdaten individuell und Verwaltungsdienste standardmäßig eingeschränkt?
Können Geräte während ihrer nutzbaren Lebensdauer authentisierte Aktualisierungen erhalten?
Ist das Ende der Unterstützung sichtbar, bevor ein Gerät zu unverwalteter Infrastruktur wird?
Können Eigentümer ungewöhnliches Scanning oder starken ausgehenden Verkehr erkennen?
Ist Isolation oder Ersatz praktikabel, wenn ein Gerät nicht repariert werden kann?
Gibt es einen erreichbaren Meldeweg zwischen Hersteller, Eigentümer und Zugangsnetz?

Kunden sollten fragen:

Welche Angriffsstärken und Paketmischungen hat der Anbieter unter realistischen Bedingungen getestet?
Ist die Abwehr ständig aktiv, bedarfsgesteuert oder hybrid, und welche Signale lösen einen Wechsel aus?
Welche Kundenprotokolle könnten durch Notfallfilter eingeschränkt werden?
Wie weist der Anbieter legitime Zustellung und regionale Wiederherstellung nach?
Welche Informationen und Ansprechpartner stehen nach einem Ereignis zur Verfügung?
Sind alternative Anbieter, Routen oder Ursprünge tatsächlich unabhängig und getestet?
Welche Messung gilt als Wiederherstellung: sichtbare Route, offene Verbindung oder erfolgreiche Anwendungstransaktion?
Wie werden Ausnahmen, Nebenwirkungen und verbleibende Einschränkungen dokumentiert?

Prüfer und zuständige Stellen sollten fragen:

Sind Kapazitätsangaben an konkrete Schnittstellen, Paketmischungen, Regelmengen und Testdaten gebunden?
Belegen die Daten einen funktionierenden Dienst oder lediglich viel verworfenen Angriffsverkehr?
Sind Aktivierungsbefugnis und Rückkehr auf genehmigte Netzressourcen begrenzt?
Können vertrauliche Paket- und Topologiedaten geprüft werden, ohne sie unsicher öffentlich zu machen?
Besitzen Verbesserungszusagen aktuelle Übungsergebnisse und dokumentierte Ausnahmen?
Sind Register- und Missbrauchskontakte mit einer tatsächlich handlungsfähigen Reaktion verbunden?
Werden Widersprüche zwischen Betreibertelemetrie, Kundenerfahrung und externen Messungen untersucht?
Ist klar getrennt, welche Aussagen gemessen, zugeschrieben, geschätzt oder unbekannt sind?

Diese Fragen verlangen weder unbegrenzte Kapazität noch die Zusage eines ausnahmslos störungsfreien Netzes. Sie prüfen, ob ein Betreiber eine bekannte Bedrohungsklasse erkennen, innerhalb begrenzter Befugnisse handeln, wesentliche Dienste erhalten und das Ergebnis nachvollziehbar erklären kann.

Schlussfolgerung: Kapazität wird rechenschaftsfähig, wenn legitimer Verkehr ankommt

OVHclouds Meldung eines Mirai-Angriffs von mehr als einem Terabit pro Sekunde bleibt ein Meilenstein in der Entwicklung großvolumiger DDoS-Angriffe. Die unabhängige Mirai-Forschung zeigt, wie eine große Population kompromittierter Geräte verteilten direkten Verkehr erzeugen konnte. Behörden-, Normen- und Branchenquellen zeigen, warum die Reaktion Gerätesicherheit, Herkunftsnetze, Transit, Hosting, Filterung und Strafverfolgung umfassen muss. [1][2][3][4][5][6][7][8][9][10][11][12][13][14][15][16][17][18][19][20]

Die zentrale Lehre lautet nicht, ein Anbieter hätte unbegrenzte Bandbreite beschaffen müssen. Kein glaubwürdiges Netz kann versprechen, jede denkbare Flut zu absorbieren. Eine Kapazitätsaussage wird erst dann belastbar, wenn sie an beobachtbares Verhalten der tatsächlich laufenden Infrastruktur gebunden ist.

Dazu gehören Bit- und Paketraten an benannten Grenzen, ein dokumentierter Aktivierungsauslöser, kontrollierte Routing- und Filterbefugnisse, ausreichende Kapazität des bereinigten Pfades, Dienstprüfungen, Aufzeichnungen zu Nebenwirkungen, Herkunftskoordinierung und eine erprobte Rückkehr. Der Nachweis muss direkten Botnetzverkehr von Reflexionsverstärkung unterscheiden und Anti-Spoofing dort einsetzen, wo der Mechanismus es rechtfertigt, nicht als universelles Schlagwort.

Die Verantwortung bleibt verteilt. Hersteller können unsichere Voreinstellungen reduzieren. Eigentümer können Geräte aktualisieren oder isolieren. Zugangsnetze können auffälligen ausgehenden Verkehr erkennen und begrenzen. Transit- und Abwehranbieter können Filterung und Kapazität bereitstellen. OVH kann den Hosting-Pfad betreiben und seine Wiederherstellung belegen. Strafverfolgungsbehörden können gegen Botnetzbetreiber vorgehen. Jeder Akteur ist nach den Kontrollen zu beurteilen, die er tatsächlich besaß, und nach den Belegen, die er erzeugen konnte.

Registereinträge, autonome Systemnummern, Verkehrsdiagramme, Kapazitätspläne und Ereignistickets sind wichtige Aufzeichnungen. Sie sind nicht der Dienst selbst. Entscheidend ist, ob Pakete mit legitimer Arbeit ihr Ziel erreichten, während feindlicher Verkehr begrenzt blieb. Für ein Hosting-Netz unter DDoS-Druck liegt der überzeugende Nachweis nicht in der größten Zahl des Rückblicks. Er liegt im weitergeleiteten legitimen Verkehr, in der beherrschten Engpassressource und in einer Wiederherstellung, die ein anderer Betreiber nachvollziehen kann.

Quellen

OVHcloud, „Was ist ein DDoS-Angriff?“: https://www.ovhcloud.com/en-gb/security/anti-ddos/ddos-definition/
OVHcloud, „The rise of packet rate attacks: when core routers turn evil“: https://blog.ovhcloud.com/en/posts/the-rise-of-packet-rate-attacks-when-core-routers-turn-evil/
USENIX Security 2017, Präsentationsseite zu „Understanding the Mirai Botnet“: https://www.usenix.org/conference/usenixsecurity17/technical-sessions/presentation/antonakakis
Antonakakis et al., „Understanding the Mirai Botnet“: https://www.usenix.org/system/files/conference/usenixsecurity17/sec17-antonakakis.pdf
US-Justizministerium, Anklagen und Schuldbekenntnisse mit Mirai-Bezug: https://www.justice.gov/archives/opa/pr/justice-department-announces-charges-and-guilty-pleas-three-computer-crime-cases-involving
National Security Telecommunications Advisory Committee, Bericht zur Widerstandsfähigkeit von Internet und Kommunikation: https://www.cisa.gov/sites/default/files/publications/NSTAC%20Report%20to%20the%20President%20on%20ICR%20FINAL%20%2810-12-17%29%20%281%29-%20508%20compliant_0.pdf
Akamai, Zusammenfassung des „Q3 2016 State of the Internet Security“-Berichts: https://www.akamai.com/site/en/documents/state-of-the-internet/q3-2016-state-of-the-internet-security-executive-summary.pdf
Akamai, Mitteilung zum „Q3 2016 State of the Internet Security“-Bericht: https://www.akamai.com/content/akamai/it/newsroom/press-release/akamai-releases-third-quarter-2016-state-of-the-internet-security-report1
ENISA, „The Internet of Things: when your washing machine and blood pressure monitor become a target for cyberattacks“: https://www.enisa.europa.eu/news/enisa-news/the-internet-of-things-when-your-washing-machine-and-blood-pressure-monitor-become-a-target-for-cyberattacks
NTIA, Mitteilung zum Botnetzbericht der US-Handels- und Heimatschutzbehörden: https://www.ntia.gov/press-release/2018/us-departments-commerce-homeland-security-release-report-president-promoting-action-against-botnets
US-Handels- und Heimatschutzministerium, Botnetzbericht: https://www.ntia.gov/sites/default/files/publications/eo_13800_botnet_report_for_public_comment_0.pdf
NIST, „Mitigating IoT-Based DDoS“: https://csrc.nist.gov/pubs/pd/2017/12/14/mitigating-iotbased-ddos/final
NIST, „Resilient Interdomain Traffic Exchange: BGP Security and DDoS Mitigation“: https://www.nist.gov/publications/resilient-interdomain-traffic-exchange-bgp-security-and-ddos-mitigation
NIST Special Publication 800-189: https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-189.pdf
IETF, RFC 2827 / BCP 38, Network Ingress Filtering: https://datatracker.ietf.org/doc/rfc2827/
IETF, RFC 3704 / BCP 84, Ingress Filtering for Multihomed Networks: https://datatracker.ietf.org/doc/rfc3704/
IETF, RFC 4732, Internet Denial-of-Service Considerations: https://datatracker.ietf.org/doc/rfc4732/
IETF, RFC 4948, Internet Security Challenges: https://datatracker.ietf.org/doc/rfc4948/
IETF, RFC 7039, Source Address Validation Improvement: https://datatracker.ietf.org/doc/html/rfc7039
MANRS, Netzwerkleitfaden zum Anti-Spoofing: https://docs.manrs.org/docs/network-guide/anti-spoofing/