Umgang mit Sicherheitslücken in CPUs (Meltdown & Spectre)

    Quote from julian-w

    Wie viel "vorher" musst du denn Bescheid wissen? 300 Sekunden vor dem Zwangsneustart kommt per ACPI der Reboot rein, folglich hast du 5 Minuten Zeit dich vorzubereiten und dein System sauber herunterzufahren ;)

    Sehe ich diese nachricht dann wie einen Broadcast in Putty oder gibt es für mich irgendeine Möglichkeit nur kurz vor dem Restart bescheid zu wissen? Nur 10 Sekunden würden schon vollkommen ausreichen.

    Quote from julian-w

    Wie viel "vorher" musst du denn Bescheid wissen? 300 Sekunden vor dem Zwangsneustart kommt per ACPI der Reboot rein, folglich hast du 5 Minuten Zeit dich vorzubereiten und dein System sauber herunterzufahren ;)

    Mit Verlaub, aber das ist Blödsinn. Wenn Dein System korrekt auf die ACPI Signale hört, ist Deine SSH-Sitzung schneller beendet, als Du es überhaupt lesen könntest… ;)


    Wenn man den Zeitpunkt des Reboots vorher nicht einmal annähernd kennt, muss man im schlimmsten Fall in den nächsten Tagen quasi jede Handlung am eigenen Server verschieben. Inklusive Betriebssystemupdates, weil jene sonst unterbrochen werden könnten.


    [netcup] Felix P. So sehr ich Verständnis für die Maßnahme habe, aber eine kurze Info vorher wäre schon hilfreich. Gibt es da wirklich gar keine Möglichkeit, das wenigstens ein paar Minuten vorher im SCP oder sonst wo anzuzeigen?


    Das Updatescript o.ä. wird doch wissen: Node XXX ist an Stelle YYY in der Warteschleife und kommt somit wahrscheinlich innerhalb der nächsten halben Stunde an die Reihe. Ihr werdet ja kaum alle Hostsysteme gleichzeitig anstoßen... :)


    Ich möchte hier auch gar keine große Welle los treten oder eurem Team noch mehr Zeit stehlen, die heute eh schon knapp ist. Gerne kann diese Diskussion in ein eigenes Thema ausgelagert werden, damit hier nicht alles zugemüllt wird.


    Edit: ACPI-Diskussion ins längste Thema verlagert.

    "Wer nur noch Enten sieht, hat die Kontrolle über seine Server verloren." (Netzentenfund)

    Edited 4 times, last by KB19 ().

    Quote from [netcup] Felix

    Wir können aufgrund der Dringlichkeit nicht ankündigen, wann der Neustart genau passieren wird, da wir keine künstliche Verzögerung zwecks Planungen machen können.

    Hmm, schade.


    Wir betreiben unsere netcup-Server allerdings nicht nur zum Spaß ;) - unsere Kunden nutzen diesen durchaus engmaschig produktiv, und erwarten eine gute Verfügbarkeit und Stabilität. Aus diesem Grund haben wir (nach längerem Test und dabei sehr guten Erfahrungen bzgl. Stabilität und Support!) bewusst netcup als Anbieter ausgewählt, und waren bislang damit auch sehr zufrieden. Der grundsätzliche Umgang mit diesem Problem bestätigt dies auch wieder - allerdings können wir mit o.g. Aussage im speziellen nicht gut leben. :/


    Dass eine individuelle Absprache und Planung mit jedem einzelnen Kunden bei der gebotenen Dringlichkeit nicht sinnvoll ist, leuchtet völlig ein. Aber eine kurze Info vor dem Neustart eines Servers (so kurzfristig wie nötig) sollte doch machbar sein, oder ?


    Danke,

    Christoph

    Quote from [netcup] Felix

    Die Root-Server werden neu gestartet. Es wird nur eine harte Abschaltung vorgenommen, wenn der Server auf den Reboot-Befehl nicht reagiert.

    Der Vorgang ist mir noch nicht ganz klar, ein Reboot der Root-Server bring ja erst dann etwas wenn der Server und damit meine ich die VM/OS selbst den entsprechenden Patch erhalten hat. Dafür ist ja jeder Nutzer eines Root-Server selbst verantwortlich und kann nicht von netcup gesteuert werden.

    Quote from killerbees19

    Mit Verlaub, aber das ist Blödsinn. Wenn Dein System korrekt auf die ACPI Signale hört, ist Deine SSH-Sitzung schneller beendet, als Du es überhaupt lesen könntest…

    Genau: wenn man "standardmäßig" darauf reagiert. Aber das deaktivieren des Standardverhaltens ist z.B. mit einer Zeile in der grub.conf erledigt. Zudem könnte man sich sicherlich auch ein Skript basteln was den Shutdown Prozess anhält/beendet und per E-Mail benachrichtigt. Zudem wen ner nur 10sec braucht reicht ihm vermutlich sowieso ein kleines Skript aus. Aber glaube das wird zu sehr Offtopic.

    Der Host muss rebootet werden weil die Wahrscheinlichkeit besteht dass VMs aus Ihrer Umgebung ausbrechen könnten und Daten vom Host oder von anderen VMs abgreifen...

    Damit ist natürlich das Problem in der eigenen VM nicht gefixt, klar, aber die eigene VM hat man ja selber unter Kontrolle.

    Quote from ThomasChr

    Der Host muss rebootet werden weil die Wahrscheinlichkeit besteht dass VMs aus Ihrer Umgebung ausbrechen könnten und Daten vom Host oder von anderen VMs abgreifen...

    Damit ist natürlich das Problem in der eigenen VM nicht gefixt, klar, aber die eigene VM hat man ja selber unter Kontrolle.

    Richtig aber in einem HA Konstrukt könnten die VM`s von dem Host verschoben und danach ein Reboot durchgeführt werden, wenn das nacheinander durchgeführt merkt man bestenfalls garnix8)

    Quote from Ronny

    Der Vorgang ist mir noch nicht ganz klar, ein Reboot der Root-Server bring ja erst dann etwas wenn der Server und damit meine ich die VM/OS selbst den entsprechenden Patch erhalten hat. Dafür ist ja jeder Nutzer eines Root-Server selbst verantwortlich und kann nicht von netcup gesteuert werden.

    Ja und Nein, eine VM hat keinen direkten CPU-Zugriff,

    von daher ist es hinreichend, wenn das Host-System gefixt ist;

    da aber auch die VM sich - weil eigener Kernel - auf die CPU einstellt,

    macht dies schon Sinn, weil durch das Bugfixen des Host-Systems,

    auch der Guest eine gefixte CPU bekommt ...

    Grüße / Greetings

    Walter H.


    RS, VPS, Webhosting - was man halt so braucht;)

    Guten Tag,


    Quote

    [netcup] Felix So sehr ich Verständnis für die Maßnahme habe, aber eine kurze Info vorher wäre schon hilfreich. Gibt es da wirklich gar keine Möglichkeit, das wenigstens ein paar Minuten vorher im SCP oder sonst wo anzuzeigen?


    Das Updatescript o.ä. wird doch wissen: Node XXX ist an Stelle YYY in der Warteschleife und kommt somit wahrscheinlich innerhalb der nächsten halben Stunde an die Reihe. Ihr werdet ja kaum alle Hostsysteme gleichzeitig anstoßen... :)


    es gibt Nodes die rebooten komplett in 5 Minuten und welche die dafür 30 Minuten brauchen. Um hier planen zu können dürften wir jeden Node nur zu einem zuvor geplanten Zeitpunkt neustarten. Das wäre bei der Anzahl die wir an Nodes haben eine künstliche Verzögerung die eine Verlängerung der Reboots von vermutlich mehr als 7 Tage zur Folge hätte.


    Alternativ könnten wir alle Server sofort zeitgleich neu starten. Damit wären dann aber auch alle Server die ein Kunde hat zeitgleich weg. Das wollen wir nicht.


    Normalerweise werden Reboots von Nodes nach Möglichkeit Nachts und nach längerer Vorankündigung durchgeführt. Bei den hier bestehenden Sicherheitslücken müssen wir leider so schnell wie nur möglich aktiv werden.


    Wir werden hier über den Fortschritt der Reboots berichten, sobald sich genauere Zahlen und Statistiken dazu ableiten lassen.



    Mit freundlichen Grüßen


    Felix Preuß

    Hallo,


    vorab vielen Dank für den guten Service, den ihr liefert.


    Zum Thema: Ist denn bereits mit den Neustarts der Hosts begonnen worden? Oder laufen noch Tests mit dem Patch?


    Falls die Welle noch nicht läuft, wird es eine Ankündigung geben, wenn die Welle gestartet wird?


    Vielen Dank,

    Christopher Linn

    • Official Post

    Die vServer haben 5 Minuten Zeit um nach absetzen des ACPI Shutdowns herunter zu fahren.


    Wir können natürlich nur Systeme aktualisieren die unter unserer Administration stehen. Jeder der irgendwo Root-Zugriff hat, muss sich eigenverantwortlich um die Aktualisierung innerhalb seiner VM kümmern. Wir haben auf normale Kunden Root-Server oder VPS kein Zugriff. Dort liegt die Administrative Verantwortung beim Kunden.