TuxCare ELS: continuare a utilizzare in modo controllato le vecchie versioni di Linux

Cosa integra TuxCare ELS

Quando termina il supporto regolare di una distribuzione Linux, un server non riceve necessariamente ulteriori aggiornamenti di sicurezza tramite le fonti dei pacchetti precedenti. Ciò risulta particolarmente problematico se un’applicazione specialistica è ancora legata al vecchio ambiente. Il supporto esteso può concedere il tempo necessario per una transizione controllata, senza annullare la fine del supporto regolare.

TuxCare Assistenza per l'intero ciclo di vita for OS fornisce aggiornamenti di sicurezza e correzioni di bug selezionate per le distribuzioni meno recenti supportate. Secondo il produttore, l’offerta comprende il kernel e una selezione di pacchetti importanti, a seconda della distribuzione. Non installa una nuova versione principale di Linux: il server mantiene la versione della distribuzione attualmente in uso e riceve ulteriore manutenzione per i componenti coperti.

Dal punto di vista operativo, questa può rappresentare un’importante soluzione transitoria: invece di dover sostituire immediatamente un’applicazione incompatibile, è possibile preparare la migrazione mentre vengono installate le correzioni di sicurezza disponibili per i pacchetti interessati. È tuttavia necessario che i pacchetti effettivamente necessari, l’architettura e l’offerta scelta siano compatibili tra loro.

Il sito Copertura per pacchi non è sinonimo della sicurezza dell'intero server. Un'applicazione installata autonomamente, un'estensione o un servizio proveniente da un'altra fonte di pacchetti potrebbe non rientrare nell'offerta del sistema operativo. Anche gli errori di configurazione e i servizi accessibili senza necessità non scompaiono con un abbonamento; devono comunque essere controllati e messi in sicurezza.

Anche per i pacchetti coperti, il livello di gravità è rilevante: TuxCare prevede correzioni di sicurezza per rischi elevati e critici a partire da un punteggio CVSS pari a 7. Per i rischi medi compresi tra CVSS 4,0 e 6,9, secondo il fornitore si prendono in considerazione le patch se non è disponibile alcuna misura di mitigazione e se vi è una domanda sufficiente da parte dei clienti. TuxCare si riserva inoltre il diritto di offrire una misura di mitigazione anziché una correzione diretta del codice. Un pacchetto coperto non implica quindi che ogni vulnerabilità nota al suo interno venga risolta.

Non è quindi determinante solo il fatto che la distribuzione figuri in un elenco di supporto. Per Sicurezza di Linux verifica quali componenti siano in uso sul server specifico, se siano disponibili le correzioni adeguate e se queste siano effettivamente installate. ELS integra il processo di applicazione delle patch, ma non sostituisce né l’inventario né un piano di migrazione.

Verificare la copertura e l'inventario dei server

Prima di scegliere TuxCare ELS, è necessario Inventario dei server. Registrare la distribuzione, la versione esatta, l'architettura e il kernel in esecuzione. Documentare inoltre i repository dei pacchetti configurati e i servizi accessibili pubblicamente o da altre reti. In questo modo è possibile confrontare l'elenco fornito dal produttore con il sistema effettivo, anziché limitarsi a spuntare il nome della distribuzione.

Nel caso di un server web meno recente, ad esempio, l’inventario deve includere il pacchetto del server web, le librerie crittografiche, il runtime PHP e le estensioni PHP necessarie. Annota sempre la provenienza del pacchetto e la versione installata. Un’estensione proveniente da un repository di terze parti può avere condizioni di manutenzione diverse rispetto a un pacchetto della distribuzione originale.

Confronta questi componenti uno per uno con l'elenco dei pacchetti aggiornato relativo alla distribuzione in questione. Verifica anche l'architettura e i requisiti dell'offerta prevista. Il fatto che una distribuzione sia supportata non significa che ogni pacchetto installato su di essa o ogni versione di un runtime sia automaticamente coperto da ELS for OS. Anche nel caso dei pacchetti coperti, la gestione delle singole vulnerabilità dipende, tra l’altro, dal loro livello di gravità.

I programmi compilati autonomamente e gli ambienti di esecuzione installati separatamente sono particolarmente facili da trascurare. Anche un'immagine container include i propri componenti: la manutenzione del sistema operativo host non garantisce che i pacchetti presenti nell'immagine siano aggiornati. Per tali componenti è necessaria una verifica specifica e un processo di aggiornamento dedicato.

