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 inspeccionarse, restringirse y registrarse 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 correctamente 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.

PHP2Shell — estado a 24 de octubre de 2026: Para CVE-2026-109618 y CVE-2026-109619, Sophos no indica protección específica de Sophos Firewall WAF en el aviso del 22 de octubre, versión 4. Los entornos de ejecución PHP afectados en el backend deben actualizarse; publicarlos mediante WAF no sustituye esa actualización. Las firmas IPS disponibles desde el 22 de octubre sirven para detectar intentos de ataque. Debe comprobarse por separado si una política IPS adecuada inspecciona la ruta real de los datos y qué acción aplica; la guía de IPS explica estas comprobaciones. La ausencia de alertas no demuestra que el sistema esté correctamente parcheado.

Decisión antes de publicar

Antes de crear una regla WAF, debe estar claro si WAF, DNAT, VPN o ZTNA se adapta a la aplicación. Esta decisión es más importante que el propio formulario del firewall, porque determina la superficie de ataque, la operación y la resolución de problemas.

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 el nombre de host, el certificado, las rutas, los perfiles de protección, la autenticación o las 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 admite WebDAV. Por lo tanto, aplicaciones como Nextcloud no deben publicarse a ciegas 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 con qué rapidez se puede configurar una publicación, sino si después se puede operar, probar y retirar de forma segura. 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. Deben probarse DNS, certificado, nombre de host, perfil de protección, logging y accesibilidad del backend.
Portal de clientes, portal de socios o interfaz de administración: WAF con restricción por 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. Deben revisarse conjuntamente la regla de firewall, la regla NAT, el servidor de destino, la ruta de retorno y el logging.
Aplicación web con WebDAV o protocolo especial: no usar WAF automáticamente. Probar las funciones admitidas, el comportamiento del cliente y una publicación alternativa.
Aplicación solo para usuarios internos: evaluar VPN, ZTNA o WAF con restricciones estrictas. La accesibilidad pública debe cuestionarse críticamente.

Para aplicaciones privadas, una regla WAF accesible desde todo el mundo suele representar una superficie de ataque excesiva. Si solo unas pocas personas necesitan acceso, las redes de origen fijas, VPN, ZTNA u otra arquitectura de acceso privado suelen ser una solución más adecuada que una publicación web pública.

Planificación y requisitos previos

Una publicación WAF estable requiere DNS, certificado, accesibilidad del backend, logging y un plan de rollback. Estos puntos deben estar definidos antes de la configuración.

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, países o grupos de usuarios permitidos
Perfil de protección adecuado y política IPS opcional
Logging 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 de host IP o FQDN. Para los 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, en lugar de adoptar sus valores sin comprobarlos.

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 acceso y puede reducir el rendimiento. Por eso, esta opción solo debe utilizarse para delimitar un problema específico 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 nombres de host separados. En ese caso, no se deben crear más reglas individuales sin criterio, sino revisar el esquema de nombres, las rutas, los servidores web virtuales y las 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 admiten 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 contrastan las rutas, los métodos de autenticación y los perfiles 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.

Crear un objeto de backend con un ejemplo claro

El nombre público y el nombre del backend cumplen funciones distintas. En el siguiente ejemplo, los usuarios abren portal.example.com; el firewall accede al servidor mediante backend.example.com. Ambos nombres son marcadores de posición y deben sustituirse por los nombres DNS propios. Desde la perspectiva del firewall, el nombre del backend debe resolverse al servidor real, no de nuevo a la propia dirección pública de WAF: de lo contrario, no se obtiene una ruta útil hacia el backend.

En Hosts and services > FQDN host > Add, crear un objeto llamado WAF_Backend_Portal con FQDN backend.example.com y guardarlo. Como alternativa, utilizar un objeto de host IP para un servidor backend fijo. Según la documentación del producto, los hosts FQDN ofrecen una compatibilidad más amplia con servidores; aun así, deben comprobarse la resolución DNS y el servidor de destino.
En Web server > Web servers > Add, crear un objeto de servidor web WAF_Portal_Server y seleccionar el objeto de backend en Host.
Configurar Type y Port según el listener real del backend: en el ejemplo HTTPS, HTTPS y 443; para un backend HTTP, HTTP y, por ejemplo, 80. El puerto de escucha externo se define después en la regla WAF y no tiene por qué coincidir con el puerto del backend. Para un backend HTTP, proteger expresamente el segmento sin cifrar; un frontend HTTPS por sí solo no cifra este segmento.
Activar Keep alive solo si el servidor web admite la reutilización de conexiones. Evaluar inicialmente Timeout con el valor predeterminado de 300 segundos. Se refiere al tiempo de espera de datos hacia o desde el backend, no a una duración máxima total fija para cada solicitud: mientras los datos lleguen a tiempo, una respuesta puede durar más. Por tanto, ante un 502, revisar los logs del backend y las pausas en la transmisión de datos, en lugar de aumentar el valor de inmediato.
No activar Disable backend connection pooling como optimización de rendimiento durante el funcionamiento normal. Guardar el objeto, comprobar su asignación a la regla WAF o a la ruta Protect de SFOS 23 y verificar un acceso representativo al backend.

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

Una regla WAF no debe empezar a planificarse en el formulario. Antes debe estar claro si Sophos Firewall solo debe publicar o si también debe encargarse de la autenticación, los perfiles de protección, las reglas de país y el logging.

Estas preguntas son importantes antes de una publicación en producción:

¿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 facilidad de gestión 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? Las excepciones demasiado amplias debilitan WAF; los perfiles demasiado estrictos pueden impedir que las aplicaciones funcionen.
¿Cómo se registrará y probará? Log Viewer, reverseproxy.log y los logs del backend deben conocerse antes de la puesta en producción.

Para los certificados, se debe aclarar pronto 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

La regla WAF propiamente dicha consta de dirección pública, nombres de host, certificado, servidor de destino, orígenes permitidos y perfil de protección. Estos campos deben considerarse conjuntamente, no como opciones individuales aisladas.

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 de servidor web creado previamente con host, protocolo, puerto y ajustes de conexión.
Allowed client networks: redes de origen que pueden acceder.
Blocked client networks / countries: orígenes 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 mediante proxy inverso. 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 suele parecer un problema de certificado, DNS o backend.

Crear una regla WAF

La ruta del menú es:

Rules and policies > Firewall

Procedimiento:

Las reglas nuevas están activadas de forma predeterminada. Por tanto, para una publicación preparada pero aún no autorizada, comprobar expresamente el estado de la regla y mantenerla desactivada hasta la puesta en producción prevista. Rule position ofrece Top o Bottom; Rule group asigna la regla a un grupo existente o a uno creado mediante Create new. Automatic utiliza el primer grupo que coincida según el tipo de regla y las zonas de origen y destino. La agrupación facilita la administración, pero no sustituye la comprobación del acceso.

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.

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

SFOS 23: Publicar rutas en Traffic routing

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.
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.
Para cada ruta protegida, asignar la política de autenticación 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.
Si solo se van a publicar determinadas rutas, mantener conscientemente / con Block como ruta por defecto. 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.
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.
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.

La ruta predeterminada se puede editar, clonar o eliminar. Un clon no hereda la autorización funcional: volver a comprobar la acción, el backend, la autenticación y los orígenes de acceso para la nueva asignación. No eliminar / por accidente si constituye la ruta por defecto configurada expresamente para bloquear.

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, de forma consciente.

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 es 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.

El puerto predeterminado del User Portal es 4443; los listeners de los portales y sus límites se describen en la descripción general de los portales.

SFOS 23: Definir las respuestas de bloqueo y redirección

Una acción de enrutamiento puede agrupar varias entradas en Paths si todas necesitan el mismo tratamiento. En Traffic routing > Add new path, seleccionar las rutas y la acción, rellenar los campos correspondientes a la acción y guardar la entrada de rutas. Utilizar entradas separadas si los backends, las reglas de acceso o los destinos de redirección son diferentes.

Para Block, Response code determina la respuesta. Un ejemplo es /admin/ con Forbidden (403), mientras / permanece en Block como ruta por defecto. La selección documentada comprende de 400 a 417, además de 422, 423, 424 y 426. Elegir el código según el significado que se quiera comunicar: 403 indica acceso denegado y 404, contenido no encontrado. Seleccionar el código 401 no configura una política de autenticación; el código de estado por sí solo no protege el acceso mediante inicio de sesión. En la prueba de aceptación, comprobar el estado configurado y la ausencia de una solicitud correspondiente al backend.

Para Redirect, además de Paths y Action, la configuración incluye los campos Response code, Protocol, Host, Path y Port. Ejemplo: /old-portal/ con Temporary Redirection (307), Protocol HTTPS, un host FQDN para portal.example.com, Path /portal/ y Port 443. Sustituir los nombres y las rutas por los de la aplicación de destino propia. 307 indica una redirección temporal que conserva el método de la solicitud; resulta adecuado para un piloto controlado si el destino procesa el mismo método. Aun así, probar por separado el navegador y el cliente API, especialmente las solicitudes POST. El destino /portal/ debe ser accesible y estar protegido por sí mismo, por ejemplo, mediante una ruta Protect adecuada; una redirección por sí sola no crea allí una configuración de backend ni de acceso.

La selección ofrece 300, 301, 302, 303, 304, 305, 307 y 308. No todos los códigos disponibles son una redirección habitual a una página nueva: 304 describe la validación de caché. 305 está obsoleto por motivos de seguridad y no se recomienda para aplicaciones públicas. Utilizar 301 o 308 únicamente si se pretende un cambio permanente y tener en cuenta el comportamiento del cliente y de la caché al revertirlo. Los puertos predeterminados del destino son 80 para HTTP y 443 para HTTPS. Redirect no realiza inspección WAF ni envía la solicitud a un backend de esta ruta; por tanto, comprobar en el cliente el estado y el destino de redirección y, después, la protección de la aplicación de destino.

Ajustar de forma específica la cabecera Host, HTML y la compresión

Las Advanced settings de una regla WAF ayudan a resolver problemas concretos de proxy inverso. No son opciones que deban activarse todas de forma indiscriminada:

Pass host header reenvía al backend la cabecera Host solicitada por el cliente. Si hay varios sitios web en un servidor, esto permite seleccionar el host virtual correcto. Configurar el vHost del backend de acuerdo con el nombre publicado y comprobar en el registro de acceso que no responde otro sitio web.
Rewrite HTML adapta los enlaces de las páginas devueltas. Por ejemplo, si un enlace absoluto apunta a http://backend.example.com/ mientras la aplicación se publica mediante el nombre público, puede ser necesaria una reescritura. Normalmente no es necesaria si los nombres de host públicos ya son correctos o si todos los enlaces son relativos. El procesamiento afecta a los Content-Types text/* y *xml*; las descargas binarias deben entregarse con el Content-Type correcto, ya que, de lo contrario, pueden dañarse. Después, probar por separado los enlaces públicos, las descargas y las funciones de la aplicación.
Rewrite cookies reescribe las cookies de las páginas devueltas. Si hay problemas de sesión, examinar las cookies que realmente se establecen, así como el inicio y el cierre de sesión, en lugar de confundir la reescritura de cookies con Cookie signing: la reescritura y la protección contra manipulaciones cumplen funciones diferentes.
Disable compression support es una ayuda específica para páginas que se muestran incorrectamente o errores de Content-Encoding. En ese caso, el firewall solicita datos sin comprimir al backend y los entrega sin comprimir, independientemente de la codificación solicitada. Documentar el estado anterior, repetir el acceso a la misma página y revertir la opción si no resuelve el error.

Algunos puertos están reservados para servicios del sistema, aunque el servicio correspondiente no se utilice. Que no haya ningún listener ocupando un puerto de este tipo no significa que esté disponible para WAF; el resumen Puertos reservados de Sophos Firewall ayuda a planificar. Traffic shaping asigna ancho de banda y priorización según horarios a la publicación. Es una decisión operativa, no una protección adicional de la aplicación; con la política activada, comprobar también las cargas y descargas bajo una carga representativa.

Go-live y aceptación

La publicación aún no está terminada al guardar la regla. Solo las pruebas externas, los logs adecuados y un rollback claro permiten que el cambio esté preparado para producció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 cuando ya existen redirecciones de puertos, se debe tratar el cambio como una pequeña puesta en producción.

Antes del Go-live, revisar:

Documentar la configuración actual del firewall o, al menos, los ajustes de reglas y certificados afectados.
Identificar las reglas DNAT o de firewall anteriores que afectan al 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 pasa 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 un criterio de rollback, por ejemplo, imposibilidad de iniciar sesión, backend no accesible, certificado incorrecto, alta tasa de errores o fallos en partes críticas de la aplicación.

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 el mismo 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 supervisarse 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, inicio de sesión y rutas importantes. La aplicación debería abrirse mediante el nombre de host 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 registros deberían mostrar solicitudes permitidas o bloqueadas con justificación.
Servidor web backend: revisar el registro de acceso, el registro de errores, la sesión de la aplicación y X-Forwarded-For. La solicitud debería llegar al vHost o a la ruta correcta, y debe comprenderse la lógica de la IP del cliente.

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 deliberadamente 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

En las aplicaciones web públicas, WAF es solo una capa de protección. Los certificados, las restricciones de origen, los Threat Feeds, los perfiles de protección y el registro del backend deben planificarse conjuntamente.

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. *. solo se permite al principio, por ejemplo, *.example.com; una regla puede contener varios dominios comodín.
Los guiones bajos en la etiqueta izquierda del dominio no conforman un nombre DNS válido y deben evitarse para los 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 el nombre de host qué regla WAF es adecuada.

Por tanto, los dominios de la regla WAF deben coincidir exactamente con DNS y certificado. Los comodines pueden ayudar, pero no deberían sustituir un diseño de publicación bien definido. Si varias aplicaciones funcionan bajo nombres de host parecidos, hace falta documentación clara de reglas y certificados; de lo contrario, más tarde será difícil entender qué regla WAF coincidió 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 si no hay ningún servidor web virtual coincidente.

El nombre del objeto de certificado solo puede contener caracteres alfanuméricos del juego de caracteres US-ASCII; no debe confundirse con el nombre DNS del certificado. Después de seleccionarlo, revisar los Domains incorporados automáticamente y, si es necesario, editarlos, añadir otros o eliminarlos. HTTPS hace que el listener sea accesible mediante HTTPS, pero no también mediante HTTP. Redirect HTTP redirige por separado los accesos del puerto 80 al puerto 443; por tanto, también deben planificarse estos listeners y los posibles conflictos de puerto.

Cuando el nombre del subdominio no coincide, no tiene por qué aparecer una página gráfica de bloqueo. La documentación muestra, por ejemplo, 403 al acceder mediante otro subdominio. Por eso se deben revisar el estado HTTP y reverseproxy.log, no solo el aspecto de la página en el navegador.

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 de 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 e 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 bloquear el propio acceso.
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 e IP 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 adquieren mayor relevancia también para el tráfico entrante y reenviado, como las publicaciones WAF y DNAT. El firewall puede contrastar estas 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 otras fuentes maliciosas conocidas. Sin embargo, esto no reemplaza la gestión de parches, una autenticación bien configurada ni 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 durante la operación los eventos WAF, los registros de Active Threat Response y los registros del backend?
¿Existe un proceso para falsos positivos, listas de permitidos 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, el equipo de operaciones debe saber dónde se ve la coincidencia y cómo decidir con criterio: 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 Protection Policies, 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 suites de cifrado 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 revierten 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 niveles de filtrado. Level 1 es el más permisivo y no se registra; a partir de Level 2 las coincidencias 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 adecuadamente este análisis.

Static URL hardening distingue mayúsculas de minúsculas, no admite comodines 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; por eso, 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 las cargas, las descargas y los 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 el firewall y el 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 eficacia de la protección. La ruta, fuente, motivo, fecha y fecha de revisión deben documentarse para que las soluciones provisionales no se conviertan en permanentes.

Crear una política de protección y comprender su efecto

En Web server > Protection policies > Add, asignar un nombre descriptivo, por ejemplo WAF_Portal_Protection, configurar las funciones de protección necesarias y seleccionar Save. A continuación, seleccionar la política en el campo Protection de la regla WAF; en SFOS 23 solo se aplica a las rutas con Protect. Una política predeterminada existente, por ejemplo para Exchange Autodiscover, solo debe utilizarse para el caso de uso correspondiente.

Para una prueba piloto de la propia aplicación, decidir primero de forma explícita entre Monitor y Reject. Monitor no bloquea ni muestra los mensajes WAF correspondientes en Log Viewer; para consultarlos se necesita reverseproxy.log. La mayor visibilidad de Reject no debe confundirse con una compatibilidad de la aplicación ya comprobada. Pass Outlook anywhere permite a los clientes externos de Outlook eludir la protección del servidor web para acceder a Exchange. Esta opción no es una solución general de compatibilidad para portales modernos y debe permanecer desactivada si no existe un caso de uso heredado que la justifique.

Interpretar correctamente la protección de cookies, URL y formularios

Cookie signing añade a una cookie establecida por el servidor una segunda cookie con un hash calculado a partir del nombre, el valor y un secreto que solo conoce el firewall. Si el cliente no devuelve el par correspondiente, se descarta la cookie. Esto protege frente a la manipulación, pero no sustituye las sesiones seguras de la aplicación ni la configuración correcta de las cookies del backend. Después de activarlo, probar el inicio de sesión, el carrito de compra y cualquier otro proceso que dependa de cookies.

Con Static URL hardening, el firewall firma los enlaces estáticos y determina, a partir de la respuesta del servidor, qué enlaces posteriores están permitidos. Entry URLs define las URL de entrada a las que se puede acceder sin una firma de endurecimiento; para un sitio web sencillo, / puede ser el punto de entrada. Esta lista no es una lista general de enrutamiento. Respetar las mayúsculas y minúsculas y no introducir comodines. Las aplicaciones con URL generadas mediante JavaScript o enlaces directos legítimos a páginas internas requieren una comprobación específica. Form hardening firma la estructura original del formulario y rechaza los formularios manipulados. Siguen siendo decisivos el límite de 8,000 bytes y un Content-Type correcto de HTML o XML.

El ejemplo sencillo documentado de protección frente a ataques utiliza Reject, Static URL hardening con el punto de entrada /, Form hardening, Antivirus, Block clients with bad reputation y Common threat filter. En ese ejemplo, Cookie signing, Pass Outlook anywhere y Skip remote lookups for clients with bad reputation están desactivados. Se trata de un perfil de prueba para ese procedimiento concreto, no de una recomendación universal ni de una prueba de que los valores predeterminados sean adecuados para todas las aplicaciones. Para un portal moderno, evaluar cada una de estas opciones con el tráfico real de la aplicación. Tampoco Basic with passthrough, mencionado en ese ejemplo, constituye una recomendación de MFA; el modo de cliente, la transmisión de credenciales y las plantillas se explican en el artículo sobre autenticación WAF y MFA.

Configurar conscientemente el antivirus y la reputación

