Názory k článku
Útočníci se zaměřují na zálohovací úložiště a vynucují si tím zaplacení výkupného

Nemalou měrou tomu nahrává to, že většina systémů je postavena tak, že má přístup pro zápis na zálohovací stranu. Nenašel jsem systém který by běžel autonomně a měl naopak přístup do zálohovaného stroje je čtení

Článek je reklama na Veeam.
Což je autonomní systém, který má práva ke čtení.
Na jedné straně data čte a na druhé je zapisuje.
Takže to jaksi problém neřeší. Jen útočníkům přidá další vrstvu ochrany.

Dá se to řešit i jinak. Například file systém, který neumí data mazat. Pouze je označí jako smazané a ke smazání dojde až po nějaké době. Například za měsíc. Přepis funguje tak že původní soubor se označí za smazaný a změněný se uloží jako nový.
No a vše smazané se dá obnovit měsíc zpětně.
Je to náročné na místo, ale dnes když 20TB disk stojí 10 000Kč...

Jak to řeší čtenáři ROOTu?

25. 5. 2023, 06:52 editováno autorem komentáře

Az na to, ze 20TB nestoji 10, ale spis tak 100kKc.

Co to meleš?

možná měl na mysli SSD.

Jeden z čtenářů to dělá následovně:

Uživatelská data jsou na btrfs, kde se každých 10 minut dělá read-only snapshot (cron). Těchto se tam drží pár set, takže mám podrobnou historii pár dní dozadu a můžu se vrátit k předchozí revizi souboru, případně vrátit něco, co rozbiju/omylem smažu.

Další cronjob jednou za delší chvilku (1-2 hodiny) udělá komprimovanou a šifrovanou deltu mezi aktuálním a starším snapshotem (btrfs send | zstd | openssl > /někam). Tu umístí do untrusted synchronizovaného adresáře, odkud se to rozšíří po světě. Dříve přes syncthing, dnes používáme Garage, což je distribuovaný object store s S3 API. Máme v kolektivu pár NASů, kde si vzájemně hostujeme místo, a taky pronajímáme prostor v mráčku (10 TB za $50/měsíc u Backblaze B2). Jednou za delší čas se udělá plný dump (tj. ne delta), aby ten playback log nebyl příliš dlouhý. Playback zhruba 1 roku delt totiž trvá na Zen3 s běžným NVME asi 2 dny :))

Na vlastním trusted stroji (NASu) mám ještě path.trigger, který každou nově přijatou deltu ověří, dešifruje, aplikuje na filesystem. Tím vzniká stínová kopie mého /home s mnohem delší historií, aktuálně 3 roky read-only snapshotů zpětně (a roste). Tam si občas zajdu pro dlouho ztracený soubor. V případě potřeby ty snapshoty můžu libovolně promazávat (snižovat hustotu z hodinových třeba na jednodenní), abych uvolnil místo.

Systémy nijak nezálohujeme, všechno je 100% automaticky derivováno z deklarativní definice (NixOS), kterou spravujeme v git repozitářích.

Problém řeším tak, že data z koncových zařízení notebooků rodiny shromažďuji na Synology s diskovou redundancí na fyzické úrovni a BTRFS souborovým systémem na shared folders svazku (tzn. vrstvy dat, self-healing). Na Synology jsou zálohované pomocí Active Backup for Business image disků notebooků (díky přechodu z neschopného Turris na Synology router RT6600 jsou i přes Wifi inkrementální zálohy extrémně rychlé - přes dvě zdi cca 90MB/s), extra jsou pomocí pomocí Cloud station domovské adresáře + per uživatele spec. adresáře. Synology spravuje archiv fotek, domácích videí, koupené hudby atd. atd.
Mám zakoupený cloudový prostor od Synology a 1x denně do něj jdou zálohy nejdůležitějších dat (home adresáře uživatelů, instalační data, adresáře fotek, hudby, domácích videí) ceny viz https://c2.synology.com/en-us/pricing/storage

