Hardening contro privilege escalation su sistemi Linux

Perché il privilege escalation è il punto debole più pericoloso

Su un sistema Linux ben esposto in rete, la compromissione iniziale non è quasi mai il problema finale. Il vero salto di qualità per un attaccante arriva quando riesce a passare da un utente limitato a root, oppure a ottenere privilegi equivalenti tramite servizi, binari SUID, configurazioni permissive, kernel vulnerabili o credenziali riutilizzate. Il hardening contro il privilege escalation non è una singola impostazione: è una somma di scelte coerenti che riducono la superficie d’attacco, limitano i percorsi di salita di privilegi e rendono più difficile l’abuso di errori umani o software non aggiornato.

La regola pratica è semplice: meno privilegi permanenti, meno binari speciali, meno servizi esposti, meno permessi scrivibili e meno eccezioni nella gestione degli accessi. Il resto è verifica continua.

Principio di lavoro: togliere scorciatoie prima di inseguire l’attacco

Molte guide partono dagli exploit. È un approccio sbagliato per l’operatività quotidiana. Conviene partire dai punti di appoggio che un attaccante usa davvero: sudo troppo permissivo, file con setuid/setgid non necessari, cron e systemd mal protetti, directory scrivibili in percorsi sensibili, chiavi SSH deboli, container o servizi con privilegi eccessivi, kernel vecchi, moduli caricabili senza controllo, montaggi insicuri e log insufficienti.

Il hardening efficace non elimina il rischio, ma riduce la probabilità che una vulnerabilità o una credenziale rubata diventino controllo completo del sistema.

1. Aggiornamenti: il primo filtro contro l’escalation

La maggior parte delle escalation reali sfrutta bug già corretti da tempo. Per questo la base è mantenere kernel, librerie e pacchetti allineati alle versioni sicure del proprio ramo.

• Abilita aggiornamenti di sicurezza regolari.
• Applica patch del kernel con finestra di manutenzione controllata.
• Rimuovi repository non necessari.
• Verifica che i pacchetti critici siano supportati dal vendor o dalla distro.

Su Debian e Ubuntu conviene controllare il servizio di aggiornamento automatico e l’eventuale presenza di pacchetti in hold. Su Alma, Rocky e CentOS, il ciclo di patch management deve includere kernel e componenti di base, non solo il web stack.

Controllo minimo consigliato

uname -r

Esito atteso: kernel coerente con il livello di supporto della distribuzione e senza versioni obsolete note per escalation pubbliche.

2. Ridurre i privilegi permanenti con sudo ben definito

Il file sudoers è uno dei punti più delicati. Un permesso mal scritto può trasformare un utente tecnico in root senza limiti. La logica corretta è concedere solo il comando necessario, non l’interprete, non la shell e non wildcard inutili.

• Evita regole come ALL=(ALL) NOPASSWD: ALL salvo casi eccezionali e documentati.
• Concedi comandi specifici con percorso assoluto.
• Usa gruppi dedicati per ruoli distinti.
• Preferisci password sudo per operazioni sensibili.

Controlla anche eventuali file in /etc/sudoers.d/. Spesso il problema non è il file principale, ma una regola lasciata da un vecchio setup o da un plugin di pannello.

Verifica utile

sudo -l

Esito atteso: elenco ristretto, comprensibile e coerente con il ruolo dell’account. Se compare un accesso totale non voluto, va corretto subito.

3. Limitare i binari SUID e SGID

I file SUID e SGID sono legittimi, ma ogni binario con bit speciali è un potenziale vettore di escalation se vulnerabile o male configurato. La difesa migliore è conoscere quali esistono, capire se servono davvero e rimuovere quelli inutili.

Molti ambienti hanno binari SUID ereditati da vecchie installazioni, utility di test o software dismesso. Più ne lasci, più aumenti il rischio.

• Inventaria i binari SUID/SGID.
• Confrontali con la baseline del sistema.
• Rimuovi i bit speciali dove non servono.
• Verifica i pacchetti che li forniscono prima di toccarli.

Un approccio prudente è usare l’inventario come audit, non come lista da modificare alla cieca. Se un binario è necessario, lascia il bit ma monitora il pacchetto e la sua versione.

Controllo utile

find / -xdev -type f -perm -4000 -o -perm -2000 2>/dev/null

Esito atteso: elenco limitato e giustificabile. Ogni voce non nota va spiegata o rimossa dopo verifica.

4. Proteggere cron, systemd e i percorsi di automazione

Molte escalation sfruttano job schedulati o servizi che eseguono script in directory scrivibili da utenti non privilegiati. È un errore classico: uno script root che legge file modificabili da altri diventa una porta d’ingresso perfetta.

