Como atualizar a segurança no FreeBSD

Como o FreeBSD gere as atualizações de segurança

O FreeBSD gere as atualizações de segurança com duas ferramentas diferentes, porque um servidor FreeBSD é composto por duas partes distintas. O sistema base, que inclui o kernel e o userland fornecido com a release, é atualizado com freebsd-update. Tudo o que instalar depois disso é um pacote, e os pacotes são atualizados com pkg. Se executar uma ferramenta e ignorar a outra, metade da máquina fica sem atualizações, e nada no sistema o informará.

A SSD Nodes não disponibiliza imagens FreeBSD. Os nossos planos executam Linux. Este artigo é apresentado mesmo assim porque o público é o mesmo: as pessoas que gerem os nossos servidores Ubuntu e Debian também executam FreeBSD numa firewall ou na única máquina que herdaram. O modelo de atualização dividido é a parte que costuma causar problemas a um administrador Linux, por isso é a parte que vale a pena documentar. Todos os comandos, formatos dos avisos de segurança e datas de suporte abaixo foram verificados na página de segurança do FreeBSD e nas páginas de manual do projeto em agosto de 2026.

Uma nota antes dos comandos. O FreeBSD não instala sudo no sistema base. Tudo o que é apresentado aqui requer root. Use su - ou instale primeiro sudo ou doas a partir dos pacotes.

O sistema base e os pacotes são universos separados

No Ubuntu, apt controla toda a máquina. O kernel, openssl, nginx e as suas próprias ferramentas chegam como ficheiros .deb provenientes de uma única ferramenta, e apt upgrade atualiza todos em conjunto.

O FreeBSD divide isso em duas partes. O sistema base é compilado como uma unidade e versionado como uma unidade: 15.1-RELEASE-p3 é um único número que abrange o kernel, a biblioteca C, sshd e a cópia do OpenSSL em /usr/lib. Nada disso vem de pkg. Todo o restante fica em /usr/local, chega como um pacote binário compilado a partir da árvore de ports e tem a sua própria versão.

Assim, uma máquina pode conter duas cópias do OpenSSL: a cópia base em /usr/lib, corrigida apenas por freebsd-update, e a cópia do pacote em /usr/local/lib, corrigida apenas por pkg. A cópia usada por um programa depende daquela contra a qual foi ligado, e o software instalado a partir de pacotes normalmente é ligado à cópia do pacote. Corrigir uma não altera a outra.

Três comandos mostram a situação atual:

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

freebsd-version -u mostra o nível de patch do userland instalado. freebsd-version -k mostra o nível de patch do kernel instalado, e freebsd-version(1) explica explicitamente por que isso não é igual a uname: "se um novo kernel tiver sido instalado, mas o sistema ainda não tiver sido reiniciado, freebsd-version mostrará a versão e o nível de patch do novo kernel". uname -r mostra o kernel em execução neste momento. Também existe freebsd-version -r, que mostra o kernel em execução, mas é "não afetado por variáveis de ambiente", o que é importante dentro de uma jail, onde UNAME_r costuma estar definido com outro valor.

Avisos de segurança e avisos de errata

A FreeBSD Security Team emite dois tipos de aviso, e eles têm significados diferentes.

Um Security Advisory trata de uma vulnerabilidade de segurança no sistema base. O identificador tem o formato FreeBSD-SA-26:55.elf: as letras SA, o ano com dois dígitos, um número sequencial desse ano e o componente afetado. FreeBSD-SA-26:52.if_wg e FreeBSD-SA-26:50.kqueue foram publicados em 2026-07-29. A lista completa está na página de avisos da FreeBSD.

Um Errata Notice trata de um problema de correção ou estabilidade que justifica ser incluído num ramo de release, mas que não tem impacto de segurança. O formato é o mesmo, com EN no lugar de SA: FreeBSD-EN-26:19.zfs, FreeBSD-EN-26:18.tzdata. Uma atualização dos dados de fuso horário é o exemplo clássico. Ninguém consegue atacar o sistema por causa de dados de fuso horário desatualizados, mas os timestamps ficam incorretos até instalar a correção. Os avisos de errata estão listados na página de avisos de errata da FreeBSD.

