Absicherung gegen Spectre-NG: "Foreshadow"

  • Vielen Dank für Ihre vielen Argumente. Diese kann ich ich zum Teil auch gut nachvollziehen.


    Im Normalfall spielen wir Updates mit mindestens 7 Tage Vorankündigung Nachts ein.


    Sicherheitskritische Updates spielen wir so bald wie möglich ein. Dabei müssen wir abwägen, wann dieser Zeitpunkt ist und wie viel vorher wir ihn ankündigen können.


    In dem hier konkreten Fall müssen mehr als 40.000 VMs neu gestartet werden. Dabei berücksichtigen wir, dass VMs der gleichen Generation nicht parallel neu gestartet werden, um HA-Cluster nicht zu gefährden. Zudem mussten wir sicher stellen, dass die aktuellen Updates wirklich funktionieren. Wenn wir uns anschauen wie lange am Kernel gearbeitet wurde, war es sicherlich gut, dass wir nicht das aller erste Update eingespielt haben. Hier haben wir von den Updates bzgl. Meltdown gelernt. Da wir nicht genau sagen können wie lange ein Reboot eine VM dauert, können wir ein Zeitfenster von ca. 2 Stunden angeben, in dem der Reboot stattfindet.


    Unsere VMs vertreiben wir zu einem extrem günstigen Preis. Vermutlich kann niemand anders auf der Welt VMs mit der von uns gebotenen Leistung zu solchen Preisen anbieten. Wenn ich dann lese das eine individuelle Abstimmung zu den Neustarts gewünscht wird, fühle ich unsere Produkte doch etwas missverstanden. Wie soll denn das gehen? Sollen wir in 10 Jahren mit den Neustarts fertig sein? Sollen wir 1000 Mitarbeiter einstellen von denen jeder 40 Neustarts plant und mit den Kunden bespricht?


    Es gibt Mitbewerber die betreuen auf Wunsch mit drei Mitarbeitern eine VM eines Kunden. Die Mitarbeiter fahren dann sogar auch auf Wunsch beim Kunden vorbei und planen derartige Neustarts nach den individuellen Bedürfnissen. Derartiges ist bei unseren kostengünstigen Produkten leider nicht möglich.


    Ich bitte darum diesen Beitrag für Fragen zu den eigentlichen Updates und Fragen dazu frei zu halten. Wir werden unseren hier vorgegebenen Prozess nicht ändern können.



    Mit freundlichen Grüßen


    Felix Preuß

  • Sicherheitskritische Updates spielen wir so bald wie möglich ein. Dabei müssen wir abwägen, wann dieser Zeitpunkt ist und wie viel vorher wir ihn ankündigen können.

    ...

    Wenn wir uns anschauen wie lange am Kernel gearbeitet wurde, war es sicherlich gut, dass wir nicht das aller erste Update eingespielt haben. Hier haben wir von den Updates bzgl. Meltdown gelernt.


    Diese zwei Sätze widersprechen sich doch deutlich ... wenn man einige Woche warten kann bis die Updates stabil laufen und man sie ausreichend getestet hat, dann kann man das Update auch 2 Werktage (anstatt 1 Werktag) vorher ankündigen. Der Neustart von über 40 000 VMs erfordert bestimmt auch mehrere Tage Vorbereitung und Planung und vielleicht hätte man die Kunden doch einen Tag früher informieren können.


    Dabei berücksichtigen wir, dass VMs der gleichen Generation nicht parallel neu gestartet werden, um HA-Cluster nicht zu gefährden.

    Um die 10 Minuten zwischen den Wartungsfenstern von VMs der gleichen Generation sind aber nicht wirklich ausreichend um die Funktion der neu gestarteten Node zu validieren und die Node wieder in den HA-Cluster einzuhängen. Wenn es 30-60 Minuten wären hätte ich auch gar nix gesagt, aber ungefähr 10 sind ein echtes Glücksspiel - das kann gehen oder aber auch nicht. Wenn es sich nicht ausgeht und der HA-Cluster fällt unter die kritische Anzahl von Nodes ist der HA-Cluster down und es bleibt nur ein Fail-Over auf die Notfall-Infrastruktur inkl. möglichem Datenverlust.


    Wir werden unseren hier vorgegebenen Prozess nicht ändern

    Ich verstehe durchaus, dass der Prozess für dieses Update nicht mehr geändert wird bzw. nicht mehr geändert werden kann. Aber da momentan vermehrt auf dem Gebiet geforscht wird war das bestimmt nicht die letzte Sicherheitslücke in Intel CPUs. Vielleicht kann man beim nächsten Update versuchen, dass der zeitliche Abstand zwischen VMs der gleichen Generation etwas länger ist um HA-Clustern die Möglichkeit zu geben die Node wieder einzuhängen und ein Rebalance zu machen.


    Von meiner Seite war es das aber jetzt auch dazu ... da es für das Update morgen ohnehin nichts mehr ändert ... war einfach eine kleine Anregung zur Planung von zukünftigen Updates.

  • Mein Server hier braucht, dank einiger Container, dann doch n paar Minuten für n Reboot, aber soweit habe ich das nun, dass der Reboot safe laufen sollte. Die aktive Informationspolitik seitens Netcup finde ich vorbildlich. Ich habe einen zweiten Server bei nem Mitbewerber, bei dem das Problem scheinbar nichteinmal bekannt ist. Wenn mein Server nun irgendwann mal 5 min off ist, dafür aber die Sicherheitslücken nicht mehr hat, ist mir das mehr als recht.

  • Die ersten beiden Reboots sind bei mir durch und verliefen problemlos und schnell. Das Monitoring hat den Ausfall noch nicht mal bemerkt.

    Alle Sicherheitslücken (Spectre Variant 1, 2, 3, 3a, 4, Foreshadow & Foreshadow-NG) sind geschlossen (G7 Server, CentOS 7).


    Gestestet mit spectre-meltdown-checker.sh (https://raw.githubusercontent.…ectre-meltdown-checker.sh)


    So gerne weiter, wegen mir dann auch während der Geschäftszeit. Daumen hoch!

  • Hay,


    ich bin gerade mit einem Server in diesem Zeitfenster bis 15:00 Uhr dran und habe manuell heruntergefahren - jetzt weiß ich allerdings nicht, wann ich "durch" bin und wieder starten kann. Einer eine Idee, woran stelle ich das feststelle? :D


    Kommando zurück - es ist jetzt offensichtlich geworden...


    pasted-from-clipboard.png


    CU, Peter

    Peter Kleemann // https://www.pkleemann.de // +49 621 1806222-0 // Kann Programme, Internet, Netzwerke und Telefon.

  • Wenn ich die Diskussion um den "Wunsch-Neustartzeitpunkt" hier verfolge, dann fällt mir hierzu ad-hoc ein Vorschlag ein.


    Netcup könnte im SCP in den Server-Einstellungen (z.B. da wo man sich auch das Autostart ein/auschalten kann) eine Konfigurationsmöglichkeit anbieten die etwa so aussehen könnte:


    Wunsch-Zeitpunkt für planbare Wartungsereignisse die einen System-Neustart zur Folge haben (z.B. Host-System Kernel Updates, ...):

    [x] 00:00 - 03:00 [ ] 12:00 - 15:00

    [x] 03:00 - 06:00 [ ] 15:00 - 18:00

    [x] 06:00 - 09:00 [ ] 18:00 - 21:00

    [x] 09:00 - 12:00 [x] 21:00 - 24:00


    Per Default ist alles angehakt. Diejenigen die einen Zeitpunkt bewusst aussparen möchten können die betreffenden Zeiten de-selektieren und sich so "wünschen" in dieser Zeit verschont zu werden. Je nach Dringlichkeit könnte Netcup das dann berücksichtigen. Leute die einen Cluster betreiben können sich so bewusst disjunkte-Zeitpläne einrichten mit ausreichend Zwischenraum.

  • Per Default ist alles angehakt. Diejenigen die einen Zeitpunkt bewusst aussparen möchten können die betreffenden Zeiten de-selektieren und sich so "wünschen" in dieser Zeit verschont zu werden. Je nach Dringlichkeit könnte Netcup das dann berücksichtigen. Leute die einen Cluster betreiben können sich so bewusst disjunkte-Zeitpläne einrichten mit ausreichend Zwischenraum.

    Das wäre natürlich perfekt und auch sehr ähnlich zu dem was Google bzw. Amazon anbieten wenn man bei Ihnen einen Datenbankserver betreibt - bei denen kann man auch auswählen in welchem (von einigen vorgegebenen Zeiträumen) ein Restart erfolgen kann. Bei einem Cluster sind die Zeiten selbstverständlich unterschiedlich gewählt.



    Nach der gestrigen Kritik auch von meiner Seite ein Lob an das Netcup-Team - die Server wurden 1 bis 3 Minuten nach Beginn des angekündigten Wartungsfensters ordnungsgemäß heruntergefahren und 28 bis 32 Minuten danach wieder neu gestartet. Die Sicherheitslücken wurden geschlossen und die Server laufen inzwischen wieder einwandfrei.


    @netcup-felix

    Wie im ersten Beitrag von dir erwähnt wird es ja einige Zeit in Anspruch nehmen bis alle Server aktualisiert wurden - wisst ihr bereits ob für die weiteren Server die Ankündigung ebenfalls so kurzfristig (1 Werktag) vorher rausgeht oder ob die Ankündigungen für diese Server etwas mehr Vorlaufzeit haben?


    PS: noch eine Anregung für die Zukunft - ideal wäre es natürlich wenn geplante Wartungsarbeiten auch im SCP beim jeweiligen Server angezeigt werden

  • Je nach Dringlichkeit könnte Netcup das dann berücksichtigen.

    egal wie dringend soetwas ist, müssen alle VMs einen gemeinsamen Slot haben, den sie nutzen können. Und das wird nicht überall zu schaffen sein.

    Nach der gestrigen Kritik auch von meiner Seite ein Lob an das Netcup-Team - die Server wurden 1 bis 3 Minuten nach Beginn des angekündigten Wartungsfensters ordnungsgemäß heruntergefahren und 28 bis 32 Minuten danach wieder neu gestartet. Die Sicherheitslücken wurden geschlossen und die Server laufen inzwischen wieder einwandfrei.

    Und warum dann vorher mit Kanonen auf Spatzen schießen? Ich verstehe nicht, warum man Systeme manuell aus einem Cluster nehmen muss und sie dann wieder manuell einhängen muss.

  • Tja, schön war anders.


    Etwas mehr Vorlaufzeit hätte ich mir schon gewünscht, von den betroffenen Kunden hatten nur etwa die Hälfte unsere Ankündigung bis dato mitbekommen. Und wir selbst konnten uns auch nicht so schnell umstellen (alle wesentlichen Leute im Urlaub, krank oder beim Kunden) - natürlich ist dann nicht alles einfach wieder gestartet und wir waren über 2h offline.
    Ich beantworte jetzt gerade noch die letzten Mails...


    (Ich in froh dass nur einer unserer Dedicated hier betroffen war)

  • Ich verstehe nicht, warum man Systeme manuell aus einem Cluster nehmen muss und sie dann wieder manuell einhängen muss.

    Weil ein Big-Data Datenbank Cluster drauf läuft und wenn ich die Server nich vorher rausnehme, dann muss ich während der Geschäftszeiten einen Re-Balance machen um die Integrität im Falle eines weiteren Server-Ausfalls sicher zu stellen (ja, auch während Wartungsarbeiten können andere Server ungeplant ausfallen) - Ein Rebalance zu Stoßzeiten hätte dann einen direkten Performance-Impact auf den laufenden Betrieb. Wenn ich die betroffenen Server aber in der Nacht davor manuell rausnehme und der Nacht darauf manuell wieder rein hänge, dann habe ich den Rebalance in der Nacht und nicht während der Stoßzeiten.


    Etwas mehr Vorlaufzeit hätte ich mir schon gewünscht, von den betroffenen Kunden hatten nur etwa die Hälfte unsere Ankündigung bis dato mitbekommen.

    War bei uns nicht anders und ich kann inzwischen auch bestätigen, dass die Vorlaufzeit für die weiteren Server genau so knapp ist - habe heute um ca. 18:25 (also nach Dienstschluss) einige E-Mails von Netcup bekommen, dass die restlichen Server am Freitag Vormittag dran sind. Das ist etwas was ich bei der Kommunikation nun wirklich nicht verstehe warum die Server die später dran kommen auch nur einen Werktag Vorlaufzeit haben - das kann man definitiv besser planen und kommunizieren. netcup - bitte in Zukunft (zumindest bei den Servern die nicht als erstes dran kommen) mehr Vorlaufzeit

  • Genau. Netcup wartet am besten 2 Monate bis ihr alle eure Kunden informiert habt. Und zwischendurch kommt wirklich der erste Exploit, weil die Systeme nicht umgehend gesichert wurden und dann ist das Geschrei groß. Manchen kann man es einfach nicht recht machen.

  • Mal was anderes: Wann immer jetzt eine Mail reinkommt, die über den anstehenden Reboot informiert, gehe ich ins SCP und schaue per Strg + F welcher Server betroffen ist, weil in der Mail nur der ~20 Zeichen lange Servername angegeben wird. Wäre es möglich, den im SCP gespeicherten Nickname mit in die Mail zu schreiben? Habe ich etwas Offensichtliches übersehen?


    (Und sorry falls etwas in der Art schon mal gesagt wurde. Ich komme in letzter Zeit nicht mehr ganz mit bei dem hohen Aufkommen an Posts hier im Forum ...)

    • Offizieller Beitrag

    Ich persönlich sehe bei so einer Lösung allerdings folgendes Problem:

    Man hat einen Node mit z.b. 10 Kunden mit jeweils einer VM. Jeder Kunde hat andere Zeiträume angekreuzt wodurch es dann quasi keine bzw nur sehr wenige Überschneidungen gibt. Im Support werden dann Beschwerden von 8 der 10 Kunden eintreffen, warum wir uns nicht an die ausgewählten Wartungsfenster vom Kunden halten. Die anderen beiden Kunden sind glücklich, da die die beiden waren deren Wunsch-Wartungsfenster genutzt wurde

    Solche Lösungen funktionieren einfach nicht sobald mehrere Kunden mit jeweils eigenen Präferenzen auf einem Hardwaresystem liegen.


    Im Prinzip ist es so als würde man ein Flugzeug ohne vorher definierten Bestimmungsort besteigen und dann im vollbesetzten Flugzeug abstimmen wo es denn hingeht. Eine Vielzahl der Passagiere wird unglücklich mit dem Ergebnis der Abstimmung sein.

  • Wenn ich die Diskussion um den "Wunsch-Neustartzeitpunkt" hier verfolge, dann fällt mir hierzu ad-hoc ein Vorschlag ein.


    Netcup könnte im SCP in den Server-Einstellungen (z.B. da wo man sich auch das Autostart ein/auschalten kann) eine Konfigurationsmöglichkeit anbieten die etwa so aussehen könnte:

    Die Idee finde ich super, wird für Netcup nur schwer umzusetzen sein, wenn zwei VMs auf der gleichen Hardware liegen und sich die Wunschzeiträume der beiden stark unterscheiden. Hier könnte aber eine Schnittmenge der Zeiträume über alle VMs einer Maschine gebildet werden und so eine Annäherung erfolgen. Eine exakte Darstellung wird aber wahrscheinlich unmöglich sein.