Samba file verziók megörzése

Debian GNU/Linux

Hi!

Az egyik helyen bekaptak egy cryptolockert és a samba megosztáson lévő filekat is "lerendezte".
Nincs AD, csak munkacsoport és a 3-as samba.

Úgy hallottam, hogy a 4.1-es samba - btrfs-el -már "megkérhető" arra, hogy a file módosításakor az előző verziót őrizze meg. Igen, tudom, ez nem helyettesíti a biztonsági mentést és a víruskeresőt sem, de így a napon belüli adatvesztést is minimalizálni lehetne.

Tehát továbbra is munkacsoportos működésre lenne szükségem + a filok előző verzióinak a megtartására. Esetleg van valakinek ezzel talapsztalata? Érdekelne a véleménye, buktatók (pl. eszi a helyet ;-) ), esetleg egy jó leírás.

Más részről viszont úgy érzem, hogy "ágyúval verébre" a 4-es sambát 10 gépes munkacsoporthoz rakni, így a fenti feladat kapcsán felmerült bennem valamilyen NAS feltétele is, vagy ez meg nagyon alulméretezett lenne?
Mivel a NAS-okat semennyire sem ismerem, így azt sem tudom egyenlőre, hogy a file verziókat képes -e megtartani. Ha esetleg lenne ebben valakinek tapasztalata, azt is megköszönném.

Minden ötletet, észrevételt előre is köszönök!

  • 4518 megtekintés

( uid_3194 | 2016. 02. 25., cs – 09:32 )

Nem túlméretezés a 4-es samba a kis munkacsoporthoz sem. Én épp most üzemeltem be egyet egy 6 gépes munkacsoporthoz. (bár várható majd bővülés)Igaz ott van éjszakai mentés és víruskeresés is.
Kb ugyan annyira "bonyolult" beüzemelni a 4-es sambát, mint a hármast. Új telepítést már nem illik hármas sambával csinálni.

A btrfs-es dologgal nincs tapasztalatom.

--
Rózsár Gábor (muszashi)

Kb ugyan annyira "bonyolult" beüzemelni a 4-es sambát, mint a hármast.

Ezzel vitatkoznék, szerintem egyelőre még lényegesen egyszerűbb. Majd ha megint kezdődik, hogy házilag saját elképzelés szerint lehet legózni [Andrew Bartlet tartott az ilyen megoldásokról egy előadás, érdemes a slide-jait átfutni :) ] más rendszerekkel (openLDAP back-end, MIT kerberos back-end stb.)... :)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Ilyen kisvállalati pár gépes hálózatnál kb ugyan azt kell csinálni samba3 és samba4-nél is. Ezért írtam, hogy ugyan annyira "bonyolult".
Ugyan úgy megy write list read list valid user stb amivel az alap tulajdonságait be lehet lőni a megosztásnak, finomítani meg ACL-el.
A két smb.conf kb ugyan az.
Másra meg ilyen esetben nincs szükség, nincs ami bonyolítsa.
--
Rózsár Gábor (muszashi)

( gemnon v | 2016. 02. 25., cs – 09:39 )

Én is gondoltam már rá, hogy a Zenytal-ba bele kellene heggeszteni ez alapján, de még nem értem odáig. (bár ha jól olvastam 3.x-es samban is van shadow_copy2 vfs object)

( SzBlackY | 2016. 02. 25., cs – 09:58 )

Partszélről bekiabálás, mert még nem kísérleteztem vele:

_minden_ fájl verziót [ez gondolom egy close hívás lenne] megőrizni szerintem nem lehet hatékonyan. Az összes shadow copy VFS modul arra épít, hogy vannak snapshotjaid, a veszélyes benne, hogy a kliens kérheti snapshot létrehozását/törlését (és van olyan, ami utóbbit is meg tudja tenni) - a ransomware-k pedig be szoktak ezzel próbálkozni; vagyis ha egy admin jogú usernél esik be egy ilyen drágaság, akkor nem nyertél vele.

