Apri automaticamente il contenitore LUKS all'avvio del sistema in modo sicuro

7

Ho un sistema Linux in esecuzione presso un provider cloud in cui ho creato un contenitore crittografato utilizzando LUKS per archiviare dati personali.

Il contenitore crittografato viene montato manualmente a /srv ; il resto del sistema non è crittografato in modo tale che il server e in particolare il demone ssh si avviino automaticamente all'avvio del sistema.

Al momento, se il server si riavvia (a causa di un aggiornamento che richiede un riavvio o perché il sistema host in cui viene eseguito il droplet richiede un riavvio) Devo aprire manualmente il contenitore LUKS e avviare i servizi che memorizzano i dati nel partizione crittografata (dovecot, mysql ecc.). Naturalmente, questa è la conseguenza logica di avere una partizione crittografata. Ma mi stavo chiedendo se posso automatizzare questo in modo sicuro.

Non voglio memorizzare la passphrase sul server per ovvi motivi. Così ho scritto un piccolo script che gira su un Raspberry Pi a casa: ssh-es ogni 5 minuti nel server e controlla se il dispositivo Loopback è montato. Se no monta il contenitore (righe rilevanti dello script, questo viene eseguito solo se /srv non è montato):

# Mount Srv Container
ssh root@<ip> "echo -n '*** my passphrase ***' | cryptsetup luksOpen /root/srv_container_file container -"
ssh root@<ip> "mount -t ext4 /dev/mapper/container /srv"

# Start Services that store data on /srv
# ...

L'approccio funziona ma sembra super hacky. Non sono sicuro se le connessioni costanti, ovvero i controlli attivi, siano una buona idea e non sono nemmeno sicuro se mi sto aprendo alle vulnerabilità facendo eco alla mia passphrase in cryptsetup .

Quindi la mia domanda:

Che cos'è un modo buono / standard per aprire automaticamente il contenitore LUKS senza memorizzare la passphrase sul server e senza aprire il mio sistema alle vulnerabilità (rispetto all'apertura manuale del contenitore)? I riferimenti alla documentazione ufficiale sono i benvenuti.

Di cosa sto cercando di proteggermi?

  • Non so come il cloud provider gestisca i dischi vecchi e / o difettosi. Non voglio che nessuno legga i miei dati dai dischi fisici o dai backup eseguiti dal mio provider cloud.
  • Non so se la mia immagine del disco viene spostata nella memoria fisica (secondo i documenti del mio provider è archiviata in modo ridondante), quindi non voglio che nessuno che abbia accesso a quei blocchi dopo di me essere in grado di ripristinare i dati.

  • So che una volta che un utente malintenzionato ha accesso alla shell al mio sistema in esecuzione, è game over quando la partizione è aperta e non è necessaria la passphrase.

posta phisch 29.04.2018 - 12:20
fonte

1 risposta

2

Piuttosto che avere una macchina locale interrogare periodicamente il server e spingere la chiave su di essa, se necessario, si può fare il contrario e chiedere al server di estrarre la chiave dal proprio computer locale. Il server e il client possono autenticarsi reciprocamente con SSH, in modo tale che sia necessario un utente malintenzionato attivo che abbia accesso alla memoria del computer locale o all'archiviazione della macchina remota per rubare la chiave. Se l'utente malintenzionato è passivo e può solo leggere il contenuto del disco della macchina remota, ma non agire su di esso (ad esempio, da SSHing al server reale e backdooring), la password deve essere protetta. L'implementazione specifica dipende da te, ma potrebbe essere:

  1. Il server si avvia, si collega al computer locale e richiede la chiave.

  2. Il server e il computer locale si autenticano reciprocamente su SSH.

  3. Opzionalmente, le due macchine possono verificare che l'altra si colleghi dall'IP corretto.

  4. Dopo l'autenticazione, il server estrae la chiave dal computer locale.

Poiché hai specificato che il tuo modello di minaccia coinvolge un utente malintenzionato con accesso completo alla memoria del server remoto, tieni presente che puoi proteggere solo da un avversario passivo, non da chi è in grado di leggere entrambi gli e MITM la tua connessione, o SSH direttamente usando le credenziali rubate.

    
risposta data 29.04.2018 - 13:11
fonte

Leggi altre domande sui tag