Configurer et tester NetFlow sur Sophos Firewall

Avec NetFlow, Sophos Firewall envoie les métadonnées des connexions à un collecteur de flux externe. Il devient ainsi possible d’analyser dans le temps les relations de communication, le volume de trafic et les connexions suspectes. Le prérequis le plus important est facile à oublier : seul le trafic des règles de pare-feu pour lesquelles Log firewall traffic est activé est exporté.

La procédure rapide est la suivante :

1. Préparer un listener NetFlow v5 sur le collecteur, par exemple sur UDP 2055.
2. Ajouter le collecteur sous System > Administration > Netflow.
3. Activer Log firewall traffic dans la règle de pare-feu concernée.
4. Générer un flux de test clairement documenté.
5. Contrôler séparément le transport avec Packet Capture et le contenu dans le collecteur.

Un résultat fiable exige que trois éléments concordent : les champs de la version 5, la règle de pare-feu réellement appliquée et le chemin réseau vers le collecteur.

Quand NetFlow est-il l’outil approprié ?

NetFlow convient lorsqu’un collecteur doit stocker les Flow Records des connexions traitées par des règles journalisées et les analyser dans le temps. Les questions typiques sont les suivantes : quelles adresses source et de destination communiquent entre elles, quels ports sont utilisés et combien de paquets ou d’octets appartiennent au flux ?

D’autres outils répondent à d’autres questions :

• Surveillance sFlow échantillonne le trafic et les compteurs d’interface de certaines interfaces matérielles. Elle convient particulièrement à l’analyse des modèles de trafic et à la surveillance de la capacité.
• Syslog vers un SIEM transporte les événements de journal du pare-feu, du VPN, de l’IPS et d’autres fonctions avec des champs propres au produit.
• Surveillance matérielle SNMP surveille le matériel, les interfaces, la température, les ventilateurs ou les alimentations.
• Central Firewall Reporting fournit les rapports, la recherche et la conservation propres à Sophos dans Sophos Fusion (anciennement Sophos Central).
• Packet Capture reste plus précis pour un chemin de paquets particulier, NAT ou une erreur de connexion.

NetFlow ne remplace pas ces outils. Le collecteur signale souvent un flux suspect, puis Log Viewer ou Packet Capture permet de déterminer quelle règle, décision NAT ou fonction de sécurité est intervenue.

Ce que montre NetFlow v5 – et ce qu’il ne montre pas

SFOS 22 et SFOS 23 documentent NetFlow Version 5 et la possibilité d’exporter tous les paramètres v5. Cette capacité documentée ne confirme pas que chaque champ contient une valeur pertinente pour chaque flux ; il faut le vérifier dans les enregistrements effectivement reçus. Un enregistrement v5 peut notamment contenir les valeurs suivantes :

• adresse IPv4 source et de destination ;
• port source et de destination ainsi que protocole IP ;
• compteurs de paquets et d’octets ;
• heure de début et de fin du flux ;
• interface d’entrée et de sortie sous forme d’ifIndex ;
• TCP flags, ToS ainsi que des informations AS et de préfixe.

En revanche, NetFlow v5 ne contient aucun champ natif pour le nom d’utilisateur, le Firewall Rule ID, l’URL, l’application ou le contenu des paquets. Un collecteur peut corréler les adresses IP avec d’autres sources de données, mais ces informations ne proviennent pas directement de l’enregistrement v5.

L’aide Sophos indique également que l’objectif est d’identifier les protocoles, les politiques, les interfaces et les utilisateurs qui consomment beaucoup de bande passante. Les protocoles et les indices d’interface peuvent être analysés à partir des enregistrements v5 ; l’attribution à une politique ou à un utilisateur nécessite des données supplémentaires issues des journaux ou de l’inventaire. Sophos cite PRTG et Open Source Data Analyzer comme exemples d’outils d’analyse des rapports, et non comme une liste exhaustive de compatibilité.

Dans SFOS, l’adresse du collecteur peut être saisie sous forme d’adresse IPv4, d’adresse IPv6 ou de FQDN. Cela ne modifie pas le format d’exportation : le pare-feu continue d’envoyer NetFlow v5. Ce format ne comporte aucun champ pour les adresses IPv6 source et de destination. Une adresse IPv6 du collecteur concerne donc uniquement le transport vers celui-ci ; elle ne permet pas de représenter le trafic utile IPv6 sous forme de flux IPv6 natifs.

