Hatékony vírusírtás serveren és zsaroló vírusok

Linux-kezdő

Sziasztok,

az lenne a kérdésem, hogy hogyan lehet hatékonyan a vírusokat, kifejezetten a zsaroló vírusokat a serveremtől távol tartani? Azaz létezik-e olyan megoldás, ami egy ilyen jellegű vírust távol tud tartani (értelemszerűen a biztonsági mentésen felül). Pl: ha megfertőződik egy kliens gép, akkor az egész megosztást ne tudja megfertőzni, a SAMBA server ezt pl ne engedje. Ezt a profik hogyan oldják meg?

Lehet ez naiv kérdés, de hátha valamiről lemaradtam :)

Köszi!

Kalmi

  • 2720 megtekintés

( dlaszlo | 2018. 03. 13., k – 00:02 )

(A legfontosabb a rendes mentés szerintem.)

Samba: nem tudom mennyit ér, de pl samba alatt be lehet állítani, hogy egy könyvtár ne mutassa magát, csak akkor tudsz belelépni, ha tudod a könyvtár nevét.

Egyébként érdemes lehet egy time machine szerű mentést csinálni: egy nem felmountolt helyre mentést csinálni, pl rsync-el, de az előző mentést előtte hard linkekkel lemásolni, az előző X napot, Y hetet, Z hónapot megtartod, a többit törlöd, ami már nem kell (a legrégebbit törlöd, az eggyel korábbit a helyére mozgatod, az kettővel korábbit az egyel korábbi helyére, stb...). Amikor észreveszed, hogy egy zsaroló vírus lekódolt mindent, akkor előveheted az utolsó épkézláb állapotot.

Lehet hogy amatőr megoldás, de otthon a fenti két dologgal próbálom védeni a nas-on lévő családi képeket a zsaroló vírus ellen + mentés külső disk-re.

Csaladi kepekre miert is kell samban irasjog?
Az tipikusan olyan, hogy elkeszul, opcionalisan utolag allitod a szineket/fenyeket, es onnantol keszen van, normalis felhasznalas mellett nem modosul.

--
Any A.I. smart enough to pass a Turing test is smart enough to know to fail it. -Ian McDonald

( ncc1701 | 2018. 03. 13., k – 06:24 )

Az adatoknak zfs-en a helye, és használj snapshotot, és mentés kell legyen.

( freeoli v | 2018. 03. 13., k – 06:35 )

A samba támogat av lehetőséget aminek a logjara fail2ban konfigurálható de sajnos ez sem az igazi mert a minta nem biztos hogy benne lesz mire nálad tevékenykedni kezd.

Szerintem egy komplex szemléletmód segíthet leginkább a megelőzésben.

OS és app upgrade. Jogok szabályzása. Uac, emet, egy ssl kapcsolatot is szűrő utm akár opnsense akár fizetős sonicwall.

Talán elég, ha az írási műveletek periodikusoságát figyeli, erre van a VFS module:

https://www.samba.org/samba/docs/current/man-html/vfs_full_audit.8.html

Az jó kérdés, hogy a Ransomware hirtelen próbál-e ledarálni mindent, vagy szép lassan.

Kevés Ransomware-t láttam, ami képes volt privilégiumszint emelésre, jól beállított jogosultságokkal és up-to-date rendszerrel valószínűleg kicsi a kockázat.

"Az jó kérdés, hogy a Ransomware hirtelen próbál-e ledarálni mindent, vagy szép lassan."

Mint az őrült, ki letépte láncát (Unlock92 v2.0).
Az egyik szerver közelében voltam, amikor elkezdett dolgozni. Arra figyeltünk fel, hogy iszonyatosan elkezdtek kerregni a merevlemezek. Rövid idő alatt rengeteget elkódolt.

( mogorva v | 2018. 03. 13., k – 10:50 )

Félmegoldás: nálunk minden kép telefonnal készül (hogy mennyire szarok az most mindegy). A telókon van sync program, ami periodikusan scp-vel feltolja a képeket a szerverre, ott meg egy script szépen tovább másolja őket, stb.
A feltöltött képek böngészővel nézhetők.

Előnyök:
- talán (_talán_) scp-n át kevésbé mennek át a vírusok
- csak a legutóbbi sync óta készült dolgok vesznek el
- kevés a user/vírus számára nem readonly pont a folyamatban

Hátrányok:
- más esetekben (pl. gépen készülő dokumentumok, fényképezővel készült képek, stb.) macerás az upload
- még nincs bebizonyítva, hogy tényleg véd

(Ezen kívül a fontosnak ítélt dolgokról van egy rsync egy másik kerületben lévő másik NAS-ra.)

( sj | 2018. 03. 13., k – 18:51 )

a zsarolovirusok egy nagyon szemet problemat vetnek fel. Mert mi tortenik? Egy legitim felhasznalo (kozvetve?) elindit egy programot (=virus), ami modositja azokat a file-okat, amihez o jogosan hozzafer az o sajat gepen, meg akar a mount-olt meghajtokon.

