SeizeLOG: il Tool che Acquisisce e analizza i log di un server online

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

In questi quattro comandi SeizeLOG ha fatto, al posto tuo:

• Verificato la sincronia dell'orologio via NTP (timestamp difendibile in tribunale)
• Identificato univocamente il server con FQDN e tutti i domini ospitati
• Scoperto tutti i log presenti (discovery a 3 livelli)
• Acquisito log, configurazioni, timeline filesystem con hash SHA-256
• Enumerato processi, porte, connessioni attive con IP remoto
• Analizzato lo stack mail: Postfix, Dovecot, Exim, OpenDKIM
• Correlato tentativi falliti con login riusciti successivi
• Generato report PDF + report.txt timestampato RFC 3161 + 16 pagine HTML
• Cifrato il pacchetto con AES-256-CBC

In aula, il consulente della controparte cercherà di contestarti ogni cifra. Con SeizeLOG hai la risposta pronta: risk score calcolato da 10 moduli indipendenti, ognuno con la sua metodologia documentata, findings tracciati con riferimenti CIS Benchmarks e MITRE ATT&CK. Nessun numero è arbitrario.

L'Executive Summary mostra lo stato istantaneo del server: chi ha trovato cosa, quanto pesa, cosa fare. È la prima pagina che il giudice leggerà — e in 30 secondi saprà se c'è stato un breach, quanto è grave, quali azioni immediate servono.

• Hostname di sistema + hostname -A
• Reverse DNS degli IP pubblici
• Directory Let's Encrypt (certificati effettivamente deployati)
• Direttive server_name di Nginx
• Direttive ServerName/ServerAlias di Apache
• Postfix mydestination + virtual_*_domains

Ogni dominio nel report appare con la lista delle sorgenti che lo confermano: esempio.com [nginx, letsencrypt, postfix]. Identificazione forense univoca, multipla, tracciabile. E insieme ai domini: FQDN, hardware, CPU, RAM, IP pubblico, IPv6, gateway, DNS, reverse DNS.

C'è stata un'intrusione? Il modulo Compromise Assessment correla sei check diversi: IP pubblici con fallimenti + successi autenticazione, modifiche a file sensibili entro 30 minuti dal login, integrity dei binari di sistema via dpkg --verify, network threats noti (AbuseIPDB), processi orfani, malware hash verificati su MalwareBazaar. Il risultato è un verdetto forense: LIKELY_CLEAN, SUSPICIOUS o COMPROMISED, con confidence score e breakdown delle evidenze raccolte.

Quanti attacchi ha subito? Il modulo Brute Force raggruppa i tentativi falliti per IP e utente, li geolocalizza su una mappa mondiale interattiva, e — con soglia robusta ≥5 tentativi — identifica gli IP che sono poi riusciti ad autenticarsi (compromised IPs). Un typo isolato non è più considerato attacco: l'algoritmo distingue incidenti reali da rumore di fondo.

Chi si è collegato al server e quando? Il modulo Sessions ricostruisce ogni login SSH con timestamp, IP sorgente, paese (GeoIP), metodo di autenticazione (publickey vs password), durata della sessione. In più: parsing di access log Apache/Nginx con supporto per CloudPanel, Plesk, cPanel, DirectAdmin — attack detection per SQL injection, path traversal, XSS, LFI, RCE, scanner. Cross-log correlation fra sessioni SSH e accessi web.

Ci sono tracce di persistenza malevola? Il modulo IOC scandaglia cron persistence (con whitelist per pannelli di controllo noti), systemd backdoor, bashrc manipulations, SSH authorized_keys recenti, binari SUID anomali, webshell PHP con scoring basato su pattern (eval + obfuscation, chr() chain, preg_replace /e, base64 + eval). Nessun falso positivo da cron job legittimi di CloudPanel o cPanel.

Quali vulnerabilità non sono ancora state patchate? Il CVE Scan confronta i pacchetti installati con il database NVD: per ogni servizio in esecuzione elenca le CVE con severity CVSS, stato fixed/unfixed, versione vulnerabile vs versione patchata. Distingue fra CVE su servizi attivi (pesano sul Risk Score) e CVE su pacchetti inattivi (documentati ma non contano).

