Asegurar Sophos Firewall WAF con MFA

Con Sophos Firewall WAF MFA se pueden asegurar adicionalmente las aplicaciones web publicadas a través del Web Application Firewall con autenticación multifactor. Esto es especialmente útil para portales internos, interfaces de administración, áreas de clientes o accesos de socios que deben ser accesibles a través de HTTPS, pero que no deben estar protegidos solo por la aplicación en sí.

WAF-MFA no reemplaza una aplicación segura, gestión de parches ni un concepto de permisos limpio. Es una capa de protección previa en el firewall. El firewall verifica primero el inicio de sesión y el segundo factor antes de redirigir el acceso al servidor web protegido.

Para la publicación básica de un servidor web a través de WAF, primero consulte la guía Sophos Firewall WAF: Publicar servidores web de forma segura. Este artículo se centra en la autenticación previa y MFA.

Cuándo es útil WAF-MFA

WAF-MFA es especialmente potente cuando una aplicación web debe ser accesible desde Internet, pero no está destinada a todos los visitantes.

Casos de uso típicos:

portales internos con acceso externo
interfaces de administración de aplicaciones especializadas
portales de socios o clientes con un grupo de usuarios limitado
aplicaciones web heredadas sin MFA propia fuerte
aplicaciones donde se desea una protección de acceso adicional antes del backend

Para sitios web públicos, tiendas o páginas de información, WAF-MFA generalmente no es adecuado, ya que cada visitante vería primero un inicio de sesión en el firewall. En aplicaciones privadas complejas, ZTNA, SSE o un proxy inverso dedicado pueden ser más adecuados que WAF-MFA. Si se necesita WebDAV, se debe tener especial cuidado: Sophos WAF no admite WebDAV de manera adecuada, lo que puede ser relevante para aplicaciones como Nextcloud.

Cuándo WAF-MFA no es suficiente

WAF-MFA es una capa de acceso previa. Sin embargo, esta capa no responde a todas las preguntas de arquitectura. Especialmente en portales críticos, se debe decidir conscientemente si la aplicación debe ser accesible públicamente.

Situación	Mejor evaluación
La aplicación está destinada solo a unos pocos usuarios internos	Evaluar VPN, ZTNA, redes de origen fijas o una publicación no pública
La aplicación contiene datos especialmente sensibles	Evaluar permisos de backend, registro, auditoría y sesiones de aplicación adicionalmente
La aplicación necesita WebDAV o protocolos especiales	Probar la compatibilidad de WAF antes de la implementación o elegir otra arquitectura
Los socios externos acceden raramente	Documentar claramente la implementación de tokens, el proceso de soporte y el plan de contingencia
El backend tiene su propio inicio de sesión y roles	Considerar WAF-MFA solo como una capa adicional, no como un reemplazo de los roles de backend

Si un portal sigue siendo accesible mundialmente, MFA no debe ser la única medida. Redes de origen fijas, limitación por países, Threat Feeds, perfiles de protección y parches de backend limpios reducen el riesgo adicionalmente.

Requisitos previos

Antes de la configuración, se deben aclarar estos puntos:

La aplicación web ya está planificada o publicada a través de una regla WAF.
Los usuarios o grupos están presentes en el firewall, por ejemplo, localmente, a través de AD, LDAP o RADIUS.
Los usuarios pueden configurar su token OTP.
La hora del sistema del firewall es correcta y NTP funciona.
Se utiliza HTTPS con un certificado adecuado para la regla WAF.
Está claro si el servidor web de backend necesita autenticación propia o si el firewall debe asumir completamente el inicio de sesión.
Hay un usuario de prueba y un acceso administrativo de contingencia disponibles.

⚠️ MFA para WAF debe probarse primero con un grupo piloto. Una combinación incorrecta de grupo MFA, política de autenticación WAF y autenticación de backend puede bloquear a usuarios legítimos o hacer que una aplicación parezca “rota”.