Ambos os tipos são assinados com a chave PGP (pretty good privacy) do Security Officer e arquivados em security.FreeBSD.org. Ambos são entregues à máquina por freebsd-update.

Este é o ponto que costuma surpreender administradores Linux. Nenhum dos dois tipos abrange packages. A página de segurança afirma isso claramente: os problemas na FreeBSD Ports Collection "são tratados separadamente no documento FreeBSD VuXML". Uma vulnerabilidade remota no package nginx nunca receberá um número SA. Se monitorar apenas o feed de avisos, nunca saberá que ela existe.

Como fico a saber de uma atualização de segurança do FreeBSD?

A lista a subscrever é freebsd-security-notifications. É moderada e tem pouco tráfego. Envia os próprios avisos de segurança e as notificações de errata. Subscreva em lists.freebsd.org.

A freebsd-announce também é moderada e envia avisos juntamente com anúncios de versões. É uma opção adequada se quiser uma única lista para tudo. A freebsd-security é a lista de discussão. É útil para acompanhar as discussões, mas não é o local onde deve saber que precisa de instalar uma correção.

Todas estas listas enviam apenas notícias sobre o sistema base. As vulnerabilidades dos pacotes nunca são enviadas por correio eletrónico. Para as encontrar, execute um comando.

pkg audit e o banco de dados por trás dele

VuXML, a Vulnerabilities and Exposures Markup Language, é o registo do projeto FreeBSD sobre problemas de segurança em ports e packages. Cada entrada identifica o package afetado, os intervalos de versões vulneráveis, os identificadores CVE (common vulnerabilities and exposures) e uma breve descrição. Todo o conjunto pode ser consultado no índice VuXML, ordenado por package, por CVE ou por data.

pkg audit é a ferramenta que o lê:

pkg audit -F

-F obtém uma cópia atualizada do banco de dados antes da verificação. Use-o sempre. Sem -F, a comparação usa a cópia que a máquina já tem, que pode estar desatualizada há meses. Por isso, um resultado limpo não significa nada. O comando compara a versão de cada package instalado com cada entrada do VuXML, mostra cada correspondência com os respetivos números CVE e um link para a página VuXML. No fim, apresenta uma linha com a contagem dos problemas encontrados e dos packages instalados afetados.

Vale a pena conhecer mais duas flags de pkg-audit(8). pkg audit -r também «mostra os packages que dependem de packages vulneráveis e que, por isso, também podem estar vulneráveis». É assim que se identifica que uma biblioteca vulnerável é relevante porque seis componentes instalados fazem link para ela. pkg audit -R mostra o mesmo resultado em JSON ou noutro formato adequado para máquinas. É esse formato que se fornece a uma verificação de monitorização.

O package pkg instala um script periódico em /usr/local/etc/periodic/security/410.pkg-audit. O script é executado como parte da verificação diária de segurança e envia o resultado por e-mail para root. Confirme que está ativo com uma linha em /etc/periodic.conf:

daily_status_security_pkgaudit_enable="YES"

Esse e-mail diário é o equivalente mais próximo no FreeBSD do mecanismo de unattended-upgrades do Ubuntu. A diferença é precisamente o ponto principal: unattended-upgrades instala a correção enquanto você dorme, mas pkg audit apenas informa que é necessária uma correção. pkg audit gera relatórios. Nunca aplica correções. Num sistema FreeBSD padrão, nada instala uma atualização de segurança sem a sua intervenção.

Corrigir um pacote vulnerável

pkg update
pkg upgrade

Não existe um repositório apenas para atualizações de segurança nos repositórios de pacotes do FreeBSD. O Ubuntu pode obter pacotes apenas de noble-security e manter todos os outros pacotes como estão. O FreeBSD não tem um equivalente. Por isso, corrigir um pacote vulnerável significa instalar a versão atualmente disponibilizada pelo repositório, juntamente com quaisquer dependências que tenham sido atualizadas. Planeie a atualização de pacotes como uma alteração, não como uma tarefa em segundo plano.

