Aggiornamenti di sicurezza FreeBSD: guida a freebsd-update

Come gestisce gli aggiornamenti di sicurezza FreeBSD

FreeBSD gestisce gli aggiornamenti di sicurezza con due strumenti distinti, perché un server FreeBSD comprende due componenti 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 pacchetto e viene aggiornato con pkg. Se si esegue uno solo dei due strumenti, metà del sistema resta senza patch e il server non segnala il problema.

SSD Nodes non offre immagini FreeBSD. I nostri piani utilizzano Linux. Questo articolo è comunque utile perché il pubblico è lo stesso: le persone che gestiscono i nostri server Ubuntu e Debian usano anche FreeBSD su un firewall o sull'unico server che hanno ereditato. Il modello di aggiornamento separato è 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 a ottobre 2026.

Una nota prima dei comandi. FreeBSD non installa sudo nel sistema di base. Tutte le operazioni descritte richiedono root. Usate su - oppure installate prima sudo o doas dai pacchetti.

Il sistema di base e i pacchetti appartengono a universi separati

Su Ubuntu, apt gestisce l’intera macchina. Il kernel, openssl, nginx e gli strumenti installati dall’utente arrivano tutti come file .deb da un unico strumento, e apt upgrade li aggiorna tutti insieme.

FreeBSD separa questi componenti. In un’installazione classica, il sistema di base arriva come set di distribuzione e viene aggiornato soltanto da freebsd-update. freebsd-version -u indica un unico livello di patch per lo userland installato, ad esempio 15.1-RELEASE-p3, che comprende la libreria C, sshd e la copia di OpenSSL in /usr/lib. Il kernel ha un proprio livello di patch, indicato da freebsd-version -k, quindi i due numeri possono differire. Nessuno di questi componenti proviene da pkg. Tutto il resto si trova in /usr/local, arriva come pacchetto binario compilato dal ports tree e ha una propria versione.

Il programma di installazione della versione 15.x offre anche una seconda modalità. Il capitolo sull’installazione del manuale elenca i Distribution Sets, il metodo classico, insieme ai Packages (Tech Preview), spesso chiamati pkgbase. Questa modalità installa il sistema di base come un insieme di singoli pacchetti dal repository FreeBSD-base, in modo che pkg upgrade possa aggiornare insieme il sistema di base e il software di terze parti. Il manuale prevede che pkgbase diventi il metodo predefinito in FreeBSD 16.0 e raccomanda i Distribution Sets per un percorso di aggiornamento conservativo durante il ciclo di vita della versione 15.x, soprattutto in produzione. Il resto di questo articolo segue il modello Distribution Sets.

Un singolo sistema può quindi contenere due copie di OpenSSL: la copia del sistema di base in /usr/lib, aggiornata soltanto da freebsd-update, e la copia dei pacchetti in /usr/local/lib, aggiornata soltanto da pkg. La copia utilizzata da un programma dipende da quella con cui è stato collegato, e il software installato dai pacchetti normalmente si collega alla copia dei pacchetti. Aggiornare una copia non aggiorna 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 esplicitamente perché questo valore 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 un jail, dove UNAME_r è spesso impostata 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 che utilizza

VuXML, il Vulnerabilities and Exposures Markup Language, è il registro del progetto FreeBSD relativo ai problemi di sicurezza presenti nelle porte e nei pacchetti. Ogni voce indica il pacchetto 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 pacchetto, 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 potrebbe essere obsoleta anche di diversi mesi; quindi un risultato senza rilevamenti non è significativo. Il comando confronta la versione di ogni pacchetto installato con ogni voce VuXML, stampa ogni corrispondenza con i relativi numeri CVE e un collegamento alla pagina VuXML, quindi termina con una riga riepilogativa che indica quanti problemi sono stati rilevati e in quanti pacchetti installati.

Vale la pena conoscere altri due flag di pkg-audit(8). pkg audit -r stampa anche i «pacchetti che dipendono da pacchetti 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 collegano. pkg audit -R stampa lo stesso risultato in JSON o in un altro formato elaborabile, da usare in un controllo di monitoraggio.

