News CrowdStrike: Update legt PCs & Server weltweit lahm, Workarounds helfen

[blackiwid]

Ich muss schon mal sagen, das in den ersten 15 Seiten glaub 1x Linux erwähnt wurde vielleicht 2x, also praktisch gar nicht, viele haben darauf verzichtet den 11er zu verwandeln auch wenn umgekehrt die Häme bei dem SSH Sicherheitsloch schon ein bisschen größer.

Was ich mal sagen will ist das zumindest es ungut ist das es bei Windows mehr oder weniger nur 1 Produkt gibt, ja es gibt auch irgend ne Server Version oder so es ist nicht wirklich nur 1 einziges Windows in dem Sinn, aber die Vielfalt ist kleiner, oft wird das als Problem von Linux an gesehen, aber es ist ne Stärke, warum weil man Maßgeschneiderte Lösungen für das ganz spezifische Problem sich raus suchen kann und das benutzen, natürlich bedeutet mehr Vielfalt auch das nicht alles auf einmal aus fällt, das macht man sich bei Flugzeugen ja auch zu nutze in dem man oft mehrere Systeme gleichzeitig laufen lässt so das wenn eins ausfällt nicht gleich der Flieger ab stürzt.

Natürlich macht das auch kosten, es fallen gewisse skalierungs und synergy Effekte aus, und man muss mehr wissen im Betrieb haben wenn nicht alle das selbe nutzen, aber ich halte das immer noch besser spezielle Software zu benutzten für einen Zweck anstatt eine Art Eierlegende Wollmilchsau für alles zu benutzen und obendrauf noch von ner weiteren Firma Software installieren um diese für einen Zweck hin zu biegen, logischerweise bedeutet dieser Ansatz mehr Code und bei gleicher Fehlerdichte logischerweise dann auch mehr Fehler.

Und ja dann hat man für viele Sachen eben auch Enterprise Sachen wo eben auch nur Sicherheitsupdates kommen, das Argument das ohne ständig updates man ja gehackt würde ist daher auch weitgehend widerlegt, man muss nur sicherheitsupdates von den grösseren häufigeren normalen Updates trennen und schon reduziert sich das Problem stark.

Zu guter letzt verderben mehr Köche den Brei das mag sich bei Opensource komisch anhören, aber es gibt in jeder Linux Distro einen oder ein paar Chefköche, die sagen wo es hin geht, das zwischen verschiedenen firmen zu koordinieren in live updates ist ne katastrophe, das kann nur schief gehen.

Was ich wirklich für ein Unding an sehe und um mal die Anti Linux Werbung von MS auf zu greifen wo mutierte Pinuguine zeigte, besser mutierte Pinguine mit Geweien als zu viel Inzucht was wir wohl hier haben...

Unter Linux weiß man genau es gibt Distros die sind zum einbutteln und Atomkrieg überleben und welche die sind cutting oder gar bleeding edge, bei Windows gibts standardmässig nur 1 level das mag relativ konservativ sein, aber eben nicht dieses Einbuttel-level.

Ich halte es quasi für ausgeschlossen das ein Debian Server oder selbst Desktop / Workstation plötzlich nach nem Update mit nem Bluescreen nimmer bootet, speziell wenn man nicht irgendwie Nvidia Hardware verwendet.

Man kann immer sagen, aber Linux ist auch nicht perfekt usw, aber sorry sowas kann mit einem Debian nicht passieren, zugegeben Crowdstrike ist nicht windows, aber wieso kommt man überhaupt auf die Idee von diesen Leuten die Strafvereitelung von Hillary Clinton gemacht haben solche Services ein zu kaufen.

Für IT Personal wird in den meisten Firmen nur Peanuts ausgegeben aber für solch einen totalen Schwachsinn dann Unsummen eine Firma die angeblich sich um Cloud kümmert also remote server aber irgendwie trotz dieser Behauptung so viel Macht über lokale Rechner kriegt das die diese kaputt (das OS) machen kann... ist schon wild.

Wieso nicht direkt der NSA Geld geben das sie für die eigene "Sicherheit" sorgen.

 

[fdsonne]

Bei uns schimpft sich das Release Management. Mit der Unterscheidung zwischen Standard Usern und Key Usern sowie der Organisation in Testringen können wir die Risiken etwaiger Rollouts von Patches, Fixes und sonstiges Releases in verschiedenen Dunstkreisen testen, bevor das große Rollout stattfindet.

