Sophos Firewall v22 MR2: ¿actualización o nuevo riesgo?

Sophos Firewall v22 MR2 ya está aquí. La compilación 546 se publicó el 14 de julio de 2026 y aporta una combinación manejable, pero bastante razonable, de funciones de seguridad, cambios de autenticación, ajustes de certificados y más de 50 correcciones de errores.

Sobre el papel es una versión de mantenimiento clásica. En la práctica, sin embargo, contiene precisamente esa mezcla que ya me obliga a mirar dos veces cuando se trata de Sophos: nueva lógica de detección en el IPS, cambios en la asignación de usuarios, nuevas cadenas de certificados y, al mismo tiempo, una larga lista de fallos del kernel, problemas de HA, estados failsafe, errores de VPN e interrupciones en los informes.

Esto no es exclusivamente positivo. Que una versión de mantenimiento corrija más de 50 errores demuestra, por una parte, que Sophos está haciendo limpieza. Por otra, también muestra cuántos problemas graves seguían presentes en GA y MR1. Ya critiqué precisamente esta calidad del firmware en Sophos Firewall: sin CVE, pero con errores (de v21.5 a v22).

Voy a instalar MR2 inmediatamente en uno de mis Sophos Firewall. No porque confíe ciegamente en la versión desde el primer día, sino porque quiero comprobar si la compilación 546 por fin estabiliza la línea v22 o si vuelven a aparecer más errores nuevos de los que corrige la actualización. Me interesan especialmente HA, el registro, IPsec, el tiempo de respuesta de WebAdmin, STAS y la estabilidad después de las actualizaciones de patrones.

Al mismo tiempo, Sophos crea un contraste extraño con esta versión. Config Studio 2.6 ocupa ya mucho espacio en las actualizaciones oficiales del firewall. La herramienta externa para el navegador recibe fusión de plantillas, una búsqueda mejorada, comparaciones de varios archivos, análisis de migración y datos de compatibilidad de hardware. En cambio, en la interfaz del propio firewall no vuelve a haber prácticamente ningún cambio visible para la administración diaria.

Por eso considero que MR2 es importante desde el punto de vista técnico, pero decepcionante desde el estratégico. El motor de seguridad recibe nuevas funciones, mientras los flujos de trabajo modernos para administradores vuelven a desplazarse a Config Studio.

Lo más importante en pocas palabras

SFOS 22.0 MR2 lleva el número de compilación 546 y sucede a MR1 Build 490. Sophos destaca esencialmente siete áreas en esta versión:

• detección y control de criptografía poscuántica
• mejor categorización de aplicaciones de IA generativa
• una nueva extensión Chromebook User ID con Manifest V3
• un comportamiento predeterminado modificado para STAS
• el anuncio anticipado del fin de soporte de Novell eDirectory en SFOS 23.0
• nuevas cadenas de confianza de Let’s Encrypt y mejores notificaciones por correo electrónico
• Config Studio 2.6 con nuevas funciones de análisis, migración y comparación

A ello se suman más de 50 problemas corregidos. Desde el punto de vista operativo, algunas de estas correcciones son más importantes que las funciones nuevas, porque incluyen fallos del kernel, problemas de HA, estados failsafe, errores de VPN y problemas de rendimiento en los informes.

Mi valoración resumida:

• Quien ya utilice v22 GA o MR1 y esté afectado por uno de los errores enumerados tiene un motivo concreto para instalar MR2.
• Quien tenga una instalación 21.5 estable no debería actualizar precipitadamente solo por PQC o Config Studio.
• Las firmas PQC deben empezar en un modo exclusivamente de observación, no directamente con Drop.
• Los entornos STAS deben comprobar después de la actualización cómo se trata el tráfico no autenticado durante el Identity Probe.
• Las instalaciones con HA, IPsec, WAF, correo e informes necesitan pruebas funcionales reales, no una mirada rápida a indicadores verdes.
• Config Studio 2.6 es técnicamente útil, pero no demuestra que la interfaz WebAdmin de SFOS sea más moderna. Más bien al contrario.

El límite de hardware sigue siendo importante: SFOS 22.0 ya no admite appliances de hardware XG ni SG. La versión está destinada a XGS, instalaciones virtuales, de software y en nubes compatibles. Quien todavía opere hardware XG no puede planificar MR2 como el siguiente paso normal de firmware.

Detectar y controlar la criptografía poscuántica

La novedad técnicamente más interesante es el control de la criptografía poscuántica, o PQC. Esto no significa que Sophos Firewall repela de pronto ordenadores cuánticos. La función afecta a métodos modernos de intercambio criptográfico de claves concebidos para ser más resistentes frente a futuros ataques con ordenadores cuánticos potentes.

MR2 se centra en ML-KEM. El procedimiento fue estandarizado en 2024 como FIPS 203 y se basa en la dificultad asumida del problema Module Learning with Errors. NIST define tres conjuntos de parámetros:

• ML-KEM-512, con las claves y el volumen de datos más pequeños,
• ML-KEM-768, como variante intermedia y especialmente extendida hoy,
• ML-KEM-1024, con un nivel de seguridad superior, pero también mayor coste de procesamiento y transmisión.

En la documentación de MR2, Sophos solo habla en general de algoritmos de intercambio de claves puros e híbridos basados en ML-KEM. No especifica qué conjuntos de parámetros, grupos TLS o identificadores de firma concretos están cubiertos. Por tanto, no debe suponerse automáticamente que se detecte cualquier variante imaginable de ML-KEM.

Qué hace técnicamente un KEM

ML-KEM no cifra directamente todo el flujo de datos. Simplificando, un Key Encapsulation Mechanism consta de tres operaciones:

1. KeyGen genera una Encapsulation Key y la Decapsulation Key correspondiente.
2. Encaps utiliza la Encapsulation Key pública para generar un objeto ciphertext y un secreto compartido.
3. Decaps recupera en el otro extremo el mismo secreto mediante la Decapsulation Key privada.

A partir de ese secreto compartido, el protocolo deriva después claves de sesión simétricas. Los datos útiles continúan protegidos con métodos simétricos rápidos como AES o ChaCha20. ML-KEM sustituye por tanto la parte asimétrica vulnerable del intercambio de claves, no todo el cifrado de datos TLS.

El contexto práctico es Harvest now, decrypt later: un atacante puede grabar hoy tráfico cifrado y esperar poder descifrarlo dentro de algunos años con un ordenador cuántico criptográficamente relevante. Esto resulta menos dramático para datos de vida corta. Sin embargo, para datos sanitarios, comunicaciones estatales, propiedad intelectual o información empresarial confidencial a largo plazo, el periodo durante el que deben permanecer protegidos puede superar claramente el tiempo que falte hasta una posible nueva clase de ataque.

Puro e híbrido no son lo mismo

