Créer et tester des Web Exceptions Sophos Firewall en toute sécurité

Une Web Exception se crée rapidement, mais son effet peut être bien plus large que prévu. Selon l’option choisie, Sophos Firewall contourne non seulement le déchiffrement HTTPS, mais aussi la validation des certificats, l’analyse des logiciels malveillants et du contenu, l’analyse Zero-Day ou l’ensemble des contrôles de la Web Policy.

La séquence sûre consiste donc à identifier d’abord le flux affecté et le contrôle réellement perturbateur, puis à limiter la correspondance et seulement ensuite à activer l’exception minimale requise. Un test positif ne suffit pas. Lors du test négatif, une destination similaire non exclue doit continuer à être contrôlée normalement.

Ce guide s’applique à SFOS 22.0. Les libellés WebAdmin restent volontairement en anglais afin d’être directement repérables dans l’interface.

Web Exception en sept étapes

1. Documenter le client affecté, l’hôte de destination, le chemin URL, le protocole et l’heure.
2. Vérifier si DPI Mode ou Web Proxy Mode est utilisé et quelle règle de pare-feu ainsi que quelle Web Policy s’appliquent réellement.
3. Déterminer si seul le déchiffrement TLS ou un contrôle précis de Web Protection provoque le problème.
4. Sous Web > Exceptions > Add an exception, définir des critères URL, catégorie, source ou destination étroitement limités.
5. Sous Skip the selected checks or actions, ne sélectionner que l’option minimale nécessaire.
6. Activer l’exception et retester le même flux avec un nouveau processus de navigateur ou d’application.
7. Effectuer un test négatif vers une destination similaire non exclue, puis documenter la correspondance, l’effet, le responsable et la date de révision.

⚠️ HTTPS decryption n’est pas une option de compatibilité anodine. Pour le trafic correspondant, les contrôles qui dépendent du déchiffrement disparaissent également et le pare-feu autorise alors les certificats serveur non valides. Malware and content scanning contourne automatiquement aussi l’analyse Zero-Day. Une exception large ne doit donc pas être la première étape du dépannage.

Vérifier les prérequis du produit avant de choisir une exception

Pour certains produits administrés, les autorisations de ports et de domaines sont indispensables à la fonction concernée. Avant de choisir une règle de pare-feu, une TLS Exclusion ou une Web Exception, préciser avec le responsable du produit la fonction, la version et le chemin de connexion réel. Consigner les destinations, ports, protocoles, directions et exclusions d’inspection explicitement requis dans le ticket de changement, plutôt que d’autoriser globalement tous les produits Sophos.

• Wireless : Le contrôle préalable Wireless distingue le réseau d’administration, DNS, le service de temps et les destinations régionales de la configuration Wi-Fi ultérieure.
• ZTNA : Identifier d’abord le déploiement local ou cloud dans le guide de la passerelle ZTNA ; leurs directions de connexion et exigences d’inspection ne sont pas interchangeables.
• Enregistrement des switches : Le guide d’enregistrement des switches couvre DNS, les destinations d’enregistrement et la vérification du chemin proxy/TLS.
• Endpoint, XDR et MDR : Les exigences réseau et proxy distinguent les plateformes, fonctions sous licence et destinations propres à l’installation. Une liste de domaines autorisés n’est pas une liste globale d’exclusions de déchiffrement.
• NDR et appliances d’intégration : La planification de l’appliance couvre les ports et domaines sortants ; le guide d’exploitation aide à vérifier séparément les fonctions NDR et Log Collector réellement hébergées.

Le guide interne est un point de départ ; le responsable du produit doit confirmer les exigences faisant autorité pour ce déploiement avant le changement. L’accessibilité réseau et le contournement de l’inspection restent deux décisions distinctes. Si les exigences ne sont pas vérifiées ou si les sources se contredisent, ne pas élargir l’exception au hasard : conserver les preuves et clarifier avec les responsables du produit et du pare-feu. Le pilote, les tests positifs et négatifs, la révision et le retour arrière de ce guide restent ensuite applicables.

Choisir une Web Exception ou une TLS Exclusion

Les deux outils peuvent empêcher le déchiffrement du trafic HTTPS, mais ils ne répondent pas au même besoin.

Une SSL/TLS inspection rule avec Action: Don’t decrypt convient lorsque seul le déchiffrement doit être exclu pour des destinations clairement définies en DPI Mode. Un URL Group dans la Local TLS exclusion list est particulièrement efficace, car le pare-feu compare le Server Name Indication, ou SNI, sous forme de texte.

Créer et utiliser des URL Groups en toute sécurité montre comment créer une telle liste de domaines, l’intégrer dans une règle Don't decrypt et la tester avec une destination négative.

Une Web Exception convient lorsqu’un contrôle de Web Protection doit être contourné en plus ou à la place du déchiffrement :

• HTTPS decryption
• HTTPS certificate validation
• Malware and content scanning
• Zero-day protection
• Policy checks

En DPI Mode, une Web Exception ne s’applique que si au moins une Web Policy, Malware and content scanning ou ATP est actif pour le flux. En Web Proxy Mode, la Web Exception appartient directement au chemin Web Protection basé sur le proxy.

La SSL/TLS exclusion list utilise des noms de domaine en clair et inclut leurs sous-domaines, plutôt que des expressions régulières. Les exclusions SSL/TLS peuvent contourner les exigences relatives aux certificats et aux protocoles, en plus du déchiffrement. Elles ne sont donc pas équivalentes à une Web Exception limitée à HTTPS certificate validation. Les domaines confirmés peuvent être ajoutés à la Local TLS exclusion list depuis Control Center ou Log Viewer ; on peut aussi modifier le URL Group sous Web > URL groups ou la SSL/TLS inspection rule. Les catégories web peuvent également servir de critères dans une SSL/TLS inspection rule.

