In breve: prima di reinstallare un server compromesso, conservi le prove nell'ordine della loro volatilità: per primi processi, connessioni e utenti connessi, poi log e configurazione, quindi un'immagine completa del sistema e i dati dei servizi a monte. Ogni copia riceve un checksum e viene custodita fuori dal server. Per farlo il server viene scollegato dalla rete, ma non spento.
Il riflesso di reinstallare subito
Chi scopre un'intrusione vuole porvi fine il più in fretta possibile. Un sistema nuovo, installato in modo pulito, con password nuove: dà una sensazione di controllo. Dal punto di vista tecnico la ricostruzione è spesso anche la via giusta, soprattutto se l'aggressore aveva i privilegi di root.
Il problema è il momento. Con il vecchio sistema scompaiono tutte le risposte alle domande che arrivano nei giorni successivi. Attraverso quale falla è entrato l'aggressore? Da quando era nel sistema? Aveva accesso ai dati dei clienti? Anche il server del database accanto è interessato? Senza tracce restano solo supposizioni, e queste non aiutano né per la protezione dei dati né per l'assicurazione.
Dopo PHP2Shell si aggiunge un punto particolare: non esistono Indicators of Compromise pubblicati e confermati. Se e come un server sia stato interessato si può dedurre solo dal comportamento, cioè proprio dalle tracce che una ricostruzione precipitosa cancella. La stampa specializzata consiglia di conservare i log del server a partire dal 20.10.2026.
Conservazione delle prove sul server: l'ordine conta
Le tracce hanno una volatilità diversa. Ciò che sta nella memoria è perso al prossimo riavvio. I log durano più a lungo, ma vengono ruotati. I dati sui servizi a monte scompaiono secondo i loro termini. Ne deriva l'ordine:
| Traccia | Volatilità | Come conservarla |
|---|---|---|
| Processi, connessioni di rete, utenti connessi | scompare al riavvio | scrivere in file gli output dei comandi di sistema |
| Memoria | scompare al riavvio | solo con strumenti specializzati, compito per i periti forensi |
File temporanei in /tmp o /dev/shm |
spesso cancellati al riavvio | copiare, senza eseguire |
| Log di server web, PHP, sistema | vengono ruotati | copiare per intero, fermare la rotazione |
| File system e database | stabile fino alla reinstallazione | snapshot o immagine del supporto, esportazione del database |
| CDN, WAF, firewall, hoster | conservazione secondo i termini del fornitore | richiedere l'esportazione, farsela confermare per iscritto |
La memoria la acquisisca solo se sono disponibili una persona con lo strumento adatto e con esperienza. Per sistemi con dati sensibili o una controversia legale prevedibile, se ne dovrebbe occupare un servizio di IT forensics.
Acquisire i dati volatili in pochi minuti
I comandi seguenti non modificano nulla nel sistema. Scrivono lo stato attuale in file che vengono poi messi al sicuro fuori dal server. Crei la directory di destinazione possibilmente su un supporto collegato e separato:
ZIEL=/mnt/sicherung/fall-$(date -u +%Y%m%dT%H%MZ)
mkdir -p "$ZIEL"
date -u > "$ZIEL/zeitpunkt-utc.txt"
ps auxwwf > "$ZIEL/prozesse.txt"
ss -tunap > "$ZIEL/verbindungen.txt"
who -a > "$ZIEL/angemeldet.txt"
last -F > "$ZIEL/anmeldungen.txt"
ip addr > "$ZIEL/netz.txt"; ip route >> "$ZIEL/netz.txt"
for u in $(cut -d: -f1 /etc/passwd); do crontab -l -u "$u" 2>/dev/null | sed "s/^/$u: /"; done > "$ZIEL/cronjobs.txt"
sha256sum "$ZIEL"/* > "$ZIEL.sha256"
Come mettere al sicuro e analizzare poi i log per intero lo descrive la guida Analizzare i log del server web dopo un attacco. Sui server virtuali, uno snapshot tramite la gestione del fornitore è la via più semplice per un'immagine completa. Cattura il sistema senza che Lei debba avviare altri strumenti sul server compromesso.
Perché la copia abbia valore in seguito
Una copia vale quanto la sua prova. Tre regole la rendono affidabile:
- Checksum: ogni file acquisito riceve un checksum SHA-256. Così si potrà dimostrare in seguito che la copia non è stata modificata.
- Verbale: chi ha acquisito che cosa, quando, con quale comando, dove? Ogni consegna a terzi viene annotata. Gli specialisti la chiamano catena di custodia.
- Custodia separata: le copie vanno su un sistema a cui l'aggressore non ha avuto accesso e vengono poi usate solo in lettura.
Dopo lavori solo con le copie. Ogni analisi sull'originale modifica data e ora e può sovrascrivere le tracce. Non esegua mai file sospetti e non li apra tramite il browser.
Richieda presto i log di CDN, WAF e hoster. Questi dati si trovano fuori dal Suo server e sono difficili da manipolare per un aggressore, ma spesso vengono conservati solo per poco tempo.
Ciò che distrugge il quadro probatorio
Molte tracce non vanno perse per opera dell'aggressore, ma per un pronto intervento a fin di bene. Questi passi vanno evitati prima della copia:
- Riavvio o spegnimento: processi, connessioni e memoria poi non ci sono più.
- Antivirus con cancellazione automatica: rimuove file prima che qualcuno li abbia messi al sicuro e modifica data e ora.
- Pulizia di log o cartelle temporanee: anche se lo spazio scarseggia, prima copiare, poi cancellare.
- Installare sul server nuovi strumenti da Internet: ogni installazione scrive nel file system e può coprire tracce.
- Accedere senza necessità con credenziali privilegiate: se sul server gira ancora codice dannoso, le password inserite possono essere lette.
Proprio gli assicuratori chiedono poi che cosa è stato messo al sicuro e quando. Indicazioni sugli obblighi tipici si trovano in Assicurazione cyber: che cosa conta in caso di sinistro.
Valutare: quanto tempo c'è per la copia?
Non ogni incidente consente una lunga acquisizione. Se è in corso una fuga di dati o vengono attaccati i visitatori, ha la precedenza il contenimento. Il distacco dalla rete con il sistema in funzione concilia le due cose: l'aggressore perde l'accesso, le tracce restano. Per la maggior parte dei server web basta poi un lasso di tempo contenuto per i dati volatili e lo snapshot.
Prenda la decisione in modo consapevole e la annoti: chi ha deciso quando reinstallare e che cosa è stato messo al sicuro prima? Questa nota diventa poi parte della cronologia dell'incidente. Se la ricostruzione o la bonifica sia la via giusta lo chiarisce l'articolo Reinstallare o bonificare il server?.
Come aiuta PHP SOS in concreto?
- Acquisiamo dati volatili, log e immagini del sistema nell'ordine giusto, con checksum e verbale.
- Richiediamo i dati dei servizi a monte prima che scadano i loro termini di conservazione.
- Se necessario, con partner specializzati ci occupiamo dell'acquisizione e dell'analisi forensi.
- Solo dopo ricostruiamo il server, chiudiamo il punto d'ingresso e documentiamo l'incidente finché non è chiuso.
Domande frequenti
Perché dovrei conservare le prove prima di reinstallare?
Perché solo le tracce mostrano come è entrato l'aggressore, per quanto tempo è rimasto nel sistema e a quali dati poteva accedere. Queste risposte servono per la protezione dei dati, per l'assicurazione e per la questione se altri sistemi siano interessati. Dopo la ricostruzione sono perse.
Che cosa è più urgente nella conservazione?
I dati volatili, come processi in esecuzione, connessioni di rete e utenti connessi, scompaiono allo spegnimento. Vengono acquisiti per primi. Seguono i log, un'immagine del sistema e i dati dei servizi a monte.
Un normale backup basta come conservazione delle prove?
Di solito no. Molti backup non contengono log, file di sistema né metadati come data e ora e proprietario. Per la conservazione delle prove serve una copia completa e non modificata con checksum, idealmente uno snapshot o un'immagine del supporto.
Posso scollegare il server dalla rete prima della copia?
Sì, se nel frattempo resta in funzione. Il distacco dalla rete ferma la fuga di dati e il controllo remoto senza distruggere le tracce volatili. Un riavvio o lo spegnimento, invece, cancella la memoria e i processi in esecuzione.