mikä on Verkkoliikennevirta?

Verkkoliikennevirrat (virtaukset) ovat hyödyllisiä rakennettaessa karkearakeista ymmärrystä Tietokoneverkon liikenteestä, joka tarjoaa kätevän yksikön liikenteen mittaamiseen ja/tai käsittelyyn.

virtoja voidaan mitata, jotta voidaan ymmärtää, mitä isännät puhuvat verkossa, osoitteiden, määrien ja liikennetyyppien tiedot. Tämä verkon näkymä voi olla hyödyllinen vianmäärityksessä, tietoturvahäiriöiden havaitsemisessa, suunnittelussa ja laskutuksessa

, mutta mikä on virtaus ja miten se määritellään?

tämä kysymys Kuulostaa triviaalilta vastattavaksi, mutta syvemmältä kaivauduttaessa löydämme vivahteita ja kulmatapauksia, jotka tekevät virtauksista kiinnostavia ja lopulta vaikeasti määriteltäviä.

Tausta

voidaksemme todella ymmärtää virtauksia, meidän on aloitettava jostain taustasta.

verkot alkoivat piirikytkettyinä. Kun isäntä halusi kommunikoida toisen isännän kanssa, se pyysi verkkoa perustamaan piirin. Kun tiedonkulku oli päättynyt, piiri purettiin.

Kuva 1-Esimerkki Piirikytkentävillä verkoilla

Piirikytkentävillä verkoilla on perintönsä puhelinverkoissa. Niillä on useita haittoja, kuten huono skaalautuvuus ja alhainen kapasiteetin käyttöaste.

tarvittiin vaihtoehto, jonka avulla voitiin rakentaa lopulta Internetpakettikytkentäisiä verkkoja. Viestit pilkotaan vaihtelevan kokoisiksi paloiksi, jotka osoitetaan yksittäin ja lähetetään paketteina eri puolille verkkoa.

kuva 2-Esimerkki pakettikytkentäinen Verkko

vastaanottava isäntä kokoaa paketeista tulevan hyötykuorman takaisin viestiin. Huomautus: paketit voivat sisältää myös ohjaustietoja, kuten virtauksen ohjausta ja polkujen ei tarvitse olla symmetrisiä.

virtojen määrittely piirikytketyssä verkossa on helppoa, koska piiri on virtaus ja noudattaa protokollaa muodostaakseen ja poistaakseen (piiri = virtaus); pakettikytketyssä verkossa asiat ovat kuitenkin vähemmän ilmeisiä.

Kuvittele sekunti, että olet Kuvan 1 piirikytkentäisessä verkossa havaintopisteessä A, näkisit:

kuva 3-Lähennä Piirikytkettyyn verkkoon

kaksi virtaa havaittaisiin-virtapiirit isäntäverkkojen 3 & 4 ja 5 & 6 välillä. Virtojen tarkkailu piirikytketyssä verkossa on suhteellisen helppoa, koska verkko on mukana piirien perustamisessa, joten tietää niiden tilan ja päätepisteet.

Kuvittele nyt, että olet Havainnointipisteessä a Kuvan 2 pakettikytkentäisessä verkossa, näkisit:

Kuva 4-Zoom in on Packet-Switched Network

Suddenly things are less clear. On paketti tulossa isäntä 5 tarkoitettu isäntä 6. Olettaen, että tarkkailemme jonkin aikaa näemme enemmän paketteja saapuvan ja lähtevän. Virtojen tarkkailu pakettikytkentäisessä verkossa vie aikaa ja vaatii pakettitietojen tallentamista ja analysointia.

ensimmäinen (naiivi) yritys määritellä virtaus

käyttäen pakettikytkettyjen verkkojen tuntemustamme, ensimmäinen yritys vastata “mikä on virtaus” voi olla:

a-virtaus on sarja paketteja, jotka kuljettavat tietoa kahden isännän välillä

tämä määritelmä näyttää:

kuva 5 – Ensimmäinen yritys määritellä virtaus

