Šifrované zálohování celého systému přes wifi / vpn

9.1.2011 13:28 | Přečteno: 2045× | Linux - readonly debian pro routery |

Šifruji celý souborový systém mého notebooku. Občas jsem dělal ruční zálohu toho důležitého na šifrovaný USB disk. Teď jsem ale přemýšlel jak tento postup nějak zautomatizovat, nejlépe přes síť. Chci zálohu pravidelně (teď jsem na to totiž trochu doplatil). Jediné místo kam mohu teď po síti zálohovat je menší souborový server kam má ale přístup víc lidí. Sice jen jako uživatelé, nicméně kdo ví co tam budou hledat. Navíc bych nerad aby si ten server někdo vzal a odnesl. Po promýšlení jsem došel k jistým závěrům o které se chci podělit. Pro někoho to možná bude inspirace, já bych ale rád slyšel vaše názory, jistě by to šlo i jinak. Zajímá mě v mojí implementaci co si myslíte o bezpečnosti a dalších spektech celého řešení.

Jdem k věci.

Na serveru, ke kterému přistupuji přes VPN, je dostatečná disková kapacita. Nainstaloval jsem si tam nfs server a k diskovému prostoru mohu přistupovat přes NFS. Na mém notebooku pak přimountuji vzdálený prostor do mého /mnt/nfs

mount -t nfs 10.10.18.24:/mnt/space2 /mnt/nfs

Dále si vytvořím soubor, který bude pak obsahovat šifrovaný filesystém, o velikosti 500GB.

dd if=/dev/zero of=/mnt/space2/fs_backup.lks bs=1M count=500000

Problém je, že pro šiforvání je vhodné, aby soubor obsahoval co možná nejnáhodnější data. Bylo by lepší sahat do /dev/random, ten je ale ukrutně pomalý, eventuelně do /dev/urandom který je rychlejší, méně kvalitní z hlediska náhody, nicméně pro vytvoření takto velkého souboru zase nevhodný. Můj postup který volím je vytvořit soubor obsahující samé nuly, dále soubor převedu do luks formátu a připojím. Pak toto šifrované zařízení přepíšu přes shread 1x náhodnýmy daty. Data nemusejí být podle mě nějak kvalitní protože po zašifrování už se bude jednat o kvalitní bordel. Dále odpojím přes cryptsetup luksClose šifrovaný kontainer a ještě přepíšu hlavičku, prvních 32mb mého souboru, tentokrát si na /dev/urandom počkám. Teď mám tedy soubor obsahující, doufejme, kvalitní náhodná data a bylo to o poznání rychlejší než čekat na /dev/urandom.

Aby bylo vubec možné soubor na disku použít, je třeba přes losetup vytvořit ze souboru blokové zařízení. Zde je moje otázka - je problém že vytvářím zařízení které je připojené přes wifi /802.11a/? Z hlediska problému se sítí... popere se tento postup s lagy a podobně?

losetup /dev/loop0 /mnt/nfs/fs_backup.lks

Dále je třeba /dev/loop0 naformátovat do luks formátu. Dosáhnu toho pomocí příkazu.

cryptsetup -y luksFormat -c blowfish -s 256 /dev/loop0

Zde bych se zase rád zeptal na názory, je vhodné použít blowfish? nebo raději aes? vzhledem k přístupu přes síť není třeba rychlost. Můžete doporučit nějaké dobré nastavení při formátu do luks? Jde mi zejména o bezpečnost.

Dál je třeba kontainer připojit, zadám heslo...

cryptsetup luksOpen /dev/loop0 loop0

Dál je třeba kontainer naformátovat do nějakého rozumného souborového systému

mkfs.ext3 /dev/mapper/loop0

Nakonec připojit...

mount /dev/mapper/loop0 /mnt/zaloha

Teď syncnout, rozhodl jsem se přes rsync...

rsync -av --delete /home/ /mnt/zaloha/

