Reforçando exports NFS: escopo de rede, opções de squash e sec=krb5 em vez de AUTH_SYS

Objetivo

Reduzir o que um export NFS aceita como verdadeiro por parte dos clientes: quais hosts podem se conectar, qual UID/GID uma requisição pode declarar e se o servidor pode exigir uma prova criptográfica de identidade em vez de acreditar na palavra do cliente.

Pré-requisitos

Um export já existente em /etc/exports. Para a opção com Kerberos, é preciso ter um realm Kerberos funcionando, uma chave nfs/<fqdn> no keytab do servidor, gssproxy (ou o mais antigo rpc.svcgssd) no servidor e rpc.gssd nos clientes; essa configuração está fora do escopo deste artigo.

Passos

1. Nunca exporte para todos os hosts. O exports(5) permite direcionar um export a um único host, a um padrão de nomes ou a uma sub-rede inteira no formato address/netmask; limite cada export à menor rede que realmente precisa dele.
2. Mantenha root_squash (o padrão): a opção mapeia as requisições de uid/gid 0 para o uid/gid anônimo, de modo que um cliente que se declara root não obtém root sobre os arquivos do servidor. Ela não impede que o root do cliente assuma qualquer outro UID e atue como esse usuário. Remova-a (no_root_squash) apenas para um host de administração específico e confiável que realmente precise disso.
3. Em exports nos quais nenhum UID fornecido pelo cliente deve ser considerado confiável — um diretório compartilhado de depósito, por exemplo — use all_squash, para que toda requisição seja mapeada para a conta anônima, independentemente do UID apresentado.
4. Entenda por que isso importa: as considerações de segurança do nfs(5) afirmam que os servidores NFS controlam o acesso aos dados dos arquivos, mas dependem da implementação de RPC para a autenticação, e a implementação tradicional representa cada usuário por um simples número fornecido pelo próprio cliente — o servidor não o verifica de forma independente.
5. Quando os dados justificarem, mude o export e a montagem no cliente para sec=krb5 (apenas autenticação), krb5i (mais integridade) ou krb5p (mais criptografia). O nfs(5) documenta sec= como uma lista separada por dois-pontos de um ou mais tipos (flavors) de segurança a usar no acesso aos arquivos da montagem, sendo krb5, krb5i e krb5p flavors válidos; a linha do export aceita uma opção sec= correspondente para exigi-lo.
6. Reexporte com exportfs -ra e confirme o flavor que o cliente realmente negociou verificando as opções da montagem no cliente (cat /proc/mounts ou nfsstat -m).

Resultado esperado

Montagens vindas de fora da rede configurada são recusadas; um cliente que apresenta UID 0 é mapeado para a conta anônima nos exports com squash; e, quando o export lista apenas flavors sec=krb5*, o acesso sem credenciais Kerberos válidas é recusado (no momento da montagem ou no primeiro acesso), em vez de recorrer a AUTH_SYS.

Limites e base de verificação

O AUTH_SYS concede a cada usuário de cada cliente permitido o acesso que o respectivo UID implica; root_squash trata apenas do root, e all_squash só serve para exports em que não é necessária propriedade de arquivos por usuário. O NFS com Kerberos depende de sincronização de horário correta e de um keytab bem mantido — um KDC com problemas faz as montagens falharem em vez de degradar silenciosamente, portanto teste as mudanças em uma janela de manutenção. Guarde uma cópia do /etc/exports anterior antes de restringi-lo.