Šifrování vzdálené zálohy

[Martin]

Mozna jsem trosku paranoidni, ale vytvoril jsem si zalozni prostor na jednom ne moc znamem virtualnim hostingu a jelikoz jim moc neduveruji tak:
Data ukladam pres rsnapshot do truecrypt souboru, ktery mountuju manualne po bootu OS.
SSH na primarni server je povoleno skrze authorized_keys, pricenz identity file klienta je ulozen taktez v truecrypt ulozisti.

Ted se chci zeptat je vubec mozne dostat se do TC souboru pro nektereho z adminu hostingu? A co pro to musi udelat?
Doufam ze nevidi primo primountovany adresar, to by me dost mrzelo

[Reklama]

[David Strejc]

Jestli "cosi" uploadujete na cizi stroje (jsou v moci admina - stroj jste si neinstaloval sam) a chcete tam soubory "videt", tak je "tam" musite taky rozsifrovat - cili je pak na 100% muze videt i majitel boxu. Jestli tam uploadujete jen zasifrovany snapshot, ktery rozsifrovavate jinde, tak neuvidi pravdepodobne nic.

Je to jako s postou - muzete mit TLS muzete mit POPs IMAPs muzete mit certa v krabicce, ale ty soubory v konecnem dusledku lezi na disku nezasifrovane, cili administratori se k nim dostanou.

To je cele.

[stilett]

Jestliže si admini nechali nějaký způsob, jak na virtuálním stroji získat roota, tak se můžou dostat k přimountovanému truecryptovému adresáři (jestli jsem správně pochopil, že ho mountujete na tom virtuálním stroji).

Já to dělávám tak, že ze svého počítače pomocí sshfs přimountuju adresář ze serveru, kde je uložen zašifrovaný soubor s truecryptovým diskem a tento truecryptový disk si přimountuju na svém počítači. Heslo tedy zadávám na svém počítači, rozšifrované to je pouze na něm. Na server chodí jen zašifrovaná data.

[Martin]

No dobre, nejedna se o zadne prisne tajne vladni dokumenty, chci pouze snizit riziko, ze se v tom bude nekdo hrabat...
Otazka mela znit co musi udelat dotycny admin, aby se do toho adresare podival? Heslo roota jsem zmenil pres SSH, zadny key allowed klic jsem nenasel, chroot by mu asi nepomohl ze?

Jinak pokud sem to dobre pochopil, pres sshfs by se dala udelat opacna metoda zalohovani, kdy primarni server sam primountuje pres ssh sifrovany soubor a zalohuje na nej rozdilove data? Nebude to pomale?

[Jenda]

Doporučuji zálohovat lokálně do encfs a tento encfs tam následně rsyncovat. Rsync možná bude potřeba patchnout: https://bugzilla.samba.org/show_bug.cgi?id=3752

Jinak co musí udělat - záleží na virtualizační technologii, ale když už nic, tak ti může podvrhnout binárku TC, aby mu zadávané heslo poslala mailem.

[Reklama]

[stilett]

Ano pochopil jste správně, že záloha je iniciována z opačné strany. Pro rozdílovou zálohu to pomalé bude, pro plnou to velký rozdíl nebude.

Musíte si rozmyslet, zda chcete, aby virtuální server viděl na chvíli data rozšifrovaná. Buď je vidí rozšifrovaná a může počítat kontrolní součty pro porovnávání a nemusí se přenášet všechna data, nebo nic rozšifrovaného nevidí, ale pak musí poslat druhé straně všechna data, aby ona mohla soubory porovnat. Nebo to jde dělat nadvakrát, viz dále.

Pokud se jedná o jednu hromadnou operaci (což záloha bývá), tak je opravdu lepší vytvořit si lokální šifrovaný disk (třeba tím TrueCryptem) uložený v souboru, připojit ho u sebe, do něj zazálohovat data, odpojit ho či jinak vynutit uložení všech dat, a pak rsyncem přenést zašifrovaný soubor s truecryptovým diskem na virtuální server. Jak při lokální záloze, tak při přenosu na server se mohou přenášet jen rozdíly.

Jestliže se jedná o více drobných operací, tak je pohodlnější způsob, který jsem popsal ve svém předchozím příspěvku.

Co se paranoii týče. Jde o to, zda důvěřujete nainstalovanému softwaru na virtuálním stroji, jestli nemá nějaká zadní vrátka. Stačí, aby tam byl nainstalovaný upravený démon běžící pod rootem (např. sshd akceptující rovněž nějaké zadrátované univerzální heslo pro roota), který umožní ovládat stroj jako root. Jako root můžete přistupovat do všech přimountovaných adresářů, udělat díru do firewallu a data zkopírovat kamkoliv. Nebo můžete nainstalovat keylogger (pokud už tam není :-). Tož tak.

[Martin]

Nejsem si jistej jestli sem to pochopil spravne. Takze to zopakuji:

Na primarnim serveru bezi lokalne rsnapshot. Pokud ho tedy prekonfiguruji tak, aby zalohoval do TC, ktery bude mit naprikald velikost 100GB. Pak tedy staci pres rdiff, tento 100GB  soubor presunout na zalozni server, a dejme tomu jednou denne mu rdiffem posilat rozdilovou zalohu.

1. nebudou tyto inkrementalni zalohy prilis velke? A lze takto rdiffovat napriklad 20 dni zpet dejme tomu do nekonecna?
2. Nebude 100GB soubor pro rdiff priliz narocny? (CPU, HDD)

Jestli to tak je, zni to dobre i bezpecne

[Jenda]

Já to dělávám tak, že ze svého počítače pomocí sshfs přimountuju adresář ze serveru, kde je uložen zašifrovaný soubor s truecryptovým diskem a tento truecryptový disk si přimountuju na svém počítači. Heslo tedy zadávám na svém počítači, rozšifrované to je pouze na něm. Na server chodí jen zašifrovaná data.

To je hrozně pomalé, protože FS má strašlivou režii - například při spuštění rsyncu se musí přečíst všechny bloky, ve kterých jsou časy změn souborů. Co jsem tak zkoušel, tak je problém v rozumné době jenom vyrobit na megabitu ext2.

[stilett]

Bylo to myšleno tak, že ten truecryptový disk si budete nechávat na primárním stroji a do něj budete dělat zálohy pomocí rsnapshotu. Musí být velký tak, aby pojal dostatečné množství záloh rsnapshotu (řekněme 100GB). Když rsnapshot dokončí svou práci, tak pomocí rsyncu přenesete zašifrovaný soubor s truecryptovým diskem na zálohovací server (rsync umí použít ssh pro vytvoření tunelu a chytře porovnat rozdíly na obou stranách. Žádné sshfs pak není potřeba.). Poprvé bude potřeba překopírovat na záložní server celých 100GB, ale potom se budou přenášet jen rozdíly. Rozdíly v zašifrovaném souboru by měly být mírně větší než velikost snapshotu vytvořeného rsnapshotem.

U rsyncu při posílání velkých souborů si pohrajte s nastavením parametru --block-size.

Toto řešení plýtvá místem na primárním stroji, ale je bezpečné a na pro linku úsporné. Pro lepší výkon a úsporu místa je samozřejmě lepší šifrovaný disk připojovat na zálohovacím, virtuálním, stroji, ale má to ty bezpečnostní nevýhody popsané dříve.

[stilett]

to Jenda: Pomalé to je, ale nepřislo mi to tak hrozné. Souhlasím, že sshfs a rsync nejsou přátelé.

[Martin]

K tomu presunu snapshotů do TC, predpokladam ze mohu pouzit rsync -aH od kam  ? Nenastane nejakej problem ?

[Mirek Prýmek]

Nebo by ještě šlo použít těžší kalibr - např. Baculu:

Bacula permits file data encryption and signing within the File Daemon (or Client) prior to sending data to the Storage Daemon. Upon restoration, file signatures are validated and any mismatches are reported. At no time does the Director or the Storage Daemon have access to unencrypted file contents.

Encryption and signing are implemented using RSA private keys coupled with self-signed x509 public certificates. This is also sometimes known as PKI or Public Key Infrastructure. Each File Daemon should be given its own unique private/public key pair. In addition to this key pair, any number of "Master Keys" may be specified - these are key pairs that may be used to decrypt any backups should the File Daemon key be lost.

http://www.bacula.org/5.0.x-manuals/en/main/main/Data_Encryption.html

Na stroji, který máš pod správou, by běžel director a file daemon, na cizim hostingu jenom storage daemon. Ovšem chce to vymyslet nejenom dobrou politiku zálohování (což u tohodle těžšího kalibru nemusí být úplně triviální), ale i dobrou politiku práce s klíči, hlavně s master keys.

Má to zepár háčků, např. na storage daemonovi je potřeba udělat několik zálohovacích médií, která se budou v pravý čas odmountovávat, jinak při kompromitaci directoru by útočník mohl smazat zálohy.

atd. atd.

[Martin]

Hm ted jsem to projistotu cele testoval, bohuzel pri pouziti rdiff-backup na 500MB TC kontajner, to pokud zmenim neco na mountovanem disku pak ho projiostotu i odpojim, nezaregistruje zadne zmeny...
pouzity prikaz:  rdiff-backup /tc/ /zaloha/

nevim jakou formou ta kontrola zmen probiha, ale dost me to desi.

[Martin]

Jinak k tomu puvodnimu reseni kdy se primo na VM mountuje TC kontajner a pomoci rsnapshotu se vzdalene pres SSH tvori zalohy, vyskytla zavazna chyba. Pokazdy se server pretizi, nelze nacist ani odpojit TC a kernel hlasi toto: task loop0 blocked for more than 120 seconds

Zlobit to zaclo az kdyz tam bylo nekolik zaloh.

z googlu taky nejsem moudrejsi...