Címke: zsarolóvírus

Az alábbi történetet elsősorban céges ügyfeleknek ajánlom figyelmébe, de rengeteget tanulhatnak belőle a magán felhasználók is. Nehéz tapasztalatokkal indult a 2021-es évünk, sok átvirrasztott éjszakával, reménytelennek tűnő adathelyreállítási próbálkozásokkal, majd végeredményben egy tökéletesen kivitelezett zsaroló vírus támadás szinte szó szerint minden tapasztalatával. Ezeket a tapasztalatokat szeretném most megosztani mindenkivel, egyrészt segíteni felkészülni, másrészt kicsit jobban megérteni, belelátni abba hogyan is dolgoznak a csalók. Mivel ezúttal számtalan technikai tapasztalatot is szereztünk így a cikknek egyes részei, bekezdései kicsit száraz szakmai leírások lesznek, hogy ne maradjanak ki azok se a részletekből akik erre is kíváncsiak és értik is amiről beszélek. Azok számára, akiknek ezek a részek érdektelenek lehetnek majd igyekszem mindig felhívni a figyelmet hol érdemes tovább lépni. A szigorúan szakmai témakörrel rendelkező paragrafusokat ezért igyekszem majd piros háttérrel jelölni. Akit ez a rész nem érdekel nyugodtan ugorjon tovább a következő fejezetre.

Január első napjaiban történt meg egy ügyfelünk rendszerén, hogy egy sikeres behatolást követően zsarolóvírus áldozatává vált a szerver. Amit felhasználói oldalról tudni érdemes, hogy a gépen két ügyviteli szoftver volt használatban kb. 170GB-nyi adatbázissal, ezen felül kb. 500GB-nyi adat a fájl szerveren. Továbbiakban pár további technikai információ, akik számára nem releváns nyugodtan átugorható.

A gépen egy szinte teljesen naprakész Windows Server 2016 Essentials futott, ami legutóbb november végén volt frissítve, tehát mindössze a decemberi frissítések hiányoztak csak róla. A gépet a Windows Defender védte a vírusoktól, a Windows saját tűzfalával együtt ez felelt a védelemért. A külső tűzfal egy szolgáltató által biztosított router volt, mindössze az SSTP alapú VPN és egy RDP port volt továbbítva rajta a szerver felé, ezek közül az RDP a Windows saját tűzfalán korlátozva volt a helyi hálózat és egy publikus IP cím irányából. A brute force támadások ellen pedig egy RDP Defender szolgáltatás védte a gépet. A gépben egy RAID1 tükör védte a hardveres meghibásodástól az adatokat, a napi szintű biztonsági mentés a Windows saját beépített mentő szoftverével helyben készült egy különálló lemezre.

Magáról a támadás kezdetéről sajnos kevés információnk van, mivel a rendszer napló tanulsága szerint a hacker a támadás befejeztével egy külön erre a célra szolgáló programmal törölte a naplókat. Egy dolog biztos, hogy az egyik ügyvezető profiljával távoli asztaloztak be a gépre, tehát megtudták a név/jelszavát, nála a letöltések mappában megtaláltuk azokat az eszközöket, amiket a hacker használt a munkája során. A mappák időbélyege és a napló törlés alapján az egész tevékenysége kb. 20-25 percet vett igénybe.

