Créer et utiliser des URL Groups en toute sécurité sur Sophos Firewall

Un URL Group regroupe des domaines précis afin de les utiliser ensemble dans une Web Policy ou une SSL/TLS inspection rule. Cette opération paraît simple, mais elle a une conséquence importante : chaque modification du groupe affecte toutes les règles et politiques qui référencent cet objet.

Le processus sûr ne commence donc pas par la liste de fournisseur la plus étendue possible. Il faut d’abord relever les domaines réellement utilisés à partir d’une requête, d’un journal ou de la documentation du fournisseur. Un petit groupe est ensuite créé avec un objectif, un responsable et un plan de test clairs.

URL Group en sept étapes

1. Documenter le client concerné, les hôtes de destination réels et la décision attendue : autoriser, bloquer ou ne pas déchiffrer.
2. Vérifier qu’un URL Group est réellement adapté. Il traite des domaines, mais pas des chemins d’URL, des chaînes de requête ni des expressions régulières.
3. Sous Web > URL groups > Add, définir un nom parlant et valider chaque nom de domaine correct avec Add.
4. Sélectionner le groupe soit comme Activity dans une Web Policy, soit sous Categories and websites dans une SSL/TLS inspection rule.
5. Contrôler l’ordre des règles, le statut, le périmètre source et la journalisation. Un groupe seul n’autorise ou ne bloque encore rien.
6. Utiliser une nouvelle connexion pour tester une correspondance attendue et une non-correspondance volontairement similaire.
7. Documenter la liste des domaines, les consommateurs, le responsable, le motif, la date du test et le rollback.

⚠️ Plusieurs domaines au sein d’un URL Group sont évalués avec OR. Une seule correspondance suffit. Pour les exclusions TLS, une entrée de domaine inclut également ses sous-domaines. Un domaine racine trop large ou une règle Allow placée très haut peut donc couvrir nettement plus de trafic que prévu.

Ce qu’un URL Group contrôle ou non

Un URL Group est un objet de domaine réutilisable. Il décrit quels domaines doivent être regroupés. La règle qui l’utilise décide ensuite ce qui arrive à la correspondance.

Utilisations courantes :

• une petite allowlist métier dans une Web Policy
• une blocklist explicite pour des domaines connus
• une liste de domaines dans une règle Don't decrypt
• la liste locale d’exclusions TLS pour des problèmes de déchiffrement confirmés

Un URL Group n’est toutefois pas l’outil adapté à tous les cas web :

• Web category : classification étendue du contenu ou catégorie personnalisée avec chemins d’URL ou mots-clés
• Web Exception : correspondance basée sur une regex et contournement ciblé de contrôles web, d’analyse ou de certificat
• FQDN Host : objet réseau basé sur DNS pour des règles de pare-feu, de NAT ou de routage
• Threat Feed : listes d’IOC ou de domaines mises à jour dynamiquement

Configurer Web Protection avec des Web Policies explique toute la logique de politique. Le choix entre une catégorie personnalisée et une liste de domaines est présenté dans Utiliser les web categories et Instant Alerts. Pour les listes de sécurité dynamiques, utiliser les Threat Feeds de Sophos Firewall.

Domaine au lieu d’une URL complète

Sous Search/Add, SFOS attend un nom de domaine valide. Le protocole, le chemin et la requête n’ont pas leur place dans ce champ.

Exemples de valeurs valides :

updates.vendor.example
cdn.vendor.example

Valeurs inadaptées :

https://updates.vendor.example/download/file.bin
*.vendor.example
^updates\.vendor\.example/

L’extension .example est réservée à la documentation. Dans la configuration réelle, les exemples sont remplacés par les domaines confirmés dans le journal, la requête ou la documentation du fournisseur.

Si un chemin d’URL, un paramètre de requête ou une expression régulière précise est nécessaire, une web category personnalisée ou une Web Exception limitée en toute sécurité convient selon l’objectif. La liste de domaines n’est pas élargie par un motif générique apparemment pratique.

Planifier le périmètre des domaines

L’exemple utilise le groupe Vendor update domains avec deux hôtes distincts :

• updates.vendor.example pour le téléchargement des mises à jour
• cdn.vendor.example pour le point de terminaison de contenu associé