En un intercambio de claves PQC puro, la seguridad de la negociación se basa únicamente en el nuevo método poscuántico. Un intercambio híbrido, en cambio, combina un mecanismo clásico con ML-KEM. Un ejemplo extendido en implementaciones reales es X25519MLKEM768: el componente clásico X25519 y ML-KEM-768 contribuyen conjuntamente al secreto resultante.

El enfoque híbrido es razonable en este momento. Si más adelante aparece un error de implementación o una debilidad matemática en ML-KEM, se mantiene el componente clásico. Si, por el contrario, un ordenador cuántico suficientemente potente pudiera romper la curva elíptica clásica, permanecería el componente ML-KEM. El modo híbrido es así un puente de migración, no un cifrado doble innecesario.

No obstante, conviene aclararlo: X25519MLKEM768 es aquí un ejemplo técnico real de implementaciones TLS actuales. Sophos no afirma expresamente en la documentación de MR2 que este sea el único grupo detectado o el principal.

Qué hace el IPS

El Intrusion Prevention System recibe nuevas firmas capaces de detectar intercambios de claves ML-KEM puros e híbridos. Los administradores pueden crear reglas IPS específicas y asignar acciones como Allow, Drop o Reset.

Técnicamente, un firewall puede reconocer el intercambio de claves ofrecido y seleccionado durante el handshake TLS porque el cliente anuncia sus grupos compatibles y Key Shares en el ClientHello, y el servidor confirma su elección en el ServerHello. Esta fase tiene lugar antes de que comience el flujo cifrado de la aplicación. En principio, por tanto, la detección es posible sin leer posteriormente el contenido HTTPS.

Sin embargo, Sophos no documenta en qué punto Snort o la canalización IPS de SFOS evalúan estas características, qué versiones de TLS se cubren ni si la detección difiere entre tráfico proxy, DPI y FastPath no descifrado. Las notas de la versión confirman la capacidad, pero no la implementación interna de la ruta de datos. Una política de producción requiere por ello pruebas propias con los registros del firewall y del IPS.

Las acciones tienen efectos diferentes:

• Allow deja continuar la conexión y, junto con el registro, resulta adecuado para crear un inventario.
• Drop descarta silenciosamente los paquetes coincidentes. El cliente suele percibir un timeout o un handshake interrumpido.
• Reset termina activamente la conexión TCP. El error aparece antes, pero puede verse de otra manera para el usuario y en los registros de la aplicación que con un descarte silencioso.

Las nuevas firmas están desactivadas de forma predeterminada. Es la decisión correcta. PQC ya no es solo tecnología de laboratorio. Grandes navegadores, servicios cloud y plataformas web ya prueban o utilizan procedimientos híbridos. Si Sophos bloqueara estas conexiones de forma general, podrían fallar sitios web y aplicaciones legítimos.

Una introducción sensata debería ser así:

1. Activar primero las firmas, permitiendo y registrando el tráfico.
2. Evaluar durante varios días o semanas qué aplicaciones y destinos utilizan ML-KEM.
3. Comprobar si las políticas criptográficas internas prohíben determinados procedimientos o los exigen expresamente.
4. Solo después aplicar de forma selectiva Drop o Reset.

En el primer debate de la comunidad, un administrador informó justo después de la actualización de que aún no encontraba las firmas IPS correspondientes buscando PQC, KEM o quantum. Puede deberse a una actualización de patrones que todavía no había llegado o a la nomenclatura. Pocas horas después de la publicación no es posible concluir que exista un fallo de producto fiable. Pero sí muestra un problema de documentación: una función solo es administrable si se pueden localizar el nombre de la firma, el SID, la categoría y las características del registro.

Antes de modificar una política comprobaría concretamente:

• ¿Está activo el IPS y es válida la suscripción Network Protection?
• ¿Qué versión de patrones IPS está instalada?
• ¿Con qué nombre y SID aparecen las nuevas firmas?
• ¿Aparecen las coincidencias en el registro IPS y en los informes centrales?
• ¿Se mantiene igual la detección con excepciones DPI, inspección TLS y FastPath?
• ¿Qué navegadores, sistemas operativos, servicios cloud y aplicaciones internas generan coincidencias?

Qué hace Web Protection

Además, según Sophos, Web Protection impide que las sesiones web negocien algoritmos PQC no compatibles. Es una tarea distinta de una firma IPS. IPS reconoce patrones determinados y puede reaccionar. Web Protection interviene en el flujo controlado de TLS y web para impedir que una conexión utilice un método que el firewall no pueda procesar o que no esté permitido por la política.

Esto resulta relevante sobre todo con inspección TLS. En una conexión descifrada, el firewall termina la sesión TLS del cliente y establece por sí mismo una segunda sesión TLS con el servidor de destino. Existen así dos handshakes separados y dos conjuntos distintos de claves de sesión. Un navegador y un servidor web podrían admitir PQC, mientras el componente de inspección intermedio no pudiera procesar correctamente un grupo ofrecido.

Sin un comportamiento controlado pueden aparecer errores difíciles de interpretar: el cliente ofrece un grupo nuevo, el firewall no puede mediar por completo el handshake, el servidor selecciona una variante inesperada o un fallback se comporta de manera distinta a la prevista. MR2 debe impedir que las sesiones web negocien algoritmos PQC no compatibles.

Lo que Sophos no describe con precisión es igual de importante: la documentación no incluye una matriz de políticas PQC propia de Web Protection, una lista de grupos compatibles ni una declaración exacta sobre si una oferta no compatible se elimina, se rechaza o se sustituye por un fallback clásico. Esto no debe confundirse con la acción IPS configurable libremente.

La función tiene sentido, pero no sustituye una estrategia criptográfica. Las empresas deben seguir sabiendo qué conexiones TLS se descifran, dónde existen excepciones y si PQC solo debe observarse o aplicarse realmente.

Las aplicaciones de IA generativa ganan visibilidad

La segunda nueva función de seguridad afecta a las aplicaciones de IA generativa. Sophos mejora su categorización mediante Synchronized Application Control.

El principio no es nuevo: Sophos Endpoint ve qué proceso local establece una conexión y comparte con el firewall los datos de contexto de la aplicación a través de Security Heartbeat. De esta forma, el firewall puede asignar una sesión a un programa incluso cuando el puerto, la IP de destino y el tráfico cifrado no permiten por sí solos una identificación inequívoca.

La ruta de datos técnica, simplificada, es la siguiente:

1. Una aplicación de un endpoint protegido abre una conexión de red.
2. Sophos Endpoint conoce el nombre del proceso, la ruta y el contexto local de la aplicación.
3. Security Heartbeat conecta la perspectiva del endpoint con la del firewall.
4. SFOS asigna a una aplicación la sesión que, de otro modo, sería desconocida o solo se reconocería de forma genérica.
5. La aplicación aparece en Synchronized Application Control y puede categorizarse.
6. Una Application Filter Policy permite, bloquea o regula el tráfico correspondiente.