Ez alatt az idő alatt a gépre belépve letöltött oda egy mappát néhány hasznos segédprogrammal. Első körben egy kis program segítségével kikapcsolta a Windows Defendert és a tűzfalat, így a védelem inaktív lett, ezt megelőzően pedig belenyúlhatott a tűzfal konfigurációjába is, mivel ott is találtunk több ismeretlen elemet. (A Defender egyébként a később telepített vírust felismerte volna, tehát ennek komoly jelentősége volt.) Vélhetően a következő körben tölthette le a többi, már kártékonynak is minősülő segédprogramot, melyek közül a legfontosabb elem a hacker körökben nagyon népszerű mimikatz.exe volt. Ez a kis segédprogram nem csinál mást, mint a gép memóriájából kiszedi az ott tárolt jelszó hash-eket (titkosított jelszavakat) és azokat elküldi a címtárnak. (Normál esetben egy billentyűzeten begépelt jelszót a gép titkosítva tárol be a memóriába, ezt a változatot küldi el és hasonlítja össze a címtár a saját, szintén titkosítva tárolt változatával. Ha egyezik, akkor megvan a hozzáférés.) Így már a következő körben sikerült a legmagasabb szintű admin jogosultságot is megszerezni a géphez, amivel megnyíltak a támadási lehetőségek. Több módosítást is felfedeztünk a címtárban, pl. a VPN-hez szinte minden címtárban lévő felhasználónak hozzáférést adtak, vélhetően egy esetleges visszatéréshez. Végezetül letöltöttek a gépre egy Disk wipe nevű, kimondottan adatmegsemmisítésre kifejlesztett segédprogramot, és elindították a mentéseket tároló lemezen, majd ezzel nagyjából egy időben indították a gépre töltött zsarolóvírust és közvetlen a kapcsolat bontása előtt egy naplókat módszeresen törlő alkalmazással törölték a nyomokat. A vírus elvégezte a feladatot (majdnem teljesen, de erről majd később), a Disk wipe pedig gyakorlatilag ment egy kört a backup lemezen.

A gépre való belépéskor nagyjából másfél órája futhatott a vírus, ami elég volt neki az adatok kb. 80-90%-ának a titkosítására, a biztonsági mentéseket tároló lemezen pedig akkor váltott 99%-ra a Disk wipe folyamat, amikor leállítottuk. Az első dolog, amit ilyenkor az ember ellenőriz és ezt ajánlom is mindenki figyelmébe, az a feladatkezelő. Miután az ügyvezető profilja be volt jelentkezve távoli asztallal és a neve alatt futott egy halom kártékony program így természetesen első körben a felhasználó került kijelentkeztetésre, majd következett a feltört tartományi adminisztrátor felhasználó futó folyamatainak ellenőrzése, ahol szintén volt egy futó példány a vírusból, ez is azonnal leállításra került. A javasolt eljárás ilyenkor mindig az, hogy a lehető legrövidebb idő alatt le kell állítani a gépet teljesen, ha nem értünk hozzá és biztosra akarunk menni (ez az otthoni felhasználóknak is egy jó tanács!), akkor inkább tépjük ki a gépből a tápkábelt és áramtalanítsuk le, a lényeg, hogy a vírus minden másodpercben adatot semmisít meg a gépen, így minden másodperc számít! Itt jól látható volt melyik folyamat végzi ezt, így annak kilövése után még pár perc gyors adatbegyűjtés következett, amivel elő lehet készülni míg a gép hozzánk kerül. Így végül távolról leállítottuk a gépet és jeleztük az ügyfélnek, hogy semmi esetre se kapcsolja vissza. Ezt követően egy olyan 3-4 nap vette kezdetét, amit az ellenségünknek sem kívánnánk.

A szervizbe szállítást követően első körben több helyreállító programmal is átvizsgáltuk a biztonsági másolatokat tároló lemezt, hiszen annak egy esetleges helyreállításával egy előző napi időpontra visszaállítható lett volna a teljes rendszer, adatokkal együtt. Ehhez végigpróbálgattuk a jól bevált GetDataBack, majd az R-Studio és az Easeus nevű gyártó legjobb adathelyreállító szoftvereit is, sajnos mindet reménytelenül. A legidegőrlőbb az egészben, hogy ezek a szoftverek egy teljes, mélyreható elemzést a lemezen (ami egy 1TB-s winchester volt jelen esetben) több órán át csinálnak, majd egyes esetekben a talált fájlstruktúra megnyitása is 1-1,5 órát igénybe vehet, a helyreállítás szintén és a végén legtöbbször kapunk egy kupac szemetet, sok haszontalan sérült adatot. Ez esetben még azt sem, mivel a Disk wipe-ot olyan jellegű adatmegsemmisítésre szokás használni, ami véletlenszerűen beleírva vagy különböző katonai szintű megoldásokkal, algoritmusokkal teszi tönkre a lemezen lévő adatokat. Később a piacon legnagyobb múltú adathelyreállítással foglalkozó cégtől, a Kürt Kft-től is ezt az információt kaptuk, de erről majd lentebb.

