CHS ransomware - mi történt, hogy történt

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

A CHS publikálta, hogy mi, mikor és hogyan történt - tanulságos kis cikk:

[...]

Egy hosszú hétvége, síeléssel: a kellemes fáradtságot egy pillanat alatt söpörte félre a szerda reggel, a munkahelyem felé tartva kapott, rövid SMS. „Ha beérsz, ne kapcsold be a notebookodat.” Ekkor még nem tudtam, hogy ransomware-támadás ért minket – de természetesen azonnal elkezdtem azon gondolkozni, miért írhatta. Fel is hívtam a kollégám: kiderült, ő már észrevette, hogy letitkosították a fájljait, így kellő bizonyossággal és magyarsággal közölte: „bekaptuk”. Elért minket is az az IT „betegség” amin vagy átestél már, vagy át fogsz. Minket ezen a napon ért el a végzet.

[...]

A teljes cikk itt.

( tigrincs | 2023. 05. 11., cs – 13:43 )

tldr: semmi konkret nem derul ki

En hianyolom a beszamolobol az alabbiakat:

Mik voltak elszabva a mentesi tervben

Hogyan usztak meg konkretan (nem csak egy product name hanem reszletezve a miertek)

Hogyan jutottak be a rendszerbe (nem az nem info, hogy phishing)

0. hiba: Megfelelő szakemberek alkalmazásának hiánya - tisztelet a kevés kivételnek. Tippem szerint, ha megfizetik a hozzáértő szakembereket, elküldik őket képzésekre, illetve meghallgatja a vezetőség a szakemberek tanácsait - különös tekintettel IT security téren, akkor nem történik ekkora blama.

Ennél rosszabb! Olyan volt, hogy be se törtek és a Microsoft és partnere elvesztette az ügyfelei adatait amatőrségében! :D :D :D

Annyira, hogy azt az üzletágat be is kellett zárni. Látom newcomer vagy:

Az ügyfelek backup adatainak majdnem biztos elvesztése miatt kért elnézést a T-Mobile és a Microsoft/Danger

Valami egy hét szerencsétlenkedés után valahonnan sikerült az adatok egy részét visszaállítani, de már senki sem hitt abban, hogy ott tárolja az adatait.

Kiderült, hogy egy storage* firmware frissítés olyan "jól sikerült", hogy az üzletág ment a gajdeszba. :D

(* mit kell ahhoz érteni, nem?)

trey @ gépház

Az a helyzet, hogy meghallgatják, majd utána a büdzséfronttól, munkaigénytől szívrohamot kapnak, és akkor hát meg kéne oldani valahogy, jólesz valahogy. A másik probléma, hogy sok helyen 5 perc downtime-ért is megy a könyörgés, mert mindíg vki szuperfontos. A harmadik dolog, hogy ez a fajta teljes mélységi csapás egészen újszerű, ez még csak nem is olyan, hogy a random SMB kliens amit elér átkódol, és majd visszamásolod azt kész. Sok helyen nincs végpontvédelem, az IDS/IPS megoldások mégfontosabbak lesznek, sőt valszin mindenfélét kell kombinálni. A felhasználók képzése újfent kulcspozícióba kerül, mert minden 0sec linket, malware verziót nem lesz az a csodarendszer, ami megfog.

Több helyen épp a fenti miatt sikerült meggyőzni a vezetőséget, hogy komolyan rá kell fordulni a mélységi védelemre, és pl.a mentési stratégia bővítésére. Ráadásul több kollégával arra jottunk, hogy ha valahogy bekapunk egy komolyabbat, akkor végső soron azon fog múlni az egész történet, hogy mennyire sikerült szeparált mentéseket készítsünk. Azt remélem, hogy sikerül az infra elérését megvédeni, aztán majd meglátjuk.

IDS/IPS? milyen GDPR hiszti lenne abból? ;)

Nem mintha nem tennék rá, egy évre visszamenőleg van zeek log és suricata is mondjuk az vagy háromra. Amíg engem vesznek elő ha beüt a crack (vagy nem jönnek rá, hogy a onemanshow mindenes kevés) addig marad is.

Ugyanitt valaki nem tud egy linket a cikkben promozott nimble cucc firmwarejére ránéznék poénból, de gondolom zenterprájz access kell hozzá.

( kruska v | 2023. 05. 11., cs – 14:23 )

Természetesen nem maradhat el a tanulságok levonása sem.
...
– A mentőegységből mindenki vegye ki a szalagot.

