Quando un server Linux viene compromesso, la rapidità e la precisione nella raccolta delle prove forensi sono cruciali. Ogni secondo che passa, dati volatili possono essere persi, rendendo l’analisi dell’incidente incompleta o addirittura fuorviante. L’obiettivo primario è acquisire un’istantanea dello stato del sistema nel momento della compromissione, minimizzando al contempo l’alterazione delle prove. Questo script, sviluppato e testato in scenari di incident response reali, automatizza la raccolta di informazioni essenziali, dai processi attivi alle connessioni di rete, dai log di sistema ai file modificati di recente, fornendo una base solida per l’indagine forense successiva.
Testato su: Ubuntu 22.04 LTS · Debian 11 · CentOS 7 · [luglio 2024]
Prerequisiti / Ambiente di test
Per eseguire lo script è necessario avere accesso al sistema compromesso con privilegi di root o un utente con accesso sudo. Idealmente, lo script dovrebbe essere eseguito da un supporto non persistente (es. USB live boot) o copiato e eseguito da una directory temporanea, per ridurre l’impatto sul disco e prevenire la sovrascrittura di prove. Assicurati che sul sistema siano disponibili comandi standard come tar, gzip, sha256sum, ps, netstat, ls, cat, find, mount, che sono solitamente presenti in tutte le distribuzioni Linux. Lo script è progettato per essere il più agnostico possibile rispetto alla distribuzione.
1. Comprendere la Priorità dei Dati Volatili
In un’indagine forense, i dati vengono classificati in base alla loro volatilità. I più volatili sono quelli che cambiano rapidamente o vengono persi al riavvio del sistema, come i processi in memoria e le connessioni di rete attive. La raccolta di questi dati deve essere la prima priorità per preservare un’immagine accurata dello stato del sistema al momento dell’incidente. Lo script inizia proprio da qui, catturando i dati più effimeri prima che possano essere alterati o persi.
2. Lo Script di Raccolta Prove (Forensic Toolkit)
Questo script Bash è progettato per essere eseguito su un sistema Linux potenzialmente compromesso. Raccoglie una serie di informazioni critiche e le impacchetta in un archivio tar.gz con un timestamp per facilitare l’analisi successiva. Leggi anche: Come automatizzare la creazione di report con Ansible
#!/bin/bash
# Script di raccolta prove forensi per sistemi Linux
# Autore: Rosario Giordano
# Versione: 1.0
# Data: 2024-07-22
# Verifica privilegi di root
if [[ $EUID -ne 0 ]]; then
echo "Questo script deve essere eseguito come root o con sudo."
exit 1
fi
OUTPUT_DIR="/tmp/forensic_collection_$(date +%Y%m%d_%H%M%S)"
mkdir -p "$OUTPUT_DIR"
echo "Inizio raccolta prove forensi in $OUTPUT_DIR..."
# 1. Dati Volatili
# Processi in esecuzione
ps auxww > "$OUTPUT_DIR/ps_auxww.txt"
ps -ef > "$OUTPUT_DIR/ps_ef.txt"
ls -l /proc/*/exe > "$OUTPUT_DIR/proc_exe_links.txt" 2>/dev/null
ls -l /proc/*/fd > "$OUTPUT_DIR/proc_fd_links.txt" 2>/dev/null
# Connessioni di rete
netstat -tulnp > "$OUTPUT_DIR/netstat_tulnp.txt"
netstat -anp > "$OUTPUT_DIR/netstat_anp.txt"
ss -tulnp > "$OUTPUT_DIR/ss_tulnp.txt" # Alternative a netstat su sistemi moderni
ss -anp > "$OUTPUT_DIR/ss_anp.txt"
# Tabelle ARP
arp -an > "$OUTPUT_DIR/arp_an.txt"
# Cache DNS
cat /etc/resolv.conf > "$OUTPUT_DIR/resolv.conf"
# Per cache DNS specifiche di servizi (es. systemd-resolved, dnsmasq) potrebbe servire integrazione specifica
# Variabili d'ambiente (per processi specifici, se rilevante)
# Esempio: cat /proc/PID/environ
# 2. Informazioni di Sistema e Configurazione
# Informazioni sul kernel e versione OS
uname -a > "$OUTPUT_DIR/uname_a.txt"
cat /etc/os-release > "$OUTPUT_DIR/os_release.txt"
# Utenti e Gruppi
cat /etc/passwd > "$OUTPUT_DIR/passwd.txt"
cat /etc/shadow > "$OUTPUT_DIR/shadow.txt"
cat /etc/group > "$OUTPUT_DIR/group.txt"
cat /etc/sudoers > "$OUTPUT_DIR/sudoers.txt" 2>/dev/null
# Configurazioni di rete
ifconfig -a > "$OUTPUT_DIR/ifconfig_a.txt"
ip a > "$OUTPUT_DIR/ip_a.txt"
ip r > "$OUTPUT_DIR/ip_r.txt"
cat /etc/network/interfaces > "$OUTPUT_DIR/network_interfaces.txt" 2>/dev/null
# Servizi in esecuzione
systemctl list-units --type=service > "$OUTPUT_DIR/systemctl_services.txt"
# Cron jobs
crontab -l > "$OUTPUT_DIR/crontab_root.txt" 2>/dev/null
# Per altri utenti: for user in $(cut -f1 -d: /etc/passwd); do crontab -l -u $user 2>/dev/null >> "$OUTPUT_DIR/crontab_${user}.txt"; done
# 3. Log di Sistema
# Log recenti (ultime 24h o più, a seconda della rotazione)
journalctl --no-pager --since "1 day ago" > "$OUTPUT_DIR/journalctl_last_day.log"
find /var/log -maxdepth 1 -type f -name "*.log" -o -name "messages" -o -name "syslog" -o -name "auth.log" -exec cp --parents {} "$OUTPUT_DIR/logs/" \; 2>/dev/null
# 4. File e Directory Sospette
# File modificati negli ultimi X giorni (es. 7 giorni)
find / -type f -mtime -7 -print0 2>/dev/null | xargs -0 tar -rf "$OUTPUT_DIR/recently_modified_files.tar" 2>/dev/null
# File con permessi SUID/SGID
find / -type f -perm /6000 -exec ls -la {} \; > "$OUTPUT_DIR/suid_sgid_files.txt" 2>/dev/null
# File nascosti nella home directory (es. .bashrc, .profile)
find /home -maxdepth 2 -type f -name ".*" -print0 2>/dev/null | xargs -0 tar -rf "$OUTPUT_DIR/hidden_home_files.tar" 2>/dev/null
# 5. Integrità delle Prove
# Genera hash SHA256 per tutti i file raccolti
find "$OUTPUT_DIR" -type f -exec sha256sum {} \; > "$OUTPUT_DIR/sha256sums.txt"
# 6. Compressione e Pulizia
# Comprimi l'intera directory in un archivio tar.gz
ARCHIVE_NAME="forensic_evidence_$(date +%Y%m%d_%H%M%S).tar.gz"
tar -czvf "/tmp/$ARCHIVE_NAME" -C "$(dirname "$OUTPUT_DIR")" "$(basename "$OUTPUT_DIR")"
echo "Raccolta completata. Archivio creato in /tmp/$ARCHIVE_NAME"
echo "Eliminazione directory temporanea $OUTPUT_DIR..."
rm -rf "$OUTPUT_DIR"
echo "Script completato."3. Analisi delle Sezioni dello Script
Lo script è strutturato per coprire le aree più critiche in caso di incidente. Leggi anche: Wazuh vs Security Onion: Due Settimane di Test
Dati Volatili
Questa sezione è la più importante. ps auxww e ps -ef catturano tutti i processi in esecuzione con i loro argomenti completi, rivelando eventuali processi malevoli o anomali. netstat -tulnp e ss -tulnp mostrano le connessioni di rete attive e i programmi in ascolto, fondamentali per identificare comunicazioni C2 (Command and Control) o servizi inattesi. I link in /proc//exe e /proc//fd possono rivelare processi che hanno eliminato i loro binari dal disco (fileless malware) o file aperti verso destinazioni inusuali.
Informazioni di Sistema e Configurazione
Catturare uname -a e /etc/os-release fornisce un contesto essenziale sulla versione del sistema operativo. I file /etc/passwd, /etc/shadow, /etc/group sono vitali per identificare account utente compromessi o aggiunti illecitamente. /etc/sudoers rivela chi ha privilegi elevati. Le configurazioni di rete (ifconfig, ip a, /etc/network/interfaces) possono mostrare modifiche a indirizzi IP, route o interfacce. I servizi di sistema (systemctl) e i cron jobs (crontab -l) sono punti chiave dove gli attaccanti spesso stabiliscono persistenza.
Log di Sistema
I log sono la narrazione degli eventi. journalctl (per sistemi moderni con systemd) e i file in /var/log (auth.log, syslog, messages) contengono registrazioni di accessi, errori, tentativi di login falliti e attività sospette. La loro analisi è fondamentale per ricostruire la timeline dell’attacco.
File e Directory Sospette
find è uno strumento potente per identificare file modificati di recente (-mtime), file con permessi SUID/SGID insoliti (spesso usati per privilege escalation), o file nascosti che potrebbero contenere configurazioni malevole. L’inclusione di questi file in un archivio separato facilita un’analisi mirata. Leggi anche: Honeypot Agosto: 7 Giorni, 1.200 Attacchi SSH
4. Errori Comuni e Troubleshooting
- Esecuzione su sistema compromesso: L’esecuzione dello script sul sistema compromesso può alterare le prove. Idealmente, si dovrebbe montare il disco del sistema compromesso su una macchina forense separata e raccogliere i dati da lì. Se non è possibile, eseguire lo script su
/tmpe trasferire subito l’archivio. - Permessi: Assicurati che lo script abbia i permessi di esecuzione (
chmod +x script.sh) e che sia eseguito con privilegi di root (sudo ./script.sh). - Spazio su disco: La raccolta di log e file modificati può generare un archivio di grandi dimensioni. Controlla lo spazio disponibile su
/tmpo sulla destinazione dell’archivio. - Comandi mancanti: Se un comando come
ssojournalctlnon è presente (su distribuzioni molto vecchie o minimali), lo script continuerà, ma i dati di quella sezione saranno mancanti. È un compromesso accettabile per uno script generico. - Time Stomping: Gli attaccanti possono modificare i timestamp dei file. Le hash SHA256 e i timestamp di raccolta dello script sono cruciali per dimostrare l’integrità delle prove. Leggi anche: NIS2 Sanità: Registro Trattamenti Tecnico
FAQ — Domande Frequenti
Devo modificare lo script per ogni incidente?
No, lo script è progettato per essere generico. Tuttavia, potresti voler aggiungere sezioni specifiche per software particolari (es. configurazioni di database, log di applicazioni web) se sai che sono installati sul sistema target. L’importante è mantenere la sua natura non invasiva e la raccolta dei dati critici.
Dove dovrei salvare l’archivio delle prove?
L’archivio viene creato in /tmp. È fondamentale trasferirlo il prima possibile su un sistema di archiviazione sicuro e offline, ad esempio un server di log centralizzato o un dispositivo USB dedicato all’analisi forense, per garantirne l’integrità e la disponibilità per le indagini future.
Questo script è sufficiente per un’analisi forense completa?
Questo script fornisce una base eccellente per la raccolta iniziale delle prove. Non sostituisce un’analisi forense approfondita che potrebbe includere l’imaging del disco completo, l’analisi della memoria RAM e l’utilizzo di strumenti forensi specializzati. È un primo passo rapido e robusto per “fermare il tempo” e catturare i dati più critici.
Come posso verificare l’integrità dell’archivio dopo il trasferimento?
Lo script genera un file sha256sums.txt all’interno dell’archivio. Dopo aver trasferito l’archivio, puoi estrarre questo file e rieseguire sha256sum -c sha256sums.txt all’interno della directory estratta per verificare che nessun file sia stato alterato durante il trasferimento o l’archiviazione.
Conclusioni con takeaway operativi
La gestione di un incidente su un sistema Linux richiede prontezza e metodologia. Questo script fornisce un framework operativo per la raccolta rapida e sistematica di prove forensi. Il takeaway principale è che l’automazione in questa fase non solo accelera il processo, ma riduce significativamente il rischio di errori umani e la perdita di dati cruciali. Avere uno strumento del genere a portata di mano, testato e compreso, è un vantaggio inestimabile per qualsiasi team di sicurezza o sysadmin. Ricorda sempre di trasferire le prove raccolte su un sistema sicuro e di non analizzare direttamente sul sistema compromesso per preservare la catena di custodia. Leggi anche: PSN: Migrazione e Impatto sulla Gestione Sistemi
Aggiornato: luglio 2024
