Guida Tecnica Completa all'Acquisizione Forense di Log di Sistema

SeizeLOG è uno strumento DFIR per l'acquisizione forense di log, configurazioni, metadati filesystem e contesto runtime da server Linux remoti. Automatizza la fase di evidence collection del framework NIST SP 800-86 (Guide to Integrating Forensic Techniques into Incident Response) e produce un pacchetto probatorio pronto per le fasi successive di examination, analysis e reporting. Un singolo binario Go statico, zero dipendenze, operativo via SSH. Clicca su ogni immagine per ingrandirla.

Cos'è SeizeLOG e quando si usa

SeizeLOG risponde al caso d'uso dominante dell'incident response moderno: il server compromesso è in cloud, in data center o in container, accessibile solo via SSH. L'acquisizione deve avvenire mentre il sistema è in esecuzione (live acquisition), con tracciabilità completa dell'operazione e documentazione della non-dimostrabile inalterazione del sistema target durante la raccolta.

SeizeLOG non è un tool di imaging disco. Non produce una copia 1:1 del filesystem. Produce una raccolta forense mirata dei dati volatili e semi-volatili — log ruotati, processi in memoria, connessioni attive, stato NTP, metadati filesystem — che vengono normalmente sovrascritti o cancellati dopo poche ore. È complementare a SeizeDB (acquisizione contenuto database) e a tool di imaging tradizionali per i casi in cui lo spegnimento del server non è praticabile.

Destinatari: consulenti tecnici d'ufficio (CTU), consulenti tecnici di parte (CTP), incident responder, team SOC / CSIRT, auditor NIS2 e GDPR, auditor ISO/IEC 27001, periti informatici.

Allineamento al framework NIST SP 800-86

NIST SP 800-86 identifica quattro fasi del processo forense: Collection, Examination, Analysis, Reporting. SeizeLOG copre integralmente la Collection e automatizza parti significative di Examination e Analysis:

• Collection — identificazione, labeling, recording e acquisizione dei dati con procedure che preservano l'integrità (hash SHA-256 per file, timestamping RFC 3161, chain of custody). Copre le quattro major categorie di data source NIST: files, operating systems, network traffic, applications.
• Examination — analisi automatica dei log raccolti con metodi documentati: discovery a 3 livelli, categorizzazione automatica per servizio, cross-log correlation.
• Analysis — 10 moduli con findings tipizzati secondo MITRE ATT&CK tactic/technique e CIS Benchmarks, risk scoring con metodologia documentata.
• Reporting — tre formati (TXT autoritativo timestampato, PDF forense, HTML interattivo a 24 pagine organizzate in 6 gruppi collassabili nella sidebar) con Executive Summary e Remediation Roadmap.

Architettura: binario Go statico via SSH

SeizeLOG è un singolo eseguibile Linux compilato con CGO_ENABLED=0: gira su qualunque distribuzione senza installazione. Il flusso operativo standard:

scp seizelog-linux-amd64 config.json root@server:/tmp/
ssh root@server "/tmp/seizelog-linux-amd64 --config /tmp/config.json --apikey CHIAVE"
scp -r root@server:/tmp/seizelog_* ./
ssh root@server "rm -rf /tmp/seizelog-linux-amd64 /tmp/config.json /tmp/seizelog_*"

Supporto nativo per Debian/Ubuntu, RHEL/CentOS/Rocky/Alma/Fedora/Amazon Linux/Oracle Linux, Alpine (OpenRC), SUSE, Gentoo. Rilevamento automatico via /etc/os-release, adattamento percorsi log (/var/log/auth.log su Debian, /var/log/secure su RHEL, /var/log/messages su Alpine).

Flusso di esecuzione: 8+1 step

Acquisizione reale: 1259 log sources, 1220 file raccolti, 367 MB originali compressi in 42.9 MB, 10 moduli di analisi, report generati, ZIP cifrato — in 3 minuti e 32 secondi.

