Sophos Firewall WAF: Publicar servidores web de forma segura

Con Web Server Protection o Web Application Firewall (WAF) se publican aplicaciones web internas o basadas en la nube a través de Sophos Firewall. El firewall actúa como un Proxy Inverso: los clientes se conectan a la dirección pública del firewall, el firewall inspecciona el tráfico HTTP o HTTPS y reenvía la solicitud al servidor web protegido.

Para el contexto general de hardening, sirve el hub Sophos Firewall Hardening: buenas prácticas para una configuración segura.

Una regla WAF no reemplaza automáticamente el desarrollo seguro de aplicaciones, el parcheo, la autenticación fuerte o el endurecimiento del servidor. Sin embargo, en comparación con una simple redirección de puertos, reduce significativamente la superficie de ataque, ya que el tráfico HTTP(S) puede ser inspeccionado, restringido y registrado de manera más específica.

Aun así, WAF no es automáticamente la respuesta correcta para cada publicación. Lo crucial es si la aplicación realmente funciona bien sobre HTTP o HTTPS, si el firewall debe evaluar nombres de host y rutas, y si la capa adicional de Proxy Inverso se adapta a la aplicación.

Decisión antes de publicar

Cuándo es conveniente usar WAF en lugar de DNAT

Para servicios TCP o UDP simples, se sigue utilizando NAT y reglas de firewall. Para aplicaciones web, WAF suele ser la mejor opción.

• DNAT encaja para servicios no HTTP, redirecciones de puertos simples y protocolos especiales. En ese caso, el firewall traduce y permite principalmente el tráfico.
• WAF / Web Server Protection encaja para aplicaciones HTTP y HTTPS cuando son relevantes nombre de host, certificado, rutas, perfiles de protección, autenticación o reglas de país.
• Reverse Proxy o ZTNA encaja para plataformas web complejas, integración de identidad y aplicaciones privadas cuando el acceso debe estar muy controlado o no debe ser público.

Si solo se necesita hacer accesible rápidamente un servidor web interno mediante redirección de puertos, la guía Publicar servidor mediante DNAT en Sophos Firewall puede ser útil. Para aplicaciones web públicas, se debe considerar primero WAF.

⚠️ Sophos WAF no soporta WebDAV. Por lo tanto, aplicaciones como Nextcloud no deben publicarse ciegamente a través de WAF, sino planificarse mediante reglas de firewall y NAT adecuadas u otra arquitectura de publicación.

Decisión: WAF, DNAT o acceso privado

La pregunta más importante no es cuán rápido se puede construir una publicación, sino si se puede operar, probar y desmantelar de manera segura más adelante. Esta clasificación ayuda antes de la implementación técnica:

• Sitio web público o aplicación HTTPS simple: WAF suele ser el punto de partida adecuado. DNS, certificado, nombre de host, perfil de protección, logging y accesibilidad del backend deben probarse.
• Portal de clientes, portal de socios o interfaz de administración: WAF con limitación de origen y opcionalmente MFA puede tener sentido. Antes debe aclararse si son posibles WAF-MFA, reglas de país o redes de origen fijas.
• Servicio TCP o UDP puro: DNAT suele encajar mejor. Regla de firewall, regla NAT, servidor de destino, ruta de retorno y logging deben revisarse conjuntamente.
• Aplicación web con WebDAV o protocolo especial: no usar WAF automáticamente. Probar funciones soportadas, comportamiento del cliente y publicación alternativa.
• Aplicación solo para usuarios internos: revisar VPN, ZTNA o WAF fuertemente restringido. La accesibilidad pública debe cuestionarse críticamente.

Para aplicaciones privadas, una regla WAF accesible mundialmente a menudo representa demasiada superficie de ataque. Si solo unas pocas personas necesitan acceso, redes de origen fijas, VPN, ZTNA u otra arquitectura de acceso privado suelen ser más limpias que una publicación web pública.

Planificación y requisitos previos

Requisitos previos

Antes de la primera regla WAF, se deben aclarar estos puntos:

• Nombre DNS público, por ejemplo, portal.example.com
• Dirección IP pública o alias en la interfaz WAN
• Certificado para el nombre de host publicado
• Dirección IP interna o FQDN del servidor web
• Puerto de destino interno del servidor web
• Decisión sobre si HTTP se redirigirá a HTTPS
• Redes de origen permitidas, países o grupos de usuarios
• Perfil de protección adecuado y política IPS opcional
• Registro activado para análisis posterior
• Acceso de prueba externo fuera de la propia LAN

El nombre DNS público debe apuntar a la dirección utilizada en la regla WAF como Hosted address. En HTTPS, el certificado debe coincidir con el nombre de host publicado.

Además, el firewall necesita un objeto de servidor web en Web server > Web servers. Allí se describe el servidor de destino interno o externo con host, protocolo y puerto. El host es un objeto IP o FQDN. Para backends se puede usar HTTP o HTTPS; los puertos estándar son 80 y 443. Si el servidor web backend entrega respuestas largas o necesita keep-alive, Keep alive y Timeout deben revisarse de forma consciente y no heredarse al azar.

El Timeout del backend admite de 1 a 65,535 segundos; el valor predeterminado es 300 segundos. Cuando vence, WAF envía 502 al cliente. Disable backend connection pooling fuerza una nueva conexión al backend para cada solicitud y puede reducir el rendimiento. Esta opción solo debe usarse para una resolución de problemas específica y después debe restaurarse el estado anterior documentado.