Le trafic couvert diffère également : en DPI Mode, les Web Exceptions s’appliquent aux connexions SSL/TLS sur tous les ports ; en Web Proxy Mode, elles s’appliquent au SSL/TLS sur le port 443. Les SSL/TLS Exclusion Rules ne s’appliquent qu’en DPI Mode, mais indépendamment du port. Outre les URL Groups, elles peuvent utiliser comme critères les zones, réseaux, adresses IP, services, utilisateurs et groupes. Les Web Exceptions proposent les modèles d’URL, les Web categories et les adresses IP ou plages source et destination.

Une Web Exception active peut remplacer les contrôles de protection sélectionnés pour les flux web correspondants ; cela ne garantit pas que tout blocage système puisse être levé. Son périmètre ne peut donc pas être sécurisé en plaçant une règle de Web Policy plus loin dans l’ordre. Les critères de l’exception sont déterminants ; l’ordre des règles de pare-feu, Web et SSL/TLS doit néanmoins être vérifié séparément, car il détermine le chemin de protection qui traite initialement le flux.

Limite documentée et contradiction non résolue : Sophos présente généralement les exceptions comme indépendantes des policies et règles. Toutefois, le guide des catégories de SFOS 22.0 et 23.0 indique explicitement que highly objectionable criminal activity est toujours bloquée : aucune policy ou exception ne peut autoriser ces pages, et les domaines sont volontairement masqués dans les logs et rapports. Ces affirmations divergentes ne prouvent pas qu’un contournement fonctionne. La démarche sûre consiste à ne pas contourner ce blocage et, si nécessaire, à clarifier la contradiction avec Sophos Support. Les tests utilisent uniquement des destinations inoffensives et approuvées, jamais de contenus interdits.

Le déploiement planifié de DPI ou Web Proxy, des Decryption Rules et de la CA est expliqué dans Déployer correctement TLS Inspection. La logique de filtrage proprement dite figure dans Configurer Web Protection avec des Web Policies.

Planifier une correspondance étroite et traçable

Une exception ne doit pas commencer par un domaine de fournisseur choisi au hasard. Il faut d’abord relever la requête concrète dans le navigateur, Log Viewer ou les journaux de l’application. On peut ensuite déterminer si le hostname, le chemin, la catégorie, l’adresse IP source ou l’adresse IP de destination constitue le critère le plus stable.

AND entre les types, OR au sein d’un type

Sophos Firewall relie les différents types de critères avec AND. Si des modèles d’URL et des Source IP addresses sont définis, par exemple, les deux types doivent correspondre.

Plusieurs valeurs d’un même type sont évaluées avec OR. Avec deux modèles d’URL, l’un des deux peut donc suffire. Avec deux Source IP addresses, l’une des deux sources peut suffire.

Cette logique est importante pour le dépannage. Une exception peut sembler correcte sans s’appliquer, car un type de critère supplémentaire ne correspond pas au flux réel.

Ancrer l’expression régulière en toute sécurité

Les expressions régulières sont autorisées sous URL pattern matches. Un modèle brut comme vendor.example ne convient pas. Le texte peut aussi correspondre à un emplacement inattendu de l’URL et exclure trop de requêtes.

Pour le domaine d’exemple réservé updates.vendor.example, un modèle d’hôte volontairement ancré peut prendre la forme suivante :

^([A-Za-z0-9.-]*\.)?updates\.vendor\.example/

Cette valeur n’est qu’un exemple. vendor.example est un domaine réservé à la documentation et doit être remplacé par l’hôte de destination réel confirmé dans le journal ou la requête. Le préfixe facultatif autorise les sous-domaines. Si un seul hôte précis doit être exclu, aucun wildcard de sous-domaine inutile n’est ajouté.

Les caractères non ASCII sont indiqués sous forme de Punycode dans le modèle. Après chaque modification de la regex, le test doit comprendre une correspondance attendue et au moins une non-correspondance volontairement similaire.

Vérifier les points, la limite de l’hôte et les correspondances indésirables dans le chemin

Dans une regex, un point non échappé représente n’importe quel caractère. Les points d’un nom d’hôte fixe s’écrivent donc \.. Le ^ ancre la correspondance au début ; le / final délimite l’hôte par rapport aux noms commençant de façon similaire, comme updates.vendor.example.attacker.example. Sophos Firewall accepte / et \/. Pour un seul hôte précis, le modèle plus restreint est :

^updates\.vendor\.example/

Les exemples utilisent la représentation hôte/URL à laquelle ces modèles Sophos s’appliquent, sans https:// au début. L’outil de test doit utiliser la même représentation. Si les ports ou la représentation diffèrent, ne pas ajouter .* au hasard : identifier la valeur réellement évaluée et le chemin de protection. La limite HTTPS décrite dans la section suivante reste valable.

Les résultats suivants sont attendus pour le modèle d’hôte exact. Avec le modèle existant à sous-domaine facultatif, cdn.updates.vendor.example/file constitue également une correspondance voulue ; les autres cas négatifs restent sans correspondance.

Les deux derniers cas sont particulièrement importants : la comparaison peut porter sur toute l’URL, chemin et paramètres de requête compris. Un texte de domaine non ancré peut donc déclencher l’exception sur un autre hôte. Ce test vérifie uniquement la correspondance ; la suppression effective des contrôles de protection sera vérifiée ensuite avec une nouvelle requête et des journaux.

Tester localement de longues chaînes sans correspondance

