Entenda servidor comprometido: contenção e recuperação

19 min de leitura  ·  Guia técnico

Servidor comprometido exige contenção imediata: isole o host da rede, preserve evidências voláteis, identifique o vetor de entrada e recupere o ambiente com limpeza limitada ou reinstalação completa, conforme a gravidade. Em Linux, a ordem correta é conter, investigar e só depois restaurar o serviço com hardening aplicado.

1. Isole o servidor bloqueando conexões de entrada e saída no firewall imediatamente.
2. Preserve logs e tire um snapshot do estado atual antes de qualquer alteração.
3. Identifique o vetor de entrada analisando logs de autenticação e processos ativos.
4. Remova ou desative backdoors, contas não autorizadas e processos maliciosos encontrados.
5. Decida entre limpeza cirúrgica ou reinstalação completa do sistema operacional.
6. Restaure a partir de backup limpo, aplique hardening e monitore ativamente após a recuperação.

Pré-requisitos para executar este procedimento

• Acesso root ou sudo ao servidor (via SSH ou console de emergência do provedor).
• Distribuição Linux compatível: Ubuntu 24.04 LTS, Debian 12, Rocky Linux 9 ou AlmaLinux 9.
• Acesso ao painel do provedor para gerenciar regras de firewall de rede e criar snapshots.
• Backup recente do servidor em local externo (anterior à data suspeita de comprometimento).
• Ferramentas disponíveis: chkrootkit, rkhunter, netstat, ss, auditd, last, who.
• Conhecimento básico de linha de comando Linux e administração de serviços com systemctl.

Como identificar sinais de servidor comprometido

Detectar um servidor invadido exige atenção a indicadores de comprometimento (IoCs) distribuídos em diferentes camadas do sistema. Antes de qualquer ação, colete evidências sem modificar o estado do servidor.

Verificar logins e sessões ativas suspeitas

O primeiro passo é auditar quem está conectado e quem se conectou recentemente:

who
last -n 30
lastb -n 20

Output esperado (exemplo de login suspeito):
root     pts/1        203.0.113.45     Tue Jan 14 03:22   still logged in
root     pts/0        198.51.100.12    Tue Jan 14 02:58 - 03:01  (00:03)

IPs desconhecidos, horários incomuns (madrugada) e sessões ainda ativas de usuários que não deveriam estar conectados são sinais claros de invasão.

Inspecionar processos e conexões de rede anômalas

Processos maliciosos frequentemente se disfarçam com nomes genéricos ou ficam ocultos. Verifique:

ps aux --sort=-%cpu | head -20
ss -tulnp
netstat -tulnp

Output esperado (exemplo suspeito):
tcp   LISTEN  0  128  0.0.0.0:4444  0.0.0.0:*  users:(("nc",pid=1337,fd=3))

Portas abertas incomuns (como 4444, 1337, 31337) e processos como nc (netcat), python3 -c ou binários em /tmp são indicadores críticos de comprometimento ativo.

Verificar arquivos modificados recentemente

Invasores frequentemente alteram binários do sistema ou instalam webshells. Localize arquivos modificados nas últimas 24 horas:

find /usr /bin /sbin /lib /etc -mtime -1 -type f 2>/dev/null
find /var/www -name "*.php" -mtime -3 -type f 2>/dev/null

Qualquer binário do sistema modificado recentemente sem uma atualização justificada é um sinal grave. Webshells PHP em diretórios web são vetores comuns de persistência.

Checar contas de usuário criadas sem autorização

cat /etc/passwd | grep -v nologin | grep -v false
awk -F: '$3 == 0 {print}' /etc/passwd

Output esperado (conta suspeita com UID 0):
backdoor:x:0:0::/root:/bin/bash

Qualquer conta com UID 0 além de root, ou contas desconhecidas com shell válido, indica que o invasor criou acesso persistente.

Contenção imediata do servidor comprometido

