Firewall do Proxmox VE: regras em datacenter, nó e VM sem se perder

O Proxmox traz um firewall distribuído embutido, e ele é bom. O problema é que ele opera em três níveis com herança entre eles, e a primeira experiência de muita gente é: ligar, perder o acesso à interface web e passar a próxima hora no console físico. Depois disso, o firewall costuma ficar desligado para sempre — o que é um desperdício, porque ele resolve exatamente o problema que mais importa num hipervisor.

Este texto é o mapa mental que faltava: o que cada nível faz, em que ordem as regras são avaliadas e como ligar tudo sem se trancar para fora.

Por que o firewall do hipervisor importa mais que o da VM

Dentro de cada VM você provavelmente já tem firewall do sistema operacional. Então por que ligar mais um?

Porque o firewall do Proxmox está em um lugar que o da VM não alcança: antes da VM. Isso muda três coisas.

• O cliente ou usuário que administra a VM não pode desligar a regra. Firewall dentro da VM é configurado por quem tem root lá dentro; o do Proxmox é configurado por você.
• A regra continua valendo se a VM for comprometida, reinstalada ou substituída.
• Ele protege o próprio hipervisor — a interface de gestão, o tráfego de cluster, o acesso ao storage. Essa é a superfície que você menos pode perder.

Em ambiente com mais de um cliente ou mais de uma área usando o mesmo cluster, isso deixa de ser boa prática e vira requisito.

Os três níveis

A herança funciona de cima para baixo: o que está no datacenter vale para todos, o do nó soma ao do datacenter naquele host, e o da VM soma para aquela VM. E cada nível tem o seu próprio interruptor de habilitação.

É essa combinação de três interruptores que gera a confusão mais comum: o firewall só age na VM se estiver habilitado no datacenter, no nó e na VM, e também na interface de rede daquela VM. Esqueceu um, a regra parece não funcionar. E o contrário também: habilitou no datacenter com política padrão restritiva sem pensar nos nós, e perdeu o acesso.

A ordem de avaliação, em linguagem simples

Para tráfego chegando a uma VM, o caminho é:

1. Regras do datacenter para entrada.
2. Regras do nó que hospeda a VM.
3. Regras da VM.
4. Política padrão da VM (aceitar ou descartar).

Duas consequências práticas. Primeira: uma negação em nível mais alto não é recuperável nos níveis abaixo — se o datacenter bloqueia, não adianta liberar na VM. Segunda: a política padrão é o que decide o que acontece com o que nenhuma regra mencionou. Política padrão de entrada como descarte é o desenho correto; libere explicitamente o que precisa.

O roteiro para ligar sem se trancar para fora

Esta é a parte que evita a hora no console físico. A ordem importa.

1. Tenha acesso alternativo garantido antes de começar: console IPMI/iDRAC/iLO funcionando e testado, ou acesso físico. Não confie apenas no SSH.
2. Crie primeiro as regras de liberação, antes de habilitar qualquer coisa. No nível do datacenter, libere a partir da sua rede de administração: a porta da interface web (8006), SSH (22) e, se usar, o console SPICE (3128).
3. Crie um alias ou IPSet com a sua rede de gestão. Endereço escrito na mão em dez regras é dívida garantida.
4. Libere o tráfego de cluster entre os nós — o Corosync usa portas próprias e bloqueá-lo derruba o quórum, que é uma forma espetacular de derrubar o cluster inteiro.
5. Libere o tráfego de storage — Ceph, NFS, iSCSI, conforme o seu desenho — entre os nós e para o storage externo.
6. Habilite no nível do nó primeiro, em um único nó, e confirme que você continua com acesso. Só então replique.
7. Habilite no datacenter por último, com a política padrão de entrada como descarte.
8. Só depois comece a tratar as VMs, uma de cada vez.

O princípio geral: libere antes de bloquear, e valide a cada passo em um nó só.

Aliases, IPSets e security groups: a parte que evita bagunça

Um firewall com trinta regras escritas na mão vira intratável em seis meses. O Proxmox oferece três abstrações que resolvem isso, e usá-las desde o começo é a diferença entre um conjunto de regras legível e um emaranhado.