Natürlich, nur ging es hier nicht um ein Major Software Update, wo sowas durchaus funktioniert, zumindest in gewisser Größe von Unternehmen und IT sondern um eine Art Pattern Update. Da kommst du auch mit dem Standard oder Keyuser nicht weit, zudem das kein Enduser System only Problem war, sondern beim Sicherheitssystem ansetzt. Der Standard- oder Keyuser hat auf dem Server im Zweifel nix verloren. Je nach Schutzbedarf aber müssen die Systeme vor Angriffen geschützt werden, Crowdstrike setzt hier am Endsystem an und wie bei vielen Nextgen. Sicherheitslösungen wird nicht nur auf Dateien gescannt sondern auf Verhalten bzw. im Traffic analysiert.

Das ergibt nur in Kombination mit möglichst schnellem verteilen der Infos Sinn, auf die untersucht werden soll. Was bringt die Differenzierung am User wenn die Ransomware durchs Backend kriecht weil es nicht schnell genug freigegeben wird? Und ja, hier wäre es vielleicht aufgefallen, weil es effektiv alle Systeme lahm gelegt hat, wo das File drauf gelandet ist. Aber schon der Fall, wo nur in bestimmten Situatione oder unter bestimmten Bedingungen etwas eintritt, ist derlei aufgrund der Häufigkeit dieser Kontentupdates weitestgehend unmöglich vorab zu evaluieren.

Wenn ein kleiner Fix an einer zentralen Komponente dazu führt, dass eine geschäftskritische Anwendung und damit der halbe Betrieb lahmgelegt wird, was zur Folge hat, dass kostspielige Sonderschichten an Wochenenden geschoben und Vertragsstrafen gezahlt werden müssen, weil eine zentralisierte Infrastruktur einfach anfälliger ist, dann ist das Release Management meiner Meinung nach die einzig sinnvolle Lösung, wenn der Hersteller in seinem Qualitätsmanagement teilweise versagt oder dieses schlichtweg nicht existiert.

Stimmt, in der Prozessdenke ist das so. Aber mit Prozessen allein kommst du nicht ans Ziel.

Wie erwähnt, man kann viel machen, das von dir beschriebene Verhalten auf bspw. Patternupdates angewendet, bedeutet im Umkehrschluss ein sehr hoher Aufwand in der extrem kurzen Zeit zwischen diesen alle erdenklichen Szenarien durchzutesten. Ob man sich das als Unternehmen leisten kann oder will, ist ne andere Frage.
Zufällig kenne ich auch den Ansatz in höchster Form des sogenannten zerprozessierens auch zur Genüge. Meiner Ansicht nach funktionieren Prozesse in Sachen IT Security nur Hand in Hand mit praktischer Umsatzbarkeit. Ne Theoriebetrachtung bringt nichts und führt auch zu nix. Eher im Gegenteil, es sorgt sogar negative Auswirkungen, nämlich weil Ressourcen und Personal gebunden werden.

Die Netzwerksegmentierung ist nur ein kleiner Teil eines ganzen Maßnahmenpaketes. Es ist tatsächlich auch so, dass gewisse Unternehmensbereiche nicht direkt miteinander kommunizieren können. Da kommen dann schon mal nette Anfragen an, ob man den Client für bestimmte Netze freischalten könne, damit man nicht in Bereich B latschen muss, um dort einen Zugriff auf die Maschinensteuerung vorzunehmen. Wird halt konsequent abgelehnt..., aber erst, nachdem die Firma schmerzlich lernen musste.

Aber was spielt das hier für eine Rolle?
Das Channel File kam aus der Cloud, vom Anbieter, ALLE Agents haben das File erhalten, man kann in aller Regel Agent Versionen bzw. allgemein die Software in Teilen wie du beschreibst, über Prozesse gestaffelt ausrollern, aber der Datenbestand auf den diese Lösung zugreift, wird eben normal nicht manuell verteilt, sondern zentral vom Hersteller freigegeben.

