Sistemas de arquivos de rede seguros para Linux: o que as pessoas estão fazendo?

26

O NFSv3 é generalizado, mas o modelo de segurança padrão é ... singular . O CIFS pode usar a autenticação Kerberos, mas sem a semântica do POSIX, não é de partida. O AFS nunca criptografou o tráfego no fio e é krb4 - e basicamente um projeto morto. Novos sistemas de arquivos experimentais sofisticados nunca se materializam ou se concentram na velocidade (e, se tiver sorte, na confiabilidade dos dados) - por exemplo, o Luster usa o mesmo modelo de confiança do cliente que o NFSv3. Para uso doméstico, o sshfs é bacana, mas com certeza não aumenta.

E, claro, há o NFSv4, com sec = krb5p. Ótimo em teoria, mas depois de dez anos, parece incomodamente não utilizado no mundo real. O cliente Linux acabou de remover a tag experimental. E se você olhar para o EMC Celerra, Isilon etc., é tudo NFSv3. (O Celerra suporta NFSv4, mas está realmente oculto na documentação. O Isilon aparentemente trabalhou para adicionar o suporte RPCGSS ao FreeBSD, então talvez esteja chegando, mas não está lá agora.) Não consigo nem marcar esse post como "nfsv4" porque sou novo aqui e isso seria uma nova tag .

Então realmente . O que vocês estão fazendo?

mattdm
fonte
Eu gostaria de dizer "NFS3 sobre IPSEC", mas não posso.
sysadmin1138
1
O "NFS3 sobre IPSEC" ajuda com o problema on-the-wire, mas não trata de outro problema fundamental do NFS: se uma caixa de cliente fica enraizada ou se você estiver em um ambiente em que os usuários se enraízam em seus próprios sistemas, eles pode personificar trivialmente qualquer usuário remoto.
mattdm
Aí está, nova tag;)
Cry Havok
1
AFAIK, Kerberos foi definido para NFS
Javier
2
Não tenho tanta certeza sobre a necessidade de criptografar o tráfego na conexão em um ambiente de LAN (a autenticação deve ser criptografada). Você deve monitorar para o envenenamento ARP de qualquer maneira ...
Hubert Kario

Respostas:

8

Como é uma pergunta específica (o que vocês estão fazendo), vamos responder: nada. A maioria dos administradores e usuários não se preocupa com a segurança do NFS; portanto, todo mundo usa o NFSv3. Normalmente, é um ambiente controlado (no sentido em que apenas máquinas conhecidas podem se conectar à rede em primeiro lugar). Se alguém for pego abusando da infraestrutura, será demitido ou preso.

Para dados que você realmente não quer que ninguém possa ler, você os criptografa explicitamente, por exemplo, bancos de dados de senhas do Firefox, chaves ssh ou chaves pgp. Você faz isso porque sabe que o administrador poderia lê-los no servidor de arquivos, portanto a segurança do sistema de arquivos da rede não ajudaria em nada.

Martin v. Löwis
fonte
14

Você parece estar fazendo duas perguntas aqui:

O que estamos realmente usando? e o que isso faz?

O que eu estou usando realmente é CIFS, em meus casos de uso POSIX é menos importante para que eu não tive nenhum problema. O NFS3 é usado em áreas onde a segurança não é importante, como meu servidor de instalação SLES. E, finalmente, sshfs / gvfs para compartilhamento simples da terra do usuário. A criptografia com fio não é considerada necessária, portanto isso não é um fator significativo para nós.

Quanto à outra pergunta, parece haver seis requisitos principais para o que você está procurando:

  1. Criptografa o tráfego no fio.
  2. Criptografa a autenticação.
  3. Semântica de Posix.
  4. Forte aplicação de ACLs baseadas em servidor.
  5. Não é usuário.
  6. É realmente usado.

Eu suspeito que os pontos 5 e 6 serão os assassinos aqui, mas aqui vai (também, este é o ponto em que uma tabela seria realmente útil, mas o markdown / StackExchange não a suporta).

NFSv3 + IPSec

  1. Criptografado no fio, passe
  2. Nenhuma autenticação criptografada, falha
  3. Semântica Posix, passe
  4. Nenhuma aplicação forte de ACLs baseadas em servidor, falha
  5. Não é usuário, passe
  6. É realmente usado, passe

NFSv4 + Krb + IPSec

  1. Criptografado no fio, passe
  2. Autenticação criptografada, passe
  3. Semântica Posix, passe
  4. Imposição forte de ACLs baseadas em servidor, aprovação
  5. Não é usuário, passe
  6. Na verdade, não é usado, falha

