Firewall na VM ou firewall da nuvem: onde bloquear o quê

O ufw status afirma que a porta 5432 está fechada. Um nmap disparado do seu notebook afirma que ela está aberta. As duas ferramentas estão certas ao mesmo tempo, e essa contradição é o melhor resumo de por que firewall em nuvem confunde tanta gente.

O motivo é que existem duas camadas independentes, com regras próprias, aplicadas em pontos diferentes do caminho do pacote. Quem trata as duas como se fossem uma só acaba com regra duplicada de um lado, buraco do outro, e nenhum lugar único capaz de responder à pergunta que importa: quem, afinal, consegue falar com esta máquina?

Onde cada camada age

O firewall da nuvem roda na rede, antes do pacote chegar à sua VM. Se ele bloqueia, o tráfego nem é entregue ao servidor — a placa de rede virtual não vê nada, o kernel não processa nada, o seu nginx não registra nada.

O firewall do sistema — ufw, firewalld ou nftables puro — roda dentro da VM, no kernel. O pacote já chegou, já consumiu banda e já está sendo processado quando a decisão acontece.

Essa diferença de posição tem três consequências práticas:

• Custo de CPU. Um ataque de volume filtrado no perímetro não consome nada da sua máquina. O mesmo ataque filtrado pelo nftables consome interrupção, ciclo de CPU e entrada de log em cada pacote.
• Blindagem contra o seu próprio erro. Se você subir um Redis escutando em 0.0.0.0 sem senha, o firewall da nuvem continua barrando. O firewall do sistema não te protege de uma regra que você mesmo abriu.
• Visibilidade. O que você bloqueia no perímetro não aparece no log da VM. Isso é ótimo para ruído e ruim para diagnóstico — vale lembrar disso quando algo "não chega" e não há rastro nenhum no servidor.

O que colocar no firewall da nuvem

A camada de perímetro deve carregar a regra grosseira e estável: o que o mundo pode alcançar.

Um servidor web publicado tem exatamente três portas de entrada — e a terceira é discutível:

# Regras de entrada típicas de um servidor web
80/tcp    0.0.0.0/0        # HTTP (redireciona para HTTPS)
443/tcp   0.0.0.0/0        # HTTPS
443/udp   0.0.0.0/0        # HTTP/3, se você habilitou QUIC
22/tcp    203.0.113.10/32  # SSH apenas do IP do escritório

O SSH é o caso que mais gera discussão. Deixá-lo aberto para o mundo inteiro significa aceitar alguns milhares de tentativas de senha por dia no seu log. Restringir por IP de origem elimina isso de uma vez — e é a única regra dessa lista que realmente muda a superfície de ataque da máquina.

O contra-argumento honesto é que IP fixo nem sempre existe. Se você trabalha de casa com IP dinâmico, restringir por IP vira uma armadilha: um dia o IP muda e você fica de fora. Nesse cenário, o caminho é autenticar por chave em vez de senha e desligar a autenticação por senha no sshd. A força bruta continua batendo, mas passa a bater em porta que não abre.

Já as portas de banco de dados, cache e fila — 5432, 3306, 6379, 5672 — não têm razão nenhuma para estar no firewall da nuvem. Se a aplicação e o banco estão na mesma VM, elas nem deveriam estar escutando em interface pública. Se estão em VMs diferentes, a regra libera o IP interno da outra VM, nunca 0.0.0.0/0.

O que continua sendo trabalho do ufw

Se o perímetro já faz o corte grosso, para que manter firewall dentro da VM? Por três motivos concretos:

• Tráfego entre as suas próprias VMs. O perímetro costuma tratar a rede interna como confiável. Uma VM comprometida enxerga as vizinhas. O firewall local é o que segmenta isso.
• Regra de saída. Limitar para onde o servidor pode conectar é a diferença entre um comprometimento contido e um que exfiltra dados a noite inteira.
• Regras que mudam junto com a aplicação. A porta de um serviço novo é um detalhe da aplicação; ela pertence ao mesmo lugar onde o serviço é implantado.

Um conjunto local mínimo e defensável:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow OpenSSH
sudo ufw allow 80,443/tcp
sudo ufw allow from 10.0.0.0/8 to any port 5432 proto tcp
sudo ufw enable
sudo ufw status verbose

