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

 ( kalmarr | 2018. március 13., kedd - 0:27 )

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

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

(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

Csaladi kepekre miert is kell samban irasjog?

A többi doksival együtt ez így alakult, de igaz, lehetne külön.

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

ZFS + snapshot egy jó megoldás.
Sőt, ezzel a kombinációval szépen megoldható, hogy az adott file előző verziója is visszaállíthatóvá válik.

Számunkra ez volt az egyetlen épeszű megoldás. Plusz virtuális gépeken dolgozunk, amikről van napi mentés, a desktop gép pedig innentől senkit sem érdekel, image van róla.

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.

Nem vagyok benne biztos, hogy ez minden ransomware-nél így van, de ebben az esetben segíthet a fail2ban.

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.)

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...

Atnevezes, titkositas.
Agyon kene korlatozni mindent az altalad javasoltak szerint, egyebkent megkerulheto lesz.

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...

https://github.com/zfsonlinux/zfs-auto-snapshot/tree/master/etc

Evvel alapból max 15 perc munka vész kárba, de hónapokkal ezelőttről is van snapshot, és mégse fog korlátlanul növekedni. Persze ezen lehet finomítani. A ZFS-ben az a jó, hogy simán elbírja.

Nálunk óránkénti van.

Igen, fantáziálni bármiről lehet, konkrét, üzem biztos megvalósítás kevesebb van. A rendszeres snapshot viszont nem fantázia, hanem működő dolog.

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.

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

Sűrűn változnak és sok a 00day vagy -1day ahogy tetszik. Az pedig igen nehezen védhető, hogy ha a juzer saját jogosultságának megfelelő "tevékenykedik".

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.

nagycici se kell, elég az, hogy legutolsó_penzügyi_kimutatás.xls, van aki erre gerjed :D

el_se_fogja_hinni_mi_tortent_miutan_sarka_kata.....exe

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.

btrfs+snapshot+backup?
https://btrfs.wiki.kernel.org/index.php/Incremental_Backup
vegul is hasonlo mint amit zfs-re irtak