Klassisches NetFlow und Flow-Analytics stützen sich typischerweise auf L3/L4-Felder — Quell-IP, Ziel-IP, Port, Protokoll und Byte-Anzahl. Diese Daten sind wertvoll für Netzwerkkapazität und Traffic-Richtung, können aber bei modernem HTTP- und API-Traffic die Frage "Was ist passiert?" allein nicht beantworten. Hunderte verschiedener Hosts, Pfade, Methoden und Anwendungsverhalten können dieselbe IP und denselben Port teilen.
Operations- und Sicherheitsteams können auf dem Flow-Collector-Bildschirm hohe Traffic-Volumina sehen, aber wenn sie nicht erkennen können, welche URL, welche Methode, welcher Status-Code oder welcher Client-Kontext diesen Traffic erzeugt hat, bleibt die Analyse unvollständig. L7-Kontext ist für Kapazitätsplanung, DDoS-Analyse, PCI-Scope-Reporting und Anfrage-Level-Audit erforderlich.
Diese Lücke mit einer separaten Flow-Probe oder einer externen Collector-Schicht zu schließen ist möglich, fügt aber Installationsarbeit, separate Wartung, ein separates Hochverfügbarkeitsmodell und separaten Monitoring-Overhead hinzu. Wenn Anwendungs-Traffic bereits die ADC/WAAP-Schicht durchläuft, ist das Reproduzieren desselben Kontexts an einem anderen Punkt operativ ineffizient.
Der richtige Ansatz besteht darin, Flow-Exporte am Traffic-Transitpunkt zu produzieren und sie an externe Systeme im Standard-IPFIX / NetFlow-Format zu liefern. Standard-Felder bewahren die Netzwerk-Sichtbarkeit, während Enterprise-IE-Felder HTTP-Kontext hinzufügen. Flow-Analytics-Systeme können dann nicht nur "Welche IP hat wie viel kommuniziert?" beantworten, sondern auch "Welcher Pfad, welche Antwort und welcher Client-Kontext war beteiligt?"
TR7 Nativer IPFIX / NetFlow-Export kombiniert Standard-IPFIX-Felder mit TR7-Enterprise-IE-Feldern und produziert L7-angereicherte Flow-Datensätze aus beiden Anfrage- und Antwortphasen.
TR7 entfernt Flow-Export aus der Rolle einer externen Probe und implementiert ihn als eingebaute Observabilitätsschicht innerhalb des ADC/WAAP-Datenpfads.
Standard- und Enterprise-Informationselemente werden von der eingebauten Bibliothek vorbereitet. Der Lua-Wrapper sammelt die erforderlichen Werte aus der Anfrage- und Antwortphase und konvertiert sie in IPFIX-Datensätze.
Auf der Anforderungsseite werden Host, Pfad, Abfrage, Methode, Header und hochgeladene Byte-Daten gesammelt. Auf der Antwortseite vervollständigen Status-Code, Antwort-Content-Type, heruntergeladene Bytes und Terminierungsstatus den Flow-Datensatz.
Das IPFIX v10-Format verwendet Template-Sets und Template-IDs, um Flow-Felder für externe Systeme zu definieren. Dieses Modell ermöglicht Collectoren, Felder korrekt zu parsen, und erhält die Kompatibilität mit Standard-Flow-Analytics-Tools.
Unter TR7-Enterprise-Nummer 57011 sind benutzerdefinierte Felder für Upload/Download-Byte-Anzahlen, Anfrage-Abfrage, X-Forwarded-For, Referer, Cookie, Antwort-Content-Type und Terminierungsstatus definiert. Klassische Flow-Daten werden durch diesen Mechanismus mit L7-Kontext angereichert.
IPFIX / NetFlow-Export kombiniert Standard-Netzwerkfelder mit HTTP-Anfrage-/Antwort-Details und sendet angereicherte Flow-Datensätze an Collector-Systeme.
TR7 kann sourceIPv4Address, destinationIPv4Address, sourceIPv6Address und destinationIPv6Address mit Standard-IPFIX-Informationselementen exportieren. Sowohl IPv4- als auch IPv6-Traffic sind im Flow-Analytics-Bereich sichtbar. Dual-Stack-Umgebungen sind nicht auf reine IPv4-Analyse beschränkt. Quell- und Ziel-Netzwerksichtbarkeit wird auf der Collector-Seite durch Standard-Felder bewahrt.
Die Felder sourceTransportPort und destinationTransportPort sind im Flow-Datensatz enthalten. Diese Felder sind in der Netzwerk-Level-Analyse für Client-Verbindungen, VIP-Ports und Service-Zugriff wichtig. Kombiniert mit HTTP-Kontext wird es möglich zu sehen, welcher Anwendungspfad über welchen Port läuft. Kapazitäts- und Anomalie-Analyse wird aussagekräftiger.
Standard-HTTP-Felder wie httpRequestHost, httpRequestPath, httpRequestMethod und httpMessageVersion heben den Flow-Datensatz auf L7-Ebene. Verschiedene Hosts oder Pfade, die auf derselben IP und demselben Port ankommen, können unterschieden werden. Dies liefert kritische Sichtbarkeit in virtuellen Service- und Multi-Anwendungsumgebungen. Flow-Analytics sieht nicht mehr nur die Verbindung — es sieht den Kontext der Anwendungsanfrage.
Das httpStatusCode-Feld zeigt an, ob die Antwort ein Erfolg, eine Weiterleitung, ein Client-Fehler oder ein Server-Fehler war. Die Anfrage-Content-Type- und Antwort-Content-Type-Felder helfen bei der Analyse des übertragenen Datentyps. Diese Informationen sind besonders wertvoll für Fehlerrate-Analyse, API-Verhaltensinspektion und datentyp-basierte Traffic-Untersuchung. L7-Fehlertrends können auf dem Flow-Collector klarer abgelesen werden.
Die Felder httpUserAgent, httpReferrer und httpCookie ermöglichen eine detailliertere Analyse des Client-Verhaltens. Diese Felder können für Bot-Analyse, User-Flow-Inspektion und Client-Typ-Unterscheidung verwendet werden. Das Cookie-Feld kann sensible Daten enthalten, daher sollte die Export-Policy sorgfältig gestaltet werden. Es sollte nur für sichere Umgebungen und begrenzte Collector-Ziele bei Bedarf aktiviert werden.
Das TR7-Enterprise-IE umfasst uploadedBytes- und downloadedBytes-Felder. Diese Felder ermöglichen es, das Anfrage-Body- und Antwort-Body-Volumen auf Flow-Ebene zu messen. Nicht nur die gesamte Verbindungs-Byte-Anzahl, sondern der gerichtete Anwendungsdatenfluss kann analysiert werden. Diese Sichtbarkeit ist in Fällen wie großen Uploads, abnormalen Downloads oder vermutetem Daten-Exfiltration wertvoll.
Das httpRequestQuery-Feld fügt Abfrageparameter über den Pfad hinaus dem Flow-Datensatz hinzu. Das httpXForwardedFor-Feld hilft dabei, die echte Client-IP hinter einer Proxy-Kette zu analysieren. Beide Felder sind besonders nützlich bei der Korrelation von Anwendungs-Logs mit Flow-Datensätzen. Der Anfrage-Kontext wird in Sicherheits- und Compliance-Untersuchungen vollständiger.
Das httpTerminationStateCode-Feld liefert ein zusätzliches Signal darüber, wie die Verbindung beendet wurde. Normales Schließen, Fehler, Unterbrechung oder unerwartete Beendigung können in der Flow-Analytics unterschieden werden. Diese Information hilft bei der gemeinsamen Bewertung von Netzwerk- und Anwendungsebene-Problemen. Es ist ein wertvolles Feld für SRE-Teams bei der Fehlerursachen-Analyse.
Enterprise-IE-Felder sind unter TR7-Enterprise-Nummer 57011 definiert. Diese Struktur bricht die Standard-IPFIX-Kompatibilität nicht; sie trägt benutzerdefinierte Felder auf klar parseable Weise. Wenn die Collector-Seite so konfiguriert ist, diese Felder zu erkennen, werden L7-Details in Flow-Dashboards verfügbar. Standard- und benutzerdefinierte Felder werden im selben Export-Datensatz kombiniert.
TR7s Export-Ansatz ist auf IPFIX v10 aufgebaut und unterstützt einen NetFlow v9-abwärtskompatiblen Pfad. Dies erleichtert die Integration mit den bestehenden Flow-Collector- und Netzwerksichtbarkeits-Investitionen der Organisationen. Statt ein neues benutzerdefiniertes Log-Format zu erlernen, kann das Standard-Flow-Ökosystem verwendet werden. L7-Anreicherung kommt als zusätzliche Wertschicht von TR7.
IPFIX / NetFlow-Export wird zusammen mit Template-Struktur, Enterprise-Feldern, Transport-Verhalten, Byte-Reihenfolge und Build-Abhängigkeiten betrieben.
Der IPFIX-Versionswert ist 10. Template-Set-ID ist 2 und Template-ID ist 256. Dieses Template informiert den Collector, welche Felder in welcher Reihenfolge ankommen werden.
Der IPFIX-Header besteht aus den Feldern version, length, exportTime, sequenceNumber und observationDomainId. Die gesamte Header-Länge beträgt 16 Bytes. Diese Struktur liefert den Basisrahmen für Standard-IPFIX-Collector-Kompatibilität.
TR7-benutzerdefinierte Informationselemente werden unter Enterprise-Nummer 57011 geführt. Die Felder uploadedBytes, downloadedBytes, httpRequestQuery, httpXForwardedFor, httpReferrer, httpCookie, httpResponseContentType und httpTerminationStateCode sind in diesem Bereich definiert. Nicht-Standard-L7-Felder werden durch diesen Mechanismus explizit unterschieden.
Der Standard-Transport für den Export ist UDP. Der Collector-Port kann je nach Umgebungsanforderungen auf Werte wie 4779 oder 2055 konfiguriert werden. UDP ist ein ressourcenschonendes und weit verbreitetes Flow-Transport-Modell; für Umgebungen, die Zustellgarantien erfordern, sollte die Collector-Architektur entsprechend geplant werden.
Multi-Byte-Felder werden in Netzwerk-Byte-Reihenfolge übertragen. Dieses Verhalten ist kritisch für die korrekte Analyse von Port-, Längen-, Template- und Zählerfeldern. Collector-Kompatibilität hängt stark von dieser Standard-Kodierung ab.
Die eingebaute C-Bibliothek wird als Shared Library für Lua-Integration kompiliert. Die Build-Umgebung erfordert Lua-Entwicklungspakete, pkg-config und Kompilierungstools. Die resultierende Bibliothek wird vom Lua-Wrapper aufgerufen, um Flow-Datensätze zu produzieren.
Ein Service-Provider, der IPFIX-Export von TR7 empfängt, kann HTTP-Host-, Pfad- und Status-Code-Details in seinem bestehenden Flow-Analytics-System anzeigen. Klassische IP/Port-Analyse wird mit L7-Kontext erweitert. Kapazitäts- und Anomalie-Untersuchung wird aussagekräftiger.
Finanzinstitute können jede HTTP-Anfrage als Flow-Datensatz in externe Systeme exportieren. Host-, Pfad-, Methode-, Status-Code- und Byte-Felder können mit einem SIEM oder Flow-Collector korreliert werden. Audit-Fragen darüber, welcher Traffic durch welchen Anwendungspfad geflossen ist, werden klarer beantwortet.
Sicherheitsteams können Upload/Download-Byte-Werte und HTTP-Status-Code-Verteilung aus Flow-Datensätzen für die Anomalie-Erkennung nutzen. Plötzlich hohe Uploads, abnormale Downloads oder dichte 4xx/5xx-Muster können am Collector überwacht werden. TR7 überträgt L7-Signale für die Angriffs-Analyse auf die Flow-Schicht.
Anwendungspfade im Karteninhaberdaten-Scope können mit Host- und URL-Kontext im Flow-Export verfolgt werden. Audit-Teams erhalten Traffic-Nachweise basierend auf dem relevanten HTTP-Pfad statt nur IP/Port. Dies stärkt die Scope-Bestimmungs- und Audit-Trail-Erstellungsprozesse.
Operations-Teams können Traffic-Volumen nach HTTP-Pfad statt nur nach IP/Port in ihrem bestehenden Flow-Analytics-System anzeigen. Welcher Endpunkt welche Last trägt, kann detaillierter analysiert werden. Diese Sichtbarkeit unterstützt Ressourcenplanung und Wachstumsentscheidungen.
IPFIX v10- und NetFlow v9-kompatibler nativer Export — HTTP-angereicherte Flow-Datensätze ohne separate Probe. Lassen Sie uns einen Live-Durchlauf auf Ihrer eigenen Collector-Infrastruktur durchführen.