Bloquer correctement QUIC et HTTP/3 avec Sophos Firewall

QUIC est un protocole de transport moderne, principalement pertinent aujourd’hui en lien avec HTTP/3. De nombreux navigateurs et services Web utilisent QUIC pour établir des connexions Web plus rapidement et de manière plus stable. Cependant, pour les administrateurs, un autre point est crucial : QUIC fonctionne sur UDP, le plus souvent sur UDP 443, et se comporte donc différemment du HTTPS classique sur TCP.

Sur Sophos Firewall, cela est important car le filtrage Web, l’analyse des malwares, l’inspection TLS et le contrôle des applications ne peuvent être évalués de manière fiable que si le trafic passe par la règle sous la forme attendue. Dans de nombreux environnements, Block QUIC protocol reste donc un paramètre judicieux dans les règles Internet des clients.

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

QUIC déplace ce trafic Web sur UDP. Pour les utilisateurs, c’est souvent plus rapide. Pour le pare-feu, cela signifie :

• Le trafic Web ne ressemble plus au HTTPS classique sur TCP.
• UDP 443 peut contourner les attentes de filtrage Web et d’analyse.
• 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 bloque les paquets UDP sortants vers les ports 80 et 443 pour le trafic qui correspond à la règle de pare-feu concernée. C’est le point décisif : si un client accède à Internet via une autre règle, le paramètre de la règle standard n’a aucun effet sur ce trafic. Les navigateurs reviennent alors normalement au HTTPS sur TCP.

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.

Pour un réseau Wi-Fi invité sans inspection approfondie, QUIC peut être moins critique. Pour les réseaux clients gérés, les serveurs avec accès Internet sortant ou les environnements avec des exigences de conformité, il est préférable de décider consciemment de QUIC et de ne pas simplement laisser le navigateur décider.

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

L’emplacement normal est la règle de pare-feu sortante, par exemple LAN_to_WAN_Clients.

Chemin du menu :

Rules and policies > Firewall rules

Procédure :

1. Ouvrir la règle Internet client concernée.
2. Aller à la section Security features > Web filtering.
3. Activer Log firewall traffic afin que les tests soient visibles dans le Log Viewer.
4. Vérifier la politique Web ou l’analyse des malwares.
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.

Sophos active Block QUIC protocol par défaut lorsqu’une politique Web est sélectionnée dans une règle ou que HTTP et HTTPS déchiffré sont analysés. Néanmoins, il est conseillé de contrôler consciemment le paramètre pour les règles Internet importantes, surtout après des migrations, d’anciens ensembles de règles, des règles copiées ou des règles automatiquement retriées.

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.

Alternative : Contrôle des applications ou règle UDP

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 : contrôle complémentaire via la reconnaissance des applications. Limite : il faut une politique Application Control appropriée et des journaux.
• 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.

Application Control peut rendre QUIC plus visible en complément, mais ce n’est pas un laissez-passer pour du trafic Web non contrôlé. Certaines micro-applications Web sont reconnues plus fiablement lorsque le pare-feu peut analyser le contexte URL du trafic déchiffré. Si l’inspection TLS n’est pas active ou si le trafic n’arrive pas dans le chemin attendu à cause de QUIC, il faut toujours lire les journaux Application Control avec les journaux 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.

Test et validation

Après une modification, il convient de vérifier si le client revient vraiment au HTTPS sur TCP et si la règle de pare-feu attendue est appliquée.

Procédure de test pratique :

1. Réinitialiser le compteur d’utilisation de la règle de pare-feu concernée.
2. Redémarrer complètement le navigateur sur le client de test afin que les connexions existantes et les états HTTP/3 ne faussent pas le test.
3. Ouvrir un site Web qui utilisait auparavant QUIC.
4. Filtrer dans le Log Viewer par IP source, Rule ID, protocole et port de destination.
5. Vérifier si UDP 443 est bloqué ou n’est plus utilisé.
6. Vérifier si HTTPS sur TCP 443 apparaît dans la règle attendue.
7. Si le filtrage Web ou l’inspection TLS est actif, vérifier les modules de journal correspondants.
8. En cas de doute, utiliser Packet Capture sur l’interface client ou pare-feu.

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

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

Questions fréquentes