NFS és una eina molt útil però, històricament, ha sofert moltes limitacions, la majoria de les quals s'han resolt amb la versió 4 del protocol. L'inconvenient és que aquesta última versió d'NFS és més difícil de configurar quan voleu fer ús de les característiques bàsiques de seguretat com l'autenticació i el xifratge ja que es basa en Kerberos per a aquestes parts. I sense aquests, el protocol NFS s'ha de restringir a una xarxa local de confiança, ja que les dades passen per la xarxa sense encriptar (un «sniffer» pot interceptar-les) i els drets d'accés es concedeixen basant-se en l'adreça IP del client (que es pot suplantar).
11.4.1. Seguretat amb NFS
Si no s'utilitzen les característiques de seguretat basades en Kerberos, és vital garantir que només les màquines que poden utilitzar NFS puguin connectar-se als diversos servidors RPC requerits, perquè el protocol bàsic confia en les dades rebudes de la xarxa. El tallafocs també ha de bloquejar l'«IP spoofing» o “suplantació d'ip” per tal d'evitar que una màquina externa actuï com a interna, i l'accés als ports apropiats s'ha de restringir a les màquines destinades a accedir a les comparticions d'NFS.
Les versions anteriors del protocol requerien altres serveis RPC que utilitzaven ports assignats dinàmicament. Afortunadament, amb la versió 4 d'NFS només es necessita el port 2049 (per a NFS) i 111 (per al «portmapper“) i per tant són fàcils d'adaptar a un tallafocs.
El servidor NFS forma part del nucli de Linux; en els nuclis proporcionats per Debian es compila com un mòdul del nucli. Si es vol que el servidor NFS s'executi automàticament en arrencar, s'hauria d'instal·lar el paquet nfs-kernel-server, que conté els scripts d'inici pertinents.
El(s) fitxer(s) de configuració del servidor NFS, /etc/exports i /etc/exports.d/, llisten els directoris que estan disponibles a través de la xarxa (exportats). Per a cada exportació NFS, només es concedeix accés a la llista de màquines donada. Es pot obtenir un control d'accés refinat amb algunes opcions. La sintaxi d'aquest fitxer és bastant simple:
/directori/per/exportar màquina1(opció1,opció2,...) màquina2(...) ...
Tingueu en compte que, amb NFSv4, tots els directoris exportats han de formar part d'una única jerarquia i que el directori arrel d'aquesta jerarquia s'ha d'exportar i identificar amb l'opció fsid=0 o fsid=root.
Cada màquina pot ser identificada pel seu nom DNS o per la seva adreça IP. També es poden especificar conjunts sencers de màquines utilitzant una sintaxi com *.falcot.com o un rang d'adreces IP com 192.168.0.0/255.255.255.0 o 192.168.0.0/24.
Els directoris estan disponibles per defecte com a només lectura (o amb l'opció ro). L'opció rw permet l'accés de lectura i escriptura. Els clients d'NFS normalment es connecten des d'un port restringit a l'usuari «root» (en altres paraules, inferior a 1024); aquesta restricció es pot aixecar amb l'opció insecure (l'opció secure és implícita, però es pot fer explícita, si cal, per claredat).
Per defecte, el servidor només respon a una consulta NFS quan l'operació de disc actual està acabada (opció sync); això es pot desactivar amb l'opcióasync). Les escriptures asíncrones augmenten una mica el rendiment, però disminueixen la fiabilitat, ja que hi ha un risc de pèrdua de dades en cas que el servidor falli entre el reconeixement de l'escriptura i l'escriptura real al disc. Com que el valor per defecte ha canviat recentment (en comparació amb el valor històric d'NFS), es recomana configurar-ho explícitament.
Per tal de no donar accés a l'arrel al sistema de fitxers a cap client NFS, totes les consultes que semblen provenir d'un usuari arrel són considerades pel servidor com a procedents de l'usuari nobody. Aquest comportament correspon a l'opció root_squash, i està activat per defecte. L'opció no_root_squash, que inhabilita aquest comportament, és arriscada i només s'ha d'utilitzar en entorns controlats. Si tots els usuaris han de ser “mapejats” a l'usuari nobody, utilitzeu all_squash. Les opcions anonuid=uid i anongid=gid permeten especificar un altre usuari fals per ser utilitzat en lloc de UID/GID 65534 (que corresponen a l'usuari nobody i al grup nogroup).
Amb NFSv4, es pot afegir una opció sec per indicar el nivell de seguretat que voleu: sec=sys és el valor per defecte sense característiques de seguretat especials, sec=krb5 només activa l'autenticació, sec=krb5i afegeix protecció d'integritat, i sec=krb5p és el nivell més complet que inclou protecció de la privacitat (amb xifratge de dades). Perquè això funcioni cal una configuració funcional de Kerberos (aquest servei no està cobert en aquest llibre).
Hi ha altres opcions disponibles; estan documentades a la pàgina de manual exports(5).
Igual que amb altres sistemes de fitxers, la integració d'una exportació NFS a la jerarquia del sistema requereix un muntatge (i el paquet nfs-common). Com que aquest sistema de fitxers té les seves peculiaritats, es requereixen alguns ajustos a la sintaxi de l'ordre mount i al fitxer /etc/fstab.
Exemple 11.19. Muntatge manual amb l'ordre mount
# mount -t nfs4 -o rw,nosuid arrakis.internal.falcot.com:/shared /srv/shared
Exemple 11.20. Entrada NFS al fitxer /etc/fstab
arrakis.internal.falcot.com:/shared /srv/shared nfs4 rw,nosuid 0 0
L'entrada descrita a dalt munta, a l'engegada del sistema, el directori NFS /shared/ del servidor arrakis al directori local /srv/shared/. Es demana accés de lectura i escriptura (d'aquí el paràmetre rw). L'opció nosuid és una mesura de protecció que elimina qualsevol bit setuid o setgid de programes emmagatzemats al directori muntat. Si el directori NFS només està destinada a emmagatzemar documents, una altra opció recomanada és noexec, que evita executar programes emmagatzemats en l'espai importat. Tingueu en compte que, al servidor, el directori shared està per sota de l'exportació arrel NFSv4 (per exemple /export/shared), no és un directori de nivell superior.
La pàgina del manual nfs(5) descriu totes les opcions amb cert detall.
