La chiave VPN è leggibile da tutti: cosa correggere

Il primo segnale è di solito un avviso, non un guasto. Un client rifiuta di caricare una chiave perché il file è leggibile dal gruppo o da tutti, oppure una revisione di sicurezza trova client.key in modalità 644 in una cartella di profilo che contiene anche pacchetti esportati. Niente è ancora guasto, ed è proprio per questo che l’avviso viene ignorato. La chiave funziona, il tunnel si alza e il file è leggibile da ogni account della macchina.

Il sintomo è un avviso di permessi, non un’interruzione

Su un sistema simile a Unix, una chiave privata dovrebbe essere leggibile solo dall’account che esegue il servizio. Un modo 600 con il proprietario corretto è la disposizione abituale. Un modo 644 significa che ogni utente locale può copiare la chiave, e su un host di compilazione condiviso questo è un pubblico reale.

I client che verificano questo vi fanno un favore. Quelli che non lo fanno non sono prova che il file sia sicuro, e una connessione riuscita non dice nulla su chi altro può leggere il materiale che l’ha resa possibile. Trattate l’avviso come l’intera constatazione. È accurato ed è arrivato prima che qualcuno copiasse il file.

Adattate il modo all’identità del servizio

L’accesso riservato al proprietario si addice a una chiave usata da quel proprietario. Un servizio con un gruppo condiviso di proposito può aver bisogno di un’altra disposizione controllata, come la lettura di gruppo su una chiave di proprietà di un account di servizio. Impostare ciecamente un solo modo numerico su tutti i file rompe i client supportati, e chmod -R 777 non risolve nulla.

Controllate il proprietario e l’account di servizio prima di cambiare qualsiasi cosa. I certificati CA pubblici e le chiavi di identità private hanno requisiti di segretezza diversi anche quando si trovano nella stessa cartella, quindi un modo ricorsivo applicato all’intera cartella li tratta come lo stesso oggetto.

ls -l /etc/openvpn/client/
stat -c '%U %G %a %n' /etc/openvpn/client/*.key
id openvpn

Su altre piattaforme usate l’archivio di chiavi o il modello di controllo degli accessi documentato invece di tradurre i modi Unix in una congettura. Un nome di file che termina in private è un’etichetta, non un meccanismo di applicazione.

Trovate le copie che il modo non copre

Editor, archivi di backup, profili esportati e pacchetti temporanei possono ciascuno conservare la stessa identità. Proteggete quelle copie in base al loro contenuto, perché stringere il file originale non fa nulla per quella nel tar del mese scorso.

Una passphrase su un file di chiave è utile per il materiale archiviato e non giustifica la pubblicazione del file cifrato accanto alla sua password. I permessi proteggono l’oggetto attuale del file system; non dicono nulla su una credenziale già copiata altrove.

Cercate le copie prima di dichiarare il lavoro finito: grep -rl la riga di intestazione della chiave nelle directory probabili e uno sguardo alle esclusioni dei backup. Il risultato è di solito più interessante del file con cui avete iniziato.

Dopo la correzione, verificate e rinnovate

Verificate che il servizio previsto si autentichi ancora, poi confermate che nessun account inutile abbia ottenuto l’accesso. Limitate l’output diagnostico ai metadati, perché stampare la chiave non serve a dimostrare che il file è leggibile e mette il materiale in un registro.

Se la chiave è stata esposta, stringete il modo, poi sostituite la credenziale e revocate quella vecchia. La specifica POSIX chmod spiega cosa significa ogni bit di modo, cosa che vale la pena sapere prima che la revisione successiva vi chieda di giustificare il numero scelto.