Checklist mensal de segurança para servidor dedicado: atualizações, contas, portas expostas, backup testado, certificados, logs e discos.

Para que serve

Segurança não é configurada uma vez e esquecida: contas acumulam, portas são abertas "temporariamente", certificados vencem e backups param sem avisar. Este checklist mensal de segurança reúne, em cerca de uma hora, as verificações que mais evitam incidentes em um servidor dedicado com Proxmox VE, VMs Linux e Windows. Ele complementa o checklist das primeiras 24 horas, que trata da configuração inicial.

Pré-requisitos

  • Acesso administrativo ao host Proxmox, às VMs e ao gerenciador de senhas.
  • Uma máquina externa para testar portas (seu computador ou outro servidor).
  • Um lugar para registrar o resultado (planilha, wiki ou ticket interno), com data e responsável.

1. Atualizações e reinicializações pendentes

  1. Linux e host Proxmox:
    sudo apt update && apt list --upgradable
    ls /var/run/reboot-required 2>/dev/null && echo "Reinicialização pendente"
    sudo needrestart -r l   # serviços usando bibliotecas antigas
  2. Proxmox: confira a versão com pveversion e as notas de lançamento antes de atualizar.
  3. Windows Server:
    Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 5
    Confirme que a atualização cumulativa do mês foi instalada.
  4. Aplicações: CMS, plugins, painéis, bancos de dados, imagens Docker (docker compose pull) e firmware do firewall virtual.
  5. Compare o que você usa com o catálogo KEV da CISA (vulnerabilidades sendo exploradas ativamente). Itens dessa lista têm prioridade máxima.

2. Contas, chaves e acessos

  1. Usuários com shell e administradores no Linux:
    awk -F: '$7 !~ /(nologin|false)$/ {print $1}' /etc/passwd
    getent group sudo
    sudo find / -xdev -name authorized_keys -exec sh -c 'echo "== $1"; cat "$1"' _ {} \; 2>/dev/null
  2. Proxmox:
    pveum user list
    pveum user token list root@pam
    Remova quem saiu da equipe e tokens sem uso. Confira se todos os administradores têm 2FA.
  3. Windows:
    Get-LocalUser | Where-Object Enabled | Select-Object Name, LastLogon
    Get-LocalGroupMember -Group "Administradores"
  4. Gerenciador de senhas: membros da organização, coleções compartilhadas e relatório de senhas fracas ou reutilizadas.
  5. Contas externas: área do cliente, registrador de domínio, DNS e e-mail do administrador, todas com 2FA e e-mail de recuperação correto.

3. Superfície exposta

  1. De uma máquina externa, varra o seu bloco de IPs (veja o artigo sobre escanear o servidor):
    sudo nmap -Pn --top-ports 1000 203.0.113.0/28
    Só devem aparecer as portas que você decidiu publicar.
  2. No host e nas VMs, compare com o que está escutando:
    sudo ss -tulpn
  3. Revise regras de firewall do Proxmox, do firewall virtual e do Windows. Apague regras "temporárias" e redirecionamentos de porta esquecidos.
  4. Rode o Lynis e compare o índice com o mês anterior.

4. Backup: teste de restauração

  1. Confirme que os jobs do último mês terminaram com sucesso (Datacenter → Backup e o histórico de tarefas, ou o painel do Proxmox Backup Server).
  2. Restaure de verdade uma VM ou um banco por mês, alternando, em uma VM de teste sem rede pública. Backup que nunca foi restaurado é só uma esperança.
  3. Confira se existe cópia fora do servidor e se ela não pode ser apagada com as mesmas credenciais da produção.
  4. No PBS, verifique o resultado dos jobs de Verify e de Garbage Collection.

5. Certificados e domínios

  1. Validade dos certificados (a Let's Encrypt não envia mais e-mails de aviso de expiração):
    echo | openssl s_client -connect www.exemplo.com.br:443 -servername www.exemplo.com.br 2>/dev/null | openssl x509 -noout -enddate
    sudo certbot certificates
  2. Renovação automática funcionando: systemctl list-timers | grep certbot e sudo certbot renew --dry-run.
  3. Certificado da interface do Proxmox (porta 8006) e de serviços internos.
  4. Data de expiração dos domínios no registrador e renovação automática ativa.
  5. Nota no SSL Labs dos sites principais.

6. Logs e alertas

  1. Tentativas de login no SSH e logins bem-sucedidos:
    sudo journalctl -u ssh --since "-30 days" | grep -c "Failed"
    last -n 20
    sudo lastb -n 20
    (No Debian 13 e Ubuntu 24.04, prefira journalctl _COMM=sshd se last/lastb não existirem.)
  2. Windows: falhas de logon (evento 4625) e logons por RDP (evento 4624, tipo 10) no Visualizador de Eventos.
  3. Bloqueios do fail2ban/CrowdSec: sudo fail2ban-client status sshd ou sudo cscli decisions list.
  4. Relatórios do AIDE, eventos do auditd ou alertas do Wazuh, se usados.
  5. Teste se os alertas ainda chegam: provoque um evento simples (um login com senha errada) e veja se o aviso aparece.

7. Saúde do hardware e dos discos

  1. ZFS:
    zpool status -x
    zpool list
    A resposta esperada é all pools are healthy. Confira se o scrub mensal rodou (zpool status mostra a data).
  2. SMART dos discos:
    sudo smartctl -H /dev/nvme0n1
    sudo smartctl -A /dev/nvme0n1 | grep -i -E "percentage used|media|error"
  3. Espaço livre no host, nos datastores e nas VMs (df -h). Disco cheio derruba bancos de dados e interrompe backups.
  4. Alertas de hardware no console IPMI/iLO (log de eventos do sistema).

8. Registro do checklist mensal de segurança e próximos passos

  1. Anote data, quem executou, o que foi encontrado e o que foi corrigido.
  2. Abra tarefas para o que não deu para resolver na hora, com prazo.
  3. Atualize o inventário de sistemas e de dados pessoais, se algo mudou (veja o artigo sobre LGPD).

Como saber se funcionou

  • Há um registro para cada mês, com responsável e pendências acompanhadas.
  • Nenhuma surpresa no nmap externo, nenhuma conta órfã e nenhum certificado vencendo nos próximos 20 dias.
  • O último teste de restauração foi há menos de 30 dias e funcionou.

Problemas comuns

  • Checklist abandonado depois de dois meses: marque um horário fixo no calendário e divida os blocos entre pessoas.
  • Atualização pendente porque "não pode reiniciar": combine uma janela mensal de manutenção com os usuários. Servidor que nunca reinicia acumula falhas no kernel.
  • Comando não encontrado: instale o pacote correspondente (needrestart, smartmontools, nmap).

Perguntas frequentes

Mensal é suficiente?

Para a rotina, sim. Atualizações críticas e alertas de invasão não esperam o checklist: trate-os assim que surgirem.

Posso automatizar o checklist?

Boa parte, sim: monitoramento de certificados, SMART, ZFS e jobs de backup com alertas automáticos. O teste de restauração e a revisão de contas continuam exigindo olhar humano.

O que entra no checklist anual?

Revisão do desenho de rede e da segmentação, simulação de incidente (restaurar o ambiente inteiro a partir do backup), revisão de contratos e do inventário de dados, e troca de credenciais compartilhadas.

Leitura complementar

Precisa de ajuda?

Se o checklist apontar alerta de hardware no IPMI/iLO, disco com falha ou qualquer problema na infraestrutura física, abra um ticket ou chame o suporte 24/7.

Esta resposta lhe foi útil? 0 Usuários acharam útil (0 Votos)

Leia também