Configurer la surveillance sFlow sur Sophos Firewall

Avec la surveillance sFlow, un Sophos Firewall peut envoyer des échantillons de trafic à un collecteur externe. Les pics de volume, les flux inhabituels, les destinations inattendues et la répartition de la charge entre les interfaces deviennent ainsi plus faciles à repérer que dans des journaux en direct isolés. Cette fonction est disponible dans Sophos Firewall v22.

Cette fonction est particulièrement intéressante pour le dépannage, la planification de la capacité et la surveillance de la sécurité. Cependant, sFlow ne remplace ni le Log viewer ni Packet Capture ou une conservation propre des journaux via Central Firewall Reporting ou Syslog. sFlow répond à d’autres questions : pas “quelle règle a exactement été appliquée ?”, mais “quels flux de trafic passent par cette interface et comment sont-ils répartis ?”. Pour l’état matériel, la température, les ventilateurs, les alimentations et le PoE, SNMP Hardware Monitoring est plus approprié.

Si des enregistrements NetFlow v5 issus de règles de pare-feu journalisées de manière ciblée sont requis plutôt que des échantillons d’interface, Configurer et tester NetFlow sur Sophos Firewall convient mieux. Si, au contraire, un switch doit envoyer passivement un flux de paquets répliqué au pare-feu, Discover Mode avec TAP et SPAN constitue le modèle adapté et clairement distinct.

Quand sFlow est-il pertinent ?

sFlow est pertinent lorsqu’un collecteur externe ou un système de surveillance est disponible et que les modèles de trafic doivent être visibles dans le temps.

Cas d’utilisation typiques :

• Détecter des pics de bande passante inattendus sur les interfaces WAN, LAN ou Core.
• Mieux comprendre le trafic entre VLANs ou sites.
• Soutenir la planification de la capacité pour le pare-feu, le lien montant ou le commutateur central.
• Trouver des flux suspects comme point de départ pour une analyse plus approfondie.
• Comparer les données de surveillance avec les journaux du pare-feu, le reporting central ou les données SIEM.

Si une seule connexion doit être vérifiée, sFlow n’est souvent pas l’outil approprié. Pour des tests de performance ciblés, iPerf est plus adapté. Pour des problèmes de connexion concrets, le Log Viewer, le Policy Test et le Packet Capture sont généralement plus rapides.

Prérequis

Pour sFlow, vous avez besoin de :

• Sophos Firewall avec SFOS 22.0 ou plus récent.
• Accès administratif à la Device Console.
• Un collecteur sFlow accessible, par exemple un NMS, SIEM ou un outil d’analyse de flux.
• Un réseau sécurisé entre le pare-feu et le collecteur.
• Une décision claire sur les interfaces matérielles à surveiller.

La configuration ne se fait pas dans une page WebAdmin. Dans WebAdmin sous SFOS 22, ouvrez le menu du nom d’utilisateur (par exemple admin) en haut à droite et choisissez Console ; sous SFOS 23, cliquez à cet endroit sur l’icône de compte Account icon et choisissez Command line. Dans les deux versions, choisissez ensuite 4. Device Console pour exécuter system sflow. L’Advanced Shell n’est pas adaptée. L’article Dépannage de Sophos Firewall : services et journaux explique la différence.

Avec un client SSH, ouvrez Administration > Device access > Local service ACL, autorisez SSH depuis la zone source requise, puis cliquez sur Apply. N’ouvrez pas une zone entière sans nécessité : une Local service ACL exception rule est plus restrictive si seuls certains postes d’administration doivent accéder au service. Vérifiez l’accès existant à la console ou en SSH avant de modifier sFlow, et non au moment d’un retour arrière.

Déroulement minimal

La configuration elle-même est courte. L’important est surtout de planifier d’abord le chemin de surveillance, puis seulement d’activer sFlow :

