Cosa fa#
File di testo in /var/log/auth.log che raccoglie tutti gli eventi di autenticazione del sistema — login SSH, sudo, su, creazione e cancellazione utenti, sessioni PAM. E' scritto da rsyslog che riceve eventi dai servizi tramite il socket syslog. A differenza del journal di systemd, e' un file di testo modificabile da chiunque abbia accesso root.
TL;DR#
# Leggi in tempo reale
sudo tail -f /var/log/auth.log
# Filtra solo i login falliti
grep "Failed password" /var/log/auth.log
# Conta per IP
grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -rnStruttura di una riga#
2026-03-25T00:52:56.715577+00:00 barno-server sshd[26654]: Accepted publickey for barno from 192.168.64.1 port 53834 ssh2
│ │ │ │ │ │
│ │ │ │ │ └─ messaggio evento
│ │ │ │ └─ PID del processo
│ │ │ └─ nome servizio
│ │ └─ hostname
│ └─ timezone offset
└─ timestamp ISO 8601Pattern chiave da riconoscere#
# Login SSH riuscito con chiave pubblica
Accepted publickey for barno from 192.168.64.1 port 53834 ssh2
# Login SSH riuscito con password
Accepted password for barno from 192.168.64.1 port 53834 ssh2
# Login SSH fallito — utente inesistente
Failed password for invalid user pippo from 192.168.64.1 port 53936 ssh2
pam_unix(sshd:auth): check pass; user unknown
# Login SSH fallito — utente esistente, password sbagliata
Failed password for barno from 192.168.64.1 port 53936 ssh2
# sudo riuscito
sudo: barno : TTY=pts/0 ; PWD=/home/barno ; USER=root ; COMMAND=/usr/bin/apt update
# sudo bloccato — non in sudoers
sudo: barno : user NOT in sudoers ; TTY=pts/0 ; COMMAND=/usr/bin/cat /etc/shadow
# su riuscito con login shell
su[27176]: (to testuser) barno on pts/2
pam_unix(su-l:session): session opened for user testuser(uid=1001)
# Creazione utente
useradd[27123]: new user: name=testuser, UID=1001, GID=1001, home=/home/testuser
# Cancellazione utente
userdel[27211]: delete user 'testuser'
# Cron job di sistema (normale — compare ogni 5-10 minuti)
CRON[26602]: pam_unix(cron:session): session opened for user root(uid=0)
CRON[26602]: pam_unix(cron:session): session closed for user rootauth.log vs journal vs btmp#
auth.log journal (journald) btmp
──────────────────── ─────────────────────── ──────────────────
testo in chiaro database binario binario
alterabile da root FSS — modifiche rilevabili alterabile da root
scritto da rsyslog scritto da systemd scritto da pam_faillog
tutti gli eventi auth tutti gli eventi sistema solo login falliti
grep funziona journalctl per leggere lastb per leggereIl journal e' piu' resistente alla manomissione grazie a FSS (Forward Secure Sealing - sigillatura sicura in avanti) — ogni blocco e' firmato crittograficamente. auth.log puo' essere svuotato silenziosamente con > /var/log/auth.log. La soluzione definitiva e' il log forwarding esterno — Wazuh lo fa al mese 3.
Comandi essenziali#
# Lettura in tempo reale
sudo tail -f /var/log/auth.log
# Tutti i login falliti
grep "Failed password" /var/log/auth.log
# Solo i login SSH riusciti
grep "Accepted" /var/log/auth.log
# Tutti i sudo
grep "sudo:" /var/log/auth.log
# Tutti i cambi utente con su
grep " su:" /var/log/auth.log
# Creazione e cancellazione utenti
grep -E "useradd|userdel|adduser" /var/log/auth.log
# Conteggio login falliti per IP — script di triage
grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -rnScenario Reale#
Un analista riceve un alert alle 03:14. Apre auth.log e cerca i pattern in sequenza:
grep "Accepted" /var/log/auth.log— c'e' stato un login riuscito?grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn— da quali IP vengono i tentativi?grep "sudo:" /var/log/auth.log— dopo il login, ha usato sudo?grep "useradd\|userdel" /var/log/auth.log— ha creato o cancellato utenti?
Se la sequenza e' "molti login falliti → login riuscito → sudo → useradd", e' un pattern classico di compromissione.
Dove l'ho incontrato#
- Lab Ubuntu mercoledi' 25 marzo — primo contatto con log reali
- sudo — ogni sudo lascia traccia qui
- pam — ogni evento PAM finisce qui
Collegato a#
- iam — categoria
- log — categoria
- pam — genera la maggior parte degli eventi
- journald — alternativa piu' resistente
- journalctl — per leggere il journal
- lastb — per i login falliti da btmp
- sudo — traccia tutti i comandi sudo
- ssh — traccia tutti i login SSH




