Un sistema Linux, anche se rinomato per la sua robustezza, non è immunizzato di default contro gli attacchi. La sicurezza di Linux si basa su un insieme di configurazioni, regole di accesso e meccanismi di monitoraggio che devono essere attivati e mantenuti manualmente. Senza intervento, un server o un workstation appena installato espone servizi inutili, porte aperte e account con permessi troppo ampi.
Prioritizzazione delle patch del kernel: la vera sfida della sicurezza Linux
I concorrenti ripetono tutti che è necessario aggiornare il proprio sistema. Il consiglio rimane valido, ma la realtà è cambiata. Nel 2024, il kernel Linux ha registrato 3 108 CVE, con un aumento di circa il 79% rispetto ai 1 736 CVE del 2023, secondo il database NVD del NIST.
Questa esplosione non indica un degrado del codice. Essa è il risultato del miglioramento degli strumenti di analisi automatizzati, alcuni dei quali sfruttano l’intelligenza artificiale per scansionare le circa 40 milioni di righe del kernel. Da febbraio 2024, il kernel Linux è diventato la propria autorità di numerazione CVE (CNA), il che accelera la segnalazione di ogni vulnerabilità rilevata.
Per un amministratore, applicare ciecamente ogni patch pubblicata equivale a inseguire un flusso quasi continuo di aggiornamenti. L’approccio corretto consiste nel filtrare i CVE per punteggio CVSS e per esposizione reale del sistema. Una vulnerabilità critica su un modulo di rete in produzione merita una patch immediata. Una vulnerabilità su un driver hardware assente dalla macchina può attendere il prossimo ciclo di manutenzione.
Per seguire queste evoluzioni e comprendere il loro impatto concreto, le informazioni di sicurezza su Hebdo Linux dettagliano regolarmente le patch del kernel e gli avvisi associati alle distribuzioni principali.
Riduzione della superficie di attacco su un server Linux
Il hardening del sistema mira a rimuovere tutto ciò che non ha motivo di esistere sulla macchina. Ogni servizio attivo, ogni porta aperta e ogni pacchetto installato rappresentano un potenziale punto di ingresso per un attaccante.
Servizi e pacchetti inutili
Dopo un’installazione standard, diversi servizi girano senza che nessuno li abbia richiesti: server di stampa (CUPS), Avahi per la scoperta di rete locale, o ancora un agente di posta (Postfix, Exim). Su un server di produzione, questi componenti non hanno alcuna utilità e ampliano la superficie di attacco. Il comando systemctl list-unit-files –state=enabled consente di identificare precisamente ciò che si avvia automaticamente.
Disattivare un servizio non è sempre sufficiente. Se il pacchetto rimane installato, una riattivazione accidentale o un exploit locale rimangono possibili. Rimuovere l’intero pacchetto è il metodo più affidabile.
Configurazione di rete e firewall
Un firewall correttamente configurato costituisce la prima barriera tra la rete e i servizi interni. Sulle distribuzioni recenti, nftables sostituisce progressivamente iptables. La logica rimane identica: bloccare tutto il traffico in entrata di default, per poi aprire solo le porte necessarie.
- Consentire la porta 22 (SSH) solo da indirizzi IP noti, mai dall’intero internet.
- Chiudere le porte relative ai database (3306 per MySQL, 5432 per PostgreSQL) sull’interfaccia pubblica e esporle solo sull’interfaccia locale o su una rete privata.
- Attivare la registrazione dei pacchetti rifiutati per rilevare i tentativi di scansione.
Controllo degli utenti e escalation dei privilegi
La gestione degli account utente determina chi può fare cosa sul sistema. Un account root utilizzato quotidianamente rimane uno degli errori più comuni, anche su macchine gestite da profili tecnici.
Sudo deve sostituire ogni accesso diretto come root. Ogni comando eseguito tramite sudo è registrato con l’identità dell’utente, creando così una traccia di audit utilizzabile in caso di incidente. Il file /etc/sudoers consente di limitare i comandi autorizzati per utente o per gruppo.
Oltre a sudo, i moduli di controllo degli accessi obbligatori come SELinux (distribuzioni Red Hat, Fedora) o AppArmor (Ubuntu, Debian) aggiungono uno strato di restrizione per processo. Anche se un attaccante compromette un servizio, il modulo impedisce l’accesso a file o directory al di fuori del perimetro definito dalla politica di sicurezza.
- Applicare il principio del minimo privilegio: ogni utente dispone solo dei diritti necessari per il proprio compito.
- Disattivare gli account inutilizzati piuttosto che lasciarli inattivi con una password debole.
- Configurare una scadenza automatica delle password tramite chage per forzare un rinnovo periodico.
- Controllare regolarmente i file /etc/passwd e /etc/group per individuare account o gruppi inaspettati.
Registrazione e rilevamento di comportamenti anomali su Linux
Un sistema può essere compromesso per settimane senza che nessuno se ne accorga se i log non sono né centralizzati né monitorati. La registrazione non serve solo per l’analisi post-incidente: se sfruttata correttamente, consente di rilevare un’intrusione in corso.
Il journal di systemd (journalctl) centralizza gli eventi di sistema, ma la sua rotazione di default può cancellare tracce prima che vengano analizzate. Esportare i log verso un server remoto (tramite rsyslog o syslog-ng) garantisce che un attaccante che ha ottenuto accesso root non possa eliminare le proprie tracce localmente.
Per andare oltre, strumenti come auditd consentono di monitorare eventi specifici: modifica di un file di configurazione sensibile, aggiunta di un utente, cambiamento di permessi su una directory critica. Ogni regola di audit genera un’entrata timestampabile utilizzabile per ricostruire la cronologia di un incidente.
La combinazione di un firewall rigoroso, di un controllo degli accessi granulare e di una registrazione esportata copre i tre assi della sicurezza Linux: prevenzione, restrizione e rilevamento. Trascurare uno di questi assi equivale a lasciare una porta aperta, anche se gli altri due sono bloccati.
