Configurer Sophos Firewall Discover Mode avec TAP et SPAN

En Discover Mode, Sophos Firewall reçoit une copie du trafic réseau via une interface TAP. Le switch réplique les ports ou VLAN sélectionnés vers un port SPAN ou mirror relié à un port libre du pare-feu. Le pare-feu n’est pas en ligne et ne modifie pas le chemin de paquets en production.

Procédure rapide : Garantir un accès d’administration séparé, configurer un port SPAN bidirectionnel sur le switch, sélectionner un port libre du pare-feu, exécuter system discover-mode tap add PortD dans la Device Console et vérifier d’abord l’arrivée des paquets avec Packet Capture. Examiner ensuite Current Activity, les rapports et, si nécessaire, un Security audit report.

⚠️ Discover Mode est un mode d’observation. Aucune Security Policy ne peut être appliquée au trafic de l’interface TAP, et le pare-feu ne peut ni le bloquer ni le rejeter. HTTPS n’est pas pris en charge dans ce mode. Un rapport sans constat ne prouve donc ni une visibilité complète ni une protection efficace.

PortD est un exemple dans ce guide. Il faut utiliser le port physique réellement libre de l’appliance.

Discover Mode en huit étapes

1. Vérifier un port d’administration indépendant du pare-feu et un chemin de secours sûr vers l’administration.
2. Définir sur le switch les ports ou VLAN à répliquer dans les deux sens.
3. Relier un port mirror dédié à un port physique libre du pare-feu.
4. Dans la Device Console, enregistrer l’état initial avec system discover-mode tap show.
5. Activer le port d’exemple comme TAP avec system discover-mode tap add PortD.
6. Sous Network > Interfaces, vérifier le type Discover, physical (TAP).
7. Générer un flux de test connu et confirmer ses paquets sur l’interface TAP.
8. Seulement ensuite, évaluer les rapports, l’attribution des utilisateurs et un Security Audit Report.

Le switch et le pare-feu sont configurés séparément. Une interface TAP visible ne prouve pas encore que le switch réplique les bonnes trames.

Quand TAP convient et quand il ne convient pas

Discover Mode convient à un inventaire passif, à une preuve de concept ou à une analyse préliminaire avant un déploiement ultérieur en ligne. Les objectifs typiques sont les suivants :

• visualiser les relations de trafic et les applications actives ;
• classer les catégories web et applicatives dans les limites techniques ;
• observer les détections IPS sans modifier le chemin de données ;
• collecter des rapports pour planifier ensuite les règles et la segmentation ;
• évaluer un nouveau pare-feu en parallèle de l’infrastructure existante.

TAP n’est pas le bon choix si le trafic doit déjà être activement bloqué, déchiffré, modifié par NAT ou contrôlé par des règles basées sur les utilisateurs. Cela nécessite un mode gateway, bridge ou un autre fonctionnement en ligne avec des règles de pare-feu adaptées.

Discover Mode peut être associé aux modes gateway, mixed et bridge. Les règles de sécurité s’appliquent alors aux interfaces en ligne normales, pas à l’interface TAP. Planifier les zones et interfaces Sophos Firewall explique comment les ports physiques, les zones, les bridges et les autres types d’interface s’articulent.

Topologie d’exemple et valeurs à remplacer

L’exemple utilise les composants suivants :

• Switch principal : SW-Core-01
• Uplink à répliquer : Switch-Port 1, réception et émission
• Destination SPAN : Switch-Port 24
• TAP du pare-feu : PortD, libre et sans configuration IP
• Administration du pare-feu : PortA - 10.10.10.16/24
• Client de test : 10.20.30.40

Les noms et les adresses sont des exemples. Leur fonction est déterminante : le port TAP reçoit uniquement les trames répliquées. L’administration, les mises à jour, le DNS et l’envoi des rapports utilisent une autre interface configurée normalement.

Le port mirror doit être au moins aussi rapide que le trafic observé. Si plusieurs ports source très sollicités sont répliqués vers un port de destination plus lent, le switch peut rejeter des paquets de la copie. La connexion de production continue de fonctionner, mais le rapport reste incomplet. TAP n’est donc pas une capture forensique sans perte, et l’absence d’un événement ne prouve pas qu’il ne s’est pas produit.

Prérequis et limites de sécurité

Ces points doivent être clarifiés avant l’activation :

• Un switch administré prend en charge SPAN ou port mirroring.
• Un port physique du pare-feu est libre et n’est pas utilisé en production.
• L’administration reste accessible via une interface séparée.
• Le pare-feu accède à Internet pour la classification cloud, les mises à jour IPS et la génération du Security Audit Report.
• Si le rapport doit afficher les utilisateurs au lieu des seules adresses IP, une source d’authentification externe appropriée est intégrée.
• La finalité, la conservation et les destinataires des données répliquées sont conformes aux exigences de confidentialité.

