Ubuntu 24.04: unattended-upgrades è attivo di default?

Perché vale la pena configurare gli aggiornamenti di sicurezza automatici

Un server senza patch è il bersaglio più facile su Internet. La maggior parte delle violazioni dei server di piccole dimensioni non richiede tecniche sofisticate: sfrutta un bug noto presente in un vecchio pacchetto che il proprietario non ha mai aggiornato. Ubuntu include uno strumento che elimina autonomamente questo problema: unattended-upgrades installa automaticamente gli aggiornamenti di sicurezza secondo una pianificazione, senza richiedere l'accesso interattivo. È la misura di sicurezza più economica disponibile su un VPS e, su Ubuntu, richiede pochi minuti di configurazione.

Lo strumento è volutamente conservativo. Per impostazione predefinita applica solo gli aggiornamenti di sicurezza, non l'aggiornamento di tutti i pacchetti, perché una patch di sicurezza presenta un rischio ridotto e conviene installarla senza revisione, mentre un aggiornamento funzionale può modificare un comportamento da cui dipendi. Questa impostazione predefinita è adatta alla maggior parte dei server e questa guida la mantiene, mostrando solo le poche impostazioni che vale la pena modificare.

Passaggio 1: installazione e abilitazione

Su Ubuntu Server 24.04 il pacchetto è installato e abilitato per impostazione predefinita. La documentazione del server Ubuntu indica che unattended-upgrades è installato per impostazione predefinita e che l'installazione automatica degli aggiornamenti di sicurezza è abilitata subito dopo l'installazione. Durante l'installazione, la domanda sull'abilitazione del pacchetto ha come risposta predefinita yes. Pertanto, salvo che qualcuno abbia risposto esplicitamente no, il job giornaliero è già attivo. Un'immagine personalizzata o ridotta del provider può comunque comportarsi in modo diverso, quindi è meglio verificare anziché dare per scontato questo comportamento. Questi comandi sono sicuri in entrambi i casi: installano il pacchetto se manca e ripropongono la domanda che lo abilita:

sudo apt update
sudo apt install -y unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

Il prompt dpkg-reconfigure pone una sola domanda con risposta yes-or-no: se scaricare e installare automaticamente gli aggiornamenti stabili. Rispondere yes. In questo modo viene scritto il file che abilita il job giornaliero:

cat /etc/apt/apt.conf.d/20auto-upgrades

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

La prima riga aggiorna ogni giorno l'elenco dei pacchetti; la seconda esegue ogni giorno l'aggiornamento automatico. Quando entrambe sono impostate su 1, il sistema verifica e applica ogni giorno gli aggiornamenti di sicurezza tramite un timer systemd, senza ulteriori interventi.

Passaggio 2: Decidere cosa applicare automaticamente

La policy si trova in /etc/apt/apt.conf.d/50unattended-upgrades. Aprila e individua il blocco Allowed-Origins nella parte iniziale del file:

Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}";
    "${distro_id}:${distro_codename}-security";
    "${distro_id}ESMApps:${distro_codename}-apps-security";
    "${distro_id}ESM:${distro_codename}-infra-security";
};

Le righe -security sono quelle rilevanti e sono abilitate per impostazione predefinita. Questa è la policy prudente: gli aggiornamenti di sicurezza vengono applicati automaticamente, mentre i normali aggiornamenti funzionali restano da applicare manualmente quando lo decidi. Puoi decommentare la riga "${distro_id}:${distro_codename}-updates" nello stesso blocco per applicare automaticamente anche i normali aggiornamenti stabili di Ubuntu. In questo modo la policy si estende soltanto all'archivio -updates di Ubuntu, non a ogni repository o PPA presente sul computer. Restano inoltre valide le normali verifiche: lo strumento sospende l'aggiornamento di qualsiasi pacchetto che richieda una conferma per un file di configurazione e non installa nulla se le relative dipendenze non possono provenire da un'origine autorizzata. Per un server che ospita servizi importanti, applicare automaticamente soltanto le patch di sicurezza è l'impostazione predefinita più sicura. Lasciala invariata, come fornita, salvo che tu abbia un motivo specifico per modificarla.

Passaggio 3: gestire i riavvii

Alcuni aggiornamenti, come quelli del kernel o di una libreria di base, diventano pienamente effettivi solo dopo un riavvio. unattended-upgrades non riavvia il server se non glielo indichi esplicitamente; di conseguenza, un kernel aggiornato può restare inutilizzato fino al successivo riavvio. Decidi come gestire questa situazione e imposta esplicitamente il comportamento in 50unattended-upgrades:

Unattended-Upgrade::Automatic-Reboot "true";
Unattended-Upgrade::Automatic-Reboot-Time "04:00";

Questa impostazione riavvia il server alle quattro del mattino, ma solo quando un aggiornamento lo richiede. Su un singolo VPS senza un cluster a cui eseguire il failover, un breve riavvio nelle prime ore del mattino è in genere un compromesso ragionevole per applicare tempestivamente le correzioni del kernel. Se il server esegue un servizio che non deve mai riavviarsi in modo imprevisto, lascia disabilitato il riavvio automatico e riavvia manualmente il server dopo aver controllato /var/run/reboot-required.

Passaggio 4: Verifica del funzionamento

Non attendere un giorno per scoprire se il job viene eseguito. Avvia una simulazione (dry run) che mostri esattamente cosa verrebbe applicato, senza modificare nulla:

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

L'output elenca i pacchetti presi in considerazione e le relative origini, permettendo di osservare la policy in azione. Dopo che il job reale è stato eseguito almeno una volta, il suo registro si trova qui:

cat /var/log/unattended-upgrades/unattended-upgrades.log

Quel log è la risposta alla domanda "il mio server si sta aggiornando automaticamente". Se mostra l'installazione programmata di pacchetti di sicurezza, il job sta funzionando.

Dove si inserisce

Gli aggiornamenti automatici sono un livello della messa in sicurezza del server, non l'intera soluzione. Impediscono che i bug noti restino presenti, ma non intervengono sugli utenti autorizzati ad accedere né sui servizi esposti. Abbinali a un hardening di SSH con accesso basato solo su chiavi, in modo da impedire attacchi di forza bruta al punto di accesso, a un firewall UFW con criterio default-deny, così che sia raggiungibile solo ciò che scegli, e a utenti di servizio senza privilegi, così che un'applicazione compromessa non possa prendere il controllo dell'intero server. Le applicazioni ospitate gestiscono inoltre i propri secret; se questo server esegue un password vault self-hosted, un intervento di hardening di Vaultwarden protegge il token amministrativo e il file di backup, che nessuna quantità di patch applicate da apt può proteggere. Le patch chiudono le vulnerabilità note; gli altri livelli limitano i danni causati da quelle che non conosci.

FAQ

unattended-upgrades applica tutti gli aggiornamenti o solo quelli di sicurezza?

Per impostazione predefinita, solo gli aggiornamenti di sicurezza. Il blocco Allowed-Origins in /etc/apt/apt.conf.d/50unattended-upgrades abilita le origini -security e lascia a te l'applicazione manuale dei normali aggiornamenti funzionali. È una scelta intenzionale: le patch di sicurezza presentano un rischio ridotto e conviene installarle automaticamente, mentre gli aggiornamenti funzionali possono modificare il comportamento del sistema; per questo la maggior parte dei server dovrebbe mantenere l'impostazione conservativa predefinita.

Gli aggiornamenti automatici riavvieranno il server?

Solo se lo specifichi. Imposta Unattended-Upgrade::Automatic-Reboot "true" e un Automatic-Reboot-Time nella configurazione: il server si riavvierà a quell'ora quando un aggiornamento lo richiede, ad esempio dopo una patch del kernel. Se lasci l'impostazione disabilitata, un kernel aggiornato resterà in attesa fino al riavvio manuale; controlla /var/run/reboot-required per verificare se ce n'è uno in sospeso.

Come verifico che gli aggiornamenti automatici siano effettivamente in esecuzione?

Esegui sudo unattended-upgrade --dry-run --debug per vedere cosa verrebbe applicato in questo momento, senza modificare nulla, e consulta /var/log/unattended-upgrades/unattended-upgrades.log per il registro delle esecuzioni precedenti; ogni installazione automatica viene inoltre registrata in /var/log/apt/history.log. Se il log mostra l'installazione giornaliera di pacchetti di sicurezza, il timer funziona. Se la simulazione restituisce No packages found that can be upgraded unattended, significa che tutto è già aggiornato oppure che le origini autorizzate sono troppo limitate per includere il repository di sicurezza.

unattended-upgrades è sufficiente per mantenere sicuro il server?

No, ma è un livello necessario. Impedisce che le vulnerabilità note restino senza patch, evitando il tipo più comune di violazione, ma non controlla gli accessi né l'esposizione dei servizi. Combinalo con l'hardening di SSH, un firewall con criterio default-deny e utenti di servizio con privilegi minimi, per ottenere un server realmente difficile da compromettere.