NetFlow classique et l'analytique de flux s'appuient généralement sur des champs L3/L4 — IP source, IP destination, port, protocole et comptage de bytes. Ces données sont précieuses pour la capacité réseau et la direction du trafic, mais dans le trafic HTTP et API moderne, elles ne peuvent pas répondre seules à la question « que s'est-il passé ? ». Des centaines d'hôtes, chemins, méthodes et comportements applicatifs différents peuvent partager la même IP et le même port.
Les équipes opérationnelles et sécurité peuvent voir des volumes de trafic élevés sur l'écran du collecteur de flux, mais si elles ne peuvent pas voir quelle URL, méthode, code de statut ou contexte client a généré ce trafic, l'analyse reste incomplète. Le contexte L7 est requis pour la planification de capacité, l'analyse DDoS, le reporting de périmètre PCI DSS et l'audit au niveau des requêtes.
Combler cet écart avec une sonde de flux séparée ou une couche de collecteur externe est possible, mais cela ajoute du travail d'installation, une maintenance séparée, un modèle de haute disponibilité séparé et une surcharge de supervision séparée. Lorsque le trafic applicatif traverse déjà la couche ADC/WAAP, reproduire le même contexte en un point différent est opérationnellement inefficace.
La bonne approche consiste à produire les exports de flux au point de transit du trafic et à les livrer aux systèmes externes au format IPFIX / NetFlow standard. Les champs standard préservent la visibilité réseau tandis que les champs Enterprise IE ajoutent le contexte HTTP. Les systèmes d'analytique de flux peuvent alors répondre non seulement à « quelle IP a communiqué combien ? » mais aussi à « quel chemin, quelle réponse et quel contexte client étaient impliqués ? »
L'Export IPFIX / NetFlow Natif de TR7 combine les champs IPFIX standard avec les champs TR7 Enterprise IE, produisant des enregistrements de flux enrichis L7 à partir des phases de requête et de réponse.
TR7 retire l'export de flux du rôle d'une sonde externe et l'implémente comme couche d'observabilité intégrée dans le chemin de données ADC/WAAP.
Les éléments d'information standard et enterprise sont préparés par la bibliothèque intégrée. Le wrapper Lua collecte les valeurs requises depuis les phases de requête et de réponse et les convertit en enregistrements IPFIX.
Côté requête, l'hôte, le chemin, la requête, la méthode, les en-têtes et les données de bytes uploadés sont collectés. Côté réponse, le code de statut, le content-type de réponse, les bytes téléchargés et l'état de terminaison complètent l'enregistrement de flux.
Le format IPFIX v10 utilise des template sets et des template IDs pour définir les champs de flux pour les systèmes externes. Ce modèle permet aux collecteurs de parser correctement les champs et maintient la compatibilité avec les outils standard d'analytique de flux.
Sous le numéro d'entreprise TR7 57011, des champs personnalisés sont définis pour les comptages de bytes upload/download, la requête de la demande, X-Forwarded-For, Referer, Cookie, content-type de réponse et état de terminaison. Les données de flux classiques sont enrichies avec le contexte L7 via ce mécanisme.
L'export IPFIX / NetFlow combine les champs réseau standard avec le détail des requêtes/réponses HTTP, envoyant des enregistrements de flux enrichis aux systèmes collecteurs.
TR7 peut exporter sourceIPv4Address, destinationIPv4Address, sourceIPv6Address et destinationIPv6Address en utilisant des éléments d'information IPFIX standard. Le trafic IPv4 et IPv6 est visible dans le périmètre de l'analytique de flux. Les environnements dual-stack ne sont pas limités à une analyse IPv4 uniquement. La visibilité réseau source et destination est préservée côté collecteur via des champs standard.
Les champs sourceTransportPort et destinationTransportPort sont inclus dans l'enregistrement de flux. Ces champs sont importants dans l'analyse au niveau réseau pour les connexions clients, les ports VIP et l'accès aux services. Combinés au contexte HTTP, il devient possible de voir quel chemin applicatif s'exécute sur quel port. L'analyse de capacité et d'anomalie devient plus significative.
Des champs HTTP standard tels que httpRequestHost, httpRequestPath, httpRequestMethod et httpMessageVersion élèvent l'enregistrement de flux au niveau L7. Différents hôtes ou chemins arrivant sur la même IP et le même port peuvent être distingués. Cela fournit une visibilité critique dans les environnements de services virtuels et multi-applications. L'analytique de flux ne voit plus seulement la connexion — elle voit le contexte de la requête applicative.
Le champ httpStatusCode indique si la réponse était un succès, une redirection, une erreur client ou une erreur serveur. Les champs request content-type et response content-type aident à analyser le type de données transférées. Ces informations sont particulièrement précieuses pour l'analyse du taux d'erreurs, l'inspection du comportement API et l'investigation du trafic basée sur le type de données. Les tendances d'erreurs L7 peuvent être lues plus clairement sur le collecteur de flux.
Les champs httpUserAgent, httpReferrer et httpCookie permettent une analyse plus détaillée du comportement client. Ces champs peuvent être utilisés pour l'analyse de bots, l'inspection des flux utilisateurs et la différenciation des types de clients. Le champ Cookie peut contenir des données sensibles, la politique d'export doit donc être conçue avec soin. Il ne doit être activé que pour des environnements sécurisés et des cibles de collecteurs limitées si nécessaire.
Le TR7 Enterprise IE inclut les champs uploadedBytes et downloadedBytes. Ces champs permettent de mesurer le volume du corps de la requête et du corps de la réponse au niveau du flux. Non seulement le comptage total de bytes de connexion mais aussi le flux de données applicatif directionnel peuvent être analysés. Cette visibilité est précieuse dans des cas tels que les uploads importants, les téléchargements anormaux ou les suspicions d'exfiltration de données.
Le champ httpRequestQuery ajoute les paramètres de requête au-delà du chemin dans l'enregistrement de flux. Le champ httpXForwardedFor aide à analyser la véritable IP client derrière une chaîne de proxy. Les deux champs sont particulièrement utiles lors de la corrélation des logs applicatifs avec les enregistrements de flux. Le contexte de la requête devient plus complet dans les investigations de sécurité et de conformité.
Le champ httpTerminationStateCode fournit un signal supplémentaire sur la façon dont la connexion s'est terminée. La fermeture normale, l'erreur, l'interruption ou la terminaison inattendue peuvent être différenciées dans l'analytique de flux. Ces informations aident à l'évaluation conjointe des problèmes au niveau réseau et applicatif. C'est un champ précieux pour les équipes SRE lors de l'analyse des causes profondes d'erreurs.
Les champs Enterprise IE sont définis sous le numéro d'entreprise TR7 57011. Cette structure ne brise pas la compatibilité IPFIX standard ; elle porte les champs personnalisés de manière clairement parsable. Lorsque le côté collecteur est configuré pour reconnaître ces champs, les détails L7 deviennent disponibles dans les tableaux de bord de flux. Les champs standard et personnalisés sont combinés dans le même enregistrement d'export.
L'approche d'export de TR7 est construite sur IPFIX v10 et prend en charge un chemin rétrocompatible NetFlow v9. Cela rend l'intégration avec les collecteurs de flux et les investissements en visibilité réseau existants des organisations simple. Plutôt que d'apprendre un nouveau format de log personnalisé, l'écosystème de flux standard peut être utilisé. L'enrichissement L7 arrive comme couche de valeur ajoutée de TR7.
L'export IPFIX / NetFlow est exploité conjointement avec la structure des templates, les champs enterprise, le comportement de transport, l'ordre des bytes et les dépendances de build.
La valeur de version IPFIX est 10. Le Template Set ID est 2 et le Template ID est 256. Ce template informe le collecteur des champs qui arriveront et dans quel ordre.
L'en-tête IPFIX se compose des champs version, length, exportTime, sequenceNumber et observationDomainId. La longueur totale de l'en-tête est de 16 bytes. Cette structure fournit le cadre de base pour la compatibilité standard avec les collecteurs IPFIX.
Les éléments d'information personnalisés TR7 sont portés sous le numéro d'entreprise 57011. Les champs uploadedBytes, downloadedBytes, httpRequestQuery, httpXForwardedFor, httpReferrer, httpCookie, httpResponseContentType et httpTerminationStateCode sont définis dans ce périmètre. Les champs L7 non standard sont explicitement différenciés via ce mécanisme.
Le transport par défaut pour l'export est UDP. Le port du collecteur est configurable sur des valeurs telles que 4779 ou 2055 selon les exigences de l'environnement. UDP est un modèle de transport à faible surcharge et largement utilisé pour les flux ; pour les environnements nécessitant des garanties de livraison, l'architecture du collecteur doit être planifiée en conséquence.
Les champs multi-bytes sont transmis en utilisant l'ordre des bytes réseau. Ce comportement est critique pour le parsing correct des champs de port, longueur, template et compteur. La compatibilité du collecteur dépend largement de cet encodage standard.
La bibliothèque C intégrée est compilée comme bibliothèque partagée pour l'intégration Lua. L'environnement de build nécessite les packages de développement Lua, pkg-config et les outils de compilation. La bibliothèque résultante est appelée par le wrapper Lua pour produire des enregistrements de flux.
Un fournisseur de services recevant l'export IPFIX depuis TR7 peut consulter les détails d'hôte HTTP, de chemin et de code de statut dans son système d'analytique de flux existant. L'analyse classique IP/port est étendue avec le contexte L7. L'investigation de capacité et d'anomalie devient plus significative.
Les institutions financières peuvent exporter chaque requête HTTP comme enregistrement de flux vers des systèmes externes. Les champs hôte, chemin, méthode, code de statut et bytes peuvent être corrélés avec un SIEM ou un collecteur de flux. Les questions d'audit sur le trafic qui a transité par quel chemin applicatif sont répondues plus clairement.
Les équipes sécurité peuvent utiliser les valeurs de bytes uploadés/téléchargés et la distribution des codes de statut HTTP des enregistrements de flux pour la détection d'anomalies. Des uploads soudainement élevés, des téléchargements anormaux ou des patterns denses de 4xx/5xx peuvent être supervisés au niveau du collecteur. TR7 porte les signaux L7 vers la couche de flux pour l'analyse d'attaques.
Les chemins applicatifs dans le périmètre des données de titulaires de cartes peuvent être tracés avec le contexte hôte et URL à l'intérieur de l'export de flux. Les équipes d'audit reçoivent des preuves de trafic basées sur le chemin HTTP pertinent plutôt que simplement IP/port. Cela renforce les processus de détermination du périmètre et de création de piste d'audit.
Les équipes opérationnelles peuvent visualiser le volume de trafic par chemin HTTP plutôt que par IP/port seul dans leur système d'analytique de flux existant. Quel endpoint supporte quelle charge peut être analysé plus en détail. Cette visibilité soutient la planification des ressources et les décisions de croissance.
Export natif compatible IPFIX v10 et NetFlow v9 — enregistrements de flux enrichis HTTP sans sonde séparée. Effectuons une démonstration en direct sur votre propre infrastructure de collecteur.