Les trames répliquées peuvent révéler des adresses internes, des requêtes DNS, des protocoles non chiffrés et des relations de communication. Les captures de paquets et les rapports ne sont donc conservés que le temps nécessaire et sont transférés de manière protégée.

Bien comprendre Port Affinity

Pour certaines plateformes, le guide Sophos recommande d’associer l’interface TAP à un processeur avec bind-with avant l’activation. Les appliances XGS ne nécessitent pas de Port Affinity manuelle, car le traitement est automatiquement réparti entre les cœurs du processeur.

Sur d’autres appliances et plateformes virtuelles, l’affectation appropriée du processeur dépend du matériel, de l’adaptateur et de la charge. Il ne faut pas reprendre une valeur de processeur provenant d’un autre exemple. Si la plateforme nécessite une affectation manuelle, celle-ci est planifiée avant le déploiement TAP à l’aide des recommandations adaptées à l’équipement ou du support. Une commande set port-affinity générique ne fait pas partie de la procédure rapide normale.

Pour un pare-feu virtuel, il faut également s’assurer que l’hyperviseur, le vSwitch et l’adaptateur réseau virtuel livrent réellement les trames répliquées à la VM. L’état de l’adaptateur réseau virtuel ne suffit pas à le confirmer ; la preuve par paquets dans SFOS est déterminante.

Préparer SPAN ou port mirroring sur le switch

La configuration exacte dépend du fabricant. Au minimum, les valeurs suivantes sont définies sur le switch :

1. Source: le port physique à observer ou les VLAN prévus.
2. Direction: réception et émission afin de voir les deux sens.
3. Destination: le port dédié relié à PortD du pare-feu.
4. Session status: activé.

Le port de destination n’est pas utilisé simultanément comme port access ou trunk normal pour des terminaux. Le port d’administration du pare-feu n’est pas non plus connecté au port mirror. Sinon, les chemins d’administration et d’observation se mélangent, ou le switch crée une topologie de couche 2 inattendue.

Avant de configurer le pare-feu, il est recommandé de documenter les VLAN et les directions réellement répliqués par le switch. Sur les uplinks importants, le pilote commence de préférence avec un seul VLAN de test ou un port clairement limité plutôt qu’avec tout le trafic du cœur de réseau.

Activer l’interface TAP sur Sophos Firewall

Sous Network > Interfaces, le port sélectionné doit appartenir à la zone None et ne doit avoir ni configuration IP ni dépendance de production. Il ne faut pas libérer un port utilisé uniquement pour le test : cela peut interrompre les interface hosts, DHCP, le routing, les règles ou d’autres services.

Après la connexion SSH à Sophos Firewall, ouvrir Option 4: Device Console. Lire d’abord l’état actuel :

system discover-mode tap show

Activer ensuite le port d’exemple prévu et le contrôler à nouveau :

system discover-mode tap add PortD
system discover-mode tap show

Sophos documente le message Discover Interface added successfully pour une activation réussie. Le port apparaît ensuite sous Network > Interfaces comme Discover, physical (TAP).

La commande ne configure pas le SPAN sur le switch. Si le port présente le bon état SFOS mais aucun trafic, vérifier d’abord le côté switch au lieu de créer une règle de pare-feu par supposition.

Vérifier le trafic et les rapports

1. Effectuer une vérification contrôlée des paquets

Sur le client de test 10.20.30.40, générer un test DNS clair ou HTTP non chiffré. Sous Diagnostics > Packet capture, utiliser un filtre BPF précis :

host 10.20.30.40

La capture doit afficher des paquets avec In interface PortD. Avec une réplication bidirectionnelle, la requête et la réponse apparaissent. Une Firewall Rule ID ou un état Forwarded n’est pas un critère de réussite sur le chemin TAP passif, car SFOS ne transfère pas ce trafic et ne lui applique aucune règle de sécurité.

Packet Capture dans Sophos Firewall WebAdmin explique l’utilisation, les filtres et les limites d’exportation. La capture est arrêtée après le test et ne conserve que la période nécessaire.

2. Vérifier la visibilité dans son contexte

Après la preuve par paquets, examiner Current activities et les rapports locaux appropriés. Les attentes doivent correspondre au protocole :

• les adresses source et destination visibles correspondent au test ;
• une catégorie applicative ou web n’est attendue que si SFOS peut classifier le trafic ;
• une détection IPS est une observation, pas un blocage ;
• les utilisateurs n’apparaissent qu’avec une source d’identité fonctionnelle et une attribution correcte ;
• le contenu HTTPS n’est pas pris en charge dans Discover Mode.

La source externe des utilisateurs est testée séparément. Pour Active Directory, consulter Connecter Active Directory à Sophos Firewall. Sinon, l’absence d’un nom d’utilisateur ne signifie pas automatiquement que le trafic TAP est absent.

3. Générer un Security Audit Report

Sous Reports > Show report settings > Report scheduling > Add, sélectionner le type Security audit report. Saisir consciemment les destinataires et l’organisation, puis vérifier séparément le transport des e-mails et le contenu du rapport.

