Ransomware rsync

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

Ezt nem értem.

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 38, 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:

--delete-before
--delete-during

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.

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

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.

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

Senkinek nincs köze világod belsejéhez, neked sincs közöd mások életéhez, csak az Irgalom útján van közöd, Istenektől rendelt kötelességed.

Nagyjából ezek miatt:

  1. Windows alatt van VSS támogatás. Duplicatiról váltottam, mert bár ez is tette a dolgát, de az én izlésemnek kicsit lassúnak/körülményesnek bizonyult. És olvastam pár rémtörténetet, amikor a Duplicati DB sérülése miatt nem lehetett adatot visszaállítani
  2. Tud közvetlenül network-re menteni (SFTP/B2/S3, etc); illetve tud rclone-t használni proxynak, így annak az összes backend típusa támogatott
  3. Létezik hozzá egy rest-server (append-only móddal), ami a `borg serve` megfelelője, csak SSL helyett HTTP(s)-en
  4. Egy repóhoz több kulcsot is tud használni, így a kulcs rotálás is könnyen megoldható
  5. 2022 áprilisa óta végre van benne tömörítés (zstd) is (ha nem is olyan finoman kontrollálható, mint a borg compression szintjei)
  6. Tetszik a snapshotok tag-elése, és akár a tagek alpaján történő forget/prune-olás

Kérlek add meg, hogy milyen paraméterrekkel futott az rsync.

A jövőben használj dirvish-t (ami szintén rsync-el, csak jobban).

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.

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.

A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

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!

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.

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

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

Szerkesztve: 2023. 03. 26., v – 17:31

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

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.