Server Identification: FQDN, domini ospitati, rete

Executive Summary e Risk Score 0-100

I 10 moduli di analisi forense

Ogni modulo produce un JSON strutturato in analysis/, findings tipizzati con severity (CRITICAL/HIGH/MEDIUM/LOW) e referenze MITRE ATT&CK + CIS Benchmarks.

1. IOC — Indicators of Compromise

2. Brute Force Analysis

3. Sessions — SSH + Web Access

4. CVE Scan

5. Attack Surface — Audit CIS Benchmarks

6. Compromise Assessment

7. Recon & TLS

8. Mail Services — stack completo

9. Processes, Ports & Active Connections

10. GeoIP

Database DB-IP Lite offline per geolocalizzazione degli IP attaccanti. Alimenta la mappa mondiale del report HTML e le tabelle top countries by attack count. Nessuna chiamata di rete durante l'acquisizione (offline-first).

Open Files Snapshot — lsof Volatile Data

Snapshot completo dei file descriptor aperti dal sistema al momento esatto dell'acquisizione, conforme al data source OS volatile di NIST SP 800-86. Cattura via lsof -nP +c 0: file regolari, socket di rete, pipe, dispositivi, librerie mappate in memoria, e file cancellati ancora referenziati da processi (evidence MITRE T1070.004 — Indicator Removal: File Deletion).

Memory Composition — /proc/meminfo con TOC sticky

Pagina dedicata alla composizione della memoria con donut chart SVG inline (zero dipendenze esterne), divisa in 13 sezioni navigabili tramite indice sticky in cima alla pagina.

Acquisizione memoria volatile (opzionale, --with-memory)

Con il flag --with-memory SeizeLOG esegue l'acquisizione forense della RAM — conforme al livello 1 di volatility di RFC 3227 Order of Volatility. Il dump viene compresso gzip, accompagnato da tripla attestazione (SHA-256 raw + SHA-256 gzip + dimensione pre/post), allegato al pacchetto cifrato ma escluso dal calcolo slot: è un extra tecnico, non parte della tariffazione a peso.

Cascade a tre livelli per massimizzare la copertura su target eterogenei:

1. AVML — binario Microsoft (MIT) embedded nel SeizeLOG via go:embed, estratto in /tmp al momento dell'esecuzione. Tenta le tre sorgenti: /dev/crash, /proc/kcore, /dev/mem. Funziona su kernel permissivi (Ubuntu server, Debian server, la maggior parte dei cloud provider senza Secure Boot).
2. /proc/kcore diretto — fallback in Go se AVML fallisce per motivi diversi dal lockdown, con cap configurabile e timeout.
3. Per-process /proc/[pid]/mem — scatta automaticamente quando il kernel è in lockdown mode (Secure Boot, CONFIG_LOCKDOWN=integrity|confidentiality). Per ogni PID leggibile iterare /proc/[pid]/maps, selezionare le regioni forensicamente rilevanti ([heap], [stack], anonime RW — dove vivono credenziali e token), leggere via /proc/[pid]/mem, scrivere un file framed con header === PID=N COMM=name REGION=addr-addr PATH=path PERMS=rwx ===. Funziona su qualsiasi Linux perché è memoria user-space, non kernel.

Preflight disco obbligatorio: verifica che lo spazio libero sulla partizione di destinazione sia ≥ 1.5× la RAM totale. Se insufficiente, skip documentato in evidence/ram-dump-unavailable.txt con reason esplicita — chain of custody intatta anche in caso di non-acquisizione.

Analisi euristica del dump RAM

Dopo la compressione, SeizeLOG esegue una analisi euristica in streaming sul gzip — nessuna decompressione su disco. L'approccio è deliberatamente euristico perché la decodifica strutturale delle task_struct kernel richiederebbe symbol table ISF Volatility per ogni versione kernel × distro × architettura — ingestibile in distribuzione binaria.

Ottimizzazioni performance:

• Literal-prefix prefilter via bytes.Index ASCII-case-insensitive: per ogni pattern una lista di prefissi fissi (AKIA, -----BEGIN, ghp_, xoxb-, eyJ, Authorization: bearer…). Il 99% dei byte del dump viene skippato senza mai toccare il motore regex. La regex completa gira solo in una finestra di ±512 byte intorno a ogni hit letterale.
• Parallelizzazione chunk-level: runtime.NumCPU() worker goroutine (cap 16) consumano chunk da 16 MB da un canale. La decompressione gzip resta single-threaded (protocollo), ma l'analisi CPU-bound scala linearmente con i core disponibili.
• Risultato misurato: dump da 16.9 GB analizzato in 88 secondi su server 4-core — vs ~30 minuti del design sequenziale iniziale.

20+ pattern di matching categorizzati per severity e confidence:

• Credenziali critiche: AWS access/secret key, GitHub PAT (ghp_/gho_/ghs_), Slack token, PEM private key blocks, JWT tokens, HTTP Authorization Bearer/Basic, MySQL CLI password (-p, --password=), env variabili sensibili (API_KEY, SECRET_KEY, PASSWORD).
• Network & C2: Tor .onion address, pattern reverse-shell bash -i /dev/tcp/, curl | bash, wget | sh.
• Anti-forensic & staging: history -c, unset HISTFILE, echo pwd | sudo -S, base64 -d | sh, binari in esecuzione da /tmp//dev/shm//var/tmp, riferimenti a (deleted) executable (T1070.004).
• IOC correlation: i keyword dal modulo IOC esistente (path sospetti, hash malware noti) vengono correlati con il contenuto RAM.

Ogni finding include valore rilevato, contesto ±40 byte sanitizzato printable-safe, offset hex nel file decompresso, severity/confidence, fingerprint redatto (per display pubblico). Per dump per-process l'analyzer parsa gli header di framing e attribuisce ogni finding al PID + comm + region che lo conteneva. Per avml full-RAM l'attribuzione non è possibile senza Volatility — il modal HTML segnala esplicitamente il limite.

Il report HTML include una guida Volatility 3 copia-incolla con i 10 comandi essenziali (banners.Banners, linux.pslist, linux.malfind, linux.check_syscall, linux.bash, linux.netstat) per chi voglia analisi deterministica post-acquisizione.

Hardening Posture — 17 meccanismi di difesa rilevati

SeizeLOG rileva e valuta automaticamente lo stato di tutti i meccanismi di sicurezza kernel/OS attivi sul target. Due usi:

• Per l'operatore: spiega perché alcune operazioni DFIR (RAM dump completo, ptrace cross-user) possono essere state bloccate.
• Per il perito: documenta la baseline di sicurezza del server — elemento rilevante sia per valutare la compromissione sia per la difesa in giudizio.

Meccanismi rilevati e scorati:

• Mandatory Access Control: SELinux (enforcing/permissive), AppArmor (profili caricati), Smack
• Boot integrity: Kernel lockdown (none|integrity|confidentiality da /sys/kernel/security/lockdown), Secure Boot (mokutil --sb-state o EFI vars), module signing (sig_enforce), module loading disabled
• Debugger & info-leak: YAMA ptrace_scope, kptr_restrict, dmesg_restrict, perf_event_paranoid
• Memory hardening: KASLR (cmdline parsing), randomize_va_space, unprivileged BPF disabled, unprivileged user namespace
• Network defenses: firewall attivo (ufw/firewalld/nftables/iptables), fail2ban, TCP syncookies
• Seccomp filtering: conteggio processi con filtri seccomp attivi (scan /proc/[pid]/status)

Score ponderato 0-100 con verdict minimal/standard/strong/maximum. Persistito in system/hardening.json + hardening.txt, renderizzato nella pagina HTML dedicata con card ON/OFF per meccanismo.

Process Enrichment: catalogo esaustivo dei processi

