mi a hálózati forgalom?

a hálózati forgalmi áramlások (áramlások) hasznosak a forgalom durva szemcsés megértésének felépítéséhez egy számítógépes hálózaton, kényelmes egységet biztosítva a forgalom mérésére és/vagy kezelésére.

a folyamatok mérhetők annak megértéséhez, hogy a gazdagépek mit beszélnek a hálózaton, a címek, a kötetek és a forgalom típusainak részleteivel. Ez a hálózati nézet hasznos lehet hibaelhárításhoz, biztonsági incidensek észleléséhez, tervezéshez és számlázáshoz

de mi is pontosan az áramlás, és hogyan definiálható?

ez a kérdés triviálisnak tűnik, de ha mélyebbre ásunk, olyan árnyalatokat és sarokpontokat találunk, amelyek érdekessé teszik az áramlásokat, és végül nehéz meghatározni.

háttér

ahhoz, hogy valóban megértsük az áramlásokat, némi háttérrel kell kezdenünk.

a hálózatok áramköri kapcsolással indultak. Amikor egy gazdagép kommunikálni akart egy másik gazdagéppel, megkérte a hálózatot, hogy állítson be egy áramkört. Miután az információáramlás befejeződött, az áramkört lebontották.

1. ábra-példa áramkör-kapcsolt hálózat

az áramkör-kapcsolt hálózatok öröksége a telefonhálózatokban van. Számos hátrányuk van, többek között a gyenge skálázhatóság és az alacsony kapacitáskihasználás.

alternatívára volt szükség a végső soron az Internet – csomagkapcsolt hálózatok kiépítéséhez. Az üzeneteket változó méretű darabokra vágják, amelyeket külön-külön címeznek és csomagként küldenek a hálózaton keresztül.

2. ábra – példa csomagkapcsolt hálózat

a fogadó gazdagép újra összeállítja a csomagok hasznos terhelését az üzenetbe. Megjegyzés: a csomagok tartalmazhatnak vezérlési információkat is, például az áramlásszabályozást, és az útvonalaknak nem kell szimmetrikusnak lenniük.

az áramlások meghatározása egy áramkörrel kapcsolt hálózatban egyszerű, mivel az áramkör áramlás, és protokollt követ a létrehozáshoz és a leszereléshez (áramkör = áramlás); azonban egy csomagkapcsolt hálózatban a dolgok kevésbé nyilvánvalóak.

képzelje el egy pillanatra, hogy az 1. ábra áramköri kapcsolt hálózatának a megfigyelési pontján van, látni fogja:

3. ábra-Nagyítás az áramköri kapcsolású hálózaton

két áramlás figyelhető meg – a 3 & 4 és az 5 & 6 állomás közötti áramkörök. Az áramlások megfigyelése egy áramkörrel kapcsolt hálózatban viszonylag egyszerű, mert a hálózat részt vesz az áramkörök beállításában, így ismeri azok állapotát és a végpontokat.

képzelje el most, hogy a 2. ábra csomagkapcsolt hálózatának a megfigyelési pontján tartózkodik, ehelyett azt látná:

4. ábra-Nagyítás a csomagkapcsolt hálózaton

hirtelen a dolgok kevésbé világosak. Egy csomag érkezik az 5-ös állomásról a 6-os állomásra. Feltételezve, hogy egy ideig megfigyeljük, több csomag érkezik és távozik. A csomagkapcsolt hálózaton zajló folyamatok megfigyelése időt vesz igénybe, és megköveteli a csomaginformációk rögzítését és elemzését.

első (naiv) kísérlet egy áramlás meghatározására

a csomagkapcsolt hálózatok ismereteinek felhasználásával az első kísérlet arra, hogy megválaszoljuk a ‘mi az áramlás’ lehet:

a folyamat két állomás között információt hordozó csomagok sorozata

ez a meghatározás így néz ki:

5. ábra – első kísérlet egy áramlás meghatározására

van azonban egy probléma. Mi történik, ha egynél több típusú kommunikáció történik a gazdagépek között, például a SSH és HTTPS kapcsolattal rendelkezik B-vel? Az SSH és a HTTPS csomagok ugyanannak a folyamatnak a részei? Intuitív módon nemet mondunk, ezek különböző ülések, sőt teljesen más protokollok. Mi lehet jobb …

második kísérlet a

meghatározására mi lenne, ha a csomagfejlécekből származó protokollinformációkat közös tulajdonságként használnánk a csomagok áramlásokba történő azonosítására? Ez elkülöníti a különböző típusú kapcsolatokat különböző áramlásokra.

a hálózaton lévő csomagok nagy része valószínűleg IP 3. réteg protokoll, TCP vagy UDP mint a 4. réteg átviteli protokoll. Ezért ésszerű megfontolni a TCP és UDP paraméterek használatát a csomagfejlécek folyamatkulcsaként.

5 paramétert fogunk használni a csomagfejlécekből; forrás IP, cél IP, protokoll, TCP vagy UDP forrásport és TCP vagy UDP célport rendezett listaként, közismert nevén 5-tuple, mint a csomagok áramlásokhoz való leképezésének közös tulajdonságai.

