Samba védelme a zsarolóvírusoktól

Security-all

Sziasztok!

Gondoltam nekilátok kialakítani valamilyen védelmet samba szerverhez ami zsarolóvírusoktól védi a megosztásokat. Mentés és snapshot természetesen van, ez azon felül működne.

Az alap elképzelés az, hogy az audit logging alapján kétféle dolgot lehetne figyelni, az egyik a kiterjesztés például „locky”, a másik pedig a túl sok átnevezés. Ezután egy fail2ban a tűzfalon tiltaná az IP-t. A kiterjesztést figyelni nem túl nehéz, arra már találtam a neten pl ezt:

https://techtalk.pcmatic.com/2016/09/15/54418/

Ehhez keresnem kell még egy kiterjesztés listát, ahogy olvasom és tapasztalom, az általános az, hogy egy kiterjesztés van, és nem dinamikusan generált. Persze egy új ransomware ellen ez nem jó, arra lenne a túl sok átnevezés figyelése, ami már kicsit nehezebb.

Ha valakinek van már ilyesmi működőmegoldása, vagy esetleg valamilyen linkje a neten ami bejött neki, megköszönném ha megosztaná, illetve ha használ ilyesmi megoldást a tapasztalat is érdekel.

Ha nincs akkor majd megosztom én ha kész lesz :)

  • 1403 megtekintés

( Tassadar v | 2021. 01. 09., szo – 11:37 )

Szerkesztve: 2021. 01. 09., szo – 11:50

Szerintem ezek hamis biztonságérzetet okoznak, valós védelem helyett. A snapshot és a backup is csak szerencsés esetben hatékony. 

Mi van akkor, ha nem nevezi át a fájlokat? Mennyi idő alatt leszel képes visszaállni, ha ránézésre nem tudod megállapítani, hogy melyik fájl érintett? 

Próbáld minél inkább korlátozni, szegregálni  jogosultságokat és ahol lehet, szorítsd ki az SMB/FTP/NFS-alapú megosztást. 

Üzleti oldalon legyen felelős, aki jóváhagy jogosultságot. 

Legyen foltozott a kiszolgáló és kliens infrastruktúra, fontold meg, hogy szükséges-e binárisokat és scripteket korlátlanul engedélyezni. 

A megközelítésed elméleti, az enyém meg gyakorlati. Részben egyetértek veled, de mondjuk a mentésről egészen más a tapasztalatom. Nem egy cégnél dolgozom, hanem külsősként soknál, és ahol közöm volt a mentéshez és bekaptak valami zsarolóvírust, kivétel nélkül mindig meg tudtuk oldani a dolgot, igen minimális adatvesztéssel. Szóval a mentés nem hamis egyáltalán. Olyan zsarolóvírust még nem láttam, ami nem nevezi át a fájlt, persze nincs simán lehet ilyen is.

A SMB pedig szvsz velünk fog élni még igen sokáig, és lehet hogy antihype, vagy eretnek gondolat, de én még mindig egy igen jól használható és olcsó megoldásnak tartom a problémaival együtt is. Azt meg nem gondolom, hogy ez a szűrő csodaszer lenne, sőt, de minél többféle a védelem annál jobb, és ha egyszer megcsinálom, percek alatt lehet beüzemelni bárhol.

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.

Előbb-utóbb csak észreveszi valaki, hogy gáz van. Ha más nem a backup scriptet logolásra kéred (pl. rsync log) és ha megugrott az előző napi log méret (sok fájlnál változott a checksum, ezért az rsync áthúzta), akkor riaszt rá a nagios.

Én ZFS-en csináltam samba-t, windows féle shadow copy megoldással. Azaz a user jobb katt, korábbi verziókra tud tallózni a snaphotok alapján elérhető korábbi fájl változatok között.

Az auto-snapshotok folyamatosan jönnek létre és halnak el, auto lejáratúak, egyre nagyobb megtartási idővel, valahogy igy:

5 perces snapshotok 1 óráig élnek
1 órás snapshotok 1 napig élnek
1 napi snapshotok 30 napig élnek
1 havi snapshotok 3 hónapig élnek
Ez csak a helyi shadow copy.

+ van egy bazi nagy backup szerver, rajta zfs, 2 évre minden nap zfs snapshot, napi mentéssel.

Az nem működik, hogy az ember létrehoz egy honepot könyvtárat, benne egy figyelt fájllal, és ha meg kell tudni, mikor történt a kompromittálás, akkor megnézi, hogy mikor romlott el a fájl tartalma?* (Meg persze a fájl tartalmát figyelni is lehet, ha változik, akkor baj van, mindent lehet RO remountolni és tolni az alertet).

