Rollback-Strategie (war: Feeling Burioni)
Der Shitstorm über die Arbeit von Microsoft/CrowdStrike/Whoever geht weiter und ich bekomme von verschiedenen Leuten unterschiedliche Informationen mit unterschiedlicher Bedeutung. Ich weiß nicht, ob diese Informationsstreuung überhaupt beabsichtigt sein könnte – aus Gründen der Schadensbegrenzung – oder ob sie Teile der Realität enthalten könnte. Nehmen wir uns einen Moment Zeit, um einige der kompetenteren – oder weniger bizarren – Dinge zu untersuchen, die ich von Leuten gehört habe, von denen ich weiß, dass sie kompetent sind.
1. Rollback-Strategie
Jeder, der an Unternehmenssystemen gearbeitet hat, wird feststellen, dass er etwas an einem Produktionssystem aktualisiert. Sie werden bemerkt haben, dass Sie, egal welchen Prozess Sie verfolgen (das ITIL CAB oder das „Go/NoGo-Meeting“ oder was auch immer Sie tun), immer noch etwas besprechen: die Rollback-Strategie.
Auch das kann man viele Dinge nennen, aber die Frage dahinter ist: Da Murphy nicht aufzuhalten ist, was machen wir, wenn er hier durchkommt und das Upgrade fehlschlägt? Gute Frage.
Je nachdem, wie das System funktioniert, gibt es viele Antworten. In jüngster Zeit arbeiten fast alle Orchestratoren, von denen der Cloud bis hin zu solchen wie Kubernetes und anderen, mit dem Konzept des „Artefakts“: Dies bedeutet, dass die Durchführung eines Upgrades den Wechsel von der xyZ-Version zu einer höheren, aber immer noch versionierten Version bedeutet . Das Artefakt ist ein erweiterbares Konzept, das auch auf eine VM oder deren Image hinweisen kann.
Und die Frage ist: „Wenn Xy10, wie bekommen wir Xy09 wieder online?“ An diesem Punkt denken wir, abhängig davon, ob das System deklarativ ist oder nicht, einfach darüber nach, die alte gespeicherte Version zu nehmen und alles wieder in den Zustand zu versetzen, in dem es funktionierte. Reicht es immer? Also . Nein: Wenn es irgendwo zum Beispiel eine Datenbank gäbe, die sich gerade beim Starten der neuen Version geändert hat, und die Programmierer ziemlich dumm sind, könnte es auch solche Probleme geben.
Im Allgemeinen können Rollback-Strategien komplex werden und einen Dump der wiederherzustellenden Daten, einen Snapshot usw. umfassen. Bis hin zur umfangreichsten Version, die eine Disaster-Recovery-Umgebung beinhaltet, also eine Kopie von allem, absolut allem, von dem aus eine funktionierende Situation wiederhergestellt werden kann.
Aber wenn man es auf „Devops“-Art machen möchte, weiß der Orchestrator normalerweise selbst, wie man ein Rollback durchführt und das alte „Artefakt“ wieder in die Ausführung bringt.
Die Hauptaufgabe eines Einsatzteams besteht bei einem Chaos darin, den vorherigen Betriebszustand wiederherzustellen.
Bei einem Vorfall dieser Größenordnung führt Operations keine oder nur dann Untersuchungen durch, wenn dies unbedingt erforderlich ist. Es gibt ein SLA, das eingehalten werden muss, d. h. der Ausfall hat eine maximale vertragliche Dauer . Wenn Sie nicht sofort verstehen, was zum Teufel passiert, wird das vorherige System wiederhergestellt, die fehlerhaften Bilder werden gespeichert und wir sprechen von „Post-Mortem“. " Analyse.
Aber egal wie viele widersprüchliche Gerüchte ich höre, nichts davon scheint passiert zu sein. Wenn das, was gesagt wird, wahr ist, haben diese Updates ohne Rollback-Strategie eingefügt. Ist das wahr, was sie sagen? Und warum hat diese Praxis nicht das nötige Misstrauen erzeugt? Was sagten sie einander, als sie ihre CABs oder andere Besprechungen hatten, um das Upgrade zu genehmigen, als sie die Rollback-Strategie besprachen? Wenn das, was sie sagen, wahr ist, haben sie offensichtlich etwas getan, was in einer Unternehmensumgebung definitiv keine gute Praxis ist, insbesondere wenn der Service geschäftskritisch ist.
Bisher ist, was auch immer ich gehört habe, nur klar, dass die Rollback-Strategie zeitaufwändig ist und manuell durchgeführt werden muss. Und es verursacht einen Ausfall, einen Mangel an Service.
2. „Mit Linux/*BSD wäre das nicht passiert
Äh. Die Antwort ist nein".
Nein, denn wenn es mir egal ist und ich mit den nötigen Privilegien Module kalt in den Kernel injiziere, kann ich sogar in einem UNIX-ähnlichen Betriebssystem einen schönen Kernel-Dump verursachen.
Und kann ich Code schreiben, der den Kernel in Panik versetzt? Natürlich ja'. Unter den Bedingungen, unter denen CrowdStrike operiert, d. h. mit völliger Vertrauenswürdigkeit und der Möglichkeit, Teile des Betriebssystems zur Laufzeit zu überschreiben, kann ich alles zum Absturz bringen.
Aber die Antwort ist auch ein bisschen „Nein“, in dem Sinne, dass diese Systeme Sie „einladen“, die Dinge richtig zu machen. Wenn ich das machen wollte, was CrowdStrike unter Linux macht, würde ich keine Zeit damit verschwenden, das Rad neu zu implementieren. Ich würde etwas verwenden, das bereits in Linux vorhanden ist, nämlich eBPF. Und da es sehr gut funktioniert und bereits Code geschrieben ist, werden viele Unternehmen es vorziehen, weniger Geld für Programmierer auszugeben, anstatt das Rad neu zu erfinden und eBPF zu verwenden. Dies ist bei vielen anderen Cybersicherheitsanbietern auf dem Markt der Fall.
BSDs haben auch ihr BPF. Um ehrlich zu sein, wurde das ursprüngliche BPF aus einem BSD-Unix geboren, aber das Linux-BPF ist völlig anders.
Reicht das also? Löst eBPF alles? Das nutzen und den Mund halten? Äh. Es ist wahr, dass die Verwendung eines JIT-Compilers, eBPF, einige vorläufige Prüfungen erfordert, und da es auch Trace-Tools im Userland bietet, „lädt es uns ein, das Rad nicht neu zu erfinden und diese zu verwenden.“ Sehr gut.
ABER reden wir andererseits über XDG? Die Möglichkeit, Codeteile in C, einer nicht sehr sicheren Sprache, zu schreiben und sie auf derselben Ebene wie der Treiber, also dem Kernel, einzuschleusen, birgt das Risiko, dass alles ein wenig kaputt geht.
Also: Wäre das nicht mit Linux/*BSD passiert? Die Antwort lautet: „Es kommt darauf an“. Ich kann mir vorstellen, dass es weniger passiert, weil es sich um Systeme handelt, die bereits Trace- und Ktrace-Tools enthalten und daher Unternehmen „einladen“, Geld zu sparen und diese zu verwenden.
Kurz gesagt, ich würde nicht viel mehr expandieren.
3. ABER was zum Teufel haben sie am Ende gespritzt?
Hier höre ich alles. Von Dateien „voller Nullen“ über „beschädigte Dateien“ bis hin zu „Dateien voller Zufallsbits“. Nun gibt es Prüfsummen schon seit 40 Jahren und ich verstehe wirklich nicht, wie man einen Effekt wie „Meine Datei wurde beim Herunterladen beschädigt“ erzielen kann. Auch digitale Signaturen und ausführbare Formate: Es scheint unwahrscheinlich, dass dies passiert ist. Es scheint eher eine Erklärung zu sein, die Aranzulla erreichen kann, aber auf einem modernen System ist es unwahrscheinlich, dass dies geschieht. Wenn das, was Sie hören, wahr ist.
Auch das Konzept der „bedeutungslosen Teile“ verwirrt mich. Ich habe an Juniper-Appliances gearbeitet, bei denen Sie (wie bei XDG) bestimmte Hardwarekarten so programmieren können, dass sie den Datenverkehr abhören und nach Mustern suchen. Wenn Sie sich diese Binärteile ansehen, scheinen sie möglicherweise bedeutungslose Sequenzen zu sein. In einigen wissenschaftlichen Anwendungen werden auch Zufallsdaten geladen, also Zufallszahlen, die von Unternehmen verkauft werden, die ihren Lebensunterhalt mit dem Verkauf WIRKLICH Zufallszahlen verdienen.
Es ist schwer zu verstehen, was mit „Zufallszahlen“ gemeint ist, und da jeder vom Hörensagen spricht, wäre ich sehr geneigt, zu zweifeln.
Wie gesagt, alles ist in der Schwebe. Das einzig Sichere ist, dass jemand etwas aktualisiert hat und keine Rollback-Strategie hatte.
Bisher ist das das Einzige, was sicher ist.
Uriel Fanelli
Der Blog ist von Fediverso aus wie folgt sichtbar:
Kontakte:
- Fediverse: @ uriel@fedi.keinpfusch.net
- MATRIX: @uriel:mtrx.keinpfusch.net
- GNU JAMI: Ufanelli