Además, se deben considerar pronto los límites de Web Server Protection. Sophos menciona, entre otros, un límite de 60 reglas WAF por firewall. Esto basta para muchos entornos, pero puede volverse relevante antes de lo esperado con muchos portales de clientes, tenants, sistemas de prueba o hostnames separados. Entonces no se deberían crear más reglas individuales sin pensar, sino revisar concepto de nombres, rutas, servidores web virtuales y vías alternativas de publicación.

SFOS 22 no admite reglas WAF mediante IPv6. Por eso, una aplicación no debe planificarse como publicación IPv6 con esta función; el resumen Compatibilidad y límites de IPv6 en Sophos Firewall con SFOS 22 diferencia WAF de las funciones IPv6 compatibles para reglas y protección. Las plantillas de Exchange tampoco son una autorización general para entornos Exchange modernos: Sophos documenta que las reglas WAF actualmente no soportan versiones de Exchange posteriores a 2013.

Las plantillas preconfiguradas proceden de un panorama de aplicaciones Microsoft más antiguo: Exchange Autodiscover, Outlook Anywhere y Exchange General terminan en este límite de Exchange 2013; las demás guías de Sophos citan Microsoft Lync, Remote Desktop Gateway o RD Web 2008/R2 y SharePoint 2010/2013. Por tanto, no son una referencia actual para Microsoft 365, versiones modernas de Exchange, Teams ni implementaciones RDS actuales. Antes de utilizar una plantilla, se comparan las rutas, los métodos de autenticación y las políticas de protección realmente necesarios con la arquitectura actual de Microsoft; para una aplicación moderna, Preconfigured template se deja en None en caso de duda.

Planificar la liberación de WAF antes de la configuración

Una regla WAF no debe planificarse solo en la interfaz. Antes debe estar claro si Sophos Firewall solo debe publicar o si también debe encargarse de la autenticación, perfiles de protección, reglas de país y registro.

Estas preguntas son importantes antes de una publicación productiva:

• ¿Es realmente una aplicación HTTP o HTTPS? Para otros protocolos, DNAT suele ser más adecuado.
• ¿Debe la aplicación ser accesible públicamente? Los portales de administración privados suelen encajar mejor con VPN, ZTNA o redes de origen restringidas.
• ¿Qué nombre de host y certificado se usarán? DNS, SNI, certificado y dominios WAF deben coincidir.
• ¿Cuántas publicaciones están planificadas? El límite de reglas WAF y la operabilidad posterior influyen en el diseño.
• ¿Debe el firewall autenticar a los usuarios? Para portales, WAF-MFA puede ser útil.
• ¿Qué perfiles de protección están activos? Excepciones demasiado amplias debilitan WAF, perfiles demasiado estrictos pueden romper aplicaciones.
• ¿Cómo se registrará y probará? Log Viewer, reverseproxy.log y logs del backend deben ser conocidos antes del go-live.

Para los certificados, se debe aclarar temprano si se importará un certificado existente con su clave privada y la cadena de CA, si el firewall debe crear y renovar un certificado Let’s Encrypt o si se necesita un certificado generado externamente. Para certificados comodín, hay una guía separada: Crear certificado comodín Let’s Encrypt.

Configurar la regla WAF

Estructura básica de una regla WAF

Una publicación WAF consta de varios componentes:

• Hosted address: dirección IP pública o alias donde los clientes acceden a la aplicación.
• Listening port: puerto público, generalmente 80 o 443.
• Domains: nombres de host que deben coincidir con la regla WAF.
• HTTPS certificate: certificado para el nombre de host publicado.
• Web server: objeto web server creado previamente con host, protocolo, puerto y ajustes de conexión.
• Allowed client networks: redes de origen que pueden acceder.
• Blocked client networks / countries: fuentes o países que se bloquearán.
• Protection policy: protección WAF contra ataques web típicos.
• Authentication: autenticación previa opcional a través del firewall.

Sophos crea reglas WAF en el área de Reglas de Firewall. La acción se llama Protect with web server protection.

Importante: una regla WAF no es una regla de firewall normal con NAT detrás. Se crea una publicación Reverse Proxy. Por eso Hosted address, Listening port, Domains, certificado, Protected server y Allowed client networks deben encajar. Si uno de estos campos no coincide, el error a menudo parece un problema de certificado, DNS o backend.

Crear una regla WAF

La ruta del menú es:

Rules and policies > Firewall

Procedimiento:

El siguiente procedimiento numerado con Protected servers se aplica únicamente a SFOS 22 y no cambia para esta versión. Las reglas WAF solo admiten IPv4. La acción Protect with web server protection de la regla no equivale a la acción por ruta Action > Protect de Traffic routing en SFOS 23; para SFOS 23 se aplica la guía independiente que aparece justo después de este procedimiento.

