Vlákno názorů ke zprávičce Útočníci se zaměřují na zálohovací úložiště a vynucují si tím zaplacení výkupného od Vladimír Cejvik Bílek - Nemalou měrou tomu nahrává to, že většina systémů...
-
Č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
-
A ty krabice a infrastruktura kolem nic nestoji? Ten disk si pichnu do nosu ? A raid taky zadny? Takze kdyz ten disk pojde tak? A IOps? Ty taky netreba zejo ...
Jeden pidizakaznik pouziva prave veeam a ma na to 4diskovy stroj. Zvlada to 15-20MB/s ... vic ani tuk. Spocital sem jim to, na 14 dnu ... nez by se obnovila zaloha.
Vetsi pouziva na backup 20ti diskovy pole (kombinace HDD/SSD) v porizovaci cene novyho cca 1M. A vazne to nema 2EB kapacity ...Ma to cca 30TB. Full obnova by trvala cca 3 hodiny.
-
To je nějak tragicky málo. Sociální verze zálohování přes Veeam znamená Synology přes iSCSI a tam je rychlost i na těch levnějších krámech přes 40MB/s. U většího rackovýho není problém dostat se na 200MB/s, ale tam už jsme na tom kile.
Každopádně Synology u všech vyšších modelů (tuším nemají na konci "j") nabízí snapshoty, takže stačí trošku připlatit za lepší model, rozumně dimenzovat kapacitu a není problém mít několik snapshotů zcela nedostupných, útočník by se musel být schopen dostat do managementu Synology. Jako další stupeň ochrany jde tyto snapshoty kopírovat v rámci dalšího Synology.
Byť to není ideální zálohovací nástroj, tak pro firmičky s pár virtuály je to použitelný řešení za opravdu málo peněz, nějakých 10TB v raid1 vyjde zhruba na 20 tisíc. -
To neni malo, ono to presne odpovida ... na ty disky nasypes nejaky data. A pak uz tam ladujes jen rozdily. Pokud des data obnovovat, tak se skladaji postupne ze vsech snapu ktery tam mas. Tzn defakto mas na discich 100% fragmentaci.
Jinak receno, pokud si na disky pustis bench a nastavis mu random cteni(*), tak to je presne ta hodnota, kterou ti to da. A prave proto, aby to dalo vyrazne vic, tak potrebujes vyrazne vic disku a/nebo SSD. A na to pochopitelne taky potrebujes adekvatni krabici, do ktere to vsechno das. Dal pak potrebujes taky adekvatni konektivitu, protoze pri objemech dat ktery dneska i pidifirmy syslej (casto samozrejme uplne nesmyslne) je Gbit zcela nepouzitelne pomaly. Nekdy uz je i 10G tragicky malo.
Proto se u tech vetsejsich instalaci (kde se teda chce bezpecne zajistit provoz) ... vubec s obnovovanim dat nepocita, protoze se to technicky vlastne udelat neda. Resi se to tak, ze se proste udela mirror celyho storage, a pri vypadku se vesele jede z toho druhyho. Az se vymeni/opravi, tak se to nejak nekdy casem dosyncne.
(*) doporucuju kazdymu "domacimu" ssdckari s nejakym tim uzanym 300 000 iops ... ssdckem za petikilo ... to se zasmeje, az mu to bude davat 10MB/s nebo min.
-
Veeam nabízí už snad deset let defragmentaci záloh, jde nastavit i četnost, což zabrání tomu, co popisuješ. Dokonce to funguje i na verzi zdarma. A tipuju, že to bude umět i spousta dalších zálohovacích software.
Dvě SANky se synchronizací nenabízí ochranu proti šifrování, tam je zásadní právě snapshotování, bez něho jsou to dneska už v podstatě vyhozený peníze. -
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.
-
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).
