Anfang Juli tauchte eine große Sicherheitslücke namens Januscape auf (CVE-2026-53359) erschütterte die Welt der Virtualisierung. Dieser kritische Fehler ermöglichte es einem Angreifer, einer virtuellen Maschine zu entkommen und den physischen Server zu gefährden, auf dem sie gehostet wurde – ein Katastrophenszenario für jeden Cloud-Anbieter. Für OVHcloudDas Risiko war immens und bedrohte Zehntausende Hosts und fast eine Million virtuelle Maschinen Kunden auf der ganzen Welt.
Warum wurde ein fristloser Zwangsneustart beschlossen?
Angesichts dieser Bedrohung prüften die Teams des Hosting-Unternehmens schnell ihre Optionen. Hot-Patching schien im großen Maßstab zu riskant, und die Live-Migration von VMs auf bereits sichere Hosts hätte Monate gedauert, sodass die Flotte zu lange ungeschützt geblieben wäre. Die einzig praktikable Lösung, wenn auch radikal, bestand darin, den Patch direkt zu integrieren und das Ganze neu zu starten betroffenen Server, um dieser Sicherheitslücke entgegenzuwirken.
Die gewagteste Entscheidung war das „einseitige Patchen“. kontrollierte Auswirkungen.“ Offensichtlich wurde kein Wartungsfenster mit jedem Kunden ausgehandelt, sondern Neustarts vorgeschrieben so schnell wie möglich zu handeln. Das Exekutivkomitee bestätigte diesen Ansatz, um so viele Menschen wie möglich zu schützen, und akzeptierte dabei unvermeidliche Auswirkungen für eine Minderheit, die Infrastruktur zu sichern, bevor Angriffe gestartet werden.
Wie kam es zu dieser Operation auf globaler Ebene?
Die Operation begann in Sydney, einer kleinen Region, die als Testgelände ausgewählt wurde, um das Verfahren unter realen Bedingungen zu testen. Der Fix wurde auf die Linux-Kernelversion angewendet vom Unternehmen genutzt wird, dann eine „Follow-the-Sun“-Strategie » (FTS) wurde eingeleitet: Jede Region übernahm jeden Morgen und sorgte so für eine kontinuierliche Intervention über 11 Tage in ganz Europa und Nordamerika.
Um den Schaden zu begrenzen, gelten strenge Schutzmaßnahmen wurden eingerichtet. Schwellenwerte für das automatische Herunterfahren pausierten die Welle, wenn zu viele Hosts gleichzeitig ausfielen. Colocation-Diagramme wurden vor allem so berechnet, dass niemals zwei Server, auf denen Maschinen aus demselben Client-Projekt gehostet werden, gleichzeitig neu gestartet werden, um so deren hohe Verfügbarkeit zu gewährleisten indem man am besten eine „Anti-Affinitäts“-Regel anwendet.
Welche Auswirkungen und Erkenntnisse gab es?
Trotz der Vorsichtsmaßnahmen verlief der Vorgang nicht reibungslos, sodass Korrekturen erforderlich waren in sehr großem Maßstab. Virtuelle Maschinen starteten nicht von selbst neu, da sie Opfer von Softwarekonflikten oder Hardwarefehlern waren wie fehlerhafte Speichersticks. Auf drei Clustern wurde Datenbeschädigung festgestellt, und APIs in der Region Paris blieben zwei Stunden lang blockiert, was eine Welle von Updates verzögerte.
Die Kommunikation wurde bewusst eingeschränkt während des Betriebs, um zu vermeiden, dass die Bereitstellungssequenz offengelegt wird und böswillige Akteure dazu ermutigt werden, den Exploit zu testen. Julien Levrard, der CISO, beschreibt die Intervention als „ feat » technisch, erkennt aber die Spielräume für Fortschritt aninsbesondere zur Kundeninformation. Er warnt davor, dass die Übung wiederholt wird und kommt zu dem Schluss: „ Beim nächsten Mal müssen wir es besser machen „.
OVHcloud-Blog
