Recentemente, um de nossos clientes realizou uma auditoria de rede de TI de outra empresa de auditoria de TI (terceira). Os resultados foram geralmente bons, embora tenham apontado que havíamos usado o cliente iSCSI no Windows Server como meio de conexão ao NAS, em vez de criar um compartilhamento SMB no NAS. Eles sugeriram que isso era uma má ideia:
"Há [também] um risco de segurança com ataques iSCSI e Ransomware, onde a criptografia ilícita pode ser realizada no disco iSCSI, deixando os dados ilegíveis. Do ponto de vista da segurança, é aconselhável retirar este método de compartilhamento de dados e adotar uma abordagem de compartilhamento."
O que eles querem dizer com isso? Está se referindo ao fato de que o iSCSI opera em uma camada OSI inferior (sessão) do que o SMB (aplicativo), e um disco iSCSI se apresenta à camada de aplicativo da mesma maneira que um disco conectado localmente, portanto, mais fácil de comprometer?
Se sim, isso está correto?
Não sou um especialista em segurança forense, embora nosso trabalho seja frequentemente de natureza forense. Meu entendimento é que o ransomware tem a mesma probabilidade de atacar dados em um compartilhamento SMB acessível a uma determinada máquina Win, assim como atacaria um disco iSCSI.
Meu entendimento está correto ou perdi alguma coisa?
Contexto adicional para a pergunta
A senha CHAP está definida no servidor iSCSI, então presumo que o que eles estão dizendo esteja relacionado a um comprometimento do servidor Win que possui o cliente iSCSI instalado.
Apenas um cliente iSCSI está conectado e uma "higiene cibernética" muito forte é adotada para garantir que essa senha não seja inserida em nenhum outro momento em nenhum outro servidor ou máquina dentro ou fora da rede.
Geralmente, nossa preferência é usar o iSCSI para disponibilizar discos NAS para o Windows Server. Descobrimos que quando o Windows cuida do sistema de arquivos, não temos problemas com entradas de controle de acesso avançado (ACEs) na DACL. Por exemplo, a implementação da QNAP apresentou erros no passado em relação aos pedidos do ACE, o que pode ser problemático. Também encontramos um bug na configuração de CONTAINER_INHERIT_ACE em objetos filhos (comunicado à QNAP, mas até hoje nunca resolvido). Este ponto não é estritamente relevante para esta questão, mas fornece algum contexto sobre por que preferimos o iSCSI.
Ao contrário do meu ponto acima, no caso deste cliente específico, o disco anexado iSCSI em questão é formatado com ReFS, porque é usado como armazenamento de backup da Veeam. Embora não seja tecnicamente necessário, a Veeam recomenda o uso de ReFS em vez de NTFS por motivos de desempenho, por isso tendemos a preferir esta opção. (Aqui está um bom artigoexplicando ReFS vs NTFS para backup.) Esses ganhos só serão possíveis se usarmos iSCSI, não se movermos o NAS para SMB.
Já li um pouco sobre esse assunto e não consegui encontrar nenhuma evidência de que o iSCSI esteja mais sujeito a ransomware do que à conexão por meio de um compartilhamento de rede, mas continuo com a mente aberta.
Responder1
Qualquer disco gravável online pode ser corrompido por um software ou usuário malicioso. Subestimá-los presumindo que não conseguem encontrar um compartilhamento de arquivo é um erro.
A última linha de defesa para dados importantes é sempretestado, backups offline frios. E neste caso, os dados importantes podem incluir os próprios backups! Pense nas maneiras possíveis de impossibilitar a alteração dos arquivos de backup. Mídia removível (fita), armazenamento em nuvem imutável com credenciais usadas apenas para backup, dedique o NAS para backup e não conecte mais nada, faça firewall em tudo, exceto nas portas do software de backup, desative o compartilhamento de arquivos.
Outro controle é permitir a listagem de software, restringindo significativamente a execução de coisas desconhecidas.
O contexto que você forneceu indica que você pensou sobre isso, explicar o uso do protocolo é bom. Pense em um nível um pouco mais alto do que esta pergunta e inclua na resposta quais proteções existem no plano de continuidade de negócios.
- Quando foi realizado o último teste de restauração de backup. Ele atendeu aos objetivos de ponto de recuperação e tempo de recuperação?
- Alguém provou que os backups frios não estão online e são vulneráveis, como por meio de um exercício da equipe vermelha?
- Quando foi a última vez que você teve problemas com ransomware e o que foi feito para melhorar os controles técnicos ou de processo?
Responder2
Deixando de lado a questão da vulnerabilidade do iSCSI ao usá-lo sem um sistema de arquivos em cluster, mas com vários iniciadores, dificilmente consigo encontrar qualquer razão clara pela qual o protocolo de compartilhamento de arquivos seria mais seguro em termos de ransomware em comparação ao iSCSI. Você obtém CHAP para fortalecer a autenticação e IPSec para proteger a transferência de dados pela rede. Aqui está uma boa leitura geral do porquê do iSCSI:https://www.starwindsoftware.com/blog/complete-an-infrastructure-project-for-your-organization-with-iscsi-san
Caso contrário, é mais uma questão de segurança geral do servidor de backup, como separá-lo do ambiente de produção principal, fora do domínio e com uma conta separada (não administrador do domínio) e assim por diante. De qualquer forma, se você conseguir levar o ransomware para o servidor de backup, não fará muita diferença se você estiver usando, por exemplo, o compartilhamento SMB como repositório de backup (https://helpcenter.veeam.com/docs/backup/vsphere/smb_share.html?ver=100) ou um armazenamento iSCSI.
Responder3
Sim, qualquer protocolo de acesso a dados de rede em nível de arquivo é MAIS SEGURO em comparação ao bloco (iSCSI, FC, FCoE etc) devido à incapacidade de danificar o volume com "redirecionador de rede", o que é super fácil de fazer com um cluster configurado incorretamente ou qualquer sistema de arquivos local (EXT3/4, ReFS, XFS etc.). Toda a história é bem abordada aqui:
https://forums.starwindsoftware.com/viewtopic.php?f=5&t=1392