Il pacchetto pkg installa uno script periodico in /usr/local/etc/periodic/security/410.pkg-audit. Lo script viene eseguito nell'ambito del controllo di sicurezza quotidiano e invia il risultato via email a root. Per impostazione predefinita, lo script è già attivo. Per impostarlo esplicitamente, aggiungi una riga a /etc/periodic.conf:

security_status_pkgaudit_enable="YES"

Questa email quotidiana è la soluzione più vicina disponibile in FreeBSD alla gestione degli aggiornamenti automatici senza supervisione di Ubuntu, e la differenza è fondamentale: unattended-upgrades installa la correzione mentre dormi, mentre pkg audit si limita a segnalare che è necessaria una correzione. pkg audit segnala. Non applica mai le patch. In un sistema FreeBSD standard, nessun componente installa un aggiornamento di sicurezza senza un 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 fisso, pubblicato in una tabella dei branch nella pagina sulla sicurezza. Al 25 October 2026, la tabella riporta:

• releng/15.1, ovvero 15.1-RELEASE, fino al 31 March 2027
• releng/14.5, ovvero 14.5-RELEASE, fino al 30 June 2027
• releng/14.4, ovvero 14.4-RELEASE, fino al 31 December 2026
• stable/15 fino al 31 December 2029
• stable/14 fino al 30 November 2028

Le point release hanno periodi di supporto brevi. 15.0-RELEASE non è più presente nella tabella. Ad August 2026 era indicata con termine il 30 September 2026, poco più di tre mesi dopo la pubblicazione di 15.1, avvenuta il 16 June 2026. 14.4-RELEASE sarà la prossima a uscire dal supporto, alla fine di December 2026. I branch stable durano per anni e sono branch del codice sorgente che freebsd-update non serve.

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

WARNING: FreeBSD 14.4-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 il superamento della data, l'avviso diventa WARNING: FreeBSD 14.4-RELEASE HAS PASSED ITS END-OF-LIFE DATE. Una release non supportata continua a funzionare. Smette però di ricevere gli avvisi di sicurezza. Questo significa che la prossima vulnerabilità del sistema base resterà a tuo carico in modo permanente.

Le istruzioni per l'upgrade di FreeBSD 15.1 avviano l'upgrade della release con freebsd-update fetch e freebsd-update install per applicare le patch in sospeso. Seguono freebsd-update upgrade -r 15.1-RELEASE, quindi freebsd-update install, poi il riavvio con il nuovo kernel e infine freebsd-update install per aggiornare nuovamente lo userland. A questo punto freebsd-update potrebbe chiederti di ricompilare o reinstallare il software di terze parti, perché le librerie di sistema sono cambiate. La pagina dell'upgrade indica di seguire queste istruzioni quando necessario. Per un salto di versione principale, ad esempio da 14.x a 15.1, la procedura generale dell'handbook usa pkg-static upgrade -f. Un ultimo freebsd-update install rimuove i file obsoleti del sistema base. L'handbook segnala che le fasi di installazione possono essere soltanto due invece di tre, a seconda che siano stati incrementati i numeri di versione delle librerie. Un sistema pkgbase segue una procedura pkg separata nella stessa pagina. Entrambi i percorsi terminano con l'aggiornamento del boot loader. 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

Un aggiornamento di FreeBSD applica patch anche ai miei pacchetti?

No. freebsd-update copre solo 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 sulla 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 solo 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à senza impatto sulla sicurezza, ad esempio dati dei fusi orari non aggiornati. 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 una mail a root, ma non le installa mai. Lo script periodic installato da pkg esegue pkg audit ogni giorno e invia il risultato tramite mail, ma non aggiorna nulla. L'installazione automatica dovrebbe essere implementata autonomamente con un cron job e, poiché un aggiornamento di un pacchetto FreeBSD installa la versione più recente anziché un backport limitato alla sicurezza, la maggior parte degli amministratori legge la mail ed esegue l'installazione 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: al 25 ottobre 2026, 14.4-RELEASE termina il 31 dicembre 2026, mentre 15.1-RELEASE è supportata fino al 31 marzo 2027; 15.0-RELEASE non è più presente nella tabella. freebsd-update fetch mostra un avviso quando la data si avvicina e, dopo tale data, stampa una riga che indica che la release HA SUPERATO LA DATA DI FINE VITA. Dopo quel momento, nessun ulteriore avviso di sicurezza si applica al sistema.