Checklist de segurança para VPS Linux antes de colocar serviços em produção: hardening, SSH, backups e monitoramento

Por · Publicado em · Atualizado em · 9 min de leitura

Mãos de pessoa em terno segurando prancheta com documentos e caneta, foco nas mãos e prancheta
Revisão do checklist e responsabilidades antes de colocar serviços em produção. Foto: Mikhail Nilov / Pexels

Antes do go‑live, use este checklist de segurança para VPS Linux antes de colocar serviços em produção (hardening, SSH, backups, monitoramento). Ele traz passos práticos para reduzir superfície de ataque, proteger acesso, ativar TLS, configurar firewall e alertas, e validar backups. Aplique como lista de conferência para chegar à produção com menos riscos e recuperação mais rápida.

Como usar este checklist de forma prática

Trate cada seção como uma etapa obrigatória antes do go‑live. Marque o que foi feito e registre evidências: comandos executados, arquivos alterados e capturas de tela dos painéis de monitoramento.

Aplique em três momentos: na preparação inicial da VPS, antes de cada release significativa e após incidentes. Reavalie permissões, portas abertas e políticas de atualização regularmente.

Integre ao seu controle de mudanças: versionamento de arquivos de configuração, PRs revisados e aprovações. Guarde as evidências em um repositório interno para auditoria.

Se sua equipe usa runbooks, integre este checklist. Ele é complementar a políticas de segurança e não as substitui.

  • Defina um responsável por cada etapa.
  • Registre data e resultado da verificação.
  • Automatize onde for possível (scripts e IaC).

Contas, privilégios e acesso seguro

Separe contas administrativas das de aplicação. Desabilite login direto do root e use sudo apenas quando necessário. Autenticação deve ser por chaves SSH, nunca por senha em produção.

Restrinja quem pode acessar via SSH e considere segundo fator (TOTP/U2F) e/ou um bastion host para acesso mediado. Veja o guia de bastion com 2FA em bastion SSH com chaves e 2FA.

Mantenha chaves rotacionadas e remova acessos de ex‑colaboradores. Para serviços, prefira tokens de curta duração e segredos fora do código.

  • Conta administrativa dedicada (ex.: deploy).
  • Root sem login remoto.
  • Sudo com registro (sudo -l e logs).
  • Chaves SSH fortes e rotacionadas.
  • Acesso por IPs conhecidos ou VPN.
# criar usuário administrativo e configurar SSH por chave
adduser deploy
usermod -aG sudo deploy
mkdir -p ~deploy/.ssh && chmod 700 ~deploy/.ssh
# cole sua chave pública no arquivo abaixo
nano ~deploy/.ssh/authorized_keys
chmod 600 ~deploy/.ssh/authorized_keys
chown -R deploy:deploy ~deploy/.ssh

# desabilitar login root por SSH e reiniciar serviço
sed -i 's/^#\?PermitRootLogin.*/PermitRootLogin no/' /etc/ssh/sshd_config
systemctl reload sshd || service ssh restart

Sistema atualizado e serviços mínimos

Mantenha o sistema atualizado e ative atualizações de segurança automáticas. Após upgrades de kernel, programe janelas de reboot. Remova pacotes e serviços que não são necessários para diminuir a superfície de ataque.

Revise serviços habilitados na inicialização e desative o que não precisar. Use varreduras pontuais para checar pacotes expostos desatualizados.

Considere remover ferramentas de compilação em hosts de produção, desinstalar servidores que não serão usados e bloquear módulos de kernel desnecessários quando fizer sentido.

  • Atualizações aplicadas e pendências resolvidas.
  • Atualizações de segurança automáticas ativas.
  • Serviços desnecessários removidos.
  • Reboot agendado após kernel update.
# atualizar sistema e configurar atualizações automáticas (Debian/Ubuntu)
apt update && apt full-upgrade -y
apt install -y unattended-upgrades
# assistente para ativar atualizações automáticas
DPKG_FRONTEND=noninteractive dpkg-reconfigure --priority=low unattended-upgrades

# listar serviços habilitados para revisar
systemctl list-unit-files --type=service --state=enabled

Firewall e endurecimento de rede

Aplique política padrão de negar (deny) entradas e permitir saídas, liberando apenas portas necessárias. Limite tentativas de conexão ao SSH. Endureça parâmetros de rede com sysctl para mitigar scans e spoofing.

