karabiner
Blog-Posts,
die hängen bleiben.

Under Attack – unsere erste DDoS-Attacke

Am Tag unseres 3W-Events Mitte September geschah es: Aus heiterem Himmel schlugen am Nachmittag alle unsere Überwachungs-Systeme an und so ziemlich unsere gesamte Infrastruktur schien nach und nach auszufallen. Zuerst gingen die Systeme in Bern in die Knie, kurz darauf auch am zweiten Standort, im Rechenzentrum in Zürich. Den Plan, den PC herunterzufahren, das Polo-Shirt gegen das schicke Hemd zu tauschen und zu unserem jährlichen Kunden-Anlass zu fahren, verwarf ich vorerst.

Dieser Blog-Post soll einerseits den Ablauf dieser konkreten Angriffs-Welle aufzeigen und gleichzeitig das Thema Distributed-Denial-of-Service-Attacken (kurz DDoS) erklären.

Die erste Erkenntnis: Wir werden attackiert!

Da die erste Meldung aus dem Monitoring-System einen der Switches in Bern betraf, lag die erste Vermutung nahe, dass es einen Hardware-Ausfall gab. Als wenige Minuten später nach und nach alle Systeme in Bern und dann auch in Zürich vom Netz verschwanden – respektive als rote Warnungen im Monitoring auftauchten – erschien diese Theorie eher unlogisch.

Ausfälle über beide Standorte hinweg deuten eher in Richtung unseres Providers, von welchem wir an beiden Rechenzentrums-Standorten die Verbindung ins Internet beziehen (den sogenannten Uplink). Das erste Telefonat war ziemlich kurz: „Ja, wir sehen da was, wir sind dran, melden uns gleich wieder“.

Parallel dazu informierten wir über den internen Team-Chat das gesamte, noch im Büro befindliche internezzo-Team über die grossflächige Störung. Interessanterweise dauerte es ca. 20 Minuten, bis die ersten Kunden bei uns anriefen, ihre Website sei nicht erreichbar oder sie könnten keine E-Mails versenden.

Kurz darauf telefonierte ich erneut mit unserem Provider und die Lage wurde klarer: „Gratuliere, ihr werdet attackiert, eine DDoS-Attacke gegen eine einzelne eurer IP-Adressen“. Diese Information musste ich mir erst einen Moment durch den Kopf gehen lassen, um das Ausmass zu realisieren: Jemand von extern zwingt unsere gesamte Infrastruktur in die Knie. Heute. Mist, ich wäre doch jetzt auch lieber beim Apéro.

Parallel klingelten bei uns die Telefone im Minuten-Takt und Christian beantwortete die Anfragen unserer Kunden souverän.

In Absprache schaltete unser Provider auf Ebene seiner Router, also noch vor unserer Infrastruktur, zusätzliche Filter auf und löste damit temporär das Problem. Kurz darauf war damit der Spuk vorbei, unsere Systeme meldeten nach und nach wieder „All green“ und mit Verspätung schaffte ich es dann doch noch an den Anlass und der Abend war ein voller Erfolg.

Wenn man sich im Nachhinein den Chart eines einzelnen Systems bei uns anschaut, ist deutlich der Unterschied im aufgezeichneten Daten-Volumen sichtbar: Links ist die Kurve mehr oder weniger einheitlich im Normalzustand und auf einmal kommt der Ausschlag in die Höhe:

Traffic-Spike am 11. September im Vergleich zum Normalzustand

Traffic-Spike am 11. September im Vergleich zum Normalzustand

Die effektiven Zahlenwerte spielen in diesem Chart keine grosse Rolle – es geht mir darum, den im Verhältnis kurzfristig massiv erhöhten Datenverkehr aufzuzeigen.

Aber wie kam es nun zu diesem Angriff?

DDoS – wie bitte?

Was verbirgt sich hinter dem kryptischen Begriff „DDoS“ nun konkret? Kleine Vorwarnung, das Thema ist technisch und so ganz ohne Fachbegriffe wird es nicht zu erklären sein – ich versuche es dennoch möglichst verständlich zu halten:

In Ihrem Whitepaper zum Thema DDoS schreibt die Melde- und Analysestelle Informationssicherung (MELANI) des Bundes:

Unter DDoS versteht man einen Angriff auf Computer-Systeme mit dem erklärten Ziel, deren Verfügbarkeit zu stören. (…) Die Motivation hinter solchen DDoS-Attacken sind meistens politischer Aktivismus, Erpressung oder Schädigung eines Konkurrenten. (…) Eine DDoS-Attacke wird vielfach von einer Geldforderung begleitet. (…) DDoS kann jede Firma/Organisation treffen.

Vereinfacht dargestellt, wird ein System (4) – in unserem Fall ein einzelner Server in unserem Rechenzentrum – so massiv mit Datenpaketen beschossen (1), dass dieses unter der Last entweder einknickt oder soweit überlastet ist, dass legitime Anfragen (2) gar nicht mehr bis zu ihm durchkommen. Da die Angriffswelle aber nicht von einer einzelnen Quelle ausgeht, sondern von bis zu hunderten unterschiedlichen Systemen, ist sie nicht einfach „abzuklemmen“.

