O fim do LUN masking: bloqueando spoofing em NVMe/TCP com DH-HMAC-CHAP
Descubra por que o LUN masking tradicional não protege sua SAN NVMe/TCP contra spoofing de NQN e aprenda a implementar a autenticação mútua DH-HMAC-CHAP.
A transição do Fibre Channel isolado para o NVMe/TCP trouxe um ganho de performance absurdo para os datacenters modernos. Nós pegamos o protocolo de armazenamento mais rápido do mundo e o colocamos para rodar sobre a rede Ethernet padrão. O problema é que, ao fazer isso, muitos administradores trouxeram junto as práticas de segurança da década de 1990.
O LUN masking, aquela velha prática de esconder volumes de armazenamento baseada no identificador do servidor, é o equivalente digital a uma placa de "Por favor, não pise na grama". Funciona muito bem contra acidentes, mas é completamente inútil contra um invasor motivado. Se você está rodando NVMe over Fabrics (NVMe-oF) em redes TCP e confiando apenas em identificadores de host para proteger seus dados, sua infraestrutura está a um script de distância de um vazamento massivo.
Resumo em 30 segundos
- LUN masking e NQNs não são mecanismos de segurança, são apenas filtros administrativos para evitar corrupção acidental de dados.
- Falsificar um NQN em uma rede NVMe/TCP exige apenas privilégios básicos de root em um servidor comprometido para sequestrar volumes inteiros.
- A autenticação mútua com DH-HMAC-CHAP impede o sequestro de dados garantindo identidade criptográfica na camada de transporte.
A ilusão da segurança baseada em nomes qualificados do NVMe
No ecossistema NVMe, cada host e cada subsistema de armazenamento possui um identificador único chamado NVMe Qualified Name (NQN). Ele é o equivalente moderno do WWN no Fibre Channel ou do IQN no iSCSI. Quando um servidor tenta se conectar a um storage array, ele apresenta seu NQN. O storage, por sua vez, consulta uma lista de controle de acesso e decide se aquele NQN tem permissão para enxergar e montar determinados namespaces (volumes).
Isso é o que a indústria chama de LUN masking. O problema fundamental aqui é a confiança cega. O storage array acredita que o servidor é quem diz ser, simplesmente porque ele apresentou um nome em formato de texto. Não há desafio criptográfico. Não há prova de identidade.
Em uma rede Fibre Channel tradicional, essa abordagem sobrevivia porque a rede física era isolada (air-gapped). Para falsificar um WWN, o invasor precisava de acesso físico aos switches SAN. No NVMe/TCP, o tráfego de armazenamento trafega na mesma infraestrutura Ethernet que o resto do seu datacenter. A barreira física desapareceu.
Como um invasor clona identificadores para sequestrar volumes de bloco
Imagine que um invasor conseguiu explorar uma vulnerabilidade em um servidor web de front-end que possui acesso à rede de armazenamento via NVMe/TCP. O objetivo dele não é o servidor web, mas sim o banco de dados financeiro que reside em outro servidor físico.
O invasor sabe que o storage array usa LUN masking baseado em NQN. Tudo o que ele precisa fazer é descobrir o NQN do servidor de banco de dados. Isso pode ser feito através de enumeração de rede, vazamento de configurações ou acessando repositórios de infraestrutura como código (IaC) mal protegidos.
⚠️ Perigo: Alterar um NQN em um sistema Linux moderno é trivial. O invasor só precisa editar o arquivo
/etc/nvme/hostnqn, reiniciar o serviço de descoberta do NVMe e apontar a conexão para o IP do storage array.
O storage array recebe a requisição de conexão vinda do servidor web comprometido, lê o NQN falsificado do banco de dados e entrega o volume de bloco inteiro. O invasor agora tem acesso direto aos blocos do disco, ignorando completamente as permissões do banco de dados, firewalls de aplicação e controles de acesso do sistema operacional original. Ele pode copiar os dados silenciosamente ou criptografar o volume para um ataque de ransomware.
Figura: Diagrama ilustrando um ataque de spoofing de NQN onde um servidor comprometido clona o identificador legítimo para acessar volumes de dados.
Por que segmentação de VLAN e LUN masking falham na camada de transporte
A resposta padrão de muitas equipes de infraestrutura para esse risco é a segmentação de rede. Colocar o tráfego NVMe/TCP em uma VLAN dedicada e isolada. A segmentação é uma excelente prática de higiene de rede, mas não é uma fronteira de segurança impenetrável.
Ataques de VLAN hopping, configurações incorretas de portas trunk e comprometimento de hypervisors podem colocar um invasor diretamente na sua rede de armazenamento. Uma vez dentro da VLAN de storage, a rede é plana. Se o seu único controle de acesso for o LUN masking, o invasor tem passe livre.
O LUN masking foi projetado para evitar que um servidor Windows formate acidentalmente um volume VMFS do VMware. Ele é uma ferramenta de conveniência operacional. Tratar LUN masking como segurança é o mesmo que usar um crachá de papel impresso em casa para tentar entrar em um cofre de banco. Precisamos de criptografia na camada de transporte.
Implementando autenticação mútua com DH-HMAC-CHAP no NVMe-oF
A especificação base do NVMe resolveu esse problema introduzindo um protocolo de autenticação robusto (in-band) chamado DH-HMAC-CHAP. Se você quer segurança real em NVMe/TCP, é isso que você precisa habilitar.
Vamos desmembrar a sigla para entender por que ela funciona:
DH (Diffie-Hellman): Permite que o host e o storage array negociem uma chave secreta de sessão através da rede de forma segura, mesmo que alguém esteja interceptando o tráfego.
HMAC (Hash-based Message Authentication Code): Garante a integridade da mensagem, provando que ela não foi alterada em trânsito.
CHAP (Challenge-Handshake Authentication Protocol): O mecanismo de desafio e resposta que prova a identidade sem nunca enviar a senha pela rede.
Diferente do CHAP antigo usado no iSCSI (que era vulnerável a ataques de dicionário offline e sniffing), o DH-HMAC-CHAP utiliza algoritmos de hash modernos como SHA-256 e chaves dinâmicas. Além disso, ele suporta autenticação mútua. O storage array exige que o host prove quem é, e o host exige que o storage array prove que é legítimo. Isso impede que um invasor suba um storage falso na rede para capturar dados gravados pelos servidores.
Comparativo de Controles de Acesso em Storage
| Característica | LUN Masking (NQN) | CHAP Básico (iSCSI legado) | DH-HMAC-CHAP (NVMe-oF) |
|---|---|---|---|
| Mecanismo Base | Filtro de texto simples | Desafio/Resposta estático | Troca de chaves dinâmica |
| Resistência a Spoofing | Nenhuma (Trivial de burlar) | Média (Vulnerável a sniffing) | Alta (Criptografia forte) |
| Autenticação Mútua | Não suportado | Opcional (Raramente usado) | Nativo e Recomendado |
| Proteção contra Replay | Nenhuma | Baixa | Alta (Chaves de sessão únicas) |
| Complexidade Operacional | Baixa | Média | Alta (Exige gestão de chaves) |
Rotação de chaves e isolamento de malha durante um comprometimento
Implementar DH-HMAC-CHAP muda o jogo, mas introduz um novo desafio operacional: a gestão de segredos. Cada host precisa de uma chave criptográfica forte configurada localmente para responder aos desafios do storage array.
Se um invasor obtiver acesso root total a um servidor, ele inevitavelmente conseguirá ler a chave DH-HMAC-CHAP armazenada naquele host. A diferença crucial é o escopo do dano. Com LUN masking, o invasor poderia falsificar o NQN de qualquer outro servidor e acessar todos os volumes da rede. Com DH-HMAC-CHAP, o invasor só tem acesso aos volumes especificamente atrelados àquela chave comprometida. O raio de explosão é contido.
💡 Dica Pro: Não configure chaves DH-HMAC-CHAP manualmente. Utilize ferramentas de automação como Ansible ou Terraform integradas a cofres de senhas (como HashiCorp Vault) para injetar as chaves nos hosts e nos arrays de storage. Isso viabiliza a rotação periódica de chaves sem tempo de inatividade.
Em caso de incidente, a resposta se torna cirúrgica. A equipe de segurança revoga a chave do host comprometido diretamente no storage array. Imediatamente, as sessões NVMe/TCP daquele servidor são derrubadas e o isolamento da malha (fabric isolation) é garantido, protegendo os dados em repouso.
Figura: Fluxo de autenticação mútua do protocolo DH-HMAC-CHAP garantindo a identidade criptográfica entre host e storage.
O veredito da infraestrutura moderna
A adoção do NVMe/TCP está democratizando a performance extrema que antes era exclusiva de redes Fibre Channel caríssimas. No entanto, a conveniência do Ethernet não pode ser uma desculpa para negligenciar a segurança da camada de blocos.
Continuar operando com LUN masking em redes IP é aceitar um risco arquitetônico massivo. A tecnologia para blindar essas conexões já existe e está padronizada. Exija que seus fornecedores de storage e hypervisors suportem DH-HMAC-CHAP de forma nativa e integre a gestão dessas chaves ao seu pipeline de automação. A segurança do seu dado mais crítico começa muito antes do banco de dados, ela começa no bloco.
Referências & Leitura Complementar
NVM Express Base Specification (Revisão 2.0 ou superior): Define os mecanismos de segurança in-band e a implementação técnica do protocolo DH-HMAC-CHAP.
RFC 8639 (NVMe over TCP Transport Protocol): Documentação oficial da IETF sobre o encapsulamento de comandos NVMe sobre redes TCP/IP.
SNIA (Storage Networking Industry Association): Guias de melhores práticas para segurança em redes de armazenamento baseadas em Ethernet.
O que é spoofing de NQN em redes NVMe/TCP?
É um ataque direto e letal onde um servidor malicioso falsifica o NVMe Qualified Name (NQN) de um host legítimo. O objetivo é enganar o storage array para obter acesso não autorizado a volumes de dados (namespaces), contornando os controles básicos de acesso da rede de armazenamento.Por que o LUN masking tradicional não é suficiente para segurança?
Porque o LUN masking atua apenas como um filtro de conveniência para evitar corrupção acidental de dados por administradores, não como uma barreira criptográfica. Ele confia cegamente no identificador (NQN ou IQN) apresentado pelo cliente. Esse identificador é apenas um arquivo de texto que pode ser facilmente alterado via software pelo sistema operacional de qualquer invasor com privilégios básicos.Como o DH-HMAC-CHAP difere do CHAP tradicional usado no iSCSI?
O DH-HMAC-CHAP moderniza a autenticação adicionando a troca de chaves Diffie-Hellman para gerar chaves de sessão dinâmicas e utiliza algoritmos de hash muito mais fortes (como SHA-256). Isso elimina a transmissão de hashes estáticos pela rede, mitigando completamente ataques de interceptação (sniffing) e tentativas de quebra de senhas offline que assombravam o iSCSI legado.
Roberto Esteves
Especialista em Segurança Defensiva
"Com 15 anos de experiência em Blue Team, foco no que realmente impede ataques: segmentação, imutabilidade e MFA. Sem teatro de segurança, apenas defesa real e robusta para infraestruturas críticas."