Was ist ein Netzwerkverkehrsfluss?

Netzwerkverkehrsflüsse (Flows) sind nützlich, um ein grobkörniges Verständnis des Datenverkehrs in einem Computernetzwerk aufzubauen und eine praktische Einheit für die Messung und / oder Behandlung des Datenverkehrs bereitzustellen.

Flows können gemessen werden, um zu verstehen, welche Hosts im Netzwerk sprechen, mit Details zu Adressen, Volumina und Arten von Datenverkehr. Diese Ansicht des Netzwerks kann zur Fehlerbehebung, Erkennung von Sicherheitsvorfällen, Planung und Abrechnung nützlich sein

Aber was genau ist ein Flow und wie wird er definiert?

Diese Frage klingt trivial zu beantworten, aber wenn wir tiefer graben, finden wir Nuancen und Eckfälle, die Flüsse interessant und letztendlich schwierig zu definieren machen.

Hintergrund

Um Flows wirklich zu verstehen, müssen wir mit einigen Hintergrundinformationen beginnen.

Netzwerke begannen als leitungsvermittelt. Wenn ein Host mit einem anderen Host kommunizieren wollte, bat er das Netzwerk, eine Schaltung einzurichten. Nachdem der Informationsfluss beendet war, wurde die Schaltung abgerissen.

Abbildung 1 – Beispiel Leitungsvermitteltes Netzwerk

Leitungsvermittelte Netzwerke haben ihr Erbe in Telefonnetzen. Sie weisen eine Reihe von Nachteilen auf, darunter eine schlechte Skalierbarkeit und eine geringe Kapazitätsauslastung.

Eine Alternative wurde benötigt, um das zu bauen, was letztendlich das Internet wurde – paketvermittelte Netzwerke. Nachrichten werden in Stücke variabler Größe zerhackt, die einzeln adressiert und als Pakete über das Netzwerk gesendet werden.

Abbildung 2 – Beispiel eines paketvermittelten Netzwerks

Der empfangende Host setzt die Nutzdaten aus den Paketen wieder in die Nachricht zusammen. Hinweis: Pakete können auch Steuerinformationen enthalten, z. B. Flusssteuerung, und Pfade müssen nicht symmetrisch sein.

Das Definieren von Flows in einem leitungsvermittelten Netzwerk ist einfach, da die Schaltung ein Flow ist und einem Protokoll zum Einrichten und Stilllegen folgt (circuit = flow); In einem paketvermittelten Netzwerk sind die Dinge jedoch weniger offensichtlich.

Stellen Sie sich für eine Sekunde vor, Sie befinden sich am Beobachtungspunkt A im leitungsvermittelten Netzwerk von Abbildung 1, Sie würden sehen:

Abbildung 3 – Vergrößern des leitungsvermittelten Netzwerks

Es würden zwei Flüsse beobachtet – Stromkreise zwischen Hosts 3 & 4 und Hosts 5 & 6. Das Beobachten von Strömen in einem leitungsvermittelten Netzwerk ist relativ einfach, da das Netzwerk am Aufbau der Schaltkreise beteiligt ist, also deren Zustand und die Endpunkte kennt.

Stellen Sie sich nun vor, Sie befinden sich stattdessen am Beobachtungspunkt A im paketvermittelten Netzwerk von Abbildung 2:

Abbildung 4 – Vergrößern des paketvermittelten Netzwerks

Plötzlich sind die Dinge weniger klar. Es kommt ein Paket von Host 5, das für Host 6 bestimmt ist. Angenommen, wir beobachten für einen bestimmten Zeitraum, dass mehr Pakete ein- und ausgehen. Die Beobachtung von Datenströmen in einem paketvermittelten Netzwerk erfordert Zeit und erfordert die Aufzeichnung und Analyse von Paketinformationen.

Erster (naiver) Versuch, einen Fluss zu definieren

Mit unserem Wissen über paketvermittelte Netzwerke könnte ein erster Versuch, zu beantworten, was ein Fluss ist, sein:

Ein Flow ist eine Folge von Paketen, die Informationen zwischen zwei Hosts transportieren

Diese Definition sieht so aus:

Abbildung 5 – Erster Versuch, einen Fluss zu definieren