Planificar piloto, contingencia y responsabilidades

WAF-MFA actúa antes de la aplicación real. Por lo tanto, no se debe tratar la implementación como una regla de firewall normal, sino como un cambio en el proceso de inicio de sesión de la aplicación. Los usuarios ven primero el inicio de sesión de Sophos Firewall y solo después, dependiendo del backend, la aplicación real.

Antes de activar, se deben establecer estos puntos:

¿Qué grupo de usuarios prueba primero?
¿Quién puede desactivar el acceso si el inicio de sesión falla?
¿Existe un segundo acceso de administrador que no dependa de la misma regla WAF, el mismo portal o el mismo usuario de prueba?
¿Qué partes de la aplicación deben probarse después de un inicio de sesión exitoso?
¿Quién revisa reverseproxy.log, Log Viewer y los registros de backend en caso de errores?
¿Cómo se informa a los usuarios sobre el token, el vencimiento de la sesión y un posible segundo inicio de sesión en el backend?

Un error común de planificación es mezclar la autenticación del firewall y la autenticación del backend. WAF puede verificar a los usuarios antes del backend. Sin embargo, esto no significa automáticamente que la aplicación en sí ya no necesite su propio inicio de sesión, verificación de roles o gestión de sesiones. Especialmente en portales de administración y datos de clientes, se debe mantener conscientemente la autorización del backend.

Si el servicio publicado está destinado solo a unas pocas personas, además de MFA, se deben restringir las fuentes. Para la publicación básica y la limitación de fuentes, consulte Sophos Firewall WAF: Publicar servidores web de forma segura. Si se planean derechos de usuario o MFA de acceso remoto en general, consulte Activar MFA para Sophos Firewall WebAdmin, VPN Portal y Remote Access.

Se debe preparar un rollback antes de la activación. Prácticamente, esto significa: documentar el método de acceso anterior que funcionaba, nombrar la regla WAF y la política de autenticación, designar a la persona responsable y elegir un momento en el que sea posible recibir comentarios de los usuarios y revisar los registros. Si la aplicación es crítica para el negocio, WAF-MFA debe activarse primero para un dominio de prueba, un grupo piloto o una ventana de mantenimiento.

Componentes de la configuración

Para WAF-MFA, varias configuraciones deben coincidir:

Componente	Propósito
Configuración de MFA	Define qué usuarios usan MFA y si se protege la Web application firewall
Política de autenticación WAF	Define el modo de inicio de sesión, usuarios/grupos, plantilla y comportamiento de sesión
Regla WAF	Vincula el servidor web publicado con la política de autenticación
Reenvío de autenticación de backend	Define si el firewall pasa las credenciales de inicio de sesión al servidor web
Implementación de tokens	Asegura que los usuarios puedan generar su código OTP realmente

La diferencia más importante: MFA no solo se activa globalmente. La regla WAF afectada también debe usar una política de autenticación adecuada.

Activar MFA para WAF

La ruta del menú es:

Authentication > Multi-factor authentication

Procedimiento:

En One-time password (OTP), seleccione All users o Specific users and groups.
En Specific users and groups, agregue los usuarios o grupos afectados.
Active Generate OTP token with next sign-in si los usuarios deben configurar su token en el próximo inicio de sesión.
En Require MFA for, active la opción Web application firewall.
Guarde la configuración.

Si los usuarios deben configurar su token por sí mismos, deben tener acceso a un portal donde se muestre el código QR. En muchos entornos, esto es relevante para el User Portal o VPN Portal. La planificación general de MFA se describe en Activar MFA para Sophos Firewall WebAdmin, VPN Portal y Remote Access.

Preparar implementación de tokens y comunicación con usuarios

WAF-MFA a menudo falla en la operación no por la regla WAF en sí, sino por la implementación de tokens. Los usuarios deben saber dónde aparece el código QR, qué aplicación usar, cuánto tiempo es válida una sesión y si después del inicio de sesión en el firewall sigue un segundo inicio de sesión en la aplicación.

