KANDÓ KÁLMÁN VILLAMOSMÉRNÖKI KAR HÍRADÁSTECHNIKA INTÉZET Infokommunikációs Hálózatok laboratóriumi mérési útmutató IPv4 csomagok vizsgálata Wireshark analizátorral I.
Tartalomjegyzék Hálózati forgalom vizsgálata a Wireshark hálózatelemző programmal... 2 IPv4 Internet Protocol fejléc... 3 IPv4 fejléc mezők... 3 ICMP üzenetek... 7 A Wireshark használata... 8 Szűrési lehetőségek... 10 Mérési feladatok... 11 Hálózati forgalom vizsgálata a Wireshark hálózatelemző programmal A hálózatokon kommunikáló számítógépek adatforgalmának vizsgálata több szempontból is hasznos lehet: - hálózati hibák deríthetők fel; - magasabb rétegbeli protokollok vizsgálata során ellenőrizhető egy alkalmazás által ténylegesen küldött és fogadott adathalmaz; - jobban megérthető a hálózati protokollok működése. A nagy adatátviteli sebesség miatt a valós idejű vizsgálat gyakorlatilag lehetetlen, így mindenképpen érdemes a kívánt adatforgalmat rögzíteni, majd az így előállított adathalmazt megfelelő eszközzel elemezni. Napjaink legnépszerűbb hálózati technológiája az Ethernet, ezért az ilyen hálózatok vizsgálatára rengeteg megoldás áll rendelkezésünkre. Ezek egyike a Wireshark nevű adatgyűjtő és elemző program, ami többféle operációs rendszer alatt használható. A Wireshark két fő részből áll: a hálózati csatolón áthaladó adatokat begyűjtő és tároló modulból, valamint a vizsgálatokat lehetővé tevő felhasználói interfészből. A két modul párhuzamosan is működhet, vagyis az adatok rögzítése alatt a már begyűjtött keretek vizsgálhatók. A kívánt keretek, csomagok kiválogatására rugalmas és jól használható szűrési lehetőségek állnak rendelkezésre. A mérés célja a Wireshark alapfokú használatának és a TCP/IP protokollgyűjtemény működésének megismerése. A mérési feladatok ezen mérési útmutató végén helyezkednek el,
a következőkben megadjuk a mérés elvégzéséhez szükséges elméleti alapok rövid összefoglalóját. IPv4 Internet Protocol fejléc Az IP címek kezelése, valamint a csomagok IP cím alapján történő irányítása az OSI rétegmodell szerint a 3. rétegben (hálózati network layer ) valósul meg. A kapcsolást végző protokoll, úgynevezett megbízhatatlan kategóriába sorolt, hiszen maga a kapcsoló protokoll garanciát nem vállal arra, hogy a csomagok a cél állomáshoz rendben, sorrendhelyesen és hibamentesen megérkezzenek. A hibajavítás (ha ez szükséges) általában a felsőbb rétegekben valósul meg (például a szállítási rétegben működő TCP végzi el). A továbbítandó adatelem (datagram) a hálózati rétegben egy fejlécet kap (beágyazódik egy IP csomagba), mely IPv4 esetén a következőképpen néz ki: 4 bit 4 bit 8 bit 8 bit 8 bit Version IHL Type of service Total Length Identification Flags Fragment offset Time to Live Protocol Header Checksum Source IP address Destination IP address Option Padding DATAGRAM IPv4 fejléc mezők A Version mező (4 bites hosszúságú) hordozza a verziószámot, ami IPv4 esetén a 4-es értéket kapta (bináris 0100 ). IHL IP Header Length mező adja meg az IP fejléc hosszát. A fenti ábra nem szemlélteti, de az IP fejléc Option mezője változó hosszúságú lehet. Az IHL értéke 5 15 közé eső szám lehet, és azt mondja meg, hogy az IP fejléc mennyi 32 bites szóból áll (a szükséges
mezők mérete miatt a minimum érték 5, a 4 biten ábrázolható legnagyobb érték pedig 15 lehet, ami 60 byte limitet jelent). A Type of Service mező jelentése menetközben megváltozott (talán helyesebb, ha azt mondjuk, hogy kibővült). A napjainkban használatos elnevezés a Differentiated Services, vagyis DS, amiben egy 6 bites érték, a Differentiated Services Code Point (DSCP) határozza meg a csomag kezelésének módját. A DS tartalmára vonatkozó előírásokat az RFC3168 határozza meg. Korábban ebben a mezőben (Type of Service) lehetett jelezni azt, hogy az adott csomag úgynevezett normál, vagy hálózatvezérlő csomag-e. Ennek jelentése a szolgáltatás-osztály azonosítása, mely alapján a csomagtovábbítás priorizálható, így szolgáltatásminőség (Quality of Service) biztosítására is van lehetőség. A Total Length mező adja meg a teljes csomagméretet byte mértékegységben (ebbe az IP Header is beletartozik). A mező 16 bites, így a csomag maximális mérete 65535 byte, vagyis 64 kbyte-1 byte lehet.. Az Identification mezőt elsődlegesen az eredeti IP datagram töredékeinek (fragmentjeinek) beazonosítására használjuk, amennyiben a datagram továbbítása csak kisebb méretű töredékekben volt lehetséges. A Flags nevű mező három jelzőbitet tartalmaz és az úgynevezett fragmentálással kapcsolatos. Itt talán célszerű megállnunk és áttekintenünk, hogy mi az, és miért szükséges a fragmentálás! Az eljárás során a továbbítandó csomagot darabokra vághatjuk. Erre azért lehet szükség, mert az egyes útirányok átvitel technikai jellemzői (leginkább a bit hibaarány érdekes most) különbözők lehetnek. Abban az esetben, ha a bit hibaarány (hibás bitek/összes átvitt bitek aránya) érték azt mutatja, hogy egy adott keretben igen nagy valószínűséggel előfordul hibás bit, és a hibajavítást újraküldéssel kívánjuk megoldani, akkor az átvitel ellehetetlenedik. Példaképpen vizsgáljunk meg egy 64 kbyte méretű csomagot (65536 bitből áll). Amennyiben ezt a méretű csomagot olyan átviteli útra irányítanánk, mely 2 10 5 BER jellemzőt mutat (vagyis a bithibák egyenletes eloszlását feltételezve minden ötvenezredik bit meghibásodik), akkor az átvitel lehetetlenné válik. Viszont, ha ezt az átküldendő csomagot tíz részre bontjuk, akkor az egymás után küldött csomagok közül nagy (előzőnél nagyobb) valószínűséggel csak egy vagy kettő fog meghibásodni, mely hibák a hibás csomagok újraküldésével már javíthatók.
Bizonyos átviteli technológiák a keretszervezésük során (ami az OSI rétegmodell szerinti második rétegben történik) figyelembe veszik a fizikai közeg jellemzőit. Például Ethernet esetében ez 1500 byte, vagyis 12 000 bit. Amennyiben a csomagunk egy ilyen hálózat felé irányítódik, a tördelés (fragmentálás) elkerülhetetlen. A kapcsoló eszközökben az egyes irányokra (interfészekre) vonatkozó maximális hosszt az MTU (Maximum Transmission Unit) tartalmazza. Az MTU byte-okban adja meg a maximális méretet. Miután tisztáztuk a csomag-tördelés szükségességét, nézzük meg a konkrét Flag bitek jelentését! A 0. bit értéke fix 0, további fejlesztésekhez tartották fenn. Az 1. bit a DF (Don t Fragment). Abban az esetben, ha ezt a bitet 1 -be állítjuk, az azt jelenti, hogy a csomag tördelése nem megengedett. Ekkor, ha a csomagunk olyan irányba menne, ahol a tördelés elkerülhetetlen, akkor a csomagot a kapcsoló eszköz el fogja dobni és a feladót egy ICMP Destination Unreachable típusú üzenettel értesíti ( Fragmentation needed and DF set kód). A 2. bit elnevezése MF (More Fragment). Abban az esetben áll ez a bit 1 értéken, ha a csomagunk feldarabolt és a most érkező csomagot még további töredék csomag követi. Az utolsó töredék csomag esetén ez a bit már 0 -ban áll. Ezt a bitet a tördelést végző eszköz állítja be. A Fragment offset mező szintén a tördeléssel kapcsolatos, 13 bit hosszúságú, és 8 byte (64 bit) egységekből álló blokkokban adja meg az adott töredék helyét (offset-jét) a teljes IP csomagon belül. Az első töredék esetében ez a mező összes bitje 0 -ban áll. Példaként vizsgáljuk meg a következő esetet: Egy 4500 byte hosszúságú datagrammot, amely 20 byte-os IP fejléccel rendelkezik, az útválasztó eszköz egy olyan interfész felé irányítja, melynek MTU értéke 2500 (vagyis maximum 2500 byte méretű lehet a továbbított csomag). Abban az esetben, ha a DF bit 1 értékű, akkor a csomagot az útválasztó eldobja; Abban az esetben, ha a DF bit 0 értéken áll, akkor az eszköz a csomagot jelen esetben két részre fogja bontani. Az első csomag az IP fejléccel együtt 2500 byte méretű lesz (első fragment datagram mérete 2480 byte), a Fragment offset = 0000000000000, míg az MF bit 1 -ben fog állni. A második töredék csomag mérete 2020 byte, melyből a datagram mérete
2000 byte és a fejléc pedig ismét 20 byte (az eddigi összes IP fejlécben nulla Option mezőt feltételeztünk). Ebben a csomagban az MF bit 0 -ban áll, míg a Fragment offset a decimális 310 értéket (2480/8) tárolja. Fontos megemlíteni, hogy egy fragmentált csomagot a köztes útválasztó eszközök nem állíthatnak újra össze, ez a feladat a címzett végpontra marad. A csomagok tördelése rengeteg biztonsági problémát vet fel (például a teljes csomagon kívülre mutató Fragment Offset érték, egymást átlapoló töredékek), ezért az IPv6 nem tartalmazza ezt a funkciót. A Time to Live TTL egy 8 bites mező, amely eredetileg a csomag hálózati továbbítás során eltölthető idejét tartalmazta másodperc mértékegységben, maximális értéke 255 lehet. Minden útválasztó eszköz levonja belőle a továbbításhoz szükségessé vált időt, és ez nullára csökken, akkor a csomagot eldobja. Emellett azonban az is kikötés, hogy a TTL mező minden routolásnál eggyel csökkenjen. Mivel a tipikus útválasztási idő kevesebb, mint 1 másodperc, ezért általánosságban ez az érték a továbbítási lánc maximális hosszát definiálja (szokás ezért Hop-count -nak is nevezni). A mező feladata az, hogy segítségével az eltévedt (például végtelen továbbítási hurokba került) csomagok automatikusan törlődjenek egy idő múlva és ne bolyongjanak a hálózatban végtelen ideig, a hasznos sávszélességet csökkentve. A Protocol mező hordozza azt az információt, hogy az adott IP csomag milyen protokoll szerinti információt (jelen esetben a Datagram -ról van szó) hordoz. Az RFC1700 értelmében a mező néhány értékét és annak jelentését adjuk meg: 1 ICMP; 2 IGMP; 6 TCP; 7 UDP. A Header Checksum segítségével a fogadó oldal képes ellenőrizni az IP fejléc hibátlanságát. Ez a mező 16 bites, és minden útválasztó berendezésnek ezt az értéket újra kell számítania, mert a TTL mező csökkentése új ellenőrző mező tartalmat igényel. Az ellenőrző összeg számítás módját az RFC 1071 írja elő. A Source IP address a forrás állomás (küldő), míg a Destination IP address a cél állomás (címzett) IP címe ami IPv4 esetén mindkét mezőben 32bit.
Nem szabad elfelejtenünk azt, hogy az IP hálózatban megjelenő csomagok esetén a Source IP address nem minden esetben a konkrét küldő címe! A magán hálózatról indított csomag esetében a nem publikus IP cím átfordításra kerül (NAT Network Address Translation). Az Option mező jelenléte nem kötelező, mint a nevében benne szerepel, opcionális. Abban az esetben, ha az IP keret tartalmaz Option mezőt, akkor az IHL > 5 értéken áll. Az Option mező hosszúsága változó lehet, ezért a végén egy byte lezáró kódnak kell szerepelnie, ami minden esetben 0x00 tartalmú byte (End of Option List lezáró karakternek is szokás nevezni). A Padding mező feladata mindössze annyi, hogy az Option mezőt kiegészítse 32 bit egész számú többszörösére (gondoljunk az IHL mező jelentésére). ICMP üzenetek Általában a Host-ok (állomások) közti datagram átvitelre az Internet Protokollt (IP-t) használjuk, amely képes különböző hálózatok közti kommunikáció biztosítására is. A hálózatok között az útválasztó eszközök (routerek) teremtik meg a kapcsolatot. Az együttműködő eszközök közti szervizüzenetek számára alkották meg az ICMP-t (Internet Control Message Protocol). Az ICMP-t az RFC792 ajánlás definiálja, a harmadik (hálózati) rétegben működő protokoll, minden IP implementáció köteles ezt is megvalósítani. Az ICMP Header az IPv4 Header után következik, ekkor az IP fejléc Protocol mező 1 értéket kap. Az IP csomag adatmezőjében (payload) találjuk az ICMP fejlécét és az esetleges adattartalmát (emiatt úgy tűnhet, hogy az ICMP a negyedik réteg protokollja, de mégis a harmadik rétegbe sorolják). 8 bit 8 bit 8 bit 8 bit Type Code Checksum ID Sequence Az operációs rendszerekben jól ismert PING parancs hatására is egy ICMP üzenet kerül kiküldésre (Echo request; Echo Reply), de a hálózat működése során keletkező eseményekről is ICMP üzenetekkel értesítik egymást a hálózat tagjai.
A Wireshark használata A program a méréshez használatos számítógépeken (Ubuntu Linux), az ikonjára kattintva indítható el. Indulás után a kezdőképernyő fogad: A listából választható ki az az interfész, amelyik forgalmát szeretnénk megfigyelni. Az interfészt kiválasztva azonnal megkezdődik a forgalom rögzítése, ez megszakítható a státuszsor alatti ikoncsíkon található megfelelő ikonra kattintva, vagy a Capture menü Stop menüpontjával. Az ikoncsík ikonjai fölé mozgatva, majd ott tartva a kurzort a program megjeleníti az ikonhoz kapcsolódó funkció nevét: - Start capturing packets: elindítja a rögzítést. - Stop capturing packets: a folyamatban levő rögzítést állítja le. - Restart current capture: újraindítja az aktuális rögzítést. - Capture options: a rögzítés paramétereit állíthatjuk be.
A rögzített tartalom a képernyőn látható, természetesen némi késéssel. A mezők jelentése: - No: a keret sorszáma. - Time: a rögzítés kezdete óta eltelt idő. - Source: a forrás címe (harmadik rétegbeli cím). - Destination: a célpont címe (harmadik rétegbeli cím). - Protocol: a csomagban szállított magasabb rétegbeli protokoll azonosítója. - Length: a csomag hossza. - Info: rövid összefoglaló a csomag főbb tulajdonságairól. A lista alatt található a kijelölt csomag részleteit tartalmazó mező (Packet details), alul a csomag tartalma 8 bites egységekben, tizenhatos számrendszerben ábrázolva, felette pedig rétegenként dekódolva, logikai egységekre bontva. Az egyes rétegek lebonthatók, a rétegbeli fejlécek mezői külön-külön is vizsgálhatók. A mezők adatait tartalmazó sorra kattintva a
Wireshark kiemeli a mezőt alkotó byte-okat, így könnyen azonosítható a helyük a csomagon belül. Szűrési lehetőségek A begyűjtött csomagok között szűrésre is lehetőség van, logikai kifejezések használatával. Ezeket a Filter sorában lehet megadni, az Expression gombra kattintva lehet válogatni a lehetséges mezőnevek között. Például az ICMP üzenetek listázása elvégezhető az ip.proto==1 kifejezéssel (minden olyan IP csomagot megjelenít, amelyeknek protocol mezője 1 értékű, vagyis minden ICMP csomag megjelenik). A feltételt tovább is lehet szűkíteni: ip.proto==0x01 && icmp.type==8 Ekkor az ICMP üzenetek közül csak a 8-as típuskódúak jelennek meg (ez az Echo request üzenet, amit a ping parancs küld). Az IP csomagok cím szerinti szűrésére az ip.addr==x.x.x.x szintaktika használható.
Mérési feladatok 1. Indítsa el a Wiresharkot, tanulmányozza használatát! 2. Nyisson egy terminált a Linux számítógépen, majd a Wireshark grafikus felületén indítson el egy capture folyamatot. A terminálban indítsa el: ping 10.11.12.1 3. A ping parancs ICMP echo request üzeneteket fog küldeni a kijelölt IP című végpontnak, az pedig ICMP echo reply üzenetekkel fog válaszolni. Készítsen szűrőfeltételt a megadott IP címre tartó vagy onnan visszaérkező csomagokra! Vizsgálja meg a csomagokat, értelmezze a fejlécben található mezőket! 4. Határozza meg a távoli eszköz MAC címét a csomagok vizsgálatával, majd készítsen szűrőt, ami ezeket a kereteket szűri a második rétegben (eth.addr)! Magyarázza meg a lejátszódó folyamatot (ARP címfeloldás, echo request, echo reply üzenetek)! Amennyiben az ARP már korábban felderítette a távoli végpont mac címét, keressen másik végpontot a helyi hálózaton belül (10.11.12.2-10.11.12.13)! 5. Indítson újabb rögzítést, majd indítson el egy IP cím újrakonfigurálási kérést a Linux Network Manager segítségével (jobb felső sarokban hálózati ikon, majd Disconnect ). Ekkor egy DHCP release folyamat fog lezajlani. Gyűjtse ki a DHCP üzenetváltás csomagjait, majd magyarázza el ezek alapján a folyamat lényegét. Figyelje meg, milyen adatok érkeznek a szervertől! 6. Igényeljen újabb IP címet a DHCP szervertől (hálózat ikon, majd Auto menüpont). Szűrje ki a DHCP üzenetváltást (például a saját MAC címre alapozva), és figyelje meg az egyes üzeneteket! 7. Vizsgálja meg az IP protokollverem nyomkövetési lehetőségeit! Ehhez használja a traceroute majd a tracepath parancsokat. Indítsa el a Wiresharkban a forgalom
rögzítését, majd a terminálablakban írja be: traceroute 8.8.4.4. A 8.8.4.4 IP címen a Google egy nyitott DNS szervere található, a traceroute ugrásonként (hop) követi a csomag útját. Állítsa meg a capture folyamatot, majd szűrje le a 8.8.4.4 címre induló és az onnan érkező csomagokat. Nézze végig a parancs által generált, és kapott válaszcsomagokat, a Wireshark rétegvizsgálójának segítségével magyarázza el a működést! 8. Ismételje meg az előző mérést a tracepath parancs használatával is! Hasonlítsa össze a kétféle algoritmust, ismertesse a különbségeket!