Am Abend des 11. August haben Cyberkriminelle einen DDoS-Angriff auf das Netzwerk eines Kunden des Zürcher Hosting- und Cloud-Anbieters Nine gestartet. Nine stellt für diesen Kunden die Anbindung zum Internet bereit. Auch wenn Nine den Namen dieses Kunden nicht nennt, liegt es nahe, zu vermuten, dass es sich um Threema handelt. Threema war am 11. August, zwischen 19.30 und 23.30 Uhr nicht verfügbar und hat seine Sicht auf die Ereignisse bereits publiziert.

Wie Nine nun in einem Postmortem-Bericht zum Angriff erklärt, gehe man davon aus, dass der erste betroffene Kunde das primäre Ziel war, könne aber nicht vollständig ausschliessen, dass auch andere Kunden Ziele waren. Der durch den Angriff entstandene Traffic beeinträchtigte zudem auch das eigene Netzwerk von Nine.

Als Angriffstechnologie verwendeten die Kriminellen laut Nine UDP-Amplification. Dabei werden kleine Anfragen an offene Dienste im Internet geschickt, allerdings wird die IP-Adresse des Ziels selbst als Absender der Anfragen angegeben. Die Antworten gehen deshalb ihrerseits auch an das Ziel und verursachen ein Mehrfaches des Traffic-Volumens. Wenig Bandbreite erzeuge so ein sehr grosses Angriffsvolumen. In Spitzenzeiten wurden durch den Angriff 500 bis 600 Gbit/s an Traffic verursacht, laut Nine ein Mehrfaches seiner Uplink-Kapazität.

Die erste Welle traf gemäss Nine wie erwähnt eine einzelne Kunden-IP, überlastete dabei aber auch die Uplinks des Hosters selbst. Den ersten Angriff habe man mit einer Blackhole-Route bei den Upstream-Providern abgewehrt. Über Nacht folgten jedoch weitere Angriffswellen, unter anderem gegen die Website von Nine selbst.

Weitere Wellen folgten am Morgen des 12. August, wobei die Ziele laufend wechselten. Nine habe daraufhin seine exponierten Applikationen hinter ein CDN mit DDoS-Schutz gestellt und die betroffenen Netze nur noch über Routen geleitet, auf denen die Abwehrmassnahmen tatsächlich griffen. Gegen 19.15 Uhr am Abend stoppte der Angriff, was auch Messungen eines Upstream-Providers bestätigten.

Ab dem nächsten Tag baute Nine dann einige Abwehrmassnahmen wieder ab. Diese Massnahmen hatten bewirkt, dass der Traffic zu einigen Kunden komplett gesperrt war. Alle Applikationen und Dienste seien seither aber wieder im Normalbetrieb.

Sobald bei einem UDP-Amplification-Angriff der Uplink voll ist, erklärt Nine, greife eine Filterung innerhalb des eigenen Netzwerks nicht mehr. Zu diesem Zeitpunkt würden legitime Pakete bereits verworfen, weil der Uplink überlastet ist. Ein Angriff dieser Art lasse sich deshalb nur ausserhalb weiter abwehren – bei den Upstream-Providern. Das Mittel dort sei Blackholing: Der Provider verwerfe Traffic, der an eine bestimmte IP-Adresse gerichtet ist, statt ihn weiterzuleiten. Das schütze das Netzwerk und alle anderen Kunden, betreffe aber auch den legitimen Traffic zu dieser IP-Adresse.

Als Konsequenz seien betroffene IP-Adressen während des aktiven Blackholings bewusst unerreichbar gemacht worden, auch für legitimen Traffic. Man habe also die Verfügbarkeit einzelner Ziele vorübergehend aufgegeben, um das Netzwerk für alle anderen stabil zu halten.

Nachdem Nine direkt angegriffen worden war, verschob der Provider seine eigene Website auf eine neue IP-Adresse. Aber auch diese Adresse wurde innerhalb von Minuten angegriffen. Die Anzahl der Anfragen sei hoch genug gewesen, um einzelne Dienste zu überlasten, so Nine. Blackholing habe zwar das Netzwerk vor weiterer Überlastung geschützt, konnte aber die angegriffenen Dienste nicht verfügbar halten, weil es sämtlichen Traffic zur betroffenen IP-Adresse blockierte.

Um die Verfügbarkeit wiederherzustellen, habe man deshalb eine zusätzliche Abwehrebene eingeführt. Am 12. August habe man die exponierten Applikationen hinter ein CDN mit DDoS-Schutz gestellt und die Migration am Folgetag abgeschlossen.

Auch der als erster betroffene Kunde – vermutlich Threema – habe auf seiner Seite zusätzliche Abwehrmassnahmen geprüft und umgesetzt. Der Angriffsverkehr ende nun beim Schutzanbieter, während legitime Anfragen die Applikationen trotzdem noch erreichen. Weil Nine sein eigenes Netzwerk betreibe, habe man Routing-Änderungen direkt während des laufenden Angriffs vornehmen und die zusätzlichen Abwehrmassnahmen koordinieren können, ohne dass man auf Anpassungen an einer darunterliegenden Netzwerkinfrastruktur angewiesen war.

Nine erklärt auch sehr offen, warum seine vorher bestehenden Schutzmassnahmen nicht ausgereicht haben.

Die Traffic-Erkennung deckte beispielsweise nicht alle Netzwerke ab, die Nine betreibt. Die erste Welle traf genau ein solches Netz und musste manuell abgewehrt werden, was rund 90 Minuten kostete. Diese Lücke habe man aber noch in derselben Nacht geschlossen.

Die Wirksamkeit des Blackholings wurde zudem nicht pro Route überprüft, erklärt Nine weiter. Das funktioniere aber nur, wenn jeder Upstream-Provider das Blackholing-Signal akzeptiert und umsetzt. An Internet Exchanges sei diese Methode zudem generell nicht anwendbar. Es gab weder eine regelmässige Überprüfung pro Route noch eine Alarmierung. Ein Ausweichen über andere Routen war auch keine Option. Ein einzelnes Netz gegenüber einem einzelnen Provider zurückzuhalten, war nicht vorgesehen. Diese Fähigkeit habe Nine erst während des Angriffs unter Volllast entwickelt und in Betrieb genommen, ebenso wie den CDN-Schutz.

Beide Massnahmen haben zwar letztendlich funktioniert, waren aber langsamer und riskanter als nötig, räumt Nine ein.

Ein weiteres Problem: Nine betreibt seine eigene Website auf deplo.io, auf derselben Plattform, die auch Kunden angeboten wird. Der Angriff darauf betraf deshalb auch Applikationen, die dieselbe Plattform nutzen. Das Cockpit und das Ticketsystem liefen zwar auf separater Infrastruktur, wurden zu einem späteren Zeitpunkt aber ebenfalls direkt angegriffen. Daraus habe sich die unangenehmste Folge des Vorfalls ergeben: Kunden verloren vorübergehend gleichzeitig ihre Applikation, deren Verwaltung und einen Teil ihrer Kommunikationswege zu Nine.

Nine will seine eigenen Dienste trotzdem weiterhin auf deplo.io betreiben. Statt sie zu migrieren, wolle man die Plattform härten. Nine werde die deplo.io-Architektur weiter entwickeln, um die Abhängigkeit einzelner Applikationen von gemeinsam genutzten Adressen zu reduzieren. Zusätzlich werde das Cockpit und das Ticketsystem besser geschützt, damit diese auch während eines Angriffs erreichbar bleiben.