co je tok síťového provozu?

síťové dopravní toky (toky) jsou užitečné pro budování hrubého chápání provozu v počítačové síti a poskytují vhodnou jednotku pro měření a / nebo zpracování provozu.

toky lze měřit, abyste pochopili, co hostitelé mluví v síti, s podrobnostmi o adresách, objemech a typech provozu. Tento pohled na síť může být užitečný pro řešení problémů, detekci bezpečnostních incidentů, plánování a fakturaci

ale co přesně je tok a jak je definován?

tato otázka zní triviálně odpovědět, ale když budeme kopat hlouběji, najdeme nuance a rohové případy, díky nimž jsou toky zajímavé a nakonec obtížně definovatelné.

pozadí

abychom skutečně pochopili toky, musíme začít s nějakým pozadím.

sítě začínaly jako obvody spínané. Když hostitel chtěl komunikovat s jiným hostitelem požádal síť nastavit obvod. Po dokončení toku informací byl okruh stržen.

Obrázek 1-Příklad sítě se spínaným obvodem

sítě se spínaným obvodem mají své dědictví v telefonních sítích. Mají řadu nevýhod, včetně špatné škálovatelnosti a nízkého využití kapacity.

byla zapotřebí alternativa k vybudování toho, co se nakonec stalo internetovými paketovými sítěmi. Zprávy jsou rozděleny do různých velikostí kusů, které jsou jednotlivě adresovány a odesílány jako pakety v síti.

Obrázek 2-Příklad sítě s přepínáním paketů

přijímající hostitel znovu sestaví užitečné zatížení z paketů zpět do zprávy. Poznámka: pakety mohou také obsahovat řídicí informace, jako je řízení toku a cesty nemusí být symetrické.

definování toků v síti se spínaným obvodem je snadné, protože obvod je tok a řídí se protokolem pro vytvoření a vyřazení z provozu (circuit = flow); nicméně v síti se spínaným paketem jsou věci méně zřejmé.

Představte si na vteřinu, že jste v pozorovacím bodě A v obvodově spínané síti na obrázku 1, uvidíte:

obrázek 3-přiblížení sítě se spínaným obvodem

byly pozorovány dva toky – obvody mezi hostiteli 3 & 4 a hostiteli 5 & 6. Pozorování toků v síti se spínaným obvodem je relativně snadné, protože síť se podílí na Nastavení obvodů, takže zná jejich stav a koncové body.

Představte si, že nyní, když jste v pozorovacím bodě A v síti přepínané pakety na obrázku 2, místo toho byste viděli:

obrázek 4-přiblížení sítě s přepínáním paketů

najednou jsou věci méně jasné. Z hostitele přichází paket 5 určený pro hostitele 6. Za předpokladu, že pozorujeme po určitou dobu, vidíme, že více paketů dorazí a odejde. Pozorování toků v síti s přepínáním paketů vyžaduje čas a vyžaduje záznam a analýzu informací o paketech.

první (naivní) Pokus o definování toku

pomocí našich znalostí sítí s přepínáním paketů by první pokus o odpověď “co je to Tok” mohl být:

tok je posloupnost paketů nesoucích informace mezi dvěma hostiteli

tato definice vypadá takto:

obrázek 5-První pokus definovat Tok

je zde však problém. Co se stane, pokud mezi hostiteli probíhá více než jeden typ komunikace, například a má připojení SSH a HTTPS K B? Jsou pakety SSH a HTTPS součástí stejného toku? Intuitivně říkáme ne, jsou to různá sezení, a dokonce i zcela odlišné protokoly. Můžeme to udělat lépe…

druhý pokus definovat

Co kdybychom použili informace protokolu z hlaviček paketů jako běžné vlastnosti k identifikaci paketů do toků? Tím se oddělí různé typy připojení do různých toků.

velká část paketů v síti je pravděpodobně protokol IP layer-3, s protokolem TCP nebo UDP jako transportním protokolem layer-4. Proto je rozumné zvážit použití parametrů TCP a UDP jako klíčů toku z hlaviček paketů.

použijeme 5 parametrů z hlaviček paketů; zdrojová IP, Cílová IP, protokol, TCP nebo UDP zdrojový port a TCP nebo UDP cílový port jako uspořádaný seznam, běžně známý jako 5-n-tice, jako společné vlastnosti pro mapování paketů na toky.

