Cómo actualizar FreeBSD y sus paquetes de seguridad

Cómo gestiona FreeBSD las actualizaciones de seguridad

FreeBSD gestiona las actualizaciones de seguridad con dos herramientas independientes, ya que un servidor FreeBSD se compone de dos elementos distintos. El sistema base, es decir, el kernel y el espacio de usuario que se distribuye con la versión, se parchea con freebsd-update. Todo lo que se instala posteriormente se considera un paquete, y los paquetes se parchean con pkg. Si ejecuta una herramienta y omite la otra, la mitad de la máquina permanecerá sin parches y el sistema no le notificará al respecto.

SSD Nodes no ofrece imágenes de FreeBSD. Nuestros planes utilizan Linux. Este artículo se incluye de todos modos porque el perfil de usuario es prácticamente idéntico: quienes administran nuestros servidores Ubuntu y Debian también utilizan FreeBSD en firewalls o en equipos heredados. El modelo de parcheo dividido es el punto que suele confundir a los administradores de Linux, por lo que merece la pena documentarlo. Cada comando, formato de aviso y fecha de soporte que aparece a continuación se verificó con la página de seguridad de FreeBSD y las páginas del manual del proyecto en agosto de 2026.

Una nota antes de los comandos. FreeBSD no instala sudo en el sistema base. Todo lo que se describe aquí requiere privilegios de root. Utilice su -, o instale primero sudo o doas desde los paquetes.

El sistema base y los paquetes son universos separados

En Ubuntu, apt es propietario de toda la máquina. El kernel, openssl, nginx y sus propias herramientas llegan como archivos .deb desde una única herramienta, y apt upgrade los mueve todos juntos.

FreeBSD divide esto en dos. El sistema base se construye como una unidad y se versiona como una unidad: 15.1-RELEASE-p3 es un número único que cubre el kernel, la biblioteca C, sshd y la copia de OpenSSL en /usr/lib. Nada de esto proviene de pkg. Todo lo demás reside bajo /usr/local, llega como un paquete binario construido desde el árbol de ports y tiene su propia versión.

Por lo tanto, un equipo puede contener dos copias de OpenSSL: la copia base en /usr/lib, parcheada solo por freebsd-update, y la copia del paquete en /usr/local/lib, parcheada solo por pkg. Cuál de ellas utiliza un programa depende de con cuál fue enlazado, y el software instalado desde paquetes generalmente enlaza la copia del paquete. Parchear una no afecta a la otra.

Tres comandos le indican su situación:

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

freebsd-version -u imprime el nivel de parche del espacio de usuario instalado. freebsd-version -k imprime el nivel de parche del kernel instalado, y freebsd-version(1) es explícito sobre por qué esto no es lo mismo que uname: "si se ha instalado un nuevo kernel pero el sistema aún no se ha reiniciado, freebsd-version imprimirá la versión y el nivel de parche del nuevo kernel". uname -r imprime el kernel que se está ejecutando en este momento. También existe freebsd-version -r, que imprime el kernel en ejecución pero "no se ve afectado por las variables de entorno", lo cual es importante dentro de una jail donde UNAME_r a menudo se establece en otro valor.

Avisos de seguridad y notas de erratas

El equipo de seguridad de FreeBSD publica dos tipos de avisos, los cuales tienen significados distintos.

Un Aviso de seguridad (Security Advisory) cubre una vulnerabilidad de seguridad en el sistema base. El identificador tiene el formato FreeBSD-SA-26:55.elf: las letras SA, el año de dos dígitos, un número correlativo dentro de ese año y el componente afectado. FreeBSD-SA-26:52.if_wg y FreeBSD-SA-26:50.kqueue fueron publicados el 2026-07-29. La lista completa se encuentra en la página de avisos de FreeBSD.

Una Nota de errata (Errata Notice) cubre un problema de corrección o estabilidad que merece ser incluido en una rama de lanzamiento, sin impacto en la seguridad. Tiene el mismo formato, pero con EN en lugar de SA: FreeBSD-EN-26:19.zfs, FreeBSD-EN-26:18.tzdata. Una actualización de datos de zona horaria es el ejemplo clásico. Nadie puede atacarle por tener datos de zona horaria obsoletos, pero sus marcas de tiempo serán incorrectas hasta que aplique la corrección. Las erratas se listan en la página de notas de erratas de FreeBSD.

