Sophos Firewall v23: novedades y funciones explicadas

Sophos Firewall v23 aborda varias tareas que consumen tiempo en la administración diaria de un firewall: buscar reglas, identificar correctamente a los usuarios, planificar actualizaciones y averiguar por qué ha conmutado un clúster. La nueva versión principal incorpora para ello una API REST y un asistente de IA, además de mejoras en WAF, DNS y DHCP.

Estado de la versión: Como en años anteriores, la próxima versión principal comienza con una fase Early Access de Sophos Firewall v23 alrededor de octubre; este año empezó ya el 28 de septiembre de 2026. Este artículo se basa en EAP1. Algunas funciones y detalles todavía pueden cambiar antes de la versión definitiva.

Algunas novedades están disponibles directamente en el firewall; otras requieren Sophos Fusion o software adicional. Hay un requisito especialmente importante para la planificación: la nueva identificación de usuarios mediante Synchronized Security exige Sophos Endpoint en los dispositivos afectados y una licencia de Endpoint adecuada. Quien hasta ahora solo utilice Microsoft Defender u otra solución de protección de endpoints no obtendrá esta función simplemente actualizando el firewall, sino que tendría que introducir y licenciar Sophos Endpoint por separado. Si ya existen licencias de Sophos, el esfuerzo adicional dependerá del contrato vigente. Explicamos los requisitos de las demás funciones en sus respectivos apartados.

IA y automatización

API REST: automatizar la configuración del firewall

La nueva API REST permite que los scripts y las herramientas de administración lean y modifiquen la configuración directamente en el firewall. La autenticación se realiza mediante claves de API. Una especificación en formato OpenAPI 3.0 documenta las llamadas y los campos de datos disponibles, facilitando la integración en herramientas existentes. Se accede al propio firewall, con independencia de la API de Sophos Central para exportar e importar configuraciones.

Distribuir ajustes comunes entre varios firewalls ya era una idea central de Sophos Central Firewall Management. Los grupos de firewalls y las políticas superiores deberían permitir administrar estos cambios de forma centralizada. Sin embargo, en nuestra experiencia esto solo funciona parcialmente como necesitamos para una operación fiable. Para cambios recurrentes preferimos por ello nuestros propios scripts y procesos, cuyo desarrollo y resultado podemos controlar directamente. Precisamente para eso la nueva API REST resulta una incorporación útil.

Un ejemplo son los objetos de red para un servidor nuevo que deben existir en los firewalls de varias sedes. Un script puede comprobar primero si el objeto ya existe, realizar únicamente el cambio necesario y volver a leer después el valor guardado. El registro permite ver qué firewall se ha actualizado correctamente y dónde queda trabajo pendiente. Esto es especialmente útil si una sede no está accesible durante el cambio y debe actualizarse más tarde.

Las claves de API se administran en Administration > API access. Heredan los permisos del administrador asociado. Por eso conviene utilizar para las automatizaciones una cuenta propia con un perfil de permisos adecuado. También deben configurarse correctamente las direcciones de origen permitidas y el acceso de administración. Este acceso debería limitarse a los sistemas que realmente lo necesiten para sus tareas de gestión.

Allowed IP hosts: También en v23 solo se pueden autorizar aquí direcciones IP o redes. Sigue sin ser posible usar un FQDN, es decir, un nombre DNS completo. Para un servidor de automatización con una IP de salida fija no supone un problema. Pero si el script se ejecuta detrás de una conexión cuya IP pública cambia, no se puede añadir simplemente su nombre DNS como origen permitido. Entonces se necesita, por ejemplo, un punto de salida fijo o un acceso VPN controlado. Precisamente en una interfaz destinada a facilitar la automatización nos habría gustado más flexibilidad.

El REST API guide se abre desde la interfaz WebAdmin en Administration > API access. El enlace se encuentra arriba a la derecha de la lista de claves de API, junto a OpenAPI.yaml. La referencia pública de la API de Sophos Firewall describe los endpoints, los campos de datos y los primeros pasos de la autenticación. Para la implementación concreta, la referencia determinante es el archivo OpenAPI del build instalado en el firewall. Antes de sustituir automatizaciones XML existentes conviene comprobar si todas las funciones necesarias están cubiertas. La gestión de errores, los registros y un procedimiento de reversión probado siguen siendo necesarios también con una API moderna.

Asistente de IA para reglas de firewall

El nuevo asistente de Sophos Fusion responde preguntas sobre las reglas de firewall. Coloca los borradores de reglas desactivados al final de la tabla; la aprobación sigue correspondiendo al administrador.

Es una forma sensata de colaborar con la IA. Una petición como «Crea un borrador para permitir el acceso HTTPS desde la red de empleados al servidor web interno» puede adelantar trabajo. Antes de activarla, aun así, hay que tener claro a qué objetos concretos se refiere, si debe limitarse a determinados usuarios y qué controles de seguridad hacen falta.