Streiten kann man sich darüber, ob das gut ist. Faktisch sind die Vorteile wie bspw. quasi Echtzeitverteilung perse nicht von der Hand zu weisen.
Die wie früher, quasi Turnschuh-Admin Bedingungen, als man mit der Diskette von Rechner zu Rechner gelaufen ist, lässt sich mit ner händischen Push Maßnahme zwar etwas verschnellern, aber es bleibt ein manueller Eingriff. Das ist der Sinn hinter der Echtzeitverteilung, eben nicht diese Wartezeiten zu haben. Das Produkt wäre sozusagen das falsche, wenn man das nicht haben möchte.

"Bezahlbar" ist tatsächlich ein wunderschönes Buzzword in Diskussionen. Wie oft hat die Abteilungsleitung die Vorschläge damit abgewehrt... Wie oft hat die Geschäftsführung gesagt: "Nö, machen wir nicht. Wir brauchen bezahlbare Lösungen.".

Ich seh es pragmatischer, wenn die eigene Lösung durch hohen Personalaufwand so teuer am Markt ist, dass die Mitbewerber das rennen machen (die im Zweifel exakt an dieser Personalstelle eben sparen) - was machst du dann?

Da du ja auch scheinbar in der Prozesswelt ebenso bewandert bist, hier sind wir am Ende einfach nur in der Risikobetrachtung. Es gibt keinen Indikator von IT Sicherheit in der Form, dass es irgendwo vergleichbar wäre. Am Ende trägt das Unternehmen das Risiko, ggf. mit Versicherungen in der Hinterhand oder stellt den Betrieb eben ein, weil unrentabel. Das Ding ist eben, mit Moral kommst du nicht an Kunden.

Hier und da bisschen Support, aber mal da und dort um die Ecke denken? "Sorry, keine Zeit.".

Da sind wir aber doch schon beim Punkt der Bezahlbarkeit. Jeder Dienstleister wird dir das auch geben was du willst, wenn es entsprechend honoriert wird. Die Frage ist, wer zahlt die Rechnung? Von Luft und Liebe und um die Ecke Denken, kann kein Unternehmen überleben...

"Das war unvorhersehbar."
"Damit konnte niemand rechnen."
"Ein solches Ausmaß war nicht absehbar.".

Wie gesagt, ich denke wir sind da auf dem gleichen Gedanken unterwegs. Damit konnte Niemand rechnen ist auch nur ein Resultat aus dem vorher nicht durchgeführten Test oder eben etwas vollends zu durchdenken.
Problem dabei ist nur, du wirst auf Probleme häufig erst schließen wenn sie sich zeigen. Wäre es so einfach das anders zu machen, gäbe es quasi keine Bugs oder Sicherheitsprobleme in Software. Zumindest keine die auf Fehler im Code zurückzuführen sind, weil Niemand Fehler macht und an alles immer gedacht wird. Ein Ding der Unmöglickeit wenn der Faktor Mensch dabei inkludiert ist. Vielleicht erreichen wir sowas in ferner Zukunft in einer Matrix-like Welt, wo KI sich selbst trainiert und damit Code letzendlich quasi bis zu Ende durchoptimiert werden könnte, da die KI sozusagen fehlerfrei Programmieren kann. Da sind wir aber lange nicht.

In der Zwischenzeit wird man testen was man testen kann bzw. woran man denkt zu testen, aber es reicht exakt eine einzige Sache, die man vorher nicht gesehen hat, bewusst oder unbewusst und der ganze Test war wertlos, weil der Betrieb steht. Im Nachgang zu sagen, aber das hätte man wissen müssen ist einfach, vor allem mit dem Wissen um das Problem, hilft aber Rückblickend leider auch Niemanden...

 

[Wechhe]

Also wenn jemand die verschlossene Tür deiner Firma knackt und einbricht dann ist nicht der Einbrecher schuld, sondern du, weil du kein Vorhängeschloss und keinen Zaun mit Stacheldraut drumherum gebaut hast? Seltsame Logik. Der Fehler war in der Software von crowdstrike, natürlich sind sie die Verursacher, nicht die Firmen, die das einsetzen. Hetze braucht es aber generell nicht.

