Hardening de Servidor Linux: Como Transformei um VPS Pelado em Fortaleza Digital

PorOlivetto

Se você acabou de alugar um VPS e acha que o padrão da provedora é “seguro o suficiente”, tenho uma notícia: na primeira noite, já tinham 200 tentativas de login SSH. E isso é um dia tranquilo.

Neste artigo, vou te mostrar como eu transformei um servidor Ubuntu pelado em algo que respira segurança — firewall UFW, Fail2Ban, SSH blindado e monitoramento básico. Sem teoria de livro, só o que funciona na prática. O que eu fiz, o que errei, e o que você deve copiar.

A segurança de servidores Linux não é opcional — é a diferença entre dormir tranquilo e acordar com um criptominador rodando na sua máquina. Vamos lá.

Sala de servidores com iluminação azul em datacenter moderno representando infraestrutura segura

Por que o servidor padrão é um convite aberto

Provedoras de VPS entregam máquinas com configurações pensadas em funcionar, não em segurar. Isso significa:

  • SSH na porta 22 com login por senha ativado
  • Nenhum firewall configurado
  • Root habilitado para login direto
  • Nenhum sistema de detecção de intrusão
  • Sem atualizações automáticas de segurança

Tradução: é como deixar a porta de casa aberta com uma plaquinha “entre, por favor”. Bots varrem a internet inteira 24/7 procurando exatamente isso.

Passo 1 — Atualize tudo antes de mais nada

Sério, antes de configurar qualquer coisa:

sudo apt update && sudo apt upgrade -y
sudo apt autoremove -y
sudo apt install ufw fail2ban unattended-upgrades -y

Ative atualizações automáticas de segurança:

sudo dpkg-reconfigure -plow unattended-upgrades

Selecione “Yes”. Pronto, agora patches de segurança entram sozinhos. Esse é o tipo de automação que salva emprego.

Passo 2 — SSH blindado: a primeira muralha

2.1 Gerando chaves SSH (sem senha, sem drama)

Na sua máquina local, não no servidor:

ssh-keygen -t ed25519 -C "alisson@automente" -f ~/.ssh/automente_vps

Envie para o servidor:

ssh-copy-id -i ~/.ssh/automente_vps.pub root@SEU_IP

2.2 Desativando login por senha e root direto

Edite /etc/ssh/sshd_config:

# /etc/ssh/sshd_config
PermitRootLogin prohibit-password
PasswordAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
ClientAliveInterval 300
ClientAliveCountMax 2

Atenção: antes de reiniciar o SSH, teste a conexão com chave em outro terminal. Se funcionar, aí sim:

sudo systemctl restart sshd

Se você travar pra fora do servidor, é reiniciar pelo painel da provedora e tentar de novo. Já fiz isso. Duas vezes. Na mesma semana.

🧱 Box do Perrengue: O dia que eu me tranquei fora

Configurei PasswordAuthentication no, reiniciei o SSH, fechei o terminal comemorando. Aí percebi que não tinha copiado a chave privada pro celular. Resultado: madrugada, sem acesso, VPS inacessível até o suporte da provedora responder. Moral da história: sempre teste em uma segunda conexão ANTES de fechar a primeira.

Passo 3 — UFW: firewall que até eu consigo usar

O UFW (Uncomplicated Firewall) é o iptables pra quem quer viver, não sofrer:

# Regras padrão: bloqueia tudo que não for explicitamente permitido
sudo ufw default deny incoming
sudo ufw default allow outgoing

# Libera SSH (IMPORTANTE: faça isso ANTES de ativar)
sudo ufw allow 22/tcp

# Se rodar web server:
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

# Ativa o firewall
sudo ufw enable

# Verifica
sudo ufw status verbose

Simples? Sim. Eficiente? Muito. O UFW bloqueia tudo que não está na lista branca. Seu servidor acaba de ficar 90% mais silencioso pro mundo exterior.

Tela de erro em terminal de datacenter representando falhas de segurança em servidores

Passo 4 — Fail2Ban: o cachorro bravo da porta

O firewall bloqueia portas. O Fail2Ban bloqueia comportamento suspeito. Se alguém tenta 5 logins SSH errados, banido por 30 minutos. Simples assim.

