A sua VM web ainda responde, mas você chega ao momento em que uma regra muito ampla pode abrir um serviço desnecessário ou cortar o SSH.
O firewall do Proxmox já está ativo e a questão se torna precisa: devemos escrever no nível da VM, do nó ou do sistema operacional convidado?
Para uma VM ou um contêiner, comece com o convidado e seus fluxos reais.
Leia as opções de net0, construa as regras IN, decida o destino de OUT, e então fatorize apenas as regras que merecem um grupo. Os controles do Proxmox e o teste de aplicativo permanecem separados do firewall do host.
Defina o alvo antes de escrever a primeira regra
Identifique o VMID, a interface virtual, o endereço do convidado e os serviços realmente expostos. Uma VM Debian que serve HTTP e HTTPS não tem as mesmas entradas que um contêiner de administração acessível a partir de um bastião.
- anote o
VMIDreal e a interfacenet0; - liste as portas de entrada e as fontes autorizadas;
- mantenha um console ou acesso administrativo ao host;
- verifique se o firewall do Datacenter/Nó já foi tratado.
As zonas não se substituem. O Datacenter se refere especialmente a blocos reutilizáveis, o Nó diz respeito ao host, e VM/CT filtra fluxos para ou a partir do convidado.
O firewall do Debian é uma camada separada. A documentação oficial do Proxmox VE descreve essa separação, bem como as direções IN, OUT e FORWARD.
Se o firewall do nó ainda não estiver ativado ou se você teme perder a Web UI ou o SSH, pare antes das regras da VM e consulte a ativação prudente do firewall Proxmox sem perder o acesso.
O bloqueio do host está fora do âmbito aqui.
Leia as opções da VM e de sua interface
Antes de escrever, releia a configuração a partir do nó Proxmox. Substitua <VMID> pelo identificador numérico da sua VM:
qm config <VMID> --currentEm seguida, verifique na configuração da VM, enable, policy_in, policy_out, log_level_in, log_level_out e ipfilter.
Cada interface também possui seu próprio indicador de firewall. A opção geral da VM não é suficiente se a flag de net0 estiver desativada.
[OPTIONS]
enable: 1
policy_in: DROP
policy_out: ACCEPT
log_level_in: nolog
log_level_out: nolog
ipfilter: 1Este bloco ilustra uma entrada restritiva e uma saída ainda permissiva. Não é um arquivo para copiar exatamente: adapte os valores à sua VM, e depois verifique a configuração gerada.
ipfilter serve principalmente para limitar a falsificação de endereço na interface, não para criar uma lista de permissões HTTP ou SSH.
Permitir fluxos de entrada realmente necessários
Comece pelas entradas. Para uma VM web, o SSH geralmente vem de um bastião ou de uma rede de administração.
As portas 80 e 443 vêm do reverse proxy ou de uma fonte pública prevista pela arquitetura. Portanto, uma regra de autorização deve nomear o protocolo, a porta, a fonte e a interface quando esses elementos são conhecidos.
[RULES]
IN ACCEPT -p tcp -dport 22 -source +admins -i net0
IN ACCEPT -p tcp -dport 80 -source +reverse_proxy -i net0
IN ACCEPT -p tcp -dport 443 -source +reverse_proxy -i net0Neste exemplo, +admins e +reverse_proxy são IPSet definidos separadamente.
O endereço documental 192.0.2.0/24 pode ilustrar uma rede em um exemplo ou documentação, mas não representa sua rede real. Substitua por suas fontes verificadas, sem copiar um endereço encontrado em um tutorial.
Coloque as permissões específicas antes de uma política DROP ou REJECT. Uma recusa global adicionada muito cedo oculta a regra útil.
Isso transforma um simples esquecimento em uma interrupção do SSH. Faça uma leitura da configuração antes de endurecer, e mantenha um console de host disponível.
Decidir a política OUT antes de torná-la rígida
Uma saída autorizada permite o funcionamento de DNS, NTP, atualizações, repositórios APT, supervisão ou APIs externas desde que as outras camadas as filtrem.
Uma saída restritiva exige um inventário preciso: o primeiro pacote DNS bloqueado é suficiente para fazer crer que a VM ou seu bridge está fora do ar.
| Fluxo da VM | Direção | Exemplo | Risco sob DROP |
|---|---|---|---|
| SSH de administração | IN | +admins para 22/tcp | Acesso negado se a fonte não estiver listada. |
| HTTP/HTTPS | IN | +reverse_proxy para 80/443 | O serviço web se torna inacessível. |
| Resolução DNS | OUT | UDP/TCP 53 para o resolvedor | APT e as chamadas por nome falham. |
| Tempo do sistema | OUT | UDP 123 para a fonte NTP | O relógio deriva se nenhum outro mecanismo assumir o controle. |
| Repositórios e APIs | OUT | TCP 80/443 para os destinos previstos | Atualizações e supervisão podem parar. |
Prefiro deixar policy_out: ACCEPT durante o inventário, e depois mudar para DROP com as saídas documentadas uma a uma.
Essa escolha protege a disponibilidade do serviço durante a construção. Não substitui uma política de saída se seu ambiente realmente impõe uma lista branca.
[OPTIONS]
policy_out: DROP
[RULES]
OUT ACCEPT -p udp -dport 53 -dest dns_interne
OUT ACCEPT -p tcp -dport 53 -dest dns_interne
OUT ACCEPT -p udp -dport 123 -dest ntp_interne
OUT ACCEPT -p tcp -dport 80 -dest depots
OUT ACCEPT -p tcp -dport 443 -dest depotsOs nomes dns_interne, ntp_interne e depots devem apontar para seus endereços ou grupos reais. A sintaxe de várias portas e aliases deve ser revisada com a versão instalada do Proxmox antes da aplicação.
Fatorizar as regras repetíveis com um Grupo de Segurança
Um Grupo de Segurança se torna útil quando várias VMs ou contêineres compartilham a mesma função.
O Proxmox o define no nível do cluster, e a configuração de cada convidado o chama em sua seção [RULES]. O grupo não se aplica a nenhuma VM até que você o insira em suas regras.
# /etc/pve/firewall/cluster.fw
[group webserver]
IN ACCEPT -p tcp -dport 80
IN ACCEPT -p tcp -dport 443
# /etc/pve/firewall/<VMID>.fw
[RULES]
GROUP webserverMantenha no grupo as regras realmente comuns. Uma exceção específica de uma VM permanece em /etc/pve/firewall/<VMID>.fw. Essa separação evita ter que modificar todos os convidados para corrigir uma única porta de administração.
Nomear as fontes com IPSet e aliases
Os IPSets agrupam endereços ou redes; os aliases dão um nome legível a um endereço ou rede.
As regras podem usá-los como fonte ou como destino. Você pode assim reler +admins ou dns_interne sem a necessidade de interpretar uma sequência de IP a cada vez.
# /etc/pve/firewall/cluster.fw
[ALIASES]
dns_interne 192.0.2.53
[IPSET admins]
192.0.2.10
[IPSET reverse_proxy]
192.0.2.20
192.0.2.21Os endereços 192.0.2.10, 192.0.2.20 e 192.0.2.21 são marcadores de documentação. Um IPSet é referenciado com o prefixo +, por exemplo, -source +admins.
Sem esse prefixo, o Proxmox lê o nome como um endereço ou um alias e a regra não corresponde à intenção.
Não confunda ipfilter-net0 com uma lista de permissões de aplicativo.
Esse IPSet anexado à interface ajuda a evitar a falsificação do endereço de origem. Ele não decide quem pode abrir a porta 443 de sua aplicação.
Leia a ordem das regras antes de tornar a política rígida
Uma regra de grupo ou uma regra local só tem efeito se for lida no local esperado. Coloque as correspondências precisas antes da recusa geral e releia a configuração após cada mudança.
| Ordem lida | Exemplo | Risco se colocado muito baixo |
|---|---|---|
| 1. Fonte e porta precisas | SSH de +admins para 22/tcp | O bastião é bloqueado pela política. |
| 2. Grupo reutilizável | GROUP webserver | As portas web permanecem fechadas nesta VM. |
| 3. Saídas documentadas | DNS, NTP, repositórios | O serviço inicia e depois perde suas dependências. |
| 4. Política padrão | DROP ou REJECT | Todo fluxo esquecido cai aqui. |
A documentação oficial descreve a sintaxe IN/OUT, as opções --source, --dest, --dport e --iface, bem como a inserção de um Grupo de Segurança.
Use a forma correspondente à sua versão, e então controle a configuração compilada em vez de supor que o grupo está ativo.
Ativar um log direcionado durante o teste
A journalização do Proxmox está desativada por padrão para o tráfego filtrado. As opções log_level_in e log_level_out ativam os logs padrão da VM/CT, visíveis em Firewall → Log.
O nível adicionado ao log serve para identificar o pacote: ele não aumenta automaticamente o número de pacotes registrados.
[OPTIONS]
log_level_in: info
log_level_out: nolog
[RULES]
IN ACCEPT -p tcp -dport 22 -source +admins -i net0 -log infoAtive o nível apenas durante o teste do fluxo que lhe interessa, e depois volte para nolog se o volume se tornar ruidoso.
Uma journalização global permanente complica a leitura dos reais recusas e aumenta o ruído operacional.
Atenção: um log vazio não prova que um serviço está funcionando. É preciso ainda verificar a regra, a resposta da aplicação e o caminho de rede a partir da fonte real.
Compilar, testar e prever o retrocesso
Comece pela leitura do estado do firewall no nó:
pve-firewall status
pve-firewall compilepve-firewall status releitura e compila as regras: um aviso de sintaxe é um problema a ser corrigido antes do teste de rede.
pve-firewall compile permite que você veja a configuração gerada.
A documentação oficial do pve-firewall também descreve pve-firewall simulate, que pode ajudar a simular uma fonte, um destino, uma porta e um protocolo, mas não prova nem o roteamento do kernel nem o funcionamento da aplicação.
O controle final deve partir da fonte autorizada, e então de uma fonte que deve ser recusada se você puder utilizá-la sem risco:
- SSH a partir do IP de administração esperado com
ssh -v; - HTTP ou HTTPS a partir do reverse proxy com
curl -I https://<IP_VM>; - DNS, NTP e APT a partir da VM se
policy_outfor restritiva; - leitura do log do Proxmox durante a janela de teste, e então voltar para
nolog.
Não apresente esses comandos como um teste já realizado: eles formam seu protocolo de validação.
Um resultado esperado é uma conexão autorizada que responde, um fluxo proibido que falha e um registro consistente com a regra examinada.
Se uma regra cortar a VM, remova essa regra ou desative temporariamente o firewall dessa VM/CT.
Volte para policy_out: ACCEPT se DNS, NTP ou atualizações estiverem falhando.
Não use pve-firewall stop como um retrocesso normal: esse comando remove as regras do Proxmox do host e pode deixar o servidor desprotegido.
Mantenha os limites visíveis
Uma VM sem endereço IP, um bridge ausente ou um VLAN mal transportado não se conserta com uma regra de firewall.
Se a regra parece correta, mas o convidado não tem um IP, passe para o diagnóstico de rede de uma VM Proxmox, do bridge ao convidado: restaurar a rede da VM.
Para um problema no lado do host, o guia criar um bridge Proxmox sem perder o acesso ao servidor aborda a camada apropriada.
O backend nftables proxmox-firewall permanece marcado como pré-visualização técnica na documentação PVE 9.2.11.
Os exemplos acima permanecem centrados no backend padrão pve-firewall. Se seu ambiente usa IPv6, verifique também o NDP e os endereços IPv6 em vez de concluir apenas com um teste de IPv4.