Antes de activar la regla WAF productiva, se debe establecer:

Punto	Verificación
Creación de tokens	¿Dónde configura el usuario el token OTP?
Acceso al portal	¿Está el User Portal o VPN Portal accesible para los usuarios afectados?
Aplicación de autenticación	¿Qué aplicación está aprobada y probada con el algoritmo elegido?
Contingencia	¿Quién puede restablecer un token perdido o defectuoso?
Caso de soporte	¿Qué información necesita el helpdesk en caso de problemas de inicio de sesión?
Comunicación	¿Qué secuencia de inicio de sesión verán los usuarios a partir del Go-live?

Si se utiliza Generate OTP token with next sign-in, el primer inicio de sesión debe probarse de manera controlada. Es importante si los usuarios ven el código QR en el portal esperado y si luego pueden acceder con éxito a la aplicación WAF con contraseña más OTP. Los portales en sí se describen en Sophos Firewall Portales: WebAdmin, User Portal y VPN Portal.

Para el helpdesk y la operación, al menos debe estar documentado:

nombre de host publicado de la aplicación WAF
grupo de usuarios afectado
política de autenticación utilizada
algoritmo OTP utilizado
aplicación de autenticación permitida
procedimiento para restablecer tokens
mensaje esperado en caso de contraseña incorrecta o OTP incorrecto
ubicaciones de registro para la primera revisión: Log Viewer y reverseproxy.log

Especialmente con socios externos o portales poco utilizados, el primer inicio de sesión no debe ocurrir solo en una emergencia productiva. Un breve piloto con usuarios normales a menudo revela problemas que los administradores no ven en su propia prueba: aplicación de autenticación diferente, falta de acceso al portal, segundo inicio de sesión en el backend no claro o tiempos de espera de sesión que son demasiado cortos para la aplicación.

Crear política de autenticación WAF

La ruta del menú es:

Web server > Authentication policies

Para WAF-MFA, el modo de cliente debe establecerse en Form. Con la autenticación basada en formularios, el firewall puede controlar el inicio de sesión a través de un formulario y sesiones.

Procedimiento:

Abra Add.
Asigne un nombre descriptivo, por ejemplo, WAF_MFA_Portal_Users.
En Mode, seleccione la opción Form.
Seleccione una Authentication template adecuada.
Seleccione los usuarios o grupos que tendrán acceso a esta publicación WAF.
Elija conscientemente el Authentication forwarding mode.
Establezca Session timeout y Session lifetime de acuerdo con la aplicación.
Guarde.

Elegir correctamente el reenvío de autenticación

El Authentication forwarding mode decide qué sucede entre el firewall y el backend.

Modo	Uso
`None`	El firewall autentica al usuario, el servidor web no recibe credenciales de inicio de sesión
`Basic`	El firewall pasa el nombre de usuario y la contraseña al backend mediante HTTP Basic Authentication

Si la aplicación no necesita autenticación propia o el inicio de sesión previo del firewall es suficiente, None suele ser más limpio. Si el backend espera HTTP Basic Authentication, el modo de reenvío debe coincidir con la aplicación.

⚠️ Basic Authentication solo debe usarse con HTTPS. Además, debe estar claro si el backend realmente debe procesar las credenciales de inicio de sesión pasadas por el firewall.

Usar política de autenticación en la regla WAF

La regla WAF se edita en Rules and policies > Firewall rules. La acción es Protect with web server protection.

En la regla WAF afectada, estos puntos deben coincidir:

Dirección Hosted address y puerto de escucha correctos.
Dominio correcto y certificado HTTPS adecuado.
Servidor web protegido correcto.
Política de Authentication policy deseada seleccionada.
El grupo de usuarios en la política de autenticación coincide con el grupo MFA.
Las restricciones de acceso a través de Allowed client networks, países o Threat Feeds están establecidas conscientemente.

