Incident response: cosa fare nella prima ora di un server compromesso

Ricevi una notifica alle 3 del mattino: il sito di un cliente mostra una pagina di phishing. Oppure il carico CPU è al 100% e ps aux mostra processi che non hai mai visto. Il server è compromesso.

La prima ora è critica. Cosa fai, e in che ordine, determina se l'incidente è contenibile o diventa un disastro.

Per incidenti non legati a compromissione ma a downtime puro, affianca questa guida con Server down: cosa fare nei primi 60 minuti. Se invece ti serve una messa in sicurezza strutturale, la pagina corretta è Security Hardening.

La regola d'oro: non panico, documenta

Prima di fare qualsiasi cosa:

1. Apri un file di log con timestamp
2. Fai screenshot di ogni anomalia
3. Non riavviare il server (perdi volatile evidence)
4. Non cancellare nulla (ancora)

Ogni azione che fai deve essere documentata. Se l'incidente va in tribunale o in un report per il cliente, serve la catena delle decisioni.

Minuti 0-10: Isolamento

L'obiettivo è tagliare l'accesso esterno senza spegnere il server.

# Isola dalla rete (se hai console di accesso)
# Opzione A: firewall immediato
iptables -I INPUT 1 -s TUO_IP -j ACCEPT
iptables -I INPUT 2 -j DROP

# Opzione B: se sei via SSH e non hai console, 
# almeno blocca il traffico in uscita
iptables -I OUTPUT 1 -d TUO_IP -j ACCEPT
iptables -I OUTPUT 2 -j DROP

# Verifica
iptables -L -n -v

Se il server è su cloud (AWS, Hetzner, DigitalOcean), sposta l'istanza in un security group isolato. È più veloce e reversibile.

Se non hai console, snapshot o accesso amministrativo pieno, non improvvisare. In questi casi è più sicuro aprire un intervento SOS e lavorare su contenimento e raccolta evidenze con una sequenza controllata.

Minuti 10-30: Snapshot forensico

Prima di toccare qualsiasi cosa, cattura lo stato attuale:

# Salva su storage esterno (non sul server compromesso!)

# 1. Processi in esecuzione
ps auxwwf > /tmp/evidence/processes.txt

# 2. Connessioni di rete
ss -tlnp > /tmp/evidence/listening.txt
ss -anp > /tmp/evidence/connections.txt
netstat -rn > /tmp/evidence/routes.txt

# 3. Utenti e login
last -50 > /tmp/evidence/last-logins.txt
lastb -50 > /tmp/evidence/failed-logins.txt
cat /etc/passwd > /tmp/evidence/passwd.txt
cat /etc/shadow > /tmp/evidence/shadow.txt 2>/dev/null

# 4. Cron jobs
for user in $(cut -f1 -d: /etc/passwd); do 
  crontab -l -u "$user" 2>/dev/null >> /tmp/evidence/crontabs.txt
done
cat /etc/crontab >> /tmp/evidence/crontabs.txt

# 5. File modificati nelle ultime 48 ore
find / -mtime -2 -type f -not -path "/proc/*" -not -path "/sys/*" \
  -not -path "/tmp/evidence/*" > /tmp/evidence/modified-files.txt 2>/dev/null

# 6. Log recenti
cp /var/log/auth.log /tmp/evidence/ 2>/dev/null
cp /var/log/syslog /tmp/evidence/ 2>/dev/null
journalctl --since "24 hours ago" > /tmp/evidence/journal-24h.txt

# 7. Hash dei file critici
sha256sum /usr/bin/{ls,ps,netstat,ss,top,crontab} > /tmp/evidence/binary-hashes.txt

# 8. Copia tutto su storage esterno
tar czf /root/evidence-$(hostname)-$(date +%Y%m%d_%H%M%S).tar.gz /tmp/evidence/
# scp questo archivio fuori dal server PRIMA di procedere

Minuti 30-45: Identificazione della compromissione

Analizza i dati raccolti:

Segnali di compromissione comuni:

• Processi anomali: miner crypto, reverse shell, scanner di rete
• File in /tmp, /dev/shm, /var/tmp con permessi eseguibili
• Modifiche a authorized_keys di utenti esistenti
• Nuove entry in crontab
• File web shell (.php, .phtml) nelle directory web
• Connessioni verso IP sconosciuti su porte non standard

# Cerca file sospetti
find /tmp /var/tmp /dev/shm -type f -executable -ls
find /var/www -name "*.php" -mtime -3 -ls
grep -r "eval(" /var/www --include="*.php" | head -20
grep -r "base64_decode" /var/www --include="*.php" | head -20

# Controlla se ci sono rootkit
# (se hai chkrootkit o rkhunter installati)
chkrootkit
rkhunter --check --skip-keypress

Minuti 45-60: Contenimento

Ora che sai cosa è successo, conteniamo il danno:

# 1. Kill dei processi malevoli
kill -9 <PID_DEL_PROCESSO_SOSPETTO>

# 2. Rimuovi crontab malevoli
crontab -e  # cancella le entry sconosciute

# 3. Revoca accessi compromessi
# Cambia TUTTE le password
passwd
# Rimuovi chiavi SSH sconosciute
cat /root/.ssh/authorized_keys
# Rimuovi utenti creati dall'attaccante
userdel <utente_sconosciuto>

# 4. Rimuovi web shell trovate
# Ma PRIMA salva copia per forensic
cp /var/www/miosito.it/shell.php /tmp/evidence/
rm /var/www/miosito.it/shell.php

# 5. Aggiorna software compromesso
apt update && apt upgrade
# Se WordPress: reinstalla core pulito
wp core download --skip-content --force

Cosa NON fare

Dopo la prima ora: bonifica completa

L'incident response non finisce dopo 60 minuti. La bonifica vera richiede:

1. Root cause analysis: come sono entrati? Aggiornamento mancante? Password debole? Vulnerabilità nel plugin?
2. Hardening: chiudere il vettore d'ingresso
3. Ripristino: da backup verificato pulito, non dal server compromesso
4. Monitoring intensivo: 72 ore di osservazione post-ripristino
5. Report: cosa è successo, cosa abbiamo fatto, cosa cambiamo

Runbook stampabile

Tieni questo runbook stampato o in un repository separato. Quando sei sotto stress alle 3 del mattino, non vuoi cercare su Google "come isolare un server compromesso".

Il tempo è nemico. Ogni minuto che il server compromesso resta accessibile è un minuto in più per l'attaccante per esfiltrare dati o propagarsi.

Prevenzione: checklist rapida

La migliore incident response è quella che non serve. Verifica:

• [ ] SSH con sole chiavi, no password
• [ ] Fail2ban configurato e attivo
• [ ] Firewall con default deny
• [ ] Aggiornamenti automatici di sicurezza
• [ ] Monitoring con alert su anomalie CPU/rete
• [ ] Backup testati e immutabili
• [ ] Log centralizzati (non solo locali)
• [ ] Runbook documentato e accessibile

Se hai clienti con dati sensibili (GDPR), la procedura di incident response è obbligatoria. Averla pronta PRIMA dell'incidente è la differenza tra una crisi gestita e un disastro.