Il server è configurato correttamente? Il modulo Attack Surface audita la configurazione secondo CIS Benchmarks e MITRE ATT&CK: SSH, sudoers, PAM, open ports con classificazione process-aware, capabilities, Docker exposure, kernel hardening, NFS/SMB, SSL certs, backup esposti nel webroot, world-writable, presenza di compilatori in produzione. Whitelist per configurazioni legittime (PAM standard Debian/Ubuntu/RHEL, file distribuiti con CMS) — zero rumore.

Ci sono cipher deboli o certificati scaduti? Il modulo Recon & TLS esegue probe TLS sui servizi in ascolto: protocollo negoziato, cipher suite, detection di cipher deboli (RC4, 3DES, NULL, MD5). Validazione certificati con whitelist per snakeoil/panel (cloudpanel.clp, .local, cpanel, plesk). HTTP security headers: CSP, HSTS, X-Frame-Options, Referrer-Policy. OSINT + Certificate Transparency lookup.

Tre livelli di analisi: configurazione (myhostname, mynetworks, TLS, SASL, restrictions, virtual maps), mailbox/utenti virtuali, log analytics con 26+ metriche. Security findings automatici: open relay, TLS disabilitato, cert/key mancanti, banner che rivela versione, Dovecot ssl=no, plaintext auth, OpenDKIM non firmante, chiave privata DKIM con permessi leaky, spoof di domini locali.

Il parsing log distingue rigorosamente mittenti legittimi da spoofing: top senders conta solo messaggi effettivamente accettati dal postfix/qmgr, top recipients solo status=sent. Gli indirizzi from= usati nei reject vengono tracciati separatamente come spoofed senders — mai confusi con mittenti reali. Delivery outcomes (delivered, bounced, deferred, discarded, held, expired), reject categories (relay, RBL, HELO, PTR, greylist, milter), connection events (timeout, rate-limited, too-many-errors), SASL/IMAP/POP3 auth, TLS protocolli per versione, verdetti DKIM/DMARC/SPF.

Il risultato è un'analisi forense completa della posta: sai chi ha cercato di usare il tuo server come relay, da quale IP, con quale dominio spoofato, verso quale destinatario. Tutti i findings con severity e remediation concreta: pubblicare SPF restrittivo (-all), DKIM, DMARC (p=reject), abilitare disable_plaintext_auth, aggiornare TLS a ≥1.2.

• Ogni processo con PID, user, comando, binario eseguito, flag "deleted" se il binario è stato cancellato dopo l'avvio
• Classificazione automatica: system daemon noto (sshd, nginx, mysqld, ...) vs applicazione utente vs sconosciuto vs sospetto (eseguibile in /tmp, /dev/shm, binario cancellato)
• Ogni porta in ascolto con processo proprietario e scope (loopback vs esposta esternamente)
• Ogni connessione attiva con direzione: inbound (qualcuno che ci attacca in quel momento), outbound (il server che parla con qualcuno — potenzialmente un C2), local
• Findings CRITICAL su processi da directory temporanee (MITRE T1036.005), HIGH su binari cancellati (T1070.004)

Questi dati, raccolti prima che l'amministratore riavvii il server, sono irrecuperabili altrimenti. Una volta riavviato, i processi in memoria non ci sono più, le connessioni ESTAB vengono chiuse, i binari cancellati sparirebbero dal filesystem. SeizeLOG li cattura come snapshot forense, con attribuzione di ogni listener al suo processo proprietario e ogni connessione alla sua direzione.

Log Explorer — naviga i 1220 file di log raccolti, 43 MB compressi, filtrati per categoria (auth, web, database, mail, system, application). Per ogni file: path originale, categoria, dimensione, SHA-256 verificabile con un click.

