Export NFS bloccato su un indirizzo VPN: cosa non dimostra
Una regola di export controlla da dove è arrivato il pacchetto; AUTH_SYS dichiara un UID locale e Kerberos autentica un utente. Decidi quale serve al tuo servizio file.
Un host esporta una directory verso un indirizzo VPN, il montaggio riesce e il progetto viene annotato come autenticato. Ciò che quella regola vincola davvero è da dove i pacchetti sembrano provenire. Che la persona che guida l'operazione sui file sia chi dice di essere dipende dal profilo di sicurezza NFS, e nella maggior parte degli export di questo tipo nessuno l'ha cambiato rispetto al valore predefinito.
Tre identità possono comparire in una sola richiesta
Il peer VPN porta un'identità registrata, come un certificato client o una chiave del peer. Il pacchetto IP interno porta un indirizzo di origine. L'operazione sui file porta le credenziali utente fornite dal suo meccanismo NFS. Un progetto che tratta l'indirizzo come sostituto di tutte e tre ha silenziosamente dato per scontata proprio la parte che andava verificata.
| Identity | What it proves | What it does not |
|---|---|---|
| VPN peer | Which peer was accepted by the tunnel | Which user runs on that machine |
| Inner source address | Where the packet appears to originate | That only the intended client can use it |
| NFS credential | What the file service believes about the caller | Anything, if the flavour only asserts local IDs |
Scrivere quelle tre righe è l'intero esercizio. Gran parte del dibattito sulla sicurezza di un export crolla quando è chiaro in quale riga vive ogni controllo.
La proprietà dell'indirizzo è un dettaglio implementativo
Un gateway può assegnare un indirizzo di tunnel a un peer accettato o autorizzare per esso una sottorete instradata. Che l'implementazione rifiuti poi un pacchetto la cui origine interna appartiene a un altro client è una proprietà di quell'implementazione, e vale la pena verificarlo invece di darlo per scontato.
Il codice server in spazio utente del Community tradizionale OpenVPN può, per esempio, rifiutare un'origine associata a un altro client prima che il pacchetto venga consegnato tramite il dispositivo TUN. È un controllo di proprietà dell'indirizzo di valore reale, e non è ancora autenticazione utente NFS, perché non dice nulla su quale account esegue l'operazione.
La traduzione dell'origine erode persino questo. Un gateway NAT può presentare ogni client come un solo indirizzo, e allora una regola di export non può distinguere le persone che vi stanno dietro. La precisione apparente della regola diventa allora una finzione mantenuta dallo schema. Se l'export conta, mantieni l'indirizzamento esplicito invece di lasciare che un traduttore decida chi conta come chi.
Leggi il profilo di sicurezza prima di fidarti dell'export
La guida NFS di Red Hat separa sec=sys, che usa UID e GID UNIX locali tramite AUTH_SYS, dalle modalità Kerberos. krb5 aggiunge l'autenticazione utente, krb5i aggiunge la protezione dell'integrità e krb5p aggiunge la protezione della riservatezza del traffico.
Le credenziali AUTH_SYS contengono campi come l'UID del chiamante e gli identificatori di gruppo, e la RFC 5531 avverte chiaramente che questo profilo non offre sicurezza di per sé e dipende da una protezione esterna. Eseguirlo dentro una VPN fornisce protezione per il trasporto e non cambia nulla dell'asserzione dentro il pacchetto.
exportfs -v
showmount -e nfs.example.internalLeggi il profilo in quell'output prima di leggere l'elenco dei client. Un export che sembra limitato può esserlo solo per indirizzo mentre ogni chiamante dichiara ancora l'UID che preferisce.
Scegli il modello, poi conserva i permessi
Scegli il modello di autenticazione del servizio file adatto ai client che amministri davvero. Kerberos richiede un'identità e un'implementazione del servizio alle spalle, quindi cambiare un'opzione di montaggio non è una migrazione e semplicemente fallirà finché non esistono il dominio Kerberos, i principal e i keytab.
Con entrambi i modelli, conserva i permessi di export e l'autorizzazione del filesystem che limitano ciò che il principal autenticato può fare. L'autenticazione ti dice chi chiede; l'autorizzazione decide se la risposta deve essere sì. Fondere le due in un'unica impostazione è il modo in cui una migrazione finisce per concedere più di quanto facesse la vecchia configurazione.
Usa la regola dell'indirizzo per il suo vero scopo
Limitare il servizio al percorso e alle origini approvate resta utile, inclusa la politica di input dell'host quando l'endpoint VPN e il server NFS condividono la macchina. Le regole che inoltrano traffico non governano le richieste dirette a un servizio in esecuzione localmente sullo stesso host. Questa lacuna spiega un numero sorprendente di export che dovevano essere privati. Verifica esplicitamente la politica di input locale invece di presumere che le regole del tunnel la coprano.
Verifica che un'altra interfaccia o un gateway con traduzione dell'origine non possa soddisfare la regola inaspettatamente, e trattalo come motivo per stabilire la provenienza, non come l'affermazione che falsificare un indirizzo garantisca un montaggio funzionante.
Esegui tre casi di accettazione invece di uno. Inizia con un client approvato che agisce come utente approvato, poi ripeti da un peer che non è mai stato approvato, e infine prova qualcosa che l'utente approvato non è ancora autorizzato a fare. Chiediti poi cosa cambia se un client autorizzato viene compromesso, perché l'autenticazione del trasporto non rende affidabile ogni processo su quella macchina. Un certificato rubato e un account locale curioso sono problemi diversi con controlli diversi.