Aggiornamenti di sicurezza FreeBSD: guida a freebsd-update

Come FreeBSD gestisce gli aggiornamenti di sicurezza

FreeBSD gestisce gli aggiornamenti di sicurezza con due strumenti distinti, perché un server FreeBSD è composto da due parti separate. Il sistema di base, cioè il kernel e lo userland incluso nella release, viene aggiornato con freebsd-update. Tutto ciò che viene installato sopra il sistema di base è un package, e i package vengono aggiornati con pkg. Se si esegue uno solo dei due strumenti, metà del sistema resta senza patch e il sistema non segnala questa condizione.

SSD Nodes non offre immagini FreeBSD. I nostri piani utilizzano Linux. Questo articolo è comunque utile perché la sovrapposizione tra i lettori è completa: chi gestisce i nostri server Ubuntu e Debian esegue FreeBSD anche su un firewall o sull'unico server ereditato da un precedente amministratore. Il modello di aggiornamento diviso è l'aspetto che può creare problemi a un amministratore Linux, quindi è quello che vale la pena documentare. Ogni comando, formato degli advisory e data di supporto riportati di seguito sono stati verificati sulla pagina sulla sicurezza di FreeBSD e nelle pagine del manuale del progetto ad agosto 2026.

Una nota prima dei comandi. FreeBSD non installa sudo nel sistema di base. Tutte le operazioni descritte qui richiedono root. Usare su - oppure installare prima sudo o doas dai package.

Il sistema base e i pacchetti sono ambienti separati

Su Ubuntu, apt gestisce l'intera macchina. Il kernel, openssl, nginx e i tuoi strumenti arrivano tutti come file .deb da un unico strumento, mentre apt upgrade li aggiorna insieme.

FreeBSD divide il sistema in due parti. Il sistema base viene compilato come un'unica unità e usa un'unica versione: 15.1-RELEASE-p3 è un singolo numero che copre il kernel, la libreria C, sshd e la copia di OpenSSL in /usr/lib. Nessun componente proviene da pkg. Tutto il resto risiede in /usr/local, arriva come pacchetto binario compilato dall'albero dei ports e ha una propria versione.

Su un singolo host possono quindi coesistere due copie di OpenSSL: la copia del sistema base in /usr/lib, corretta solo da freebsd-update, e la copia del pacchetto in /usr/local/lib, corretta solo da pkg. Il programma usa la copia a cui è stato collegato; il software installato dai pacchetti viene in genere collegato alla copia del pacchetto. Correggere una copia non modifica l'altra.

Tre comandi indicano lo stato del sistema:

freebsd-version -u
freebsd-version -k
uname -r

freebsd-version -u stampa il livello di patch dello userland installato. freebsd-version -k stampa il livello di patch del kernel installato, mentre freebsd-version(1) spiega chiaramente perché non coincide con uname: "se è stato installato un nuovo kernel ma il sistema non è ancora stato riavviato, freebsd-version stampa la versione e il livello di patch del nuovo kernel". uname -r stampa il kernel attualmente in esecuzione. Esiste anche freebsd-version -r, che stampa il kernel in esecuzione ma è "indipendente dalle variabili d'ambiente"; questo è importante all'interno di una jail, dove UNAME_r è spesso impostato su un valore diverso.

Avvisi di sicurezza e avvisi di errata

Dal FreeBSD Security Team vengono pubblicati due tipi di avviso, con significati diversi.

Un Security Advisory riguarda una vulnerabilità di sicurezza nel sistema di base. L'identificativo ha il formato FreeBSD-SA-26:55.elf: le lettere SA, l'anno a due cifre, un numero progressivo per quell'anno e infine il componente interessato. FreeBSD-SA-26:52.if_wg e FreeBSD-SA-26:50.kqueue sono stati pubblicati entrambi il 2026-07-29. L'elenco completo è disponibile nella pagina degli avvisi di sicurezza di FreeBSD.

Un Errata Notice riguarda un problema di correttezza o stabilità abbastanza importante da essere incluso in un ramo di release, ma senza impatto sulla sicurezza. Il formato è lo stesso, con EN al posto di SA: FreeBSD-EN-26:19.zfs, FreeBSD-EN-26:18.tzdata. Un aggiornamento dei dati dei fusi orari è l'esempio classico. I dati dei fusi orari obsoleti non possono essere sfruttati per attaccare il sistema, ma i timestamp restano errati finché non viene installata la correzione. Gli errata sono elencati nella pagina degli avvisi di errata di FreeBSD.