Para portales públicos o altamente expuestos, MFA no debe ser la única medida de protección. La limitación por países y fuentes se describe en Sophos Firewall: Bloquear países e IPs maliciosas. Para listas de bloqueo dinámicas, consulte Sophos Firewall Threat Feeds.

Planificar sesiones y tiempo de espera

Con la autenticación WAF basada en formularios, el firewall trabaja con sesiones. En la política de autenticación, se establece:

Session timeout: después de qué inactividad los usuarios deben volver a iniciar sesión
Session lifetime: cuánto tiempo es válida una sesión como máximo

Además, en Web server > General settings se encuentra el número máximo de sesiones simultáneas para la autenticación de proxy inverso basada en formularios. El valor predeterminado es 25,000, el rango admitido es de 100 a 100,000.

Las sesiones cortas aumentan la seguridad, pero pueden molestar a los usuarios. Las sesiones muy largas son más cómodas, pero aumentan el riesgo de que un acceso al navegador robado o compartido siga siendo utilizable por más tiempo. Para portales de administración, se debe comenzar de manera conservadora y observar el comportamiento en operación.

Algoritmo OTP y aplicación de autenticación

SFOS 22 admite, además de SHA1, SHA256 y SHA512 para tokens OTP. Esto es sensato desde el punto de vista de la seguridad, pero solo funciona si la aplicación de autenticación utilizada admite el algoritmo elegido.

Puntos importantes:

SHA256 o SHA512 son más seguros que SHA1.
No todas las aplicaciones de autenticación admiten estos algoritmos en este contexto.
Microsoft Authenticator puede escanear el código QR con SHA256 o SHA512, pero el inicio de sesión puede fallar después.
Si se cambia el algoritmo, los tokens antiguos deben eliminarse y escanearse nuevamente.

Para implementaciones productivas, se debe probar la aplicación deseada y el algoritmo con un pequeño grupo piloto. Solo después se deben migrar ampliamente los usuarios existentes.

Plan de pruebas después de la configuración

Después de la configuración, no solo se debe verificar si aparece la página de inicio de sesión. Es importante probar todo el camino de acceso.

Usar un navegador externo o una red de prueba externa.
Abrir la URL WAF con un usuario del grupo permitido.
Probar el inicio de sesión con contraseña correcta y OTP.
Probar el inicio de sesión con OTP incorrecto.
Probar con un usuario fuera del grupo permitido.
Verificar el vencimiento de la sesión después de la inactividad.
Verificar la función de backend de la aplicación.
Revisar Log Viewer y reverseproxy.log en busca de anomalías.

Para los archivos de registro, consulte Solución de problemas de Sophos Firewall: Servicios y registros. Los eventos de WAF suelen estar en el Reverse Proxy y también aparecen en el Log Viewer.

Para la aceptación, cada caso de prueba debe estar asociado a un resultado visible:

Vista	Lo que debería ser visible
Usuario	Aparece el inicio de sesión del firewall, se solicita OTP, luego se abre la aplicación esperada
Sophos Firewall	Log Viewer y `reverseproxy.log` muestran autenticación WAF permitida o denegada
Fuente de autenticación	AD, LDAP, RADIUS o fuente de usuario local muestra el inicio de sesión exitoso o fallido esperado
Backend	La aplicación alcanza el estado de usuario o invitado correcto y no muestra una segunda página de error inesperada

Si solo el navegador parece exitoso, pero no se ven registros correspondientes, la aceptación es incompleta. Entonces se debe verificar si la regla WAF correcta coincide, si la política de autenticación está realmente activa y si los registros llegan al lugar esperado.

Go-live y operación después de la activación