La posición de la regla es especialmente importante. Una autorización correcta desde el punto de vista técnico puede no surtir efecto si antes coincide otra regla. A la inversa, una regla demasiado amplia situada muy arriba puede permitir más tráfico del previsto. Por tanto, el asistente no toma la decisión de seguridad por el administrador. Su valor está en preparar el trabajo sobre el conjunto de reglas y facilitar la búsqueda de relaciones.

Permitir o bloquear servicios de IA de forma selectiva

Para controlar el uso de la IA se añaden la categoría web Generative AI y filtros de aplicaciones relacionados con Sophos AI Defense.

En Diagnostics > URL category lookup se puede consultar la clasificación de un dominio. Para openai.com, el firewall muestra la categoría Generative AI. Esto ayuda al diagnosticar problemas: si un servicio de IA queda bloqueado inesperadamente, primero se puede comprobar su categoría y después la política web que le corresponde.

Para una empresa, una configuración útil empieza con una decisión sencilla: ¿qué servicios de IA están autorizados para cada tipo de trabajo? El equipo de desarrollo puede necesitar herramientas distintas de las del departamento de contabilidad. Solo a partir de esa decisión se puede definir una política de red adecuada.

Que un dominio esté permitido no indica, sin embargo, qué información puede introducirse en él. El control de acceso y la protección de datos son tareas distintas. Incluso con un servicio autorizado hacen falta reglas para los datos de clientes, el código fuente y los documentos confidenciales. Los filtros de red pueden apoyar estas normas organizativas, pero no sustituyen la revisión del contenido de cada prompt.

Administración de reglas y manejo de la interfaz

Nueva tabla para las reglas de firewall

La vista de Rules and policies > Firewall rules se ha rediseñado a fondo. En lugar de carpetas desplegables, Sophos presenta ahora las reglas en una tabla continua. La agrupación se mantiene, pero se muestra en la columna Group. Se añaden la búsqueda de texto libre, los filtros y una vista de columnas personalizable.

Esto resuelve una molestia de la interfaz anterior: después de editar y guardar una regla de firewall, el grupo volvía a cerrarse. Si se quería editar enseguida la siguiente regla del mismo grupo, había que abrir la carpeta de nuevo. Al modificar varias reglas seguidas resultaba innecesariamente engorroso. Con la pertenencia al grupo como columna ya no es necesario repetir ese paso.

Seleccionar y ordenar columnas

Mediante el icono de engranaje situado arriba a la derecha de la tabla se eligen las columnas visibles. Se pueden ocultar datos innecesarios, mostrar detalles adicionales y cambiar el orden de las columnas. También se pueden fijar columnas. Por ejemplo, el nombre de la regla puede permanecer visible mientras se recorre horizontalmente una tabla ancha.

Un detalle especialmente positivo: en nuestra prueba, la vista elegida seguía guardada tras cerrar sesión y volver a entrar. No hace falta recomponer la tabla en cada inicio de sesión.

Para una revisión rápida suelen bastar el nombre, grupo, acción, estado y tráfico. Para diagnosticar un problema interesan, en cambio, las redes de origen y destino, los servicios y el registro. Si, por ejemplo, hay que retirar el acceso a un servidor de aplicaciones antiguo, conviene ver directamente uno junto a otro los destinos de las reglas afectadas. No tener que abrir cada regla por separado ahorra tiempo y facilita la comparación.

Se pueden elegir las siguientes columnas. Sus nombres corresponden a la interfaz inglesa; aquí están agrupados por temas para facilitar la lectura:

• Regla y visión general: Name, Type, Group, ID, Features, Traffic (In/Out), Status, Action, Schedule, Description.
• Redes y servicios: Src networks, Src zones, Dst zones, Dst networks, Services.
• Usuarios y registros: Users, Exclude users from accounting, Web authentication for unknown users, Log.
• Funciones de protección y políticas: Email, Web policy, IPS policy, Application policy.
• Ancho de banda y priorización: Traffic shaping policy, Traffic shaping (applications), Traffic shaping (web category), DSCP marking.
• Security Heartbeat: Source HB, Block client with no source HB, Destination HB, Block client with no destination HB.
• Excepciones: Excluded source address, Excluded destination address, Excluded source zone, Excluded destination zone, Excluded service.

La vista anterior sigue disponible por ahora

El interruptor New design todavía permite volver a la vista anterior. Quien no se adapte a la nueva tabla cuenta, de momento, con esa alternativa. No está claro durante cuánto tiempo Sophos mantendrá ambas vistas en paralelo.

Reglas NAT: siguen sin agrupación ni clonación