En Antivirus, Mode determina si se utiliza uno o dos motores de análisis; si se utiliza un solo motor, seleccionarlo. Direction establece si se analizan las cargas, las descargas o ambas direcciones. Block unscannable content bloquea, por ejemplo, archivos cifrados o dañados que no se pueden analizar. Esto refuerza la aplicación de la protección, pero puede afectar a documentos cifrados legítimos; por eso, definir previamente los procesos de negocio permitidos y la vía de soporte.

Limit scan size limita el volumen que se analiza; 0 o un campo vacío significa que no hay límite de tamaño para el análisis. Por ejemplo, con un límite de análisis de 50 MB y archivos de 45, 5 y 10 MB en una misma carga, el último archivo no se analiza. Por tanto, una carga correcta no demuestra que se hayan analizado todos los archivos que contiene. Este límite de análisis debe distinguirse de Request size limit, que se aplica a todo el cuerpo HTTP: un límite de cuerpo mayor no permite automáticamente analizar más contenido. Elegir los límites según las cargas realmente necesarias, los recursos y los requisitos de seguridad, y comprobar las cargas de varios archivos y los contenidos que no se pueden analizar en un entorno de pruebas autorizado.

Block clients with bad reputation utiliza información de RBL y GeoIP: Sophos SXL para las RBL y MaxMind para GeoIP. También se documentan bloqueos para las clasificaciones A1 (proxies anónimos o servicios VPN) y A2 (ISP por satélite). Esto puede afectar a accesos legítimos de socios. Skip remote lookups for clients with bad reputation puede mejorar el rendimiento, pero modifica la evaluación mediante consultas remotas; no activarlo inadvertidamente ni equipararlo a una lista de fuentes permitidas.

Evaluar Common threat filter por categorías y nivel de filtrado

Las categorías responden a distintas necesidades y se seleccionan deliberadamente para la aplicación:

Application attacks: Detecta, entre otras cosas, accesos no permitidos a rutas e intentos típicos de ejecución de comandos, incluso después de una posible intrusión.
SQL injection attacks: Comprueba si los argumentos de las solicitudes contienen comandos SQL incrustados y caracteres de escape.
XSS attacks: Comprueba si las entradas contienen etiquetas de script y código incrustados.
Protocol enforcement: Comprueba la conformidad con el protocolo, encabezados habituales como Host y User-Agent, límites de argumentos y el uso permitido de HTTP. Por ello, también puede detectar como anómalo un cliente legítimo poco habitual.
Scanner detection: Detecta patrones típicos de bots, rastreadores y escaneos; aun así, deben probarse los accesos deseados de motores de búsqueda o sistemas de monitorización.
Data leakage: Impide que llegue al cliente información sensible, por ejemplo a través de mensajes de error del servidor. Si Application attacks o SQL injection attacks están activos, también debe revisarse esta categoría, ya que sus ámbitos de detección se solapan.

Filter strength tiene Level 1 como valor predeterminado y genera el menor número de falsos positivos. Level 2 añade, por ejemplo, expresiones regulares para inyecciones SQL y XSS y otras palabras clave de inyección de código; Level 3 añade reglas, listas de palabras clave y límites de caracteres especiales; Level 4 restringe aún más los caracteres especiales y requiere pruebas especialmente exhaustivas de falsos positivos antes de la puesta en producción. Se mantienen las limitaciones de registro descritas anteriormente: Level 1 no se registra; Level 2 y los niveles superiores aparecen en /log/reverseproxy.log. No considerar validado como seguro un nivel más alto solo porque se abra la página de inicio.

Comprobar HSTS y la protección MIME antes de activarlos

Con HTTP Strict Transport Security y Redirect HTTP activado, el firewall añade este encabezado:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

31536000 equivale a un año. Esto no afecta únicamente al punto de entrada probado: includeSubDomains incluye los subdominios, y los navegadores pueden guardar esta directiva. Antes de activarla, HTTPS, los certificados y todos los subdominios afectados deben funcionar de forma permanente; desmarcar posteriormente la casilla no revierte de inmediato las directivas ya guardadas por los navegadores. La presencia de preload en el encabezado no demuestra por sí sola la inclusión en una lista de precarga de un navegador. MIME-type sniffing protection añade X-Content-Type-Options: nosniff; por eso, corregir los tipos MIME erróneos en el backend en lugar de eliminar el encabezado de forma general. Comprobar ambos encabezados desde el cliente externo.

Crear excepciones con el alcance mínimo necesario