Unternehmen, die kritische Infrastruktur bereitstellen, sollten ihre Systeme entsprechend absichern um die Risiken und die Auswirkungen von Ausfällen gering zu halten.
Baut man sich also eine Infrastruktur (oder kauft die ein als Service), dann sollte man das entsprechend beachten.
Hier hat ein scheinbar kleiner Fehler eines Updates dazu geführt, dass Server und Clients einfach ausgehen und sich nicht mehr starten lassen.
Klar ist die Ursache bei Crowdstrike - aber warum kann so eine Kleinigkeit seitens Crowdstrike so eine große Auswirkung haben? Warum ist die Architektur der Windows Geräte so anfällig? Und so weiter.

Stellt ein Unternehmen ein Dienst bereit, welcher kritisch für die Gesellschaft ist, dann müssen die auch sicherstellen, dass es funktioniert. Die Schuld einfach auf Dienstanbieter dahinter abzuwälzen, finde ich zu billig. Deswegen finde ich es zu einfach gedacht, einfach nur auf Crowdstrike herumzuhacken, wie es hier einige im Forum tun. Das Problem ist etwas komplizierter und sollte als ganzes betrachtet werden - indem wir eben die Unternehmen und am besten auch die Gesetzgebung mit rein nehmen.

 

[cansys]

[...] Was bringt die Differenzierung am User wenn die Ransomware durchs Backend kriecht weil es nicht schnell genug freigegeben wird? Und ja, hier wäre es vielleicht aufgefallen, weil es effektiv alle Systeme lahm gelegt hat, wo das File drauf gelandet ist. Aber schon der Fall, wo nur in bestimmten Situatione oder unter bestimmten Bedingungen etwas eintritt, ist derlei aufgrund der Häufigkeit dieser Kontentupdates weitestgehend unmöglich vorab zu evaluieren.

Genau deswegen macht man eine Business-Impact-Analye (BIA) von allen Prozessen, die in einem Unternehmen so existieren. Das ist Bestandteil des Notfallmanagements. Setzt natürlich voraus, dass man seine Prozesse kennt und dokumentiert hat. Da fängt aber in vielen Unternehmen schon das grundsätzliche Problem an: "Das ist historisch so gewachsen." oder "Das war schon immer so."

Wir haben allein in diesem Jahr schon 47 fehlerbehaftete Fixes für die Datenbank des ERP-Systems vom Hersteller abgefangen, weil ich letztes Jahr den Impact auf "HOCH" gesetzt habe. Das kaufmännische Risikomanagement hatte ihn als "GERING" klassifiziert.

Der Rest ist Qualitätsmanagement (QM) in Verantwortung des Herstellers. Das kannst du als Kunde nur bedingt beeinflussen. Unsere neue Telefonanlage, die wir gerade einführen möchten, hat im Probebetrieb ein miserables Zeugnis bekommen, weil sich hinterher Probleme offenbarten, die in der Risikobewertung innerhalb des Projektmanagements nicht mal betrachtet wurden. Da stellte sich beispielsweise heraus, dass der Anbieter nur wenige Entwickler hat, wir als Unternehmen aber schlichtweg zu groß sind. Der IT-Abteilung lag bis zur Risikoüberprüfung kein Handbuch vor; es gibt schlichtweg keins, sondern nur eine Art "Technische Dokumentation", wo der Hersteller sein System so beschrieben hat, wie es sich über die Jahrzehnte hinweg entwickelt hat. Da hast du Seitensprünge, dass ist unglaublich...

Der Anbieter war aber halt "günstig". Ergo: Wieder beim Abteilungsleiter antanzen, wieder gegenüber der Geschäftsführung argumentieren. Am Ende wurde der PMO vor die Tür gesetzt und der Abteilungsleiter der IT angezählt, wegen "gravierender Fehler im Projektmanagement". Natürlich waren die Risiken wieder einmal "nicht vorhersehbar". Schon jetzt sind alle Planwerte nicht mehr erreichbar. Und huch, die Kosten explodieren...

Stimmt, in der Prozessdenke ist das so. Aber mit Prozessen allein kommst du nicht ans Ziel.

Ich bin auch ein großer Fan der praktischen Arbeit, aber ohne Theorie geht es eben auch nicht, wenn du Risiken eingrenzen möchtest. Und dazu brauchst du nun mal Prozessverständnis.

[...] Meiner Ansicht nach funktionieren Prozesse in Sachen IT Security nur Hand in Hand mit praktischer Umsatzbarkeit. Ne Theoriebetrachtung bringt nichts und führt auch zu nix. Eher im Gegenteil, es sorgt sogar negative Auswirkungen, nämlich weil Ressourcen und Personal gebunden werden.