Amíg a backup lemezzel küzdött egy gépünk, addig utána jártunk pontosan, hogy mivel is állunk szemben. A RAID tükröt megbontottuk első körben és az egyik lemezt eredeti állapotában, egy esetleges későbbi adathelyreállítás céljából félretettük, a másik lemezen pedig egy teljes, offline vírusellenőrzést végeztünk el egy GData által készített boot lemezzel. A vírusirtó Crisys.E néven azonosította, később több témában jártas szakértő viszont a Phobos/Dharma egy Roger nevű variánsaként azonosította, ezt a nevét pedig onnan kapta, hogy .roger kiterjesztésűek voltak a fájlok, amiket generált. Ahogyan az ilyenkor lenni szokott és a témában jártas szakértők is egyből ezt javasolják, mi is ezt tettük, felkerestük a www.nomoreransom.org oldalt, ahol egyébként minta feltöltéssel is lehet segítséget kérni és ellenőrizhető pillanatok alatt, hogy az éppen aktuális vírusunk ellen van-e valami ellenszer. Ahogyan a legtöbb ilyen esetben szokott lenni, természetesen nem volt, illetve a pontos az, hogy jelenleg nincs. Ebből a vírus törzsből ugyanis 2016 óta heti 2-3 variáns jelenik meg, számos ilyennek közülük már felkerültek a titkosító kulcsai a netre, így tudtak rájuk decryptert (visszakódoló programot) írni. Itt ez sajnos nem volt meg. Mivel az eredeti Crisys és a Dharma vírusokra is vannak már különböző decrypter programok, gyártott ilyet az ESET, a Kaspersky, a Trend Micro, az Avast és még sokan mások, így természetesen ezeket is egyenként végigpróbálgattuk, de teljesen reménytelenül. Néhány órányi próbálkozás után sajnos bebizonyosodott az, amit jó néhány fórumon írtak, köztük legutóbb 2020. decemberében, ennek a vírusnak egyelőre nincsen megoldása. (Később lehet lesz, ilyenkor tehát érdemes egy időre elrakni a kódolt fájljainkat, mert egy nap még visszakaphatjuk őket.)

Végül kb. 20 munkaórányi adathelyreállítási kísérlet után fel kellett adni a harcot a backup lemezzel is, egyetlen program sem volt képes bármi használhatót visszanyerni belőle. Következhetett tehát az eltitkosított fájlokkal teleírt adatlemez, majd újabb többször több órás körök, melyek során a GetDataBack talált számtalan állapotot a fájlrendszerről, amiket egyenként kb. 1-1,5 óra alatt nyitott meg és kezdetben biztató eredményekkel, ugyanis néhány apróbb fájlt, az ügyviteli szoftverek konfigurációs állományait sikerült helyreállítani, de az öröm így sem tartott sokáig, ugyanis a nagyobb fájlok esetében jól láthatóan más állományok adatai jöttek vissza, azok is legtöbbször sérülten, tehát pl. egy szemmel láthatóan PDF állományt PDF-re átnevezve sem lehetett megnyitni, mert sérült volt.

Közben a közel egy nap alatt teljes vírusirtáson átesett másik lemezen elindult a Windows, számos, de nem végzetes sérüléssel, a vírus ugyanis a Windows mappát csak itt-ott bántotta, jellemzően ikonokat tett benne tönkre, így pl. egyes konzolok csak kikeresve a programokat voltak indíthatóak, viszont működtek. Fentebb esett róla szó, hogy szépen sorban mennyi módosítást találtunk a rendszeren, módosított VPN csoportot, módosított tűzfalkonfigurációt, a csoportházirend beállításokat teljesen hazavágta a vírus, kérdés előtte mihez nyúltak benne. Gyaníthatóan ezeken kívül is több aknát elhelyeztek a gépen, így egy néhány órás vizsgálat és helyreállítási próbálkozás után végül a teljes újraépítés mellett döntöttünk.