Ambos tipos están firmados con la clave PGP (pretty good privacy) del responsable de seguridad y se archivan en security.FreeBSD.org; además, ambos se entregan en su máquina mediante freebsd-update.

Aquí es donde los administradores de Linux suelen confundirse. Ninguno de los dos tipos cubre paquetes. La página de seguridad lo indica claramente: los problemas en la FreeBSD Ports Collection "se tratan por separado en el documento VuXML de FreeBSD". Un agujero de seguridad remoto en el paquete nginx nunca recibirá un número de SA. Si el feed de avisos es lo único que supervisa, nunca se enterará de ello.

¿Cómo me entero de una actualización de seguridad de FreeBSD?

La lista a la que debe unirse es freebsd-security-notifications. Está moderada, tiene un volumen bajo y en ella se publican los avisos y las notas de erratas. Suscríbase en lists.freebsd.org.

freebsd-announce también está moderada y publica avisos junto con los anuncios de versiones, por lo que es útil si prefiere una sola lista para todo. freebsd-security es la lista de discusión. Es una lectura recomendable, pero no es el lugar donde se le notificará que debe aplicar un parche.

Todas estas listas contienen únicamente noticias sobre el sistema base. Las vulnerabilidades de los paquetes nunca se envían por correo electrónico. Para encontrarlas, debe ejecutar un comando.

pkg audit y la base de datos que lo sustenta

VuXML, el Vulnerabilities and Exposures Markup Language, es el registro del proyecto FreeBSD sobre problemas de seguridad en ports y paquetes. Cada entrada identifica el paquete afectado, los rangos de versiones vulnerables, los identificadores CVE (Common Vulnerabilities and Exposures) y una breve descripción. El conjunto completo puede consultarse en el índice de VuXML, ordenado por paquete, por CVE o por fecha.

pkg audit es la herramienta que lo lee:

pkg audit -F

-F descarga una copia actualizada de la base de datos antes de realizar la comprobación. Úselo siempre. Sin -F, usted está comparando contra cualquier copia que la máquina ya tenga, la cual puede estar desactualizada por meses, por lo que un resultado limpio no significa nada. El comando compara cada versión de paquete instalado contra cada entrada de VuXML, imprime cada coincidencia con sus números CVE y un enlace a la página de VuXML, y termina con una línea de conteo que indica cuántos problemas se encontraron en cuántos paquetes instalados.

Vale la pena conocer dos flags adicionales de pkg-audit(8). pkg audit -r también "imprime los paquetes que dependen de paquetes vulnerables y que, por tanto, son potencialmente vulnerables también", que es como usted descubre que una librería vulnerable es importante porque seis elementos instalados la enlazan. pkg audit -R imprime el mismo resultado en formato JSON u otro formato legible por máquina, que es lo que se utiliza para alimentar una comprobación de monitorización.

El paquete pkg instala un script periódico en /usr/local/etc/periodic/security/410.pkg-audit. Se ejecuta como parte de la comprobación de seguridad diaria y envía el resultado por correo al usuario root. Confirme que está activado con una línea en /etc/periodic.conf:

daily_status_security_pkgaudit_enable="YES"

Ese correo diario es lo más parecido que tiene FreeBSD a la costumbre de unattended-upgrades en Ubuntu, y la diferencia es precisamente el punto clave: unattended-upgrades instala la corrección mientras usted duerme, y pkg audit solo le informa de que se necesita una corrección. pkg audit informa. Nunca aplica parches. Nada en un sistema FreeBSD estándar instala una actualización de seguridad sin su intervención.

Corrección de un paquete vulnerable

pkg update
pkg upgrade

No existe un repositorio exclusivo de seguridad en los repositorios de paquetes de FreeBSD. Ubuntu puede obtener actualizaciones únicamente de noble-security y dejar el resto de los paquetes intactos. FreeBSD no tiene un equivalente, por lo que corregir un paquete vulnerable implica instalar la versión que el repositorio ofrece actualmente, junto con cualquier dependencia que se haya actualizado con él. Planifique la aplicación de parches en paquetes como un cambio programado, no como una tarea de fondo.