Entrambi i tipi di avviso sono firmati con la chiave PGP (pretty good privacy) del Security Officer e archiviati in security.FreeBSD.org. Entrambi vengono inoltre distribuiti al computer tramite freebsd-update.

Questo è il punto che spesso crea confusione agli amministratori Linux. Nessuno dei due tipi riguarda i pacchetti. La pagina sulla sicurezza lo dichiara esplicitamente: i problemi nella FreeBSD Ports Collection «sono trattati separatamente nel documento FreeBSD VuXML». Una vulnerabilità remota nel pacchetto nginx non riceverà mai un numero SA. Se monitorate soltanto il feed degli avvisi di sicurezza, non ne verrete mai a conoscenza.

Come ricevere informazioni su un aggiornamento di sicurezza di FreeBSD?

La lista a cui iscriversi è freebsd-security-notifications. È moderata e ha un volume ridotto di messaggi; distribuisce direttamente gli avvisi di sicurezza e le notifiche di errata. Iscriviti tramite lists.freebsd.org.

Anche freebsd-announce è moderata e distribuisce gli avvisi insieme agli annunci delle release, quindi è adatta se vuoi usare un'unica lista per tutto. freebsd-security è la lista di discussione. È utile da seguire, ma non è il canale da consultare per sapere che devi applicare una patch.

Tutte queste liste distribuiscono solo notizie sul sistema di base. Le vulnerabilità dei package non vengono mai comunicate via email. Per individuarle devi eseguire un comando.

pkg audit e il database alla base

VuXML, ovvero Vulnerabilities and Exposures Markup Language, è il registro del progetto FreeBSD relativo ai problemi di sicurezza presenti in ports e package. Ogni voce indica il package interessato, gli intervalli di versioni vulnerabili, gli identificativi CVE (common vulnerabilities and exposures) e una breve descrizione. L'intero insieme è consultabile nell'indice VuXML, ordinato per package, CVE o data.

pkg audit è lo strumento che lo legge:

pkg audit -F

-F scarica una copia aggiornata del database prima di eseguire il controllo. Usalo ogni volta. Senza -F, il confronto viene eseguito con la copia già presente sul computer, che può essere vecchia di mesi; quindi un risultato pulito non è significativo. Il comando confronta la versione di ogni package installato con tutte le voci VuXML, visualizza ogni corrispondenza con i relativi numeri CVE e un link alla pagina VuXML, quindi termina con una riga riepilogativa che indica quanti problemi sono stati trovati e in quanti package installati.

Vale la pena conoscere altri due flag di pkg-audit(8). pkg audit -r «visualizza anche i package che dipendono da package vulnerabili e che sono quindi potenzialmente vulnerabili a loro volta»: in questo modo puoi capire che una libreria vulnerabile è rilevante perché sei componenti installati la utilizzano tramite linking. pkg audit -R visualizza lo stesso risultato in JSON o in un altro formato elaborabile, da usare in un controllo di monitoraggio.

Il package pkg installa uno script periodico in /usr/local/etc/periodic/security/410.pkg-audit. Lo script viene eseguito nell'ambito del controllo di sicurezza giornaliero e invia il risultato via email a root. Verifica che sia attivo controllando che in /etc/periodic.conf sia presente una riga:

daily_status_security_pkgaudit_enable="YES"

Questa email giornaliera è l'equivalente più vicino che FreeBSD offre alla pratica degli aggiornamenti automatici su Ubuntu, e la differenza è il punto centrale: unattended-upgrades installa la correzione mentre dormi, mentre pkg audit si limita a segnalare che è necessaria una correzione. pkg audit genera report. Non applica patch. In un sistema FreeBSD standard, nessun componente installa un aggiornamento di sicurezza senza il tuo intervento.

Correggere un pacchetto vulnerabile

pkg update
pkg upgrade

Nei repository dei pacchetti FreeBSD non esiste un pocket dedicato esclusivamente agli aggiornamenti di sicurezza. Ubuntu può scaricare soltanto da noble-security e lasciare invariati tutti gli altri pacchetti. FreeBSD non offre un equivalente. Di conseguenza, correggere un singolo pacchetto vulnerabile significa installare la versione attualmente disponibile nel repository, insieme alle eventuali dipendenze aggiornate con essa. Pianifica l'aggiornamento dei pacchetti come una modifica, non come un'attività in background.