A "full" mentéseket persze. De a napi / óránkénti inkrementális / deduprepo-diff szalagok mellett csak nem ülhet állandóan egy operátor. Ezeket WORM-ra írjuk, ahhoz nem tudnak nyúlni. Amúgy is: ahol lehet, pull mentés. Akkor is, ha ennek egy nagy mirror terület az ára.

– De a legfontosabb: a HPE Nimble bevezetése, hiszen a napi snapshotok megmenthetik a cégeteket!

Szerényebb infrán is működik a btrfs snapshot send/receive, zfs send, lvm snapshot, lxc export | borg.

Amikor a beszopott ransomware post-mortemből is lehet kanyarintani egy kiba. HPE reklámot.

A cikk meg szakmailag egy rövid lószar. Nem tanul belőle senki semmi újat, felesleges elolvasni.

Ezt mi is meg tudjuk mutatni, így akit a fent említett HPE Nimble (Alletra), vagy bármely további HPE-termék és stratégiai partnereinek megoldása érdekel működés közben, várjuk a CHS budaörsi kompetenciaközpontjában, ahol HPE GreenLake konstrukcióban egy komplett adatközponti megoldás üzemel. A történetünk hosszabb, vágatlan verzióját pedig szívesen elmesélem szóban – hátha találunk olyat, amire nem gondoltatok, de mi átéltük, tette hozzá Czinszky Péter.

Itt meg köp az ember egyet maga mellé.

A Veeam "pull" mentést csinál, ennek nagy tükör terület ára sincs (bár nem világos, mit értesz ezalatt).

A gond valószínűleg az volt, hogy a mentések nem voltak (kellően) védve (tűzfal és jogosultság), esetleg a mentés is csak "fut, örülünk" módon volt beállítva, illetve annyi minimális kiolvasható a cikkből, hogy a jelszó kezelés slendrián lehetett, pl. XLS vagy TXT.

Már-már örültem, hogy lesz egy érdekes/tanulságos olvasmány, de ez tényleg csak egy (műszakilag gyenge) HPE reklám. A visszaállás sokkal inkább tekinthető egy oltári nagy mázlinak (a tároló pillanatkép készítés mögött sem sejlik fel különösebb tudatosság), mintsem bármi másnak (ha a támadók már ott voltak a tárolón, nem sok kellett volna a pillanatképek törléséhez).

A Veeam, illetve minden hasonló, az infrán belül fut úgy mond. Felkerült a virtualizációs hosztra, és onnan ment. A pull alatt szerintem itt az a koncepció lenne, hogy nem a mentendő valaminek van jogosultsága a backup storage-en, hanem a backup storage-en fut bármi, aminek joga van a mentendőhöz. Pont a CHS példa miatt gondolunk át néhány mentési stratégiát, illetve bővítjük, és arra jutottam, hogy az offsite mentés úgy lenne célszerű, hogy fapad módon a Veeam repot kintről rsyncelem lefelé, és nem a Veeam másodlagos backupját használom, vagy készítek rá egy ritkább jobot. A másik faék megoldást is be fogjuk vetni, miszerint időszakosan egy valamire kézihajtányosan kimásoljuk a veeamrepot, nemfelülírósan... :)

Felkerült a virtualizációs hosztra, és onnan ment.

Alapvetően nem feltétlenül, infrastruktúrától függ, azon ESXi-re, amin a mentendő VM-ek futnak, tipikusan backup proxy kerül.

A pull alatt szerintem itt az a koncepció lenne, hogy nem a mentendő valaminek van jogosultsága a backup storage-en, hanem a backup storage-en fut bármi, aminek joga van a mentendőhöz.

Veeam esetén ezt nem is igazán tudod másként. Illetve lehet, ha valaki Windows licencet szeretne spórolni és gőze nincs a témáról, de akkor az meglehetősen pancser dolog.

fapad módon a Veeam repot kintről rsyncelem lefelé, és nem a Veeam másodlagos backupját használom,

Igen, ez is lehet egy opció, de ha TXT-ben vannak a jelszavak, akkor majdnem mindegy: ha tárolóra beléptek és jelszót módosítottak, akkor +1 egy SSH nem lesz akadály. Az ehhez kapcsolódó jelszót/jelszavakat valószínűleg érdemes külön tárolni, átgondolni a hozzáférhetőségét.

A Veeamnek egy ideje van "immutable repository"-ja.

De más hasonló technológiák is vannak, a NetApp SnapLock erős múltra tekint vissza, bár nem olcsó kategória, de egy CHS-nek pl beleférne a keretbe.

