Bien choisir entre DPI Engine et Web Proxy sur Sophos Firewall

Pour les nouvelles règles Internet générales des clients, le DPI Engine constitue généralement un point de départ plus judicieux. Il traite les décisions d’inspection des pare-feu, du Web, du contrôle des applications, des IPS, des logiciels malveillants et des TLS selon un chemin commun. Le Web Proxy reste correct lorsqu’une fonctionnalité explicitement liée au proxy est nécessaire, telle que l’analyse Policy Quota, Batch, Web Cache ou une conception de proxy direct.

Le choix n’est pas une décision globale de l’un ou l’autre pour l’ensemble du pare-feu. Différentes règles de pare-feu et groupes de clients peuvent utiliser différents chemins. Toutefois, pour un flux de test individuel, il doit être clair quelle règle s’applique et si le DPI Engine, le Web Proxy transparent ou un Direct Proxy explicitement configuré traite la demande.

⚠️ Une règle de production ne doit pas basculer spontanément entre DPI Engine et Web Proxy. Le changement modifie le déchiffrement TLS, les fonctions prises en charge, la vue des journaux et parfois le comportement des navigateurs et des applications. Un client pilote est d’abord testé dans une règle distincte, le chemin de retour est documenté, puis la portée est élargie.

Décision rapide

1. Collectez le groupe de clients concerné, Firewall Rule ID, Web Policy, la requête TLS et les fonctions Web requises.
2. Sélectionnez DPI Engine si le trafic client acheminé normal doit être contrôlé sans fonction proxy spéciale.
3. Choisissez Web Proxy si une analyse Policy Quota, Batch, Web Cache ou une conception de proxy intentionnelle est requise.
4. Pour Direct Proxy, vérifiez également la configuration de l’écouteur, Device Access, PAC ou du navigateur et des services de pare-feu locaux.
5. Configurez le décryptage TLS au bon endroit : SSL/TLS inspection rule pour DPI, décryptage proxy HTTPS pour Web Proxy.
6. Incluez un hôte pilote dans sa propre règle enregistrée et déclenchez exactement une demande autorisée et une demande bloquée.
7. Rule ID, vérifiez l’action du filtre Web, l’émetteur du certificat, le résultat de l’analyse et le chemin des données utilisés ensemble.
8. S’il y a des écarts, revenez au chemin de contrôle précédent au lieu de changer les deux modes en même temps sur le même flux de test.

Comprendre DPI Engine, Web Proxy transparent et Direct Proxy

Les trois termes ne décrivent pas la même configuration :

• DPI Engine: Le trafic normalement acheminé est vérifié par rapport à la règle de pare-feu et au SSL/TLS inspection rules. Le client ne connaît pas de proxy.
• Transparent Web Proxy: Le client ne connaît pas non plus de proxy. Cependant, la règle de pare-feu utilise Use web proxy instead of DPI engine et transmet le trafic Web classique au Web Proxy.
• Direct Web Proxy: Le navigateur ou l’application se connecte explicitement au listener proxy du pare-feu, généralement sur le port TCP 3128. Ce chemin est créé par la configuration du client, pas par l’option de la règle de pare-feu.

Dans tous les cas, Web Policy n’agit que si elle est sélectionnée dans la règle de pare-feu qui correspond réellement. Scan HTTP and decrypted HTTPS n’active pas non plus le déchiffrement TLS à lui seul. Configurer Web Protection avec Web Policies explique la planification, les catégories et l’ordre des règles.

Avec DPI Engine, Sophos traite SSL/TLS Inspection, IPS, Application Control, Web Policies et l’antivirus dans un chemin d’inspection commun. Selon la plateforme et le flux, ce chemin peut bénéficier de l’accélération du pare-feu. Les connexions proxy sont en revanche terminées puis rétablies par un processus proxy. Cela ne permet pas d’affirmer qu’un mode est toujours plus rapide ou plus sûr. Seuls des tests sur l’appliance réelle, avec des règles, des applications cibles et un débit représentatifs, sont concluants.

Quelles fonctions déterminent la décision

DPI Engine pour le trafic client général

Le DPI Engine est un bon point de départ si l’environnement a besoin de ces fonctionnalités :

• trafic client acheminé normal sans PAC ou proxy de navigateur par défaut
• SSL/TLS Inspection sur Decryption Profiles basé sur des règles
• Détection HTTP ou TLS également en dehors des ports classiques, à condition que les règles et la détection correspondent
• Évaluation conjointe avec IPS, Application Control et analyse des logiciels malveillants
• Un chemin de données aussi uniforme que possible pour les nouvelles règles Internet des clients

Dans DPI Engine, l’analyse des logiciels malveillants fonctionne toujours en Real-time. Configurer et tester l’analyse des logiciels malveillants sur Sophos Firewall explique le moteur d’analyse, les limites de taille et les actions en cas d’erreur.