Il ramo del repository in uso determina la rapidità con cui ricevi una correzione. Il ramo predefinito è quello quarterly, che il manuale descrive come in grado di offrire «un'esperienza più prevedibile e stabile» perché accetta soltanto aggiornamenti non funzionali. Il ramo latest offre invece le versioni più recenti di tutti i pacchetti. Pertanto, quando pkg audit -F segnala che un pacchetto è vulnerabile e pkg upgrade indica che non c'è nulla da fare, la correzione non è ancora arrivata nel ramo in uso. Questo spiega il comportamento apparentemente contraddittorio.

Per spostare una macchina al ramo latest, copia il file del repository fornito con il sistema e modifica la copia:

mkdir -p /usr/local/etc/pkg/repos
cp /etc/pkg/FreeBSD.conf /usr/local/etc/pkg/repos/FreeBSD.conf

Sostituisci quarterly con latest nella riga url della copia, quindi esegui pkg update -f per scaricare il nuovo catalogo. Copia il file invece di digitare a memoria il nome del repository: il nome contenuto in /etc/pkg/FreeBSD.conf è quello effettivamente utilizzato dal sistema, mentre un file in /usr/local/etc/pkg/repos sovrascrive soltanto un repository con lo stesso nome esatto.

Applicazione delle patch del sistema di base

freebsd-update fetch
freebsd-update install

fetch scarica le patch per la release in uso e stampa l’elenco dei file che verranno modificati. Quando non c’è nulla da fare, stampa No updates needed to update system to 15.1-RELEASE-p3. e termina. Quando ci sono aggiornamenti da applicare, termina indicando di eseguire il comando di installazione. Non viene applicato nulla finché non si esegue freebsd-update install, quindi fetch può essere eseguito in qualsiasi momento senza rischi.

freebsd-update(8) fornisce aggiornamenti binari per le versioni ALPHA, BETA, RC e RELEASE, ma non per PRERELEASE, STABLE o CURRENT. Se si segue stable/15, il sistema viene compilato dai sorgenti e questo strumento non è utile.

Automatizzare il download e mantenere manuale l’installazione. La riga del manuale per /etc/crontab è:

@daily                                  root    freebsd-update cron

freebsd-update cron attende per un intervallo casuale compreso tra 1 e 3600 secondi, quindi scarica gli aggiornamenti esattamente come fa fetch e invia un messaggio a root quando sono disponibili aggiornamenti da installare. L’attesa casuale evita che tutte le macchine FreeBSD connesse a Internet contattino i mirror degli aggiornamenti nello stesso secondo.

L’output contiene due elementi che spesso creano confusione. src component not installed, skipped è normale su un server privo dell’albero dei sorgenti e non indica un errore. L’insieme dei componenti è controllato da una riga Components in /etc/freebsd-update.conf. I valori disponibili sono src, world e kernel.

Se l’installazione non va a buon fine, freebsd-update rollback disinstalla gli aggiornamenti installati più di recente. Su un sistema con root ZFS è possibile adottare una soluzione migliore e creare prima un boot environment:

bectl create pre-patch
freebsd-update fetch install

Se il sistema con le patch non si avvia, selezionare il boot environment precedente dal menu del loader per tornare allo stato iniziale. Questa possibilità di ripristino è uno dei motivi pratici per usare ZFS come filesystem root e richiede quasi nessuno spazio su disco finché i due environment non divergono.

La mia release di FreeBSD è ancora supportata?

Ogni release è supportata per un periodo definito, pubblicato in una tabella dei branch nella pagina dedicata alla sicurezza. Ad agosto 2026 la tabella è la seguente:

• releng/15.1, ovvero 15.1-RELEASE, fino al 31 marzo 2027
• releng/15.0, ovvero 15.0-RELEASE, fino al 30 settembre 2026
• releng/14.4, ovvero 14.4-RELEASE, fino al 31 dicembre 2026
• stable/15 fino al 31 dicembre 2029
• stable/14 fino al 30 novembre 2028

Le point release hanno periodi di supporto brevi. 15.0-RELEASE non sarà più supportata circa sette settimane dopo la pubblicazione di questo articolo, perché 15.1 è stata rilasciata e ha fatto partire il relativo periodo di scadenza. I branch stabili durano per anni e sono branch del codice sorgente che freebsd-update non distribuisce.

