Como Configurar Regras de Firewall do VPS com Segurança
Publicado em 4 de setembro de 2026
Um firewall deve permitir o tráfego de que o seu servidor precisa e recusar silenciosamente o restante. Para configurar regras de firewall do VPS com segurança, comece pelos serviços que devem permanecer acessíveis, especialmente o SSH, e depois adicione portas web e de aplicação uma de cada vez. Não comece bloqueando tudo a partir da única sessão de terminal que você tem aberta. É assim que uma tarefa de manutenção tranquila se transforma em uma tarefa de recuperação pelo console.
Para a maioria das implantações de VPS Linux, o objetivo prático é simples: negar por padrão o tráfego de entrada não solicitado, permitir o tráfego de saída necessário e criar regras de entrada restritas para usuários e serviços confiáveis. Isso reduz a superfície de ataque sem dificultar a administração rotineira.
Comece com o mapa de tráfego
Antes de alterar qualquer regra, anote o que o VPS realmente faz. Um site WordPress público, por exemplo, normalmente precisa de SSH para administração e das portas 80 e 443 para tráfego web. Uma API privada pode precisar apenas de HTTPS, enquanto um servidor de banco de dados normalmente deve aceitar conexões apenas de um servidor de aplicação em uma rede privada.
Verifique primeiro os serviços em escuta. Na maioria das distribuições Linux, este comando fornece uma visão útil:
```bash sudo ss -tulpn ```
Não abra automaticamente todas as portas mostradas. Alguns serviços escutam apenas em localhost ou em uma interface privada e não precisam de acesso público pelo firewall. Outros podem ser serviços de teste antigos, agentes de monitoramento ou software que não deveria ser acessível pela internet de forma alguma.
Para cada porta exposta publicamente, responda a três perguntas: quem precisa dela, de onde e por qual protocolo? Uma regra que permite HTTPS de qualquer lugar é normal para um site público. Uma regra que permite uma porta de banco de dados de qualquer lugar normalmente é um problema esperando educadamente nos logs.
Mantenha um caminho de recuperação antes de configurar regras de firewall do VPS
Mantenha duas sessões SSH ativas enquanto faz alterações no firewall. Use uma sessão para aplicar as regras e deixe a segunda intocada. Depois de aplicar uma alteração, teste uma nova conexão a partir de outro terminal antes de fechar qualquer coisa. Isso detecta erros no caminho real da conexão em vez de depender do otimismo.
Confirme também que o console do provedor do seu VPS está disponível. Um console baseado em navegador ou um ambiente de resgate é a alternativa caso o SSH seja bloqueado. Isso não substitui um trabalho cuidadoso, mas é um bom seguro operacional.
Se o SSH estiver em execução em uma porta não padrão, verifique isso antes de criar as regras:
```bash sudo ss -tulpn | grep ssh ```
Uma porta SSH não padrão pode reduzir o ruído de fundo de verificações automatizadas, mas não representa uma segurança significativa por si só. Autenticação forte, acesso de origem limitado e aplicação de patches em tempo hábil fazem o trabalho real.
Use uma política padrão de negação de entrada com UFW
O UFW é uma interface de firewall prática para servidores VPS Ubuntu e baseados em Debian. É fácil de ler depois, o que importa quando outro administrador precisa solucionar uma indisponibilidade às 2 da manhã.
Primeiro, defina padrões sensatos:
```bash sudo ufw default deny incoming sudo ufw default allow outgoing ```
Em seguida, permita o SSH antes de ativar o firewall. Se o seu servidor usar a porta SSH padrão, use:
```bash sudo ufw allow OpenSSH ```
Se o SSH escutar em uma porta personalizada, especifique-a explicitamente. Este exemplo usa a porta 2222:
```bash sudo ufw allow 2222/tcp ```
Para um site público normal, permita HTTP e HTTPS:
```bash sudo ufw allow 80/tcp sudo ufw allow 443/tcp ```
Depois, ative o firewall e verifique a política resultante:
```bash sudo ufw enable sudo ufw status numbered ```
O status numerado é útil porque as regras podem ser removidas com precisão mais tarde. Evite deixar regras temporárias amplas para trás após a solução de problemas. Regras temporárias têm o curioso hábito de se tornarem móveis permanentes.
Se o VPS hospeda uma aplicação web por trás de um proxy reverso, a porta da aplicação talvez não precise ser pública. Por exemplo, o Nginx pode aceitar tráfego nas portas 80 e 443 enquanto a aplicação escuta em `127.0.0.1:3000`. Nesse design, nenhuma regra de firewall para a porta 3000 é necessária.
Restrinja o acesso administrativo por IP de origem
O SSH não deve estar aberto para todos os endereços, a menos que sua equipe realmente precise dessa flexibilidade. Se o seu escritório, VPN ou jump host tiver um endereço IP público estável, limite o SSH a ele:
```bash sudo ufw allow from 203.0.113.25 to any port 22 proto tcp ```
Para uma equipe distribuída com IPs residenciais variáveis, uma VPN ou um bastion host costuma ser uma solução melhor do que abrir o SSH globalmente. Isso acrescenta um pouco de trabalho de configuração, mas oferece um caminho único e controlado para administração e uma trilha de auditoria mais limpa.
A limitação de taxa também pode reduzir tentativas básicas de adivinhação de senha no SSH:
```bash sudo ufw limit 22/tcp ```
Isso não substitui chaves SSH, autenticação por senha desativada quando apropriado, nem acesso multifator por meio do seu caminho de gerenciamento. Pense nisso como um painel da cerca, não a cerca inteira.
Trate bancos de dados, painéis e monitoramento separadamente
Portas de banco de dados como MySQL na 3306, PostgreSQL na 5432, Redis na 6379 e MongoDB na 27017 quase nunca devem estar disponíveis publicamente. Permita-as apenas a partir do endereço IP privado ou da sub-rede do servidor de aplicação.
Por exemplo, para permitir conexões MySQL apenas de um VPS de aplicação em `10.10.0.12`:
```bash sudo ufw allow from 10.10.0.12 to any port 3306 proto tcp ```
O próprio serviço de banco de dados também deve se vincular à interface privada pretendida, sempre que possível. Regras de firewall e vinculação de serviço são camadas separadas. Usar ambos significa que uma alteração equivocada no firewall tem menos chance de expor o serviço.
Painéis de hospedagem, dashboards do Grafana e endpoints de monitoramento merecem a mesma atenção. Se forem apenas para a equipe, restrinja-os a uma VPN, faixa de IP do escritório ou rede de gerenciamento dedicada. Páginas públicas de monitoramento podem expor mais detalhes da infraestrutura do que o esperado, mesmo quando não mostram segredos.
Considere o firewall do provedor e o IPv6
Seu VPS pode ter mais de uma camada de firewall. Um firewall em nuvem ou no nível do provedor filtra o tráfego antes que ele chegue ao servidor, enquanto UFW, firewalld, nftables ou iptables filtram o tráfego no próprio VPS. Usar ambos faz sentido, mas as regras precisam estar alinhadas.
Se a porta 443 estiver aberta no VPS, mas bloqueada na camada do provedor, os visitantes ainda não conseguirão se conectar. Se o provedor permitir uma porta, mas o VPS a negar, o VPS permanecerá protegido. Durante a solução de problemas, verifique ambas as camadas em ordem: política do provedor, firewall do VPS, endereço de escuta do serviço e configuração da aplicação. Os logs normalmente contam a mesma história depois que esses itens são verificados.
Não se esqueça do IPv6. Se o seu VPS tiver um endereço IPv6 público, serão necessárias regras IPv6 equivalentes. O UFW pode gerenciar IPv6 quando ele está habilitado em sua configuração, mas verifique com:
```bash sudo ufw status verbose ```
Um endereço IPv4 devidamente protegido não ajuda se o mesmo serviço estiver totalmente exposto por IPv6.
Teste de fora e depois monitore o resultado
Após cada alteração significativa, teste a partir de uma rede externa ao VPS. Confirme que os serviços pretendidos funcionam e depois confirme que as portas que devem permanecer privadas não estão acessíveis. Testes no navegador são úteis para sites, mas testes de linha de comando fornecem respostas mais claras para portas específicas:
```bash nc -vz your-server-ip 443 ```
Para portas bloqueadas, um tempo limite ou uma recusa pode significar coisas diferentes, dependendo da regra e do estado do serviço. Revise o status do firewall, o status do serviço e os logs do sistema em vez de alterar várias configurações ao mesmo tempo.
Ative o registro com cuidado ao diagnosticar um problema:
```bash sudo ufw logging low ```
O nível baixo de registro normalmente é suficiente para identificar tráfego negado inesperado sem produzir atividade desnecessária em disco. Em servidores ocupados, logs de firewall em alto volume podem se tornar um pequeno incômodo operacional por si só.
Revise as regras do firewall sempre que implantar um novo serviço, descontinuar uma aplicação antiga, alterar endereços IP do escritório ou modificar a arquitetura de rede. As melhores regras não são o conjunto mais longo de regras. Elas são o menor conjunto que descreve com precisão como o servidor deve se comunicar.
Se preferir não assumir esse trabalho sozinho, uma equipe de VPS gerenciado pode revisar os requisitos de acesso, aplicar alterações com um plano de recuperação e monitorar o servidor depois. Na kodu.cloud, isso se encaixa naturalmente ao lado de operações gerenciadas e monitoramento contínuo, especialmente para equipes que precisam focar em clientes e produto em vez de filtragem de pacotes.
Um firewall está fazendo seu trabalho quando ninguém percebe sua presença. Mantenha a política restrita, documente por que cada exceção existe e teste o acesso antes de declarar que o serviço está tranquilo novamente.
Andres Saar Engenheiro de Atendimento ao Cliente