Po skončení odpojit fs, zavřít šifrovaný kontainer, odpojit loop zařízení a odmountovat nfs

umount /mnt/zaloha
cryptsetup luksClose loop0
losetup -d /dev/loop0
umount /mnt/nfs

Samozřejmě že pro zálohování se pojede už jenom následující sekvence, s heslem v texťáku (zabijte mě! nevím jak jinak, neinteraktivně).

mount -t nfs 10.10.18.24:/mnt/space2 /mnt/nfs
losetup /dev/loop0 /mnt/nfs/fs_backup.lks
echo heslokterejetajne | cryptsetup luksOpen /dev/loop0 loop0 -
mount /dev/mapper/loop0 /mnt/zaloha
rsync -av --delete /home/ /mnt/zaloha/
umount /mnt/zaloha
cryptsetup luksClose loop0
losetup -d /dev/loop0
umount /mnt/nfs

Celé toto hodím do cronu a nastavím noční hodinu, třeba 2 hodiny v noci. Pak mi stačí notebook na noc nevypínat a ráno budu mít zálohy.

Fajn je, že po síti, i když je šifrovaná, nelítají prostá data. V podstatě z mého notebooku neodejde nic nezašifrované, takže i kdyby někdo naslouchal přímo u serveru se zálohou, nebude mu to nic platné. Stejně tak nehrozí zneužití v souvislosti s kompromitací serveru. Jde jen a pouze o to, udežet v tajnosti souborový systém mého notebooku. Který z podstaty věci musím udržet v tajnosti. Když praskne heslo k záloze, už skoro není třeba zálohu dále udržovat v tajnosti... neb bude mít útočník data z mého laptopu :) Táák, nějaké nápady, připomínky?        

Anketa

Anketa

Komentáře

[Petr Tomášek]

Táák, nějaké nápady, připomínky?

Mno, imho, kdybys šifroval asymetricky (klidně pomocí gpg, nebo tak) tak budeš mít jeden klíč na zašifrování a druhý na dešifrování, tak se nemusíš sypat strachy, že ti někdo ukradne heslo

[Johny z Podoli]

Pak bych ovšem nemohl šifrovat na úrovni fs, přišel bych o rsync. Což by pro mě bylo komplikované. Navíc, ztráta hesla... když přijdu o heslo které mém jen na mém notebooku, pak nejspíš "jako bych přišel o vše". Ale děkuji za zajímavý podnět.

[Petr Tomášek]

Pak bych ovšem nemohl šifrovat na úrovni fs, přišel bych o rsync. Což by pro mě bylo komplikované.

Mno, zřejmě jo...

Navíc, ztráta hesla... když přijdu o heslo které mém jen na mém notebooku, pak nejspíš "jako bych přišel o vše". Ale děkuji za zajímavý podnět.

Vytisknout klíč na papír a nechat uschovat u notáře? :-P

[Jendа]

Mno, zřejmě jo...

Bylo. Pořád čekám, jestli někdo napíše „distribuovanou P2P zálohovací síť“, kdy si vyhradíš třeba 30 GB pro cizí zálohy a za to si budeš moct zálohovat k někomu jinému (=geograficky odděleně).

Vytisknout klíč na papír a nechat uschovat u notáře? :-P

K tomu podle mě např. policie může (řeknutí hesla by byla výpověď, ale tohle by bylo jen vydání věci).

[Jakub Lucký]

(1) Každý má právo odepřít výpověď, jestliže by jí způsobil nebezpečí trestního stíhání sobě nebo osobě blízké.

A co když to dáš "někomu" a policii neřekneš kde to je? A optimálně dotyčnému neřekneš, co v tom je...

[Jendа]

To to jasně, pokud ho nevypátrají, pak si o to nemůžou říct.

Lidé s čistým svědomím a s dobrými úmysly nevymýšlejí, jak být anonymní, aby se na ně nepřišlo. To obvykle dělají pouze zločinci a obecně lidé patřící do kriminálu. Už jen založení diskuze na podobné téma je podezřelé a mělo by se prošetřit.