Para IPv6, garanta regras equivalentes às de IPv4. Faça varredura externa (nmap) a partir de outra máquina para confirmar somente o necessário exposto.

Para um passo a passo com UFW, veja o guia de firewall no Ubuntu com UFW.

  • Política padrão: deny incoming, allow outgoing.
  • Portas mínimas abertas (80/443 e 22 quando necessário).
  • Rate‑limit no SSH (UFW limit).
  • sysctl com proteção a IP spoofing e SYN cookies.
  • Regras consistentes para IPv6 (se ativo).
Porta/Serviço Estado recomendado Como verificar
22 / SSH Aberta, limitada e/ou por IP ufw status | grep 22
80 / HTTP Aberta apenas se houver app web ufw status | grep 80
443 / HTTPS Aberta para TLS ufw status | grep 443
9100 / Node Exporter Restrita por IP ou fechada ufw status | grep 9100
5432 / PostgreSQL Fechada (somente interno) ss -tulpn | grep 5432 
# política de firewall com UFW
ufw default deny incoming
ufw default allow outgoing
ufw allow 80,443/tcp
ufw allow 22/tcp && ufw limit 22/tcp
ufw enable
ufw status verbose

SSH endurecido e, se possível, com bastion

Fortaleça o sshd_config para chaves somente, número reduzido de tentativas e keepalive curto. Evite mudar a porta 22 como única defesa; priorize autenticação forte e restrição por IP/VPN.

Para acessos de equipes e terceiros, centralize em um bastion com registro e 2FA. Veja o passo a passo em bastion SSH com chaves e 2FA.

Use fail2ban para bloquear tentativas maliciosas e defina AllowUsers/AllowGroups explicitamente. Revise periodicamente os logs de auth para sinais de brute force.

  • Somente chaves (sem senha).
  • PermitRootLogin no.
  • MaxAuthTries baixo (ex.: 3).
  • AllowUsers com lista explícita.
  • Keepalive para desconectar sessões inativas.
# /etc/ssh/sshd_config (trecho recomendado)
Port 22
Protocol 2
PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
ClientAliveInterval 300
ClientAliveCountMax 2
# restrinja usuários autorizados
AllowUsers deploy
UsePAM yes
# ative ChallengeResponseAuthentication apenas se usar 2FA via PAM
# ChallengeResponseAuthentication yes

TLS, HTTPS e segurança nas aplicações

Use HTTPS em todo tráfego público. Automatize emissão e renovação de certificados com ACME, e aplique políticas como HSTS e redirecionamento 80→443. Configure proxies reversos com mínimos cabeçalhos de segurança.

Avalie protocolos e cifras suportadas, removendo versões obsoletas. Habilite stapling de OCSP e ALPN quando aplicável. Em HSTS, cuidado com subdomínios se ainda há serviços sem TLS.

Se precisa de um guia prático, veja como gerar certificados em SSL grátis com Let's Encrypt.

  • Certificados válidos e renovação automatizada.
  • Redirecionamento de HTTP para HTTPS.
  • HSTS habilitado quando aplicável.
  • TLS moderno e sem protocolos obsoletos.
# emitir certificado usando o modo standalone (pare o serviço HTTP temporariamente)
apt update && apt install -y certbot
certbot certonly --standalone \
  -d example.com -d www.example.com \
  --agree-tos -m [email protected] --no-eff-email
# teste de renovação
certbot renew --dry-run

Monitoramento, logs e alertas acionáveis

Colete métricas de sistema (CPU, memória, disco, rede), disponibilidade e erros de aplicações. Configure alertas com limiares claros e responsáveis. Retenha logs com rotação e centralização quando possível.

Adicione verificações de uptime a partir de fora da VPS. Alerta de pré‑vencimento de certificados, falhas de backup e uso de disco previnem incidentes. Documente quem atende alertas e o playbook de resposta.

Para visualizar métricas, combine Prometheus e Grafana. Há um guia com Docker Compose em configurar Prometheus e Grafana.

  • Métricas de host (Node Exporter).
  • Dashboards de serviços críticos.
  • Alertas para disco cheio, OOM e picos de latência.
  • Logs com rotação e retenção definida.
  • fail2ban para banir IPs maliciosos.