Az szep, hogy zfs, meg snapshot, rendszeres mentesek, valamit ernek is, kb. mint ha baltaval operalnal: lehet, hogy elmulik a beteg labanak fajasa, csak az a baj, hogy a laba is. Bar jobb 1 labat elvesziteni, mint a beteget magat :-)

A felhasznalo gepen az lehetne egy valodi vedelem, ha be lehetne azt allitani, hogy pl. a .docx file-okat csak az msoffice irhatja. Vagy egy pdf file-t csak olvasni lehet, modositani nem. Szoval, ha az OS tudna, hogy melyik program akarja birizgalni a file-t, akkor eldonthetne, engedi, vagy beint.

--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...

Nem értem a "baltával operál" hasonlatot. Nem is azt mondtuk, hogy a zfs, snapshot meggyógyítja a beteget, de képes egy korábbi, még egészséges állapotot visszahozni. Igen, ettől még a betegség forrását detektálni kell, sőt, az esetlegesen többi megfertőződött klienst is gyógyítani kell.
Már az nagy dolog - imho -, hogy van olyan megoldás, ami esélyt ad a túlélésre (mert 0day sebezhetőség mindig lesz).

képes egy korábbi, még egészséges állapotot visszahozni

ugy ertem, ha van napi snapshot-od, amit azert tul hosszu history-val nem lehet csinalni, akkor ugrott az utolso napi munka (a szerveren). Felteve, hogy rogton masnap eszrevetted...

--
t-systems-es it architect allast keres. Jelige: csak webshopot ne kelljen...

( franklin | 2018. 03. 14., sze – 05:19 )

Ja, jó téma. Én csak arra az időszakra teszem hálózaton elérhetővé a mentőegységet amikor szinkronizálom a mentést. Utána hálózatról le, sőt, amelyik eszköz tud ilyet, még ki is kapcsolom, ütemezetten pedig be.

Annál nincs jobb, hogy nem tudja írni, mert be sincs kapcsolva. A szinkronizálás pedig több napra visszamenőleg történik amúgy sem árt néha ha esetleg később lehet észrevenni valamit.

Egy so-so ötlet, de a mentéshez a felhasználók úgyis csak olvasási joggal férnek hozzá, mert csak egyetlen helyről koordinálódik a mentés, az pedig egy külön felhasználóval (sajnos tudom ha már egy helyen belép lopható is) - csak arra fel, ha "keresni akarnak a mentésben" és "egyéni gépről kell menteni mert az ezer éves DOSos program nem hajlandó még subst-al sem menni).

Az a baj, hogy ezek jellemzően nem sérülékenységre épülnek, hanem egyszerűen arra, hogy a user futatt egy makrót tartalmazó xls-t.

Milliárd variáns van belőlük, a ransomware gyanús működést figyelő vírusirtókkal nincs jó tapasztalatom (legalábbis heterogén nagyvállalati környezetben).

Inkább a felhasználók oktatása és a jogok, binarisok (Windows oldalon AppLocker) korlátozása, ami hatékony.

( Raynes v | 2018. 03. 14., sze – 05:33 )

Az a baj, hogy a topikindítónak az egész alapvetése rossz. Azt már régen megette a fene, ha egy hálózaton a kliensek zsarolóvírussal fertőződhetnek, már hatalmas a bosszúság akkor is, ha a Samba-megosztásokat megvédtük. Így elsősorban arról kell gondoskodni, hogy már a klienseknél egy olyan védelmi vonal ki legyen építve (a rendszeres mentés mellett), hogy esélye ne legyen zsarolóvírusnak egyik kliensre mászni, pl. rendszeresen frissített antivírus, OS biztonsági frissítéseinek feltelepítése), stb.

Sambán egyébként be lehet állítani, hogy a kliensnek csak olvasási és felöltési joga legyen, de a már feltöltött anyagokat ne tudja módosítani.

„Pár marék nerd-et leszámítva kutyát se érdekel már 2016-ban a Linux. Persze, a Schönherz koliban biztos lehet villogni vele, de el kéne fogadni, ez már egy teljesen halott platform. Hagyjuk meg szervergépnek…” Aron1988@PH Fórum

Igen, baj, ha a cliens "elkaphat" valamit, de lássuk be, nincs 100% védelem, az emberi tényezőt nem lehet kizárni, még informatikusok között sem, nemhogy egy "hétköznapi" felhasználó esetében.

"Sambán egyébként be lehet állítani, hogy a kliensnek csak olvasási és felöltési joga legyen, de a már feltöltött anyagokat ne tudja módosítani."

Ezzel azt szeretnéd mondani, hogy a cliensre mentse le, majd ott dolgozzon rajta és ha vége akkor töltse vissza?

Sokat nem ér az antivírus sem. Én azért komolyabb összeget nem tennék rá. Viszont arra az userre igen, aki mindenáron meg akarja nyitni a nagycici.jpg-t, amit kapott.
Ezért írtam, zfs+snapshot, így max az utolsó snapshot óta eltelt változás vész el. Ha sok helyed van, teheted 5 percre is a snapshotok gyakoriságát.

( zz7 | 2018. 03. 14., sze – 09:38 )