ELS per OS e ELS per applicazioni Si tratta di offerte distinte. La possibilità di effettuare la manutenzione di una vecchia versione di PHP tramite un’offerta aggiuntiva dipende, tra l’altro, dalla versione, dal formato del pacchetto, dall’architettura e dal canale di approvvigionamento. Un altro possibile ambiente per le applicazioni PHP meno recenti è descritto nell’articolo su CloudLinux Alt-PHP e i suoi aspetti relativi alla sicurezza; ne consegue che non è prevista alcuna copertura da parte di un abbonamento al sistema operativo TuxCare.

Classificare correttamente i termini di assistenza

La data di scadenza dell'assistenza è significativa solo se considerata insieme alla rispettiva fase di manutenzione. La fine della manutenzione ordinaria non implica sempre che tutte le offerte a pagamento o complementari terminino contemporaneamente. Per prendere una decisione, dovresti quindi prendere nota sia del periodo di validità sia dei pacchetti, delle architetture e delle condizioni contrattuali coperti.

La documentazione di TuxCare attualmente disponibile indica, per i sistemi operativi supportati, un tempo di esecuzione ELS garantito di 25 anni a partire dalla data di fine supporto originaria indicata in ciascun caso. A titolo di esempio, cita il 30 giugno 2049 per CentOS 7 e il 31 maggio 2048 per Ubuntu 18.04. Si tratta di indicazioni fornite dal fornitore relative al periodo di supporto, non di una garanzia per ogni applicazione installata.

Per Ubuntu 18.04, Canonical distingue diverse fasi: il supporto standard è terminato a maggio 2023; Ubuntu Pro è previsto fino a maggio 2028. La panoramica attuale indica maggio 2033 come data per la copertura legacy aggiuntiva. Queste offerte non sono comparabili solo in base alle loro date di scadenza, poiché per il server specifico contano la portata del pacchetto, l’architettura e le condizioni contrattuali.

Nel caso, ad esempio, di un server web Ubuntu, verifica se i pacchetti necessari siano effettivamente inclusi nella versione di manutenzione selezionata e in che modo gli aggiornamenti si integrino nel processo operativo esistente. Un periodo di tempo più lungo è di scarsa utilità se un tempo di attività critico o un’estensione esulano dall’ambito concordato.

I termini indicati si basano su pagine web dei produttori soggette a modifiche, secondo lo stato delle fonti consultate al 4 novembre 2026. Non è possibile verificare in modo retroattivo se tutte le informazioni attuali fossero già valide a tale data. Si raccomanda pertanto di ricontrollare i termini e gli elenchi dei pacchetti prima della pubblicazione o della stipula del contratto e di attenersi alle rispettive Stato delle richieste di certo. Anche una promessa di assistenza a lungo termine non costituisce una garanzia di sicurezza complessiva del server.

Configurazione pratica di un server CentOS 7

Supponiamo che un server web CentOS 7 debba continuare a eseguire temporaneamente un’applicazione specialistica meno recente. Prima di TuxCare ELS Selezionando questa opzione, si acquisiscono lo stato effettivo del sistema e le dipendenze dell'applicazione. Non è determinante solo il fatto che CentOS 7 sia supportato, ma anche che i componenti necessari per l'architettura esistente siano coperti.

Puoi eseguire i seguenti comandi in una shell sul server. Questi comandi rilevano l'identificativo della distribuzione, l'architettura della macchina e la versione del kernel in esecuzione; non modificano né i pacchetti né le fonti dei pacchetti. Annota i risultati nell'inventario del server e confrontali con la guida attuale di CentOS 7.

cat /etc/os-release
uname -m
uname -r

Completa questo Inventario dei server le fonti dei pacchetti configurate, le versioni dei pacchetti installate e i servizi accessibili pubblicamente. Nel caso di un server web, questi includono in particolare il pacchetto del server web, le librerie di crittografia, il runtime PHP e le estensioni. Annota inoltre quali componenti provengono da fonti esterne o sono stati compilati autonomamente; essi non devono essere considerati parte della copertura del sistema operativo senza essere stati verificati.

