Vlákno názorů k článku
Útočníci se zaměřují na zálohovací úložiště a vynucují si tím zaplacení výkupného od Jimm - Já nějak nerozumím tomu, v čem je problém....

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.