Después de una prueba exitosa, WAF-MFA no debe simplemente activarse ampliamente y luego olvidarse. Las primeras horas después del Go-live son importantes, ya que los usuarios reales traen otros navegadores, otras aplicaciones de autenticación, contraseñas guardadas, marcadores antiguos y otros estados de sesión que una prueba de administrador.

Para el Go-live, es útil un pequeño plan de operación:

Punto	Recomendación
Grupo de implementación	primero grupo piloto, luego otros grupos de usuarios
Ventana de soporte	Mantener el helpdesk o los administradores responsables disponibles durante los primeros inicios de sesión
Monitoreo	Observar Log Viewer, `reverseproxy.log` y fuente de autenticación
Restablecimiento de tokens	Procedimiento claro para tokens OTP perdidos o configurados incorrectamente
Comportamiento de sesión	Revisar tiempo de espera de sesión y duración de sesión según el uso real
Ruta de contingencia	Mantener documentada la regla WAF, la política de autenticación y los pasos de cambio

En aplicaciones críticas para el negocio, no se debe programar el Go-live en un momento en que nadie pueda verificar adecuadamente los problemas de inicio de sesión. Es mejor una ventana controlada con usuarios de prueba de diferentes grupos, luego una breve revisión de los registros y solo después la ampliación a más usuarios.

Después de algunos días, se debe revisar nuevamente la configuración:

¿Hay usuarios que evitan MFA porque acceden a través de otra regla WAF o URL diferente?
¿El acceso sigue estando permitido solo para los grupos planificados?
¿La duración de la sesión y el tiempo de espera por inactividad se ajustan a la aplicación?
¿Se ven realmente los inicios de sesión rechazados y los problemas de tokens en operación?
¿Hay casos de soporte que indiquen comunicación poco clara con los usuarios o una aplicación de autenticación incorrecta?
¿Se han eliminado las reglas de prueba antiguas, los dominios de prueba o las excepciones temporales?

Este seguimiento es especialmente importante si varios nombres de host, rutas o reglas WAF apuntan a la misma aplicación. De lo contrario, puede suceder que una ruta esté protegida adecuadamente con MFA, pero otra ruta siga siendo accesible sin autenticación previa.

Errores típicos

Error	Impacto
Web application firewall no activado en Require MFA for	El inicio de sesión WAF no solicita un segundo factor
La política de autenticación no usa Form	El comportamiento de MFA no coincide con la configuración WAF esperada
La regla WAF no utiliza una política de autenticación	Los usuarios acceden a la aplicación sin inicio de sesión previo
El grupo MFA y el grupo de la política WAF son diferentes	Los usuarios no son solicitados o rechazados como se esperaba
El backend espera su propia Basic Authentication, el reenvío está en `None`	El inicio de sesión en el firewall funciona, el backend rechaza el acceso
El reenvío está en `Basic`, el backend no espera autenticación	La aplicación reacciona de manera inesperada o ve encabezados innecesarios
La aplicación OTP no admite el algoritmo hash elegido	Se escanea el código QR, pero el inicio de sesión falla de todos modos
La duración de la sesión es demasiado larga	Los usuarios permanecen conectados más tiempo de lo deseado operativamente
El acceso de contingencia depende de la misma regla WAF	Los administradores no pueden revertir el cambio de manera adecuada en caso de error
La implementación de tokens no fue probada	Los usuarios fallan en el primer inicio de sesión, aunque la regla WAF es técnicamente correcta
Una segunda URL o regla WAF permanece activa sin MFA	Los usuarios evitan sin querer el MFA previo
Las excepciones temporales del piloto no se eliminan	La protección productiva es inconsistente y difícil de auditar

Solución de problemas

MFA no se solicita

Primero verifique si Web application firewall está activado en Require MFA for. Luego controle si la regla WAF realmente utiliza una política de autenticación y si esta política contiene los usuarios o grupos esperados.

El inicio de sesión funciona, pero la aplicación no se abre