Az immutable mennyire immutable, hogy ha hozzáférnek a mögöttes storage-hez? Elsőre ezt találtam, igazából jól hangzik: https://www.veeam.com/blog/v11-immutable-backup-storage.html

Alapvetően itt az a probléma, hogy ha bejutnak, és mondjuk egy ideig lappangó fázisban vannak, akkor nem kell jelszólista, hanem nekiállnak adott eszközöket feltörögetni. Mindíg mindent baromi nehéz abszolút napra készen tartani, és még ha ez nagyjából megy is, akkor is lehetne olyan napok, amikor még nincs fent a legfrissebb valami.

A befelé jövő SSH-val nem tudnak mit kezdeni, ráadásul nincs jelszó, hanem kulcs van. :) Azt gondolnám, hogy ha valahol van egy ilyen "fordítás", akkor az egy igen jó eljárás a kódolás végigzavarásának megállítására.

Kulcs, alapvetően igen, de azért az sem 100%:

- egy hasonló szervernek ne legyen iLO-ja (ha már HPE témában vagyunk), vagy annak a jelszava is nagyon jól el legyen dugva. Hiába kulcs alapú az SSH, ha iLO-n, majd konzolon belép és töröl.

- felmerül, hogy milyen gépről jutottak be az infrastruktúrába. Ha például a rendszergazda gépéről, amin ott az SSH kulcs (márpedig van rá esély), akkor majdnem mindegy. Mert normál esetben felhasználói gépről ugyebár nem kellene tudni infrastruktúra eszközök felé közlekedni, se jelszóval, se kulccsal, semmivel.

Őszintén szólva a Linux alapú immutable tárral még nincs tapasztalat, közeljövő témája, például az fs-t hordozó partíciót miként lehet letörölni. Vagy ha iLO hozzáférhető, akkor akár a VD-t is lehet törölni. NetApp esetén van mód törlésre SnapLock Enterprise esetén, de nagyon izzadságos, SnapLock Compliance esetén tényleg csak fizikai megsemmisítés játszik, azaz kvázi kivett szalagos biztonság.

Feltörés: és még az is lehet, hogy minden tuti friss, mégis feltörik...

Reverse incremental .vbk-t rsync-eltél már (pull)?

Egyelőre nem kezdtem hekkelni Veeam mentésnél a repót sehol. Az az elméletem, hogy mondjuk hétvégén napközben lehúzom az adott állapotot, ami elvileg konzisztens. Baj esetén a Veeam-be importálva tudom használni. Elméletben, hogy ez ilyenolyan file az lényegtelen, mert tökéletes másolata a repónak. Akár úgy, hogy nem túl helytakarékosan van egy A és B hét, azaz kettő példányban megvan, hogy a felülírást részben kerüljem. E melllé ki tudok tolni egy külön Veeam offsite mentést.

(Természetesen mindenki úgy számol, és annyi példányt tart, amit a rendelkezésre álló erőforrások engednek, bár roppant olcsóak a TB-ok önmagukban.)

A Veeam elég jól ki van találva, simán be tudod importálni a mentéseket, még bűvészkedni sem kell hozzá.

Két dologra kell figyelni:

  • akkor másold, amikor nem fut mentés (a másolás mentés után induljon, újabb mentés ne induljon, amíg fut a másolás) vagy készíts pillanatképet és azt másold
  • cél oldalon legyen pillanatkép a mentés alatt, ha megszakadna vagy bármi egyéb lenne, akkor is megmaradjon a konzisztens állapot; a pillanatképpel két dolgot nyerhetsz:
    • inkrementális marad az rsync
    • a tartalékképzés csak annyi helyet foglal, amennyi a változás; a pillanatkép törölhető, ha sikeresen lefutott az rsync.

Azért kérdeztem a reverse incrementalt, mert forrás oldalon a legfrissebb állapot így mindig egy teljes mentés, ezáltal az rsync mindig inkrementális tud maradni. De nyilván tisztában kell lenni a reverse incremental vonatkozásaival (jelentősen nagyobb lemezterhelés).

Egy Azure-nál is lehetséges biztonsági probléma, akár felhasználóilag, akárhogy. Az adatokért szintén nem vállalnak felelősséget, csak sokmindent elkövetnek, hogy jó legyen. Azzal nem vitatkozom, hogy általában jó lehet, és valóban adhat védelmet, csak a "sosem lesz probléma", az simán nem jelenthető ki semmire.

Feljebb ezt irtad: "Ha hozzáférnek a felhőjuzerhez, hiszen automatikusan ment oda a valami, akkor az úr legyen veled. :P"