• Controlla /etc/crontab, /etc/cron.* e le crontab utente.
• Verifica che script eseguiti da root siano in directory non scrivibili da utenti normali.
• Controlla unità systemd con ExecStart verso file sicuri.
• Evita path relativi o directory temporanee per script privilegiati.

Anche un servizio apparentemente innocuo può diventare vulnerabile se legge configurazioni in una directory con permessi sbagliati. La regola è: root deve eseguire solo ciò che può fidarsi di leggere.

Verifica pratica

systemctl list-unit-files --type=service

Esito atteso: elenco dei servizi installati da confrontare con quelli realmente necessari. Quelli non usati vanno disabilitati o rimossi.

5. Sistemare permessi e ownership in modo chirurgico

Il privilegio escalation non nasce solo da bug complessi. Spesso nasce da file e directory con permessi troppo larghi. Una directory scrivibile in un percorso di servizio o una configurazione modificabile da utenti non autorizzati è sufficiente per alterare il comportamento di un processo privilegiato.

Le aree da controllare con più attenzione sono:

• /etc e sottodirectory di configurazione.
• /usr/local/bin e script personalizzati.
• /var/www quando ospita applicazioni con diversi ruoli utente.
• /tmp e directory temporanee usate da job automatici.

La correzione deve essere precisa: non fare chmod massivi senza capire il contesto. Prima identifica il proprietario corretto, poi assegna il minimo permesso necessario.

Un sistema sicuro non è quello dove tutto è chiuso, ma quello dove ogni scrittura è giustificata.

6. Bloccare le escalation via SSH

SSH è spesso il primo punto di accesso amministrativo, quindi anche il primo bersaglio per il passaggio di privilegi. Se un attaccante ottiene una chiave o una password debole, il resto dipende da come hai impostato il login e la delega dei privilegi.

• Disabilita il login diretto di root via SSH.
• Usa chiavi SSH al posto delle password.
• Limita gli utenti autorizzati con AllowUsers o AllowGroups.
• Imposta MFA dove disponibile.

Ridurre root login via SSH non elimina il rischio, ma obbliga a passare da un account con tracciabilità e regole sudo. È una barriera utile contro l’abuso immediato di credenziali rubate.

Controllo consigliato

sshd -T | grep -E 'permitrootlogin|passwordauthentication|pubkeyauthentication|allowusers|allowgroups'

Esito atteso: root login disabilitato o fortemente limitato, password login disattivato se usi chiavi, regole di accesso coerenti con il tuo piano di amministrazione.

7. Usare AppArmor, SELinux e confinamento dei servizi

Un servizio compromesso non dovrebbe poter fare tutto. Qui entrano in gioco i profili di confinamento. AppArmor su Ubuntu e derivati, SELinux su Alma/Rocky/CentOS, aiutano a contenere l’impatto di un processo che viene sfruttato per leggere file sensibili o agganciare privilegi non previsti.

Molti ambienti li disattivano per comodità. È una scelta che semplifica il troubleshooting ma aumenta il danno potenziale. Se il servizio è importante, vale la pena investire tempo nel profilo corretto.

• Lascia in enforcement i profili compatibili con i servizi in uso.
• Testa prima in modalità permissiva dove serve.
• Abilita log e audit per individuare i blocchi reali.
• Evita di disattivare il controllo globale per risolvere un singolo errore.

Il confinamento non sostituisce gli aggiornamenti, ma limita il salto laterale e la persistenza locale.

8. Proteggere mount point, filesystem e opzioni pericolose

Alcune escalation passano da mount insicuri o da filesystem montati con opzioni troppo permissive. Un classico è la presenza di nosuid assente su partizioni dove non servono binari speciali, oppure di directory condivise con permessi che consentono sostituzione di file eseguibili.

Per le aree non destinate a eseguire codice, l’opzione nosuid è una misura semplice e molto utile. In alcuni casi ha senso anche nodev e noexec, ma vanno applicate con attenzione per non rompere software legittimo.

• Valuta nosuid su partizioni dati e directory temporanee.
• Usa nodev dove non servono device speciali.
• Applica noexec solo dopo test applicativi.
• Controlla i mount persistenti in /etc/fstab.

Le opzioni di mount sono difese semplici, reversibili e spesso sottovalutate. Non fermano tutto, ma riducono molto la superficie di abuso.

9. Disabilitare ciò che non serve davvero

Ogni servizio attivo è una possibilità in più di escalation. Un demone in ascolto, un agente di backup, un vecchio exporter, un tool di monitoraggio o un servizio di stampa possono aprire percorsi non previsti. Il hardening serio elimina il superfluo.

Il criterio è netto: se un servizio non serve alla funzione del server, non deve essere in esecuzione. Se serve solo in manutenzione, deve essere attivato on demand e con privilegi minimi.