Amit esetleg tehetsz, hogy automatizáltan, időzítetten (pl. óránként, napi, heti) csinálsz snapshotokat a kiosztott fájlrendszerekről (pl. az openSUSE-féle snapper-rel, vfs modul is van hozzá), akkor is legrosszabb esetben az utolsó egy óra veszik el.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Szükségmegoldásként én is ezen a gyakori fs snapshot-on gondolkozom, de azért mennyivel elegánsabb lenne egy lista minden file korábbi verzióiról, jelezve melyik mikori és ki által íródott.
Helyspórolás jelleggel mondjuk lehetne őket ritkítani (pl. 1 héttel korábbról már elég az óránkénti utolsó verzió - ha volt is gyakoribb változás)

(egyébként sub)

----------------------------------^v--------------------------------------
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"

Nekem pont most volt egy ügyfélnél kérés, hogy amit aznap megírnak doksit azt másnap már ne lehessen módosítani, max más néven mentve. Így aztán éjfélkor minden fájlra megy az immutable bit. Ezzel mellékhatásként elértük, hogy max az utolsó 24 óra tud elveszni. :)

--
Rózsár Gábor (muszashi)

Samba-n nem tudom, de windows-on biztos, hogy nem kérheti kliens a VSS snapshot törlését, lehet akármilyen joga a share-re a usernek.
Én sokfelé üzemeltetek igy win szervereket, óránként VSS snapshot, a userek maguk tudják visszahozni a véletlenül felülirt/törölt fileokat (jobbklatty, előző verziók fül), akár több hétre visszamenőleg és nem az én időmet pazarolják az ilyesmivel. Tökéletesen üzemel, sok-sok éve.

Ööööö.... nem. :)

1.6-os fejezet: "The File Server Remote VSS Protocol is applicable in environments in which shadow-copy-aware applications store or manage data on remote file shares."

Ez nem arról szól, hogy egy fileszerver saját vss backupjait egy kliens kezelhesse, hanem hogy a saját VSS-aware alkalmazásod, saját VSS backupjait egy távoli fileszerveren tárold és kezeld.

De nagyon szivesen veszek egy példát, nemhogy egy távoli smb kliens, de akár helyben a szerverről hogyan törölsz egyetlen, adott VSS snapshotot ami egy adott könyvtár korábbi snapshotját tartalmazza. Tudomásom szerint erre még helyben a szerveren sincs lehetőség, nemhogy távolról.

Ööööö.... de. :)

Ez nem arról szól, hogy egy fileszerver saját vss backupjait egy kliens kezelhesse, hanem hogy a saját VSS-aware alkalmazásod, saját VSS backupjait egy távoli fileszerveren tárold és kezeld.

Nézz rá a diagramra a hármas fejezetben. És akkor vedd FSRVP kliensnek a diskshadow.exe-t [vagy a malware-t] és ott vagy, hogy a kliensed tudja kezelgetni a távoli szerver volume shadow-it.

pl. a Suse véleménye a témában: https://www.suse.com/documentation/sles-12/book_sle_admin/data/samba_ad…

De nagyon szivesen veszek egy példát, nemhogy egy távoli smb kliens, de akár helyben a szerverről hogyan törölsz egyetlen, adott VSS snapshotot ami egy adott könyvtár korábbi snapshotját tartalmazza.

vssadmin delete shadows https://technet.microsoft.com/en-us/library/cc788026.aspx?
És egy McCaffee lab-tól származó cikk, hogy használja is ransomware: https://blogs.mcafee.com/mcafee-labs/new-teslacrypt-ransomware-arrives-…

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

A helyben megoldást kérdezted ;)

A többit majd megnézem később, de biztos vagyok benne, hogy egy kliens nem fogja tudni törölni távolról a szerver vss backupjait.