1. Définir le collecteur, le port et le chemin réseau.
2. Choisir une interface matérielle pour le premier pilote.
3. Exécuter d’abord system sflow show pour vérifier si d’anciens collectors ou interfaces de monitoring sont déjà configurés.
4. Configurer le taux d’échantillonnage et, si nécessaire, l’intervalle de polling.
5. Utiliser system sflow show pour vérifier que le collecteur et l’interface sont correctement configurés.
6. Activer sFlow avec system sflow on.
7. Dans le collecteur, vérifier que les données arrivent depuis l’IP d’agent attendue du pare-feu.

Les sections suivantes expliquent les différentes étapes et les limites opérationnelles.

Limites importantes avant l’activation

sFlow semble inoffensif, mais peut avoir des impacts sur le fonctionnement et la sécurité.

sFlow n’est pas chiffré

Le trafic sFlow du pare-feu vers le collecteur n’est pas chiffré. Par conséquent, le collecteur doit être accessible via un réseau de gestion de confiance, un réseau de surveillance interne ou un chemin protégé d’une autre manière.

⚠️ sFlow ne doit pas être envoyé sans protection sur des réseaux non sécurisés. Les données de flux peuvent rendre visibles les adresses IP internes, les relations de communication et les systèmes cibles.

FastPath est désactivé sur l’interface surveillée

Lorsque sFlow est actif sur une interface, Fast Path est désactivé sur cette interface. Cela est particulièrement important pour les interfaces WAN, LAN ou Core fortement sollicitées.

Avant l’activation, il convient de vérifier :

• Quel est le niveau de charge de l’interface ?
• Du trafic à haut débit y circule-t-il ?
• Y a-t-il une fenêtre de maintenance pour le premier test ?
• Peut-on comparer la performance avant et après l’activation ?

Pour une compréhension de base des performances du pare-feu, l’article Comprendre correctement les données de performance de Sophos Firewall est approprié.

Cluster HA : sFlow fonctionne uniquement sur le Primary

Dans un cluster HA, l’agent sFlow fonctionne sur le Primary. Cela doit être pris en compte lors des évaluations et des tests de basculement. Après un changement de rôle, il convient de vérifier si le collecteur continue de recevoir des données et si l’IP de l’agent reste comme prévu.

Pour la planification de l’exploitation HA et de la surveillance, Configurer la haute disponibilité de Sophos Firewall est approprié.

Planification de l’interface et du collecteur

sFlow est configuré sur des interfaces matérielles. Les interfaces dépendantes telles que les alias et les VLANs de l’interface matérielle choisie peuvent également apparaître dans les échantillons. La sélection de l’interface doit donc toujours correspondre au chemin de trafic réel, et non seulement au nom du VLAN ou à l’évaluation souhaitée dans le collecteur.

Dans SFOS 22, l’agent utilise l’adresse IP d’une interface matérielle. Dans SFOS 23, il s’agit du choix automatique lorsqu’aucune IP d’agent n’est configurée avec agent-ip. Toutefois, l’aide SFOS 22 ne précise pas quelle adresse est choisie lorsque plusieurs interfaces conviennent. Ne déduisez donc pas l’IP de l’agent du routage ou du nom de l’interface. Après l’activation, relevez et documentez l’IP réellement reçue par le collecteur ; toute liste d’autorisation du collecteur doit tenir compte de cette observation.

Cela est pratique, mais peut conduire à des interprétations erronées :

• Si Port1 est surveillé, les interfaces VLAN ou alias associées peuvent également apparaître dans l’échantillonnage.
• Si seul un VLAN spécifique est d’intérêt, il doit être correctement filtré dans le collecteur.
• Si plusieurs ports Core ou WAN existent, il ne faut pas activer immédiatement toutes les interfaces.
• Dans les conceptions LAG, Bridge ou VLAN, il doit être clair au préalable où le trafic pertinent circule réellement.

La base propre pour cela est une planification compréhensible des interfaces et des zones. L’article Configurer les zones et interfaces de Sophos Firewall aide à classer les interfaces physiques, les VLANs, les ponts, les LAGs et RED.

