Secure Network Filesystems per Linux: cosa stanno facendo le persone?

NFSv3 è molto diffuso, ma il modello di sicurezza predefinito è ... caratteristico . CIFS può utilizzare l'autenticazione Kerberos, ma senza la semantica POSIX non è un avviatore. AFS non ha mai crittografato il traffico sul filo ed è krb4 - e sostanzialmente un progetto morto. I nuovi fantasiosi filesystem sperimentali non si materializzano mai o sono focalizzati sulla velocità (e se sei fortunato, l'affidabilità dei dati) - ad esempio, Lustre utilizza lo stesso modello di affidabilità client di NFSv3. Per uso domestico, sshfs è elegante, ma sicuramente non si adatta.

E poi ovviamente c'è NFSv4, con sec = krb5p. Grande in teoria, ma dopo dieci anni, sembra essere inutilizzato in modo preoccupante nel mondo reale. Il client Linux ha appena rimosso il tag sperimentale. E se guardi EMC Celerra, Isilon, ecc., È tutto NFSv3. (Celerra supporta NFSv4, ma è davvero sepolto nella documentazione. A quanto pare Isilon ha lavorato per aggiungere il supporto RPCGSS a FreeBSD, quindi forse sta arrivando, ma non è lì adesso.) Non posso nemmeno contrassegnare questo post come "nfsv4" perché Sono nuovo qui e sarebbe un nuovo tag .

Quindi davvero . Cosa state facendo tutti?

Dal momento che è una domanda specifica (cosa state facendo tutti), rispondiamo: niente. La maggior parte degli amministratori e degli utenti non si preoccupano della sicurezza di NFS, quindi tutti usano NFSv3. In genere è un ambiente controllato (nel senso che solo macchine ben note possono collegarsi alla rete in primo luogo). Se qualcuno viene sorpreso ad abusare dell'infrastruttura, viene licenziato o imprigionato.

Per i dati che non vuoi davvero che nessuno sia in grado di leggere, li crittografhi esplicitamente, ad esempio database di password di Firefox, chiavi ssh o chiavi pgp. Lo fai perché sai che l'amministratore potrebbe leggerli sul file server, quindi la sicurezza del file system di rete non sarebbe comunque di alcun aiuto.

Sembra che tu stia facendo due domande qui:

Cosa stiamo effettivamente usando? e che cosa fa questo?

Quello che sto effettivamente usando è CIFS, nei miei casi d'uso POSIX è meno importante, quindi non ho avuto problemi. NFS3 viene utilizzato in aree in cui la sicurezza non è importante, come ad esempio il mio server di installazione SLES. E infine, sshfs / gvfs per una semplice condivisione utente-terra. La crittografia dei cavi non è ritenuta necessaria, quindi non è un fattore significativo per noi.

Per quanto riguarda l'altra domanda, sembrano esserci sei requisiti principali per quello che stai cercando:

1. Crittografa il traffico sul filo.
2. Crittografa l'autenticazione.
3. Semantica Posix.
4. Forte applicazione di ACL basati su server.
5. Non è terra dell'utente.
6. Viene effettivamente utilizzato.

Sospetto che i punti 5 e 6 saranno gli assassini qui, ma qui va (anche questo è il punto in cui un tavolo sarebbe davvero utile, ma markdown / StackExchange non lo supporta).

NFSv3 + IPSec

1. Crittografato sul filo, passa
2. Nessuna autenticazione crittografata, errore
3. Semantica Posix, passaggio
4. Nessuna forte applicazione di ACL basati su server, non riesce
5. Non è userland, passa
6. Viene effettivamente utilizzato, passa

NFSv4 + Krb + IPSec

1. Crittografato sul filo, passa
2. Autenticazione crittografata, pass
3. Semantica Posix, passaggio
4. Forte applicazione di ACL basati su server, pass
5. Non è userland, passa
6. In realtà non viene utilizzato, fallire

CIFS

1. Non crittografato sul filo, errore
2. Autenticazione crittografata
3. Semantica Posix, pass (Samba e Kernel ora, Windows ha avuto un livello Posix dai tempi di NT)
4. Forte applicazione di ACL basati su server, pass
5. Non è userland, passa
6. Viene effettivamente utilizzato, passa

CIFS + IPSec

1. Crittografato sul filo, passa
2. Autenticazione crittografata
3. Posix semantics, pass (Samba & Kernel now)
4. Forte applicazione di ACL basati su server, pass
5. Non è userland, passa
6. In realtà non viene utilizzato, fallire