1. Seleccionar IPv4.
2. Abrir Add firewall rule.
3. Seleccionar New firewall rule.
4. Asignar un nombre descriptivo a la regla.
5. Definir conscientemente Rule position, especialmente si ya existen reglas WAF más generales o publicaciones antiguas.
6. En Action, elegir la opción Protect with web server protection.
7. Si no se necesita una plantilla especial, dejar Preconfigured template en None.
8. En Hosted server details, definir la dirección pública, el puerto de escucha, HTTPS, certificado y dominios.
9. En Protected servers, seleccionar el objeto web server adecuado o crearlo antes en Web server > Web servers.
10. Establecer Allowed client networks conscientemente. Para sitios web públicos puede ser necesario Any IPv4; para portales suele ser mejor una restricción.
11. Si es necesario, establecer Blocked client networks o Blocked countries.
12. Revisar conscientemente Protection, Intrusion prevention y Traffic shaping en las políticas avanzadas.
13. Guardar la regla y probarla externamente.

SFOS 23: Publicar rutas en Traffic routing

1. En Rules and policies > Firewall, crear o editar una regla IPv4. Seguir seleccionando Protect with web server protection como Action de la regla y configurar adecuadamente la dirección pública, el puerto, el certificado HTTPS y los dominios. Una regla nueva contiene de forma predeterminada / con Block: sin configuración adicional de enrutamiento, las solicitudes se rechazan y la aplicación no se publica.
2. En Traffic routing, usar Edit o Add new path para editar o añadir la ruta concreta prevista. En Action, seleccionar explícitamente Protect y asignar los objetos backend necesarios de Web server > Web servers. Aunque una plantilla crea rutas con Protect, sigue siendo necesario asignarles los backends.
3. Para cada ruta protegida, asignar la Authentication Policy prevista en el campo Authentication y establecer conscientemente Allowed client networks, sin dejarlo vacío. Revisar específicamente Blocked client networks, Blocked countries y Block IP addresses of unknown country-origin; si el país de origen es desconocido, considerar también el riesgo de bloquear el propio acceso.
4. Si solo se van a publicar determinadas rutas, mantener conscientemente / con Block como ruta de respaldo. Establecer / en Protect únicamente si se desea publicar toda la aplicación; revisar expresamente el backend, la autenticación, las restricciones de acceso y las partes de la aplicación que pasan a ser accesibles. Las rutas más largas y específicas se evalúan primero, independientemente del orden de la tabla.
5. Distinguir las acciones: Block rechaza las solicitudes para la ruta seleccionada y no las reenvía al backend. Protect aplica la política de protección de la regla, así como los ajustes de autenticación y acceso configurados. Redirect envía al cliente una redirección al destino configurado, en lugar de publicar un backend. Passthrough crea un túnel al backend sin inspección WAF y sin aplicar la política de protección. Protection solo se aplica a las rutas con Protect.
6. Después de guardar, probar desde el exterior una ruta prevista como permitida, una ruta bloqueada intencionadamente y una ruta sin coincidencia específica. Si se utilizan, comprobar también Redirect y Passthrough por separado. Correlacionar el resultado del cliente, Log Viewer, reverseproxy.log y los logs del backend para la misma solicitud y el mismo momento.

Reglas existentes después de la actualización: Según la documentación de Sophos, las reglas WAF existentes se convierten automáticamente a Protect al actualizar a SFOS 23; las rutas específicas existentes se conservan. Esto difiere del valor predeterminado / con Block de las reglas nuevas y de la antigua migración de las ModSecurity Protection Policies de SFOS 18. Aun así, después de la actualización se deben revisar la acción, el backend, la autenticación, las restricciones de acceso y la ruta efectiva de cada ruta, y realizar una prueba de aceptación externa; la migración automática no sustituye la aceptación.

Contexto del tutorial: El tutorial de Sophos para proteger un servidor web contra ataques sigue utilizando el procedimiento con Protected servers y menciona IPv4 or IPv6, aunque la referencia de reglas WAF limita WAF a IPv4. Por tanto, el tutorial no es una guía completa de enrutamiento para SFOS 23. Para la configuración actual se aplican IPv4 y las acciones explícitas por ruta descritas arriba.

Cuando se guarda la regla, Sophos reinicia las reglas de Web Server Protection. Las conexiones en vivo existentes a través de estas reglas pueden interrumpirse. Por lo tanto, los cambios en las reglas WAF productivas deben realizarse en una ventana de mantenimiento o al menos conscientemente.

Si Allowed client networks queda vacío, la regla WAF no funciona correctamente; el navegador puede recibir un 400 Bad Request. Para una aplicación pública, Any IPv4 puede ser posible, pero no es automáticamente correcto. Para portales de administración, portales de socios o herramientas internas se deben revisar primero redes de origen fijas, limitación por países, WAF-MFA, VPN o ZTNA.

Los conflictos de puerto deben aclararse antes de guardar. WebAdmin y User Portal necesitan cada uno un puerto exclusivo. WAF y VPN Portal utilizan TCP, por lo que sus Hosted address o direcciones IP WAN deben ser distintas cuando utilizan el mismo puerto. WAF puede diferenciarse de SSL VPN por la dirección IP WAN, el puerto o el protocolo, ya que SSL VPN admite TCP o UDP. Un FQDN o nombre SNI diferente no basta por sí solo para separar estos listeners. Si otro servicio o una publicación DNAT antigua ya escucha en una IP pública, la asignación debe probarse por dirección IP, puerto y protocolo antes de la puesta en producción.

Go-live y aceptación

Planificar el Go-live y el Rollback

Una publicación WAF no debe considerarse completa solo al guardar la regla. Lo crucial es si DNS, certificado, Hosted address, backend, perfil de protección y registro funcionan juntos. Especialmente en redirecciones de puertos existentes, se debe tratar el cambio como una pequeña publicación.

