Šifrovaný Proxmox VE 6: ZFS, LUKS, systemd_boot a Dropbear

4. 9. 2019 | Mark Stopka | Návody | 10787×

Tento článek, jenž byl přeložen z anglického originálu na blogu po svolení původního autora, popisuje, jak nastavit plně šifrovaného hostitele Proxmox VE 6 s rootem na ZFS a umožnit jeho odemčení skrze vzdálený přístup pomocí Dropbear SSH serveru. Navíc se jedná o metodu, jež zanechá systemd_boot netknutý, a proto zachová veškerou funkcionalitu nástrojů pve.

Obsah

1. Instalace Proxmox VE 6 na server
2. Základní konfigurace po instalaci
3. Zašifrování provedené instalace
1. Odstranění disku z ZFS poolu
2. Zašifrování disku LUKSem
3. Přidání disku zpět do ZFS poolu
4. Opakování, dokud nejsou zašifrovány všechny disky
4. Nastavení Dropbear SSH a systemd_boot pro zpřístupnění vzdáleného odemykání

Požadavky

Jediným zásadním požadavkem, kromě serveru, na který chcete nainstalovat Proxmox VE 6, je mít v tomto serveru alespoň 2 disky. To proto, abyste mohli vytvořit ZFS RAID 1. I pokud byste nechtěli mít root oddíl zrcadlený, stále budete potřebovat druhý disk alespoň dočasně, aby mohl být root oddíl zrcadlený. V opačném případě byste nejdříve museli nainstalovat šifrovaný Debian a až do něj nainstalovat Proxmox VE 6.

Mimo to předpokládám, že jste dostatečně obeznámeni s funkcionalitami plného šifrování disků na linuxových systémech, pokud nejste, měli byste se s touto problematikou nejprve seznámit předtím, než si začnete hrát se samotným hardware. Nezkoušejte tento postup na produkčních systémech, pokud nejste s problematikou plně seznámeni.

Instalace Proxmox VE 6

Jediná věc, na kterou si musíte při instalaci dát pozor, je, abyste instalaci provedli na ZFS RAID 1, zbytek postupu je shodný s jakoukoli jinou instalací Proxmox VE 6.

Základní konfigurace po instalaci

Z nějakého zvláštního důvodu se nastavení proměnné PATH v běžné příkazové řádce liší od nastavení PATH v javascriptové příkazové řádce přístupné z webového rozhraní, toto je vhodné napravit:

echo "export PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" >> ~/.bashrc

Odstraňte oznámení o chybějící komerční podpoře (zdroj):

sed -i.bak "s/data.status !== 'Active'/false/g" /usr/share/javascript/proxmox-widget-toolkit/proxmoxlib.js && systemctl restart pveproxy.service

Nastavte komunitní repozitáře:

rm /etc/apt/sources.list.d/pve-enterprise.list
echo 'deb http://download.proxmox.com/debian/pve buster pve-no-subscription' > pve-community.list

Aktualizujte server:

apt update
apt upgrade

Zašifrování provedené instalace

Tento postup je částečně založen na postupu z tohoto komentáře.

Ihned po instalaci by rozdělení disků mělo být obdobné tomuto výstupu z lsblk:

NAME            MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda               8:0    0 465.8G  0 disk
├─sda1            8:1    0  1007K  0 part
├─sda2            8:2    0   512M  0 part
└─sda3            8:3    0 465.3G  0 part
sdb               8:16   0 931.5G  0 disk
sdc               8:32   0 931.5G  0 disk
sdd               8:48   0 465.8G  0 disk
├─sdd1            8:49   0  1007K  0 part
├─sdd2            8:50   0   512M  0 part
└─sdd3            8:51   0 465.3G  0 part

Třetí oddíl na každém disku obsahuje naši instalaci, první a druhý oddíl obsahují oddíly boot a efi.

zpool status by měl vypadat přibližně takto:

NAME             STATE     READ WRITE CKSUM
rpool            ONLINE       0     0     0
  mirror-0       ONLINE       0     0     0
    ata-Samsung_SSD_850_EVO_500GB_XXXXXXXXXXXXXXX-part3  ONLINE       0     0     0
    ata-WDC_WDS500G2B0A-XXXXXX_XXXXXXXXXXXX-part3        ONLINE       0     0     0

V tomto bodě je nutné nainstalovat cryptsetup:

apt install cryptsetup

Odstraňte první oddíl z rpoolu, poté jej zašifrujte, namapujte přes LUKS do /dev/mapper/cryptrpool1 a přidejte zpět do rpoolu.

zpool detach rpool ata-Samsung_SSD_850_EVO_500GB_XXXXXXXXXXXXXXX-part3
cryptsetup luksFormat /dev/disk/by-id/ata-Samsung_SSD_850_EVO_500GB_XXXXXXXXXXXXXXX-part3
cryptsetup luksOpen /dev/disk/by-id/ata-Samsung_SSD_850_EVO_500GB_XXXXXXXXXXXXXXX-part3 cryptrpool1
zpool attach rpool ata-Samsung_SSD_850_EVO_500GB_XXXXXXXXXXXXXXX-part3 cryptrpool1

Dále vyčkejte, než dojde k synchronizaci zrcadla, což si můžete ověřit na řádku scan příkazu zpool status. Výstup by měl být podobný tomuto:

scan: resilvered 1022M in 0 days 00:00:04 with 0 errors on Wed Aug 21 17:27:55 2019

