rkhunter: detectar rootkits no VPS Linux

# Instalar rkhunter (e chkrootkit como complemento):
sudo apt update && sudo apt install rkhunter chkrootkit

# Atualizar banco de dados de assinaturas:
sudo rkhunter --update

# IMPORTANTE: criar baseline do sistema ANTES de qualquer comprometimento
# (registrar hashes dos binários do sistema no estado atual):
sudo rkhunter --propupd

# Primeiro scan completo:
sudo rkhunter --check --sk --rwo
# --sk: skip key press (não pausa para confirmar)
# --rwo: report warnings only (mostrar apenas alertas)

# Scan mais detalhado com saída completa:
sudo rkhunter --check --sk
# Resultado: "System checks summary: No warnings found" é o ideal

# Ver log do último scan:
cat /var/log/rkhunter.log | grep -E "Warning|Rootkit"

# /etc/rkhunter.conf — configurações importantes:
sudo tee /etc/rkhunter.conf.local << 'EOF'
# Endereço para receber alertas por email:
MAIL-ON-WARNING=admin@seudominio.com.br
MAIL_CMD=mail -s "[rkhunter] Alerta VPS $(hostname)"

# Permitir arquivos e ferramentas legítimas que o rkhunter flagra por padrão:
# (ajuste conforme o que está instalado no seu sistema)
ALLOWHIDDENFILE=/dev/.udev
ALLOWHIDDENFILE=/dev/.static
ALLOWHIDDENFILE=/dev/.initramfs

# Binários que mudam normalmente (ex: após apt upgrade):
# (listar após identificar falsos positivos nos primeiros scans)

# Não verificar estes scripts (scripts de provedor de cloud):
SCRIPTWHITELIST=/usr/sbin/adduser
SCRIPTWHITELIST=/usr/sbin/useradd

# Verificar arquivos de configuração do SSH:
ENABLE_TESTS=ssh

# Permitir versão específica do protocolo:
ALLOW_SSH_PROT_V1=0

# Habilitar verificação de ports abertos:
ENABLE_TESTS=ports
# Lista de ports permitidos (os que você abriu intencionalmente):
ALLOWDEVFILE=/dev/shm
EOF

# Após configurar: atualizar a baseline para incluir os novos allowlists:
sudo rkhunter --propupd

# O pacote rkhunter já cria um cron diário em /etc/cron.daily/rkhunter
# Verificar:
cat /etc/cron.daily/rkhunter

# Configurar o cron diário em /etc/default/rkhunter:
sudo tee /etc/default/rkhunter << 'EOF'
# Habilitar execução automática pelo cron:
CRON_DAILY_RUN="yes"
CRON_DB_UPDATE="yes"
DB_UPDATE_EMAIL="no"   # não enviar email só por atualização de DB
REPORT_EMAIL="admin@seudominio.com.br"
APT_AUTOGEN="yes"      # atualizar baseline após apt upgrade automaticamente
EOF

# Script de scan com log e alerta Telegram:
sudo tee /usr/local/bin/rkhunter-scan.sh << 'SCRIPT'
#!/bin/bash
LOG=/var/log/rkhunter-daily.log
sudo rkhunter --update --sk --quiet 2>/dev/null
sudo rkhunter --check --sk --rwo --logfile $LOG 2>/dev/null
WARNINGS=$(grep -c "Warning" $LOG 2>/dev/null || echo 0)
if [ "$WARNINGS" -gt 0 ]; then
  DETAILS=$(grep "Warning" $LOG | head -10)
  curl -s -X POST "https://api.telegram.org/bot$TELEGRAM_TOKEN/sendMessage"     -d chat_id="$CHAT_ID"     -d text="🚨 rkhunter: $WARNINGS alertas em $(hostname)
$DETAILS"
fi
SCRIPT
chmod +x /usr/local/bin/rkhunter-scan.sh

# Adicionar ao cron (1h da manhã):
echo "0 1 * * * root /usr/local/bin/rkhunter-scan.sh" | sudo tee /etc/cron.d/rkhunter-scan

# chkrootkit tem métodos de detecção diferentes do rkhunter — usar os dois:

# Scan completo:
sudo chkrootkit

# Verificar resultado:
sudo chkrootkit | grep -v "not infected" | grep -v "nothing found"

# Saída limpa esperada: cada verificação termina com "not infected"
# Alertas comuns (falsos positivos no Ubuntu):
# "Checking 'bindshell'... INFECTED (PORTS: 465)"
# → Port 465 é SMTP/SMTPS, falso positivo — verificar:
sudo ss -tlnp | grep 465

# Automatizar chkrootkit diariamente:
# /etc/cron.daily/chkrootkit já existe após instalação
# Configurar em /etc/chkrootkit.conf:
echo 'RUN_DAILY="true"' | sudo tee -a /etc/chkrootkit.conf
echo 'RUN_DAILY_OPTS="-q"' | sudo tee -a /etc/chkrootkit.conf

# Verificar binários críticos com debsums (detecta modificação por rootkit):
sudo apt install debsums
sudo debsums --silent    # verifica hashes de pacotes Debian instalados
sudo debsums -c          # mostrar apenas arquivos com hash diferente do esperado

# Se rkhunter ou chkrootkit detectar rootkit confirmado:

# 1. ISOLAR o servidor imediatamente:
#    - No painel do provedor: desabilitar interface de rede ou criar snapshot
#    - NÃO desligue o servidor (pode perder evidências em memória)

# 2. Preservar evidências ANTES de qualquer alteração:
#    - Criar snapshot do disco via painel do provedor (Snapshots/Backups)
#    - Dump de memória (se possível)

# 3. Coletar evidências para análise forense:
sudo ss -tlnp > /tmp/network-before.txt        # conexões ativas
sudo ps auxf > /tmp/processes-before.txt        # processos
sudo find / -newer /tmp -type f 2>/dev/null > /tmp/new-files.txt  # arquivos recentes
sudo last -F > /tmp/logins.txt                  # histórico de logins
cat /root/.bash_history > /tmp/root-history.txt

# 4. Identificar o vetor de entrada (como o atacante entrou):
sudo journalctl -b -0 | grep -E "Accepted|Failed|error" | head -100
sudo ausearch -ts "2 weeks ago" -k identity --interpret

# 5. Se confirmado comprometimento: NÃO tente limpar — reinstale!
#    A única forma segura é: snapshot para forense → reinstalar OS limpo
#    → restaurar dados do backup ANTERIOR ao comprometimento
#    → aplicar hardening antes de voltar ao ar

# 6. Revisar e corrigir o vetor de entrada antes de voltar ao ar