Exportação NFS fixada a um endereço VPN: o que isso não prova

Um host exporta um diretório para um endereço VPN, a montagem funciona e o projeto fica registrado como autenticado. O que essa regra realmente restringe é de onde os pacotes parecem vir. Se a pessoa que conduz a operação de arquivo é quem diz ser depende do perfil de segurança do NFS, e na maioria das exportações deste tipo ninguém o alterou em relação ao padrão.

Três identidades podem aparecer em uma única solicitação

O par de VPN carrega uma identidade inscrita, como um certificado de cliente ou uma chave de par. O pacote IP interno carrega um endereço de origem. A operação de arquivo carrega as credenciais de usuário que o seu mecanismo NFS fornecer. Um projeto que trata o endereço como substituto das três assumiu silenciosamente justamente a parte que deveria verificar.

Escrever essas três linhas é todo o exercício. A maior parte da discussão sobre se uma exportação é segura desmorona quando fica claro em qual linha vive cada controle.

A propriedade do endereço é um detalhe de implementação

Um gateway pode atribuir um endereço de túnel a um par aceito ou autorizar uma sub-rede roteada para ele. Se a implementação depois recusa um pacote cuja origem interna pertence a outro cliente é uma propriedade dessa implementação, e vale a pena verificar em vez de supor.

O código de servidor em espaço de usuário do Community tradicional OpenVPN pode, por exemplo, rejeitar uma origem associada a outro cliente antes de o pacote ser entregue pelo dispositivo TUN. Isso é uma verificação de propriedade de endereço com valor real, e ainda não é autenticação de usuário NFS, porque não diz nada sobre qual conta realiza a operação.

A tradução de origem corrói até isso. Um gateway NAT pode apresentar cada cliente como um único endereço, e então uma regra de exportação não consegue distinguir as pessoas por trás dele. A precisão aparente da regra torna-se então uma ficção mantida pelo diagrama. Se a exportação importa, mantenha o endereçamento explícito em vez de deixar um tradutor decidir quem conta como quem.

Leia o perfil de segurança antes de confiar na exportação

O guia de NFS da Red Hat separa sec=sys, que usa UID e GID UNIX locais via AUTH_SYS, dos modos Kerberos. krb5 acrescenta autenticação de usuário, krb5i acrescenta proteção de integridade e krb5p acrescenta proteção de privacidade para o tráfego.

A credencial AUTH_SYS contém campos como o UID do chamador e identificadores de grupo, e a RFC 5531 avisa claramente que este perfil não fornece segurança por si só e depende de proteção externa. Executá-lo dentro de uma VPN fornece proteção para o transporte e não muda nada na afirmação dentro do pacote.

exportfs -v
showmount -e nfs.example.internal

Leia o perfil nessa saída antes de ler a lista de clientes. Uma exportação que parece restrita pode estar restrita apenas por endereço enquanto cada chamador ainda declara o UID que quiser.

Escolha o modelo e depois mantenha as permissões

Escolha o modelo de autenticação do serviço de arquivos adequado aos clientes que você realmente administra. O Kerberos exige uma identidade e uma implantação de serviço por trás, então mudar uma opção de montagem não é uma migração e simplesmente falhará até que existam o domínio Kerberos, os principais e os keytabs.

Em qualquer dos modelos, mantenha as permissões de exportação e a autorização do sistema de arquivos que limitam o que o principal autenticado pode fazer. A autenticação diz quem está perguntando; a autorização decide se a resposta deve ser sim. Fundir as duas em uma única configuração é como uma migração acaba concedendo mais do que a configuração antiga.

Use a regra de endereço para o seu propósito real

Restringir o serviço ao caminho e às fontes aprovadas continua valendo, incluindo a política de entrada do host quando o ponto de extremidade da VPN e o servidor NFS compartilham a máquina. Regras que encaminham tráfego não governam as solicitações dirigidas a um serviço executado localmente no mesmo host. Essa lacuna explica um número surpreendente de exportações que deveriam ser privadas. Verifique explicitamente a política de entrada local em vez de supor que as regras do túnel a cobrem.

Verifique que outra interface ou um gateway com tradução de origem não possa satisfazer a regra inesperadamente, e trate isso como motivo para estabelecer a procedência, não como a afirmação de que falsificar um endereço garante uma montagem funcional.

Execute três casos de aceitação em vez de um. Comece com um cliente aprovado atuando como usuário aprovado, repita depois a partir de um par que nunca foi aprovado e então tente algo que o usuário aprovado ainda não pode fazer. Pergunte depois o que muda se um cliente autorizado for comprometido, porque a autenticação de transporte não torna confiável cada processo naquela máquina. Um certificado roubado e uma conta local curiosa são problemas diferentes com controles diferentes.