Planification du pilote, de la confidentialité et du retour

Avant la première activation, sFlow doit être traité comme un changement de surveillance en production. La fonction génère des données supplémentaires, modifie FastPath sur l’interface surveillée et envoie des informations de flux à un autre système. Il ne suffit donc pas de saisir uniquement l’IP du collecteur et le taux d’échantillonnage.

Avant le pilote, ces points doivent être établis :

• Quel problème concret sFlow doit-il résoudre : planification de la capacité, pics de bande passante, surveillance de la sécurité ou recherche de pannes ?
• Qui gère le collecteur et qui peut voir les données de flux ?
• Combien de temps les données de flux seront-elles conservées ?
• Par quel chemin réseau les paquets sFlow atteignent-ils le collecteur ?
• Quelle interface sera testée en premier ?
• Quels indicateurs sont considérés comme une base avant l’activation ?
• Quand sFlow sera-t-il désactivé ou déplacé vers une autre interface ?

Les données de flux peuvent rendre visibles les adresses IP internes, les relations de communication, les systèmes cibles, les ports et le volume de trafic. Ces données sont donc moins détaillées qu’un Packet Capture complet, mais restent pertinentes pour l’exploitation et la sécurité. Si le collecteur est connecté à un SIEM ou à une plateforme de surveillance centrale, la responsabilité doit être aussi clairement définie que pour Envoyer les journaux Syslog de Sophos Firewall à un SIEM.

Pour le premier test, un pilote limité est judicieux :

1. Documenter l’état initial : charge de l’interface, charge CPU, services concernés, données de surveillance existantes.
2. Choisir une interface unique, non maximisée.
3. Définir un taux d’échantillonnage conservateur.
4. Vérifier la réception du collecteur et la quantité de données.
5. Observer la performance, la latence et le débit après l’activation.
6. Tester le retour : system sflow off ou retirer l’interface de surveillance.

Le retour doit être clair avant l’activation. Si les performances d’une interface de production se dégradent, ne modifiez pas simultanément le taux d’échantillonnage, le collecteur, le routage et les règles du pare-feu. Désactivez d’abord sFlow ou retirez l’interface concernée de la surveillance, puis mesurez à nouveau.

Pour un premier pilote avec les valeurs d’exemple sans modification de l’identité de l’agent, le retour arrière est le suivant. Ce bloc ne réinitialise pas une identité configurée avec agent-ip ; la limitation de l’étape facultative SFOS 23 reste applicable :

system sflow off
system sflow monitor delete interface-name Port1
system sflow collector delete ip-address 192.0.2.10 port 6343
system sflow polling-interval 60
system sflow show

Seules les entrées créées dans l’exemple sont supprimées et l’intervalle de sondage est rétabli à sa valeur par défaut documentée de 60 secondes. Si sFlow était déjà configuré, ce bloc n’est pas un retour arrière global. Supprimez uniquement vos ajouts, rétablissez l’intervalle de sondage et l’état activé/désactivé relevés auparavant avec system sflow show, puis exécutez de nouveau cette commande pour vérifier l’état final. Si SSH a été autorisé uniquement pour ce pilote, rétablissez également la Local service ACL ou la règle d’exception préalablement documentée sans supprimer les autres accès d’administration.

Ajouter un collecteur sFlow

Tout d’abord, le collecteur est défini. Si aucun autre port n’est prévu, sFlow utilise typiquement 6343. Sophos autorise des valeurs de port de 1 à 65535; le default documenté est 6343. Dans les environnements de production, le port doit tout de même correspondre au collecteur utilisé et aux règles de pare-feu sur le chemin.

Exemple :

system sflow collector add ip-address 192.0.2.10 port 6343

Sophos prend en charge jusqu’à cinq collecteurs. Chaque collecteur est ajouté séparément.

Le statut actuel peut ensuite être vérifié :

system sflow show

Pour supprimer un collecteur :

system sflow collector delete ip-address 192.0.2.10 port 6343

Facultatif : définir l’identité de l’agent dans SFOS 23

