Suspeitas que o Teu Servidor Linux Foi Invadido? Os Primeiros 60 Minutos de Análise Forense e Contenção

O Pânico da Invasão: O Que NUNCA Deves Fazer

O cenário é o pior pesadelo de qualquer administrador de sistemas: o processador do teu servidor Debian salta subitamente para os 100% de uso contínuo, a monitorização de rede acusa ligações suspeitas para IPs estrangeiros desconhecidos ou começas a receber alertas de clientes sobre emails fraudulentos.

Nesse segundo de pânico, muitos administradores cometem erros fatais. O impulso clássico é correr para o painel de controlo da cloud e carregar no botão de reiniciar a máquina, ou disparar um shutdown -r now no terminal na esperança de que um reboot elimine o invasor.

Reiniciar um servidor invadido é o pior erro que podes cometer. Ao reiniciares a máquina, apagas por completo a memória volátil (RAM). Destróis as únicas provas capazes de te explicar como o invasor entrou: processos de malware a correr em memória, ligações ativas com os servidores de comando do atacante, comandos executados na consola e chaves de encriptação temporárias.

REINÍCIO EM PÂNICO VS. RESPOSTA A INCIDENTES CLÍNICA

• O ERRO DO REINÍCIO EM PÂNICO (PROVAS FORENSES DESTRUÍDAS): Intrusão Detetada → O Administrador Executa: reboot
• (Memória RAM Apagada a Zero)
• Malware em Memória Desaparece / Não Se Conhece a Causa da Invasão: (O script de persistência do invasor volta a arrancar; o servidor continua invadido!)
• O GUIA DOS PRIMEIROS 60 MINUTOS (MÉTODO FORENSE EM DIRETO): 1. Minuto 0–10: Isolamento de Rede sem Perder a Tua Ligação SSH

2. Minuto 10–25: Preservação de RAM e Análise de Processos Ocultos
3. Minuto 25–40: Caça à Persistência (Cron, Systemd, Chaves SSH)
4. Minuto 40–60: Imagem do Disco e Plano de Reconstrução Limpa

Na Webxtek, seguimos uma metodologia rigorosa na gestão de crises de segurança. Através da nossa consultoria técnica e serviços de manutenção preventiva, ajudamos empresas a conter ameaças em tempo recorde sem destruir evidências cruciais.

Fase 1: Isolamento de Rede sem Cortares a Tua Própria Ligação (Minutos 0–10)

O teu primeiro objetivo é impedir que o servidor continue a transferir ficheiros para fora ou a receber ordens do atacante, mantendo a tua própria sessão de SSH ativa para fazeres a triagem.

Nunca desligues a placa de rede com ifdown. Cria antes uma regra de quarentena atómica com o nftables:

# Isola o servidor da Internet mas mantém a tua ligação aberta
cat <<EOF > /tmp/quarentena.nft
flush ruleset

table inet quarentena {
    chain input {
        type filter hook input priority filter; policy drop;
        # Permite APENAS o endereço IP fixo da tua máquina de trabalho
        ip saddr 198.51.100.14 tcp dport 22 accept
        ct state established,related accept
    }
    chain output {
        type filter hook output priority filter; policy drop;
        # Permite respostas exclusivamente para o teu computador
        ip daddr 198.51.100.14 accept
        ct state established,related accept
    }
}
EOF

# Aplica a regra de quarentena de forma atómica
nft -f /tmp/quarentena.nft

Com este comando, o tráfego do atacante é bloqueado no mesmo segundo, mas a tua consola continua a responder com tranquilidade.

Fase 2: Preservação de Memória e Processos Ocultos (Minutos 10–25)

Muitos malwares modernos correm exclusivamente na memória RAM: descarregam o binário para /tmp, arrancam o processo e apagam o ficheiro do disco logo a seguir para enganar scanners antivírus.

Para descobrires estes processos ocultos e inspecionares a memória:

# Procura processos que continuam a correr a partir de ficheiros já apagados
ls -la /proc/*/exe 2>/dev/null | grep '(deleted)'

# Inspeciona todas as ligações de rede e portas abertas com os respetivos PIDs
ss -tulpn
ss -tupn state established

DESCOBERTA DE PROCESSOS FANTASMA EM RAM

• Comando: ls -la /proc/*/exe | grep ‘(deleted)’
• Resultado: /proc/28412/exe -> /tmp/.minerador (deleted)
• O atacante descarregou o malware para a pasta /tmp
• Arrancou o processo diretamente na RAM
• Apagou o ficheiro do disco para não deixar rasto!
• (RECUPERAÇÃO DIRETA ATRAVÉS DO PSEUDO-SISTEMA /PROC) dd if=/proc/28412/exe of=/tmp/malware_recuperado.bin (Binário Salvo!)

Ao copiares o ficheiro a partir de /proc/<PID>/exe, recuperas o ficheiro original do malware para análise posterior.

Fase 3: Caçar os Mecanismos de Persistência (Minutos 25–40)

Os atacantes experientes deixam sempre portas das traseiras escondidas para conseguirem voltar a entrar caso tentes fechar o acesso. Segundo as normas da OWASP, deves auditar os pontos habituais de persistência:

1. Ficheiros authorized_keys de SSH

Verifica se foram adicionadas chaves públicas estranhas nas contas de utilizadores:

# Lista as chaves autorizadas de todos os utilizadores da máquina
for user in $(cut -f1 -d: /etc/passwd); do
  key_file=$(eval echo ~$user)/.ssh/authorized_keys
  [ -f "$key_file" ] && echo "=== $user ===" && cat "$key_file"
done

2. Tarefas de Cron e Timers do Systemd

Vê se existem scripts agendados com nomes suspeitos:

# Inspeciona todas as pastas de cron e temporizadores do sistema
ls -la /etc/cron* /var/spool/cron/crontabs/
systemctl list-timers --all

3. Bibliotecas Injetadas no /etc/ld.so.preload

Muitos rootkits de Linux alteram o carregador dinâmico do sistema para esconder processos:

# Confirma se existe alguma biblioteca injetada no sistema
cat /etc/ld.so.preload 2>/dev/null

Se este ficheiro tiver conteúdo desconhecido, utilitários normais como ps ou netstat podem estar a mentir-te porque as chamadas de sistema foram adulteradas.

Fase 4: A Regra de Ouro: Reconstruir Sempre, Nunca “Limpar”

O maior erro após um incidente é acreditares que “limpaste” o servidor porque mataste o processo malicioso e apagaste um script suspeito.

Quando um atacante obtém acesso de utilizador root, o sistema operativo deixa de ser confiável para sempre. Ele pode ter alterado o próprio kernel ou criado utilizadores ocultos em bibliotecas de sistema.

A PERDA DEFINITIVA DE CONFIANÇA NUM ACESSO ROOT

• O ATACANTE TEVE ACESSO DE ROOT: [ Acesso Máximo ] → Pode ter Injetado Módulos no Kernel ou Alterado Binários
• O Administrador Mata o Processo e Apaga um Script → Pensa que o Servidor Está Limpo!
• (O Backdoor Oculto Continua no Kernel)
• Servidor Volta a Ser Invadido 2 Semanas Depois / Perda Total de Credibilidade
• O ÚNICO CAMINHO PROFISSIONAL E SEGURO: 1. Guarda uma cópia do disco para fins legais e forenses
• 2. Exporta os dados da base de dados em formato de texto limpo
• 3. Monta um servidor NOVO a partir de código limpo de infraestrutura
• 4. Muda 100% de todas as palavras-passe, chaves de API e tokens da empresa!

Podes encontrar scripts abertos de análise forense e guias de resposta a incidentes no GitHub.

Aliando esta disciplina operacional às nossas soluções de alojamento gerido, a tua empresa garante que os seus sistemas recuperam de qualquer incidente com total rigor técnico, proteção de dados e resiliência duradoura.

Na prática, aplicas exatamente estes padrões operacionais em setores exigentes como cibersegurança e cibersegurança b2b e inteligência corporativa. Quando alinhas a tua estrutura através de consultoria técnica antes de construir e manutenção de website e cuidado técnico, transformas boas práticas técnicas numa vantagem competitiva real e mensurável para o teu negócio.