Como configurar o firewall UFW no Ubuntu em 5 passos

O Ubuntu já vem com o UFW instalado, mas desligado. Quem sobe um servidor em VPS, instala nginx, Postgres, Redis e sai usando costuma ficar com meia dúzia de portas abertas pra internet sem nem ter percebido. O UFW (Uncomplicated Firewall) é uma camada simples em cima do iptables/nftables que resolve isso com meia dúzia de comandos. Este tutorial mostra o passo a passo, incluindo o erro clássico que tranca você pra fora do próprio servidor.

O que é o UFW e por que usar

O que é o UFW no Ubuntu?

UFW é a interface de linha de comando do Ubuntu para gerenciar o firewall do kernel (netfilter) sem escrever regras de iptables à mão. Você define quais conexões de entrada e saída são permitidas ou bloqueadas, e ele traduz isso para as regras reais.

A lógica de segurança é a do menor privilégio: negar tudo que entra por padrão e liberar só o que o servidor precisa oferecer. Um serviço esquecido escutando em 0.0.0.0 deixa de ser um problema, porque o firewall o bloqueia antes de qualquer pacote chegar nele.

Passo 1: confira o estado atual

sudo ufw status verbose

Em uma instalação nova, a resposta é Status: inactive. Antes de ativar qualquer coisa, veja o que está escutando de fato:

sudo ss -tulpn

Esse comando lista as portas TCP/UDP abertas e o processo dono de cada uma. É a sua lista do que precisa ser liberado — ou fechado. Se você usa Windows, o equivalente em PowerShell está no post sobre Get-NetTCPConnection para ver portas abertas.

Passo 2: defina a política padrão

sudo ufw default deny incoming
sudo ufw default allow outgoing

A primeira linha bloqueia toda conexão de entrada que não tenha regra explícita. A segunda deixa o servidor falar com o mundo (atualizações, DNS, APIs). Esse é o padrão do próprio UFW, mas declarar explicitamente evita surpresas se alguém alterou o /etc/default/ufw.

Passo 3: libere o SSH ANTES de ativar

Este é o erro que derruba quem usa VPS: ativar o firewall com política deny incoming sem ter liberado a porta do SSH. A sessão atual normalmente continua viva, mas qualquer nova conexão é recusada — e se a sessão cair, você perdeu o acesso (só o console do provedor salva).

sudo ufw allow OpenSSH

O perfil OpenSSH libera a porta 22/tcp. Se você mudou a porta no sshd_config, libere a número certa:

sudo ufw allow 2222/tcp

Melhor ainda: em vez de abrir pra todo mundo, use limit, que bloqueia temporariamente IPs que fazem 6 ou mais tentativas de conexão em 30 segundos:

sudo ufw limit OpenSSH

É uma proteção básica contra força bruta. Para algo mais sofisticado, combine com o fail2ban, que lê os logs e bane por mais tempo. E o firewall não substitui configurar o próprio daemon: veja os 7 ajustes essenciais de SSH hardening.

Passo 4: libere só os serviços necessários

Exemplos comuns:

sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw allow from 203.0.113.10 to any port 22 proto tcp
sudo ufw allow from 192.168.1.0/24 to any port 5432 proto tcp

• Linhas 1 e 2: web (HTTP e HTTPS) aberta pra qualquer origem.
• Linha 3: SSH somente a partir de um IP específico (troque 203.0.113.10 pelo seu IP fixo ou da VPN). É a regra mais forte contra scanners.
• Linha 4: banco de dados acessível apenas da rede local. Banco exposto na internet é uma das causas mais comuns de vazamento.

Se usar a regra de IP único para o SSH, remova a regra genérica do SSH depois de testar uma conexão nova em outro terminal.

Passo 5: ative e confira

sudo ufw enable
sudo ufw status numbered

O UFW avisa que a ativação pode interromper conexões SSH existentes; confirme com y apenas se o passo 3 já foi feito. A listagem numerada mostra cada regra com um índice. Para apagar uma regra:

sudo ufw delete 3

Os números mudam a cada remoção, então rode status numbered de novo antes de apagar a próxima. Para ligar o registro de tentativas bloqueadas:

sudo ufw logging on

Os bloqueios aparecem em /var/log/ufw.log (ou no journal, conforme a configuração). Vale olhar de vez em quando: é um retrato do tipo de varredura que seu IP recebe.

Pegadinhas que quase ninguém conta

O Docker ignora as regras do UFW?

Sim: portas publicadas com -p 8080:80 no Docker são abertas direto nas regras do iptables e passam por fora do UFW. A própria documentação do Docker avisa que o UFW não consegue bloquear esse tráfego.

Na prática, um container de banco com -p 5432:5432 fica acessível da internet mesmo com deny incoming ativo. Duas saídas: publicar a porta só em loopback (-p 127.0.0.1:5432:5432) ou, quando o serviço só precisa falar com outros containers, não publicar porta nenhuma.

E o IPv6?

Confira se IPV6=yes está no /etc/default/ufw. Com ele ativo, as regras valem para IPv4 e IPv6. Sem isso, o servidor pode estar protegido no v4 e aberto no v6.

Como testar de fora?

Do seu computador (não do servidor), rode nmap -Pn IP-DO-SERVIDOR e compare com a lista de portas que você decidiu liberar. Só varra servidores seus ou com autorização.

Firewall é uma camada, não a solução

O UFW reduz a superfície de ataque, mas não corrige senha fraca, software desatualizado nem credencial vazada. Trate como a primeira porta fechada de uma casa com várias. Se você administra acesso remoto no Windows, o raciocínio é o mesmo, e o post sobre como proteger o RDP contra força bruta mostra como aplicar. Comece hoje pelo ss -tulpn no seu servidor: o que você não reconhecer nessa lista é o primeiro candidato a fechar.