Bloquear correctamente QUIC y HTTP/3 en Sophos Firewall

QUIC es un protocolo de transporte moderno y cifrado sobre UDP; HTTP/3 utiliza QUIC como transporte. Por tanto, ambos términos están estrechamente relacionados, pero no son idénticos. Los navegadores y servicios web suelen utilizar HTTP/3 sobre UDP 443. Para los administradores, lo decisivo es que esta ruta no corresponde al HTTPS clásico sobre TCP.

En Sophos Firewall esto importa porque la documentación de SFOS 22 indica que el filtro web no puede analizar QUIC y que QUIC elude Web Filtering. Si una regla de cliente debe imponer una Web Policy, escaneo de malware o inspección TLS basada en TCP, Block QUIC protocol es el método estándar documentado. La opción no espera a identificar un handshake QUIC: dentro del ámbito de la regla de firewall coincidente descarta todos los paquetes UDP salientes dirigidos a los puertos 80 y 443.

¿Qué artículo de protección web es adecuado?

QUIC casi nunca es el objetivo real, sino un factor que interfiere en escenarios de Web Protection, TLS Inspection o troubleshooting. Según la tarea, conviene empezar por otro artículo:

• Planificar Web Policy, URL Groups, SafeSearch y filtrado web en general: Configurar Sophos Firewall Web Protection con Web Policies.
• Usar categorías web e Instant Alerts: Utilizar categorías web e Instant Alerts en Sophos Firewall.
• Descifrar tráfico HTTPS y desplegarlo de forma controlada: Introducir correctamente Sophos Firewall TLS Inspection.
• Comprobar qué regla de firewall hace match realmente: Probar reglas de Sophos Firewall con Log Viewer y Packet Capture.

Este artículo responde sobre todo a la pregunta de cuándo y cómo bloquear QUIC o HTTP/3 en la regla de firewall adecuada y validarlo después de forma limpia.

Qué significa QUIC para el firewall

El HTTPS clásico suele funcionar sobre TCP 443. Según la regla, la Web Policy, la DPI Engine, el Web Proxy y la inspección SSL/TLS, el firewall puede decidir si el tráfico solo se permite, se categoriza, se descifra, se escanea o se bloquea.

HTTP/3 desplaza este tráfico web a QUIC sobre UDP. Para el firewall, significa:

• El tráfico web ya no parece HTTPS clásico sobre TCP.
• QUIC puede eludir Web Filtering de SFOS y su filtro web no puede analizarlo.
• TLS Inspection no se aplica como en HTTPS normal sobre TCP.
• El troubleshooting se complica cuando los navegadores cambian automáticamente entre TCP y QUIC.
• Policy Tester, Log Viewer y Packet Capture deben compararse de forma consciente por protocolo y puerto.

La opción Block QUIC protocol descarta paquetes UDP salientes hacia los puertos de destino 80 y 443 cuando el tráfico cumple los criterios de esa regla. Si el cliente sale por otra regla, la opción no tiene efecto. Como el bloqueo se basa en puertos, también puede afectar a una aplicación que no use QUIC pero sí UDP 80 o 443. Los navegadores habituales suelen intentar HTTPS sobre TCP cuando falla HTTP/3, pero esta alternativa debe comprobarse para cada aplicación crítica.

Esto no descifra HTTPS automáticamente. El bloqueo de QUIC solo lleva el tráfico a una ruta TCP más controlable. Que después se apliquen Web Policy, Malware Scan, Application Control o TLS Inspection depende del resto de la configuración de reglas e inspección.

Cuándo bloquear QUIC

En muchas redes productivas de clientes, bloquear QUIC es razonable si se cumple una o varias de estas afirmaciones:

• El filtrado web debe aplicarse de forma fiable.
• El escaneo de malware para descargas web es importante.
• La inspección TLS se utiliza para categorías o grupos de usuarios seleccionados.
• Application Control debe reconocer mejor las aplicaciones web.
• Los accesos web deben ser rastreables en el Log Viewer.
• El helpdesk y el equipo de seguridad deben poder realizar pruebas reproducibles.

Permitir QUIC puede ser una decisión consciente en una Wi-Fi de invitados sin Web Filtering ni inspección de contenido; se documenta entonces que el filtro web de SFOS no analiza esa ruta UDP. En redes administradas o dentro de cumplimiento suele ser más justificable el bloqueo por regla. Los servidores y aplicaciones especiales se prueban aparte, porque no todo cliente basado en QUIC garantiza fallback a TCP.