De nombreux modèles non ancrés peuvent nécessiter davantage de recherche, notamment lorsque le déchiffrement HTTPS rend disponible le texte complet de l’URL. Cela ne permet pas de déduire, pour tous les modèles, un nombre universel d’étapes ni un temps d’exécution toujours constant, linéaire ou exponentiel. L’ancrage ne remplace pas non plus l’examen des quantificateurs complexes. Ne pas utiliser un wildcard général .* pour les noms d’hôte.

Un test de 1000 caractères complète les cas courts. Sur un poste local d’administration doté de Python 3, cet exemple génère un texte d’URL entièrement fictif avec un long chemin et le domaine cible uniquement dans les paramètres de requête. Il teste les deux modèles présentés ici sans contacter de pare-feu :

import re
from time import perf_counter

prefix = "other.example/"
suffix = "?next=updates.vendor.example/file"
value = prefix + "a" * (1000 - len(prefix) - len(suffix)) + suffix
assert len(value) == 1000
patterns = [
    r"^updates\.vendor\.example/",
    r"^([A-Za-z0-9.-]*\.)?updates\.vendor\.example/",
]
for pattern in patterns:
    regex = re.compile(pattern)
    start = perf_counter()
    for _ in range(100):
        assert regex.search(value) is None
    print(pattern, "Nicht-Treffer, Sekunden:", perf_counter() - start)

Deux résultats sans correspondance sont attendus. D’autres cas synthétiques doivent couvrir de longs noms d’hôte presque correspondants et de longs chemins ; comparer les modèles avant et après avec les mêmes entrées. Pour les modèles complexes suspects, utiliser un outil local avec une limite de temps et interrompre tout test bloqué. Les durées Python et les compteurs d’étapes d’autres moteurs regex ne sont ni des mesures SFOS ni une promesse de performances. Ne pas copier d’URL de production, de tokens, de noms d’utilisateur ou de données clients dans des sites externes de test regex ; des données fictives suffisent.

Distinguer le hostname et le chemin URL

Les exceptions pour HTTPS decryption et HTTPS certificate validation peuvent évaluer le hostname à partir du contexte TLS. En revanche, un modèle qui vise uniquement un chemin URL ne fonctionne pour HTTPS que si la connexion est déjà déchiffrée. Avec HTTP non chiffré, le chemin URL est visible sans déchiffrement TLS.

Il en résulte une limite importante : une exception ne peut pas désactiver le déchiffrement puis utiliser de manière fiable comme critère une partie uniquement visible dans le chemin HTTP chiffré. Ce cas nécessite un périmètre basé sur l’hôte ou une autre conception.

Créer la Web Exception

L’exemple exclut du déchiffrement HTTPS un seul client pilote pour un hôte de fournisseur confirmé. Il ne s’agit pas d’une règle d’exception universelle.

1. Ouvrir Web > Exceptions.
2. Sélectionner Add an exception.
3. Définir un nom explicite, par exemple Vendor API no decrypt.
4. Activer URL pattern matches.
5. Saisir le modèle testé et ancré sous Search/Add, puis le valider avec Add.
6. Pour le pilote, activer également Source IP addresses, saisir l’adresse IP précise du client et la valider avec Add.
7. Sous Skip the selected checks or actions, sélectionner uniquement HTTPS decryption.
8. Sélectionner Save.
9. Dans la liste, activer le commutateur de la nouvelle exception.
10. Vérifier à nouveau le nom, les Matching URLs, les sources et le contrôle contourné.

L’adresse IP source est volontairement définie dans l’exemple. Sans elle, l’exception s’appliquerait immédiatement à tous les clients dont la requête correspond au modèle d’URL. Après un pilote réussi, le périmètre peut être étendu de manière contrôlée aux sources qui en ont réellement besoin.

Pour une exclusion TLS pure portant sur de nombreuses destinations, un URL Group dans une règle Don't decrypt est généralement plus facile à maintenir et plus efficace. De nombreux FQDN Host Objects dans la source ou la destination d’une SSL/TLS inspection rule sont défavorables, car ils peuvent entraîner de nombreuses recherches DNS pour les nouvelles connexions TLS.

Préparer une nouvelle exception d’hôte dans Config Studio

Config Studio peut créer une nouvelle Web Exception à partir d’un nom de domaine sans importer d’abord une exception existante. Il s’agit d’un processus distinct ; Bad regex et Apply Fix servent en revanche à réparer les entrées existantes, comme décrit plus bas. La nouvelle exception est d’abord préparée localement et n’est appliquée au firewall qu’au moyen de l’importation TAR.

Avant de commencer, conserver dans un emplacement protégé une sauvegarde complète du firewall et un export sélectif non modifié de WebFilterException provenant du même firewall. La section Exporter WebFilterException et le vérifier avec Config Studio décrit l’export de Entities.xml, la gestion des fichiers et le téléchargement ultérieur. Consigner dans le ticket de changement un nom encore inutilisé, l’hôte de destination confirmé, l’option de contournement nécessaire et le périmètre de clients prévu. Un nom existant n’est pas un moyen sûr d’ajouter une entrée : l’importation met à jour les exceptions existantes correspondantes. Un nom modifié crée au contraire une nouvelle entrée sans supprimer l’ancienne.