Le domaine racine vendor.example n’est volontairement pas utilisé comme raccourci. Sophos précise que les sous-domaines sont inclus lors de la correspondance d’URL Groups dans les exclusions TLS. Une entrée vendor.example inclurait donc également login.vendor.example, telemetry.vendor.example et d’autres sous-domaines dans ce flux.

Même une entrée plus étroite inclut des sous-domaines dans la correspondance des exclusions TLS. api.updates.vendor.example est un sous-domaine de updates.vendor.example et constitue donc une correspondance attendue, pas une cible négative. Dans cet exemple, login.vendor.example convient comme cible négative, à condition que ni vendor.example ni cet hôte ne figurent dans le groupe et qu’aucune autre exception ne le couvre. Remplacer les cibles par des hôtes de test réels et contrôlés. Si l’autorisation d’exclusion porte exclusivement sur un seul hôte, une entrée de domaine ne permet pas de garantir une correspondance exacte limitée à cet hôte ; avant la mise en production, évaluer les sous-domaines inclus et clarifier le périmètre autorisé.

Plusieurs entrées dans le même groupe ne constituent pas une liste obligatoire. En raison de la logique OR, la correspondance d’un seul domaine suffit. Si un service ne fonctionne que lorsque deux hôtes sont accessibles ensemble, chaque hôte doit être testé séparément. L’URL Group ne prouve aucune dépendance fonctionnelle entre eux.

Créer un URL Group

Vérifier d’abord les licences, les utilisations et le mode de fonctionnement

Selon l’aide SFOS 22, une Base License suffit pour appliquer des URL Groups comme critères dans une SSL/TLS inspection rule. Les Web Categories de la même règle nécessitent toutefois une licence Web Protection. Avant d’utiliser le groupe dans une Web Policy, vérifier aussi sous Administration > Licensing que Web Protection est actif.

La page Object usage documente un compteur d’utilisation pour les objets de réseau, de routage, d’hôtes et de services, mais pas pour les URL Groups. Avant de modifier un groupe existant, contrôler donc ses consommateurs possibles directement sous Web > Policies et Rules and policies > SSL/TLS inspection rules. Une seule modification d’un groupe partagé peut en effet changer plusieurs décisions de sécurité.

1. Ouvrir Web > URL groups.
2. Sélectionner Add.
3. Définir un nom tel que Vendor update domains.
4. Saisir updates.vendor.example sous Search/Add.
5. Sélectionner Add et vérifier que la valeur apparaît dans la liste.
6. Ajouter cdn.vendor.example de la même manière.
7. Sélectionner Save.
8. Ouvrir à nouveau le groupe enregistré et vérifier le nom et les deux domaines.

La sélection de Add constitue une étape distincte. Un nom de domaine qui reste uniquement dans le champ de saisie ne fait pas encore partie du groupe.

Ouvrir un groupe existant sous Web > URL groups en sélectionnant Edit pour le groupe concerné. Avant d’enregistrer, documenter la liste actuelle des domaines et toutes les utilisations connues. Sélectionner ensuite Save, ouvrir à nouveau le groupe avec Edit et vérifier, avec de nouvelles connexions, la liste enregistrée ainsi que son effet dans les politiques et règles TLS concernées. En cas d’effet inattendu, rétablir la liste de domaines précédente documentée ; ne pas simplement supprimer un groupe partagé.

Les pages d’aide consacrées aux URL Groups et à leur création pour SFOS 22 et 23 n’indiquent aucun nombre maximal fixe de domaines par groupe. Cela ne constitue pas une promesse de liste illimitée. Si des centaines d’entrées, des changements fréquents du fournisseur ou des IOC continuellement variables sont attendus, un URL Group maintenu manuellement n’est généralement pas le bon modèle d’exploitation.

Utiliser un URL Group dans une Web Policy

Un URL Group n’obtient un effet Allow, Warn, Block ou Quota que par l’intermédiaire d’une règle de Web Policy.

