Servidor invadido: o que fazer se você suspeitar de invasão

Servidor invadido? Veja o que fazer nas primeiras horas: conter sem desligar, preservar evidências, trocar credenciais, reinstalar e comunicar a ANPD.

Para que serve

Este artigo é um roteiro do que fazer com um servidor invadido nas primeiras horas depois de perceber sinais de invasão: processos desconhecidos usando 100% de CPU, usuários ou chaves SSH que ninguém criou, arquivos com extensão estranha e nota de resgate, tráfego de saída anormal ou aviso de abuso vindo de terceiros. O objetivo é conter o dano, preservar o que for preciso para entender o que aconteceu e voltar a operar com segurança.

Pré-requisitos

• Acesso ao console IPMI/iLO pela Central do Cliente (ele continua funcionando mesmo com a rede do sistema bloqueada).
• Um computador limpo, fora do servidor suspeito, para trocar senhas e guardar anotações.
• Um local externo para copiar evidências (outro servidor, storage ou disco local).

O que fazer com um servidor invadido, passo a passo

1. Anote tudo desde o primeiro minuto. Registre data, hora (com fuso), o que você viu e cada ação que tomar. Isso é essencial para a investigação, para o seguro e para eventuais comunicações legais.
2. Contenha sem desligar. Desligar o servidor apaga a memória RAM, onde costumam estar pistas importantes (processos, conexões, chaves). Prefira cortar a comunicação:
   • Linux: pelo console IPMI/iLO, bloqueie todo tráfego exceto o seu IP, ou derrube a interface de rede (ip link set NOME_DA_INTERFACE down).
   • Windows: desabilite o adaptador de rede pelo console.
   • Proxmox: se o problema está numa VM, desconecte a placa de rede da VM (Hardware > Network Device > Disconnect) e mantenha a VM ligada.
   Se houver criptografia em andamento (ransomware ativo) e não for possível isolar a rede rapidamente, desligar passa a ser aceitável: salvar os dados é mais importante que preservar a RAM.