Por desgracia, Sophos no ha trasladado la nueva vista a las reglas NAT. También en v23 se tratan de manera diferente: las reglas NAT no se pueden agrupar ni clonar. En las reglas de firewall sí es posible clonar, pero esa función sigue faltando en NAT.

Sería especialmente útil al publicar varios servicios similares. Si otro servidor web necesita casi la misma redirección, lo lógico sería copiar una regla NAT existente y ajustar después el destino y el servicio. En cambio, hay que crear la regla de nuevo. Esto lleva tiempo y aumenta el riesgo de que alguna de las demás opciones quede distinta sin querer.

Ya comentamos estas peticiones en nuestro artículo sobre Sophos Firewall v22. La nueva vista de reglas de firewall supone un avance bienvenido. Por eso resulta más decepcionante que la administración de NAT siga rezagada en funciones básicas de uso.

WebAdmin, número de serie y estado del clúster

La interfaz WebAdmin utiliza HTTP/2 para acelerar la transferencia de los elementos de las páginas. Además, el número de serie y el estado del clúster HA permanecen visibles al cambiar de página de configuración.

HTTP/2 puede ayudar a cargar páginas con muchos elementos, sobre todo en conexiones de mayor latencia. Sin embargo, que una vista concreta parezca más rápida también depende del procesamiento en el firewall. Una consulta lenta a la base de datos o el guardado de una configuración compleja no se aceleran por sí solos con otro protocolo de transporte. En mi primera prueba, la mejora de velocidad fue escasa: guardar una regla de firewall seguía tardando varios segundos.

La identidad visible del dispositivo tiene una ventaja inmediata: con varias sesiones de firewall abiertas, resulta más fácil comprobar en qué sistema se está trabajando. Antes de modificar un clúster HA conviene además mirar el papel y el estado de los dispositivos implicados.

Quien atienda varias instalaciones de clientes casi idénticas conoce esa breve duda antes de guardar un cambio. Un número de serie siempre visible facilita cotejar el dispositivo con el ticket sin salir de la página actual. Es un cambio pequeño con una utilidad muy concreta.

Alta disponibilidad: detectar antes y conmutar mejor

Estado del hardware como desencadenante

Además de las conexiones y los servicios, el clúster HA supervisa ahora el estado de ciertos componentes de hardware, entre ellos el SSD. Si su estado empeora, el clúster puede conmutar al otro firewall.

Un clúster HA solo puede reaccionar de forma útil si detecta el fallo. Un dispositivo puede seguir accesible por sus interfaces de red aunque ya tenga problemas internos. Por eso la supervisión adicional del hardware es importante para la operación.

Un SSD defectuoso puede, por ejemplo, perjudicar las operaciones de escritura mientras el enlace HA continúa funcionando. La supervisión exclusiva de las conexiones no detectaría el estado del disco. La vigilancia adicional del hardware interviene antes de que un nodo debilitado falle por completo.

Tras una conmutación así, la causa sigue requiriendo investigación. El segundo nodo mantiene el servicio, pero no repara el SSD averiado. El procedimiento operativo incluye revisar el dispositivo afectado, valorar la redundancia que queda y, si procede, sustituir el hardware.

Ventana de detección más corta

Gracias a la supervisión acelerada, el clúster HA detecta la caída del otro firewall en 300 ms, frente a los cuatro segundos anteriores.

Los 300 ms se refieren al tiempo necesario para que el firewall detecte la caída del otro dispositivo del clúster. Antes de que una aplicación vuelva a funcionar normalmente pueden ser necesarios otros pasos: el firewall restante debe asumir la operación, los equipos de red vecinos deben enviar el tráfico por la ruta correcta y las conexiones existentes deben continuar o restablecerse.

Por eso una prueba representativa debe observar algo más que un ping. Una llamada telefónica activa, una transferencia de archivos y una conexión VPN muestran efectos diferentes. Solo esas mediciones responden a la pregunta de si la conmutación es suficientemente rápida para los procesos de la organización.

Menos conmutaciones erróneas con carga elevada

Los dos firewalls intercambian periódicamente mensajes breves de estado, los llamados HA heartbeats. Ahora estos mensajes tienen prioridad y se procesan separados del tráfico de datos normal.

Así se aborda un problema con cargas altas: si un sistema está muy ocupado, una respuesta tardía puede parecer una caída. Una conmutación provocada por ello añade inestabilidad a un entorno ya exigido.

Por tanto, interesan dos situaciones en las pruebas de aceptación: ¿detecta el clúster una caída real y permanece estable con carga alta cuando ningún dispositivo ha fallado? Una prueba funcional en reposo solo responde a la primera parte.

Seguridad DNS, hotfixes y firmware

DNS over HTTPS y DNSSEC

