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

  • Mein vServer wurde wie per Email angekündigt neu gestartet, ohne Komplikationen. Vielen Dank an Felix und das Netcup Team. Ich habe diesen Thread von Anfang an verfolgt und freue mich über eure offene Kommunikation und professionelle Vorgehensweise.


    Roman :thumbup:

    vServer: Root-Server M, OS: Debian 8.2 Jessie

  • Hier lieb das Update ohne Probleme durch, VM läuft wieder und vom Durchsatz her ist auch alles schick. Bei uns in der Firma stehen gerade deswegen auch Updates dutzender VMs/VMHosts an, von daher mal eine große virtuelle Kanne Kaffee an das Netcup-Team für eure Mühen.

  • Statusupdate #7:


    Langsam aber sicher ist das Ende der ersten Update-Phase zu sehen. Mehr als 95% unserer Nodes sind mit Updates versorgt. Die letzten Nodes der Webhosting-Cloud sind gerade dabei neu zu starten.


    Es gibt allerdings noch einige Nodes die Probleme bereiten. Nodes von Root-Server mit Intel(R) E5-2600 CPUs und Intel(R) E5-2600v2 CPUs starten in unregelmäßigen unerwartet neu. Betroffen davon sind auch VPS-Produkte, die auf Servern mit dieser Intel-CPU-Generation liegen. Wir können hier leider nicht zu Neustarts informieren, da die Nodes wegen CPU-Fehler eigenständig neu starten. Betroffene Kunden die auf Hardware mit diesen CPUs liegen und die bereits einmal unerwartet neu gestartet ist werden wir daher gezielt anschreiben. Unsere Techniker und Softwareentwickler arbeiten auf Hochtouren um die Ursache dafür zu finden. Wenn wir bis Montag keine Lösung gefunden haben, werden wir den betroffenen Kunden einen Wechsel auf eine andere Hardwarearchitektur anbieten. Auch der Hersteller der Server HPE ist mit involviert.


    Vereinzelnd mussten wir auch VPS und Root-Server anderer CPU-Generationen rebooten. Aufgrund eines Softwarefehlers wurden nicht alle Kunden über die erneuten Reboots informiert. Wir bedauern diesen Fehler und bitten dafür um Entschuldigung.


    Täglich werden neue Kernelpatches, Microupdates und Qemu-Updates veröffentlicht. Wir sind dabei diese in einer separaten Testumgebung mit allen von uns angebotenen Distributionen zu testen. Auch werden alle Hardwarekonstelationen auf Verträglichkeit geprüft. Derzeit sind viele der Patches noch fehlerbehaftet und können daher von uns nicht eingespielt werden. Weitere Reboots sind daher Stand heute noch nicht geplant.


    Wir empfehlen allen Kundinnen und Kunden neue Kernelupdates zu prüfen. Fertigen Sie ggf. einen Snapshot an, damit Sie einfach auf eine alte Version zurück wechseln können.


    Sobald es weitere Updates gibt, werden wir hier darüber berichten.



    Mit freundlichen Grüßen


    Felix Preuß

  • vielen Dank für das Update

    Zitat

    Die letzten Nodes der Webhosting-Cloud sind gerade dabei neu zu starten.

    mit wie viel downtime für das Webhosting ist hier ca. zu rechnen -> eher Minuten oder eher Stunden ?

    Grüße,
    Dirk
    (gekündigt am 06.11.2022, aus Gründen...)

  • Hallo zusammen,


    also von unserer Seite erstmal ein herzliches Dankeschön an das gesamte netcup Team für den großen und schnellen Einsatz der letzten Tage.


    Wir hosten 8 Server bei netcup. Allesamt sind mit Debian 16.4 LTS ausgestattet.

    7 der Server sind Root Server der aktuellen Generation aber mit verschiedenen "Ausbaustufen" (1000, 2000, ...), 1 Server ist ein Storage Server.

    Die 7 Root Server wurden allesamt via ACPI sauber beendet und wieder ohne Probleme nach jeweils 10-15 Minuten hochgefahren. Die Systeme waren bei Auslösung des ACPI-Shutdowns allesamt auf dem aktuellsten Kernel- und Softwarestand der Distribution.

    Bei 6 von 7 Servern wurden wir auch im Vorfeld über den anstehenden Reboot informiert - auch hier sehr gut. :)


    Eine Frage habe ich jedoch:

    Langsam aber sicher ist das Ende der ersten Update-Phase zu sehen. Mehr als 95% unserer Nodes sind mit Updates versorgt. Die letzten Nodes der Webhosting-Cloud sind gerade dabei neu zu starten.

    Was ist mit den Storage-Servern? Kommen die später? Das ist bei uns der Einzige welcher noch nicht "behandelt" wurde.

    Alle anderen Server, bzw. halt die entsprechenden Nodes, wurden in der Reihenfolge der ehemaligen Bestellung gepatched - was mich vermuten lässt, dass so auch das System war, also von alt zu neu.



    Beste Grüße

    Patrick

  • Bei den neuesten Webhosting Tarifen sollte keine downtime entsteht, da diese als HA Cluster aufgebaut sind.

    hmmmm .... schön wär's ...
    mein (neues) Webhosting 4000 ist seit fast 2 Stunden down ...
    inkl. der Verwaltungsoberfläche (neues WCP),
    und auch das CCP findet das Hosting nicht mehr, es wird angezeigt: "Ein Fehler ist aufgetragen bei WebhostingOnyxHelper::getSession"

    Grüße,
    Dirk
    (gekündigt am 06.11.2022, aus Gründen...)

  • Ich hätte eine Frage zu ungepatchten Kunden VMs.

    Können diese aus der Cloud ausbrechen und den Speicherinhalt anderer Kunden VMs auslesen?

    So wie ich den CVE verstanden habe, handelt es sich hierbei ja um ein "Feature" von Intel Prozessoren, welches durch einen Software Patch abgeschaltet wird.

    Wenn jetzt eine ungepatchte Virtuelle Maschine dieses Feature noch nicht weg gepatcht hat, hat diese dann dennoch die Möglichkeit auszubrechen und den Speicherinhalt von anderen Maschinen auszulesen?

  • Guten Tag templis,


    Zitat

    Wenn jetzt eine ungepatchte Virtuelle Maschine dieses Feature noch nicht weg gepatcht hat, hat diese dann dennoch die Möglichkeit auszubrechen und den Speicherinhalt von anderen Maschinen auszulesen?


    gerade deswegen haben wir ja geupdatet. Innerhalb der VMs kann ggf. noch ein nicht erlaubter Speicherzugriff erfolgen. Deswegen sollten hier auch neue Updates eingespielt werden. Das liegt bei Servern ohne gebuchten Management in der Hand unserer Kundinnen und Kunden.


    Nach aktuellem Kenntnisstand kann aus einer VM nicht ausgebrochen werden. Zudem war Spectre nur sehr schwierig in einer KVM Umgebung anwendbar.


    Mit freundlichen Grüßen


    Felix Preuß

  • Moin,


    das folgende ist keine Beschwerde, dazu gibt es nun wirklich keinen Anlass!

    Es geht nur darum das zu vermerken für eventuelle Verbesserungen bei den nächsten "ungeplanten" reboots...


    RS 1000 SAS G7SEa1

    11:03(Posteingang bei outlook.com) --> Info Mail (das Neustart erfolgen wird in den nächsten 60 Minuten) erhalten

    11:05 --> Extern laufendes Monitoring meldet :Server down.

    11:06 --> Login im SCP : Server tatsächlich nicht mehr erreichbar



    Auszug /var/log/messages dazu :

    Jan 11 11:02:23 hostname systemd-logind: Power key pressed.




    Ich würde es ganz "...angenehm..." finden, wenn die Info-Mail einem tatsächlich noch ein wenig Zeit einräumen würde um ggf. Vorkehrungen zu treffen.

    (Aber das wurde hier im Thread ja schon ein zwei mal angemerkt)

    Ich möchte mich dieser Bitte einfach nur anschließen.


    Ansonsten bin ich wirklich absolut zufrieden mit der Leistung der Mitarbeiter, vor allem was den Informationsfluss betrifft.

  • 11:03(Posteingang bei outlook.com) --> Info Mail (das Neustart erfolgen wird in den nächsten 60 Minuten) erhalten


    Auszug /var/log/messages dazu :

    Jan 11 11:02:23 hostname systemd-logind: Power key pressed.

    Mich würde mal interessieren, was für Zeiten im Email Header stehen. Gerade bei Outlook.com, hotmail und Konsorten von M$ würde es mich nicht wundern, wenn die Mails noch 15 Minuten durch deren Systeme geistern bevor sie zugestellt werden.

  • Moin Toffelwurst,


    da ich das, nennen wir es mal, Phänomen auch kenne, hatte ich da schon drauf geschaut.

    Hier aber gerne mal die relevanten Zeilen aus dem header :


    Ich war so frei meine Mailadresse mit ein paar "xx" zu verschönern, ansonsten ist der Header unverändert.

    Nur eben reduziert auf das wesentliche.

  • nach angekuendigtem Serverneustart ist dieser im SCP (ich habe es auch im VSCP probiert) nicht mehr administrierbar. Neugestartet wurde er auch nocht nicht, ist per SSH nicht erreichbar.


    Entschuldigung, das sollte nicht passieren.

    Ein Serverfehler ist aufgetreten. Sollte der Fehler wiederholt auftreten, setzen Sie sich bitte mit dem Support in Verbindung.


    Was tun?

    • Offizieller Beitrag

    Der Reboot des Nodes ihres Servers ist noch nicht abgeschlossen. Ich bitte Sie um etwas Geduld.

  • Danke Dir für die Infos.

    War auch nicht als Affront gegen dich gemeint, war nur mal interessant zu sehen, da ich selbst ca. 20 Minuten Vorlauf hatte. :)

  • Eine Frage habe ich jedoch:

    Was ist mit den Storage-Servern? Kommen die später? Das ist bei uns der Einzige welcher noch nicht "behandelt" wurde.

    Alle anderen Server, bzw. halt die entsprechenden Nodes, wurden in der Reihenfolge der ehemaligen Bestellung gepatched - was mich vermuten lässt, dass so auch das System war, also von alt zu neu.

    Meine Storage Nodes wurden auch erst nach dem 95% Status behandelt (11:38 Uhr). Leider beide gleichzeitig :( 3. Node des Ceph-Clusters steht gottseidank bei einem anderen Anbieter :wacko:

  • Hallo,


    heute morgen sind zwei der 5 Server abgeschossen worden. Zwar mit Email Ankündigung, aber ohne sauberen Shutdown. Ein dritter Server wurde ein zweites Mal neugestartet (ohne Ankündigung) und ebenfalls via Abschuss. Vielleicht sind 5min einfach zu wenig, wenn auf den Servern Jails laufen, die ebenfalls Zeit zum Herunterfahren benötigen.


    Schnelles fixen von Sicherheitslücken ist großartig, aber bitte nicht um jeden Preis. NetCup hat hier in den letzten Tagen an Reputationen verloren, wenn man sich mal in den diversen Foren umsieht. Die abgeschossenen Systeme hinterlassen mehr als nur einen faden Beigeschmack und das nicht einmal zu Unrecht.


    Da man immer mit etwas positiven aufhören sollte - Daumen hoch für die Kommunikation hier

  • Moin,

    erstmal großes Dankeschön an Netcup das so schnell reagiert wird und Updates eingespielt werden.

    Mal eine andere Frage kommt es jemanden auch so vor als würde die VM spürbar schneller reagieren nachdem der Node neugestartet wurde und eventuell der Raid Controller getauscht wurde?