Verificar la configuración en la regla de firewall

El lugar habitual es la regla de firewall saliente, por ejemplo LAN_to_WAN_Clients. En SFOS 22, la opción está en Security features > Web filtering > Block QUIC protocol.

Ruta de menú:

Rules and policies > Firewall rules

Procedimiento:

Para un piloto se puede copiar la regla de Internet existente o crear encima una regla limitada. Un ejemplo documentable usa Source zones: LAN, Source networks and devices: CLIENT-WEB-01 con 10.20.30.50, Destination zones: WAN, Destination networks: Any y los Services y Security Policies ya necesarios en producción. Se sustituyen la IP y los nombres por un cliente inequívoco; Destination, NAT y perfiles de protección se mantienen inicialmente sin cambios.

1. Abrir la regla de Internet de clientes afectada.
2. Ir a Security features > Web filtering.
3. Activar Log firewall traffic para que las pruebas sean visibles en el Log Viewer.
4. Comprobar la Web Policy prevista y Scan HTTP and decrypted HTTPS.
5. Dejar activado Block QUIC protocol o activarlo conscientemente.
6. Activar Scan HTTP and decrypted HTTPS solo si también está claro cómo se descifra HTTPS.
7. En DPI Mode, comprobar que Use web proxy instead of DPI engine no esté activado por error.
8. En Web Proxy Mode, comprobar si Decrypt HTTPS during web proxy filtering y la distribución de la CA encajan con el objetivo.
9. Guardar la regla.
10. Comprobar el cliente de prueba y revisar el Log Viewer.

SFOS 22 selecciona Block QUIC protocol de forma predeterminada al elegir una Web Policy o activar Scan HTTP and decrypted HTTPS. Es un valor predeterminado de la interfaz para esa regla, no una política global. Después de migraciones, copias o cambios de orden, se vuelve a comprobar la regla que realmente coincide.

Hay más información sobre las opciones individuales de una regla de firewall en Entender y configurar correctamente las reglas de Sophos Firewall.

No desactivar QUIC solo en el navegador

Antes era habitual desactivar QUIC directamente en el navegador o mediante Chrome Flags. Esto puede ayudar en pruebas, pero no es un concepto de seguridad sólido:

• Las configuraciones del navegador cambian.
• No solo Chrome puede usar QUIC o HTTP/3.
• Los usuarios o actualizaciones pueden restablecer configuraciones.
• Los dispositivos BYOD, invitados y no administrados apenas pueden controlarse así.
• Las Security Policies deben ser trazables de forma centralizada en el firewall.

En entornos productivos, la regla de firewall es el mejor lugar. Las pruebas del lado del navegador pueden ser útiles como complemento cuando se quiere acotar un error.

Encajar correctamente Application Control y las reglas UDP propias

Además de Block QUIC protocol, hay otras formas de restringir el tráfico QUIC.

• Block QUIC protocol en la regla de firewall: caso estándar para filtrado web y escaneo. Límite: la opción solo se aplica al tráfico que hace match con esa regla.
• Application Control: la detección y el registro mediante firmas pueden complementar el bloqueo. En Applications > Application list se comprueba si la versión actual de patrones ofrece una entrada QUIC adecuada; una captura histórica no demuestra el catálogo actual. Un Application Filter solo actúa cuando se asigna a la regla coincidente en Other security features > Identify and control applications (App control).
• Regla Drop propia para UDP 80/443: bloqueo técnico muy claro. Límite: la regla debe estar bien posicionada y limitada a redes de clientes.
• Configuración del navegador: útil para pruebas breves o entornos especiales administrados. Límite: no es lo bastante robusta como única política de firewall.

Si se utiliza una regla Drop propia, debe estar por encima de las reglas generales de Internet para clientes y registrarse correctamente. De lo contrario, más adelante no se podrá saber si QUIC se bloqueó conscientemente o si el tráfico quedó detenido en otro punto.