En Connection List, SFOS puede solicitar información al endpoint para conexiones no identificadas mediante Resolve application info. La lista de aplicaciones puede buscarse por nombre, ruta, categoría o endpoints. Sophos indica un máximo de 15.000 aplicaciones administradas mediante Synchronized Application Control. Por motivos de memoria, el firewall conserva únicamente las cinco apariciones más recientes por aplicación y endpoint.

MR2 mejora específicamente la clasificación de aplicaciones de IA generativa. Sophos Endpoint debe reconocerlas con mayor precisión y transmitir la información al firewall. La categoría Generative AI existe en la lista de aplicaciones de SFOS y puede utilizarse en Application Filters e informes.

Para los administradores hay tres aspectos relevantes:

• Visibilidad: los informes deben mostrar con mayor claridad qué aplicaciones de IA generativa se utilizan en la empresa.
• Reglas: las aplicaciones detectadas pueden permitirse, limitarse o bloquearse con mayor precisión.
• Inventario: los equipos de seguridad y protección de datos obtienen una base mejor para distinguir servicios de IA autorizados y no autorizados.

Es útil, pero la expresión «detectar IA generativa» no debe interpretarse como algo más amplio de lo que realmente es.

Synchronized Application Control responde principalmente a esta pregunta: ¿Qué aplicación generó la conexión? No responde automáticamente:

• qué prompt introdujo un usuario,
• qué archivo se cargó,
• si contenía datos personales o confidenciales,
• si una sesión del navegador corresponde a un uso privado o empresarial de IA,
• si un servicio de IA permitido se utilizó mediante una función integrada en el navegador.

Un cliente de escritorio con una ruta de proceso inequívoca es más fácil de asignar que diez servicios web de IA ejecutados en el mismo proceso del navegador. La categorización de URL, la inspección TLS y la detección de aplicaciones cloud pueden aportar información adicional, pero son niveles de detección técnicamente distintos.

El valor añadido también depende de Sophos Endpoint, un Security Heartbeat activo y Synchronized Application Control habilitado. La primera activación se realiza mediante Sophos Central. Quien utilice únicamente SFOS sin Sophos Endpoint o tenga endpoints fuera de la ruta de Heartbeat no obtiene automáticamente la misma profundidad de detección.

La expectativa correcta es esta: MR2 mejora la asignación de aplicaciones y, con ello, la base para las políticas. No resuelve por sí solo la cuestión organizativa de qué servicios de IA están permitidos ni qué datos pueden procesarse en ellos.

Después de la actualización, yo no bloquearía inmediatamente toda la categoría Generative AI. Primero hay que determinar en los informes qué coincidencias proceden del contexto del endpoint, de una firma del firewall o de la categorización web. De lo contrario, podrían bloquearse funciones productivas de Microsoft 365, herramientas de desarrollo, navegadores o plataformas de soporte sin entender su uso real.

Cambios en la autenticación y la asignación de usuarios

MR2 incluye tres temas de autenticación independientes. Dos exigen una preparación concreta; el tercero es una advertencia temprana de migración.

Chromebook User ID con Manifest V3

La Sophos Chromebook User ID Extension se ha adaptado a Manifest V3. Es la plataforma actual de extensiones de Chrome y sustituye la base técnica anterior.

El punto decisivo: Sophos exige desinstalar la extensión anterior e instalar la nueva versión. No basta con una actualización silenciosa de la antigua extensión. Los centros educativos y empresas con Chromebooks administrados centralmente deben preparar el cambio mediante sus políticas de Google Admin, probarlo con un grupo piloto y desplegarlo después de forma general.

Técnicamente, la extensión solo forma parte de la ruta SSO. Para Chromebook SSO, Sophos requiere, entre otras cosas:

• un servidor AD, LDAP o Google Secure LDAP en el firewall,
• Chromebooks dentro de la red protegida por SFOS,
• direcciones de usuario del dominio registrado en Google Workspace,
• un certificado para la comunicación cifrada,
• un CN que coincida con el certificado,
• el puerto de comunicación de Sophos 65123 de forma predeterminada,
• una configuración JSON exportada desde SFOS y almacenada en Google Workspace,
• acceso a accounts.google.com, los hosts de Google API y Chrome Web Store.

En Google Workspace, la nueva extensión se distribuye desde Devices > Chrome > Apps and extensions > Users and browsers. Para entornos de producción resulta adecuado Force install, de modo que los usuarios no puedan eliminar la extensión necesaria para la asignación de identidad. Además, la aplicación Sophos User ID debe autorizarse como fiable en API Controls; de lo contrario, OAuth puede fallar.

Después del cambio no comprobaría únicamente si la extensión está instalada. Lo decisivo es toda la cadena:

1. El usuario inicia sesión en el Chromebook.
2. La extensión alcanza el firewall por la red y el certificado previstos.
3. El usuario aparece en Live users.
4. Una regla basada en usuarios coincide realmente con el usuario o grupo.
5. Tras cerrar sesión o cambiar de dispositivo, la asignación vuelve a desaparecer correctamente.

Sin la nueva extensión podrían dejar de recibirse futuras actualizaciones. Dependiendo del diseño de autenticación, esto puede afectar a la asignación de usuarios y, con ello, a reglas de firewall o web basadas en usuarios. En un centro educativo puede convertirse rápidamente en un problema de filtrado aunque el firewall, el acceso a Internet y el Chromebook parezcan estar todos «online».

STAS ya no bloquea el tráfico de forma predeterminada durante la comprobación de identidad

En Sophos Transparent Authentication Suite, MR2 cambia a No el valor predeterminado de Restrict client traffic during identity probe.

STAS asigna direcciones IP a los usuarios detectados en el controlador de dominio de Windows. El proceso es antiguo, pero técnicamente interesante:

1. El usuario inicia sesión en el dominio de Windows.
2. El controlador de dominio escribe un evento de auditoría de seguridad, normalmente el Event ID 4768 en versiones recientes de Windows.
3. El STAS Agent extrae del evento el nombre de usuario y la dirección IP.
4. El agente envía la información al Collector, de forma predeterminada mediante TCP 5566.
5. El Collector comunica las asignaciones correctas al firewall mediante UDP 6060.
6. Cuando SFOS detecta tráfico de una IP desconocida, puede consultar el Collector a través del puerto 6677.
7. El firewall completa la pertenencia a grupos mediante el servidor AD configurado y aplica reglas basadas en usuarios.

Cuando el firewall aún no tiene una asignación para una IP, esta entra en Learning Mode. Hasta ahora, el tráfico se detenía o descartaba de forma predeterminada durante este sondeo. El periodo predeterminado documentado es de 120 segundos. Si el Collector no responde, la IP puede considerarse no autenticada durante una hora; en ese caso se aplican las reglas para tráfico no autenticado.

Ahí precisamente existía un problema operativo real en MR1. Sophos documenta NC-181885: con Restrict client traffic during identity probe = Yes, las Identity Probes repetidas podían causar interrupciones intermitentes o bloquear la actualización a MR1. MR2 figura como versión corregida y cambia al mismo tiempo el valor predeterminado a No.

