Dotaz: LUKS: Sifrovany disk na domacim serveru/NAS, ano nebo ne?

[JiK]

Otazka do diskuze, chci nazory skusenejsich. Mam v merku domaci server/media centrum/uloziste, je to dell micro s intel gen6 procesorem a 8 gb ram. 1 maly ssd disk na system (openmediavault/debian) a jeden velky ssd na data. V minule debate jsem byl presvedcen ze velky ssd nemam rozdelovat na nejake partisny, ale radeji pouzit quota nebo neco podobneho, omezeni na jine urovni. Ted mam dotaz na sifrovani.

Kdyz budu mit LUKS na cely ten velky datovy disk, bude tam nejaka znatelna ztrata vykonu pri zapise, nebo to bude daleko spis limitovano rychlosti wifi a vseho kolem? je ten LUKS stabilni a bezpecny?

Jake jsou vlastne vyhody a nevyhody sifrovani celeho disku? Predpokladam, ze vyhoda je, ze kdyz mi nekdo ukradne/zabavi ten server, tak si bez hesla nezjisti vubec nic o tom, co tam je. Ani jmena souboru. nic. nula. (nebo toho bude pulka leaknuta v nesifrovanych logach na tom systemovem disku?) Nevyhody? Predpokladam, ze nutnost zadavat nejaky klic nebo heslo/frazi pri kazdem bootu pred pripojenim datoveho disku. mozna horsi rychlost. kdyz se neco pokazi, nebude to nikdo umet opravit. Vse bude slozitejsi a je tam dalsi potencialni zdroj problemu. Unika mi neco? Jake jsou dalsi vyhody a nevyhody? Je k tomu dobra dokumentace? Pouziva se to siroce? Bude to v pohode s XFS nebo Ext4?

Dodatek, nasel jsem hromadu dokumentace, ktera resi JAK to udelat aby se to heslo/klic zadalo samo pri startu. Z pohodlnosti. 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??

Odpovědi

[luky]

rozmyslal som ci nieco napisat sem kedze nemam teraz nahodeny fileserver, som kupil hotove naska ale k sifrovaniu

napr take openbsd sifruje vsetko aspon sa tym chvalia ze swap aj cely disk a tusim aj boot ma to openbsd nejako vyriesene ze pri starte sa zada heslo a vsetko potom je magia openbsd a neviem ci sa da aj usb kluc s heslom to neviem ale riesi to crypto softraid u linuxu neviem ale pre mna je ext4 lepsia nez xfs mal som par krat xfs a ked sa to rozsypalo uz som to nedal dokopy

[X]

Ma to HW akceleraci?

[k3dAR]

Ano

s 6gen intel cpu bude brzda wifi a/nebo sata...
sifroval bych nejen data ale i system disk...
ty navody na auto unlock byli nejspis pro druhej luks dotaz co dela initramdisk, prvni dela Grub (pri sifrovanem i /boot)
pouzivam roky luks pod ext4 a v pohode... misto grub mam sicherboot + v uefi jen vlastni klice, heslo zadam 1x v initramdisk, kdyz rebootuju remote pres ssh odemknu diky dropbear balicku pro initramdisk... ( to by slo s Grub jen pri nesifrovanem /boot protoze k Grub luks dotaz by ses remote nepripojil)

[k3dAR]

btw: rychlost ciste co da CPU si muzes overit:

cryptsetup benchmark

psal 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/s

s 8gen Intel (i5-8600T):

#    Algoritmus |      Klíč |       Šifrování |     Dešifrování
        aes-xts        512b      1461,5 MiB/s      1468,6 MiB/s

SSD pres SATA III da max ~550MB/s
Wifi ci GLAN ti daj max ~100MB/s
i v pripade 10Gbps LAN by LUKS nebrzdil

[frufru]

Jen tak pro informaci amd ryzen 5 2600

aes-xts 512b 2361,3 MiB/s 2350,1 MiB/s

[J]

Budes mit na tom jakakoliv citliva data, nebo jenom fekalni porno stazene z internetu? V pripade prvni moznosti sifruj, v te druhe nemusis. Dopad na vykon to dle typu sifrovani muze mit, ale pokud pouzijes neco s AES tak ten dopad bude minimalni jelikoz CPU podporuje prislusne rozsireni.

[AraxoN]

Ext4 a LUKS (nad mdadm RAID1) používam roky. Výkonnostný problém to bol na starom Atome, na moderných procesoroch už nie.

Šifrovaný mám len dátový disk.

[JiK]

Tohle je přesně to, co chci. Můžeš se rozepsat víc? Jak jsi to nastavil, proč? Jak zadávaš klíč, jak to ustálo různé mimořádnosti a havárie? Je něco, co bys zpětně udělal jinak?

[k3dAR]

zamysli se nad tim sifrovanym systemem i swapem, protoze do obou se muze dostat citliva informace a zaroven muze pripadny lokalni utocnik oboje napadnout pridanim keylogeru apod... ja mam:

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/hdd