A branch do repositório que está a utilizar determina a rapidez com que uma correção chega ao sistema. A predefinição é a branch trimestral, que o manual descreve como proporcionando "uma experiência mais previsível e estável" por aceitar apenas atualizações que não introduzem funcionalidades. A branch latest utiliza a versão mais recente de tudo. Por isso, quando pkg audit -F indica que um pacote está vulnerável e pkg upgrade indica que não há nada a fazer, a correção ainda não chegou à sua branch. Esse é o motivo da confusão.

Para mover uma máquina para a branch latest, copie o ficheiro do repositório fornecido com o sistema e edite a cópia:

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

Altere quarterly para latest na linha url da cópia e execute pkg update -f para obter o novo catálogo. Copie o ficheiro em vez de escrever o nome do repositório de memória: o nome dentro de /etc/pkg/FreeBSD.conf é o que o sistema realmente utiliza, e um ficheiro em /usr/local/etc/pkg/repos apenas substitui um repositório cujo nome corresponda exatamente.

Aplicar patches do sistema base

freebsd-update fetch
freebsd-update install

fetch transfere patches para a sua release atual e apresenta a lista de ficheiros que serão alterados. Quando não há nada a fazer, apresenta No updates needed to update system to 15.1-RELEASE-p3. e termina. Quando há alterações pendentes, termina indicando que deve executar o comando de instalação. Nada é aplicado até executar freebsd-update install, por isso fetch é seguro executar a qualquer momento.

freebsd-update(8) fornece atualizações binárias para as versões ALPHA, BETA, RC e RELEASE, mas não para PRERELEASE, STABLE ou CURRENT. Se acompanhar stable/15, compila a partir do código-fonte, e esta ferramenta não tem nada para si.

Automatize a transferência e mantenha a instalação manual. A linha do handbook para /etc/crontab:

@daily                                  root    freebsd-update cron

freebsd-update cron aguarda um período aleatório entre 1 e 3600 segundos. Depois, transfere as atualizações exatamente como fetch e envia uma mensagem para root quando existem atualizações pendentes. A espera aleatória evita que todas as máquinas FreeBSD na Internet acedam aos mirrors de atualizações no mesmo segundo.

Há dois aspetos do resultado que confundem as pessoas. src component not installed, skipped é normal num servidor sem árvore de código-fonte e não é um erro. O conjunto de componentes é controlado por uma linha Components em /etc/freebsd-update.conf, e as opções são src, world e kernel.

Se uma instalação correr mal, freebsd-update rollback desinstala as atualizações instaladas mais recentemente. Num root ZFS, pode fazer melhor e criar primeiro um ambiente de arranque:

bectl create pre-patch
freebsd-update fetch install

Se o sistema com os patches não arrancar, selecione o ambiente de arranque antigo no menu do loader e regressará ao estado anterior. Esta possibilidade de recuperação é uma das razões práticas para usar ZFS como sistema de ficheiros root, e quase não ocupa espaço em disco até os dois ambientes divergirem.

A minha versão do FreeBSD ainda tem suporte?

Cada versão tem suporte durante um período fixo, publicado como uma tabela de branches na página de segurança. Em agosto de 2026, essa tabela indica:

• releng/15.1, que corresponde a 15.1-RELEASE, até 31 March 2027
• releng/15.0, que corresponde a 15.0-RELEASE, até 30 September 2026
• releng/14.4, que corresponde a 14.4-RELEASE, até 31 December 2026
• stable/15 até 31 December 2029
• stable/14 até 30 November 2028

As point releases têm períodos de suporte curtos. 15.0-RELEASE termina cerca de sete semanas depois da publicação deste texto, porque 15.1 foi lançada e iniciou a contagem desse prazo. Os stable branches duram anos e são branches de código-fonte que freebsd-update não disponibiliza.

