Az ITBN 2023 rendezvényen volt többek között egy olyan előadása a munkáltatómnak, amelyet a Rubrikkal közösen tartott. Herceg András a Rubriktól elég velősen foglalkozott azzal, hogy mikor már nincs más lehetőség, mint az adatvagyon részének vagy egészének visszaállítása, akkor honnan tudjuk melyik az, amire érdemes visszaállni.
Preface: Mint minden ezen a blogon, a privát véleményem tükrözi. Ezt sajnos ismételnem kell, mert nehány vállalat képes ezt elfelejteni és megy a sértődés. Abban a remek helyzetben vagyok, hogy nem gyártónál dolgozom, azaz nem azért kapom a pénzt, hogy a takarmány kukoricáról is azt mondjam a piacon, hogy csemege.
Nem tudok elmenni a médiát megjárt, nagy disztribútor története mellett, ahol a SNAPSHOT mentette meg az adatokat, aminek tegyük hozzá semmi köze magához a tárolóhoz – ma már egy 80ezer forintos otthoni NAS is tud snapshot-ot készíteni – de még az alkalmazott mentőrendszerhez sem. Erről írtam egyet korábban és a tökéletes állatorvosi ló a témában.
Az, hogy nem írták fel a tároló admin felhasználójának a jelszavát egy dolog, de a Nimble nem használ snapshot-ot. A Nimble képes snapshot-ot készíteni, amit vagy a tároló ütemez maga vagy a tárolóval integrált rendszer ütemezi a tárolón. Jelen esetben gondolom az előbbi állt fent. A szalagos mentés semmit sem ér, ha nem veszik ki a szalagokat. Láttam már olyan támadást, ahol pontosan ugyanígy letörölte a támadó a szalagokat. Ráadásul az is, hogy ekkor a Nimble még nem tudott második faktort a saját admin felületén, az csak később került be a szoftverébe. Ez tényleg őrült szerencse volt.
Nyilatkozták, hogy örültek egy snapshotnak, hogy van MENTÉS. Mondjuk a snapshot nem mentés, de biztosan csak nyelvbotlás (akkor nem tévesztés, ha a Nimble tároló a Veeam alatt mint mentési célterület szolgált, akkor valós az állítás.)
Szóval:
- elfelejtették a Nimble admin-ját.
- rosszult volt megépítve a mentőrendszer.
- nem volt második faktor sem a mentőrendszerben, sem a tárolón – mert mondjuk nem is tudta még.
- nem vették ki a szalagokat a szalagkönyvtárból.
- nem volt vészhelyzeti forgatókönyv – hiszen csak később jöttek rá, hogy amúgy van snapshot.
Pont azok a pontok, amiket legalább el szoktam mondani bármelyik ügyfélnek, hogy mit ne.
És akkor jelen cikk magját alkotó apropó: Aztán pedig azt, hogy csak idő kérdése volt, hogy olyan snapshot-ra találjanak, ami még nem titkosított.
A fájdalom, hogy repetitív módon vissza kell tenni a mentéseket – a fenti esetben ugye az használhatatlan is volt egy az egyben – vagy a tárolón készül snapshot-okat és átnézegetni kézzel az ÖSSZES “mentett” szervert, share-t és egyebeket, hogy találjanak egy olyat, ami még nem fertőzött. Ehhez el kell indítani minden virtuális gépet például.
Itt óriási szerencséje volt a károsultnak, mert ha óránként készül egy snapshot, akkor csak 48-72 darabot kellett átnézni, ha naponta akkor meg 2-3 darabot. Csak ha éppen nem január végén jutottak volna be, hanem sokkal, mondjuk egy hónappal korábban, akkor lehet hogy 1000-ret – a Nimble annyi snapshot-ot tud kezelni – vagy több százat. Amíg megy a keresgetés, addig biztosan nem megy az üzlet, nincs eladás, gyártás, fejlesztés vagy bármi amihez amúgy az ügyfél az IT-ra hagyatkozik. Kérdés, hogy ez a fájdalmi küszöb kinél, hol van pontosan.
Aztán van a Rubrik
A Rubrik meg tudta volna-e akadályozni a fertőzést? Nem. Ez nem az ő feladata. Ez nem egy operációs rendszer oldali védelmi termék, Nem XDR, nem antivírus stb.
Amiben tudott volna segíteni:
- nem tudta volna kompromittálni a mentési megoldást a támadó.
- így, hogy a szalagos mentést, amiben a szalagokat NEM veszik ki a szalagkönyvtárból, ki tudta volna váltani, szalagkönyvtár nélkül.
- még fontosabb, hogy a fertőzés megjelenését követő első mentés után már jelezte volna, hogy zsarolóvírus van a rendszerben. Ezt a szóban forgó mentési megoldás nem tudja (igazából tudná ha be lett volna konfigurálva benne egy ehhez szükséges feladat), a HPE Nimble meg persze hogy nem, hiszen az egy tároló, neki a titkosított adat is ugyanolyan adat, mint az Oracle adatbázis.
Minden mentés után a Rubrik rendszer átnézi az elkészült példányokat és kutat olyan mintázatok után, amelyek valamilyen zsarolóvírusra utalnak. Nem küldi el az adatokat a felhőbe, hogy ott nézze meg valami, lokálisan vizsgál mindent. Ilyenek a nyilvánvaló kiterjesztések, a kevésbé nyilvánvaló szekvenciák a fájlokban, a fájlok tartalmának erős változása vagy éppen az entrópiában bekövetkezett erős változás. Már egy mentésből is meg tudja mondani ezeket, de mentések között is fel tudja vázolni, hogy terjedt szét mondjuk egy ilyen fertőzés.
Itt jegyzem meg, hogy amúgy a zöld gyártó termékeinek – nem a üres zöld téglalap, hanem a mentéses zöld gyártó – is híve vagyok. Ott hasonló képesség elérése azt igényli, hogy a mentéseket teszteljük egy feladattal, ami során a mount server-en becsatolódik a mentés és ott egy AV engine-nel nézi meg mi történik. Ugyanakkor statisztikát erről a mentések tekintetében nem tud előállítani.
Na itt pedig pont az történik, hogy a már lementett kópiát vizsgálja, anélkül, hogy becsatolná, elindítaná vagy végső soron, hogy bármit kéne vele nekünk csinálni. De ha ez az elmélet, akkor nézzük meg gyakorlatban!
Fertőzzünk meg valamit WannaCry-al
A teszt előkészítése során telepítettem egy Windows virtuális gépet, aminek a neve FS01. Óránkénti mentést állítottam be ár, amelyet a Rubrik szintjén létrehozott és a VM-hez direkt módon hozzárendelt “hourly” SLA domain végez el. Alább a “policy based” sorok jelentik az automatikus mentéseket, az “On demand” sorok azokat, amelyeket én magam végeztem el. A teszteket ráadásul kétszer ismételtem meg.
Ezek után a VM-et az eredeti WannaCry vírussal fertőztem meg olyan 09:54 környékén. A mentés természetesen továbbra is tökéletesen fut és futott is. Az időpont után következő mentések befejezését követően pár percen belül megjelent a Rubrik Security Cloud oldalán riasztás. Anomalous object!
Kattintva rá, elő is ugrik hol találta és melyik mentésben. Az FS01-es VM-ben talált 620 gyanús fájlt – 292 töröltet és 906 új fájlt – méghozzá a 09:55-kor készült mentésben.
A VM-re kattintva picit több részlet nyílik.
Sőt, akár a meghajtókat is ki lehet tallózni a pontos fájlok tekintetében. Az Administrator asztalán meg is jelenik pár fájl.
Persze a C meghajtó igen mutat némi elváltozást.
Hogyan döntsük el melyik mentés volt még ép? Rubrik esetén nem kell sokat dolgoznia senkiknek, hogy “rátaláljanak a legutolsó, nem korrupt mentésre.” mivel már már pár lépéssel előbb megmutatta hogy a 09:55-kor készült mentésben jelent meg és most így is járok el, a 09:40-kor készült mentés visszaállításával meg is oldom a problémát.
Ismételjük meg a fertőzést, azaz újra bejuttatom a vírust és újra tesztelem a Rubrik képességeit. 11:47-kor – alább látszik – kapta meg a WannaCry-t.
Készítettem is egy mentést gyorsan, mert türelmetlen vagyok és nem akarom megvárni az óránkénti ütemezettet. Nem kell sokat várni, hogy ismételten jelezze a problémát.
A visszaállításkor nem kell barkóbázni, egyből látszik mire kell visszaállni.
Összefoglalva
Tökéletes megoldás nincs, azonban jelentős különbség van a különböző mentési megoldások által adott képességek tekintetében, amelyek ha az általunk választott termékben nem elérhető, akkor azt vagy munkával vagy az RTO értékével fizetjük meg.
A vészhelyzeti terv nem vicc, mert anélkül nem lehet koordináltan és hatékonyan dolgozni, főleg akkor, ha a feladaton nem egy ember dolgozik. A rosszul felépített és üzemeltetett rendszeren semmi sem segít, nincs az a mentési rendszer ami olyat tudna.
(a kiemelt képet a leonardo.ai készítette)