Erre kérdeztem rá, hogy mire gondolsz. Nemhogy a felhőuserhez (ill. annak SAS url-jéhez), de még a teljes storage account key-hez is hozzférhetnek, akkor sem tudják sem törölni sem módositani az immutable-é tett blob-okat, a retention lejáratáig.

Maga a blob service, azon belül is az immutable storage pedig tucatnyi, komoly certificate-ekkel és audittal rendelkezik, annak elég pici az esélye, hogy a ransomware hacker be tud sétálni az adatközpontba, meg tudja találni a konkrét redundáns szervereket ahol tárolva vannak, majd ott hozzá tud férni. Persze mindezt több földészen és adatközpontban egyidejűleg, hiszen georedundáns az adat és mindezt észrevétlenül teszi.

Ezért mondtam, hogy ha erre képes, akkor bizony megérdemli az adatokhoz való hozzáférést, még meg is tapsolom.

( gemnon v | 2023. 05. 11., cs – 16:37 )

Hogy jöttek be, nem derül ki....

Nincs rá pénz.  De ha egy ransomware eltitkosítja a 25k-s Tesco gazdaságos winyón (arra sincs amúgy pénz úgyhogy a sajátom) a Borg backupot ami addig találkozik géppel amíg ment akkor tényleg baj lesz. ;)

Van sima backup is nem elszeperált hálózaton (ha külön vlan ér akkor elszeperált :)). Amúgy ez a nimble bigyó mennyivel tud többet mint egy a btrfs snapshot?

Ket hasonlo esetet is lattam, mindket esetben az MS SQL foszereplo volt, termeszetesen publikusra kiajanlva. 

Aszongya:

Természetesen nem maradhat el a tanulságok levonása sem.

Valoban, az ott olvasottak alapjan halvany lila fingjuk nincs a tamadasi vektorokrol, akkor sem, ha kiveri a szemuket. Ugyanis epp arrol nem esett szo, hogy megvizsgaltak volna, vajon miert is az sql kiszolgalo volt az elsodleges target.

Error: nmcli terminated by signal Félbeszakítás (2)

Amit én láttam távolról ott valószínűleg egy pályázatos fortinet esett áldozatul, "megoldásszállító" ledobta teljesítés igazolás kiállítva mindenki örül, karbantartásra (update button időnként) nincs pénz ;)

De emailesek nálunk is voltak (még a locky időben) és természetesen magán Freemail, pendriveos is volt (raspberry Robin) gőzöm nincs honnan szedte a csóka ;)

( khiraly | 2023. 05. 12., p – 06:31 )

Egy tanulság mégis van:

Backupbol sosem elég.

Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

( gyuri23 | 2023. 05. 12., p – 06:38 )

Tanulság:

De a legfontosabb: a HPE Nimble bevezetése

:D

A fizikai kiszolgálókhoz nem volt könnyű hozzáférni, mivel az iLO-k gyári adminisztrátor jelszavait is megváltoztatták.

Ez elég kamu szagú, nincs default password az iLO-ban, mindegyik egyedi és egy matricán van a gépen.

A tömegek sohasem szomjúhozták az igazságot. A nekik nem tetsző bizonyságok elől elfordulnak és inkább a tévedést istenítik, ha ez őket elkápráztatja. Aki illúzióba ringatja őket, úr lesz fölöttük, de áldozatuk az, aki megpróbálja őket kiábrándítani.

Ebben engem az érdekelne, hogy hogy a fenében fértek hozzá ahhoz a hálózathoz, ahol ILO és társai figyelgetnek, illetve hacsak nincs extrém sok gép, akkor minek voltak esetleg domainbe léptetve? Tudom, a domaines auth nagyonszupcsi, és mindenhol csinálják, meg szupermenedzselt lesz, de könyörgöm néhány, de mondjuk 10 szervernél tényleg kell egyáltalán foglalkozni vele külön?

Valószínűleg voltak alapvető architekturális problémák (rosszabb esetben még mindig vannak), nem hiába nem taglalták jobban, ellenben úgy gondolták, hogy egy HPE reklámnak megfelelő. Simán lehet néhány ügy, ahol a műszakilag nem képben levő döntéshozókat megvezetik ransomware-biztos sztorival.

A domaines részhez: Már 5 gépnél megéri az AD domain. Bekonfigurálom az account lockout policy-t (hogy csak a legalapabb beállításról beszéljek), aztán lehet törögetni. Akár úgy beállítva, hogy csak kézzel lehessen unlockolni a usert.