Per CentOS 7, TuxCare indica come prerequisiti una chiave di licenza valida, l'accesso come root e connessioni HTTPS. La guida distingue inoltre in base all'architettura: per aarch64 e i686 descrive la copertura dello spazio utente, mentre il live patching del kernel è descritto solo per x86_64. Questa limitazione riguarda la guida relativa a CentOS 7 e non può essere estesa in modo generalizzato ad altre distribuzioni.

Verifica quindi, per la specifica applicazione, ogni pacchetto necessario confrontandolo con l'elenco aggiornato e chiarisci eventuali lacune con il rispettivo fornitore. Anche un kernel supportato e in esecuzione, di per sé, non garantisce né la compatibilità con l'applicazione né che tutti gli aggiornamenti disponibili siano installati e attivi.

Configurare il repository e distribuire gli aggiornamenti

Progetta l'allestimento come un ambiente controllato Catena di controllo: Innanzitutto, la licenza, l'architettura e i pacchetti necessari devono essere compatibili. Successivamente, verifica se il server è autorizzato ad accedere tramite HTTPS alle destinazioni richieste dalla sua distribuzione. Per la registrazione e la configurazione del repository, segui le istruzioni originali aggiornate specifiche per la distribuzione, poiché i prerequisiti e gli indirizzi di destinazione potrebbero variare.

Per CentOS 7, TuxCare descrive la registrazione del sistema, l’aggiunta del repository dei pacchetti e di una chiave PGP. Il repository consente quindi di scaricare i pacchetti necessari, ma non installa automaticamente tutti gli aggiornamenti disponibili. Dopo la configurazione, verifica che il repository sia integrato correttamente e che il gestore dei pacchetti proponga gli aggiornamenti appropriati.

Nella pianificazione occorre tenere conto dell’eventuale presenza di un proxy o di regole restrittive del firewall in uscita. In caso di più sistemi, previa consultazione con TuxCare, si può prendere in considerazione l’utilizzo di un mirror locale. Non copiare ciecamente gli indirizzi di destinazione da una FAQ generica: prima di procedere, confrontali con le istruzioni aggiornate relative alla distribuzione scelta e al percorso operativo previsto.

Prova innanzitutto gli aggiornamenti disponibili in un ambiente di test il più possibile simile a quello dell'applicazione aziendale. Verifica l’avvio, i processi aziendali chiave e le interfacce. Successivamente, procedi all’approvazione operativa e all’installazione sul sistema di produzione; documenta le versioni dei pacchetti, la data e il risultato, invece di considerare come conclusa la procedura solo in base alla corretta attivazione nel repository.

Se un aggiornamento previsto non è ancora disponibile, controlla anche il Stato dell'implementazione. Per diverse piattaforme, TuxCare distribuisce gli aggiornamenti in modo scaglionato; dopo la pubblicazione nel repository stabile, ciò può richiedere fino a 14 giorni in più. Se necessario, il fornitore descrive una soluzione alternativa: utilizzarla solo seguendo le istruzioni aggiornate relative alla distribuzione e alla versione specifica in questione, nonché previa approvazione operativa. La durata del rollout non implica un termine complessivo garantito per l’applicazione di una patch.

Assicurati inoltre di predisporre un piano di ripiego e un intervallo di tempo adeguato per la manutenzione. Le chiavi di licenza non devono essere incluse nei comandi di esempio pubblicati, nei ticket o nei log non protetti. Per la registrazione vera e propria, dovresti seguire le istruzioni aggiornate del produttore e fornire i dati di accesso solo tramite le procedure previste a tale scopo.

Confronto tra le diverse opzioni di manutenzione

La scelta tra TuxCare ELS e un servizio di manutenzione esteso del produttore dipende dall'effettivo inventario dei pacchetti e dai termini contrattuali. La tabella riporta esempi di preselezione, non una garanzia generale per ogni architettura o pacchetto. La data di riferimento della ricerca è il 4 novembre 2026; le informazioni dinamiche fornite dal produttore e gli elenchi dei pacchetti devono essere ricontrollati prima della pubblicazione.

Per Ubuntu 18.04, il supporto standard è terminato a maggio 2023. Canonical indica per Ubuntu Pro un supporto fino a maggio 2028 e, nella sua attuale panoramica sul supporto legacy aggiuntivo, fino a maggio 2033. TuxCare indica attualmente il 31 maggio 2048 come data di scadenza dell’ELS per Ubuntu 18.04. Queste date si riferiscono a offerte diverse; una data di scadenza più tardiva non implica automaticamente la copertura adeguata del pacchetto.