6. ábra-5. példa-tuple

itt megy a 2. Kísérlet:

a folyamat két gazdagép között információt hordozó csomagok sorozata, ahol a csomagok közös tulajdonságokkal rendelkeznek:

• az áramlásban lévő összes csomag ugyanazt az 5-tuple-t használja

a forgatókönyvünk most így néz ki:

ábra 7-második kísérlet, hogy meghatározza a Flow

tökéletes mondod. Az élet szép. Van egy definíciónk az áramlásra, itt nincs több látnivaló … de várj, mi a helyzet a csomagok irányával?

harmadik kísérlet – kétirányú

egy 5-tuple egyirányú (egyirányú). Alapértelmezés szerint csak egy irányba haladó csomagokat fog egyeztetni, mivel a fordított irányú csomagok IP-címeket és portszámokat ültettek át, és így egy másik 5-tuple hash.

jó okunk van arra, hogy a folyamatokat az egyirányúakkal szemben kétirányúnak tekintsük, beleértve az ügyfél/szerver viselkedésének meghatározását és az oda-vissza menetidők kiszámítását, valamint a biztonsági események, például a szkennelés észlelésének javítását.

Vegyünk egy egyszerű TCP kapcsolatot a 8. ábrán, ahol a csomagok oda-vissza ugrálnak az a állomás között & B:

8. ábra-létra Diagram egy egyszerű TCP Flow

látunk egy klasszikus TCP 3-utas kézfogás (SYN, SYN+ACK, ACK), majd adatcsere. Az egyirányú áramlás elemzése a hálózat megfigyelési pontján két különálló áramlást látna, irányonként egyet, ábra szerint 9:

9. ábra-egyirányú létrák egyszerű TCP áramláshoz

az egyirányú áramlásmérés problémája az, hogy elmulasztjuk a lehetőséget, hogy rögzítsünk néhány fontos metaadatot az áramlásról. Persze, minden egyirányú áramlás képes tárolni irányított metaadatokat bájtokhoz és csomagokhoz ebben az irányban. Ez magában foglalhatja a csomagok közötti időzítést (lásd a címkézett pontokat a 9.ábrán). De elszalasztjuk a lehetőséget, hogy olyan metaadatokat gyűjtsünk, amelyekhez mindkét irányban meg kell mérni a forgalmi paramétereket.

fontolja meg a kétirányú megfigyelést az ábrán 10:

10. ábra-kétirányú megfigyelések létrája egyszerű TCP áramláshoz

most megfigyelhetjük és megmérhetjük a TCP 3-utas kézfogását (F1, B1, F2 pontok), és megnézhetünk más mutatókat, például a válaszidőket.

kétirányú áramlásokhoz két 5-sorra van szükségünk, amelyek közül a második megfordítja mind az IP-címek, mind a portszámok tuple sorrendjét. Az alábbiakban egy példa SSH flow előre és hátra 5-tuples:

11. ábra-megfordítása 5-tuple

jobb, hogy nem volt túl nehéz. De várj, egy kis részlet leselkedik, amely további figyelmet igényel. Honnan tudjuk, hogy mi az áramlás iránya? Az irányt az első megfigyelt csomag alapján határozzuk meg, amely feltételezhetően a kliens felé halad a szerver irányába, de ez nem lesz 100% – ban megbízható, mivel a csomagok meghibásodhatnak és/vagy a megfigyelés részben egy folyamon keresztül kezdődhet. Ezt a módszert fogjuk használni, de emlékeznünk kell arra, amikor az eredményeket nézzük, hogy nem tökéletes.

alternatív módszer a szállítási protokoll mezők ellenőrzése. Például a TCP – ben csak a SYN zászló jelenléte ésszerű jelzés arra, hogy a csomag az első az áramlásban.

a folyamat definíciója most:

a folyamat olyan csomagok sorozata, amelyek információt hordoznak két gazdagép között, ahol a csomagok közös tulajdonságokkal rendelkeznek:

• az áramlásban lévő összes csomag ugyanazt az 5-tuple-t vagy átültetett 5-tuple-t használja

negyedik kísérlet-beleértve a nem TCP IP forgalmat

addig a pontig feltételeztük, hogy a szállítási protokoll TCP. Mi a helyzet más IP átviteli protokollokkal?

az UDP a második leggyakoribb szállítási protokoll nyilvánvaló választása, különösen az UDP-n keresztüli valós idejű forgalom növekedésével, valamint az új protokollokkal, mint például a QUIC. Az UDP könnyen illeszkedik ugyanabba a modellbe, mivel forrás – és célportszámokkal rendelkezik, az alábbi QUIC példa szerint:

12. ábra-az UDP 5-tuple (ugyanaz, mint a TCP) megfordítása

Stream Control Transmission Protocol (SCTP) egy másik szállítási protokoll, amely portszámokat használ, és így 5-tuple-vel működik.

de mi a helyzet más protokollokkal, például az IPsec-kel?

IPsec ESP (Encapsulating Security Payload) egy olyan protokoll, amely nem tartalmazza a forrás/cél port számát, ezért vissza kell térnünk egy 3-tuple-re, mivel a protokoll hasznos terhelésének megértése valószínűleg nem lesz praktikus.

