Post Mortem: Störung im Cloud Hosting Stack
Timeline der Störung
Störungsbeginn: 2024-09-20, 19:30
Störungsende: 2024-09-22, 01:15
Am 20.09.2024 stellten wir gegen 19:30 Uhr ein deutlich erhöhtes Paketaufkommen an unsere Cloud Infrastruktur fest. Als mutmaßliche Ursache dafür identifizierten wir eine DDoS-Attacke auf unsere Hosting-Infrastruktur. Die hohe Anzahl an Netzwerkverbindungen hatte zur Folge, dass einige Nodes nicht mehr erreichbar waren und infolgedessen von unserer Cloud-Plattform neu erstellt wurden. Auf den neu erstellten Nodes konnten Projekte aufgrund der gestörten Netzwerkverbindung zum Storage jedoch nicht starten.
In der darauffolgenden Analyse versuchten wir, die Verbindung zum Storage wiederherzustellen, sahen uns aber einem sehr diffusen Fehlerbild gegenüber. Eine erste Diagnose bestätigte die grundlegende Funktionalität des Stacks, der jedoch mit starker Verzögerung reagierte. Unsere erste Vermutung: ein Fehler in der Netzwerkstrecke zwischen den Nodes und der Registry für unsere Container-Images. Nach weiterer Analyse fanden wir heraus, dass der von der Registry genutzte Netzwerkstorage grundsätzlich funktionierte, Dateien aber nur langsam gelesen und geschrieben werden konnten. Als akute Gegenmaßnahme stellten wir die Image Registry auf einen anderen Storagemechanismus um und bauten sie neu auf. Parallel suchten wir die Ursache für die plötzlich stark verlangsamten Requests. Erschwert wurde die Analyse durch gleichzeitige und anhaltende DDoS-Attacken gegen unsere Infrastruktur, weswegen die Analyse einige Stunden in Anspruch nahm.
Eine weitere DDoS-Attacke am frühen Morgen des 21.09.2024 löste schließlich einen gleichzeitig auftretenden Softwarefehler in allen Spine-Switchen aus. Diese Switche sind die zentrale Netzwerkkomponente unserer Leaf-Spine-Architektur. In Folge kam es zur Nicht-Erreichbarkeit unserer kompletten Cloud-Infrastruktur. Dadurch war auch der Login ins Kundencenter, das mStudio und der Mailversand (eingehend und ausgehend) betroffen.
Nach der Reparatur der Spine-Switche war die Cloud-Infrastruktur wieder erreichbar. Durch den zentralen Netzwerkausfall mussten Teile der Cloud-Infrastruktur jedoch mit manuellem Aufwand neu provisioniert werden. Diese Neuprovisionierung wurde parallel von weiteren DDoS Attacken unterbrochen, was die Entstörung der Situation spürbar verzögerte.
Im Rahmen unserer Analysen identifizierten wir weitere Komponenten unserer Cloud-Infrastruktur, die bei den benannten Traffic-Spitzen zum Flaschenhals wurden. Im Zuge der Entstörung nahmen wir leichte Anpassungen an unserer Cloud-Architektur vor, um die betroffenen Komponenten skalieren zu können. Bei den betroffenen Switches passten wir außerdem die Firmware an, da wir hier eine zentrale Anfälligkeit vermuteten und bestätigt fanden.
Am frühen Abend des 21.09.2024 zeigten die Anpassungen ihre komplette Wirkung: Die Cloud-Infrastruktur war ab diesem Zeitpunkt wieder komplett funktional und hielt weiteren Lastspitzen ohne Beeinträchtigung der Verfügbarkeit stand. In den darauffolgenden Stunden nahmen wir weitere nötige, manuelle Schritte vor, um individuelle Fehler einzelner Kundensysteme zu beheben und diese wieder verfügbar zu machen. Diese Arbeiten konnten wir in der Nacht zum 22.09.2024 erfolgreich abschließen und die Störungslage damit abschließend beheben.
Was ist bei der Störung genau passiert?
Wie kann ein erhöhtes Paketaufkommen die Nicht-Erreichbarkeit von Nodes zur Folge haben?
Durch den DDoS-Angriff haben mehrere Nodes ihre netzwerkseitige Erreichbarkeit verloren. Als Ursache hierfür identifizierten wir volle ip_conntrack Tabellen. Diese Tabellen werden vom Linux-Kernel dafür verwendet, offene IP-Verbindungen nachzuverfolgen. Sind sie gefüllt, nimmt der Linux-Kernel keine weiteren Verbindungen entgegen. Das beeinträchtigt die Funktionalität des Software-defined Networkings, was in Folge zur Störung der netzwerkseitigen Erreichbarkeit zwischen Compute- und Storage-Nodes führte.
Wie kann ein DDoS zum kompletten Ausfall von Spine Switches führen?
In unserem Cloud Network Stack setzen wir redundant ausgelegte Komponenten von namhaften Herstellern ein. Diese werden mit den empfohlenen Firmware-Versionen betrieben. Während des hohen Paketaufkommens konnten wir feststellen, dass diese den eingehenden Traffic nicht korrekt weiterleiteten. Als Grund hierfür vermuten wir ein Fehlverhalten in der eingesetzten Firmware-Version. Die vollständige Einstellung sowohl internen als auch externen Traffics in den frühen Morgenstunden des 21.09. konnten wir zudem auf einen weiteren Firmware-Fehler zurückführen, da die verwendeten Geräte ihre Hardware-Komponenten betriebssystemseitig nicht mehr erkannten. Ein Reboot der Geräte brachte zunächst keine Besserung. Erst ein Neustart unter Trennung der Spannungsversorgung führte wieder zur korrekten Erkennung der Komponente.
Wir gehen davon aus, dass die ersten Angriffe dieses spezielle Fehlerszenario in der Firmware auslösten. Diese Vermutung bestätigte sich, als wir zunächst einen Switch auf einen neuen Firmwarestand aktualisierten. Bei einer darauffolgenden Traffic-Spitze konnten wir nachvollziehen, dass der Switch mit neuer Firmware den Peak korrekt verarbeitete. Beim Switch mit alter Firmware konnten wir das genannte Fehlverhalten erneut nachvollziehen.
Maßnahmen und Behebung
Ursächlich für das Fehlverhalten der Cloud-Infrastruktur waren Peaks im eingehenden Traffic, die nicht korrekt verarbeitet werden konnten. Um die Störung zu Beheben und diese Anfälligkeit nachhaltig zu lösen, haben wir mehrere Maßnahmen vorgenommen:
- Anpassung der Firmware unserer Spine-Switche
- Skalierung der Ingress-Nodes innerhalb der Hosting-Cluster
- Verwendung von ECMP zur besseren Verteilung des eingehenden Traffics auf mehrere Nodes
- Verschärfte Filterung des eingehenden Traffics
Nach Umsetzung dieser Maßnahmen konnten wir auch bei folgenden Lastspitzen kein netzwerkseitiges Fehlverhalten mehr feststellen.
Perspektive
Zusätzlich zu den bereits umgesetzten Maßnahmen unterziehen wir unsere Cloud-Plattform derzeit einem Re-Engineering. Ziel davon ist es, die Komplexität der Plattform und insbesondere des Networking-Stacks zu reduzieren. Dadurch erhöhen wir die Stabilität und Resilienz des Gesamtsystems.
Das umfasst beispielsweise, weniger auf komplexe Cloud-Architekturen wie OpenStack, sondern vermehrt auf Bare-Metal-Architekturen mit einer vereinfachten Bereitstellung von Kubernetes-Clustern zu setzen. Diese umfangreichen Anpassungen an der Cloud-Infrastruktur befinden sich aktuell in der Test- und Stabilisierungsphase. Wir werden sie im Laufe der nächsten Monate ausrollen.
