"tenendo aperto" casa criptata con ssh locale

2

Ho un paio di macchine che uso per cose puramente automatizzate, con le directory home crittografate usando ecryptfs. Pertanto, anche se la macchina è accesa, tali directory non vengono decodificate a meno che l'utente non acceda (comportamento desiderato). Ora, mi piacerebbe essere in grado di eseguire un server utilizzando uno di questi utenti (i dati in esso memorizzati), e non mi dispiace loggarlo una volta all'avvio del servizio. Tuttavia, non voglio lasciare una sessione SSH aperta da un'altra macchina a quella automatizzata.

La mia strategia attuale è uno script che esegue una sessione SSH localhost all'interno di un processo di screening, che quindi si scollega dopo l'accesso. Ciò mantiene l'utente "connesso a se stesso" purché quel processo di schermo sia in esecuzione. Eseguo questo script dall'esterno utilizzando SSH, quindi rilascia la sessione SSH remota, lasciando in esecuzione la sessione SSH schermata localhost, mantenendo montata la directory ecryptfs.

Quali sono i rischi per la sicurezza di questo approccio, se esiste?

    
posta bright-star 24.12.2013 - 05:34
fonte

1 risposta

2

Se qualcuno accede al tuo sistema tramite software significa che mentre il filesystem crittografato è montato, ottiene l'accesso al filesystem.

Se qualcuno ottiene l'accesso al tuo sistema tramite software significa che mentre il filesystem crittografato non è montato, possono comunque accedere al filesystem: dipende da quando rilevi l'intrusione. Se riescono a ottenere il root (e non solo l'accesso come altri demoni di sistemi confinati), possono installare malware che registreranno la password e la chiave di decodifica del filesystem la prossima volta che inserirai la password di decrittografia.

Se qualcuno ottiene l'accesso al tuo sistema con mezzi hardware mentre il filesystem crittografato è montato, può ottenere l'accesso al filesystem. Ad esempio, possono eseguire una calda estrazione della RAM e scaricare i tasti dalla memoria.

Quindi mantenendo le directory non criptate si aumenta la finestra del rischio. Tuttavia, l'unico modo per ridurre tale rischio è smettere di utilizzare il server: il processo del server deve comunque accedere ai dati.

Mantenere un processo di Screening in esecuzione, anziché, ad esempio, disattivare lo smontaggio automatico, ha solo un impatto sulla sicurezza se c'è una vulnerabilità in Screen. Screen è un programma maturo e abbastanza stabile, quindi la probabilità che una vulnerabilità ancora sconosciuta venga scoperta al suo interno è piuttosto bassa. La sicurezza dello schermo si basa sulle autorizzazioni dei file (la proprietà della directory dei socket), quindi in ogni caso qualsiasi cosa che possa influire su di esso è altamente probabile che sia in grado di influenzare anche il demone che fornisce servizi.

In termini pratici, questo approccio non aumenta il rischio oltre a quello inerente all'esecuzione del daemon, in primo luogo.

    
risposta data 24.12.2013 - 12:45
fonte

Leggi altre domande sui tag