Configurar regras de firewall

Um servidor com IP público começa a receber tentativas de conexão em minutos. Não é ataque direcionado: é varredura automatizada testando portas conhecidas e senhas fracas. O firewall existe para que essas tentativas não cheguem a nenhum serviço seu.

A regra de projeto é uma só: negue tudo por padrão e abra apenas o que você usa. O contrário — abrir tudo e fechar o que parece perigoso — falha porque você precisaria conhecer antecipadamente todo serviço que um dia vai subir na máquina por acidente, com configuração padrão e senha padrão.

Duas camadas, propósitos diferentes

Você tem dois lugares onde filtrar tráfego, e vale usar os dois.

O Firewall da EasyOps age na rede, antes do pacote chegar à sua VM. Ele controla entrada e saída, pode ser aplicado a várias VMs e não tem custo extra. Vantagem prática: se você errar uma regra e perder o acesso, o servidor continua ligado e você corrige de fora — o filtro não está dentro da máquina.

O firewall do sistema operacional (ufw ou iptables no Linux, Windows Firewall no Windows) age dentro da VM. Ele é sua segunda linha: filtra o que vem de qualquer origem, inclusive de outras VMs suas, e continua valendo se a regra de rede for afrouxada por engano.

Não trate as duas como redundância inútil. Uma porta só está realmente aberta quando as duas camadas permitem — e isso é a causa mais comum de "abri a porta e não conecta".

Quais portas abrir de fato

Comece listando o que está escutando na máquina, não o que você imagina que está:

sudo ss -tulnp

Cada linha com 0.0.0.0: ou [::]: é um serviço exposto a qualquer origem. Compare com a tabela:

Bancos de dados e caches expostos na internet são a origem de boa parte dos incidentes de vazamento. Se sua aplicação roda na mesma VM, faça o banco escutar só em 127.0.0.1. Se roda em outra máquina, restrinja a origem ao endereço dela e a nada mais. Para acesso pontual de administração, use um túnel em vez de abrir a porta:

ssh -L 5432:127.0.0.1:5432 usuario@seu-servidor

O cliente local conecta em localhost:5432 e o tráfego passa criptografado pelo SSH. Nenhuma porta nova fica exposta.

A ordem que evita você se trancar fora

Este é o risco concreto do artigo. Se você negar tudo antes de permitir o SSH, a sua sessão atual pode sobreviver, mas a próxima não conecta.

Sempre nesta ordem:

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

O ufw enable vem por último, depois das permissões. Confira o resultado antes de fechar o terminal:

sudo ufw status verbose

E teste de verdade: abra uma segunda sessão SSH sem encerrar a primeira. Se a nova conectar, a regra está boa. Se não, você ainda tem a sessão original para desfazer com sudo ufw disable.

Se ainda assim perder o acesso, o console no browser não passa pelo SSH nem pela rede pública — é por ali que você recupera a máquina. Vale conferir como acessar sua VPS por SSH para ter os dois caminhos prontos antes de mexer em regras. E antes de reescrever um conjunto grande de regras em produção, tire um snapshot: a captura é instantânea e sem downtime.

Para restringir o SSH ao seu IP:

sudo ufw allow from 203.0.113.10 to any port 22 proto tcp
sudo ufw delete allow 22/tcp

Só faça isso com IP fixo. Com IP residencial dinâmico você se tranca fora na próxima renovação do link. A alternativa mais segura para a maioria dos casos é manter a 22 aberta e eliminar a senha: use chaves SSH em vez de senha e desative PasswordAuthentication. Força bruta contra chave não funciona.

Se mantiver a porta pública, limite a taxa de tentativas:

sudo ufw limit 22/tcp

Isso bloqueia origens com muitas conexões em pouco tempo, mas não substitui a chave.

Regras de saída: por que não deixar liberado

Saída aberta é o padrão de conveniência, e para muita coisa está certo — apt precisa dos repositórios, o sistema precisa de DNS (53) e NTP (123), o certbot precisa alcançar a autoridade certificadora.

O motivo de apertar a saída é o depois. Se uma aplicação sua for comprometida, o próximo passo do atacante é sair: baixar payload, mandar dados para fora, entrar num botnet. Uma política de saída restrita transforma isso num serviço que não consegue completar a tarefa.

Um meio-termo razoável para servidores de aplicação: permitir 80, 443, 53 e 123 na saída e negar o resto. Para máquinas que só servem HTTP e nunca iniciam conexões arbitrárias, feche mais. Documente cada exceção — regra de saída negada é o tipo de coisa que quebra um deploy meses depois, e a única pista é um timeout sem explicação.

Verificando de fora

Testar de dentro da própria máquina não vale: o pacote nem passa pelo filtro de rede. Verifique de outro host:

nc -zv seu-servidor 443
nc -zv seu-servidor 5432

A primeira deve responder que conectou. A segunda deve dar timeout ou recusa. Se a porta do banco responde, uma das duas camadas está aberta.

Ao emitir certificado, a 80 precisa estar acessível para a validação HTTP — é uma dependência real e não um detalhe, como mostra o passo a passo de apontar um domínio e emitir SSL. Depois da emissão, mantenha a 80 aberta apenas redirecionando para 443, porque a renovação automática usa o mesmo caminho.

Por fim: um Floating IP move o endereço público entre servidores, mas não move as regras. Ao apontar o IP para outra VM, confirme que a VM de destino tem o mesmo conjunto de regras. Caso contrário o endereço passa a atender uma máquina mais aberta do que a anterior.