4.1 Configuração mínima que funciona

Crie /etc/fail2ban/jail.local (nunca edite o jail.conf original):

[DEFAULT]
bantime = 3600
findtime = 600
maxretry = 3
banaction = ufw

[sshd]
enabled = true
port = ssh
filter = sshd
logpath = /var/log/auth.log
maxretry = 3
bantime = 7200

Ative e verifique:

sudo systemctl enable fail2ban
sudo systemctl start fail2ban
sudo fail2ban-client status sshd

Em poucas horas, você vai ver IPs banidos acumulando. É satisfatório de um jeito estranho.

4.2 Protegendo outros serviços

[nginx-http-auth]
enabled = true
filter = nginx-http-auth
port = http,https
logpath = /var/log/nginx/error.log

[recidive]
enabled = true
bantime = 86400
findtime = 86400
maxretry = 2

A jail recidive é a cereja do bolo: se um IP foi banido mais de uma vez em 24h, toma ban de 24h direto. Reincidente? Pior pra ele.

Passo 5 — Monitoramento: saber antes de explodir

5.1 Logs que importam

# Tentativas de SSH
sudo journalctl -u sshd | grep "Failed password"

# Bans do Fail2Ban
sudo fail2ban-client status sshd

# Conexões ativas
sudo ss -tulpn

# Uso de disco (cheio = dor)
df -h

5.2 Script de checagem rápida

Crie /usr/local/bin/security-check.sh:

#!/bin/bash
echo "=== UFW Status ==="
sudo ufw status numbered
echo ""
echo "=== Fail2Ban Bans ==="
sudo fail2ban-client status sshd
echo ""
echo "=== Top IPs tentando SSH ==="
sudo journalctl -u sshd --since "24 hours ago" | \
  grep "Failed password" | \
  awk '{print $(NF-3)}' | \
  sort | uniq -c | sort -rn | head -5
echo ""
echo "=== Disk Usage ==="
df -h | grep -E "^/dev"
sudo chmod +x /usr/local/bin/security-check.sh

Coloque no cron pra rodar diariamente e mandar o resultado por email ou Telegram (via bot). Automação que salva.

Passo 6 — Camada extra: mudar a porta SSH

Isso não é segurança real — é security through obscurity. Mas reduz o ruído de bots em 95%:

# Em /etc/ssh/sshd_config
Port 2222

Não esqueça: libere a porta nova no UFW ANTES de reiniciar o SSH:

sudo ufw allow 2222/tcp
sudo systemctl restart sshd

Conecte com ssh -p 2222 user@ip. Se funcionou, pode remover a porta 22 do UFW.

Passo 7 — Backups: o seguro de vida que ninguém usa até precisar

Nenhuma configuração de segurança importa se você não tem backup. Ponto.

# Backup diário automatizado
sudo tar -czf /backup/server-$(date +%Y%m%d).tar.gz \
  /etc/ssh/ \
  /etc/fail2ban/ \
  /etc/ufw/ \
  /var/log/auth.log

# Rote para armazenamento externo (S3, B2, outro VPS)
# Use rclone ou rsync over SSH

Coloque isso no cron e esqueça. Até o dia que precisar. Aí vai agradecer.

Checklist final: sua fortaleza digital

  • ✅ Sistema atualizado com patches automáticos
  • ✅ SSH com chave, sem senha, root bloqueado
  • ✅ UFW ativo com lista branca de portas
  • ✅ Fail2Ban protegendo SSH e web server
  • ✅ Porta SSH alterada (opcional mas recomendado)
  • ✅ Monitoramento de logs automatizado
  • ✅ Backups diários em local externo
  • ✅ Firewall testado e documentado

E agora, qual é a sua maior dor de cabeça com segurança?

Se você chegou até aqui, já tem conhecimento suficiente pra blindar 90% dos servidores que rodam na web. Mas cada realidade é diferente. Qual automação de segurança você quer ver aqui no AutoMente? VPN com WireGuard? Certificados SSL automatizados? Detecção de intrusão com OSSEC?

Comenta aí. O próximo artigo pode ser a solução que você precisa.

E se conhece alguém que ainda usa senha “admin123” no servidor — manda esse link. A gente agradece, e o servidor também. 😉

Posts Similares