Per ogni PID running SeizeLOG produce un record di arricchimento combinando fonti locali (target-side) e un dizionario statico embedded:

• Descrizione statica: ~150 processi Linux comuni (systemd family, web/db/mail/container daemon, kernel threads) con descrizioni curate da man-pages e package descriptions. Lookup smart con strip di suffissi versione (python3.11 → python3 → python) e separatori (kworker/0:1 → kworker).
• Descrizione whatis: invocato runtime sul target per ogni comm unico (cached), estrae descrizione dal man-page locale.
• Package owner: per ogni /proc/[pid]/exe symlink, dpkg -S (Debian/Ubuntu) / rpm -qf (RHEL/Fedora/SUSE) / apk info -W (Alpine). Risultato: "nginx-core", "openssh-server", "systemd", o vuoto per binari custom/(deleted).
• Service unit: systemctl status PID estrae il nome del .service e la description (es. "nginx.service — A high performance web server").
• Catena PPID: walker da PID fino a PID 1 (max 20 link, anti-loop) con nome di ogni parent.
• User: risolto da /proc/[pid]/status Uid contro /etc/passwd.
• Command line: /proc/[pid]/cmdline NUL→space, troncato a 500 char.

Renderizzato nella pagina Process forensics: tabella cliccabile (PID, comm, user, description, package, service) con modal dettagliato per processo che mostra la catena parent completa con frecce tipo 1234:nginx → 12:systemd → 1:systemd.

Access Log & Mtime Fencing

Durante la raccolta dei log, SeizeLOG genera evidence/access-log.jsonl: un record JSON per ogni file letto con (a) size_before + mtime_before snapshot prima dell'apertura, (b) sha256_at_read computato durante lo stream, (c) size_after + mtime_after dopo la chiusura, (d) time_read_start_utc/time_read_end_utc, (e) flag altered_during_read.

Questo è il requisito di integrity fencing per live acquisition richiesto da ISO/IEC 27037 §6.8: se un log rotante (auth.log, access.log di servizio attivo) cresce durante la lettura, l'SHA-256 acquisito identifica univocamente i byte effettivamente letti, e il flag altered segnala la discrepanza mtime/size senza nascondere nulla. Pagina HTML dedicata separa visivamente file "stable" vs "altered during read".

Hidden-Process Detection & Kernel Integrity

Triangolazione di tre sorgenti indipendenti per individuare rootkit che nascondono processi:

• /proc/[PID]/ enumeration diretta (ciò che il kernel espone)
• ps -eo pid= (ciò che vede l'utente)
• ss -tunpH parse dei PID che possiedono socket

PID presenti in /proc ma assenti da ps → indicatore forte di LKM rootkit che hooka la readdir() syscall (MITRE T1014). PID che possiedono socket ma non compaiono in /proc → possibile tampering di /proc. Risultato in system/process-forensics/hidden-process-check.json.

Kernel integrity fingerprint: SHA-256 di /proc/kallsyms (mappa degli indirizzi simboli kernel) e /proc/modules (elenco moduli caricati). Confronto cross-acquisizione sullo stesso host permette di spottare moduli iniettati a caldo. Pagina Process forensics renderizza /proc/modules parsato con colonne leggibili (size human-readable, stato Live/Loading, taint flags con badge colorati P/O/E/F con tooltip esplicativo).

Catena di custodia rinforzata

Tre modifiche strutturali al chain of custody, conformi ai requisiti di ISO/IEC 27037 §5.4.2 (integrità dello strumento) e del principio dei "quattro occhi" per operazioni irreversibili:

• Tool attestation: SeizeLOG computa MD5 + SHA-1 + SHA-256 del binario running (/proc/self/exe) all'avvio, li include nel report.txt, nel PDF forense, e li invia al server backend al momento dello sblocco. Il perito può confrontarli con gli hash del binario originale distribuito e dimostrare quale esatto build ha eseguito l'acquisizione.
• Supervisore "four-eye": campi opzionali supervisor_name, supervisor_id nel file config. Se valorizzati, il report header mostra "Four-eye verified" e il DB backend persiste la doppia firma. Utile per perizie contestuali dove serve garantire che l'operatore non agisca da solo.
• Tripla hash sui file chiave: tutto l'inventory file interno al pacchetto (Acquisition File Inventory in report.txt) ha MD5, SHA-1, SHA-256. MD5 e SHA-1 servono per retrocompatibilità con tool legacy e pregresse catene di custodia pre-2015; SHA-256 resta il primario crittograficamente robusto.

DFIR Artifacts — Shell history, SSH, Login, Persistence, Containers

Pagina consolidata che raccoglie gli artefatti DFIR seguendo le metodologie UAC (Unix-like Artifact Collector), Velociraptor e SANS FOR577. Cinque tab consolidate per artefatti tipicamente sparsi su decine di file.

Integrity Verification & Rootkit Detection

Pagina dedicata alla verifica integrità del sistema e detection rootkit, con sei tab che coprono package verification, anti-rootkit, LD_PRELOAD/getcap, kernel runtime, PAM stack, mail queue.

Package verify — actionable filtering

Su un server con installazioni complesse l'output di dpkg --verify può contenere decine di migliaia di righe, di cui il 99% rumore (file installer estratti in /tmp, package cache, locale, manpage). SeizeLOG produce due output paralleli: il raw completo per la forensic completeness e una versione actionable filtrata e categorizzata per severity (CRITICAL/HIGH/MEDIUM/LOW).

Kernel runtime — dmesg, sysctl, modules, mounts

PAM stack full dump

Log Explorer e Filesystem Timeline

report.txt: il documento autoritativo con RFC 3161

Nella filosofia di SeizeLOG il file ZIP è solo un contenitore di trasporto: il documento legalmente autoritativo è report.txt, accompagnato dal token RFC 3161 report.txt.tsr.

Remediation Roadmap

Conformità normativa: NIS2, GDPR, quadro italiano

Direttiva NIS2 (UE 2022/2555) e D.Lgs 138/2024

La NIS2 è stata recepita in Italia con D.Lgs 138/2024, in vigore dal 16/10/2024. Dal 1° gennaio 2026 i soggetti NIS2 hanno l'obbligo di notificare al CSIRT Italia / ACN gli incidenti significativi secondo una procedura in tre fasi:

• Pre-notifica / Early Warning — entro 24 ore dalla conoscenza dell'incidente significativo: notifica rapida senza dettagli tecnici completi.
• Notifica di Incidente — entro 72 ore: aggiornamento con assessment iniziale di severity, impatto, indicators of compromise.
• Report finale — entro 30 giorni: descrizione dettagliata dell'incidente, cause, mitigazioni adottate.

Il pacchetto SeizeLOG fornisce direttamente gli IoC richiesti nella notifica a 72h: ogni indicator è classificato con severity, MITRE ATT&CK technique, timestamp. I findings del Compromise Assessment e dell'Attack Surface alimentano l'assessment iniziale. La Remediation Roadmap è la base del report finale a 30 giorni.

GDPR art. 33 — Notifica al Garante Privacy

Il Titolare del Trattamento che subisce una violazione di dati personali ha l'obbligo di notifica al Garante per la protezione dei dati personali senza ingiustificato ritardo e comunque entro 72 ore dalla conoscenza, salvo che la violazione sia improbabile comporti un rischio per diritti e libertà delle persone. La notifica si effettua tramite la procedura telematica obbligatoria su servizi.gpdp.it/databreach/, operativa dal 1° luglio 2021.

Se il rischio è elevato, occorre notificare anche gli interessati ex art. 34 GDPR. SeizeLOG produce evidence documentali — hosted domains (quali servizi sono coinvolti), brute force sources (quali IP hanno attaccato), compromise assessment (se l'attaccante è entrato), mail spoofing (se è stata tentata esfiltrazione via mail) — direttamente utilizzabili nella descrizione della natura della violazione richiesta dal Provvedimento Garante 30/07/2019 [9126951].

Allineamento con framework forensi internazionali

• NIST SP 800-86 — Guide to Integrating Forensic Techniques into Incident Response. SeizeLOG automatizza la fase Collection (4-step process: identify, label, record, acquire) preservando l'integrità dei dati.
• ISO/IEC 27037:2012 — Identificazione, raccolta, acquisizione e preservazione di prove digitali. SeizeLOG è conforme ai principi di repeatability, reproducibility, auditability.
• ISO/IEC 27042:2015 — Analisi e interpretazione delle prove digitali.
• ISO/IEC 27035 — Incident management.
• MITRE ATT&CK — ogni finding mappato a tactic/technique.
• CIS Benchmarks — Attack Surface e hardening.

Riferimenti italiani

• D.Lgs 138/2024 — recepimento NIS2
• D.Lgs 82/2005 art. 20 — efficacia probatoria dei documenti informatici
• L. 48/2008 — ratifica Convenzione di Budapest sul cybercrime
• Art. 234 c.p.p. — ammissibilità delle prove documentali informatiche
• Regolamento eIDAS art. 41-42 — validazione temporale elettronica qualificata
• GDPR art. 32-34 — sicurezza, notifica al Garante, comunicazione agli interessati
• Provvedimento Garante Privacy 30/07/2019 n. 9126951 — notifica violazioni dati personali

Inventario file con SHA-256 e purpose

Il blocco Acquisition File Inventory in report.txt è il cuore del valore probatorio. Tabella filePurposeTable mappa ~40 pattern di file a descrizione semantica:

  analysis/ioc-report.json
    size:    3.9 KB
    sha256:  c0a4377781fdd0705fd83b397d4efc00edab6cc90feafdef7e98515bcf7ea757
    purpose: IOC indicators (cron, systemd, bashrc, webshells, SUID, SSH keys)

  analysis/processes-report.json
    size:    87.2 KB
    sha256:  ...
    purpose: Processes, listening ports, active TCP/UDP connections

  operations-log.txt
    size:    5.0 KB
    sha256:  ...
    purpose: Per-step operations log with NTP offsets and timings

Tariffazione a slot e marca temporale qualificata

1 MB di pacchetto compresso = 1 slot (minimo 1 slot). Marca temporale InfoCert qualificata eIDAS: +2 slot. Gli slot vengono scalati solo al momento dello sblocco (non al momento dell'acquisizione). --dry-run per stima preventiva.

Il dump RAM opzionale (--with-memory) è escluso dal calcolo slot: billable_size = zip_size − ram_dump_compressed_size. Il dump è un extra tecnico (può pesare diversi GB) che va nel pacchetto cifrato e contribuisce al zip_sha256 — la catena di custodia resta intatta — ma non impatta la tariffazione. Il backend persiste i metadati ram_dump_acquired, ram_dump_method (avml/kcore/per-process), ram_dump_size_raw, ram_dump_size_compressed, ram_dump_sha256 per audit.

Supporto distribuzioni, modalità root/non-root, admin_ips

Debian, Ubuntu, RHEL, CentOS, Rocky, Alma, Fedora, Amazon Linux, Oracle Linux, Alpine (OpenRC), SUSE, Gentoo. Rilevamento automatico via /etc/os-release. Whitelist distro-specific per cron (dnf-automatic, yum-cron, anacron, updatedb, mandb, sysstat, zypper) e PAM (common-auth Debian, system-auth RHEL, common-auth-pc SUSE).

Modalità --notroot: acquisisce tutto ciò accessibile all'utente, documenta in system/not-collected.txt cosa non è stato raccolto. Adatto a container e account limitati.

Config admin_ips: lista IP pubblici dell'operatore (home ISP, office VPN) che bypassano l'heuristic "suspicious login from public IP" del Compromise Assessment.