Sophos Firewall : déployer TLS Inspection pas à pas

Une grande partie du trafic web actuel est chiffrée. Sans TLS Inspection, la firewall ne voit souvent que l’IP de destination, le SNI, les informations de certificat et des métadonnées, mais pas le contenu réel de la connexion.

C’est un problème de sécurité : de nombreuses fonctions de protection ne peuvent pas contrôler le payload chiffré, ou seulement de manière très limitée. Malware-Scanning, Web Protection, analyse Zero-Day, Content-Scanning et certaines parties de la détection applicative ou de menaces deviennent réellement efficaces lorsque la firewall peut déchiffrer le trafic TLS, l’analyser, puis le rechiffrer. IPS et NDR profitent également d’une meilleure visibilité en clair. Sans déchiffrement, de nombreux signaux restent limités aux métadonnées, certificats, IP, domaines ou informations de protocole.

TLS Inspection n’est toutefois pas une fonction à activer sans préparation pour tous les utilisateurs. Elle peut perturber des applications, soulever des questions de protection des données et charger davantage la firewall. TLS Inspection doit donc être introduite de façon planifiée, progressive et avec une stratégie d’exceptions claire.

Licence et prérequis

Pour TLS Inspection et l’analyse utile du trafic déchiffré, les licences de protection adaptées sont nécessaires.

Les points les plus importants sont :

• Web Protection : contient Web Security, Web Control, Application Control et Web Malware Protection.
• Network Protection : contient notamment IPS, Security Heartbeat et d’autres fonctions de protection réseau.
• Zero-Day Protection : devient important si des fichiers ou téléchargements doivent aussi être analysés par Machine Learning ou sandbox.

Web Protection est inclus dans le bundle Standard Protection. Xstream Protection et Epic Protection incluent également Web Protection et d’autres modules de sécurité. Sophos décrit les modules de licence dans la vue d’ensemble officielle : Sophos Firewall licensing info.

Avant le rollout, il faut vérifier :

• Un firmware Sophos Firewall actuel est installé.
• Web Protection est sous licence.
• Le certificat CA de la firewall est distribué aux clients.
• Un groupe ou réseau de test est défini.
• Le rollback est documenté.
• Le processus d’exception est clarifié.
• Le logging est activé.

Si le certificat CA n’a pas encore été distribué, l’article suivant peut aider : Installer le certificat CA Sophos Firewall pour HTTPS Scanning.

⚠️ TLS Inspection peut perturber les applications qui utilisent Certificate Pinning ou leurs propres contrôles de certificat. Commence toujours avec un groupe de test, pas directement avec tous les utilisateurs.

DPI ou Web Proxy ?

La Sophos Firewall peut réaliser HTTPS-Decryption dans deux modes :

• DPI Mode : la règle firewall utilise le DPI Engine. Les SSL/TLS Inspection Rules sous Rules and policies > SSL/TLS inspection rules décident ce qui est déchiffré.
• Web Proxy Mode : la règle firewall utilise le Web Proxy. HTTPS-Decryption est alors piloté par les paramètres Web Proxy et les Web Policies.

Pour les configurations modernes, DPI Mode est souvent utilisé. La règle firewall est alors importante :

1. Ouvre Rules and policies > Firewall rules.
2. Modifie la règle LAN-to-WAN concernée.
3. Ouvre Security features > Web filtering.
4. Active la Web Policy appropriée.
5. Active Scan HTTP and decrypted HTTPS.
6. Laisse Use web proxy instead of DPI engine désactivé si les SSL/TLS Inspection Rules doivent s’appliquer.

Si Use web proxy instead of DPI engine est activé, le trafic web passe par le Web Proxy. Pour HTTP/HTTPS, d’autres paramètres de decryption s’appliquent alors que pour les SSL/TLS Inspection Rules basées sur DPI.

Sophos décrit cette différence dans le guide Configure SSL/TLS inspection and decryption.

Quel trafic faut-il déchiffrer ?

Il ne faut pas tout déchiffrer aveuglément. Une bonne TLS Inspection commence avec des objectifs clairs.

Premières cibles pertinentes :

