Skip to main content
  1. Concetti/

auth.log - log di autenticazione

·4 mins
Alessio Barnini
Author
Alessio Barnini
Table of Contents

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 -rn

Struttura 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 8601

Pattern 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 root

auth.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 leggere

Il 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 -rn

Scenario Reale
#

Un analista riceve un alert alle 03:14. Apre auth.log e cerca i pattern in sequenza:

  1. grep "Accepted" /var/log/auth.log — c'e' stato un login riuscito?
  2. grep "Failed password" /var/log/auth.log | awk '{print $(NF-3)}' | sort | uniq -c | sort -rn — da quali IP vengono i tentativi?
  3. grep "sudo:" /var/log/auth.log — dopo il login, ha usato sudo?
  4. 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

Related