Semmilyen vírusvédelem, se kliensen, se szerveren nem lesz 100%-os. Tehát azon kívül hogy ajánlott a használatuk, csak erre nem alapoznék.
Kell egy olyan fajta adatmentés aminek a területeit nem látják írás joggal a kliensek, vagy sehogy se. Ezt aztán sokféle módon meg lehet valósítani, ZFS snapshot, megfelelő SSH/rsync/hardlink mentő megoldások, olyan adatmentő rendszerek mint pl. urBackup stb.
És persze külön adatmentő gép, gépek és jó sok tárhely a fájl verziók őrzése miatt.

( dotnetlinux | 2019. 12. 21., szo – 11:34 )

Környezetemben két alkalommal futottunk bele, minket nem érintett - egyelőre. De már keressük a megoldást a detektálásra.

Mentés van, jó lenne időben észrevenni, ha álljunk le és kezdjük el használni a mentést. Erre vannak tool-ok, amelyek mass access/modify dolgokat észrevesznek (atim, mtime alapon), de félek tőle hogy nem minden ransomware kezd el tömegesen dolgozni.

Ezért gondolkodom azon, hogy rsync előtt rsync --stat -tal megnézem mi változott, majd azokban keresgélek mask-okat. docx, png, jpg, mysqldump és szabványos fájlokban kell hogy legyen valami identity mask, ami vélhetően megváltozik, amikor kódolásra kerül. Egy JPG olvashatatlan lesz, ha el van kódolva. 100e fájl esetén ha 100 módosul naponta már sokat mondok (adatbázisok többszor módosulnak, de a fájl alapú doksik nem tömegesen), rsync előtt végignézni nem lenne - elméletileg - nagy meló. Aztán mehetne egy alert, ha ha baj/jelenség van.

Mi erről a véleményetek?

Lásd az előttem szólót és az rdiff-backup nevű rsync alapú történetet. Desktop és Windows esetén a Veeam Agent very nyerő és ingyenes, és tud olyat, hogy "if media connected", meg "disconnect when done", úgy néz ki, hogy a malwares kódolós történetekre gondoltak rendesen. Ha sima rsync és a hely nem számít (vagy mert "végtelen" a backup, vagy mert 10G-s nagyságrendben kell menteni), akkor heti vagy akár havi szeparált mentés is lehet, esetleg úgy hogy a napi rdiff, de van egy külön sima rsync hetente mondjuk. Természetesen mindez minimum két helyre, azaz a mentésnek is legyen mentése és ami fontos, azt ki kell külön külső diszkre vagy bármire menteni ami szimpatikus.

( agostonl | 2019. 12. 21., szo – 16:51 )

Nálam, otthon, ZFS van és kétféle megoldással mentek.

Az egyik a ZFS snapshot, a másik az rsync. Mindkettő megoldás 7 napra visszamenőleg tárol.

Természetesen az rsync csak akkor mountolja fel a meghajtót, amikor ment.

Proxmox-ot használok, így a "nem adat meghajtók" mentését maga a proxmox végzi.

( •̀ᴗ•́)╭∩╮

"speciel a blockchain igenis hogy jó megoldás, ezért nagy erőkkel keressük hozzá a problémát"
"A picsat, az internet a porno es a macskas kepek tarolorandszere! : HJ"

Az élet ott kezdődik, amikor rájössz, hogy szart sem kell bizonyítanod senkinek

Ha meg akarod nevettetni Istent, készíts tervet!

( debtamas88 | 2019. 12. 21., szo – 18:13 )

Szerkesztve: 2019. 12. 21., szo – 22:17

Szia!

Kliens oldali védelem röviden,

Ransomware-k 99%-a cscript.exe-használja ki, ahol egy fájlba (doc,xls,stb) beágyaznak valamilyen scriptet pl.: JS (javascript) fájl, ami leszed valamilyen bináris fájlt valamilyen szerverről, és fertőz.

- Windows Script Host (cscript.exe) -> disable (regedit kulcsal lehet beállítani)
- Path Rules: Disallow
    %AppData%\*.exe
    %AppData%\*\*.exe
    %LocalAppData%\*.exe
    %LocalAppData%\*\*.exe
    %LocalAppData%\*.zip\*.exe
    %LocalAppData%\7z*\*.exe
    %LocalAppData%\Rar*\*.exe
    %TEMP%\*.exe
    %TEMP%\*\*.exe
    %TMP%\*.exe
    %TMP%\*\*.exe
    %UserProfile%Local Settings\*.exe
    %UserProfile%Local Settings\*\*.exe
    %UserProfile%Local Settings\Temp\*.zip\*.exe
    %UserProfile%Local Settings\Temp\7z*\*.exe
    %UserProfile%Local Settings\Temp\Rar*\*.exe
- Office-ben vbscript/makrók tiltása
- Fájltársítás: js, jse, vbs, vbe, wsh, wsf
        Application        nul

Fenti beállításoknak köszönhetően, egyes programok nem működnek (pl.: önkicsamogoló setup programok), azt kézzel kell felrakni.

 

Itt egy jó leírás erről:
http://www.bleepingcomputer.com/virus-removal/cryptolocker-ransomware-i…