on kuitenkin ongelma. Mitä tapahtuu, jos isäntien välillä tapahtuu useampaa kuin yhtä tietoliikennetyyppiä, esimerkiksi A: lla on SSH-ja HTTPS-yhteys B: hen? Ovatko SSH – ja HTTPS-paketit osa samaa virtaa? Intuitiivisesti sanomme ei, ne ovat eri istuntoja, ja jopa täysin erilaisia protokollia. Voimme tehdä paremmin…

toinen yritys määritellä

mitä jos käyttäisimme pakettiotsikoiden protokollatietoja yleisinä ominaisuuksina tunnistaaksemme paketit virtoihin? Tämä erottaa erityyppiset yhteydet eri virtoihin.

suuri osa verkon paketeista on todennäköisesti IP layer-3-protokollaa, jossa TCP tai UDP on layer-4-siirtoprotokolla. Siksi on järkevää harkita TCP-ja UDP-parametrien käyttöä pakettiotsikoiden virtausavaimina.

käytämme 5 parametria pakettien otsikoista; lähde IP, kohde IP, protokolla, TCP – tai UDP-lähdeportti ja TCP-tai UDP-kohdeportti tilattuna luettelona, joka tunnetaan yleisesti nimellä 5-tuple, yhteisinä ominaisuuksina pakettien kartoittamiseksi virtoihin.

kuva 6-esimerkki 5-tuple

tässä menee yritys 2:

virtaus on kahden isännän välistä tietoa kuljettavien pakettien sarja, jossa paketeilla on yhteisiä ominaisuuksia:

• kaikki virrassa olevat paketit jakavat saman 5-tuplen

skenaariomme näyttää nyt tältä.:

Kuva 7 sekunnin yritys määritellä virtaus

Perfect you say. Elämä on hyvää. Meillä on määritelmä virtaukselle, ei muuta nähtävää, – mutta hetkinen, entä pakettien suunta?

kolmas yritys-kaksisuuntainen

a 5-tupla on yksisuuntainen (yksisuuntainen). Oletuksena se vastaa vain yhteen suuntaan matkaavia paketteja, koska päinvastaiseen suuntaan suunnatuissa paketeissa on transponoitu IP-osoitteet ja porttinumerot, ja siten erilainen 5-tuple hash.

on hyviä syitä pitää virtoja kaksisuuntaisina eikä yksisuuntaisina, mukaan lukien kyky määrittää asiakkaan/palvelimen käyttäytyminen ja laskea edestakaiset ajat sekä parantaa tietoturvaloukkausten, kuten skannauksen, havaitsemista.

tarkastellaan yksinkertaista TCP-yhteyttä kuvassa 8, jossa paketit pomppivat edestakaisin isännän a & B välillä:

Kuva 8-Tikkakaavio yksinkertaisesta TCP-virrasta

näemme klassisen TCP: n 3-suuntaisen kädenpuristuksen (SYN, SYN+ACK, ACK), jota seuraa tiedonvaihto. Yksisuuntainen virtausanalyysi verkon havaintopisteessä näkisi kaksi erillistä virtausta, yhden per suunta, kuvan mukaan 9:

Kuva 9-yksisuuntaiset tikkaat yksinkertaiselle TCP-virtaukselle

yksisuuntaisen virtausmittauksen ongelma on, että menetämme mahdollisuuden tallentaa joitakin tärkeitä metatietoja virtauksesta. Toki jokainen yksisuuntainen virtaus voi tallentaa suunnattuja metatietoja tavuille ja paketeille tuohon suuntaan. Tähän voi sisältyä pakettien välinen ajoitus (KS.merkityt pisteet kuvassa 9). Mutta menetämme mahdollisuuden kerätä metatietoja, jotka edellyttävät liikenneparametrien mittaamista molempiin suuntiin.

ota kaksisuuntainen havainto huomioon kuviossa 10:

Kuva 10-kaksisuuntaisten havaintojen tikkaat yksinkertaiselle TCP-virtaukselle

voimme nyt tarkkailla ja mitata TCP: n 3-suuntaista kättelyä (pisteet F1, B1, F2) ja tarkastella muita mittareita, kuten vasteaikoja.

kaksisuuntaisiin virtoihin tarvitaan kaksi 5-tuplea,joista toinen kääntää sekä IP-osoitteiden että porttinumeroiden tuplejärjestyksen. Alla on esimerkki SSH virtaus eteenpäin ja taaksepäin 5-tuples:

Kuva 11-5-tuplen kääntäminen

oikein, se ei ollut kovin vaikeaa. Mutta odota, pieni yksityiskohta vaanii, joka vaatii lisää huomiota. Mistä tiedämme, mikä on virtauksen suunta eteenpäin? Määritämme suunnan ensimmäisen havaitun paketin perusteella, jonka oletetaan matkustavan asiakkaan palvelimen suuntaan, mutta tämä ei tule olemaan 100% luotettava, koska paketit voivat olla epäkunnossa ja/tai havainto voi alkaa osittain läpi virtauksen. Käytämme tätä menetelmää, mutta täytyy muistaa, kun katsomme tuloksia, että se ei ole täydellinen.

vaihtoehtoinen menetelmä on kuljetusprotokollan kenttien tarkastaminen. Esimerkiksi TCP: ssä pelkän syn-lipun läsnäolo on kohtuullinen indikaattori siitä, että paketti on ensimmäinen virrassa.

määrittelymme virralle on nyt:

virtaus on kahden isännän välistä tietoa kuljettavien pakettien sarja, jossa paketeilla on yhteisiä ominaisuuksia:

• kaikki virrassa olevat paketit jakavat saman 5-tuplen tai transponoidun 5-tuplen

neljäs yritys-mukaan lukien ei-TCP IP-liikenne

tähän asti olemme olettaneet, että siirtoprotokolla on TCP. Entä muut IP-protokollat?

UDP on ilmeinen valinta toiseksi yleisimmäksi kuljetusprotokollaksi, erityisesti reaaliaikaisen liikenteen noustessa UDP: n yläpuolelle sekä uusien protokollien, kuten QUIC: n, myötä. UDP sopii helposti samaan malliin kuin se on lähde-ja kohdeportti numerot, kuten kohti QUIC esimerkki alla:

Kuva 12-UDP 5-tuplen (sama kuin TCP) kääntäminen

Stream Control Transmission Protocol (SCTP) on toinen siirtoprotokolla, joka käyttää porttinumeroita ja toimii siten 5-tuplen kanssa.

mutta entä muut protokollat, esimerkiksi IPsec?

IPsec ESP (encapsulating Security Payload) on protokolla, joka ei sisällä lähde-/kohdeportin numeroita, joten meidän on palattava 3-tupleen, koska protokollan hyötykuorman ymmärtäminen ei todennäköisesti ole käytännöllistä.

kuva 13-kaksisuuntainen 3-Tuple

määritelmämme virralle on nyt:

virtaus on kahden isännän välistä tietoa kuljettavien pakettien sarja, jossa paketeilla on yhteisiä ominaisuuksia:

• siirtoprotokollille, joissa on porttinumero (ts. TCP / UDP / SCTP)):

kaikki virrassa olevat paketit jakavat saman 5-tuplen tai transponoidun 5-tuplen

else:

kaikki virrassa olevat paketit jakavat saman 3-tuplen tai transponoidun 3-tuplen

on kuitenkin vielä yksi huomioon otettava tekijä – aika.

viides yritys-virtauksen Päättyminen

virtaus on olemassa vain tietyn ajan. On mahdollista, että samaa 5-tuplea (tai 3-tuplea) voitaisiin käyttää uudelleen eri ajankohtana, eri virtaukseen, samojen isäntien välillä.