CIFS

  1. Não criptografado no fio, falha
  2. Autenticação criptografada
  3. Semântica Posix, passe (Samba e Kernel agora, o Windows tem uma camada Posix desde os dias do NT)
  4. Imposição forte de ACLs baseadas em servidor, aprovação
  5. Não é usuário, passe
  6. É realmente usado, passe

CIFS + IPSec

  1. Criptografado no fio, passe
  2. Autenticação criptografada
  3. Semântica Posix, passe (Samba e Kernel agora)
  4. Imposição forte de ACLs baseadas em servidor, aprovação
  5. Não é usuário, passe
  6. Na verdade, não é usado, falha

SSHFS

  1. Criptografado no fio, passe
  2. Autenticação criptografada, passe
  3. Semântica Posix, passe
  4. Imposição forte de ACLs baseadas em servidor, aprovação
  5. O usuário está com falha
  6. É realmente usado, passe

AFP / NetATalk

  1. Criptografado no fio, falha
  2. Autenticação criptografada, passe
  3. Semântica Posix, passe
  4. Imposição forte de ACLs baseadas em servidor, aprovação
  5. Não é usuário, passe
  6. É realmente usado, falha

E não estou mexendo nos sistemas de arquivos distribuídos por aí. Simplesmente não existe uma coisa que faça tudo. Alguns chegam perto (CIFS) e outros já estão lá, mas ninguém os usa (NFS4 + IPSec, CIFS + IPSec). Por alguma razão, um sistema de arquivos de rede seguro é algo que foi submetido a muitos compromissos ao longo dos anos.

sysadmin1138
fonte
Você poderia ter mencionado "NFSv4 + Krb" e adicionado "7. É razoavelmente rápido (ou seja, comparado à mesma pilha de protocolos sem criptografia)?" como uma pergunta. O que provavelmente seria uma falha para o NFSv4 + krb5p, mas passe para as perguntas 1 a 6.
al.
pode haver tempo para um novo SNFS de sistema de arquivos de rede seguro?
The Unix Janitor
@ user37899 O problema, como sempre, é convencer os fornecedores de dispositivos a suportá-lo e as organizações a implantá-lo.
sysadmin1138
1
Tivemos muita má sorte ao tentar usar o CIFS no modo POSIX. Talvez seja hora de revisitar isso.
mattdm
FWIW Estou usando CIFS + IPsec, mas não com semântica POSIX. servidor é emc celerra, clientes win7. túneis ipsec feitos no modo lan-to-lan entre o Cisco ASA (próximo ao celerra) e o ipsec embutido no win7.
Dan Pritts
3

Eu uso openafs em produção há anos, com clientes Linux e Windows. Ele funciona muito bem, tem uma comunidade de desenvolvimento ativa e ficou muito mais fácil de instalar e administrar nos últimos anos, pois as várias distribuições linux incluíram o empacotamento. Ele tem suas verrugas, mas descobri que elas são compensadas por mais flexibilidade administrativa, capacidade de separar clientes e servidores por links lentos, facilidade de backups externos e outros AFSismos positivos.

Uma coisa que eu gosto em particular é executar servidores Web de produção voltados para a Internet em openafs, com as ACLs bloqueadas. Sem um tíquete do kerberos, não há processo na máquina - mesmo um sendo executado como root - que possa gravar no sistema de arquivos. Não sei contar quantas vezes notamos que os ataques falham por causa dessa medida simples.

Existem alguns usuários openafs bastante grandes - o maior usuário comercial que conheço é o Morgan Stanley.

stevegt
fonte
1

Que tal o OpenAFS, que ainda está ativo e uma VPN nele, porque sua única criptografia no momento é DES.

Rob Olmos
fonte
2
Eu usei o OpenAFS na produção. Os rumores de sua vitalidade são muito exagerados.
mattdm
Houve uma nova versão este mês e antes disso houve atualizações bastante regulares para suportar novas versões do Windows e novas versões do kernel do Linux (a versão mais recente suporta o 3.0).
Hubert Kario
1

Vejo que muitas pessoas neste segmento estão falando sobre ocultação de dados, ou seja, ataques que não conseguem bisbilhotar seus dados. É igualmente importante pensar na integridade e autenticidade dos dados. Esses pacotes nfs são realmente do seu servidor nfs? Um pacote nfs foi alterado em trânsito?