• Rimuovi pacchetti inutili.
• Disabilita servizi non usati all’avvio.
• Controlla socket attivi e porte esposte.
• Documenta ogni eccezione con una motivazione.

Verifica utile

ss -tulpn

Esito atteso: solo i servizi necessari risultano in ascolto. Ogni porta inattesa va indagata e giustificata.

10. Separazione degli account e minimo privilegio reale

Un errore molto comune è usare lo stesso account per deploy, manutenzione, test e amministrazione. Quando un’unica identità ha accessi troppo ampi, la compromissione si propaga subito. La separazione dei ruoli è una difesa concreta contro l’escalation.

• Usa account distinti per amministrazione, deploy e operatività.
• Non condividere chiavi SSH tra persone o ruoli.
• Concedi accessi temporanei quando possibile.
• Rivedi periodicamente i gruppi locali e i privilegi ereditati.

Il principio del minimo privilegio funziona solo se viene applicato anche nei flussi quotidiani. Se un utente può fare tutto per comodità, prima o poi qualcuno userà quel margine in modo improprio o lo sfrutterà dopo una compromissione.

11. Logging e audit: senza tracce non fai difesa

Il hardening contro privilege escalation non è completo senza osservabilità. Devi sapere chi ha fatto cosa, quando e da dove. I log servono sia per rilevare tentativi di abuso sia per capire se una correzione ha rotto qualcosa.

• Abilita log di autenticazione e sudo.
• Centralizza i log se il server è critico.
• Monitora modifiche a file sensibili e binari privilegiati.
• Conserva i log con rotazione e retention adeguate.

Strumenti come auditd, journald, syslog centralizzato e monitoring esterno aiutano a vedere il problema prima che diventi incidente. La differenza la fa la qualità degli eventi raccolti, non solo la quantità.

12. Protezione extra per server esposti e ambienti hosting

Su VPS, server web e nodi hosting il rischio aumenta perché convivono più utenti, più siti e più applicazioni. Qui il hardening deve essere più rigoroso: isolamento dei virtual host, permessi separati, limiti sui processi, versioni aggiornate di PHP e database, e pannelli amministrativi protetti con attenzione.

Se usi cPanel, Plesk o FastPanel, verifica che ogni account abbia confini chiari. Evita configurazioni che consentono a un sito di leggere file di un altro. Nei sistemi multiutente, la leakage di permessi è spesso la porta d’ingresso verso escalation locale o compromissione laterale.

• Isola gli account hosting tra loro.
• Controlla i permessi delle home directory.
• Usa versioni supportate di PHP e moduli essenziali בלבד.
• Rivedi i plugin di gestione file e backup automatici.

13. Un piano operativo semplice da applicare

Se devi partire da zero, conviene seguire una sequenza concreta. Prima metti in sicurezza i punti più facili da abusare, poi passi ai controlli strutturali.

1. Applica aggiornamenti di sicurezza e verifica il kernel installato.
2. Controlla sudoers e rimuovi deleghe troppo ampie.
3. Inventaria SUID/SGID e verifica che ogni elemento sia necessario.
4. Controlla cron, systemd e script root per percorsi scrivibili.
5. Riduci i servizi attivi e chiudi le porte inutili.
6. Abilita o rafforza AppArmor/SELinux dove compatibile.
7. Rivedi permessi, ownership e mount options.
8. Attiva logging e audit sui punti sensibili.

Questo ordine funziona perché riduce il rischio subito e, nello stesso tempo, produce evidenze utili per gli step successivi.

14. Check finale di hardening

Prima di considerare chiuso il lavoro, verifica questi punti:

• Root non è accessibile direttamente via SSH se non strettamente necessario.
• sudo concede solo ciò che serve.
• I binari SUID/SGID sono pochi e giustificati.
• I servizi superflui sono disabilitati.
• Log e audit registrano autenticazioni, escalation e modifiche ai file sensibili.

Se uno di questi punti manca, l’hardening è incompleto. La sicurezza Linux contro il privilege escalation non si ottiene con una sola barriera, ma con livelli sovrapposti che rendono costoso ogni tentativo di salita di privilegi.

Conclusione operativa

Il miglior hardening contro privilege escalation è quello che rende difficile l’abuso dei dettagli quotidiani: permessi, servizi, script, chiavi, mount e deleghe. Non serve inseguire ogni exploit possibile; serve togliere agli attaccanti le scorciatoie più frequenti e mantenere il sistema in uno stato verificabile, aggiornato e coerente con l’uso reale.

Se un server è aggiornato, limitato nei privilegi, osservato nei log e privo di eccezioni inutili, il salto da utente a root diventa molto più difficile. Ed è proprio lì che si vince la partita.