Department of Software Engineering

Átírás

1 Tavasz 2017 UNIVERSITAS SCIENTIARUM SZEGEDIENSIS UNIVERSITY OF SZEGED Department of Software Engineering Számítógép-hálózatok 4. gyakorlat Wireshark, DNS Jánki Zoltán Richárd S z e g e d i T u d o m á n y e g y e t e m

2 Tartalomjegyzék Bevezetés... 3 DNS (Domain Name System)... 3 Azonosítás... 3 Működése... 3 További DNS szolgáltatások... 4 DNS szerverek hierarchiája... 4 Centralizált adatbázis... 4 Elosztott, hierarchikus adatbázis... 4 DNS rekordok és üzenetek... 6 Gyakorlati háttér... 7 nslookup parancs... 7 ipconfig parancs... 9 Szűrés DNS csomagokra... 9 Capture filter... 9 Display filter Munka az elfogott csomagokkal Ellenőrző kérdések Források

3 Bevezetés Ezen a gyakorlaton ismét az alkalmazási réteggel foglalkozunk, azon belül is egy újabb ott működő, érdekes protokollal ismerkedünk meg, mely a DNS (Domain Name System) névre hallgat. Lássuk, mi is ez, és hogyan működik! DNS (Domain Name System) Azonosítás Induljunk ki egy valós életbeli példából! Az emberek azonosítására számos lehetőség ismert. Például, ez lehet az adott személy neve, TAJ-száma, személyi igazolványának száma vagy a vezetői engedélyének száma (ha rendelkezik ilyennel). Az, hogy a felsoroltak közül melyiket használjuk, csupán a kontextustól függ. Például egy sürgősségi betegellátás esetében a vezetői engedély száma nem releváns információ a betegkezelőnél, mert a rendszer nem tud ezzel az információval mit kezdeni. A kontextusnál maradva, egy személy neveként pedig igen furcsán mutatna egy TAJ-szám. ("Szia! Engem nak hívnak.") Hasonlóképp az Interneten megtalálható host-ok is sokféleképp azonosíthatóak. Egy azonosítási forma lehet a host neve (pl.: Ezek a felhasználók számára is könnyen értelmezhetőek, azonban számos információ elrejtésre kerül. Nem tudunk semmit a host helyéről (pl.: egy.hu-ra végződő oldalról könynyen megmondhatjuk, hogy magyar vonatkozása van, és jó eséllyel Magyarországon található). Mivel a host neve (hostname) változó hosszúságú alfanumerikus karakterekből áll, ez egy nehezen értelmezhető információ egy router számára. Ezért használjuk a host-ok azonosítására az ún. IP-címeket. Az IP-címekről később fogunk részletesen tanulni, egyelőre csak annyi legyen elég nekünk, hogy az IPv4-es címek 32 bitesek, melyeket decimális alakba átírva 4 db ponttal elválasztott számot kapunk, ahol minden decimális szám 0 és 255 közötti (pl.: ). Az IP-címek már sokkal pontosabb információt nyújtanak a host helyzetéről (hol található a hálózatok hálózatában). Mindkét azonosítási forma használatos, de más kontextusban. Az emberek számára a hostname a kézenfekvőbb, míg a router-ek számára az IP-címek. A kettőt közötti konverziót (fordítást) kell megoldani, melyet a DNS valósít meg. Működése A DNS egy elosztott adatbázis, amelyet DNS-szerverek hierarchiájában implementálnak. Ezzel egyidejűleg egy protokoll is, mely lehetővé teszi, hogy a host-ok lekérdezéseket indítsanak az adatbázis felé. A DNS főként más alkalmazási rétegbeli protokollok miatt kerül használatra (pl.: HTTP, SMTP, FTP). Egy HTTP-kérés esetén a felhasználó hostname szerint indítja a kérést, viszont azt át kell fordítani IP-címmé, hogy a kérés megérkezhessen a web-szerverhez. Lássuk ennek a folyamatát! 1. A felhasználói gép futtatja a DNS alkalmazás kliens oldalát. 2. A böngésző kiolvassa a host nevét az URL-ből, majd továbbítja az 1. pontban említett DNS alkalmazás kliensének. 3. A DNS-kliens küld egy lekérdezést a DNS-szerver felé, mely tartalmazza a kiolvasott host nevét. 3

4 4. A DNS-kliens fogadja a szerver válaszát, mely tartalmazza a host névhez tartozó IP-címet. 5. Amint a böngésző rendelkezik a DNS-től fogadott IP-címmel, képes kapcsolatot nyitni a web-szerverrel felé, illetve HTTP-kérést intézni az IP-címhez tartozó 80-as portra (a HTTP port számára). További DNS szolgáltatások A hostname - IP-cím fordításon kívül a DNS számos fontos szolgáltatást nyújt. Ezek közül néhányat említünk csak meg: Host aliasing: Egy host, amelyet egy bonyolult névvel láttak el, rendelkezhet egy vagy több alias névvel is. Ezeknek a célja, hogy használatuk és elérhetőségük egyszerűbb legyen (pl.: relay1.west-coast.enterprise.com helyett az egyszerűbb használat végett az enterprise.com-ot vagy a használjuk). Levelező szerver aliasing: Az előzőhöz hasonlóan itt is a kezelhetőségen van a hangsúly. Például, egy valaki@hotmail.com cím sokkal könnyebben megjegyezhető és használható, mint egy valaki@realy1.westcoast.hotmail.com cím. Terhelés elosztás: A sokak által látogatott oldalakról gyakran készítenek "másolatokat" több web-szerver fenntartásával. A különböző web-szerverek különböző IP-címekkel bírnak, de mégis azonos a host nevük. Egy DNS kérés következtében megkapjuk az összes listában szereplő IP-címet, és ezek közül kiválasztásra kerül az első. Azonban a lista elemeinek a sorrendje cserélődik, tehát eltérő web-szerverek felé fog indulni a HTTP kérés. DNS szerverek hierarchiája Centralizált adatbázis A jegyzet a hostname - IP-cím fordításra fókuszál, így az erre épülő architektúrát vizsgáljuk meg. A legegyszerűbb változat az lenne, ha egyetlen központi DNS szerver látna el minden DNS kérést, azonban azonnal látszik, hogy ez nem vezetne jóra. "Egy pont hibája": Ha leáll a DNS szerver, leáll az egész Internet. Forgalom méretének problémája: Egyetlen DNS szerver esetén eszközök százmilliói által generált kéréssorozatot kellene kielégíteni. Távoli centralizált adatbázis problémája: Egyetlen DNS szerver nem lehetne elég közel minden eszközhöz (pl.: egy DNS szerver New York-ban hatalmas késleltetéssel tudna csak kiszolgálni egy Ausztráliából indított kérést) Fenntarthatóság problémája: Egyetlen szerver esetén minden rekordot egy centralizált adatbázisban tárolnánk, ami nem csak hatalmas lenne, hanem azt állandóan frissíteni is kellene az új host-ok listájával. Összességében kijelenthetjük, hogy nem skálázható a gondolat. Ezért valósult meg elosztott, hierarchikus adatbázis segítségével. Elosztott, hierarchikus adatbázis A DNS szervereket három osztályba sorolhatjuk: gyökérponti (root) DNS szerverek: ezekből összesen 13 darab található a különböző földrészeken elosztva (2012-es információk szerint). 4

5 felső-szintű domain (top-level domain = TLD) szerverek: ezek felelősek a felső-szintű névtartományokért (domain-ekért), mint például com, org, net, edu, stb. autoritatív (mérvadó) DNS szerverek: a szervezetek céljait szolgálják ki, hogy publikus hozzáférést biztosítsanak saját web-szervereik, levelező szervereik, stb. eléréséhez 1. ábra DNS szerver hierarchia Ezek alkotják a hierarchiát, amelyet a fenti ábrán is láthatunk. Ezeken kívül egy ún. lokális DNS szerver csoportot is megkülönböztetünk, amely a hierarchiába szorosan nem épül be. A lokális DNS szerverek az ún. ISP-k által kerülnek meghatározásra (pl.: egyetemeknél). Ezek a szerverek tulajdonképpen proxy-ként üzemelnek, és továbbítják a kérést a DNS szerver hierarchia felé. 2. ábra DNS szerverek interakciója 5

6 A fenti példa bemutatja a DNS szerverek hierarchiájának működését, kiegészülve egy lokális DNS szerverrel. Vegyük végig ezt a példát! Tfh. a cis.poly.edu névre hallgató host szeretné megszerezni a gaia.cs.umass.edu IP-címét a kommunikáció érdekében. Továbbá legyen a Műegyetem lokális DNS szervere a dns.poly.edu és a gaia.cs.umass.edu autoritatív DNS szervere. A folyamat az alábbi: 1. A cis.poly.edu host küld egy DNS kérést az ő lokális DNS szerverének, a dns.poly.edu-nak. A kérés tartalmazza a gaia.cs.umass.edu host nevet, ugyanis az ehhez tartozó IP-címet szeretnénk megtudni. 2. A lokális DNS szerver továbbítja a kérést egy gyökérponti DNS szerver felé. A gyökérponti DNS szerver az edu végződés alapján megkeresi az összes ehhez tartozó TLD szerver címét, és visszaküld egy IP-cím listát a lokális DNS szervernek. 3. A lokális DNS szerverünk egy újabb DNS kérést küld, de ezt már a listában szereplő TLD szerverek valamelyikének intézi. 4. A TLD szerver fogadja a kérést, viszont ő már az umass.edu végződés alapján keres egyezést az adatbázisban. 5. A TLD szerver a válaszban visszaküldi a lokális DNS szerver számára a megfelelő autoritatív DNS szerver IP-címét (jelen esetben a Massachusetts-i Egyetem autoritatív DNS szerverének címét, a dns.umass.edu-ét). 6. Végül a lokális DNS szerver harmadjára is elküldi a DNS kérést, de már közvetlenül a dns.umass.edu-nak. 7. A dns.umass.edu autoritatív DNS szerver válaszol a gaia.cs.umass.edu IP-címével. 8. A lokális DNS szerver a fogadott IP-címet továbbítja a kérést indító host felé, a cis.poly.edu-nak. Ezt a folyamatot végignézve arra a következtetésre juthatunk, hogy egyetlen host eléréséhez 4 kérésre és 4 válaszra volt szükség, ami igen nagy forgalmat jelent. Ennek a problémának megoldására alkalmazzák a DNS cache-elési technikát. DNS rekordok és üzenetek A DNS szerverek együttesen valósítják meg azt az elosztott DNS adatbázist, amely tartalmazza a hostname - IP-cím párokat. A forrás rekordok egy négyes tuple-t (kvázi rendezett rekordsorozatot) alkotnak. A tuple-ben az alábbi mezők találhatóak meg: (Name, Value, Type, TTL). A TTL (time-to-live) mező határozza meg, hogy az adott forrás rekordot meddig szükséges a gyorsítótárban (cache-ben) tartani a gyors elérés végett. A Name és Value mezők a Type mező tartalmától függnek. Tekintsük meg ezeket! Type=A a Name mezőben a hostname található, a Value mezőben pedig a hostname-hez rendelendő IP-cím. Type=NS a Name mező tartalma egy domain név, a Value mezőé pedig az autoritatív DNS szerver host neve. Az autoritatív DNS szerver már képes lesz arra, hogy egy IP-címet visszafejtse az adott névtartományban (domainben). Type=CNAME a Value mező tartalmazza a teljes host nevet, ami a Nameben szereplő alias-hoz van rendelve. Type=MX a Value egy levelező szerver teljes host nevét tartalmazza, a Name pedig annak egy alias-át. 6

7 Gyakorlati háttér nslookup parancs Az nslookup parancs segítségével indíthatunk manuálisan DNS kérést egy adott web-szerverre vonatkozóan. Ez a parancs egyaránt működik Linux és Windows alatt is a terminálban. Az nslookup-ban megjelölhető egyaránt web-szerver, gyökérponti DNS szerver, TLD DNS szerver, autoritatív DNS szerver is. A parancs kimenete a DNS szerverről visszaérkező válasz. Nézzünk egy példát a DNS szerverére indított kéréssel. Az eredmény alább látható! 3. ábra nslookup parancs host névre A parancs: nslookup A válasz: 1. A válasz első része tartalmazza a kiszolgáló nevét és IP-címét, amely felelős a válaszért. Ez egy lokális DNS szerver, amelyet az SZTE Informatikai Intézete menedzsel (netid1.inf.u-szeged.hu, ). 2. A válasz második felében egy nem mérvadó (non-authoritative) választ kaptunk, ami annyit jelent, hogy a válasz valamely DNS szerver cache-éből került ki, nem pedig a Google autoritatív DNS szerverétől érkezett. A webszerver neve a megadott IP-címe pedig A Kiszolgáló mezőben a default lokális DNS szerver van megjelölve. Amennyiben nem specifikáljuk a DNS szervert, úgy az nslookup az alapértelmezett lokális DNS szerverhez fordul. Az nslookup paranccsal lehetőségünk van egy domain-hez tartozó autoritatív szerverek lekérdezésére. Ennek a megfelelő paraméterezése és eredménye a következő képen látható. 7

8 4. ábra nslookup parancs autoritatív szerverekre A parancs: nslookup -type=ns google.com A válasz: 1. A kiszolgáló mező tartalma továbbra is egy lokális DNS szerverre mutat. 2. A lényegi információ ismételten a "Nem mérvadó válasz:" részben található. 4 különböző szerver host nevét láthatjuk, amelyek mindegyike autoritatív DNS szerver, alatta pedig a hozzájuk társított IP-címeket. Tehát az nslookup parancs felparaméterezhető egy type mezővel, amelyben megadható, hogy milyen DNS kérést szeretnénk indítani. Értelemszerűen az NS érték lecserélhető akár CNAME-re, akár MX-re, stb. Az alapértelmezett érték az A szokott lenni, tehát ha nem használjuk a type mezőt a parancsban, akkor egy A típussal ellátott DNS kérést indítunk. Eddig mindig rábíztuk a DNS kérésünk kezelését az alapértelmezett lokális DNS szerverekre. Hogyan lehetne ezt megváltoztatni? Például, szeretném az web-szerverének IP-címét kideríteni, de ehhez most az SZTE egyik autoritatív DNS szerverét szeretném használni! Első körben le kell kérdezni az egyetemi autoritatív szerverek listáját. Ezt követően valamely listában szereplő szerver segítségével DNS kérést indítani a vonatkozóan. 8

9 5. ábra nslookup parancs konkrét kiszolgáló DNS szerverrel 1. parancs: nslookup -type=ns u-szeged.hu 1. válasz: Az egyetemnek 4 autoritatív DNS szervere van, ezek közül használjuk most a huni6.cc.u-szeged.hu-t. 2. parancs: nslookup huni6.cc.u-szeged.hu 2. válasz: Hasonlóképp megkaptuk a google.com web-szerverének az IP-címét, viszont a kiszolgáló módosult az általunk megadott egyetemi autoritatív DNS szerverére. Ezek után felállíthatjuk az nslookup parancs általános formáját: nslookup -option1 -option2 keresett-host dns-szerver Az opciókat mindig - jellel használjuk, ezt követően megadjuk annak a host-nak a nevét, amelynek az IP-címét szeretnénk megkapni, és végül megadjuk azt a kiszolgáló DNS szervert, amelytől a választ várjuk. ipconfig parancs Az ipconfig Windows alatt használható parancs. Linux alatt ifconfig használatos, de a kimenet ugyanaz mindkét esetben. A parancsot követően megkapjuk az egyes interfészeinknek az IP-címeit, DNS szervercímeket, stb. Egy részletesebb leírást kaphatunk az ipconfig /all parancs segítségével. A cache-ben levő DNS szerverek lekérdezhetőek az ipconfig /displaydns paranccsal. A tábla pedig kiüríthető az ipconfig /flushdns segítségével. Szűrés DNS csomagokra Capture filter Ha kizárólag DNS csomagokat szeretnénk elfogni a Wireshark programmal, akkor az interfész kiválasztásakor (a monitorozást megelőzően) meg kell adnunk 9

10 egy elfogási szűrőt (capture filter-t). A DNS kérés default esetben az UDP (User- Datagram Protocol) szállítási rétegbeli protokollt használja, úgyhogy erre fogunk szűrni! udp port 53 Elindíthatjuk a szűrést, és ehhez hasonló eredmény fogad bennünket hamarosan! 6. ábra Wireshark monitorozás DNS capture filter-rel Display filter Tfh. elindítottunk egy monitorozást, de csak később fogalmazódik meg bennünk a gondolat, hogy szeretnénk a DNS csomagokat megvizsgálni. Ehhez már megjelenítési szűrőre lesz szükségünk (hacsak nem szeretnénk teljesen új monitorozást indítani). Több lehetőségünk is van a szűrési feltétel megadására! udp.port == 53 udp.port eq 53 dns Mindegyik szűrő ugyanazt adja eredményül. A továbbiakban megvizsgáljuk, hogy a csomagokban milyen beágyazódásokat figyelhetünk meg! Munka az elfogott csomagokkal A csomag részletes információinál kinyithatjuk az alkalmazás rétegbeli tartalmat (Domain Name System (query/response)). 10

11 7. ábra DNS kérés Az első sorban látható, hogy hanyadik csomag (az elfogottak közül) tartalmazza a kérésre érkezett választ. (Response In: 2) A tranzakció azonosító utal a nyitott DNS kapcsolat azonosítójára (Transaction ID: 0xceb8). A Queries részben találhatjuk, hogy melyik Kiolvasható a Queries sorban a kérés, amire az adott válasz készült. Az Answers részben megtalálhatóak a válaszok, típusokkal és a konkrét adattartalommal ellátva. 11

12 Ellenőrző kérdések 1. Hogyan paraméterezzük fel helyesen az nslookup parancsot, ha a Google levelező szervereinek IP-címeit szeretném lekérdezni? 2. Mely portot használta a monitorozó host a DNS kérés kiküldéséhez? 3. Mely portot használta a DNS szerver a kérés fogadásához? 4. Mi volt a kiszolgáló DNS szerver IP-címe? 5. Hány válaszmező (Answer) található a DNS kérésre visszaküldött válaszban? 6. Volt-e sikertelen kérés a monitorozás során? Ha igen, mi volt a hibaüzenet? Források James F. Kurose, Keith W. Ross: Computer Networking, A Top-Down Approach (Sixth Edition) 12