pokud 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...

[k3dAR]

* obchrana podepsani vlastim klicem samozrejme vyzaduje zapnutej SecureBoot a zaheslovanej vstup do BIOSu aby nesel vypnout
zaroven nutno rict, ze pokud by utocnik provedl rozebrani stroje, vyresetovani biosu (at uz jumperem, baterkou ci preprogramovanim chipu) tak by napadenej linux.efi se natahnul...

[JiK]

chvili jsem dumal na tim, proc tak slozite zabezpecovat bios a vubec ten system, kdyz by utocnika stejne cekal zaheslovany system, ktery se kope do prdele a ceka na heslo po ssh. Ale pak mi doslo, ze se tak chranis pred nekym, kdo by se ti tam dostal fyzicky, modifikoval prihlasovani, vse vratil zpet, jakoby nic, a cekal, az mu do keyloggeru napises heslo k diskum.

Neni to moc sci-fi scenar? policajti, kdyz to seberou, tak uz to nevrati, aby sis toho nevsiml, bytovi zlodeji taky. To bych se musel bat nejakych tajnych sluzeb nebo podobnych hrozeb, a ti by ze me to heslo dostali daleko snadneji netechnickymi prostredky. kryptoanalyza gumovou hadici, vyhrozovni clenum rodiny, hrozbou konfiskace vseho majetku, etc...

[k3dAR]

neresim co je/neni scifi, proste sem pred casem zacal tento postup delat na veskerem mem (PC)HW (NB, NAS/Server, HTPC, ...), ze kdyz uz sifrovat, tak (v ramci moznosti) poradne...
- neprijde mi to nijak slozite, nastavit heslo do biosu (+zapnout UEFI+SecureBoot a zakazat Legacy) v biosu je vlastnost biosu.
- sicherboot se po instalaci (po rucni editaci /etc/kernel/cmdline) pusti pres "secureboot setup", vygeneruje klice a podepise jima aktuani jadro+initramdisk a hodi to do EFI
(to same pak dela pri aktualizaci jadra a/nebo initramdisk (nebo komponenty co se bundluje do initramdisku))
- smazat vychozi UEFI klice a nahrat vlastni umej novejsi UEFI biosy, pripadne EFI KeyTool (z baliku efitools)

[LarryL]

- 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?

[k3dAR]

v prve rade ted si nejsem jistej zda vubec umi Windows, tim ze pouziva systemd-boot,
kazdopadne pokud ano, tak jak pises, pro Windows bys musel MS klice v EFI nechat a pak by ti mohl nekdo podvrhnout "sicherboot" efi binarku z kompromitovanym initramdisk podepsanou MS klicema(resp. tema co maj distra od MS) a ne tema tvejma...

nicmene diky za otazku zkousel sem hledat jak s tema Win a narazil na github sicherbootu ze pred mesicem ho hodil do readonly a pridal:

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...

[Zopper]

Pokud je to NAS/desktop, tak hlavní riziko je krádež, nebo vyhození starého disku bez pořádného smazání dat (nefunkční disky se musí blízce seznámit s bouracím kladivem). Oboje vyřeší prosté šifrování všeho za /boot, ten samotný v tuhle chvíli roli nehraje. Systémový oddíl bych ale už tak jako tak šifroval, protože si pak člověk udělá třeba certifikát, ten bude sedět někde v /etc, nebo heslo zůstane uložené na swap oddíle...

Pokud jde o notebook, který se podívá aspoň někdy i ven z domu, tak tam nikdy nevíte, kdo se k němu dostane. A jak se říká, to, že je člověk paranoidní, ještě neznamená, že po něm nejdou. Třeba pomstychtivý kolega, který chystá dáreček na rozloučenou, než ho z firmy vyhodí, a tak.

[Peter Golis]

nefunkční disky se musí blízce seznámit s bouracím kladivem

Ja 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ť.

[AraxoN]

Ako píšeš nižšie, tiež som si spočítal, že ak niekto získa fyzický prístup, je veľmi nepravdepodobné, že mi tam do systému nastraží keyloger. Skôr to odpojí a odnesie a po reštarte tak získa nejaký základný systém, ale dáta nie.

Omnoho pravdepodobnejšie je, že sa tam niekto nabúra cez chybu v softvéri. Ale keď je to raz sieťový server, na sieti byť musí. Takže silné heslá, konzervatívne nastavenia, firewall, VPN a monitoring. Viac asi nespravím.

Moje konkrétne riešenie asi nebude prenositeľné. Ja som si to spravil tak, že som vytvoril nový runlevel (OpenRC) s názvom "crypt". Služby, ktoré potrebujú pripojený šifrovaný disk sú až v tomto runleveli. Do init.d som si spravil vlastný skript, ktorý sa spustí pred všetkými ostatnými (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...).

[Max]

