Bloquer correctement QUIC et HTTP/3 avec Sophos Firewall

QUIC est un protocole de transport moderne et chiffré sur UDP ; HTTP/3 utilise QUIC comme transport. Les deux termes sont donc étroitement liés, sans être identiques. Les navigateurs et services Web utilisent généralement HTTP/3 sur UDP 443. Pour l’administrateur, l’essentiel est que ce chemin diffère du HTTPS classique sur TCP.

Sur Sophos Firewall, cela compte parce que la documentation SFOS 22 indique que le filtre Web ne peut pas analyser QUIC et que QUIC contourne Web Filtering. Lorsqu’une règle client doit imposer une Web Policy, l’analyse des malwares ou une inspection TLS sur TCP, Block QUIC protocol est donc la méthode standard documentée. L’option n’attend pas d’identifier un handshake QUIC : dans le périmètre de la règle correspondante, elle rejette tous les paquets UDP sortants vers les ports de destination 80 et 443.

Quel article de protection Web convient ?

QUIC n’est généralement pas l’objectif principal, mais un facteur perturbateur dans les scénarios de protection Web, d’inspection TLS ou de dépannage. Selon la tâche, un autre point de départ est approprié :

• Planifier les politiques Web, les groupes d’URL, SafeSearch et le filtrage Web en général: Configurer la protection Web de Sophos Firewall avec des politiques Web
• Gérer les catégories Web et les alertes instantanées: Utiliser les catégories Web et les alertes instantanées de Sophos Firewall
• Déchiffrer le trafic HTTPS et le déployer de manière contrôlée: Introduire correctement l’inspection TLS de Sophos Firewall
• Vérifier quelle règle de pare-feu est réellement appliquée: Tester la règle de Sophos Firewall avec Log Viewer et Packet Capture

Cet article répond principalement à la question de savoir quand et comment bloquer QUIC ou HTTP/3 dans la règle de pare-feu appropriée et comment valider proprement ensuite.

Ce que QUIC signifie pour le pare-feu

Le HTTPS classique fonctionne généralement sur TCP 443. Le pare-feu peut alors, selon la règle, la politique Web, le moteur DPI, le proxy Web et l’inspection SSL/TLS, décider si le trafic est simplement autorisé, catégorisé, déchiffré, analysé ou bloqué.

HTTP/3 déplace ce trafic Web vers QUIC sur UDP. Pour le pare-feu, cela signifie :

• Le trafic Web ne ressemble plus au HTTPS classique sur TCP.
• QUIC peut contourner Web Filtering de SFOS et son filtre Web ne peut pas l’analyser.
• L’inspection TLS ne fonctionne pas comme avec le HTTPS normal sur TCP.
• Le dépannage devient plus difficile lorsque les navigateurs passent automatiquement de TCP à QUIC.
• Le testeur de politique, le Log Viewer et le Packet Capture doivent être comparés consciemment avec le protocole et le port.

L’option Block QUIC protocol rejette les paquets UDP sortants vers les ports de destination 80 et 443 lorsque le trafic répond aux critères de cette règle. Si le client emprunte une autre règle, l’option reste sans effet. Comme le blocage repose sur les ports, il peut aussi toucher une application non-QUIC utilisant UDP 80 ou 443. Les navigateurs courants essaient généralement HTTPS sur TCP après l’échec de HTTP/3, mais ce repli doit être vérifié pour chaque application critique.

Cela ne déchiffre pas automatiquement HTTPS. Le blocage de QUIC place seulement le trafic dans un chemin TCP plus contrôlable. Ensuite, c’est le reste de la configuration des règles et de l’inspection qui détermine si la politique Web, l’analyse des malwares, Application Control ou l’inspection TLS s’appliquent.

Quand bloquer QUIC

Dans de nombreux réseaux clients en production, il est judicieux de bloquer QUIC si une ou plusieurs de ces affirmations sont vraies :

• Le filtrage Web doit être fiable.
• L’analyse des malwares pour les téléchargements Web est importante.
• L’inspection TLS est utilisée pour des catégories ou des groupes d’utilisateurs sélectionnés.
• Le contrôle des applications doit mieux reconnaître les applications Web.
• Les accès Web doivent être traçables dans le Log Viewer.
• Le helpdesk et l’équipe de sécurité doivent pouvoir effectuer des tests reproductibles.

Autoriser QUIC peut être un choix conscient sur un Wi-Fi invité sans Web Filtering ni inspection de contenu ; il faut alors documenter que le filtre Web SFOS n’analyse pas ce chemin UDP. Pour un réseau géré ou un périmètre de conformité, le blocage par règle est généralement plus facile à justifier. Testez séparément serveurs et applications spécialisées, car tout client QUIC ne garantit pas un repli TCP.