1. Ouvrir Web > Policies.
2. Modifier la politique concernée ou en créer une nouvelle.
3. Sélectionner Add rule.
4. Sous Users, définir le périmètre prévu des utilisateurs ou groupes.
5. Sous Activities, désélectionner le choix général All web traffic et sélectionner l’URL Group Vendor update domains.
6. Définir l’action souhaitée pour HTTP et HTTPS, par exemple Allow ou Block.
7. Vérifier la position de la règle, activer son statut et enregistrer la politique.
8. Sous Rules and policies > Firewall rules, vérifier que cette Web Policy est sélectionnée sous Web filtering dans la règle de pare-feu qui correspond réellement.
9. Dans les Advanced settings de la Web Policy, activer Enable logging and reporting, puis Log firewall traffic dans la règle de pare-feu pour la recette.

Les règles d’une Web Policy sont évaluées de haut en bas. Une règle Allow générale située au-dessus de la nouvelle règle d’URL Group peut masquer la correspondance. À l’inverse, une règle Allow spécifique placée trop haut peut rendre des règles Block ultérieures inopérantes. La position fait donc partie de la décision de sécurité et n’est pas qu’une question d’affichage.

Un URL Group dans une Web Policy ne remplace pas une règle de pare-feu. La règle de pare-feu autorise d’abord le flux de données entre les zones, puis la Web Policy associée évalue l’accès web. Tester les règles avec Log Viewer, Policy Tester et Packet Capture montre quelle règle et quelle politique s’appliquent réellement.

Utiliser un URL Group comme exclusion TLS

Pour des problèmes confirmés de Certificate Pinning ou d’autres problèmes de déchiffrement, le même type d’objet peut être utilisé dans une SSL/TLS inspection rule avec Action: Don’t decrypt. SFOS compare efficacement le domaine sous forme de texte au moyen du Server Name Indication, ou SNI.

Ce flux s’applique au mode DPI et aux connexions SSL/TLS détectées sur TCP ; les SSL/TLS inspection rules ne s’appliquent pas à UDP. Dans une règle personnalisée, seules des zones internes peuvent être sélectionnées sous Source zones. La règle de pare-feu est évaluée en premier, puis la SSL/TLS inspection rule. Une règle de pare-feu ou une Web Policy correspondante ne prouve donc pas une correspondance TLS.

Deux variantes propres sont possibles.

Compléter la Local TLS exclusion list

La Local TLS exclusion list est un URL Group intégré et vide par défaut. Elle appartient à la règle d’exclusion par défaut permanente située en haut de la table des règles SSL/TLS.

Le chemin manuel est le suivant :

Web > URL groups > Local TLS exclusion list

Cette variante convient à une exclusion de domaine confirmée localement qui doit s’appliquer indépendamment d’une règle personnalisée plus étroite par source ou utilisateur. Des domaines peuvent aussi être ajoutés à cette liste via les fonctions de dépannage du Control Center ou du Log Viewer. Chaque nouveau domaine est donc documenté et testé comme une exception de sécurité en production.

La Managed TLS exclusion list répond à un autre besoin. Sophos y maintient des domaines incompatibles connus et peut la mettre à jour au moyen des mises à jour du firmware. Les domaines propres à l’exploitation ne remplacent pas une règle locale délibérée dans cet objet géré par le fournisseur.

Créer une règle Don’t decrypt personnalisée

Si l’exception doit être limitée à certaines sources, certains utilisateurs, services ou zones de destination, une règle personnalisée est plus facile à contrôler :

1. Ouvrir Rules and policies > SSL/TLS inspection rules.
2. Sélectionner Add.
3. Définir un nom tel que Vendor updates no decrypt.
4. Sélectionner Action: Don’t decrypt.
5. Activer Log connections.
6. Sélectionner un Decryption profile adapté. Les restrictions du profil peuvent aussi s’appliquer avec Don’t decrypt ; le profil n’est donc pas sans effet. Tenir compte des limites suivantes pour TLS 1.3.
7. Limiter Source zones, Source networks, Users, Destination zones et Services au périmètre nécessaire.
8. Sous Categories and websites, sélectionner l’URL Group Vendor update domains.
9. Placer la règle directement sous les exclusions par défaut et au-dessus des règles Decrypt générales.
10. Enregistrer et tester avec une nouvelle connexion.