El firewall puede ahora enviar consultas DNS cifradas mediante HTTPS a un resolvedor y validar respuestas DNS con DNSSEC. También resulta más sencillo activar Sophos DNS Protection.

Las dos tecnologías DNS resuelven problemas diferentes. DNS over HTTPS, o DoH, cifra el transporte hasta el resolvedor. DNSSEC permite verificar datos DNS firmados. Una conexión cifrada no confirma por sí sola la autenticidad de una respuesta DNS, y una firma válida no oculta la consulta a observadores del camino de transporte.

Antes de introducir estos cambios conviene entender el recorrido DNS actual. ¿Consulta el cliente al firewall, a un servidor DNS interno de Windows o directamente a un resolvedor público? Los espacios de nombres internos deben seguir resolviéndose en el lugar correcto. Para ello siguen siendo relevantes, por ejemplo, las DNS Request Routes.

Los navegadores con sus propios ajustes DoH también merecen atención. Si un cliente utiliza otro resolvedor, su recorrido DNS real puede diferir de la configuración central prevista. Por ello, la prueba funcional debe abarcar nombres internos, resolución externa y las decisiones de filtrado deseadas.

Hotfixes y actualizaciones de seguridad visibles

Al revisar la interfaz observamos otro cambio: bajo Backup & firmware vuelve a haber una sección propia para hotfixes. La pestaña se llama Hotfix: Security updates. Antes, el ajuste de hotfixes estaba en el apartado Firmware. Allí una casilla permitía decidir si debían instalarse automáticamente los hotfixes importantes. Después de desaparecer de la interfaz, los hotfixes vuelven a tener un lugar visible.

La nueva vista muestra el estado de las actualizaciones de seguridad. El antiguo interruptor de activación no aparece en la pantalla mostrada. Que el ajuste desapareciera temporalmente tampoco significa que el firewall hubiera dejado de recibir hotfixes: la instalación automática sigue existiendo como función.

Para qué sirven los hotfixes

Los hotfixes son correcciones específicas de problemas urgentes, especialmente vulnerabilidades de seguridad. Pueden distribuirse al margen de las versiones regulares del firmware. Así, una corrección importante no tiene que esperar al siguiente maintenance release ni a que la empresa programe una actualización completa del firmware.

Si, por ejemplo, se descubre una vulnerabilidad en un servicio de administración, un hotfix adecuado puede corregir el componente afectado. La instalación automática reduce el tiempo entre la publicación de la corrección y su aplicación en el firewall. Está activada de forma predeterminada y debería mantenerse activa durante la operación normal. Sin embargo, los hotfixes no sustituyen las actualizaciones habituales de firmware: estas también incluyen otras correcciones de errores, cambios en componentes y funciones nuevas.

Consultar directamente el estado de los parches

La interfaz muestra ahora qué vulnerabilidades se han corregido mediante hotfixes instalados. Cada entrada incluye el identificador CVE, la gravedad, la fecha de instalación y un enlace al aviso de seguridad correspondiente. Esta información también está disponible en los informes.

Esto ayuda con una pregunta operativa frecuente: ¿se ha tratado ya una vulnerabilidad concreta en este firewall? Un número de versión del firmware no siempre cuenta toda la historia si también se han distribuido hotfixes.

Si un cliente pregunta por un nuevo aviso de seguridad, el estado local puede documentarse con mayor precisión. En lugar de deducir la protección únicamente de la versión del firmware, se puede consultar la CVE afectada y la fecha de instalación del hotfix y registrarlas en el ticket.

Para la documentación hay que evaluar el estado de los parches junto con el aviso correspondiente. Un parche instalado responde a la pregunta sobre esa corrección concreta. No demuestra que todo el sistema esté configurado de forma segura ni descarta un ataque anterior. Para ello siguen haciendo falta una revisión de la configuración, un análisis de los registros y, en su caso, una investigación.

Actualizaciones periódicas del firmware

En Sophos Fusion se pueden establecer ventanas de mantenimiento recurrentes en las que los firewalls instalan automáticamente nuevas versiones del firmware. Los dispositivos no tienen que actualizarse todos a la vez. Se pueden actualizar primero algunos firewalls seleccionados y dejar el resto para más tarde. Es posible configurar excepciones para dispositivos concretos, por ejemplo si una sede necesita una ventana de mantenimiento propia.

Esto resulta especialmente útil con varias sucursales. Por ejemplo, primero recibe la actualización el firewall de una oficina pequeña. Después se comprueban allí las conexiones VPN, los inicios de sesión de usuarios y los servicios publicados. Solo cuando esas comprobaciones tienen éxito se continúa con las demás sedes. Así no hace falta iniciar cada instalación por separado y se conserva el control de la secuencia.

