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

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?

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.

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.

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.

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

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?

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.

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.

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.