1) Problém s výkonem by byl na starších CPU, které nepodporovaly akceleraci u šifrování (Atomy apod.), s gen6 nebude problém.
2) Ano, LUKS je plně stabilní, není tam žádný problém.
3) Ano, LUKS je bezpečný (používá dostatečně silné šifrování)
4) Výhoda LUKS, třeba v mém případě, je taková, že když bych reklamoval disk, nemusím se bát, že má data budou čitelná v cizích rukou.
5) fyzická bezpečnost je jiná pohádka, kdo má fyzický přístup, může časem vyloudit vše (keylogger, webkamera, ukrást token s certifikátem pro dešifrování, vyresetovat bios a obejít secure boot atd. atd. atd.)
6) LUKS je jen další vrstva, něco jako třeba dělá mdadm (RAID1 apod.), nezáleží na tom, jaký FS je nad tím, z pohledu LUKS je mu to jedno a z pohledu FS je mu jedno, co je pod tím.

Jak už jsem psal, já používáš šifrování primárně kvůli tomu, kdybych chtěl hw reklamovat, nebo kdybych chtěl z nějakého důvodu udělat rychlý blok (na dálku máznout klíče a znepřístupnit tak data).
Pro mě tedy dává smysl mít klíč součástí bootu a automaticky odemykat LUKS.
Zdar Max

[Bohatyr]

Ahoj,

jedna věc je bezpečnost, druhá, jak v případě HW poruchy SSD/disku z něj vyzobeš čitelná data? Jo... zálohuj :) Na ext. disk? Šifrovaný? Uložený v trezoru v jiné lokaci? Na jinou NAS? Šifrovanou? Umístěnou mimo tvé bydliště? Do cloudu? S šifrováním na straně klienta? Tohle už mě dávno přešlo, ale rozumím, že někdo tu potřebu šifrování všeho, všude a za všech okolností mít bude.

... a externí disk se šifrovanou zálohou pro jistotu pořádně popsat. Aby sis ho později náhodou nespletl, až zjistíš, že disk nemá žádné partišny a začneš si myslet, že je vlastně prázdný. Pěkně napsat: bacha šifrovaný disk se zálohou, heslo je "Máňa".

[JiK]

Kdepak. Heslo je posledních 8 číslic pi.

[Radek]

Jen taková malá zajímavost - aes-512 je na 64bit cpu rychlejší jak aes-256 ;)

[Radek]

teda ne vždy, ale zpravidla

[Andrej]

…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:

1. GRUB se zeptá uživatele na heslo k LUKS.
2. GRUB sám pro sebe vypočítá master key a dokáže tak číst LUKS oddíl.
3. GRUB najde v kořenovém LUKS oddílu souborový systém (kde Btrfs samozřejmě patří mezi podporované).
4. GRUB načte ze souborového systému (uvnitř LUKS) kernel a initramdisk a spustí kernel.
5. Initramdisk má v sobě nešifrovaný klíč k LUKS, který je přístupný během první fáze bootování.
6. Systém (tedy, 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.
7. A normálně se nabootuje a nic už se podruhé na heslo neptá, byť je kořenový oddíl šifrovaný.

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é?)

[xxxs]

ako sa toto zalohuje a ako sa to obnovuje, ak sa rozsype niektora zlozka?

[Andrej]

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í?

[xxxs]

nehanim tvoj fancy FS, mozes byt informativnejsi.

[MP]

Ti, kdo tvrdi, ze vykonostni problem byl jen na starych cpu, se velmi myli. Mame luks na Xeon Gold (myslim 6132?) nad 4x SAS 12G SSD disky a vykonostni propad je priblizne 25-30%.

[Max]

A nesouvisí to i s aplikacemi záplat pro Xeony? Jen se ptám.
Jinak ten propad se týče čeho? I/O při zápisu, nebo i čtení, nebo i datového toku?
Zdar Max

[MP]

Je to aspon 5 let zpatky, takze s tema zaplatama to jeste tehdy takova prekerka nebyla. Fio testy, propad v R i W. Tehdy jsem delal zkusebne i luks na slabsim, ale aktualnim Xeonu (supermicro X10) nongold, tam byl propad dokonce 90%, jen nevim, ktereho ssd pole se tykalo - je tam nvme i sata.

[Max]

Myslím, že se tomu dá bez problémů věřit, že to při velké zátěži na rychlém poli bude mít overhead. Jde o to, že dotazy jsou o desktopu, domácím serveru apod. Tam podle mě nelze dosáhnout na nějaký limit, protože už jen samotné diskové úložiště bude pomalejší, a to i ssd, protože i ty jsou docela pomalé.
Zdar Max

[AraxoN]

Ešte ten Atom mám... pošlem Ti ho na testy?

Ak ten Tvoj disk normálne dáva 700MB/s, s Atomom pôjde na 16MB/s. Prepad o slabých 25% Ti potom razom príde celkom zanedbateľný.

V Tvojom prípade je ten disk rýchlejší než to šifrovanie na CPU. S klasickým rotačným diskom to neplatí, takže ani dopad šifrovania nie je taký veľký.