Nyní stejný postup zopakujte pro druhý disk, který je součástí zpoolu:

zpool detach rpool ata-WDC_WDS500G2B0A-XXXXXX_XXXXXXXXXXXX-part3
cryptsetup luksFormat /dev/disk/by-id/ata-WDC_WDS500G2B0A-XXXXXX_XXXXXXXXXXXX-part3
cryptsetup luksOpen /dev/disk/by-id/ata-WDC_WDS500G2B0A-XXXXXX_XXXXXXXXXXXX-part3 cryptrpool2
zpool attach rpool cryptrpool1 cryptrpool2

Po provedení těchto změn by výstup příkazu lsblk měl vypadat následovně:

NAME            MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda               8:0    0 465.8G  0 disk
├─sda1            8:1    0  1007K  0 part
├─sda2            8:2    0   512M  0 part
└─sda3            8:3    0 465.3G  0 part
  └─cryptrpool1 253:0    0 465.3G  0 crypt
sdb               8:16   0 931.5G  0 disk
sdc               8:32   0 931.5G  0 disk
sdd               8:48   0 465.8G  0 disk
├─sdd1            8:49   0  1007K  0 part
├─sdd2            8:50   0   512M  0 part
└─sdd3            8:51   0 465.3G  0 part
  └─cryptrpool2 253:1    0 465.3G  0 crypt

Po provedení úplné synchronizace by výstup příkazu zpool status měl vypadat takto:

NAME             STATE     READ WRITE CKSUM
rpool            ONLINE       0     0     0
  mirror-0       ONLINE       0     0     0
    cryptrpool1  ONLINE       0     0     0
    cryptrpool2  ONLINE       0     0     0

Dalším krokem je nastavení souboru /etc/crypttab, k tomu použijeme nástroj blkid, abychom zjistili PARTUUID pro oba oddíly:

blkid -s PARTUUID -o value /dev/disk/by-id/ata-Samsung_SSD_850_EVO_500GB_XXXXXXXXXXXXXXX-part3
blkid -s PARTUUID -o value /dev/disk/by-id/ata-WDC_WDS500G2B0A-XXXXXX_XXXXXXXXXXXX-part3

Poté je přidáme do souboru /etc/crypttab tak, aby vypadal následovně:

root@caliban:~# cat /etc/crypttab
# <target name> <source device>                                <key file>      <options>
  cryptrpool1   PARTUUID=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX  none            luks,discard,initramfs
  cryptrpool2   PARTUUID=YYYYYYYY-YYYY-YYYY-YYYY-YYYYYYYYYYYY  none            luks,discard,initramfs

Dalším krokem je úprava initramfs a jeho umístění na bootovací oddíl (zde se odlišujeme od odkazovaného postupu na fóru výše):

update-initramfs -u -k all
pve-efiboot-tool refresh

Pokud se vám to přihodí, v tomto bodě může cryptsetup skončit s chybovým hlášením při provádění update-initramfs, avšak řešení následně funguje:

cryptsetup: ERROR: Couldn't resolve device rpool/ROOT/pve-1
cryptsetup: WARNING: Couldn't determine root device

Nyní je čas server restartovat a při bootování odemknout pevné disky heslem tak, aby se správně sestavil ZFS oddíl.

Nastavení Dropbear SSH serveru pro umožnění vzdáleného odemčení

Nyní začíná ta složitější, avšak o to zábavnější část celého návodu! Vzhledem k tomu, že nepoužíváme grub, musíme udělat nějaké změny oproti běžnému postupu v těchto situacích.

Pár zajímavých odkazů, které se vyplatí prostudovat:

• Tento článek hezky popisuje, jak použít klíče, které Dropbear vygeneruje při instalaci, namísto jejich nahrazování.
• Stránka Freedesktop pojednávající o systemd-boot.
• Tento článek o nastavení Arch Linuxu s Dropbear SSH serverem není úplně aplikovatelný pro naši situaci, avšak poskytuje dostatek informací, abychom nastavili systemd-boot tak, aby spustil kernel s parametry, které budeme potřebovat.

Nejdříve nainstalujeme Dropbear a busybox:

apt install dropbear busybox

Poté přidáme busybox do /etc/initramfs-tools/initramfs.conf:

root@caliban:~# cat /etc/initramfs-tools/initramfs.conf | grep ^BUSYBOX
BUSYBOX=y

Zkonvertujeme Dropbear SSH klíče:

cd /etc/dropbear-initramfs/
/usr/lib/dropbear/dropbearconvert dropbear openssh dropbear_rsa_host_key id_rsa
dropbearkey -y -f dropbear_rsa_host_key | grep "^ssh-rsa " > id_rsa.pub

Dalším krokem je přidání vlastního veřejného SSH klíče mezu autorizované klíče:

vi /etc/dropbear-initramfs/authorized_keys

Poté se ujistíme, že dropbear bude spuštěn tím, že ověříme, že hodnota klíče NO_START je rovna 0 v souboru /etc/default/dropbear.

root@caliban:~# cat /etc/default/dropbear | grep ^NO_START
NO_START=0

Nakonec nastavíme Dropbear SSH server na nestandardní port (odlišný od 22), abychom se vyvarovali varování o man-in-the-middle při připojování k serveru, když je v režimu bootování, případně již nabootován k produkčnímu užití změnou hodnoty DROPBEAR_OPTIONS v souboru /etc/dropbear-initramfs/config:

root@caliban:~# cat /etc/dropbear-initramfs/config | grep ^DROPBEAR_OPTIONS
DROPBEAR_OPTIONS="-p 12345"

Ve svém lokálním souboru ~/.ssh/config můžete přidat dvě nastavení pro snažší vzdálenou správu:

$ cat ~/.ssh/config
Host unlock_caliban
  Hostname 1.2.3.4
  User root
  Port 2222

Host caliban
  Hostname 1.2.3.4
  Port 22

V tuto chvíli jsem si všiml, že po restartu je připojen pouze třetí oddíl, který je součástí rpoolu. Po ručním připojení oddílu /boot jsem si všiml, že obsahuje konfigurační soubory systemd-boot, avšak vypadaly, že jsou automaticky generovány Proxmoxem po spuštění příkazu pve-efiboot-tool refresh. Podíval jsem se tedy na soubor /usr/sbin/pve-efiboot-tool a prohlížel zdrojový kód, dokud jsem nenarazil na část, jež odkazuje na /etc/kernel/postinst.d/zz-pve-efiboot, která obsahuje kód, který generuje konfigurační soubory pro systemd-boot:

# [...]
for kver in ${BOOT_KVERS}; do

    linux_image="/boot/vmlinuz-${kver}"
    initrd="/boot/initrd.img-${kver}"

    if [ ! -f "${linux_image}" ]; then
        warn "No linux-image ${linux_image} found - skipping"
        continue
    fi
    if [ ! -f "${initrd}" ]; then
        warn "No initrd-image ${initrd} found - skipping"
        continue
    fi

    warn "  Copying kernel and creating boot-entry for ${kver}"
    KERNEL_ESP_DIR="${PMX_ESP_DIR}/${kver}"
    KERNEL_LIVE_DIR="${esp}/${KERNEL_ESP_DIR}"
    mkdir -p "${KERNEL_LIVE_DIR}"
    cp -u --preserve=timestamps "${linux_image}" "${KERNEL_LIVE_DIR}/"
    cp -u --preserve=timestamps "${initrd}" "${KERNEL_LIVE_DIR}/"

    # create loader entry
    cat > "${esp}/loader/entries/proxmox-${kver}.conf" <<- EOF
            title    ${LOADER_TITLE}
            version  ${kver}
            options  ${CMDLINE}
            linux    /${KERNEL_ESP_DIR}/vmlinuz-${kver}
            initrd   /${KERNEL_ESP_DIR}/initrd.img-${kver}
    EOF
done
# [...]

Pro naše účely je podstatná část, která obsahuje příkaz cat: proměnná CMDLINE, která je obsažena na řádku začínajícím options a obsahuje bootovací parametry pro linuxové jádro. Tato proměnná je nastavena ve stejném souboru:

# [...]
if [ -f /etc/kernel/cmdline ]; then
  CMDLINE="$(cat /etc/kernel/cmdline)"
else
  warn "No /etc/kernel/cmdline found - falling back to /proc/cmdline"
  CMDLINE="$(cat /proc/cmdline)"
fi
# [...]

Soubor /etc/kernel/cmdline je místem, kde Proxmox ukládá své bootovací parametry na jediném řádku:

root=ZFS=rpool/ROOT/pve-1 boot=zfs

Po objevení souboru /etc/kernel/cmdline jsem procházel dokumentaci Proxmox a zjistil, že se jedná o to správné místo, kde by měly být upraveny bootovací parametry v tomto případě.

Nyní, když víme, kde provádět změny, jsou dvě změny, které chceme přidat:

1. chceme se ujistit, že síťová rozhraní se nahodí, abychom se mohli připojit přes SSH do systému, který vytváří initramfs, k tomu použijeme příkaz ip v následujícím formátu (více v této dokumentaci):

       ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf>:<dns0-ip>:<dns1-ip>:<ntp0-ip>:
       

   Vynechal jsem vše, co následovalo po autoconf, následující konfigurace mi funguje v pořádku:

       ip=1.2.3.4::1.2.3.1:255.255.255.0:caliban:enpXsY:none:
       

2. také musíme říci jádru, které zařízení jsou ta, která chceme odemknout, k tomu použijeme proměnnou cryptodevice (ve které použijeme UUID patřičných diskových oddílů):

       cryptdevice=UUID=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX cryptdevice=UUID=YYYYYYYY-YYYY-YYYY-YYYY-YYYYYYYYYYYY
       

Celý obsah souboru /etc/kernel/cmdline pak tedy vypadá následovně:

ip=1.2.3.4::1.2.3.1:255.255.255.0:caliban:enpXsY:none: cryptdevice=UUID=XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX cryptdevice=UUID=YYYYYYYY-YYYY-YYYY-YYYY-YYYYYYYYYYYY root=ZFS=rpool/ROOT/pve-1 boot=zfs

Naším posledním krokem pak bude:

update-initramfs -u -k all
pve-efiboot-tool refresh

Nyní byste se po restartu měli být schopni připojit na SSH port, který jste nastavili pro dropbear. Odtamtud již můžete odemknout pevné disky příkazem:

echo -n "password" > /lib/cryptsetup/passfifo

Tento příkaz musíte zopakovat dvakrát, protože v rpoolu máte dvě bloková zařízení. Případně můžete použít příkaz:

/lib/cryptsetup/askpass "password: " > /lib/cryptsetup/passfifo

Nebo můžete použít skript cryptroot-unlock, který se vás na heslo bude také ptát dvakrát.

Pokud se s dvojitým zadáváním hesla nechcete obtěžovat, můžete také umístit následující skript do /etc/initramfs-tools/hooks a přiřadit mu atribut "executable". V podstatě jsem spojil příkazy uvedené výše se skriptem, který se mi někde povaloval, zdá se, že se jednalo o skript z tohoto GISTu. Jednou se vás zeptá na heslo a pak použije echo, aby jej zapsal do /lib/cryptsetup/passfifo dvakrát (protože používáme dvě bloková zařízení) s jednosekundovým odstupem mezi oběma zápisy, a poté ukončí sezení, aby bootování mohlo pokračovat. Pravděpodobně není příliš bezpečné jej používat, ale mi funguje v pořádku:

#!/bin/sh

PREREQ="dropbear"

prereqs() {
    echo "$PREREQ"
}

case "$1" in
    prereqs)
        prereqs
        exit 0
        ;;
esac

. "${CONFDIR}/initramfs.conf"
. /usr/share/initramfs-tools/hook-functions

if [ "${DROPBEAR}" != "n" ] && [ -r "/etc/crypttab" ] ; then

    cat > "${DESTDIR}/bin/unlock" << EOF