Taková činnost ale maří vyšetřování policejním institucím. Nedávno dávali ve zprávách, že právě šifrované hovory přes skype jim velmi ztěžují pachatele odhalit. Právě možnost sledování lidí na internetu umožní bojovat proti trestné činnosti a to právě chrání celou naši společnost a zajišťuje nám bezpečí.

Zdroj; těžko říct, jak moc vážně je to myšleno.

[Jakub Lucký]

To co tam dotyčný píše už bohužel víme dávno.. ale dokud nás všechny nezavřou, tak to nebude ono...

[Ondra]

...distribuovanou P2P zálohovací síť...

Freenet?

[Jendа]

Tam AFAIK soubory, o které není zájem (a to o zálohu není, alespoň dokud neodejde disk), mizí.

[Petr Tomášek]

K tomu podle mě např. policie může (řeknutí hesla by byla výpověď, ale tohle by bylo jen vydání věci).

Ty pácháš trestnou činnost?

[Jendа]

Ne (nebo o tom alespoň nevím ). Asi paranoia…

[Jendа]

Mimochodem, z čeho vyplývá, že to zrovna z tohoto důvodu takhle nemám?

A navíc, to, že nic nepácháš, neznamená, že po tobě z nějakého důvodu (podezření, které se nakonec nepotvrdí) nemůžou jít.

[Jakub Lucký]

Jak říká ten strašně rychle mluvící právník ve videu Proč nemluvit s policií, nikdo si nemůže být jistý, že nepáchá/nespáchal nějaký trestný čin...

[a1bert]

Pak bych ovšem nemohl šifrovat na úrovni fs, přišel bych o rsync.

o rsync jsi prisel i tak, jaky smysl ma pretahnout data po siti (nfs) pak je rsyncem zanalyzovat na zmeny a pripadne zmeny zapsat?

rsync ma smysl pokud bezi primo na vzdalenem stroji, pak se opravdu prenasi jen zmeny ale takhle to muzes klidne natvrdo prekopirovat a budes na tom stejne ne-li lip..

[asfethan]

EncFS nepoznate? Cely postup by zredukoval asi o polovicu, ak nie aj o 3/4

[kolcon]

EncFS je proti dm-cryptu silene pomale - pravda pri zalohach pres sit to asi nevadi

[Jendа]

No jo, je to FUSE…

[Josef Kufner]

rdiff-backup ... pořiď si inkrementální zálohy. A taky zálohuj večer, ne přes noc, ať nemusíš nechávat notebook zapnutý.

[Nicky726]

Kdysi mi někdo na šifrované zálohování doporučoval Duplicity.

[Shadow]

Přesně tak, Duplicity je ideální volbou pro zálohu na "nedůvěryhodné" úložiště - zálohy komprimuje i šifruje (pokud se to tedy explicitně nezakáže), podporuje nejrůznější protokoly (samozřejmě včetně SSH), umí inkrementální zálohování (takže se při následných zálohách přenáší/ukládají jen rozdíly). K šifrování používá GnuPG.

[Jendа]

Pokud to dobře chápu, tak se kupí a kupí a kupí rozdílové soubory a nikdo je nemaže (vzdálený server to udělat nemůže, protože dovnitř nevidí, a jejich smazání z klienta by znamenalo přegenerování celého archivu a tedy přenos celého znovu).

[Shadow]

Ano, proto se jednou za čas udělá další plná záloha a ta starší (i s příslušnými inkrementy) se smaže.

[Jendа]

s heslem v texťáku (zabijte mě! nevím jak jinak, neinteraktivně)

Google: luks keyfile

Já zálohuji do encfs - výhodou je, že se záloha nafukuje nebo naopak zmenšuje podle toho, kolik dat v ní skutečně je. Musel jsem si patchnout rsync, protože v encfs je bug.