* Feltételezem, hogy egy zsarolóvírus gyorsan megpróbál mindél több fájlt tönkretenni, nem pedig lassan és óvatosan.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Nem is a megelőzésre gondoltam, hanem arra, hogy ha füstöt tapasztalunk, akkor tudjuk, hogy az egyel korábbi mentéssel érdemes először próbálkozni.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

ahol lehet, szorítsd ki az SMB/FTP/NFS-alapú megosztást. 

Mi a javasolt ezek helyett, ha fájlrendszerként akarom látni a dolgokat? Vagy akkor mindegy, és valami fájl szintű webes dologra gondolsz helyettük, mint mondjuk egy Sharepoint?

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

Mi az use-case pontosan?

Rengeteg helyen látom, hogy valami gardróbnak tekintik és belecsesznek source code-ot, artifact-ot, build és test result-okat, milliónyi olyan dokumentumot, amiből ténylegesen csak párat használnak.

Mivel nem triviális jogosultságot delegálni benne, feleslegesen nagy halmazokat definiálnak. 

Szerintem az SMB felett lassan eljár az idő. 

Azért azt ugye tudod, hogy nem csak fejlesztő cégek léteznek :)

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.

Lehet egy csomó különböző use case, feltételezem, hogy vannak olyan helyzetek, amikor fájlrendszer kell és más helyzetek, amikor nem kell fájlrendszer. Feltételezem, hogy a zsarolóvírus csak a fájlrendszerként elérhető dolgokban tud kárt tenni. A kérdésem az volt, hogy az SMB/NFS/FTP(?) kiszorítása azt jelenti, hogy lecseréli az ember ezeket valami más hálózatos fájlrendszerre, ami valamilyen szempontból előnyösebb/biztonságosabb, vagy itt arra gondoltál, hogy ha nem muszáj, akkor ne legyen fájlrendszer? (Mondjuk az FTP-t azt nem értem. Az nem fájlrendszer, nem tudok róla, hogy a zsarolóvírusok ftp szerveren tárolt dolgokhoz hozzáfértek).

Nálam az a use case, hogy van egy NAS, aminek a megosztását NFS-en mountolom fel. Az, hogy fájlrendszerként látszik, az lehetővé tesz olyan dolgokat, mint pl. updatedb és locate, vagy pl. a Steam library nem a (kicsi) ssd-n van, hanem egy symlink a NAS felmountolt megosztásába mutat bele.

De mondhatnám azt is példának, hogy volt olyan munkahelyi gépem, ami a bootoláskor a /usr-t NFS-t használva mountolta fel egy központi helyről (persze a /usr read-only volt, szóval a zsarolóvírus szempontjából emiatt se kockázat meg amiatt sem mert a fs sérülése esetén simán helyre lehet állítani a tartalmát a csomagok ismételt feltelepítésével).

Gondolom másoknak más use case-ei vannak, de szerintem ne ezen akadjunk most el!

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

A snapshot és a backup is csak szerencsés esetben hatékony. 

Nem értek egyet. Még az első zsaroló vírus megjelenése előtt csináltam egy ügyfelemnek rsnapshot alapú mentést. Rég volt, kopnak az emlékek, de kb az utolsó 30 mentés fért el a diszken.

Egy nap hívnak, hogy az egyik gépük bekapott egy zsaroló vírust, és az összes általa írható megosztásban lekódolta a fájlokat. Nem volt nehéz kikeresni az utolsó tiszta mentést, és visszamásolni. (persze másnap is ugyanez történt, utána újrahúzták a windowst)

> ránézésre nem tudod megállapítani, hogy melyik fájl érintett? 

nalam naponta lefut egy rsync egy masik tarhelyre, es errol a log filet elkuldi emailben, a valtozott fileok listajaval. ha ranezesre gyanus akkor backup vissza es max 1 napi change veszik el...

sambaval az a baj, hogy torlesnel at tudja rakni trashbin-be, de modositas eseten ugy tudom nem.

amugy mindig atnevezik a g@cik es olyat is lattam mar, hogy a kiterjesztes valami random 5-6 karakter volt.

kaspersky altalaban 5-10 file atnevezes utan elkapja, de azokat mar nem tudja helyreallitani, backupbol kellett.

a sok atnevezesre IP tiltas amugy jo otlet...

> szorítsd ki az SMB/FTP/NFS-alapú megosztást. 

es mit javasolsz helyette? taroljanak papiron mindent? vagy a local gepen, backup nelkul?