Si un cambio exige una regla de bloqueo separada, se crea, por ejemplo, QUIC_UDP_80_443 en Hosts and services > Services > Add con Type of service: UDP y Destination port: 80,443. El valor predeterminado Source port: 1:65535 se deja sin cambios. La regla situada sobre el Allow general usa Action: Drop, Source zones: LAN, el objeto piloto en Source networks and devices, Destination zones: WAN, Destination networks: Any, este Service y Log firewall traffic. Nombre, Source scope y posición se adaptan al entorno; los puertos UDP se mantienen limitados y los posibles efectos sobre tráfico no QUIC se validan aparte.

Application Control no sustituye de forma equivalente a la opción documentada basada en puertos cuando se debe imponer la ruta TCP del filtro web. Las firmas cambian con las actualizaciones de patrones y las microaplicaciones basadas en URL requieren que la DPI Engine vea la URL descifrada. Por ello se correlacionan los logs de Application, Firewall, Web y SSL/TLS Inspection.

Relación con la inspección TLS

Block QUIC protocol no sustituye a TLS Inspection. La opción solo evita que los navegadores sigan comunicándose por QUIC cuando el tráfico coincide, y normalmente hace que vuelvan a HTTPS sobre TCP.

Solo después surge la verdadera pregunta de TLS:

• ¿Existe una SSL/TLS Inspection Rule adecuada?
• ¿El certificado de CA está distribuido en los clientes?
• ¿El tráfico se descifra o se deja sin descifrar conscientemente?
• ¿Está activa Scan HTTP and decrypted HTTPS en la regla de firewall?
• ¿Existen excepciones para aplicaciones con fijación de certificados?

Si se deben inspeccionar contenidos HTTPS, hace falta un despliegue TLS planificado. Los detalles están en Introducir correctamente Sophos Firewall TLS Inspection.

Es importante el modo operativo de la regla. En DPI Mode, las SSL/TLS Inspection Rules se aplican en Rules and policies > SSL/TLS inspection rules. En Web Proxy Mode, el descifrado HTTPS se controla mediante los ajustes de Web Proxy y la opción Decrypt HTTPS during web proxy filtering. Si se mezclan estos dos modelos, QUIC puede parecer rápidamente el problema principal, aunque en realidad no esté clara la arquitectura de inspección.

Elegir correctamente DPI Engine o Web Proxy explica la decisión funcional y de migración entre estas rutas de tráfico.

Demostrar el efecto con pruebas positiva y negativa

Que el sitio sea accesible no demuestra el fallback. La validación separa tres cuestiones: que la regla prevista descarte UDP 443, que después se establezca una nueva conexión TCP y que en esa ruta se aplique la decisión Web o TLS esperada.

Procedimiento de prueba práctica:

1. Anotar estado previo, Rule ID, IP del cliente, destino y hora. Confirmar primero que el destino genera un intento UDP 443; de lo contrario la prueba no dice nada sobre QUIC.
2. Activar Log firewall traffic y, opcionalmente, restablecer el Usage Counter de la regla piloto.
3. En Diagnostics > Packet capture, hacer clic en Configure e introducir host 10.20.30.50 and proto UDP and dst port 443 en Enter BPF string, sustituyendo la IP. Iniciar la captura, cerrar por completo y reabrir el navegador y solicitar el destino preparado.
4. En Diagnostics > Packet capture > Display filter, filtrar por Source IP, Destination port: 443, Reason: Firewall y la Rule ID esperada. Un paquete UDP con estado Violation en esa regla demuestra positivamente el bloqueo; la mera ausencia de UDP no lo hace.
5. Cambiar el filtro a host 10.20.30.50 and proto TCP and dst port 443 y crear una conexión nueva. El handshake TCP y la Rule ID esperada demuestran la ruta.
6. En Log viewer > Firewall, correlacionar hora, Source IP, destino, Rule ID, protocolo y puerto. Las sesiones suelen aparecer al Connection Destroy event; una conexión abierta se revisa también en Current activities > Live connections.
7. Si el objetivo es Web Protection, realizar desde el mismo ámbito una solicitud permitida y otra bloqueada por la Web Policy. Para TLS Inspection, comprobar además SSL/TLS inspection, la Decryption Rule y el emisor del certificado visible. Scan HTTP and decrypted HTTPS no demuestra por sí solo el descifrado.
8. Como prueba negativa, sacar temporalmente el piloto del ámbito o restaurar el estado previo de Block QUIC protocol, crear una sesión nueva y comprobar que UDP 443 reaparece en la ruta prevista. Después se restablece el estado aprobado.

Para pruebas de reglas, la guía Probar reglas de Sophos Firewall con Log Viewer y Packet Capture es adecuada.

