NFS è uno strumento molto utile ma, storicamente, ha sempre sofferto di molte limitazioni, la maggior parte delle quali sono state affrontate con la versione 4 del protocollo. Lo svantaggio è che l'ultima versione di NFS è più difficile da configurare quando si desidera fare uso di funzionalità di sicurezza di base come l'autenticazione e la crittografia di dati che si basa su Kerberos. E senza quelle, il protocollo NFS deve essere limitato a una rete locale fidata (trusted) in quanto i dati passano attraverso la rete in chiaro (una sniffer può intercettarli) ed i diritti di accesso sono concessi in base all'indirizzo IP del client (che può essere falsificato).
11.4.1. Mettere in sicurezza NFS
Se non si utilizzano le funzioni di sicurezza basate su Kerberos, è vitale assicurarsi che solo le macchine autorizzate all'uso di NFS possano connettersi ai vari server RPC richiesti, in quanto il protocollo di base si fida dei dati ricevuti dalla rete. Il firewall deve inoltre bloccare l'IP spoofing per prevenire che macchine esterne possano agire come una interna, e limitare l'accesso alle porte appropriate alle solo macchine che devono accedere alle condivisioni NFS.
Le vecchie versioni del protocollo richiedono altri servizi RPC che usano porte assegnate dinamicamente. Fortunatamente, con NFS versione 4, sono necessarie solo porta 2049 (per NFS) e 111 (per il portmapper) e sono quindi facili da filtrare sul firewall.
Il server NFS è parte del kernel Linux: nei kernel forniti da Debian è compilato come modulo. Se il server NFS è eseguito automaticamente all'avvio il pacchetto nfs-kernel-server dev'essere installato poiché contiene gli script di avvio necessari.
The NFS server configuration file(s), /etc/exports
and /etc/exports.d/
, lists the directories that are made available over the network (exported). For each NFS share, only the given list of machines is granted access. More fine-grained access control can be obtained with a few options. The syntax for this file is quite simple:
/directory/da/condividere macchina1(opzione1,opzione2,...) macchina2(...) ...
Si noti che con NFSv4, tutte le directory esportate devono essere parte di un unica gerarchia e che la directory radice di quella gerarchia deve essere esportata e identificata con l'opzione fsid=0
oppure fsid=root
.
Ogni macchina può essere identificata sia dal suo nome DNS che dal suo IP. È anche possibile specificare un intero insieme di macchine utilizzando una sintassi come *.falcot.com
o un intervallo di indirizzi IP come 192.168.0.0/255.255.255.0
o 192.168.0.0/24
.
Le directory sono rese disponibili in sola lettura in via predefinita (o con l'opzione ro
). L'opzione rw
permette l'accesso in lettura e scrittura. I client NFS si connettono tipicamente da una porta riservata a root (in altre parole inferiore a 1024): questa restrizione può essere sospesa con l'opzione insecure
(l'opzione secure
è implicita ma può essere resa esplicita, se necessario, per rendere le cose più chiare).
Per impostazione predefinita il server risponde ad una richiesta NFS unicamente quando l'operazione corrente sul disco è completata (opzione sync
); questo comportamento può essere disabilitato con l'opzione async
. La scrittura asincrona può aumentare un po' le prestazioni, ma diminuisce l'affidabilità poiché c'è il rischio di perdere dati nel caso in cui il server subisca un crash tra la conferma di scrittura e la reale scrittura sul disco. Poiché il valore predefinito è cambiato recentemente (rispetto al valore storico di NFS), si raccomanda di rendere esplicita questa impostazione.
In order to not give root access to the filesystem to any NFS client, all queries appearing to come from a root user are considered by the server as coming from the nobody
user. This behavior corresponds to the root_squash
option, and is enabled by default. The no_root_squash
option, which disables this behavior, is risky and should only be used in controlled environments. If all users should be mapped to the user nobody
, use all_squash
. The anonuid=uid
and anongid=gid
options allow specifying another fake user to be used instead of UID/GID 65534 (which corresponds to user nobody
and group nogroup
).
Con NFSv4, è possibile aggiungere l'opzione sec
per indicare il livello di protezione desiderato: sec=sys
è l'impostazione predefinita senza particolari caratteristiche di sicurezza, sec=krb5
abilita solo l'autenticazione, sec=krb5i
aggiunge protezione di integrità, e sec=krb5p
è il livello più completo che comprende la tutela della privacy (con crittografia dei dati). Per questo lavoro bisogna lavorare alla configurazione di Kerberos (questo servizio non è coperto da questo libro).
Sono disponibili altre opzioni: sono documentate nella pagina di manuale exports(5).
As with other filesystems, integrating an NFS share into the system hierarchy requires mounting (and the nfs-common package). Since this filesystem has its peculiarities, a few adjustments were required in the syntax of the mount
command and the /etc/fstab
file.
Esempio 11.19. Montare manualmente con il comando mount
#
mount -t nfs4 -o rw,nosuid arrakis.internal.falcot.com:/shared /srv/shared
Esempio 11.20. Condivisione NFS nel file /etc/fstab
arrakis.internal.falcot.com:/shared /srv/shared nfs4 rw,nosuid 0 0
The entry described above mounts, at system startup, the NFS directory /shared/
from the arrakis
server into the local /srv/shared/
directory. Read-write access is requested (hence the rw
parameter). The nosuid
option is a protection measure that wipes any setuid
or setgid
bit from programs stored on the share. If the NFS share is only meant to store documents, another recommended option is noexec
, which prevents executing programs stored on the share. Note that on the server, the shared
directory is below the NFSv4 root export (for example /export/shared
), it is not a top-level directory.
La pagina di manuale nfs(5) descrive tutte le opzioni dettagliatamente.