UFW no Linux: firewall host sem se trancar fora do servidor

UFW (Uncomplicated Firewall) é a interface padrão do Ubuntu para administrar um firewall de host. Ele simplifica regras comuns, mas não substitui o desenho da rede nem torna seguro um serviço mal configurado. Em servidor remoto, o erro mais comum é habilitar o firewall antes de garantir a regra de acesso administrativo — e perder a própria sessão.

Resposta direta

Antes de executar sudo ufw enable, descubra quais serviços realmente precisam receber conexões e de onde elas devem vir. Em servidor acessado por SSH, crie e valide primeiro a regra de SSH para a sua origem administrativa. Depois habilite o UFW, confira sudo ufw status verbose, teste uma segunda conexão antes de fechar a primeira e só então avance para outras portas.

1. Entenda o papel do UFW

O UFW gerencia filtragem de tráfego no próprio host. A documentação do Ubuntu o descreve como uma forma simplificada de criar e remover regras para firewall baseado em host. Isso é diferente de um firewall de borda, de uma regra de Security Group em nuvem ou de segmentação entre VLANs.

Se o objetivo é controlar tráfego entre redes, VPNs, NAT complexo ou múltiplos segmentos, um gateway dedicado pode ser a camada certa. Veja também como pensar regras em um firewall de borda.

2. Faça inventário das portas antes das regras

• Qual serviço está escutando?
• Ele precisa aceitar conexões externas ou apenas locais?
• Qual protocolo e porta usa?
• Quais redes ou hosts devem iniciar a conexão?
• Existe outra camada de firewall na nuvem, roteador ou provedor?

Não abra uma porta só porque um tutorial lista aquela porta. Primeiro confirme o processo que está escutando e a necessidade do serviço.

3. Veja o estado atual antes de habilitar

Comece por comandos de leitura:

• sudo ufw status — mostra se o UFW está ativo e as regras visíveis.
• sudo ufw status verbose — inclui informações adicionais do estado.
• sudo ufw status numbered — numera regras para facilitar revisão e exclusão.
• sudo ufw app list — lista perfis instalados por aplicações.

O Ubuntu informa que o UFW começa desabilitado por padrão. Isso não significa que o servidor esteja “sem nenhuma proteção”: pode haver firewall de nuvem, roteador ou outras regras. Por isso, diagnostique todas as camadas.

4. Servidor remoto: preserve o caminho de administração

Se você administra por SSH, permita o acesso antes de habilitar o firewall. Quando possível, restrinja pela rede ou host de administração em vez de aceitar SSH de qualquer origem.

Exemplo da própria documentação do Ubuntu para permitir SSH apenas de uma origem específica: sudo ufw allow proto tcp from 192.168.0.2 to any port 22. Em uma rede inteira, ajuste a origem para a sub-rede que realmente administra o servidor.

Depois de habilitar, mantenha a sessão atual aberta e teste uma nova sessão. Se a nova conexão falhar, não feche o único acesso que ainda funciona.

5. Teste uma regra antes de aplicá-la

O UFW oferece --dry-run para mostrar as regras resultantes sem aplicá-las. Por exemplo, sudo ufw --dry-run allow http. Use essa etapa para conferir o efeito de mudanças simples antes da aplicação.

6. Abra somente o serviço necessário

A documentação do Ubuntu mostra regras por número de porta e por perfil de aplicação. Exemplos comuns:

• sudo ufw allow 22 — permite porta 22; em produção, prefira restringir origem quando viável.
• sudo ufw allow http — usa o nome de serviço quando disponível.
• sudo ufw allow Samba — usa o perfil de aplicação instalado.
• sudo ufw allow from 192.168.0.0/24 to any app Samba — restringe Samba à rede local de exemplo.

O ponto não é decorar comandos: é associar cada regra a um serviço, uma origem e uma justificativa.

7. Remova regras com precisão

Evite “resetar tudo” para corrigir uma regra errada. Use sudo ufw status numbered para revisar a ordem e remova a regra específica. A documentação também aceita exclusão pelo próprio texto da regra, como sudo ufw delete deny 22.

8. Logs ajudam, mas não substituem diagnóstico

