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

> Analizzare l'access log dopo un attacco: mettere al sicuro i log, trovare le tracce tipiche, comandi per Apache e Nginx e particolarità di PHP2Shell.

Fonte: https://phpsos.de/it/ratgeber/logfiles-auswerten/  
Stato: 25/10/2026  
Fornitore: PHP SOS, Assistenza di emergenza PHP e sicurezza dei server. Assistenza immediata su WhatsApp: https://wa.me/491736494914?text=Buongiorno%20PHP%20SOS%2C%20abbiamo%20bisogno%20di%20aiuto%20con%20il%20nostro%20server%20PHP.%20Azienda%3A%20%E2%80%A6%20Sito%20web%3A%20%E2%80%A6

**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.

```bash
# 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](https://phpsos.de/it/leistungen/it-forensik/).

> **Importante:**
> Verifichi la rotazione dei log (`/etc/logrotate.d/`) e prolunghi temporaneamente la conservazione, in modo che durante l'analisi non vengano cancellati altri file.

## Dove si trovano i log e come è fatta una riga

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

| Sistema | Access log ed error log |
|---|---|
| Debian, Ubuntu con Apache | `/var/log/apache2/` |
| RHEL, AlmaLinux, Rocky con Apache | `/var/log/httpd/` |
| Nginx | `/var/log/nginx/` |
| Plesk | `/var/www/vhosts/system/<domain>/logs/` |
| PHP-FPM | `/var/log/php*-fpm.log` o nel journal |

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`.

```bash
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](https://phpsos.de/it/ratgeber/webshell-erkennen/).

## 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?](https://phpsos.de/it/php2shell/bin-ich-gehackt-anzeichen/).

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

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

```bash
# 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](https://phpsos.de/it/leistungen/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

**Per quanto tempo dovrei conservare i log del server web?**  
Per quanto lo consente il Suo concetto di protezione dei dati e ha senso un'analisi. Per PHP2Shell la stampa specializzata consiglia di conservare i log a partire dal 20/10/2026. Verifichi la rotazione dei log, in modo che i file più vecchi non vengano cancellati automaticamente.

**L'access log mostra se un attacco è riuscito?**  
Non da solo. Mostra richieste, codici di stato e dimensioni delle risposte, ma non quale codice sia stato eseguito sul server. Solo insieme a error log, log di PHP-FPM, modifiche ai file e log di sistema nasce un quadro solido.

**Posso comunicare a terzi gli indirizzi IP presenti nei log?**  
Gli indirizzi IP di regola sono considerati dati personali. Per chiarire un incidente e per le denunce penali esistono sì delle basi, ma la comunicazione andrebbe concordata con il responsabile della protezione dei dati.

**Perché vedo nel log molti attacchi anche se non è successo nulla?**  
I server pubblici vengono scansionati continuamente in modo automatizzato. La maggior parte di queste richieste va a vuoto e termina con 404 o 403. Interessano soprattutto le richieste con stato 200 su file sconosciuti e gli schemi che coincidono nel tempo con altre tracce.

## Fonti

- [TechTarget: PHP2Shell, 22M exposed servers at risk](https://www.techtarget.com/cybersecurity/news/366652444/PHP2Shell-22M-exposed-servers-at-risk-as-emergency-patches-released)
- [php.net: bollettini di sicurezza](https://www.php.net/)
- [BSI IT-Grundschutz (protezione di base IT del BSI)](https://www.bsi.bund.de/DE/Themen/Unternehmen-und-Organisationen/Standards-und-Zertifizierung/IT-Grundschutz/it-grundschutz_node.html)