encfs je buď na USB disku, nebo ho připojuji přes sshfs (pomalejší). Ta nejdůležitější data zálohuji do zvláštního encfs (má asi 4 GB) a ten pak rsyncuji po Internetu.

[Shadow]

Blowfish je už zastaralý, a nemusí být proto pro diskové šifrování vhodný. Lepší je vybrat si některého z AES finalistů, popřípadě vítěze (Rijndael). Kromě šifrovacího algoritmu je důležité brát ohled i na šifrovací mód - výchozí pro LUKS je snad stále ještě cbc-essiv s minimálně jednou známou zranitelností. Momentálně je asi nejvhodnější mód xts, nastavitelný třeba takto:

cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/zarizeni

Ale v tomhle případě bych opravdu raději doporučil Duplicity...

[xkucf03]

Nemáš možnost použít iSCSI? To by bylo pro sdílení blokového zařízení (nebo souboru) lepší než NFS.

následující sekvence, s heslem v texťáku (zabijte mě! nevím jak jinak, neinteraktivně).

Místo hesla můžeš použít klíč v souboru – takže klíč nebude na vzdáleném disku (zašifrovaný heslem), ale budeš ho mít hezky u sebe. Volba: --key-file

A když už tam mít heslo, tak bych místo echo tajné_heslo | … dal alespoň cat soubor_s_heslem.txt | … (plus ošetřit práva k tomu souboru).

[Kvakor]

Nemáš možnost použít iSCSI? To by bylo pro sdílení blokového zařízení (nebo souboru) lepší než NFS.

Ono by možná úplně stačilo i network block device (nbd), pomocí kterého jde v Linuxu přitupovat na libovolné blokové zářízení. Server navíc běží čistě v uživatelském prostoru, jen klient potřebuje modul v jádře.

[Vantomas]

Pokud se notebook nekdy uspava a nebezi furt, tak by melo byt mozne pres ACPI wakealarm notebook probudit, provest zalohu a pak zase uspat.
Tehda tu do blogu i nekdo psal nejakou aplikaci co si vyrobil viz http://www.abclinuxu.cz/blog/johny/2009/1/acpi-wakeup.

[Vantomas]

Jinak NFS pres wifi a jeste k tomu pres VPN, docela bych se tomu vyhnul. Zasekle NFS je schopno zaseknout cele KDE, protoze se nekde ceka na nejaky zamek, kdo vi jak se to bude chovat u loop zarizeni. Pri pouziti softlock zase hrozi ztrata nebo poskozeni dat na serveru.

Spis bych se porozhlednul po necem jako je rdiff-backup, tedy neco co umi inkrementalni zalohy a tyto se zasifruji pres GPG a potom poslou pres SCP na server.

[yossi]

FS mám šifrovaný, zálohy tiež hoci storage je dôveryhodný.

Na zálohovanie používam Deja-Dup - dva gombíky (záloha, obnova), chodí to samo a je to pekne integrované do gnome (pravý klik na súbor a revízie). Je to blízko toho čo si predstavujem ako ideál - Blow-job backup solution. :)

[gtz]

a nešel by použít Truecrypt?

[Jendа]

Šel a má obdobnou nevýhodu - kontejner alokuje nějaké místo, které se nemění podle množství uložených dat. Navíc TC podle mě neumí resize, dm-crypt ano.

[Habo]

Pokiaľ viem, z menej náhodných dát sa "náhodnejšie" spraviť nedajú bez použitia iných ešte "náhodnejších" dát, takže spôsob, akým sa ten súbor vytvára je naprd...

Nebolo by lepšie ťahať dáta z /dev/dsp (príp. /dev/audio) a do mikrofónu pustiť kvalitný šum z rádia? Prípadne ich ťahať z /dev/video0 a kameru namieriť na zrniacu TV... Alebo ešte lepšie použiť takto viac zdrojov a potom ich merge-núť (napr. bajty na striedačku) To by bola pravdepodobne oveľa kvalitnejšia náhoda...