1. Ouvrir Config Studio via le lien d’accès ci-dessous, sélectionner Configuration editor, puis aller dans Rules > Web exceptions.
2. Sélectionner Add et saisir le nouveau nom unique, par exemple Vendor API exact host no decrypt.
3. Dans Skip these checks, activer uniquement l’option nécessaire au cas traité. Pour l’exemple de déchiffrement, il s’agit de Skip HTTPS decryption. Les autres options sont Skip policy check, Skip cert validation, Skip malware scan et Skip zero-day protection. Les conséquences sur la protection décrites plus haut s’appliquent aussi à la création dans l’éditeur ; ne pas sélectionner plusieurs options par précaution.
4. Dans Match by URL/Domain, choisir le périmètre : Exact host only pour le seul hôte confirmé, ou Domain + all subdomains si tous ses sous-domaines sont explicitement nécessaires et approuvés. Pour updates.vendor.example, l’exemple conserve Exact host only ; cdn.updates.vendor.example ne doit pas être inclus.
5. Saisir le nom de domaine confirmé dans le champ de texte, sans chemin URL, par exemple updates.vendor.example. Remplacer cette valeur de documentation par l’hôte de destination réel. La regex générée et l’aperçu apparaissent automatiquement ; vérifier les deux par rapport au périmètre prévu et aux cas positifs et négatifs décrits plus haut.
6. Sélectionner Add to URL Regex list. Le motif doit ensuite figurer dans URL Regex Patterns. Une valeur visible dans l’aperçu n’est pas encore une entrée ajoutée à la liste.
7. Facultativement, dans URL Regex Patterns, utiliser + Add URL regex pour ajouter directement un motif personnel déjà vérifié. Ce n’est pas nécessaire pour la création à partir d’un domaine ; les motifs supplémentaires élargissent les correspondances possibles en raison de OR.
8. Enfin, sélectionner Add en bas du formulaire latéral. C’est seulement à ce stade que la nouvelle exception est créée dans l’éditeur.

Avant le téléchargement, comparer dans Preview le XML d’importation avec l’état initial sauvegardé et le ticket de changement. Seule la nouvelle exception approuvée doit être ajoutée ; aucun nom, critère, état d’activation ni option de contournement existant ne doit être modifié involontairement. Le périmètre de clients doit aussi être correct : Exact host only limite la destination, pas les sources. Si la présence d’une source pilote requise dans la configuration générée ne peut pas être démontrée, ne pas importer ; utiliser plutôt le processus WebAdmin décrit plus haut avec Source IP addresses. Ne pas ajouter de champs supplémentaires non vérifiés au XML.

Sélectionner ensuite Download > Download TAR et conserver l’archive dans un emplacement protégé. La section Importer, vérifier l’effet et revenir en arrière couvre les messages d’importation, la comparaison avant/après dans Web > Exceptions, le contrôle d’activation et les nouvelles connexions avec tests positifs et négatifs. L’aperçu XML ou une importation réussie ne remplace pas ce test de l’effet sur la protection. En cas de résultat inattendu, désactiver la nouvelle entrée de manière contrôlée et vérifier à nouveau le chemin de protection normal. Réimporter l’export sélectif initial ne supprime pas automatiquement l’exception nouvellement créée ; la supprimer de façon ciblée seulement après avoir clarifié les dépendances. Ne pas toucher aux exceptions existantes.

Exclure une catégorie plutôt qu’un seul domaine

Si des données financières confidentielles ne doivent pas être déchiffrées, la catégorie Financial services peut constituer le bon critère. Une exception de catégorie couvre toutefois plus de destinations qu’un seul hôte ; la classification doit correspondre au périmètre prévu.

1. Sous Web > Exceptions > Add an exception, saisir un nom tel que Financial services no decrypt.
2. Activer Web site categories, sélectionner Add new item, puis Financial services.
3. Valider avec Apply selected items. Pour le pilote, définir également Source IP addresses avec l’adresse IP du client et Add.
4. Sélectionner uniquement HTTPS decryption, choisir Save, puis activer le commutateur dans la liste.
5. Tester un service financier approuvé et une destination inoffensive hors de cette catégorie avec de nouvelles connexions. La source pilote et la catégorie doivent toutes deux correspondre en raison de AND.

Les connexions HTTPS correspondantes ne sont plus déchiffrées et perdent les contrôles de contenu qui en dépendent ; la conséquence sur les certificats décrite plus haut s’applique également. Il ne s’agit ni d’une autorisation générale de la catégorie ni d’une affirmation selon laquelle toutes les autres fonctions de protection sont désactivées.

Exception antimalware pour un hôte de téléchargement confirmé

Un fournisseur jugé peu risqué ne suffit pas, à lui seul, à justifier la désactivation de l’analyse. Si une exception dûment justifiée est nécessaire, reprendre la procédure ci-dessus avec un nom distinct tel que Vendor download scan exception, le modèle de l’hôte confirmé et la source pilote. Sélectionner Malware and content scanning à la place de HTTPS decryption. Zero-day protection est sélectionné automatiquement ; les anciennes exceptions qui contournent l’analyse antimalware contournent aussi l’analyse Zero-Day. Choisir ensuite Save et activer le commutateur. Les téléchargements correspondants ne font plus l’objet d’une analyse antimalware ou de contenu, ni d’une analyse Zero-Day avec ses rapports. Ne pas désélectionner en plus les autres contrôles. Vérifier le chemin de protection prévu avec un téléchargement inoffensif et contrôlé depuis l’hôte approuvé et une destination de comparaison non exclue ; un téléchargement réussi ne suffit pas.

Saisir d’autres critères et gérer les exceptions existantes

Renseigner Destination IP addresses avec l’adresse IP confirmée du site web et cliquer sur Add, et non avec celle du client. Pour les combinaisons autorisées du critère de destination avec l’URL ou la catégorie, tous les types sélectionnés doivent correspondre. Les modèles d’URL utilisent des caractères ASCII ; les noms de domaine internationalisés sont écrits en Punycode. Matching URLs dans l’exception par défaut Apple Update peut servir d’exemple de syntaxe, pas de modèle d’autorisation non vérifié.

