Analizzare i log del server web dopo un attacco: leggere correttamente l'access log

In breve: chi vuole analizzare l'access log dopo un attacco mette prima al sicuro i log senza modificarli e poi lavora solo con copie. Si cercano richieste con stato 200 su file PHP sconosciuti, richieste POST sospette, accessi alle directory di upload e schemi temporali. Per PHP2Shell non esistono Indicators of Compromise pubblicati e confermati, perciò conta il quadro d'insieme di più fonti di log.

Prima mettere al sicuro, poi analizzare

Sulla maggior parte dei server i file di log vengono ruotati automaticamente e cancellati dopo un tempo fisso. Dopo un attacco il primo passo è quindi mettere al sicuro i log esistenti prima che scompaiano. Vale anche se non è ancora sicuro che sia successo qualcosa. Per PHP2Shell la stampa specializzata consiglia di conservare i log a partire dal 20/10/2026.

# Copiare i log con i timestamp e registrare i checksum
ZIEL=/root/sicherung-logs-$(date +%F)
mkdir -p "$ZIEL"
cp -a /var/log/nginx /var/log/apache2 /var/log/php* "$ZIEL"/ 2>/dev/null
cp -a /var/log/auth.log* /var/log/syslog* "$ZIEL"/ 2>/dev/null
find "$ZIEL" -type f -exec sha256sum {} + > "$ZIEL.sha256"

Depositi la copia di sicurezza anche su un altro sistema. Un aggressore con accesso al server potrebbe altrimenti modificare i log a posteriori. I checksum dimostreranno in seguito che la copia è invariata. Se serve una copia di sicurezza utilizzabile in sede giudiziaria, ad esempio per una denuncia o per l'assicurazione, dovrebbe occuparsene un'analisi forense IT.

Dove si trovano i log e come è fatta una riga

I luoghi di archiviazione dipendono da distribuzione e interfaccia di gestione. Percorsi tipici:

Nel diffuso formato Combined ogni riga contiene l'indirizzo del client, data e ora, metodo e percorso della richiesta, il codice di stato, la dimensione della risposta in byte, il referer e lo user agent. Faccia attenzione al fuso orario nel timestamp, in particolare quando confronta i log con segnalazioni in UTC. Le patch di PHP2Shell, ad esempio, sono state pubblicate il 21/10/2026 alle 14:00 UTC, cioè alle 16:00 ora tedesca.

Se il Suo sito si trova dietro un proxy, una CDN o un load balancer, nel log potrebbe comparire solo il loro indirizzo. Il vero indirizzo del visitatore si trova allora in un campo apposito o nei log del servizio a monte.

Senza riga di comando: log nel pannello o presso l'hoster

Non ogni gestore ha accesso alla shell. Con lo shared hosting o i server gestiti, le interfacce di gestione offrono di solito una visualizzazione dei log e il download di access ed error log. Scarichi i file per l'intero periodo disponibile e li conservi in modo sicuro. Chieda per iscritto al Suo hoster per quanto tempo i log vengono conservati e se si possano mettere al sicuro gli stati più vecchi prima che scadano.

Tenga presente la protezione dei dati: i log contengono indirizzi IP e spesso ulteriori dati personali. Salvi le copie con accesso protetto, le comunichi solo a persone che ne hanno bisogno per il chiarimento e stabilisca quando verranno cancellate dopo la chiusura dell'incidente.

Analizzare l'access log: le interrogazioni principali

I comandi seguenti sono in sola lettura e adatti a Nginx e Apache nel formato Combined. I file ruotati e compressi si consultano con zgrep o zcat.

LOG=/root/sicherung-logs-2026-10-25/nginx/access.log

# Richieste riuscite a file PHP, per frequenza
awk '$9 == 200 && $7 ~ /\.php/ {split($7,p,"?"); print p[1]}' "$LOG" | sort | uniq -c | sort -rn | head -40

