Su Debian e Ubuntu, Nginx registra i log su /var/log/nginx/access.log e error.log, e Apache su /var/log/apache2/access.log e error.log. Su RHEL, Rocky e Alma, Apache utilizza /var/log/httpd/access_log e error_log, con underscore e senza estensione. Nei container creati dall’immagine ufficiale di Nginx, non ci sono file di log: tutto va su stdout e stderr, quindi docker logs è il tuo export.
Il log del server web è spesso il primo luogo in cui un’intrusione lascia una traccia: lo scanner alla ricerca di file .env, la stringa exploit, il POST a un file che non dovrebbe esistere. Prime Core ha 812 regole di rilevamento per i log dei server web, mappate su 337 tecniche MITRE ATT&CK. Tra esse: sfruttamento di app esposte (T1190), web shell (T1505.003) e scansione delle vulnerabilità (T1595.002).
Prima di iniziare
Trova i percorsi reali. Gli host virtuali spesso registrano in posizioni personalizzate. Chiedi al server stesso:
# Nginx: scarica la configurazione effettiva completa e individua le direttive del log
sudo nginx -T 2>/dev/null | grep -E 'access_log|error_log'
# Apache
sudo apachectl -S
sudo grep -Ri -E 'CustomLog|ErrorLog' /etc/apache2/ /etc/httpd/ 2>/dev/null
Su Apache basato su Debian, gli host virtuali senza il loro CustomLog finiscono in other_vhosts_access.log. Le persone se ne dimenticano continuamente.
Controlla quale indirizzo IP stai registrando. Dietro un bilanciatore di carico, un CDN o un proxy inverso, ogni richiesta può sembrare provenire dal proxy. Ciò vale a meno che il server non sia configurato per registrare il vero client: set_real_ip_from e real_ip_header in Nginx, mod_remoteip in Apache. Se ogni riga mostra gli stessi pochi IP interni, l’indirizzo dell’attaccante è solo in X-Forwarded-For, se lo registri, o nei log del proxy.
Controlla il formato. Entrambi i server predefiniscono il formato “combined”, ma molti set up lo personalizzano (log_format in Nginx, LogFormat in Apache). Nota come appare il tuo prima di caricarlo.
Permessi. Su Debian e Ubuntu questi log sono leggibili da root e dal gruppo adm; altrove, organizza con sudo.
Esportare dai file di log
I log ruotano giornalmente o settimanalmente, quindi includi i file ruotati. zcat -f legge file normali e compressi allo stesso modo:
# Nginx, attuale e ruotato, dal più antico
sudo zcat -f $(ls -tr /var/log/nginx/access.log*) > web-03_nginx_access.log
# Apache su RHEL
sudo zcat -f $(ls -tr /var/log/httpd/access_log*) > web-03_httpd_access.lo
Per un singolo giorno, i timestamp in formato combinato rendono sufficiente il grep:
grep '19/Oct/2026' web-03_nginx_access.log > web-03_access_1019.log
Prendi anche il log degli errori. I fallimenti a monte, gli errori PHP e alcuni tentativi di exploit appaiono solo lì.
Esportare dai container
# Docker: stdout è il log degli accessi, stderr il log degli errori
docker logs --since 2026-10-19T00:00:00 --until 2026-10-20T00:00:00 nginx > nginx_access.log 2> nginx_error.log
# Kubernetes
kubectl logs deploy/nginx --since=24h > nginx.log
I log dei container scompaiono con il container a meno che qualcosa non li raccolga. Se il pod è stato sostituito, controlla il collettore dei log del tuo cluster.
Cosa cercare
| Modelli | Cosa significa solitamente |
|---|---|
| Improvvisi 404 per /.env, /.git/config, /wp-login.php, /phpmyadmin | Scansione automatizzata |
| ../, ${jndi:, union select, <script> nell’URL | Tentativi di exploit: traversal, Log4Shell, iniezioni SQL, XSS |
| 200 su un POST a un file strano sotto una directory di upload | Possibile web shell; esamina cos’altro ha richiesto quell’IP |
| User agent come sqlmap, nikto, nuclei | Strumenti che non si sono curati di nascondersi |
| Un picco di 5xx subito dopo richieste strane | Qualcosa si è rotto, possibilmente perché un exploit è andato a segno |
Caricare, sanitizzare e controllare in LogTotal
- Carica. Apri logtotal.com e trascina il file.
- Sanitizza. [what gets masked: client IPs, hostnames, usernames and tokens in URLs]. Look it over before you continue. Query strings often carry session tokens.
- Controlla.
Quando le cose vanno male
| Sintomo | Probabile causa | Fix |
|---|---|---|
| No /var/log/nginx | Percorso personalizzato, o funziona in un container | nginx -T, o docker logs |
| access.log esiste ma è vuoto | I log vanno su stdout, o access_log off | Controlla la configurazione e il container |
| Ogni richiesta proviene dagli stessi IP | Proxy o bilanciatore di carico davanti; IP reale non configurato | Usa X-Forwarded-For o i log del proxy |
| Solo gli ultimi giorni | File ruotati esclusi | Usa il comando zcat -f con il glob * |
| Accesso negato | Non root, non in adm | sudo |
FAQ
Quale importa di più, il log degli accessi o quello degli errori?
Il log degli accessi dice cosa è stato richiesto. Il log degli errori dice cosa si è rotto. In un caso di sfruttamento, vuoi entrambi, uno accanto all’altro.
E per IIS?
IIS scrive i log W3C in C:inetpublogsLogFiles per impostazione predefinita. Serve una guida a parte.