Cette étape concerne uniquement SFOS 23 ; le déroulement existant sous SFOS 22 reste inchangé. Avec agent-ip, on peut définir une IP unicast valide comme identité sFlow du pare-feu dans le collecteur. Une seule IP d’agent configurée est autorisée par pare-feu. Ce n’est pas l’adresse de destination du collecteur. Sans identité configurée, SFOS 23 utilise automatiquement une IP d’interface matérielle.

⚠️ Avant toute modification, sauvegardez la configuration initiale avec system sflow show, y compris toute IP d’agent existante. Une identité différente peut modifier l’attribution et les filtres d’identité du collecteur. Ne remplacez pas aveuglément une identité existante ; confirmez d’abord la procédure pour la version installée. La description SFOS 23 se contredit sur la suppression : le résumé de syntaxe exige une adresse IP, mais la description détaillée et l’exemple l’omettent. Aucun ordre de suppression ni retour arrière complet pour une identité nouvellement configurée n’est donc fourni ici. Si un retour fiable à l’identité automatique est nécessaire, ignorez cette étape facultative jusqu’à clarification faisant autorité de la syntaxe de suppression pour la version installée. system sflow off arrête l’exportation, mais ne prouve pas que l’identité précédente a été restaurée.

Uniquement après ces vérifications préalables et en l’absence d’identité déjà configurée, voici un exemple à adapter dans la Device Console :

system sflow show
system sflow agent-ip add 192.0.2.20
system sflow show

192.0.2.20 est une valeur de documentation : remplacez-la par une IP unicast valide destinée à identifier sans ambiguïté votre pare-feu dans le collecteur. 192.0.2.10 reste la destination distincte du collecteur dans cet exemple. L’identité de l’agent ne garantit ni l’adresse source UDP, ni le routage, ni l’affectation d’interface, ni le comportement des ACL de transport ; vérifiez le chemin réseau séparément.

Vérifiez la configuration après la modification puis, après l’activation, comparez l’IP d’agent réellement décodée dans les données sFlow par le collecteur à la valeur prévue. Adaptez les filtres d’identité uniquement sur la base de cette observation. En cas d’écart, vérifiez d’abord la configuration et le décodage du collecteur plutôt que d’improviser d’autres changements d’identité. Vérifiez à nouveau la réception et l’attribution après un basculement HA ; la stabilité de l’identité lors d’un changement de rôle n’est pas garantie.

Configurer l’interface et le taux d’échantillonnage

Ensuite, il est déterminé quelle interface sera surveillée et avec quel taux d’échantillonnage les paquets seront sélectionnés. Dans SFOS 22, l’agent sFlow utilise une IP d’interface matérielle ; dans SFOS 23, cela s’applique uniquement sans agent-ip configurée. Dans le collecteur, une IP d’interface matérielle peut donc apparaître même si l’analyse réelle concerne un VLAN ou un alias sous ce port.

Exemple :

system sflow monitor add interface-name Port1 sampling-rate 1000

Le taux d’échantillonnage détermine la fréquence à laquelle les paquets sont sélectionnés comme échantillons. Un nombre plus bas génère plus d’échantillons et donc plus de détails, mais aussi plus de charge et plus de données au collecteur. Un nombre plus élevé réduit la quantité de données, mais peut rendre les flux courts ou plus petits moins visibles.

Les valeurs limites pertinentes sont :

Pour commencer, une valeur conservatrice est judicieuse, par exemple 1000 ou plus. Ensuite, il convient de vérifier dans le collecteur si la quantité de données, le niveau de détail et la performance correspondent à l’objectif.

Une interface de surveillance peut être retirée :

system sflow monitor delete interface-name Port1

Régler l’intervalle de sondage

En plus de l’échantillonnage de paquets, sFlow peut également interroger des statistiques et des compteurs d’interface à un intervalle donné. Sophos permet un intervalle de sondage entre 30 et 300 secondes; le default est 60 secondes. Avec 0, le sondage est désactivé.

