A Crowdstrike cybersecurity platform leállt - hány általad felügyelt gép (volt) érintett?

Titkosítás, biztonság, privát szféra

A tegnapi Crowstrike incidenssel kapcsolatban hány általad felügyelt gép (volt) érintett?

nulla
93% (916 szavazat)
1-100
3% (32 szavazat)
100-500
1% (13 szavazat)
500-1000
0% (2 szavazat)
1000+
2% (22 szavazat)
Összes szavazat: 985

( Adamyno | 2024. 07. 20., szo – 15:46 )

Mielőtt bármit kirakunk élesbe, van egy kis tesztelés. Úgy látszik a fejlett nyugaton ez már tré :)

- Indítsd újra a gépet! - Az egészet? - Nem, a felét...

Hol élsz te. A 90-es években? A mai IT-sek irgalmatlan lusták. Olyan alap dolgokhoz, hogy dolgokat alapvetően jól beállítsanak, minden default-on hagynak, legtöbbször még backup sincs, meg alap tanúsítványhibákat, lejárati időt nem tudnak megoldani. Ha valami eltörik, sok helyen napokig kis sem megy az IT-s, alapvetően csak távfelügyelettek erőlködik, ha offline beavatkozás kell, akkor akár napokig is állhat minden. A MS már maga is szarik bele, nem tesztel, az Insider program is csak kabaré lett, mindent rátolnak a userre, bugos frissítésektől a 100-szori újraindításig, ami fontos munka, konferencia közben is kihúzza a használója alól a gépet. Mindenki mindent online tárol, felhőbe van kényszerítve, adatait adják-veszik.

Ez már rég nem az a világ, ahol lelkiismeretesen több menetben tesztelnek, nem csak az upstream fejelsztőknél, de deploy közben is. Elmondod ezt, hogy tesztelés, a legtöbb helyen kiröhögnek, aztán ennek is vissza Faszbukozni. Eleve már a fejlesztőket se érdekli, azok is csak agilisen kapkodnak, tolják ki erőltetett menetben, lehetetlen határidőkre a sok bughalmazt, amit 100 menetben kell állandaón patchelve működőképesen tartani. Nem csak a Crowdstrike, mindenki ezt a fenntarthatatlan hozzáállást nyomja.

Mondanám, hogy a Linux legalább különb, mert ott próbának legalább a kernelesek lelkiismeretesebben teszteli kiadás előtt, de még ott is előfordult a kései 5-ös kernelágban, hogy az utolsó RC kiadása után, mikor kijött a végleges, Torvalds nyomta a szokásos sablonszövegeit a maillistára, hogy fairly calm, looks good, nothing exciting, fairly confident, bla-bla, és kiadás után azonnal jöttek a bugreportok, hogy AMD GPU-kon energiatakarékosság nem működik megfelelően, súlyos ext4-es regresszió miatt inkonzisztens lesz a fájlrendszer egyes gépeken, stb., így egy nappal a kiadás után már kellett is kitolni a .1-es bugfix alverziót.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

( kuszi | 2024. 07. 20., szo – 16:40 )

Igen. Ez itt a döbbenet, és kritikus iparágakban a fejlesztőtől az éles üzemig semmi kontroll, próba telepítés, homokozó, ne adj' isten elkülönített hálózaton. Attól hogy egy cég biztonsági termékeket fejleszt még nem biztos, hogy jobban tesztel. Ez itt kód volt, nem csak mondjuk malware szignatúrák. Az hogy ennyi végponton beállít a hiba arra utal, hogy deploy előtt még volt valami kis ártatlan last minute módosítás... :) ezt ki se próbálták... legalábbis azt a csomagot ami kiment (ha egyáltalán ezt akarták kitolni)

Manjaro - Android - Smalltalk - Flamenco - OSMC

Ezt mi, akiknek a szekere mellett elment a versenyautó, nem érthetjük. Én is csak pislogok, hogy hogy elment mellettem az IT, be kell vallanom, az old school hozzáállásom már kompatibilis ezzel az új szemlélettel.

A tesztelés az éles deploy előtt olyan so '90 évek, én már hallottam nem egyszer olyat, hogy ez az "élesteszt" ... 🫢 😆

trey @ gépház

"Attól hogy egy cég biztonsági termékeket fejleszt még nem biztos, hogy jobban tesztel. "

 