A fase de contenção de incidente de segurança tem um único objetivo: impedir que o invasor continue agindo ou que o comprometimento se espalhe para outros sistemas. Aja com rapidez, mas sem apagar evidências.

Isolar o servidor com firewall

Atenção: os comandos abaixo bloqueiam todas as conexões de entrada e saída. Você perderá acesso SSH remoto. Execute apenas se tiver acesso ao console de emergência do provedor (KVM/VNC).

iptables -I INPUT -j DROP
iptables -I OUTPUT -j DROP
iptables -I FORWARD -j DROP

Se preferir manter acesso SSH apenas do seu IP para continuar a investigação remotamente, substitua por:

SEU_IP="203.0.113.10"
iptables -I INPUT ! -s $SEU_IP -j DROP
iptables -I OUTPUT ! -d $SEU_IP -j DROP

No painel da AviraHost, você também pode aplicar regras de firewall de rede diretamente na infraestrutura, antes mesmo de chegar ao sistema operacional — isso é mais seguro quando o servidor está totalmente comprometido.

Preservar evidências voláteis antes de qualquer reinicialização

Nunca reinicie o servidor imediatamente após detectar uma invasão. A memória RAM contém processos, conexões e chaves de criptografia que desaparecem com o reboot. Capture o estado atual:

ps auxf > /tmp/processos_$(date +%Y%m%d_%H%M%S).txt
ss -tulnp > /tmp/conexoes_$(date +%Y%m%d_%H%M%S).txt
last -n 100 > /tmp/logins_$(date +%Y%m%d_%H%M%S).txt
cp /var/log/auth.log /tmp/auth_backup.log
cp /var/log/syslog /tmp/syslog_backup.log

Copie esses arquivos para um local externo seguro via SCP antes de continuar. Se o provedor oferecer snapshot, tire um agora — ele preserva o estado completo do disco para análise forense posterior.

Encerrar sessões ativas do invasor

Se identificou uma sessão SSH ativa do invasor, encerre-a sem fechar a sua própria:

who -u

root     pts/1        Jan 14 03:22   0:05      1337 (203.0.113.45)

kill -9 1337

Altere imediatamente a senha do root e de todos os usuários com shell válido após encerrar a sessão:

passwd root
passwd usuario_suspeito

Consulte também o guia Como trocar a senha do usuário root do servidor VPS ou Dedicado para o procedimento completo.

Investigação forense: identificar o vetor de entrada

A análise forense de servidor Linux comprometido é essencial para entender como a invasão ocorreu e evitar que se repita. Sem identificar o vetor, a recuperação é incompleta.

Analisar logs de autenticação SSH

grep "Accepted" /var/log/auth.log | tail -50
grep "Failed password" /var/log/auth.log | awk '{print $11}' | sort | uniq -c | sort -rn | head -20

Output esperado:
   4521 192.0.2.88
   1203 198.51.100.77
      1 203.0.113.45

Um IP com milhares de tentativas falhas seguido de um login bem-sucedido indica ataque de força bruta bem-sucedido. Em Rocky Linux 9 e AlmaLinux 9, os logs ficam em /var/log/secure em vez de /var/log/auth.log.

Verificar histórico de comandos executados