Davat pristup druhe strane k sobe, taky neni idealni.

Jedine reseni je, ze na zalohovanem stroji bezi nejaky idealne hloupy client, ktery to zalohuje nekam, kde se ty zalohy spravuji a nejsou pristupne.

Napr tahle to resim ja: https://www.snapbackuper.com/cs. Rsyncem se tam odlejou data a sprava zaloho se resi tam a clienty ty zalohy ani nevidi.

Pokud (a to je dneska pomerne hodne provozu) je infrastruktura virtualizovana, tak se zalohovani resi zvenku. Jinak receno, ten zalohovany stroj ani netusi, ze ho neco zalohuje.

Ma to ale jiste nedostatky, ktere prave zmineny veeam ... naprosto nezvlada ani v nejmensim. Napriklad vyrobit konzistentni zalohu databaze.

Jinak se typicky nezalohuji soubory, ale nejake snapshoty = i kdyby ten "utocnik" zalohy prepsal, prepise maximalne posledni, ke starsim se nemuze nijak primo dostat.

O konzistenci data aplikace se stara aplikacni zalohovani (vetsinou nastroje od tvurcu aplikace), stanadardni zalohovaci systemy tu konzistenci aplikacnich dat nemaji sanci resit.

Takze si vzivote zadne zalohovani nevidel? Chapu to spravne? Kazdy normalni zalohovac ma celou radu klientu, kteri jsou urceni prave k tomu, aby aplikace (typicky databaze) pro kterou je klient, vedela, ze se bude zalohovat.

Veeam tvrdi, ze ma totez, ale nedokazi to vubec zprovoznit. Meli na to v mem pripade 3/4 roku.

Kuprikladu windows disponuji VSS. Potiz je v tom, ze aby to fungovalo, musi s tim umet fungovat i aplikace, coz typicky neumi (neumi to ani jejich vlastni aplikace).

"Davat pristup druhe strane k sobe"
Nechápu v čem je problém. Extra osoba má své přihlášení, svá práva na folder se zálohami. Z důvodu důvěrnosti si může data na klientovi zašifrovat...

Já nějak nerozumím tomu, v čem je problém. Stroje dělají zálohy na úložiště, odkud se data každé ráno přesunou jinam, napsat takový script zvládne malé dítě a je to tím vyřešeno, ne?

Jistě to zvládne, ale v praxi to spousta firem nedělá. Nedávno mi volal člověk, že potřebuje pomoc, protože měl přes USB k serveru trvale připojený externí disk, kam se automaticky ukládaly zálohy. Přišel ransomware a jeho firma má velký problém. V takové situaci bohužel není jak pomoct. Takovéhle zprávy by měly lidi varovat, aby se nad svými postupy zamysleli.

Nevím, jaký to má asi praktický dopad. Četl jsem to stokrát, je to zde minimálně jednou ročně. Pokud to opakování někomu doposud nepomohlo, už je jedno, kolikrát to ještě uslyší. :)

Ono jde i o rozsah. Mam treba "jen" 18TB dat (nekolik let zaloh). Jak mi rsync poresi "zivotnost" zaloh na offsite strane? Na primaru mi zivotnost zaloh resi zalohovaci system (inkrement, denni, tydenni atd), kdyz to rsyncnu (i stovky GB denne), jak tuhle logiku poresim na druhe strane? Proto to delaji jen ti, "nemaji prachy na zalohovaci sw" ruznymi nahodnymi skripty, ale firmy potrebuji ucelene reseni.

malé dítě? Škoda, že u más je zakázané zaměstnávání malých dětí, hned bych pár takových pracantů chtěl.

Udělat spolehlivě zálohování je pěkná věda a není to jen o nějakém scriptu. Jednoduchý script bude namátkou fungovat pouze za předpokladu, že dat je málo, je shodný filesystem jako na uložišti, data nejsou aktivně zapisovaná a jsou již fsyncutá na disk atd.