Exclusion TLS : indications contradictoires sur le périmètre. Les pages Add an exception de SFOS 22.0 et 23.0 décrivent la logique générale AND entre types de critères, mais Exclude a website from TLS inspection indique explicitement que les exceptions de source et de destination ne peuvent pas être combinées. Le périmètre exact de cette restriction reste incertain ; la logique générale de correspondance ne prouve pas que cette combinaison soit autorisée. Combiner Source IP addresses et Destination IP addresses n’est donc pas une procédure dont l’autorisation est vérifiée. Avant d’activer une exclusion TLS, confirmer le build réel de SFOS, le chemin DPI/proxy, le contrôle à contourner et le périmètre restreint d’hôte/catégorie. Conserver l’approche ci-dessus associant la source pilote au nom d’hôte ou à la catégorie confirmés, sans ajouter de critère d’IP de destination. Destination plus nom d’hôte/catégorie confirmés n’est une option distincte que si le périmètre des clients est limité indépendamment et approuvé. Ne pas remplacer la restriction prévue par une exception portant uniquement sur la source, ni supprimer un critère simplement pour obtenir une correspondance : cela élargit le contournement des protections. Si des restrictions d’IP de source et de destination sont toutes deux nécessaires, s’arrêter sans activer ni élargir l’exclusion et obtenir une clarification de Sophos Support pour le build concerné avec le responsable du pare-feu.

Les exceptions par défaut prennent en charge les mises à jour logicielles et d’autres fonctions importantes des sites web. Sous Web > Exceptions, Edit ouvre une exception existante et Clone en crée une copie. Vérifier tous les critères et options hérités avant de l’activer. Web > General settings régit la validation générale des certificats HTTPS ; une exception de certificat individuelle ne remplace pas ce réglage de base.

Comprendre l’effet des options de contournement

Avant l’enregistrement, la protection perdue doit être clairement identifiée.

HTTPS decryption

Le pare-feu ne déchiffre pas le trafic HTTPS correspondant. Il ne peut donc pas non plus effectuer les contrôles qui nécessitent le contenu déchiffré. Sophos indique également que le trafic présentant un certificat serveur non valide est autorisé pour cette correspondance.

Si seule une particularité du certificat pose problème, cette option est souvent trop large. Il faut d’abord vérifier si HTTPS certificate validation constitue l’exception la plus précise.

HTTPS certificate validation

Le pare-feu ignore le contrôle de validité du certificat serveur. Le déchiffrement configuré peut continuer. Cette exception ne convient qu’à une destination connue présentant un problème de certificat consciemment accepté et nécessite une date de révision proche.

Un certificat expiré, mal nommé ou non approuvé doit si possible être réparé sur le système de destination. Le déploiement de la bonne Inspection CA résout un autre problème et est décrit dans Déployer le certificat CA pour TLS Inspection.

Malware and content scanning

Le pare-feu contourne l’analyse des logiciels malveillants et du contenu pour la correspondance. Zero-day protection est alors automatiquement contourné aussi. Une seule sélection retire donc deux couches de protection du chemin des données.

Avant cette exception, il faut vérifier le type de fichier, la limite d’analyse, le chiffrement, l’action en cas d’échec et le téléchargement qui correspond réellement. Le processus complet se trouve dans Configurer et tester l’analyse antimalware.

Zero-day protection

L’analyse Zero-Day est contournée. Aucun rapport d’analyse n’est créé pour les fichiers correspondants, même si l’analyse antimalware classique signale une détection. Cette option est plus étroite que le contournement complet de Malware and content scanning.

Policy checks

Les contrôles de la Web Policy sont contournés pour la requête correspondante. Une telle exception peut rendre inopérantes les catégories, la logique des utilisateurs ou groupes et d’autres décisions de policy. Elle ne doit être utilisée que pour un problème de policy clairement démontré, et non comme solution générale à un site web bloqué.

Cela n’autorise pas à utiliser Policy checks pour lever le blocage absolu documenté de highly objectionable criminal activity décrit ci-dessus.

Vérifier l’effet avec des tests positifs et négatifs

Le chargement réussi d’une page prouve uniquement qu’un changement s’est produit. Il ne prouve pas encore que l’exception est précise.

1. Noter l’heure, le client pilote, l’hôte de destination et le résultat attendu.
2. Fermer la session existante du navigateur ou de l’application et établir une nouvelle connexion.
3. Répéter la requête affectée.
4. Dans Log Viewer, comparer l’adresse IP source, l’hôte de destination, la Web Policy, le Firewall Rule ID et l’action.
5. Pour une exception de déchiffrement, comparer le certificat serveur visible par le client avec son état avant la modification.
6. Ouvrir une destination similaire qui n’a pas été exclue.
7. Vérifier que cette destination reste couverte par la Web Policy, la Decryption Rule et la chaîne d’analyse normales.
8. Désactiver brièvement l’exception et reproduire l’erreur initiale si cela peut être fait sans risque pendant la fenêtre de maintenance.
9. Réactiver l’exception et confirmer à nouveau le résultat.

Si QUIC ou HTTP/3 contourne le chemin TLS sur TCP attendu, le test peut être trompeur. La distinction est expliquée dans Bloquer correctement QUIC et HTTP/3. Log Viewer, Policy Tester et Packet Capture indiquent quelle règle et quelle policy correspondent réellement.

Le Policy tester s’ouvre sous Diagnostics > Tools, dans la section Pop-out tools. Sa méthode Firewall, SSL/TLS, and web aide à identifier la règle de pare-feu, la SSL/TLS inspection rule et la Web Policy attendues. Il ne teste toutefois le trafic web qu’en Transparent Mode et ne reproduit donc pas un flux direct web proxy explicite. L’application effective de la Web Exception doit toujours être confirmée par une nouvelle requête et des journaux réels.