Ilyenkor pedig egy jó szakember felteszi a kérdést: Vajon miért zárolták a fiókot? Ennek utána kell járni és annak megfelelően továbblépni. Csak ez itt megérzésem szerint elmaradt.

ILO jelszó: Tippem alapján több vagy az összes géphez ugyanazt a jelszót használhatták. Aztán Szezám tárulj...

( akoscomp | 2023. 05. 12., p – 07:28 )

Számomra itt még van egy nagyon fontos tanulság. A mentéssel kapcsolatos infrastruktúra soha ne legyen elérhető a központi auth userrel (jellemzően AD).

( hnsz2002 v | 2023. 05. 12., p – 09:18 )

Szerkesztve: 2023. 05. 12., p – 09:24

Ez mese habbal, semmi konkrétum.

Ugyanakkor több szomorú dolog is van:

- miért nem tudja a helyi IT a mentéseket kezelni?

- a mentések korruptálhatóak az éles rendszerből

- nem volt jelszó policy

- nem voltak updatek felrakva

- mi az, hogy default jelszavak???

Minek vannak akkor amúgy, mit csinálnak? Patront cserélgetnek a nyomtatókban? Egy IT-jellegű cégnél... Igazából megérdemelték...

"Sose a gép a hülye."

"Egy IT-jellegű cégnél..."

Ők nem IT cég, hanem egy nagyobb méretű kereskedő cég, akik történetesen IT eszközöket árulnak. De azok az eszközök dobozokban vannak, és  általában a vevőik akik a dobozokat kicsomagolják, és értenek a felhasználásukhoz.

A cikkből nekem az jön le, hogy egy napig ész nélkül rohangáltak, mire rájöttek mit kéne tenni. Azért ezt az amatőrséget még egy bútor nagykereskedés IT üzemeltetőitől sem várná az ember.

Érdemes ezt összehasonlítani a Unixtrade-es esettanulmánnyal. Egyikben sincs hiány az önfényezésből, de a Unixosból azért átjön némi professzionális válságkezelési feeling, ez meg csak egy felszopó PR cikk.
 

"A storage jelszavának sikeres visszaállítása után azt láttuk, ... a Nimble által használt napi időzített storage snapshot-ok viszont elérhetőek maradtak...""

Szóval valójában nem a csili-vili storage mentette meg őket, szimplán csak k. nagy mázlijuk volt, mivel miután felnyomták az ominózus storage-ot a támadók, véletlenül (hozzá nem értésből?) nem törölték az automata snapshotokat. Hiába na, a hackerek sem érthetnek minden storage-hoz...

Ezek után mondja azt valaki, hogy a "Security through obscurity" nem megfelelő védelem. Itt most pont ez játszott....

Számomra gyanús, hogy az eszközök valamilyen központi authentikációs történetbe voltak bedrótozva, a gyári jelszavak pedig millió éve "valamire" megváltoztatva. Ha a központi auth rendszert, pl. egy AD-t kódolnak, vagy jelszavakat változtatnak random, akkor rögtön kizáródnak onnan is, amit igazából nem törtek meg. Egy storage-re belépve file rendszer szintű "eltitkosítással..." nem szokás találkozni, hanem a LUN-okat valami használja. A másik ötletem, hogy valamilyen script haladt végig és vagy kiderült valahonnan a jelszó és változtatott, vagy dictionary attack volt.

Egyébként ha a menedzsment interface-eket szeparálni akarjuk, akkor ott vagy nem használunk AD integrációt, vagy egy csak azon a hálózaton létező tartomány kell. Ez utóbbi valszin még néhány 10 eszköznél is erősen overkill.

Jó eséllyel AD integrált volt, azért nem tudtak elsőre belépni. Írják, hogy az ILO-k ba sem tudtak belépni, valószínűleg AD ból voltak azok is. Egy támadó nem hiszem, hogy szórakozik ILO jelszavak módosításával, mert azt elég triviális visszaállítani. (Bár a fun factort biztos növeli....)

A kiajánlott volume-okat meg nyilván a kliens szervereken encryptálták.

Valószínüleg nem csak automatizmus dolgozott, mert a veeam-os tape libben is törölték a mentéseket. A storage admin felületére is simán be tudtak volna lépni a támadók, a mázli az volt, hogy ezt jó eséllyel valamért nem tették meg.
Nem kizárt, hogy az valami védett hálózaton volt, de ha ugyanabba az AD-ba volt integrálva, amiből mindenki mást authentikáltak, akkor nem valószínű, hogy nagyon szeparált lett volna.
Dictionary attack nem kell, ha megvan az AD felett az ellenörzés. Onnantól bármelyik accounttal bárhová be lehet lépni, igazából csak az a feladat, hogy megtaláld, melyikkel hova érdemes.

