"Minha VPS é nova, não preciso me preocupar" — eu já ouvi isso de gente experiente, sempre poucas semanas antes de o servidor ser invadido. Hardening não é opcional, é o custo de entrada. E não precisa ser caro: o checklist abaixo é rápido e gratuito.
1. Acesso só por chave SSH
Se você ainda entra por senha, já tá atrasado. Chave SSH + desativar login por senha:
ssh-keygen -t ed25519 -a 100
ssh-copy-id usuario@vps
Depois, no servidor:
# /etc/ssh/sshd_config
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
Pulo do gato:
PermitRootLogin no+ login só por chave elimina a classe mais comum de ataque: força bruta no root com senha de peão.
2. Firewall: só o que é usado
Porta aberta que não tem serviço é convite. UFW resolve:
ufw default deny incoming
ufw default allow outgoing
ufw allow ssh
ufw allow 80,443/tcp
ufw enable
3. Não viva no root
Dia a dia com usuário comum e sudo só quando precisa. Vivo no root e um apt desatento vira problema sério.
4. Backup local e isolado
Backup no mesmo disco do app não é backup. Com Docker, fácil e barato: um container só de backup que joga o dump num volume separado — e, melhor ainda, pra fora da máquina.
backup:
image: prodrigestivill/postgres-backup-local:16
volumes:
- ./dump:/backups
environment:
POSTGRES_DB: app
POSTGRES_USER: app
POSTGRES_PASSWORD: ${DB_PASSWORD}
SCHEDULE: "@daily"
BACKUP_KEEP: 14
Duas semanas de retenção, rodando sozinho, todo dia às 3h da manhã. Se o disco queimar, você tem o dump salvo em outro lugar — fora do host.
5. Monitoramento mínimo
"Serviço caiu e ninguém viu" não é aceitável. O mínimo: healthcheck no compose (o Docker reinicia sozinho se o app não responder + fica visível erro no status) e um ping externo que te avisa no WhatsApp/Telegram. Você não precisa de observabilidade enterprise pra dormir tranquilo — precisa saber que alguém vai te avisar.
O resultado
Com esse checklist: sem senha no root, uma porta extra aberta, backup que se faz sozinho e ninguém adormecido se seu sistema cair. É praticamente impossível fazer parte das estatísticas de VPS invadida por porta 22.
FAQ
Preciso fazer tudo isso antes do primeiro deploy?
O mínimo é o item 1 e 2 antes de expor o site. Os outros dá pra fazer em seguida, mas não deixe pra depois de algo grave acontecer.
E se eu só expor o site pelo Caddy?
Ótimo — menos superfície. O princípio continua: menos portas, menos risco.
Isso substitui monitoramento externo pago?
O essencial é não ficar cego. Se depois você quiser alertas mais refinados, ótimo. Mas comece pelo básico que se sustenta.
Bora colocar isso no teu negócio?
Eu cuido da VPS dos sistemas da Flashti com esse padrão (e mais um pouco). Se você quer publicar seu sistema sem medo de viver preocupado, me chama que a gente monta a base certa.