2 napnyi, mintegy 40 órányi reménytelen adathelyreállítási próbálkozás után, illetve még annak befejezése előtt elkezdtük a vészforgatókönyveket is végigjárni. Felvettük a kapcsolatot a Kürt Kft-vel, és egy ehhez hasonló vírusokra specializálódott ausztrál adathelyreállító céggel is. Még a második nap éjszakáján elment a levél a támadónak is, akinek a figyelmeztető üzenete a leírással, hogy mit kellene csinálnunk nem jelent meg, mivel a vírus még nem végzett, de az e-mail címe benne volt minden fájlnévben. A Kürt Kft-nél azt mondták ha nincsen visszafejtő kulcsunk az adatokhoz, akkor nem fognak tudni benne segíteni, a Disk wipe után a mentések biztosan nem jönnek vissza, a másik lemezre halvány reményt látnak, de nem sokat. Talán labor körülmények között a winchester megbontásával. Az ausztrál cég már biztatóbb volt, a kapcsolatfelvételt követően kértek tőlünk mintákat, majd visszaírtak, hogy 99% valószínűséggel vissza tudják állítani. Mindezt 4-7 munkanapos átfutással 6 ezer USA dollárból, vagy 48 órával picit több, mint 8 ezerből. A zsarolók mindössze 2 nappal később írtak csak vissza, előbb mintákat kértek, majd amint azt megkapták másnap megírták a követelést, 0.3 bitcoin (jelen árfolyamon picivel több, mint 3 millió forint) 2 napon belül fizetve, vagy 0.55 2 napon túl. Időközben egy személyes ismeretség útján beszéltünk egy szakértővel, aki a támadás módját is segített rekonstruálni, ezen kívül számos hasznos tanáccsal ellátott minket. Többek közt azzal is, hogy addig ne fizessünk senkinek, még adathelyreállító cégeknek sem, amíg nem láttunk rá bizonyítékot, hogy vissza is tudják állítani. Az ausztrálok sem ígértek ilyesmit, mindössze annyit ha nem sikerül nem kell fizetni, de vélhetően a módszerükből adódóan, hogy a helyreállítási kulcs megfejtésébe nem kevés számítási teljesítményt, egy szerver parkot fektetnek be, így a minta visszaküldése pont annyira munkaigényes, mint maga a visszafejtés. Nehéz dilemma, de tényleg nagy kérdés kiben és hogyan bízhatunk ezek után, kinek és hogyan merjünk ekkora pénzeket fizetni ilyen esetekben.

Végül egyiket sem választottuk, így ez a tapasztalat ezúttal elmaradt. 2 napnyi idegőrlő helyreállítási próbálkozás után a visszafejtést és az adathelyreállítást is fel kellett adni, és időközben a cégnek már dolgoznia is kellett volna, így sürgőssé vált a rendszer mielőbbi helyreállítása. Szerencsére a levelezésük nem sokkal korábban költözött át O365-be, így az végig biztonságban volt, belegondolni is rossz mi van, ha a korábbi rendszer szerint gépre vannak letöltve a levelek és azt is elintézi a vírus. Offline mentésük egy NAS-on volt, 1 évvel korábbról. A gyors beavatkozásnak köszönhetően az egyik ügyviteli program adatbázisait csak a 2010-es évig intézte el a vírus, így azokat a 2019. decemberi mentésből vissza lehetett állítani, így ez a szoftver, a cég szempontjából legfontosabb teljesen helyreállt. A fájl szerveren tárolt adatok esetében az R betűig jutott a mappák sorában, így az azt követőek megmenekültek, az R betű előttiek pedig szintén 2019-es állapotra voltak csak visszaállíthatóak. Szerencsére ezen állományok egy jó része már vagy feldolgozásra vagy elküldésre került, esetleg nyomtatva megvan, mások pedig itt-ott levélcsatolmányokból pótolhatóak. Ami nagyobb veszteség az a másik ügyviteli program, amiben így 1 évnyi adat hiányzik, önmagában ezért viszont már nem éri meg az adathelyreállító cégekkel kockáztatni. Azt pedig mi is, minden esetben hangsúlyozzuk, hogy aki csak teheti vagy nem az élete múlik rajta az ne fizessen soha bűnözőknek! Nem csak azért, mert ez motiválja ezeket az embereket, de szakértők arra figyelmeztetnek, hogy nagyon gyakran, az esetek 99%-ában csak a névtelen címre a bitcoin vándorol el, helyreállító kulcsot már nem kapunk. Az pedig a legrosszabb forgatókönyv.

