Post Mortem zur Störung im Cloud Hosting Stack infolge eines DDoS
Timeline der Störung
Störungsbeginn: 2024-09-27, 11:45
Störungsende: 2024-09-27, 18:00
Fehlerbild und Abgrenzung zur Störung vom 20.09.2024
Auslöser der Störung vom 20.09.2024 war ebenfalls eine DDoS-Attacke auf unsere Infrastruktur. Im Post Mortem haben wir über die Ursachen und die ergriffenen Gegenmaßnahmen aufgeklärt. Die am 27.09.2024 beobachtete DDoS-Attacke hatte eine ähnliche Signatur. Die Auswirkungen dieses Angriffs beschränkten sich aber auf einen spürbar kleineren Teil unserer Infrastruktur. Auch die Entstörung nahm deutlich weniger Zeit in Anspruch. Die im Kontext der Störung vom 20.09.2024 ergriffenen Gegenmaßnahmen zeigen also Wirkung, mussten nun jedoch noch einmal ausgebaut werden.
Warum konnte ein DDoS wieder zu Ausfällen führen?
Ursächlich für die andauernden Downtimes im Zuge der benannten DDoS-Attacke vom 20.09.2024 war eine netzwerkseitige Störung in unserem Cloud-Stack. Als Kernproblem stellten sich damals überfüllte ip_conntrack-Tabellen und ein Fehlverhalten der Spine Switches heraus, was zu spürbaren Folgefehlern führte.
Überfüllte ip_conntrack-Tabellen konnten wir am 27.09.2024 als Störungsursache ausschließen. Aufgrund der Erfahrungen des vorausgehenden Vorfalls überprüften wir diese direkt und konnten keine signifikanten Abweichungen vom Normalzustand feststellen.
Im Zuge der Analyse fiel jedoch ein Fehlverhalten von Routing-Komponenten unseres Software-defined Networking Stacks auf. Diese Komponente hatte bei der Störung vom 20.09.2024 keine Auffälligkeiten gezeigt. Nun führte ein Fehlverhalten dazu, dass Pakete innerhalb des einzelnen betroffenen Clusters nicht mehr zuverlässig geroutet wurden. In der Folge kam es immer wieder zu Aussetzern in der Erreichbarkeit einzelner Projekte. Dieses Fehlerbild ist sehr untypisch und schwer zu identifizieren, weshalb die Analyse einige Zeit in Anspruch nahm.
Wir konnten außerdem wiederholt ein Fehlverhalten des Spine Switches beobachten, der bereits in der Störung vom 20.09.2024 für Auffälligkeiten gesorgt hatte. Dieser Switch hatte im Zuge der letztmaligen Störungsbehebung einen aktualisierten Firmwarestand erhalten, was das Fehlverhalten des Geräts jedoch offenbar nur kurzzeitig behob - am 20.09.2024 konnten wir durch diese Maßnahme eine Lösung des Problems beobachten.
Welche Gegenmaßnahmen wurden ergriffen?
Beim Fehlverhalten der Routing-Komponente im Software-defined Networking Stack handelt es sich um ein untypisches Fehlerbild, das hier erstmalig in knapp 4 Betriebsjahren dieser Infrastruktur auftat. Wir konnten zum jetzigen Zeitpunkt noch keine konkrete Ursache für dieses Fehlverhalten feststellen und werden es in den kommenden Tagen eingehend analysieren. Als Sofortmaßnahme haben wir Monitoring-Checks implementiert und ins Alerting eingebunden, die auf diesen Fehlerfall prüfen.
Das Fehlverhalten des Spine Switches können wir mittlerweile auf eines der beiden Geräte im Spine Mesh eingrenzen, das im DDoS-Fall wiederholt für Fehler gesorgt hat. Wir sehen keinen Anhaltspunkt für einen Hardware-Fehler. Trotzdem werden wir die Hardware kurzfristig im Zuge einer geplanten Wartung austauschen und das Verhalten darauffolgend weiter analysieren.
Zusätzlich haben wir weitere netzwerkseitige Anpassungen vorgenommen, um den eingehenden Traffic besser filtern und verarbeiten zu können. Genauere Informationen dazu veröffentlichen wir aus Sicherheitsgründen an dieser Stelle bewusst nicht, um Angreifern keine zusätzlichen Informationen zur Entwicklung von Angriffsszenarien zu bieten.
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. Damit reduzieren wir die Failure-Domain, verringern die Vermaschung und die Kreuzabhängigkeiten der Infrastruktur und verteilen den eingehenden Traffic bereits initial auf eine große Anzahl Backends. So minimieren wir auch den Impact etwaiger Attacken oder Störungen.
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.