Note sur l’API : La référence Configure Netflow de SFOS 23 documente pour NetflowServer les types de données IPADDRESS et DOMAIN ainsi qu’un maximum de 255 caractères. La référence de SFOS 22 mentionne également STRING et ne précise pas de longueur maximale pour ce champ. Il s’agit d’une différence entre les métadonnées documentées de l’API, et non d’une preuve d’acceptation illimitée dans SFOS 22 ou de valeurs désormais rejetées dans SFOS 23. Cela ne permet de conclure ni à une validation dans WebAdmin ni à un comportement testé à l’exécution.

Préparer le collecteur et le chemin réseau

Avant de configurer le pare-feu, le collecteur doit disposer d’un listener NetFlow v5 actif. Sophos utilise UDP 2055 par défaut ; un autre port UDP valide peut être utilisé si le pare-feu et le collecteur sont configurés de manière identique. Il est possible d’enregistrer jusqu’à cinq serveurs NetFlow.

L’exemple utilise les valeurs suivantes :

• Nom du collecteur : flow-collector-primary
• Adresse du collecteur : 192.0.2.50
• Transport : UDP
• Port du collecteur : 2055
• Règle de test : LAN_Test_to_WAN_HTTPS

192.0.2.50 est une adresse réservée à la documentation et ne peut pas servir de véritable collecteur. Dans cet exemple, elle indique uniquement le champ concerné. Il faut saisir l’adresse IP réelle ou le FQDN du collecteur sur lequel le listener v5 fonctionne et que le pare-feu peut atteindre par le chemin réseau prévu. Les points suivants doivent être clarifiés au préalable :

• Le collecteur prend en charge NetFlow v5 et écoute réellement sur UDP 2055.
• Le pare-feu dispose d’une route vers le collecteur ; avec un FQDN, le DNS doit également fonctionner.
• Les composants intermédiaires et le pare-feu hôte du collecteur autorisent le port UDP.
• Le collecteur attribue l’adresse source effectivement utilisée au bon pare-feu.
• L’objectif, les droits d’accès et la durée de conservation des données de flux sont définis.

L’exportation NetFlow est un trafic système généré par le pare-feu. Une règle de pare-feu client ne contrôle pas cette exportation. Les éléments pertinents sont le chemin du trafic système, le routage, le DNS avec un FQDN et les filtres entre le pare-feu et le collecteur.

⚠️ Les références NetFlow examinées ne décrivent pas de paramètres TLS ou d’authentification et ne constituent pas un inventaire exhaustif des options disponibles. Les données de flux peuvent révéler des adresses internes, des partenaires de communication, des ports, des horaires et des volumes. Le collecteur devrait donc être accessible via un réseau de management fiable ou un chemin VPN protégé.

Exemple : préparer PRTG comme collecteur

Dans PRTG, c’est la Probe qui reçoit les flux, et non automatiquement le serveur web central. L’exemple suivant suppose qu’une Probe locale ou distante existe déjà. Le capteur NetFlow v5 ne prend pas en charge les Probes de cluster ; avec PRTG Hosted Monitor, une Probe distante est nécessaire.

1. Ajouter un capteur NetFlow v5 sur la Probe prévue.
2. Saisir 2055 sous Receive Packets on UDP Port.
3. Sous Receive Packets on IP Address, sélectionner l’adresse réelle de la Probe qui sera renseignée dans SFOS comme destination du collecteur.
4. Sous Sender IP Address, saisir l’adresse source réellement observée pour l’exportation du pare-feu. Si ce champ est vide, les données de n’importe quel émetteur sont acceptées sur ce port ; ce n’est donc pas une solution de remplacement durable appropriée à une attribution correcte.
5. Pour le premier test, laisser Include Filter et Exclude Filter vides afin qu’aucun filtre du collecteur ne masque le flux de référence. Sur l’hôte de la Probe, autoriser la réception uniquement depuis les exportateurs nécessaires.

Après le test d’exportation, comparer Top Talkers, Top Connections et Top Protocols aux valeurs de test notées. Si des paquets UDP arrivent sur l’hôte de la Probe, mais qu’aucun résultat d’analyse n’apparaît, vérifier d’abord l’adresse de réception, le filtre des émetteurs et les filtres d’inclusion et d’exclusion. Le statut Unknown peut apparaître après l’expiration de Active Flow Timeout (Minutes) si aucune nouvelle donnée de flux n’est reçue. À lui seul, il ne prouve pas une erreur du pare-feu ; aucun délai d’expiration d’exportation non confirmé n’est prescrit ici pour SFOS.