Was ist denn für dich "praktische Umsetzbarkeit"? Etwa das Ignorieren von Best Practices, weil "zu aufwendig" oder "zu teuer"?

Aber was spielt das hier für eine Rolle?
Das Channel File kam aus der Cloud, vom Anbieter, ALLE Agents haben das File erhalten, man kann in aller Regel Agent Versionen bzw. allgemein die Software in Teilen wie du beschreibst, über Prozesse gestaffelt ausrollern, aber der Datenbestand auf den diese Lösung zugreift, wird eben normal nicht manuell verteilt, sondern zentral vom Hersteller freigegeben.

Wenn du die Hoheit über deine Systeme abgibst, wozu brauchst du dann noch eine eigene IT-Abteilung? Dann kannst du auf "MDR" setzen und Dritte in deiner Infrastruktur werkeln lassen. "Spart Geld und schont Ressourcen", habe ich gehört.

[...] Das Produkt wäre sozusagen das falsche, wenn man das nicht haben möchte.

Nichts für ungut, aber das EDR oder XDR ist nur ein Baustein in einem IT-Sicherheitskatalog, den man einsetzt.

Ich seh es pragmatischer, wenn die eigene Lösung durch hohen Personalaufwand so teuer am Markt ist, dass die Mitbewerber das rennen machen (die im Zweifel exakt an dieser Personalstelle eben sparen) - was machst du dann?

Ich gebe dir mal einen Preis: 150,00 EUR / h. Diesen Preis rufen neuerdings einige externe IT-Dienstleister für die Abwicklung des First-Level-Supports auf und das nur, weil die Kunden selbst nicht verstehen, dass sie ihre Belegschaft für gewisse Self-Services befähigen müssen, was sie deutlich günstiger käme.

Ja, es gibt IT-Services, die kann man bedenkenlos outsourcen, etwa das Druckergeschäft. Aber wie immer gilt, die Risiken müssen ebenso betrachtet werden. Der Imageschaden kann am Ende einen weitaus größeren finanziellen Schaden verursachen, als man glaubt.

[...] Am Ende trägt das Unternehmen das Risiko, ggf. mit Versicherungen in der Hinterhand oder stellt den Betrieb eben ein, weil unrentabel. Das Ding ist eben, mit Moral kommst du nicht an Kunden.

Wird Zeit für die seit Jahren geforderte Herstellerhaftung. Btw: Versicherungen für solche Risiken gibt es kaum noch. Selbst die hochgelobten "Cyberversicherungen" sind rückläufig bzw. du kriegst sie mittlerweile nicht mehr, weil die Risiken selbst für die Versicherer inzwischen unkalkulierbar sind. Überraschung!

Da sind wir aber doch schon beim Punkt der Bezahlbarkeit. Jeder Dienstleister wird dir das auch geben was du willst, wenn es entsprechend honoriert wird. Die Frage ist, wer zahlt die Rechnung? Von Luft und Liebe und um die Ecke Denken, kann kein Unternehmen überleben...

Bezahlbarkeit gewährleistet man, indem man seine eigenen Prozesse permanent hinterfragt und kontinuierlich weiterentwickelt. Continual improvement nennt man das beispielsweise im IT Service Management, was aber ein Prozess in Dauerschleife ist.

Dabei haben die IT-Abteilungen im Kern zwei simple Aufgaben:

1. Die Sicherstellung von einem möglichst störungsarmen (nicht störungsfreien) Betrieb.
2. Die Weiterentwicklung des Unternehmens mit bedarfsgerechten IT-Lösungen mitzugestalten.

Dabei empfehle ich einigen IT-Abteilungen erstmal bei sich selbst anzufangen, ansonsten bleiben sich die Bastelbuden treu.

[...] Ein Ding der Unmöglickeit wenn der Faktor Mensch dabei inkludiert ist.

Der Faktor Mensch spielt in allen Szenarien eine zentrale Rolle, wird aber allzu oft ignoriert. Natürlich kann man nicht alle Eventualitäten berücksichtigen. Deswegen geht es im Risikomanagement darum das Denkbare niederzuschreiben und nicht das, was man sich in der Phantasie zur Utopie zusammenspinnt, um ins Extreme abzuschweifen.