Pour disposer d’une preuve dans les journaux, Log firewall traffic doit être actif dans la règle de pare-feu ; il faut également activer Log connections dans la SSL/TLS inspection rule. Sous System services > Log settings, les types de journaux concernés doivent être activés pour Local reporting. Dans Log Viewer, limiter ensuite l’affichage à l’heure du test et à l’adresse IP source, puis comparer les modules Web filter et SSL/TLS inspection avec le Firewall Rule ID, la policy et l’Action. Utiliser correctement Sophos Firewall Log Viewer explique les commandes. Si toute la vue reste vide, suivre Log Viewer ne se met pas à jour au lieu d’élargir l’exception sur une simple supposition.

Circonscrire les erreurs méthodiquement

L’exception ne s’applique pas

• Le blocage absolu documenté d’une catégorie n’est pas une erreur de correspondance. Un domaine volontairement masqué n’est pas ici un défaut de journalisation. Les catégories web et Web Policies expliquent cette limite ; ne pas tenter une exception plus large ni des tests sur ces contenus.
• Le commutateur sous Web > Exceptions n’est pas activé.
• Un type de critère supplémentaire ne correspond pas en raison de la logique AND.
• La regex n’est pas ancrée au début ou ne représente pas le hostname réel.
• Pour une exception de chemin HTTPS, le trafic n’est pas déchiffré et le chemin n’est donc pas visible.
• En DPI Mode, aucune Web Policy, Malware and content scanning ni ATP n’est actif pour le flux.
• Une autre règle de pare-feu, Web Policy ou mode de fonctionnement s’applique contrairement aux attentes.
• La session existante du navigateur ou de l’application n’a pas été recréée.

L’exception s’applique trop largement

• Le modèle contient un wildcard non maîtrisé ou uniquement le texte brut d’un root domain.
• Les Source IP addresses ou un autre périmètre pilote sont absents.
• Plusieurs modèles d’URL du même type ont un effet plus large que prévu en raison de OR.
• Une Web category entière a été exclue au lieu de l’hôte précis.
• Plusieurs options de contournement ont été activées alors qu’un seul contrôle pose problème.

Le site fonctionne, mais l’effet sur la protection reste incertain

L’exception ne doit alors pas être étendue. Il faut d’abord comparer le certificat du navigateur, les journaux Web et SSL/TLS Inspection, le Firewall Rule ID, la Web Policy et un téléchargement contrôlé. Sans ces preuves, l’exception n’est qu’un contournement fonctionnel, pas encore une décision de sécurité acceptée.

Si les outils WebAdmin ne permettent pas d’isoler la cause, Associer correctement les journaux de service Sophos Firewall relie les journaux DPI, proxy, malware et Zero-Day au chemin de protection concerné. Le débogage n’est pas activé en première étape.

CPU élevée et accès web lents après des changements de regex

Sous Diagnostics > System graphs, comparer d’abord les horaires et l’évolution de la charge aux requêtes lentes et aux dernières modifications d’exceptions. Dans Web > Exceptions, vérifier Selection criteria ou Matching URLs de toutes les exceptions actives : manque-t-il ^, des points de nom d’hôte échappés ou une limite d’hôte claire ? Y a-t-il des wildcards larges ou beaucoup de textes de domaine non ancrés ?

Avec un accès console autorisé, exécuter la commande suivante, en lecture seule, sous Device Management > Advanced Shell. Elle affiche la charge actuelle des processus sans modifier la configuration ; quitter l’affichage avec q.

top

Si awarrenhttp ou snort figurent en tête de l’utilisation CPU, les regex de Web Exceptions peuvent contribuer à la charge. C’est un indice, pas la preuve d’une cause unique : ces deux processus réalisent d’autres contrôles. Examiner ensemble charge, requêtes et modèles, effectuer une modification limitée puis mesurer à nouveau sous une charge de trafic comparable. Si la CPU reste élevée, continuer à isoler les autres causes dans le chemin de protection concerné ; ne pas désactiver globalement l’inspection ou toutes les exceptions pour faire un test comparatif.

Réparer sélectivement les regex existantes

Pour quelques exceptions, Web > Exceptions > Edit est la voie la plus claire. Conserver d’abord les noms, l’état d’activation, les critères et les options de contournement ; corriger ensuite uniquement le modèle d’URL testé. Pour de nombreuses entrées, il est possible d’exporter le module WebFilterException. Cet export comprend les configurations de Web Exceptions sélectionnées, pas automatiquement la seule exception défectueuse. Les entrées inchangées doivent également être préservées dans la comparaison avant/après.

Avant chacune des deux variantes d’import, conserver en sécurité une sauvegarde actuelle du pare-feu et un export sélectif inchangé. Définir le retour arrière, la fenêtre de maintenance et l’accès administrateur avant l’import. Un export sélectif ne remplace pas une sauvegarde complète. Conserver séparément l’original, la copie de travail et le résultat approuvé ; les configurations et rapports générés contiennent des informations internes et doivent rester sur un poste d’administration autorisé dont l’accès est protégé.

Exporter WebFilterException et le vérifier avec Config Studio