Configurer le collecteur NetFlow

1. Ouvrir System > Administration > Netflow dans WebAdmin.
2. Cliquer sur Add.
3. Saisir flow-collector-primary sous Server name.
4. Saisir 192.0.2.50 sous Netflow server IP/domain.
5. Saisir 2055 sous Netflow server port.
6. Enregistrer avec Save.

Les entrées de serveurs NetFlow existantes peuvent également être mises à jour. Après une modification, répéter le test contrôlé d’exportation décrit ci-dessous : vérifier séparément la correspondance de la règle, le transport UDP et le décodage v5.

L’interface ne propose aucun test de connexion documenté. Une entrée enregistrée confirme donc uniquement la configuration, et non le transport ni le décodage dans le collecteur.

Activer Rule Logging comme source de données

NetFlow exporte uniquement les connexions des règles de pare-feu pour lesquelles Log firewall traffic est activé. Ce paramètre se vérifie dans la règle concernée sous Rules and policies > Firewall rules.

Pour le premier test, il convient d’utiliser une règle clairement délimitée. Dans l’exemple, LAN_Test_to_WAN_HTTPS traite un test HTTPS d’un client connu vers une destination autorisée. Le nom de l’exemple n’est pas important ; l’administrateur doit surtout pouvoir identifier sans ambiguïté dans Log Viewer la règle qui traite réellement le flux.

Créer correctement des règles Sophos Firewall explique comment structurer et journaliser proprement une règle. En cas de doute sur la correspondance, Tester une règle avec Log Viewer, Policy Tester et Packet Capture peut aider.

Tester l’exportation de manière contrôlée

Le test sépare trois questions : la bonne règle s’est-elle appliquée, un paquet UDP quitte-t-il le pare-feu et le collecteur peut-il lire le contenu comme NetFlow v5 ?

Avant de commencer, définir une fenêtre d’observation finie adaptée à l’environnement local et noter son heure de fin. Les sources examinées ne précisent aucun calendrier d’exportation SFOS ; l’observation de l’exportation peut être retardée après la fin de la connexion. Pendant cette fenêtre, surveiller l’état de la capture, l’occupation du tampon et le traitement dans le collecteur. La capture WebAdmin dispose d’un tampon de 2048 KB et s’arrête automatiquement lorsqu’il est plein, sauf si Wrap capture buffer once full est activé. Cette option permet de poursuivre la capture, mais écrase les anciens paquets. Sauvegarder les éléments nécessaires avant leur perte et ne pas considérer une capture arrêtée prématurément ou écrasée comme une observation continue.

1. Vérifier dans le collecteur que le listener v5 fonctionne sur UDP 2055.
2. Noter l’heure, le client de test, l’adresse de destination, le port de destination et la règle de pare-feu attendue.
3. Sous Diagnostics > Packet capture, cliquer sur Configure, saisir dst host 192.0.2.50 and dst port 2055 sous Enter BPF string, cliquer sur Save, puis lancer la capture avec Trace On.
4. Générer un seul flux de test identifiable et limité depuis le client, par exemple une requête HTTPS autorisée, et terminer la connexion lorsque c’est possible. Noter son heure de fin.
5. Vérifier dans Log Viewer si LAN_Test_to_WAN_HTTPS ou le Rule ID attendu s’est appliqué.
6. Poursuivre l’observation jusqu’à l’heure de fin prévue et rechercher les paquets UDP destinés au collecteur ; arrêter ensuite la capture avec Trace Off.
7. Pendant la même fenêtre, vérifier si un enregistrement v5 contenant les valeurs source et de destination attendues apparaît dans le collecteur et noter le résultat. L’absence de données dans une fenêtre courte n’est pas concluante sans connaître les délais d’exportation ; elle ne prouve pas à elle seule un défaut d’exportation.

Pour un contrôle supplémentaire en lecture seule, une courte capture peut être lancée dans la Device Console :

tcpdump 'host 192.0.2.50 and port 2055'

Remplacer 192.0.2.50 et 2055 par le collecteur et le port réels. Arrêter la capture avec Ctrl+C. Les paquets UDP visibles confirment le transport jusqu’à l’interface observée, mais pas encore que le collecteur décode les enregistrements en version 5.