Don’t decrypt n’implique pas les mêmes contrôles de certificat que Decrypt. Pour TLS 1.3, le blocage des erreurs de certificat et l’application de la longueur minimale des clés RSA dans le Decryption Profile nécessitent l’action Decrypt. Downgrade to TLS 1.2 and decrypt ne s’applique également qu’avec cette action. Avec Don’t decrypt ou Deny, Reject and notify est appliqué comme Reject. Avant de créer une exception, vérifier donc la version TLS négociée, les contrôles de certificat nécessaires et le profil. Cette procédure a été vérifiée à partir de la documentation, mais n’a pas été testée sur un pare-feu ; pendant la phase pilote, contrôler dans le journal la règle, l’action et la version TLS réellement utilisées, ainsi que le certificat visible par le client. Si des contrôles requis manquent, ne pas valider l’exception ou rétablir la règle précédente documentée.

Les SSL/TLS inspection rules utilisent leurs propres critères après la règle de pare-feu. Une règle de pare-feu qui correspond correctement ne prouve donc pas que la règle TLS souhaitée s’applique. À l’inverse, Don’t decrypt ne retire que le déchiffrement de ce flux. Il ne s’agit pas d’une autorisation générale pour un trafic réseau quelconque.

La prudence s’impose lorsque des exceptions de source et de destination sont combinées : la description de la règle TLS indique que tous les critères configurés doivent correspondre ; les instructions relatives aux exceptions de sites web précisent toutefois que les exceptions de source et de destination ne peuvent pas être combinées. Le périmètre exact de cette remarque reste incertain. Cet exemple ne constitue donc ni une garantie pour toutes les combinaisons ni des instructions pour les connexions entrantes ; il utilise des zones internes sous Source zones. Avant toute validation en production, tester avec de nouvelles connexions la source autorisée vers l’hôte faisant l’objet de l’exception, cette même source vers un hôte ne faisant pas l’objet de l’exception et une autre source vers l’hôte faisant l’objet de l’exception. Seule la combinaison prévue doit correspondre à la règle Don’t decrypt personnalisée. Si l’effet observé diffère de celui attendu, rétablir la règle précédente documentée et clarifier le périmètre, plutôt que d’élargir l’exception.

Les URL Groups sont plus efficaces pour cette correspondance SNI que de nombreux FQDN Host Objects dans la source ou la destination d’une règle TLS. Les FQDN Host Objects effectuent une résolution DNS et répondent à un autre besoin. Créer et utiliser des FQDN Hosts en toute sécurité explique les différences.

Si la connexion TLS ne contient pas de SNI exploitable, le domaine ne peut pas être reconnu de cette manière. Le groupe n’est alors pas élargi avec un domaine racine. Il faut d’abord vérifier l’IP de destination, le certificat, Packet Capture et le flux réel de l’application.

Vérifier la correspondance avec des tests positifs et négatifs

Le chargement réussi d’une page prouve uniquement que le service est accessible. Il ne prouve ni que la bonne règle de Web Policy s’applique, ni que l’exclusion TLS souhaitée fonctionne.

Test de Web Policy

1. Noter le client pilote, l’utilisateur, l’heure et l’action attendue.
2. Fermer complètement la session du navigateur ou de l’application et la redémarrer.
3. Ouvrir updates.vendor.example ou le domaine positif réel.
4. Dans Log Viewer, vérifier Source, User, Domain, Firewall Rule ID, Web Policy et Action.
5. Tester login.vendor.example ou un hôte réel volontairement non ajouté.
6. Confirmer que l’hôte négatif est toujours évalué par la règle de politique normale suivante.
7. Si deux valeurs du groupe sont nécessaires, tester chaque hôte séparément.

Si le navigateur utilise QUIC ou HTTP/3, le chemin web TCP attendu peut être différent. Il faut d’abord distinguer le test de QUIC et HTTP/3.

Test de l’exclusion TLS

1. Établir une nouvelle connexion TLS vers l’hôte positif.
2. Dans le journal SSL/TLS, vérifier la règle correspondante et le statut de non-déchiffrement.
3. Comparer le certificat visible par le client avec l’état de la règle de déchiffrement normale.
4. Ouvrir un hôte négatif similaire qui n’appartient pas au groupe.
5. Confirmer que cet hôte est toujours traité par la règle Decrypt attendue.
6. Documenter le périmètre source, le SNI et la position de la règle.

