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

  • Sehr geehrte Kundinnen und Kunden,


    der 4. Januar 2018 wird in die Geschichte eingehen. Medien überschlagen sich heute mit Berichten zu einer Sicherheitslücke in CPUs. Es gibt bereits etliche Spekulationen unter anderem das CPUs langsamer werden usw.. Wir denken es ist wichtig, dass Sie die Fakten kennen und wissen was netcup in dieser Angelegenheit unternimmt.


    Ein Überblick:

    Heise berichtet dazu: https://www.heise.de/security/…ende-Patches-3931562.html

    Golem berichtet: https://www.golem.de/news/memo…speicher-1801-131938.html

    Selbst die Tagesschau berichtet dazu heute: http://www.tagesschau.de/ausla…icherheitsluecke-101.html


    Unser Support erhält dazu auch etliche Anfragen. Sie als unsere Kundinnen und Kunden wollen zu recht wissen, wie netcup mit der Sicherheitslücke umgeht. Damit wir Informationen gebündelt an Sie weitergeben können und damit auch Sie sich mit anderen Kundinnen und Kunden austauschen können, haben wir diesen Beitrag eröffnet. Wir werden hier Neuigkeiten bekannt geben, sobald wir diese haben.


    Zunächst das Wichtigste:


    Wir nehmen Sicherheit sehr ernst und tun alles, damit wir Ihnen die bestmögliche Sicherheit anbieten können die es gibt. Wir gehen nicht davon aus, dass unsere CPUs wesentlich langsamer werden, wenn wir die Sicherheitslücken durch einen Softwarepatch schließen, da wir auf unseren Servern ausreichend freie CPU-Ressourcen haben. Unsere Nodes für Root-Server sind z.B. im Schnitt nur zu 60% ausgelastet, was die CPU-Leistung angeht. Darüber hinaus setzen wir neue CPUs von Intel (R) ein. Diese sollen laut Experten keine merkbaren Performance-Einbußen bei einem Softwarepatch erfahren.


    Zum aktuellen Stand:


    Seit heute morgen schreiben wir alle Kundinnen und Kunden an, die einen vServer, Root-Server, Storage-Server oder managed private Server bei uns beziehen und verweisen auf diesen Forenbeitrag. Darüber hinaus verweisen wir darauf, dass wir alle vServer, Root-Server, Storage-Server oder managed private Server neustarten, sobald wir einen getesteten Patch für unsere Systeme haben. 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. Wir werden die Nodes allerdings möglichst seriell (sprich nacheinander) Neustarten. Wenn Sie mehrere vServer, Root-Server, Storage-Server oder managed private bei uns gebucht haben, werden diese somit nach Möglichkeit nacheinander neu gestartet werden. Wenn Sie eine Failvoder-IP bei uns gebucht haben, können Sie eine HA-Cluster somit aufrecht erhalten.


    Kundinnen und Kunden die einen managed private Server / managed vServer oder managed dedizierten Server bei uns gebucht haben, brauchen nichts weiter zu unternehmen. Wir kümmern uns darum, dass alle gebuchten Dienste nach dem Neustart wieder korrekt arbeiten.


    Dedizierte Managed Server werden wir auch sehr zeitnah mit dem Patch versehen und nach Rücksprache mit unseren Kundinnen und Kunden neustarten.


    Nodes unserer Webhosting-Cloud werden nacheinander neugestartet werden. Hier wird es nur eine sehr kurze Nichterreichbarkeit von Webhosting-Accounts geben.


    Unsere Bitte:


    Damit dieser Forenbeitrag übersichtlich bleibt, bitten wir darum hier keine Spekulationen zu führen. Bitte stellen Sie Fragen oder versorgen Sie diesen Beitrag mit Informationen aus verlässlichen Quellen.


    Vielen herzlichen Dank!

  • Werden die Rootserver einfach abgeschossen ("Forced Poweroff") oder werden die über "Shutdown (ACPI)" heruntergefahren? Wenn ersteres, dann wäre es klug, wenn man selbst die Server derweil herunterfährt, oder?

    Bisher wurde es bei Netcup immer so gehandhab, dass der vServer erst ein ACPI-Shutdown Signal erhält und erst wenn darauf nicht reagiert wird, wird der KVM Prozess abgeschossen. Die Zeit, die abgewartet wird, empfand ich persönlich aber immer als recht knapp bemessen. (Ich glaube nur irgendwas um die 10 Sekunden)

    Sollten komplexere Dienste laufen, die etwas länger brauchen um Vorgänge sauber zu beenden, wurde ich diese sicherheitshalber vorab beenden.



    Eine Frage meinerseits währe noch:

    Sie schließen damit die Lücke "nur" auf Ihrer eigenen Seite, also auf Ihrem Node/root/Hardware nehme ich an? Wer einen normalen vServer besitzt muss sich selbst noch Kernel-Patches kümmern, da die Lücke weiterhin auf der eigene Verwaltungsebene ausgenutzt werden kann.

  • Bisher wurde es bei Netcup immer so gehandhab, dass der vServer erst ein ACPI-Shutdown Signal erhält und erst wenn darauf nicht reagiert wird, wird der KVM Prozess abgeschossen. Die Zeit, die abgewartet wird, empfand ich persönlich aber immer als recht knapp bemessen. (Ich glaube nur irgendwas um die 10 Sekunden)

    Sollten komplexere Dienste laufen, die etwas länger brauchen um Vorgänge sauber zu beenden, wurde ich diese sicherheitshalber vorab beenden.

    Sollten es 10 Sekunden sein so ist das wirklich etwas knapp.

    Mein FreeBSD im vSERVER braucht ca. 30 Sekunden bis es nach einem ACPI-Befehl den reboot auslöst.

    Vorher sind ggf. noch Laufwerke gemountet und nicht ge-sycnt.


    In der Steuerkonsole gibt es den "Garantierten Neustart", dieser warte angeblich 5 Minuten bis zum harten reboot, das klingt deutlich sinnvoller als 10 Sekunden.

  • Eine Frage meinerseits währe noch:

    Sie schließen damit die Lücke "nur" auf Ihrer eigenen Seite, also auf Ihrem Node/root/Hardware nehme ich an? Wer einen normalen vServer besitzt muss sich selbst noch Kernel-Patches kümmern, da die Lücke weiterhin auf der eigene Verwaltungsebene ausgenutzt werden kann.

    So würde ich sagen wir das gemacht, da NetCup ja nicht auf die Instanzen zugreift. und einige ja auch eigene Kernel gebaut haben, vermutlich.

    Ich denke aber, wenn das Problem am Host gefixed ist sollten die "lagen" darunter auch gefixed sein

  • Die Quelle? Es wird ja viel spekuliert.


    Viele Grüße


    Felix Preuß

    "Die Software-Maßnahmen gegen die Sicherheitslücken dürften zwar die Leistung der Prozessoren beeinträchtigen, räumte Intel ein. [...]

    Besonders brenzlig werden könnte das Problem zumindest theoretisch in Server-Chips, auf denen sich die Wege vieler Daten kreuzen."


    Quelle: Handelsblatt: http://www.handelsblatt.com/te…betroffen/20811890-2.html


    Müssen wir jetzt CPU Benchmarks machen?

  • Guten Tag,


    wir geben jeden Gast 300 Sekunden Zeit für einen ACPI Reboot, bevor resettet wird.


    Zitat

    Wie es scheint bekommen "die Großen" mehr Infos zu dieser Lücke kommuniziert. Ist das dann ein Linux / vmware / netapp / etc Patch? Von diesem wird es wohl noch einige verbesserte Versionen geben, so daß es es weitere reboots geben wird.


    Wir haben unterschiedliche Systeme. Da so gut wie alle Systeme davon betroffen sind werden alle Kernel und CPU-Microcodes geupdatet werden.

    Zitat

    Eine Frage meinerseits währe noch:

    Sie schließen damit die Lücke "nur" auf Ihrer eigenen Seite, also auf Ihrem Node/root/Hardware nehme ich an? Wer einen normalen vServer besitzt muss sich selbst noch Kernel-Patches kümmern, da die Lücke weiterhin auf der eigene Verwaltungsebene ausgenutzt werden kann.


    Es ist noch nicht erwiesen ob durch das Update auf dem Wirt automatisch alle Gäste sicher sind. Prinzipiell ist es sicherlich ratsam das Sie auch alle Kernelupdates auf einem Gast einspielen die es gibt.


    Mit freundlichen Grüßen


    Felix Preuß

  • Guten Tag,

    ich habe bisher nur gesehen das die Systeme in den nächsten 72 Stunden restarten sollten. Gibt es für die Nutzer eines Server einer Warnung kurz vor den Restart? Also eine Art Brodcast welcher bescheid gibt dass das System in der Nächsten Minute restarten wird? Da dies für mich Sehr wichtig währe kurz vor des Restarts bescheid zu wissen.

    Mit freundlichen Grüßen

  • wir geben jeden Gast 300 Sekunden Zeit für einen ACPI Reboot, bevor resettet wird.

    In diesem Fall entschuldige ich mich für die eingeworfene Fehlinformation. Jetzt da ich von Ihnen die Zahl 300 lese: Kann es sein, dass in dem Benarichtigungstext, welchen man per Mail erhält wenn eine Inode von Ihnen neu gestartet wird, ein Tippfehler ist? Ich meine mich nämlich daran zu erinnern, in diesen Mails in der Vergangenheit etwas von 30 Sekunden gelesen zu haben.

    Ich möchte natürlich nicht abstreiten, dass der Fehler auch bei mir liegen kann. Evt. habe ich mich da einfach verlesen. 300 Sekunden bzw. 5 Minuten machen aber in jedem Fall mehr Sinn.



    Es ist noch nicht erwiesen ob durch das Update auf dem Wirt automatisch alle Gäste sicher sind. Prinzipiell ist es sicherlich ratsam das Sie auch alle Kernelupdates auf einem Gast einspielen die es gibt.

    Interessant wäre für mich hierbei gewesen, ob es sich um einen Firmware-Patch auf Ihrer CPU handelt, oder um ein Software-Patch Ihres Wirt-Betriebssystems.

    Ein Reminder an die Updatefaulen, dass sie immder den aktuelles Kernel ihres System nutzen sollten, ist aber natürlich nie falsch!

  • Guten Tag,

    ich habe bisher nur gesehen das die Systeme in den nächsten 72 Stunden restarten sollten. Gibt es für die Nutzer eines Server einer Warnung kurz vor den Restart? Also eine Art Brodcast welcher bescheid gibt dass das System in der Nächsten Minute restarten wird? Da dies für mich Sehr wichtig währe kurz vor des Restarts bescheid zu wissen.

    Mit freundlichen Grüßen


    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 ;)