Confronta quindi il Ambito della manutenzione per ogni pacchetto necessario e per l’architettura effettivamente utilizzata. Nel caso di Ubuntu, sono particolarmente rilevanti i componenti Main e Universe, nonché i requisiti per Pro e un’eventuale estensione Legacy. Verifica inoltre in che modo sia possibile dimostrare la disponibilità delle correzioni CVE e se i processi di approvazione e aggiornamento esistenti siano adeguati all’offerta.

In entrambi gli esempi, la destinazione della migrazione rimane una decisione di pianificazione, non una caratteristica del contratto di manutenzione. Se l’applicazione specialistica non è ancora eseguibile su una piattaforma supportata, un’alternativa di manutenzione adeguata può concedere il tempo necessario per effettuare i test. Se nessuna delle offerte copre una dipendenza critica, tale lacuna deve essere affrontata separatamente prima che sia possibile garantire il proseguimento del funzionamento in modo responsabile.

Verificare le segnalazioni CVE e i backport

Se, dopo un aggiornamento, uno scanner continua a segnalare una vulnerabilità, verifica innanzitutto la distribuzione e la versione esatte, nonché il nome, l’architettura e la versione installata del pacchetto interessato. Individua inoltre da quale repository provenga. Un risultato relativo a un pacchetto della distribuzione non può essere automaticamente esteso a un’applicazione compilata autonomamente o a un pacchetto proveniente da un repository di terze parti.

La ragione delle apparenti contraddizioni può essere un Backport ovvero: in questo caso, una correzione di sicurezza viene incorporata in una versione precedente, senza che il numero di versione upstream visibile corrisponda a quello dell'ultima versione rilasciata. Un numero di versione precedente, di per sé, non dimostra quindi né che il pacchetto sia vulnerabile, né che il messaggio dello scanner sia necessariamente errato.

Confronta il CVE specifico e la versione del pacchetto installata con le informazioni relative alla tua distribuzione presenti nel TuxCare CVE Tracker. „In Testing“ significa che una correzione è ancora in fase di test; „In Rollout“ indica che viene distribuita tramite i repository di rollout. „Released“, invece, indica il rilascio completo per tutti gli utenti. Anche in questo caso devi verificare se sia stata effettivamente installata la versione corretta; „Not Vulnerable“ significa che la versione di TuxCare non è interessata dalla vulnerabilità.

Se nel gestore dei pacchetti manca un aggiornamento previsto, controlla, oltre alla fonte del pacchetto e alla versione, anche il Stato dell'implementazione. In caso di piattaforme multiple, la distribuzione graduale dopo la pubblicazione nel repository stabile può richiedere fino a 14 giorni aggiuntivi. Un eventuale bypass può essere integrato nel processo solo in base alle istruzioni originali aggiornate relative alla distribuzione e alla versione e previa approvazione operativa; ciò non comporta alcuna garanzia sui tempi complessivi di applicazione della patch.

Esamina quindi il database e i risultati dello scanner. TuxCare mette a disposizione dati OVAL per una serie di prodotti ELS; spetta a te verificare se il tuo strumento utilizza i dati adeguati al sistema specifico e li interpreta correttamente. Documenta la versione del pacchetto, lo stato CVE e l’ora della scansione. Se la corrispondenza non è chiara, considera il risultato ancora in sospeso e chiariscilo con gli uffici competenti o con il fornitore.

Pianificare le operazioni di patch e i riavvii

La creazione di un repository rappresenta l'inizio del processo di applicazione delle patch, non la sua conclusione. Stabilisci chi deve verificare regolarmente la disponibilità di aggiornamenti, chi deve autorizzarne l'installazione e come individuare gli aggiornamenti non installati. A tal fine, confronta le versioni dei pacchetti effettivamente installate con gli aggiornamenti disponibili e registra eventuali discrepanze per ogni sistema.

Se possibile, prova gli aggiornamenti inizialmente su un sistema di test simile, dotato della stessa applicazione e delle stesse fonti dei pacchetti. Verifica in particolare l'avvio, l'accesso e le interfacce principali dell'applicazione specialistica. Solo dopo l'approvazione operativa procedi alla distribuzione controllata dei pacchetti; il risultato e gli eventuali errori devono essere riportati nel verbale di installazione.