Antes del Go-live, revisar:

• Documentar la configuración actual del firewall o al menos las configuraciones de reglas y certificados afectadas.
• Identificar las reglas DNAT o de firewall anteriores que afectan el mismo puerto, IP pública o nombre de host.
• Desactivar las reglas DNAT antiguas o documentar claramente por qué no compiten con la regla WAF.
• Reducir el TTL de DNS antes de un cambio si el nombre de host público cambia de una publicación antigua a la WAF.
• Proporcionar acceso de prueba externo, no solo probar desde la LAN interna.
• Definir casos de prueba: página de inicio, inicio de sesión, carga, descarga, ruta API, WebSocket, cierre de sesión y mensaje de error.
• Establecer puntos de registro esperados: Log Viewer, reverseproxy.log, registro de acceso del backend y registro de errores del backend.
• Establecer criterio de rollback, por ejemplo, inicio de sesión no posible, backend no accesible, certificado incorrecto, alta tasa de errores o partes críticas de la aplicación defectuosas.

Durante el cambio, solo debe estar activa una publicación a la vez. Si una regla DNAT antigua y una nueva regla WAF utilizan la misma IP pública y puerto, el comportamiento es difícil de entender. Antes de cambiar a producción, debe estar claro qué regla procesa realmente el tráfico.

Un rollback simple a menudo consiste en desactivar la nueva regla WAF y reactivar la publicación anterior. Si además se cambió DNS, se debe considerar el TTL de DNS. En caso de problemas con certificados o nombres de host, un rollback solo a través de DNS suele ser demasiado lento; en tales casos, la regla antigua debe poder reactivarse en la misma Hosted address o debe estar disponible un acceso alternativo.

Después del Go-live, los primeros accesos deben ser monitoreados activamente. No solo son importantes los códigos de estado HTTP exitosos, sino también los bloqueos de WAF, errores del backend, redirecciones inesperadas, problemas de sesión e información de IP del cliente faltante en los registros del backend.

Prueba de aceptación después del Go-live

Una prueba WAF solo está completa cuando la misma solicitud se puede rastrear desde tres perspectivas: cliente, firewall y backend. Esto permite identificar más rápidamente si un problema está en DNS, certificado, coincidencia de WAF, perfil de protección o aplicación.

• Cliente externo: revisar resolución DNS, certificado, estado HTTP, login y rutas importantes. La aplicación debería abrirse mediante el hostname público sin advertencia de certificado.
• Sophos Firewall: revisar Log Viewer, regla WAF, reverseproxy.log y firmas bloqueadas. La regla WAF correcta debería procesar el acceso y los logs deberían mostrar requests permitidos o bloqueados con justificación.
• Servidor web backend: revisar access log, error log, sesión de aplicación y X-Forwarded-For. El request debería llegar al vHost o ruta correcta, y la lógica de IP de cliente debe entenderse.

Para aplicaciones productivas, se deben probar al menos estos casos:

• Acceso a través del nombre de host correcto y a través de un dominio no coincidente.
• Inicio de sesión con usuario válido e inválido, si la aplicación o WAF autentica.
• Función de carga, descarga, API o WebSocket, si la aplicación utiliza tales funciones.
• Acceso desde una fuente permitida y, si es posible, desde una fuente conscientemente no permitida.
• Comportamiento de una solicitud de prueba WAF conocida e inofensiva, para que el registro y la ruta de bloqueo sean visibles.

Si la aplicación parece funcionar después del Go-live pero no se ven registros correspondientes, la prueba aún no está completa. Puede ser que otra publicación coincida, falte registro o el acceso no se realice a través de la ruta esperada.

Asegurar protección y acceso

Certificados y nombres de host

Para HTTPS, la regla WAF debe usar un certificado que coincida con el nombre de host público. El certificado se importa o crea en Certificates > Certificates y luego se selecciona en la regla WAF.

Puntos importantes:

• El nombre DNS debe coincidir con el certificado.
• El certificado HTTPS seleccionado puede rellenar automáticamente la lista de dominios en la regla WAF o sobrescribir entradas de dominio existentes.
• Con varios nombres de host en la misma IP, el firewall utiliza SNI.
• Los certificados comodín son posibles, pero deben documentarse adecuadamente.
• Los dominios comodín solo se utilizan después de reglas de dominio más específicas.
• Los guiones bajos en la etiqueta izquierda del dominio no son un nombre DNS limpio y deben evitarse para dominios WAF.
• El backend puede usar un nombre interno diferente si el encabezado Host y la aplicación pueden manejarlo.
• En caso de problemas con enlaces absolutos, Rewrite HTML puede ser relevante.

Si varios servidores web virtuales funcionan en la misma IP y puerto, el firewall decide en HTTPS según SNI y nombre de host qué regla WAF es adecuada.

Los dominios de la regla WAF deben coincidir exactamente con DNS y certificado. Los comodines pueden ayudar, pero no deberían sustituir un concepto de publicación limpio. Si varias aplicaciones funcionan bajo hostnames parecidos, hace falta documentación clara de reglas y certificados; de lo contrario, más tarde será difícil entender qué regla WAF hizo match realmente. Una prueba con un subdominio deliberadamente no coincidente es útil: así se ve si responde la regla específica, una regla comodín o ningún servidor web virtual coincidente.

