Il kernel Linux ora corregge più di 1.500 CVE per versione principale, e le proiezioni per Linux 7.3 si avvicinano a 2.000 CVE per release. Questa inflazione, alimentata dagli strumenti di analisi del codice assistiti da IA, cambia radicalmente le regole del gioco per gli amministratori di sistema. Proteggere un sistema Linux non si limita più ad attivare un firewall e a lanciare un apt upgrade settimanale: è un lavoro di selezione, priorizzazione e architettura difensiva continua.
Selezione delle CVE del kernel Linux: gestire l’ondata di patch
Tra le versioni 6.9 e 6.19 del kernel, il ritmo era di circa 500 CVE corrette per release. Da Linux 7.0, questo volume è raddoppiato, poi triplicato. Gli stessi manutentori dichiarano di essere “completamente sopraffatti” dal flusso di rapporti generati tramite strumenti automatizzati.
Per un amministratore, ciò significa che la patching sistematica di ogni CVE è diventata irrealistica senza strumenti di priorizzazione. Applicare tutte le patch alla cieca significa riavviare continuamente i servizi, con il rischio di regressioni funzionali su carichi di produzione.
Un punteggio CVSS lordo di 7.5 su una vulnerabilità di rete non ha lo stesso impatto su un server isolato dietro una rete privata rispetto a una macchina esposta in DMZ. Un approccio basato sul punteggio CVSS contestuale consente di dare priorità alle patch realmente critiche.
Strumenti come KernelCare (live patching senza riavvio) o i flussi OVAL forniti dalle distribuzioni filtrano le CVE applicabili alla vostra configurazione reale. Le risorse dedicate alla sicurezza su Hebdo Linux completano utilmente questa sorveglianza tecnica.
Configurazione SSH e controllo degli accessi privilegiati su Linux
SSH rimane il vettore d’attacco più mirato sui server Linux esposti. La configurazione predefinita di OpenSSH sulla maggior parte delle distribuzioni è funzionale, ma non sicura.
Parametri sshd_config da bloccare in priorità
- PermitRootLogin no e disattivazione dell’autenticazione tramite password (PasswordAuthentication no): solo l’autenticazione tramite chiave Ed25519 o ECDSA dovrebbe essere autorizzata su un server di produzione
- Restrizione degli algoritmi di crittografia alle suite moderne tramite KexAlgorithms e Ciphers, escludendo esplicitamente diffie-hellman-group1-sha1 e CBC
- Attivazione di AllowUsers o AllowGroups per limitare l’accesso SSH a un elenco nominativo di account, piuttosto che fare affidamento esclusivamente sul firewall
- MaxAuthTries fissato a 3 e LoginGraceTime ridotto a 30 secondi per limitare la finestra di brute-force
Gestione dell’escalation di privilegi con sudo
La configurazione sudoers merita la stessa attenzione di SSH. Un file sudoers troppo permissivo annulla qualsiasi politica di minor privilegio. Si osservano ancora regolarmente configurazioni in cui un account applicativo dispone di ALL=(ALL) NOPASSWD: ALL, il che equivale a concedergli un accesso root permanente.
La buona pratica consiste nel creare alias di comandi mirati (Cmnd_Alias) per ogni ruolo applicativo e nel registrare ogni invocazione sudo tramite syslog. Abbinato a auditd, ciò fornisce una tracciabilità completa delle azioni privilegiate.
Riduzione della superficie d’attacco di rete su un server Linux
Ogni porta aperta e ogni servizio attivo rappresentano un potenziale punto d’ingresso. La riduzione della superficie d’attacco inizia con un inventario rigoroso.
Il comando ss -tulnp (che sostituisce netstat) elenca i socket in ascolto con il processo associato. Su un tipico server web, dovrebbero apparire solo le porte 22, 80 e 443. Qualsiasi servizio aggiuntivo (postfix, cups, avahi-daemon, rpcbind) deve essere disattivato tramite systemctl disable se non necessario, e poi mascherato con systemctl mask per impedire una riattivazione accidentale.
Per il filtraggio di rete, nftables ha sostituito iptables come framework predefinito sui kernel recenti. La sua sintassi dichiarativa tramite insiemi (sets) e mappe (maps) semplifica la gestione delle regole su larga scala. Una politica predefinita di drop sulle catene input e forward, con apertura esplicita dei flussi necessari, rimane la base.
Audit e registrazione: auditd, journald e rilevamento delle intrusioni Linux
Senze registrazione centralizzata, qualsiasi compromissione rimane invisibile fino a quando non vengono constatati i danni. Il framework audit del kernel Linux (auditd) consente di monitorare le chiamate di sistema critiche con una granularità fine.
Le regole da configurare in priorità riguardano il monitoraggio delle modifiche su /etc/passwd, /etc/shadow, /etc/sudoers e i file di configurazione SSH. Una regola auditctl del tipo -w /etc/shadow -p wa -k shadow_changes registra qualsiasi scrittura o modifica di attributi sul file.
Per il rilevamento delle intrusioni a livello di file, AIDE (Advanced Intrusion Detection Environment) genera un’impronta crittografica dell’albero di sistema. Qualsiasi modifica non autorizzata di un binario o di un file di configurazione attiva un avviso durante la prossima scansione. Una scansione quotidiana tramite cron con invio del rapporto tramite canale crittografato costituisce un minimo vitale.
Journald, abbinato a un’aggregazione remota (tramite systemd-journal-remote o un raccoglitore come rsyslog verso un SIEM), consente di correlare gli eventi tra più server. Un attaccante che compromette una macchina tenterà di eliminare i log locali. Inviare i log a un server di terze parti rende questa eliminazione inefficace.
Cyber Resilience Act e conformità dei sistemi Linux in Europa
Il Cyber Resilience Act (CRA) impone agli editori di software commerciali, compresi quelli che integrano componenti open source, obblighi di monitoraggio delle vulnerabilità e di fornitura di patch per tutta la durata del prodotto. I primi obblighi di reporting entreranno in vigore a settembre 2026.
Per i team che distribuiscono Linux in ambienti professionali, il CRA significa concretamente che la tracciabilità dei componenti (SBOM, Software Bill of Materials) e la capacità di dimostrare un processo di gestione delle patch diventano requisiti normativi, non solo buone pratiche. Le distribuzioni principali hanno iniziato a fornire SBOM utilizzabili, ma la responsabilità della conformità rimane a carico dell’entità che immette il prodotto sul mercato europeo.
La combinazione di un kernel che genera quasi 2.000 CVE per release e di un quadro normativo che richiede una gestione documentata di ogni vulnerabilità rende gli strumenti di live patching e di automazione della selezione non più opzionali, ma strutturalmente necessari per qualsiasi infrastruttura Linux in produzione.