Controlla la tua versione con freebsd-version -u e confrontala con la tabella. Anche freebsd-update mostra un avviso. Quando la data si avvicina, fetch visualizza:

WARNING: FreeBSD 15.0-RELEASE is approaching its End-of-Life date.
It is strongly recommended that you upgrade to a newer
release within the next 2 months.

Dopo la scadenza, l'avviso diventa WARNING: FreeBSD 15.0-RELEASE HAS PASSED ITS END-OF-LIFE DATE. Una release non supportata continua a funzionare. Non riceve più gli avvisi di sicurezza, quindi la prossima vulnerabilità del sistema di base resterà a tuo carico in modo permanente.

Per passare a una release successiva, esegui freebsd-update -r 15.1-RELEASE upgrade, poi freebsd-update install, riavvia il sistema, quindi esegui di nuovo freebsd-update install, usa pkg-static upgrade -f per reinstallare ogni pacchetto con le nuove librerie e infine esegui freebsd-update install. Il manuale indica che le fasi di installazione possono essere soltanto due invece di tre, a seconda che siano stati modificati i numeri di versione di alcune librerie. Pianifica una finestra di manutenzione e leggi la guida alla configurazione di un server FreeBSD 15 prima di iniziare.

Riavvio o è sufficiente riavviare un servizio?

FreeBSD risponde con un solo confronto:

freebsd-version -k
uname -r

freebsd-version -k è il kernel sul disco. uname -r è il kernel in memoria. Se le stringhe sono diverse, è stato installato un nuovo kernel ma non è in esecuzione: riavviare il sistema. Se le stringhe corrispondono, la patch non ha modificato il kernel e il riavvio non serve.

Per una patch dello userland, riavviare tutto ciò che usa il codice modificato. Una correzione a OpenSSL di base in /usr/lib non produce alcun effetto su un sshd avviato tre settimane fa, che ha ancora la libreria precedente mappata nel proprio spazio di indirizzamento. Il file sul disco è nuovo. Il processo in esecuzione no.

service sshd restart

La stessa regola vale per i pacchetti. pkg upgrade sostituisce il binario sul disco, mentre il processo in esecuzione mantiene aperta la versione precedente; per questo service nginx restart è il passaggio che rende effettiva la correzione.

Il sistema di base non dispone di un equivalente di needrestart di Debian. Nessuno quindi chiede di eseguire il riavvio e non viene mantenuto alcun elenco. È necessario tenere traccia dei servizi che collegano ogni libreria modificata oppure riavviare il sistema dopo qualsiasi patch che interessi le librerie di base. Su un server la cui configurazione è gestita con il controllo versione, il riavvio è un'operazione ordinaria e costa molto meno che credere di avere installato una patch quando non è così.

Applicare le patch a una macchina che esegue jail

Un jail condivide il kernel dell’host. Di conseguenza, un advisory relativo al kernel riguarda l’host e si applica a ogni jail presente sulla macchina. Applicare la patch all’host e riavviare il sistema completa l’aggiornamento del kernel per tutti i jail. Lo userland all’interno di ogni jail è invece un’installazione separata, con un proprio livello di aggiornamento, e freebsd-version -j <jail> lo segnala dall’host. Anche i pacchetti all’interno di un jail sono separati; pkg -j <jail> audit -F li controlla senza accedere al jail. Questa distinzione tra kernel condiviso e userland separato è la stessa differenza strutturale che caratterizza il confronto tra jail e container Docker.

La traduzione per Ubuntu

Ogni abitudine di FreeBSD ha un equivalente, quindi puoi applicare la stessa procedura in entrambe le direzioni.