Es gibt jedoch ein Problem. Was passiert, wenn zwischen den Hosts mehr als eine Art von Kommunikation stattfindet, z. B. hat A eine SSH- und HTTPS-Verbindung zu B? Sind die SSH- und HTTPS-Pakete Teil desselben Flusses? Intuitiv sagen wir nein, es sind verschiedene Sitzungen und sogar völlig unterschiedliche Protokolle. Wir können es besser machen …

Zweiter Versuch,

Wie wäre es, wenn wir Protokollinformationen aus Paketheadern als gemeinsame Eigenschaften verwenden, um Pakete in Flows zu identifizieren? Dadurch werden verschiedene Verbindungstypen in verschiedene Flüsse unterteilt.

Ein großer Teil der Pakete in einem Netzwerk ist wahrscheinlich das IP-Layer-3-Protokoll mit TCP oder UDP als Layer-4-Transportprotokoll. Es ist daher sinnvoll, TCP- und UDP-Parameter als Flussschlüssel aus den Paketheadern zu verwenden.

Wir verwenden 5 Parameter aus den Paketheadern; quell-IP, Ziel-IP, Protokoll, TCP- oder UDP-Quellport und TCP- oder UDP-Zielport als geordnete Liste, allgemein bekannt als 5-Tupel, als gemeinsame Eigenschaften zum Zuordnen der Pakete zu Flows.

Abbildung 6 – Beispiel 5-Tupel

Hier geht Versuch 2:

Ein Flow ist eine Folge von Paketen, die Informationen zwischen zwei Hosts übertragen, wobei Pakete gemeinsame Eigenschaften haben:

• Alle Pakete im Flow haben dasselbe 5-Tupel

Unser Szenario sieht jetzt so aus:

Abbildung 7 – Zweiter Versuch, einen Fluss

zu definieren, wie Sie sagen. Das Leben ist gut. Wir haben eine Definition für einen Fluss, hier gibt es nichts mehr zu sehen … Aber moment mal, wie sieht es mit der Richtung der Pakete aus?

Dritter Versuch – Bidirektional

Ein 5-Tupel ist unidirektional (einweg). Standardmäßig werden nur Pakete in einer Richtung abgeglichen, da Pakete in umgekehrter Richtung IP-Adressen und Portnummern transponiert haben und somit einen anderen 5-Tupel-Hash haben.

Es gibt gute Gründe, Flows als bidirektional im Gegensatz zu unidirektional zu betrachten, einschließlich der Möglichkeit, das Client / Server-Verhalten zu bestimmen und Roundtrip-Zeiten zu berechnen sowie die Erkennung von Sicherheitsvorfällen wie Scans zu verbessern.

Betrachten Sie eine einfache TCP-Verbindung in Abbildung 8, bei der Pakete zwischen Host A & B hin und her springen:

Abbildung 8 – Leiterdiagramm eines einfachen TCP-Flusses

Wir sehen einen klassischen TCP-3-Wege-Handshake (SYN, SYN+ACK, ACK), gefolgt von einem Datenaustausch. Eine unidirektionale Flussanalyse an einem Beobachtungspunkt im Netzwerk würde zwei separate Flüsse sehen, einen pro Richtung, gemäß Abbildung 9:

Abbildung 9 – Unidirektionale Leitern für einfachen TCP-Durchfluss

Das Problem bei der unidirektionalen Durchflussmessung besteht darin, dass wir die Möglichkeit verpassen, einige wichtige Metadaten über den Durchfluss zu erfassen. Sicher, jeder unidirektionale Fluss kann direktionale Metadaten für Bytes und Pakete in dieser Richtung speichern. Dies kann das Timing zwischen Paketen einschließen (siehe beschriftete Punkte in Abbildung 9). Wir verpassen jedoch die Gelegenheit, Metadaten zu sammeln, die die Messung von Verkehrsparametern in beide Richtungen erfordern.

Betrachten Sie die bidirektionale Beobachtung in Abbildung 10:

Abbildung 10 – Leiter der bidirektionalen Beobachtungen für einfachen TCP-Fluss

Wir können jetzt den TCP-3-Wege-Handshake (Punkte F1, B1, F2) beobachten und messen und andere Metriken wie Antwortzeiten betrachten.