O zelador do Unix
fonte
O NFS sobre IPsec cuida disso (em links de área ampla) e o monitoramento de envenenamento por ARP faz isso na LAN
Hubert Kario
alguém está realmente usando IPsec com sucesso?
The Unix Janitor
1

Bem, para mim parece que um desses sistemas de arquivos distribuídos seria para você. Eu não gostaria de recomendar o OpenAFS, pois é antigo, ainda não suporta IPv6.

Estou muito feliz com o GlusterFS . O Gluster é bem maduro, funciona bem e possui um bom conjunto de recursos. No entanto, como discutido recentemente no IRC, o Gluster também não suporta IPv6 de maneira estável. Este recurso será agendado para 3.6 ou 3.7.

Há também um projeto chamado HekaFS, baseado no Gluster, que adiciona recursos de autenticação mais avançados e SSL. É extremamente bem documentado e muito bem projetado.

O que também pode lhe interessar é o XtreemFS , projetado para computação em grade global, por isso vem com SSL e outras coisas por padrão. Minha escolha pelo uso recaiu sobre o Gluster, já que a comunidade parece mais ativa e muito melhor documentada.

Ambos são compatíveis com posix, é claro.

juwi
fonte
0

Eu uso o NFS. Mas o NFS de servidor para servidor é feito em um backbone de rede dedicado, portanto, a criptografia não é necessária e a autenticação é meio inútil. Basta definir cada exportação para compartilhar apenas um diretório selecionado em um servidor com base no IP.

Varanda
fonte
rede dedicada, até que alguém conecte o switch ao rack com o wireshark.
The Unix Janitor
Esse é um problema de segurança física então. Uma vez que eles estão na mesma sala dos servidores, o jogo acaba assim mesmo.
Porch
-2

Com todo o respeito, você está olhando completamente para esse problema da maneira errada e deve se afastar do console por algumas horas.

Praticamente todo o armazenamento io não é criptografado porque não importa nessa camada da pilha de abstração. Duvido? Dê um toque no seu switch de fibra de brocado e você verá que o canal de fibra, como iscsi e nfs, é tudo uma bagunça não criptografada - por design. Resolver um problema médio, não um protocolo de armazenamento. Por exemplo, deseja nfs seguros e criptografados? Criou uma LAN criptografada ponto a ponto entre o cliente e o servidor nfs usando ipsec / ssl / tls ou uma solução de hardware puro.

Rafael Ferreira
fonte
Acho que você está perdendo um ponto-chave. Como a pergunta diz, o problema está no modelo de segurança NFS. Embora a criptografia seja boa, é, como você diz, um problema solucionável. O grande problema do NFS é que, uma vez que um sistema de arquivos é montado em um sistema, qualquer pessoa com acesso root nesse sistema pode acessar qualquer arquivo desse sistema, independentemente da propriedade ou das permissões. Um sistema como o AFS ou, em teoria, o NFSv4 com sec = krbp5, exige fortes credenciais para acessar arquivos e, portanto, representa um aumento substancial na segurança. Um cliente NFS raiz não equivale a uma exposição massiva de dados.
Larsks #
1
A menos que você solicite ao usuário que insira credenciais para cada acesso, as credenciais serão armazenadas. É provável que um cliente comprometido pela raiz desista facilmente da chave armazenada. Qualquer sistema de arquivos em rede aumentará a exposição do sistema de arquivos a comprometer-se.
BillThor
@ BillThor Era isso que eu estava pensando. Ainda está aberto ao ataque se as credenciais estiverem na memória do kernel? Eu acho que um módulo do kernel pode ser carregado para ler qualquer parte da memória do kernel.
Rob Olmos
Desde que a solicitação seja usada no contexto de um usuário com acesso ao armazenamento compartilhado, provavelmente não importa onde estão as credenciais. As credenciais geralmente são mantidas por um processo em segundo plano; portanto, qualquer pessoa que possa se comunicar com ela poderá obter acesso ao armazenamento compartilhado. Eu classificaria o risco de armazenamento em rede seguro aproximadamente o mesmo que armazenamento local.
BillThor
2
@ BillThor: com o kerberos, o risco é significativamente atenuado, pois o atacante só teria acesso aos sistemas de arquivos dos usuários que encaminharam seus tickets e apenas pelo tempo de vida desses tickets. Com a autenticação baseada em sistema (à la nfsv3), o root pode acessar e manipular os arquivos de qualquer usuário, mesmo que esse usuário não tenha nada a ver com o sistema comprometido.
mattdm