Cosa fa#
Sistema di autenticazione modulare di Linux. Quando un servizio (SSH, sudo, login) deve autenticare un utente, non gestisce l'autenticazione da solo — delega a PAM. PAM esegue una catena di moduli configurabili, ognuno con un compito preciso. Questo e' il motivo per cui nei log vedi sempre pam_unix(sshd:auth) invece di sshd:auth.
TL;DR#
ssh pippo@server
│
▼
sshd ──delega──► PAM
│
▼
catena moduli /etc/pam.d/sshd
│
pam_unix → controlla /etc/passwd e /etc/shadow
pam_limits → controlla limiti risorse
pam_env → imposta variabili d'ambiente
│
▼
autenticazione: OK o FAILED
│
▼
log in /var/log/auth.log:
pam_unix(sshd:auth): authentication failureArchitettura — moduli e stack#
/etc/pam.d/
├── sshd ← configurazione PAM per SSH
├── sudo ← configurazione PAM per sudo
├── login ← configurazione PAM per login da console
├── su ← configurazione PAM per su
└── common-auth ← configurazione condivisa — inclusa da tuttiOgni file contiene uno stack di righe nel formato:
tipo_controllo modulo argomenti
# Esempio da /etc/pam.d/sshd:
auth required pam_unix.so # verifica password
auth required pam_nologin.so # blocca se esiste /etc/nologin
account required pam_unix.so # verifica account attivo
session required pam_unix.so # apre/chiude la sessioneI quattro tipi di gestione#
| Tipo | Cosa controlla |
|---|---|
auth | Identita' — verifica chi sei (password, chiave) |
account | Account — verifica se puoi accedere (scadenza, orari) |
password | Cambio password — regole di complessita' |
session | Sessione — setup e teardown (montare home, log) |
I flag di controllo#
| Flag | Comportamento |
|---|---|
required | Deve passare — ma esegue tutti i moduli prima di fallire |
requisite | Deve passare — se fallisce si ferma subito |
sufficient | Se passa, basta — ignora i moduli successivi |
optional | Il risultato non e' determinante |
Cosa appare in auth.log#
# Login SSH riuscito
pam_unix(sshd:session): session opened for user barno(uid=1000) by barno(uid=0)
# Login SSH fallito — utente inesistente
pam_unix(sshd:auth): check pass; user unknown
# sudo riuscito
pam_unix(sudo:session): session opened for user root(uid=0) by barno(uid=1000)
# sudo fallito — utente non in sudoers
sudo: barno : user NOT in sudoers
# su riuscito
pam_unix(su-l:session): session opened for user testuser(uid=1001) by barno(uid=1000)
# la "l" in su-l indica login shell — conferma l'uso di su -Il formato e' sempre: pam_modulo(servizio:tipo): messaggio
Moduli pam principali#
| Modulo | Cosa fa |
|---|---|
pam_unix.so | Autenticazione classica — legge /etc/passwd e /etc/shadow |
pam_nologin.so | Blocca tutti i login se esiste /etc/nologin |
pam_limits.so | Applica limiti di risorse da /etc/security/limits.conf |
pam_env.so | Imposta variabili d'ambiente al login |
pam_tally2.so | Conta i tentativi falliti — blocca dopo N fallimenti |
pam_google_authenticator.so | 2FA con Google Authenticator |
Scenario Reale#
Un analista vede in auth.log:
pam_unix(sshd:auth): authentication failure; logname= uid=0
euid=0 tty=ssh ruser= rhost=45.33.12.1 user=rootIl pattern user=root con rhost esterno significa tentativi di brute force SSH direttamente su root. La prima contromisura e' PermitRootLogin no in /etc/ssh/sshd_config — PAM non arrivera' mai a verificare la password di root perche' sshd blocca prima.
Dove l'ho incontrato#
- auth-log — ogni riga di auth.log e' generata da un modulo PAM
- sudo — sudo delega l'autenticazione a PAM
- su — su delega l'autenticazione a PAM