• LAN > WAN : trafic web classique des utilisateurs vers Internet.
• Wi-Fi > WAN : clients gérés dans le WLAN d’entreprise.
• VPN > WAN : utilisateurs Remote Access si leur trafic Internet passe par la firewall.
• LAN > DMZ : accès internes à ses propres serveurs, si un contrôle de sécurité est souhaité et si les certificats sont correctement distribués.

À traiter avec prudence :

• Banque, santé, administrations et portails très sensibles.
• Gestionnaires de mots de passe et Identity Providers.
• Services de mise à jour des systèmes d’exploitation et fabricants.
• Applications mobiles et appareils Android.
• Applications avec Certificate Pinning.
• Services voix, vidéo et collaboration s’ils deviennent instables avec Decryption.

Pour les publications de serveurs depuis Internet vers la DMZ, TLS Inspection n’est pas automatiquement la meilleure solution. Pour les serveurs web, Web Server Protection / WAF ou un Reverse Proxy est souvent plus adapté.

Stratégie de rollout

Une approche progressive a fait ses preuves :

1. Distribuer le certificat CA.
2. Préparer la Web Policy et la règle firewall.
3. Sélectionner le Decryption Profile.
4. Définir un petit groupe de test.
5. Activer la SSL/TLS Inspection Rule uniquement pour ce groupe.
6. Surveiller Control Center et Log Viewer.
7. Analyser les erreurs et documenter proprement les exceptions.
8. Étendre progressivement à d’autres groupes d’utilisateurs.

Cela permet d’identifier tôt les applications problématiques sans affecter toute l’exploitation.

Comprendre les Decryption Profiles

Un Decryption Profile définit à quel point la firewall traite strictement les connexions TLS. Les profiles se trouvent sous Profiles > Decryption profiles.

Un Decryption Profile répond notamment à ces questions :

• Que se passe-t-il avec des certificats invalides ou non approuvés ?
• Les anciennes versions TLS sont-elles bloquées ?
• Les Cipher Suites non sécurisées sont-elles bloquées ?
• Que se passe-t-il avec la compression SSL ?
• Que se passe-t-il avec des unrecognized cipher suites ?
• Que se passe-t-il si la firewall ne peut pas déchiffrer une connexion ?
• Quelle CA est utilisée pour la resignature ?

Pour un premier rollout, un profile plus compatible est judicieux, par exemple Maximum compatibility ou un profile personnalisé conservateur. Pour des règles de sécurité en production, un profile plus strict comme Block insecure SSL peut ensuite être utilisé.

Important : le Decryption Profile est sélectionné directement dans la SSL/TLS Inspection Rule. Sophos indique que le profile peut remplacer les paramètres SSL/TLS Inspection globaux pour cette règle.

Créer une SSL/TLS Inspection Rule

Le chemin de menu est Rules and policies > SSL/TLS inspection rules.

Une première règle doit être aussi ciblée que possible :

• Action: Decrypt
• Decryption profile: profile de test conservateur
• Source zones: LAN ou réseau de test
• Source networks and devices: groupe de test ou sous-réseau de test
• Destination zones: généralement WAN
• Destination networks: d’abord Any
• Services: souvent Any au début, car SSL/TLS peut aussi être reconnu sur d’autres ports TCP
• Websites / Categories: restriction optionnelle

Sophos décrit que les SSL/TLS Inspection Rules peuvent reconnaître les connexions SSL/TLS sur n’importe quel port TCP. Les règles sont traitées de haut en bas. Les règles spécifiques doivent donc être placées au-dessus des règles générales.

Documentation officielle : SSL/TLS inspection rules.

Exclusion Lists

Tout le trafic TLS ne doit pas être déchiffré. Sophos utilise pour cela des Exclusion Rules et des TLS Exclusion Lists.

Local TLS Exclusion List

La Local TLS exclusion list est la liste d’exceptions locale de la firewall. Elle est vide par défaut et peut être remplie via le troubleshooting dans Control Center ou Log Viewer.

Elle peut aussi être modifiée manuellement :

Web > URL groups > Local TLS exclusion list

Cette liste est utile pour les domaines qui posent problème dans son propre environnement, par exemple à cause de Certificate Pinning ou d’applications client particulières.

Managed TLS Exclusion List

La Managed TLS exclusion list contient des exceptions maintenues par Sophos pour des services connus comme problématiques. Cette liste est mise à jour par les mises à jour firmware.