#!/bin/sh
unlock_devices() {
  pw="\$(/lib/cryptsetup/askpass "password: ")"
  echo -n \$pw > /lib/cryptsetup/passfifo
  sleep 1
  echo -n \$pw > /lib/cryptsetup/passfifo
}
if unlock_devices; then
# kill \`ps | grep cryptroot | grep -v "grep" | awk '{print \$1}'\`
# following line kill the remote shell right after the passphrase has
# been entered.
kill -9 \`ps | grep "\-sh" | grep -v "grep" | awk '{print \$1}'\`
exit 0
fi
exit 1
EOF

    chmod 755 "${DESTDIR}/bin/unlock"

    mkdir -p "${DESTDIR}/lib/unlock"
    cat > "${DESTDIR}/lib/unlock/plymouth" << EOF
#!/bin/sh
[ "\$1" == "--ping" ] && exit 1
/bin/plymouth "\$@"
EOF

    chmod 755 "${DESTDIR}/lib/unlock/plymouth"

    echo To unlock root-partition run "unlock" >> ${DESTDIR}/etc/motd
fi

A toto je konec návodu, po jeho aplikaci si můžete užívat nový, šifrovaný Proxmox s možností vzdáleného odemykání šifrovaných disků.

       

Komentáře

[Harvie.CZ]

Asi bych doplnil, ze v Proxmoxu 6 je ZFS 0.8.x, ktery uz ma sifrovani primo v sobe. LUKS teda teoreticky neni potreba. Vyhoda je, ze pokud mate vic spravcu virtualnich serveru / kontejneru, tak jde velmi snadno kazdemu virtualu nastavit extra sifrovaci klic/passphrase.

Popravde doufam, ze na to treba udelaji nejaky UI primo v proxmoxu, aby si to zakaznici mohli zadavat pri spousteni virtualu pres web. Potom jako provozovatel serveru ani nebudu muset klice od jejich virtualu znat. (aspon teda pokud nebudu chtit... ale zkusenost rika, ze nechci )

[Petr]

Super návod a teď jak zálohovat Proxmox pomocí snapshotů ZFS

[Harvie.CZ]

Ja pouzivam znapzend. Ze vseho co jsem zkousel to vypada jako nejmensi zlo. Ma to jeste naky kosmeticky vady, ale vyvoj je porad aktivni. Vyviji to stejnej clovek co napsal treba rrdtool. Ale ted se mi to nak podelalo pri upragdu na novej Debian (instaloval jsem to rucne). Budu to muset nak vyupgradovat

https://github.com/oetiker/znapzend https://www.znapzend.org/

[Jendа]

Asi už s tím budu otravný, ale ještě mi to nikdo nevysvětlil:

ZnapZend uses the ZFS send/receive functionality to transfer backups to remote locations.

Na jaké úrovni tohle funguje (ještě víc by mě to teda zajímalo u btrfs)? Přenáší to soubory (nepravděpodobné), nebo nějaké low-level binární diffy? Pokud to přenáší binární diffy struktur souborového systému, tak to podle mě popírá jeden z hlavních důvodů zálohování: pokud se FS rozbije (i úmyslně, třeba to napadl ransomware), tak si tohle rozbití přeneseš tím sendem i na zálohovací pole a máš problém.

Chápu, že jednotlivé subvolumes/snapshoty snad budou nějak trochu izolované, ale podle mě kód FS nebude navržený aby byl proti tomuto odolný.

[Harvie.CZ]

Puvodni dotaz byl jak zalohovat ZFS pomoci snapshotu, tak si ted nemuzes stezovat, ze jako reseni uvadim software na zalohovani pomoci ZFS snapshotu

Ano. Jsou to low level binarni diffy. Na zdrojovym serveru se nesmi smazat posledni snapshot prenesenej na cilovej server, aby si mel ten diff proti cemu vygenerovat.

Na jaky urovni FS (umyslne) rozbijes/zaransomwarujes? Pokud na urovni souboru (=FS je stale konzistentni), tak mas stale k dispozici ty stary snapshoty. Je na tobe, aby sis vsimnul problemu driv nez ti vyprsi posledni snapshot/zaloha. Pokud ti soubory zasifruje ransomware, tak si nedovedu predstavit zadnej zalohovaci system, kterej te zachrani, pokud ho nechas nekonecne dlouho bezet a nevsimnes si toho (za predpokladu, ze se zalohy prepisujou po case, protoze uloziste ma konecnou velikost).

Pokud na urovni binarniho formatu FS, tak se to neprenese, protoze ZFS kontroluje checksumy. Navic je teda pravdepodobnejsi vyhackovanej kontejner, nez hostitel. (aspon teda to je zakladni myslenka celyho proxmoxu, ktery slepe verime a z kontejneru se na blockdev se ZFS nedostanes, jen na soubory.

subvolumes/snapshoty jsou izolovany naprosto pokud vim. (jako ze zevnitr kontejneru neprepises existujici snapshot ani subvolume jinyho kontejneru). A ani by nemelo bejt mozny upravit subvol A tak, aby se pri jeho replikaci do subvolu B samovolne prepsal subvol C.

Nerikam, ze nemuzes paralelne ke snapshotum jeste zalohovat... Ale mel jsem loni problem, ze shorel server a obnova klasicky zalohy trvala 2dny (=2dny vypadek). Pokud mas nekde disk s replikovanym ZFS, tak se tohle proste nestane. Disk vemes, das ho do toho spadlyho serveru a jedes behem pul hodiny. V idealnim pripade mas na ty destinaci kam to replikujes rovnou nainstalovanej proxmox a jen ty virtualy vzdalene nahodis.

[Jendа]

Na jaky urovni FS (umyslne) rozbijes/zaransomwarujes?

Na úrovni struktur FS. Neříkej, že jsi nikdy neviděl rozbitý FS, který třeba ani nešel přimountovat - typicky vlivem HW selhání (vadná RAM) nebo SW bugu.

Pokud na urovni binarniho formatu FS, tak se to neprenese, protoze ZFS kontroluje checksumy.

Přepíšu checksumy aby seděly…

A ani by nemelo bejt mozny upravit subvol A tak, aby se pri jeho replikaci do subvolu B samovolne prepsal subvol C.

Ano, o tohle mi přesně šlo. A upřímně bych tomu zas tak moc nevěřil.

[Harvie.CZ]

Tak pouziva se nakej binarni strom. Asi nebude tezky zkontrolovat do jaky vetve zapisujes...

[Jendа]

A teď úplně lamerský dotaz (neboť jsem tohle nikdy nedělal): dá se specifikovat a specifikuješ do jaké větve zapisuješ? Například z 1 a 2 (první dva odkazy z Googlu na dotaz zfs send receive) mi úplně nepřišlo že by recv řekli „posílám ti nový snapshot, na nic jiného nesahej“.

[Harvie.CZ]

U recv se da specifikovat volume. Takze jeden virtual ti neprepise druhej. Nevim jestli jde specifikovat konkretni snapshot. Myslim ze trik bude jeste jinde:

ZFS je Copy on write filesystem. Tudiz pri recv snapshotu by se nemelo nic prepisovat, jen appendovat novy data. To myslim dostatecne zajisti, ze custom upravou novyho snapshotu nemuzes prepsat starej.

[Josef Kufner]

rozbitý FS, který třeba ani nešel přimountovat

Pro takové radosti máme zálohy a obnovíme to z nich.

[trekker.dk]

Jste ve vlákně, kde se řeší případ, kdy se zálohuje pomocí send/receive a chyba se přenese do zálohy

[Käyttäjä 11133]

Toto je spravne

low-level binární diffy

.

[j]

Jedinej kdo ma problem ses ty, protoze mas v hlave nasrano ...

KAZDEJ zalohovaci system kupodivu zalohuje PRESNE to, co je aktualne na disku, a naprosto vubec ho nezajima, jestli je to dobre nebo ne, protoze to nema naprosto jak zjistit.

Teprve AZ nejaka aplikace padne nebo nejak zjisti ze se ji zmenila data, obnovi administrator (ty rozhodne ne) data ze zalohy, a to tak stara, jak je treba k tomu aby chybu napravil.

O jak moc dat pak pripadne prijde nezalezi vubec na systemu zalohovani, ale prave a vyhradne na aplikaci. Pokud databazi mesice nevadi, ze ma rozjebany soubory, tak prijde o mesice dat.

ZADNEJ filesystem NEUMI a NIDKY nebude umet zajistit konzistenci dat. FS zajistuje konzistenci FS. Jak prekvapive co?

[Peter Golis]

FS vie zabezpečiť konzistenciu údajov počas zálohy. Vo svete MS existuje technológia VSS ktorá to dokáže zaručiť pri _kompatibilných_ aplikáciách.

Zaujímalo by ma či niečo také existuje aj vo svete Linuxu. Žurnál vo FS je málo, a treba k tomu komunikačné API.

[Harvie.CZ]

Tak ZFS ma kontrolni soucty VSECH dat. Narozdil od ostatnich FS nebo mdraidu, kde jsou overitelny jen metadata.

[Peter Golis]

Kontrolný súčet zapísaných dát ti ale nezaručí že napríklad databáza vykonala konzistentný transakčný zápis pre potreby zálohy.

[kvr]

V podstatě by k tomu z hlediska aplikace měly stačit transakce. Ty Windows pokud vím umí (předpokládám, že se následně zapíšou do journal změny a poté označí jako commit celek), wiki ale říká, že "its use is now discouraged". U Linuxu kdysi byla snaha, ale matně si vzpomínám, že byla dost svázaná s implementací BTRFS (takže osud asi dost nejistý). A API snad vyžadovalo všechny operace v jednom system call, aby se předešlo deadlocks (a potenciálně DoS) mezi procesy.

IMHO to nikoho moc nezajímá, neboť využití je mizivé - jednoduchý update konfigurace se dá udělat přejmenováním. Zajímavější by to bylo pro instalace, ale ta se stejně nedělá paralelně, takže se ověří, že všechno projde a zbytek je jeden velký rename (a oba snapshot + instalace jsou obvykle pod kontrolou administrátora). Na všechnu ostatní správu dat se používá stejně databáze, která konzistenci zajišťuje na vyšší úrovni.

[Peter Golis]

Ak na disk(y) zapisuje aplikácia ktorá kvôli zvýšeniu výkonu používa asynchrónne diskové operácie, tak ti je ten žurnál len na ozdobu keďže ten snapshot nebude obsahovať dáta ktoré by mali byť konzistentné z pohľadu aplikácie.

[kvr]

Tak to si samozřejmě musí pohlídat samotná aplikace, aby data zapisovala ve správném pořadí. V případě asynchronous IO například zapsat celý payload a poté, co dostane potvrzení ukončení AIO, tak teprve zapsat značku commitu (příklad transakční DB, ale platí obecně). Mezitím samozřejmě může probíhat jiné AIO na nezávislých datech.

Obecně to ale není problém transakcí, ale aplikace. Většinu problémů mezi filesystem a procesy lze vyřešit zárukou pořadí operací, což je nejspíš hlavní důvod, proč zájem o transakční filesystemy upadl.

[Peter Golis]

Akurát že robiť stále flush cache je plytvanie výkonu diskov. Schválne, skúste si v práci napríklad zapnúť backup mode v databáze počas vykonávania uzávierky, a odmerajte si koľko krát to bude pomalšie.

[/dev/win]

to by ma sef zabil ... a veduce 78 pobociek tiez... a to bezime na ZFS over NVME @ FreeBSD...

[Peter Golis]

Tak potom prajem veľa zdaru pri recovery z takého snapshotu. Vyjsť to môže, al garantované to nebude.

[Jendа]

KAZDEJ zalohovaci system kupodivu zalohuje PRESNE to, co je aktualne na disku, a naprosto vubec ho nezajima, jestli je to dobre nebo ne, protoze to nema naprosto jak zjistit.

A proto zálohuji s historií, aby když zjistím, že před týdnem se na disku udělalo něco špatně, tak bych mohl obnovit zálohu starou 8 dní.

O jak moc dat pak pripadne prijde nezalezi vubec na systemu zalohovani, ale prave a vyhradne na aplikaci.

Hovoříme o situaci, kdy je systém zálohování možná postavený tak, že tu historii nedokáže uchovat.

ZADNEJ filesystem NEUMI a NIDKY nebude umet zajistit konzistenci dat.

O tomto vůbec nehovoříme.

[MP]

Slusne receno, ve srovnani s Windows je sifrovani v Linuxu slusny pruser.

Umi luks2 presifrovat disk za behu? Umi luks2 jednoduchym zpusobem pouzit TPM? Podpora pri startu systemu? atd...

Bitlocker nastavim ja nevim, v 5 krocich s podporou TPM a je vyreseny i boot/update, zaloha klicu na ruzna mista...

Jako linux admin jsem dost rozladeny (komplikuje mi to praci).

[Peter Golis]

A akú má človek záruku že ten bitlocker neodomkne univerzálny šperhák od výrobcu toho closed source riešenia? Bez toho sa jedná len o placebo ktoré je v prípade bezpečnosti dosť závažným rizikom.

[Harvie.CZ]

Podle me je zas slusny pruser verit TPM. Uz jsem videl hodne "slusnych pruseru" ze strany vyrobcu HW, tak nevim proc bych jim mel sverovat zrovna sifrovaci klice.

Na co je potreba presifrovat disk za behu? Nevim jak to ma LUKS, ale vetsinou mas primarni klic zasifrovanej sekundarnim klicem, takze presifrujes jen ten, kdyz chces treba zmenit passphrase.

[MP]

Od toho jsou recovery keys, kdyby neco. Navic, oproti luks2 to chrani alespon proti vybrani disku ze stroje, aniz by to narusilo schopnost stroje nabootovat.

[Jendа]

Slusne receno, ve srovnani s Windows je sifrovani v Linuxu slusny pruser.

Mně naopak přijde jako průser ta neprůhlednost šifrování (stejně jako asi tak všeho dalšího) na Windows.

Umi luks2 presifrovat disk za behu?

Ne, jenom offline inplace (cryptsetup-reencrypt). Jaký je usecase? Já jsem reencrypt použil při duplikování VM aby měly jiný klíč (což je na tom duplikátu offline operace) a jednou snad pro změnu módu šifry za silnější.

Umi luks2 jednoduchym zpusobem pouzit TPM?

Ne, to by bylo proti unixové filozofii. LUKS má API jak mu předat klíč, a je na jiné utilitě, aby mu klíč předala (a je jedno jestli si ho sežene z TPM, po SSH nebo odkud).

Podpora pri startu systemu?

Opět, toto není věcí LUKSu, ale startovacích skriptů. Všechny distribuce které jsem používal (Debian, Arch, Ubuntu) mají podporu pro šifrovaný / už cca. 10 let, z toho 5 let doslova na jedno kliknutí/jeden příkaz (podle toho jestli používáte grafický nebo textový instalátor :) při instalaci.

Bitlocker nastavim ja nevim, v 5 krocich s podporou TPM a je vyreseny i boot/update, zaloha klicu na ruzna mista...

A necrackne to každý Franta se šroubovákem?

[MP]

Jenze ve Win to funguje, v Linuxu se s tim musi kazdy nadrit.

Use case pro presifrovani za behu: potrebuji nesifrovany disky zasifrovat. Tedy ne reencrypt, ale encrypt neceho, kde se s sifrovanim drive ani neuvazovalo - napr. zalohovaci masiny se storage v desitkach TB.

K cemu unix filozofie, kdyz Linux neni Unix? Ja potrebuji nastroj, ktery nastavim a funguje to out of box, ne to bastlit z X modulu (to at je volitelna konfigurace toho nastroje). Navic, zkuste zautomatizovat ten postup !

Umi ta podpora pri startu pocitat s tim, ze se aktualizuji kernely/initramfs apod? Pokud ano, tak muzu jeden bod skrtnout. A propos, vyzaduje to UEFI?

[Jendа]

Jenze ve Win to funguje, v Linuxu se s tim musi kazdy nadrit.

Mně to v Linuxu funguje i bez nadření.

Use case pro presifrovani za behu: potrebuji nesifrovany disky zasifrovat. Tedy ne reencrypt, ale encrypt neceho, kde se s sifrovanim drive ani neuvazovalo - napr. zalohovaci masiny se storage v desitkach TB.

OK, good point. Tohle bohužel pro Linux neexistuje.

Ja potrebuji nastroj, ktery nastavim a funguje to out of box, ne to bastlit z X modulu

Protože když to bude jedna věc co „umí všechno“, tak za chvíli narazíš na něco, co ve skutečnosti neumí.

Navic, zkuste zautomatizovat ten postup !

Co? Představuju si to tak, že si ten skript k odemčení přes TPM přidáš do /etc/initramfs-tools/hooks/něco a to pak máš na všech strojích stejné.

Umi ta podpora pri startu pocitat s tim, ze se aktualizuji kernely/initramfs apod?

Eh, ano? Jak si představuješ že to funguje?

A propos, vyzaduje to UEFI?

Proč by proboha mělo? Kernel a initramfs se libovolným způsobem naloaduje a pak už se služby firmware nijak nevyužívají.

[Josef Kufner]

Use case pro presifrovani za behu: potrebuji nesifrovany disky zasifrovat. Tedy ne reencrypt, ale encrypt neceho, kde se s sifrovanim drive ani neuvazovalo - napr. zalohovaci masiny se storage v desitkach TB.

man cryptsetup-reencrypt praví:

To encrypt data on (not yet encrypted) device, use --new with combination with --reduce-device-size or with --header option for detached header.

Tedy není to za běhu, ale aspoň to je in-place. Pokud bych to chtěl za běhu a nemuselo to být in-place, tak by se dalo uvažovat o triku s RAID 1, kdy bych přidal šifrované zařízení a odebral nešifrované. Výpadek by byl jen na remount do RAIDu, ale během přešifrovávání by to bylo dostupné.

[MP]

Coz je milionkrat rizikovejsi zpusob, pokud napr. dojde k restartu serveru, tak jsou vsechna data v pr...

[Josef Kufner]

A nebyla by to jinak nuda?

[Jendа]

Naopak, ne? Když to šifruješ do RAIDu a resetuje se server, tak v nejhorším stačí tu neúplnou kopii zahodit a začít znova. Zatímco pokud šifruješ blokové zařízení inplace, tak po resetu nevíš kde přesně jsi skončil. Leda že bys měl externí datový žurnál, což znamená 2x víc zápisů než by bylo potřeba. (jiná věc je šifrování na úrovni souborů žurnálovacího FS)

[Josef Kufner]

Co? Představuju si to tak, že si ten skript k odemčení přes TPM přidáš do /etc/initramfs-tools/hooks/něco a to pak máš na všech strojích stejné.

Stačí do /etc/crypttab nebo do parametru jádra přidat volbu keyscript=něco, kde něco je cesta ke skriptu, který získá klíč a vypíše ho na stdout. Pak ještě je potřeba přidat ten skript do initramfs, pokud ho tam nějaký balíček ještě nedal.

Tedy těch X modulů je dva (cryptsetup, TPM) a propojíš je jednou vobou a jedním triviálním skriptem.

[Max]

Bitlocker má jednu velkou výhodu s TPM a jednu nevýhodu. Výhodou je možnost odemykat volume přes síť. Když tedy není uživatel přítomen, je možné otočit PC a pokračovat v údržbě aniž by člověk měl fyzický přístup k PC. Pro správu tedy ideální. Jak moc bezpečnostních slabin to má, to je otázkou. Nicméně primárně se většinou řeší šifrování kvůli reklamacím vadných disků, případně kvůli krádeži ntb. Automatické odemykání v rámci firemní sítě tedy nemusí být v těchto případech tak extra zabezpečené.

Nevýhou je, že člověk nemůže mít zapnutý fast start, nemůže si připojovat a odpojovat některé věci k ntb, jak se mu zachce, protože win zjistí změnu hw a místo PINu pak vyžadují recovery key (docela dlouhé číslo, které je dobré si zálohovat do AD).
Zdar Max

[Ruža Becelin]

Neni problem, fast start stoji za velky smradlavy stejne, takze to automaticky vypiname.

[Jendа]

Bitlocker má jednu velkou výhodu s TPM a jednu nevýhodu. Výhodou je možnost odemykat volume přes síť. Když tedy není uživatel přítomen, je možné otočit PC a pokračovat v údržbě aniž by člověk měl fyzický přístup k PC.

To snad nesouvisí s TPM, přímo v článku je návod jak tohle udělat pomocí dropbearu v initramdisku.

[j]

Ony umej widle sifrovat? A od kdy? JO a ha, widle jakoze sifrujou ... ale jen data, sytem sifrovat vubec neumej ... takze si tam kdokoli muze nahrat cokoli a pak staci uz jen pockat, az se user prihlasi ze? A nebo jeste lip, nastartovat ophcrack a za 10s ma hesla 80% useru ze?

[Käyttäjä 11133]

Ehm...

[3bit]

Proxmox velmi nepoznam, ale spytam sa tych co s nim pracuju, da sa nadefinovat samostatne SSD na read cache aj samostatne SSD na write cache? Dakujem.

[Harvie.CZ]

Proxmox neni storage. Muzes pouzivat libovolnou storage co jede na Linuxu. ZFS treba tohle umi. Nevim jak bcache.

[j]

Tohle na tuxovi udelas s libovolnym FS, jen sem si skoro 100% jistej, ze to je neco, co rozhodne delat nechces. Protoze typicky presne to, co si prave zapsal chces precist.

[cbrpnk]

Ale veď keď je HW na UPS tak je to jedno, nie ? Akurát že to bude rýchlejšie... A keď SSD budú trebárs 2TB na zápis a 2TB na čítanie tak zrýchlenie musí byť enormné...

[Peter Golis]

Samozrejme. Najmä ak aplikácia chce prečítať to, čo zapísala. Skús opísať kadiaľ by to teda cestovalo, a koľko krát.

[Aleš Kapica]

V tom blogu má chybu, kterou jsi převzal. Sice ne zásadní, ale někoho by mohla mást. Jako příklad portu na kterém ná dropbear naslouchat píše 12345, ale v následujícím ukázkovém konfigu je vidět, že použil 2222.

Další věc – zrovna dnes jsem dropbear instaloval (Debian unstable) – měnit číslo portu není nutné, pokud se nepovolí jeho spouštění i v nastartovaném systému (tak jak je to uvedeno zde). Dropbear se spustil automaticky, když nastal v ramdisku problém. Bylo jenom potřeba naimportovat klíče (tak jak je popsáno zde).

Taky není nutné nastavovat IP adresu pokud si ji stroj bere z DHCP.

[Käyttäjä 11133]

V tom blogu má chybu, kterou jsi převzal. Sice ne zásadní, ale někoho by mohla mást. Jako příklad portu na kterém ná dropbear naslouchat píše 12345, ale v následujícím ukázkovém konfigu je vidět, že použil 2222.

Diky, par chyb jsme zachytili jiz pri prekladu, o tomto autora take informuji...

Další věc – zrovna dnes jsem dropbear instaloval (Debian unstable) – měnit číslo portu není nutné, pokud se nepovolí jeho spouštění i v nastartovaném systému (tak jak je to uvedeno zde). Dropbear se spustil automaticky, když nastal v ramdisku problém. Bylo jenom potřeba naimportovat klíče (tak jak je popsáno zde).

To dava smysl, ale tohle si radeji otestuji sam a muj testovaci server je tedka v zapujcce.

Taky není nutné nastavovat IP adresu pokud si ji stroj bere z DHCP.

To je ponekud logicke...

[Aleš Kapica]

K tomu dhcp. Logické to je, ale pokud někdo půjde podle postupu, tak mu to jasné být nemusí. Řešil jsem teď diskless přes Wi-Fi, a u původního postupu pro nahození Wi-Fi v ramdisku, co jsem našel na netu, se jméno Wi-Fi rozhraní předávalo přes ip=

[Käyttäjä 11133]

A neměl bych ještě čtenářům připomenout, že postup nebude fungovat pokud nebudou mít připojené médium na první vrstvě ISO/OSI modelu? V článku je v dané sekci odkaz na dokumentaci, takže své konkrétní use-casy si člověk může dovodit z ní.

[Aleš Kapica]

To platí jen pokud používají defaultní nfs skript Upřímně řečeno, je dost primitivní, ale na jednoduché věci to stačí.

[Aleš Kapica]

Já se bavím tímhle.

[Käyttäjä 11133]

Opověď originálního autora...

Cool!

Thanks for bringing this to my attention, this could really be confusing for readers! I was changing all the specific information on my setup to dummy values and this one slipped through my fingers, guess not everyone knows I'm really using port 2222^^ I will change the line it in the post!

Changing the port however is important, because I'm not importing the Openssh key from the openssh server that is already installed. I'm instead converting the key that Dropbear generates automatically when it is installed. The openssh server that is running once the system has booted up is using different keys. When I run Dropbear on port 22 I still get the MITM warning.