Planificar IP del cliente y registros del backend

En publicaciones WAF, el servidor web interno a menudo no ve la IP del cliente real como dirección de origen directa. Sophos Firewall actúa como un Proxy Inverso y establece la conexión con el backend por sí mismo. Por lo tanto, para la aplicación y los registros del servidor web, primero puede ser visible la dirección del firewall.

Si la aplicación o el backend necesitan la IP del cliente original, se debe verificar temprano si se evalúa X-Forwarded-For u otro encabezado comparable. Esto es importante para:

• Registros de aplicaciones y evaluación de seguridad
• Límites de tasa o protección de inicio de sesión a nivel de aplicación
• Análisis de errores con referencia a usuario o IP de origen
• Correlación de SIEM o monitoreo
• Evaluación forense después de un incidente

Es importante el límite de confianza: un backend solo debe tratar tales encabezados como confiables si la solicitud realmente proviene de Sophos Firewall o un Proxy Inverso definido. Los clientes públicos no deben poder establecer X-Forwarded-For directamente como prueba de seguridad. En la práctica, el servidor web solo debe confiar en la IP del firewall y ignorar o sobrescribir encabezados de otras fuentes.

Para la resolución de problemas, esto significa: Log Viewer, reverseproxy.log y el registro del backend deben cubrir el mismo momento de prueba. Si en el backend solo es visible la IP del firewall, no es automáticamente un error de WAF, sino a menudo un comportamiento normal de Proxy Inverso.

Restringir el acceso del cliente

No todas las aplicaciones web deben ser accesibles mundialmente. Ya en la regla WAF se puede limitar el acceso.

Restricciones sensatas:

• Permitir solo direcciones IP de origen conocidas o redes de socios.
• Bloquear países no necesarios.
• Bloquear direcciones IP de origen de países desconocidos solo si se ha evaluado el riesgo de un bloqueo propio.
• Para portales, usar adicionalmente WAF-MFA o autenticación previa.
• Bloquear fuentes maliciosas conocidas a través de Threat Feeds.

Para el bloqueo de países y IPs maliciosas, ayuda Sophos Firewall: Bloquear países e IPs maliciosas. Para listas de amenazas dinámicas, es relevante Sophos Firewall Threat Feeds.

Planificar Threat Feeds y Active Threat Response

En aplicaciones web accesibles públicamente, no solo se debe considerar la regla WAF en sí. Desde SFOS 22, los Threat Feeds también son relevantes para el tráfico entrante y reenviado como publicaciones WAF y DNAT. El firewall puede comparar tales coincidencias con MDR Threat Feeds, NDR Essentials y Third-Party Threat Feeds.

Para los administradores, esto significa: WAF es la capa de publicación, Threat Feeds y Active Threat Response pueden bloquear o hacer visibles fuentes maliciosas conocidas adicionales. Sin embargo, esto no reemplaza la gestión de parches, una autenticación limpia y el endurecimiento de aplicaciones.

En la práctica, se debe verificar:

• ¿Está Active Threat Response configurado de manera adecuada en el entorno?
• ¿Se utilizan y revisan regularmente Threat Feeds relevantes?
• ¿Son visibles en operación los eventos WAF, registros de Active Threat Response y registros del backend?
• ¿Existe un proceso para falsos positivos, listas blancas y autorizaciones de emergencia?
• ¿Está claro quién reacciona ante las coincidencias y si solo se registra o se bloquea activamente?

Especialmente en portales de clientes, interfaces de administración o accesos de socios, esta revisión debe realizarse antes del Go-live. Si un feed bloquea más tarde el tráfico productivo, la operación debe saber dónde se ve la coincidencia y cómo decidir limpiamente: ataque real, falsa alarma o aplicación mal publicada.

Perfiles de protección y excepciones

Una regla WAF no solo debe publicar, sino también proteger. Para ello, se utilizan Políticas de Protección, políticas IPS opcionales y excepciones.

Áreas de protección típicas:

• Manipulación de cookies
• Endurecimiento de URL
• Endurecimiento de formularios
• Cross-Site Scripting
• Ataques a aplicaciones
• Inspección antivirus
• Clientes de mala reputación

En Web server > General settings hay ajustes globales adicionales para Web Server Protection, entre ellos el control de versiones TLS y la protección frente a patrones HTTP DoS lentos. Estos ajustes no afectan solo a una regla. Por eso los cambios deben planificarse conscientemente y coordinarse con las publicaciones WAF existentes.

SFOS 23: Ajustar el perfil de workers de forma específica

En Web server > General settings > Worker customization, el firewall calcula los valores predeterminados según los recursos de CPU y RAM disponibles; son adecuados para la mayoría de las instalaciones. Los valores más altos pueden afectar negativamente al rendimiento de WAF y a los recursos del sistema. Por tanto, activar Use custom worker profile solo después de comprobar la necesidad y evaluar los efectos. Antes, documentar los valores anteriores y si el perfil era calculado o personalizado, crear una copia de seguridad de la configuración y planificar una ventana de mantenimiento y el rollback exactamente a ese estado anterior. Este ajuste no modifica Maximum sessions.