V praxi ale řešíme problém zálohování živých dat z růných filesystému s různým nastavení (velikost blocků, metadata/facl, case (in)sensitive, zámky), k tomu ještě problémy s integritou záloh a jejich ověřením.

Vůbec to není snadný. Příkladem je i tvoje řešení, co když je daný systém napadený a útočník pozměnil zálohovací script, aby se zálohovaly nesmysly nebo náhodná data? Takhle to může nechat běžet měsíce bez povšimnutí a následně ti smazat produkční systém a ty skončíš s měsíce starými daty. Přesně takovýhle případ jsme před pár měsíci řešili u klienta. Nejhorší jsou naivní řešení, měli to udělané vlastně úplně stejně jak navrhuješ.

Ty jsi logiky moc nepobral.

Pokud mi útočník napadne server, já o tom nebudu vědět a bude mi zálohovat nesmysly, zboří to jakýkoli systém záloh vymyslíš, potom je to už o tom, že se holt musí někdy testovat disaster recovery.

Kdyz mas kontrolu zalohovanych dat, tak nezbori. A ta kontrola muze byt velmi primitivni a rychla.

prosím, vynech osobní urážky.

Záloha, která je jednostranná není dobrou zálohou. Vždy jí musíš testovat a kontrolovat a to nejen při jejím vytvoření, ale i průběžně (opominu-li běžný problém, že data jsou nečitelná, občas se po nějaké době změní kompatilibita aplikací a jejich datových souborů, měl bych to zjistit zavčasu).

Vždyť jeden z důvodů zálohy je právě nepřijít o data nebo jejich autenticitu, když budu mít kompromitovaný server, což není vůbec žádný velký problém (0day zranitelností je pořád požehnaně, tomu se nevyhneš a musíš s tím počítat).

Nezboří to dobře navržený systém, který bude zálohy funkčně ověřovat. Stejně tak to nezboří zálohy, které jsou strukturované (např. transakční logy z databáze) a tu strukturu a obsah validuji.

Tvůj nápad s jednoduchým scriptem, který napíše i dítě je právě jeden z největších dnešních problémů, když se řeší napadení infrastruktury a potřeba něco obnovit. On člověk teprve až potom zjišťuje, kde jsou poslední zálohy, jak vypadal ten script, který je zálohuje, co vlastně přesně zálohuje a jak to vlastně mám obnovit.

"Pokud mi útočník napadne server, já o tom nebudu vědět ... zboří to jakýkoli systém záloh"
Dobře navržené zálohy opravdu nezboří. Pokud mohu mluvit o Synology, tak změny jsou ukládány v "časových vrstvách". Navíc se nastavuje retence dat ve stylu chci zachovat poslední změnu každého dne posledních 7 dnů, na konci x týdnů atd. atd.
Navíc Synology cloud obsahuje monitorovací triggery změn dat, kde si můžete zadat procentuální práh mazaných a procentuální práh měněných souborů. V případě překročení, okamžitě dostáváte varování.
Některé zálohovací systémy mají ještě bezpečností "udičky" ve formě kontrolovaných souborů rozhozenych mezi užitečná data a v případě, že jsou "udičky" modifikovány (např. díky kryptoviru), zálohovací úloha neproběhne.

Koukam za panove nezvladaji cist ...

kdyz nekdo ovlada ten stroj, ktery se ma zalohovat, muze na nem tudiz menit data ktera se maji zalohovat. A pokud provozovatel NEVI ze ten stroj je napaden, tak ani NEVI, ze se zalohuji nesmysly. Az to za par mesicu zjisti, uz nebude mit zadne zalohy ktere by slo pouzit. Ackoli tech zaloh bude mit hromadu.

Naprosto vpohode mu system zalohovani bude reportovat, ze je vse OK, zalohy projdou vsemi testy ... jen v nich budou hovadiny.