Configurer la surveillance sFlow sur Sophos Firewall

Avec la surveillance sFlow, un Sophos Firewall peut envoyer des échantillons de trafic à un collecteur externe. Cela permet de mieux visualiser les pics de volume, les flux remarquables, les destinations inhabituelles ou la répartition de la charge sur les interfaces qu’avec de simples journaux en direct. Sophos a ajouté sFlow comme fonction de surveillance avec 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é.

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 l’interface WebAdmin normale, mais via la Device Console avec system sflow. La Advanced Shell n’est pas le bon endroit pour cela. La distinction entre Device Console et Advanced Shell est expliquée dans l’article Sophos Firewall Troubleshooting: Services et Logs.

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.

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 la performance sur une interface en production se dégrade, il ne faut pas modifier simultanément le taux d’échantillonnage, le collecteur, le routage et les règles du pare-feu. Désactiver d’abord sFlow ou retirer l’interface concernée de la surveillance avec system sflow monitor delete interface-name ..., puis mesurer à nouveau.

Ajouter un collecteur sFlow

Tout d’abord, le collecteur est défini. Le port standard pour sFlow est souvent 6343; dans les environnements de production, le port doit correspondre au collecteur utilisé.

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

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.

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

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. Ensuite, contrôlez si l’IP du collecteur, le port, le routage et les règles du pare-feu vers le collecteur sont corrects. De plus, vérifiez sur le collecteur si le port UDP est accessible et si les paquets sFlow entrants sont rejetés.

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