Exemple :

system sflow polling-interval 80

Désactiver le sondage :

system sflow polling-interval 0

Pour la plupart des environnements, un intervalle moyen est judicieux. Des intervalles trop courts génèrent plus de données et ne sont pas automatiquement plus utiles.

Activer sFlow

Lorsque le collecteur, l’interface et le sondage sont planifiés, sFlow est activé. Par défaut, sFlow est désactivé :

system sflow on

Vérifier le statut :

system sflow show

Désactiver sFlow :

system sflow off

Après l’activation, il ne faut pas seulement vérifier le pare-feu, mais aussi le collecteur. Les données de l’IP de l’agent du pare-feu doivent y arriver et être résolues de manière significative.

Validation après l’activation

Après l’activation, il convient de vérifier ces points :

1. system sflow show affiche correctement le collecteur, l’interface, le taux d’échantillonnage et le statut.
2. Le collecteur reçoit des données sFlow de l’IP de pare-feu attendue.
3. L’heure sur le pare-feu et le collecteur est correcte.
4. Les noms d’interface et la direction des flux sont traçables dans le collecteur.
5. La charge sur le pare-feu et le collecteur reste non critique.
6. La quantité de données correspond à la conservation et au traitement prévus.
7. Le retour défini a été testé une fois ou au moins documenté comme commande concrète.
8. Dans les clusters HA, après un basculement, il est vérifié si les données continuent d’arriver.

Si des règles de pare-feu, NAT, VPN ou TLS Inspection sont analysées en parallèle, sFlow ne doit pas être considéré isolément. Pour des décisions de connexion concrètes, le Log Viewer et le Packet Capture restent essentiels. Pour une évaluation à long terme, il convient de vérifier si Syslog ou Central Reporting est également nécessaire.

Dépannage

Aucun trafic dans le collecteur

Vérifiez d’abord system sflow show, puis l’IP du collecteur, le port et le chemin réseau. Sur le collecteur, recherchez des paquets sFlow rejetés ou un filtre basé sur une mauvaise IP d’agent. Si le pare-feu possède plusieurs adresses d’interface matérielle, ne présumez pas l’IP de l’agent.

Seule une partie du trafic est visible

sFlow fonctionne avec un échantillonnage. Il est normal que chaque paquet ne soit pas visible. Si des flux importants manquent, le taux d’échantillonnage peut être ajusté ou une autre interface choisie. Pour les VLANs et les alias, vérifiez si la bonne interface matérielle est surveillée.

La performance change après l’activation

Si une interface fortement utilisée est surveillée, la désactivation de FastPath peut être pertinente. Dans ce cas, sFlow doit être désactivé à titre de test et la performance comparée. Pour les interfaces Core ou WAN en production, un test planifié est préférable à une activation spontanée.

Les données HA semblent incomplètes

Dans les environnements HA, l’agent sFlow fonctionne sur le Primary. Après un basculement, il convient de vérifier quel pare-feu est actuellement Primary, quelle IP est utilisée comme IP de l’agent et si le collecteur continue d’attribuer correctement les données.

Liste de vérification opérationnelle

• Placer le collecteur dans un réseau sécurisé.
• Documenter le propriétaire, l’objectif, l’accès et la conservation des données de flux.
• Vérifier le port UDP et le routage vers le collecteur.
• Commencer avec une ou quelques interfaces.
• Capturer la ligne de base avant-après pour la charge de l’interface, le CPU, la latence et le débit.
• Choisir un taux d’échantillonnage conservateur et l’ajuster ensuite.
• Prendre en compte l’impact de FastPath sur les interfaces critiques.
• Documenter le retour : system sflow off ou retirer l’interface de surveillance.
• Tester le basculement HA si sFlow est utilisé dans le cluster.
• Comparer les données de flux avec le Log Viewer, le Packet Capture et le Reporting.
• Vérifier régulièrement si les données sont encore exploitées ou simplement collectées sans utilisation.

FAQ