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 peut inclure des sous-domaines. Dans une correspondance TLS, updates.vendor.example peut donc aussi couvrir api.updates.vendor.example. Si un seul hôte précis est attendu, un hôte volontairement similaire est toujours testé comme cible négative en plus de la cible positive.

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

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.

L’aide actuelle de SFOS 22 n’indique aucun nombre maximal fixe de domaines par URL Group. 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. Activer Log firewall traffic 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.

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. Limiter Source zones, Source networks, Users, Destination zones et Services au périmètre nécessaire.
7. Sous Categories and websites, sélectionner l’URL Group Vendor update domains.
8. Placer la règle directement sous les exclusions par défaut et au-dessus des règles Decrypt générales.
9. Enregistrer et tester avec une nouvelle connexion.

Les SSL/TLS inspection rules fonctionnent indépendamment des règles 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.

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.

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