Pour un test volontaire du rollback, rétablir l’état antérieur documenté de la règle web ou TLS consommatrice pendant une fenêtre de maintenance. L’hôte positif doit alors retrouver son comportement précédent. Seul ce contre-test transforme un workaround fonctionnel en recette reproductible.

Délimiter systématiquement les erreurs

L’URL Group ne s’applique pas dans la Web Policy

• Le domaine a été saisi, mais n’a pas été validé avec Add.
• L’URL Group n’est pas sélectionné sous Activities dans la règle de politique active.
• All web traffic ou une autre règle antérieure correspond en premier.
• La règle de politique est désactivée.
• La Web Policy n’est pas sélectionnée dans la règle de pare-feu qui correspond réellement.
• La requête réelle utilise un hôte de redirection, de connexion, d’API ou de CDN non documenté.
• Une connexion existante du navigateur ou de QUIC n’a pas été rétablie.

Utiliser Diagnostics > Tools > Policy tester pour vérifier d’abord l’action de Web Policy attendue pour l’URL, l’utilisateur et l’heure. Ce test ne remplace pas un vrai client et les journaux, mais distingue une erreur de politique d’une règle de pare-feu mal associée. Si le flux reste incertain, Diagnostics > Packet capture affiche notamment Firewall Rule ID et Web Filter ID. Activer la capture uniquement pour le client pilote et l’hôte cible concernés, puis la désactiver.

L’exclusion TLS ne s’applique pas

• L’URL Group n’est pas sélectionné sous Categories and websites dans la règle attendue.
• La règle Don't decrypt se trouve sous une règle Decrypt qui correspond déjà.
• Source, User, Zone, Service ou un autre critère de la règle ne correspond pas.
• La connexion n’envoie pas de SNI exploitable.
• L’hôte TLS réel diffère de l’URL visible dans le navigateur.
• La session TLS existante a continué d’être utilisée après la modification.

L’URL Group s’applique trop largement

• Un domaine racine a été ajouté à la place des hôtes réellement nécessaires.
• Une entrée inclut des sous-domaines supplémentaires dans la correspondance TLS.
• Le groupe est utilisé par plusieurs politiques ou règles TLS.
• Une règle Allow est placée trop haut ou s’applique à trop d’utilisateurs.
• La Local TLS exclusion list a un effet plus large qu’une règle personnalisée limitée par source.

Il ne faut alors pas ajouter un autre domaine. Il faut d’abord vérifier toutes les utilisations du groupe, l’ordre réel des règles et le test négatif.

Exploiter les modifications et le rollback en toute sécurité

Avant chaque modification d’un URL Group en production, noter :

• la liste de domaines précédente
• les Web Policies et SSL/TLS inspection rules qui la référencent
• le responsable et la justification métier
• les utilisateurs, sources et services concernés
• les cas de test positifs et négatifs
• la date de révision ou d’expiration

Un groupe partagé n’est pas élargi silencieusement pour un incident isolé. Si une web allowlist et une exclusion TLS ont des responsables ou des cycles de vie différents, des URL Groups distincts sont plus clairs, même si certains domaines sont identiques.

Pour le rollback, rétablir d’abord l’état de la règle ou de la politique consommatrice, ou supprimer uniquement le domaine nouvellement ajouté. Le groupe complet n’est supprimé que lorsqu’aucune autre politique ou règle n’en dépend. Les nouvelles connexions aux hôtes positif et négatif ainsi que les journaux sont ensuite à nouveau vérifiés.

Liste de contrôle opérationnelle

• URL Group confirmé comme outil adapté.
• Uniquement des domaines valides ajoutés, sans protocoles, chemins, caractères génériques ni regex.
• Effet du domaine racine et des sous-domaines volontairement limité.
• Logique OR entre plusieurs domaines prise en compte.
• Nom du groupe, responsable, objectif et date de révision documentés.
• Web Policy ou SSL/TLS inspection rule consommatrice clairement identifiée.
• Statut, position, périmètre source et journalisation de la règle vérifiés.
• Web Policy sélectionnée dans la bonne règle de pare-feu.
• Pour une exclusion TLS, SNI et règle Don't decrypt confirmés.
• Licences, mode DPI/TCP et Decryption profile vérifiés.
• Tests positifs et négatifs effectués avec de nouvelles connexions.
• Références et état antérieur enregistrés pour le rollback.

Questions fréquentes