obrázek 6-příklad 5-n-tice

zde jde pokus 2:

tok je posloupnost paketů nesoucích informace mezi dvěma hostiteli, kde pakety mají společné vlastnosti:

• všechny pakety v toku sdílejí stejnou 5-Tice

náš scénář nyní vypadá takto:

Obrázek 7-druhý pokus definovat Tok

perfektní říkáte. Život je dobrý. Máme definici toku, nic víc zde vidět … ale vydrž, co směr paketů?

třetí pokus-obousměrný

5-Tice je jednosměrná (jednosměrná). Ve výchozím nastavení bude odpovídat pouze paketům cestujícím v jednom směru, protože pakety v opačném směru mají transponované adresy IP a čísla portů, a tedy jiný hash 5-n-tice.

existují dobré důvody, proč považovat toky za obousměrné na rozdíl od jednosměrných, včetně schopnosti určit chování klienta/serveru a vypočítat časy zpáteční cesty a zlepšit detekci bezpečnostních incidentů, jako je skenování.

zvažte jednoduché TCP spojení na obrázku 8, kde se pakety odrazí tam a zpět mezi hostitelem a & B:

Obrázek 8-žebříkový Diagram jednoduchého TCP toku

vidíme klasický TCP 3-way handshake (SYN, SYN+ACK, ACK) následovaný výměnou dat. Jednosměrná analýza toku v pozorovacím bodě v síti by viděla dva samostatné toky, jeden na směr, podle obrázku 9:

obrázek 9-jednosměrné žebříky pro jednoduchý tok TCP

problém s jednosměrným měřením toku je, že nám chybí příležitost zachytit některá důležitá metadata o toku. Jistě, každý jednosměrný tok může ukládat směrová metadata pro bajty a pakety v tomto směru. To může zahrnovat časování mezi pakety (viz označené tečky na obrázku 9). Chybí nám však příležitost shromažďovat metadata, která vyžadují měření dopravních parametrů v obou směrech.

zvažte obousměrné pozorování na obrázku 10:

obrázek 10-žebřík obousměrných pozorování pro jednoduchý tok TCP

Nyní můžeme pozorovat a měřit TCP 3-way handshake (body F1, B1, F2) a podívat se na další metriky, jako jsou doby odezvy.

pro obousměrné toky potřebujeme dvě 5-n-tice, z nichž druhá obrací n-tice pořadí IP adres i čísel portů. Níže je uveden příklad toku SSH vpřed a vzad 5-n-tice:

obrázek 11-obrácení 5-n-tice

správně, to nebylo příliš obtížné. Ale počkejte, skrývá se malý detail, který vyžaduje další pozornost. Jak víme, jaký je dopředný směr toku? Směr určujeme na základě prvního pozorovaného paketu, o kterém se předpokládá, že cestuje ve směru klienta na server, ale to nebude 100% spolehlivé, protože pakety by mohly být mimo provoz a/nebo pozorování by mohlo začít částečně přes tok. Budeme používat s touto metodou, ale je třeba mít na paměti, když se podíváme na výsledky, že to není dokonalé.

alternativní metodou je kontrola polí transportního protokolu. Například v TCP je přítomnost pouze příznaku SYN rozumným indikátorem toho, že paket je první v toku.

naše definice pro tok je nyní:

tok je posloupnost paketů nesoucích informace mezi dvěma hostiteli, kde pakety mají společné vlastnosti:

• všechny pakety v toku sdílejí stejnou 5-Tice nebo transponovanou 5-Tice

čtvrtý pokus-včetně non-TCP IP provozu

až do tohoto okamžiku jsme předpokládali, že transportní protokol je TCP. A co další IP transportní protokoly?

UDP je jasnou volbou pro druhý nejběžnější transportní protokol, zejména s nárůstem provozu v reálném čase přes UDP a novými protokoly, jako je QUIC. UDP se snadno vejde do stejného modelu, jako má čísla zdrojových a cílových portů, podle níže uvedeného příkladu QUIC:

Obrázek 12-obrácení UDP 5-n-tice (stejné jako TCP)

Stream Control Transmission Protocol (SCTP) je další transportní protokol, který používá čísla portů, a proto pracuje s 5-n-tice.

ale co jiné protokoly, například IPsec?