Entonces el problema suele estar después del inicio de sesión en el firewall. Verifique la accesibilidad del backend, el certificado, el encabezado del host, la ruta, la política de protección y el reenvío de autenticación. Si el backend espera autenticación propia, el modo de reenvío debe coincidir.

El usuario no puede iniciar sesión después de cambiar el algoritmo

Si se cambió de SHA1 a SHA256 o SHA512, los tokens existentes deben eliminarse y escanearse nuevamente. Además, la aplicación de autenticación debe admitir el nuevo algoritmo.

La contraseña y el OTP se pasan al backend

En WAF-MFA, se debe verificar si la versión del firewall está actualizada. En las Notas de la versión de SFOS-22.0 se documenta un error de WAF corregido, donde el código OTP no se eliminó de la contraseña antes de pasar los datos al backend.

Demasiadas o viejas sesiones

Verifique el tiempo de espera de la sesión, la duración de la sesión y la configuración global de sesiones WAF. En entornos productivos, debe estar claro si se desean sesiones largas o si los usuarios deben autenticarse nuevamente rápidamente después de la inactividad.

Lista de verificación

La regla WAF está documentada y probada externamente.
El certificado HTTPS coincide con el nombre de host publicado.
MFA se aplica al grupo de usuarios correcto.
Require MFA for > Web application firewall está activado.
La política de autenticación WAF utiliza Form.
El reenvío de autenticación coincide con la aplicación de backend.
La implementación de tokens, el acceso al portal y el procedimiento del helpdesk están preparados.
El tiempo de espera de la sesión y la duración de la sesión están establecidos conscientemente.
La aplicación OTP y el algoritmo hash han sido probados.
El acceso de administrador de contingencia está disponible.
El rollback y la persona responsable están documentados.
La fuente de autenticación y el inicio de sesión de backend se han probado por separado.
Log Viewer y reverseproxy.log se revisaron después de la prueba.
La ventana de soporte del Go-live y el procedimiento de restablecimiento de tokens están establecidos.
Se han verificado los nombres de host alternativos, rutas y reglas WAF para evitar MFA.
Las excepciones temporales del piloto se eliminaron después de la implementación.

Preguntas frecuentes

¿Puede Sophos Firewall colocar MFA delante de una aplicación web?

Sí. A partir de SFOS 22, Sophos Firewall puede imponer MFA para servidores web protegidos por WAF. Para ello, se deben configurar MFA, la política de autenticación WAF y la regla WAF juntas.

¿Debe la política de autenticación WAF usar Form?

Para WAF-MFA, se debe usar el modo de cliente Form. La configuración depende de la política de autenticación basada en formularios, la plantilla de autenticación y la selección de usuarios o grupos.

¿Es suficiente WAF-MFA como protección para un portal público?

No. WAF-MFA es una protección adicional fuerte, pero no reemplaza una aplicación parcheada, un concepto de permisos, un registro ni una restricción de acceso. Para portales críticos, también se deben verificar las fuentes, los países, los Threat Feeds y la propia aplicación.

¿Qué aplicación de autenticación se debe usar?

La aplicación debe admitir el algoritmo OTP elegido. Con SHA256 o SHA512, se debe probar la aplicación antes de la implementación. Si los usuarios ya usan Microsoft Authenticator, se debe tener especial cuidado, porque pueden aparecer limitaciones con SHA256 y SHA512.

¿Dónde configuran los usuarios el token OTP?

Depende del diseño del portal y MFA. A menudo, la configuración inicial se realiza a través del User Portal o VPN Portal, si Generate OTP token with next sign-in está activo. Antes de la implementación, se debe verificar si los usuarios afectados pueden acceder a este portal y ver el código QR.

¿Dónde se ven los problemas de WAF-MFA en los registros?

El Log Viewer es el primer punto de referencia. Para un análisis más profundo, reverseproxy.log es relevante. Dependiendo de la fuente de autenticación, los registros de autenticación o RADIUS también pueden ser importantes.