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

Benji18 schrieb:
das war ein Binary Update da wird MS nichts geprüft haben, weil der Treiber ansich nicht geändert wurde.
Ja, das ging bestimmt an der CI vorbei ... aber das sind nur Mutmaßungen von mir.
 
Autsch ... Wir haben auch von außen zugesehen.

Bei einem Kumpel, dessen Arbeitgeber auch Crowdstrike einsetzt hat der Scanner bei einem bestimmten Debian Kernel zur Kernelpanic geführt. Jetzt die Windows Sache. Läuft ja 👏
 
xexex schrieb:
Da sollten wir vielleicht den Unterschied zwischen "erhöhte Rechte" und "höchste Rechte" klären, höchste Rechte wäre ein Zugriff im Kernelmodus auf Systemfunktionen, die braucht ein "normaler" Virenscanner genauso wenig wie ein...
hast du schonmal versucht einen "wild gewordenen" Viren/Vulnerability Scanner vom System zu entfernen oder zu deaktivieren?

so ein Ding wehrt sich mit Händen und Füßen ;)

ich muss ganz ehrlich sagen, dass ich heute morgen extrem überrascht war, wie simpel sich das Problem hier beheben ließ (ok, wenn AD benötigt, um an Admin / BitLocker credentials zu kommen, die DC aber vom CrowdStrike lahmgelegt sind, dann hat man ein Huhn/Ei Problem :( )

wir brauchen jetzt nicht über Begrifflichkeiten wie Viren- , Vulnerabilty-Scanner, EDR usw. usf. diskutieren, bitte!
 
  • Gefällt mir
Reaktionen: CyborgBeta
Mickey Mouse schrieb:
hast du schonmal versucht einen "wild gewordenen" Viren/Vulnerability Scanner vom System zu entfernen oder zu deaktivieren?
Das eine hat mit dem anderen nicht zu tun, wenn ich mit einem Klick einen Virenscanner deaktivieren könnte, wäre es jedem anderen Nutzer oder Script ebenfalls möglich. Trotzdem liegt zwischen einem Kernelmodustreiber und und Systemrechten noch ein weiter Unterschied.
 
rongador schrieb:
Frage: Wenn man Hyper-V verwendet - dann kann man die VM doch bei einem laufenden "Windows Server" einfach über den Hyper V Manager neu starten und muss gar nicht den gesamten Windows Server (also den Rechner, vor dem man sitzt) neu starten - richtig?
Hat darauf vielleicht jemand eine Antwort parat?
 
CyborgBeta schrieb:
Ja, das ging bestimmt an der CI vorbei ... aber das sind nur Mutmaßungen von mir.
nachdem der Workaround das löschen dieses files war und nach dem korrekten Boot sofort eine neuere Version geladen wurde ist das durchaus die realistischer Variante.
 
  • Gefällt mir
Reaktionen: CyborgBeta
...
Benji18 schrieb:
bezweifle ich, MS kann für das fahrlässige Verhalten eines Drittherstellers eigentlich nix
Doch können sie.:D
Oder man baut den Kernel grundlegend um damit sowas nicht mehr passiert.

Bei so kritischer Drittherstellersoftware tief im Windows System sollte Microsoft höhere Anforderungen stellen oder diese bei den Windows Serverversionen bei dem geforderten Preis selbst anbieten.
 
bieten MS Ja auch selbst an, das nennt sich Windows Defender ATP
 
xexex schrieb:
Trotzdem liegt zwischen einem Kernelmodustreiber und und Systemrechten noch ein weiter Unterschied.
habe ich von Kernelmodus oder Systemrechten geredet? NEIN!
denke mal bitte darüber nach, wer die Diskussion in diese Richtung gelenkt hat (warum auch immer)
 
Bei uns Halbleiterkonzern, hatte es keinen impact.
Dafür hat es meine Freunde am Wiener Flughafen erwischt nach 6 Stunden ohne Infos wurde der Flug nach Palma gecancelt (Ryanair).

Ich finde es amüsant, da ich in der Zertifizierung und innere Revision bin und bei IT schon immer auf BCP (Business Continuity Plan) & RTO (Recovery Time Objective) und RPO (Recovery Point Objective) dazu natürlich SLAs mit den externen Provider (TCS, AWS, Azure und Co) hingewiesen und evaluiert habe.

Hat man immer leicht auf die Schulter genommen, wieder ein Beispiel was man nehmen kann wie es NICHT funktionieren soll.

Am besten wo einen Koffer mit gedruckter Anleitung, wenn man offline ist!

Ich glaub das hier SaaS auch mal wieder hinterfragt werden wird, das auch das nicht das Heilmittel schlechthin ist.

Bei kritischer Infrastruktur sollte halt nicht alles auf eine Karte gesetzt sein.

Möchte nicht in der Haut gewisser CrowdStrike Mitarbeiter oder Manager stecken, die nächsten Tage werden hart.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: dasBaum_CH
luckysh0t schrieb:
Gibt drei relevante Enterprise Distributionen – Red Hat, SUSE, Ubuntu. Ansonsten Flatpak für alle anderen. Ist nicht sooo schwer sich zu entscheiden.
 
rongador schrieb:
Frage: Wenn man Hyper-V verwendet - dann kann man die VM doch bei einem laufenden "Windows Server" einfach über den Hyper V Manager neu starten und muss gar nicht den gesamten Windows Server (also den Rechner, vor dem man sitzt) neu starten - richtig?

rongador schrieb:
Hat darauf vielleicht jemand eine Antwort parat?

VM-Neustart über den HV-Manager benötigt keinen Neustart des Host-Servers.
 
cansys schrieb:
Ich lasse es z. B. gar nicht erst zu, dass ein Update gleich an alle Systeme ausgerollt wird. Bei meinem Arbeitgeber haben wir vier Testringe eingerichtet. Im ersten sind unkritische Systeme, in zweiten Systeme mit mittlerem Risiko, im dritten folglich Systeme mit hohem Risiko und im letzten Ring Systeme, die in die KRITIS-Definition fallen. Alle Testringe haben unterschiedliche Zeiträume und in jedem gibt es einen kleinen Testpool, bevor der restliche Testring versorgt wird.
https://www.crowdstrike.com/blog/statement-on-falcon-content-update-for-windows-hosts/

Es handelt sich hier um Channel Files, laut der Ausführungen von 0409 UTC, keine 2h später wurde das Issue gefixt. Üblicherweise sind das eher Pakete vergleichbar mit Pattern Updates, die prüft man in aller Regel nicht in der Form einzeln wie du es für eine heile IT Welt mit genügend Mitteln idealerweise machen könnte, sondern die werden unbeaufsichtigt automatisch deployed. Das sind keine Pakete von Major Software Updates wie ganz prominent, der monatlichen Microsoft Patches, sondern da geht es im Fall von Crowdstrike Falcon um möglichst schnelles ausrollen der Daten an alle Systeme (die man ja zu diesem Zweck auch damit betankt hat)

Es ist reichlich sinnbefreit derartige Updates erst in X Phasen gestaffelt und dann noch pro Phase vorab in Gruppen getestet zu verteilen, bei der Häufigkeit im teilweise Stundentakt oder noch geringer kommst du aus dem Testen nicht mehr hinaus.

Die Konsequenz aus einem solchen Versagen der Sicherheitslösung ist die schwindende Reputation des Produktes bzw. des Herstellers. Das wird sich rumsprechen und es werden sich Kunden auch nach Alternativen umsehen.
Denn das ist zu Teilen eben etwas, was man eben nicht selbstständig testen und verhindern kann und man auf den Diensteanbieter angewiesen ist.
cansys schrieb:
Dazu gehört aber auch, dass die Infrastruktur anders organisiert wurde und wir mit VLAN und Co. arbeiten, was es sicherlich etwas aufwendiger, dafür aber robuster macht. So haben wir schon den einen oder anderen fehlerhaften Patch von Geschäftspartnern abfangen können, ohne so einen großen Impact zu haben.
Was haben VLANs jetzt damit zu tun?
Das klingt mir nach Buzzwordbingo. Das ist eine simple Segmentierung von Netzen, bringt dir exakt gar nix wenn die Systeme untereinander dennoch kommunizieren müssen.

Siehe oben, man kann vieles machen, auch praktisch aber der Aufwand und der Nutzen müssen im Verhältnis stehen und es muss bezahlbar sein.

Am Ende wird der KRITIS Ausfall mehr Impact haben als irgendwelche Testsysteme. Die Frage ist, ob man im Test alle möglichen Dinge auch bedacht hat.
Simples Beispiel, wenn du Windows Updates durch und durch vorevaluierst um sicherzustellen, dass der Patch am Livesystem auch wirklich funktioniert, dir aber ein Patternupdate, ein Hotpach oder bspw. sowas wie KIR das System zerlegt, ggf. auch weil sich zwischen Test und Livedeployment noch Revisionen ändern, die dann das Testergebnis beeinflussen, kann das schon zu einem Ding der Unmöglickeit werden. Weiterhin kommt noch die Unbekannte dazu, dass ein Testsystem selbst bei Bedacht darauf selten 100% dem Livesystem entspricht, einfach weil es teilweise utopischer Aufwand ist, alles zu 100% nachzubauen. Und auch das Thema, von wo nach wo und was und wie oft, patch man, ist zu beachten.

Ich bin der Meinung, man muss da mit gesundem Verstand und Maßstab ran gehen, wie erwähnt, blind in Gruppen, Ringen, whatever zu deployen, bringt nix, wenn es an anderer Stelle dann klemmt. Man benötigt hierfür dann im Zweifel einfach den Plan B, Wiederherstellungskonzepte, Wiederanlaufpläne, IT Notfallhandbuch usw. und selbst das arbeitet noch mit Annahmen und Eintrittswahrscheinlichkeiten.
cansys schrieb:
Ich kann dir aber versichern: Unser Risikomanagement ist noch lange nicht dort, wo es sein müsste.
Ich behaupte, diesen Zustand gibt es nicht, denn das würde bedeuten, jeden erdenklich Umstand abdecken zu können. Das wäre der perfekte Betrieb. MMn unmöglich zu erreichen.


Btw. was die OnPrem vs. Cloud Thematik meint, versteh ich nicht, ich zumindest kenne dieser Tage kein Unternehmen, was nicht wenigstens irgendwo auch Clouddienste nutzt. Und ich müsste lügen ob ich IT Landschaften mit Cloud only Lösungen je gesehen habe? Ich meine nein. Die Frage nach dem einen oder anderen stellt sich da ja gar nicht, wo es in aller Regel ein mixed Betrieb ist? Auf einzelne Dinge runter gebrochen, mag sich sowas stellen, aber im Gesamtbild? Beim Thema Sicherheit zählt nur die Gesamtbetrachtung, das dicke Vorhängeschloss der Panzertür bringt nix, wenn der Kollege im Nachbarbüro das Fenster offen stehen lässt.
 
  • Gefällt mir
Reaktionen: ComputerJunge, SheepShaver, Sirhaubinger und eine weitere Person
fdsonne schrieb:
[...] Es ist reichlich sinnbefreit derartige Updates erst in X Phasen gestaffelt und dann noch pro Phase vorab in Gruppen getestet zu verteilen, bei der Häufigkeit im teilweise Stundentakt oder noch geringer kommst du aus dem Testen nicht mehr hinaus.
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.

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.

fdsonne schrieb:
Die Konsequenz aus einem solchen Versagen der Sicherheitslösung ist die schwindende Reputation des Produktes bzw. des Herstellers. Das wird sich rumsprechen und es werden sich Kunden auch nach Alternativen umsehen. [...]
Ja gut, man sieht bei Microsoft hervorragend, dass so viel passieren kann und trotzdem kein Umdenken stattfindet, weil man der Überzeugung zur "Alternativlosigkeit" folgt. Dazu musst du dir nur mal den Umgang der EU-Kommission rund um Microsoft 365 ansehen... Was interessieren einen schon Gesetze... Da ist der eigene Datenschutzbeauftrage schon mal lästig.

fdsonne schrieb:
Was haben VLANs jetzt damit zu tun?
Das klingt mir nach Buzzwordbingo. Das ist eine simple Segmentierung von Netzen, bringt dir exakt gar nix wenn die Systeme untereinander dennoch kommunizieren müssen.
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.

fdsonne schrieb:
Siehe oben, man kann vieles machen, auch praktisch aber der Aufwand und der Nutzen müssen im Verhältnis stehen und es muss bezahlbar sein.
"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.".

Gut, dann suchen wir mal "bezahlbare Lösungen":
Wir schaffen das teure ERP-System ab, ersetzen das minderwertige CRM-System, die Schrottkiste namens Telefonanlage fliegt raus, die Tools 10 bis gefühlt 100 fliegen raus, Prozesse hier und da werden umgekrempelt, die Belegschaft für Self-Services befähigt, diese in komplexeren Anwendungen ordnungsgemäß geschult, Führungskräfte weitergebildet und, und, und.

Selbstverständlich wurde viel abgelehnt. "Wir haben für so etwas keine Zeit.". Bis zu jenem Tag, wo die Firma wieder schmerzvoll lernen musste und die Gesellschafter dann doch langsam unruhig werden, dass hier und da, und die IT-Abteilung war Spitzenreiter, viel Geld verbrannt wird.

fdsonne schrieb:
Am Ende wird der KRITIS Ausfall mehr Impact haben als irgendwelche Testsysteme. Die Frage ist, ob man im Test alle möglichen Dinge auch bedacht hat.
Lasse deinen Key Usern freien Lauf und finde es heraus. Dafür gibt es neben Produktiv- eben auch Testsysteme und neben produktiven Datenbanken auch Testdatenbanken. Let's go.

fdsonne schrieb:
[...] Weiterhin kommt noch die Unbekannte dazu, dass ein Testsystem selbst bei Bedacht darauf selten 100% dem Livesystem entspricht, einfach weil es teilweise utopischer Aufwand ist, alles zu 100% nachzubauen. [...]
Da sind wir wieder beim Release Management...

fdsonne schrieb:
[...] Man benötigt hierfür dann im Zweifel einfach den Plan B, Wiederherstellungskonzepte, Wiederanlaufpläne, IT Notfallhandbuch usw. und selbst das arbeitet noch mit Annahmen und Eintrittswahrscheinlichkeiten.
Es gibt in vielen Fällen keinen "Plan B", wenn deine Prozesse nahezu vollständig IT-gestützt sind. Einen alternativen Plan zu haben, hieße, deine Anwendungen zu diversifizieren, also mehrere Hersteller für denselben Zweck einzusetzen. Das erhöht die Sicherheit nicht, sondern schwächt sie. Warum? Schon mit Standardlösungen hadern viele Unternehmen, weil ihnen oft das tiefergehende Verständnis fehlt. Das erklärt auch, warum viele IT-Abteilungen und IT-Dienstleister einen mittelmäßigen bis schlechten Ruf haben. Lösungen implementieren? Kein Problem. Hier und da bisschen Support, aber mal da und dort um die Ecke denken? "Sorry, keine Zeit.".

fdsonne schrieb:
Ich behaupte, diesen Zustand gibt es nicht, denn das würde bedeuten, jeden erdenklich Umstand abdecken zu können. Das wäre der perfekte Betrieb. MMn unmöglich zu erreichen.
Diese Argumentation kenne ich allzu gut aus dem Katastrophenschutz. Sinngemäß:
"Das war unvorhersehbar."
"Damit konnte niemand rechnen."
"Ein solches Ausmaß war nicht absehbar.".

Klar, wenn man vor allem mit Best-Case-Szenarien arbeitet und seine Fantasien nicht entfalten kann, dann kommt eben so etwas raus wie im Ahrtal. War natürlich nicht vorhersehbar... Konnte ja keiner ahnen, dass sich Wasser seine Wege sucht, wenn der Boden auf engstem Raum massiv versiegelt wurde... Und natürlich kann man so etwas nicht berechnen, schon gar nicht, wenn es Vorlagen aus anderen Szenarien gibt. Niemals. 😉

fdsonne schrieb:
Btw. was die OnPrem vs. Cloud Thematik meint, versteh ich nicht, ich zumindest kenne dieser Tage kein Unternehmen, was nicht wenigstens irgendwo auch Clouddienste nutzt. Und ich müsste lügen ob ich IT Landschaften mit Cloud only Lösungen je gesehen habe? [...]
Die hybride Infrastruktur, wo also ein Teil On-Premises und häufig der größte Teil Off-Premises extern läuft, ist die teuerste Variante. Viele Unternehmen vergessen, dass sie für die Risiken und Sicherheit in Rechenzentren (btw: nichts anderes ist "Cloud Computing") verantwortlich sind. So ein Tenant ist schnell registriert, aber die Einrichtung ist dann noch mal ein anderes Thema.

Ich gebe dir ein Praxisbeispiel:
Mein Arbeitgeber (Logistik mit mehreren Standorten in DE) hat darüber diskutiert, wie man das hauseigene "Rechenzentrum" (ein Serverraum am Hauptstandort mit vielen alten Systemen und Redundanz am zweitgrößten Standort > entsprechend mit Personal) auflösen könnte, weil "zu teuer". Man ließ sich von windigen Beratern und Dienstleistern überzeugen, dass das Outsourcing die "wirtschaftlich beste Lösung" sei.

Jetzt ging es noch um das technische Wie. Zu diesem Zeitpunkt stieß ich in das Unternehmen und bekam natürlich mit, worum es ging. Auf dem Tisch lag zunächst nur ein Konzept: Alles outsourcen und rein in diverse Cloud-Lösungen und alle Standorte per MPLS anbinden, wobei ein RZ-Betreiber gleichzeitig der Knotenpunkt zum öffentlichen Teil des Internets darstellen sollte. Die Standorte sollten alle eine zweite Leitung bekommen. Wo es technisch nicht ging, LTE als Fallback.

Mein Vorschlag war das "Edge Computing", bei dem der Großteil im hauseigenen "RZ" betrieben wird, durch Digitalisierung und Transformation auslaufende IT-Services (Drucker, Großformatdrucker, Plotter, ...) outgesourct, Prozesse analysiert und optimiert, diverse alte Tools ersetzt, bestimmte Server virtualisiert und die Standorte via SD-WAN angebunden werden. Alle Standorte sollten dazu ein Fallback für die Netzwerkkonnektivität erhalten, ob nun mit zweiter Leitung oder LTE+ oder 5G+.

Entschieden hat man sich für Variante 1, um bereits nach einem Jahr festzustellen, dass sich die ursprünglich geplanten Kosten bereits verdreifacht haben. Wiederum ein Jahr später ging ein Dienstleister pleite, sodass man sich einen neuen und vor allem deutlich teureren Dienstleister dazukaufen musste, nachdem man das eigene Personal teilweise entlassen hatte. Kosten haben sich auch da nochmal verdoppelt. Dann knapp ein dreiviertel Jahr später lief der Vertrag mit dem externen RZ aus. Der neue Vertrag verursachte eine Vervierfachung der Kosten. Man konnte ja nicht erahnen, dass so viele Daten anfallen, die verarbeitet werden wollen.

Zwischenzeitlich schränkte das externe RZ die angemieteten Leitungen ein, um die Dienstequalität für alle Kunden gewährleisten zu können.

Nebenbei kämpft man mit hohen Latenzen und Datenverlusten, fehlenden Ressourcen, Unzufriedenheit in der Belegschaft und Folgekosten, die natürlich "niemand vorhersehen konnte". Dabei hatten schon diverse Wirtschaftsprüfer die betriebswirtschaftlichen Entscheidungen klar und deutlich bemängelt und der IT-Abteilung ein miserables Zeugnis ausgestellt. Selbst die ersten beiden IT-Risikomanager bezeugten die Missstände in der IT zu Entscheidungen, die allein von den Führungskräften, aber teilweise auch von den Fachkräften angetrieben wurden. Hier und da habe ich mir auch keine Freunde gemacht, als ich Entscheidungen hinterfragte... Nun ja, man kann nicht alles haben.

Im ersten Halbjahr 2024 gab es 5 Störungen bei MPLS mit dem Ergebnis, dass alle Standorte zeitweise lahmgelegt wurden. Die Folge: Sonderschichten, Vertragsstrafen, vermeidbare Rufbereitschaften für die IT und immense Kosten, die das Unternehmen zusätzlich tragen muss. Jetzt dämmert den Verantwortlichen langsam, dass sie umdenken müssen...
 
  • Gefällt mir
Reaktionen: Donnerkind, chaopanda, Xiaolong und 3 andere
Die Quality Assurance bei CS war in diesem Fall ein totaler Fail. Eventuell haben die einfach ungetestet das Update freigegeben. Bei so viel Kundschaft ... AUA.
 
rongador schrieb:
Hat darauf vielleicht jemand eine Antwort parat?
Hast Du überhaupt CrowdStrike auf deiner VM laufen? Für mich hört es sich gar nicht so an, als hättest Du CrowdStrike im Einsatz!
 
  • Gefällt mir
Reaktionen: CyborgBeta
QXARE schrieb:
Tja, dann hast du wohl was falsch gemacht, wenn die Server sogar ohne Windows abfahren.
Wo hat er geschrieben das er als Linux Admin für alle Server zuständig ist? Kann ja den Frust über so manche flapsige Besserwisserei verstehen, aber dann mit Strohmännern Leute oder Meinungen Verunglimpfen muss doch nicht sein.
 
  • Gefällt mir
Reaktionen: Miuwa und CyborgBeta
rongador schrieb:
Nur als Denkanstoß: Wenn Linux beliebter wird, immer mehr Linux nutzen, ratet mal, wohin sich dann "Angriffe" verlagern?
Nur als Denkanstoß: Guck mal, womit Server schon heute überwiegend laufen und um was für Infrastruktur es hier geht.
 
  • Gefällt mir
Reaktionen: Miuwa, cansys und areiland
rongador schrieb:
dann kann man die VM doch bei einem laufenden "Windows Server" einfach über den Hyper V Manager neu starten und muss gar nicht den gesamten Windows Server (also den Rechner, vor dem man sitzt) neu starten - richtig?
Ja.

Cu
redjack
 
Zurück
Oben