Verifique a sua versão com freebsd-version -u e compare-a com a tabela. freebsd-update também emite um aviso. Quando a data se aproxima, fetch apresenta:

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.

Depois de a data passar, o aviso torna-se WARNING: FreeBSD 15.0-RELEASE HAS PASSED ITS END-OF-LIFE DATE. Uma versão sem suporte continua a funcionar. Deixa de receber avisos de segurança, o que significa que a próxima vulnerabilidade no sistema base ficará permanentemente sob a sua responsabilidade.

A atualização para uma versão mais recente consiste em freebsd-update -r 15.1-RELEASE upgrade, depois freebsd-update install, depois reiniciar o sistema, depois freebsd-update install uma segunda vez, depois pkg-static upgrade -f para reinstalar todos os pacotes com as novas bibliotecas, e finalmente freebsd-update install. O handbook indica que pode haver apenas duas fases de instalação em vez de três, dependendo de terem sido alterados os números de versão de alguma biblioteca. Agende uma janela de manutenção e leia o guia de configuração de servidores FreeBSD 15 antes de começar.

Reiniciar ou basta reiniciar um serviço?

O FreeBSD responde a isto com uma comparação:

freebsd-version -k
uname -r

freebsd-version -k é o kernel no disco. uname -r é o kernel na memória. Strings diferentes significam que foi instalado um kernel novo, mas que ele ainda não está em execução; nesse caso, reinicie o sistema. Strings iguais significam que o patch não alterou o kernel e que um reboot não traz qualquer benefício.

Para um patch de userland, reinicie o que utiliza o código corrigido. Uma correção no OpenSSL base em /usr/lib não tem efeito num sshd iniciado há três semanas e que ainda tem a biblioteca antiga mapeada no seu espaço de endereçamento. O ficheiro no disco é novo. O processo em execução não é.

service sshd restart

A mesma regra aplica-se aos pacotes. pkg upgrade substitui o binário no disco enquanto o processo em execução mantém o binário antigo aberto; por isso, service nginx restart é o passo que torna a correção efetiva.

O sistema base não tem um equivalente ao needrestart do Debian. Por isso, nada lhe pede para reiniciar e não existe uma lista mantida automaticamente. Controle quais serviços estão ligados a cada biblioteca corrigida ou reinicie o sistema depois de qualquer patch que altere bibliotecas base. Num servidor cuja configuração está sob controlo de versões, um reboot é uma operação de rotina e custa muito menos do que acreditar que o sistema está corrigido quando não está.

Aplicar patches numa máquina que executa jails

Uma jail partilha o kernel do host. Por isso, um aviso de segurança do kernel é um problema do host, e todas as jails do sistema ficam expostas a ele. Aplique o patch no host e reinicie-o. A parte relacionada com o kernel fica então resolvida para todas as jails. O userland dentro de cada jail é uma instalação separada, com o seu próprio nível de patches, e freebsd-version -j <jail> apresenta essa informação a partir do host. Os pacotes dentro de uma jail também são separados, e pkg -j <jail> audit -F faz a auditoria sem entrar na jail. Esta separação entre um kernel partilhado e um userland independente é a mesma diferença estrutural que define a comparação entre jails e contentores Docker.

A tradução para Ubuntu

Cada hábito do FreeBSD tem um equivalente, por isso pode aplicar a mesma rotina em qualquer uma das direções.

