Rileva le modifiche in / boot quando si utilizza la crittografia completa del disco

4

Quando si esegue un sistema Linux completamente crittografato usando dm-crypt, la partizione /boot deve essere decodificata per l'avvio, per quanto ne so. Ho installato un server che può essere sbloccato in remoto connettendosi a un server ssh di pre-avvio in esecuzione da initrd.

Un vettore di attacco che vorrei chiudere è l'installazione di un keylogger in initrd.

Ho ragionato in questo modo: Non posso impedire modifiche alla partizione /boot poiché l'avversario ha accesso ad esso in un ambiente ospitato. Ma posso rilevare le modifiche utilizzando i checksum all'interno del sistema crittografato usando semplice sha512sum o tripwire. Inoltre posso monitorare il server per il riavvio (che potrebbe indicare cambiamenti).

Quali sono i metodi di mitigazione che ti vengono in mente?

    
posta Peter Meyer 05.08.2012 - 22:21
fonte

2 risposte

6

Questo è esattamente il problema che Secure Boot è stato creato per risolvere. Il problema è che se non hai una catena di fiducia che ritorna al POST, allora non puoi garantire che non ci sia stata manomissione. (E anche allora, "garanzia" è un'esagerazione).

È possibile eseguire il checksum della partizione di avvio all'avvio; forse usa il checksum come parte della chiave per il prossimo passo. Non è completamente a prova di manomissione, ma senza integrazione crittografica basata su hardware non lo sarà. Fai del tuo meglio con gli strumenti che hai e assicurati di aver compreso le limitazioni.

    
risposta data 06.08.2012 - 04:07
fonte
-1

Dopo aver collegato SSH in remoto al server, è possibile eseguire kexec in un kernel fornito da una posizione sicura. Assicurati inoltre di fornire i tuoi binari hash / kexec in quanto potrebbero anche essere temperati. Assicurati che i moduli siano caricati anche da una posizione sicura.

    
risposta data 06.08.2012 - 08:08
fonte

Leggi altre domande sui tag