Web Proxy convient aux fonctions proxy

Le Web Proxy est nécessaire ou utile si au moins une de ces conditions s’applique :

• un Web Policy utilise Quota
• L’analyse des logiciels malveillants devrait fonctionner en mode Batch au lieu de simplement Real-time.
• Web Content Cache fait partie de la conception
• Les clients utilisent un Direct Proxy avec PAC, GPO, MDM ou une configuration d’application
• un proxy parent ou une autre architecture liée au proxy est fourni
• un chemin d’authentification proxy existant et testé doit être conservé

Policy Quota n’est pas pris en charge par le DPI Engine. Un passage au DPI n’adopterait donc pas une telle politique de la même manière. À l’inverse, un proxy existant n’est pas une raison pour définir chaque nouvelle règle en mode proxy. La fonction requise et le chemin de données réel décident pour chaque groupe de clients.

Avec Web Proxy transparent, le chemin classique traite HTTP sur le port 80 et HTTPS sur le port 443. Direct Web Proxy écoute sur le listener configuré, par défaut sur TCP 3128. Configurer Direct Web Proxy avec un fichier PAC réunit le listener, le fichier PAC, une Local Service ACL limitée et la règle proxy.

Ce dont les deux modes ont besoin en commun

Quel que soit le mode, la protection web nécessite :

• une règle de pare-feu qui touche vraiment le trafic de test
• un Web Policy sélectionné et une journalisation activée
• des critères clairs de source, de destination, de service et d’utilisateur
• une décision consciente QUIC pour le trafic du navigateur
• Visibilité TLS lorsque le contenu ou les téléchargements HTTPS doivent être inspectés
• des exceptions Web et TLS ciblées plutôt que larges
• un test positif et négatif avec du trafic réel

Web Exceptions peut contourner des contrôles de protection dans les deux architectures. Une exception n’est donc créée qu’après l’analyse de la cause et documentée avec un responsable et une date de révision. Utiliser Web Exceptions en toute sécurité explique la séparation entre les exceptions de stratégie, de malware, HTTPS et de certificat.

Préparer un exemple et un pilote

Le flux utilise les valeurs de documentation suivantes :

• Réseau client : 10.20.30.0/24
• Client pilote : CLIENT-WEB-01
• IP pilote fixe : 10.20.30.50
• règle existante : LAN_Clients_Web
• Règle pilote : LAN_Web_Mode_Pilot
• Web Policy : Web_Standard
• Nom de domaine complet du proxy à Direct Proxy : fw01.example.com
• Port proxy direct : 3128

10.20.30.0/24 et 10.20.30.50 sont remplacés par le réseau client réel et une IP pilote fixe visible sur le pare-feu. Aucun NAT ne peut cacher des clients supplémentaires derrière l’adresse pilote. example.com est un domaine de documentation réservé ; fw01.example.com est uniquement remplacé par le nom de domaine complet du pare-feu résoluble en interne lors d’un test de proxy direct.

Avant le changement, les paramètres Rule ID, Web Policy, Use web proxy instead of DPI engine, Scan HTTP and decrypted HTTPS, QUIC actuels, les règles TLS, l’autorité de certification, les exceptions et les journaux pertinents sont documentés. De plus, le pilote a besoin d’un itinéraire de retour testé utilisant la règle existante inchangée.

La règle pilote est supérieure à la règle client précédente et contient uniquement CLIENT-WEB-01 comme source. Destination, Services, Web Policy et autres profils de protection sont initialement adoptés à l’identique. Le test modifie uniquement le chemin d’inspection et non le routage, le NAT, les catégories ou la logique utilisateur en même temps.

Configurer DPI Mode

La règle pilote est ouverte sous Rules and policies > Firewall rules :

1. Désactivez Use web proxy instead of DPI engine.
2. Sélectionnez Web_Standard sous Web filtering > Web policy.
3. Activez Scan HTTP and decrypted HTTPS en fonction de l’analyse planifiée des logiciels malveillants et du contenu.
4. Activez Log firewall traffic.
5. Bloquez délibérément QUIC si vous souhaitez que les navigateurs se contentent de vérifier HTTPS sur TCP.
6. Enregistrez la règle et vérifiez sa position au-dessus de la règle générale du client.

Le déchiffrement TLS pour DPI n’est pas activé dans cette règle de pare-feu. Sous Rules and policies > SSL/TLS inspection rules, le pilote a besoin d’une règle appropriée avec Action: Decrypt, le Decryption profile prévu, la journalisation active et la portée source correcte. L’autorité de certification utilisée par ce chemin doit être approuvée sur le client pilote.