• Correções do sistema base: freebsd-update fetch e depois freebsd-update install. No Ubuntu, apt update && apt upgrade, que atualiza o sistema base e todos os restantes componentes de uma só vez.
• Software de terceiros: pkg update && pkg upgrade no FreeBSD. No Ubuntu, use novamente apt.
• Verificação de vulnerabilidades conhecidas: pkg audit -F no FreeBSD. No Ubuntu 24.04, o comando mais próximo é pro security-status, que mostra as atualizações de segurança dos pacotes instalados, incluindo o conteúdo do Expanded Security Maintenance.
• Instalação automática: unattended-upgrades no Ubuntu aplica as atualizações de segurança automaticamente. O FreeBSD não inclui nada equivalente, por isso freebsd-update cron transfere os dados e envia-os por e-mail enquanto a instalação é feita manualmente.
• Feed de avisos: freebsd-security-notifications contém itens FreeBSD-SA e FreeBSD-EN. ubuntu-security-announce contém Ubuntu Security Notices.
• Base de dados de vulnerabilidades: VuXML para ports e pacotes do FreeBSD. O Ubuntu CVE tracker para pacotes do Ubuntu.
• Verificação da necessidade de reboot: freebsd-version -k em comparação com uname -r no FreeBSD. No Ubuntu, verifique a presença de /var/run/reboot-required.
• Período de suporte: a tabela de branches na página de segurança do FreeBSD. No Ubuntu, o calendário de releases e pro security-status.

A rotina subjacente é idêntica nos dois sistemas: subscreva o feed, execute a auditoria segundo um calendário e decida o que instalar e quando reiniciar. No FreeBSD, é necessário executar explicitamente a segunda parte, porque o sistema não a faz por si. A comparação mais ampla entre Linux e FreeBSD como plataforma de servidor explica o que mais muda quando move uma carga de trabalho entre os dois sistemas.

FAQ

O freebsd-update também corrige os meus pacotes?

Não. freebsd-update abrange apenas o sistema base, ou seja, o kernel e o userland disponibilizados com a release. O software instalado em /usr/local vem de pacotes e é corrigido com pkg upgrade. Execute pkg audit -F para identificar os pacotes instalados que têm vulnerabilidades conhecidas, porque os avisos do sistema base nunca os mencionam e as listas de correio de segurança nunca os anunciam.

Como sei se uma atualização do FreeBSD exige um reboot?

Compare freebsd-version -k com uname -r. O primeiro mostra o kernel instalado no disco, incluindo um kernel que acabou de ser gravado, mas ainda não foi iniciado. O segundo mostra o kernel em execução. Strings diferentes significam que é necessário fazer um reboot. Strings iguais significam que o patch foi apenas no userland; nesse caso, reinicie os serviços afetados, por exemplo service sshd restart, porque um processo em execução mantém a biblioteca antiga mapeada até ser reiniciado.

Qual é a diferença entre um Security Advisory e um Errata Notice?

Um Security Advisory, como FreeBSD-SA-26:55.elf, corrige uma vulnerabilidade de segurança no sistema base. Um Errata Notice, como FreeBSD-EN-26:18.tzdata, corrige um problema de correção ou estabilidade sem impacto na segurança, como dados de fuso horário desatualizados. Ambos usam o padrão ano, dois-pontos, número de sequência, componente. Ambos são assinados pelo Security Officer e entregues por freebsd-update, e nenhum dos dois abrange software instalado a partir de ports ou pacotes.

Existe um equivalente ao unattended-upgrades para o FreeBSD?

Não no sistema base. freebsd-update cron transfere os patches pendentes do sistema base e envia um email para root, mas nunca os instala. O script periódico que pkg instala é executado por pkg audit diariamente e envia o resultado por email; também nunca atualiza nada. A instalação unattended é algo que teria de criar com um cron job. Como uma atualização de pacote do FreeBSD instala a versão mais recente, em vez de um backport apenas de segurança, a maioria dos administradores lê o email e instala as atualizações manualmente.

Como verifico se a minha release do FreeBSD ainda é suportada?

Execute freebsd-version -u para obter a versão do seu userland e compare-a com a tabela de branches suportadas na página de segurança do FreeBSD. As point releases têm períodos de suporte curtos: em agosto de 2026, 15.0-RELEASE termina em 30 September 2026, enquanto 15.1-RELEASE é suportada até 31 March 2027. freebsd-update fetch avisa quando a data se aproxima. Depois de a data passar, apresenta uma linha a indicar que a release HAS PASSED ITS END-OF-LIFE DATE. A partir desse momento, nenhum aviso adicional se aplica ao seu sistema.