CVE del kernel Linux in crescita: come Host.it patcha in tempo reale senza riavviare i server

Due fenomeni si sono sommati, e conviene tenerli distinti. Il primo è amministrativo. Da febbraio 2024 il Linux kernel è una CVE Numbering Authority: molti issue che prima restavano in mailing list o in commit ora escono con un ID pubblico. Il catalogo si è allungato anche senza un'epidemia di bug nuovi.

Il secondo è tecnico, ed è quello che negli ultimi mesi ha cambiato il ritmo. Il fuzzing (syzkaller e dintorni) gira da anni. Quello che è cambiato è l'assistenza dell'AI nella ricerca: agent che esplorano superfici, riducono falsi positivi, aiutano a scrivere riproduttori e a chiudere il cerchio fino alla pubblicazione. Più occhi automatici, più CVE. «Grazie» all'AI, nel senso stretto: più vulnerabilità scoperte e comunicate, non un kernel più fragile di colpo.

Cosa non è (e cosa è) un CVE kernel

Un CVE sul kernel non è un plugin da cliccare in dashboard. È un identificativo su un difetto del sistema operativo che fa girare WordPress, Joomla, lo shop, la posta. La gravità va letta caso per caso: non tutti gli ID sono exploitable in hosting condiviso, e non tutti richiedono un reboot immediato. Quello che è cambiato è la cadenza: il backlog di patch da valutare non è più un evento mensile.

La superficie che l'agenzia vede è CMS, plugin, PHP, certificati. La superficie che l'attaccante può usare include anche il kernel, i driver, i namespace, la rete. Non dovete diventare kernel hacker. Dovete sapere chi patcha cosa, in quanto tempo, e con quale impatto sull'uptime.

Tre piani, tre responsabilità

• Applicazione. Core, temi, plugin: è il vostro mestiere, o un canone che vendete. Staging, backup, finestra di verifica.
• Sistema. Kernel, libc, hypervisor: è mestiere dell'hoster. Se l'hoster patcha solo a reboot, ogni CVE serio diventa un downtime programmato.
• Contratto col cliente. Chi risponde se lo shop è giù durante un saldi? Se non è scritto, lo pagate in reputazione.

Per una web agency con cinquanta o duecento siti il kernel è invisibile finché funziona. Diventa visibile la notte in cui dieci clienti contemporaneamente ricevono un timeout. Non è un problema di «sicurezza in astratto»: è continuità del servizio che avete venduto.

La patch classica del kernel è semplice da spiegare e costosa da vivere: installi, riavvii, aspetti che i servizi risalgano, controlli che PHP, database e coda mail siano tornati. Su un server è una finestra. Su un parco è un calendario di interruzioni.

Cosa paga il cliente (e cosa pagate voi)

• Minuti di sito giù. Un e-commerce in campagna ads non distingue «manutenzione kernel» da «hosting inaffidabile».
• Finestre notturne. Se ogni advisory chiede un reboot, le notti si moltiplicano. Il team interno o il fornitore le deve coprire.
• Ticket a raffica. Anche un riavvio pulito produce allarmi di monitoraggio e telefonate. Costa più della patch.

L'alternativa non è ignorare i CVE. È separare la correzione dal reboot: applicare la patch in memoria quando è possibile, e tenere il riavvio per i casi in cui serve un kernel nuovo, non per ogni ID pubblicato lunedì mattina.

Su Host.it la strategia è studiata per l'uptime dei Clienti, non per la comodità del calendario interno. Quando arriva un advisory kernel rilevante, applichiamo la correzione a caldo (live / hot patch): il codice vulnerabile in esecuzione viene sostituito senza un ciclo di spegnimento e accensione. I siti restano raggiungibili. Non è magia e non elimina ogni reboot della vita di un server: elimina la necessità di riavviare di continuo solo per inseguire il ritmo dei CVE.

Cosa facciamo, in pratica

• Valutazione. Non tutti i CVE kernel hanno lo stesso impatto sul nostro stack. Prioritizziamo quelli che toccano l'esposizione reale dei servizi.
• Patch in tempo reale. Dove il live patching copre il difetto, la correzione entra in produzione senza downtime di hypervisor o di macchina.
• Reboot solo quando serve. Un kernel nuovo, una dipendenza che la patch a caldo non copre, una finestra pianificata: il riavvio resta uno strumento, non la risposta di default.
• Osservabilità. Monitoriamo che i servizi restino sani dopo la patch. L'uptime lo misuriamo, non lo dichiariamo a manifesto: vedi trasparenza uptime.

Vale per l'infrastruttura su cui girano hosting, cloud e VPS: il cliente finale non deve imparare cosa sia un live patch. Deve trovare il sito acceso. Se gestite il parco da agenzia, la differenza la vedete nei ticket che non arrivano. Dettagli su sicurezza Host.it e sui VPS.

Il CVE kernel è un argomento scomodo in riunione finché lo raccontate come tecnologia. Diventa un argomento di listino se lo traducete in continuità, responsabilità e canone.

• Clausola di uptime onesta. Non promettete il 100%. Spiegate che gli aggiornamenti di sicurezza del sistema non coincidono con finestre di sito spento a ogni advisory. È un motivo concreto per restare su un hoster che patcha a caldo.
• Report di manutenzione. Una riga nel report mensile: «kernel aggiornato, nessun downtime da reboot». Il cliente non capisce il CVE; capisce che qualcuno ha fatto il lavoro senza fargli chiudere lo shop.
• Hosting come voce di governance. Su Host Bucket isolate i clienti, rivendete con il vostro brand e tenete l'infrastruttura italiana. La patch del kernel non è un extra: è parte di quello che state vendendo come affidabilità.

Nessuna di queste tre cose la fa un prompt. Le fa un'agenzia che ha scelto dove far girare i siti e sa spiegarlo.

I CVE del kernel Linux continueranno ad arrivare, in parte perché il processo di numerazione è più ampio, in parte perché l'AI aiuta a trovarli prima. Chi risponde con un reboot a ogni ID accumula downtime. Chi ignora gli advisory accumula rischio. La terza via è quella che usiamo in Host.it: patch in tempo reale, riavvii solo quando servono, uptime come vincolo.

Se gestite siti per conto terzi, questo è il pezzo di conversazione da avere con l'hoster, non con il CMS. Per parlarne sul vostro parco: contattaci. Per il programma rivenditori: hosting per web agency.