Vérifier le paramètre dans la règle de pare-feu

L’emplacement habituel est la règle de pare-feu sortante, par exemple LAN_to_WAN_Clients. Dans SFOS 22, l’option se trouve sous Security features > Web filtering > Block QUIC protocol.

Chemin du menu :

Rules and policies > Firewall rules

Procédure :

Pour un pilote, copiez la règle Internet existante ou créez au-dessus une règle étroite. Un exemple documentable utilise Source zones: LAN, Source networks and devices: CLIENT-WEB-01 avec 10.20.30.50, Destination zones: WAN, Destination networks: Any, ainsi que les Services et Security Policies déjà nécessaires en production. Remplacez l’adresse et les noms par un client de test clairement identifiable ; conservez d’abord Destination, NAT et profils de protection du chemin précédent.

1. Ouvrir la règle Internet client concernée.
2. Aller dans Security features > Web filtering.
3. Activer Log firewall traffic afin que les tests soient visibles dans le Log Viewer.
4. Vérifier la Web Policy prévue et Scan HTTP and decrypted HTTPS.
5. Laisser Block QUIC protocol activé ou l’activer consciemment.
6. Activer Scan HTTP and decrypted HTTPS uniquement si l’on sait clairement comment HTTPS est déchiffré.
7. En DPI Mode, vérifier que Use web proxy instead of DPI engine n’est pas activé par erreur.
8. En Web Proxy Mode, vérifier si Decrypt HTTPS during web proxy filtering et la distribution de la CA correspondent à l’objectif.
9. Enregistrer la règle.
10. Vérifier le client de test et contrôler le Log Viewer.

SFOS 22 sélectionne Block QUIC protocol par défaut dès qu’une Web Policy est choisie ou que Scan HTTP and decrypted HTTPS est activé. Il s’agit d’une valeur par défaut de l’interface pour cette règle, et non d’une politique globale. Après une migration, une copie ou un changement d’ordre, contrôlez de nouveau la règle qui correspond réellement.

Plus d’informations sur les différentes options d’une règle de pare-feu sont disponibles dans Comprendre et configurer correctement les règles de Sophos Firewall.

Ne pas désactiver QUIC uniquement via le navigateur

Il était courant auparavant de désactiver QUIC directement dans le navigateur ou via les Chrome Flags. Cela peut aider pour les tests, mais ce n’est pas un concept de sécurité fiable :

• Les paramètres du navigateur changent.
• Non seulement Chrome peut utiliser QUIC ou HTTP/3.
• Les utilisateurs ou les mises à jour peuvent réinitialiser les paramètres.
• Les appareils BYOD, invités et non gérés sont difficiles à contrôler de cette manière.
• Les politiques de sécurité doivent être traçables de manière centralisée sur le pare-feu.

Pour les environnements de production, la règle de pare-feu est un meilleur emplacement. Les tests côté navigateur peuvent être utiles en complément si l’on souhaite cerner une erreur.

Bien positionner Application Control et les règles UDP personnalisées

En plus de Block QUIC protocol, il existe d’autres moyens de restreindre le trafic QUIC.

• Block QUIC protocol dans la règle de pare-feu : cas standard pour le filtrage Web et l’analyse. Limite : le paramètre ne s’applique qu’au trafic qui correspond à cette règle.
• Application Control : la détection et la journalisation par signatures peuvent compléter le blocage. Vérifiez sous Applications > Application list si la version actuelle des patterns propose une entrée QUIC adaptée ; une ancienne capture ne prouve pas le catalogue actuel. Un Application Filter n’agit qu’après son affectation à la règle correspondante sous Other security features > Identify and control applications (App control).
• Règle de rejet personnalisée pour UDP 80/443 : blocage technique très clair. Limite : la règle doit être correctement positionnée et limitée aux réseaux clients.
• Configuration du navigateur : utile pour des tests courts ou des environnements spéciaux gérés. Limite : pas assez robuste comme seule politique de pare-feu.

Si une règle de rejet personnalisée est utilisée, elle doit être placée au-dessus des règles Internet client générales et être correctement journalisée. Sinon, il ne sera pas clair plus tard si QUIC a été bloqué consciemment ou si le trafic est bloqué ailleurs.