Antes debe quedar claro quién comprueba los resultados y detiene las siguientes actualizaciones si aparecen problemas. Una instalación automática no sustituye una copia de seguridad ni un procedimiento de reversión preparado. Los pasos necesarios se describen en nuestras guías sobre actualizaciones de firmware y copia de seguridad y restauración.

Identidad e inicio de sesión

Entra ID con Synchronized User ID

Mediante Synchronized Security, el firewall también puede identificar ahora a usuarios que trabajan con Entra ID. Así pueden coexistir dispositivos unidos al AD local y equipos con identidad en la nube. La identificación requiere Sophos Endpoint en los dispositivos afectados y una licencia de Endpoint adecuada.

La pregunta práctica es cómo sabe el firewall qué usuario hay detrás de una conexión. Una dirección IP por sí sola no siempre basta para una regla basada en usuarios que tenga sentido. Al pasar de un dominio local a una identidad en la nube, esta asociación debe seguir funcionando de forma fiable.

Un caso habitual es el de una empresa que solo une los portátiles nuevos a Entra ID, mientras los antiguos siguen en el dominio AD local. Para la política web de contabilidad, esta transición técnica no debería marcar ninguna diferencia: lo determinante es el grupo del usuario. Esa continuidad es importante en una migración gradual a la nube.

Para la planificación conviene distinguir esta función del inicio de sesión con Entra ID que ya existía en el Captive Portal. Aquí se trata de la interacción con Sophos Endpoint. Tener un entorno Entra ID no implica, por sí solo, que el firewall pueda identificar adecuadamente a los usuarios. En una prueba piloto hay que comprobar qué usuario aparece realmente y qué regla de grupo se aplica después.

Google Workspace como proveedor de identidad

Los usuarios pueden iniciar sesión con su cuenta de Google Workspace en Captive Portal, VPN Portal, Sophos Connect y la interfaz WebAdmin. Google Workspace actúa como proveedor de identidad y también puede exigir autenticación multifactor durante el inicio de sesión.

Para organizaciones que utilizan Google como directorio central de usuarios, es una incorporación importante. Las cuentas y las condiciones de acceso deberían gestionarse, siempre que sea posible, donde también se administran los demás accesos de la organización.

Por ejemplo, una escuela con Google Workspace no necesita mantener un conjunto independiente de contraseñas en el firewall para el acceso VPN del profesorado. Eso reduce la administración duplicada y facilita proteger el inicio de sesión mediante el proveedor de identidad central.

No obstante, autenticarse correctamente es solo una parte de la integración. Después deben asignarse los permisos adecuados. Un empleado normal no debe obtener acceso de administración solo porque funciona el SSO. Por eso la prueba debe abarcar los atributos de usuario, la asignación de grupos, los servicios permitidos y la revocación de permisos.

Configuración de MFA por correo electrónico

El firewall puede enviar por correo electrónico el código QR necesario para configurar la autenticación multifactor. Si el registro no se completa en 24 horas, el código no utilizado caduca. En las instalaciones existentes permanece disponible inicialmente el procedimiento anterior mediante el portal.

Esto modifica el proceso de alta de nuevos usuarios. Antes del despliegue conviene comprobar las direcciones de correo y la entrega de mensajes. De lo contrario, el primer acceso VPN puede convertirse en un caso de soporte aunque la autenticación en sí esté bien configurada.

Un código QR de registro contiene información sensible para la seguridad, por lo que el buzón receptor también debe estar protegido. El servicio de asistencia necesita además un procedimiento claro para registros caducados y direcciones incorrectas. El reenvío de un código no debe hacer que se omita la comprobación de identidad de quien lo solicita.

SSO para Chromebook

Una nueva extensión para Chromebooks permite transmitir al firewall el inicio de sesión del usuario sin que este tenga que volver a autenticarse en Captive Portal. La extensión es compatible con todas las versiones de SFOS que siguen teniendo soporte.

Los inicios de sesión repetidos en el portal son especialmente molestos en las escuelas. Allí, sin embargo, no importa solo el primer acceso correcto, sino también el cambio de usuarios y dispositivos. Una prueba con Chromebooks compartidos debe demostrar que, tras un cambio de usuario, no se sigue utilizando una asociación anterior.

Como la extensión está diseñada para funcionar con varias versiones, conviene planificar su implantación por separado de la actualización a v23. Desplegar al mismo tiempo un nuevo componente de cliente y un nuevo firmware de firewall dificulta localizar posibles errores.

Servidores de terminal: identificación de usuarios con XDR Sensor

Para Sophos Authentication for Thin Client, o SATC, se puede utilizar un XDR Sensor ligero. Ayuda al firewall a atribuir el tráfico de red de un servidor compartido a cada usuario y puede funcionar junto a una solución de protección de endpoints ya existente.