• Alias — dá nome a um endereço ou rede. rede-gestao, storage, vpn-escritorio. Se o endereço mudar, você muda em um lugar.
• IPSet — um conjunto nomeado de endereços e redes. Serve para "todas as redes internas", "endereços de administração", "lista de bloqueio". Uma regra referencia o conjunto inteiro.
• Security group — um conjunto nomeado de regras, criado no datacenter e aplicado a várias VMs. É a abstração mais valiosa: você cria um grupo web (libera 80 e 443), um grupo banco (libera a porta do banco só a partir do IPSet da aplicação), um grupo gestao-ssh, e aplica os grupos às VMs conforme o papel de cada uma.

Com security groups, adicionar uma VM de aplicação passa a ser "aplique o grupo web e o grupo base" em vez de escrever cinco regras de novo, provavelmente com uma diferença acidental.

O que proteger no nível do nó

O nó é a superfície mais crítica. O que deveria estar liberado e o que não deveria:

Libere apenas a partir da rede de gestão:

• Interface web (8006).
• SSH (22).
• Console SPICE (3128), se usar.
• Proxmox Backup Server (8007), se o servidor de backup estiver separado.

Libere entre os nós do cluster:

• Corosync, para o quórum.
• Migração ao vivo.
• Replicação e tráfego de storage, conforme o desenho.

Nunca deveria ser alcançável a partir de VM de cliente:

• Qualquer uma das portas acima.

Esse último ponto é o mais importante do artigo. A rota mais curta para um comprometimento sério é uma VM de cliente que enxerga a interface de gestão do host. Se a sua rede de gestão está na mesma bridge das VMs, o firewall é a última linha — e ele precisa estar ligado.

Registro de log: ligue, mas com critério

O firewall do Proxmox pode registrar o que bloqueia, por nível. É extremamente útil para descobrir por que algo parou de funcionar depois de uma mudança — e é igualmente eficiente em encher o disco do nó se ficar no nível mais verboso para sempre.

O uso que funciona: suba o nível de log durante a implantação e durante diagnóstico, e volte para um nível discreto depois. Registre o que é descartado na política padrão; é a informação mais reveladora e o volume é gerenciável depois que o ambiente estabiliza.

Onde o firewall do Proxmox não é suficiente

Honestidade sobre limites:

• Ele filtra por endereço, porta e protocolo. Não inspeciona conteúdo de aplicação, não faz proxy reverso e não substitui um WAF na frente de uma aplicação web exposta.
• Não é o lugar de fazer NAT elaborado nem de terminar VPN. Essas funções pedem um appliance ou uma VM dedicada de borda.
• Ele protege a fronteira da VM, não o que acontece dentro dela. Manter o sistema convidado atualizado continua sendo necessário.

O desenho completo costuma ter o firewall do Proxmox como camada de isolamento entre cargas e proteção do hipervisor, e um firewall de borda cuidando da internet.

Erros comuns

• Habilitar o firewall no datacenter antes de criar as regras de liberação.
• Não testar o acesso por console fora de banda antes de começar.
• Esquecer de habilitar o firewall na interface de rede da VM e achar que a regra não funciona.
• Bloquear o tráfego do Corosync e derrubar o quórum do cluster.
• Escrever endereços na mão em vez de usar alias e IPSet.
• Repetir as mesmas regras em dezenas de VMs em vez de criar security group.
• Política padrão de entrada como aceitar, tornando o firewall decorativo.
• Deixar a interface de gestão alcançável a partir de rede de VM.
• Manter log no nível mais verboso indefinidamente e encher o disco do nó.
• Nunca revisar as regras depois que o ambiente muda.

Onde a Solvefy/Cloud entra

Como parceiros oficiais Proxmox, desenhamos essa camada com você: separação das redes de gestão, cluster, storage e cargas; conjunto de security groups por papel de VM; regras de nó que protegem o hipervisor; e a implantação feita na ordem certa, com acesso fora de banda garantido e validação a cada passo. Também documentamos o conjunto, para que a próxima pessoa entenda por que cada regra existe.

Seu hipervisor está exposto e você não tem certeza? Fazemos um diagnóstico gratuito da infraestrutura, sem compromisso, em solvefy.cloud.

Solvefy/Cloud — Infraestrutura que cresce com você.