O Ubuntu documenta sudo ufw logging on para ativar registros do firewall. Use logs para entender bloqueios inesperados e tentativas de conexão, mas considere volume, retenção e a ferramenta de log do sistema. Um pacote bloqueado não prova, sozinho, uma invasão.

9. Regras padrão e saída: decida conscientemente

Muitos servidores adotam a lógica de negar entradas não solicitadas e permitir saídas, mas isso é uma política, não uma lei. Antes de mudar defaults em produção, documente serviços de monitoramento, DNS, NTP, atualizações, bancos e integrações que dependem de tráfego de saída.

Em ambientes mais restritos, filtragem de saída exige inventário e observabilidade para não quebrar dependências legítimas.

10. UFW em servidor com Docker, roteamento ou NAT

Contêineres, encaminhamento de pacotes, bridges e regras de NAT podem introduzir caminhos de tráfego que não se comportam como um host simples. Se a máquina também atua como roteador, gateway ou host de contêineres publicados, não aplique um roteiro básico sem entender a cadeia de regras e a arquitetura.

Nesses casos, desenhe primeiro o fluxo: origem → interface → serviço → retorno. Se houver VPN de acesso remoto, conecte a política ao planejamento de VPN empresarial.

Quando parar

• Você administra o servidor remotamente e não possui console alternativo nem regra SSH validada.
• Não sabe qual processo usa a porta que pretende abrir.
• A máquina roteia tráfego, faz NAT ou hospeda contêineres e você não mapeou essas regras.
• Existe firewall de nuvem/roteador e você não sabe qual camada está bloqueando.
• Para fazer o serviço funcionar, a única ideia restante é desabilitar o firewall por completo.

O que não fazer

• Não habilite UFW em servidor remoto antes de preservar o acesso administrativo.
• Não abra “qualquer origem” quando o serviço só precisa da rede local.
• Não use porta aberta como substituto de autenticação segura no serviço.
• Não interprete log de bloqueio como prova automática de ataque.
• Não misture alterações de UFW, roteamento, Docker e firewall de nuvem numa única mudança sem plano de rollback.

Checklist de validação

• sudo ufw status verbose mostra o estado esperado.
• Uma segunda sessão SSH abre a partir da rede administrativa autorizada.
• Portas necessárias respondem apenas das origens previstas.
• Portas que não deveriam estar públicas continuam inacessíveis.
• Aplicação, DNS, atualizações e monitoramento continuam funcionando.
• As regras possuem justificativa documentada e podem ser revertidas individualmente.

Decisão: UFW é a camada certa?

Use UFW quando você precisa controlar conexões do próprio host Ubuntu com regras compreensíveis. Se a necessidade é segmentar várias redes, controlar NAT, concentrar VPNs ou aplicar política para muitos dispositivos, trate o problema como arquitetura de firewall/gateway. Se o servidor está em nuvem, alinhe UFW com Security Groups/firewall do provedor em vez de configurar cada camada sem relação.

Dúvidas rápidas antes de começar

UFW substitui um firewall de borda?

Não. UFW protege o host; um firewall de borda controla tráfego entre redes e pode aplicar políticas antes de o pacote chegar ao servidor.

Posso permitir SSH só da minha rede?

Sim. O UFW aceita regras com origem específica ou sub-rede. Isso reduz exposição quando a arquitetura permite uma origem administrativa estável.

Preciso reiniciar o servidor depois de cada regra?

As regras do UFW são aplicadas pelo próprio utilitário; o importante é verificar o estado e testar o serviço após a mudança.

UFW protege uma aplicação vulnerável?

Ele reduz superfície de rede e controla quem alcança uma porta, mas não corrige vulnerabilidades, senhas fracas ou falhas da aplicação.

Glossário rápido

Firewall de host

Filtro aplicado no próprio computador ou servidor.

Regra de entrada

Política para tráfego que tenta chegar ao host.

Origem

Host ou rede de onde a conexão é iniciada.

Porta

Identificador lógico usado por serviços de rede.

Dry run

Simulação que mostra o efeito esperado sem aplicar a regra.

Para conectar firewall, VPN, Wi-Fi e segmentação ao diagnóstico de rede, siga o Atlas de redes e Wi-Fi.