En un servidor de terminal, muchas sesiones comparten la misma IP del servidor. Una autorización basada en IP no distingue, por tanto, entre el departamento de contabilidad y un colaborador externo en el mismo equipo. Para aplicar reglas web o de firewall basadas en usuarios hace falta una asociación adicional.

La posibilidad de usar un sensor junto a un producto de protección existente es interesante para entornos mixtos. Pero eso no equivale a una garantía general de compatibilidad para cualquier combinación. Deben comprobarse de antemano la licencia, el sistema operativo y la interoperabilidad admitida. La prueba funcional debería incluir al menos dos usuarios conectados simultáneamente a los que se apliquen reglas diferentes. Los efectos sobre el propio servidor de terminal deben valorarse por separado de las decisiones del firewall.

WAF: más control sobre aplicaciones publicadas

Acciones distintas para cada ruta URL

El Web Application Firewall incorpora acciones por ruta: Protect, Block, Redirect y Passthrough. Esta última sirve para WebSockets sin inspección WAF.

Con Protect, la ruta sigue bajo inspección WAF. Block rechaza el acceso con HTTP 403. Redirect envía el navegador a otra dirección. Passthrough constituye así una excepción deliberada para el tráfico WebSocket correspondiente, no una capa de inspección adicional.

Esto permite adaptar mejor el tratamiento de una aplicación a su estructura. Tras cambiar de portal, por ejemplo, /altes-portal podría redirigir a /kundenportal, mientras una zona retirada bajo /legacy se bloquea con HTTP 403. La parte principal de la aplicación permanece bajo inspección WAF. Gestionar estas decisiones directamente en el punto de acceso frontal puede reducir los cambios necesarios en el backend.

En las redirecciones, el destino debe ser preciso. Una ruta incorrecta puede romper el proceso de inicio de sesión o los enlaces guardados; una redirección poco meditada puede crear bucles. Si se establece una excepción sin inspección WAF, debe quedar claro qué protección mantiene la propia aplicación. Que la conexión funcione no demuestra que exista una inspección de seguridad equivalente.

Más rutas y reglas

Se admiten hasta 128 rutas por entrada de ruta. El límite de reglas WAF es 100 de forma predeterminada y puede elevarse a 200.

En la planificación hay que considerar por separado el límite de reglas y la capacidad de rendimiento. Poder configurar más reglas no significa que un appliance pueda atender un número arbitrario de aplicaciones activas con el mismo tiempo de respuesta. El procesamiento TLS, la inspección, las cargas de archivos y la velocidad de los servidores backend también determinan el consumo de recursos.

Una prueba de aceptación útil debe utilizar, por ello, solicitudes típicas de las aplicaciones reales. Una página de prueba estática, por ejemplo, representa mal un portal con cargas de archivos grandes.

Nuevo procesamiento con Apache Event MPM

El WAF pasa a utilizar Apache Event MPM para gestionar mejor las solicitudes simultáneas.

De forma simplificada, se trata de aprovechar mejor la capacidad de trabajo mientras determinadas conexiones esperan a que continúe su procesamiento. Con muchos accesos simultáneos, esa distribución es decisiva: no todas las conexiones abiertas deberían ocupar innecesariamente recursos que hacen falta para otras solicitudes. La capacidad del backend sigue siendo un límite independiente.

El indicador operativo decisivo es el comportamiento con carga. Una aplicación puede seguir técnicamente accesible y, aun así, responder tan despacio que los usuarios abandonen su trabajo. En las pruebas de carga deben evaluarse, además de las conexiones exitosas, los tiempos de respuesta y las tasas de error.

Para una comparación válida antes y después, el hardware, el perfil de seguridad, el backend y el tráfico de prueba deben mantenerse iguales. Solo entonces puede valorarse qué diferencia aporta el nuevo procesamiento en el entorno propio. Del cambio de arquitectura, por sí solo, no se puede derivar una cifra de rendimiento universal.

DHCP, enrutamiento y servicios de red

DHCP en el nuevo plano de control

El servicio DHCP se ejecuta ahora en el nuevo plano de control y puede gestionar rangos de direcciones más grandes y más reservas. Además, el firewall inspecciona el tráfico DHCP antes de que llegue al servicio para limitar los efectos de una avalancha de solicitudes. Los ajustes que antes requerían la línea de comandos ahora están disponibles en la interfaz.

Esto afecta a una dependencia básica de la red. Si los clientes no reciben una dirección, muchos otros servicios también parecen fallar. Por eso, tras una actualización, el servidor DHCP merece una comprobación tan consciente como la VPN o el acceso a internet.

