CentOS 6 ha smesso di ricevere aggiornamenti il 30 novembre 2020. Quasi sei anni dopo, qualche server con questo sistema è ancora acceso: spesso ospita un gestionale scritto su misura, un vecchio negozio online o un portale che nessuno ha più toccato perché “funziona”. Sopra c’è quasi sempre un PHP della serie 5, a sua volta abbandonato dal progetto PHP da molti anni.
È una situazione doppiamente fuori supporto: né il sistema operativo né l’interprete ricevono correzioni. In questo articolo vediamo cosa comporta davvero, strato per strato, come fare un inventario senza rompere nulla, cosa si può fare subito per proteggere PHP e ridurre l’esposizione del server e perché, su CentOS 6, la migrazione va pianificata adesso e non rimandata.
Cosa vuol dire doppiamente fuori supporto
Su un server supportato, una vulnerabilità di PHP o di una libreria di sistema viene corretta da chi mantiene i pacchetti. Su CentOS 6 questa catena si è interrotta due volte. Il sistema operativo è fermo all’ultima versione, la 6.10, con i pacchetti archiviati su vault.centos.org. Il PHP di base è la versione 5.3.3, di un ramo che il progetto PHP ha chiuso il 14 agosto 2014. Chi aveva bisogno di una versione più recente usava i pacchetti di Remi Collet o le Software Collections, con PHP dal 5.4 al 5.6: rami chiusi rispettivamente nel 2015, nel 2016 e alla fine del 2018.
Anche le fonti alternative si sono fermate. Il repository di Remi per Enterprise Linux 6 non riceve aggiornamenti da tempo e, ad agosto 2026, è stato spostato tra gli archivi e non viene più distribuito dai mirror. Red Hat offre per RHEL 6 un supporto esteso a pagamento, rinnovabile di anno in anno fino al 2030, ma vale solo per i sistemi con un abbonamento RHEL e copre i pacchetti di RHEL 6, quindi al massimo il PHP 5.3 di base.
Cosa c’è sotto PHP
Il problema di CentOS 6 non è solo l’età di PHP. Tutto il software di base appartiene a una generazione precedente, e ogni componente porta i suoi limiti:
| Componente | Versione su CentOS 6.10 | Cosa comporta |
|---|---|---|
| Kernel | Linux 2.6.32 | nessuna correzione dal 2020: una falla in PHP può diventare il punto di partenza per ottenere i privilegi di root |
| OpenSSL | 1.0.1e | niente TLS 1.3; PHP lo usa per HTTPS, cURL e le connessioni verso servizi esterni come gateway di pagamento e API |
| glibc | 2.12 | il software moderno compilato per sistemi recenti non si installa |
| Avvio dei servizi | SysV init e Upstart | niente systemd: strumenti e procedure attuali non si applicano |
| PHP | 5.3.3, oppure 5.4 – 5.6 da Remi o SCL | vulnerabilità pubblicate dopo la fine del ramo senza correzione ufficiale |
Oltre al rischio di attacco c’è quello di un guasto improvviso: un fornitore di pagamenti, un corriere o un servizio di fatturazione aggiorna i requisiti delle sue connessioni e il server smette di comunicare. Sotto pressione, a quel punto, si tende a improvvisare.
L’inventario, prima di toccare qualcosa
Su un server così vecchio la documentazione è spesso incompleta, e chi lo ha configurato non lavora più in azienda. Prima di qualsiasi intervento serve una fotografia precisa di cosa gira e di come. Questi comandi leggono soltanto, e funzionano anche con i repository irraggiungibili:
# Versione del sistema, del kernel e delle librerie principali
cat /etc/redhat-release
uname -r
rpm -q openssl glibc
# Versione di PHP della riga di comando e pacchetti installati
php -v
rpm -qa --qf '%{NAME}-%{VERSION}-%{RELEASE} %{VENDOR}\n' | grep -i php | sort
# Collezioni installate in parallelo (Red Hat e Remi)
ls -d /opt/rh/* /opt/remi/* 2>/dev/null
# Servizi avviati al boot e porte in ascolto
chkconfig --list | grep ':on'
ss -tlnpAll’elenco aggiungi le cose che i comandi non dicono: le attività pianificate in crontab, i virtual host del server web, le connessioni verso database e servizi esterni, le credenziali salvate nei file di configurazione. Poi fai una copia completa del server, un’immagine della macchina virtuale o un backup a livello di disco, da usare come ambiente di prova.
Proteggere PHP, per quanto possibile
Il primo passo pratico è lo stesso di CentOS 7: puntare i repository all’archivio vault.centos.org, che per CentOS 6 contiene i pacchetti della 6.10, così da poter installare di nuovo dipendenze e strumenti. Abbiamo descritto i comandi nell’articolo su CentOS 7 dopo la fine del supporto: per CentOS 6 sono identici.
Il secondo passo è il backport delle patch sul PHP installato. Ricostruiamo lo stesso pacchetto, con lo stesso nome, gli stessi percorsi e le stesse estensioni, aggiungendo le correzioni per le vulnerabilità pubblicate dopo la fine del ramo e adattate al suo codice. La compilazione avviene in un ambiente CentOS 6 pulito, identico a quello di produzione, e il pacchetto viene provato con l’applicazione reale prima del rilascio, che facciamo con Ansible e un piano di rollback. Per dare un’idea della mole di lavoro su questi rami: sul solo PHP 5.6.40, l’ultima versione ufficiale del 5.6, il nostro pacchetto corregge 55 CVE, 11 delle quali aggiunte da noi con backport dedicati. Ne parliamo nell’articolo su PHP 5.6 nel 2026.
Su CentOS 6 il backport ha però un limite evidente: chiude le falle di PHP e delle sue estensioni, mentre kernel, OpenSSL e librerie restano scoperti. Per questo va sempre affiancato dall’isolamento del server.
Isolare il server
L’obiettivo è che il server CentOS 6 parli con il minor numero possibile di sistemi, e che nessuno di questi sia Internet. Lo schema che proponiamo mette davanti al vecchio server un reverse proxy su un sistema supportato.
- Reverse proxy aggiornato: termina le connessioni HTTPS con protocolli e certificati moderni, filtra le richieste sospette e limita per indirizzo IP le aree amministrative. Il vecchio server riceve solo richieste già controllate.
- Rete isolata: il firewall del server accetta connessioni solo dal proxy e dalle macchine di amministrazione, e blocca le uscite verso Internet tranne quelle indispensabili, da elencare una per una.
- PHP ridotto al minimo: estensioni non usate disattivate,
expose_phpspento, cartelle di upload senza esecuzione di script. - Integrazioni esterne spostate: dove possibile, le chiamate verso API di terzi passano da un sistema moderno, così non dipendono dall’OpenSSL di CentOS 6.
- Backup e log fuori dal server: in caso di compromissione, i dati per ripartire e per capire cosa è successo non devono stare sulla macchina compromessa.
Perché qui la migrazione non può aspettare
Su CentOS 7 il backport di PHP può proteggere la produzione per un periodo ragionevole. Su CentOS 6 il margine è più stretto, per tre motivi. Il sistema è fuori supporto da più tempo, e le falle aperte nel kernel e nelle librerie sono di più. Le dipendenze esterne, come i servizi di pagamento e le API dei fornitori, si allontanano ogni anno di più da quello che OpenSSL 1.0.1e e le vecchie estensioni riescono a gestire. E in un audit un sistema fuori supporto da anni è difficile da giustificare anche con un piano.
C’è poi la distanza del codice. Un’applicazione nata per PHP 5.3 usa spesso funzioni rimosse da tempo: l’estensione mysql e le funzioni ereg sono state eliminate in PHP 7.0, create_function() e each() in PHP 8.0. Il salto verso PHP 8 è un progetto vero, da stimare con un’analisi del codice, e prima comincia meglio è. Per la parte sul database abbiamo scritto una guida al passaggio da mysql a PDO.
Esistono strumenti per aggiornare sul posto CentOS 6 a CentOS 7, e da lì proseguire verso le versioni successive. Su un sistema così datato, però, una catena di tre o quattro aggiornamenti consecutivi, ciascuno con un cambio di versione di PHP, richiede più lavoro e più rischi di un server nuovo installato da zero. Per questo di norma consigliamo la seconda strada.
Un piano in quattro tappe
- Fotografia: inventario completo, copia del server e ambiente di prova identico alla produzione.
- Messa in sicurezza: repository dal vault, backport delle patch su PHP, reverse proxy e isolamento di rete.
- Nuovo server: Rocky Linux, AlmaLinux o RHEL in versione 9 o 10, con l’applicazione adeguata a PHP 8 e provata su una copia dei dati reali.
- Passaggio: il proxy invia il traffico al nuovo server, il vecchio resta spento ma disponibile per qualche settimana, poi viene dismesso con la cancellazione sicura dei dati.
Le prime due tappe si fanno in tempi brevi e riducono subito il rischio; la terza è quella che richiede più lavoro, e le prime due servono proprio a darle il tempo necessario. Se vuoi impostare il piano sul tuo server, trovi come lavoriamo nella sezione sulla migrazione applicativa.
In conclusione
Un server CentOS 6 con PHP è fuori supporto a ogni livello: il sistema dal 30 novembre 2020, il PHP 5.3 di base dal 2014, le versioni dal 5.4 al 5.6 dal 2015 al 2018, e anche i repository alternativi sono ormai in archivio. Il backport delle patch protegge lo strato di PHP, ma kernel, OpenSSL e librerie restano scoperti, per questo va affiancato da un isolamento serio con un reverse proxy aggiornato davanti e una rete chiusa intorno. Sono misure che servono a guadagnare tempo in sicurezza. La meta è un server nuovo con Rocky Linux, AlmaLinux o RHEL e l’applicazione portata su PHP 8, da pianificare subito partendo da un inventario accurato.