Con No, el tráfico del cliente puede seguir circulando durante la comprobación. Esto reduce las interrupciones, pero modifica el equilibrio:

• El usuario sufre menos interrupciones.
• Durante la comprobación, el firewall puede no disponer todavía de una identidad confirmada.
• Por ello deben revisarse con precisión las reglas basadas en usuarios y el registro durante esta fase transitoria.

Es el clásico compromiso entre disponibilidad y aplicación estricta de la identidad. Con Yes, una comunicación defectuosa con el Collector puede bloquear al cliente. Con No, el tráfico puede fluir durante el sondeo antes de confirmar la identidad del usuario. Si ese tráfico coincide con una regla general de red, una regla para usuarios no autenticados o posteriormente con una regla de usuario debe probarse en el conjunto de reglas propio.

Las notas de la versión indican que el valor predeterminado cambia a No. No afirman inequívocamente que MR2 sobrescriba automáticamente cualquier configuración existente establecida de forma consciente. Por ello, las instalaciones actuales deben comprobar después de la actualización qué valor está realmente configurado.

También comprobaría los siguientes puntos:

• ¿Están abiertos UDP 6060 y 6677 entre el firewall y el Collector?
• ¿Está en ejecución STAS Service y vinculado a la NIC correcta?
• ¿Hay varios Collectors configurados en grupos para Fault Tolerance?
• ¿Se aplican objetos Clientless User para impresoras, IoT y otros dispositivos ajenos al dominio?
• ¿Aparecen correctamente los usuarios después de suspensión, roaming, cambio de DHCP y cierre de sesión?
• ¿Coinciden las reglas durante Learning Mode y el estado no autenticado tal como lo prevé el diseño de seguridad?

Esto es especialmente importante en entornos donde la identidad del usuario no solo sirve para los informes, sino como condición real de acceso.

Novell eDirectory termina con SFOS 23.0

MR2 anuncia por primera vez y con antelación que Sophos dejará de admitir servidores de autenticación Novell eDirectory con SFOS 23.0.

eDirectory sigue funcionando en MR2. El aviso es una advertencia anticipada, no una pérdida inmediata de funciones. No obstante, quien todavía utilice eDirectory en producción debe aprovechar el tiempo restante y migrar a un tipo de autenticación compatible antes de instalar SFOS 23.0.

Una migración de este tipo afecta a mucho más que la entrada del servidor. Los grupos, las reglas de firewall, las políticas web, los accesos VPN, los portales de usuario y los informes pueden depender de la fuente de identidad anterior. Las diferencias en Distinguished Names, anidamiento de grupos, rutas de búsqueda y formatos de nombres de usuario también pueden hacer que una prueba LDAP técnicamente correcta esté muy lejos de ser una migración funcional de políticas.

A ello se suma una limitación ya conocida: STAS no admite LDAP sobre SSL/TLS con eDirectory. Por tanto, que Sophos elimine eDirectory por completo en SFOS 23.0 no resulta del todo sorprendente. Aun así, la arquitectura de sustitución debe estar preparada a tiempo. Debe tratarse como un proyecto propio, con cuentas de prueba, grupos paralelos equivalentes, referencias de reglas documentadas y un plan de reversión.

Let’s Encrypt: nuevas cadenas y mejor identificación

Let’s Encrypt está trasladando gradualmente su infraestructura de certificados a nuevos certificados raíz e intermedios. MR2 añade compatibilidad con YE Root, YE1, YE2, YR Root, YR1 y YR2.

Es la denominada jerarquía Generation Y. Consta de dos nuevas Root CA con tipos de clave distintos:

• ISRG Root YE utiliza ECDSA P-384 y es la ruta sucesora de la anterior jerarquía ECDSA.
• ISRG Root YR utiliza RSA 4096 y es la nueva ruta raíz RSA.
• YE1 y YE2 son certificados intermedios ECDSA P-384.
• YR1 y YR2 son certificados intermedios RSA 2048.

Las raíces están firmadas de forma cruzada por las raíces ISRG anteriores. De esta manera, las nuevas cadenas pueden volver a anclas de confianza antiguas y ya extendidas mientras los fabricantes de navegadores y sistemas operativos incorporan las nuevas raíces a sus Trust Stores. Los intermedios YE1, YE2, YR1 e YR2 adquirieron relevancia para la emisión activa en 2026.

Para SFOS se trata principalmente de un cambio de compatibilidad. El firewall debe conocer correctamente los nuevos emisores y cadenas para que la emisión automática, la renovación, el uso en WAF y la validación sigan funcionando con la próxima generación de la infraestructura de Let’s Encrypt. Sin la cadena de confianza actualizada, las operaciones con certificados podrían fallar aunque el dominio, el puerto 80 y la validación HTTP-01 estuvieran correctamente configurados.

Operativamente resulta especialmente incómodo porque es fácil atribuir mal un error ACME. Entonces se buscan problemas en DNS, DNAT, el puerto 80, la regla WAF o los Terms of Service aunque la causa real pueda ser una nueva cadena de CA.

SFOS sigue utilizando HTTP-01 para las solicitudes de Let’s Encrypt. El dominio debe apuntar como FQDN a la dirección WAN pública seleccionada. El puerto 80 debe alcanzar el firewall, y una regla DNAT que compita en la misma dirección y puerto 80 puede impedir la validación. MR2 no cambia este principio básico; amplía la jerarquía de CA compatible.

Además, las notificaciones por correo electrónico de Let’s Encrypt incluyen ahora el hostname y el número de serie del firewall. Parece un cambio pequeño, pero resulta muy útil para MSP y entornos grandes. Quien administre decenas de firewalls puede asignar por fin un aviso al dispositivo correcto más rápidamente, sin tener que buscar primero a partir de un mensaje genérico.

Es una mejora clásica de calidad de vida: técnicamente poco espectacular, pero útil en el día a día. En realidad, cualquier mensaje generado por el sistema de un firewall administrado centralmente debería incluir al menos hostname, número de serie, modelo y firmware. Sophos ya había avanzado en esta dirección con los correos de backup; Let’s Encrypt se suma con MR2.

Config Studio 2.6: todas las funciones nuevas explicadas

Sophos presenta oficialmente Config Studio 2.6 como parte del anuncio de MR2, aunque sigue siendo una herramienta independiente para el navegador y no una nueva interfaz ejecutada directamente en SFOS. Quien aún no conozca el concepto puede consultar el flujo completo con exportación, Entities.xml, comparación y editor en el artículo anterior Sophos Firewall Config Studio V2: mucho más que un visor.

Un aspecto importante para la valoración técnica y de privacidad: Sophos afirma que el análisis sintáctico, el análisis y la generación de informes se realizan localmente en el navegador del endpoint. La configuración cargada no debería enviarse a Sophos ni a ningún otro servidor. Esto es decisivo para una configuración completa del firewall, ya que Entities.xml puede contener redes internas, objetos, reglas, definiciones de VPN, referencias de certificados y nombres organizativos.