La ampliación de capacidad resulta relevante, por ejemplo, en una escuela cuando muchos dispositivos se conectan al Wi-Fi casi a la vez por la mañana y solicitan una dirección. Para los usuarios, una asignación lenta parece rápidamente un problema de Wi-Fi. Procesar las concesiones con rapidez ayuda en un punto que puede pasarse por alto durante el diagnóstico.

Las pruebas deben incluir concesiones nuevas, renovaciones de concesiones existentes y direcciones reservadas. También deben ser correctos los valores entregados, como la puerta de enlace, los servidores DNS y las opciones DHCP individuales. Los ajustes utilizados con poca frecuencia a menudo solo se descubren cuando se reinicia un dispositivo especial.

También se ha revisado la consulta de direcciones asignadas. Las opciones DHCP se procesan de forma más uniforme conforme a los estándares subyacentes. Por eso, las configuraciones especiales existentes merecen una comparación específica antes y después de actualizar.

Entre los ajustes trasladados a la interfaz están las confirmaciones negativas y la limitación a una concesión por cliente. Una confirmación negativa indica al cliente que no puede utilizar una dirección solicitada y que debe negociar de nuevo su configuración de red. Estos ajustes deben valorarse en función del diseño de la red, sobre todo si intervienen varios servicios DHCP.

Reflector mDNS para Bonjour y detección de dispositivos

El reflector mDNS permite que los dispositivos descubran servicios en otras redes seleccionadas. Funciona tanto con IPv4 como con IPv6. Para establecer después una conexión con el dispositivo descubierto sigue haciendo falta una regla de firewall adecuada.

Esto es relevante, por ejemplo, si las impresoras y los empleados están en VLAN diferentes. La impresora puede tener una dirección correcta y ser accesible en principio, pero no aparecer en la búsqueda automática de dispositivos. La detección del servicio y la posterior conexión de datos son dos pasos distintos.

En la configuración solo deben autorizarse los pares de redes y los servicios necesarios. Una red de invitados no tiene por qué descubrir todos los dispositivos de la infraestructura interna. Tras la instalación, conviene probar tanto el comportamiento deseado como el límite: se encuentra y se puede utilizar la impresora prevista, mientras otros servicios internos siguen siendo inaccesibles.

Motor de enrutamiento y BFD experimental

El firewall utiliza una versión actualizada del software de enrutamiento FRR. Los distintos protocolos de enrutamiento se pueden administrar desde una consola común. Se añade compatibilidad experimental con BFD para BGP y rutas estáticas en firewalls independientes.

BFD, siglas de Bidirectional Forwarding Detection, sirve para detectar rápidamente una conexión caída entre vecinos de enrutamiento. Su cometido es distinto de la conmutación de roles en un clúster HA de firewalls. Detectar antes un fallo puede ayudar a dirigir el tráfico antes por una ruta alternativa.

Los intervalos de supervisión muy cortos no son un fin en sí mismos. Si el equipo remoto o el camino de transporte no responde de forma fiable bajo carga, una configuración agresiva puede provocar cambios de estado innecesarios. Por eso hay que tomarse en serio su carácter experimental y evaluar BFD primero en un entorno de pruebas adecuado.

Esto puede interesar, por ejemplo, con dos conexiones enrutadas entre sedes: si la interfaz local sigue activa aunque el vecino ya no sea accesible por la ruta preferida, el estado del enlace no basta para detectar el fallo. Una integración BFD adecuada puede ayudar a reconocerlo antes en una arquitectura así.

IPv6 IPoE y 4in6

El firewall admite más variantes de conexión mediante IPv6 IPoE y túneles 4in6. Entre ellas se encuentra el servicio de internet japonés Xpass.

Con 4in6, el tráfico IPv4 se transporta a través de una conexión IPv6. Estas funciones resultan pertinentes principalmente cuando el proveedor de internet exige precisamente ese modelo de conexión. Para una conexión convencional no constituyen, por sí solas, motivo para rediseñar la configuración WAN.

Las mejoras afectan también a las direcciones dinámicas, los extremos de los túneles y MTU/MSS. Su interacción es importante para el diagnóstico: que un túnel se establezca correctamente no garantiza que los paquetes grandes o todas las aplicaciones funcionen bien. Por ello, los parámetros del proveedor, la resolución de nombres y los tamaños de paquete deben comprobarse conjuntamente.

Despliegue en IONOS Cloud

Sophos Firewall también puede ejecutarse ahora en IONOS Cloud con la imagen oficial de SFOS. La instalación es manual mediante una imagen propia, no a través de una entrada lista para usar en Marketplace.

Para diseñar la arquitectura aún hay que definir cómo se conectan las redes públicas e internas, cómo se protege el acceso de administración y quién se encarga del ciclo de vida de la máquina virtual. Un destino de instalación compatible no resuelve por sí solo las cuestiones de redundancia, recuperación y supervisión.