Az mindenesetre gyanús, hogy az rpcclient-nek meg kell adni a snapshot GUID-et, a diskshadow-nak viszont nem -- ami egybe vág azzal, amit egy SambaXP-s előadásban (http://archive.sambaxp.org/fileadmin/user_upload/SambaXP2012-DATA/thu/t…) említettek ("Shadow copy identifiers need to be retained by the client - Strangely no shadow copy enumeration RPC"). Vagyis lehet, hogy az egyetlen "védelmi vonal", hogy nem lehet felsoroltatni az összes GUID-et, kiajánlva [netshareenum] pedig (tippre) csak a FSRVP-vel létrehozott snapshotok vannak.
Ha valamikor nagyon ráérek, feldobok egy WinSrv-t és kipróbálom, hogy helyileg létrehozott snapshot GUID alapján törölhető-e távolról.

Szerk.: Ha valamikor NAGYON NAGYON ráérek. 10586.0.151029-1700.TH2_RELEASE_SERVER_OEMRET_X64FRE_EN-US.ISO 2 nap, 12 óra van hátra.
Szerk 2.: Ez is jól indul... lejött az iso, összerakom a virtuális gépet, folyamatosan maxon hajtva a CPU-t megáll a telepítő töltő képernyőjénél... úgyhogy jön lefelé a WSrv2k12R2 iso...

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

OK, a lokálisban igazad van, nekem úgy rémlett, csak egyben lehet az összeset törölni.

A távolira nagyon kiváncsi vagyok mire jutsz. De szerintem még ha meg is tippelnéd a guid-et távolról, akkor sem lehet majd sima userként törölni távolról, max adminként, nyilván rpc-n is azonosit.

Az adminként stimmel, a szál kezdőhozzászólásában írtam is, hogy admin jog (ill. a samba doksi szerint backup operator is elég) kell hozzá ("vagyis ha egy admin jogú usernél esik be egy ilyen drágaság")

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Ennyi számomra már bőven elég, hogy biztonságosnak nevezzem ransomware-ek ellen a filszerveren történő ütemezett VSS backup-ot.
Ha a file szerveren egy mezei usernek admin vagy backup operator joga van, akkor az lesz a legkisebb probléma, hogy letörölheti a VSS backup-okat, nem életszerű.

Az az életszerű, hogy usereknek smb-n akár full access-ük is van adott share-ekre és hiába kapnak be egy ransomware-t, nem fogja tudni törölni a VSS backup-okat.

Ez pedig

"Vagyis lehet, hogy az egyetlen "védelmi vonal", hogy nem lehet felsoroltatni az összes GUID-et"

már egészen másként hangzik, ha hozzátesszük, hogy mellette legyen admin joga a file szerveren. Akkor ez már nagyon nem egyetlen védelmi vonal, hanem egy elég erős védelmi vonal (szerver oldalon admin jog igénye) kiegészitése egy újabb vonallal, hogy nem fogja tudni a guid-eket, amiket törölni szeretne, még akkor sem admin joga van a szerveren.

Úgy tűnik, igazad van, látszólag az fsrvp szerver valahol tárol magának egy ShadowCopySet listát az általa létrehozott SCS-ekről.

Első nekifutásra néhány tapasztalat:
* [virtuális gépből kézzel másolgatni a guid-okat masszív pita, amikor két különböző GUID kell 1-1 művelethez... :)]
* vssadmin-nal készült shadow copyt nem sikerült törölnöm, mivel nincs megosztáshoz kötve - majd feldobok egy ProcMon-t, hogy hol tárolhatja (szerencsére külön svchost alatt fut)
* vssadmin-nal létrehozott shadow copy-t az fsrvp az IsShadowCopied-dal nem tagadja le [sajnos az ExposeShadowCopySet önmagában nincs kivezetve az rpcclient-be, kipróbálnám egy nem az fsrvp-vel létrehozott shadow copy sethez mit szól]
* az fsrvp-vel létrehozott snapshotok nem jelennek meg az előző verziók közt, mert nem ClientAccessible-k (DataVolumeRollback típusúak), se helyileg, se távolról
* távolról létrehozott SC-nél az FSRVP-n visszaadott GUID-ok (Shadow Copy Set és Shadow Copy Id) megegyeznek a fájlrendszeren levő GUID-okkal - utóbbi a megosztás nevében is látszik, csak a Shadow Copy Set tűnik utólag nem felfedezhetőnek
* távolról létrehozott SC-t vssadmin nem hajlandó törölni, rossz kontextusra hivatkozva és próbáljam meg az azt létrehozó alkalmazásból törölni... diskshadowból működött a törlés... ami után bennragadt a létrehozott share. Amit kézzel eltávolítva az fsrvp még mindig mondogatta, hogy van a megosztáshoz tartozó shadow copy (ráadásul újraindítás után is, innen gondolom, hogy tárolja valahol perzisztens helyen is magának a mapet [3.1.1.1 szerinti GlobalShadowCopySetTable]).

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Hálásan köszönöm - minden érdeklődő nevében-, hogy kipróbáltad és megosztottad velünk!