Que se procese localmente tampoco significa que no exista ningún riesgo. El navegador sigue cargando la aplicación desde Internet. En entornos muy sensibles permanecen las cuestiones relativas a la versión del código, la caché del navegador, el uso offline, el endurecimiento del endpoint y el almacenamiento seguro de las exportaciones. Un archivo Entities.xml no debe acabar sin control en Descargas, tickets o una sincronización cloud normal.

Config Studio 2.6 cubre ya cinco áreas de trabajo:

• Configuration Report con Policy Test, análisis y búsqueda global
• comparación de dos o más configuraciones
• editor visual con Bulk Editing y salida XML, API o curl
• migración desde Sophos UTM, SonicWall, FortiGate y Palo Alto Networks
• compatibilidad de Backup Restore, Flexi Port, transceptores y modelos

La versión 2.6 amplía estas áreas en varios puntos.

Combinar plantillas

Merge Templates permite combinar configuraciones de referencia con plantillas específicas de un sector. Un MSP podría, por ejemplo, unir una configuración base técnica para registro, DNS, accesos administrativos y objetos estándar con una plantilla para consultas médicas, centros educativos o sucursales.

La ventaja reside en la reutilización. No hay que empezar desde cero con cada firewall. Una baseline puede contener, por ejemplo, accesos administrativos, NTP, DNS, Syslog, servicios estándar y convenciones de registro. Una segunda plantilla añade reglas y objetos específicos del sector.

El punto crítico sigue siendo la gestión de conflictos:

• ¿Qué sucede con nombres de objeto idénticos que tienen valores distintos?
• ¿Se resuelven de forma coherente UUID, referencias y orden de reglas?
• ¿Qué referencias a interfaces y zonas no se ajustan al modelo de destino?
• ¿La fusión crea reglas duplicadas o solapadas?
• ¿Se sustituye un objeto restrictivo existente por un valor más amplio de la plantilla?

Después de la fusión, Duplicate Analysis, Shadow Rule Analysis, Usage References y una prueba completa con Policy Test son obligatorios. Que la fusión sea técnicamente correcta no demuestra que la política resultante sea segura.

Búsqueda global mejorada

La búsqueda global permite encontrar objetos de configuración con mayor rapidez y navegar directamente hasta ellos. Esto es más importante de lo que parece en conjuntos de reglas grandes. Un objeto host puede estar referenciado en configuraciones de firewall, NAT, TLS, web o VPN. Si un resultado lleva con un clic al punto relevante, se ahorra mucho trabajo de apertura y navegación manual.

Config Studio no solo puede buscar el nombre visible del objeto. Según el tipo de datos, también son relevantes valores, rutas y elementos referenciados. El salto directo al resultado resulta especialmente útil con nombres genéricos como Server, LAN_Network o grupos de hosts creados a lo largo de los años.

Sin embargo, Search no es lo mismo que Usage Reference. Search responde: «¿Dónde encuentro este objeto o valor?». Usage Reference responde: «¿Qué otros elementos de configuración dependen de él?». Para realizar un cambio seguro se necesitan ambas perspectivas.

Precisamente esta función también hace mucha falta directamente en la interfaz del firewall.

Informes de configuración más significativos

En las reglas de firewall, NAT y TLS, los informes muestran ahora no solo los nombres de referencia, sino también los valores y detalles de los objetos utilizados. En lugar de ver únicamente Webserver-Gruppe, por ejemplo, el revisor puede identificar directamente qué hosts o redes contiene.

Es un gran avance para auditorías, traspasos y revisiones por pares. Una regla solo puede evaluarse razonablemente si el origen, el destino, los servicios y los objetos vinculados son visibles sin una cadena adicional de clics. Un nombre de objeto puede parecer correcto y, aun así, contener Any, una red demasiado amplia o entradas olvidadas hace tiempo.

El informe también admite Policy Test y análisis. Policy Test comprueba qué regla o ruta coincide con valores de origen y destino definidos. El análisis busca, entre otras cosas, shadowing y duplicados. Como SFOS evalúa las reglas de firewall de arriba abajo y se detiene en la primera coincidencia, el orden forma parte de la lógica de seguridad y no es solo una cuestión de presentación.

Config Studio 2.6: migración, comparación y exportación

Análisis de migración con porcentaje de éxito

Config Studio muestra información sobre la migración y conversión, incluido el porcentaje transferido correctamente. Un porcentaje es un indicador rápido, pero no un protocolo de aceptación.

Sophos distingue varios estados en las migraciones desde otros fabricantes:

• Supported: migrado automáticamente y sin cambios de contenido
• Partial: migrado con carencias; las partes que faltan deben completarse
• Manual: debe recrearse manualmente en Sophos Firewall
• Not supported: no se migra
• Action required: exige una decisión concreta antes de la exportación

Aunque se haya convertido el 95 % de una configuración, el cinco por ciento restante puede contener precisamente certificados, contraseñas, VPN, NAT o routing especial. El valor práctico no reside solo en el porcentaje verde, sino en la lista de elementos no migrados, migrados parcialmente o resueltos automáticamente.

Las diferencias entre las lógicas de los fabricantes son reales. Las reglas de FortiGate pueden estar más ligadas a interfaces, mientras SFOS trabaja con zonas. Palo Alto utiliza otros modelos de objetos, zonas y políticas. Config Studio puede convertir sintaxis y muchas estructuras, pero no puede demostrar automáticamente que el modelo de seguridad conserve exactamente la misma semántica.

Multi-File Configuration Diff

Hasta ahora, la comparación clásica era sobre todo un modelo de antes y después. Multi-File Diff permite cargar dos o más estados de configuración y compararlos a lo largo de distintos momentos. Config Studio ordena los archivos por fecha de modificación y puede presentar cambios de campo como añadidos, eliminados o modificados.

Hay vistas Side-by-Side, Unified y Semantic. La comparación semántica resulta especialmente interesante porque en XML un diff puramente textual se llena rápidamente de ruido debido al orden, los ID o el formato. Un diff a nivel de entidad y campo intenta mostrar en su lugar el cambio de configuración real.

Esto es útil para reconstruir cambios y localizar errores. Si un problema no aparece inmediatamente después de una sola ventana de mantenimiento, pueden compararse varias exportaciones para comprobar cuándo cambió realmente una regla, un objeto o una opción.

La limitación permanece: hacen falta estados de configuración guardados periódicamente, marcas temporales correctas y un tratamiento seguro de los datos sensibles exportados. La fecha de modificación de un archivo descargado o copiado no tiene por qué coincidir con el momento del cambio en el firewall. Para mantener un historial fiable deben documentarse conjuntamente el nombre del archivo, la hora de exportación, el hostname del firewall, el número de serie, el firmware y el ticket de cambio asociado.