1. Sur le même pare-feu, ouvrir Backup & firmware > Import export et sélectionner Export selective configuration.
2. Rechercher WebFilterException via Add new item et valider avec Apply selected items. Ne pas sélectionner Include dependent entity : les autres domaines de configuration ne doivent pas être modifiés en même temps.
3. Enregistrer l’archive API-[timestamp].tar avec Export ou Download. Extraire une copie de travail ; elle contient Entities.xml.
4. Ouvrir Sophos Firewall Config Studio. Choisir Configuration editor et Rules > Web exceptions, puis charger le fichier sélectif Entities.xml via Import.
5. Dans Config Analysis, rechercher Bad regex. Ouvrir l’entrée concernée avec Edit, examiner la proposition via Apply Fix et valider avec Update. Ne pas modifier les noms ; un nom modifié entraîne la création d’une nouvelle exception lors de l’import sur le pare-feu au lieu de mettre à jour l’existante.
6. Vérifier la proposition avec les cas positifs, négatifs et les longues chaînes sans correspondance. Pour les nouveaux modèles d’hôte, Exact host only et Domain + all subdomains distinguent le périmètre voulu ; la réparation ne doit pas autoriser des sous-domaines par inadvertance. Une correction automatique ne remplace ni cette décision ni le test de l’effet sur la protection.
7. Sous Preview, vérifier la configuration à importer et la comparer à l’original : seules les regex approuvées doivent changer, pas les noms, sources, critères de destination, activation ou options de contournement. Enregistrer l’archive approuvée via Download > Download TAR.

Config Studio traite les données de configuration dans le navigateur du poste ; l’analyse syntaxique, l’analyse et la création de rapports ne téléversent pas ces données à l’extérieur. Les fichiers locaux, téléchargements et rapports HTML restent néanmoins confidentiels. Ne pas transférer de configurations vers d’autres outils d’analyse en ligne. Modifier ou télécharger dans Config Studio ne change encore rien sur le pare-feu.

Alternative : modifier Entities.xml de manière contrôlée

Sans Config Studio, modifier la même copie de travail exportée sélectivement dans un éditeur de texte. Changer uniquement les modèles d’URL concernés ; ne pas remplacer globalement tous les points du fichier XML. Conserver la structure XML, les noms d’objets et les autres champs. Avant de créer l’archive, vérifier que le XML est bien formé et examiner le diff complet. Ne pas importer si la syntaxe est incertaine ou si des fichiers supplémentaires inattendus apparaissent.

Conserver exactement le nom Entities.xml et placer les fichiers dans une nouvelle archive TAR ayant la même structure que l’original, pas dans un ZIP ni dans un dossier supplémentaire. Si l’original contient d’autres fichiers, ne pas les écarter silencieusement. Cette procédure simple de Web Exceptions ne doit pas être appliquée à d’autres modules ou à des objets sensibles interdépendants.

Importer, vérifier l’effet et revenir en arrière

L’import écrase les paramètres existants correspondants. Une archive téléversée avec succès ne prouve ni un périmètre de correspondance restreint ni une protection inchangée. Approuver d’abord le diff, puis importer pendant la fenêtre de maintenance convenue.

Sous Backup & firmware > Import export > Import, sélectionner le .tar vérifié avec Browse et lancer Import. Vérifier les messages d’import pour détecter les erreurs ; ensuite, sous Web > Exceptions, comparer noms et nombre d’entrées, activation, Matching URLs, critères et options de contournement à l’état attendu. Les paramètres sans entrée d’import correspondante restent en place ; l’import ne supprime pas automatiquement les exceptions supplémentaires indésirables.

Créer ensuite de nouvelles connexions, répéter les tests positifs et négatifs existants avec les journaux et, pour une réparation de performances, comparer l’évolution CPU et la charge des processus à la référence initiale. En cas d’erreur, arrêter le déploiement et désactiver l’exception concernée de manière contrôlée si les conséquences pour l’application sont acceptables. Pour une restauration ciblée, l’export sélectif inchangé du même pare-feu peut être importé ; exclure d’abord toute modification intermédiaire, car elle serait également écrasée. Ne pas réactiver sans examen un état antérieur dont le périmètre est manifestement trop large. La restauration d’une sauvegarde complète reste une procédure d’urgence planifiée séparément, pas le premier retour arrière pour une regex isolée. Après chaque retour arrière, vérifier à nouveau la configuration et le chemin de protection.

Planifier WebFilterException via l’API XML

L’import sélectif de Entities.xml décrit ci-dessus n’est pas une procédure générale pour l’API XML. Les références d’objets pour SFOS 22.0 et 23.0 décrivent Add Web Filter Exception / Update Web Filter Exception avec l’objet WebFilterException. Les correspondances suivantes aident à vérifier une automatisation prévue ; elles ne constituent pas une requête complète, prête à être envoyée ou testée sur un pare-feu. L’accès, la protection des identifiants, l’opération explicite, l’enveloppe de requête propre à la version et l’analyse sécurisée des réponses relèvent de la procédure centrale Utiliser l’API XML en toute sécurité. Aucune écriture ne doit être effectuée sans syntaxe confirmée pour le build concerné.

Distinguer l’activation, les indicateurs de contournement et DomainList

Enabled active l’exception et accepte on ou off. Les cinq indicateurs de contournement acceptent également on ou off, mais désignent le contournement d’un contrôle, et non son activation : HttpsDecrypt pour le déchiffrement HTTPS, VirusScan pour l’analyse antimalware, PolicyCheck pour les contrôles de la Web Policy, ZeroDayProtection pour la protection Zero-Day et CertValidation pour la validation des certificats HTTPS. La valeur on d’un indicateur de contournement signifie donc que la protection est contournée. Les conséquences sur la protection expliquées ci-dessus restent applicables, notamment le contournement automatique de Zero-Day lorsque l’analyse antimalware est contournée. Ne pas déduire d’un indicateur de contournement activé qu’une entrée est déjà active ou correspond au flux.

La référence présente sous DomainList des critères répétables et des commutateurs distincts au niveau de l’objet :