La rama del repositorio en la que se encuentre determina la rapidez con la que recibe una corrección. La rama predeterminada es la trimestral (quarterly), que el manual describe como una opción que ofrece "una experiencia más predecible y estable" al aceptar solo actualizaciones que no añaden funciones. La rama latest obtiene la versión más reciente de todo. Por lo tanto, cuando pkg audit -F informa que un paquete es vulnerable y pkg upgrade indica que no hay nada que hacer, la corrección aún no ha llegado a su rama, y ese es el mecanismo que causa la confusión.

Para cambiar una máquina a la rama latest, copie el archivo de repositorio que viene con el sistema y edite la copia:

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

Cambie quarterly por latest en la línea url de la copia y, a continuación, ejecute pkg update -f para descargar el nuevo catálogo. Copie el archivo en lugar de escribir el nombre del repositorio de memoria: el nombre dentro de /etc/pkg/FreeBSD.conf es el que su sistema utiliza realmente, y un archivo bajo /usr/local/etc/pkg/repos solo sobrescribe un repositorio cuyo nombre coincida exactamente.

Aplicación de parches al sistema base

freebsd-update fetch
freebsd-update install

fetch descarga los parches para su versión actual y muestra la lista de archivos que se modificarán. Cuando no hay tareas pendientes, imprime No updates needed to update system to 15.1-RELEASE-p3. y finaliza. Cuando hay cambios, indica al terminar que debe ejecutar el comando de instalación. No se aplica nada hasta que ejecute freebsd-update install, por lo que fetch es seguro de ejecutar en cualquier momento.

freebsd-update(8) proporciona actualizaciones binarias para versiones ALPHA, BETA, RC y RELEASE, pero no para PRERELEASE, STABLE o CURRENT. Si sigue stable/15, usted compila desde el código fuente y esta herramienta no le será de utilidad.

Automatice la descarga y mantenga la instalación manual. La línea del manual para /etc/crontab es:

@daily                                  root    freebsd-update cron

freebsd-update cron espera un tiempo aleatorio entre 1 y 3600 segundos, luego descarga las actualizaciones exactamente igual que fetch y envía un correo a root cuando hay algo pendiente. La espera aleatoria existe para que todas las máquinas FreeBSD en internet no accedan a los espejos de actualización en el mismo segundo.

Dos aspectos de la salida confunden a los usuarios. src component not installed, skipped es normal en un servidor sin árbol de fuentes y no es un error. El conjunto de componentes está controlado por una línea Components en /etc/freebsd-update.conf, y las opciones son src, world y kernel.

Si una instalación falla, freebsd-update rollback desinstala las actualizaciones instaladas más recientemente. En una raíz ZFS puede hacer algo mejor y crear un entorno de arranque primero:

bectl create pre-patch
freebsd-update fetch install

Si el sistema parcheado no arranca, seleccione el entorno de arranque antiguo desde el menú del cargador y volverá al estado inicial. Esa vía de escape es una de las razones prácticas para usar ZFS como sistema de archivos raíz, y casi no consume espacio en disco hasta que los dos entornos divergen.

¿Sigue teniendo soporte mi versión de FreeBSD?

Cada versión tiene soporte durante un periodo fijo, publicado como una tabla de ramas en la página de seguridad. A fecha de agosto de 2026, dicha tabla indica lo siguiente:

• releng/15.1, que es 15.1-RELEASE, hasta el 31 de marzo de 2027
• releng/15.0, que es 15.0-RELEASE, hasta el 30 de septiembre de 2026
• releng/14.4, que es 14.4-RELEASE, hasta el 31 de diciembre de 2026
• stable/15 hasta el 31 de diciembre de 2029
• stable/14 hasta el 30 de noviembre de 2028

Las versiones de mantenimiento (point releases) tienen periodos cortos. 15.0-RELEASE caduca unas siete semanas después de la publicación de este artículo, ya que 15.1 se lanzó y activó su cuenta atrás. Las ramas estables duran años y son ramas de código fuente que freebsd-update no sirve.