# instalar métricas básicas do host (Debian/Ubuntu)
apt update && apt install -y prometheus-node-exporter
systemctl enable --now prometheus-node-exporter
# restrinja a porta 9100 ao IP do Prometheus (exemplo)
ufw allow from 203.0.113.10 to any port 9100 proto tcp

Backups testados e plano de recuperação

Defina o que será salvo: bases de dados, arquivos de aplicação, configurações e segredos. Faça backups automáticos, externos à VPS, com retenção e criptografia. O ponto crítico é o teste de restauração: simule a recuperação periodicamente.

Integre checagens de integridade, alertas de falha e espaço em disco. Documente quem aciona o plano e em quanto tempo cada serviço deve retornar. Cuidado ao armazenar chaves e senhas no script.

Estabeleça RPO/RTO realistas, valide restores em ambiente isolado e guarde passphrases fora da VPS. Se usar snapshots do provedor, combine com dumps consistentes das bases.

  • Backups automáticos off‑site e criptografados.
  • Testes de restauração regulares.
  • Retenção por camadas (diário/semanal/mensal).
  • Documentação do plano de recuperação.
  • Acesso restrito às chaves de backup.
#!/usr/bin/env bash
# backup básico (exemplo). Ajuste caminhos e credenciais.
set -euo pipefail
TS=$(date +%F-%H%M)
HOST=$(hostname -s)
BACKUP_DIR=/var/backups
REMOTE="[email protected]:/backups/${HOST}/"

mkdir -p "$BACKUP_DIR/db" "$BACKUP_DIR/files"

# dumps (ajuste usuários e senhas via .pgpass/.my.cnf ou variáveis seguras)
pg_dumpall | gzip > "$BACKUP_DIR/db/postgres-$TS.sql.gz" || true
mysqldump --all-databases --single-transaction | gzip > "$BACKUP_DIR/db/mysql-$TS.sql.gz" || true

# arquivos críticos
tar czf "$BACKUP_DIR/files/etc-$TS.tgz" /etc
tar czf "$BACKUP_DIR/files/app-$TS.tgz" /var/www || true

# sincronizar para armazenamento externo
rsync -az --delete "$BACKUP_DIR/" "$REMOTE"

# retenção local de 7 dias
find "$BACKUP_DIR" -type f -mtime +7 -delete

echo "Backup concluído em $TS"

Perguntas frequentes

Com que frequência devo rodar este checklist na VPS?

Use na preparação inicial, antes de cada release relevante e após qualquer incidente. Para manutenção, revise mensalmente pontos críticos como atualizações, portas abertas, falhas de login, uso de disco, status de backups e alertas. Ajuste a cadência conforme criticidade do serviço.

Trocar a porta 22 aumenta a segurança do SSH?

Mudar a porta reduz ruído de scans automatizados, mas não substitui medidas essenciais: autenticação por chave, desabilitar senhas e root, limitar tentativas e, idealmente, restringir por IP ou VPN. Use a troca de porta apenas como complemento, não como defesa principal.

UFW é suficiente ou devo usar iptables diretamente?

Para a maioria dos cenários, UFW é suficiente e menos sujeito a erros. Ele gera regras iptables por baixo. Se você precisa de regras avançadas, múltiplas tabelas e marcações, pode configurar iptables ou nftables diretamente, mantendo documentação e testes de regressão.

Como validar que os backups realmente funcionam?

Faça restaurações de teste em ambiente isolado. Verifique integridade dos arquivos, consistência das bases e se o sistema volta a operar. Documente o tempo de recuperação e passos. Automatize verificações de sucesso dos jobs e alerte em falhas ou tempos acima do esperado.

Quais métricas devo monitorar em uma VPS de produção?

Monitore CPU, memória, disco (uso e IO), latência de rede, conexões, erros de aplicação, tempos de resposta, filas e taxas de erro por endpoint. Adicione alertas para disco cheio, OOM, quedas de serviço, certificados próximos do vencimento e falhas nos jobs de backup.

Precisa de ajuda para aplicar o checklist na sua VPS?

Podemos estruturar hardening, backups e monitoramento com documentação e scripts reprodutíveis, alinhados ao seu ambiente.

Falar sobre hardening e manutenção

Veja também