• EnableSrcIP avec SrcIp : contrôle de l’adresse IP source ; c’est ici que doit figurer le client.
• EnableDstIP avec DstIp : contrôle de l’adresse IP de destination ; c’est ici que doit figurer l’adresse du site web.
• EnableURLRegex avec URLRegex : contrôle des modèles d’URL, et non une liste de domaines incluant automatiquement les sous-domaines.
• EnableWebCat avec WebCategory : contrôle de la catégorie web.

Les quatre commutateurs sont des valeurs scalaires yes/no, et non on/off. Les quatre critères sont des tableaux de chaînes acceptant plusieurs valeurs ; pour chaque entrée de SrcIp et de DstIp, la référence indique une limite de 43 caractères. Un tableau simplement renseigné ne remplace pas un commutateur d’activation confirmé. Selon la logique de correspondance, les différents types de critères activés doivent correspondre avec AND, et les valeurs au sein d’un même type avec OR. Des modèles d’URL supplémentaires peuvent donc élargir la correspondance. La restriction TLS non résolue, documentée ci-dessus pour les exceptions combinant les adresses IP source et de destination, reste valable : la présence des deux champs dans l’API ne prouve pas que leur combinaison soit autorisée. Ne pas créer un contournement plus large en omettant un critère.

Pour URLRegex, les ancrages de début, les points de nom d’hôte échappés, une limite d’hôte claire, ASCII/Punycode ainsi que les tests positifs, négatifs et sur de longues chaînes sans correspondance restent nécessaires. Le modèle de la référence de l’API n’est pas une liste d’autorisation approuvée et ne remplace ni ces tests ni la limite relative aux chemins HTTPS. La seule vérification de la syntaxe XML ne prouve pas que la correspondance est sûre.

Name est le seul paramètre marqué comme obligatoire : une chaîne scalaire de 60 caractères au maximum ; les caractères ^, ;, ', " et \ sont exclus. Le paramètre facultatif NewName sert au renommage et présente les mêmes limites. Il ne doit pas être assimilé à la création d’une nouvelle entrée par modification du nom lors d’un import sélectif. Desc est une chaîne scalaire facultative de 250 caractères au maximum ; IsDefault identifie une exception par défaut au moyen d’une valeur scalaire yes/no et n’autorise pas à modifier les objets par défaut. Les autres paramètres sont facultatifs et leurs colonnes de valeurs par défaut sont vides. Cela n’implique ni une valeur par défaut précise ni la garantie que les valeurs omises lors d’une mise à jour seront conservées. Sauvegarder au préalable l’état enregistré et définir la comparaison complète entre l’état attendu et l’état réel.

Classer les réponses par opération, code et symbole

Les deux références d’objets contiennent exactement les correspondances suivantes. Les désignations des opérations et les symboles restent volontairement inchangés :

Ces codes XML ne sont pas des codes de statut HTTP. Message.* reste un symbole de documentation non résolu, et non un message d’exécution vérifié ou une cause d’erreur univoque. En particulier, aucun maximum numérique ne doit être déduit de Message.WebExceptionsLimit. Add et Update possèdent des symboles de réussite et d’échec distincts ; les correspondances de Add pour 502 et 522 ne sont pas transposées à Update.

Conserver la réponse réelle avec l’opération et le code XML dans un emplacement protégé, y compris en cas de timeout ou de résultat incertain. Avant chaque nouvelle tentative d’écriture, vérifier l’entrée réellement enregistrée au moyen d’une requête en lecture confirmée pour le build concerné ou sous Web > Exceptions : ancien nom et, le cas échéant, nouveau nom, nombre d’entrées, activation, ensemble des critères et indicateurs de contournement. Même une réussite signalée ne remplace pas cette comparaison. Si une entrée existe, ne pas tenter aveuglément de la recréer, de la renommer, de l’écraser ou d’en supprimer des critères. Si l’état est incertain ou partiellement modifié, s’arrêter et clarifier la situation avec le responsable du pare-feu à partir de la réponse, de l’état initial et de l’état attendu. Après une modification confirmée, établir de nouvelles connexions et effectuer les tests positifs et négatifs existants ; seuls ces tests vérifient l’effet sur la protection. Le guide central de l’API explique en complément les avertissements, les réussites partielles et la procédure sûre sans nouvelles tentatives aveugles.

Révision et rollback

Chaque Web Exception de production comporte au minimum :

• justification technique et ticket
• responsable de l’application et du pare-feu
• hôtes, chemins, sources et groupes d’utilisateurs affectés
• contrôles exacts contournés
• date des tests positifs et négatifs
• date de révision ou d’expiration
• état précédent documenté

Pour le rollback, l’exception est d’abord désactivée plutôt que supprimée immédiatement. L’erreur initiale, le chemin de protection normal et les destinations non affectées sont ensuite retestés. L’exception ne peut être supprimée que lorsqu’il ne reste plus aucune dépendance.

Les exceptions par défaut et du fabricant ne sont pas modifiées sans contrôle. Pour une exception personnalisée, la raison de son existence et la personne chargée de sa réévaluation ultérieure doivent rester évidentes.

Liste de contrôle opérationnelle

• DPI Mode ou Web Proxy Mode identifié.
• Règle de pare-feu et Web Policy réellement correspondantes confirmées.
• Hostname et, le cas échéant, chemin URL relevés dans le trafic réel.
• Regex ancrée au début et testée contre des non-correspondances.
• AND entre types de critères et OR au sein d’un type pris en compte.
• Seule l’option de contournement minimale nécessaire sélectionnée.
• Contournement Zero-Day automatique avec Malware and content scanning pris en compte.
• Source pilote limitée.
• Tests positifs et négatifs réalisés.
• Log Viewer, certificat et effet sur la protection vérifiés ensemble.
• Responsable, ticket, date de révision et rollback documentés.

Questions fréquentes