Compruebe su versión con freebsd-version -u y compárela con la tabla. freebsd-update también le avisará. Al acercarse la fecha, fetch muestra:

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.

Una vez pasada la fecha, el aviso cambia a WARNING: FreeBSD 15.0-RELEASE HAS PASSED ITS END-OF-LIFE DATE.. Una versión sin soporte sigue funcionando. Deja de recibir avisos de seguridad, lo que significa que la próxima vulnerabilidad del sistema base será responsabilidad suya de forma permanente.

Actualizar a una versión superior implica freebsd-update -r 15.1-RELEASE upgrade, después freebsd-update install, un reinicio, luego freebsd-update install por segunda vez, después pkg-static upgrade -f para reinstalar todos los paquetes frente a las nuevas librerías y, finalmente, freebsd-update install. El manual señala que puede haber solo dos fases de instalación en lugar de tres, dependiendo de si se han incrementado los números de versión de alguna librería. Reserve una ventana de mantenimiento y lea la guía de configuración de servidores FreeBSD 15 antes de empezar.

¿Reiniciar o basta con reiniciar el servicio?

FreeBSD responde a esto con una comparación:

freebsd-version -k
uname -r

freebsd-version -k es el kernel en el disco. uname -r es el kernel en memoria. Si las cadenas son distintas, significa que se ha instalado un kernel nuevo y no lo está ejecutando, por lo que debe reiniciar. Si las cadenas coinciden, el parche no afectó al kernel y reiniciar no aporta ninguna ventaja.

Para un parche de espacio de usuario, reinicie cualquier elemento que utilice el código parcheado. Una corrección en la versión base de OpenSSL en /usr/lib no tiene efecto en un sshd que se inició hace tres semanas y que aún mantiene la biblioteca antigua asignada en su espacio de direcciones. El archivo en el disco es nuevo. El proceso en ejecución no lo es.

service sshd restart

La misma regla se aplica a los paquetes. pkg upgrade reemplaza el binario en el disco mientras el proceso en ejecución mantiene el antiguo abierto, por lo que service nginx restart es el paso que hace efectiva la corrección.

El sistema base no tiene un equivalente al needrestart de Debian, por lo que nada le notificará ni mantendrá una lista. Debe realizar un seguimiento de qué servicios enlazan con qué biblioteca parcheada o reiniciar después de cualquier parche que afecte a las bibliotecas base. En un servidor con su configuración bajo control de versiones, un reinicio es una operación rutinaria y resulta mucho menos costoso que creer que está protegido cuando no lo está.

Actualización de una máquina que ejecuta jails

Una jail comparte el kernel del host, por lo que un aviso de seguridad del kernel es un problema del host y todas las jails en el equipo lo heredan. Actualice el host y reinicie; la parte del kernel quedará resuelta para todas ellas. El espacio de usuario (userland) dentro de cada jail es una instalación independiente con su propio nivel de parches, y freebsd-version -j <jail> lo reporta desde el host. Los paquetes dentro de una jail también son independientes, y pkg -j <jail> audit -F los audita sin necesidad de entrar en la jail. Esa división entre kernel compartido y espacio de usuario independiente es la misma diferencia estructural que define cómo se comparan las jails con los contenedores Docker.

La traducción a Ubuntu

Cada hábito de FreeBSD tiene su equivalente, por lo que puede trasladar la rutina en ambas direcciones.

• Parches del sistema base: freebsd-update fetch y luego freebsd-update install. En Ubuntu, apt update && apt upgrade, que cubre el sistema base y todo lo demás a la vez.
• Software de terceros: pkg update && pkg upgrade en FreeBSD. En Ubuntu, nuevamente apt.
• Comprobación de vulnerabilidades conocidas: pkg audit -F en FreeBSD. En Ubuntu 24.04 el comando más cercano es pro security-status, que muestra las actualizaciones de seguridad para los paquetes instalados, incluido el contenido de Expanded Security Maintenance.
• Instalación automática: unattended-upgrades en Ubuntu aplica las actualizaciones de seguridad por usted. FreeBSD no incluye nada equivalente, por lo que freebsd-update cron descarga y envía por correo las notificaciones mientras usted realiza la instalación manualmente.
• Fuente de avisos: freebsd-security-notifications contiene los elementos FreeBSD-SA y FreeBSD-EN. ubuntu-security-announce contiene los Ubuntu Security Notices.
• Base de datos de vulnerabilidades: VuXML para los ports y paquetes de FreeBSD. El rastreador de CVE de Ubuntu para los paquetes de Ubuntu.
• Comprobación de reinicio: freebsd-version -k frente a uname -r en FreeBSD. La presencia de /var/run/reboot-required en Ubuntu.
• Ventana de soporte: la tabla de ramas en la página de seguridad de FreeBSD. El calendario de lanzamientos y pro security-status en Ubuntu.