En Add new exception, definir Paths, Sources, Operation y las comprobaciones concretas que se omitirán. Las rutas de las excepciones distinguen mayúsculas de minúsculas y admiten comodines, por ejemplo /products/*/images/*. Esto las diferencia de Entry URLs de la política de endurecimiento de URL estáticas, que no admite comodines. En Operation, la combinación booleana es decisiva: exigir que coincidan una ruta y una fuente tiene un alcance más restringido que exigir que coincida una ruta o una fuente. Comprobar la intersección deseada antes de guardar para no excluir accidentalmente una fuente de un socio de la protección en todas las rutas.

Para Sources de una excepción se documentan direcciones IP, rangos, listas y redes. Esto no debe extrapolarse a otros campos: en Path-specific routing de SFOS 22 y en los campos Allowed client networks y Blocked client networks de Passthrough de SFOS 23, solo se documentan los tipos de host IP y Network, no rangos ni listas de IP. Para obtener una restricción de acceso predecible, utilizar allí objetos de IP individuales o de red.

Las opciones de una excepción omiten, entre otras comprobaciones, Cookie signing, Static URL hardening, Form hardening, Antivirus, Block clients with bad reputation y determinadas categorías de Common threat filter. Dos opciones requieren especial precaución:

Never change HTML during static URL hardening or form hardening impide reescribir la página HTML, por ejemplo si la aplicación depende de enlaces sin modificar. Esto no implica automáticamente que se acepten los enlaces sin firmar; para ello puede ser necesaria una excepción específica de endurecimiento.
Accept unhardened form data acepta datos de formulario sin una firma de endurecimiento. Una excepción de Form hardening por sí sola no lo hace. Esta autorización adicional elimina otra comprobación y solo es adecuada para un proceso delimitado con precisión y debidamente justificado.

Antes, conservar la solicitud legítima que falla, la hora y la Rule ID comprobada. Después, repetir la misma solicitud y realizar una comprobación de contraste con una fuente o una ruta no excluida. La excepción solo está delimitada adecuadamente cuando el proceso necesario funciona y el resto de la protección se mantiene; en caso de duda, excluir una única Rule ID comprobada en Skip filter rules en lugar de un área de protección completa.

Volver a validar las políticas de protección migradas

Desde SFOS 18, Web Server Protection utiliza OWASP ModSecurity Core Rule Set 3.0. Al migrar políticas de protección anteriores se combinaron categorías previas, se reasignaron los ID de las reglas y se introdujeron niveles de filtrado. Si una de las categorías combinadas estaba activa, la nueva categoría conjunta también 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 los niveles de filtrado 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.

Para la antigua migración de SFOS 18 son importantes las siguientes correspondencias: Protocol violations, Protocol anomalies, Request limits y HTTP policy se combinaron en Protocol enforcement; Generic attacks y Tight security, en Application attacks; Bad robots, en Scanner detection; y Outbound, en Data leakage. Rigid filtering se migra a Level 1 y debe volver a evaluarse de forma deliberada. La categoría Trojans se eliminó; el antivirus asume la protección correspondiente. Las reglas ya excluidas que tengan asignada una nueva Rule ID siguen excluidas, mientras que los ID sin correspondencia, eliminados o combinados en una nueva regla se eliminan de la lista de exclusiones. Por eso, no copiar la antigua lista de excepciones sin comprobarla, sino contrastarla con la política y los logs actuales.

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 entre 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 por defecto. 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 por defecto 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.

Sin un mecanismo adicional de afinidad, las solicitudes se distribuyen entre los distintos servidores web seleccionados. Sticky session cookie vincula el navegador a un servidor backend; si este falla, se actualiza la cookie y la sesión pasa a otro servidor. Esto no garantiza la transferencia del estado de la aplicación: un carrito de compra, por ejemplo, puede necesitar un almacenamiento de sesiones compartido.

Hot-standby mode envía inicialmente todas las solicitudes al primer servidor seleccionado y utiliza los demás como respaldo. Cuando vuelve a estar disponible el servidor principal, las sesiones regresan a él por norma general; con Sticky session cookie activado, la sesión existente permanece en el servidor de respaldo. Por ello, en la prueba de aceptación se deben verificar por separado el servidor principal, el orden de los servidores de respaldo, el fallo, la vuelta al servicio y una operación de inicio de sesión o de carrito de compra que realmente mantenga estado.

El campo Authentication también figura para Passthrough en la tabla de SFOS 23, mientras que el resumen de funciones asigna la autenticación a Protect. Esta discrepancia en la documentación no se resuelve mediante suposiciones. Si se requiere WAF-MFA, el área protegida debe basarse en Protect y en una política explícita; la delimitación y las pruebas se describen en Autenticación WAF con MFA.

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 con dirección asignada 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:

Crear y guardar el gateway en Routing > Gateways > IPv4 gateway > Add. En el ejemplo se llama gw6, utiliza Gateway IP 10.12.13.2 e Interface xfrm1-10.12.13.1. En Monitoring condition, utilizar un host detrás del gateway que responda de forma fiable; el ejemplo documentado utiliza 10.12.13.2. Sustituir estas direcciones privadas y la interfaz por el direccionamiento real del túnel y un host de monitorización adecuado.
En Routing > SD-WAN routes, seleccionar IPv4 y Add, por ejemplo, con el nombre SD-WAN_WAF_Portal. En Destination networks, eliminar Any y seleccionar la interfaz WAN pública o la Hosted address mediante la cual el cliente alcanza la regla WAF; en el ejemplo, #Port1. En esta ruta WAF documentada no se trata simplemente de la IP privada del backend.
En Services, eliminar Any y seleccionar el Listening Port externo de la regla WAF; en el ejemplo, TCP 8080. Si difiere del puerto backend interno, aquí se utiliza expresamente el puerto externo. El puerto no estándar también debe tenerse en cuenta al realizar la solicitud de prueba externa.
En Link selection settings, seleccionar Primary and Backup gateways y establecer en Primary gateway el gateway XFRM gw6 creado previamente. Guardar la ruta. 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.

El procedimiento de SD-WAN remite a una guía de VPN route-based con Traffic Selectors; sin embargo, la referencia de reglas WAF excluye expresamente los Traffic Selectors basados en subredes. Por tanto, para este caso de uso de WAF se debe planificar una conexión Any-to-Any y no interpretar el título de la guía enlazada como una autorización para configurar selectores de subred.

La prueba de aceptación separa después las capas: la solicitud 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

Durante la operación, lo importante es que se pueda seguir comprendiendo cómo funciona la publicación: qué regla coincide, qué logs son relevantes, qué excepciones existen y cómo proceder ante una incidencia.

Errores comunes

El nombre DNS público apunta a la IP incorrecta: la regla WAF nunca se alcanza.
El certificado no coincide con el nombre de host: los navegadores muestran errores de certificado o la coincidencia SNI no es correcta.
Hosted address incorrecta seleccionada: el firewall coincide con otra regla o no coincide con ningún 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 adecuadamente más publicaciones.
Versión de Exchange posterior a 2013 planificada con una plantilla WAF: la plantilla no se ajusta al límite de compatibilidad de WAF.
Conflicto de puerto con User Portal, VPN Portal u otro servicio: la aplicación no es accesible o responde un servicio del firewall.
El backend no es accesible internamente: los clientes externos reciben errores aunque DNS y certificado sean correctos.
Timeout del backend configurado incorrectamente: las respuestas largas terminan con errores aunque la aplicación sea accesible en principio.
Backend a través de VPN o SD-WAN sin una ruta adecuada: la regla WAF coincide, 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 la protección disminuye innecesariamente.
Aplicación WebDAV publicada mediante 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: las conexiones existentes pueden interrumpirse al reiniciar las reglas WAF.
La regla DNAT antigua y la 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:

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

Para el análisis inicial, el Log Viewer es útil. Para una resolución de problemas más profunda, ayudan los logs de Web Server Protection en el firewall. En Resolución de problemas de Sophos Firewall: servicios y logs se ofrece una visión general de los archivos de registro y los servicios.

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 concreta de SFOS afectada o corregida ni un workaround soportado.

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

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

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 se ha probado 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 externas de Go-live están definidas.
El acceso está restringido a las fuentes o los países necesarios.
Threat Feeds y Active Threat Response se han evaluado 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 se ha probado externamente.
La fecha de vencimiento o la fecha de revisión está documentada.

Clasificar los objetos WAF mediante la API XML

Para las automatizaciones, la publicación, el backend y la política de protección están relacionados, pero siguen siendo objetos distintos. FirewallRule con PolicyType HTTPBased contiene HTTPBasedPolicy; RealServers describe el servidor web backend y ProtocolSecurity, la política de protección. La regla WAF referencia estos objetos; no sustituye su configuración. El acceso, la verificación TLS, los secretos, las operaciones de escritura explícitas y la evaluación del estado XML se explican en Limitar de forma segura el acceso a la API XML.

Las siguientes correspondencias explican las referencias de SFOS 22/23, pero no son plantillas de solicitud ejecutables. Antes de cualquier escritura, contrastar la API help de la compilación instalada con el objeto existente, preparar una copia de seguridad y un procedimiento de reversión, y comprobar primero una consulta de lectura inocua. Si la sintaxis, la unidad o la correspondencia de las acciones no están aclaradas, no escribir, sino solicitar su aclaración al soporte. Esto se aplica especialmente después de un cambio de versión.

No confundir la publicación con las rutas de acceso

Name identifica la FirewallRule; la referencia permite un máximo de 60 caracteres, sin comas y en UTF-8. Position es obligatorio e indica Bottom, Top, After o Before; las dos últimas variantes requieren también la regla de referencia identificada por su nombre. Para Status, la tabla indica el valor predeterminado ON y los valores de escritura Disable y Enable: omitirlo no es una forma segura de preparar una publicación desactivada. Según la tabla, LogTraffic tiene el valor predeterminado Disable; comprobar expresamente el registro. IPFamily también ofrece IPv6 en el contrato común de FirewallRule, pero HTTPBasedPolicy está limitado expresamente a IPv4. Las reglas de red y de usuario se tratan en Reglas de firewall, y no deben incorporarse como carga útil WAF.

En la sección WAF, HostedAddress, ListenPort, HTTPS, HTTPSCertificate y Domains/Domain corresponden al listener público. La tabla enumera HostedAddress, ListenPort, HTTPS y Domains como campos obligatorios. ListenPort es un entero de 1 a 65535; se documentan 80 con HTTPS desactivado y 443 con HTTPS activado. No es el puerto del backend. RedirectHTTP es la redirección HTTP independiente. Comprobar conjuntamente el nombre público, el certificado y el listener después de cada cambio.

Las asignaciones de rutas se encuentran en HTTPBasedPolicy/AccessPaths/AccessPath. Dentro de este bloque, backend referencia los objetos de servidor web; allowed_networks, denied_networks, blocked_countries y block_unknown_country describen el acceso de los clientes. stickysession_status y hot_standby corresponden a la persistencia de sesión y a la selección del backend. Una política de autenticación referenciada se explica en el artículo sobre autenticación WAF; la existencia de un campo por sí sola no aplica MFA para todas las acciones.

Diferencia entre versiones: La tabla de SFOS 22 describe path como una cadena individual y backend como un array obligatorio. En SFOS 23, path es un array con varios valores, mientras que backend figura como opcional. Según la tabla, los valores de ruta están limitados a 63 caracteres y no pueden contener comas. Aquí, opcional no significa que tenga sentido publicar una ruta Protect o Passthrough sin un backend asignado: la interfaz actual exige seleccionar un backend para estas acciones, mientras que Block y Redirect no publican ningún backend.

SFOS 23 añade action en minúsculas con los valores permitidos 0, 1, 2, 3, además de response_code, redirect_protocol, redirect_host, redirect_port y redirect_path. La referencia no asigna los cuatro números a las acciones de la interfaz. No construir una correspondencia a partir del orden o de suposiciones; disponer de la correspondencia confirmada para la compilación instalada es un requisito previo para cualquier cambio automatizado. Action, con mayúscula inicial y los valores Accept, Drop, Reject, aparece en el ejemplo bajo UserPolicy o NetworkPolicy, no en el bloque WAF. No sustituye ni a la acción WAF externa de la interfaz ni a AccessPath/action. Para redirect_protocol, la tabla indica literalmente http y https; para redirect_port, de 1 a 65535; y para redirect_path, un máximo de 8192 caracteres. Allí, response_code solo se describe como un entero; la selección de la interfaz indicada arriba sigue siendo determinante para la configuración concreta.

El ejemplo tampoco demuestra el esquema: mezcla path y Path, contiene referencias vacías y marcadores de posición, y no muestra por completo HTTPSCertificate ni LogTraffic en el bloque WAF. SFOS 22 todavía muestra websocket_passthrough; SFOS 23 utiliza el modelo de acciones. Por tanto, confirmar la escritura exacta, el anidamiento, los campos necesarios y el registro en el contrato específico de la compilación, en lugar de completar mecánicamente el ejemplo. ProtocolSecurity en el bloque WAF referencia la política de protección. Los controles avanzados PassHostHeader, RewriteHTML, RewriteCookies y CompressionSupport corresponden a los ajustes del proxy inverso explicados arriba; no unificar los valores contradictorios del ejemplo y de la tabla en enumeraciones propias.

El ejemplo muestra además SourceNetworks/Network y ExceptionNetworks/Network, mientras que su comentario menciona como alternativas Authentication, AllowFrom, BlockFrom o AccessPaths. No deducir de ello equivalencia entre alias, combinaciones permitidas ni reglas de precedencia. En los objetos existentes con esta representación del acceso, aclarar la estructura y el efecto en la compilación instalada; si siguen sin aclararse, no realizar escrituras automatizadas.

Para las excepciones existe un bloque independiente Exceptions/Exception. En él, path, source y op combinan las condiciones; la tabla indica literalmente and, or, AND, OR para op. skipcookie, skipurl, skipform, skipav y skipbadclients omiten las comprobaciones correspondientes. En cambio, skiphtmlrewrite impide modificar los contenidos coincidentes, y skipform_missingtoken permite datos de formulario sin firma de hardening, además de la excepción de formulario. La fila correspondiente de la tabla intercambia la descripción y el valor predeterminado; no deducir de ella un valor predeterminado fiable. Las consecuencias de seguridad de ambas opciones descritas arriba siguen siendo determinantes. skip_threats_filter_categories utiliza tokens distintos de los de la política de protección, por ejemplo, application_attacks y data_leakages. No confundir estos tokens de excepción con los nombres mostrados en la política. El texto descriptivo obsoleto sobre categorías anteriores tampoco autoriza el uso de tokens antiguos. Después de un cambio, comprobar por separado la ruta permitida, la ruta bloqueada, la ruta por defecto y una solicitud no exenta.

La tabla describe path para rutas de Site-Path; en cambio, el ejemplo de excepción muestra varios elementos path dentro de una Exception, sin un contrato propio inequívoco definido en la tabla. Por tanto, no se deben aplicar a las excepciones la cardinalidad ni los límites de las rutas de enrutamiento. Antes de realizar cambios automatizados en las excepciones, confirmar la estructura, la cantidad y los valores permitidos en la compilación instalada; si el contrato no está aclarado, no efectuar escrituras.

Comprobar de forma segura el contrato del backend y el tiempo de espera

En RealServers, Name, Host, Port y TimeOut están documentados como campos obligatorios. Name permite un máximo de 60 caracteres UTF-8 sin comas. Host es la referencia a un objeto de host IP o FQDN, no un nombre público WAF intercambiable libremente. Port va de 1 a 65535, con el valor predeterminado de API 80; Type indica literalmente Plaintext (HTTP) o Encrypted (HTTPS). Por tanto, para un backend HTTPS, contrastar expresamente el listener y el puerto reales, en lugar de adoptar el puerto predeterminado de la API.

La API describe TimeOut con el valor predeterminado 300, el intervalo de 1 a 65535 y la indicación de que solo se aplica cuando Keep alive está activado. En cambio, la GUI explica Timeout como el tiempo de espera de datos hacia o desde el backend e indica un HTTP-502 cuando se agota. Es una descripción diferente, no una prueba de comportamiento idéntico con Keep-alive desactivado. Para las configuraciones de la interfaz, utilizar la prueba de pausas en la transferencia de datos descrita arriba; antes de una automatización, aclarar la dependencia y el valor almacenado en la compilación instalada. No deducir de ello un aumento global del tiempo de espera.

Para KeepAlive, el ejemplo muestra Enable/Disable, pero la tabla solo indica 0 y Enable, así como el valor predeterminado ON. No corregir silenciosamente esta discrepancia mediante un supuesto Disable. DisableReuse indica Disable y Enable y corresponde a Disable backend connection pooling. Guardar el estado anterior, volver a leer el objeto modificado y solo después comprobar una transferencia de datos representativa y los registros del backend. Una respuesta de la API por sí sola no demuestra ni la accesibilidad del backend ni la adecuación de los ajustes de conexión.

Política de protección y opciones dependientes

Según la tabla, ProtocolSecurity requiere Name, Mode y RequestSizeLimit. Para Name se permite un máximo de 60 caracteres UTF-8 sin comas; Mode indica Monitor y Reject. Los controles CookieSigning, StaticUrlHardening y FormHardening corresponden a la protección de cookies, URL y formularios descrita arriba. Según la tabla, PassOutlookAnywhere tiene el valor predeterminado OFF: la API describe brevemente el acceso a Exchange, mientras que la GUI menciona expresamente la omisión de Web Server Protection. Por tanto, dejarlo desactivado si no existe un caso de uso heredado justificado; no tratarlo como un control de compatibilidad ordinario. Con StaticUrlHardening activado, la referencia describe EntryURLType con Manual, SitemapFile, SitemapURL; para el caso manual, el ejemplo muestra EntryURLList/EntryURL, con varias URL de entrada de un máximo de 255 caracteres cada una. No deducir de ello que la GUI ofrece todas las variantes de la API de forma idéntica.

La tabla de la API indica que CookieSigning, StaticUrlHardening, FormHardening, AntiVirus, BlockClientsWithBadReputation y ThreatsFilter tienen cada uno el valor predeterminado OFF, y ParanoiaLevel, el valor predeterminado 1. Por tanto, una Policy nueva o referenciada no demuestra por sí sola que las comprobaciones de protección estén activadas. Al crearla, configurar explícitamente los controles previstos y volver a leer sus valores. Al usar Edit sin un contrato de actualización confirmado, no presuponer ni la conservación de los campos omitidos ni su restablecimiento a los valores predeterminados.

Con AntiVirus activado, pasan a ser relevantes AVMode (Avira, Sophos, DualScan), Direction (Uploads, Downloads, UploadsAndDownloads), BlockUnscannableContent y LimitScanSize. El entero Megabytes depende además de que LimitScanSize esté activado. Esto sigue siendo independiente del límite del cuerpo. SkipRemoteLookups depende de BlockClientsWithBadReputation; no deducir el efecto de la comprobación de reputación únicamente de la breve descripción de la API.

ThreatsFilter activa el filtro de amenazas comunes. Incluye ThreatFilters/Filter, ParanoiaLevel de 1 a 4 y SkipFilterRules/FilterRules como lista de identificadores de regla enteros. Los tokens de filtro permitidos son literalmente Application attacks, SQL injection attacks, XSS attacks, Protocol enforcement, Scanner detection, Data leakages. El último token difiere del nombre de la GUI Data leakage. Aplicar excepciones específicas solo a falsos positivos demostrados y comprobar después el resto de la protección; el nivel, la categoría y la excepción son decisiones distintas.

RequestSizeLimit sigue presentando un conflicto entre fuentes: La tabla de la API lo indica como obligatorio, con el valor predeterminado 10, la descripción «Megabytes» y un intervalo de enteros de 1 a 1073741824. En cambio, la GUI actual documenta de 1 a 1024 MB, con el valor predeterminado 10 MB. En el ejemplo de la API, RequestSizeLimit falta por completo. No deducir de ello ni una conversión entre bytes y MB, ni un límite ampliado para producción, ni que sea seguro considerarlo opcional. Para la GUI, utilizar el intervalo documentado en MB; utilizar un valor de escritura de API solo después de confirmar la unidad, el intervalo y el comportamiento del campo obligatorio en la compilación instalada. Lo mismo se aplica al identificador de la tabla HSTS Enforcement, que falta en el ejemplo: no inventar una etiqueta XML a partir del nombre. XContentTypeOptions describe la protección MIME; comprobar externamente la asignación de política almacenada y las cabeceras reales.

Distinguir las respuestas XML según la operación

Los siguientes números son estados de objetos XML, no códigos de estado HTTP. Message.* designa aquí un nombre de símbolo sin resolver procedente de la referencia, no un mensaje de error traducido ni una prueba de una causa exacta. Comprobar conjuntamente la respuesta, la operación y el estado almacenado del objeto; ante errores, advertencias o posibles cambios parciales, nunca volver a escribir a ciegas. La guía central de seguridad de la API explica el procedimiento seguro de comprobación y escalado.

Para las respuestas de FirewallRule relevantes para WAF, son especialmente importantes estas diferencias:

Add firewall rule: 200 → Message.FWRuleAddSuccess, 500 → Message.FWRuleAddFail, 502 → Message.FWRuleRecordExists. Edit firewall rule: 200 → Message.FWRuleEditSuccess, 202 → Message.FirewallRuleUpdateWithRename, 500 → Message.FWRuleEditFail, 502 → Message.FWRuleUpdateRecordExist. Con 202, volver a leer también el nombre del objeto y las referencias, no limitarse a reutilizar el nombre anterior.
Add firewall rule 541 → Message.VHIPRangeConflict. En cambio, Edit firewall rule 541 tiene Message.FWRuleFailMaxUser; el mismo código no debe dar lugar al mismo diagnóstico.
Add firewall rule 543 y Edit firewall rule 544 → Message.CannotSetupRedirectionFromHTTP. Add firewall rule 544 y Edit firewall rule 543 → Message.CannotUseDefaultPort. La correspondencia está invertida entre Add y Edit: comprobar el listener, el puerto y la redirección, en lugar de clasificar únicamente por el número.
En Add firewall rule y Edit firewall rule: 542 → Message.CannotUseTypeHTTP, 545 → Message.PortAlreadyExists, 546 → Message.CannotConfigureDomainWithAddrTypePort, 550 → Message.PortUsedInUserPortal, 553 → Message.CannotConfigureDomainWithHTTPSRedirection. Contrastar la configuración existente de listeners y dominios; no cambiar las aperturas de puertos basándose en suposiciones.
En ambas operaciones: 547 → Message.warn_update_business_policy; tanto 548 como 549 utilizan Message.MaxIPv4ForAppServerAllowed. La asignación duplicada del símbolo no demuestra la existencia de distintos límites inventados. Comprobar la advertencia y el estado WAF realmente almacenado.
Add firewall rule 554 → Message.CannotUseFQDNWildCardAsProtectedServer; Edit firewall rule 554 → Message.CannotUpdateFQDNWildCardAsProtectedServer. No confundir los dominios públicos con comodines con un host backend adecuado. Edit firewall rule 552 → Message.CannotImportDiffPolicytypeWithSameName: comprobar el nombre y el tipo de política, no sobrescribir otro objeto.
En Add, Edit y Delete firewall rule: 596 → Message.CMLOCALOperationrestriction. Para Delete se indican además 200 → Message.FWDelSuccess y 500 → Message.FWRuleDeleteFail. Aclarar la responsabilidad de administración y las referencias antes de volver a intentarlo. La página de Delete califica Name como opcional y utiliza un texto descriptivo inadecuado sobre Before/After; esto no constituye una plantilla de eliminación segura. Confirmar el destino exacto y el contrato de Remove específico de la compilación; de lo contrario, no eliminar.

El backend y la política de protección también tienen sus propias series de respuestas: Add Web Server 200/500/502 corresponden a Message.RealServerAddSuccess/Message.RealServerAddFail/Message.RealServerRecodExist; Update Web Server 200/500, a Message.RealServerUpdateSuccess/Message.RealServerUpdateFail. Add Protection Policy 200/500/502 corresponden a Message.ProtocolSecurityAddSuccess/Message.ProtocolSecurityAddFail/Message.ProtocolSecurityRecodExist; Edit Protection Policy 200/500, a Message.ProtocolSecurityUpdateSuccess/Message.ProtocolSecurityUpdateFail. Las grafías RecodExist se conservan literalmente; no son nombres de símbolos corregidos. Ante colisiones de nombres, leer primero el objeto existente; eliminar y volver a crear no es una estrategia segura de reintento predeterminada.

Para el objeto global WAFSlowHTTP, RequestHeaderTimeoutEnabled, RequestHeaderTimeoutSoftLimit, RequestHeaderTimeoutHardLimit y RequestHeaderTimeoutExtensionRate corresponden al control de activación y a los tres límites explicados arriba. Los cuatro están documentados como campos obligatorios; el control indica Disable y Enable, y los demás valores son enteros sin un intervalo especificado. NetworkExceptions/Host es una lista opcional de referencias de host. Los valores de ejemplo 10, 30, 5000 no son valores predeterminados demostrados. SlowHTTP Protection indica 200 con Operation Successful. y 500 con Operation Fail.. Los cambios siguen siendo globales: comprobar los valores almacenados y las excepciones acotadas, y validar todas las publicaciones afectadas con clientes legítimos lentos.

Preguntas frecuentes

¿Reemplaza WAF el parcheo del servidor web?

No. WAF puede detectar o bloquear ataques, pero no puede compensar permanentemente una aplicación insegura. El sistema operativo, el servidor web, los frameworks, los plugins y el código de la aplicación deben seguir siendo mantenidos.

¿Se necesita DNAT adicionalmente?

Normalmente no para la misma publicación web. La regla WAF se encarga de la publicación a través de la Hosted address y reenvía las solicitudes al servidor web protegido. DNAT sigue siendo relevante para otros protocolos o aplicaciones web no soportadas.

¿Por qué el servidor web no ve la IP real del cliente?

El firewall actúa como un Proxy Inverso. Por lo tanto, el servidor web a menudo ve el firewall como la dirección de origen. La IP original del cliente está en el encabezado X-Forwarded-For, siempre que la aplicación o el servidor web evalúe este encabezado.

¿Se pueden publicar varios sitios web a través de la misma IP pública?

Sí, en HTTPS el firewall utiliza SNI y el nombre de host para elegir la regla WAF adecuada o el servidor web virtual correspondiente. DNS, certificado y dominios en la regla WAF deben coincidir adecuadamente para ello.

¿Se debe usar WAF para Nextcloud?

No sin una revisión cuidadosa. WebDAV está documentado como un caso no soportado por WAF. Dado que Nextcloud utiliza intensivamente WebDAV, una publicación a través de WAF no es adecuada en muchos entornos.

¿Protegen los Threat Feeds también las reglas WAF?

Bajo SFOS 22, los Threat Feeds también pueden ser relevantes para el tráfico entrante y reenviado como publicaciones WAF y DNAT. Para que esto se convierta en una protección real, los feeds, el registro, las alertas, la responsabilidad y el proceso de falsos positivos deben gestionarse adecuadamente.