servidor NFS + cliente: endurecimento recomendado / toques finais

Question

Acabamos de configurar um adorável compartilhamento / cliente nfs pela primeira vez.

a) O UID para arquivos no lado do cliente, está aparecendo como 4294967294 quando listado via ls, mas o cliente é capaz de criar e remover arquivos / dirs no compartilhamento. Arquivos e pastas criadas no final do cliente, aparecem com o nome de usuário (e uid) correto no lado do servidor. Nós nos certificamos de que os usuários que estão escrevendo para o compartilhamento tenham o mesmo UID no servidor.

O seguinte aparece para todos os arquivos / pastas no lado do cliente:

drwxr-xr-x 6 4294967294 4294967294 4096 Feb 23 16:04 foldername

Está tudo bem?

b) Alguma coisa precisa ser feita com os daemons portmap / nfs para desabilitar completamente qualquer serviço nfs (ou rpc *, como não foi instalado antes disto) da execução em nossa interface externa? Idealmente, gostaríamos de vincular os serviços apenas às nossas sub-redes lan e vpn.

c) Qual é a maneira ideal de tornar o lado do cliente do nfs o mais agressivo possível em tentativas de reconexão? Idealmente, se a conexão de rede for perdida a qualquer momento, o lado do cliente do nfs continuará tentando com freqüência e indefinidamente. É possível realizar isso via fstab? Ou o cliente nfs, por padrão, já faz isso? O lado da LAN, onde os compartilhamentos nfs são compartilhados, é uma conexão de 1GBit.

d) Mais alguma coisa?

Mais e mais.

    

Answer 1

Estou apenas respondendo a pergunta de segurança aqui, já que é com isso que tenho mais experiência.

O NFS é complicado de proteger. A coisa mais importante que eu poderia recomendar é usar o NFS4 com mecanismos de autenticação do GSS, mas continuarei respondendo como se você estivesse usando o NFS3 (ou mesmo o NFS2).

• Especifique IPs, nomes de host ou netgroups no seu arquivo de exportações. Nunca exporte para * , pois isso permite que qualquer pessoa acesse seu compartilhamento em qualquer lugar.
• Nunca use as opções insecure ou no_root_squash export. secure mantém a confiança do servidor limitada à raiz no cliente, não apenas a qualquer usuário, e root_squash remapeia solicitações por raiz para nobody , impedindo o acesso a arquivos confidenciais do sistema por meio do compartilhamento.
• Como você já está tentando fazer, não permita o acesso ao portmapper, rpc.nfsd ou rpc.mountd da Internet. Uma boa configuração de rede (firewalls, ACLs de roteador, etc.) garantirá isso, mas a opção -i para portmap e o uso do arquivo hosts.allow para limitar o acesso a IPs locais também são boas ideias.

Se você quiser testar sua configuração para problemas de segurança, escrevi um programa em Python para contornar os mecanismos básicos de segurança do NFS, NfSpy . Sinta-se à vontade para experimentar e ver se você pode acessar sua exportação de maneiras que você não esperava.

P.S. Em relação às tentativas de reconexão do cliente, consulte a seção MOUNT OPTIONS da página man do nfs (5). Em geral, as opções retrans e hard / soft controlam o que você deseja, mas por solicitação. A montagem em si permanecerá ativa mesmo se o servidor ficar inoperante por longos períodos. Essas configurações determinam como as solicitações específicas (leitura, gravação, etc.) são tratadas.

    

Answer 2

Este é um tópico muito amplo, e nada que possa ser respondido rapidamente com um único post. Eu acho que você deve começar lendo alguns dos muitos guias sobre hardening e melhores práticas para servidores e clientes NFS.

Eu fiz uma busca rápida no google e encontrei dois links que podem interessar a você:

Protegendo o NFS

Linux NFS-HOWTO

(Contém as práticas recomendadas e muitas outras boas informações sobre segurança e ajustes)