2024. március 29., péntek

Gyorskeresés

Útvonal

Cikkek » Számtech rovat

Egy ZFS + LUKS sztori - játék a tűzzel

Titkosítani szerettem volna az asztali gépemet is, mert "mi van, ha ellopják" :)

[ ÚJ TESZT ]

LUKS kötetek boot alatti automatikus feloldása

Elérkeztem ahhoz a ponthoz, hogy lehetővé tegyem a header és key fájlok segítségével a titkosított lemezek feloldását boot legelején. A felállás a következő:

1. A gépen Windows van SSD-re telepítve, első partíció, és onnan is indul.

2. A Linux /boot-ja USB stick-en van titkosítás nélkül, egy plusz EFI partícióval, így ha az USB be van dugva a gép elejébe, a Debian bootol

3. jelszóval a / -t feloldaná (ami az SSD-n egy titkosított kötet, itt értelemszerűen key és header fájl mókolás nincs, a feloldókulcs a kézzel bepötyögött kód)

4. Debian indul, és hát ilyenkor fel kéne oldania a 3 db HDD-t, hogy azok titkosítatlan logikai rétegei megjelenjenek /dev/mapper-ben és ahogy a boot folyamat egyik következő lépésében a ZFS alrendszer is öntudatára ébred, már keresse is /dev/mapper-ben a 3 lemeznek megfelelő "diszket", hogy mountolja a poolt nekem a megfelelő könyvtárba.

Ez az automatikus titkosítás-feloldás az /etc/crypttab -ban történik, ez most szűz verzióban, / (gyökér) partíció titkosításával így néz ki:

root@desktop:~/luks2/zfsraidz1# cat /etc/crypttab
sdb1_crypt UUID=afa71100-675d-42ee-baa1-2a2ee159bdfb none luks,discard

Tehát 1 sor van benne, aztán jónapot.

1. oszlop: a titkosított eszköz neve /dev/mapper-ben majd

2. oszlop: abszolút elérési útvonal, vagy egyéb azonosítóval hivatkozás az eszközre (itt UUID alapján, így a meghajtók esetleges cserélgetése nem köp bele a levesbe)

3. oszlop: key fájl (mivel itt "none" áll, jelszót kér be feloldáskor)

4. oszlop: titkosítás típusa és én - lévén SSD - a discard-ot is használom, modern SSD-ken már nemigen kell az auto garbage collection / wear leveling miatt, itt ez arról szól, hogy nagyon kicsi biztonság-csökkenés mellett, ami szerintem egy földi halandónak belefér, a felsőbb, /dev/mapper rétegben kiadott TRIM utasítások végigmennek át a titkosított rétegen is a fizikai diszkig. Aki hiperparanoid, ne használjon discard-ot. Azt zárójelben érdemes tudni, hogy SSD titkosítása LUKS-szal annyiban különbözik az SSD gyári (natív, beépített, UEFI-ben aktiválható) titkosításától (ebben a kontextusban) :) , hogy discard hiányában az SSD nem tudja, mely blokkok szabadok ténylegesen és melyek nem, ugyanis a LUKS kriptográfiai réteg amikor dd nullázunk egy /dev/mapper-es feloldott eszközt, full random adatokkal teleírja a partíciót vagy teljes SSD-t. LUKS mellett discard-ot kihagyva a biztonság totál maxon marad, viszont a meghajtó jobban kopik, ha így tetszik. De szerintem ez marginális és otthoni felhasználás mellett mehet a discard nyugodtan a LUKS rétegnek is (meg majd fstab-ban is).

Nos, ebbe a crypttab-ba kellene belegyömöszölnünk a mi 3 HDD-nket is, hogy a boot folyamat során automatikusan feloldódjon a 3 diszk. Így a rendszerünk lényegében egy jelszavas / (gyökér) partíciós feloldással van "csak" védve, majd ezt átgondolom, jó-e így, vagy legyen a titkosítatlan /boot-on az SSD-s gyökér partíciónak is egy random generált kulcsa és headerje. Ugyanis, ha a gépet magára hagyom, az USB sticket kihúzom, előtte /boot-ot át-mountolom a feloldott SSD-n lévő /boot-ba, ergo míg fut a gép, nincs gond (míg nem frissítek valamit, de akkor visszadugom) :D, ha pedig USB nélkül indítja bárki, a Windows jön be és az illető max. sejti, hogy az SSD-n még van valami ismeretlen cumó, de ha csak nem valami Vérpista hekker, nemigen fog tudni mit kezdeni az egésszel. Meg amúgy sem feltétlen, ez nem egészen úgy működik, mint a filmekben, bár az eNeSA-t nem kérdeztem még ilyenekről... :)

No, akkor kreáljunk 3 újabb bejegyzést a cryptab-ba a 3 új HDD automatikus feloldásához:

root@desktop:~# echo "0x5000c500c4026a8f /dev/disk/by-id/wwn-0x5000c500c4026a8f /root/luks2/zfsraidz1/key_0x5000c500c4026a8f.bin luks2,header=/root/luks2/zfsraidz1/header_0x5000c500c4026a8f.bin" >> /etc/crypttab

root@desktop:~# echo "0x5000c500c4029c75 /dev/disk/by-id/wwn-0x5000c500c4029c75 /root/luks2/zfsraidz1/key_0x5000c500c4029c75.bin luks2,header=/root/luks2/zfsraidz1/header_0x5000c500c4029c75.bin" >> /etc/crypttab

root@desktop:~# echo "0x5000c500d50df969 /dev/disk/by-id/wwn-0x5000c500d50df969 /root/luks2/zfsraidz1/key_0x5000c500d50df969.bin luks2,header=/root/luks2/zfsraidz1/header_0x5000c500d50df969.bin" >> /etc/crypttab

Ellenőrzés: bent van minden szépen:

root@desktop:~# cat /etc/crypttab
sdb1_crypt UUID=afa71100-675d-42ee-baa1-2a2ee159bdfb none luks,discard
0x5000c500c4026a8f /dev/disk/by-id/wwn-0x5000c500c4026a8f /root/luks2/zfsraidz1/key_0x5000c500c4026a8f.bin luks2,header=/root/luks2/zfsraidz1/header_0x5000c500c4026a8f.bin
0x5000c500c4029c75 /dev/disk/by-id/wwn-0x5000c500c4029c75 /root/luks2/zfsraidz1/key_0x5000c500c4029c75.bin luks2,header=/root/luks2/zfsraidz1/header_0x5000c500c4029c75.bin
0x5000c500d50df969 /dev/disk/by-id/wwn-0x5000c500d50df969 /root/luks2/zfsraidz1/key_0x5000c500d50df969.bin luks2,header=/root/luks2/zfsraidz1/header_0x5000c500d50df969.bin

Egyébként úgy tudom, sima "luks" is mehetne típusba "luks2" helyett, de nem dobott hibát, így maradt.
No, innentől már reboot.
* * * * * * * * * * * * * * * * *

Újra itt. A gép az SSD feloldása (/) után vagy 1-2 mp-ig megrecsegtette a HDD-ket, ahogy feloldotta azokat + a ZFS felvette a poolt, és voilá:

root@desktop:~# zpool status
pool: zfsraidz1
state: ONLINE
scan: scrub repaired 0B in 1 days 08:38:02 with 0 errors on Tue Jun 7 22:47:53 2022
config:

NAME STATE READ WRITE CKSUM
zfsraidz1 ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
0x5000c500c4026a8f ONLINE 0 0 0
0x5000c500c4029c75 ONLINE 0 0 0
0x5000c500d50df969 ONLINE 0 0 0

errors: No known data errors

Fstab-bal nem kell törődnünk, mivel a /dev/mapper-be feloldott diszkek (aliasain) ZFS van és annak fájlrendszerbe mountolását a ZFS alrendszer végzi, a pool felismerődik, mount megtörténik és kész.

Tehát a crypttab-ban lévő 4 sorból csak az SSD-n lévő root partíció feloldása utáni /dev/mapper-ben létrejövő eszközre kell fstab-ban auto mount-olás (nyilván), a crypttab 3 db HDD-s bejegyzésére nem.

root@desktop:~# cat /etc/fstab
# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# systemd generates mount units based on this file, see systemd.mount(5).
# Please run 'systemctl daemon-reload' after making changes here.
#
# <file system> <mount point> <type> <options> <dump> <pass>
/dev/mapper/sdb1_crypt / ext4 discard,noatime,nodiratime,usrquota,grpquota,user_xattr,errors=remount-ro 0 1
# /boot was on /dev/sdh2 during installation
UUID=1870de57-00b1-406b-8606-f8eb96753f11 /boot ext4 discard,noatime,nodiratime 0 2
# /boot/efi was on /dev/sdh1 during installation
UUID=DF82-1624 /boot/efi vfat umask=0077 0 1

A discard-ot itt is alkalmaztam fstab-ban, hiszen SSD és ultra-paranoid nem vagyok, csak kicsit.

No, most viszont USB pendrive ki, vettem egy W10-et és illene lenne feltolni az SSD másik felén lévő rá várakozó partícióra. BattleField-ek sajnos nem szeretik a Linuxot :D

A cikk még nem ért véget, kérlek, lapozz!

Előzmények

  • OpenZFS a mindennapokra

    Az otthon tárolt adatmennyiség növekedése miatt szükségessé válhat saját NAS, melyhez kiváló a ZFS fájlrendszer.

Hirdetés

Copyright © 2000-2024 PROHARDVER Informatikai Kft.