Sin disciplina de versiones, ni siquiera un Multi-File Diff puede inventar un historial. Y precisamente por eso esta función sería mucho más potente directamente en Central, con un historial de auditoría inmutable, que mediante una carga manual de archivos.

Referencia de Backup Restore, Flexi Port y velocidades

Config Studio puede comprobar la compatibilidad de Backup Restore y la disposición de puertos entre distintos modelos de Sophos Firewall. También muestra información sobre módulos Flexi Port y las velocidades y estándares compatibles, incluidos 25, 40 o 100 Gbit/s.

Esta función ayuda en las migraciones de hardware. Antes de cambiar de un modelo a otro permite valorar mejor:

• si un backup puede restaurarse en principio,
• cuántos puertos físicos hay disponibles,
• si los módulos Flexi Port actuales son compatibles,
• qué estándares y velocidades de interfaz se admiten.

No sustituye, sin embargo, un diseño de migración. LAG, VLAN, bridges, HA, nombres de puertos, zonas y la asignación concreta de interfaces siguen necesitando planificación y comprobación después de la restauración.

La compatibilidad ampliada de Backup Restore se aplica a destinos desde SFOS 20.0 MR2. Según la versión de origen y la plataforma de destino, aparece Backup Restore Assistant para asignar las interfaces. Los puertos físicos pueden volver a mapearse, mientras las VLAN y los alias siguen a su interfaz principal y los LAG o bridges se reconstruyen con los puertos asignados.

Especialmente con Flexi Ports, no basta con preguntar «¿encaja físicamente el módulo?». Deben comprobarse conjuntamente la generación del modelo, el factor de forma, el transceptor, el estándar compatible, la velocidad del puerto, el comportamiento breakout y la versión SFOS disponible. Config Studio agiliza la referencia, pero no sustituye las pruebas de enlace y failover después de la migración.

Dark Mode

Las notas de la versión propiamente dichas también mencionan Dark Mode. Es una pequeña mejora de uso, no una función del firewall. Aun así, resulta casi simbólico: incluso el modo oscuro llega primero al Config Studio externo, mientras la consola WebAdmin local avanza visual y ergonómicamente con extrema lentitud desde hace años.

Qué puede generar técnicamente el editor

El editor permite importar configuraciones o crearlas desde cero, realizar Bulk Changes y mostrar el resultado antes de exportarlo como Import XML, API Request o curl. También puede descargarse XML o un archivo TAR e importarlo en SFOS mediante Backup & firmware > Import export.

Es potente, pero también aumenta la responsabilidad del administrador. Una solicitud API generada no es automáticamente idempotente. Una importación correcta no confirma que Rule Order, el uso de objetos, NAT, VPN y las Security Policies sean funcionalmente correctos. Antes de aplicarlo en producción, la salida debe incluirse en un ticket de cambio, el diff debe someterse a revisión y el firewall resultante necesita una prueba real de la ruta de datos.

Más de 50 correcciones son el verdadero motivo para MR2

Sophos menciona más de 50 problemas de fiabilidad, estabilidad y seguridad corregidos. No todas las correcciones afectan a todas las instalaciones, pero varias entradas son operativamente graves.

Desde mi punto de vista, estos grupos son especialmente relevantes:

HA y failsafe no son asuntos secundarios

Varias correcciones no afectan solo a una función aislada, sino a la capacidad operativa del appliance:

• NC-181331: una partición de configuración llena podía llevar el firewall a Failsafe Mode.
• NC-180110: Logging Daemon no podía iniciarse en el Primary, tras lo cual el dispositivo HA entraba en failsafe.
• NC-177441: después de actualizar a v22 GA, el dispositivo Primary original podía entrar en failsafe por un problema de Postgres.
• NC-178906: RED Server Service podía no arrancar y provocar así un estado failsafe.
• NC-177467: el dispositivo Auxiliary no se iniciaba correctamente ante un número muy elevado de intentos SSH no autenticados simultáneos.

Son causas distintas, pero tienen el mismo efecto operativo: el firewall pierde servicios, entra en un modo de protección o el partner HA no está disponible como hacía pensar anteriormente la imagen verde del clúster. Por eso, después de la actualización no basta con mirar HA status: Active-Passive. Hay que probar sincronización, estado de servicios, failover y tráfico real.

Las correcciones de IPsec llegan hasta el fondo de la ruta de datos

Las correcciones de VPN tampoco son cosméticas:

• NC-180433: el tráfico multicast a través de un túnel VPN podía provocar fallos repetidos del firewall.
• NC-171719: el tráfico ESP encontraba un routing incorrecto en una configuración SD-WAN.
• NC-180520: con IPsec Acceleration activado, un gateway XFRM quedaba no disponible después de la actualización si el túnel estaba ligado a una IP alias y ESP llegaba por otro puerto WAN.
• NC-176855: el rendimiento IPv6 mediante IPsec route-based estaba afectado.
• NC-178121: drag-and-drop podía mover conexiones IPsec Site-to-Site a posiciones incorrectas dentro de un Failover Group.

Un estado de túnel Active no demuestra nada ante estos tipos de error. En VPN route-based hay que probar por separado la interfaz XFRM, Routing Table, la decisión SD-WAN, la ruta ESP, MTU, IPv4 e IPv6. En Failover Groups también debe comprobarse si el orden y la conmutación después de la actualización siguen correspondiendo a la prioridad documentada.

El registro y los informes podían causar interrupciones por sí mismos

NC-155252 es una corrección especialmente desagradable: una elevada carga de E/S de disco en Reporting causaba picos de CPU y cortes intermitentes de Internet de hasta un minuto. Es exactamente el tipo de error en el que un subsistema de análisis perjudica la ruta de datos productiva.

NC-178745 describe el reinicio automático de un dispositivo HA por falta de memoria en Logging Framework. NC-181520 mejora el rendimiento de Log Viewer. En conjunto, muestran que el registro de SFOS no debe considerarse una función secundaria inocua. Storage, la base de datos, Garner, Log Viewer y Central Reporting están operativamente más unidos al sistema de lo que sugiere la interfaz.

Después de MR2, no comprobaría solo si aparecen líneas nuevas en los registros. Lo relevante es:

• ¿Llegan completos los eventos de firewall, IPS, WAF, Authentication y VPN?
• ¿Se mantiene la cronología sin huecos?
• ¿Sigue recibiendo datos el colector Syslog externo?
• ¿Se mantienen estables CPU, RAM y E/S de disco con una carga normal?
• ¿Se generan los informes sin perjudicar la ruta de datos?

Las correcciones de Central muestran los límites del «Single Pane of Glass»

Con NC-181175, las Group Policies de Sophos Central podían quedarse en estado Pending. NC-180513 afectaba a la importación de configuraciones desde Central View después de actualizar a MR1. NC-181904 impedía liberar correos en cuarentena mediante Central.