Im Katastrophenschutz sagte mal jemand zu mir: "Sollen wir dann mit 100 Meter hohen Flutwellen kalkulieren?". Klar, mit solchen Totschlagargumenten kann man Debatten auch ins Jenseits befördern.

Vielleicht erreichen wir sowas in ferner Zukunft in einer Matrix-like Welt, wo KI sich selbst trainiert und damit Code letzendlich quasi bis zu Ende durchoptimiert werden könnte, da die KI sozusagen fehlerfrei Programmieren kann. Da sind wir aber lange nicht.

Zu KI habe ich eine klare Meinung: Sie ist strunzdumm. Von "Intelligenz" will ich da nicht sprechen. Das ist aber ein anderes Thema.

Im Nachgang zu sagen, aber das hätte man wissen müssen ist einfach, vor allem mit dem Wissen um das Problem, hilft aber Rückblickend leider auch Niemanden...

Hätte, hätte, Fahrradkette. ___ Peer Steinbrück. 😎

 

[nscharrn]

Bei uns im Konzern (ebenfalls Kritis) gehts auch gut ab. Einfach eine volatile Landschaft. Wenn man sich bedenkt wie viel Testing (hoffentlich) vorher stattgefunden hat, ist das schon irre.

Die Kosten dürften brutal werden. Wer versichert eigentlich solche Unternehmen (Crowdstrike) gegen Forderungen der Kunden bei Eigenverschulden?

Keiner

 

[Miuwa]

N-2 sind genauso betroffen

Wieso eigentlich? Bzw. wird irgendwo für den Interessierten Laien öffentlich zugänglichen erklärt was bei Crowdstrike N-X genau bedeutet?

 

[ragan62]

Sicher sehr ärgerlich für die Betroffenen.
Desaströs für die Verantwortlichen.
Teuer für alle Beteiligten.

Klarer Fall von Murphy's Law.

 

[CyborgBeta]

Klarer Fall von Murphy's Law.

True ... Aber andererseits ... alles wird heißer gekocht als gegessen ... Ja, an einem Tag stand einiges still oder war außer Betrieb, aber es ist kein Weltuntergang, wenn ein paar Computer mal nicht hochfahren konnten ... Wirtschaftlicher Schaden: Ja, bestimmt ... aber Menschenleben sind letztlich wichtiger und zu Schaden kam in dieser Hinsicht keiner, das "Notfallmanagement" hat überwiegend funktioniert.

Ergänzung (20. Juli 2024)

Errare humanum est.

 

[rongador]

Hast Du überhaupt CrowdStrike auf deiner VM laufen?

Jepp, läuft darauf. Aber es ist nicht mein Rechner.

 

[Teckler]

Sind eigentlich alle Windows Rechner betroffen die das Update bekommen haben ?

 

[luckysh0t]

Gibt drei relevante Enterprise Distributionen – Red Hat, SUSE, Ubuntu. Ansonsten Flatpak für alle anderen. Ist nicht sooo schwer sich zu entscheiden.

Ja super, und am Ende hat man dann genau die drei Systeme in Menge X, weil jeder Softwarehersteller für seinen Favoriten entwickelt. Sofern es nativ ist.

 

[F1Freak]

Crowdstrike ist das Virus bzw. der Trojaner! Solange das die Firmen nicht kapieren, gibt es weiterhin Ausfälle wegen Cyberattacken und angeblich fehlerhaften Updates...

 

[Benji18]

Sind eigentlich alle Windows Rechner betroffen die das Update bekommen haben ?

Ja. Manche System laufen nach einigen Neustarts wieder und andere müssen über den Safe Mode händisch von diesem File befreit werden um wieder sauber zu booten.

 

[twx24]

Sind eigentlich alle Windows Rechner betroffen die das Update bekommen haben ?

Nein, offenbar nicht zu 100%, bei unsere Citrix-Umgebung haben es einige der identisch provisionierten Server mitsamt Usersessions überlebt, vielleicht aber auch nur, weil der Zugang zur Netz verloren gegangen ist, bevor das Update vorlag. In HA-Clustern scheint auch nicht alles gestorben zu sein, und bei den Clients wäre die Frage, wer im fraglichen Zeitraum nachts und früh morgens online war (Ausland weitgehend) Das aufzudrösseln wird etwas dauern.

 