pont hogy az a jobb irany hogy a szerveren legyen minden, es ott keszuljon surun snapshot es backup...

Milyen collaboration share az amin a felhasznalok nem tudnak irni?

Pl. webes alkalmazások.

Most csak egy példa: ha Mancika munkája Google Drive-on lévő dokumentumok szerkesztése mondjuk Google Sheets használatával, akkor a zsarolóvírus ahhoz nem fér hozzá (ha nincs a Drive tartalma szinkronizálva a helyi gépre). Ugyanez, gondolom Sharepoint és Online Office programokkal, vagy bármilyen olyan dokumentum kezelő rendszerrel, amiben a webes felületen a workflow-t követve lehet csak haladni (ennek a kategóriának nem jut eszembe a neve, de tudjátok, mire gondolok bizonyára).

Most megpróbáltam felidézni, mikor dolgoztam utoljára olyan helyen, ahol fájlrendszerként volt felmountolva bármi. Munkára 2007-ben már biztos Sharepointot használtunk, annál csak korábbi emlékem van olyan (de évszámot nem tudok pontosan, talán 2002-2004 körül lehetett) amikor fájlrendszert mountoltam. Illetve lehet, hogy volt egy cég 2009-ben, ahol szintén, de nem emlékszem rá tisztán.

2007-ig az akkori munkahelyem adott személyes samba tárhelyet, ahová az ember a saját cuccait fel tudta tolni. Ami oda fel volt töltve, arról készült mentés, más dolgaihoz nem fértünk hozzá.

Olyan volt, hogy pl. source control hozzám szinkronizált egy halom könyvtárat, amit egy vírus felülírhatott volna és én ha nem veszem észre, committolhattam volna (de persze ezt egyszerű visszacsinálni). Az is rémlik, hogy Sharepoint-on megosztott könyvtárakat szintén fájlrendszerbe szinkronizált valami, de a SharePoint is tárol verziókat, szóval ott se lenne nehéz a visszaállítás, és nem emlékszem már, de mintha nem is lehetett volna csak úgy felülírni a fájlokat, ha az ember nem követte a webes felületen is használt workflow-t, vagyis checkout, változtatás, checkin.

disclaimer: ha valamit beidéztem és alá írtam valamit, akkor a válaszom a beidézett szövegre vonatkozik és nem mindenféle más, random dolgokra.

( dlaszlo | 2021. 01. 09., szo – 12:04 )

Nem megoldás, és nem alapoznék rá semmit, de azért bekapcsoltam: meg lehet mondani a sambában, hogy melyik könyvtárakat ne listázza a samba. Csak belépni lehet ezekbe a könyvtárakba, de ismerni kell a könyvtárnevet. Így egy butább zsarolóvírus esetleg nehezebben talál rá ezekben lévő fájlokra, persze nem hiszem, hogy nehéz megkerülni ezt.

Amúgy én mentéssel védekezek.

( zrubi v | 2021. 01. 09., szo – 15:57 )

Gondoltam nekilátok kialakítani valamilyen védelmet samba szerverhez ami zsarolóvírusoktól védi a megosztásokat

good luck ;)

 

Ezután egy fail2ban a tűzfalon tiltaná az IP-t

Ez nem tudk kidobni egy már bejelentkezett (aktív TCP session-nal rendelkező) usert.

A probléma az, hogy ezt NEM igazán lehet szerver oldalról megvédeni. Ha egyszer kiadtad az adott foldert a usernek - és az írni is tudja - akkor ennyi. A kliens innentől azt csinál a fájlokkal amit akar. És mivel a vírus a kliens-en aktiválódik, azt kell(ene) megvédeni.

 

Szerver oldalról amit tehetsz az, hogy vezió követed az állományokat, így megmarad a korábbi x verzió. Ez nem csak vírus ellen véd, hanem user error ellen is. - de a SAMBA ilyet alapból biztosan nem tud. Nextcloud - és egyéb Enterprise szintű cuccok tudják ezt - de cserébe lassúak is.

zrubi.hu

Ez nem tudk kidobni egy már bejelentkezett (aktív TCP session-nal rendelkező) usert.

Erre tényleg nem gondoltam, kell valami reset elé, pl. samba restart, az meg nem túl szép.

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.

Nincs konkrét, általános megoldással próbálkozom.

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.

( debtamas88 | 2021. 01. 09., szo – 16:44 )

Szerkesztve: 2021. 01. 09., szo – 16:48

Szia!

Ebben a topikban volt róla már szó:
https://hup.hu/node/146211