• Patch del sistema di base: prima freebsd-update fetch, poi freebsd-update install. Su Ubuntu, apt update && apt upgrade, che aggiorna contemporaneamente il sistema di base e tutto il resto.
• Software di terze parti: pkg update && pkg upgrade su FreeBSD. Su Ubuntu, di nuovo apt.
• Controllo delle vulnerabilità note: pkg audit -F su FreeBSD. Su Ubuntu 24.04, il comando più vicino è pro security-status, che mostra gli aggiornamenti di sicurezza per i pacchetti installati, inclusi quelli di Expanded Security Maintenance.
• Installazione automatica: su Ubuntu unattended-upgrades applica automaticamente gli aggiornamenti di sicurezza. FreeBSD non offre un equivalente integrato, quindi freebsd-update cron scarica e invia i risultati tramite email mentre l'installazione viene eseguita manualmente.
• Feed degli avvisi: freebsd-security-notifications contiene gli avvisi FreeBSD-SA e FreeBSD-EN. ubuntu-security-announce contiene gli Ubuntu Security Notices.
• Database delle vulnerabilità: VuXML per port e pacchetti FreeBSD. Per i pacchetti Ubuntu, il tracker CVE di Ubuntu.
• Controllo del riavvio: freebsd-version -k rispetto a uname -r su FreeBSD. Su Ubuntu, verifica la presenza di /var/run/reboot-required.
• Periodo di supporto: la tabella dei branch nella pagina sulla sicurezza di FreeBSD. Su Ubuntu, la pianificazione delle release e pro security-status.

La procedura di base è identica su entrambi i sistemi: iscriviti al feed, esegui l'audit secondo una pianificazione, quindi decidi cosa installare e quando riavviare. FreeBSD richiede semplicemente di gestire esplicitamente anche la seconda parte, perché non lo fa automaticamente. Il confronto più ampio tra Linux e FreeBSD come piattaforme server illustra gli altri aspetti che cambiano quando sposti un carico di lavoro da una piattaforma all'altra.

FAQ

freebsd-update applica patch anche ai miei pacchetti?

No. freebsd-update copre soltanto il sistema di base, cioè il kernel e lo userland distribuito con la release. Il software installato in /usr/local proviene dai pacchetti e viene aggiornato con pkg upgrade. Esegui pkg audit -F per individuare i pacchetti installati con vulnerabilità note, perché gli avvisi relativi al sistema di base non li menzionano e le mailing list di sicurezza non li annunciano.

Come posso sapere se un aggiornamento di FreeBSD richiede un riavvio?

Confronta freebsd-version -k con uname -r. Il primo mostra il kernel installato sul disco, incluso quello appena scritto ma non ancora avviato. Il secondo mostra il kernel in esecuzione. Stringhe diverse indicano che è necessario un riavvio. Stringhe identiche indicano che la patch riguardava soltanto lo userland; in questo caso riavvia invece i servizi interessati, ad esempio service sshd restart, perché un processo in esecuzione mantiene la vecchia libreria mappata finché non viene riavviato.

Qual è la differenza tra un Security Advisory e un Errata Notice?

Un Security Advisory, come FreeBSD-SA-26:55.elf, corregge una vulnerabilità di sicurezza nel sistema di base. Un Errata Notice, come FreeBSD-EN-26:18.tzdata, corregge un problema di correttezza o stabilità privo di impatto sulla sicurezza, ad esempio dati obsoleti sui fusi orari. Entrambi usano il formato anno, due punti, numero progressivo, componente. Entrambi sono firmati dal Security Officer e distribuiti tramite freebsd-update, e nessuno dei due riguarda il software installato dai ports o dai pacchetti.

Esiste un equivalente di unattended-upgrades per FreeBSD?

Non nel sistema di base. freebsd-update cron scarica le patch del sistema di base in attesa e invia un messaggio a root, ma non le installa mai. Lo script periodic che pkg installa viene eseguito ogni giorno da pkg audit e invia il risultato tramite posta elettronica; inoltre non aggiorna mai nulla. L'installazione automatica è quindi un meccanismo da creare autonomamente con un cron job. Poiché un aggiornamento dei pacchetti FreeBSD installa la versione più recente invece di applicare un backport limitato alle correzioni di sicurezza, la maggior parte degli amministratori legge il messaggio e installa gli aggiornamenti manualmente.

Come posso verificare che la mia release di FreeBSD sia ancora supportata?

Esegui freebsd-version -u per conoscere la versione dello userland, quindi confrontala con la tabella dei branch supportati nella pagina sulla sicurezza di FreeBSD. Le point release hanno periodi di supporto brevi: ad agosto 2026, 15.0-RELEASE termina il 30 settembre 2026, mentre 15.1-RELEASE è supportata fino al 31 marzo 2027. freebsd-update fetch avvisa quando la data si avvicina e, dopo tale data, stampa una riga che indica che la release HA SUPERATO LA DATA DI FINE SUPPORTO. Da quel momento gli avvisi successivi non si applicano più al tuo sistema.