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

  • Hallo,


    auch meine (Windows-)Server wurden gestern nachmittag hart ausgeschaltet, ohne ein ACPI-Shutdown-Signal. Nach ca. 25 Minuten liefen sie dann wieder.


    Bei Windows Server ab 2012 ist es in diesem Fall wichtig, dass man in der Systemsteuerung bei den Energieoptionen bei "Turn off the display:" ("Bildschirm ausschalten:") unbedingt "Never" ("Niemals") auswählt (am besten für alle drei Power-Profile, nicht nur für das aktuell ausgewählte), denn sonst wenn der Bildschirm gerade aus ist, fährt der Server beim ersten ACPI-Shutdown-Signal nicht herunter, sondern schaltet nur den Bildschirm wieder ein (ähnlich wie wenn man eine Taste drückt oder die Maus bewegt), und erst beim zweiten Shutdown-Signal kurz danach fährt er herunter. Nur wenn die Einstellung auf "Never" ist, kann man sicher sein, dass er auch beim ersten Signal herunterfährt.


    Diese Einstellung habe ich jedoch bei allen Servern gemacht, und es funktioniert auch wenn ich im Server-Controlpanel "Herunterfahren (ACPI)" wähle; bei dem Reboot gestern wurde das Signal aber anscheinend nicht gesendet.

  • Das mit den 72 Stunden war wohl auch ein klein wenig zu optimistisch ;) Zumindest bei mir sind Stand heute nach über 72 Stunden nur 3/9 Systeme rebootet worden. Wollte jetzt am Wochenende eigentlich mal alle Systeme durchpatchen, aber das wird wohl leider doch nichts, da ich erst auf den Reboot der Wirtsysteme warten will.


    Dafür hat bei mir das ACPI Signal einwandfrei funktioniert und meine Systeme sind sauber heruntergefahren :thumbup:

    Code
    Jan  6 14:27:29 aragorn systemd-logind: Power key pressed.
    Jan  6 14:27:29 aragorn systemd-logind: Powering Off...
    Jan  6 14:27:29 aragorn systemd-logind: System is powering down.
  • Guten Morgen,


    ich kann nur noch einmal betonen, dass wir keine vServer bei einem regulären Reboot hart abschalten. Jeder vServer erhält ein ACPI-Shutdown-Signal. Zur Sicherheit haben wir dieses jetzt nochmal manuell überprüft. Wenn Server hart abgeschaltet werden, dann nur wenn diese nicht innerhalb von 5 Minuten auf das Signal reagiert haben.

    Hallo,

    es tut mir echt leid, dass ich da nochmal drauf eingehen muss, obwohl ihr gerade so viel zu tun habt. Das Problem scheint ja zu sein, dass das ACPI Signal leider nicht bei allen vServern angekommen ist. Es sind ja mittlerweile doch ein paar Leute hier, bei denen das offenbar passiert ist. Was machen wir falsch, bzw. sollten wir ändern/prüfen, wenn es übers VCP ankommt, aber nicht durch Netcup ausgelöst? Ich wäre auch bereit das mit meinem Server auf Reproduzierbarkeit zu testen, sofern wir einen passenden Zeitpunkt finden.


    Hier nochmal ein Log von gestern. Um 16:20 Uhr der Reboot durch Netcup, ohne vorherigen Shutdown. Die anderen beiden durch mich übers VCP.


    Ich bin ratlos und wünsche ebenfalls allen einen schönen Sonntag.

  • Vieles deutet auch darauf hin, dass die kommenden 14 Tage weitere neue Kernelupdates und Microcodeupdates von Intel veröffentlicht werden. In diesem Fall müssen wir und andere Cloudanbieter erneut Updates und Reboots durchführen.


    Mit freundlichen Grüßen


    Felix Preuß

    Ed.Edison:

    mir geht es ebenso, ACPI Shutdown aus dem VCP funktioniert immer tadellos und auch bei den Offline-Snapshots (betreibe OpenBSD 6.2). Aber Gestern von netcup Server einfach runtergerissen ... bei laufenden Datenbanken. Beim darauffolgenden Neustart wurden erstmal minutenlang inodes repariert.

    Wenn ich die Aussage von Felix lesen, dann wird mir Angst und Bange, denn die naechsten Tage/Wochen mehreremale erneut die Server ohne ACPI ausschalten ... hmm.

  • Guten Tag,

    ich verfolge dieses Thema ebenfalls wie viele andere hier von Anfang an. Jetzt musste ich mich aber doch mal hier registrieren um meine Meinung zu äußern.


    Kurz vorweg:

    Moin, ich bin Tobias aus dem schönen Niedersachsen. :) Ich habe bei netcup Root-Server, die ich gewerblich für das WordPress-Hosting nutze.


    Nun zum Thema:

    Ich verstehe einerseits die Reaktion von netcup, schnell die Updates einzuspielen. Auf der anderen Seite steht jetzt aber der Kunde mit einer gewissen Ungewissheit. Ich z.B. zähle ebenfalls zu denen, wo der Server einfach abgeschossen wurde. Ich habe es vor ein paar Minuten nochmals getestet - ACPI geschieht in weniger als 15 Sekunden.

    Und das ist leider wirklich der Punkt, wo es für mich in die Schiene "Frechheit" reingeht. Je nach Aufgabenbereich des Servers ist es teils eine Schweinearbeit ihn so zu konfigurieren bis man zufrieden ist. Da steckt "Schweiß & Herzblut" drinnen - zumindest bei mir :)

    Und dann werden die Server einfach abgeschossen. Zumal es mir vorkommt, dass netcup dieses Problem gar nicht als solches ansieht. Es gibt ja mittlerweile eine ganze Reihe von Leuten hier, denen das gleiche widerfahren ist.

    Meine Bitte an netcup:

    Bitte schaltet die Server vernünftig aus oder gebt uns Kunden zumindest einen groben Zeitplan, weil dann fahre ich ihn lieber selber runter. Lieber eine Stunde länger offline als einen abgeschossenen Server.

    danke :)

  • Mhh also HPE sollte mal seine RAID Caches prüfen. Kann das Problem mit denen bestätigen. Da scheint minimum eine Charge schlechte Qualität aufzuweisen.

    Ansonsten super reaktion in angemessener Zeit seitens NC. Danke, dass ihr auf sowas vorbereitet seid. Das ist (leider) nicht selbstverständlich.

  • Respekt, Netcup, danke für die offene Informationspolitik und das Engagement, rund um die Uhr diese Fehlersituation zu handhaben.

    Daß der Serienfehler auf den Raid Controllern dazu kommt, ist ja übel - bin gespannt, was noch alles geschieht.


    Natürlich wäre es schön, Zeitfenster für das Reboot zu haben, oder gar die Reihenfolge bestimmen zu können (prod server bei mir war schon dran, test ist noch alt). Aber was nicht sinnvoll geht, geht nicht sinnvoll.

    Darum: Weiter so - sobald ich Umsatz generiere, werde ich hier 'richtige' Infrastruktur buchen.

  • Der Shutdown-Befehl wird bei uns via ACPI in die VMs gesendet, wie ja auch groß bekannt gegeben wurde. Andere Kunden können sicherlich bestätigen, dass die VMs einen ACPI Shutfown erhalten haben. Es liegt uns fern einen schwarzen Peter Kunden zuzuschieben.


    Liebes netcup Team - sowohl vor und nun noch einmal nach dem harten ausschalten der VM wurde diese auf korrektes agieren auf einen ACPI shutdown Befehl getestet.


    Über das SCP ausgelöst hat der der Server sich nicht nur schön heruntergefahren sondern war auch nach nur etwas über einer Minute wieder erreichbar. Ich bitte sie eindringlich ihre Scripte noch einmal zu überprüfen ob der getestete Timeout nicht womöglich falsch berechnet wird oder vlt sogar zwischen den einzelnen Nodes nicht zurückgesetzt wird...Wenn sich Meldungen häufen sollte man dies wirklich ernst nehmen.


    vielen Dank

  • Nach ein bisschen rumgeteste ist mir aufgefallen, dass ACPI Signale bei meinen drei Debian Servern standardmäßig gar nicht geloggt werden. Logging vorsorglich mal eingeschaltet, ich werde berichten, sobald meine verbliebenen zwei Server an der Reihe waren.

  • Der ACPI-Shutdown funktioniert bei meinen vServern sauber. Nach einem Kernel-Update starte ich meine vServer über das Kontrollpanel neu. Dies klappte bisher immer. Aber bei jedem kritischen Update am Host-System, werden mein[e] vServer immer alle hart ausgeschaltet. Es werden laut Logfile keine Dienste runtergefahren. Beim Neustart melden Datenbanken in den Logfiles Fehler, das Dateisystem beim mounten meldet ebenso Fehler.


    ich kann nur noch einmal betonen, dass wir keine vServer bei einem regulären Reboot hart abschalten. Jeder vServer erhält ein ACPI-Shutdown-Signal. Zur Sicherheit haben wir dieses jetzt nochmal manuell überprüft. Wenn Server hart abgeschaltet werden, dann nur wenn diese nicht innerhalb von 5 Minuten auf das Signal reagiert haben.


    [...]


    Diese Aussage kann ich nicht mehr hören. Der netcup-Support behauptet dieses auch immer wieder und schiebt seit Jahren dem Kunden den Schwarzen Peter zu. Ebenso ist man auch nicht in der Lage automatisiert eine Email zu schicken, welche vServer man bearbeitet hat.

    :thumbdown::thumbdown::thumbdown:

    "Security is like an onion - the more you dig in the more you want to cry"

  • Nach ein bisschen rumgeteste ist mir aufgefallen, dass ACPI Signale bei meinen drei Debian Servern standardmäßig gar nicht geloggt werden.

    Zumindestens Systemd sollte aber loggen, dass die Dienste heruntergefahren werden/wurden. Und zum Schluss meldet sich normalerweise rsyslogd zu Wort.

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

  • Guten Abend,



    wir haben die Zeit in der wir auf neue Hardware warten genutzt, um unsere Reportingmöglichkeiten an unsere Kundinnen und Kunden zu optimieren. Ab morgen werden wir in der Lage sein, Kunden via E-Mail kurz vor einem vServer-Neustart zu informieren. Hier wird dann ein Zeitfenster von einer Stunde genannt werden, in dem der vServer neugestartet wird.


    Hinsichtlich der Probleme bzgl. der ACPI-Shutdowns forschen wir noch. Wir können dieses Problem definitiv bei bestimmten Node-Typen (abhängig von der genutzten Distribution und Softwareversion) ausschließen. Wir nehmen die Kritik zum Anlass um dieses jetzt allerdings bei allen möglichen Konstellationen zu überprüfen. Dazu haben wir uns Testsysteme auf den entsprechenden Nodes angelegt und werden morgen prüfen, was bei den Neustarts passiert. Wenn es Probleme auf unserer Seite gibt, werden wir natürlich alles daran setzen, um diese zu beseitigen.



    Ich wünsche Ihnen eine angenehme Nacht!



    Mit freundlichen Grüßen


    Felix Preuß

  • Zumindestens Systemd sollte aber loggen, dass die Dienste heruntergefahren werden/wurden. Und zum Schluss meldet sich normalerweise rsyslogd zu Wort.

    Hatte ich auch erwartet. Tatsächlich wird im syslog aber kein Eintrag aufgeführt, der auf einen sanften Shutdown hindeutet. Beispiel nach dem Einschalten des Loggings:

    Zugegeben, auf dem Server läuft fast nichts, weswegen ich auch rumtesten konnte. Aber es wird tatsächlich zwischen ACPI Shutdown und Bootvorgang nichts geloggt.

  • [netcup] Felix P. :):thumbup:


    Teranas Hmm, interessant. Ich kenne das nur so…

    Das ist ein Debian Jessie ohne besondere Anpassungen.

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

  • Ab morgen werden wir in der Lage sein, Kunden via E-Mail kurz vor einem vServer-Neustart zu informieren.

    Perfekt!


    Ich sitze hier schon seit Tagen wie auf Kohlen und frage mich, wann der Server neugestartet wird. Das macht die Planung nun deutlich angenehmer.


    Mein VServer mit Slackware hat bei der letzten Wartung anständig auf das ACPI-Signal reagiert. Ich hoffe das wird auch diesmal wieder so sein.

  • Ein Gentoo ohne SystemD mit acpid reagiert auch gerne auf ein ACPI-Signal von außerhalb. Interessanterweise läuft mein vServer seit etwa 90 Tagen ununterbrochen ohne jegliches Anzeichen eines Neustarts des Wirtes.


    Ich kann mir gerade recht gut vorstellen, dass in Nürnberg in den Rechenzentren wo Netcup zuhause ist, eine "Party" saust...


    Was für ein Schlamassel das ganze. Brave new world.

  • wir haben die Zeit in der wir auf neue Hardware warten genutzt, um unsere Reportingmöglichkeiten an unsere Kundinnen und Kunden zu optimieren. Ab morgen werden wir in der Lage sein, Kunden via E-Mail kurz vor einem vServer-Neustart zu informieren. Hier wird dann ein Zeitfenster von einer Stunde genannt werden, in dem der vServer neugestartet wird.

    Ist diese ankündigung nun wirklich nur für vServer oder auch z.B Root-Server, Webhosting usw?