La maggior parte delle intrusioni riuscite sui server non passa da exploit ingegnosi ma da una vulnerabilità la cui patch è uscita mesi fa. Il motivo di solito non è la pigrizia: aggiornare a mano su un server in produzione fa paura, perché apt upgrade a volte riavvia ciò che nessuno gli ha chiesto. Gli aggiornamenti automatici risolvono la questione, ma hanno cattiva fama, meritata esattamente nella misura in cui li si configura di fretta.

Vediamo una configurazione in cui le patch di sicurezza arrivano da sole e la versione di PHP non cambia di notte.

Installazione

sudo apt install unattended-upgrades apt-listchanges
sudo dpkg-reconfigure -plow unattended-upgrades

Il dialogo crea /etc/apt/apt.conf.d/20auto-upgrades. Verifichi che cosa ne è uscito:

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";

Gli uno significano «ogni giorno». Il tutto viene avviato da un timer di systemd, non dal cron classico:

systemctl list-timers | grep apt

L’essenziale: solo sicurezza

Il file principale è /etc/apt/apt.conf.d/50unattended-upgrades. Contiene un elenco Allowed-Origins (su Debian, Origins-Pattern), e di default vi è attivo solo il repository di sicurezza. Lo lasci così.

La tentazione di togliere il commento alla riga con -updates — «che si aggiorni tutto» — è forte. Non lo faccia: il repository degli aggiornamenti porta versioni nuove e non solo correzioni, ed è proprio da lì che arrivano le sorprese notturne. Sicurezza e novità sono compiti diversi, e il secondo si fa meglio a mano, con lei alla tastiera.

Se un pacchetto non deve essere aggiornato automaticamente, esiste una lista nera:

Unattended-Upgrade::Package-Blacklist {
    "mariadb-server";
    "php8.3-fpm";
};

La usi con consapevolezza: ogni riga lì significa «questo pacchetto lo aggiorno io», e quella promessa andrà mantenuta.

I riavvii

La riga chiave:

Unattended-Upgrade::Automatic-Reboot "false";

Lasciare false è corretto per un server con un sito: un riavvio senza preavviso alle tre di notte è peggio di una patch rinviata di un giorno. Ma quella decisione ha una seconda metà obbligatoria, ed è quella che si dimentica.

Quando vengono aggiornati il kernel, libc o openssl, il sistema crea il file /var/run/reboot-required. Finché non c’è riavvio, la versione corretta sta sul disco mentre in memoria gira quella vecchia: la vulnerabilità, quindi, non è affatto sparita, benché il pacchetto risulti aggiornato. Lo verifichi in modo esplicito:

ls -l /var/run/reboot-required
cat /var/run/reboot-required.pkgs

Il secondo file elenca che cosa ha reso necessario il riavvio. La regola è semplice: appena vede l’indicatore, pianifichi una finestra entro uno o due giorni, non «prima o poi».

Le librerie sono un caso a parte. Viene aggiornato openssl mentre nginx e PHP-FPM continuano a girare con la versione vecchia in memoria, e nessun indicatore di riavvio compare. Chi ha bisogno di essere riavviato lo mostra needrestart:

sudo apt install needrestart
sudo needrestart -b

Lo metta però in modalità «mostra, non chiedere»: altrimenti comincerà a fare domande nel mezzo di un’installazione non interattiva e la bloccherà. Per questo metta in /etc/needrestart/conf.d/ un file con la riga $nrconf{restart} = 'l';.

Verificare che funzioni

Una prova a vuoto senza installare:

sudo unattended-upgrade --dry-run --debug

L’output mostra quali pacchetti rientrano nelle regole e quali sono stati scartati e perché. Che cosa sia realmente accaduto sta nei registri:

sudo tail -50 /var/log/unattended-upgrades/unattended-upgrades.log

Quanti aggiornamenti sono in attesa adesso:

apt list --upgradable 2>/dev/null | grep -i security

Quest’ultimo comando è il più utile di tutti. Aggiornamenti automatici configurati hanno l’abitudine di rompersi in silenzio: finito lo spazio su /boot, un repository che ha cambiato chiave, il timer disattivato dopo qualche modifica manuale. Da fuori sembra tutto a posto, e le patch non si installano da mesi.

Lo spazio su /boot

Un classico: i kernel vecchi non vengono rimossi, la partizione /boot si riempie, l’installazione di un kernel nuovo fallisce e gli aggiornamenti si fermano in blocco. Ogni pochi mesi vale la pena dare un’occhiata:

df -h /boot
sudo apt autoremove --purge

Oppure attivi la pulizia automatica nello stesso 50unattended-upgrades: Remove-Unused-Kernel-Packages "true" e Remove-Unused-Dependencies "true".

Che cosa resta alla persona

Gli aggiornamenti automatici tolgono la routine, non la sorveglianza. Due domande a cui dovrebbe saper rispondere in qualsiasi momento: quanti aggiornamenti di sicurezza sono in attesa e se è alzato l’indicatore di riavvio. Entrambe le risposte sono una riga su una pagina, e tutto il senso sta nel fatto che quella riga le salti agli occhi da sé, e non su sua iniziativa una volta a trimestre.