Én azt gondolom, hogy nagy valószínűséggel pusztán a szerencsének köszönhetik az adataikat, mert a védelem gyakorlatilag le volt nullázva, a támadók simán csak elsiklottak a storage snapshot felett.

Ezt írja a cikk:

az iLO-k gyári adminisztrátor jelszavait is megváltoztatták

...

A storage jelszavának sikeres visszaállítása után

Nekem ebből az következik, hogy bizony kézimunkáztak.

Persze ettől függetlenül lehet, hogy AD felhasználóval léptek be, és utána a helyi fióko(ka)t is módosították, mindenesetre törekedtek arra, hogy megnehezítsék az elhárítást, illetve:

Mindig legyen egy megfelelően szigorú password management a cégnél.

Ebből pedig az jön le számomra, hogy akár AD integráció nélkül is be tudhattak lépni az eszközökbe. Ha egy XLS-t vagy TXT-t megtaláltak a jelszavakkal, valószínűleg IP cím is volt mellette, úgyhogy kb ingyen büfé ebéd volt a támadó számára, akik azt az egy hibát követték el, hogy nem törölték a tárolón levő pillanatképet. Az illető valószínűleg fejmosást kapott (főleg, hogy a cikkel most kiderült, mit bénáztak el, miért nem fizettek), legközelebb valószínűleg alaposabbak lesznek.

Ha tényleg valami XLS vagy TXT jelszó fájlt találtak, akkor az nagyon komoly hiányosságokra utal, hiszen például egy titkárnőnek nem szabadna ilyenhez hozzáférnie.

Az ILO-kat különösebb kézimunka nélkül scriptelve lehet jelszóváltoztatni, illetve brute force alapon, meg néhány kurrens exploittal próbálkozva bejutni. Minden rendes IPMI képes szerver a hosztról ipmitool -lal (vagy annak megfelelővel) akár scriptelve jelszóváltoztatható. Még a felhasználó nevet sem kell tudni feltétlenül, mert azonosító alapú emlékeim szerint. Ez úgy korlátozható, hogy minden virtualizációs hoszt szépen szeparált, és nincs igazán bare metal install, ami elérhető a potenciális támadási irányból.

Jelen esetben azért gondolunk AD integrációra, mert ha valóban kézzel nézelődnek, akkor a storage snapshotra csak rájönnek. Ha már eligazodnak egy infrában, és valóban kézzel lépeget be a támadó, és persze megfelelő szinten van, akkor a storage snapshot nem eldugott történet.

Lehet, hogy volt AD integrációs dolog, de ha annak segítségével is módosítja a jelszavakat, a tárolót másként kell szerintem és ha a tárolóra is fel van készítve a szkript, akkor jó/jobb eséllyel a pillanatképek törlése is belekerül. Illetve az összegzésben benne van a jelszókezelés fontossága, én ebből azt veszem ki, hogy elérték az eszközök jelszavait.

Továbbá a szalagokat valószínűleg "kézzel" törölték, illetve Unix esetén is felkészült támadás volt, jó eséllyel itt is, azzal a hibával, hogy a tárolóról nem törölték a pillanatképeket. Mindenki hibázhat, aki dolgozik...

Mindenesetre nagyon jó eséllyel komoly biztonsági (architektúra) hiányosságok lehettek, esetleg még mindig vannak, mivel a cikkben az összegzés erre a témára csak a jelszavak szintjén tért ki, ami nagyon kevés, és ha már félig szakmai lapban jelent meg a cikk, ezt illett volna odabiggyeszteni, mert nem, nem a Nimble vásárlása a legnagyobb tanulság. A tanulságból konkrétan egyedül a szalagok kivétele ad támpontot erre az esetre, mert pl. katasztrófa tervvel sem megy semmire, ha nincs adat. Bár ez is nagyon jól hangzik menedzseri szinten, tény és való, EuroOne-hoz befuthat néhány ilyen megkeresés.

De a legjobb lenne, ha bizonyos szintig valaki kompetens tudna válaszolni, mi is történt, ha már húztak egy szakmai mézes madzagot :-)