Si un changement exige une règle de blocage distincte, créez par exemple QUIC_UDP_80_443 sous Hosts and services > Services > Add avec Type of service: UDP et Destination port: 80,443. Laissez la valeur par défaut Source port: 1:65535 inchangée. La règle au-dessus de l’Allow général utilise Action: Drop, Source zones: LAN, l’objet pilote dans Source networks and devices, Destination zones: WAN, Destination networks: Any, ce Service et Log firewall traffic. Adaptez nom, périmètre Source et position ; conservez des ports UDP ciblés et validez séparément l’impact non-QUIC possible.

Application Control ne remplace pas à l’identique l’option documentée basée sur les ports lorsqu’il faut imposer le chemin TCP du filtre Web. Les signatures évoluent avec les mises à jour des patterns et les micro-apps fondées sur l’URL exigent que la DPI Engine voie l’URL déchiffrée. Corrélez donc les journaux Application, Firewall, Web et SSL/TLS Inspection.

Lien avec l’inspection TLS

Block QUIC protocol n’est pas un substitut à l’inspection TLS. Le paramètre garantit simplement que les navigateurs ne continuent pas à communiquer via QUIC pour le trafic correspondant, mais reviennent normalement au HTTPS sur TCP.

Ensuite, la question TLS se pose :

• Existe-t-il une règle d’inspection SSL/TLS appropriée ?
• Le certificat CA est-il distribué sur les clients ?
• Le trafic est-il déchiffré ou consciemment non déchiffré ?
• Scan HTTP and decrypted HTTPS est-il actif dans la règle de pare-feu ?
• Y a-t-il des exceptions pour les applications avec épinglage de certificat ?

Si le contenu HTTPS doit être vérifié, un déploiement TLS planifié est nécessaire. Les détails sont disponibles dans Introduire correctement l’inspection TLS de Sophos Firewall.

Le mode de fonctionnement de la règle est important. En DPI Mode, les règles SSL/TLS Inspection sous Rules and policies > SSL/TLS inspection rules s’appliquent. En Web Proxy Mode, le déchiffrement HTTPS est piloté par les paramètres du proxy Web et l’option Decrypt HTTPS during web proxy filtering. Lorsque ces deux modèles sont mélangés, QUIC ressemble vite au problème principal alors que l’architecture d’inspection n’est pas claire.

Bien choisir entre DPI Engine et Web Proxy explique le choix fonctionnel et la migration entre ces chemins de trafic.

Prouver l’effet par un test positif et un test négatif

Le seul fait que le site soit accessible ne prouve pas le repli. La validation distingue trois questions : la règle attendue a-t-elle rejeté UDP 443, une nouvelle connexion TCP a-t-elle ensuite été établie et la décision Web ou TLS prévue s’est-elle appliquée sur ce chemin ?

Procédure de test pratique :

1. Noter l’état initial, la Rule ID, l’IP client, la cible et l’heure. Confirmer d’abord que la cible génère une tentative UDP 443, sinon le test ne dit rien sur QUIC.
2. Activer Log firewall traffic et, facultativement, remettre à zéro le Usage Counter de la règle pilote.
3. Sous Diagnostics > Packet capture, cliquer sur Configure et saisir host 10.20.30.50 and proto UDP and dst port 443 dans Enter BPF string, en remplaçant l’IP. Démarrer la capture, fermer complètement puis rouvrir le navigateur et appeler la cible préparée.
4. Sous Diagnostics > Packet capture > Display filter, filtrer avec Source IP, Destination port: 443, Reason: Firewall et la Rule ID attendue. Un paquet UDP au statut Violation dans cette règle constitue la preuve positive ; la seule absence d’UDP ne suffit pas.
5. Remplacer le filtre par host 10.20.30.50 and proto TCP and dst port 443 et créer une nouvelle connexion. Le handshake TCP et la Rule ID attendue prouvent le chemin réseau.
6. Dans Log viewer > Firewall, corréler heure, Source IP, destination, Rule ID, protocole et port. Les sessions apparaissent souvent au Connection Destroy event ; vérifier aussi une connexion ouverte sous Current activities > Live connections.
7. Pour Web Protection, effectuer dans le même périmètre une requête autorisée et une requête bloquée par la Web Policy. Pour TLS Inspection, contrôler aussi SSL/TLS inspection, la Decryption Rule et l’émetteur du certificat visible. Scan HTTP and decrypted HTTPS ne prouve pas à lui seul le déchiffrement.
8. Pour le test négatif, retirer temporairement le pilote du périmètre ou rétablir l’ancien état de Block QUIC protocol, créer une session et vérifier le retour d’UDP 443 sur le chemin attendu. Restaurer ensuite l’état approuvé.

Pour les tests de règles, l’instruction Tester la règle de Sophos Firewall avec Log Viewer et Packet Capture est appropriée.

