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.

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.

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.

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:

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.

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.

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:

Para los certificados, se debe aclarar temprano si se importará un certificado existente, 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.

Estructura básica de una regla WAF

Una publicación WAF consta de varios componentes:

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

Crear una regla WAF

La ruta del menú es:

Rules and policies > Firewall rules

Procedimiento:

1. Seleccionar IPv4.
2. Abrir Add firewall rule.
3. Seleccionar New firewall rule.
4. Asignar un nombre descriptivo a la regla.
5. En Action, elegir la opción Protect with web server protection.
6. Si no se necesita una plantilla especial, dejar Preconfigured template en None.
7. En Hosted server details, definir la dirección pública, el puerto de escucha, HTTPS, certificado y dominios.
8. En Protected servers, seleccionar o crear un nuevo servidor web interno.
9. Configurar conscientemente Allowed client networks. Para sitios web públicos, puede ser necesario Any IPv4, para portales, generalmente es mejor una restricción.
10. Si es necesario, configurar Blocked client networks o Blocked countries.
11. Revisar perfil de protección, IPS y opciones avanzadas.
12. Guardar la regla y probar externamente.

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.

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.

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.

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.
• Con varios nombres de host en la misma IP, el firewall utiliza SNI.
• Los certificados comodín son posibles, pero deben documentarse adecuadamente.
• 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.

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

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.

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.

Se debe tener en cuenta que el firewall no evalúa las rutas simplemente según el orden de las filas de la tabla. Las rutas específicas deben planificarse y probarse cuidadosamente. Si se necesita WebSocket, se puede activar WebSocket passthrough. El tráfico WebSocket se transmite sin la misma inspección WAF, ya que el protocolo no puede ser inspeccionado de la misma manera que el tráfico HTTP normal.

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.

Errores comunes

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. ¿Existe una regla WAF más general que coincida antes?
8. ¿El acceso se muestra en el Log Viewer como permitido, bloqueado o descartado?
9. ¿Hay indicios en /log/reverseproxy.log?

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 Sophos Firewall Troubleshooting: Servicios y Logs.

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