NFS � molto utile per condividere in modo traparente, interi file system con un gran numero di host conosciuti. Comunque, al di l� della facilit� d'uso, esistono numerosi problemi di sicurezza.
Dovete tenere in considerazione i seguenti punti quando esportate file system NFS su un server o li montate su di un client. cos� potrete ridurre al minimo i rischi legati alla sicurezza di NFS e sarete in grado di proteggere meglio i vostri dati.
Per un elenco abbreviato sulle fasi che un amministratore pu� intraprendere per rendere sicuri i server NFS, consultate il capitolo Sicurazza del server nella Red Hat Enterprise Linux Security Guide.
9.5.1. Accesso Host
A seconda dell'ambiente di rete esistente, e dei problemi riguardanti la sicurezza, � possibile scegliere la versione di NFS a voi pi� idonea. Le seguenti sezioni affrontano le differenze nell'implementazione delle misure di sicurezza con NFSv2, NFSv3, e NFSv4. L'utilizzo di NFSv4 � consigliato rispetto alle altre versioni di NFS.
9.5.1.1. Utilizzo di NFSv2 o NFSv4
NFS controlla chi pu� montare un file system esportato in base all'host che effettua la richiesta di montaggio, non in base all'utente che utilizza il file system. Occorre fornire agli host dei diritti specifici perch� possano montare il file system esportato. Non � possibile controllare l'accesso degli utenti, a differenza dei permessi di file e directory. In altre parole, quando esportate un file system tramite NFS state anche permettendo a tutti gli utenti su qualsiasi host remoto collegati al server NFS, di accedere ai dati condivisi. Per limitare tali rischi, gli amministratori possono sempre abilitare un accesso di sola lettura, limitando il potere degli utenti e dei gruppi ID tramite l'opzione squash. Sfortunatamente, queste soluzioni possono intaccare l'uso originario della condivisione NFS.
Inoltre, se un aggressore assume il controllo del server DNS utilizzato dal sistema che esporta il file system NFS, il sistema associato a un particolare hostname o a un nome di dominio completamente qualificato pu� essere indirizzato verso una macchina non autorizzata. A questo punto, tale macchina non autorizzata � il sistema che ha il permesso di montare la condivisione NFS, dal momento che non vengono scambiate informazioni di sorta relative al nome utente e password mirate ad aumentare la sicurezza del montaggio NFS.
Le wildcard vanno usate con cautela quando si esegue una esportazione di directory tramite NFS, in quanto � possibile raggiungere anche sistemi di cui non conoscete l'esistenza.
� possibile altres� limitare l'accesso al servizio portmap tramite i wrapper TCP. L'accesso alle porte usate da portmap, rpc.mountd, e rpc.nfsd, pu� essere limitato creando delle regole per il firewall con iptables.
Per informazioni su come rendere sicuro NFS e portmap, consultate il capitolo intitolato Sicurazza del server nella Red Hat Enterprise Linux Security Guide. Informazioni aggiuntive sui firewall sono disponibili sul Capitolo 18.
9.5.1.2. Utilizzo di NFSv4
Con NFSv4 si � verificata una vera e propria rivoluzione per quanto concerne il processo di autenticazione e le problematiche riguardanti la sicurezza delle esportazioni NFS. NFSv4 permette l'implementazione del modulo RPCSEC_GSS, il meccanismo GSS-API versione 5 di Kerberos, SPKM-3, e LIPKEY. Con NFSv4, i meccanismi riguardanti la sicurezza sono orientati al modello di autenticazione individuale degli utenti, e non delle macchine client come previsto con NFSv2 e NFSv3.
Nota Bene
Prima di configurare un server NFSv4, si presume che sia stato precedentemente installato un server ticket-granting di Kerberos (KDC), e che lo stesso sia stato configurato correttamente.
NFSv4 include un supporto basato su ACL su modello Microsoft Windows NT, e non sul modello POSIX, grazie alle sue caratteristiche e al suo largo impiego. NFSv2 e NFSv3 non presentano alcun supporto per gli attributi delle ACL native.
Un'altra caratteristica importante riguardante la sicurezza di NFSv4, � rappresentata dalla rimozione del demone rpc.mountd. Infatti il demone rpc.mountd presentava alcune vulnerabilit� a causa del modo con il quale gestiva i file handler.
Una volta che il filesystem NFS � stato montato in modalit� lettura/scrittura da un host remoto, la protezione per ciascuno dei file condivisi � rappresentata dai propri permessi. Se due utenti che condividono lo stesso valore di ID montano lo stesso filesystem NFS, l'uno sar� in grado di modificare i file dell'altro e viceversa. Inoltre, chiunque si colleghi come root sul sistema client p� utilizzare il comando su - per assicurarsi i permessi per accedere a determinati file attraverso la condivisione NFS. Per maggiori informazioni sui conflitti userid e NFS, consultare il capitolo intitolato Gestione degli account e dei Gruppi in Red Hat Enterprise Linux Introduzione al System Administration.
Per default, le access control lists (ACL) sono supportate da NFS sotto Red Hat Enterprise Linux. Non � consigliato disabilitare questa caratteristica. Per maggiori informazioni, consultare il capitolo Network File System (NFS) nella Red Hat Enterprise Linux System Administration Guide.
Il modo di operare per default, quando si esporta un filesystem tramite NFS � il root squashing che imposta l'ID utente di chiunque acceda alla condivisione NFS come utente root sulla propria macchina locale su un valore di un account del server nfsnobody. � altamente sconsigliato disabilitare questa opzione.
Se esportate una condivisione NFS di sola lettura, dovreste usare anche l'opzione all_squash, che attribuisce un user ID dell'utente nfsnobody, a chiunque acceda il vostro file system esportato.