• Start servers: Número de procesos worker que se inician al arrancar el servidor web.
• Server limit: Número máximo de procesos worker que pueden ejecutarse simultáneamente.
• Minimum spare threads: Número mínimo de hilos inactivos que se mantienen disponibles para nuevas solicitudes.
• Maximum spare threads: Número máximo de hilos inactivos antes de eliminar los hilos sobrantes.
• Threads per child: Número máximo de hilos worker por proceso worker.
• Asynchronous request worker factor: Controla el escalado de los procesos worker para conexiones y solicitudes asíncronas.

Para la autenticación de Reverse Proxy basada en formularios, el campo global Maximum sessions limita las sesiones de usuario simultáneas del conjunto de reglas WAF que usan este método de autenticación. El valor predeterminado es 25,000 y el intervalo permitido va de 100 a 100,000. Al alcanzar el límite, el firewall cierra sesiones antiguas o caducadas para admitir otras nuevas. Por tanto, no es capacidad por regla: debe dimensionarse según los inicios de sesión simultáneos de las aplicaciones afectadas y, tras cambiarlo, verificar inicio de sesión, cierre de sesión y cambio de sesión.

En Slow HTTP protection, Soft limit es el tiempo de espera concedido inicialmente para recibir la cabecera de la solicitud. Hard limit establece el límite superior absoluto. Extension rate define cuántos bytes adicionales recibidos amplían en un segundo el soft limit. Estos tres valores deben probarse juntos y con clientes realmente lentos; un solo valor demasiado permisivo puede debilitar innecesariamente la protección.

En Slow HTTP protection, las excepciones deben limitarse a la dirección IP o la red más pequeña necesaria. Sophos admite aquí objetos de host IP y de red, pero no rangos de IP ni listas de hosts. La Minimum TLS version también es global; antes de endurecerla se deben probar los clientes antiguos y todas las aplicaciones publicadas mediante una conexión externa real.

Como ajustes TLS globales, SFOS ofrece entre otras las opciones TLS v1.2 (wide compatibility), TLS v1.2 (strict) y TLS v1.3. Custom protocol configuration y Custom cipher configuration solo deben modificarse con valores OpenSSL documentados y probados; las cipher suites de TLS 1.3 se gestionan por separado. Los valores no válidos pueden impedir que se inicie el servicio Apache gestionado por SFOS y, por tanto, Web Server Protection. El plan de cambio debe incluir los valores anteriores, una copia de seguridad de la configuración, una ventana de mantenimiento y un acceso administrativo alternativo. Después se deben probar todas las publicaciones WAF y revisar reverseproxy.log; si el servicio no se inicia, se restauran los últimos valores personalizados en lugar de probar más variantes en producción.

En las Protection Policies, el modo es importante. Reject bloquea y genera eventos visibles en Log Viewer para reglas WAF. Monitor solo registra, pero estos mensajes WAF no aparecen necesariamente en Log Viewer; entonces hay que revisar reverseproxy.log. Monitor puede ser útil en un piloto, pero en protección productiva debe estar claro si los ataques solo se observan o se rechazan realmente.

El Common threat filter utiliza cuatro Filtering Strengths. Level 1 es el más permisivo y no se registra; a partir de Level 2 los eventos aparecen en /log/reverseproxy.log, aunque también aumenta el riesgo de falsos positivos. Las reglas individuales solo se excluyen en Skip filter rules mediante la Rule ID comprobada en el log. Desactivar de forma general una categoría completa o un nivel superior no sustituye este análisis.

Static URL hardening distingue mayúsculas de minúsculas, no admite wildcards y no ayuda con URL generadas dinámicamente mediante JavaScript. Form hardening compara la estructura del formulario y admite formularios de hasta 8,000 bytes. Si el contenido binario se entrega por error como HTML o XML, ambas funciones pueden dañarlo; primero se corrige el Content-Type del backend en lugar de desactivar ampliamente la protección.

En el análisis antivirus, el límite de tamaño se aplica al volumen total cargado en una solicitud, no a cada archivo por separado. El Request size limit adicional para el cuerpo HTTP va de 1 a 1,024 MB y tiene un valor predeterminado de 10 MB. HTTP Strict Transport Security solo añade el encabezado HSTS cuando la regla WAF utiliza Redirect HTTP; MIME-type sniffing protection establece X-Content-Type-Options: nosniff. Por eso deben probarse cargas, descargas y encabezados con la aplicación real.

IPS en una regla WAF debe evaluarse por separado. Sophos solo aplica IPS para WAF cuando la comunicación entre firewall y servidor web usa HTTP. Si el backend está conectado por HTTPS, no se debe esperar automáticamente que una política IPS seleccionada tenga el mismo efecto.

Las excepciones deben establecerse de manera restringida. Si una aplicación no funciona debido a una ruta específica o una fuente determinada, no se debe desactivar todo el perfil de protección. Es mejor una excepción específica con ruta, fuente y justificación clara.

⚠️ Cada excepción reduce la efectividad de la protección. La ruta, fuente, motivo, fecha y fecha de revisión deben documentarse para que los arreglos temporales no se conviertan en permanentes.

Volver a validar las Protection Policies migradas

Desde SFOS 18, Web Server Protection utiliza OWASP ModSecurity Core Rule Set 3.0. Al migrar Protection Policies anteriores se combinaron categorías previas, se reasignaron Rule IDs y se introdujeron Filtering Strengths. Si una de las categorías combinadas estaba activa, la nueva categoría conjunta puede quedar activada aunque otra parte estuviera desactivada anteriormente.

