Linux: LUKS e più dischi rigidi

Ho un sistema Debian Linux (amd64) installato su un dispositivo crittografato con sistema RAID-1 (LVM su LUKS) e avrò un RAID-6 di dischi = = 4 dove inserirò i miei dati (LUKS e forse LVM).

Penso che l'idea di base sia quella di sbloccare la partizione crittografata del sistema (all'avvio in locale o tramite ssh) e di archiviare un file di chiavi in / etc / crypttab per la partizione crittografata RAID-6. Ciò rappresenta un rischio per la sicurezza? Voglio dire ... è abbastanza inutile se qualcuno può semplicemente accedere al mio sistema localmente / da remoto e penso che ci siano molti servizi in esecuzione su server che sono vulnerabili al "rooting" (es. SSH). Esiste un'alternativa (oltre a sbloccare la partizione tramite SSH, che può essere un problema poiché, ad esempio, le operazioni di backup iniziano anche prima del montaggio della partizione dati).

Su un'altra macchina userò più dischi con LUKS + greyhole (no RAID-6) per i backup e sarà un vero problema sbloccare 10 dischi inserendo 10 volte la stessa password ...

— user51166
fonte

Se qualcuno può entrare nel tuo sistema e diventare root, non è necessario ottenere la chiave per la tua partizione crittografata. Non ha senso proteggerlo dal root (e non è possibile senza hardware speciale come un TPM o in esecuzione in una macchina virtuale).

— Gilles 'SO- smetti di essere malvagio' il

Mi scusi ? Anche se sono root devo fornire il file di chiavi / passphrase per sbloccare le partizioni LUKS. Suppongo che tu intenda che se qualcuno diventa root ha pieno accesso ai miei dati crittografati. Sfortunatamente questo è semplicemente vero perché una volta montata la partizione crittografata, non fa differenza se è crittografata o meno. Quale sarebbe il vantaggio di una macchina virtuale allora? Quindi perché la crittografia dovrebbe essere d'aiuto? È l'unica soluzione per negare l'accesso al root tramite SSH e servizi simili? Ma comunque se un hacker entra nel sistema come un normale utente in genere ha accesso in lettura a tutti i file, non è vero?

— user51166,

Esatto, se qualcuno è root sul tuo sistema, hanno accesso a tutto. Una VM può significare che hanno accesso a tutto nella VM. L'unico uso della crittografia è se qualcuno ruba il tuo hardware.

— Gilles 'SO- smetti di essere malvagio' il

Sì, beh ... in quel caso possiamo sostenere che l'unico modo quasi sicuro per archiviare i dati è in un computer crittografato disconnesso da tutta la rete e integrato nell'edificio. Quindi chiunque potrebbe venire con una tastiera e rubare i dati senza riavviare il sistema. Potrei anche isolare i miei sistemi da Internet poiché sarà un server di backup, quindi l'accesso LAN è tutto ciò di cui ha bisogno. Quindi di nuovo ... se una VPN viene utilizzata o una delle macchine LAN viene infettata, anche la macchina di backup viene esposta. Cosa faresti per risolvere questi problemi?

— user51166,

vedi anche unix.stackexchange.com/a/110102/50601

— Tim Abell

Risposte:

Puoi usare /lib/cryptsetup/scripts/decrypt_derivednel tuo crypttabper usare automaticamente la chiave di un disco per un altro.

Lo decrypt_derived script fa parte del pacchetto cryptsetup di Debian.

Piccolo esempio per aggiungere la chiave da sda6crypt a sda5:

/lib/cryptsetup/scripts/decrypt_derived sda6crypt > /path/to/mykeyfile
cryptsetup luksAddKey /dev/sda5 /path/to/mykeyfile
ls -la /dev/disk/by-uuid/ | grep sda5
echo "sda5crypt UUID=<uuid> sda6crypt luks,keyscript=/lib/cryptsetup/scripts/decrypt_derived" >> /etc/crypttab
shred -u /path/to/mykeyfile # remove the keyfile

Dato che oggigiorno è molto difficile eliminare davvero un file, assicurarsi che / path / to / mykeyfile si trovi su un'unità crittografata ( sda6cryptnel mio esempio sarebbe una buona soluzione).

In generale, è possibile aggiungere un ulteriore livello di sicurezza utilizzando la crittografia del file system dello spazio utente, ad esempio tramite encfs.

— Jofel
fonte

In questo modo non dovrei aver bisogno di archiviare il file di chiavi sul disco. Sarebbe carino. Tuttavia pensi che valga la pena (vale a dire che la memorizzazione del file di chiavi sul dispositivo root crittografato è "abbastanza sicura")? Sto chiedendo un'opinione poiché ho dei dubbi. Grazie per il suggerimento

— user51166,

La soluzione con decrypt_derivedha l'unico vantaggio, che non esiste un file chiave. Se qualcuno può ottenere l'accesso come root, normalmente ti perdi comunque. Leggere un file chiave potrebbe essere un po 'più semplice per un intruso che eseguire uno script. Per ottenere maggiore sicurezza, puoi rafforzare il tuo sistema usando ad esempio TOMOYO Linux, AppAmor, SMACK, SELinux, grsecurity, ... ma ciò richiede ulteriori sforzi. E la domanda se valga la pena è quindi più importante. Non dimenticare di disporre di un backup della chiave o di una chiave separata nel caso in cui l'unità si arresti in modo anomalo da dove la chiave è derivata / archiviata.

— Jofel,

Ho pianificato di utilizzare grsecurity o software simili (non all'inizio, ma quando avrò tempo lo metterei al sicuro). Sto pensando di utilizzare solo password e non file di chiavi, se possibile. Bene, la password verrà archiviata nella RAM, quindi immagino che anche tu possa discuterne.

— user51166

Non esiste un buon modo per eliminare un file chiave da nessuna parte, a parte la sovrascrittura dell'intero filesystem (e forse nemmeno in caso di guasto del disco). Un filesystem di journaling non peggiora notevolmente le cose.

— Gilles 'SO- smetti di essere malvagio' il

@Gilles Dato che non sono un esperto della cancellazione sicura dei file, ho modificato la mia risposta. Raccomando ora di archiviare il file di chiavi sull'unità crittografata.

— jofel,

Basato sulla risposta jofels, ecco lo stesso esempio ma senza dover memorizzare la chiave in un file. La chiave viene passata in una pipe denominata, che non memorizza nulla sul disco.

Puoi usare il /lib/cryptsetup/scripts/decrypt_derivedtuo crypttab per usare automaticamente la chiave di un disco per un altro. Lo decrypt_derivedscript fa parte del pacchetto cryptsetup di Debian.

Esempio modificato per aggiungere la chiave da sda6crypt a sda5:

mkfifo fifo
/lib/cryptsetup/scripts/decrypt_derived sda6crypt > fifo &
cryptsetup luksAddKey /dev/sda5 fifo
rm fifo

ls -la /dev/disk/by-uuid/ | grep sda5
echo "sda5crypt UUID=<uuid> sda6crypt luks,initramfs,keyscript=/lib/cryptsetup/scripts/decrypt_derived" >> /etc/crypttab

L' keyscriptopzione funziona solo se crypttabviene elaborata dagli strumenti di cryptsetup originali di Debian, la reimplementazione di systemd non la supporta attualmente. Se il tuo sistema utilizza systemd (che è la maggior parte dei sistemi), è necessaria l' initramfsopzione per forzare l'elaborazione in initrd da parte degli strumenti di crittografia, prima dell'avvio di systemd.

— JanKanis
fonte