IPsec ESP (Encapsulating Security Payload) je protokol, který neobsahuje čísla zdrojových / cílových portů, takže se musíme vrátit k 3-Tice, protože pochopení užitečného zatížení protokolu pravděpodobně nebude praktické.

obrázek 13-obousměrný 3-Tice

naše definice pro tok je nyní:

tok je posloupnost paketů nesoucích informace mezi dvěma hostiteli, kde pakety mají společné vlastnosti:

• pro transportní protokoly s čísly portů (např. TCP / UDP / SCTP):

všechny pakety v toku sdílejí stejnou 5-Tice nebo transponované 5-Tice

else:

všechny pakety v toku sdílejí stejnou 3-Tice nebo transponované 3-Tice

Existuje však ještě další faktor, který je třeba zvážit-čas.

pátý pokus – expirace toku

tok existuje pouze po určitou dobu. Je možné, že stejná 5-Tice (nebo 3-Tice) by mohla být znovu použita v jiném časovém bodě, pro jiný tok, mezi stejnými hostiteli.

zvažte dva hostitele, kde jeden iniciuje mnoho nových připojení TCP k druhému. Každé nové připojení TCP získá nový zdrojový port, obvykle zvýšen o 1 z předchozí alokace. IANA přidělit rozsah 49152 na 65535 pro tyto pomíjivé porty, dávat 16384 porty. V průběhu času bude zdrojový port TCP procházet rozsahem a původní zdrojový port bude znovu použit a tento tok bude mít stejný 5-Tice jako původní tok. To představuje problém, protože to není stejný tok!

abychom to vyřešili, potřebujeme, aby toky vypršely, pokud nejsou vidět žádné pakety po delší dobu. A je to tady znovu:

tok je posloupnost paketů nesoucích informace mezi dvěma hostiteli, kde pakety mají společné vlastnosti:

• pro transportní protokoly s čísly portů (např. TCP / UDP / SCTP):

všechny pakety v toku sdílejí stejnou 5-Tice nebo transponované 5-Tice

else:

všechny pakety v toku sdílejí stejnou 3-Tice nebo transponované 3-Tice

• všechny časy mezi pakety jsou menší než libovolná hodnota vypršení časového limitu toku

šestý pokus-libovolné parametry

někdy můžete chtít různé parametry pro identifikaci toků, nebo mohou být vynuceny typem hardwaru / softwaru v síti.

například v routeru Cisco jsou toky identifikovány 7-N-tice, která přidává typ služby (ToS) a vstupní sub-rozhraní ke standardní 5-n-tice. Mohou také nastat situace, kdy pole layer-2, například zdrojová nebo cílová MAC adresa, mohou mít smysl jako flow klíče (i když si všimněte, že jsou pouze místně významné).

existují další parametry, které by mohly být použity jako běžné vlastnosti pro identifikaci toku; je nakonec na provozovateli, aby rozhodl a schopnosti zařízení. Na základě toho dále upřesňujeme definici:

tok je posloupnost paketů nesoucích informace mezi dvěma hostiteli, kde pakety mají společné vlastnosti:

• pro transportní protokoly s čísly portů (např. TCP / UDP / SCTP):

všechny pakety v toku sdílejí stejnou 5-Tice nebo transponovanou 5-Tice

else:

všechny pakety v toku sdílejí stejnou 3-Tice nebo transponovanou 3-Tice

• všechny časy mezi pakety jsou menší než libovolná hodnota časového limitu vypršení platnosti toku
• může použít libovolné parametry jako klíče toku, včetně ToS, rozhraní atd.

když to všechno zabalíme

, ukázali jsme, že vytvoření jediné všeobjímající definice toku je obtížný problém. Definice toku je specifická pro implementaci, závisí na požadavcích uživatele a na schopnostech síťového zařízení, které měří toky.

v části 2 tohoto blogu se podíváme na další úvahy o tocích, jako jsou štítky toku IPv6, fragmentace (problém IPv4 a IPv6..), šifrování, non-IP pakety a jak jsou toky měřeny a používány v jiných systémech, jako je SDN.

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

pro některé související dokumenty viz: 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 a https://is.muni.cz/th/hilnn/cse2009.pdf

pro relevantní RFC viz: https://tools.ietf.org/html/rfc5103

více o standardizaci QUIC viz: https://datatracker.ietf.org/wg/quic/about/

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