Frissítés: a cikk írását követően, az eset után bő 2 héttel ismét írt a zsaroló, ezúttal alkut ajánlott, első körben 6.000 dollárért teljes visszaállítást kínálva.

Szomorú tapasztalatok, tanulságok

Sajnos a támadás kiindulási pontját továbbra is homály fedi. Az eredeti beállítások alapján túl sok opció viszont nem jöhet számításba, így ezek maradtak:

1. Adathalász módszerrel megszerezték az ügyvezető admin jogú fiókjának név/jelszavát.
2. Az egyik kliens gépet támadták meg és a belső hálózat irányából a szerzett jelszóval bejutottak a szerverre.
3. A home office miatt korábban beállított VPN elérések valamelyikét használták, egy betárolt és visszafejtett név/jelszóval bejutottak a belső hálózatra, ahonnan már elérhető volt a szerver távoli asztala.
4. Egy harmadik féltől származó eszköz sérülékenységét kihasználva jutottak a belső hálózatba.

A legelső opció a legvalószínűbb és sajnos az ellen a felhasználók biztonságtudatosságának oktatása mellett nem nagyon van más védekezési módunk. Ha kiadja valaki a felhasználónév/jelszavát egy olyan átverős levélre vagy weboldalra, amiből egyre profibb és egyre rafináltabbakkal találkozni, azzal nem sok mindent lehet kezdeni. A tavalyi évben az volt a tapasztalatunk, hogy rengeteg ilyen eset fordult elő, olyan is, amiről utólag tudomást szereztünk és félő, hogy számos olyan is van, amiről nem. A biztonságtudatos felhasználót már említettem, ezen felül jelen esetben két olyan dolog is van, amivel csökkenthető lett volna a kockázata ennek a lehetőségnek. Az egyik, hogyha rendszeresen jelszót kell cserélni. Ha kitudódik egy jelszó, akkor annak hosszabb távú felhasználását így lehet gátolni, persze nagy valószínűséggel ez esetben semmit sem segített volna. Viszont ha az ügyvezető nem rendelkezik admin jogokkal a rendszeren vélhetően a probléma nem áll elő, tehát az ügyvezetői profil admin jogkörrel való felruházása helyett érdemesebb lett volna egy különálló felhasználót (ami nem egy gyári fiók) ellátni inkább egy erős jelszóval, majd azt elzárva tartani olyan esetekre, amikre az ügyvezető a magasabb jogkört is kapta. Mivel ez a profil garantáltan nem lett volna sehol betárolva és adathalászattal se tudták volna kideríteni így megakadályozhatott volna egy sikeres támadást. A következő tanulság pedig, hogy nem szabad engedni a felhasználók nyomásának a biztonság terén. Nem csak ők, de mi magunk is komoly árat fizethetünk érte, jelen esetben számtalan átvirrasztott éjszakát és megszámlálhatatlan mennyiségű munkaórát, illetve elvesztett, nehezen visszaszerezhető adatokat. Számtalan esetben fordult már elő velünk, hogy a felhasználók nem akartak bonyolult jelszót, sőt jelszót sem, vagy mindenkinek ugyanazt, persze sose járjon le és ne is változzon. Ha nem erőltetjük rájuk akkor megváltoztatni sem fogják soha, ez is tapasztalat. A Microsoft ugyanakkor gyárilag nem véletlen követel meg bonyolult jelszavakat, nem engedi ugyanazokat jó darabig újra beállítani, a név egy részét megadni, és kötelezően változtatgatni kell rendszeresen. Ez nem ellenünk, éppen hogy értünk van. A brute force (próbálgatásos) támadások ellen ezek védenek csak. Nem szabad hagyni tehát magunkat és felpuhítani a jelszó biztonságot.

A céges kliens gépről történő betörésnek látom a 4 közül a legkisebb valószínűségét. Egyrészt a gépeket egy fizetős GData Business védte (egyedül magán a szerveren működött Windows Defender), ami egyrészt a piacon elérhető legjobb hatásfokú védelmet nyújtja és kifogástalan állapotban volt mindvégig, a rendszer visszaállításakor az ügynök program ismét jelentett az újratelepített szervernek és kifogástalan állapotban, aktív volt a védelem a gépen. A naplókban és a gépen magán sem volt semmi nyoma behatolásnak. Ráadásul a támadás egy vasárnap esti időszakban történt (bár lehetett időzített is) amikor elvileg nem tartózkodnak bent senki és ha jók az információink, akkor gép sem maradt bekapcsolva.