[SSD960]

Auch in unserer Firma geht nichts

Bist nicht der Admin. Oder? Zeigt jedenfalls dein Smiley 😵‍💫

 

[s1ave77]

Bin ja Windows-User (2x Desktop und 2x 'Server' alles lokal).

Wenn ich sowas lese, denke ich mir, hatte andere Gründe, meinen Home/Web-Server in einer Linux-VM zu haben. die direkt angebunden ist, nicht geteilt via Win-Host.

 

[bunghole]

Weiß jemand wann der BSOD ausgelöst wird? Habe meinen Rechner am Donnerstag angeschaltet gelassen und bin erst Dienstag wieder im Büro.
Werde ich noch ein funktionierendes System vorfinden, oder muss ich mit dem schlimmsten rechnen?

 

[twx24]

Ja. Manche System laufen nach einigen Neustarts wieder und andere müssen über den Safe Mode händisch von diesem File befreit werden um wieder sauber zu booten.

Richtig, auch die betroffenen Systeme verhalten sich unverschiedlich, einige kommen nach 1 BSOD wieder hoch, andere brauchen 5 - 15 Powercycles und einige müssen leider im Safe Mode repariert oder vom Backup geholt werden (was eben sinnvoller ist). Unklar ist mir, ob 100% der im Prinzip anfälligen Systeme auch den ersten BSOD erlitten haben, oder nur (hier hohe Prozentzahl einsetzen) davon, da der Zeitraum mit dem faulty Update relativ kurz war, kann ich mir vorstellen, dass ein 24/7 System, mit dem defekten File an Bord noch so lange weitergelaufen ist, bis es die gefixte Version einige Minuten später runterlud, sonst aber auch später gecrasht wäre.

 

[flaphoschi]

MS-Salesdroiden direkt an den CFO oder gleich CEO gehen und die dann deren IT dann vor vollendete Tatsachen stellen.

Ich habe mal die Hauptprobleme markiert.

Ich beneide Dich da sehr wohl.
Da wo Du bist, würde ich auch gerne leben.

Musst Du nicht.

Das Problem ist, selbst wenn ganze Abteilungen mit Linux und MacOS arbeiten muss man oft Schnittstellen zu der Microsoftlandschaft halten. Aus Erfahrung größtmögliche Distanz waren. Am besten komplett entkoppeln, eigenes Netz und Dienste.

Wenn deren Kram hochgeht hat man trotzdem ein Problem. Als Mitarbeiter oder Kunde. Reicht ja wenn E-Mails nicht gehen.

Die komplette Abkopplung ist grundsätzlich wichtig. Nichts ist perfekt und der nächste Sicherheitsvorfall kommt sowieso. Im Idealfall macht es im Nachbarbüro Boom und man bedauert die Kollegen - aber es bleibt hoffentlich ein lokales Problem. Weil man nichts direkt verbunden hat?

 

[Simanova]

Weiß jemand wann der BSOD ausgelöst wird? Habe meinen Rechner am Donnerstag angeschaltet gelassen und bin erst Dienstag wieder im Büro.
Werde ich noch ein funktionierendes System vorfinden, oder muss ich mit dem schlimmsten rechnen?

Der BSOD wird direkt nach dem Update ausgelöst, wenn der Treiber in den Kernel geladen wird. Da Crowdstrike bereits einen Fix bereitgestellt hat, dürften Geräte die nach dem 19.07 10 Uhr angeschaltet werden, sicher sein.

Ergänzung (20. Juli 2024)

Sind eigentlich alle Windows Rechner betroffen die das Update bekommen haben ?

Ja, jeder Windows 10/11 Rechner der am 19.07 zwischen 8 und 10 Uhr online war, und das Hostsensor Update bekommen hat. Ob Serversysteme betroffen war, entzieht sich meiner Kenntnis.

Ergänzung (20. Juli 2024)

***

Es gibt Hinweise darauf, dass ein ungültiger Null Pointer Reference die Ursache gewesen sein könnte
https://x.com/Perpetualmaniac/status/1814376668095754753

Spoiler: Null pointer reference, Quelle siehe Link

Erklärt nur nicht, warum das nicht aufgefallen ist - und warum exakt dieser Bug in den production branch gewandert ist.