Criptare partizioni e directory

In questo articolo tratterò il primo caso, ovvero il disco funziona perfettamente e si vuole semplicemente pararsi la schiena nel caso in cui il Server o il disco venga rubato.

La soluzione, come si può immaginare, consiste semplicemente nel criptare i dati presenti su disco.
Per fare questo ci sono due sistemi: criptare le partizioni o criptare semplicemente i dati.

Per criptare i dati si possono usare programmi come GPG/PGP, oppure crearsi una directory criptata con EncFS.
Questo sistema è utile nel caso in cui alla macchina ci siano accessi anche da altre persone e si vogliano proteggere pochi dati personali (per esempio, le chiavi SSH e GPG, oppure i files nei quali i Browser salvano le varie passwords o in cui si salvano i dati di connessione del MailAgent o di ICQ).
EncFS ha anche l'innegabile vantaggio di impedire perfino a root di accedere alla directory con i dati criptati (anche se, ovviamente, nessuno impedisce a root di usare su e diventare immediatamente l'utente che ha accesso alla directory...)!

Nel caso invece in cui si abbiano parecchi dati da criptare, e questi debbano poter essere accessibili ad altri utenti, EncFS non è una buona soluzione. In questi casi è molto meglio criptare direttamente le partizioni e quindi (dopo averle sbloccate) montarle e accederci normalmente, come qualsiasi altra partizione.
Per questi casi conviene usare lo standard LUKS (Linux Unified Key Setup), in quanto è molto rapida la modifica al volo della passphrase.

A questo punto è sufficiente lanciare il programma e crearsi una directory criptata. Questo esempio crea la directory .crypt nella Home dell'utente corrente contenente i dati criptati e la monta nella directory crypt.

encfs ~/.crypt ~/crypt

Occorre rispondere a un paio di domande (per esempio, se le directories non esistono e occorre crearle). Quindi si può scegliere tra l'exptert mode e il paranoia mode già predefinito.
Quasi sempre si usa tranquillamente il modo predefinito.
L'ultima cosa da inserire, a questo punto, è la passphrase. Una volta fatto questo la directory ~/crypt è pronta per essere usata.
Per smontare questa directory basta lanciare il comando:

fusermount -u ~/crypt

E i dati non sono più disponibili finchè non si rimonta la directory, usando lo stesso comando usato per crearla.

Personalmente ho creato due scripts che vengono lanciati rispettivamente al logon e al logout che provvedono a montare e smontare la directory nella quale ho i miei dati riservati.

Anche in questo caso occorre ovviamente installare il programma che, nelle distribuzioni basate su Debian si chiama cryptsetup.
Debian, addirittura, durante l'installazione, consente di creare le partizioni criptate, cosa questa estremamente comoda in quanto si può fare l'installazione di un sistema criptando da subito i dischi e lasciando "a libero accesso" solo / e /boot.

Nel caso, invece, si abbia un sistema già installato e si voglia semplicemente creare una nuova partizione criptata, è necessario fare tutto a mano.
Per prima cosa occorre modificare il file /etc/crypttab. Questo file contiene la descrizione delle directory criptate, nel formato:

#<target device> <source device> <key file> <options>

Per esempio:

system-data_crypt /dev/mapper/system-data none luks
system-home_crypt /dev/mapper/system-home /data/conf/luks/key luks

In questo caso, visto che son pigro, instruisco il sistema per chiedermi la passphrase per la prima partizione, e gli dico che la passphrase per la seconda la trova in un file contenuto nella prima partizione.
Questa cosa è molto comoda nel caso in cui un Server abbia parecchie partizioni, tutte criptate (come sono tutti i Servers che ho in ufficio).

Ovviamente la prima partizione (/dev/mapper/system-data_crypt) dev'essere montata prima che il sistema possa sbloccare e quindi montare la seconda.
Questo non è un problema nel momento in cui si montano a mano le partizioni, ma nel caso in cui tutte le partizioni del disco siano criptate, occorre che lo faccia il sistema durante il Boot.
Per fare questo occorre istruire il sistema per montare una partizione prima di sbloccare le altre. Questo si ottiene inserendo nel file /etc/default/cryptdisks un valore per la chiave CRYPTDISKS_MOUNT (per i sistemi Debian. Per gli altri occorre guardare dove viene messo questo file):