Sokkal nagyobb a valószínűsége hogyha kliens gépről érkezett a támadás akkor egy tartományon kívüli gépről, ami újabb kérdéseket és problémákat is felvet. Egyrészt amire szakértők is figyelmeztetnek most a világjárvány kapcsán, hogy a rengeteg home office munkavégzés arra ösztönzi a bűnözőket, hogy nagyobb hangsúlyt fektessenek a céges betörések, adatlopások során a sokkal gyengébben védett, támadhatóbb otthoni gépekre, amiket feltörve az azon tárolt hozzáférésekkel be lehet jutni a céges hálózatokba. Ugyan nagyvállalati környezetben régóta vannak ilyen jellegű megoldások is, pl. a Microsoft esetében ott van a NAP, ami nagyon régóta, a 2008-as Windows Server óta része a szerver rendszereiknek és lehetőség van korlátozni a hozzáférését pl. olyan gépeknek, amiken nincs naprakész vírusvédelem. Nagyon részletesen lehet szabályozni, de jellemzően nagyvállalati környezetben használt megoldás, a KKV-k esetében viszont gyakran még az sincs meg, hogy a dolgozójuk biztonságtudatosan használja a gépét, ne adja meg ismeretlen helyeken, levelekre a jelszavait, ne tárolja le őket, pláne ne jegyezze fel egy fájlban olvasható formában és mindig legyen a gépen naprakész vírusvédelem, anélkül egy lépést se tegyen. Abból is lehetőleg valami jobb fajta, de minimum a Windows 10-ben már alapból elérhető Defender. Sokszor ezek az alap dolgok sincsenek meg, viszont a gépre tárolva van egy szerverre csatlakozáshoz használt jelszó, ami így illetéktelen kezekbe kerülhet. A jelenlegi esetben akár egy tetszőleges felhasználó név/jelszava is kikerülhetett első körben, mivel a home office-ok miatt szinte mindenkinek volt VPN joga a rendszerhez. Amint valakinek kitudódott a jelszava a támadó máris házon belülre kerülhetett, ahol már számos kapu nyílt meg előtte. Ezen a ponton pedig muszáj megemlíteni még egy fontos és elég ijesztő dolgot. Nincs hibátlan szoftver, és feltörhetetlen operációs rendszer sem. Semmilyen. Korábbi cikkünkben írtunk egy ügyfélről, akinek konkrétan a D-Link NAS-át törték fel, ott szintén egy rendszer hibát tudtak kihasználni. Ugyanígy különböző protokollok és maga a Windows sem törhetetlen, ez ellen csak a rendszer naprakészen tartásával, rendszeres karbantartásával tudunk tenni. Viszont nagyon sok esetben például a fájl megosztást biztosító protokoll, a régi, erősen sebezhető SMB1 be van kapcsolva a szervereken, mivel egy régebbi hálózati szkenner nem hajlandó csak azzal működni. Sajnos ezt a protokollt pedig nem véletlen, hogy nem lehet szimplán visszakapcsolni, hanem szerepkörként telepíteni is kell a Windows-okra, ugyanis egy hatalmas biztonsági lyukat ütünk vele a rendszerre. Persze kihasználni csak egy helyi hálózaton futó vírus vagy egy bejutott hacker fogja tudni, egyébként nem férne senki hozzá. Az ilyen sebezhetőségek és azok a portok, amiket direkt nem publikálunk ki a netre viszont így mind támadhatóvá válnak, mivel a belső hálózatról érkezik a támadás, amitől védtelen a rendszer.