Az az érzésem, hogy sok vezető elolvasta, elolvassa, és ráöntik az ájtira, hogy "oldjuk meg nimble-lel". Biztos lesz olyan hely, ahol hozzászoktak a hasonló kérésekhez, és "megoldják", sőt megörülnek, hogy értelmes fejlesztésre lesz büdzsé. A fejlesztés lehet értelmes más szempontból. :)

Apropó, a storage snapshot funkció nagyon jó dolog, legyen az bármilyen megoldás, nehogy valaki félreértsen véletlenül. :)

Valószínüleg nem csak automatizmus dolgozott, mert a veeam-os tape libben is törölték a mentéseket. 

Vagy valójában ezek nem is törölve lettek, hanem a titkosítás miatt használhatatlanná téve - én sokkal inkább erre gondolok, mint egy bonyolult, előre megtervezett és csapatban elkövetett támadásra.

Egyébként ha a menedzsment interface-eket szeparálni akarjuk, akkor ott vagy nem használunk AD integrációt, vagy egy csak azon a hálózaton létező tartomány kell. Ez utóbbi valszin még néhány 10 eszköznél is erősen overkill

Nagyobb védelmet jelentenek a policy nélküli lokális jelszavak?

Dolgozok olyan helyen, ahol lokális jelszavak vannak pár tucat management felülethez, és kikényszerített policy a nyilvántartásuk módjáról és X naponkénti cseréjükről.
És a cseréket is lehet automatán, scriptelve.
Ahol meg már százas nagyságrendű hálózati eszköz van, ott van nekik külön, baromira védett központi authentikációs megoldás.

 

Jól írtad, ez policy kérdése, és nem műszaki kérdés.

Ha nincs szeparált központi authentikáció a management felületekre dedikálva, akkor jobb, ha egyáltalán nincs , csak lokál + megfelelő policy + megfelelő kontrol.

Nyilván meglehet, én még nem láttam ilyen helyet.
Olyat viszont rengeteget, ahol alacsony komplexitású jelszavakat használtak, éveken keresztül, függetlenül a fluktuációtól.

( Ami még elveszik, az a lockout mechanizumus - jó régen foglalkoztam iDRAC-el, úgy rémlik ott nem volt. )

Ha belátható számú eszközöd, akkor nem biztos, hogy egy AD integráció mindentől független szuperszükséges. A mellékelt ábra szerint pedig egyenes SPOF-ot építesz be, hacsak nincs egy külön domained (külön DC-kkel persze) ehhez. Az sem utolsó, hogy egyéb okból lerohad az infrád, akkor esetleg ne az infrán/hálózaton futó DC-kből próbálkozzon az ILO az authentikációval.

Kifejezett védelemnek nem nevezném, inkább a leválasztás egy lépése. Ha véges számú a géped, akkor nem olyan nehéz policyt kézzel betartani, de nem is biztos, hogy mindenképp cserélgetni kell, csak ha kimondottan indokolt (pl. akinek volt hozzáférése elmegy a cégtől).

Szerintem a központi log és lockout nélkül még így sem, de amit felvázoltál, az is csak a lokális credential-öket használó rendszerek töredékénél van jelen. Enélkül pedig lényegesen biztonságosabb a központi hitelesítés.

Ami akkor nagyszerű, hogy ha az alap infrához van egy külön jól elzárt valami, ami ezt megoldja. Itt most senki sem azt mondja, hogy ez rossz és elvetendő. kevés gépnél nem biztos, hogy akarsz vele foglalkozni, mert könnyű egy erős jelszavas lokális authot megvalósítani. Ha van mondjuk 20+ fizikai szervered, mellé 50 másik dolog amihez kell, akkor már felmerülhet jogosan, hogy legyen, de amiből egy ILO (értsd: bármi ouf-of-band menedzsment), egy storage authentikál, azt nagyon védeni kell, mert mindent visz, hogy ha megtalálják.

Ahhoz hogy a storage-hoz hozzáférjenek, nem elég kompromitálni az AD fiókot, hanem hozzáférésed kell hogy legyen a management hálózathoz is. Ha már hozzáférése van a management hálózathoz, akkor az AD nagyobb biztonságot jelent, mert megakadályozza hogy milliószor próbálkozzanak és transzparenssé teszi a kísérleteket.

Ha már HP és ILO, akkor ott egészen szigorúra vehető a hibás belépések vs. késleltetés/kizárás ideje. Ha az AD-hez hozzáfértek, és abba van bedrótozva a minden, akkor nincs millió próbálkozás, hanem ha elérik, akkor belépnek, illetve minimum nem fogod elérni őket, csak a mesterjelszóval.

