Comprometer uma VM dá acesso a uma aplicação. Comprometer o hipervisor dá acesso a todas as VMs, aos backups e ao storage — sem precisar quebrar nenhuma delas individualmente. É o alvo de maior retorno do ambiente inteiro, e costuma receber menos atenção de segurança que o servidor web que roda dentro dele.
Este texto é a sequência de endurecimento do host, em ordem de retorno. Permissões, firewall, autenticação corporativa e certificados têm cada um a sua profundidade e ficam fora daqui — o foco é o sistema por baixo e as portas de entrada que quase ninguém revisa.
O modelo de ameaça, em três caminhos
Antes da lista, vale saber de onde o problema vem. Os caminhos reais até o hipervisor são três:
- Pela rede de gestão, se ela for alcançável de onde não deveria — da internet, da rede de escritório, ou de dentro de uma VM de cliente.
- Por credencial, obtida por vazamento, reuso de senha ou phishing.
- Por escapada de VM, explorando vulnerabilidade do hipervisor ou de dispositivo emulado — raro, e é por isso que atualizar importa.
Cada item abaixo fecha um desses caminhos. O primeiro é, de longe, o mais explorado.
1. A rede de gestão, antes de tudo
Nenhum outro item deste artigo importa se a interface de gestão estiver alcançável de onde não deveria.
O que precisa ser verdade:
- Interface web e SSH em rede dedicada de gestão, separada da rede de VMs, da rede de storage e da rede de cluster.
- Acesso apenas por VPN ou de uma rede de administração restrita. Nunca exposta à internet, com ou sem senha forte.
- Nenhuma VM de cliente ou de aplicação alcança a rede de gestão. Se as VMs estão na mesma bridge dos hosts, isso já é falso.
- Um endereço de gestão por nó, com regra explícita de quem pode chegar nele.
O teste que prova: a partir de uma VM comum, tente alcançar a porta 8006 e a 22 de cada nó. Se responder, você tem o achado mais grave possível e ele precisa ser corrigido antes de qualquer outra coisa.
2. O BMC: o computador dentro do computador
IPMI, iDRAC, iLO — a interface de gestão fora de banda é um sistema completo com acesso total ao hardware, rodando mesmo com o servidor desligado. Historicamente, é uma das superfícies com histórico mais preocupante de vulnerabilidades.
E é a mais esquecida, porque funciona sozinha e ninguém mexe nela depois da instalação.
O mínimo:
- Rede isolada, sem rota para a internet e sem rota a partir de rede de usuário.
- Senha padrão trocada. As credenciais de fábrica de todos os fabricantes são conhecidas e públicas.
- Usuários desnecessários removidos, incluindo contas de fábrica.
- Firmware atualizado. É o componente com o firmware mais desatualizado de qualquer datacenter.
- Serviços desnecessários desabilitados na própria interface.
Vale uma varredura: liste os endereços de BMC do seu parque e verifique quantos ainda têm credencial padrão. O resultado costuma ser desconfortável.
3. SSH
Acesso ao shell do hipervisor deve ser exceção, não rotina — e quando acontece, precisa ser controlado.
- Autenticação por chave, com senha desabilitada.
- Login direto de root desabilitado para sessão interativa, com acesso por usuário nominal e elevação. Atenção: o cluster usa SSH entre os nós, então mudanças aqui exigem cuidado para não quebrar a comunicação interna — o ajuste correto restringe a origem, não o mecanismo do cluster.
- Escuta apenas na interface de gestão.
- Acesso restrito por firewall à rede de administração.
- Chaves com dono conhecido, revisadas periodicamente. Chave antiga de alguém que saiu é o mesmo problema da conta órfã.
4. Atualização: o item mais chato e mais importante
Boa parte das vulnerabilidades de escapada de VM é corrigida antes de ser explorada. A proteção é aplicar a correção.
O que precisa existir como rotina, não como intenção:
- Repositório coerente com o ambiente — enterprise em produção, ou no-subscription com processo, nunca test.
- Ciclo definido: quando as atualizações são aplicadas, quem aprova, qual a janela.
- Nó a nó, com as VMs migradas antes e validação depois.
- Backup válido antes de cada janela.
- Notas da versão lidas em mudança de versão maior.
- Homologação recebendo antes da produção.
- Firmware e microcódigo também — não só os pacotes do sistema. Correções de vulnerabilidade de CPU chegam por microcódigo.
Ambiente que não atualiza porque "não pode parar" é justamente o que mais vai parar, e no pior momento.
5. Reduzir o que roda no host
O nó Proxmox deve executar o hipervisor e nada mais. Cada serviço extra é superfície adicional com privilégio máximo.
- Nada de serviço de aplicação no host. Se precisa rodar algo, roda em VM ou container.
- Serviços não usados desabilitados, incluindo os que vêm ligados por padrão e não fazem parte do seu desenho.
- Nenhum software de terceiro instalado direto no host sem necessidade clara. Agente de monitoramento é a exceção comum e legítima — e deve ser um só, com privilégio mínimo.
- Postfix configurado para enviar alertas e nada mais, sem aceitar correio de fora.
6. Cifragem em repouso
Dois cenários concretos em que ela decide:
- Disco que sai do datacenter para garantia, manutenção ou descarte.
- Acesso físico não autorizado ao equipamento.
O que fazer:
- Cifragem no nível do storage — ZFS com cifragem nativa, ou cifragem de disco de dados. Avalie o impacto de desempenho no seu hardware antes de generalizar.
- Cifragem do backup do lado do cliente, que o Proxmox Backup Server faz nativamente. Este é o mais importante e o menos custoso: o backup é a cópia mais concentrada do seu ambiente e frequentemente a que sai do prédio.
- Guarda das chaves fora dos nós. Chave de cifragem armazenada no mesmo lugar que o dado cifrado não protege nada.
O último item é onde as implantações costumam falhar. Documente onde as chaves estão e como recuperá-las — inclusive no cenário em que o ambiente inteiro precisa ser reconstruído.
7. Auditoria e integridade do log
Um invasor com privilégio apaga rastro. O log só tem valor se existir em outro lugar.
- Exportação para um coletor central, fora dos nós, com escrita apenas de adição.
- Alerta em eventos sensíveis: acesso de root, falhas repetidas de autenticação, mudança de permissão, criação de token, alteração de configuração de cluster.
- Retenção suficiente para investigar um incidente descoberto semanas depois.
- Relógio sincronizado em todos os nós. Log com horário divergente é quase inútil em investigação.
8. Backup da configuração, não só dos dados
Reconstruir um nó é bem mais rápido quando a configuração existe em algum lugar:
- Configuração do cluster, das VMs e dos storages, versionada.
- Regras de firewall e definições de rede.
- Usuários, papéis e permissões.
- Configuração do PBS e a chave de cifragem, guardadas com segurança e testadas.
Isso transforma reconstrução de descoberta arqueológica em procedimento.
A ordem de execução
Se tudo estiver por fazer, comece por aqui — é decrescente em retorno:
- Verificar se uma VM alcança a rede de gestão. Corrigir.
- Tirar a interface de gestão de qualquer exposição à internet.
- Trocar credenciais padrão do BMC e isolar a rede dele.
- Estabelecer a rotina de atualização com backup e nó a nó.
- Endurecer SSH com chave e restrição de origem.
- Exportar logs e alertar em eventos sensíveis.
- Cifrar os backups e guardar a chave fora dos nós.
- Remover o que não precisa rodar no host.
- Documentar e versionar a configuração.
Os três primeiros itens respondem pela maior parte do risco real, e podem ser feitos em um dia.
Erros comuns
- Interface de gestão do hipervisor exposta à internet.
- VMs na mesma rede da gestão.
- BMC com credencial de fábrica e firmware de cinco anos atrás.
- SSH com senha habilitada e aberto a qualquer origem.
- Chaves SSH antigas de quem já saiu.
- Ambiente sem atualizar "porque não pode parar".
- Atualizar todos os nós de uma vez, sem backup.
- Esquecer firmware e microcódigo.
- Rodar serviços de aplicação direto no host.
- Backup não cifrado saindo do datacenter.
- Chave de cifragem guardada junto do dado cifrado.
- Log apenas local, perdido junto com o nó comprometido.
- Relógio dessincronizado entre nós.
- Nenhuma cópia versionada da configuração do cluster.
Onde a Solvefy/Cloud entra
Como parceiros oficiais Proxmox, fazemos a revisão de segurança do hipervisor com teste prático, não com questionário: verificamos de dentro de uma VM o que é alcançável, varremos os BMCs em busca de credencial padrão, revisamos SSH, serviços e repositórios, implantamos a rotina de atualização por nó com backup e homologação prévia, configuramos cifragem de backup com guarda de chave fora dos nós, e exportamos os registros com alerta em eventos sensíveis. Entregamos os achados priorizados por risco real.
Uma VM do seu ambiente consegue alcançar a interface de gestão do host? Fazemos um diagnóstico gratuito da infraestrutura, sem compromisso, em solvefy.cloud.
Solvefy/Cloud — Infraestrutura que cresce com você.