4.2 Firewall, portas e IP allowlist

🧅 Defesa em camadas

Nenhuma camada sozinha basta. Firewall do provedor pode ter regra mal configurada. ufw pode ser desligado por engano. Container pode rodar com --privileged. Três camadas independentes garantem que erro em uma é coberto pela próxima.

🛡️ As 3 camadas

Firewall do provedor (Hostinger, AWS Security Group, Hetzner Cloud Firewall) — bloqueia tráfego antes da VM. Mais barato em CPU e logs.

ufw no host Ubuntu — controle granular dentro da VM. Cobre tráfego de containers vizinhos e regras finas por porta.

Isolamento do container — Hermes em Docker sem --privileged, sem mounts inúteis, com network bridge padrão.

📐Regra de ouro

Toda porta aberta tem que ter justificativa documentada. Se você não consegue explicar em uma frase por que X está aberta, feche.

🏰 Hostinger Upguard / firewall built-in

A Hostinger oferece firewall direto no painel da VPS. Upguard adiciona scanning e alertas. Bloqueia o pacote antes dele chegar na sua VM — economiza CPU, banda e linhas de log no Ubuntu.

⚙️ Configuração mínima recomendada

•Default: deny inbound
•Allow: 22 (SSH) — idealmente só do seu IP
•Allow: 80, 443 (web) se você expõe dashboard ou nginx
•Outbound: tudo aberto (o agente precisa chamar APIs)

📅Manutenção

Reveja as regras a cada 90 dias. Portas que você "abriu pra testar" e esqueceu são o vetor mais comum de incidente em VPS pessoal.

🔥 ufw no Ubuntu

Uncomplicated Firewall — wrapper amigável de iptables. Em quatro linhas você fecha a VPS para o mundo e abre só o que precisa. É o controle mais granular que você tem do lado da VM.

⌨️Configuração mínima

sudo ufw default deny incoming
sudo ufw default allow outgoing
sudo ufw allow 22/tcp        # SSH
sudo ufw allow 443/tcp       # HTTPS (se for expor)
sudo ufw enable
sudo ufw status verbose

⚠️Cuidado de iniciante

•Sempre ufw allow 22 antes de ufw enable — sob pena de se trancar fora da VPS
•Se mudou a porta SSH para 2222, abra a 2222 antes de fechar a 22
•Tenha uma sessão SSH aberta enquanto testa — se trancar fora, você ainda pode reverter

💡Comandos úteis

sudo ufw status numbered    # listar regras com índice
sudo ufw delete 3           # apagar regra 3
sudo ufw allow from 1.2.3.4 to any port 22  # só seu IP
sudo ufw disable            # desligar (em emergência)

🔑 SSH hardening

99% dos ataques contra VPS são scan automatizado de SSH na porta 22 com password fraca. Três ajustes simples eliminam quase tudo isso.

🛠️ Os 3 ajustes

1.
Chave-only: edite /etc/ssh/sshd_config, PasswordAuthentication no. Garante que sua chave funciona antes.
2.
Porta não-padrão: Port 2222 (ou outra). Não é segurança real, mas reduz drasticamente o ruído nos logs.
3.
fail2ban: instala com apt install fail2ban. Bana IPs após N tentativas falhas, automaticamente.

📋Passo-a-passo

# 1. Garantir chave funcionando (de outra sessão)
ssh-copy-id usuario@vps

# 2. Editar config
sudo nano /etc/ssh/sshd_config
# - PasswordAuthentication no
# - Port 2222
# - PermitRootLogin no

# 3. Abrir nova porta no firewall
sudo ufw allow 2222/tcp

# 4. Restart SSH (mantenha sessão atual aberta)
sudo systemctl restart sshd

# 5. Testar em nova sessão antes de fechar antiga
ssh -p 2222 usuario@vps

# 6. Fechar a 22 quando confirmou
sudo ufw delete allow 22/tcp

# 7. fail2ban
sudo apt install fail2ban
sudo systemctl enable --now fail2ban

⚠️Ordem importa

Nunca fechar a 22 antes de testar a 2222 funcionando. Nunca desabilitar password antes de confirmar que sua chave está autorizada. Sempre teste numa segunda sessão antes de matar a primeira.

📍 IP allowlist quando possível

Se você só acessa a VPS de dois lugares (casa + escritório), não tem motivo pro mundo inteiro tentar SSH. Restringir SSH a IPs conhecidos reduz a superfície de ataque a quase zero.

🌐 Como aplicar

Hostinger: painel → Firewall → adicionar regra "allow 22 from 1.2.3.4"
AWS: Security Group inbound rule, source = "My IP"
ufw: sudo ufw allow from 1.2.3.4 to any port 22
Hetzner: Cloud Firewall, source IPs específicos

⚠️Cuidado com IP dinâmico

Se sua casa muda IP toda madrugada (provedor residencial comum), você vai se trancar fora da VPS na manhã seguinte. Soluções:

•Tailscale — VPN mesh, IP fixo virtual
•VPN comercial com IP estático
•Bastion/jump host com IP fixo
•Dynamic DNS + script que atualiza ufw automaticamente

💡Combinação ideal

Tailscale + ufw allow só do range 100.x.x.x (Tailscale CGNAT). SSH só pelo Tailscale. Resto do mundo nem vê a porta 22 aberta.

🤖 Pedir auditoria pro próprio Hermes

Você não precisa virar SRE. O Hermes pode rodar a auditoria, listar o estado atual e sugerir hardening. Você revisa e aprova mudança por mudança.

💬 Prompt sugerido

"Faça auditoria do firewall e da configuração SSH desta VPS. Liste portas abertas (ss -tlnp, ufw status), serviços ouvindo, regras estranhas. Compare com o que faz sentido para um VPS rodando só o Hermes Agent. Proponha hardening em ordem de prioridade. Não execute mudanças sem minha aprovação."

📊 O que ele costuma achar

•Porta 8080 aberta de algum experimento antigo
•SSH ainda aceitando password
•Container Docker exposto direto na 0.0.0.0
•fail2ban não instalado ou jail desativada
•Pacotes do Ubuntu sem atualização há semanas

⚠️Sempre revise antes

Mudanças em SSH e firewall podem te trancar fora da VPS. Permissão para o agente executar comandos sensíveis deve ser once ou session, nunca always. Mantenha sempre uma sessão SSH aberta enquanto aprova mudanças.

🎯Resumo do módulo

✓

Defesa em camadas é mandatório — provedor + ufw + isolamento de container.

✓

Configure firewall do provedor (Hostinger/AWS) primeiro — bloqueia antes de chegar na VM.

✓

ufw no Ubuntu fecha tudo, abre só 22 e 443 — sempre allow 22 antes de enable.

✓

SSH hardening: chave-only, porta custom, fail2ban — elimina 99% dos ataques automatizados.

✓

IP allowlist com Tailscale resolve IP dinâmico — SSH só pelo range Tailscale.

✓

Peça auditoria ao Hermes — ele lista estado atual e propõe hardening.

Próximo módulo:

4.3 - 🪪 Princípio do menor privilégio + contas separadas

← Módulo Anterior Próximo Módulo →