cat /root/.bash_history
cat /home/*/.bash_history
find / -name ".bash_history" 2>/dev/null -exec cat {} \;

Invasores frequentemente limpam o histórico, mas às vezes esquecem. Procure por comandos como wget, curl, chmod 777, crontab -e e downloads de scripts externos.

Verificar crontabs maliciosos

Persistência via cron é uma das técnicas mais comuns após comprometimento:

crontab -l
crontab -l -u root
cat /etc/crontab
ls -la /etc/cron.d/ /etc/cron.hourly/ /etc/cron.daily/
for user in $(cut -f1 -d: /etc/passwd); do echo "=== $user ==="; crontab -u $user -l 2>/dev/null; done

Entradas que executam scripts de /tmp, /dev/shm ou URLs externas são backdoors de persistência e devem ser removidas imediatamente.

Escanear rootkits com chkrootkit e rkhunter

apt install chkrootkit rkhunter -y
chkrootkit
rkhunter --update
rkhunter --check --sk

Output esperado (exemplo de detecção):
Checking for rootkits...
Performing check of known rootkit files and directories
  55808 Trojan - Variant A [ Not found ]
  ADM Worm                  [ Not found ]
  ...
Warning: The command '/usr/bin/lwp-request' has been replaced by a script

Em Debian 12, verifique também a integridade dos pacotes instalados:

debsums -c 2>/dev/null | head -30

Em Rocky Linux 9 ou AlmaLinux 9, use:

rpm -Va 2>/dev/null | grep "^..5" | head -30

O prefixo ..5 indica que o hash MD5 do arquivo foi alterado — sinal de binário comprometido.

Recuperação do servidor após comprometimento

A estratégia de recuperação de servidor invadido depende do nível de acesso obtido pelo invasor e da extensão do comprometimento. Existem dois caminhos principais.

Opção 1: Limpeza cirúrgica (comprometimento limitado)

Adequada apenas quando o vetor é conhecido, o acesso foi limitado (sem escalada para root) e a extensão do comprometimento é pequena e bem delimitada:

1. Remova todos os arquivos maliciosos identificados (webshells, scripts em /tmp, binários alterados).
2. Reinstale os pacotes com binários comprometidos: apt reinstall --reinstall nome-do-pacote (Debian/Ubuntu) ou dnf reinstall nome-do-pacote (Rocky/AlmaLinux).
3. Remova contas não autorizadas: userdel -r nome_conta_suspeita.
4. Limpe todos os crontabs maliciosos identificados.
5. Revogue chaves SSH não autorizadas em ~/.ssh/authorized_keys de todos os usuários.
6. Aplique todas as atualizações de segurança pendentes: apt update && apt upgrade -y.

Opção 2: Reinstalação completa (comprometimento grave)

Atenção: esta opção apaga todos os dados do servidor. Certifique-se de ter backups dos dados legítimos antes de prosseguir.

Quando houve escalada de privilégios para root, rootkits foram detectados ou o vetor de entrada é desconhecido, a reinstalação completa é a única abordagem confiável:

1. Faça backup dos dados legítimos (banco de dados, arquivos de configuração, conteúdo web) para local externo.
2. Reinstale o sistema operacional via painel do provedor (reinstall/rebuild).
3. Restaure apenas os dados — nunca restaure binários ou scripts do servidor comprometido.
4. Aplique hardening completo antes de colocar o servidor em produção novamente.

Para referência sobre como acessar seu servidor após a reinstalação, consulte o guia Acessando servidores VPS Linux da AviraHost.

Hardening pós-recuperação obrigatório

Após restaurar o servidor, aplique estas medidas antes de recolocar em produção:

apt update && apt upgrade -y

adduser adminuser
usermod -aG sudo adminuser

mkdir -p /home/adminuser/.ssh
chmod 700 /home/adminuser/.ssh
echo "SUA_CHAVE_PUBLICA_SSH" >> /home/adminuser/.ssh/authorized_keys
chmod 600 /home/adminuser/.ssh/authorized_keys

Edite /etc/ssh/sshd_config para desabilitar login por senha e acesso root direto:

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
Port 2222

systemctl restart sshd

Instale e configure o Fail2Ban para bloquear tentativas de força bruta:

apt install fail2ban -y
systemctl enable --now fail2ban

Configure o firewall UFW com política restritiva:

ufw default deny incoming
ufw default allow outgoing
ufw allow 2222/tcp
ufw allow 80/tcp
ufw allow 443/tcp
ufw enable

Instale o AIDE para monitoramento de integridade de arquivos:

apt install aide -y
aideinit
cp /var/lib/aide/aide.db.new /var/lib/aide/aide.db

Agende verificações diárias de integridade via cron:

echo "0 3 * * * root /usr/bin/aide --check | mail -s 'AIDE Report' [email protected]" >> /etc/crontab

Problemas comuns e como resolver

Sintoma: servidor continua enviando spam após limpeza

Causa: webshell ou script malicioso não foi completamente removido, ou o processo de envio de e-mail está sendo executado por um usuário de aplicação (www-data, nginx) que não foi auditado.
Solução: verifique processos rodando como www-data: ps aux | grep www-data. Inspecione todos os arquivos PHP modificados recentemente: find /var/www -name "*.php" -mtime -7 | xargs grep -l "base64_decode\|eval\|system\|passthru" 2>/dev/null. Bloqueie o envio de e-mail pelo PHP temporariamente adicionando disable_functions = mail, exec, system, passthru, shell_exec ao php.ini. Considere a correção validada quando não houver novos processos de envio suspeitos, os logs do MTA pararem de registrar filas anormais e a fila de e-mail deixar de crescer após alguns minutos de observação.

Sintoma: rkhunter reporta falsos positivos após atualização legítima

Causa: o banco de dados de hashes do rkhunter ficou desatualizado após uma atualização de pacotes legítima do sistema.
Solução: após confirmar que a atualização foi legítima (verificando o histórico do apt/dnf), atualize o banco de dados do rkhunter: rkhunter --propupd. Execute novamente o scan para confirmar que os alertas desapareceram. O resultado esperado é que apenas avisos realmente novos permaneçam; se o mesmo arquivo seguir aparecendo sem justificativa, trate como alteração suspeita e revise o pacote correspondente.

Sintoma: processo malicioso reaparece após ser encerrado com kill

Causa: o processo está sendo reiniciado por um serviço systemd malicioso, um crontab oculto ou um processo pai que não foi identificado.
Solução: identifique o processo pai: ps -ef | grep PID_SUSPEITO. Verifique serviços systemd não reconhecidos: systemctl list-units --type=service --state=running. Procure por unit files suspeitos: find /etc/systemd /usr/lib/systemd -name "*.service" -mtime -7. Desabilite e remova o serviço malicioso: systemctl disable --now nome_servico && rm /etc/systemd/system/nome_servico.service && systemctl daemon-reload. A validação é simples: após remover a persistência, o PID não deve reaparecer em novas verificações com ps e não deve mais existir serviço ou tarefa agendada recriando o processo.

Sintoma: invasor mantém acesso mesmo após troca de senha SSH

Causa: o invasor adicionou sua chave pública ao arquivo authorized_keys de um ou mais usuários, mantendo acesso por chave mesmo sem conhecer a senha.
Solução: audite e limpe todos os arquivos authorized_keys do sistema: find / -name "authorized_keys" 2>/dev/null -exec cat {} \;. Remova chaves não reconhecidas. Temporariamente, desabilite autenticação por chave no sshd_config (PubkeyAuthentication no), reinicie o SSH, troque todas as senhas e reconfigure apenas as chaves legítimas. Após a limpeza, reabilite o acesso seguro definindo novamente PubkeyAuthentication yes, confirme que sua chave pública correta está presente em ~/.ssh/authorized_keys com permissões adequadas (700 no diretório e 600 no arquivo) e teste uma nova sessão SSH por chave antes de encerrar o acesso atual. O resultado esperado é que apenas chaves autorizadas consigam autenticar e que logins antigos do invasor deixem de aparecer nos logs.

Sintoma: não consigo acessar o servidor via SSH após aplicar regras de firewall

Causa: a regra de bloqueio foi aplicada sem exceção para o IP de administração, ou a porta SSH foi alterada sem atualizar o firewall.
Solução: acesse o servidor pelo console de emergência (KVM/VNC) disponível no painel do provedor. Limpe as regras do iptables: iptables -F && iptables -X && iptables -P INPUT ACCEPT. Reconfigure o firewall corretamente com sua exceção de IP antes de aplicar políticas restritivas. Considere a correção concluída quando o SSH responder novamente na porta configurada e uma conexão de teste a partir do IP administrativo for estabelecida com sucesso.

Perguntas frequentes sobre servidor comprometido

Como saber se meu servidor Linux foi comprometido?

Sinais comuns incluem processos desconhecidos consumindo CPU ou memória, logins SSH de IPs estranhos nos logs, arquivos modificados recentemente sem justificativa, novas contas de usuário criadas sem autorização e tráfego de rede anômalo. Execute last, who, ps aux e netstat -tulnp para uma verificação inicial rápida. Qualquer anomalia nesses quatro comandos já justifica uma investigação mais aprofundada.

O que fazer primeiro quando o servidor é invadido?

A prioridade é conter o incidente antes de tentar recuperar. Isole o servidor da rede bloqueando conexões de entrada e saída com o firewall, preserve os logs sem alterá-los, tire um snapshot do estado atual se possível e só então inicie a investigação forense. Nunca reinicie o servidor imediatamente — isso pode apagar evidências voláteis na memória RAM que são essenciais para entender o vetor de ataque.

Devo reinstalar o sistema operacional após uma invasão?

Na maioria dos casos, sim. Quando o nível de acesso do invasor é desconhecido — especialmente se houve escalada de privilégios para root — a reinstalação completa é a única forma de garantir que não há backdoors ou rootkits ocultos. Restaurar a partir de um backup limpo anterior ao comprometimento é a abordagem mais segura e recomendada para ambientes de produção críticos.

Como identificar um rootkit no servidor Linux?

Use ferramentas como chkrootkit e rkhunter para varredura automatizada. Verifique também binários do sistema com debsums (Debian/Ubuntu) ou rpm -Va (Rocky Linux/AlmaLinux) para detectar arquivos alterados. Rootkits sofisticados podem mascarar processos e arquivos, por isso a análise offline — montando o disco em outro servidor — é mais confiável do que executar as ferramentas no próprio sistema comprometido.

Como evitar que o servidor seja comprometido novamente após a recuperação?

Após a recuperação, aplique todas as atualizações de segurança, desative serviços desnecessários, configure autenticação SSH por chave (desabilitando senha), implemente Fail2Ban para bloquear tentativas de força bruta, configure um firewall restritivo com UFW ou nftables e ative monitoramento de integridade de arquivos com AIDE ou Tripwire. Revise também o guia de Dicas de Otimização de Servidores Linux para boas práticas adicionais de manutenção.

Conclusão

• Contenha antes de recuperar: isolar o servidor e preservar evidências são as primeiras ações — nunca reinicie imediatamente após detectar comprometimento.
• Identifique o vetor de entrada: sem entender como a invasão ocorreu, a recuperação é incompleta e o servidor ficará vulnerável ao mesmo ataque novamente.
• Aplique hardening completo após a recuperação: autenticação SSH por chave, Fail2Ban, firewall restritivo e monitoramento de integridade de arquivos são camadas essenciais para prevenir reincidência.

Leia também

• Passo a passo para configurar firewall com nftables em VPS Linux e servidor dedicado
• Entenda o que é Fail2Ban: como funciona e exemplos práticos
• Entenda o que é blacklist de IP: como verificar e remover seu servidor

Precisa de ajuda com segurança do seu servidor?

Lidar com um servidor comprometido exige ação rápida e conhecimento técnico especializado. Um ambiente VPS com suporte qualificado pode fazer a diferença entre horas de downtime e uma recuperação controlada — além de oferecer recursos como snapshots e firewall de rede para facilitar a contenção.

Conheça os planos de VPS da AviraHost com suporte técnico