La rutina subyacente es idéntica en ambos sistemas: suscribirse a la fuente, ejecutar la auditoría según un calendario y luego decidir qué instalar y cuándo reiniciar. FreeBSD simplemente le obliga a realizar la segunda parte de forma explícita, ya que no lo hará por usted. La comparativa más amplia entre Linux y FreeBSD como plataforma de servidor cubre qué otros aspectos cambian al trasladar una carga de trabajo entre ambos.

FAQ

¿freebsd-update también parchea mis paquetes?

No. freebsd-update cubre únicamente el sistema base, es decir, el kernel y el espacio de usuario que se distribuyen con la versión. El software instalado bajo /usr/local proviene de paquetes y se parchea con pkg upgrade. Ejecute pkg audit -F para identificar qué paquetes instalados tienen vulnerabilidades conocidas, ya que los avisos del sistema base nunca los mencionan y las listas de correo de seguridad nunca los anuncian.

¿Cómo sé si una actualización de FreeBSD requiere un reinicio?

Compare freebsd-version -k con uname -r. El primero muestra el kernel instalado en el disco, incluyendo aquel que se acaba de escribir pero que aún no se ha iniciado. El segundo muestra el kernel que se está ejecutando actualmente. Si las cadenas son diferentes, debe reiniciar. Si las cadenas coinciden, el parche afectó solo al espacio de usuario; en ese caso, reinicie los servicios afectados, por ejemplo con service sshd restart, ya que un proceso en ejecución mantiene la biblioteca antigua cargada en memoria hasta que se reinicia.

¿Cuál es la diferencia entre un Security Advisory y un Errata Notice?

Un Security Advisory, como FreeBSD-SA-26:55.elf, corrige una vulnerabilidad de seguridad en el sistema base. Un Errata Notice, como FreeBSD-EN-26:18.tzdata, corrige un problema de corrección o estabilidad que no tiene impacto en la seguridad, como datos de zona horaria desactualizados. Ambos utilizan el patrón año, dos puntos, número de secuencia, componente. Ambos están firmados por el Security Officer y se distribuyen mediante freebsd-update, y ninguno de los dos cubre software instalado desde ports o paquetes.

¿Existe un equivalente a unattended-upgrades para FreeBSD?

No en el sistema base. freebsd-update cron descarga los parches pendientes del sistema base y envía un correo al usuario root, pero nunca los instala. El script periódico que instala pkg ejecuta pkg audit diariamente y envía el resultado por correo, pero tampoco actualiza nada. La instalación desatendida es algo que debe configurar usted mismo mediante un cron job; además, debido a que una actualización de paquetes en FreeBSD descarga la versión más reciente en lugar de un backport exclusivo de seguridad, la mayoría de los administradores leen el correo e instalan manualmente.

¿Cómo verifico si mi versión de FreeBSD sigue teniendo soporte?

Ejecute freebsd-version -u para conocer su versión del espacio de usuario y compárela con la tabla de ramas soportadas en la página de seguridad de FreeBSD. Las versiones puntuales tienen ventanas de soporte cortas: a fecha de agosto de 2026, 15.0-RELEASE finaliza el 30 de septiembre de 2026, mientras que 15.1-RELEASE tiene soporte hasta el 31 de marzo de 2027. freebsd-update fetch le advierte a medida que se acerca la fecha y, una vez superada, imprime una línea indicando que la versión HA SUPERADO SU FECHA DE FIN DE VIDA ÚTIL (END-OF-LIFE DATE). A partir de ese momento, no se le aplicará ningún aviso de seguridad adicional.