Después de una actualización de este tipo no basta con comparar el nombre de la política. Las categorías activadas, las excepciones y las Filtering Strengths deben contrastarse con la documentación anterior. A continuación se realizan pruebas positivas y negativas controladas con tráfico real de la aplicación y se revisan Log Viewer y reverseproxy.log. La política migrada solo queda validada cuando las solicitudes legítimas siguen funcionando y se detectan los ataques de prueba esperados.

Enrutamiento específico por ruta, WebSocket y Balanceo de Carga

WAF puede reenviar solicitudes a diferentes servidores backend según la ruta. Esto es útil cuando una aplicación tiene varios componentes o un solo nombre de host se distribuye en varios servicios internos.

Ejemplos:

• /api/ va a un servidor API.
• /shop/ va a un sistema de tienda.
• / va al servidor web estándar.

El firewall no evalúa las rutas según el orden de la tabla, sino que da prioridad a las rutas más largas y, por tanto, más específicas frente a la ruta de respaldo. Esta asignación debe probarse de forma específica. Solo para SFOS 22: Se puede activar la casilla WebSocket passthrough para la ruta del sitio web que lo necesite; el tráfico WebSocket se transmite sin protección WAF, ya que los datos WebSocket no se pueden inspeccionar como el tráfico HTTP normal. Para SFOS 23: En Traffic routing, configurar únicamente la ruta WebSocket necesaria con Action > Passthrough y el backend previsto. Este túnel funciona sin inspección WAF y sin política de protección; las demás rutas de la aplicación permanecen en Protect. Nunca se debe cambiar todo el portal a Passthrough como workaround. Probar por separado la actualización de la conexión, la transferencia de datos y la reconexión. Esto no permite concluir nada sobre la aplicación de MFA en Passthrough; si se requiere autenticación, aclarar quién se encarga de ella con la persona responsable de autenticación.

Solo para SFOS 22: En el procedimiento con Protected servers, la ruta predeterminada / reenvía las solicitudes sin una coincidencia más específica al servidor predeterminado asignado. Si se elimina esta ruta predeterminada, el firewall rechaza esas solicitudes con 404 Not Found. Para SFOS 23: Las solicitudes sin una coincidencia más específica utilizan la acción de /; en las reglas nuevas, esta es Block de forma predeterminada. Mantener conscientemente esta ruta de respaldo si solo se van a publicar rutas individuales. Protect para / solo tiene sentido si se desea publicar toda la aplicación y requiere revisar la accesibilidad adicional. En SFOS 23 no se garantiza un estado 404 fijo: la respuesta de Block se configura mediante Response code.

Con varios servidores backend, son posibles sesiones persistentes o standby en caliente. Esto ayuda en casos simples de alta disponibilidad o distribución de carga, pero no reemplaza un concepto completo de balanceo de carga de aplicaciones.

Alcanzar backends WAF remotos mediante SD-WAN

Si el servidor web protegido no está en la red local del firewall, se deben revisar routing y SD-WAN de forma especialmente consciente. Para backends a través de enlaces de sede, MPLS o route-based IPsec puede ser necesaria una SD-WAN Route adecuada para que el firewall llegue de forma fiable al Protected Server y el camino de retorno sea correcto. En route-based IPsec también es importante: Sophos no soporta WAF a través de route-based IPsec con Traffic Selectors para subredes; las conexiones Any-to-Any son la vía documentada.

El diseño documentado por Sophos parte de una regla WAF funcional y un túnel route-based alcanzable. En Routing > Gateways se crea un objeto de gateway para la ruta remota con la dirección IP del peer, la interfaz XFRM direccionada y un host de monitorización fiable detrás del peer. Solo entonces se crea en Routing > SD-WAN routes la ruta específica para el tráfico proxy de WAF:

1. Destination networks corresponde a la interfaz WAN pública o Hosted address mediante la cual el cliente alcanza la regla WAF.
2. Services contiene el Listening Port externo de la regla WAF. Si difiere del puerto backend interno, aquí se utiliza expresamente el puerto externo.
3. En Primary gateway se selecciona el gateway XFRM creado previamente.
4. Si varias publicaciones utilizan el mismo gateway, la misma SD-WAN Route puede contener varias direcciones WAN públicas y Listening Ports. Para gateways distintos se necesitan rutas separadas.

La validación separa después las capas: la prueba externa debe coincidir con la regla WAF prevista; en Log Viewer se correlacionan la regla WAF, los errores del reverse proxy y la hora; en el firewall deben estar activos la interfaz XFRM, el monitor del gateway y la SD-WAN Route; y el servidor backend debe recibir la solicitud y responder por la ruta prevista. Un túnel verde por sí solo no demuestra ni la coincidencia de SD-WAN ni la accesibilidad del backend.

Operación y resolución de problemas

Errores comunes