Schematische Darstellung einer DDoS-Attacke: Überlastung des Ziels oder dessen Internet-Anbindung durch zu viele Pakete.

Schematische Darstellung einer DDoS-Attacke: Überlastung des Ziels oder dessen Internet-Anbindung durch zu viele Pakete.

In unserem Fall war das Angriffsvolumen ca. 3-mal so gross wie unsere physikalische Anbindung (3) beim Provider. Wenn man sich diese Anbindung wie einen Gartenschlauch vorstellt, wird schnell klar, dass der Schlauch respektive die Leitung irgendwann schlicht voll und ausgelastet ist. Alles was über die Kapazität des Schlauches hinaus geht, verfehlt das Ziel und fällt daneben auf den Boden. Da in diesem Moment unsere Anbindung zum Flaschenhals wurde, war der Effekt so umfrangreich, dass sämtliche internezzo Kunden von der Störung betroffen waren und nicht nur die Websites, welche auf dem direkt angegriffenen Server betrieben werden.

Was für Systeme greifen uns hier an? Grundsätzlich gibt es aktuell zwei „populäre“ Arten eine DDoS-Attacke auszuführen, wobei wir davon ausgehen dass Variante B in unserem Fall zum Zug kam:

Variante A: ein Botnet

Um überhaupt genügend Datenpakete und Datenvolumen generieren zu können kann man für wenige Dollar auf dem Schwarzmarkt die „Dienste“ eines Botnets einkaufen. Dabei handelt es sich um geknackte und damit fernsteuer- und missbrauchbare Computer-Systeme jeglicher Art (häufig durch Viren/Trojaner etc. infiziert), welche für Aufträge wie Spamversand oder eben DDoS-Attacken vermietet werden.

Schematischer Ablauf einer DDoS-Attacke durch ein Botnet gegen ein einzelnes Ziel.

Schematischer Ablauf einer DDoS-Attacke durch ein Botnet gegen ein einzelnes Ziel.

Der Auftraggeber (1) kauft hier beim Botnet-Betreiber eine gewisse Dienstleistung, welche der Botnet-Betreiber anschliessend mittels der gekaperten Systeme (3) ausführt. Der Auftrag (2) wir dabei direkt vom Auftraggeber oder durch den Botnet-Betreiber an die missbrauchten Systeme gegeben. Im Falle einer DDoS Attacke ist die Dienstleistung (4) der Beschuss eines Ziels (5) mit absurd vielen Datenpaketen.

Variante B: Amplification-Attacken

Eine weitere Variante basiert auf Schwachstellen in Server-Software-Komponenten (teils weil veraltete Software-Versionen im Einsatz sind, teils durch fehlerhafte Konfigurationen). Bei dieser Art der Attacke sendet der Angreifer (1) kleine Datenpakete mit einer gefälschten Absenderkennung an mehrere Systeme welche für Amplification-Attacken ausnutzbar sind:

Schematische Darstellung der Amplification an Hand eines einzelnen ausnutzbaren Systems.

Schematische Darstellung der Amplification an Hand eines einzelnen ausnutzbaren Systems.

Diese kleinen Datenpakete (2) tragen dabei nicht die Absenderkennung des Angreifers, sondern des zu attackierenden Ziels (4), weswegen sämtliche Antworten (3) alle auf das gleiche Ziel losgeschickt werden. Normalerweise würde sich der Schaden in Grenzen halten, da der Angreifer ja nur eine begrenzte Menge an Datenpaketen versenden kann (ausser er hat eine sehr gross dimensionierte Internet-Anbindung, was wiederum ein Kostenfaktor wäre).

Hier kommt nun die „Amplification“, also die Verstärkung ins Spiel: Es gibt Situationen, in welchen fremde Server-Systeme von Dritten auf sehr kleine Anfragen mit einer sehr ausführlichen Antwort reagieren (Vergleich Grösse von (2) und (3) in der Darstellung). Und genau dieser Effekt kommt bei einer Amplification-Attacke zum Tragen: Kleine Pakete kommen als Anfrage herein (2) und werden mit teils 300-mal so viel Daten beantwortet (3) – und Dank der gefälschten Absenderkennung der Anfrage prasselt diese nun massiv grössere Datenmenge auf das angegriffene Ziel (4) ein.

Dieses Verhalten sollte in der Form nicht stattfinden und ist klar als Fehler anzusehen. Häufig sind solche Systeme schlecht gepflegte oder ohne Fachkenntnisse konfigurierte Server, welche in einem solchen Szenario einerseits zum unfreiwilligen Mittäter und gleichzeitig zum Opfer werden. Diese ausnutzbaren Systeme sind dabei weder im Besitz oder unter der Kontrolle des Angreifers, noch mit dem Betreiber des angegriffenen Ziel-Systems in Verbindung – sie werden willkürlich in die DDoS-Attacke mit einbezogen – einfach nur weil sie diesen Defekt aufweisen und sich dafür ausnutzen lassen.