Szerver oldalon:
- Kiterjesztés figyelése:
https://gallery.technet.microsoft.com/scriptcenter/protect-your-file-se…
Ez lézetik Samba alatt is, ezt felhasználhatod mint "template-t".
- Samba config ( smb.conf ) példa
[Folder]
Veto files = /*.exe/*.com/*.dll/*.bat/*.vbs/*.tmp/*.mp3/*.avi/*.mp4/*.wmv/*.wma/

Kliens oldali védelem:
- Mindegyik kliensre kell naprakész vírusírtó,
- GPO policy, ami megakadályozza .exe fájlok futtatását:
%LocalAppData%\*.exe
%AppData%\*\*.exe
%LocalAppData%\*\*.exe
%Temp%\*.exe
%Temp%\*\*.exe
UserProfile%\*\*.exe
...
erről itt van egy bővebb leírás:
http://woshub.com/how-to-block-viruses-and-ransomware-using-software-re…

- GPO policy a Windows Script Host letiltása ( wscript.exe ):
    HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Script Host\Settings\
        > Enabled 0
- GPO policy ( js, jse, vbs, vbe, wsf, wsh ) fájlok társítása egy "nemlétező" programohoz: nul
        > Computer Configuration > Preferences > Control Panel Settings > Folder Options
            > js ( ACTION: Update; Actions: open; Application used to perform action: nul)
            > jse ...
            > vbs ...
            > vbe ...
            > wsf ...
            > wsh ...

Összefoglalva:
- Szerver oldalon nem implementálnék semmit, mert pl.: kivételkezelést lehetetlenné teszi.
- Kliens oldalon kell implementálni a védelmet, fenti beállítások miatt bizonyos programok ( pl.: telepítők amik önkicsomagolósak ) nem fognak működni, erre az a megoldás hogy kézzel kell kicsomagolni egy mappába, és onnan indítani.

        
       

Köszi, átnézem.

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.

( dentzol | 2021. 01. 09., szo – 16:58 )

Mielőtt feltalálod újra a melegvizet érdemes megnézni mit talál a google a SIEM és SOAR kulcsszavakra.

Szép dolog az elmélet, meg van a gyakorlat...

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.

( ppenta | 2021. 01. 09., szo – 20:35 )

+ egy jótanács. Legyen a cégnél policy, hogy userek a gépüket hosszabb időre elhagyás esetén kapcsolják ki. Éjszakára mindenképp. Így nem lesz 8-12 vagy több órája futni a zsaroló vírusnak.

Hármas........alá............kettes.........................egyest írtam be.

A legutóbbi esetemnél egy "elfelejtett" gép volt, W7 + RDP távolról, nem használták semmire de ment. Szerencsére napközben történt, és én mindig használok/használtatok a samban-n audit logging-ot, így hamar ment a levesebe a gép. Külsős vagyok, főleg KKV-knél, ott a szigorú policy az esetek többségében mission imposible :)

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.

Azért a probléma összetett kissé. Az egy dolog, hogy a széleskörű olvasási és főleg írási jogú felhasználó tarol a hálózaton (nálunk anno a HR-en nyitottak meg remek RAR-ból önéletrajzot...). Nem 1-2 óra volt a visszaállítás. Azóta a probléma annyiban fejlődött, hogy még ha GP-ból ott a kötelező update (mondjuk mert óvatos vagy 3 nappal késleltetve...), akkor simán előfordulhat, hogy minimum lokál admin jogot szerez a virnyák és esetleg nekiáll terjedni a hálózaton és minden gépen lokál admin lesz. Bazira nehéz a védekezés, amik nekem jutnak eszembe:

  • az alfa és omega, hogy minden uptodate legyen sw-ből és ne is legyen suppport nélküli sw a hálózaton, gondolom már itt mindenki elvérzik (jajj kell a win7 valamihez, jajj a régi sw-ből nincs is már új stb stb)
  • miután elvéreztünk az első ponton, jön a felhasználók oktatása, emailben, élőben és mindenhogy, de valszin van olyan trükk, amit bárki (szó szerint) megszívhat
  • a korábban írtakkal, hogy a jogosultságok minimálison tartása és ilyesmik, abszolút egyetértek, de ezt néha a főnök torkán igen nehéz letoltni (dehátférjekmárhozzá...) (kiegészítés, még GDPR szempontból is hasznos)
  • miután közel háromszor elvéreztünk az emberi tényezőn, utána mindenféle GP beállítással (ha nem Windows, akkor annak megfelelő szigorúságokkal) próbálkozhatunk legalább keretek közé szorítani a dolgot
  • mentésből mindenképp inkrementális, lehetőség szerint több helyre, én személy szerint vagy rdiff-backup-olok vagy Veeam-elek, ÉS ha hajlandóak rá áldozni akkor adott időnként külső diszkre (vagy többre) offline mentés készül, de ez sem felülírósan

Az sem árt, ha a felhasználók készítenek a szuperfontos cuccokról, hiszen ők tudják mi a fontos, mi csak egy bazinagy adathalmazt látunk, legalább havonta egy külön offline mentést. Legyen ez könyvelés, ügyfélnyilvántartás, a béranyagok, szerződések, bármi. Egy külső diszk ára egy vicc ahhoz képest, amit egy felszippantott virnyák okozhat, de egyszerűen még 2020-ban sem érzik, hogy _mindenük_ a "francos" IT infrán múlik. Sajnos óriási lemaradást látok a fejekben, nem veszik komolyan, nem hajlandóak rá áldozni és mindenféle bugyuta dolgokkal fárasztanak, azaz próbálnak, ha nekik nem fontos, hát akkor nem az.

Az ismerősöknek, kollégáknak azt szoktam mondani, hogy nem lehet fillérekért a panaszkodó (akár Ügyfél, akár nem) teljes IT problémáját a nyakunkba venni (rendszerint láthatóan valami nem ránk tartozó problémát próbál áttolni), mert láthatóan nincs elképzelése sem. Ez utóbbi persze érthető, de arra sincs gondja, hogy oké nem értek hozzá, és megfizetek valakit, aki legalább alapszinten összehoz valami nagyjából működőt. Ezek kiegészítése, hogy amikor hallják ezeket, akkor "jajjhát ne fárassz már, úgysem lesz", hát oké, akkor nem lesz, nekünk van melónk elég, de ne is tajtékozz, amikor beüt a ménkő.

( gheja | 2021. 01. 10., v – 12:16 )

Ha átnevezést figyelsz, azzal eléggé mellélőhetsz, mert ezek szerintem inkább letöltik, titkosítják, majd törlik az eredetit és feltöltik a titkosított verziót.

Plusz ha ilyet detektálsz és tényleg fontosak az adatok, szerintem inkább lődd le a teljes szolgáltatást és vizsgáld ki kézzel.

Néztem már több samba logot ilyen után, eddig kivétel nélkül felülír+átnevez volt, törlés sosem.

A teljes leállításon is gondolkodom, az sem rossz ötlet, akkor nem kell a tűzfalon küzdeni.

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.

Én nemrég láttam ilyet saját szememmel.

Az a féreg először létrehozta a letitkosított új állományt, amikor elkészült

az eredeti forrás állományt feltöltötte 0-val, majd letörölte.

Ami tulajdonképpen logikus is, esélyt sem hagyott local diskről visszahozni a cuccot.

Nem tudod véletlenül, hogy melyik locker volt az?

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.

( x-daemon | 2021. 01. 11., h – 14:07 )

tudom hogy nem ez volt a kerdes, de en az uzletileg fontos fajlokat a vallalatiranyitasi rendszer iratkezelojeben tarolnam, azt sql-en keresztul eri el a kliens igy ott egyelore (mig nincs evolucios nyomas a tul keves fertozes miatt a titkosito programok iroin) vedve van.

neked aztan fura humorod van...

Én is ott tárolnám, de egy 10 fős KKV-nél nem, hogy vállalatirányítási rendszer, gyakran még sql sincs :) A Seafile, meg a NextCloud elég jó, de van ahol még ez is felesleges.

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.

( YleGreg | 2021. 01. 11., h – 19:25 )

Otthoni sambanal e ugy oldottam meg, hogy ket megosztas erheto el az egesz (nagy) csalad reszere: egy "irhato" es egy "olvashato" nevu. Barki irhat az irhatoba, feltolthet barmit amit kozkincse akar tenni (film, sorozat, zene) es en azt idonkent atrakom az olvashatoba, ami samba szinten read-only.

Nincs nagy felhasznalas, viszont ami at van rakva, az meg van vedve.

Ceges hasznalatra, dokumentum tarnak nem jo ez a megoldas, de falura elmegy.

+1

Egy helyen, egy cégnél a projektek könyvtárai, amikhez már régebben nem nyúltak, kerülnek az archív mappába, ahol írásvédetté válnak. Az aktuális projekteken talán észreveszik, ha egy vírus átment, azt vissza lehet állítani mentésből. 

Jó dolog az írásvédett könyvtár. És nem csak a vírusok ellen.