O NFS é uma ferramenta muito útil, mas historicamente, ela tem sofrido com muitas limitações, a maioria delas tendo sido atribuídas a versão 4 do protocolo. A contrapartida é que a última versão do NFS é mais difícil de configurar quando você quer usar recursos básicos de segurança tais como autenticação e criptografia já que ele faz uso do Kerberos para esses assuntos. E sem isso, o protocolo NFS tem que ficar restrito a uma rede local confiável já que os dados viajam pela rede sem criptografia (um sniffer pode interceptá-los) e os direitos de acesso são optidos com base no endereço IP do cliente (que pode ser falsificado ("spoofed")).
Se você não usa recursos de segurança baseados no Kerberos, é vital garantir que apenas máquinas com permissão de usar o NFS possam se conectar nos vários servidores RPC requeridos, porque o protocolo básico confia nos dados recebidos a partir da rede. O firewall tem também que bloquear IP spoofing para prevenir que uma máquina de fora atue como uma de dentro, e acesso às portas apropriadas tem que ser restrito às máquinas destinadas a acessar os compartilhamentos NFS.
Versões mais antigas do protocolo necessitavam de outros serviços RPC que usavam portas dinamicamente atribuídas. Felizmente, com a versão 4 do NFS, apenas a porta 2049 (para NFS) e 111 (para o portmapper) são necessárias, e assim, fácil de configurar no firewall.
O servidor NFS é parte do núcleo Linux; nos núcleos fornecidos peloDebian ele é construído como um módulo do núcleo. Se o servidor NFS tem que ser rodado automaticamente na inicialização, o pacote nfs-kernel-server deve ser instalado; ele contém os scripts de inicialização relevantes.
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:
/diretório/para/compartilhar máquina1(opção1,opção2,...) máquina2(...) ...
Note que com o NFSv4, todos os diretórios exportados tem que ser parte de uma única hierarquia e que o diretório raiz dessa hierarquia tem que ser exportado e identificado com a opção fsid=0
ou fsid=root
.
Cada máquina pode ser identificada tanto pelo seu nome no DNS quanto seu endereço IP. Todo um conjunto de máquinas pode também ser especificado usando tanto uma sintaxe como *.falcot.com
ou um intervalo de endereços IP como 192.168.0.0/255.255.255.0
ou 192.168.0.0/24
.
Os diretórios ficam disponíveis apenas para leitura por padrão (ou com a opção ro
). A opção rw
permite o acesso a leitura-escrita. Os clientes NFS tipicamente fazem a conexão a partir de uma porta restrita ao root (em outras palavras, abaixo da 1024); essa restrição pode ser elevada pela opção insecure
(a opção secure
é implícita, mas pode ser explícita para mais clareza).
Por padrão, o servidor apenas responde a uma consulta NFS quando a operação de disco corrente é concluída (opção sync
); isso pode ser desabilitado com a opção async
. A escrita assíncrona aumenta um pouco a performance, mas ela diminui a confiança já que existe o risco de perda de dados no caso do servidor falhar entre comunicar a escrita e realmente escrever no disco. Como o valor padrão foi alterado recentemente (comparado ao valor histórico do NFS), uma configuração explícita é recomendada.
Para que não seja dado acesso de root no sistema de arquivos a nenhum cliente NFS, todas as consultas que parecem vir do usuário root são consideradas pelo servidor como vindo do usuário nobody
. Esse comportamento corresponde à opção root_squash
e é habilitado por padrão. A opção no_root_squash
, que desabilita esse comportamento, é arriscada e só deve ser usada em ambientes controlados. Se todos(as) os(as) usuários(as) devem ser mapeados para o usuário nobody
, use all_squash
. As opções anonuid=uid
e anongid=gid
permitem especificar outro usuário falso a ser usado em vez de UID/GID 65534 (que corresponde ao usuário nobody
e ao grupo nogroup
).
Com o NFSv4, você pode adicionar uma opção sec
para indicar o nível de segurança que você quer: sec=sys
é o padrão, sem recursos especiais de segurança, sec=krb5
habilita apenas a autenticação, sec=krb5i
adiciona proteção de integridade, e sec=krb5p
é o mais completo nível, que inclui proteção de privacidade (com criptografia de dados). Para isso funcionar você precisa do Kerberos configurado e funcionando (esse serviço não é coberto por esse livro).
Outras opções estão disponíveis; elas estão documentadas na página de manual 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.
Exemplo 11.19. Montando manualmente com o comando mount
#
mount -t nfs4 -o rw,nosuid arrakis.internal.falcot.com:/shared /srv/shared
Exemplo 11.20. Entrada NFS no arquivo /etc/fstab
arrakis.internal.falcot.com:/shared /srv/shared nfs4 rw,nosuid 0 0
A entrada descrita acima monta, ao iniciar o sistema, o diretório NFS /shared/
no servidor arrakis
no diretório local /srv/shared/
. O acesso de leitura-escrita é requisitado (visto o parâmetro rw
). A opção nosuid
é uma medida de proteção que apaga qualquer bit setuid
ou setgid
de programas armazenados no compartilhamento. Se o compartilhamento NFS é apenas para armazenar documentos, outra opção recomendada é noexec
, a qual previne a execução de programas armazenados no compartilhamento. Note que no servidor, o diretório shared
está abaixo da raiz NFSv4 exportada ( por exemplo, /export/shared
), não é um diretório de nível mais alto.
A página de manual nfs(5) descreve todas as opções com alguns detalhes.