13. ábra-kétirányú 3-Tuple

az áramlás definíciója a következő:

az áramlás olyan csomagok sorozata, amelyek információt hordoznak két gazdagép között, ahol a csomagok közös tulajdonságokkal rendelkeznek:

• portszámokkal rendelkező szállítási protokollok esetében (azaz TCP / UDP / SCTP):

az áramlásban lévő összes csomag ugyanazt az 5-tuple-t vagy átültetett 5-tuple-t használja

else:

az áramlásban lévő összes csomag ugyanazt a 3 – tuple-t vagy átültetett 3-tuple-t használja

van azonban még egy tényező, amelyet figyelembe kell venni-az idő.

ötödik kísérlet – Flow lejárat

a flow csak egy bizonyos ideig létezik. Lehetséges, hogy ugyanaz az 5-tuple (vagy 3-tuple) újra felhasználható egy másik időpontban, más áramláshoz, ugyanazon gazdagépek között.

tekintsünk két gazdagépet, ahol az egyik sok új TCP kapcsolatot kezdeményez a másikkal. Minden új TCP-kapcsolat új forrásportot kap, általában 1-gyel növekszik az előző allokációhoz képest. Az IANA a 49152-től 65535-ig terjedő tartományt osztja ki ezekhez az efemer portokhoz, így 16384 portot kap. Idővel a TCP forrásport átgurul a tartományon, és az eredeti forrásport újrafelhasználásra kerül, és ennek az áramlásnak ugyanaz az 5-tuple lesz, mint az eredeti áramlásnak. Ez problémát jelent, mivel nem ugyanaz az áramlás!

ennek megoldásához le kell járnunk a flow-kat, ahol egy adott időtartamnál hosszabb ideig nem láthatók csomagok. Itt megyünk újra:

a flow egy olyan csomagsorozat, amely két gazdagép között információt hordoz, ahol a csomagok közös tulajdonságokkal rendelkeznek:

• portszámokkal rendelkező szállítási protokollokhoz (azaz TCP / UDP / SCTP):

az áramlásban lévő összes csomag ugyanazt az 5-tuple-t vagy átültetett 5-tuple-t használja

else:

az áramlásban lévő összes csomag ugyanazt a 3-tuple-t vagy átültetett 3-tuple-t használja

• az összes csomagközi idő kevesebb, mint tetszőleges áramlási lejárati idő

hatodik kísérlet-tetszőleges paraméterek

előfordulhat, hogy különböző paramétereket szeretne az áramlások azonosítására, vagy ezeket a hálózat hardver/szoftver típusa kényszerítheti rád.

például egy Cisco routerben az áramlásokat egy 7-Tuple azonosítja, amely hozzáadja a szolgáltatás típusát (ToS) és a bemeneti alinterfészt a standard 5-Tuple-hez. Előfordulhatnak olyan helyzetek is, amikor a 2.réteg mezőinek, például a forrás vagy a cél MAC-címének, értelme lehet folyamatkulcsként (bár vegye figyelembe, hogy ezek csak lokálisan jelentősek).

vannak más paraméterek is, amelyek az áramlás azonosításának közös tulajdonságaiként használhatók; végső soron a kezelő dönti el a berendezés képességeit. Ennek alapján tovább finomítjuk a meghatározást:

a flow egy olyan csomagsorozat, amely két állomás között információt hordoz, ahol a csomagok közös tulajdonságokkal rendelkeznek:

• portszámokkal rendelkező szállítási protokollokhoz (azaz TCP / UDP / SCTP):

az áramlásban lévő összes csomag ugyanazt az 5-tuple-t vagy átültetett 5-tuple-t használja

else:

az áramlásban lévő összes csomag ugyanazt a 3-tuple-t vagy átültetett 3-tuple-t használja

• minden csomagközi idő kevesebb, mint az önkényes áramlás lejárati időtúllépési értéke
• bármilyen tetszőleges paramétert használhat áramlási kulcsként, beleértve a ToS-t, az interfészt stb.

az egészet becsomagolva

megmutattuk, hogy egyetlen mindent átfogó áramlási definíció előállítása nehéz probléma. Az áramlás meghatározása implementáció-specifikus, a felhasználói igényektől, valamint az áramlásokat mérő hálózati eszközök képességeitől függ.

a blogbejegyzés 2. részében további szempontokat fogunk figyelembe venni az olyan folyamatokkal kapcsolatban, mint az IPv6 áramlási címkék, a töredezettség (IPv4 és IPv6 probléma..), titkosítás, nem IP csomagok és az áramlások mérése és felhasználása más rendszerekben, például az SDN-ben.

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

néhány kapcsolódó dokumentumot lásd: 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 és https://is.muni.cz/th/hilnn/cse2009.pdf

a vonatkozó RFC-t lásd:: https://tools.ietf.org/html/rfc5103

a QUIC szabványosításáról bővebben lásd:: https://datatracker.ietf.org/wg/quic/about/

lásd: https://www.cisco.com/en/US/tech/tk812/technologies_white_paper09186a008022bde8.shtml