Les exemples typiques sont des services pour lesquels TLS Inspection provoque généralement des problèmes ou n’a pas de sens techniquement.

Exclusion Rules personnalisées

On peut également créer ses propres SSL/TLS Inspection Rules avec Action > Don’t decrypt. Elles doivent être placées directement sous la règle d’exclusion standard et contenir uniquement le trafic qui ne doit réellement pas être déchiffré.

Critères possibles :

• Web categories
• URL Groups
• Utilisateurs et groupes
• Réseaux Source et Destination
• Adresses IP
• Services

Les exceptions doivent être documentées : domaine, raison, utilisateurs concernés, date et date de revue.

Surveiller le Dashboard Widget

Dans Control Center, il existe un widget pour SSL/TLS Inspection. Ce widget est très utile pour surveiller le rollout et les erreurs.

Il montre notamment :

• Part des sessions SSL/TLS déchiffrées.
• Part des sessions SSL/TLS non déchiffrées.
• Autre trafic.
• Erreurs des derniers jours.
• Top-Websites ou Top-Users avec problèmes.
• Decryption peak et Decryption limit.

Si le widget affiche de nombreuses erreurs, il ne faut pas désactiver immédiatement toute la TLS Inspection. Il vaut mieux utiliser Fix errors pour analyser les destinations concernées et créer des exceptions propres si nécessaire.

Analyser le Log Viewer

Dans le Log Viewer, on peut sélectionner le filtre SSL/TLS inspection. On y voit ce qui s’est passé pour chaque connexion.

Les couleurs aident à une première classification :

• Rouge : erreur. La connexion n’a pas pu être correctement déchiffrée ou traitée. Il faut vérifier les erreurs de certificat, Cipher Suites, versions TLS ou applications incompatibles.
• Vert : Do not decrypt. La connexion n’a volontairement pas été déchiffrée, par exemple en raison d’une Exclusion Rule ou d’une TLS Exclusion List.
• Bleu : Decrypt. La connexion a été déchiffrée puis retransmise rechiffrée.

Le log montre aussi le Decryption Profile, l’IP source, l’IP cible, l’utilisateur, la catégorie et le domaine cible. Cela permet de vérifier si la bonne règle correspond et si une exception s’applique réellement.

Tests

Après l’activation de TLS Inspection, il faut vérifier :

• Le certificat CA Sophos est-il utilisé dans le navigateur ?
• Les applications métier importantes fonctionnent-elles ?
• Existe-t-il des erreurs TLS dans le Log Viewer ?
• Les événements Malware ou Web Policy sont-ils correctement reconnus ?
• Le trafic apparaît-il comme decrypted dans le widget Control Center ?
• La performance de la firewall reste-t-elle dans la plage attendue ?
• Les utilisateurs de test remontent-ils des problèmes ?

Pour le dépannage, Log Viewer, Policy Test, la vue des certificats du navigateur, Packet Capture et le widget SSL/TLS Inspection sont particulièrement utiles.

Rollback

En cas de perturbations, un rollback clair doit être possible :

• Désactiver la SSL/TLS Inspection Rule.
• Retirer le groupe de test de la règle.
• Assouplir le Decryption Profile.
• Ajouter une exception pour le domaine ou l’application concerné.
• Remettre la règle firewall sur Web Proxy si cela est volontairement souhaité.

Sophos indique que les SSL/TLS Inspection Rules et le SSL/TLS Engine doivent être visiblement actifs pour que Control Center et Log Viewer affichent les détails. Si TLS Inspection est désactivée à des fins de troubleshooting, elle doit ensuite être réactivée.

Recommandation

TLS Inspection n’est pas un projet en un clic. Bien introduite, elle fournit toutefois beaucoup plus de visibilité et améliore l’efficacité de Web Protection, Malware Scanning, IPS, NDR et des fonctions Zero-Day.

Pour les environnements de production, nous recommandons :

• D’abord LAN-to-WAN pour un petit groupe de test.
• Distribuer proprement le certificat CA.
• Choisir consciemment le mode DPI/Web Proxy.
• Ne pas commencer avec un Decryption Profile trop agressif.
• Observer quotidiennement Log Viewer et Dashboard.
• Documenter les exceptions et les revoir régulièrement.
• Étendre le rollout seulement après des tests réussis.