Bár soha nem lehetünk nyugodtak, de ez most talán egy biztató irány. Btrfs-t még nézegetem és már van is pár kérdés, de az majd egy másik thread lesz.

Még egyszer köszönöm!!

Nincs mit, de a Samba-s implementációt ugyanígy érdemes lesz egy pár kört futtatni; ha a héten lesz rá alkalmam, megnézem. (első tippre az is rendben lesz, ott AFAIK alapból a snapshotoknak ugye nincsen GUID-je [shadow set guid meg végképp], tehát ott muszáj az fsrvp szervernek valahol tárolgatnia... megnézem)

Szerk.: belenéztem a Samba forrásba (source3/rpc_server/fss/srv_fss_agent.c), simán generálnak egy-egy új GUID-et a shadow copy set-hez és a shadow copy-hoz is (és ők is belapátolják egy tdb-be), úgyhogy rendben levőnek tűnik.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

( nvik | 2016. 02. 25., cs – 12:47 )

"Eretnek" gondolat lesz, de mukodik, es kb szopasmentes.

OSX Server, smb megosztas.
Csatlakozzanak erre a kliensek (bonusz hogy az egy kattintassal bekapcsolhato opendirectory okan az userkezelesed is nagyon kenyelmes lesz, valamint az ACL osszerakasaval sincs cumi, hanem katt-katt, GUI-rol....)
Snapshotok meg btrfs meg vfs objectek meg shadow copy helyett(amit a kovetkezo ransomware lehet hogy siman torol es/vagy titkosit ugyis), hasznald a time machinet a serveren egy kulso eszkozre, vagy akar egy nas-ra, vagy akar egy iscsi lemezre. Ezt a kliensek nem latjak, a rajtuk futo ransomware nem tudja titkositani, de keszul stabilan orankent biztonsagi mentes, inkrementalisan. Ezt a biztonsagi mentest a serveren gui-bol vagy akar ssh-n keresztul mondjuk mc-vel akar file-szinten elered, es barmit visszaallitasz totalisan szopasmentesen, a leheto legegyszerubb modon, tetszilegesen kivalasztott "snapshot"-bol.... (Ami amugy nem snapshot, hanem rendes masolat).

Igen, ezt használom is - máshol. De az törlésre vonatkozik nem?
Tehát, ha töröl egy filet, akkor átkerül a másik helyre. Bár nem ismerem a "csodavírus" működését, de ha megnyitja, majd ugyanoda visszaírja lekódolva, akkor nem történt törlés, ergo nem fog átkerülni a recycle területre.

( junior013 | 2016. 02. 26., p – 09:26 )

Mivel a jövőben nekem is szükségem lesz rá, kicsit utána olvastam, hogy ez a Samba VFS modul a Snapper-re épít és - samba doksi szerint - btrfs-re. De maga a snapper elvileg támogat ext4-et is.
Itt jön a kérdés: Manapság adattárolásra ext4 vagy btrfs?

----------------------------------^v--------------------------------------
"Probléma esetén nyomják meg a piros gombot és nyugodjanak békében!"