Portál AbcLinuxu, 31. října 2024 23:50
cryptsetup benchmarkpsal si 6gen Intel... me v s 3gen Intel (i7-3520M):
# Algoritmus | Klíč | Šifrování | Dešifrování aes-xts 512b 1069,0 MiB/s 1057,4 MiB/ss 8gen Intel (i5-8600T):
# Algoritmus | Klíč | Šifrování | Dešifrování aes-xts 512b 1461,5 MiB/s 1468,6 MiB/sSSD pres SATA III da max ~550MB/s
1x NVMe=>LUKS=>LVM=>ext4 (system) 2x HDD=>mdadm=>LUKS=>LVM=>ext4 (data) bootloader sicherboot, tzn.: - na EFI oddilu je linux.efi kterej je generovanej tim sicherboot a obsahuje v sobe kernel, initramdisk a cmdline (je podepsanej vlastnim klicem kterej sem importoval do UEFI (po predchozim smazani vsech v UEFI puvodnich klicu)) - pri startu se zobrazi nabidka, vyberu polozku - natahne a rozbali se jadro a initramdisk, ten se "pusti" a zepta na LUKS heslo (k NVMe) (diky balicku dropbear-initramfs mam moznost se pres ssh pripojit a odemknou remote) - zadam LUKS heslo, tim se odemkne LUKS nad NVMe kde je system kterej nastartuje - system automaticky (diky obsahu /etc/crypttab v rootfs) odemkne pres klic/soubor LUKS nad mdadm/hddpokud by pripadny lokalni utocnik chtel zamenit linux.efi, tak system nenabehne protoze nebude podepsan tim mojim klicem a diky smazani vychozich neprojde linux.efi podepsany beznym distribucnim klicem...
- smazat vychozi UEFI klice a nahrat vlastni umej novejsi UEFI biosy, pripadne EFI KeyTool (z baliku efitools)Sicherboot teda asi nedává smysl používat s dual bootem (Linux + Windows), protože by v Biosu musel zůstat UEFI klíč Microsoftu, že jo?
Unmaintained systemd-boot integration with secure boot support; consider https://github.com/Foxboron/sbctl instead.takze na sbctl asi kouknu, minimalne vypada sobre ze asi umi klice do EFI poslat naprimo, bez nutnosti pouzit 3rd KeyTool ci reboot do BIOSu...
nefunkční disky se musí blízce seznámit s bouracím kladivemJa som si z nich zvykol vybrať magnetky, a platne som používal ako imidžové podšálky (odpivníky). Pri SSD si to už ale neviem predstaviť.
before *
), nahodí cryptsetup luksOpen
(ten si opýta heslo) a keď toto uspeje (bolo zadané správne heslo), pripojí príslušné mountpointy. Pri vypnutí služby zase v opačnom poradí - odpojiť a potom cryptsetup luksClose
.
Systém po štarte ide do runlevelu "default". Do neho sa dá prihlásiť zdiaľky, fungujú základné služby ako VPN, SSH, monitoring a pod. Na prechod do runlevel crypt stačí zadať príkaz rc crypt
. Ten spustí spomínaný custom init.d skript a potom všetky služby, ktoré od šifrovaných dát závisia (databázy, samba, webserver, mail...).
…s intel gen6 procesorem…
Cokoliv 4. a novější generace už bude mít AES-NI instrukce, tj. problém s výkonem rozhodně nebude.
Kdyz budu mit LUKS na cely ten velky datovy disk…
Side note: Ten systémový SSD by měl být taky 100% (nebo téměř 100%, musí-li se z něj bootovat) šifrovaný; fakt není důvod to mít jinak. Šifrování brání například modifikaci systému při vypnutém serveru a několika dalším záludnostem, které jsou sice krajně nepravděpodobné, ale když se proti nim lze relativně snadno bránit, pak proč ne…
je ten LUKS stabilni a bezpecny?
Ano.
…(nebo toho bude pulka leaknuta v nesifrovanych logach na tom systemovem disku?)…
A právě proto má být všechno šifrované, systémový disk také (ne-li především).
Predpokladam, ze nutnost zadavat nejaky klic nebo heslo/frazi pri kazdem bootu pred pripojenim datoveho disku.
Dle nastavení. Může to být založené na TPM. Pak to ale chrání jen před ukradením disku, ne před ukradením celého počítače. (A těžko říct, zda lze věřit TPM, pokud jde o NSA backdoory a o spolehlivost, tedy (ne)možnost zálohovat klíče pro případ selhání…) Nebo může být klíč k LUKS na nějakém bootovacím flashdisku, který lze odpojit. Pak musí člověk na ten flashdisk myslet. Nebo to může být asymetrická kryptografie a hardwarový klíč; pokud možno víc klíčů <—> LUKS key slotů pro případ poruchy jednoho.
Nebo je třeba smířit se se zadáváním hesla při bootu. To lze buď vyžadovat lokálně, nebo taky vzdáleně přes SSH. To druhé pomůže, když člověk potřebuje svůj NAS přebootovat z druhého konce světa.
…mozna horsi rychlost.
Propustnost šifrování s AES-NI je někde v řádu jednotek GB/s, v závislosti na typu procesoru, může to být klidně třeba 10 GB/s. Který disk dá řádově 10 GB/s propustnosti? Zkrátka, krk láhve bude rozhodně disk (nebo i SSD, s výjimkou fakt dobrých PCIe modelů), nikoliv procesor.
Tedy, vyšší vytížení procesoru vlivem šifrování tam samozřejmě bude, ale na propustnost by to opravdu (ale opravdu) nemělo mít vliv. Propustnost určuje disk.
Pouziva se to siroce?
LUKS je zkrátka standard, těžko si lze představit něco širšího.
Bude to v pohode s XFS nebo Ext4?
Ne, nebude. Máme rok 2023, disky už nemají 10 GB, spíš mívají klidně 10 TB, takže zastaralé filesystémy nejsou a nebudou v pohodě. Neumí korektně zálohovat přes atomické snapshoty, nechrání před silent data corruption, nemají ani náznak škálovatelnosti (příklad: který z nich dokáže po přidání dalšího disku přetransformovat sám sebe na RAID1 — bez odmountování?) atd.
Kdo to s NASem a se svými daty myslí dobře, volí Btrfs. (Jen tu a tam, kdo velmi dobře ví, co dělá, zvolí možná ZFS, například je-li skalním fanouškem FreeBSD. Leč kdykoliv se někdo ptá, který FS, odpověď je vždy Btrfs.)
Bud jsem uplne blbej, nebo tem lidem, co si to tak nastavi, nedochazi, ze to zcela neguje cely ten duvod proc to delat a je to uplne nesmyslne, je to jako chtit se naucit plavat, a rict, ze to budu delat jen pokud pri tom nebudu mokry nebo ve vode??
Někdy to chce pozorněji číst dokumentaci. Jindy je zas pravda, že špatné dokumentace se na webu povaluje přehršel.
Automatické zadávání klíče při startu (přesněji: odkaz na klíč přímo v /etc/crypttab
) má obvykle za cíl, aby se klíč zadával jednou, nikoliv víckrát. Příklad:
systemd
, udev
, cryptsetup
a kamarádi) načte během initramdiskové fáze nešifrovaný klíč a otevře jím automaticky (znovu, nezávisle na GRUBu) šifrovaný kořenový oddíl.Kontrolní otázka, soudruzi: Proč nevadí, že je v initramdisku uložený nešifrovaný klíč k LUKS oddílu? Protože initramdisk samotný je šifrovaný (na šifrovaném oddílu) a musí ho napřed dešifrovat GRUB (na základě hesla od uživatele).
To↑ je základní princip (částečně) automatického odemykání. Pochopitelně to ovšem nebude fungovat, pokud je třeba zadávat heslo skrz SSH. K tomu je potřeba mít nějaký kernel a initramdisk (ne nutně ten finální provozní, ale zkrátka nějaký) v nešifrované podobě, ideálně zabezpečený přes SecureBoot + Sicherboot nebo něco podobného.
Další možnosti jsem zmiňoval výše; tam je třeba volit podle situace a požadavků. (Je stroj fyzicky dobře zabezpečený? Musí být schopen nabootovat bez přítomnosti obsluhy? Musí být schopen nabootovat kdykoliv a hned nebo smí čekat na heslo poskytnuté přes SSH? Je přijatelné, aby ztráta části hardwaru vedla ke ztrátě dat, nebo musí být klíče zálohované?)
Zálohuje se to (překvapení!) pomocí send
/ receive
nad sérií snapshotů. Jako obvykle, jako posledních 10+ let, pokud někdo nežil pod kamenem.
…ako sa to obnovuje, ak sa rozsype niektora zlozka?
A co když vedle toho vybouchne atomovka? Jak se to potom obnovuje?
A když se rozsype hovno, co potom???
Takhle pitomou otázku jsem už dlouho neviděl. Když se třeba na Ext4 rozsype adresář, jak se to obnovuje? Nijak. On se totiž nerozsype včas, když se rozsypat má, a místo toho bude vracet zničená data. Nemá totiž checksumy dat ani krávu (CoW).
Jasná odpověď tedy je: Obnovuje se to ze záloh. Když už selže fyzická vrstva (zvaná tvrdé zboží) tak strašně, že to není tu a tam jeden blok ve velkém souboru, ale sejme to rovnou adresář(e), tak potom žádná jiná zázračná možnost neexistuje. Nebo chce někdo „fsck
“ vymýšlející náhodná data? Já už fakt nevím.
Mimochodem, na Btrfs se nejspíš ten adresář obnoví z jiné „dup
“ repliky nebo z jiné RAID1{,C{3,4}}
repliky nebo z RAID{5,6}
parity, dřív než se tím bude muset zabývat uživatel.
XFS nebo Ext4, který nic z výše uvedeného nemá, se bude obnovovat … jak přesně? To je ta moje stokrát opakovaná, ba okřídlená otázka: S čím srovnáváme? Kde je ten etalon, to ideální řešení?
Tiskni Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.