El denominador común: la interfaz central puede aceptar o mostrar una orden sin que el cambio deseado se haya ejecutado realmente en el firewall. Después de enviar una Group Policy debe comprobarse en el dispositivo de destino si el objeto, la regla, el orden y la marca temporal han llegado de verdad. Que un diálogo se cierre correctamente en Central no demuestra técnicamente un commit.

Esta lista también muestra por qué no valoro las versiones de mantenimiento solo por la longitud de la lista de funciones. Si un firewall entra en failsafe o se reinicia por Logging, Postgres, SD-WAN o multicast, una corrección para ello vale más que un nuevo mosaico en el dashboard.

Al mismo tiempo, la cantidad de correcciones no es un sello automático de calidad. Demuestra que se han resuelto problemas, pero también cuántos errores graves contenían las compilaciones anteriores. Quien opere un entorno crítico con HA, VPN o WAF no debería quedarse eternamente en una compilación antigua por miedo, ni distribuir MR2 sin pruebas en todas partes desde el primer día.

Qué deben comprobar los administradores antes de actualizar

Sophos recomienda instalar MR2 pronto por sus correcciones de seguridad, estabilidad y rendimiento. Es comprensible en principio. Pero «pronto» no significa «a ciegas» en entornos productivos.

El etiquetado VLAN heredado en bridges bloquea MR2

Una novedad en MR2 es el bloqueo estricto de la actualización cuando existe etiquetado VLAN heredado configurado mediante CLI en interfaces bridge. Si la configuración aún utiliza el procedimiento heredado system vlan-tag, el firewall no puede actualizarse a SFOS 22.0 MR2 o posterior.

Estas configuraciones deben limpiarse o migrarse antes de actualizar. Además, los backups con esta configuración heredada no pueden restaurarse en SFOS 22.0 GA o posterior. Es especialmente importante en instalaciones antiguas que en algún momento se modificaron mediante CLI.

Los obstáculos conocidos de v22 siguen vigentes

También siguen aplicándose los requisitos conocidos de GA y MR1:

• Legacy Remote Access IPsec debe eliminarse o migrarse antes de MR1 o MR2.
• SFOS 22 necesita más espacio de almacenamiento; algunos appliances de escritorio, virtuales o de software requieren un ajuste previo.
• El comportamiento de las VPN IPsec policy-based ha cambiado desde GA y debe revisarse en los túneles correspondientes.
• El hardware XG y SG no es compatible con SFOS 22.
• RED 15, RED 15w y RED 50 antiguos dejaron de ser compatibles desde v21.5.

Mi procedimiento de actualización

Para firewalls de producción seguiría como mínimo estos pasos:

1. Crear un backup actual y guardarlo externamente.
2. Comprobar el estado del soporte y las licencias, además de la ruta de actualización autorizada.
3. Descartar Legacy Remote Access IPsec y el etiquetado VLAN por CLI en bridges.
4. Revisar los avisos de Disk Space en Control Center.
5. En HA, comprobar el estado de ambos nodos, la sincronización y el firmware disponible.
6. Documentar las VPN críticas, publicaciones WAF, flujos de correo, reglas SD-WAN y autenticación.
7. Instalar MR2 primero en un appliance de prueba representativo o menos crítico.
8. Después de actualizar, probar registros, versión de patrones, HA, routing, DNS, VPN, WebAdmin, Reporting y los envíos centrales de políticas.

En una versión con muchas correcciones, una prueba limpia antes y después resulta especialmente valiosa. De lo contrario, al final se sabe que el firmware es nuevo, pero no si las rutas de datos críticas propias siguen funcionando exactamente según lo previsto.

Desde la versión 20, SFOS dispone de un rollback automático del firmware si falla la migración de la configuración durante la actualización. Esto reduce el riesgo de arrancar con Factory Configuration en lugar de la configuración productiva. No obstante, la protección no se aplica en todos los escenarios, por ejemplo con una ruta de actualización no compatible o determinados procesos de Setup Assistant. Después de un rollback automático, migration.log y migrationhash.log deben formar parte del análisis.

Un rollback automático tampoco sustituye un backup guardado externamente, la Secure Storage Master Key ni un acceso disponible a la consola. Protege principalmente frente a una migración de configuración fallida. No demuestra que WAF, VPN, HA o Reporting funcionen correctamente después de una actualización técnicamente exitosa.

Por ello, en mi prueba directa de MR2 mediré o provocaré los mismos puntos antes y después de la actualización:

• reinicio y arranque completo de los servicios
• inicio de sesión en WebAdmin y tiempo de respuesta de listas de reglas grandes
• flujo de registros local y externo
• tráfico IPsec, Rekey y failover
• Central Policy Push con comprobación en el firewall
• actualización de patrones para IPS y Application Control
• nuevo inicio de sesión STAS y comportamiento de una IP de cliente todavía desconocida
• sincronización HA y cambio de rol controlado, si el sistema de prueba es un clúster

Solo después podré decir si MR2 es realmente mejor en mi entorno. Una instalación correcta y una página verde en Control Center no son suficientes.

Qué dicen los primeros comentarios de la comunidad

El hilo de feedback se abrió el mismo día que MR2. En el momento de esta valoración solo tiene unas horas. De él no puede deducirse ni que MR2 sea estable ni que sea problemático.

Aun así, merece la pena mencionar dos debates:

• El operador de una XGS 5500 en HA Active-Passive pregunta expresamente por la profundidad de las pruebas porque NC-177467 le había afectado durante meses en MR1. Sophos enumera el error como corregido en MR2. La corrección afecta a un dispositivo Auxiliary que no arrancaba debido a un número muy elevado de intentos SSH no autenticados simultáneos.
• Respecto a las firmas PQC, un empleado de Sophos señala que están desactivadas deliberadamente. Como el uso de PQC-TLS aumenta en navegadores y aplicaciones, activarlas inmediatamente podría generar muchísimas alertas. La recomendación es empezar con Allow y registro, y solo más adelante, si resulta realmente necesario, aplicar una acción de bloqueo.

Es una fase inicial razonable para una versión nueva: pruebas concretas, Case ID y comentarios comprensibles en lugar de un «funciona» o «está roto» genérico. Seguiría observando el hilo durante los primeros días y semanas, especialmente en relación con HA, IPsec, WAF, STAS y Reporting.

Config Studio se convierte en el almacén de recambios para una interfaz antigua

Ahora viene la parte incómoda.

Config Studio 2.6 es una buena herramienta. Combinar plantillas, buscar objetos, resolver referencias en el informe, comparar varios estados de configuración y preparar migraciones de hardware son funciones administrativas reales. No critico que Sophos desarrolle estas funciones. Critico dónde las desarrolla.

Sophos ya menciona Config Studio directamente en las notas de la versión del firewall y en el anuncio oficial de MR2. De este modo parece cada vez más la respuesta estratégica a problemas que deberían resolverse en WebAdmin o Sophos Central.

