Fórum Root.cz
Hlavní témata => Software => Téma založeno: czipis 23. 03. 2015, 15:55:26
-
resim nasledujici problem:
chci prevezt server z mista A na misto B a chci pred prevozem zasifrovat disky a po prevozu zase uvest do puvodniho (rozsifrovaneho) stavu.
myslenka je takova, ze server v miste A vypnu, nabootuju z flashky nejake live distro, provedu zasifrovani celeho /dev/sda na druhe strane udelam to same jenom s desifrovanim.
hledam ten spravny tool na sifrovani, ktery by provadel in-place sifrovani bez potreby nejakeho dalsiho mista. V idealnim pripade by to sifrovani mohlo jit pozastavit (a spustit od mista kde predtim prestal)
-
cryptsetup to umí, jen nesmíte použít luks. A musíte si pamatovat šifru, hash, atp. sám.
-
Uprimne bych si tohle bez mohutneho zalohovani nelajsnul. A jak ma clovek zalohy, tak uz je pomalu jednodussi si tu opicarnu odpustit a po prevozu obnovit ze zalohy.
-
s tim cryptsetupem si nejsem uplne jisty. zda se ze vytvori device, ktery sifruje az ve chvili kdyz do nej neco zapisuju. Ja potrebuju aby offline provedl zasifrovani celeho device ktery mu dam
principialne to je jednoduche udelat. ctu device napr po blocich 1MB. Nactu blok do pameti, zasifruju, zapisu zasifrovany blok zpet na device (na jeho puvodni misto) a jdu na dalsi blok. To ze je tu riziko, ze v prubehu teto operace dojde k selhani HW/napajeni proste pripoustim a akceptuji.
pri nejhorsim si to sam zautomatizuju pres dd if=device of=mem bs=1M seek=X count=1| openssl mem | dd if=mem of=device bs=1M seek=X count=1; X++
-
Kdybys měl na konci trošku místa, tak už na to je hotový tool. http://www.johannes-bauer.com/linux/luksipc/ (první odkaz z mého Googlu!!!)
Možná by to šlo ohnout aby fungoval inplace.
-
na ten luksipc jsem taky narazil, ale je prave potreba nechat mu tam to misto. sice to asi neni nerealne mu ho tam zaridit, ale rad bych se obesel bez nej.
-
Mam z toho trochu pocit, jako bys ta data nenavidel ;)
-
Mam z toho trochu pocit, jako bys ta data nenavidel ;)
dobre predtim udelam zalohu dd if=device of=/external/backup, pak to cele "NEJAK" zasifruju, server prevezu, "NEJAK" desifruju a kdyz se mezitim neco posere, tak potom adhoc prevezu zalohu z mista A. Nechci to delat ale cele pausalne, protoze nezasifrovane to proste z duvodu security nemuze opustit misto A a je to cele procesne zdlouhave ten prenos/prevoz zajistit.
-
A o jakem objemu dat je tady rec? A disky jsou v RAID nebo jak?
-
jedna se o desitky serveru, vetsina ma RAID1 ze dvou disku na HW radici (HP Smart Array) takze v OS je to uz jako jeden device, takze netreba resit. Vetsina z nich ma 250GB, vyjimky maji 1-2TB.
-
Hm, tak pokud najdete soft, ktery dela, co chcete, tak nez udelate zalohy a zasifrujete to, tak vam vyrostou nehty o pet centimetru. Nebylo by lepsi disky vyndat, onalepkovat, aby se vedelo, kam patri a najmout si na jejich prepravu nejake bouchace s pancerovym autem? Nejaky ten group4 security nebo jak se to jmenuje.
-
Totální nesmysl a ztráta času.
-
Rychlost je to posledni, co musis resit. Ve srovnani s potrebou ty servery nekam fyzicky prevezt... AES-NI ti umozni sifrovat vicemene na rychlosti rozhrani tech disku.
Problem neni, jak to udelat rychle, ale jak to udelat spolehlive.
Na jak tluste lince to je? Da se zneuzit cloud k docasnemu ulozeni tech dat?
-
nevim, jestli to pomuze, ale koukni sem:
http://asalor.blogspot.cz/2012/08/re-encryption-of-luks-device-cryptsetup.html
cryptsetup-reencrypt
Example: Switch unencrypted installation to encrypted
-
Vaše debata mě přiměla to prostě vyzkoušet. O této možnosti dávno vím, ale nikdy jsem nezkoušel, až dneska:
# vytvoříme si klíč
root@bigos:/# dd if=/dev/random of=/tmp/key bs=512 count=1
0+1 records in
0+1 records out
113 bytes (113 B) copied, 0.000146124 s, 773 kB/s
# vytvoříme si nějaké blokové zařízení, 100MB bude stačit
root@bigos:/# lvcreate -L 100M -n test rootvg
Logical volume "test" created
# to blokové zařízení zaplníme nějakým smetím
root@bigos:/# dd if=/dev/urandom of=/dev/rootvg/test
dd: writing to '/dev/rootvg/test': No space left on device
204801+0 records in
204800+0 records out
104857600 bytes (105 MB) copied, 13.7658 s, 7.6 MB/s
# spočítáme si hash toho smetí
root@bigos:/# sha1sum </dev/rootvg/test
f292dd2538711b3b4798116f75c81b72cee4197a -
# vytvoříme si šifrované zařízení
root@bigos:/# cryptsetup -c twofish-xts-plain -s 512 --key-file /tmp/key create encryptedtest /dev/rootvg/test
# zašifrujeme, tedy zkopírujeme data dd-čkem z nešifrovaného do šifrovaného
root@bigos:/# dd if=/dev/rootvg/test of=/dev/mapper/encryptedtest bs=4096
25600+0 records in
25600+0 records out
104857600 bytes (105 MB) copied, 3.32001 s, 31.6 MB/s
# checkneme si, zda šifrované zařízení obsahuje to stejné smetí, jako to nešifrované
root@bigos:/# sha1sum </dev/mapper/encryptedtest
f292dd2538711b3b4798116f75c81b72cee4197a -
# ano, obsahuje
# zrušíme šifrované zařízení
root@bigos:/# cryptsetup luksClose encryptedtest
# ano, opravdu bylo zrušeno
root@bigos:/# cryptsetup luksClose encryptedtest
Device encryptedtest is not active.
# pro jistotu si checkneme, že nešifrované zařízení nyní obsahuje jiné smetí, než obsahovalo na začátku, tedy že je to opravdu zašifrovano
root@bigos:/# sha1sum </dev/rootvg/test
ec07359db29eadaf587d2c708c82cad0eeaf1591 -
# ano, hash je jiný, je to zašifrované
# opět vytvoříme šifrované zařízení, tentokrát s jiným jménem
root@bigos:/# cryptsetup -c twofish-xts-plain -s 512 --key-file /tmp/key create encryptedtest2 /dev/rootvg/test
# zkontrolujeme si hash na tom právě vytvořeném zařízení
root@bigos:/# sha1sum </dev/mapper/encryptedtest2
f292dd2538711b3b4798116f75c81b72cee4197a -
# ano, je takový, jaký očekáváme, můžeme se pustit do dešifrování
# dešifrujeme
root@bigos:/# dd if=/dev/mapper/encryptedtest2 of=/dev/rootvg/test bs=4096
25600+0 records in
25600+0 records out
104857600 bytes (105 MB) copied, 1.54076 s, 68.1 MB/s
# zavřeme
root@bigos:/# cryptsetup luksClose encryptedtest2
# opravdu se zavřelo?
root@bigos:/# ls -l /dev/mapper/|grep encrypt
# ano
# hotovo, zkontrolujeme hash
root@bigos:/# sha1sum </dev/rootvg/test
f292dd2538711b3b4798116f75c81b72cee4197a -
# očekávaný
Závěr: funguje to, jak jsme očekávali. Nicméně jedna chyba či výpadek napájení = sbohem data.
Petr
-
Výpadek napájení můžeš řešit tak, že budeš šifrovat např. po 100MB kouscích a ne inplace.
Tzn. zašifruju 100MB, zkontroluju konzistenci, přepíšu nezašifrované zašifrovaným, jdu na dalších 100MB.
Pokud to spadne v prostřed, tak vždy bude jedna kopie dat správně.
-
Těch 100MB se přeci nebude zapisovat v nějaké transakci (nejsme na úrovni (transakčního) filesystému) a bude se zapisovat nenulový čas. IMO nebudeme vědět, kolik z těch 100MB se opravdu zapsalo na disk v okamžiku výpadku.
-
Na to je potrebne to miesto navyse aby vzdy existovala zaloha nezapisaneho bloku a info o tom, ktory posledny blok bol zapisany.
-
diky pedro, konecne nejaka uzitecna rada na moji otazku a ne offtopic.
Podivuju se, ze to funguje, ale sam jsem to vyzkousel a dava to ocekavane vysledky ;-)
-
Taky je potreba resit otazku, zda to, co je "zapsane", je skutecne zapsane a nevisi to nekde v cache...
Dohromady to neni uplne jednoduche udelat poradne.
-
no ja bych to stejne udelal tim reencrypt, ted ve verzi 1.6.7 je i podpora rozsifovani za chodu
* Support permanent device decryption for cryptsetup-reencrypt.
To remove LUKS encryption from a device, you can now use --decrypt option.
ad Pedro: -xts-plain se uz dlouho nedoporucuje kvuli opakovani na velkych zarizenich (coz je asi ten pripad) dej -xts-plain64 a sifru aes, jestli mas aes-ni, jinak twofish taky dobry
-
udelal jsem ted lehky benchmark a jeden server (250GB) to zasifruje za necele 2 hodiny, coz je uplne v pohode. Za tu dobu mi nehty stihnou povyrust o cca 8μm, coz se da prezit :P
-
udelal jsem ted lehky benchmark a jeden server (250GB) to zasifruje za necele 2 hodiny, coz je uplne v pohode. Za tu dobu mi nehty stihnou povyrust o cca 8μm, coz se da prezit :P
To jo. Akorat jste rikal, ze tech serveru jsou desitky. A nejvetsi prdel by pak byla, kdybyste nekam zabordelil klic. To by pak data byla uplne v bezpeci. ;-)
-
udelal jsem ted lehky benchmark a jeden server (250GB) to zasifruje za necele 2 hodiny, coz je uplne v pohode. Za tu dobu mi nehty stihnou povyrust o cca 8μm, coz se da prezit :P
To jo. Akorat jste rikal, ze tech serveru jsou desitky. A nejvetsi prdel by pak byla, kdybyste nekam zabordelil klic. To by pak data byla uplne v bezpeci. ;-)
Zabordelit klic, to je skutecne pravdepodobny scenar... Ale pokud te trapi tahle vec, muzes si predstavit dva yubikey, tiskarnu a obalku jako reseni.
Chapu to spravne, ze navrhujes ty servery sifrovat sekvencne, aby to trvalo dyl? :-D
-
Chapu to spravne, ze navrhujes ty servery sifrovat sekvencne, aby to trvalo dyl? :-D
Ne. Nicmene to sifrovani budes minimalne sekvencne spoustet. Pokud nehodlas ke kazdemu serveru poslat extra manika s live distrem. Coz asi neudelas, protoze jim nebudes verit, ze to aspon jeden nezkurvi. A, BTW, pokud to nechces sifrovat sekvencne, aby to trvalo dyl, tak si priprav desitky klicenek, na kazdy server jednu. Pak si ale dej pozor, aby se ti nejaka nezabehla, protoze bacha, je tam ten klic.
-
co jsem potreboval vedet jsem uz zjistil, neni treba vymyslet dalsi coby kdyby.
trollum netreba vysvetlovat PXE boot a remote management.
-
co jsem potreboval vedet jsem uz zjistil, neni treba vymyslet dalsi coby kdyby.
trollum netreba vysvetlovat PXE boot a remote management.
Tak jo. Budete se babrat s PXE kvuli tomu, abyste to jednou zabootoval a zasifroval? A mate vsude boot rom?
-
Myslím, že docela dobře ví, co dělá. Možná bys měl přehodnotit svůj postoj, podle kterého jsou všichni zlí blbci, co si ani nedovedou zavázat tkaničky ;)
-
Myslím, že docela dobře ví, co dělá. Možná bys měl přehodnotit svůj postoj, podle kterého jsou všichni zlí blbci, co si ani nedovedou zavázat tkaničky ;)
Ja nerikam, ze je blbec. Jen si nejsem jisty, jestli se vyplati delat se s PXE jen kvuli jednorazovemu bootu pro sifrovani. Ono rozchodit PXE take leckdy neni zalezitost na deset minut a take ne vsude je vzdycky boot ROM, protoze ho tam dosud nikdo nepotreboval. Nakonec by mohlo byt jednodussi nakopirovat dvacet flashek s live distrem.
-
tak boot bude nejmin dvourazovej, bodA-zasifrovat, bodB-desifrovat, pri desitkach serveru by tedy pxe boot probehl celkem tedy treba 75x...
cas na zprovozneni pxa bude naprosto minimalni(nebo uz je k dispozici) v porovnani s casem cele akce, pripadne servery bez bootrom (pokud vubec budou) lze obejit s ipxe na cd/usb...
-
ano PXE je v siti davno rozchozeny a pouzivany, takze jdu cestou nejmensiho odporu.
Shanet nekde 20 usb flashdisku by byla opravdu posledni moznost, ktera by me napadla. Jelikoz se jedna servery s iLO, tak bych predtim urcite mountoval virtualni CD ze ktereho bych bootoval.
koncim tuto diskuzi, co jsem potreboval to uz mam. 8)