Installare unattended-upgrades e Lynis su Debian: aggiornamenti automatici e audit di sicurezza

Perché ha senso farlo subito

Su un server Debian la sicurezza non si esaurisce con gli aggiornamenti manuali. I pacchetti di sicurezza arrivano spesso e, se non vengono applicati con regolarità, il sistema resta esposto più del necessario. In parallelo, un audit periodico con Lynis aiuta a vedere quello che gli aggiornamenti da soli non mostrano: configurazioni deboli, servizi inutili, permessi troppo larghi, kernel e hardening da migliorare.

La combinazione di unattended-upgrades e Lynis è semplice, reversibile e adatta a quasi tutti i server Debian. Il primo riduce il rischio operativo applicando automaticamente gli update di sicurezza. Il secondo dà una fotografia concreta dello stato del sistema e suggerisce correzioni pratiche.

Cosa installiamo e cosa aspettarci

Questa procedura copre Debian moderno, in particolare le versioni ancora supportate e usate su VPS e server dedicati. L’obiettivo è:

• abilitare gli aggiornamenti automatici solo per i pacchetti di sicurezza;
• verificare che il servizio lavori correttamente;
• installare Lynis e lanciare un audit iniziale;
• leggere i risultati senza farsi bloccare da falsi allarmi o suggerimenti non prioritari;
• impostare una routine minima di controllo.

Non stiamo facendo hardening aggressivo né modifiche invasive. Partiamo dalla base più sicura e più facile da mantenere.

Prima di iniziare: controlli rapidi

Prima di installare qualsiasi cosa, conviene verificare che il sistema sia davvero Debian e che il gestore pacchetti sia in ordine. Se il server ha repository rotti o una release fuori supporto, gli aggiornamenti automatici possono fallire o non trovare più i pacchetti di sicurezza.

cat /etc/debian_version

Atteso: una versione Debian valida. Se il comando non restituisce nulla di utile, il sistema potrebbe non essere Debian puro oppure il file è stato alterato.

Controlla anche che l’indice dei pacchetti sia aggiornabile:

sudo apt update

Atteso: nessun errore sui repository. Se compaiono errori DNS, repository non raggiungibili o firme GPG mancanti, è meglio risolverli prima di procedere.

Installare unattended-upgrades su Debian

Il pacchetto giusto è piccolo e stabile. In Debian, la configurazione standard è pensata proprio per applicare gli aggiornamenti di sicurezza in automatico, senza toccare i pacchetti normali se non lo decidi esplicitamente.

sudo apt update
sudo apt install unattended-upgrades apt-listchanges

apt-listchanges non è obbligatorio, ma è utile perché mostra le note dei changelog durante gli aggiornamenti manuali. Non interferisce con il funzionamento automatico e aggiunge un minimo di visibilità.

Dopo l’installazione, abilita il servizio e la configurazione automatica:

sudo dpkg-reconfigure --priority=low unattended-upgrades

Atteso: ti viene chiesto se vuoi abilitare gli aggiornamenti automatici. Rispondi Yes.

In alternativa, se preferisci controllare il file direttamente, verifica che esista la configurazione dedicata:

ls -l /etc/apt/apt.conf.d/50unattended-upgrades /etc/apt/apt.conf.d/20auto-upgrades

Atteso: almeno uno dei file deve esistere, idealmente entrambi.

Configurazione consigliata di unattended-upgrades

Il file principale è /etc/apt/apt.conf.d/50unattended-upgrades. Prima di toccarlo, fai sempre un backup. È una modifica reversibile, ma su un server in produzione conviene lavorare con prudenza.

sudo cp /etc/apt/apt.conf.d/50unattended-upgrades /etc/apt/apt.conf.d/50unattended-upgrades.bak

Apri il file con l’editor che usi di solito, per esempio nano:

sudo nano /etc/apt/apt.conf.d/50unattended-upgrades

La sezione importante è quella degli archivi consentiti. Su Debian, in genere, devono esserci le righe per la release corrente e per le security update. Un esempio tipico, da adattare alla tua versione, è questo:

Unattended-Upgrade::Allowed-Origins {
        "${distro_id}:${distro_codename}";
        "${distro_id}:${distro_codename}-security";
};

In molti casi Debian usa già una configurazione corretta. Il punto non è inventare una politica nuova, ma verificare che gli aggiornamenti di sicurezza siano effettivamente inclusi. Se vuoi mantenere il comportamento più prudente possibile, evita di abilitare repository extra o aggiornamenti completi non necessari.

Se trovi opzioni utili ma non indispensabili, queste sono le più sensate da controllare:

• Automatic-Reboot: se attivo, riavvia il server dopo aggiornamenti del kernel. Su server in produzione va valutato con attenzione;
• Automatic-Reboot-Time: imposta l’orario del reboot automatico;
• Remove-Unused-Dependencies: utile, ma da attivare solo se hai verificato che non rimuova dipendenze ancora usate;
• Mail: invio report via email, utile se il server è monitorato.

Per un primo setup, la scelta più sicura è:

• aggiornamenti automatici di sicurezza sì;
• reboot automatico no, almeno inizialmente;
• pulizia automatica delle dipendenze no, finché non hai verificato il comportamento del sistema;
• notifiche via mail sì, se hai un MTA configurato.

Abilitare la schedulazione automatica

Il file /etc/apt/apt.conf.d/20auto-upgrades controlla la frequenza. Anche qui conviene fare un backup se il file esiste già.

sudo cp /etc/apt/apt.conf.d/20auto-upgrades /etc/apt/apt.conf.d/20auto-upgrades.bak 2>/dev/null || true

Imposta almeno questi valori:

sudo tee /etc/apt/apt.conf.d/20auto-upgrades > /dev/null <<'EOF'
APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Unattended-Upgrade "1";
EOF

Questo significa: aggiorna la lista dei pacchetti ogni giorno e lancia gli aggiornamenti automatici una volta al giorno.

Verifica il contenuto:

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

Atteso: le due righe sopra devono essere presenti e corrette.

Verificare che unattended-upgrades funzioni

La parte importante non è solo installare, ma controllare che il sistema sia davvero pronto a operare. Debian usa log e simulazioni che aiutano a capire se la configurazione è coerente.

Controlla lo stato del servizio timer e del servizio collegato:

systemctl status unattended-upgrades

Atteso: nessun errore grave. Se il servizio non è attivo, non sempre è un problema: in molte installazioni l’esecuzione avviene tramite timer o job periodici. Per questo conviene verificare anche i timer APT:

systemctl list-timers | grep -E 'apt|unattended'

Atteso: vedi timer relativi ad apt-daily e, se presente, agli aggiornamenti automatici.

Per un controllo più concreto, simula l’aggiornamento con il log verbose:

sudo unattended-upgrade -d --dry-run

Atteso: il comando deve scorrere senza errori di configurazione evidenti e indicare quali pacchetti sarebbero gestiti. Se trovi errori di repository, firme o lock di APT, quelli vanno risolti prima di considerare il sistema affidabile.

I log utili sono questi:

sudo tail -n 100 /var/log/unattended-upgrades/unattended-upgrades.log

e, se necessario:

sudo journalctl -u unattended-upgrades --no-pager -n 100

Atteso: presenza di esecuzioni pianificate o almeno assenza di errori ripetuti.

Installare Lynis su Debian

Lynis è un audit tool molto utile perché non si limita a dire “c’è un problema”, ma mostra anche il contesto e spesso indica il motivo tecnico. Su Debian puoi installarlo dal repository ufficiale se disponibile, oppure usare il pacchetto della distribuzione se presente nei repository abilitati.

sudo apt update
sudo apt install lynis

Se il pacchetto non fosse disponibile nella tua release o nei repository attivi, prima di aggiungere fonti esterne conviene verificare la versione Debian e la politica della macchina. Su server in produzione è preferibile restare sui repository ufficiali, salvo necessità precise.

Controlla la versione installata:

lynis show version

Atteso: una versione valida e nessun errore di esecuzione.

Primo audit con Lynis

Il primo scan va eseguito da root o con sudo, perché Lynis deve leggere molte informazioni di sistema. Il comando base è molto semplice:

sudo lynis audit system

Atteso: il test completa la raccolta dati e produce un report con warning, suggestions e un punteggio finale.

Se vuoi salvare l’output in modo leggibile, puoi usare un log dedicato:

sudo lynis audit system --logfile /root/lynis-audit.log

Il report finale è la parte più importante. Non guardare solo il punteggio numerico: osserva soprattutto i suggerimenti con priorità alta. Su un server sano, i primi interventi di solito riguardano:

• aggiornamenti di sicurezza mancanti;
• servizi non necessari attivi;
• configurazioni SSH troppo permissive;
• firewall assente o incompleto;
• permessi su file e directory critici;
• parametri kernel e hardening di base.

Il principio giusto è semplice: correggi prima i warning che hanno impatto reale, poi i suggerimenti meno urgenti.

Come leggere i risultati senza perdere tempo

Lynis può produrre molti suggerimenti. Non tutti meritano un intervento immediato. Per evitare di inseguire ogni singola nota, usa questa priorità:

1. impatto alto: vulnerabilità, servizi esposti, aggiornamenti mancanti, SSH insicuro, firewall assente;
2. impatto medio: logging incompleto, permessi migliorabili, hardening kernel, sysctl consigliati;
3. impatto basso: ottimizzazioni estetiche, suggerimenti marginali o dipendenti dal tipo di server.

Se un controllo non è pertinente al tuo ambiente, non forzarlo. Un server web minimale e un nodo con mail, database e pannello non hanno lo stesso profilo di rischio. Lynis va interpretato con testa, non eseguito come un elenco meccanico.

Automatizzare anche l’audit, ma con criterio

Un audit manuale ogni tanto è utile, ma su un server serio conviene schedulare anche Lynis in modo periodico. Non per sostituire il controllo umano, ma per avere una baseline e vedere se qualcosa cambia.

La soluzione più pulita è creare uno script semplice e un cron settimanale. Prima di tutto, salva il report in una directory dedicata:

sudo mkdir -p /var/log/lynis

Poi puoi creare un piccolo script, ad esempio /usr/local/sbin/lynis-weekly.sh, dopo aver fatto un backup o aver verificato che il file non esista già:

sudo tee /usr/local/sbin/lynis-weekly.sh > /dev/null <<'EOF'
#!/bin/sh
/usr/bin/lynis audit system --quiet --logfile /var/log/lynis/lynis-$(date +%F).log
EOF
sudo chmod 750 /usr/local/sbin/lynis-weekly.sh

Verifica il percorso corretto di Lynis con which lynis se il binario non è in /usr/bin/lynis. È un dettaglio pratico che evita fallimenti silenziosi.

Per il cron settimanale, puoi usare una voce come questa:

sudo crontab -e

Aggiungi:

30 3 * * 0 /usr/local/sbin/lynis-weekly.sh

Atteso: ogni domenica alle 03:30 viene creato un log nuovo. Se preferisci non automatizzare subito, esegui Lynis manualmente una volta al mese e conserva il report come baseline.

Buone pratiche dopo l’installazione

Una volta attivati gli aggiornamenti automatici e fatto il primo audit, non fermarti alla configurazione iniziale. La sicurezza è manutenzione continua, non una spunta da mettere una sola volta.

• controlla i log di unattended-upgrades almeno dopo il primo ciclo automatico;
• leggi il report Lynis e risolvi prima i problemi ad alto impatto;
• verifica che il server non si riavvii in momenti critici se hai abilitato il reboot automatico;
• mantieni un backup aggiornato prima di interventi su pacchetti di sistema;
• monitora spazio disco, CPU e stato dei servizi per intercettare effetti collaterali degli update.

Se il server ospita applicazioni web, dopo gli aggiornamenti controlla sempre che il sito risponda, che PHP-FPM o Apache/Nginx siano attivi e che il database sia raggiungibile. Un aggiornamento di sicurezza riuscito non basta se poi un servizio resta fermo.

Problemi comuni e come riconoscerli

Il caso più frequente è il repository non raggiungibile. In quel caso unattended-upgrades non può scaricare nulla e i log mostrano errori di rete, DNS o firma. Un altro problema tipico è il lock di APT: se un altro processo sta già usando il gestore pacchetti, l’aggiornamento automatico può slittare o fallire.

Se Lynis segnala troppi warning all’inizio, non significa che il server sia compromesso. Spesso indica una configurazione base da migliorare. La cosa importante è distinguere tra:

• problemi reali da correggere subito;
• raccomandazioni migliorative;
• controlli non applicabili al tuo scenario.

Se il server è in produzione, ogni modifica va fatta con un minimo di disciplina: prima backup, poi cambiamento, poi verifica.

Conclusione operativa

Con pochi passaggi ottieni due vantaggi concreti: patch di sicurezza applicate automaticamente e una scansione periodica che ti aiuta a vedere dove il server è più debole. Su Debian questa combinazione è una delle basi più sane da mettere in piedi subito dopo l’installazione o dopo la migrazione di una VPS.

Se vuoi mantenerla davvero utile nel tempo, il metodo giusto è semplice: automatizza gli update di sicurezza, fai un audit Lynis iniziale, correggi i punti ad alto impatto e ripeti il controllo a intervalli regolari. È una routine piccola, ma nel tempo fa una differenza enorme.

Checklist finale

• unattended-upgrades installato e abilitato;
• file /etc/apt/apt.conf.d/20auto-upgrades configurato correttamente;
• test unattended-upgrade --dry-run senza errori bloccanti;
• Lynis installato e audit eseguito con successo;
• primi warning classificati per priorità e corretti in ordine di impatto.

Assunzione: il server usa Debian supportato e repository ufficiali funzionanti.