Un test réussi n’est complet que si la correspondance de la règle, le transport UDP et le décodage v5 concordent. Il reste ainsi possible d’identifier l’étape à laquelle une erreur se produit.

Isoler les flux manquants ou incomplets

Aucun paquet UDP vers l’adresse du collecteur

Vérifier l’adresse et le port du collecteur sous System > Administration > Netflow. Contrôler ensuite le DNS avec un FQDN, la route, l’interface de sortie et les filtres des composants intermédiaires. Le pare-feu hôte du collecteur doit également accepter UDP 2055.

Si d’autres règles ou chemins de routage sont modifiés simultanément, le résultat devient difficile à attribuer. Il faut donc commencer avec une règle journalisée connue et un seul flux de test.

Les paquets UDP arrivent, mais le collecteur n’affiche rien

Le listener doit traiter explicitement NetFlow v5. Une entrée configurée uniquement pour NetFlow v9, IPFIX ou sFlow peut recevoir les paquets UDP sans pour autant afficher de flux exploitables. Vérifier les journaux du collecteur, l’analyseur et l’adresse source attendue.

Dans ce cas, Packet Capture prouve uniquement le transport. Le décodage réussi doit être visible dans le collecteur lui-même.

Seule une partie des connexions est visible

Commencer par vérifier quelle règle de pare-feu traite réellement le trafic manquant et si Log firewall traffic y est activé. Une autre règle peut s’appliquer plus haut que prévu. La perte de paquets UDP peut également provoquer des lacunes.

NetFlow v5 présente des limites techniques. L’absence de noms d’utilisateur, de Rule IDs, d’URL ou de noms d’application ne constitue pas une erreur d’exportation. Ce format ne peut pas non plus représenter le trafic utile IPv6 avec des adresses IPv6 source et de destination natives ; une adresse IPv6 du collecteur n’y change rien.

L’adresse source est inattendue

Les références NetFlow examinées ne décrivent pas de paramètre dédié à l’adresse source de l’exportation. Une Packet Capture limitée dans le temps montre l’adresse réellement utilisée lorsque des paquets d’exportation sont observés. La comparer à l’attribution et aux filtres d’entrée du collecteur ; en cas d’écart, contrôler ensuite la route et l’interface de sortie.

Basculement HA ou changement de firmware

Les références examinées n’établissent pas de garantie d’exportation NetFlow sans interruption ou sans doublons lors d’un basculement HA. Effectuer un basculement uniquement dans le cadre d’un exercice opérationnel planifié et autorisé. Avant, en fonctionnement normal, puis après, utiliser le même test limité pour vérifier la réception des enregistrements, les lacunes ou doublons, l’adresse source et l’attribution au bon pare-feu. Il s’agit de consignes de vérification, et non du compte rendu d’un test HA effectué.

Après toute modification du firmware, du routage, du DNS, du collecteur ou des règles, le même test documenté doit être répété. Un court flux de référence est plus fiable que de supposer qu’une entrée NetFlow enregistrée fonctionne toujours.

Exploitation et protection des données

Comme les journaux du pare-feu, les données NetFlow doivent avoir un responsable et une durée de conservation définie. L’exploitation doit au minimum couvrir les points suivants :

• surveiller la réception par le collecteur pour chaque pare-feu et signaler les pannes ;
• documenter les adresses source, l’attribution des interfaces et la synchronisation horaire ;
• limiter l’accès aux métadonnées de communication internes ;
• définir la conservation et la suppression dans le collecteur ;
• effectuer un nouveau test après toute modification du routage, de la HA, du firmware ou de Rule Logging ;
• vérifier les flux suspects avec Log Viewer ou Packet Capture.

NetFlow met en évidence des relations dans le temps, mais ne prouve pas la cause d’une connexion bloquée ou lente. Pour une session précise, le Rule ID, le NAT ID, le chemin des paquets et les fonctions de sécurité impliquées restent déterminants.

Annuler la modification

Pour arrêter l’exportation, supprimer le serveur concerné sous System > Administration > Netflow. Vérifier ensuite, avec le même filtre Packet Capture précis, qu’aucun paquet UDP n’est plus envoyé à ce collecteur. Log firewall traffic ne doit être rétabli que dans son état précédent : sa désactivation arrête NetFlow pour cette règle, mais empêche aussi les futures entrées correspondantes dans le journal du pare-feu.

Questions fréquentes