Viszont most olyan speciális tesztkörnyezeteket sikerült építenie, amin ez a hiba nem jött elő...vajon mik azok a peremfeltételek, aminél ez a hiba nem jelentkezik...?

"ezt ki se próbálták... legalábbis azt a csomagot ami kiment (ha egyáltalán ezt akarták kitolni)"

Ott a pont, szinte biztos, hogy vagy egy 100%-ban teszteletlen ág ment végig a build-release folyamaton,hogy a teszt kimaradt, vagy (konteósok figyelem!) valaki valahogy belerondított, és nem az ment ki, amit ki akartak tolni...

Ott a pont, szinte biztos, hogy vagy egy 100%-ban teszteletlen ág ment végig a build-release folyamaton,hogy a teszt kimaradt, vagy (konteósok figyelem!) valaki valahogy belerondított, és nem az ment ki, amit ki akartak tolni...

Sajnos a CrowdStrike mindenről ír a blogjában, csak éppen arról nem, ami a legérdekesebb lenne: hogyan baszták ezt így el.

trey @ gépház

( trey | 2024. 07. 21., v – 12:12 )

Szerkesztve: 2024. 07. 21., v – 12:12

Kínában nem kértek az amerikai backdoor-ból, meg is úszták:

Miközben a világ nagy része a halál kék képernyőjével küzdött pénteken, egy ország, Kína nagyjából sértetlenül megúszta az egészet. Az ok tulajdonképpen nagyon egyszerű: a CrowdStrike-ot ott alig használják.

trey @ gépház

( laysoft v | 2024. 07. 21., v – 12:13 )

Számomra inkább az a megdöbbentő, hogy "komoly" cégeknek kritikus alkalmazásai futtatásához vindóznak bármi köze is van.

A tudomány és a hit vitája akkor eldőlt, amikor villámhárítót szereltek a templomokra.

Túl sokat HUP-oztál. Sajnos itt valóban lehet olyanokat olvasni, elsősorban internetes technológiákkal foglalkozóktól, amiből arra a fals következtetésre lehet jutni, hogy minden is internet, felhő, Linux, Docker, meg Kubernetes.

Erre a hibára már sokszor rámutattam itt. A vállalati IT nem ez. Az tök más. Nagyon tök más.

trey @ gépház

Mondjuk itt pont nem egy old school szarról (te futtatod, felügyeled, szabályzod, hogy mit tehet) van szó, hanem egy fancy, flitteres felhős fosról.

Ugyanis, ha ennél is lehetett volna szabályozni, hogy mit s hogyan (állítják, nem lehet), akkor fele ennyi gond se lett volna.

trey @ gépház

Ennek semmi koze a felhohoz.

Az app naponta (tobbszor?) frissiti a definicios file-jait. Olyan kontent ment ki, amitol crash-elt a kernel driver. Ennyi. Ebbe nem kell tobbet belelatni. Igen, a CS bunos, mert jobban elotesztelhette volna mielott kitolja fullba.

Hiaba tesztelsz elore, vannak olyan specialis esetek, amik gebaszt okoznak. Emlekeztek meg a szokomasodperckor jelentkezo java bugba? Csomo enterspajz app bolondult meg tole.

Jol osszefoglaltad. Egyaltalan nem akarom oket vedeni (hiszen minket is mocskosul megszivattak) De par emberek (itt is) van par tevedese ezzel a temaval kapcsolatban.

- Nem ez nem egy MS hiba volt, siman lehetett volna Linux kernel panic is, HA olyan reszet cseszik el a def. fajlnak.

- Nem ez nem egy program frissites volt, amit tesztel lehetett volna kivedeni. Eleve a legtobb helyen N-1 vagy N-2 release re volt allitva, tehat nem a legfrissebb ment ki egybol.

"Olyan kontent ment ki, amitol crash-elt a kernel driver. Ennyi. Ebbe nem kell tobbet belelatni. Igen, a CS bunos, mert jobban elotesztelhette volna mielott kitolja fullba."

Vajon milyen az a tesztkörnyezet, legyen 10-100-1000 vagy több különböző gép/konfiguráció/környezet, hogy ott nem jött ki ez a hiba, az ügyfelek gépein meg totálisan mindenhol igen?

 