Timeline filesystem — un calendario visuale mostra l'attività giornaliera sul filesystem. Ogni giorno riporta quanti file sono stati modificati, quanti Auth success/failed, quanti pacchetti installati, quanti file sospetti comparsi. Cliccando un giorno si espande la lista degli eventi cronologici.

Al suo interno:

• Header con UUID acquisizione, data UTC, operatore, fascicolo
• Server Identification completa con tutti i domini ospitati
• Executive Summary con Risk Score e stato di ciascun modulo
• Acquisition File Inventory: ogni file del pacchetto con path, size, SHA-256, purpose descrittivo — autosufficiente per verifica integrità
• Chain of Custody dichiarazione

La marca temporale RFC 3161 è applicata direttamente ai byte di report.txt: in tribunale produrrai quel file + il .tsr e dimostrerai con valore legale opponibile a terzi che il contenuto è identico a quello generato dall'acquisizione, in quella precisa data e ora.

La Remediation Roadmap è la risposta operativa alla domanda "e ora cosa faccio?". Ogni finding HIGH o CRITICAL genera una voce con priorità (IMMEDIATE ≤ 24h, SHORT ≤ 1 settimana, MEDIUM ≤ 1 mese), categoria, dettaglio, e — dove possibile — comando concreto da eseguire (es. sudo apt-get install --only-upgrade nginx). Riferimenti CIS Benchmark e MITRE ATT&CK per ciascuna azione.

Quando l'attaccante cancella il binario malevolo dal disco ma il processo resta in esecuzione, l'unica prova rimane nel kernel: il file handle aperto su un inode già rimosso. SeizeLOG cattura questo snapshot via lsof -nP +c 0: ogni file descriptor — file regolari, socket di rete, pipe, dispositivi, librerie mappate — con processo proprietario e flag deleted in evidenza. Tab dedicata "Deleted & held" isola immediatamente questo indicatore di MITRE T1070.004.

Pagina dedicata alla composizione della memoria con donut chart inline (zero dipendenze esterne, funziona offline) e indice sticky in cima per saltare a qualsiasi sezione. Stat card RAM, donut chart per RAM e Swap con pressure indicator automatico (OK/MEDIUM/HIGH), Quick figures (Memory pressure, Dirty pages, Anonymous, Mapped, Slab), tabella dettagliata raggruppata per categoria con barra orizzontale per ogni voce di /proc/meminfo. Riconosci a colpo d'occhio se il sistema era sotto pressione di memoria al momento dell'incidente — un indicatore importante in caso di OOM kill o ransomware in esecuzione.

Pagina consolidata che raccoglie gli artefatti DFIR seguendo le metodologie UAC, Velociraptor e SANS FOR577 — gli stessi standard usati nei team SOC e nei corsi di certificazione internazionali. Cinque tab: Shell history (i comandi reali eseguiti dall'attaccante), SSH artifacts (chi può entrare, da dove), Login history forensic-grade da binari wtmp/btmp, Persistence (cron + autostart + at), Containers (Docker/Podman/k8s). Tutto navigabile, filtrabile, con file collassabili.

L'output di dpkg --verify su un server reale può contenere decine di migliaia di righe, di cui il 99% rumore (file installer, package cache, locale). Senza filtro è inutilizzabile in perizia. SeizeLOG produce un actionable view filtrato e categorizzato per severity: CRITICAL per binari di sistema (rootkit T1554), HIGH per auth/persistence (sudoers, pam.d, systemd), MEDIUM per config /etc generic, LOW per user-data. Ogni voce è interpretata in linguaggio umano (es. "MD5 checksum mismatch — content modified") con LEGEND completo del formato 9-character. Il raw resta disponibile per la forensic completeness.

Stato runtime del kernel — dmesg, sysctl, lsmod, mounts — utile per audit hardening e detection di moduli kernel sospetti (rootkit kernel-mode T1014). PAM stack full dump per documentare in perizia la configurazione effettiva di autenticazione (T1556). LD_PRELOAD check con alert immediato se non vuoto (rootkit user-space tipico). getcap completo per identificare la privilege escalation surface.