SSHFS

1. Crittografato sul filo, passa
2. Autenticazione crittografata, pass
3. Semantica Posix, passaggio
4. Forte applicazione di ACL basati su server, pass
5. Userland, fail
6. Viene effettivamente utilizzato, passa

AFP / netatalk

1. Crittografato sul filo, non riesce
2. Autenticazione crittografata, pass
3. Semantica Posix, passaggio
4. Forte applicazione di ACL basati su server, pass
5. Non è userland, passa
6. Viene effettivamente utilizzato, fallire

E non sto toccando i file system distribuiti là fuori. Semplicemente non c'è una sola cosa che fa tutto. Alcuni si avvicinano (CIFS) e alcuni sono già lì, ma nessuno li usa (NFS4 + IPSec, CIFS + IPSec). Per qualche ragione un filesystem di rete sicuro è stato oggetto di molti compromessi nel corso degli anni.

Ho usato openafs in produzione per anni, con client sia Linux che Windows. Funziona benissimo, ha una comunità di sviluppo attiva ed è diventato molto più facile da installare e amministrare negli ultimi anni poiché le varie distribuzioni di Linux hanno incluso il packaging per esso. Ha le sue verruche, ma ho scoperto che sono compensate da una maggiore flessibilità amministrativa, dalla possibilità di avere client e server separati da collegamenti lenti, dalla facilità dei backup offsite e da altri AFSisms positivi.

Una cosa che mi piace in particolare è l'esecuzione di server Web di produzione rivolti a Internet su openaf, con gli ACL bloccati. Senza un ticket Kerberos non esiste alcun processo sulla macchina - nemmeno uno in esecuzione come root - che può scrivere sul filesystem. Non posso contare quante volte abbiamo notato che gli attacchi falliscono completamente a causa di quella semplice misura.

Ci sono alcuni utenti openafs piuttosto grandi - il più grande utente commerciale che conosco è Morgan Stanley.

Che ne dici di OpenAFS che è ancora attivo e una VPN sotto di essa perché la sua unica crittografia al momento è DES.

Vedo che molte persone in questo thread parlano di nascondere i dati, ovvero attacchi che non sono in grado di curiosare sui tuoi dati. Un altrettanto importante pensare all'integrità e all'autenticità dei dati. Questi pacchetti nfs provengono davvero dal tuo server nfs? Un pacchetto nfs è stato modificato durante il trasporto?

Bene, a me sembra che uno di quei filesystem distribuiti sarebbe adatto a te. Non vorrei assolutamente raccomandare OpenAFS, dato che è vecchio, non supporta ancora IPv6, ..

Sono abbastanza contento di GlusterFS me stesso. Gluster è piuttosto maturo, funziona bene e ha un buon set di funzionalità. Tuttavia, come recentemente discusso in IRC, Gluster non supporta neanche IPv6 in modo stabile. Questa funzione sarà programmata per 3.6 o 3.7.

Esiste anche un progetto chiamato HekaFS, basato su Gluster, che aggiunge funzionalità di autenticazione e SSL più avanzate. È estremamente ben documentato e molto ben progettato.

Ciò che potrebbe interessarti è XtreemFS , che è progettato per il grid computing globale, quindi viene fornito con SSL e roba di default. Tuttavia, la mia scelta di utilizzo è caduta su Gluster, poiché la community sembra più attiva e documentata meglio.

Entrambi sono compatibili posix ovviamente.

Io uso NFS. Ma NFS da server a server viene eseguito su un backbone di rete dedicato, quindi la crittografia non è necessaria e l'autenticazione è quasi inutile. Basta impostare ogni esportazione per condividere solo una directory selezionata su un server basato su IP.

Con tutto il dovuto rispetto, stai osservando completamente questo problema nel modo sbagliato e dovresti allontanarti dalla console per alcune ore.

Praticamente tutto lo storage io non è crittografato perché non ha importanza in quel livello dello stack di astrazione. Ne dubito? Metti un colpetto sul tuo interruttore in fibra di broccato e vedrai che il canale in fibra, proprio come iscsi e nfs, è tutto un pasticcio non crittografato - di progettazione. Risolvere questo è un problema medio, non un problema del protocollo di archiviazione. Ad esempio, vuoi un nfs sicuro e crittografato? Creata una lan che è criptata punto a punto tra il client nfs e il server usando ipsec / ssl / tls o una soluzione hardware pura.