Introduire progressivement TLS Inspection décrit le déploiement contrôlé de la CA, du Decryption Profile, des exceptions et de la SSL/TLS inspection rule. Sans règle Decrypt appropriée, Web Policy peut encore prendre des décisions par domaine ou catégorie, mais l’inspection attendue du contenu et des téléchargements reste limitée.

Configurer Web Proxy Mode

La même règle pilote est adaptée pour le Web Proxy transparent :

1. Activez Use web proxy instead of DPI engine.
2. Sélectionnez Web_Standard sous Web filtering > Web policy.
3. Activez Scan HTTP and decrypted HTTPS selon la conception de l’analyse.
4. Activez Log firewall traffic.
5. Sous Web > General settings, vérifiez le proxy CA, la vérification du certificat et le mode d’analyse.
6. N’activez Decrypt HTTPS during web proxy filtering que si l’autorité de certification proxy sur le pilote est approuvée et que le test HTTPS est préparé.
7. Vérifiez à nouveau la position de la règle et la source pilote.

Dans ce mode, le déchiffrement HTTPS et le traitement des certificats proviennent des paramètres du proxy. Une SSL/TLS inspection rule DPI n’active pas le déchiffrement du proxy. Lors d’un changement de mode, il ne suffit donc pas de rechercher un Decryption Profile existant : il faut aussi contrôler l’émetteur du certificat réellement affiché dans le navigateur.

Direct Proxy constitue un chemin client distinct. Le navigateur ou l’application se connecte à fw01.example.com:3128 ; le listener, Device Access, la règle de pare-feu et la configuration du client doivent correspondre. Use web proxy instead of DPI engine n’est pas requis pour cette requête explicite. Le trafic Direct Proxy présente aussi des limites propres : Traffic Shaping ne s’applique pas à ce chemin et IPS inspecte entre le proxy et WAN, pas entre le client et le proxy.

⚠️ Un Direct Proxy accessible au client peut rendre les services HTTP et HTTPS locaux du pare-feu accessibles via le proxy, même si la matrice de zones ne les autorise pas. WebAdmin, User Portal et les autres cibles d’administration doivent donc faire l’objet de tests négatifs. Si une exposition non autorisée apparaît, le déploiement de Direct Proxy est arrêté.

Modifiez en toute sécurité les règles existantes

Le changement ne s’effectue pas en modifiant l’unique règle de production pendant le test :

1. Exportez ou documentez les règles existantes et les paramètres Web/TLS pertinents.
2. Créez une règle pilote avec des critères identiques et un seul hôte pilote.
3. Répliquez d’abord le mode actuel dans la règle pilote et confirmez l’état initial.
4. Changez uniquement le mode et sa configuration TLS associée obligatoire.
5. Vérifiez le trafic autorisé, bloqué et déchiffré.
6. Testez les flux de navigateur, de mise à jour, de collaboration et de connexion critiques pour votre entreprise.
7. En cas de succès, élargissez progressivement la portée.
8. En cas d’écart, désactivez la règle pilote et testez à nouveau le chemin de retour inchangé.

Une migration de règles n’est pas le bon moment pour modifier simultanément les catégories Web, l’authentification, le NAT, SD-WAN, les exceptions et le moteur de malware. Plusieurs changements simultanés rendent difficile l’attribution d’un résultat différent.

Vérifier correctement le résultat

Au moins les quatre mêmes requêtes sont utilisées pour chaque mode :

1. une page HTTPS délibérément autorisée
2. une URL de catégorie ou de test délibérément bloquée par Web_Standard
3. un téléchargement HTTPS contrôlé capturé par le chemin d’analyse planifié
4. une application critique pour l’entreprise avec une attente de connexion ou de certificat

Dans le Log Viewer, l’heure, l’adresse IP source, l’utilisateur, Firewall Rule ID, Web Policy, la catégorie, l’action et le résultat de l’analyse sont vérifiés ensemble. Le Rule ID doit appartenir à la règle pilote. Un site Web visible ne prouve pas à lui seul la bonne règle ou le bon chemin d’inspection.

Lors du test HTTPS, l’émetteur du certificat est également contrôlé dans le navigateur. En DPI Mode, il doit correspondre à la CA de la SSL/TLS inspection rule qui a été appliquée. En Proxy Mode, il doit correspondre à la CA du proxy configurée sous Web > General settings. Si le navigateur affiche le certificat public d’origine du serveur, la connexion n’a peut-être pas été déchiffrée ou une exception a pu s’appliquer.

Pour une connexion bloquée sur le port 80 ou 443, le journal du pare-feu peut afficher la connexion comme autorisée alors que le journal Web Filter indique que la requête est bloquée. Ce comportement est compatible avec le proxy : le pare-feu autorise le flux vers le proxy, puis celui-ci génère la page de blocage. Les deux journaux sont donc corrélés dans le temps au lieu d’être considérés comme contradictoires.

