Fórumok
Sziasztok,
Samba fileserveren kompromittálódott egy megosztás ramsomware által.
A fájlok szokás szerint új kiterjesztést kaptak (xyz.typo) ergo új fájlok-nak tekinthetők.
Sajnos későn szóltak és elindult egy mentés rsync-el a szerverről, és a helyett, hogy ezeket az "új" fájlokat másolta volna, felülírásra kerültek a már meglévő rendes fájlok a mentésben...
Ezt nem értem.
Az rsync logban is új fájl transfer látszik...:
<f+++++++++
Hozzászólások
Mármint mit ?
Az rsync, ahogy a neve is mondja alapból syncronban tartja a dolgokat. Azaz ha egy fájlt átnevezek, és rsyncelem akkor a átmásolodik a régi meg törlésre kerül, hogy syncronban legyen az eredetivel.
Fedora 41, Thinkpad x280
Nem így tudom.
Az rsync alapból nem bántja a már a targeten lévő dolgokat, pont ezért van külön --delete kapcsolója...amit még "finomíthatsz" is:
stb....
..és nem a delete kapcsolóval ment az rsync természetesen.
Új kiterjesztést kapott a forrás file azaz az már más fájl...ezért nem értem.
rsync manualból, nemtom mennyire friss, első találat:
ps1.: jah közbe látom a 3.X.X -től elvileg már nincs ilyen defaultból, de erre nem vennék mérget.
Szerintem ez csak arra vonatkozhat, ha használod a --delete kapcsolót, akkor lesz --delete-before az alapértelmezés.
Ha nincs külön delete kapcsoló akkor a targeten (destination) nem töröl semmit sem.
btw ez kiderülthet gyorsan, ha azonos verziót meg tudsz nézni és azonos rsync kapcsoló paraméterekkel tudsz csinálni egy tesztet, akár "lokálisan".
Létrehozol egy bármilyen mappát, beleraksz pár sima file-t + dirt ,akár üreset. Ezt lesync-eled a backup scriptes paraméterekkel. Utána fogod átnezed a forrásnál az egyik fájlt, ráengeded újra a scriptet és kiderül, hogy az rsync cseszett-e el valamit, vagy valami más.
hogy kicsit "ontopic" legyek :)
Ezen túl vagyok, ezért mondtam, hogy nem töröl semmit a targeten...meg ezt is tapasztaltam már régen is, de természetesen most lepróbáltam
szinkronban. Bocsi, de nagyon fájt olvasni.
Btrfs/zfs snapshot?
Rsync helyett meg legalább rdiff-backup , de inkább borg/vagy mi a másik ami nekem nem tetszett talán restic?
Amúgy hogy valami on is legyen ha nem lett felülírva akkor az undelete lehet segít.
Off: Érdekelne, hogy mi nem tetszett neked a restic-ben. Pár hete átmigráltam rá borgról, és eddig elégedett vagyok vele.
Nincs semmi amit fel tudok ellene hozni. Ez a nincs pénz semmire közszféra és váltásnál (nem most volt) valahol akkor olvastam , hogy több ramot zabál mint a borg és nincs több ram ;)
Lehet ettől sokkal jobb mint a borg, de az rdiff-backupnál az is jobb. ;)
Engem meg az érdekelne, hogy miért váltottál borg-ról restic-re?
Mostanában nézegetem mit kellene felvenni a repertoárba ügyfeleknél mentésre. Csak Bacula-t használtunk eddig, szuperül működik is, le nem váltom sehol szerintem, de ahol van helyi infós, az egyik sem látja át, kellene valami "egyszerűbb".
Én például azért választottam a restic-et, mert ez volt az egyetlen, ami tudta az inkrementális mentést, deduplikálást, kliens oldali titkosítást, userspace mount lehetőséget, valamint támogatta a backblaze-t is. Azóta sem bántam meg.
Hatalmas +1 a restic-nek.
Annyira szeretem, hogy windows-on is elkezdem használni és már írtam egy kis framwork-ot hozzá python-ban és így egy perc alatt üzemelem be.
Ez egyik óriási előnye, hogy hihetetlenül könnyű használni, és a visszaállítás a mount-al faék egyszerű. Én is B2-t használok off-site mentésre, volt már rá példa, hogy a VPN miatta macera volt a szerver elérése, ezért a saját gépemen állítottam vissza keresett excel fájlt és azt küldtem el mail-ben az user-nek, hogy ezt keresi-e :)
Nagyjából ezek miatt:
Köszi, igen nézni fogok valamit, undelete-t is megpróbálom...
Igazából nincs felügyelve az egész, de nem megyek bele a részletekbe...
Kérlek add meg, hogy milyen paraméterrekkel futott az rsync.
-ahzpe
Ez jónak tűnik, ha nem volt delete, akkor meg kellene lennie a régi fájloknak. Innen sok irányba el lehet indulni. Valóban ment korábban is a mentés? Nem lehet, hogy a fájlok a két mentés között keletkeztek?
A jövőben használj dirvish-t (ami szintén rsync-el, csak jobban).
mikor volt utoljára fejlesztve a dirvish?
Inkább használjon borg/restic-t backup megoldást.
Teszi a dolgát. Régi stabil cucc, faék 1xűségű. Nem kell túlbonyolítani.
Ha megvan a ransomware neve, akkor érdemes megnézni, hogy véletlenül nem úgy működik-e, hogy előbb elkódolja a fájlokat (ami ugye sokáig tarthat), majd utána átnevezi, ami hamar megvan. És így nehezebb észrevenni. Ez egy hihető magyarázat, és talán nem teljes butaság.
Logikusnak tűnik. Ha én ilyet írnék, megköszönném neked az ötletet és beleépíteném.
Jó lenne tudni milyen ransomware, mert vannak már 'advancedebbek' is, amik mountolt backup-ot simán letitkosítják. Az infrastruktúra ismerete nélkül nagyon nehéz bármit is mondani, de az biztos, hogy ha nem volt az rsync -nek --delete opciója, akkor ő nem törölt a targeten semmit, az átnevezett fájlokat újként kellett (volna) áttolja a targetre.
Ja, sajnos ez az ördögi a ransomware-ekben, hogy hiába a rendesen frissített, Linux, meg akármilyen security paranoid hardened BSD, amit a vírus nem tudna támadni, ha egyszer Sambán át a windowsos gépek felülcsapják a fájlokat. Vagy használj inkrementális backupot (ez lehet FS snapshot is), vagy Sambán állíts be egy olyan megoldást, hogy a kliensek felől csak feltölteni tudjanak, és olvasni, de meglévő fájlokat, mappákat törölni, felülírni ne tudjanak. Ez ilyen, a windowsos szutykok mindenhova odarondítanak, bármit, amit elérnek, ha kell, egy FAT*, exfat vagy NTFS pendrive is elég, ezért is van Linuxra is vírusirtó, nem a linuxos vírusok ellen véd, hanem windowsosok ellen, hogy a linuxos rendszer ne segítsen windowsos gépeknek a szutykait tovább terjeszteni, meg a károkozást megállítsa.
“The world runs on Excel spreadsheets.” (Dylan Beattie)
Már legalább másodszor látom tőled azt a javaslatot, hogy a Samba megosztás legyen WORM, egyszer írható, aztán csak olvasható.
Pontosan hogyan lehet így megvalósítani a munkát? Mármint amit a felhasználók végeznének különböző programokkal, Windows-on (vagy bármi máson).
Mármint úgy, hogy nem módosíthatják az állományokat a legelső feltöltés után.
en is csak tippelni tudok: nyilvan a fajlok modosithatoak, csak az elozo verziot nem felulirjak hanem uj keszult a hatterben. ugyanugy foo.doc marad ott, es olvashatja/irhatja mindenki, de a hatterben valahogy megmarad az elozo verzio. mintha minden modositas utan egy snapshot keszul.
nem ismerem a sambat, nemtudom megvalosithato-e ez a dolog.
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Hát az zfs snapshot pl. biztosan használható ilyen célra. 1-10 percenkénti snapshottal eléggé alacsony szintre korlátozható az adatvesztés. Viszont felmerül a kérdés, hogy a percenként autosave mellett ez mennyi extra diszket igényel.
A Samba önmagában ilyenre nem képes. Az előttem szólóhoz csatlakozva, fájlrendszer szintű snapshot kombinációval megoldható a virtuális módosíthatatlanság, de a helyigénye miatt nyilván nem feltétlen használható a teljes megosztási struktúrára (technikailag nyilván használható, a user dönti el, mennyi tárterületet tud/aka erre szánni az RPO függvényében). Esetleg folyamatos backup (ami hasonlóan működik a snapshot-hoz), de ott is a helyigény a kérdés.
Én azért írtam a kérdést, mert hiába szidjuk folyamatosan a Windows-t mint problémák forrását, a felhasználók 99%-a azt használ (a maradék 1% meg Apple gépet, ami szintén SMB megosztást használ hálózaton manapság). Szóval az üzemeltetésnek alkalmazkodni kell a felhasználáshoz. Ha varázsütésre megfordulna a világ, és Linux lenne midnen desktop-on, napok kellenének, hogy ugyan ezek a károkozók megjelenjenek rá. A user ugyan úgy engedélyt adni egy random szoftver futására Linux-on, mint Windows-on. Szóval szerintem nem a Windows maga a probléma, hanem az elterjedtsége tesz jó célponttá.
Erre mi sokszor seafile-t használunk (a nextcloud is tudja). Helyi nas-ra seafile szinkronizálás, helyi nas-ról -igény szerinti időzítéssel- backup borg-gal távoli vasra. Samba-t vágjuk ki minden honnan, ahonnan lehet.
üdv: pomm
A 852-es kídlap telepötúsa sikeresen befejezádétt
Van egy olyan iskola, hogy a fájlnévbe bekerül a verziószám (pl.: valami_szerződés.0.1.docx). Ha módosítani akarsz a valamilyen módszerrel (pl.: chattr +i) immutable-lé tett dokumentumon, mentesz belőle egyet új verzióval, és abban dolgozol. Végül a nap végén a szerveren lefut egy újabb chattr +i az egész megosztásra. Hosszú távon nem tudom, hogy mennyire működhet.
De akkor a felhasználó a saját gépén szerkeszti az anyagot, és csak a "kész" állapotot teszi fel a szerverre? A több napig-hétig készülő első verziókra ez hogyan működne? Vagy akkor a user gépéről is kell mentés, hogy biztosítva legyen a még csak ott létező, szerverre fel nem került állomány?
Szerintem semennyire sem életszerű, hogy nem módosítható egy munka célú megosztáson lévő állomány, vagy az, hogy a felhasználók munka anyagokat a saját ("eldobható") desktop PC-jükön tároljanak.
Nem, Windows kliensről a network share-en szerkeszti az ott létrehozott új verziót.
De akkor szerkesztés közben folyamatosan módosítja (mert akinek esze van, időnként ráment kézzel, vagy bekapcsolja az auto save funkciót). De a WORM üzemmóddal ez nem lehetséges ha jól értem a lényeget. Ezért nem értem, hogyan lehet ezt megvalósítani.
Első verzió: létrehoz kézzel egy új dokumentumot (foo.v0.1.docx), szerkeszti, mentegeti. Munkaidő után egy chronjob 'chattr +i'-t futtat a share fájljaira, imnentől a felhasználó már nem tud beleírni. Másnap tehát ctrl+c, ctrl+v a fájlon, másolat átmevezése foo.v0.2.docx-re. Ezt szerkesztgeti aznap minkaidőben. Így elkerülhető a kliens gépek mentése, de semmi nem akadályozza meg a felhasználót, hogy a saját gépén lévő példánnyal dolgozzon.
Értem, hogy kidolgozható rá módszer ami végül is WORM működésnek hívható, nem is ez a kérdés. Hanem, hogy én 25 éve dolgozok üzemeltetőként mindenféle felhasználókkal (KKV és "állami", nem multi), és nem tudom elképzelni, hogy ezt bárhol meg lehetne honosítani. Vagy a helyi gépen lenne minden 1 hónap múlva, vagy 1 millió verzió lenne minden doksiból, verziónként több monogrammozott változattal (amin többen dolgoznak).
nekem ez nagyon életszerűtlen...
--backup --backup-dir=/minden_futaskor_masik_backup_konyvtar_ahova_a_regi_modosult_vagy_torolt_fajlokat_mozgatja
nem jo?
futas kezdetenek idopontjat teszem bele.
neked aztan fura humorod van...
Na meg backup szerverre
- vagy btrfs
- vagy zfs
és mehet a backup végén a snapshot és x nappal régebbieknél a snapshot ritkítás, majd végül a ritka snapshot törlése.
én ezt úgy csinálom 2 synology nas-al, hogy rsync átnyomja a backupra. majd csinál azonnal egy rotációs mentést.
így ha be is kapnék egy zsarolót, ami ugye áthúzza az összes titkosított fájlt akkor a rotációsból vissztudom állítani.
ismerősnek külső vinyó volt bekapcsolva backupnak folyamatosan, persze hogy telibe titkosította. hiába mondtam neki hogy ez így nem jó ám, de jóaz...
https://github.com/rsnapshot/rsnapshot
még mindig létezik. hardlinkkel operál
de ez nem elég. időnként kell olyan mentés is ami nem elérhető. mint szalagnál. cserélni kell mentő célon diszket pl. fizikailag!
Csak bedobom a sajat megszokasaimat a szalba...
- Windows kliens mentesere urbackupot hasznalok LAN-on belul. Incrementalisan pakolja a fajlokat. Epp ma neztem ra az egyik nyuzer mentesere. 600MB-ot ketto perc alatt pakolt el. Ez egy konyvelonek a napi munkaja, levelezese (TB) es a konyvelo programja, dokumentumai. Baratsagos a grafikus felulete. Szepen mazsolazhatsz mikorra akarsz visszamenni... Egy buuun lassu raid1 WDgreen van alatta.
- Ahol zfs van a szerver alatt ott a zfSnap-al cronbol gyartom orankent naponta hetente a snapshotokat. Persze van lejarati idejuk. Kb fel evre tudok visszatekinteni.
- Ahol ext4 van... Fuuuu... Ezt mar harom t-vel irom, olyan multido! Valamikor talaltam egy scriptet (amit kicsit kipofoztam azota meg csak masolgatom ha kell), ami naponta fut. Hardlinkekkel operal. Keszit egy full rsync-et a 0-as konyvtarba. Masnap a 0-t atnevezi 1-re es ismet rsync-el ugy, hogy a 0-hoz viszonyitva nezi a valtozast, a tobbi hardlink. Es ez megy het napon keresztul. Tehat, het napra tudok visszatekinteni. Mar nem is emlekszem a pontos mukodesre, de akkor jo otletnek tunt, es minden ejszakai allapotom klasszul megvolt a konyvtarakban.
rsnapshot-nak hívják. Több idő paramétert is definiálhatsz, így nem csak napi, hanem heti és havi mentést is tud gyártani.
Ami miatt külön jó: a backup szerver lép be kulcsos ssh-val a kliensre átemelni az adatokat - ha a kliensen valami csúnya program dolgozik, akkor lehet, hogy a kliens mentése tré lesz, de egyfelől van a korábbi mentés, másfelől innen kezdve a mentés ideje alatt se tud garázdálkodni a csúf program a backup gépen, hiszen nem éri azt el.
És 1 db rsynces mentés volt?
"Sose a gép a hülye."
Az elso mentes tart sokaig. A tobbi is rsync-es, de akkor mar csak a valtozasokat, es az uj fajlokat viszi at. A konyvtarakban pedig siman az ejszakai alapot latszik.