Update or not update?

Qualche giorno fa stavo cercando su internet ispirazione per risolvere un problema quando mi sono imbattuto in questo post contenente una frase che mi ha fatto riflettere:

I did a hugest mistake on my it-career…

I only wanted to upgrade ntp package on all servers which i administrate. Simple task, huh?

I run this command:
[…]
And some servers (several hundred!!!) was fully upgraded!!! Of course it is very high impact for business… Because some server was never updated several years…

Server, nel post mi riferisco principalmente a questi, mai aggiornati in diversi anni? Ora, dalla fine dell’università, oltre una decade per intenderci, ho lavorato sempre nella stessa azienda, forse non ho l’esperienza di infrastrutture molto più complesse o diverse ma … mai aggiornati in diversi anni mi pare un approccio un po’ discutibile.
Se da un certo punto di vista si applica la regola d’oro “funziona? non lo toccare” dall’altro un sistema non aggiornato è un sistema più vulnerabile; non solo, con il passare del tempo si accumulano tutti quei rischi (perchè ce ne sono) legati all’aggiornamento.
Vuoi che un audit del sistema forzi a fare l’aggiornamento per via delle patch di sicurezza, piuttosto che un banale errore come scritto sopra, o banalmente una risoluzione delle dipendenze per l’aggiornamento di un qualsiasi pacchetto causi una valanga, saremmo potenzialmente in una brutta situazione.

Pensate semplicemente se i 2 problemi menzionati nell’articolo su Amazon Linux fossero comparsi nello stesso momento della più recente e invasiva patch di sicurezza di log4j rilasciata da Amazon Linux 2 che di fatto andava a sostituire log4j all’interno del sistema.

Vero che ci sono backup e snapshot (viva le macchine virtuali) però a livello personale non credo sia l’approccio migliore, proviamo a vederne qualcun’ altro.

Aggiornamenti automatici

Da un punto di vista della sicurezza questo è sicuramente l’approccio migliore tuttavia, per mia conoscenza di yum-cron, se saltasse fuori un problema, lo farebbe ovunque nel giro di una giornata quindi sugli ambienti di produzione o mission critical non è proprio l’approccio migliore. Gli aggiornamenti automatici hanno un gran senso su server non mission critical tipo ambienti interni di sviluppo o pre-produzioni, eccetera perchè aiutano ad anticipare i problemi su macchine più critiche. In ogni caso un configuration manager o dei banali script che controllano la configurazione sono sempre utili, prima che l’aggiornamento resetti i file di configurazione ai valori di default.

Aggiornamenti manuali periodici – “La virtù sta nel mezzo”

Si potrebbe banalizzare semplicemente come: aggiorniamo le macchine una volta al mese, oppure in base al periodo desiderato.
In realtà io approccio la cosa in maniera più organizzata
– uno script che gira mensilmente parsa l’output di yum-check update e mi notifica via email i pacchetti disponibili per l’aggiornamento, oramai sappiamo che l’aggiornamento di certi pacchetti ha effetti sulla configurazione, ad esempio aggiornare sudo resetta i permessi di /etc/sudoer, l’aggiornamento di clamd cambia il parametro di restart, eccetera
– gli ambienti di sviluppo interno hanno aggiornamenti automatici
– si aggiornano prima gli ambienti di pre-produzione
– il giorno dopo (o qualche giorno dopo) si aggiornano gli ambienti più critici sul presupposto che non siano usciti altri aggiornamenti nel frattempo, altrimenti la giostra ricomincia.

Extrema ratio

Nella speranza di fare la cosa più giusta sono capitato su questo post e nei commenti si suggeriva di generare una lista di aggiornamenti smanacciando l’output di yum list updates

[root@cent7 ~]# pkgs=`yum -q list updates 2>&1 | tail -n+2 | awk ‘{print $1 “|” $2}’ | sed ‘s/.[^.]*|(.*:)*/-/’ | tr “n” ” “`

e di generare un comando con parametri per aggiornare solo quei pacchetti a quella versione con yum update-to

[root@cent7 ~]# echo “yum update-to $pkgs”
yum update-to dbus-1.10.24-13.el7_6 dbus-libs-1.10.24-13.el7_6 java-1.8.0-openjdk-1.8.0.242.b08-1.el7 java-1.8.0-openjdk-headless-1.8.0.242.b08-1.el7 tzdata-java-2019c-1.el7 unzip-6.0-21.el7

Un po’ hardcore ma la cosa ha assolutamente senso. No, non l’ho mai provato.

Conclusioni

Non credo ci sia un approccio giusto o uno sbagliato, ce ne sono diversi, io ho provato a passarli in rassegna tutti evidenziando debolezze e punti di forza. Certo devono esserci motivi molto molto forti per non applicare le patch di sicurezza per non perturbare l’ambiente, ma l’idea che l’inaspettato scoperchi il vaso di pandora è una cosa che mi terrorizza. E ora la domanda: voi come fate e perchè? Avete voglia di raccontarlo nei commenti?