Tester les règles Sophos Firewall de manière contrôlée réunit la correspondance des règles, Log Viewer, Policy Tester et Packet Capture. Pendant une capture, les outils de diagnostic peuvent modifier temporairement le chemin d’accélération. Une différence de performances observée pendant la capture ne permet donc pas de comparer proprement les deux modes.

Isoler les erreurs par symptôme

Web Policy ne fonctionne pas

Vérifiez Rule ID, la position de la règle, la source, l’utilisateur, le service et le Web Policy sélectionné. Avec le Direct Proxy, vérifiez également si le navigateur ou l’application utilise réellement le listener. N’ajoutez pas de règle Any plus large avant que la correspondance réelle ne soit résolue.

HTTPS n’est pas déchiffré

Déterminez d’abord le mode actif. Pour DPI, vérifiez les SSL/TLS inspection rule, Action, Decryption Profile et CA. Pour le Web Proxy Decrypt HTTPS during web proxy filtering, vérifiez le proxy CA et l’éventuel Web Exceptions. Scan HTTP and decrypted HTTPS ne remplace aucune de ces étapes de décryptage.

Après le changement, des erreurs de certificat se produisent

Vérifiez l’émetteur visible dans le client, le magasin de confiance, l’exception TLS, l’épinglage du certificat et le stockage de votre propre application. Ne créez pas immédiatement un Don't decrypt étendu ou une exception Web. L’exception doit être limitée le plus possible au domaine ou à l’application réellement concerné.

Quota ou l’analyse Batch manque

Ces fonctions nécessitent Web Proxy Mode. Il faut contrôler la règle pilote active, Use web proxy instead of DPI engine, l’affectation de la stratégie et le mode d’analyse du proxy. Un test DPI réussi ne confirme pas cette fonction du proxy.

Le site est bloqué, mais le journal du pare-feu indique que la connexion est autorisée

Fusionnez Web Filter et le pare-feu à temps. Pour le trafic proxy, le pare-feu peut autoriser la connexion au proxy avant que le proxy ne bloque l’URL et ne délivre une page de blocage. Catégorie, Action, Rule ID et Règle de politique Web fournissent la décision réelle.

Seuls les ports ou applications individuels échouent

Précisez si un proxy transparent, Direct Proxy ou DPI est utilisé. Le proxy transparent se concentre sur les ports Web classiques ; Direct Proxy a besoin d’un client pris en charge et de l’écouteur ; DPI peut reconnaître TLS sur des ports TCP supplémentaires si la règle et le déchiffrement correspondent. Ne définissez pas le partage de port universel comme remplacement du diagnostic.

Les journaux ne suffisent pas à identifier la cause

Activer la journalisation du pare-feu et du Web, puis répéter le test avec un horaire précis. Selon le chemin, les journaux du proxy Web, TLS et d’inspection sont pertinents. Services et fichiers journaux Sophos Firewall explique leur classement et un export sécurisé.

Restauration et fonctionnement

Pour revenir en arrière, la règle pilote est désactivée sans supprimer la Web Policy de production. Le pilote doit ensuite retrouver la Rule ID documentée et le chemin de trafic d’origine. Les autorisations temporaires de Device Access pour le proxy, les affectations PAC et les exceptions du pilote sont rétablies dans leur état antérieur.

Pendant le fonctionnement, chaque décision de mode liée à une règle a un propriétaire et une raison compréhensible. Les fonctions proxy uniquement, Decryption Profiles, les modifications de l’autorité de certification, les exceptions et les groupes de clients sont vérifiés régulièrement. Une modification ultérieure recommence avec un pilote car les nouvelles versions du navigateur, de TLS et de l’application peuvent modifier le résultat.

Liste de contrôle des opérations

• Le groupe de clients, l’adresse IP pilote et le chemin de retour sont documentés.
• Le Firewall Rule ID réel et la position de la règle sont connus.
• Web Policy et la journalisation sont actifs dans la règle pilote.
• Les fonctions proxy uniquement ont été capturées avant la sélection du mode.
• Le décryptage DPI et Proxy TLS ne sont pas confondus.
• L’autorité de certification réellement utilisée est approuvée sur le client pilote.
• QUIC a été intentionnellement géré et testé avec les navigateurs.
• Le trafic réel autorisé, bloqué et analysé a été vérifié.
• L’émetteur du certificat et l’action du filtre Web correspondent au mode.
• Les cibles de gestion de proxy direct ont été testées négatives si ce chemin est utilisé.
• Le pare-feu et les journaux Web ont été évalués ensemble.
• Aucune exception générale ou règle Any n’a été définie comme solution rapide.
• La restauration, le propriétaire et la date de révision sont documentés.

Questions fréquemment posées