17 de julio de 2026 · Fortinet · Perimeter · Schwachstellenmanagement · IT-Sicherheit

Cuando el firewall se parchea solo: upgrades de FortiOS

FortiOS se actualiza automáticamente y, en ciertos casos, incluso de forma forzada. Qué desencadena los upgrades, qué excepciones rigen y cómo contrarrestarlo.

Un firewall se reinicia de noche, por la mañana funciona con otra versión de firmware y nadie del equipo ha instalado una actualización. En los sistemas FortiGate, este es un comportamiento documentado. En el blog técnico de boll apareció el 17 de julio de 2026, con el título «Your FortiGate Updated Itself – But You Don’t Know Why?», un resumen de cómo se llega a ello. Hemos contrastado sus afirmaciones con la documentación del fabricante.

En resumen: hay dos mecanismos. Uno puede desactivarlo; el otro, no.

Mecanismo 1: el upgrade automático de parches

Desde FortiOS 7.2.1 puede configurarse que una FortiGate instale por sí misma las nuevas versiones de parche. Antes de 7.4.5, la función solo estaba activa de fábrica en los modelos de gama de entrada. Con FortiOS 7.4.5, Fortinet lo cambió: según la documentación del fabricante, a partir de esa versión los upgrades automáticos de firmware están activados por defecto «en todos los modelos FortiGate, incluidas las FortiGate-VM» («on all FortiGate models, including FortiGate VMs»). Quien abre por primera vez la interfaz web tras la actualización a 7.4.5 tiene que confirmarlo con «I acknowledge», un clic que en el día a día pasa fácilmente desapercibido.

Importante para situarlo: la función solo actualiza dentro de la rama de versión en curso. De 7.4.x se pasa a un 7.4.x más reciente, nunca a un 7.6.x. Se trata, por tanto, de parches, no de saltos de versión.

El comportamiento puede controlarse en la interfaz, en «System > Firmware & Registration», o por CLI, en config system fortiguard. Allí se establece si la función está activa, en qué días de la semana puede instalarse o cuántos días se espera tras la publicación de un parche (por defecto, según la documentación: tres días), y en qué franja horaria ocurre. Por defecto es de 2 a 4 h, hora local; el momento exacto se elige al azar dentro de la franja. Tras la instalación se envía un correo electrónico a la cuenta de FortiCloud en la que está registrado el equipo, no necesariamente a la persona que hoy es responsable del firewall.

Mecanismo 2: el upgrade forzado

El segundo mecanismo es el verdadero motivo del artículo de boll. Fortinet lo denomina «Required firmware upgrade»; boll habla de «Forced Upgrade». Se activa cuando se cumple una de dos condiciones:

  • La licencia de firmware no es válida. Fortinet habla de una licencia «Firmware & General Updates (FMWR)» no válida; boll, de forma más general, de la falta de un contrato FortiCare válido.
  • La rama de versión ha alcanzado su End of Engineering Support (EOES). Los equipos funcionan, por tanto, con una versión menor para la que el fabricante ya no realiza desarrollo.

En estos casos, la FortiGate comprueba a diario si hay un parche más reciente en su propia rama de versión y programa ella misma la instalación. También aquí se queda en un parche dentro de la versión menor; si la ruta de upgrade pasa por versiones intermedias, estas se recorren por orden.

En cuanto a desde cuándo rige esto, las fuentes no coinciden del todo. boll y la página «New Features» de Fortinet sobre FortiOS 8.0 mencionan 7.4.8 y 7.6.4; la guía de administración 8.0 menciona 7.4.9 y 7.6.4. FortiOS 8.0.0 está afectado en cualquier caso. Quien esté en 7.4.8 o 7.6.4, o en versiones posteriores, debería contar con el mecanismo.

La diferencia decisiva con el upgrade automático: un upgrade forzado no puede cancelarse una vez programado. La interfaz atenúa en gris el botón de cancelar, y la consola indica, en esencia, que el upgrade es forzado y no puede anularse. Solo es posible un aplazamiento con execute auto-upgrade delay-installation. boll lo cifra en siete días. La guía de administración de FortiOS 8.0 confirma el aplazamiento fijo de siete días y añade dos detalles: el comando puede repetirse tantas veces como se quiera, pero no el día en que está programada la instalación.