A ordem aqui não é decorativa. ufw allow OpenSSH antes de ufw enable é o que impede você de se desconectar da própria máquina no instante em que o firewall sobe. Vale a regra geral: nunca habilite firewall remoto sem antes conferir que a regra do SSH está na lista.

Se acontecer mesmo assim, o console no browser resolve — ele entra pelo console da virtualização, não pela rede, e por isso continua funcionando com o SSH bloqueado. É a diferença entre um susto de dois minutos e uma máquina perdida.

A pegadinha do Docker

Aqui está a explicação do ufw e do nmap discordarem, e é o erro mais comum desta lista inteira.

Quando você publica uma porta com -p 5432:5432, o Docker escreve as próprias regras de iptables em uma cadeia que é avaliada antes das regras do ufw. O resultado é que o container fica exposto mesmo com o ufw mandando negar tudo — e o ufw status continua exibindo, com toda a sinceridade, a regra que ele acredita estar aplicando.

Confirme o que realmente está publicado:

# O que está escutando, e em qual interface
sudo ss -tulpn | grep -v 127.0.0.1

# As regras que o Docker criou por conta própria
sudo iptables -t nat -L DOCKER -n

Há duas correções, e a primeira é quase sempre a certa:

# 1. Publicar só no loopback — o container fica acessível
#    ao host e a mais ninguém
ports:
  - "127.0.0.1:5432:5432"

# 2. Quando a porta precisa mesmo ser externa, filtrar na
#    cadeia DOCKER-USER, que é avaliada antes das do Docker
sudo iptables -I DOCKER-USER -p tcp --dport 5432 \
  ! -s 10.0.0.0/8 -j DROP

A opção 1 é melhor porque não depende de nenhuma regra dar certo. Uma porta que escuta apenas em 127.0.0.1 está fechada por construção, não por configuração — e é por isso que ela sobrevive à próxima pessoa que mexer no firewall sem entender.

Teste de fora, nunca de dentro

Testar firewall a partir da própria máquina é o equivalente a checar se a porta de casa está trancada estando dentro dela. curl localhost:5432 vai funcionar independentemente de qualquer regra, porque o tráfego nem passa pelo filtro de entrada.

O teste que vale exige outra origem:

# De outra máquina, ou do seu notebook
nc -zv 203.0.113.50 5432        # porta específica
nmap -Pn -p 22,80,443,5432,6379,3306 203.0.113.50

Três resultados possíveis, com significados bem distintos:

O refused é o mais mal interpretado dos três. Ele quer dizer que o pacote atravessou o firewall e encontrou a VM — a porta está fechada apenas porque nada está escutando. No momento em que alguém subir um serviço ali, ela abre sozinha. Se o objetivo era bloquear, o resultado esperado é filtered.

Erros que se repetem

• Regra de saída esquecida. default deny outgoing sem liberar DNS e NTP faz o servidor parar de resolver nome e de sincronizar relógio. Certificado que "vence" sozinho costuma ser relógio errado.
• IPv6 aberto enquanto o IPv4 está fechado. As regras são listas separadas. O ufw cuida das duas por padrão; iptables puro, não — precisa de ip6tables.
• Liberar por porta quando o correto é não escutar. Um serviço que só o localhost usa deve ter bind 127.0.0.1 na configuração dele.
• Firewall de perímetro e local divergentes. Duas fontes da verdade, e ninguém sabe qual está valendo. Escreva em algum lugar o que é responsabilidade de cada camada.
• `ufw reset` em produção. Ele derruba tudo, inclusive a regra do SSH.

O resumo operacional

A divisão que se sustenta ao longo do tempo é simples: o firewall da nuvem define quem entra na sua rede e muda pouco; o firewall do sistema define o que cada máquina aceita e acompanha o ciclo da aplicação. Duas camadas, dois propósitos, nenhuma duplicação.

Vale montar a camada de perímetro primeiro, seguindo as regras de firewall no painel, e só depois refinar o ufw dentro da VM. Se um serviço parar de responder no meio do caminho, a dúvida "é firewall ou é o serviço?" se resolve rápido com o diagnóstico do systemd — porta filtrada e serviço que não subiu produzem exatamente o mesmo sintoma para quem está de fora.