Utenti, gruppi e account

Il problema

Ogni account che può autenticarsi è una porta. Molte di queste porte non servono: account di servizio creati dai pacchetti, utenti di test mai rimossi, account di ex collaboratori. Un attaccante che fa bruteforce o riusa credenziali trapelate cerca proprio queste porte dimenticate. Il primo lavoro di hardening sugli account è sapere chi c’è e chiudere ciò che non deve entrare.

Leggere passwd e shadow

Gli account vivono in due file. /etc/passwd (leggibile da tutti) elenca gli account; /etc/shadow (solo root) tiene gli hash delle password e le policy di scadenza.

1
2
3


# formato passwd: nome:x:UID:GID:commento:home:shell
grep -E ':[0-9]{4,}:' /etc/passwd    # account con UID >= 1000 = tipicamente umani
getent passwd | awk -F: '$3>=1000 && $3<65534 {print $1, $3, $7}'

Il campo chiave per la sicurezza è l’ultimo: la shell. Un account di servizio non deve avere una shell interattiva.

1
2


# account di sistema (UID < 1000) che però hanno una shell di login = sospetto
awk -F: '$3<1000 && $7 ~ /sh$/ {print $1, $3, $7}' /etc/passwd

I demoni (nginx, postgres, …) girano sotto account dedicati che non devono poter fare login. La shell corretta per loro è /usr/sbin/nologin (o /bin/false): se qualcuno prova ad autenticarsi, viene rifiutato.

1
2
3
4
5
6


# imposta nologin su un account di servizio
usermod -s /usr/sbin/nologin postgres

# blocca la password di un account (login via password impossibile; la ! in shadow)
passwd -l nomeutente
passwd -S nomeutente          # stato: L = locked, P = password set, NP = nessuna password

Attenzione a NP (nessuna password): un account senza password che accetta login è un buco grave.

1
2


# trova account con password VUOTA (gravissimo)
awk -F: '($2==""){print $1" NON ha password!"}' /etc/shadow

Scadenza e policy

chage gestisce la vita di una password: scadenza, intervallo minimo/massimo, avviso. Non abusarne (password che scadono troppo spesso spingono a sceglierne di deboli), ma su account sensibili serve.

1
2


chage -l matteo                 # mostra le date di scadenza
chage -M 365 -W 14 matteo       # max 365 giorni, avviso 14 giorni prima

Mantenere pulito l’elenco

1
2
3
4
5


Controlli periodici sugli account:
  - chi ha UID 0 oltre a root? (NON dovrebbe essercene nessun altro)
  - chi appartiene ai gruppi potenti: sudo/wheel, docker, adm?
  - ci sono account di persone che non ci sono più?
  - ci sono account senza password o con shell dove non serve?

1
2
3
4
5


# chi altro ha UID 0 (= poteri di root)? deve stampare solo "root"
awk -F: '$3==0 {print $1}' /etc/passwd

# membri del gruppo che garantisce sudo (sudo su Debian, wheel su RHEL)
getent group sudo wheel docker

Il gruppo docker merita una nota: chi vi appartiene può, di fatto, diventare root (montando il filesystem host in un container). Trattalo come appartenenza a wheel/sudo.

Domanda: gli account di servizio li crea il gestore pacchetti già configurati con nologin. Perché controllarli a mano se la distribuzione fa la cosa giusta di default?

Perché "di default" copre il caso pulito ma non la realtà di un sistema vissuto, ed è proprio nelle deviazioni dal default che si annidano i problemi. Primo, non tutti i pacchetti sono scrupolosi: software di terze parti, script di installazione scaricati, vecchi pacchetti o configurazioni ereditate possono creare account con shell di login "perché era comodo durante lo sviluppo". Secondo, i sistemi cambiano mano: un account creato nologin può essere modificato nel tempo — qualcuno gli dà una shell per fare debug e non la toglie, un ripristino da backup riporta una vecchia configurazione, una migrazione copia account senza rivederli. Terzo, il controllo non serve solo a trovare l'errore del packager, ma a mantenere una baseline: sapere esattamente quali account esistono e quali possono autenticarsi è ciò che ti permette di accorgerti se ne compare uno nuovo e inatteso — che è uno dei segni classici di una compromissione (un attaccante che si crea un account di persistenza). Non stai sfiduciando la distribuzione: stai costruendo la conoscenza di "cosa è normale" sul tuo sistema, senza la quale non puoi riconoscere l'anomalia. Il comando che elenca gli UID 0 o gli account senza password costa secondi e va messo tra i controlli periodici proprio perché l'unico momento in cui scopri un account di troppo non dev'essere dopo che è stato usato contro di te.

Conclusione

Sapere quali account esistono, dare nologin ai servizi, bloccare le password inutili, sorvegliare chi ha UID 0 e le appartenenze a gruppi potenti: è l’igiene base degli accessi. Ma decidere chi può entrare è metà del lavoro; l’altra metà è cosa ciascuno può toccare una volta dentro — i permessi dei file, prossimo capitolo.