Un sistema Linux appena installato non è un sistema sicuro. Le distribuzioni più diffuse vengono fornite con configurazioni pensate per funzionare subito, non per resistere a un tentativo di intrusione. Rafforzare la sicurezza del proprio sistema Linux ogni giorno richiede pochi accorgimenti mirati, da ripetere regolarmente, che riducono la superficie di attacco senza trasformare il computer in una fortezza inutilizzabile.
Sandboxing di systemd: isolare ogni servizio Linux singolarmente
La maggior parte delle guide alla sicurezza di Linux parla di account utente e permessi sui file. Un aspetto meno trattato è l’isolamento dei servizi stessi. Spesso un server web o un gestore di database dispone di privilegi molto più ampi di quelli necessari.
Hai mai notato che un servizio compromesso può leggere file che non hanno nulla a che fare con la sua funzione? È proprio questo che il sandboxing di systemd permette di correggere. Tre direttive possono fare la differenza:
- ProtectSystem=strict monta il file system radice in sola lettura per il servizio interessato, impedendo qualsiasi modifica al di fuori delle directory esplicitamente autorizzate.
- PrivateTmp=true assegna al servizio una directory temporanea isolata, invisibile agli altri processi. Un aggressore che accede alla directory /tmp del servizio non può vedere quella del sistema.
- NoNewPrivileges=true impedisce qualsiasi escalation dei privilegi dopo l’avvio del servizio, anche se nel percorso di esecuzione è presente un binario setuid.
Queste opzioni si configurano nella sezione [Service] del file unit del servizio. Dopo ogni modifica, riavvia il servizio e verifica che funzioni normalmente. Una direttiva troppo restrittiva può impedire l’accesso legittimo a un socket o a un file di configurazione.
Per approfondire questo approccio e altri metodi di hardening, i consigli sulla sicurezza di Hebdo Linux illustrano diversi scenari, adatti sia ai computer desktop sia ai server.
Verificare lo stato effettivo di SELinux e AppArmor sul sistema
Avere SELinux o AppArmor installato non significa che questi meccanismi stiano proteggendo qualcosa. Perché questo aspetto viene spesso trascurato? Perché la presenza di un modulo di sicurezza nel kernel dà una falsa impressione di protezione.
Un modulo di sicurezza inattivo non protegge alcun processo. In una distribuzione come Ubuntu, AppArmor è presente per impostazione predefinita, ma non tutti i profili sono in modalità “enforce”. Alcuni sono in modalità “complain”, che si limita a registrare le violazioni senza bloccarle.
Comandi pratici per la verifica
Per AppArmor, il comando aa-status mostra l’elenco dei profili caricati e la relativa modalità. Ogni profilo in modalità “complain” rappresenta una porta aperta. Per SELinux, sestatus indica se la modalità è “enforcing”, “permissive” o “disabled”.
Controllare questi stati è una delle verifiche quotidiane più utili. Uno script eseguito da cron o da un timer di systemd può inviare un avviso se, dopo un riavvio o un aggiornamento del kernel, la modalità passa a permissive. Questo tipo di regressione silenziosa è frequente durante gli aggiornamenti di versione.
Patch Linux: verificare che l’aggiornamento sia effettivamente attivo
Installare una patch non basta. Dopo un aggiornamento del kernel, la macchina può continuare a usare il kernel precedente finché non viene riavviata. Il gestore dei pacchetti indica che il sistema è “aggiornato”, ma resta vulnerabile.
Verifica il kernel attivo dopo ogni aggiornamento critico. Il comando uname -r mostra la versione del kernel attualmente in esecuzione. Confrontala con l’ultima versione installata, visibile nel gestore dei pacchetti. Se le due versioni non coincidono, è necessario riavviare.
Gestione delle patch su un server di produzione
Su un server, il riavvio non è sempre immediato. Documenta la differenza tra il kernel installato e quello attivo. Alcune distribuzioni offrono un meccanismo di “live patching”, che applica le patch al kernel senza riavviare, ma non copre tutti i tipi di vulnerabilità.
Un aspetto spesso dimenticato riguarda le voci di avvio alternative. Se il bootloader conserva i kernel precedenti, un riavvio accidentale con una voce obsoleta reintroduce le vulnerabilità già corrette. Rimuovi regolarmente i kernel precedenti dall’elenco di avvio, dopo aver verificato la stabilità del nuovo.
Ridurre ogni giorno la superficie di rete esposta
Ogni porta aperta è un potenziale punto di ingresso. Su un computer Linux, servizi come CUPS (stampa), Avahi (rilevamento della rete) o un server SSH possono restare in ascolto a tua insaputa.
Il comando ss -tlnp elenca tutte le porte in ascolto e i processi associati. Esamina l’elenco:
- Puoi disattivare un servizio che non usi (per esempio Avahi su un computer senza stampante di rete) con
systemctl disable --now, seguito dal nome del servizio. - Se un server SSH è esposto sulla porta standard (22), è preferibile limitare l’accesso alle chiavi pubbliche anziché alle password. Disattiva l’autenticazione tramite password in
/etc/ssh/sshd_configimpostandoPasswordAuthentication no. - Il firewall nftables (o iptables, a seconda della distribuzione) deve avere una policy predefinita che rifiuti il traffico in entrata, con eccezioni esplicite solo per i servizi necessari.
Meno servizi in ascolto significa meno superficie di attacco da monitorare. Questa verifica richiede pochi minuti e riduce notevolmente il rischio di attacchi da remoto.
La messa in sicurezza di un sistema Linux non è un intervento una tantum. Isolare i servizi, verificare che i moduli di sicurezza siano attivi, accertarsi che le patch siano effettivamente in uso e chiudere le porte non necessarie: tutto questo forma un ciclo breve. Ripetuto ogni settimana, questo ciclo copre la maggior parte dei vettori di attacco più comuni su un computer o un server Linux.