En particular, el modelo operativo no debería dar por supuestas funciones propias de un servicio en la nube completamente administrado. Un firewall virtual también necesita mantenimiento planificado y copias de seguridad comprobables.

Alertas de amenazas y cambios menores

Alertas NDR sin aislamiento automático

Las detecciones de NDR Essentials y NDR Active Threat Intelligence pueden generar una alerta sin aislar automáticamente de la red el endpoint afectado.

Así se separan con mayor claridad la detección y la respuesta. Puede ayudar al introducir nuevas fuentes de detección: primero se evalúa la calidad de las alertas y después se decide qué sucesos deben desencadenar un bloqueo. Nuestro artículo sobre NDR Active Threat Intelligence explica las diferencias entre los métodos.

Una alerta por sí sola solo sirve si se atiende. Deben definirse la responsabilidad, el tiempo de respuesta y la vía de escalado. Además, hay que comprobar por separado qué acciones de bloqueo siguen configuradas en Active Threat Response. Un cambio en la forma de alertar no implica que se hayan desactivado todas las medidas de protección.

Listas de contenido de correo y categorías web

Otros cambios afectan a las referencias basadas en ID para listas de contenido de correo y a la gestión de versiones de las categorías web.

En las listas de contenido de correo, las Content Control Lists, esto separa la referencia del nombre visible. El nombre orienta a las personas; un ID estable asegura una asociación inequívoca. En cambio, la gestión de versiones de las categorías web afecta a la coordinación en segundo plano de las definiciones de categorías utilizadas con Sophos.

Estos puntos son menos visibles que una interfaz nueva, pero forman parte de una descripción completa de la versión. Al modificar o restaurar una configuración, es importante que una política siga utilizando el objeto previsto. En el filtrado web, por su parte, las páginas de prueba conocidas, tanto permitidas como bloqueadas, deberían seguir recibiendo la decisión esperada tras una actualización.

eDirectory deja de ser compatible

Sophos Firewall v23 ya no admite el tipo de servidor eDirectory nativo. Por ello, una conexión eDirectory todavía presente impide la actualización. Como alternativas se pueden utilizar Entra ID SSO, Active Directory, RADIUS o una conexión LDAP al servidor eDirectory existente.

Aquí es importante distinguir entre autenticación e identificación automática de usuarios: LDAP puede autenticar usuarios frente al directorio existente, pero no sustituye el SSO nativo de eDirectory. La conexión eDirectory anterior tampoco se conserva al restaurar una copia de seguridad o importar una configuración.

Describimos la migración y sus efectos sobre usuarios, grupos y servicios en nuestra guía Sophos Firewall: migrar eDirectory antes de SFOS 23.

Conclusión

Para mí, la API REST es una de las novedades más útiles de Sophos Firewall v23. Facilita cambios recurrentes y ofrece una buena base para analizar configuraciones con herramientas propias. Las API también ayudan en el análisis con IA: permiten leer reglas y objetos de forma estructurada, compararlos y detectar anomalías. Sigue siendo un administrador quien debe decidir qué cambios se hacen a partir de ello. Pero solo recopilar y preparar esa información ya puede ahorrar mucho trabajo manual.

También me gusta la nueva vista general de reglas de firewall. La pertenencia al grupo como columna, los detalles libremente seleccionables y la vista que permanece guardada hacen más cómodo el trabajo. Es una lástima que esa renovación no haya llegado también a las reglas NAT. Allí siguen faltando la agrupación y la clonación, aunque ambas funciones serían útiles al crear y mantener configuraciones grandes.

Además, me habría gustado ver directamente en el firewall más funciones de Sophos Firewall Config Studio: comparar varias versiones de una configuración, fusionar plantillas de configuración e informes que, para las reglas de firewall, NAT y TLS, muestren también los valores de los objetos referenciados. Estas herramientas ayudan a comprender y preparar los cambios. Por ahora siguen reservadas al Config Studio independiente.

En cuanto a la velocidad, mi primera prueba no mostró ninguna mejora importante. Guardar una regla de firewall sigue llevando varios segundos. En un único cambio tiene poca importancia. Pero al ordenar un conjunto de reglas y editar muchas seguidas, las esperas se acumulan e interrumpen constantemente el trabajo. Las mejoras de la interfaz son bienvenidas. Para la operación diaria me gustaría, sobre todo, que las tareas frecuentes fueran más rápidas y que las reglas de firewall y NAT pudieran administrarse de forma más uniforme.

FAQ

Fuentes

• Sophos Firewall v23: anuncio de la versión, publicado el 28 de septiembre de 2026.
• Sophos Firewall OS v23: Key New Features, guía técnica de funciones, a fecha de 28 de septiembre de 2026.
• Sophos Firewall v23: comentarios y experiencias, comentarios continuos de la comunidad.