Prevedi inoltre eventuali modifiche Finestra di manutenzione. Anche dopo un aggiornamento dei pacchetti eseguito con successo, i processi in esecuzione potrebbero continuare a utilizzare le vecchie librerie fino al loro riavvio. Se necessario, anche le applicazioni devono essere riavviate; in caso di modifiche al kernel, potrebbe essere necessario riavviare il sistema. Dopo il riavvio, verifica sia il funzionamento dei servizi sia lo stato previsto dei pacchetti e del sistema.

KernelCare Live Patching è un prodotto complementare e va distinto dai normali aggiornamenti dei pacchetti ELS. È in grado di applicare le correzioni del kernel supportate senza interrompere il funzionamento del sistema, ma non sostituisce né tutti gli aggiornamenti né ogni riavvio dei servizi o del sistema. Verifica il prodotto, la distribuzione e l’architettura: per CentOS 7, TuxCare documenta il kernel live patching solo per x86_64. Ulteriori nozioni di base sono illustrate nell’articolo dedicato a KernelCare Patch Feed.

La pubblicazione di uname -r mostra il kernel attualmente in esecuzione, ma non lo stato completo degli aggiornamenti del server. Ad esempio, un pacchetto del kernel installato può diventare attivo solo dopo un riavvio; d'altra parte, l'output non fornisce alcuna indicazione sul fatto che le librerie e le applicazioni siano state aggiornate e riavviate.

Scegliere una soluzione provvisoria o la migrazione

Per stabilire se TuxCare ELS sia sufficiente per un determinato server, occorre considerare i suoi componenti effettivi e i rischi associati. Confronta i pacchetti necessari con la copertura disponibile e individua le lacune presenti nelle applicazioni, negli ambienti di esecuzione e nel software di terze parti. ELS for OS copre una selezione dipendente dalla distribuzione; il supporto del sistema operativo non implica la manutenzione di ogni applicazione su di esso in esecuzione.

Verifica anche le vulnerabilità CVE residue all’interno dei pacchetti già coperti. Secondo TuxCare, i rischi medi vengono presi in considerazione per l’applicazione di una patch solo a determinate condizioni aggiuntive; inoltre, il fornitore può prevedere una misura di mitigazione anziché una correzione diretta del codice. Valuta quindi, per la vulnerabilità specifica, se è disponibile una correzione o una misura di mitigazione e se i rischi residui sono accettabili per la tua attività.

Una soluzione transitoria può essere opportuna se un’applicazione specialistica è per il momento vincolata alla vecchia piattaforma e i rischi residui sono gestibili. Valuta però anche l’assistenza tecnica offerta dal produttore: per Ubuntu 18.04, a seconda delle esigenze, si possono prendere in considerazione come alternative Ubuntu Pro ed eventualmente l’estensione Legacy. Verifica i pacchetti, l’architettura e i termini contrattuali, non limitarti a controllare solo la data di scadenza.

Per un servizio accessibile al pubblico con un’applicazione non aggiornata o con un periodo di validità non coperto, l’ELS da solo potrebbe non essere sufficiente. Limita quindi gli accessi alle reti e ai servizi effettivamente necessari, rimuovi le autorizzazioni non necessarie e controlla gli accessi amministrativi. Questi Limitazione della rete riduce la superficie di attacco, ma non sostituisce gli aggiornamenti di sicurezza mancanti.

Limita la durata della fase di transizione e definisci un obiettivo di migrazione, indicando i responsabili e una scadenza verificabile. Pianifica i test delle applicazioni sulla piattaforma di destinazione, il trasferimento dei dati e la verifica di tutte le interfacce rilevanti. Un piano di ripiego dovrebbe specificare a quali condizioni interrompere la migrazione e come tornare alla configurazione operativa precedente.

Verifica regolarmente il piano alla luce delle nuove vulnerabilità dei pacchetti, delle dipendenze dei produttori modificate e dei costi operativi. Se i componenti necessari non sono più supportati o se non è possibile limitare adeguatamente gli accessi necessari, il semplice rinnovo del supporto per il sistema operativo potrebbe non essere sufficiente. In tal caso, occorre rivalutare la migrazione, la sostituzione dell’applicazione o la dismissione controllata.