In un SOC, saper leggere lo stato di un host Linux è tanto importante quanto analizzare il traffico di rete. Un analista deve distinguere un daemon legittimo da un processo malevolo e riconoscere le condizioni che permettono a un attaccante di elevare i privilegi fino a root.

Processi e fork

Ogni programma in esecuzione è un processo, identificato da un PID. I processi nascono per fork: un processo padre si duplica e il figlio spesso sostituisce la propria immagine con exec(). Da qui deriva la gerarchia visibile con pstree: il capostipite è init/systemd (PID 1), che adotta i processi orfani. Ogni processo gira con un UID e GID effettivi che ne determinano i permessi.

ps -ef        # elenco completo con PID, PPID, utente
ps aux        # aggiunge %CPU, %MEM, comando
top / htop    # vista dinamica in tempo reale

L’analista osserva utente proprietario, percorso del binario e processo padre. Segnali sospetti: un processo in ascolto lanciato da una shell interattiva, un binario in /tmp o /dev/shm, un nome che imita un daemon di sistema ma con path anomalo.

Permessi e ownership POSIX

Ogni file ha un proprietario, un gruppo e tre terne di permessi: owner, group, others. Ciascuna terna combina lettura (r=4), scrittura (w=2), esecuzione (x=1).

Notazione Ottale Significato
rwx 7 lettura, scrittura, esecuzione
rw- 6 lettura e scrittura
r-x 5 lettura ed esecuzione
r-- 4 sola lettura

ls -l mostra ad esempio -rw-r--r--: il primo carattere è il tipo (- file, d directory, l link). Su una directory, x significa poter attraversare la cartella, non eseguirla.

setuid, setgid e sticky bit

Oltre alle terne standard esistono bit speciali. Il setuid (s nella terna owner) fa girare il binario con i privilegi del proprietario del file, non di chi lo lancia. passwd è setuid root per motivi legittimi (deve scrivere /etc/shadow). Ma un binario setuid root scritto male, o una copia di bash/find con setuid impostato, diventa una scaletta diretta verso root.

find / -perm -4000 -type f 2>/dev/null   # cerca binari setuid

In ls -l il setuid appare come -rwsr-xr-x. Il setgid (s sul gruppo) applica lo stesso concetto al GID; lo sticky bit (t, tipico di /tmp → drwxrwxrwt) impedisce a un utente di cancellare file altrui in directory condivise.

Un symbolic link è un file che punta a un altro percorso (ls -l mostra link -> /path/target). Sono utili ma sfruttabili: se uno script privilegiato scrive su un percorso prevedibile, un attaccante può sostituirlo con un symlink verso un file sensibile (/etc/passwd), causando una scrittura arbitraria. Sono attacchi di symlink / race condition classici da riconoscere.

Daemon e logging

Un daemon è un processo di servizio che gira in background, senza terminale, tipicamente avviato da systemd e spesso in ascolto su una porta (sshd, cron, rsyslog). I log finiscono in /var/log:

File Contenuto
/var/log/auth.log (o secure) autenticazioni, sudo, login SSH
/var/log/syslog (o messages) eventi generali di sistema
/var/log/cron esecuzioni pianificate

Il framework syslog classifica i messaggi per facility (auth, cron, daemon…) e severity (da emergency 0 a debug 7), inoltrabili a un collector centrale/SIEM. Su sistemi con systemd si usa journalctl. Un cron sospetto in /etc/cron.* o un servizio non firmato che riparte da solo sono indicatori di persistenza.

Privilege escalation: il quadro

I permessi errati sono il vettore più comune: un file con chmod 777, una regola sudo troppo permissiva, un binario setuid inutile o uno script privilegiato che invoca comandi con path relativo (PATH hijacking). L’analista correla il processo anomalo con auth.log e con la ricerca dei setuid per ricostruire la catena.

Trappole tipiche d’esame

  • Scenario: -rwsr-xr-x root root /usr/local/bin/tool → Risposta: il bit s è setuid: il tool gira come root a prescindere dall’utente, potenziale privilege escalation da investigare.
  • Scenario: ti chiedono il significato di chmod 4755 → Risposta: setuid (4) + rwxr-xr-x; NON confonderlo con 0755 (nessun bit speciale) né con setgid (2xxx).
  • Scenario: un processo in ascolto su una porta alta, avviato da bash con binario in /tmp → Risposta: è sospetto; un daemon legittimo ha come padre systemd e binario in path di sistema (/usr/sbin).
  • Scenario: dove cerchi i tentativi di login SSH falliti? → Risposta: /var/log/auth.log (Debian/Ubuntu) o /var/log/secure (RHEL), NON syslog generico.
  • Scenario: x su una directory → Risposta: consente di attraversarla/accedervi, non di “eseguirla”; senza x non entri nella cartella anche se hai r.