La interfaz local del firewall sigue siendo antigua en el uso diario y a menudo lenta con configuraciones grandes. Los cambios masivos son insuficientes. Faltan directamente allí donde trabajan los administradores a diario las referencias de uso de objetos, una búsqueda global real, diffs limpios, clonación de NAT, conflictos de reglas y un flujo moderno de gestión de cambios. Sophos Central solo cubre una parte de esta carencia.

El problema no es solo el diseño. En mi opinión, una interfaz de firewall moderna necesita un proceso de cambios sólido:

• Candidate Configuration en vez de cambios individuales aplicados inmediatamente
• diffs completos del antes y el después antes del commit
• comprobación de dependencias entre objetos, reglas, NAT, VPN y TLS
• commit atómico o un estado claro de la transacción
• rollback validado al último estado conocido
• asignación real de usuario, hora y origen en el Audit Trail
• Bulk Operations con vista previa y comprobación de conflictos
• salida API coherente para reproducir cambios

Config Studio reconstruye partes de este proceso fuera del sistema. Analiza una exportación, genera XML o solicitudes API y ayuda con los diffs. Pero queda una brecha entre esta vista offline y el estado activo en tiempo de ejecución del firewall. Las sesiones, el routing dinámico, el estado HA, los patrones actuales, el estado de los certificados y la configuración realmente cargada no son lo mismo que un archivo Entities.xml abierto localmente.

Sería excesivo deducir de un anuncio de versión, como si fuera un hecho, que Sophos nunca volverá a modernizar a fondo la interfaz SFOS. No existe una declaración confirmada en ese sentido. Aun así, la señal es mala: los avances más visibles en manejo, búsqueda, comparación y trabajo con configuraciones vuelven a quedar fuera de las interfaces de administración propiamente dichas.

El flujo de trabajo permanece fragmentado:

1. Exportar la configuración del firewall.
2. Descomprimir el archivo y buscar Entities.xml.
3. Cargar el archivo en una herramienta separada del navegador.
4. Analizarlo, compararlo o editarlo allí.
5. Volver a exportar el resultado y devolverlo mediante XML, API o curl.

Para una auditoría es aceptable. Para una administración moderna, segura y trazable, es un rodeo. Resulta especialmente irritante que Config Studio no cubra únicamente un caso especial. Recibe precisamente esos cambios sencillos pero valiosos que los administradores de Sophos llevan años esperando.

Y aquí soy más crítico que hasta ahora: si Sophos presenta Config Studio como un tema importante en las notas normales de la versión del firewall, la herramienta externa ya no puede considerarse una pequeña ayuda adicional. Sophos la convierte visiblemente en parte de la estrategia administrativa. Eso aumenta también la presión para explicar por fin qué funciones se integrarán a largo plazo en WebAdmin o Central y cuáles permanecerán permanentemente en la herramienta del navegador.

Sin esta hoja de ruta surge la impresión de que la interfaz antigua, lenta y cada vez menos fácil de usar con configuraciones grandes permanecerá esencialmente igual, y que los administradores deberán utilizar Config Studio para los flujos de trabajo modernos. No es un plan confirmado por Sophos. Pero sí es la dirección que transmite actualmente el producto.

Por qué UniFi lo tiene tan fácil

UniFi no sustituye por completo a todos los Sophos Firewall. Según la licencia y la arquitectura, Sophos ofrece funciones de seguridad más profundas, IPS, Web Protection, WAF, integración con endpoints, conexión MDR/XDR y funciones Enterprise clásicas. Una comparación justa no puede ignorar estas diferencias.

Pero en la percepción de calidad del producto, la facilidad de uso gana todos los días.

Ubiquiti invierte visiblemente en diseño, aplicaciones móviles, navegación coherente, topología, integración sencilla de dispositivos y una interfaz comprensible incluso sin años de experiencia con el producto. No todas las funciones de UniFi tienen mayor profundidad técnica. Pero el producto parece más moderno, y esto influye en las decisiones de compra más de lo que los fabricantes tradicionales de firewalls quieren admitir.

Cuando un equipo de TI pequeño elige entre dos soluciones, no mira únicamente las fichas técnicas del IPS. También ve:

• ¿Con qué rapidez encuentro un dispositivo, una regla o un cliente?
• ¿Puedo revisar el entorno de forma útil desde el smartphone?
• ¿Entiendo las advertencias y dependencias sin conocimientos especializados?
• ¿Cuántos clics necesito para un cambio cotidiano?
• ¿Parece el producto una plataforma coherente o varias herramientas colocadas una junto a otra?

Es justo aquí donde Sophos facilita innecesariamente el trabajo a fabricantes como Ubiquiti. Sophos Firewall puede ofrecer más desde el punto de vista de seguridad y seguir siendo la solución más razonable para muchos entornos de pymes. Pero si los administradores necesitan abrir un Config Studio separado para disponer de búsqueda moderna, diffs, plantillas y cambios masivos mientras la interfaz principal sigue siendo antigua y lenta, Sophos pierde confianza en el nivel más visible.

Una buena seguridad no solo necesita un motor potente. Necesita una interfaz en la que las personas puedan comprender reglas, detectar errores y realizar cambios de forma segura. Por tanto, la facilidad de uso no es un extra cosmético, sino parte de la seguridad operativa.

Conclusión: instalar MR2, pero el problema del producto permanece

SFOS 22.0 MR2 no es una gran versión de funciones. Es una versión de mantenimiento importante con mejoras razonables.

El control PQC llega en el momento adecuado, pero primero debe introducirse en modo de observación. La mejor detección de aplicaciones de IA generativa ayuda con la visibilidad y las políticas, pero no sustituye una estrategia DLP o de gobierno de IA. Los administradores de Chromebooks deben desplegar activamente la nueva extensión Manifest V3. STAS será menos propenso a interrupciones, pero exige una revisión consciente de las reglas de identidad. Let’s Encrypt queda preparado para las próximas cadenas de certificados. Y las numerosas correcciones abordan varios problemas capaces de provocar interrupciones reales en entornos productivos.

Instalaré MR2 directamente después del backup y el preflight y, a continuación, probaré precisamente estas rutas de datos. En especial, quien esté afectado por los problemas mencionados de HA, VPN, Reporting, Central o failsafe tiene buenas razones para actualizar. En el día del lanzamiento todavía no puede responderse seriamente si la compilación 546 será realmente más estable o traerá nuevas regresiones.

Mi crítica, sin embargo, sigue siendo clara: Config Studio 2.6 es útil, pero su papel destacado en la versión del firewall refuerza la impresión de que Sophos está desplazando la administración moderna a una herramienta secundaria. No es el abandono confirmado de una nueva interfaz SFOS. Pero sí es una señal estratégica de advertencia.

Sophos tiene una base de firewall sólida. El fabricante debería proporcionar por fin a los administradores una experiencia de gestión acorde con esa base técnica. De lo contrario, plataformas más modernas no ganarán necesariamente por una seguridad mejor, sino porque se toman más en serio a la persona que está delante de la pantalla.

Hasta la próxima,
Joe

Preguntas frecuentes