Für bidirektionale Flüsse benötigen wir zwei 5-Tupel, von denen das zweite die Tupelreihenfolge sowohl der IP-Adressen als auch der Portnummern umkehrt. Unten ist ein Beispiel für SSH-Fluss vorwärts und rückwärts 5-Tupel:

Abbildung 11 – Umkehren eines 5-Tupels

Richtig, das war nicht allzu schwierig. Aber warten Sie, ein kleines Detail lauert, das weitere Aufmerksamkeit erfordert. Woher wissen wir, was die Vorwärtsrichtung des Flusses ist? Wir bestimmen die Richtung basierend auf dem ersten beobachteten Paket, von dem angenommen wird, dass es sich in Richtung Client zu Server bewegt, aber dies wird nicht 100% zuverlässig sein, da Pakete nicht in Ordnung sein könnten und / oder die Beobachtung könnte teilweise beginnen Weg durch einen Fluss. Wir verwenden diese Methode, müssen uns aber daran erinnern, wenn wir uns die Ergebnisse ansehen, dass sie nicht perfekt ist.

Eine alternative Methode ist das Überprüfen von Transportprotokollfeldern. In TCP zum Beispiel ist das Vorhandensein nur des SYN-Flags ein vernünftiger Indikator dafür, dass das Paket das erste im Fluss ist.

Unsere Definition für einen Flow lautet jetzt:

Ein Flow ist eine Folge von Paketen, die Informationen zwischen zwei Hosts transportieren, wobei Pakete gemeinsame Eigenschaften haben:

• Alle Pakete im Flow haben dasselbe 5-Tupel oder transponiertes 5-Tupel

Vierter Versuch – Einschließlich Nicht-TCP-IP-Verkehr

Bis zu diesem Zeitpunkt haben wir angenommen, dass das Transportprotokoll TCP ist. Was ist mit anderen IP-Transportprotokollen?

UDP ist die offensichtliche Wahl für das zweithäufigste Transportprotokoll, insbesondere mit dem Anstieg des Echtzeitverkehrs über UDP sowie neuen Protokollen wie QUIC. UDP passt problemlos in dasselbe Modell, da es Quell- und Zielportnummern hat, wie im folgenden Beispiel beschrieben:

Abbildung 12 – Umkehren eines UDP-5-Tupels (wie TCP)

Das Stream Control Transmission Protocol (SCTP) ist ein weiteres Transportprotokoll, das Portnummern verwendet und daher mit einem 5-Tupel arbeitet.

Aber was ist mit anderen Protokollen, zum Beispiel IPSec?

IPSec ESP (Encapsulating Security Payload) ist ein Protokoll, das keine Quell- / Zielportnummern enthält, daher müssen wir auf ein 3-Tupel zurückgreifen, da das Verständnis der Nutzlast des Protokolls wahrscheinlich nicht praktikabel ist.

Abbildung 13 – Bidirektionales 3-Tupel

Unsere Definition für einen Flow lautet jetzt:

Ein Flow ist eine Folge von Paketen, die Informationen zwischen zwei Hosts transportieren, wobei Pakete gemeinsame Eigenschaften haben:

• Für Transportprotokolle mit Portnummern (z. B. TCP/ UDP/SCTP):

Alle Pakete im Flow teilen sich das gleiche 5-Tupel oder transponiertes 5-Tupel

sonst:

Alle Pakete im Flow teilen sich das gleiche 3-Tupel oder transponiertes 3-Tupel

Es ist jedoch noch ein weiterer Faktor zu berücksichtigen – die Zeit.

Fünfter Versuch – Ablauf des Flusses

Ein Fluss existiert nur für eine bestimmte Zeit. Es ist möglich, dass dasselbe 5-Tupel (oder 3-Tupel) zu einem anderen Zeitpunkt für einen anderen Fluss zwischen denselben Hosts wiederverwendet wird.

Betrachten Sie zwei Hosts, von denen einer viele neue TCP-Verbindungen zum anderen initiiert. Jede neue TCP-Verbindung erhält einen neuen Quellport, der im Allgemeinen um 1 von der vorherigen Zuweisung inkrementiert wird. IANA weist diesen ephemeren Ports den Bereich 49152 bis 65535 zu, was 16384 Ports ergibt. Im Laufe der Zeit rollt der TCP-Quellport durch den Bereich und der ursprüngliche Quellport wird wiederverwendet, und dieser Flow hat das gleiche 5-Tupel wie der ursprüngliche Flow. Dies stellt ein Problem dar, da es nicht der gleiche Fluss ist!