# Chiamate PHP nelle directory di upload, cache o immagini
grep -E '"(GET|POST) /[^ ]*(uploads|cache|images|tmp)/[^ ]*\.php' "$LOG"

# Richieste POST per destinazione e indirizzo
awk '$6 == "\"POST" {print $1, $7}' "$LOG" | sort | uniq -c | sort -rn | head -40

# Errori 5xx per ora: gli accumuli possono indicare processi PHP che si bloccano
awk '$9 ~ /^5/ {print substr($4, 2, 14)}' "$LOG" | sort | uniq -c

# Includere i log ruotati
zgrep -h ' 200 ' /var/log/nginx/access.log.*.gz | grep -c '\.php'

Nella prima interrogazione interessano in particolare i nomi di file che non conosce o che non appartengono all'applicazione. Confronti i file sospetti con il file system: quando sono stati creati, a chi appartengono, che cosa contengono? Indicazioni al riguardo si trovano nella guida Riconoscere e rimuovere le webshell.

Particolarità di PHP2Shell

Con PHP2Shell le vulnerabilità si trovano nell'elaborazione delle richieste di PHP stesso. Con mod_php è stato dimostrato un exploit prima ancora che venga eseguito il codice dell'applicazione. Ciò significa che può bastare una richiesta a una pagina del tutto normale. Nell'access log una simile richiesta può apparire non sospetta, perché il contenuto del corpo della richiesta non vi compare.

Non esistono Indicators of Compromise pubblicati e confermati. Faccia quindi attenzione a comportamenti e nessi, ad esempio dal 17/10/2026, il primo tentativo di attacco osservato secondo i media:

• Accumuli di errori 500 o di risposte interrotte su pagine ordinarie.
• Segnalazioni di memoria esaurita o di worker terminati nell'error log e nel log di PHP-FPM.
• File PHP nuovi o file modificati poco dopo tali accumuli.
• Nuovi cronjob, processi o connessioni in uscita con l'utente del server web.

Nessuno di questi segnali è da solo una prova. Insieme ad altre tracce danno però un quadro che risponde alla domanda su una compromissione o giustifica un'indagine più approfondita. Una panoramica dei segnali si trova in Sono già stato compromesso?.

Altre fonti: error log, PHP-FPM e log di sistema

L'access log mostra solo una parte. Per un quadro completo consulti altre fonti:

# PHP-FPM e server web nel journal a partire da una data
journalctl -u 'php*-fpm*' --since "2026-10-17" --no-pager | tail -200

# Accessi al server
last -Fa | head -40
grep -E 'Accepted|Failed' /var/log/auth.log | tail -100

# Controllare le attività pianificate di tutti gli utenti
for u in $(cut -d: -f1 /etc/passwd); do crontab -l -u "$u" 2>/dev/null | sed "s/^/$u: /"; done

Errori tipici nell'analisi sono cercare solo nel log corrente invece che anche in quelli ruotati, trascurare il fuso orario e scambiare singoli riscontri di scanner automatizzati per un attacco riuscito. Altrettanto rischioso è il contrario: considerare un access log privo di anomalie come un cessato allarme, benché error log e file system non siano ancora stati controllati.

Annoti ogni ritrovamento con ora, fonte e osservazione in una cronologia. Questa cronologia è in seguito la base per le decisioni, per le notifiche ad autorità o assicuratori e per il rapporto finale.

Come aiuta concretamente PHP SOS?

• Mettiamo al sicuro log e file rilevanti in modo che restino tracciabili per verifiche successive.
• Analizziamo insieme access log, error log, log PHP e log di sistema e creiamo una cronologia dell'incidente.
• In presenza di indizi di compromissione ci occupiamo della incident response con contenimento e bonifica.
• Impostiamo rotazione e conservazione dei log in modo che al prossimo incidente i dati necessari siano disponibili.

Domande frequenti

Fonti

• TechTarget: PHP2Shell, 22M exposed servers at risk
• php.net: bollettini di sicurezza
• BSI IT-Grundschutz (protezione di base IT del BSI)