A negyedik pont is ide kapcsolódik. Amikor egy eszközt rákötünk a hálózatra, majd ahhoz az internet irányából hozzá szeretnénk férni, ahogy jelen esetben van egy felügyeletünkön kívül eső NAS, ami a tudtunk és megkérdezésünk nélkül kerülhetett be a hálózatba, ki tudja milyen jelszóval és hozzáféréssel, illetve egy szintén távoli elérésekre tervezett kamerarendszer is, az ilyen eszközök ugyanúgy lehetnek veszélyforrások. Jobb helyeken vállalati tűzfalakkal ezeket szokás VLAN-okkal elszeparálni, vagy ún. DMZ-be tenni, ami azért fontos, mert amikor egy ilyen eszközt egy ismert sérülékenységet kihasználva feltörnek és bejutnak rá, akkor arról nem tudnak a belső hálózaton további támadásokat indítani. A hálózatot több, egymástól elkülönített virtuális hálózatra lehet bontani, köztük a kommunikációt egy tűzfal ellenőrzi és ez akár portonként és IP címenként is korlátozható. Ezekről a témákról rövidesen egy újabb cikkben jelentkezünk, ahol részletezni fogjuk és bemutatjuk hogyan működik, miért fontos és egyre fontosabb téma ez manapság.

A jelenlegi incidenssel kapcsolatban pedig megfogalmazódnak még további ajánlások is. A SOHO eszközökkel szemben a profi, vállalati tűzfalak szerepét röviden érintettük is, ez szintén ide tartozik. Ezen felül viszont talán még fontosabb pár szót ejteni a mentésről is. A helyi mentés alapvetően egy jó dolog, stabil és gyors, a Windows beépített biztonsági mentés készítője is tökéletesen lekezeli, pillanatok alatt lehet belőle nagyobb mennyiségű adatot is helyreállítani és nem kell nagy mennyiségű adatot hálózaton keresztül küldeni. Ezzel szemben viszont nem véd a fizikai károktól (tűz, víz, betörés, stb.) és sajnos azokban az esetekben is bajba kerülhetünk hogyha a gépre magára jutnak be. Én azt szoktam mondani az már régen rossz, ha a szerverre be tudnak jutni, azt minden lehetséges módszerrel akadályozni kell, onnantól egyébként a helyi mentés is biztonságban van. Viszont amikor egy ilyen jellegű támadás ér minket, akkor csak ez a 3 dolog húzhat ki minket a bajból: 1. mentés 2. mentés 3. mentés

Ha nem áll rendelkezésünkre biztonsági másolat, akkor a mai zsarolóvírusok esetében szinte biztos, hogy vesztettünk. Az árnyékmásolatokat az első pillanatban elintézik. A fájlok eredeti törölt változatai pedig felül fognak íródni a kódolt változatokkal, bár komoly adathelyreállító cégek csillagász összegekért ha szerencsénk van még lehet tudnak benne segíteni. A decrypter eszközök használatára pedig ugyancsak nagyon minimális az esély, hacsak nem valami nagyon elavult vírust szedtünk össze, aminek volt valami hibája és így tudtak rá visszafejtő programot írni. Fizetni pedig csak a legreménytelenebb helyzetben fizessünk, semmi garancia rá, hogy vissza is kapjuk az adatokat, ráadásul a támadókat arra fogjuk vele ösztönözni, hogy folytassák ezt a tevékenységet és mások is ugyanígy járhassanak másnap. Az egyetlen mentőöv, ami ilyenkor segíthet az egy offline mentés vagy egy olyan megoldás, ami a szervertől távol, külső eszközön tárolja az adatokat és a gépnek nincs közvetlen hozzáférése ehhez a területhez, így a vírus nem tudja elintézni. Számos backup szoftver nyújt ilyen megoldásokat és megfelelő sávszélesség mellett a felhő is egy kiváló alternatíva lehet. Jó esetben itt lehetnek a legnagyobb biztonságban az adataink. Ha bizonyos időközönként mi magunknak készítünk egy külső adathordozóra manuális mentést az is lehet egy jó opció, bár ezt sajnos sok esetben, pl. adatbázisok mentésekor nehéz kivitelezni, inkább csak fájl szerveren tárolt adatok mentésére alkalmas megoldás. A lényeg, hogy legyen valamilyen elzárt mentésünk, mert amikor egy ilyen baj ér minket nincs nagyon más kapaszkodó. Az idő előrehaladtával pedig egyre kifinomultabbak lesznek a módszerek, és ahogyan a fenti példából, a számos esetből is látszik egyre gyakoribbak is az ilyen jellegű támadások.