Dedede... így lehetnek védelem tekintetében nagyoaptudétek meg komplájenszek... :-) Tényleg agyf@sz, hogy bármilyen kód vagy a kirakott kód működését befolyásoló adat ellenőrizetlenül, egyszerre kimegy mindenre _is_. Marketingesül persze ez jó, mert a felhőben ami van, az faja, és azt azonnal meg kell kapnod, hogy védve legyél mindentől _is_.

Az én tippem (a csupa 0x00 byte-os SYS fileokról szóló beszámolók alapján - amiről persze CS-ék állítják, hogy nincs köze hozzá...), hogy itt inkább a release process mehetett félre. Vagyis lehet, hogy letesztelték azt házon belül, csak éppen az update szerverre már hiányosan ment ki.

Régóta vágyok én, az androidok mezonkincsére már!

Erről a cipész cipője c. klasszikus mondás jut eszembe...

(Gondolom CS-ék most izzadnak, hogy még azelőtt sikerüljön rápatkolni valami integritásvédelmet ezekre a sys fileokra, mielőtt valaki előáll egy malware-rel, ami kifejezetten ezeken keresztül jut be a kernelbe)

Régóta vágyok én, az androidok mezonkincsére már!

 Emlekeztek meg a szokomasodperckor jelentkezo java bugba? 

Ami igazából Linux kernel bug volt, és semmi köze nem volt a Javahoz.

https://lwn.net/Articles/504744/

https://www.somebits.com/weblog/tech/bad/leap-second-2012.html

Any Linux user processes that depends on kernel threads had a high chance of failing. That includes MySQL and many Java servers like webapps, Hadoop, Cassandra, etc. The symptom was the user process spinning at 100% CPU even after being restarted. 

Hátöőőő... nem tudom, nálatok hogy van, de nálunk üzletileg kritikus adatbázisok és szolgáltatások nem Ms alapú szervereken futnak. Ettől még az AD/Azure tényleg a legsokoldalúbb és legtámogatottabb, de ha valaki a frontendet teljesen Ms alapú megoldásokra bízza, akkor úgy jár, mint az érintett repterek, ahol hiába működik a légi irányítás hibátlanul, ha az utasokat nem tudod kezelni.

A DB-hozzáférést simán lehet AD/LDAP/Kerberos alapokon csinálni, sőt az OS-re sembiztos, hogy a lokális userek felmaszírozása a legjobb ötlet... Persze, lehet AD-tól föggetlen vagy azzal részben összegyógyított külön IDM is a nemwindows környezetek számára, de AD nélkül desktop-ot meg egy csomó egyéb rednszert igencsak sajtreszelős nagyobb tételben menedzselni.
 

Azért nincs ilyen, mert a döntéseket hozó menedzserek a gyors megoldásra, a tanúsítványra és a felelősség magukról letolására mennek csak, a megbízhatóság és függetlenség nem szempont. Az ezek alatt dolgozó IT meg arra, hogy neki a legegyszerűbb dolga legyen mindennel, azok sem a legprofibb megoldást vadásszák és terjesztik fel.

Azért meg lehet nézeni pl. az UNIX Autó rendszerét, amit a kriptó támadás után úgy átalakítottak, hogy a klienseken saját összeállítású Linux disztró fut, saját készítésű alkalmazást futtat és a szerver oldalon is MS nélküli minden. Szóval ha van szándék, akkor van műszaki megoldás a cégek MS nélküli működésére. Nyilván ez a cég nem olyan nagy a világméretű multikhoz képest, azoknál biztos összetettebb rendszerekre van szükség, de azoknál pénz és emberállomány is több van ilyesmire...

( Usumu | 2024. 07. 21., v – 15:04 )

Általam 0 ,a feleségem által állítólag 3600.

Jaja, miután sikerült az összes szervert kivakarni a kékhalálból .... :D Ha szerencséd van, akkor mondjuk a PXE-hez a DHCP szerver nem Windows volt, de várj .... Windows / Domain / AD környezetben a DHCP szerver is AD-integrált az esetek 101%-ban, így AZ IS BESZOPÓDOTT :D

trey @ gépház

Látom a Karácsonyi Tatuknak ez annyira nem tetszik, akkor képaláiratozok:

A képen az látszik, ahogy a multimilliárdos, XDR-t futtató, nagyon ügyi, multinacionális, hipi-szupi "mit értetek ti ehhez" vállalat AI-je, mármint Mr. AI home office-ból éppen problémát old meg (zöld LED-et nézeget a szerverszobában). Hiszen náluk már az AI szarja a Kubernetes-t és a field engineer munkáját már rég elvette az AI (ami a diszkeket is cseréli).

Hja, trey-nek megint nem volt igaza ... a világban hol kéne már kimenni egy fájltörlés miatt? Majd a Salt, Puppet nemtommi habiszti buzzword rámegy, azt' kitörli :D :D :D :D

trey @ gépház

Nyugodtan lépjünk túl a Microsoft okoláson

Amúgy nem teljesen. Létezik ugye a Last Known Good Configuration boot opció. Sok értelme nincs, ha automatikusan nem indul el LKGC-vel a gép, ha amúgy az egy távmenedzselt gép (és mint láttuk pénteken, rengeteg ilyen gép van).

Szerintem lehetne a Windowsnak olyan funkcionalitása, hogy:

- beállítható, hogy a gép mindig induljon újra (mert folyamatos üzemre van kitalálva)

- ha reboot loopba kerül, akkor a második reboot után induljon el a LKGC-vel

Valószínűleg ehhez persze kellene firmware támogatás is, hogy ha a kernel annyira elcrashel, hogy még újra sem tudja indítani a gépet, akkor a firmware tegye ezt meg.

Persze ugyanez igaz más OS-sel rendelkező (Linuxos, AIX-os stb.) szerverekre is, ha egy kernel update után nem indul el, és reboot loopba kerül, akkor létezzen az LKGC, és induljon el azzal.

Amúgy a babzsáküzemeltető DevSecOpsosokhoz képest a konzervatív üzemeltetők miért nem használják, miért nem ajánlják ezekre a távmenedzselt gépekre az Intel AMT, AMD PRO szolgáltatást, ha már a szervereknél ott van az iLO, iDRAC. És akkor nem kéne kimenni, és lehetne HO-ból rendezni a dolgokat ugyanúgy.

Ki mondta, hogy nem ajánlják?

Válaszokat írjam, vagy mutassam? Amikor meg nem nevezett vállalatnak le lett szállítva már 12 évvel ezelőtt is a full vPro megoldás (jaja, én építettem ki :() demóban, "jajj, ez kell nekünk, mibe kerül?" megkapták az árat, "besírtak, összegömbölyödtek a sarokban, mint a sündisznó, aztán leszopták magukat ... "akko' nem kő' :("

trey @ gépház

Akkor asszem nem a DevSecOps babzsáküzemeltetők a problémák itt, hanem a spúr cégek, akik most kifizetik többszörösen annak az árát a rendkívüli üzemeltetési káoszban, amit a múltban meg akartak spórolni. Mert igazából a spúr pénzügyesek tették ide a világot, nem a DevSecOpsosok.

Most azt akarod elsütni, hogy a cégek, ahol volt lóvé ilyen Crowdstrike ramatyra (amit a DevSecOps meg a társai kitalált buzzword állásban levők) üzemeltetnek, azok azért nem vettek mert nem volt rá pénzük? :D

Nem, azért, mert el sem tudták képzelni, hogy van olyan scenario (pedig előre leírtam itt a HUP-on is), amikor a szakmai nagyképűségük fogja őket botra juttatni.

Így is lett.

trey @ gépház

Itt rendszerszinten volt el...va a dolog. Ugyanis hiába volt/van n+1 node egy adott funkcióra, hiába van x munkahely (PC) adott tevékenységhez, _ha_ van olyan komponens a rendszerben, ami helyi tesztelés nélkül, valamennyi node-ra/munkahelyre egyszerre megy ki, és képes megborítani a működést.
A spúrság meg az ebben az esetben, hogy nem volt az n+1 node meg az x munkahely (PC) legalább(!) két csoportra bontva, és azokra nem két különböző, ilyen kockázatot hordozó szoftver kiválasztva és telepítve/használva.

A DRP/BCP olyankor, amikor _valamennyi_ eszközöd (incl. a DR site, incl. amit BCP-re használnál) is kéken döglik nagyjából arra jó, hogy a zilletékesek a hátsójukat... tisztogassák - mert eme nemes felük védelmére sajnos a teljes káosz miatt alkalmatlanok ezek a tervek.