Errores comunes

• Bloqueo de QUIC activado solo en una regla antigua o incorrecta: el tráfico actual del cliente pasa por otra regla.
• La regla está por debajo de una regla Allow más general: QUIC se permite antes.
• Logging está desactivado: no se ve en el Log Viewer qué ocurre.
• Se reutiliza una sesión de navegador existente: reiniciar el navegador o usar un perfil de prueba antes de evaluar los logs.
• Solo se ajustó Chrome localmente: otros navegadores o dispositivos siguen utilizando QUIC.
• Se espera TLS Inspection, pero no está configurada: los contenidos HTTPS no se descifran a pesar del bloqueo de QUIC.
• Scan HTTP and decrypted HTTPS se entiende mal: la opción solo escanea HTTPS ya descifrado.
• Se mezclan DPI Mode y Web Proxy Mode: la opción buscada puede estar entonces en otro lugar.
• UDP 443 se bloquea globalmente: aplicaciones especiales pueden verse afectadas inesperadamente.

Resolución de problemas y versiones de SFOS 22

Si el filtrado web o el escaneo no funcionan como se espera, se debe verificar este orden:

1. ¿Qué regla de firewall realmente coincide con el tráfico del cliente?
2. ¿Está Block QUIC protocol activo en esa regla específica?
3. ¿El cliente utiliza UDP 443 o TCP 443?
4. ¿Está activado Log firewall traffic?
5. ¿Una regla más específica está por encima?
6. ¿Existe una política de control de aplicaciones que trate QUIC de manera diferente?
7. ¿Existe una regla de inspección SSL/TLS si se deben verificar los contenidos HTTPS?
8. ¿Se usa DPI Mode o Web Proxy Mode?
9. ¿Packet Capture muestra paquetes UDP 443 salientes a pesar del bloqueo esperado?

Si la captura sigue mostrando paquetes Forwarded, se revisan primero Rule ID, objeto Source, ruta IPv4/IPv6, Services y orden de reglas. El paquete puede coincidir con otra regla; marcar una regla que no coincide no crea un bloqueo global. Si ni siquiera aparece un intento UDP, se usa otro destino compatible con HTTP/3 antes de atribuir el problema al firewall.

Si la Web Policy no actúa tras volver a TCP, QUIC no es automáticamente la causa. Para reglas con varios usuarios o grupos también importa el build: las Release Notes oficiales incluyen en SFOS 22.0 MR1 Build 490 el fix NC-176376 para reglas de Web Policy con más de un grupo o usuario que dejaron de funcionar tras actualizar a 22.0 GA. Se comprueban build, Rule ID y contexto de usuario antes de cambiar QUIC o TLS; una actualización sigue el proceso habitual de backup y cambio.

Si la regla no hace match, el problema principal no es QUIC, sino el orden de las reglas, la Source Zone, la Source Network, el Destination, el Service o una Exclusion. Para ello ayuda Comprobar causas cuando una regla de firewall no hace match.

Lista de verificación operativa

• Regla de Internet del cliente afectada identificada claramente.
• Política web, escaneo de malware o inspección TLS verificados en esa regla específica.
• Block QUIC protocol activado conscientemente o desactivado con justificación.
• DPI Mode o Web Proxy Mode decidido conscientemente.
• Orden de reglas y reglas de permiso más generales verificadas.
• Log firewall traffic activo.
• Prueba realizada con navegador y sitio de destino real.
• Log Viewer verificado para UDP 443, TCP 443, ID de regla y eventos web.
• En caso de inspección TLS, también se verificaron los registros de inspección SSL/TLS.
• Excepciones o reglas UDP propias documentadas.
• El helpdesk sabe que las páginas web deberían seguir funcionando normalmente después del bloqueo de QUIC.

Rollback

Antes del piloto se anotan estado y posición de la regla, Block QUIC protocol, Web Policy, Application Filter, logging, NAT y modo TLS/proxy. Para volver atrás se desactiva la regla piloto o se restaura exactamente el estado anterior de opciones y políticas. Se cierran navegador y sesiones existentes y una conexión nueva debe mostrar la Rule ID y el comportamiento UDP/TCP anteriores. Solo entonces se eliminan objetos exclusivos del piloto; no se borran Services, filtros ni reglas NAT compartidos.

Preguntas frecuentes