Planifier les rapports Sophos Firewall et les envoyer par e-mail explique les limites de Send test mail, Generate now, la confidentialité, la langue et le comportement HA. Un e-mail de test réussi prouve uniquement le chemin de messagerie. Seul un rapport généré avec des données plausibles confirme le chemin complet.

HA et modes de fonctionnement mixtes

Discover Mode prend uniquement en charge la HA active-passive. La HA active-active n’est pas possible dès qu’un des pare-feu fonctionne en Discover Mode.

Un cluster active-passive ne peut pas être créé tant que l’interface TAP est active. Pour configurer la HA, désactiver le port TAP sur les deux appliances, créer la HA, puis réactiver séparément l’interface TAP sur les deux équipements. Sophos précise également que l’interface TAP reste active sur l’appliance passive.

Le câblage, la réplication du switch et la réception des données sont donc vérifiés à nouveau après un changement de rôle planifié. Il ne faut pas supposer qu’une période de rapport existante ou une observation TAP se poursuit sans interruption sur l’autre nœud. Configurer la HA Sophos Firewall décrit les rôles, la synchronisation et le fonctionnement propre à chaque nœud.

La limite reste également claire dans une topologie gateway ou bridge mixte : les interfaces normales peuvent transférer et protéger le trafic. L’interface TAP reçoit uniquement la copie répliquée.

Résoudre les problèmes selon le symptôme

L’interface TAP n’affiche aucun paquet

1. Vérifier le port configuré avec system discover-mode tap show.
2. Sous Network > Interfaces, vérifier le type Discover, physical (TAP) et le lien physique.
3. Comparer la destination du switch, les ports source ou les VLAN, ainsi que le sens de réplication.
4. Répéter un flux de test connu sans filtre de capture trop étroit.
5. Sur une VM, vérifier si le chemin réseau virtuel transmet les trames étrangères répliquées au pare-feu.

Une règle de pare-feu n’est pas la solution, car le trafic TAP n’est pas transféré par le moteur de règles normal.

Un seul sens est visible

La source mirror du switch est souvent réglée sur RX ou TX uniquement. Passer la session sur both, c’est-à-dire les deux sens, puis répéter le même test. En cas de routage asymétrique, le chemin retour peut également emprunter un autre uplink physique qui n’est pas répliqué.

Les paquets sont visibles, mais les rapports sont vides ou incomplets

Vérifier d’abord la période, le type de rapport, l’accès Internet, l’état des patterns et les protocoles réellement répliqués. HTTPS n’est pas pris en charge dans Discover Mode. Une destination SPAN surchargée peut également perdre des copies sans affecter le trafic de production.

Si des utilisateurs manquent, poursuivre avec la source d’authentification. Si seul l’envoi d’e-mails échoue, vérifier d’abord les notifications par e-mail. Ne pas redémarrer les services de reporting par supposition et ne pas supprimer les données de rapport locales en première étape.

Un rapport indique des risques, mais rien n’est bloqué

C’est le comportement attendu. Discover Mode évalue une copie. Un constat ne devient une future règle en ligne, une segmentation ou une autre mesure de protection qu’après une analyse technique. Le pare-feu TAP ne peut pas arrêter ultérieurement le flux original observé.

Désactiver Discover Mode en sécurité

Avant la désactivation, sauvegarder les rapports, périodes et constats nécessaires. Ensuite :

1. Désactiver la session SPAN sur le switch afin qu’aucune nouvelle copie n’arrive.
2. Supprimer le port d’exemple dans la Device Console :

system discover-mode tap delete PortD
system discover-mode tap show

3. Sous Network > Interfaces, vérifier que le port n’apparaît plus comme Discover, physical (TAP).
4. Supprimer de manière contrôlée les planifications Security Audit devenues inutiles.
5. Réutiliser normalement le port de destination du switch uniquement après une vérification documentée.
6. Si le port du pare-feu doit ensuite être utilisé en production, planifier et tester sa zone, son adresse IP, ses dépendances et ses règles comme un changement distinct.

Il ne faut pas mélanger la désactivation du TAP avec une migration en ligne improvisée. Les modes gateway ou bridge modifient le routage, les règles et le risque d’interruption et nécessitent un plan de migration séparé.

Liste de contrôle

• L’accès d’administration séparé fonctionne.
• Le port TAP est physique, libre et n’est pas utilisé ailleurs.
• La source, la direction et la destination SPAN sont documentées.
• La destination mirror n’est pas surchargée.
• system discover-mode tap show affiche le port attendu.
• Packet Capture voit un flux de test connu dans les deux sens.
• Les rapports sont évalués uniquement dans les limites de la visibilité prise en charge.
• HTTPS et l’absence d’enforcement sont documentés.
• L’attribution des utilisateurs a été testée séparément si nécessaire.
• Les destinataires et la conservation des rapports sont approuvés.
• Les limites HA ou VM ont été testées dans le déploiement réel.
• La désactivation et la migration en ligne ultérieure sont des changements distincts.

FAQ