• Nombre DNS público apunta a la IP incorrecta: la regla WAF nunca se alcanza.
• Certificado no coincide con el hostname: los navegadores muestran errores de certificado o el SNI matching no encaja.
• Hosted address incorrecta elegida: el firewall hace match con otra regla o no ve tráfico WAF.
• Allowed client networks vacío: la regla no funciona como se espera.
• Límite de reglas WAF no considerado: ya no se pueden representar limpiamente más publicaciones.
• Versión de Exchange posterior a 2013 planificada con plantilla WAF: la plantilla no encaja con el límite WAF soportado.
• Conflicto de puerto con User Portal, VPN Portal u otro servicio: la aplicación no es accesible o responde un servicio del firewall.
• Backend no accesible internamente: los clientes externos reciben errores aunque DNS y certificado sean correctos.
• Timeout de backend configurado incorrectamente: respuestas largas terminan con errores aunque la aplicación sea básicamente accesible.
• Backend a través de VPN o SD-WAN sin ruta adecuada: la regla WAF hace match, pero el Protected Server no se alcanza de forma fiable.
• Route-based IPsec con Traffic Selectors hacia el backend: WAF por esta ruta no está soportado.
• Excepción WAF demasiado amplia: la eficacia de protección baja innecesariamente.
• Aplicación WebDAV publicada por WAF: la aplicación no funciona de forma fiable o no está soportada.
• La ruta URL contiene %2F: WAF responde con 404 Not Found, aunque el recurso sea accesible directamente en el backend. %2F es la forma codificada en URL de una barra / y debe distinguirse de un 404 normal del backend.
• Cambio de regla sin ventana de mantenimiento: conexiones existentes pueden interrumpirse al reiniciar las reglas WAF.
• Regla DNAT antigua y nueva regla WAF compiten: no está claro qué publicación procesa el tráfico.

Resolución de problemas

Si una publicación WAF no funciona, se debe verificar sistemáticamente:

1. ¿El nombre DNS público apunta a la IP pública correcta?
2. ¿Está seleccionada la dirección Hosted address correcta en la regla WAF?
3. ¿El puerto de escucha está libre y no está ocupado por WebAdmin, User Portal, VPN Portal u otra publicación?
4. ¿El certificado coincide con el nombre de host llamado?
5. ¿El servidor web interno es accesible desde el firewall?
6. ¿Están configuradas correctamente Allowed client networks, Blocked client networks y Blocked countries?
7. ¿El Protected Server se encuentra detrás de una ruta, SD-WAN Route o VPN que realmente encaja desde la perspectiva del firewall?
8. ¿Existe una regla WAF más general que coincida antes?
9. ¿El acceso se muestra en el Log Viewer como permitido, bloqueado o descartado?
10. ¿Hay indicios en /log/reverseproxy.log?
11. ¿La Protection Policy está en Monitor o Reject?
12. ¿El timeout del objeto web server encaja con la aplicación?

Para el análisis inicial, el Log Viewer es útil. Para una resolución de problemas más profunda, los registros de Web Server Protection en el firewall son útiles. Una visión general de los archivos de registro y servicios está en Asignar correctamente los logs de servicio de Sophos Firewall.

WAF responde con 404 cuando la ruta contiene %2F

Existe un error específico con las URL que contienen una barra codificada. Una solicitud como https://portal.example.com/api/files/project%2Freport.pdf puede devolver 404 Not Found a través de Sophos WAF, aunque el recurso exista al acceder directamente al backend. Sophos registra este comportamiento como NC-159041 y actualmente no indica una versión de SFOS afectada o corregida ni un workaround soportado.

Para delimitar la causa, se debe comparar la misma solicitud a través de WAF y directamente en el backend. Son importantes la URL exacta y la hora de la prueba:

1. Comprobar si la ruta contiene realmente %2F. Una barra normal / o la ausencia de la ruta predeterminada constituyen un error diferente.
2. Comparar la hora en Log Viewer, /log/reverseproxy.log y el registro de acceso del servidor web.
3. Si no aparece una entrada correspondiente en el backend, probablemente la solicitud se rechazó antes de llegar al servidor web. Una prueba directa contra el backend también permite confirmar que el recurso existe.

Una excepción WAF amplia no resuelve este problema de forma específica y reduciría innecesariamente la protección. Tampoco se debe modificar la configuración de Apache gestionada por SFOS: el tratamiento restrictivo de las barras codificadas ayuda a evitar que se eludan controles de ruta o de acceso.

La solución más limpia es que la aplicación o su fabricante genere URL sin barras codificadas. Si no es posible, se debe valorar conscientemente otra forma de publicación, como DNAT, un reverse proxy adecuado o acceso privado, frente a la pérdida de protección WAF. Para aplicaciones que no se pueden modificar, Sophos Support debe revisar la compilación concreta de SFOS y el caso de uso. Las formas project%2Freport.pdf y project/report.pdf son solo un patrón de diagnóstico y no son automáticamente equivalentes desde el punto de vista funcional.

Lista de verificación para reglas WAF productivas

• El nombre de la regla describe la aplicación, el nombre de host y el entorno.
• La persona responsable o el propietario del sistema está documentado.
• DNS, certificado y Hosted address están verificados.
• La accesibilidad del backend fue probada desde el firewall.
• La publicación anterior y el rollback están documentados.
• Las reglas DNAT o de firewall antiguas no compiten con la regla WAF.
• Las pruebas de Go-live externas están definidas.
• El acceso está restringido a fuentes o países necesarios.
• Threat Feeds y Active Threat Response fueron evaluados para aplicaciones públicas.
• El registro está activo.
• El perfil de protección no está desactivado innecesariamente.
• Las excepciones son restringidas, justificadas y temporales.
• El cambio fue probado externamente.
• La fecha de vencimiento o la fecha de revisión está documentada.

Preguntas frecuentes