3. Preserve evidências antes de mexer. Numa VM do Proxmox, um snapshot com memória guarda o estado completo:

   qm snapshot 101 incidente_20261008 --vmstate 1 --description "Suspeita de invasao"

   Num servidor Linux, colete e copie para fora:

   mkdir /root/ir && cd /root/ir
   date -u > data.txt
   ps auxwwf > processos.txt
   ss -tunap > conexoes.txt
   last -F > logins.txt 2>&1
   journalctl --since "-7 days" > journal.txt
   cat /etc/passwd > passwd.txt
   for u in /root /home/*; do echo "== $u"; cat $u/.ssh/authorized_keys 2>/dev/null; done > chaves.txt
   crontab -l -u root > cron_root.txt 2>&1; ls -la /etc/cron* /var/spool/cron* > cron_dirs.txt 2>&1
   systemctl list-units --type=service --all > servicos.txt
   find / -xdev -mtime -7 -type f -not -path '/proc/*' 2>/dev/null > alterados_7dias.txt
   tar czf /root/ir.tgz /root/ir && sha256sum /root/ir.tgz

   No Windows, exporte os logs de Segurança, Sistema e PowerShell (Visualizador de Eventos > Salvar Todos os Eventos Como) e liste tarefas agendadas e serviços (schtasks /query /fo LIST /v e Get-Service). Copie para fora e anote o hash SHA-256 de cada arquivo.
4. Avalie o alcance. Responda: por onde entraram (SSH, RDP, aplicação web, painel)? Quais contas foram usadas? Há sinais em outras VMs ou servidores que compartilham senhas e chaves? Houve acesso a bancos de dados ou arquivos com dados pessoais? Os backups foram alcançados? Procure especialmente por eventos 4624/4625/4720/7045 no Windows e por logins de IPs desconhecidos no last e no journal.
5. Troque credenciais a partir de uma máquina limpa. Considere comprometido tudo que estava no servidor ou passou por ele: senhas de root/Administrador e de usuários, chaves SSH, senhas de bancos de dados, chaves de API, tokens de nuvem, credenciais de backup, senha da Central do Cliente (por onde se acessa o IPMI/iLO). Ative autenticação em dois fatores onde existir.
6. Reinstale; não tente "limpar". Um invasor com acesso administrativo pode ter deixado portas dos fundos difíceis de achar (rootkits, serviços, tarefas, chaves). O caminho seguro é reinstalar o sistema do zero pelo console IPMI/iLO, aplicar todas as atualizações e o endurecimento básico (veja os demais artigos desta categoria) antes de reconectar à internet.
7. Restaure dados de um backup anterior ao incidente e verifique se não estão adulterados. Não restaure binários, scripts ou crontabs antigos sem revisar. Corrija a falha de entrada antes de colocar o serviço no ar.
8. Comunique quem precisa saber.
   • Se houver dados pessoais e risco relevante aos titulares, a LGPD e a Resolução CD/ANPD nº 15/2024 exigem que o controlador comunique a ANPD e os titulares em até 3 dias úteis a partir do conhecimento do incidente. Essa comunicação é responsabilidade de quem controla os dados, ou seja, sua: a E-Consulters não administra o seu servidor nem os dados dele. Confirme prazos e obrigações com seu encarregado (DPO) e seu jurídico. Veja também o artigo «LGPD em servidor dedicado: o que é responsabilidade de quem hospeda os dados».
   • Ataques originados de outras redes podem ser notificados ao responsável pela rede de origem, com cópia para o CERT.br (cert@cert.br), incluindo logs com data, hora e fuso.
   • Em caso de extorsão, registre boletim de ocorrência. Autoridades como a CISA recomendam não pagar resgate: não há garantia de devolução dos dados.

Como saber se funcionou

• O servidor reinstalado não tem os usuários, chaves, serviços ou tarefas suspeitos encontrados na coleta.
• ss -tunap não mostra conexões de saída para IPs desconhecidos, e o consumo de CPU e rede voltou ao normal.
• Logins antigos (senhas e chaves trocadas) são recusados.
• Você sabe explicar por onde o invasor entrou e essa falha foi corrigida.

Problemas comuns

Recebi um aviso de abuso, mas não vejo nada de estranho

Mineradores e bots costumam se esconder com nomes de processos legítimos. Compare o consumo em top com o que você espera, revise conexões de saída em ss -tunap e procure binários em /tmp, /dev/shm e /var/tmp. Responda o aviso com o que encontrou e as ações tomadas.

Os backups também foram criptografados

Verifique se existe alguma cópia offline ou imutável. Se não houver, preserve os discos para análise especializada e não reinstale por cima. Depois, reveja a estratégia (veja o artigo «Proteção contra ransomware: backup 3-2-1 com cópia imutável e teste de restauração»).

Não sei por onde entraram

Não volte ao ar com a mesma configuração. Reinstale, restrinja ao máximo os serviços expostos (SSH e RDP só por VPN ou IP fixo) e atualize todas as aplicações antes de publicar. Se o ponto de entrada foi um site, veja também o artigo «WordPress invadido: como descobrir, limpar e evitar que aconteça de novo». Para detectar uma próxima tentativa mais cedo, veja o artigo «Detecção de intrusão no servidor Linux: como usar Wazuh, AIDE e auditd».

Perguntas frequentes

Como saber se meu servidor foi invadido?

Sinais comuns: processos desconhecidos usando muita CPU, usuários ou chaves SSH que ninguém criou, arquivos com extensão estranha e nota de resgate, tráfego de saída anormal ou aviso de abuso de terceiros.

Devo desligar o servidor invadido?

Em geral, não: desligar apaga a memória RAM, onde ficam pistas importantes. Corte a rede pelo console. A exceção é ransomware criptografando dados sem que seja possível isolar a rede rapidamente.

Dá para limpar o servidor em vez de reinstalar?

Não é seguro. Um invasor com acesso administrativo pode deixar portas dos fundos difíceis de achar. Reinstale do zero, atualize e restaure os dados de um backup anterior ao incidente.

Preciso comunicar a ANPD?

Se houver dados pessoais e risco relevante aos titulares, sim: o controlador deve comunicar a ANPD e os titulares em até 3 dias úteis. Confirme com seu DPO e seu jurídico.

A E-Consulters investiga a invasão?

Não, sem o serviço de Gerenciamento a investigação e a recuperação do sistema são responsabilidade do cliente. O suporte ajuda com console IPMI/iLO, rede e hardware.

Precisa de ajuda?

Para questões de acesso ao console IPMI/iLO, rede ou hardware do servidor durante o incidente, abra um ticket pela área do cliente.