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.

NetFlow est donc rapide à configurer. Pour obtenir un résultat fiable, il faut toutefois savoir quelles données contient la version 5, quelle règle traite le flux de test et par quel chemin le pare-feu atteint 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 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 exporte NetFlow Version 5. 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.

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. Il faut donc vérifier séparément si le trafic utile IPv6 requis est représenté de manière pertinente dans l’environnement utilisé ; une adresse IPv6 du collecteur ne confirme pas la prise en charge des flux IPv6.

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 ; d’autres ports compris entre 1 et 65535 sont possibles 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.

⚠️ La configuration NetFlow ne propose aucune option TLS ou d’authentification. 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é.

Configurer le collecteur NetFlow

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

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 ?

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. Générer exactement une nouvelle connexion depuis le client de test, par exemple une requête HTTPS autorisée.
4. Vérifier dans Log Viewer si LAN_Test_to_WAN_HTTPS ou le Rule ID attendu s’est appliqué.
5. Sous Diagnostics > Packet capture, rechercher l’exportation avec dst host 192.0.2.50 and dst port 2055.
6. Vérifier dans le collecteur si un enregistrement v5 contenant les valeurs source et de destination attendues apparaît.

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. Le trafic utile IPv6 ne doit pas non plus être attendu uniquement parce que l’adresse du collecteur prend en charge IPv6.

L’adresse source est inattendue

L’interface NetFlow ne possède pas de sélecteur dédié pour la Source IP. L’adresse vue par le collecteur dépend donc du chemin du trafic système du pare-feu. Vérifier la route, l’interface de sortie et, le cas échéant, la configuration SD-WAN ou Source NAT existante pour le trafic système avant d’attribuer une adresse fixe dans le collecteur.

Basculement HA ou changement de firmware

Pour NetFlow, aucune exportation HA transparente ou sans doublons n’est garantie publiquement. Il faut donc vérifier, en fonctionnement normal et après un basculement contrôlé, que les enregistrements continuent d’arriver, quelle adresse source est visible et si le collecteur les attribue toujours au bon pare-feu.

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.

Questions fréquentes