El estado actual lo muestra execute auto-upgrade status. Allí figuran, entre otros datos, el estado del contrato, si la imagen en ejecución ha llegado al final de su vida útil y –cuando llega el momento– la anotación «Enabled (Forced)» junto con la franja horaria programada.

Las excepciones, y por qué no todas protegen

boll menciona tres configuraciones en las que el upgrade forzado no se aplica. La documentación del fabricante las confirma, pero las describe con más precisión, y los detalles cambian la afirmación:

  • Gestión mediante FortiManager. Una FortiGate conectada a FortiManager no se actualiza a sí misma. Si se conecta a FortiManager cuando ya hay un upgrade forzado programado, este se cancela.
  • Miembro de una Security Fabric. Tampoco aquí tiene lugar un upgrade automático. A la inversa: si ya hay un upgrade forzado programado, el equipo no puede unirse a ninguna Fabric.
  • Miembro secundario de un clúster HA. Es la excepción que con más facilidad se malinterpreta. El equipo secundario no inicia un upgrade propio, pero recibe el nuevo firmware a través de un upgrade del clúster que inicia el equipo primario. El clúster en su conjunto se actualiza, por tanto.

Una cuarta excepción figura solo en la documentación del fabricante: en los builds especiales («special builds») no se aplica el upgrade forzado.

Ganancia de seguridad frente a control de cambios

El fabricante justifica el mecanismo con la protección de los equipos, y el argumento se sostiene: un firewall sin contrato de firmware o en una rama de versión sin desarrollo es un sistema perimetral que ya no recibe correcciones.

Para la operación, sin embargo, es una intervención en el control de cambios. Un cambio de firmware implica un reinicio y, en un equipo individual, por tanto, una caída de las conexiones. Puede cambiar comportamientos de los que dependen los conjuntos de reglas, los extremos remotos de VPN o los sistemas conectados. Y ocurre en un momento que no ha fijado su proceso de cambios, sino el propio equipo.

La buena noticia: ambos desencadenantes son previsibles. El vencimiento de una licencia y una fecha de EOES se conocen con mucha antelación.

Lo que debería hacer ahora

  • Levantar el estado actual. Compruebe en cada equipo con execute auto-upgrade status si el upgrade automático está activo y si ya se ha programado uno forzado.
  • Llevar al inventario las vigencias de contratos y las fechas de EOES. La fecha de vencimiento de la licencia de firmware y el fin de soporte de la rama de versión deben figurar como campos en el registro de activos, con responsable y antelación, no en la memoria de empleados concretos.
  • Vincular la franja horaria a su ventana de mantenimiento. Establezca los días de la semana y la franja horaria de forma que un upgrade automático caiga en una ventana de mantenimiento anunciada, y documente el ajuste.
  • Probar primero los parches en el laboratorio. Un equipo de pruebas o una instancia virtual en la misma rama de versión muestra, antes que el equipo productivo, si un parche afecta al conjunto de reglas, a la VPN o a la autenticación.
  • Dirigir la notificación al lugar correcto. Los correos van a la cuenta de FortiCloud registrada. Compruebe si alguien sigue leyendo hoy ese buzón.
  • Saber qué excepción le aplica. Quien gestiona mediante FortiManager está exento del upgrade forzado y, por eso mismo, tiene que llevar activamente él mismo el nivel de parches. Quien opera un clúster HA no está exento.
  • Entender el aplazamiento como herramienta, no como solución. Siete días dan tiempo para terminar una prueba o acordar una ventana. No sustituyen ni al contrato ni a la migración a una rama de versión con soporte.

Cómo apoya sector7

En el marco de nuestros servicios gestionados operamos firewalls y VPN con gestión de parches, de configuración y de cambios, y actualizamos los sistemas de forma planificada y documentada en lugar de ad hoc; anunciamos las ventanas de mantenimiento y las situamos fuera del horario laboral. Más información en Servicios gestionados y soporte y Ciberseguridad.

Fuentes

Hablemos de su situación.

Concertar una conversación+49 212 240915 0