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

  • Wie sieht es mit frisch bestellten Systemen aus? Also gerade bestellte System sollten doch schon fertig sein? Da kann ich schlecht anhand der Uptime bestimmen ob das System neugestartet wurde und ich würde es lieber vermeiden gerade beim einrichten von einem Neustart betroffen zu werden.

  • Noim:


    Da frisch bestellte Systeme in der bestehenden Cloud deployed werden, kann es hier auch noch zu Reboots kommen.


    Kraeutergarten:


    Aktuell sind wir bei 1,2%. Aufgrund strengerer Prüfungen die wir zur Zeit noch durchführen und die später entfallen sollen, können wir die Frequenz der Reboots sicher noch beschleunigen.

  • Ich muss sagen, dass ich richtig enttäuscht bin. Es wurde gesagt die VMs werden neugestartet.

    Bisher wurde lt. uptime eine VM neugestartet; alle anderen haben noch mehrere Tage uptime, aber ein paar VMs waren über den Tag bis zu 25 Minuten einfach gar nicht erreichbar über Netzwerk. Da ist mir der Reboot echt lieber. Jetzt grade seit 18:04 Uhr eine VM, seit 18:09 Uhr noch eine weitere (die Monitoring-VM, jetzt bekomme ich erstmal nichts mehr mit :D) nicht erreichbar; eine andere von 17:39 Uhr bis 18:02...


    Ich muss grade hoffen, dass es nicht zwei/drei VMs aus dem gleichen Datenbank-Cluster trifft...

  • Hecke29 : Das von Ihnen Geschilderte soll so nicht sein. Da scheint irgendetwas nicht zu stimmen. Bitte wenden Sie sich daher mit Details und unter Nennung der VMs an unseren Support. Alternativ können Sie auch den Notfallsupport anrufen.


    Mit freundlichen Grüßen


    Felix Preuß

  • Mir wurde am Telefon (Notfallsupport) soeben die Auskunft erteilt, dass die 15 Minuten Downtime (die ich hier jetzt grade pinge) mit dem internen Monitoring übereinstimmen und das System bald wieder erreichbar sein müsste, was während des Telefonats, etwa nach 16,5 Minuten (von mir gemessener) Gesamt-Nichterreichbarkeit auch der Fall war (es dürften aber über 30 gewesen sein, denn die letzte Mail von dem System kam um 18:09, aber da es die Monitoring VM war, kann ich das nicht genauer sagen). Es sei auch normal, dass das so ist. Auch mit Verweis auf die 25 Minuten der anderen VM wurde mir gesagt, dass das normal ist.

  • Mein aktueller Produktivserver hat jetzt seinen Neustart hinter sich. Sauber war der aber nicht, es sah mir sehr nach erzwungen aus.Wenn ich dem sage, er soll per acpi runter fahren oder neustarten, gibts keinerlei Probleme...

    Wie dem auch sei, der Server läuft wieder, immerhin etwas.

  • Werden die Neustarts jetzt auch noch in der Nacht durchlaufen oder sind diese jetzt erstmals pausiert?


    Mein vServer ist gerade down.


    Von außen betrachtet (hatte in einer offenen SSH ein dmesg --follow laufen) war er einfach so plötzlich weg. Kann ja trotzdem sauber runtergefahren worden sein (nachdem das Netzwerk schon down war). Muss ich mal in die Logs spicken wenn er wieder da ist.

  • Operation erfolgreich, Patient tot (ich hab natürlich das Kernelupdate zersägt und durfte so erst einen Abstecher ins Rescue machen). Server wurde sauber heruntergefahren und läuft jetzt wieder. Mein Dank an Netcup für die ganze Aktion so kurzfristig im Neuen Jahr.


    Code
    Jan 05 22:37:52 KVM systemd-logind[446]: Power key pressed.
    Jan 05 22:37:52 KVM systemd-logind[446]: Powering Off...
    Jan 05 22:37:52 KVM systemd-logind[446]: System is powering down.
    ...
  • Also mein v22016093562337972 ist seit 22:59 Offline, im SCP sehe ich zu dem Server nur die Meldung "Es ist ein Fehler aufgetreten Die Informationen können zurzeit nicht ermittelt werden. Bitte versuchen Sie es in wenigen Minuten erneut."



    Viele Grüße,

  • Mein Server hat den Neustart auch schon hinter sich. Ich hatte allerdings erwartet im Server Control Panel einen Log-Eintrag zu sehen. Da sind aber nur meine Aktionen drin. Wer weiss, wo genau in den Log-Files bei Ubuntu 16.04 LTS ein sauberes Herunterfahren zu finden wäre? /var/log/messages hat 0 Byte, in /var/log/syslog scheinen nur die Starteinträge zum betreffenden Zeitpunkt zu sein. Meine mailcow(.email) Installation war auf jeden Fall nicht mehr 100% in Ordnung, nachdem der Server wieder gestartet worden war. Ich musste alle Container noch mal neu starten, bzw. habe den Neustart mit einem Update-Check verbunden, bis SOGo wieder lief. Vor meinem Neustart sah die SOGo Anmeldemaske so aus: Bildschirmfoto 2018-01-06 um 00.20.18.png

    :thumbdown:

  • Bodenhaltung: Auch mal ganz rausgegangen aus dem SCP? Bei mir war das zuerst auch so, neu eingeloggt und siehe da, Server war seit zig Minuten on aber hat den Bootvorgang einfach aus anderen Gründen nicht geschafft (verhauenes Kernelupdate).


    Auf meinem vServer funktioniert Spectre dann immer noch (gibts keinen Patch für) und Meltdown funktioniert, wenn vServer mit altem Kernel läuft bzw. der Kernel mit nopti gestartet wurde. Ich hatte ja gehofft, es würde reichen, wenn der Host das erledigt, aber scheinbar reicht das nicht (bei vServer mit dediziertem Core) und der Bug ist dann - zumindest innerhalb der VM - noch aktiv? Blickt da noch jemand durch...


    iLion: journalctl --since="1 day ago" ?

  • Also einer meiner beiden Nodes (v22016022832831872) war jetzt auch über eine Stunde weg, dazwischen war dieser mal kurz für knapp 2 Minuten wieder erreichbar laut meinem Monitoring.


    Dieser wurde laut Logs 2 mal hart abgeschaltet, da kam nichts per ACPI :thumbdown: Glücklicherweise hat dieser das verkraftet, bei meinem anderen Node bin ich mir da nicht so sicher...

  • Zu früh gefreut, der Server ist erneut nicht erreichbar. Im SCP erscheint auch nur: "Server Informationen konnten nicht ermittelt werden".


    Irgendwie scheint es doch ein paar Probleme seitens Netcup zu geben, behaupte ich mal.


    €: Vor 5 Minuten kam eine Mail von Netcup, welche mich über einen Ausfall des Nodes informiert.