tarkastellaan kahta isäntää, joissa toinen käynnistää monia uusia TCP-yhteyksiä toiseen. Jokainen uusi TCP-yhteys saa uuden lähdeportin, jota korotetaan yleensä 1: llä edellisestä jaosta. IANA jakaa vaihteluvälin 49152-65535 näille lyhytaikaisille porteille, jolloin saadaan 16384 porttia. Ajan myötä TCP-lähdeportti rullaa alueen läpi ja alkuperäistä lähdeporttia käytetään uudelleen, ja tämä virtaus on sama 5-tuple kuin alkuperäinen virtaus. Tämä on ongelma, koska se ei ole sama virtaus!

tämän ratkaisemiseksi tarvitsemme vanhentuneita virtoja, joissa paketteja ei näy yli tietyn ajan. Here we go again:

a flow on kahden isännän välistä tietoa kuljettavien pakettien sarja, jossa paketeilla on yhteisiä ominaisuuksia:

• siirtoprotokollille, joissa on porttinumero (ts.TCP / UDP / SCTP):

kaikki virrassa olevat paketit jakavat saman 5-tuplen tai transposoidun 5-tuplen

muu:

kaikki virrassa olevat paketit jakavat saman 3-tuplen tai transposoidun 3-tuplen

• kaikki pakettien väliset ajat ovat vähemmän kuin mielivaltainen virtauksen päättymisaika

kuudes yritys-mielivaltaiset parametrit

joskus saatat haluta erilaisia parametreja virtojen tunnistamiseksi, tai nämä voidaan pakottaa sinulle verkon laitteiston/ohjelmiston tyypin mukaan.

esimerkiksi Ciscon reitittimessä virrat tunnistaa 7-Tuplesta, joka lisää standardin 5-Tupleen palvelutyypin (ToS) ja syötteen aliliitännän. Voi myös olla tilanteita, joissa tason 2 kentät, kuten lähde tai kohde MAC-osoite, voivat olla järkeviä virtausavaimina (vaikkakin huomaa, että ne ovat vain paikallisesti merkittäviä).

on muitakin parametreja, joita voitaisiin käyttää yhteisinä ominaisuuksina virtausten tunnistamisessa; Viime kädessä on toiminnanharjoittajan päätettävissä ja laitteiden ominaisuudet. Tämän pohjalta tarkennamme määritelmää:

a-virtaus on kahden isännän välistä tietoa kuljettavien pakettien sarja, jossa paketeilla on yhteisiä ominaisuuksia:

• siirtoprotokollille, joissa on porttinumero (ts.TCP / UDP / SCTP)):

kaikki virrassa olevat paketit jakavat saman 5-tuplen tai transposed 5-tuplen

else:

kaikki virrassa olevat paketit jakavat saman 3-tuplen tai transposed 3-tuplen

• kaikki pakettien väliset ajat ovat vähemmän kuin mielivaltainen virtauksen päättymisaika
• voivat käyttää mitä tahansa mielivaltaisia parametreja virtausavaimina, mukaan lukien ToS, käyttöliittymä jne.

kaiken paketointi

olemme osoittaneet, että yhden kaikenkattavan virtausmääritelmän tuottaminen on vaikea ongelma. Virtausmäärittely on toteutuskohtainen, riippuu käyttäjien vaatimuksista sekä virtoja mittaavien verkkolaitteiden kyvyistä.

tämän blogikirjoituksen osassa 2 käsitellään tarkemmin virtoja, kuten IPv6 – virtausmerkintöjä, pirstoutumista (IPv4 ja IPv6-ongelma..), salaus, ei-IP-paketit ja miten virtoja mitataan ja käytetään muissa järjestelmissä, kuten SDN.

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

joidenkin asiaan liittyvien asiakirjojen osalta katso: 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 ja https://is.muni.cz/th/hilnn/cse2009.pdf

RFC: n osalta katso: https://tools.ietf.org/html/rfc5103

lisätietoja QUIC: n standardoinnista, KS.: https://datatracker.ietf.org/wg/quic/about/

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