Um dies zu lösen, müssen Flows abgelaufen sein, bei denen länger als eine bestimmte Zeit keine Pakete gesehen werden. Hier geht es wieder los:

Ein Flow ist eine Folge von Paketen, die Informationen zwischen zwei Hosts transportieren, wobei Pakete gemeinsame Eigenschaften haben:

• Für Transportprotokolle mit Portnummern (dh TCP / UDP / SCTP):

Alle Pakete im Flow teilen sich das gleiche 5-Tupel oder transponiertes 5-Tupel

sonst:

Alle Pakete im Flow teilen sich das gleiche 3-Tupel oder transponiertes 3-Tupel

• Alle Zeiten zwischen Paketen sind kleiner als ein beliebiger Ablaufzeitlimitwert für den Fluss

Sechster Versuch – Beliebige Parameter

Manchmal möchten Sie möglicherweise andere Parameter, um Flows zu identifizieren, oder diese werden Ihnen durch die Art der Hardware / Software im Netzwerk aufgezwungen.

In einem Cisco-Router werden Flows beispielsweise durch ein 7-Tupel identifiziert, das dem Standard-5-Tupel den Diensttyp (ToS) und die Eingabe-Unterschnittstelle hinzufügt. Es kann auch Situationen geben, in denen Layer-2-Felder wie Quell- oder Ziel-MAC-Adresse als Flussschlüssel sinnvoll sind (beachten Sie jedoch, dass sie nur lokal von Bedeutung sind).

Es gibt andere Parameter, die als gemeinsame Eigenschaften für die Durchflusserkennung verwendet werden könnten; Es ist letztendlich Sache des Bedieners, zu entscheiden und die Fähigkeiten der Ausrüstung. Auf dieser Grundlage verfeinern wir die Definition weiter:

Ein Flow ist eine Folge von Paketen, die Informationen zwischen zwei Hosts übertragen, wobei Pakete gemeinsame Eigenschaften haben:

• Für Transportprotokolle mit Portnummern (z. B. TCP / UDP / SCTP):

Alle Pakete im Flow teilen sich das gleiche 5-Tupel oder transponiertes 5-Tupel

sonst:

Alle Pakete im Flow teilen sich das gleiche 3-Tupel oder transponiertes 3-Tupel

• Alle Zeiten zwischen Paketen sind kleiner als ein beliebiger Ablaufzeitlimitwert für den Fluss
• Kann beliebige Parameter als Flussschlüssel verwenden, einschließlich ToS, Schnittstelle usw.

Alles einpacken

Wir haben gezeigt, dass es ein schwieriges Problem ist, eine einzige allumfassende Flussdefinition zu erstellen. Die Flussdefinition ist implementierungsspezifisch und hängt von den Benutzeranforderungen sowie den Fähigkeiten der Netzwerkgeräte ab, die die Flüsse messen.

In Teil 2 dieses Blogbeitrags werden wir auf weitere Überlegungen zu Flows wie IPv6-Flow-Labels, Fragmentierung (IPv4- und IPv6-Problem) eingehen..), Verschlüsselung, Nicht-IP-Pakete und wie Flüsse gemessen und in anderen Systemen wie SDN verwendet werden.

Sehen: https://www.eecs.yorku.ca/course_archive/2015-16/W/3214/CSE3214_01_PacketCircuitSwitching_2016_posted_part2.pdf

Für einige verwandte Artikel siehe: https://www.researchgate.net/profile/Brian_Trammell/publication/245587221_Bidirectional_Flow_Measurement_IPFIX_and_Security_Analysis/links/0f3175331dd3b49103000000/Bidirectional-Flow-Measurement-IPFIX-and-Security-Analysis.pdf und https://is.muni.cz/th/hilnn/cse2009.pdf

Für relevante RFC siehe: https://tools.ietf.org/html/rfc5103

Weitere Informationen zur Standardisierung von QUIC finden Sie unter: https://datatracker.ietf.org/wg/quic/about/

Siehe: https://www.cisco.com/en/US/tech/tk812/technologies_white_paper09186a008022bde8.shtml