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.

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.

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.

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.

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.

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 et saisir l’adresse IP précise du client.
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.

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

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.

Circonscrire les erreurs méthodiquement

L’exception ne s’applique pas

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

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