Erreurs typiques

• Blocage de QUIC activé uniquement dans une ancienne ou mauvaise règle: Le trafic client actuel passe par une autre règle
• La règle est en dessous d’une règle d’autorisation plus générale: QUIC est autorisé avant
• Le journal est désactivé: Il n’est pas visible dans le Log Viewer ce qui se passe
• Une session de navigateur existante est réutilisée: Redémarrer le navigateur ou utiliser un profil de test avant d’évaluer les journaux
• Seul Chrome est ajusté localement: D’autres navigateurs ou appareils continuent d’utiliser QUIC
• L’inspection TLS est attendue mais non configurée: Le contenu HTTPS n’est pas déchiffré malgré le blocage de QUIC
• Scan HTTP and decrypted HTTPS est mal compris: L’option analyse uniquement le HTTPS déjà déchiffré
• DPI Mode et Web Proxy Mode sont mélangés: Le paramètre recherché se trouve alors peut-être à un autre endroit
• UDP 443 est bloqué globalement: Des applications spécialisées peuvent être affectées de manière inattendue

Dépannage et versions de SFOS 22

Si le filtrage Web ou l’analyse ne fonctionne pas comme prévu, il convient de vérifier cette séquence :

1. À quelle règle de pare-feu le trafic client correspond-il réellement ?
2. Block QUIC protocol est-il actif dans cette règle précise ?
3. Le client utilise-t-il UDP 443 ou TCP 443 ?
4. Log firewall traffic est-il activé ?
5. Une règle plus spécifique s’applique-t-elle au-dessus ?
6. Existe-t-il une politique de contrôle des applications qui traite QUIC différemment ?
7. Existe-t-il une règle d’inspection SSL/TLS si le contenu HTTPS doit être vérifié ?
8. DPI Mode ou Web Proxy Mode est-il utilisé ?
9. Packet Capture montre-t-il des paquets UDP 443 sortants malgré le blocage attendu ?

Si la capture montre encore des paquets Forwarded, vérifiez d’abord Rule ID, objet Source, chemin IPv4/IPv6, Services et ordre des règles. Le paquet peut correspondre à une autre règle ; cocher une règle non correspondante ne crée pas un blocage global. En l’absence de toute tentative UDP, utilisez une autre cible compatible HTTP/3 avant de conclure à un défaut du pare-feu.

Si la Web Policy ne s’applique pas après le repli TCP, QUIC n’est pas nécessairement en cause. Pour une règle contenant plusieurs utilisateurs ou groupes, le build compte aussi : les Release Notes officielles indiquent dans SFOS 22.0 MR1 Build 490 le correctif NC-176376 pour des règles Web Policy à plusieurs groupes ou utilisateurs devenues inopérantes après une mise à niveau vers 22.0 GA. Vérifiez build, Rule ID et contexte utilisateur avant de modifier QUIC ou TLS ; toute mise à niveau suit le processus de sauvegarde et de changement habituel.

Si la règle ne correspond pas, le problème principal n’est pas QUIC, mais l’ordre des règles, la zone source, le réseau source, la destination, le service ou l’exclusion. Pour cela, Vérifier les causes de la non-correspondance de la règle de pare-feu peut aider.

Liste de contrôle opérationnelle

• Règle Internet client concernée clairement identifiée.
• Politique Web, analyse des malwares ou inspection TLS vérifiée dans cette règle précise.
• Block QUIC protocol activé consciemment ou désactivé avec justification.
• DPI Mode ou Web Proxy Mode décidé consciemment.
• Ordre des règles et règles d’autorisation plus générales vérifiés.
• Log firewall traffic actif.
• Test effectué avec le navigateur et le site cible réel.
• Log Viewer vérifié pour UDP 443, TCP 443, ID de règle et événements Web.
• Pour l’inspection TLS, journaux d’inspection SSL/TLS vérifiés en plus.
• Exceptions ou règles UDP personnalisées documentées.
• Le helpdesk sait que les sites Web devraient normalement continuer à fonctionner après le blocage de QUIC.

Retour arrière

Avant le pilote, consignez état et position de la règle, Block QUIC protocol, Web Policy, Application Filter, journalisation, NAT et mode TLS/proxy. Pour revenir en arrière, désactivez la règle pilote ou restaurez exactement l’ancien état des options et politiques. Fermez navigateur et sessions, puis vérifiez avec une nouvelle connexion l’ancienne Rule ID et l’ancien comportement UDP/TCP. Supprimez ensuite uniquement les objets propres au pilote, jamais des Services, filtres ou règles NAT partagés.

Questions fréquentes