CRYPTDISKS_MOUNT="/data"

Ovviamente /data è configurato in /etc/fstab! Nell'esempio, avremo:

/dev/mapper/system-data_crypt /data ext3 defaults 0 1
/dev/mapper/system-home_crypt /home reiserfs defaults 0 2

A questo punto occorre semplicemente formattare le partizioni:

cryptsetup luksFormat /dev/mapper/system-data
cryptsetup luksFormat /dev/mapper/system-home

Durante questo processo il sistema chiederà una passphrase che, per quanto riguarda la partizione /dev/mapper/system-home_crypt deve essere la stessa inserita nel file /data/conf/luks/key.

MOLTO IMPORTANTE! Questo file deve contenere SOLO ED ESCLUSIVAMENTE la passphrase! Anche un CRLF è vietato, in quanto verrebbe considerato parte della passphrase!! L'ideale è generare il file con questo sistema:

echo -n "<passphrase>" > /data/conf/luks/key

Una volta create le partizioni occorre sbloccarle, creare il FileSystem e infine montarle e usarle:

cryptsetup luksOpen /dev/mapper/system-data system-data_crypt
mkfs -t ext3 /dev/mapper/system-data_crypt
mount /data
cryptsetup luksOpen /dev/mapper/system-home system-home_crypt
mkfs -t reiserfs /dev/mapper/system-home_crypt
mount /home

FINITO! Durante il Boot, il sistema si bloccherà e non partirà finchè la passphrase per la partizione /data non verrà inserita, quindi, a meno che uno non sia così idiota da scrivere la passphrase su un PostIT attaccato al Server, i dati saranno al sicuro anche in caso di furto!
Certo, occorre anche installare un buon sistema di Backup, altrimenti i dati non saranno sicuramente usabili dai ladri, ma anche noi li avremo persi...

Nel caso di EncFS, basta dare il comando:

encfsctl passwd <directory contenente i dati in forma criptata (nell'esempio ~/.crypt)>

Il sistema chiederà l'attuale passphrase e la nuova (due volte!), quindi la passphrase verrà modificata.

Nel caso di LUKS, occorre inserire una seconda passphrase e quindi cancellare la prima.
Questo si ottiene in questo modo:

cryptsetup luksAddKey <device (nell'esempio /dev/mapper/system-data o /dev/mapper/system-home)>
cryptsetup luksDelKey <device> 0

Il sistema chiederà una nuova passphrase (per il primo comando) in modo da poterla aggiungere alla lista delle passphrases, e l'attuale passphrase per il secondo, quindi la prima passphrase verrà cancellata.
Ovviamente occorre modificare la passphrase anche nel file usato per montare automaticamente le partizioni al Boot, altrimenti al prossimo Boot del sistema non sarà possibile il mount automatico.

Tenetelo presente, quando installate il Server! Personalmente uso le partizioni LUKS solo per le macchine che ho in ufficio (e che sono relativamente facili da rubare). I Server in sala macchine hanno partizioni non criptate, in quanto non mi è permesso entrarci in sala macchine (che si trova dal Provider e non è nemmeno tanto vicina).

I commenti sono aggiunti quando e soprattutto se ho il tempo di guardarli e dopo aver eliminato le cagate, spam, tentativi di phishing et similia. Quindi non trattenete il respiro.

22 messaggi this document does not accept new posts

subject Di Motosauro postato il 04/03/2009 12:10

Ottima guida
Grazie

-- Motosauro

desktop Di mk66 postato il 09/03/2009 14:22

-AT- mk66 Di Luca Bertoncello postato il 10/03/2009 07:34

> Si parla di server, ma immagino che si possa attuare anche su un desktop?

Si parla di macchine con sistema operativo Linux. Che siano Server, Workstation, Firewall o quel che e', non cambia niente dal punto di vista della criptazione...

> Nel mio caso potrebbe essere utile per criptare la directory (o addirittura la partizione completa) dove salvo i lavori in corso.

E' quel che facciamo in ufficio...
Ricorda che LUKS e' molto piu' veloce di EncFS, quindi se hai parecchi files, usa LUKS (che funziona solo con una partizione).

> Sommato al backup, garantirebbe una maggior sicurezza, che non fa mai male.

Quello mai!

Ciao
Luca

-- Luca Bertoncello

-AT- mk66 Di miniBill postato il 16/03/2009 19:08

Grazie Di mk66 postato il 18/03/2009 23:07

Grazie a Luca per i chiarimenti e le spiegazioni dettagliate (appena avro' un poco di tempo, quindi non prima di maggio, ci studiero' bene sopra e procedero')

Grazie anche a MiniBill per il link, ma nella mia situazione mi sembra un pochino eccessivo criptare anche la root: quello che mi importa particolarmente e' salvaguardare il piu' possibile la mia partizione di lavoro: root e home eventualmente ci metto niente a reinstallarle, ma la partizione di lavoro mi manda in paranoia e cerco di fare di tutto e di piu' per proteggerla/proteggermi

-- mk66

-AT- mk66 Di Luca Bertoncello postato il 19/03/2009 07:39

Proprio ieri... Di Andrea Del Priore postato il 23/03/2009 13:09

-AT- Andrea Del Priore Di Luca Bertoncello postato il 23/03/2009 21:46

Criptare partizioni e directory Di Anonymous coward postato il 02/01/2010 23:13

Mi sembra di aver capito che con LUKS ci siano delle limitazioni alla lunghezza della chiave ( 256 bits ) e sui cifrari usabili. cryptoloop ( configurati con losetup ) + aes + chiave di 512 bits è una soluzione più adatta al mio grado di paranoia

Aggiungerei truecrypt alla lista dato che è anche multipiattaforma. -- Anonymous coward

@ Anonymous coward Di Luca Bertoncello postato il 03/01/2010 08:44

> Mi sembra di aver capito che con LUKS ci siano delle limitazioni alla lunghezza della chiave ( 256 bits ) e sui cifrari usabili. cryptoloop ( configurati con losetup ) + aes + chiave di 512 bits è una soluzione più adatta al mio grado di paranoia
>
> Aggiungerei truecrypt alla lista dato che è anche multipiattaforma.

Dal man di cryptsetup:

--key-size, -s
set key size in bits. Has to be a multiple of 8 bits. The key size is limited by the used cipher. See output of /proc/crypto for more information. Can be used for create or luksFormat, all other LUKS actions will ignore this flag, as the key-size is specified by the partition header. Default is 128 for luksFormat and 256 for create.

Non direi quindi che c'e' SEMPRE una limitazione di 256 bit...

In ogni caso, cryptoloop ha le sue belle limitazioni e, da quel che ne so, e' lento. E poi voglio vederti usarlo per partizioni usate dal sistema (/usr, /var/, etc.).
Cryptoloop lo userei solo per i miei dati personali (da smontare ogni volta).

Ciao -- Luca Bertoncello

@ Luca Bertoncello Di The same Anonymous coward postato il 12/01/2010 17:37

@ The same Anonymous coward Di Luca Bertoncello postato il 13/01/2010 08:10

> > Non direi quindi che c'e' SEMPRE una limitazione di 256 bit...
>
> In fase di installazione da netboot c'è :/

Ma non SEMPRE!

> E' lento e non si sposa bene con i filesystem journaled ( tutti oramai ) , ma è ancora valido : https://wiki.torproject.org/noreply/TheOnionRouter/OperationalSecurity

Niente da dire, ma rimane lento! Se lo usi solo tu per pochi dati, va bene, ma prova a farci lavorare un'intera ditta, poi mi dici!

> > E poi voglio vederti usarlo per partizioni usate dal sistema (/usr, /var/, etc.).
>
> Uhm ... ma che senso ha criptare /usr ? Posso capire /var , /tmp ... :/

Ha senso, credimi! Se ti ciulano l'Hard-Disk, e' meglio fare in modo che nessuno possa leggere NIENTE...

Ciao -- Luca Bertoncello

@ Luca Bertoncello Di The same Anonymous coward postato il 13/01/2010 15:43

> > Uhm ... ma che senso ha criptare /usr ? Posso capire /var , /tmp ... :/
>
> Ha senso, credimi! Se ti ciulano l'Hard-Disk, e' meglio fare in modo che nessuno possa leggere NIENTE...

Uhm ... ho capito : se anche la /usr è criptata , nessuno può andare a verificare che tipo di programmi erano installati sul quel sistema ( server di posta , server web , etc ...) e quindi avere informazioni sul tipo di dati eventualmente presenti nel resto del disco.

Innanzitutto , grazie per le risposte e la pazienza ... ancora una domanda : la tabella delle partizioni e le caratteristiche/il tipo delle singole partizioni sono ancora visibili , distinguibili , in chiaro con LUKS ? In caso affermativo , esiste una soluzione che non richieda meccanismi hardware tipo TPM per avere qualcosa di simile a una full disk encryption ? -- The same Anonymous coward

@ The same Anonymous coward Di Luca Bertoncello postato il 14/01/2010 08:32

> Innanzitutto , grazie per le risposte e la pazienza ... ancora una domanda : la tabella delle partizioni e le caratteristiche/il tipo delle singole partizioni sono ancora visibili , distinguibili , in chiaro con LUKS ? In caso affermativo , esiste una soluzione che non richieda meccanismi hardware tipo TPM per avere qualcosa di simile a una full disk encryption ?

Come e' scritto chiaramente nell'articolo, le partizioni sono state create normalmente con LVM. Quindi si! Le partizioni sono visibili e puoi vederne la dimensione e capire che sono poi trattate con LUKS.

NON puoi vedere, ovviamente, il FileSystem installato, perche' questo e' stato creato sopra LUKS.

Ciao -- Luca Bertoncello

LUKS ... Di jojo-QUE postato il 21/01/2010 16:28

@ jojo-QUE Di Luca Bertoncello postato il 22/01/2010 08:14

@ Luca Bertoncello Di jojo-QUE postato il 22/01/2010 22:08

> Sono memorizzate IN CHIARO?!? Scusa, ma questa mi giunge veramente nuova...
> Puoi citare un qualche articolo/HowTo/altro che spieghi 'sta roba (che a me sembra una cazzata assurda)?

http://tinyurl.com/yb2vnqw

http://www.saout.de/tikiwiki/tiki-index.php?page=LUKSFaq ( How can I backup my partition header/my metadata? )

http://lwn.net/Articles/358220/

http://theinvisiblethings.blogspot.com/2009/10/evil-maid-goes-after-truecrypt.html

http://www.schneier.com/blog/archives/2009/10/evil_maid_attac.html

Loop-aes non è vulnerabile al memory dump attack poichè prevede un meccanismo interno per lo scrubbing delle chiavi. Altri sistemi , come (Open)Solaris , implementano meccanismi simili nativamente e direttamente sulla VM ...

non sono riuscito a raccattare il thread di gmame con la patch che implementa lo scrubbing sulla VM del kernel linux e la relativa discussione ... ma comunque ho trovato altri threads interessanti su loop-aes e sull'introduzione del relativo supporto in dm-crypt

http://news.gmane.org/gmane.linux.kernel.cryptoapi/cutoff=3820
http://news.gmane.org/gmane.linux.cryptography

Ovviamente la base di partenza per il mio punto è che l'attaccante sia un fdp certificato e abbastanza determinato.
-- jojo-QUE

@ jojo-QUE Di Luca Bertoncello postato il 23/01/2010 08:39

@ Luca Bertoncello Di Anonymous coward postato il 18/04/2010 16:52

@ Luca Bertoncello Di gianni postato il 27/05/2010 17:30

accesso da remoto Di jojo-QUE postato il 03/02/2010 01:01

@ jojo-QUE Di Luca Bertoncello postato il 03/02/2010 07:34

22 messaggi this document does not accept new posts

Precedente Successivo

Luca Bertoncello ha lavorato come responsabile del MailCluster per un Internet Service Provider in Dresden (Germania), specializzandosi nella configurazione di Exim, SpamAssassin e Clam e nella gestione di Clusters basati su Heartbeat e DRBD.
Attualmente lavora per una ditta che gestisce campagne pubblicitarie su Internet (no, non e' uno spammer :D) come programmatore e sistemista.
E' completamente paranoico... :)
Maggiori informazioni sul suo sito: http://www.lucabert.de/

Il presente sito e' frutto del sudore della mia fronte (e delle mie dita), se siete interessati a ripubblicare uno degli articoli, documenti o qualunque altra cosa presente in questo sito per cortesia datemene comunicazione (o all'autore dell'articolo se non sono io), cosi' il giorno che faccio delle aggiunte potro' avvisarvi e magari mandarvi il testo aggiornato.