Ez a mondat nem értelmes, ráadásul hazug is, ugyanis én nem figyelek reggelente LED-eket.

Viszont, jártam olyan helyen Budapesten óriásvállalatnál, ahol külön ember volt arra, hogy a sok ezer négyzetméteres saját géptermükben minden reggel körbement és az volt a dolga, hogy rack/polc/egység/diszkhely alapján felírogassa a hibás diszkeket.

trey @ gépház

Semmit sem szerkesztgettem, de biztos vagyok benne, hogy én olyat nem állítottam soha, hogy én minden reggel LED-eket nézek. Úgyhogy vagy valamit halutál, vagy nem tudom.

A "megint szerkesztgettél" balfaszságod meg megint nem tudom hova tenni. Nem szoktam szerkesztgetni. Ez inkább a te menekülésed.

De, olvassák kollégáim is az oldalt, kérdezed esetleg meg tőlük, hogy hányszor járok én LED-eket nézegetni. Szerintem beszarnak a röhögéstől ...

trey @ gépház

( eperede | 2023. 05. 12., p – 11:03 )

Szemmel láthatóan sajnos bizonyos események bekövetkezése esetén át lehet venni az irányítást a lokál infrastruktúra felett, főleg ha rosszul van mgoldva a rendszerek izolációja a külvilágtól és egymástól is.

Amennyiben az Active Directory fölött átvették az irányítást, akkor már nem sok esélye van a helyi rendszereknek, kivéve ha valami jó SIEM megoldás észreveszi és időben értesülnek a megfelelő emberek a gyanús műveletekről.

Amivel szerintem gyors sikert lehetne elérni biztonsági szempontból: Azure blob storage immutable opcióval és a backup-ok automatikus feltöltése. Nyilván a többi Cloud szolgáltatónak is van hasonló megoldása. Amennyiben ezt a szolgáltatást nem kötik be az AD-ba, tehát kvázi független a helyi infrastruktúra authorizációjától, akkor kivülről nem lehet letörölni, módosítani a mentéseket, csak feltölteni új backupokat.

Ráadásul még olcsó is a megoldás, csak kell rendes uplink és kész.

Ha nem kötik be az A(A)D-ba, akkor lőttek a passswordless autentikációnak, tehát le kell tárolni egy credential-t, amivel mindent vinni lehet.

Jelen esetben pont az AAD jelent védelmet, mert azt biztosan nem tudják megsemmisíteni, akkor sem ha a helyi DC-k alatt még a vhost-ot is kilövik.

De ahol egy hackercsoport heteken - hónapokon keresztül ki - bejár (én fenntartásokkal kezelem amit a CHS leírt, ha igaz, akkor nagyjából ez volt a helyzet), ott már feladták az utolsó kenetet.

( Proci85 v | 2023. 05. 13., szo – 22:08 )

Szerkesztve: 2023. 05. 13., szo – 22:09

'„A helyszínre érkezve először a mentő szervert vettük szemügyre. Ezt egy HPE ML350 G9-es hardver szolgálta ki, elkülönítve a mentendő infrastruktúrától."

"A szerverre belépve rögtön láttuk, hogy a teljes mentőszerver titkosítva van,"

 

Akkor ezt így hogy? Nem volt védett zónában a mentőszerver? Nem volt rendesen levédve, hogy egy fertőzött munkaállomásról/random céges szerverről ne lehessen hozzáférni?

Tudok olyan helyet, ahol bár odáig eljutottak hogy belül VLAN kéne és szeparálni a dolgokat, odáig már nem, hogy bármi filter is legyen, a cisco routeren oda-vissza bármilyen irányba ment a forward (management, office, free wifi, épület felügyelet, kamera, telefon). Évekig így ment a hely, amíg át nem vettük (akkor derült ki). Valszeg ez is ilyesmi csoda lehet.

"Sose a gép a hülye."

Mert kényelmi faktor van. Ahol épp hasonló szeparációs szorongásunk van, ott valami fantörpikus meggyőzési kiviteli dolgot kell a mindenféle ájtival foglalkozókon átvinni, még saját kollégán is. "Dehát ez így nagyon kényelmetlen, hogy fogunk így dolgozni." Mintha óránként 20x kéne belépegetni ILO-ra, storage-ra vagy bárhova. Egyébként itt nagyjából van szűrés, de csak van néhány dolgozói vlan, ahonnan elérhető volt minden.

( cadmagician | 2023. 05. 14., v – 20:21 )

csak tudnám mi ennyi adat? pornó?

Aki másnak vermet ás, az stack pointer.