Da der Angriff in diesem Szenario „über Bande“ gespielt wird, lässt sich der Verursacher, welcher im Hintergrund steht, faktisch gar nicht eruieren. Die IP-Adressen welche wir respektive unser Provider als Angreifer sehen, sind eben genau die Opfer welche selbst nicht aktiv am Angriff teilnehmen.

DDoS ist illegal, oder?

Rechtlich gesehen, wird eine solche Attacke ganz klar als eine illegale Machenschaft, konkret eine (versuchte) Datenbeschädigung gem. Art. 144bis StGB angesehen. Kommt eine Drohung oder Erpressung dazu, wäre zudem der Straftatbestand der (versuchten) Erpressung nach Art. 156 StGB gegeben.

Wir haben den Fall bei der MELANI gemeldet.

Ob wir Strafanzeige gegen Unbekannt einreichen werden, ist noch offen. Der damit verbundene Aufwand dürfte unverhältnismässig sein im Vergleich zu den Erfolgschancen. Dies, da einerseits die Verursacher der Amplification-Attacke sehr gut versteckt sind und andererseits die Recherche-Aufwände sehr schnell über die Landesgrenzen hinweg gehen und damit nur noch aufwändiger werden würden.

Sofortmassnahmen müssen her

In erster Linie filterte unser Provider die Angriffs-Wellen auf seiner Infrastruktur weg, so dass diese gar nicht erst bis zu unserem Server kamen. Hier kommt jedoch die gute Handarbeit, gepaart mit viel Erfahrung zum Tragen: Jeder Angriff ist anders – und so müssen auch entsprechende Filter von Hand erstellt und aktiviert werden.

Nach der ersten Angriffswelle vom Freitag, 11. September folgten in den darauffolgenden Tagen weitere kurze Wellen mit ähnlichen Volumina. Die Angreifer änderten jeweils die Art der Angriffe leicht ab, weswegen die Filter jeweils nicht griffen und erst manuell auf die neue Angriffsart angepasst werden mussten. Das Resultat waren leider weitere kurze Unterbrüche in der Erreichbarkeit unserer Systeme.

Da das Ziel konsequent ein einzelner unserer Server war, galt es zu isolieren wer oder was (welche Webpräsenz) das konkrete Angriffsziel ist. Hier haben wir mehrere Massnahmen ergriffen welche wir aus taktischen Gründen nicht veröffentlichen können. Der Angriff bezog sich immer auf den selben einzelnen Server und nicht auf unterschiedliche Server von internezzo. Wir gehen daher davon aus, dass ein einzelner unserer Kunden das Ziel der Attacken war und alle anderen Kunden resp. die restliche Infrastruktur nur in Form von Kollateralschaden betroffen waren.

Ziemlich genau eine Woche nach dem initialen Angriff erfolgte die bis jetzt letzte Welle. Seither sind die Filter beim Provider weiterhin aktiv und unsere Vorkehrungen zur Isolation des Angriff-Ziels ebenso.

Es blieb jetzt mehrere Tage lang ruhig. Wir behalten die Situation im Auge und auch unser Provider. Weiter sind uns aber aktuell die Hände gebunden und wir können nur abwarten.

Die Learnings

Wir haben mehrere Lehren aus diesen Angriffen und unserem Handling gezogen. Einerseits werden wir die interne Organisation für solche Störungen optimieren. Damit wird der Informationsfluss im Team, bis hin zu den Kunden, welche während einer Störung anrufen, schneller und klarer.

Infrastrukturseitig haben wir einzelne bereits in Planung befindliche Projekte neu priorisiert: Ein Projekt werden wir nun konkret früher realisieren als ursprünglich geplant, um in einem Bereich die Redundanz zu erhöhen. Mehr dazu sobald es soweit ist.

Das zugrunde liegende Problem einer solchen Überlastung durch DDoS können wir kurz und mittelfristig leider nicht komplett verhindern. In rund 14 Jahren Hosting-Betrieb war dies nun die allererste DDoS-Attacke gegen unsere Infrastruktur. Anpassungen an der Infrastruktur in diesem Bereich hätten weitgreifende Konsequenzen und Einflüsse und wir verfallen hier nicht in Aktivismus. Wenn wir in diesem Bereich etwas verändern werden, dann in Ruhe, gut durchdacht und vorbereitet.

 

Ich hoffe, dieser Artikel konnte einen Einblick geben und aufzeigen was vorgefallen ist und wie wir damit umgegangen sind.

 

Kopf-Bild „Robber“ von flickr-User „clement127“ unter Creative-Commons Lizenz

Mario Rimann

Mario Rimann entwickelt individuelle Software-Lösungen und ist verantwortlich für den Betrieb der Hosting-Infrastruktur. Er engagierte sich zwischenzeitlich im Vorstand der TYPO3-Association und entwickelt auch privat OpenSource-Software.

TYPO3 as a company

3 Kommentare

  1. Grosses Dankeschön für den interessanten und lehrreichen Artikel. Seit der neusten DDoS-Welle, welche kürzlich die halbe schweizerische Online-Welt (Digitec, Galaxus, Microspot, InterDiscount und SBB) betroffen hat, ist das Thema aktueller denn je. Bin gespannt auf weitere Updates!

Hinterlasse eine Antwort