kategória
	Biológia állatok Fizikai Földrajz Kémia Matematika Növénytan Számítógépes Filozófia Gazdaság Gyógyszer Irodalom Menedzsment Receptek Vegyes

Network Monitor A halózati forgalom elemzése - 1. rész, elméleti alapok

számítógépes

egyéb tételek   I/19 Vírusok és vírusvédelem Sémakezelés és tarolasi struktúrak hierarchikus adatbazisokban Programozható vezérlők hardverfelépítése Part Design CATIA V5 - Start A DOS operaciós rendszer Matav rendszertechnika A képernyőtervezés elemei Assembly Design - CATIA V5 - Start Egy operaciós rendszer bemutatasa

 

MAC address és címzésmódok

Minden egyes hálózati kártya rendelkezik egy - az esetek elsöprő többségében - gyárilag beleégetett egyedi azonosítóval, a hatbájtos MAC addressel. Ez teszi lehetővé, hogy a használt protokolltól függetlenül megvalósítható legyen a gépek egyenkénti címzése. Maga a MAC adress két részre bontható: 3 bájtnyi gyártóazonosítóból és 3 bájtnyi sorozatszámból tevődik össze. (Például a Katron kártyák 0040F6 gyártóazonosítóval rendelkeznek).

Az Etherneten három különböző címzésmód használható. Unicas, multicas és broadcast. A leggyakrabban használt a Unicast, melynél mindössze két gép kommunikál egymással, ilyenkor az Ethernet keret fejlécének címmezőjében a célgép MAC adressét találjuk. Vannak olyan forgalomtípusok, melyeknek minden gépre el kell jutniuk, ezt broadcast címzéssel valósítják meg. Ilyenkor a keret fejlécében nem egy adott gép MAC adresse szerepel címzettként, hanem egy speciális jelzés: 0xFFFFFFFFFFFF. Ezt mindegyik gép magáénak érzi - a PC-től a hálózati kártyás iratmegsemmisítőig - és a csomagot feldolgozásra továbbadja a magasabb szintű rétegeknek. A harmadik és legritkábban használt címzés a multicast. Ilyenkor egy "központi adó műsorsugárzására" kapcsolódik rá nulla, vagy több vevő olyan formán, mint ahogy a rádióadásokat hallgatjuk. Legelterjedtebb felhasználási területei közé tartozik a multimédia adatok terítése vagy egyidejű telepítések megvalósítása (ghost).Kezdeti csomagelemzéseinkben a multicast nemigen fog előfordulni.

Első kísérletünk legyen egy PING hálózati 454d39e forgalmának elemzése. Ha tehetjük, kezdetben tiszta környezetben próbálkozzunk, ahol nincs más hálózati forgalom, mint az, amit mérni szeretnénk, különben azonnal a filterekkel kell bajlódnunk, ami nem nehéz ugyan, de mégis jobb talán, ha csak annyi csomagunk van, mint amennyire számítottunk. Indítsuk el a Network Monitort, kattintsunk a gombon, majd pingeljünk meg egy, a belső hálózaton található gépet, ki-ki a saját hálózatán:

PING 172.16.0.2

Ha megérkezett a négy válasz, állítsuk meg a felvételt, és tekintsük meg az eredményt a  (megállít+megtekint) gombbal. Ha valóban csendes volt a hálózat, körülbelül ezt láthatjuk:

A fenti ábra mindjárt meg is válaszolja azt a lappangó kérdést, hogy a PING miért pont négy választ ad. Mert a gépünk négy kérdést küldött ki! Küldhetne többet is, kevesebbet is, sőt a -t kapcsolóval végtelen számút is, a négy egyszerűen a Windows-ok mágikus pingszáma. Már ebben a listában is rendkívül sok érdekességet láthatunk, többek között azt, hogy legalább három protokoll suhant el a hálózaton figyelő tekintetük előtt: BONE, ARP_RARP és ICMP. De lássuk a részleteket.

A legelső oszlop az elkapott csomag sorszáma, ami még fontos lesz, ha szűréseket végzünk, mert a meg nem jelenített csomagok is megtartják sorszámukat.

A második oszlop a felvétel megkezdésétől eltelt időt méri trilliszekundumban. Ez a kijelzés megváltoztatható, lásd később!

A harmadik és negyedik oszlop a feladó illetve a címzett hardvercímét (vagy boldogabb esetben nevét) mutatja. Ha nincs meg a név, kísérletezhetünk a Display->Find All Names menüponttal, hogy megfejti-e a kisokos a többi gép nevét. Ha nem, akkor még mindig ott a jobbklatty.

Az ötödik oszlop a legmagasabb értelmezett protoll nevét tartalmazza. Hangsúlyos, hogy LEGMAGASABB, meg hogy ÉRTELMEZETT, mert először is a NetMon alapértelmezésben nem értelmez minden protokollt (például a Kerberost sem, de felokosítható), másodszor, ha nem értelmez egy magasszintű protokollt, akkor a listában az eggyel alatta lévő réteget jelenítni meg, Kerberos esetén például annyit, hogy TCP-ről van szó - a többi számára is rejtély. A legmagasabb pedig azt jelenti, hogy ha ott ICMP-t olvasunk, akkor is gondoljunk arra, hogy az ICMP-t IP cipeli a hátán, az meg Ethernet keretben utazik.

Ha kibontjuk a csomagot, ez azonnal ki is derül, duplaklatty az egyik soron:

Roppant zavaros, egyelőre ne ezen erőlködjünk, hanem nézzük a hatodik oszlopot: ez a LEGMAGASABB, ÉRTELMEZETT protokoll LÉNYEGÉT tartalmazza. Ping esetében ez nem túl informatív, de http-nél nagyon megkönnyíti az olvasást, hogy azonnal látszik a http kérés típusa (GET, POST stb.) Most vizsgáljuk meg a három elkapott protokoll szerepét a hálózatban!

BONE

Ezt a protokollt hiába keressük a szabványok lapjai között. Nem szabványos, hanem Microsoftos, és maga a Network Monitor bocsátja ki - tehát jelen esetben önmagunk hálózati forgalmának voltunk szemtanúi. Szerepe abban keresendő, hogy mivel a NetMon igen erőteljes eszköz még így, read only üzemmódban is (hisz komplett Excelfájlok átküldése is elkapható vele, s abban mondjuk kollegáink fizetése olvasható) jogos az igény, hogy mi megállapíthassuk amikor más NetMonozik. Tekintettel arra a szomorú tényre, hogy a távoli hálózati kártyákat nem lehet lekérdezni, hogy promiszkusz módban vannak-e éppen, más módszert eszeltek ki Redmondban - no ez a BONE, amit minden elindított NetMon minden tizedik másodpercben kibocsát, így jelzi a monitorozást a többieknek. Ha a NetMon bocsátja ki, vajon ki olvassa? Úgy van, a NetMon! A Tools->Identify NetMon Users menüpont azért tudja megmondani, hogy kik sniffelnek még rajtunk kívül, mert összegyűjtögeti a csontokat (BONE=csont) a hálózatról. Ha nincs meg a menüpont, az azért van, mert csak a NetMon főablakában jelenik meg! Váltsunk át a legelső ablakra a Window menüben, és mindjárt lesz Identify menüpont. Csendes környezetben ez valahogy így néz ki:

ARP_RARP

A következő protokoll az ARP_RARP. Ez már szabványos, sőt, létfontosságú protokoll! E nélkül nem létezne unicast címzés!

Miért?

Ha mi pingelünk egy gépet, elvárjuk, hogy az, és csak az válaszoljon a kérésünkre, annak ellenére, hogy -üzenetszórásos csatornáról lévén szó - a csomag Ethernet szinten mindenhova eljut (a switcheket megint felejtsük el). Ez csak úgy lehetséges, ha a MAC Address helyesen van kitöltve a PING fejlécében. Igen ám, de mi azt írtuk, hogy

PING 172.16.0.1

.és nem azt, hogy

PING 00-20-18-A1-B9-D2

Pedig ez utóbbi sokkal jobban megjegyezhető. Ki ne tudná fejből a vállalat összes hálókártyájának MAC Addressét? (Én :-) Gondoljuk végig: mi IP címmel pingelünk, de ezt egyik gép hálózati kártyája sem fogja felismerni, mert az IP cím az operációs rendszer tudománya (Windowséknál a registryben van, míg hálózati nyomtatók esetében az adott eszköz "operációs rendszerében") Ebből az következne, hogy gépünk képtelen helyes MAC Adressel kibocsátani a pinget, hisz fogalma sincs a szomszéd masina hardvercíméről. Akkor? Akkor marad(na) a broadcast, hisz kezdetben kizárólag a közismert 0xFFFFFFFFFFFF cím áll rendelkezésre. De gondoljuk végig, micsoda erőforráspazarlás lenne, ha minden gép megkapná és feldolgozná pingünket, majd (egy kivételével) nem válaszolna, hisz egy magasabb rétegben végül is kiderül, hogy a csomag nem neki szól! A megoldás kulcsa az ARP, azaz Address Resolution Protocol. Kezdetben, rendszerindítás után valóban kizárólag a broadcast hardvercímről van tudomása minden egyes gépnek. Ha unicast hálózati forgalomra van szükség, be kell szereznie a partner MAC addressét, aminek lekéréséhez broadcast csomagot fog küldeni, valahogy így:

-Fiúklányok! Melyikőtöknek az IP címe a 172.16.0.3?

Ezt minden gép meghallja, a hálókártyák megszakítást keltenek az oprendszer felé, amely felemeli a csomagot, belenéz, és ha magára ismer - válaszol. Visszaküldi a saját MAC addressét. A kérdező pedig feljegyzi a válaszoló hardvercímét az úgynevezett ARP gyorsítótárba. Ennek kilistázása parancssorból:

ARP -a

S már jöhet is a ping, vagy bármi más unicast hálózati forgalom. Ha a történetbe belekeverjük azt a szomorú tényt is, hogy az IP címek idővel megváltozhatnak (például DHCP címkiosztás miatt), akkor beláthatjuk, hogy egy masinának nem célszerű az idők végezetéig megjegyezni a többiek MAC Addressét: a nem használt hardvercímek "élete" két perc, de még a használtak is csak tíz percig érvényesek, utána a szabvány szerint újra kell kérni őket. Egyszóval ARP_RARP-pal elég gyakran találkozhatunk hálózati forgalom elemzése közben.

ICMP

A fantasztikus Internet Control Message Protocol rengeteg funkciót lát el, ezek közül csak egy az ICMP Echo, azaz a PING. Egy későbbi számban terveink szerint megjelentetjük az ICMP RFC fordítását mindannyiunk épülésére-szépülésére. A segédprotokoll Echo+Echo reply változata az IP kapcsolat helyességének ellenőrzésére való. Ezt most ne részletezzük, a PING parancsnak ezer kapcsolója van. Étvágygerjesztésként íme még néhány ICMP változat:

Redirect: routerek küldik ezt megtévelyedett munkaállomásoknak, akik rossz kapun (gateway) akarnak kijutni az alhálóról. A Redirect-et a Windows NT 4 SP3 óta figyelembe veszik a MS operációs rendszerei, és szót fogadnak a routernek.

Time Exceeded: az idő lejárt. Az elküldött IP csomag TTL-je nullára csökkent. Ezt az üzenetet az a router küldi vissza, akinél a csomag élete lejár, "meghal".

Source Quench: a fuldokló router így közli a túlterhelést okozó munkaállomással, hogy lassítson, mert képtelen átvinni a megadott ütemben a csomagokat - a munkaállomás vagy figyelembe veszi, vagy nem. NT4 óta figyelembe vesszük. Hogy a Windows ME figyelembe veszi-e? Fogalmam sincs.

Látványosságok

S most lássuk, hogy mi mindent lehet tenni a látványosság fokozása érdekében. Nem öncélú színezgetésre gondolok, hanem arra az esetre, ha egy hosszabb "beszélgetésből" ki szeretnénk emelni mondjuk az SMTP forgalmat. Térjünk vissza a szemüveg gombbal a részletes nézetre, és színezzünk! Display->Colors

Szerintem önmagáért beszél a felhasználói felület. Keressük ki az ICMP protokolllt e végtelen listából, és állítsuk át zöld alapon sárgára. Ne kíméljük az ARP_RARP-ot sem, legyen rózsaszín alapon világoskék! Ugye fáj? Kétszínű kiadvány lévén itt és most nem tudom bemutatni színhelyesen a látványt, így mindenképpen házi feladat a színezgetés.

Másik hasznos lehetőség a kijelzésmód megváltoztatása oly módon, hogy a listában ne a felvétel eleje óta eltelt másodpercek látszódjanak, hanem például a csomagok követési sebessége, vagy az elkapás ideje óra-percben. Ehhez menjünk a Display->Options menüpontra:

Hexa

Itt az ideje, hogy elmerüljünk a részletekben. Kettő katti a legelső ARP soron:

Látható, hogy Ethernet keretben utazik az ARP, s az Ethernetet kinyitva ráálltam a Destination Address sorra, aminek tartalma hexa 0xFFFFFFFFFFF. Felismerjük? Az első ARP kérés broadcast! Vajon ki a feladó?

ETHERNET: Source address : 002018A1B9D2

Ahogy az a középső ablakon kattintgatunk, az alsó, hexadecimális panelen mindig kijelölődik az a rész, aminek az értelmezett változatát éppen megsimogatjuk az egerünkkel. Így látszik, hogy a keret legelső 6 bájtja alkotja a címzett hardvercímét, a második 6 bájt a feladó címe és így tovább. Ha azonban rákattintunk a Frame Lenght mezőre, a hexa panelen nem jelölődik ki semmi! Ennek oka, hogy a NetMon néha olyanokat is mutat, ami nincs is bent a keretben: ez egy számított mező! A 13.-14. bájt az úgynevezett kerettípus (frame type) melynek aktuális értéke (0x0806) ARP-t jelent (IP eseténe ez a mező 0x0800 lenne).

És végül minden rétegben megtalálható a "Number of data bytes remaining", azaz az adott réteg számára egyszerűen cipelendő, de nem értelmezendő adattömb. Ha ARP-ot cipel az Ethernet keret, akkor ez további 28 bájt. Ezzel visszaérkeztünk a rétegzett hálózati architektúrához, s jó alkalom kínálkozik az egymásba ágyazás ábrázolására. Minden magasabb réteg az alatta levővel szabványos interfészen át kommunikál. Ahogy az adatok egyre lejjebb jutnak a protokollveremben, úgy rakódik rájuk egyre több információ, amit a NetMon meg is mutat nekünk. Az IP réteg IP fejlécet tesz hozzá, az Ethernet keretez, a TCP szekvenciaszámokkal operál stb. Erre még részletesen visszatérünk. Az alábbi ábrán egy fiktív, tehát sem TCP/IP, sem OSI modellt láthatunk, ahonnan leolvasható, hogy az egyes rétegek elküldés előtt hogyan egészítik ki az adatot saját fejléceikkel, s fogadáskor hogyan értelmezik és bontják le azt.

Ha most egy ICMP csomagot vizsgálunk meg ebből a szempontból akkor az egyes rétegekben jól látszik, hogy mennyi ott a "Number of data bytes remaining":

4 1.752293 LOCAL 00A0CCC07118 ICMP Echo: From 172.16.00.01 To 172.16.00.03 PLATAN 172.16.0.3 IP

Frame: Base frame properties

Frame: Frame data:

Number of data bytes remaining = 74 (0x004A)

ETHERNET: ETYPE = 0x0800 : Protocol = IP: DOD Internet Protocol

ETHERNET: Ethernet Data:

Number of data bytes remaining = 60 (0x003C)

IP: ID = 0xE45A; Proto = ICMP; Len: 60

IP: Data:

Number of data bytes remaining = 40 (0x0028)

ICMP: Echo: From 172.16.00.01 To 172.16.00.03

ICMP: Data:

Number of data bytes remaining = 32 (0x0020)

Általában minden protokoll valamilyen hasznos adatot cipel, így a PING is. Nála ez 32 bájtnyi "remaining". Házi feladatként mindenki vizsgálja meg, hogy mi a PING által átvitt "hasznos" adat!

Sok sikert!

Fóti Marcell

MCSE, MCT, MCDBA

Folytatjuk.

NetMon 2.rész - A PING élve boncolása

Mire e cikk megjelenik, a karácsony már a múlté lesz. Mindenki lázasan püföli munkahelyén a billentyűket, és lassan ismét elfelejti milyen is az élet számítógépek nélkül. Pedig a karácsony sokunk számára a billentyűzet elengedésének ünnepe is egyben! Ha pedig az emberre rátör a kóros billentyűzhetnék, akkor sem jut hozzá, hisz - ugyebár - számítógép nincs otthon. Rajtam valami olyan elemi erővel lett úrrá a billentyűzhetnék, hogy kénytelen voltam kicsomagolni azt a hazahozott laptopot, amit suttyomban pont azért csempésztem haza, hogy ha jelentkeznek az elvonási tünetek, ne kelljen orvoshoz fordulnom. Így esett, hogy szent karácsony harmadik napján feladtam a küzdelmet, és a hosszú elvonókúra után elkékült arccal, remegő inakkal billentyűzetet ragadtam, hogy megírjam ezt a cikket a Network Monitorról, mely önmaga is egy narkó. Mármint a NetMon. Nem hagyja az embert békében pihenni, keretekkel és csomagokkal tömi meg a gyanútlan áldozat fejét, aki a világot is üzenetszórásos csatornának látja, és maximum 1514 bájtos csomagokban hajlandó felvinni az emeletre a karácsonyi bevásárlás súlyos, ám - csakúgy mint az Ethernet kártya számára - értelmetlen terhét.

Megfejtés

A múlt hónapban egy rejtvénnyel fejeztem be a cikk első részét, mely így hangzott: mi a PING által szállított "hasznos" adat? Azoknak helyes a megfejtése, aki az angol ABC betűit találták meg a "number of data bytes remaining" szekcióban.

A PING "hasznos" terhe

Ez alapértelmezésben 32 bájtnyi ABC. Ha a PING parancsot -l kapcsolóval indítjuk, sokkal precízebben meg tudjuk adni, hogy mennyi legyen a hasznos teher. Minimális értéke 1, maximuma 655 Az jó sok. Hallottak már a halálos PING-ről? Régi tréfa, korábbi operációs rendszerek elleni méreg. Hogyan is működik a PING? A kezdeményező gép elküld egy bájtsorozatot a célgépnek (ECHO), amelyik ezt hibátlanul megismételve visszaküldi (ECHO REPLY). Ahhoz, hogy meg tudja ismételni, a beérkező "hasznos" adatokat rögzítenie kell, el kell tárolnia a memóriában. Tipikus biztonsági rés, amikor egy protokoll megvalósításánál a programozó nem kezeli le az összes előforduló esetet, csak azokat, amelyeket a szabványban is leírtak - vagy még azokat sem. Nos, a korai ICMP ECHO-k szinte mindegyike "megvalósította" ezt a hibát, még a büszke Linuxok is. Valahogy úgy kell elképzelni, hogy a programozó lefoglalt az ECHO számára egy meghatározott méretű puffert (mondjuk 10000 bájtot, az nem olyan sok) és ezzel a dolog el is van intézve. Szépen működik is a pingecske mindaddig, amíg a "hasznos" teher meg nem haladja a lefoglalt puffer méretét. De amint túllépi a bűvös határt, a többletkarakterek már nem a lefoglalt pufferbe kerülnek, hanem valamilyen más memóriaterületre - ami a kernel mód szabályai szerint akármi is lehetett. De messzire elkalandoztam (hiába, ez az ünnepek hatása) a halálos PING már nem létezik! Már csak a legbénább hackerek próbálkoznak vele, de azokat is megfogja minden tűzfal, beleértve az ISA Servert is.

PING

Hanem vizsgáljuk meg a PING forgalmát tetőtől talpig, hisz egy csomó olyan dolgot tartalmaz ez a néhány csomag, ami minden hibakeresést megkönnyíthet.

Felmerülhet a kérdés, hogy vajon miért e körül a 8-10, viszonylag egyszerű csomag körül ólálkodunk, miért nem ugrunk bele valami kőkeménybe, például az NTLM hálózati forgalmába. Azért, mert ez a néhány csomag olyan, mint cigarettahamu a gyilkosság helyszínén: Sherlock Holmes nem rohan el ilyen fontos bizonyíték mellett anélkül, hogy meg ne vizsgálná, és következtetéseket vonna le! Ebben a pár bájtban választ kapunk az élet néhány alapvető kérdésére is: vajon miért nem a www.microsoft.com gép MAC Addresse található a feladott Ethernet csomagban, amikor odaböngészünk? A hamu megtalálható lapunk webhelyén a januári előzetesről szóló lapon, neve PING.CAP, és akármelyik telepített NetMonnal megnyitva minden kedves olvasó pontosan ugyanazokat a kereteket, méreteket és sorszámokat láthatja, mint ami itt a cikkben is látható.

ARP, ARP, ARP

Kezdjük az ARP-pal, ezzel a kérdezz-felelekkel:

ARP kérés és válasz

Ami magyarul így hangzana:

-Fiúk, melyikőtöknek az IP címe 172.16.0.3?

-Az enyém! Itt a MAC Addressem!

Itt leolvasható, hogy a kérés a CIS TE-A1B9D2-ként azonosított hálózati kártyáról indul ki, és broadcast címzést használ az ARP kérdés, és a 172.16.0.3 IP című gépet keressük a magyar határban. Ebből következik, hogy e kérést az összes, ezen a szegmensen található gép értelmezni fogja, és a kérést feldobja operációs rendszerének, hogy a magasabb intelligencia válaszolhassa meg a kérdést: az IP cím az adott gépé-e. Erre az én gépem (LOCAL) válaszol, mivel övé a keresett IP cím, de már nem broadcasttal, mert a kérésből kiássa a feladó MAC Addressét, és közvetlenül annak válaszol.

Kevesen tudják, hogy az ARP tetszőleges hardvercímet (tehát nemcsak Ethernet, hanem egyéb címeket is) fordít tetszőleges "magasabb" címre. Erre ékes bizonyíték az ARP csomag belsejében található:

ARP_RARP: Hardware Type = Ethernet (10Mb)

ARP_RARP: Protocol Type = 2048 (0x800)

ARP_RARP: Hardware Address Length = 6 (0x6)

ARP_RARP: Protocol Address Length = 4 (0x4)

ARP_RARP: Opcode = Request

ARP_RARP: Sender's Hardware Address = 002018A1B9D2

ARP_RARP: Sender's Protocol Address = 172.16.0.1

ARP_RARP: Target's Hardware Address = 000000000000

ARP_RARP: Target's Protocol Address = 172.16.0.3

A kétbájtos Hardware Type mező mutatja, hogy itt a 10 megabites Ethernet bizony csak egy aleset, egy a sok létező fizikai réteg közül, melynek fizikai címei éppenséggel hat bájtosak (Hardware Address Length = 6). Ennél is érdekfeszítőbb ugyanakkor, hogy az IP is csak egy az ARP által támogatott sok protokoll közül - melynek négy bájtosak a címei (Protocol Address Length = 4). Ugyanez az ARP változtatás nélkül ki tudná szolgálni az Ipv6-ot Token Ringen!

Az Opcode = Request jelzi, hogy ez egy ARP kérdés, ennek párja az Opcode = Reply a következő csomagban.

S ezután következik a feladó hardver- és protokollcíme (MAC Address és IP cím), majd a kérdéses gép hardvercíme üresen marad (hisz fogalmunk sincs, erre irányul a kérdés), s végül a célgép IP címe olvasható.

Kristálytiszta?

Nem tűnnek fel a kakukktojások?

1. kakukktojás

Mivégre szerepel a feladó saját MAC Addresse az ARP kérésben, hiszen ugyanez az adat az Ethernet keretben is szerepelt? Minek küldi át a CIS TE-A1B9D2 kétszer ezt az adatot? Lehetséges válaszok:

A.)  Mert az ARP protokoll írói nem tudhatták előre, hogy a fizikai réteg is hordozni fogja ugyanezt az adatot. Emiatt a költségesebb, de előrelátóbb megismétlés mellett döntöttek.

B.)  Mert bár ott van a MAC Address az Ethernet keretben, az a célgép "agyáig" nem jut el, mert a rétegzett hálózati architektúrának megfelelően minden magasabb szintű réteg csak az alatta lévő réteg által cipelt adatot kapja meg (emlékezzünk: "number of data bytes remaining"), így az a MAC Address nem jut fel - az Ethernet kártya meghajtója éppúgy lefejti és lenyeli, mint például a célgép hardvercímét.

C.)  Mert az ARP protokollt a Microsoft írta, aki nincs jóban a Xerox-szal, aki pedig az Ethernet szabvány ura.

Ugye milyen csábító az A válasz? Nem-nem! B!

2. kakukktojás

És mit keres ott a kérdező MAC Addresse? Kit érdekel? Hisz a célgép MAC Addressére kérdezünk!

A.)  Azért van ott, mert az ARP után roppant nagy valószínűséggel kétirányú adatátvitel következik a feladó és a cél között, s ez biztosítja, hogy nem csak a kérdező fogja megtudni a célgép hardvercímét, hanem a célgép is tudomást szerez a kezdeményező címéről - mégpedig nulla darab hálózati csomag elküldésével. Ez az adat "csak úgy" bejön!

B.)  A kérdező MAC Addresse a szimmetria miatt van ott, az ARP tervezői művészlelkek voltak, és harmóniára törekedtek.

C.)  Ez arra szolgál, hogy ha már az IP cím beállításánál nem derült ki az esetleges címütközés, akkor majd most, ezzel a broadcast csomaggal felszínre kerül. Hisz itt bekiabáljuk a hálózatba saját IP címünket és MAC Addressünket, mely minden géphez eljut, s ha valamelyik esetleg ugyanezt az IP címet kapta, most észbekaphat.

No nézzük! A B válasz komplett hülyeség. Az A itt is csábító, és igaz is! Erről meggyőződhetünk az ARP gyorsítótárak kilistázásával: noha a pingfogadó gépen a kisujjunkat sem mozdítottuk, az ARP -a feltárja, hogy a cache bizony gyarapodott! És a C? Mi az, hogy egy IP cím ütközés nem derül ki?

A C válasz helyes, de marad a rejtélyes kérdés: hogyan fordulhat elő, hogy két gépen azonos IP címet állítunk be, és az csak percekkel/órákkal később derül ki?

A megfejtéseket levelezési listáinkon várjuk:

feliratkozás a tech.net-join@lyris.netacademia.net címre írott üres levéllel

Megfejtés beküldése a tech.net@lyris.netacademia.net címre írott, a megfejtést tartalmazó levéllel.

Beküldési határidő nincs, ehelyett szorgos feliratkozás van. Honnan fogja jó előre megtudni a következő szám részletes tartalmát, ha nem iratkozik fel?

Egyébként lassacskán mindent tudunk az ARP-ról. Talán még annyit tennék hozzá, hogy az ARP dolgozik az IP cím ütközések azonnali kiderítésénél (ami NEM a rejtvény tárgya!) oly módon, hogy minden gép, amelyik új IP címet kap, "megarpolja" azt mielőtt véglegesítené. Ilyenkor az ARP így hangzik:

-Fiúk, melyikőtöknek az IP címe az én jövendőbeli IP címem?

S ha erre jön válasz, akkor a cím foglalt. Ezt az ARP-ot Gratious ARP-nak hívják, és ezen kívül még egy szerepe van: mivel a fenti káltás broadcast, minden géphez eljut, és így minden gép kijavíthatja az ARP gyorsítótárába esetleg beszorult korábbi értékeket. Az ARP tehát a Microsoft Cluster Server működésének alapja. A következtetés talán egy kicsit hirtelennek tűnik, de így van, ARP nélkül nincs fürtözés. Itt és most nem fejtem ki részletesebben, mert korábban, más újság hasábjain már megtettem.

IP

S most térjünk át a következő néhány csomagra, a PING érdemi részére! A harmadik keret tartalma a következő:

Ethernetben IP-ben ICMP. Az Ethernet réteget ismertnek veszem, abban ugyanis továbbra sincsen más, mint a feladó és a célgép hardvercíme és a Frame Type, mely megmutatja, hogy az Ethernetben IP utazik (0x800). Az IP így néz ki részletesen:

IP: Version = 4 (0x4)

IP: Header Length = 20 (0x14)

IP: Precedence = Routine

IP: Type of Service = Normal Service

IP: Total Length = 60 (0x3C)

IP: Identification = 58458 (0xE45A)

IP: Flags Summary = 0 (0x0)

IP: .......0 = Last fragment in datagram

IP: ......0. = May fragment datagram if necessary

IP: Fragment Offset = 0 (0x0) bytes

IP: Time to Live = 128 (0x80)

IP: Protocol = ICMP - Internet Control Message

IP: Checksum = 0xFE41

IP: Source Address = 172.16.0.1

IP: Destination Address = 172.16.0.3

IP: Data: Number of data bytes remaining = 40 (0x0028)

A legelső bájt az IP verziószámát (felső 4 bit) és az IP fejléc hosszát (alsó 4 bit) adja meg. A verziószám azért áll legelöl, mert ez alapján derül ki, hogy a többi mezőt hogyan kell értelmezni. Ennél kisebb verziószámmal nem találkozunk, de nagyobbal se. A négyest egyébként nem az ötös követi, hanem a hatos, ha elterjed. A következő bájt a Type of Service és Precedence értékeket hordozza. Ennek a bájtnak a 3-5. bitjei a csomag által igényelt késleltetés (delay), megbízhatóság (reliability) és átbocsájtóképesség (throughput).

A Total Length az IP és az által hordott hasznos adat teljes összege bájtokban, azaz

Total Length= Header Length Number of data bytes remaining

Az Identification egy eléggé kifinomulatlan eljárás az ide-oda küldött IP csomagok helyes sorrendjének meghatározására. Ne tévedjünk, ez a növekvő sorszám NEM tesz lehetővé hibajavítást azon a szinten, ahogyan majd a TCP dolgozik, sokkal inkább a töredezett IP csomagok összeállításában segédkezik. A következő két bájt (Flags Summary és Fragment Offset) a csomag töredezettségével foglalkozik. A mi csomagunk nem töredezett, hurrá. Ezért most ne is foglalkozzunk ezzel részletesen, majd visszatérünk rá a virtuális magánhálózatok hálózati forgalmának elemzésénél.

Time to Live

Annál fontosabb viszont a TTL (Time to Live) érték. Feltételezve, hogy minden olvasóm enyhén jártas az IP útválasztás alaptudományában, minden különösebb magyarázat nélkül tekintsük meg az alábbi hálózatot, ahol R1, R2 és R3 útválasztók (routerek) úgy vannak beállítva, hogy a nyílhegy felé mutat az alapértelmezett útvonaluk (Default Gateway):

Legyen továbbá egy PC-nk (Default Gateway=Router1), amelyről megpingetünk egy olyan címet, amihez még csak hasonló sincs ebben a hálózatban. Mit tesz R1 az ismeretlen című csomaggal? R2-nek továbbítja. R2 ugyanígy tanácstalan, ezért R3-nak küldi, aki szintén nem áll a helyzet magaslatán, ezért átdobja R1-nek. S amör bezárult. Vajon meddig keringene egy hibás csomag ebben a hálózatban? Úgy van, a végtelenségig - hacsak.! Ha csak észre nem vesszük, hogy kering, és ki nem vesszük a hálózatból. Erre való a TTL. Az eredeti szabvány szerint a csomag maximális élettartamát adja meg másodpercben. A mai routerek azonban x-szer gyorsabban dolgoznak elődeiknél, így a legújabb RFC szerint a TTL nem másodpercben értendő, hanem ennyi darab útválasztón juthat át a csomag. Minden router eggyel csökkenti a rajta áthaladó csomagok TTL-jét, és ha ennek értéke eléri a nullát, akkor a csomagnak vége. Intelligensebb útválasztók ilyenkor visszaszólnak az eredeti feladónak egy ICMP Time Exceeded üzenettel, hogy értesüljön a katasztrófáról, és újra tudjon próbálkozni - most már megnövelt TTL-lel.

Rejtvény

Protocol

A következő bájt a Protocol mező. Ez határozza meg, hogy az IP mit cipel. A 0x1 jelentése: ICMP. Itt álljunk meg egy szóra. Megfigyelhető, hogy az IP tudja, mit cipel, miközben korábban arról volt szó, hogy számára értelmezetlen a benne található adat. Nem szabad összetéveszteni az adatértelmezést a továbbítást segítő Protocol mező szerepével. Az IP nem azt tudja, hogy PING-et visz a hátán, hanem azt, hogy az általa hordozott adatot a 0x1 azonosítószámú magasabb rétegnek kell továbbadnia - s ez valóban az ICMP. E mező feladata tehát a bejövő csomag útvonalának determinisztikussá tétele, hogy ne kelljen találgatni, hogy ami beérkezett, az ízlik-e az ICMP-nek, vagy nem, esetleg a TCP fogyasztja majd el, vagy a GRE. Bele van hát írva, hogy hova kell továbbdobni. Ugyanez az elv lejjebb és feljebb is megfigyelhető. Lejjebb, az Ethernet szintjén a Frame Type mező szolgált ugyanerre a célra, hogy ne kelljen találgatni, hogy vajon a beérkezett keret IPX, vayg NetBEUI. Feljebb, a TCP szintjén a portszámok osztályoznak. -as? WWW! 25-ös? SMTP! 11 -es? POP3!

Checksum

Nini, itt is egy CRC! Az Ethernetnek is volt egy! Az igaz, hogy nem látjuk a NetMonnal, mert ha az alsó CRC rossz, a keret nem jut elénk. De akkor minek még egy ellenőrzőösszeg? Azért, mert egyáltalán nem biztos, hogy az IP csomag CRC-vel védett keretben utazik, s biztos ami biztos, itt is van egy, hogy a szoftveresek is örülhessenek. Igen ám, de van itt egy kis baj, kalamajka.

Amikor egy IP csomag áthalad egy útválasztón, csökken a TTL.

Ha csökken a TTL, elromlik az ellenőrzőösszeg.

Ha elromlik az ellenőrzőösszeg, hibássá válik a csomag.

Ez nem történhet meg!

Az útválasztók fontos feladata, hogy a TTL csökkentése után újraszámítsák a CRC-t, és hibátlan IP csomagot küldjenek tovább.

IP címek

És végül az IP fejlécben olvasható a feladó és a célgép IP címe. A célgép címe az odaút kiválasztásához kell, a feladóé pedig a visszaút meghatározásában játszik majd szerepet. E két cím az, mely végponttól végpontig végigkíséri a csomagot hosszú útján - hacsak proxy vagy tűzfal nem állja útját, amely galád módon átirkálhatja mindkettőt. Az előbbi mondatot szó szerint értem. Ezek a címek utazzák végig a teljes útvonalat, ellentétben a MAC Addressel, mely csak egy adott szegmensen él. Az Ethernet rétegbéli MAC Address értelemszerűen nem lehet a nagyon távoli (például www.microsoft.com) gép kártyájának a címe, hisz

semmi garancia nincs arra, hogy a célgép egyáltalán Etherneten van. Lehet telefonvonalon, műholdon, mikrohullámon, infrán, telepátián és BlueToothon.

Az Ethernet réteg feladata NEM a végcél, hanem a kijárat megcímzése, azaz messzire menő csomagoknál a tőlem elindított Ethernet keretben a Default Gateway MAC Addresse, míg IP fejlécében a távoli gép IP címe szerepel!

ICMP

ICMP: Packet Type = Echo

ICMP: Echo Code = 0 (0x0)

ICMP: Checksum = 0x3A5C

ICMP: Identifier = 512 (0x200)

ICMP: Sequence Number = 4352 (0x1100)

ICMP: Data: Number of data bytes remaining = 32 (0x0020)

A Packet Type mutatja meg, hogy a negyedik keret egy kérdés (ECHO=0x08), az ötödik pedig válasz (ECHO REPLY=0). Jön még egy checksum. A TCP/IP üldözési mániában szenved.

A Sequence Number minden kibocsátott ECHO-nál egyedi érték, amit a válaszban (ECHO REPLY) meg kell ismételnie a felelőnek, hogy a kérdező oldalán egyértelműen meg lehessen állapítani, hogy melyik csomag érkezett vissza. Ez ahhoz szükséges, hogy a PING ki tudja számolni a csomagok megfordulási idejét. Tulajdonképpen a PING igen korlátozott módon ugyan, de sávszélesség-mérésre is alkalmas. Jártam már úgy, hogy egy bérelt vonalról meg kellett mondanom az abban lévő "maradék" sávszélességet, s mindehhez a nagy semmi állt rendelkezésemre. Ilyenkor jól jöhet egy kis furfang! Küldjünk át a mérendő vonalon akkora pingeket, hogy az valami mérhető megfordulási időt okozzon (a lokális hálózatokon alapban "mérhető" <10 ms megfordulási idő valójában mérhetetlenül gyorsat jelent). Például:

PING -l 10000 www.internetszolgaltato.hu

Ha a vonal mondjuk 128 kilobites, akkor körülbelül és durván (128/8=)16 kilobájt átvitele egy másodperc alatti-körüli válaszidőt kellene adnia, s ha ettől jelentősen eltér akkor meg tudjuk becsülni, hogy mennyi is a rendelkezésünkre álló sávszélesség.

Mai nyomozásunk lezárásaképpen még vessünk egy pillantást a 10000 bájtos PING hálózati forgalmára.

10000 bájtos PING

Látjuk az ICMP ECHO és ECHO REPLY csomagokat, de egy kicsit zavarosnak tűnik az egész, a kérdés és a válasz közé sima IP csomagok ékelődnek. Vajon mi lehet ez?

marcellf@netacademia.net

MCT, MCSE+I, MCDBA, MZ/X

Network Monitor III.

PING, PING, PING

Mai élveboncolásunk első alanya egy jó nagy ping lesz. Méretét tekintve akkora, hogy semmiképpen sem fér be egyetlen, maximálisan 1514 bájt méretű keretbe. A kísérlet azért fontos számunkra, mert a való világ valós adatainak többsége lényegesen nagyobb, mint 1514 bájt, így - mint csepp a tengerben - e jókora pingen felfedezhető ugyanaz az átalakítási eljárás, ami minden nagyobb fájl esetén megtörténik, s amit a FONTOS.XLS is elszenved, ha hálózaton keresztül továbbítjuk - vagyis darabokra bomlik a feladónál, és ezekből áll össze a fogadónál. Ezt kapd el:

Először madártávlatból vessünk egy pillantást az elkapott hálózati forgalomra:

A nagy ping látképe

Jól megfigyelhető, hogy az ICMP Echo (1) és ICMP Echo Reply (2) közé további IP csomagok ékelődtek, melyekről - legalábbis első ránézésre - nem látszik azonnal, hogy a PING-hez tartoznának. Közönséges IP csomagok volnának?? A korábbi cikkeimben leírtaknak megfelelően egy beérkező hálózati csomag determinisztikus úton jut el a megfelelő feldolgozóegységhez, hisz minden egyes réteg pontosan tudja, hogy a számára feldolgozhatatlan "Number of data bytes remaining" adatokat hova továbbítsa. Az Ethernet keretben az Ethernet Type mező mutatja meg, hogy mit szállít az adott keret, míg például az IP-ben a Protocol mező végzi ugyanezt a feladatot. Nézzük tehát meg az egyik "kósza" IP csomagot (3), hogy vajon mit tud magáról:

Elég sok újdonságot mutat ez a néhány, természetesen gondosan megritkított sor. Az IP fejléc Protocol mezőjéből leolvasható (4), hogy az itt szállított adat tulajdonképpen ICMP, vagyis annak maradéka. Honnan tudjuk, hogy maradék? Egyfelől onnan, hogy a Fragment bit (5) be van állítva, ami tulajdonképpen nem azt jelzi, hogy az éppen nagyítónk alá került csomag egy töredék, hanem azt, hogy további töredékek várhatók (More fragments in datagram after this one). Másfelől onnan, hogy a következő olvasható a "hasznos" adatok előtt (6): Fragmented Datagram Data: Number of data
bytes remaining.

Ami pedig a NetMon lustaságát illeti (hogy csak odafigyeléssel deríthető ki, hogy ez a ping folytatása) érthető, hiszen ICMP fejlécet nem találunk ebben a csomagban. Mindek is kellene mind a hét utazó csomagban megismételni, hogy ez egy ICMP Echo? A csomagok anélkül is utat találnak felfelé a protokollveremben. A kérdés csak az, hogyha a gép egyszerre két nagydarab, töredezett pinget kap, akkor a töredékeket hogyan tudja megfelelően osztályozni, hogy honnan jöttek? Erre szolgál az Identification (=13373 (0x343D)) mező (7). Minden beérkező IP csomagban, és töredékeiben azonos ez a random érték. Így nincs más teendője az IP feldolgozónak, mint mindaddig ugyanoda dobálni a beérkező töredékeket, amíg azok Identification mezője megegyezik, és be nem fut az utolsó töredék, ahol a Fragment bit már nulla (Last fragment in datagram).

Tördelés

Most vessünk egy pillantást a tördelés általános menetére. Az alábbi ábra a PING feldarabolásának sematikus vázlata. Összeáll a teljes, tízezer bájtos PING, és ezt valaki csomagok sorozatára bontja úgy, hogy az ICMP adattartalom lesz a trancsírozás áldozata - de az IP fejléc épségben megismétlődik!

A 10000 bájtos ICMP Echo darabolás előtt.

.és a darabolás után

A teljes átvitt adatmennyiség a fejlécekkel együtt pedig 6x1514+1162=10246 bájt, ami már az Ethernet és IP fejlécek méretét is tartalmazza. Ki végzi vajon a tördelést? Az előzőek alapján az IP protokollra gyanakodhatunk. Más alkalmazásokra gondolva beláthatjuk, hogy nem az alkalmazás darabol. Az biztos, hogy nem az Excel fogja szorgosan felaprítani a FONTOS.XLS-t adatátvitel előtt, hisz pontosan arra találták ki a rétegzett hálózatni architektúrákat, hogy például a hardver által okozott kellemetlenségek rejtve maradjanak a magasabb szintű rétegek, s főleg az alkalmazások elől. Jelen esetben az "alkalmazás" az ICMP, előle rejtve marad a darabolás. De vajon miért pont az IP végzi ezt a munkát? Miért nem az Ethernet meghajtóprogramja? Hisz mégiscsak közelebb áll az 1514 bájtos korlátot okozó Ethernet kártyához?

A kérdés jó, a válasz pedig az, hogy az Ethernet fejléc ugyan "közelebb" van a hardverhez, de épp emiatt kevésbé számíthatunk rá: amikor egy IP csomag útválasztó-hegyeken át jut el egy távoli kiszolgálóig, akkor az Ethernet fejléc tartóssága enyhén szólva is megkérdőjelezhető, hisz a legelső útválasztó lebontja, és teljesen más (például TokenRing) fejlécet illeszt a csomag elé. Így a végponttól-végpontig történő címzés nem bízható az Ethernetre, csak egy minden matatást és útválasztást túlélő rétegre - s az IP pont erre való. Minden töredezett csomag elején ott a helye az IP fejlécnek, hogy a töredékek mindegyike utat találjon a célba! Az ICMP fejlécről ugyanez a nagyfokú hasznosság már nem mondható el, emiatt az már a tördelés áldozatául esik. Ha majd rátérünk a TCP csatorna elemzésére, látni fogjuk, hogy ott már a TCP fejléc is beleszól a szállításba, így világos, hogy az sem fog belekerülni a darálóba.

A következő kérdés önként adódik: honnan tudja az IP, vagy majd a TCP, hogy mekkorára kell tördelni? A hálózati kártya által elfogadott legnagyobb keret méretét, valamint az összes réteg fejlécigényét megfelelő API hívásokkal le lehet kérdezni, s a Windows 2000 ezt éppúgy elvégzi menet közben, mint annyi minden mást. De hogy egy kicsit a múltba révedezzünk.

Maximum Transmission Unit

Hajdanában-danában, amikor az operációs rendszerek még feleennyit tudtak, bizony néha szükség lehetett a nem(igazán) támogatott kártyák 3rd party meghajtóit egy kis INI-fájl matatással megsegíteni a hatékony működés érdekében. Volt idő, amikor a tördelési határt kézzel kellett beállítani, s ennek a letűnt korszaknak állít emléket a regisztrációs adatbázis MTU kulcsa, ahol mind a mai napig meg lehet változtatni kézzel a tördelési határt.

Ennek a gyakorlatban még sohasem vettem hasznát, egyszerűen csak érdekes. Még érdekesebb, hogy míg IP szinten a helyi hálózati kártya MTU-jára vagyunk kíváncsiak, addig a TCP réteg a két kommunikáló fél között a teljes útvonalon érvényesíthető MTU-ra kíváncsi, s ezt le is kérdezi az útvonal teljes hosszán - ha tudja. A tördelésről egyelőre ennyit, a TCP csatornák elemzésénél még visszatérünk a témára.

Protocol Coalesce Tool

A széttöredezett PING remek lehetőséget nyújt egy másik nagyon hasznos eszköz bemutatására, amellyel nemcsak a végponti kommunikáló felek, hanem a hálózati forgalmat figyelő köztes személy is képes a töredékeket egyesíteni, s ezzel értékesebb adatokhoz jutni. Sajnos az egyesítő (Coalesce) eszköz az ingyenes, beépített Network Monitorban le van tiltva, így csak vastagabb pénztárcájú olvasóim figyeljenek jól. A vagyonosabbak ugyanis egy szakajtóderéknyi kiváló szakértőt (Expert) is kapnak a NetMonnal, akik különféle elemzéseket végezhetnek a már elkapott/elmentett hálózati forgalom alapján. A Tools->Experts menüpontból indulunk (figyelem, a NetMon menüi változnak annak függvényében, hogy melyik ablakban: a fő vagy a részletes nézetben ácsorgunk éppen!) ahol elénk tárul egy csomó fura szerzet, amelyekkel részletesebben majd egy későbbi cikkben foglalkozom, most a töredezett ping összevonására összpontosítunk.

A Protocol Coalesce Tool

A "Protocol Coalesce Tool"-t az "Add to Run." gombbal áthajítottam a jobboldalra, a lefuttatandó feladatok közé, s a "Run Experts" megnyomása után máris gyönyörködhetünk, no nem az eredményben, hanem abban az útvonalban, ahova a szakértés eredménye került, ami roppant szívderítő látvány, különösen, ha a Desktopra teszi ;)

Innen már csak egy kis egérfutkosás, és megnyitható a késztermék, az összevont pingek fájlja. Vessünk egy pillantást egy összevont ICMP Echo-ra. Mekkora az Ethernet keret mérete?

Összevont bigping

Amint az a fenti ábráról leolvasható, a keretméret 10042 bájt (8), ami sokszorosa a maximális 1514 bájtnak. Az összevonás eredménye többé soha nem tuszkolható ki az Ethernet hálózatba, bármennyire is szabványos keretnek látszik első pillantásra, s bármilyen csábító is a pénzes NetMon "Transmit Frame" menüpontja. Number of data bytes remaining? 10028=10000 betű + 20 bájt IP fejléc + 8 bájt ICMP fejléc. Pont, mint azon az előző ábrán, ahol a ping darabolás előtti állapotát rajzoltam le.

Ugyanezzel az eszközzel lehet egy, akár megabájtos keretbe összeszedni a hálózati forgalomban tördelve utazó dokumentumokat. De nem akarok további hackertippeket adni, haladjunk a korral, és lássunk más érdekességeket az ICMP háza tájáról.

Tracert

Gondolkodott-e már valaki azon, hogy a tracert (Trace Route) parancs honnan a csudából tudja két távoli végpont között az útvonalat? Talán le lehet kérdezni az útválszatókat? Lehet, hogy le lehet, de honnan tudjam, hogy melyiket, hisz az IP-ben éppen a szabad útválasztás az egyik legnagyobb találmány a világon, azaz akár minden egyes IP csomagom más útvonalon juthat el a célállomásig. Vajon van-e esély arra, hogy hálózati forgalmam nem a tracert által kiírt/megjósolt irányba fog menni? Ha alternatív útvonalak vannak a két végpont között, és az útválasztók útvonaltáblája is lehetővé teszi, akkor bizony jó esély van rá! Aki esetleg nem emlékezne rá, a tracert így működik:

Sajnos túl közel ültem a webkiszolgálónkhoz, így a lista rövidre sikeredett, de a világ más tájairól a www.netacademia.net bizony akár 40 routernyi távolságban is lehet! A válaszban soronként láthatjuk a köztes útválasztókat, valamint azok (3 darab) válaszidejét. A válaszidők átlaga talán többet mondana, de ez a jószág három különböző mérésének eredményét nem képes kiátlagolni, hanem szépen kiírja mindet egymás mellé. Például az as5200-0.ahol.com [212.97.9.1] nevű gép először 510 ms, másodszor 361 ms, végül a harmadik mérésre 260 ms alatt válaszolt. Ha a mért idők helyén csillagokat látunk, akkor az adott válaszidő több volt, mint 1 másodperc.

Idejében elindított NetMonnal szerencsésen elkaptam a tracert hálózati forgalmát, hogy megvizsgálhassuk, vajon melyik az a protokoll, amivel routereket lehet lekérdezni.

Igen, az ICMP-ről van szó már megint. Említettem, hogy az ICMP-nek rengeteg változata van, ezek közül most ismerkedjünk meg az Echoval. Na neeeeeeee! Már megint a ping?

Igen, a ping fog segíteni, mert olyan érdekes módon fogjuk használni, hogy a router kénytelen lesz válaszolni, azért mert a csomag TTL-je - gonosz módon - még a célba jutás előtt lejár. A múltkori cikkben emlékeztem meg az IP fejléc mezőiről, s akkor esett szó a TTL szerepéről, ami megakadályozza, hogy egy csomag a végtelenségig keringjen hibás útválasztású hálózatodon. Általában egy IP csomag elég magas TTL-lel indul útjára (128), ami elegendően nagy ahhoz, hogy a földet akár háromszor is körbeutazza. A tracert parancs azonban a legelső csomagot 1-es TTL-lel adja fel, amely az első útválasztón azonnal halálra ítéltetik. Mit tesz ilyenkor a router? Akár csendben el is temethetné a csomagot, de visszaszól, mégpedig - és ez tényleg új ICMP szerep - ICMP Time Exceeded üzenettel (időtúllépés). Ennek a válasznak a megfordulási idejéből számítódik és íródik ki a képernyőre a legelső válaszidő. Ezután a tracert még két ilyen TTL=1-es csomagot kiküld, hogy meglegyen a három mérési érték, utána három darab TTL=2 küldése következik, majd TTL=3 és így tovább, amíg a TTL elég nagy nem lesz ahhoz, hogy a csomag eljusson a végállomásig, s az Echo-ra megérkezhessen az Echo Reply. Madártávlatból a folyamat így néz ki:

A tracert forgalma

S most vizsgáljuk meg az egyes csomagokat! Vajon a feladott Echo-kban mi az IP cím? Mindig a legközelebbi routerre mutat? Szó sincs róla, mindig a végcél IP címe van benne, csak a csomag (az alacsony TTL miatt) nem jut el a célba. A Time Exceeded csomag beltartalma, részenként a következő:

A Precedence értéke megváltozott Routine-ről (0x00) Internetwork Controlra (0xC0).

Innentől pedig megismétlődik az eredeti IP csomag, hogy az időtúllépési üzenetet fogadó oldalán fel lehessen ismerni, mi nem ért célba:

A hibaüzenetet feladó gép IP címe alapján a feladó még elvégez egy fordított DNS lekérdezést (reverse lookup), hogy megtudja annak a routernek a DNS nevét (ha van), ahol a csomag elhunyt, majd kiírja a képernyőre. Az én esetemben a fordított lekérdezés azért nem látszik az elkapott hálózati forgalomban, mert többször is lefuttattam ugyanazt a parancsot, s míg legelőször még szükség volt a reverse lookupra (de akkor még nem futtattam a NetMont), a továbbiakban már nem, mert a Windows 2000 ügyféloldali DNS gyorsítótára elmentette a válaszokat, amit IPCONFIG /DISPLAYDNS-sel le is ellenőrizhetünk.

Egy kérdés maradt hátra: vajon biztosan a tracert által kiírt útvonalon fognak haladni csomagjaink? Mint az a madártávlati képből látszott, itt egymástól teljesen független IP csomagok jöttek-mentek, az egyiknek kisebb volt a TTL-je, a másiknak nagyobb, de a feladó és a cél IP címén kívül más közös nem volt bennük. Ad abszurdum még az is elképzelhető, hogy minden egyes tracert csomag más úton jut el a számára kijelölt kivégzési pontig (ahol elfogy a TTL), így az útvonalinformációt - nagyobb távolságokon - igencsak fenntartásokkal illik kezelni.

Pathping

Ha valaki esetleg veszi a fáradságot és körülnéz a Windows 2000 SYSTEM32 könyvtárában, talál ott egy pathping.exe parancsot, amely nagyjából ugyanazt tudja, mint a tracert azza kiegészítve, hogy képes leellenőrizni az útvonal teljes hosszán az RSVP protokoll támogatását. Az RSVP a Resource Reservation Protocol rövidítése, és garantált sávszélesség (QoS, szolgáltatásminőség) lefoglalására használható olyan útvonalakon, ahol minden router támogatja ezt a lehetőséget. Csínján bánjunk a Pathpinggel, mert elég alapos/erőszakos jószág! Míg a tracert beéri routerenként 3 pinggel, addig ez utóbbi valóságos pingáradatot ereszt meg a célgép felé (routerenként 100 darab ICMP Echo!!), igaz, mérési eredményei jóval pontosabbak a tracert-től kapott adatoknál, hisz száz ping esetén már van mit statisztikázni: százalékosan meg tudja mondani, melyik útválasztó mennyit hibázik. Az alábbi ábra azt mutatja, hogy milyen kiváló vonalaink vannak a Microsoft.com-ig ;)

A pathping eredménye

Ennek a mérésnek a hálózati forgalma 1000 (ezer!) darab ICMP Echo-t, és Replyt jelentett, erre bizonyíték az elkapott forgalom utolsó "keretében", a statisztikacsomagban olvasható:

A statisztikacsomagot mindig a NetMon Trace utolsó csomagjában, az itt felhasznált fájlokat (pigping.cap, tracert.cap, pathping.cap) pedig a weben találják Lelkes Olvasóim.

Fóti Marcell

marcellf@netacademia.net

Network Monitor IV

E havi NetMonozásunkat nem a NetMonnal a kézben kezdjük. A TCP csatorna jellegzetességeinek megfigyeléséhez előbb át kell esnünk egy kis elméleten. A múltkori részben többször elénk került (az IP fejlécben, az Ethernet keretben, az ICMP Echoban) a csomagok integritását végző ellenőrzőösszeg, a checksum. Nem igazán fejtettem ki a védelem mibenlétét, de nem is lett volna miről írni: a checksumkezelés igen primitív algoritmus alapján zajlik. A hálózati forgalmat generáló és irányító eszközökön minden egyes beérkezett csomagon kiszámítódik az ellenőrzőösszeg. Ha a kiszámított érték megegyezik azzal, ami a csomagban is olvasható, a csomag életben maradhat, ha pedig nem egyezik, vesszen a hibás, deformálódott egyed.

Maradjunk annyiban, hogy az alapértelmezett checksumkezelés elég drasztikus módon ugyan, de eltávolítja a hibás csomagokat a hálózatról.

Vizsgáljuk meg, mekkora az a maximális hiba, amit a checksum még elvisel. Ez az összegszámító algoritmustól függ. Az Ethernet kártyák által használt CRC (Cyclic Redundance Code) például akár egyetlenegy bit átbillenését is észleli.

• Ha átbillen egy bit - elromlik az ellenőrzőösszeg
• Ha elromlik az ellenőrzőösszeg - eldobódik a csomag
• Ha eldobódik a csomag - elvész az átvinni kívánt adatmennyiségből egy jókora (1514 bájt) darab.

Ki, és hogyan fogja ezt észlelni, korrigálni, pótolni? Az IP? Ugyan! Azt már a Tracert esetében is láttuk, hogy ha kicsi TTL-lel indítottuk útjára, elhullott, mint szivacsos agyhártyagyulladásban szenvedő nagy négylábú barom. Bithiba esetén sem lesz jobb a helyzet - elhullik.

A kieső csomagok pótlására akár maga a hálózati szolgáltatást igénybevevő alkalmazás is vállalkozhatna - ha tudatában lenne ennek a nehéz feladatnak. De vegyünk egy Excelt. Annak bizony egyre megy, hogy a FONTOS.XLS-t vajon helyi lemezre, vagy hálózati kiszolgálóra mentjük! A második jelöltünk e feladat ellátására az operációs rendszer (pl. Windows 2000) lehetne, ami részben igaz is: Az operációs rendszer egyik meghajtója, a tcpip.sys felel a csomagelvesztések menet közbeni korrekciójáért, a hiányzó "alkatrész" pótlásáért. Ennek érdekében a feladó oldalán a tcpip.sys minden egyes csomagot besorszámoz, hogy a fogadó oldalán csücsülő tcpip.sys a sorszámok alapján pontosan észlelhesse, ha kimarad egy-egy csomag. Az eredményességről vagy eredménytelenségről pedig rendszeres visszajelzést küld a feladónak (ACK, acknowledgement)

A TCP csatorna

Mit hívunk TCP csatornának? Csak nem ezt a teljesen primitív sorszámozós rendszert? De igen. És bármilyen furcsa lehet, a maga "bonyolultságában" ez a rendszer meglepően jó hatásfokkal működik, s messze többet tud, mint csomagelveszítéseket korrigálni. Észreveszi ugyanis a csomagsorrend cserét is, valamint a csomagok megduplázódása sem marad rejtve.

A TCP csatornát úgy célszerű elképzelnünk, mint egy csőpostát, amely két számítógépet úgy köt össze, hogy amit a cső egyik végén bedobok, az a másik végén épen, egyben bukkan fel.

Egy TCP csatorna "idealista" ábrázolása

A cső feladata a szállítás garantálása, illetve annak jelentése, hogy ha a szállítás nem valósítható meg. Sokszor mondják, hogy a TCP/IP katonai rendszer. Ezt a badar tévhitet a TCP csatorna azon viselkedése is erősíti, hogy ha romlik a vonalak minősége, akkor a cső lelassul (iszonyatosan le tud lassulni!), de NEM adja fel! Mintha bizony államtitkot kellene eljuttatnia a végpontra! Addig kínlódik, új utakat keres(nek helyette a routerek), ismételget, amíg van benne szusz. Ha pedig minden lehetőség kimerült, akkor jelenti alássan, hogy a haditervet nem sikerült teljesítenie. Olyan nincs, hogy a TCP félrevezetne minket, és úgy tenne, mintha minden rendben menne.

Miből áll tehát a TCP csatorna? Ezernyi sorszámozott csomagból, melyek oda-vissza szaladgálnak a kommunikáló felek között. Némelyikben adat van, némelyikben csak egy ACK, és mindegyikük (legalábbis Etherneten) maximum 1514 bájt nagyságú. Egyedi csomagok ezrei.

Vajon azonos útvonalon haladnak az Interneten át? Nyilván nem. Helyesebben: akár azonos útvonalon is haladhatnak, de ezt a közbenső útválasztók és vonalak pillanatnyi "hangulata" erőteljesen befolyásolja. Az előbbi, idealista ábránd helyett a valóságot sokkal hűségesebben adja vissza az alábbi ábra:

Egy TCP csatorna "valósághű" ábrázolása

Ha még azt is figyelembe vesszük, hogy egy gépen a nyitott TCP csatornák száma nem 1, hanem akármennyi, akkor az ábrán úgy néznének ki a gépek, mint egy-egy polip: egyik karja a www.netacaemia.net-re tekeredik, másik a www.microsoft.com-ra, harmadik a tartományvezérlőre stb.

Portok

Ha egy számítógépnek ennyi karja lehet, akkor vajon miért nem zavarodik bele abba, melyik karja merre nyúlik? Vegyük először egy internetező-böngésző felhasználó esetét. A célgép IP címe vajon segít a sok-sok csatorna egyedi azonosításában? Csak addig segít, amíg egy címre csak egyetlenegy TCP kapcsolatot (csatornát) nyitunk. Ez azonban nem mindig van így, hisz senki sem tilthatja meg nekünk, hogy egy weblapra öt böngészőt nyissunk! Vagy vegyük egy webkiszolgáló esetét. Egyszerre mondjuk tízezer kapcsolatot szolgál ki. Honnan tudja, hogy melyik csőbe mit kell dobni? A feladók IP címe segít? A válasz ugyanaz: ha elindítok tizennyolc böngészőt egyazon gépről ugyanarra a webkiszolgálóra, akkor e tizennyolc csatornát hogyan fogjuk tudni megkülönböztetni egymástól?

Még egy eszmefuttatás: ha egy Internetre kihelyezett gépen nemcsak webkiszolgáló fut, hanem FTP, Telnet, POP3 és még ki tudja mi minden, vajon hogyan címzem meg az egyes alkalmazásokat? Hogy van az, hogy a böngésző mindig a webkiszolgálót szólítja meg? Mindig? Tévedés! Tessék így kezdeni a begépelt URL-t: ftp://www.netacademia.net.

Mi az ördög? Ftpzik? Ftpzik!

A csatornát általában nem tudjuk a végpontjainak IP címével egyértelműen megadni. Szükség van még egy azonosítóra, amely segít megkülönböztetni az azonos gépről érkező kapcsolatokat egymástól, segít elválasztani a HTTP kérést az SMTP-től segít egy távoli gépen "eltalálni" a sok-sok futó szolgáltatás közül pont azt, amire vágyunk: ez a portszám.

1. Villámkérdés: Hányas porton megy a webszerver?

2. Villámkérdés: Hányas porton megy az Internet Explorer?

1. villámválasz

Az első kérdésre mindenki fújja a választ: 80-as. Így igaz. De miért pont a 8 -ason találjuk a webkiszolgálókat? A 80-as úgynevezett well-known (jól ismert, közismert) port, és azért pont nyolcvan, hogy a világ összes publikus számítógépén mindig megtaláljuk a webszolgáltatást. Nem kell gondolkodni, paraméterezni és programozni: ha egy gépen a nyolcvanas számú ajtón (porton) megyünk be, akkor ideális, szét-nem-konfigurált esetben a webkiszolálón vagyunk.

Portok, kapcsolatok

Hány kapcsolat építhető egy portra? A fenti ábra tanúsága szerint egészen pontosan X. Az egyetlen követelmény, hogy a kapcsolatok megkülönböztethetők legyenek. Mivel ezen az ábrán (szinte)mindegyik ugyanarra a portra fut be, ezért a szerveroldali végük alapján nem különböztethetők meg - így nyilván az alsó, "rojtos" végük különbözik. Különböző IP címekről jönnek, vagy ha azonos címről, akkor külön portról.

A 80-as port egyébként nem szentírás, a legtöbb szolgáltatás átállítható, más portra helyezhető. De ezzel el is veszítjük, ha csak valaki meg nem súgja a helyes portszámot. Ha valaki pl. a 8080-as portra tesz webszolgáltatást, akkor azt így kell becserkészni: https://www.matav.hu:8080. Ez a módja annak, hogy a böngészőnk más porton kopogtasson.

2. villámválasz

A második kérdésre is sokan rávágják: 8 -as :-O No ez nem igaz! Hisz ha nyitok két Explorert pont ugyanarra a webkiszolgálóra, sőt, ugyanarra a lapra, ezt a két kapcsolatot is meg kell tudnom különböztetni, hisz az egyik lapon teljesen másra kattinthatok, mint a másikon, s a két böngészőm ebbe nem zavarodhat bele! A böngészők és egyéb ügyfélszoftverek úgynevezett kliensporton "ülnek", aminek száma egyedi, és 1024-nél nagyobb. Az alábbi ábrán egy olyan gépet látunk, amelyen egyszerre X darab IE, és Y darab Netscape Navigator fut párhuzamosan, békességben.

"Ötszáz" böngésző egy gépen: egyedi portszámokon futnak!

Kijelentésem igazságát a

utasítás begépelésével ellenőrizhetik bátrabb olvasóim.

Tűzfalak, proxyk

Az eddigi ismeretekkel felvértezve megkísérelhetjük megérteni, mit is jelent az, amikor a tűzfal 80-as portja nyitva van. A tűzfalakon átmenő forgalomnak ugyanis meghatározott iránya van: lehet befelé, és kifelé igyekvő csomagunk. Ezen túl érdemes megfigyelnünk az így áthaladó csomag feladó és fogadó portszámát. Csak a -as porti forgalomnak négy változata van!

Ebből a négyből azok a tűzfalak, amelyek kizárólag a kifelé irányuló webböngészést engedik, csak az első és a negyedik csomagtípust eresztik át, sőt, az okosabbak csak olyan elsőt (külső választ), amely válasz egy negyedikre (weblapkérés). Ez a tűzfaltípus tehát a rajta átívelő TCP csatornák kinyitására és elzárására képes. Ha a csatornát engedélyezi, akkor visszavonul, és az átmenő forgalmat már nem ellenőrzi. Jöhetnek a vírusok!

Egy jobb tűzfal nemcsak nyit/zár, hanem megpróbálja az átmenő forgalmat értelmezni, szűrni, hogy a nyitott csatornákon át ne lehessen mást forgalmazni, mint ami oda "való": a 80-ason csak HTTP, a 25-ön kizárólag SMTP mehessen stb. Az ilyen típusú tűzfalakat más néven proxynak is hívják. Ilyenkor a kliens nem a végcéllal épít ki TCP csatornát, hanem a tűzfallal. Az minden csomagot kiszed a csőből, és ha értelmesnek találja, továbbküldi kifelé, és egy, a kliens helyett (proxy=helyettesítő) általa felépített TCP csatornába dobálja bele az adatokat. Ilyenkor a feladó és a fogadó valójában sohasem találkozik közvetlenül egymással.

Szekvenciaszámok, háromutas kézfogás

Az utolsó kérdés a TCP sorszámozásának megvizsgálása. Említettem, hogy a TCP minden egyes csomagot besorszámoz, mielőtt feladná. Nem említettem, de sejthető, hogy a visszirányú hálózati forgalom is sorszámozott: minden ACK egyedi sorszámmal bír. Mielőtt azonban a felek megkezdhetnék a kommunikációt, meg kell ismerniük egymás kezdősorszámát. Nem, nem egytől indulnak, hanem random számokat használnak - ennek biztonságtechnikai okai vannak. Azt a folyamatot, amikor a partnerek kicserélik egymás szekvenciaszámát, kézfogásnak hívjuk. Én inkább csip-csip csókának hívnám, mert olyan ez a három csomag, mintha egymás kezére tennék egymás kezét, de sajnos a W3C nem fogadta el e terminológiai javaslatomat :( Az angol elnevezés továbbra is three-way handshake, pedig a chip-chip-choka mennyivel találóbb lenne!

Körülbelül így zajlik a folyamat:

1. A feladó kapcsolatot kezdeményez a fogadógéppel a megcélzott (mondjuk 80-as) porton, és elküldi saját kezdősorszámát. Ezt a csomagot világosan meg lehet különböztetni a Network Monitorban a benne bebillentett "S" flagről. (S, SYN=Synchronize Sequence Numbers). Így fog kinézni a Network Monitorban:

..S.

2. A fogadó (ha van a megszólított porton szolgáltatás) pozitív választ küld, egy ACK formájában. Az ACK mindig azt mutatja, hogy a partner melyik szekvenciaszámtól folytathatja az adást. Így ez az ACK az előbb megkapott szám plusz egyet (S+1) fog tartalmazni. Jelentése: oké, innentől jöhet! Továbbá -sávtakarékossági célból még ugyanebben a csomagban - ő is elküldi saját kezdő szekvenciaszámát, amivel pedig a tőle kiinduló csomagokat sorszámozni fogja:

.A..S.

3. Végül az eredeti kezdeményező küld egy ACK-ot, s ezzel a csatorna felépült.

.A..

E három csomag után következhet az oly fontos adatok átvitele. Miután az összes adat átment, a csatorna bontása szintén csip-csip csóka módszerrel történik. Ekkor nem az "S", hanem az "F" flag segít, melynek jelentése: No more data from sender. A lebontás így néz ki:

...F

.A.F

.A...

Ezzel a felek illendőképpen elbúcsúztak egymástól, ásó, kapa, nagyharang. Lássuk mindezt élőben!

Nyitott 80-as port

Az első NetMon fájl, amit mutatok, a nyitott80.cap nevet viseli, és helye szokásosan az újság weblapjának feladatok alkönyvtárában található. 1,5k csupán, érdemes letölteni, hogy vizsgálatainkat együtt folytathassuk!

A TCP csatorna felépítése

Az ábrán jól látható az előbb magyarázott háromutas kézfogás, ahol a description mezőben egymás alatt három sorban ezt látjuk:

..S.

.A..S.

.A..

Az előtte lévő két DNS sor egy Standard Query és egy Response. Ezeket ismertnek veszem csakúgy, mint a Bone protokollt. Hogy miért ismertek? Mert aki nem a negyedik résztől kezdte olvasni sorozatomat, annak ez már a könyökén jön ki.

Nyissuk meg a ..S. csomagot, lássuk mi minden van benne!

Synchronize Sequence Numbers

Ethernetben IP-ben TCP. A feladó portszáma (1), a 0x047A egy kliensport, hisz ez a szám nagyobb, mint 1 24. A célgépen pedig a sokat emlegetett 80-as portot, vagyis egy webkiszolgálót céloztunk meg. Ezt a portot a NetMon is ismeri (nem hiába well-known), és oda is írja szépen a protokoll nevét (2), míg a hexa panelen egy 0x50(=80!) látványának örvendezhetünk. A szekvenciaszámról lesír, hogy random érték (3), az ACK pedig azért nulla, mert ez a legelső csomag ezen csatorna életében, nem tartunk még a visszajelzéseknél. A flag bitjei a következők lehetnek:

..0..... = Urgent data

...0.... = Acknowledgement field significant

....0... = Push function

.....0.. = Reset

......0. = Synchronize sequence numbers

.......0 = No more data from sender

A TCP-nek is van ellenőrzőösszege, ahogy az eddigi összes rétegnek volt. A Widow (4) érték - ha nagyon pongyolán szeretnék fogalmazni - annyi jelent, hogy 8760 bájt küldhető át a hálón visszajelzés, ACK megvárása nélkül. Lássuk a választ!

Synchronize Sequence Numbers válasz

A portoknál megfigyelhető, hogy az előbbi feladóból fogadó lett, s a fogadóból feladó (5): a webkiszolgáló válasza a 80-as portról jön, és a kliensportra megy. A válaszoló webgép is generál egy szekvenciaszámot, amivel a tőle kimenő csomagokat majd sorszámozni fogja (6). Érdekes összehasonlítani az itteni ACK számát (7) az előző csomag szekvenciaszámával: hát nem pont egyel több? S mit várhatunk a harmadik csomagtól? A feladóismét a kliens, s "leackolja" az itteni szekvenciaszámot, így ott ez olvasható:

Vajon hogyan fordulhatott elő, hogy e három csomag után végetért a móka, és nem hullott a kliensre egy Default.HTM? Sőt, semmi sem hullott! Ennek az az oka, hogy a fenti forgalmat nem Explorerrel generáltam, hanem telnettel: rácsatlakoztam a távoli gép 80-as portjára, így:

Mivel a telnet.exe nem kifejezetten webböngésző, nem küld be a világon semmit a kész csatornába, így az idővel lebomlik. A bomlás virága az alábbi DOS ablakba böffintett HTML hibaüzenet.

"Betelnetelek" a 80-as porton

Valójában a telnet.exe igen jó TCP segédeszköz, ugyanis nem csinál mást, mint felépít egy TCP csatornát kliensportról egy távoli gép tetszőleges portjára, majd nem szól bele egy mukkot sem, teljesen ránk bízza a csatorna adattal történő ellátását.

Zárt ajtók

Most vizsgáljuk meg, hogyan néz ki az a hálózati forgalom, amikor olyan portra próbálunk meg csatlakozni, amely nincs nyitva.

"Betelnetelek" a 8 -es, zárt porton

Azt hihetnénk, hogy a zárt port meg sem mukkan, de nem így van, mert ha válaszra sem méltatna minket, akkor hálózati hibára gyanakodva még X-szer megkísérelnénk a kapcsolatfelvételt. Emiatt tehát - az udvariasság jegyében - elvárható, hogy ha bekopogunk mondjuk a 82-es porton, akkor - mint Nyuszi a Micimackóban - visszaválaszolnak, hogy "nincs itthon senki". Ebből tudhatjuk, hogy tényleg üres a ház - ennek dacára három csatlakozási kísérlet történik, aminek az az oka, hogy sajnos nem derül ki egyértelműen a kopogtató számára, hogy mi az elutasítás oka. Az egy és oszthatatlan Reset Connection üzenet egyaránt jelenthet csukott portot és szoftveres elutasítást (például ha nincs reverse bejegyzés az IP címünkhöz). Ennek hálózati forgalma a weben a csukott82.cap fájlban található, s így fest:

Reset connection

A szokásos S kérésre ebben az esetben R (Reset connection) a válasz, amit ezután nem is követ harmadik csomag. Tekintettel arra, hogy az elutasítás egyetlen bittel történt, sajnos indoklást nem találunk a csomagban.

..S.

.A.R..

POP3

Most próbáljunk ki egy valódi alkalmazás működését Telnet segítségével! Próbáljuk meg elolvasni leveleinket POP3 protokollal, ám ügyfélprogram nélkül, puszta kézzel! (Nem fogom végigvezetni, csak a bejelentkezésig vizsgáljuk meg a hálózati forgalmat. A fájl neve: pop3.cap)

POP3 , puszta kézzel

A létrejövő TCP csatornában a kiszolgáló elküldi üdvözlő üzenetét (8), majd várakozó álláspontra helyezkedik, parancsra vár. A decemberi számunkban megjelent POP3 szabványismertető alapján haladva először megadjuk a felhasználó nevét majd jelszavát (9). Ilyen felhasználó sajnos nincsen, de sebaj. Most nézzük a NetMont!

A pop3.cap fájl

Te jó ég! Ez a két parancs 62 csomagot generált (1 )! Hiszen összesen 3-4 kérdés és válasz történt! Mi lehet ez?

Terminálemuláció

Eddig nem került szóba a telnet.exe valódi funkciója, származása. Természetesen tud TCP csatornát nyitni, de ezt azért teszi, hogy utána a TCP csatornát pontosan ugyanarra a célra lehessen használni, mint a régi terminálok "hálózati" kapcsolatát, a soros portot - vagyis karakterek átvitelére! A Telnet.exe úgy emulálja a terminálfunkciót, mintha a TCP csatorna egy vacak RS-232 kábel lenne. Vagyis, ha a felhasználó leüt egy karaktert, az már mehet is át a "kábelen". Igen ám, de itt egy virtuális "kábelről" van szó, melynek csatornajellegét az ide-oda küldött ACK-ok tartják fenn. Így a karakterenkénti átküldés eléggé sajátságos sávszélesség-gazdálkodást eredményez: minden 55 bájtos TCP csomagban EGYETLEN bájtnyi hasznos adat utazik!

Number of data bytes remaining

Csak nézzük meg szúrópróbaszerűen a Number of data bytes remaining-et mondjuk a 3 keretben! Egy nyamvadt "p" betű a hasznos adat (11)! A többiben pedig rendre "a", "s", "s", " ", "t", "i", "t", "o", "k". Azaz "pass titok". Ejnye. Titkosítatlanul megy át a hálózaton a jelszavunk? Igen, nagyon sok alapalkalmazásnál ez így történik, ami ellen a csatorna titkosításával védekezhetünk - de az SSL egy másik, hosszú történet. Ami pedig a sávszélesség okos ihasználását illeti - a telnet ebben nem jeleskedik.

7 bites az Internet?

A fenti kísérlet rávilágít egy érdekes dologra. Mint ahogy a TCP/IP nem katonai rendszer, úgy az a közvélekedés is színtiszta badarság, hogy az Internet bizonyos zugai 7 bitesek lennének. Mitől terjedt el ez a tévhit? Valami igazságalapja kell, hogy legyen! Van is. Bizonyos alkalmazásprotokollok nem binárisan kódolt üzeneteket váltanak, hanem egyszerű szöveges parancsokkal kommunikálnak. A POP3 is jó példa erre, azonban az SMTP tökéletes. Ha ugyanis betelnetelnénk egy SMTP kiszolgálóba a 25-ös porton, akkor (nagy vonalakban) így tudnánk pusztakézzel levelet küldeni:

A fenti utasításokkal lehet levelet küldeni mindenféle Outlook és egyéb úri huncutság nélkül. Mivel az SMTP a soremelést veszi a parancs végének, ennek a "karakternek" különleges szerepe van mind az SMTP, mind a POP3, IMAP4 kommunikációban - és még sok más protokollban. Tulajdonképpen minden "különleges" karakternek "különleges" szerepe van, mivel a fejlesztők nem igazán gondoltak sem a magyar nyelvre, sem a később elterjedt csatolásküldésre (virus.exe). Mivel a régi SMTP-t kidobni nem lehetett, a szabványfejlesztők érdekes módon vágták át a gordiuszi csomót. Minden olyan adat, ami nem írható le az angol ABC kis- és nagybetűivel - LEGYEN leírható az angol ABC kis-, és nagybetűivel!! Bölcs döntés nemde? Ezt hívják kompatibilitásnak. S lőn UUENCODE és MIME kódolás, melyeknek pont az a feladatuk, hogy a virus.exe csatolt fájlt enterekkel zárt, fix hosszúságú sorokból álló szöveges alakra hozzák, hogy az SMTP ne boruljon fel tőle! Hoppá! Ipartörténeti érdekesség!

Mire nem jó a TCP csatorna?

Végezetül essen szó arról is, hogy a TCP csatorna nem mindenható, egyáltalán nem minden esetben érdemes használni, sőt olyan forgalomtípusok is léteznek, melyeket képtelenség csatornába zárni. Lássuk a két esetet:

1. Nem érdemes TCP csatornát használni viszonylag kevés adat átvitele esetén, amikor többe kerülne a leves, mint a hús. Gondoljunk bele: a TCP csatorna felépítése 3 csomagot igényel, s a bontás sem "olcsóbb". Ez a 6 keret az ára a megbízhatóságnak. De mi van akkor, ha csak egy-két csomagom van, melyek akár el is veszhetnek? Vagy még ha nem is veszhetnek el, az egyszerű megismétlés bőségesen elég? Gondoljunk a DNS-re egy kérdés - egy válasz. Nincs szükség tördelésre, szekvenciaszámokra stb. Ha TCP csatornában küldenénk az egyszerű DNS lekérdezéseket, két csomag helyett nyolcat kellene használni!
2. Nem lehet TCP csatornát használni olyankor, amikor kettőnél több kommunikáló fél van, mert a TCP csatornának csak két vége lehet. Azaz nem csatornázunk Broadcast esetén, illetve multicast adatfolyam átvitelekor sem.

Ha nem jó, vagy nem kell a TCP, akkor használunk UDP-t (User Datagram Protocol), ami tulajdonképpen a TCP "light" verziója. Portszámhasználat ilyenkor is van, ám nincs szekvenciaszám, ACK és chip-chip-choka. Viszont mivel pontosan ugyanazon a programozói felületen keresztül érhető el (WinSock), rendkívül kényelmesen használható.

Fóti Marcell

Marcellf@netacademia.net

Network Monitor V.

Az eddigiekben megismerkedtünk a hálózatfigyelés alapjaival, s a TCP csatorna felismerése megadta a kulcsot az összes rejtély megfejtéséhez, hisz minden izgalmas forgalom TCP csatornában zajlik. Ha megvan a csatorna építése és bontása, s ezzel maga a csatorna, akkor már "csak" a köztes hálózati forgalmat kell elemeznünk. Ehhez azonban új eszközökre, és a mindenkiben szunnyadó matematikai képességek (sőt Boole-algebra!) kiaknázására lesz szükségünk. A dolog nem olyan vészes, mint amennyire ijesztő: egyszerű logikai kapcsolatokat fogunk felépíteni a csomagok egyes tulajdonságai alapján, azaz szűrünk.

De lassan itt az ideje, hogy elszakadjunk az eddigi vizsgálati módszerektől is, hisz mindezidáig steril körülmények közt NetMonoztunk: csak az a hálózati forgalom került a szemünk elé, amit valóban szemügyre akartunk venni. A valós életben, amikor a Network Monitort hibakeresésre, és egyéb véres dolgokra használjuk, sajnos nincs lehetőség az összes nemkívánatos hálózati forgalom elnémítására. Mi több, nemcsak kiszámítható, és adott esetben elnémítható hálózati forgalmakkal szembesülünk, hanem olyasmivel is, ami - csak úgy - egyszer van, egyszer nincs. Ki tudná ugyanis pontosan megjósolni, hogy két tatrományvezérlő mikor kezd násztáncba, s mikor hullatja a hím tartományvezérlő magját a nőstény tartományvezérlőbe?

Megoldás szerencsére majdnem mindig van. Ha a felvételi körülmények nem ideálsak, az ügyes nyomozó mindent begyűjt, s majd (otthon, a kandalló melegénél) offline szétválogatja az értékes nyomokat az értéktelenektől. Ezt az eljárást szűrésnek nevezzük. Az igazat megvallva a NetMon képes lenne eleve szűrt adatok felvételére, mert futás közben is használhatunk szűrőket, de ezzel egyfelő lehet, hogy értékes adatoktól fosztjuk meg magunkat, másfelől a futás közbeni szűrők sokkal promitívebbek, mint amit offline használhatunk.

Érdemesebb talán egy kicsit több memóriát rászánni a feladatra, s egy kicsivel többet összeguberálni, több szemétben több az arany - mondja az ószanszkrit közmondás. A Network Monitor memóriában tárolja az elkapott hálózati forgalmat, ehhez induláskor puffert foglal (alapértelmezésben 1 megabájtot), s a pufferen jár körbe-körbe. 1 megabájt terhelt hálózat esetén általában kevés, hisz ezen a területen körbe-körbe jár, így elég nagy eséllyel felülírja a 30 másodperccel korábban rögzített adatokat. Az alábbi ábra azt mutatja, hogyan lehet a Network Monitor alapértelmezésben 1 megabájtos memóriapufferét megnövelni - mondjuk - tíz megabájtosra.

Növeljük meg a puffert, hisz 1 MB semmire sem elég!

A fenti ábrán az is megfigyelhető (1), hogy a puffertúlcsordulás nem maradna rejtve árgus tekintetünk elől - ha árgus lenne a tekintetünk. Én már elemeztem körbefordult hálózati forgalmat. Másfél órát rabolt el az életemből ez az apró figyelmetlenség.

Webböngészés

Első hálózati forgalmunk a mai alkalommal a http.cap, melynek tartalma a https://www.netacademia.net letöltése közben keletkezik. Ez sem nevezhető különösebben zavarosnak, de több TCP csatorna van benne, így minimális szűrőzésre alkalmat ad. Ha letöltik kedves olvasóim az [1] címről, és beletekintenek, valami hasonlót kell látniuk ehhez:

A http.cap tartalma

Vagyis a szokásos Bone protokoll mellett (mely a Network Monitor használat velejárója) csatornaépítési és HTTP parancsokat láthatunk, összesen 181 csomagon keresztül. Ugye mostanra már mindenki tudja, hogy amit HTTP-ként látunk a NetMonban, az csak az adott csomag lényege, de valójában mindegyik sorunk összetett csomagokat tartalmaz, a HTTP - mint tudjuk - TCP-ben utazik, a TCP-t IP szálítja, az IP pedig egy Ethernet keret hasznos adata.

Szűrési lehetőségek

Vizsgáljuk meg, a NetMon szűrési képességeit! Talán nem lesz meglepő, hogy különböző szintek információi alapján képesz szűrni, kiválogathatjuk egy adott MAC Address hálózati forgalmát (az ingyenes NetMon használók eleve csak a saját forgalmukat (és a Broadcastokat) látják), egy adott IP című gép adatait, valamint protokollok szerint is szűrhetünk.

A NetMon becsapós kettősségének jegyében a szűrés (filter) elérhető a főképernyőn is, és az elkapott forgalmak ablakában is. A két filter máshol van a menüben, másképp néz ki, és másra is való! A főképernyős filter (Capture menü->Filter) egy lényegesen kisebb funkciókészletű ablakot hoz elő, melyben a futás közbeni szűrőzés beállításait csodálhatjuk meg, (de most nem használjuk), míg a forgalmi adatok ablaknál található filter (Display menü->Filter) teljeskörű, ámde offline szűrést végez, magyarán elrejti/megjeleníti az általunk kiválasztott csomagokat. (Emlékszik még valaki a színezési lehetőségre? Használjuk azt is bátran!) Mielőtt teljesen belemerülnénk, hadd hívjam fel a figyelmet az eszközsáv  gombjára, ezzel ugyanis mindig visszatérhetünk a szűrésmentes nézethez, nem feltétlenül kell újrainstallálni ehhez az egész Windowst :-)

A gazdag funkciókészletű filterablak így fest:

A teljeskörű filterablak egy bonyolult szűrőkifejezéssel

Aki igyenes NetMont használ, az az ablak megnyitásakor figyelmeztetésben részesül, hogy nála a szűrés már kissé megtörtént, csak a saját gépének forgalmát látja. Ebben az ablakban -mint azt talán a gombok is sejtetik - hihetetlenül bonyolult szűrési feltételek adhatók meg, melyeket azután el is menthetünk. Most nyomjuk meg az Expression. gombot, hogy meglássuk, milyen építőkockákból válogathatunk a bonyolult logikai kifejezések összelapátolásához:

Szűrhetünk címekre, protokollokra és egyes bitekre is

Jól látható, hogy háromféle szűrési lehetőségünk van.

Az első (Address) fül segítségével MAC Addressre, IP és IPX címre, valamint egyéb, a NetMon által felfedezett címekre szűrhetünk. Alapértelmezésben az összes elkapott hálózati forgalmat láthatjuk.

A második (Protocol) fülön választhatjuk ki a megjeleníteni kívánt protokollok listáját. Alapértelmezésben az összes előforduló protokoll megjelenített.

A harmadik (Property) fülön pedig az egyes protokollok belső információi alapján is szűrhetünk, ez néhány bekezdéssel később a TCP csatorna megragadására fogjuk használni.

A cím szerinti szűrést külön példán nem mutatom be, annyira egyértelmű. Lássuk a protokoll szerinti szűrést! Legyen az első feladat a http forgalom kiszűrése, ennek érdekében kattintsunk a második fülön, ahol a bal panelen látjuk azon protokollok felsorolását, melyek jelenleg átmennek a szűrőn - azaz mindet.

Alapértelmezésben az összes protokoll engedélyezett

Ne sajnáljuk a Disable All nyomógombot, és dobjuk át a díszes társaságot a jobb oldalra, majd kegyelmezzünk meg a HTTP-nek, és azt az egyet kijelölve, nyomjuk meg az Enable gombot. Ezzel egy olyan szűrőhöz jutunk, mely csa és kizárólag a HTTP csomagokat jeleníti meg. Beállításunk eredménye így nézzen ki:

így már csak a HTTP marad fenn a rostán

Az OK gomb megnyomása után pedig a helyes filter valami ilyesformán alakul (ha nem ezt látják, a szűrés nem ugyanazt az eredményt fogja adni, mint nálam, és a későbbiekben nem egyről fogunk írni/olvasni):

Innentől csak és kizárólag HTTP Get és Response marad előttünk, mégpedig egy-egy Get-hez hat-nyolc Response. A miértet mindenki tudja: Míg a Get elfér egy csomagban (maximum 1514 bájt!), a válasz már ritkán. Nézzük meg a legelső Get-et (hatodik csomag a 181-ből):

A (2) jelzésnél olvasható a kért fájl neve, a sima perjel (/) utal a default dokumentumra. A default dokumentum a mi esetünkben default.asp névre hallgat, és a következő, hetedik csomagban kapjuk vissza. Valószínűleg mindenki számára ismerős a weblapok letöltődésének menete: elsőként egy HTM (vagy ASP vagy egyéb) kiterjesztésű szöveges fájlt tölt le a böngészőnk, melyből kiolvassa, hogy milyen egyéb dokumentumokra lesz még szükség a megjelenítéshez: képekre, stíluslapra stb. Ezeket a további komponenseket külön HTTP Get paranccsal szedegeti le szépen, egyesével, amire bizonyíték a képek későbbi megjelenése, illetve a www.netacademia.net esetében egy komoly pillanatig stíluslap nélkül látszik az oldal, majd egy másodpercre rá megérkezik a stíluslap, és a böngésző átszabja a dizájnt (ez a jelenség csak a legelső látogatóknak szúrhat szemet, mert a stíluslapfájl éppúgy bekesselődik, mint a többi hasonló adat). Ha a többi Get-et megvizsgáljuk, látszik is a letöltés: a 13. csomagban a /css/main.css stíluslap, a 22.-ben pedig az /images/hatter2.gif stb.

A (3) jelnél láthatjuk a protokoll verziószámát. A HTTP 1.1-nél tart. Talán a legszembetűnőbb különbség az 1.0 és az 1.1 között a TCP csatornák újrafelhasználásában mutatkozik. Míg az 1.0 minden egyes dokumentum letöltéséhez külön csatornát nyit, s ezzel csomagtömegeket indít útjára, addig az 1.1 csak annyi csatornát nyit, amennyi a letöltés párhuzamossá tételének érdekében szükséges - vagy más szóval annyit, amennyit a sávszélesség elbír. Minek is nyitna objektumonként külön csatornát, ha a sávszélesség amúgy sem teszi lehetővé egyidőben egynél több GIF letöltését?

Végül a (4) jelre hívnám fel a figyelmet. Itt utazik ugyanis az ASP Suli kukija! Az ASPSESSIONIDGQGQGBDY nevű változó csak legelsőre komlett összevisszaság, a türelmes szemlélődő felfedezheti benne az ASP Session ID szavakat.

Az 56K már elegendő sávszélességet biztosít két párhuzamos csatorna megtöltésére

A fenti ábra (5) jelénél látható, ahogy a böngésző - ki sem várva a 1075-ös csatorna eredményét - párhuzamosan útjára indít egy másik kérést a 1076-os csatornában. A (6) jelnél pedig a csatorna újrahasznosítására látunk példát: a HTTP 1.1 nem lebontja a dolgavégzett csatornát, hanem új feladatot ad neki! Sávszélességspórolás: 6 csomag (3 csomag a bontásra + 3 csomag új csatorna építésére)! Milyen különös, hogy a HTTP 1.1 pont akkorra szabadít fel jelentős sávszélességet, mire az egész sávszélességkérdés röhejessé válik - valahol Amerikában.

Hány csatorna van?

A fenti képernyőképen észrevettünk két csatornát. Ennél azonban tudományosabban is megállapíthatjuk, vajon e fájlban hány különböző TCP csatorna rejtőzik! Egy olyan szűrőre volna szükségünk, amely csak a TCP csatornák legelejét, építési szakaszát mutatja meg nekünk, s azon könnyedén megszámlálhatjuk, vajon tényleg kettő van-e. Ehhez a szűrőhöz bizony már a TCP bitjeire kell szűrnünk, mert a three-way-handshake-t (chip-chip-choka) kell elcsípnünk:

..S.

.A..S.

.A..

Az S flag egyetlen bit csupán a TCP fejléc Flags mezőjében! Ennek kiszűrésére szolgál az Expressions ablak harmadik füle, ahol le lehet menni - nos, sajnos bitszintre nem. De bájtszintig mindenképpen. Ahhoz azonban, hogy sikerrel járjunk, meg kell állapítanunk a S bájtértékét. Ehhez manuálisan kikeresünk egy S csomagot, és onnan kiolvassuk, hogy S=2. A szűrési feltétel ezek után így adható meg:

A S, azaz SYNchronize Sequence Number-ek kiszűrése

A fenti ábra üres helyére odacsempésztem a szűrő logikai felépítését, hogy könnyebb legyen ellenőrizni a helyes beállítást. Az eredmény nem meglepő, két TCP csatornánk van. A szűrő két csomagot hagyott meg (ezért e képernyőképet nem is mutatom), így sajnos nem látszik a teljes csatornaépítés. Azonban ha kilessük a többi lépés bájtkódját is

..S. = 0x

.A..S. = 0x12

.A.. = 0x10

Akkor megfelelő bűvészkedés után majdnem meg is kapjuk munkánk gyümölcsét (közepérevarrtam a logikai kifejezést, már OR is van benne!):

Sok bűvészkedés után kevés eredmény: a TCP "becsapott"!

Az ábra tanúsága szerint kétségkívül megfogtuk a three-way-handshake-ket - de egy kicsit túl nagyot markolt ez a szűrő. Hogy miért? Mert

.A..

mindenütt van! Miközben mi a HTTP-re összpontosítottunk, talán el is felejtettük, hogy hűséges rabszolgánk, a TCP a háttérben csatornakarbantartási munkát végez, ACK-ol veszettül mindkét irányba!

Fogjunk meg egy csatornát!

Végezetül legyen a feladat egyetlen TCP csatorna kiszűrése, hisz ez a feladat eléggémindennapos ahhoz, hogy külön megvizsgáljuk.

Ha elejétől a végéig meg szeretnénk ragadni a http.cap fájlból mondjuk a fent említett 1076-os csatornát, akkor portszámszűrést kell használnunk. A 1076 ugyanis nem más, mint az Internet Explorer által használt kliensport a webkiszolgáló elérésére. Mi sem egyszerűbb! Készítsünk filtert a TCP protokoll Source Port mezőjére, ahol a portazonosító 1076!

Akinek semmi sem maradt a szűrés után, az elvétette a hexa - decimális átváltást (7). Akinek azonban így fest az output.

Szűrés a 1076-os portra. Félsiker.

.az pontosan ugyanazt a hibát követte el, mint én. A MAC Addressekből úgy tűnik, sikerült egyirányúvá szűrnünk a forgalmat, amit bizonyít, hogy egy fia HTTP Response nem maradt a képernyőn. Mi lehet a baj?

A tűzfalaknál már szóba került, hogy hányféle forgalom születhet két portazonosító felhasználásával. A hiba oka az, hogy a HTTP Response csomagokban nem a feladó portszáma a -os (a feladó a -as portról a webkiszolgáló), hanem a címzetté. Gyorsan javítsuk ki a szűrési feltételt, és máris miénk a 1076-os csatorna teljes forgalma! A helyes szűrőfeltétel így fest:

***HTTP megy az ingyenessel?

Elkeserítésképpen

Végezetül hadd lombozzak le mindenkit: előfordult már a praxisomban olyan hálózati forgalom, amit nem lehetett szűréssel különválasztani: egy Windows 2000 tartományvezérlőn nem működött az Active Directory keresés LDAP névfeloldása (minden más gépen ment), amit igencsak nehezen lehetett volna elválasztani a többi LDAP forgalomtól. Meg is gyűlt vele a bajom! Nincs mit szűrni, ha a DC saját hálózati forgalmában, és az Active Directory keresésben is azonos a feladó és a célgép IP címe, ráadásul azonos protokollt használnak! Nem tehettem mást, lestem, hogy mikor hallgat már el a DC, hogy végre az én forgalmam kivehető legyen a csatazajból.

Fóti Marcell

marcellf@netacademia.net

MCSE, MCT, MCDBA

Network Monitor VI.

Vizsgáljuk meg kedvenc operációs rendszerünk rendszertöltés alatt kifejtett aktivitását, melyből igen sok érdekes, a Windows belső működését is megvilágító rendszerfolyamat működésére derülhet fény.

Kezdetben úgy gondoltam, hogy most már nem védem a kedves olvasót a valós hálózatok valós terhelésétől, hisz birtokunkban a szűrők összes változata, ám a webre az [1] címre elhelyezett capture fájljaim mégis mindenféle egyidejű hálózati forgalom zavaró hatásának kiszűrésével készültek, egyszerűen azért, hogy a fájl minél kisebb legyen. Hiszen ha összegyűjtöttem volna mindazt a hálózati forgalmat, ami egy vizsgált Windows 2000 több percnyi rendszertöltése alatt hálózatunkon lezajlott, több megabájtos fájlokat kellett volna az [1] címre mentenem. Annak ellenére, hogy már a forgalom elkapásakor dolgozott egy szűrő, mely csak a kiszemelt gép hálózati forgalmát engedte rögzíteni, a legnagyobb fájl így is 236 kilobájtos lett - ennyibe "kerül" egy Windows 2000 Advanced Server tagkiszolgáló bebootolása!

Három fájlunk van ebben a hónapban:

A w98boot.cap egy Windows 98 rendszertöltésének forgalmát tartalmazza

A w2kboot.cap a fent említett Windows 2 Advanced Server tagkiszolgáló bootolásának folyamatát lesi meg

A w2kshut.cap ugyanennek a gépnek a leállítását követte nyomon. Erre a cikk terjedelmi korlátai miatt nem térek ki, házi feladat!

A Windows 98 bootolása

Bár a Windows 98 már nem igazán tekinthető friss operációs rendszernek (egyesek szerint operációs rendszernek sem), napjainkban fut még néhány millió a hálózatokon, így nem haszontalan megvizsgálni, mit is művel. (A Windows ME hálózati forgalma kísértetiesen hasonló - lenne, ha ezen a gépen futott volna az Active Directory ügyfélszoftver és/vagy a gép bejelentkezett volna a tartományba. Az alábbi ábráról tulajdonképpen teljes körűen leolvasható, hogy mit tesz a masina a hálózaton: ARP-vel keres egy IP címet, NetBIOS regisztrációt végez a NETTERM98 és NETACADEMIA nevekre, valamint ICMP Router Solicitation üzenetet küld. Ebből a néhány sorból ki is derül, hogy a gép nem DHCP ügyfél, hisz IP cím kérő hálózati forgalom nem ékelődik be a legelső ARP, és a közvetlenül ez után következő NetBIOS névregisztráció közé.

A Windows 98 bootolásának forgalma - részlet

Érdekes megfigyelni, hogy a legelső ARP mintha céltalan lenne: nem várunk a válaszra (hanem azonnal usgyi Broadcastolni), és nem is jön válasz. Mi lehet ez?

Ez az úgynevezett Gratious ARP, melynek feladata az esetleges IP cím ütközések feltárása. Ebben a csomagban a Windows 98 a saját, registryből kiolvasott IP címére kérdez rá a nagyérdeműtől:

Ha bárki válaszol, akkor az adott IP cím foglalt. Mivel nem jött válasz, a gép használatba veszi a címet. Nem időznék ennél hosszabban az ARP protokollnál, hisz egy korábbi részben szinte bitszinten kielemeztük, ugorjunk a második csomagra, ahol a NETTERM98 NetBIOS név regisztrációja történik.

NetBIOS

A NetBIOS interface (és NEM protokoll!) egy viszonylag régi, elavulófélben lévő réteg a Windowsok rétegzett hálózati architektúrájában. Elsődleges feladata egy ember által is könnyen kezelhető névtér hozzárendelése az egyes gépekhez, hogy a kedves felhasználóknak például ne IP cím alapján kelljen távoli meghajtókra csatlakozniuk (bár IP címmel is lehet. Try: \\12.34.56.78\share !) Tisztán Windows 2000-es hálózatban nincs is rá szükség, de egyelőre viszonylag kevés ilyen hálózatról tudunk -sajnos. A NetBIOS halála azért elkerülhetetlen, mert - ellentétben a DNS-sel - névtere két dimenziós, azaz hierarchiába nem lehet felfűzni a gépeket.

A NetBIOS nevek 16 bájtosak, ebből 15 bájt van fenntartva a gép/tartomány/szolgáltatás nevének, a 16. bájt pedig az adott névhez tartozó szolgáltatás kódja. A fenti ábrán látható névregisztrációs utasításokon megfigyelhető a név, és a névhez tartozó szolgáltatáskód is, például

A teljesség igénye nélkül felsorolom a leggyakoribb szolgáltatáskódokat, melyekről a Microsoft Knowledge Base-ben olvashatunk bővebben:

Egy elinduló gép sorban bejegyzi a WINS Serverbe (vagy, mint a fenti ábrán, WINS hiányában Broadcasttal adja a többi gép tudtára), hogy milyen szolgáltatásokat érdemes nála keresni. (Egy WINS adatbázis elég sok mindent elárul egy botcsinálta hackernek. A fenti rekordokon kívül ugyanis van még egy-kettő: az IIS is bejegyzi magát, az SQL Server sem tagadja le, hogy fent van egy adott gépen stb.)

NetBIOS névfeloldásnak nevezzük azt a folyamatot, amikor a munkaállomás a felhasználó által megadott gépnévhez megpróbálja megkeresni a célgép IP címét, és a kért szolgáltatást. Ennek a folyamatnak sokféle változata képzelhető el, de mindig két alapeset kombinációjával állunk szemben: vagy broadcastot használunk, vagy NetBIOS Name Servert (WINS). E kettő módszer mellett létezik persze nem hálózatos névfeloldás is az LMHOST fájl képében, de ez a NetMon szempontjából közömbös, mivel nem látszik a hálón, s így el sem tudjuk kapni. Az előző kettőt azonban igen! Mi több, meglepetéssel tapasztalhatjuk, hogy e kettő vegyesen szerepel a legtöbb hálózaton. Ennek az az oka, hogy a munkaállomás az úgynevezett Node Type beállítás függvényében képes egyszerre akár mindkét módszert használni. A következő Node Type állapotok léteznek:

B Node: Broadcast üzemmód. Ekkor a munkaállomás kizárólag broadcast alapú névfeloldással próbálkozik, s ha ez nem sikerül, hibaüzenetet kapunk. Ez a típus használhatatlan több szegmensből álló, útválasztóval összekapcsolt hálózatok között, mivel minden jól nevelt router elnyeli a Broadcastokat, így ezzel a módszerrel a túlsó hálózat gépei név szerint nem érhetők el. De hangsúlyoznám, hogy IP címmel igen!

P Node: Peer üzemmód. Ebben az esetben a munkaállomás csak WINS lekérdezést használ, ami ugyan tetszőleges távolságban lévő WINS ügyfél megtalálására alkalmas - de a tőlem másfél méterre lévő gép mégsem lesz név szerint használható, ha az valamilyen okból nem WINS kliens, és nem regisztrálja be nevét a WINS kiszolgálóba

M Node: Mixed üzemmód. Az előző két módszer előnyeit egyesíti. A munkaállomás először Broadcasttal próbálkozik, majd ha az nem jött össze, a WINS-hez fordul. Tekintettel arra, hogy egy tipikus vállalati hálózatban majdnem minden gép WINS kliens, ez a stratégia sávszélességpazarló lehet

H Node: Hybrid üzemmód. Ilyenkor a munkaállomás először a WINS kiszolgálót kérdezi, majd ha negatív válasz érkezik, bánatában Broadcastol egyet - hátha sikerül. Saját tapasztalatból mondom, hogy a Hybrid igen hasznos üzemmód, mert ha egy célgép nem WINS ügyfél, a Broadcast még mindig elérhetővé teszi név szerint - legalábbis azonos alhálón.

Sajnos fantasztikus eszközünkkel, a Network Monitorral csak következtetni tudunk gépeink Node Type beállítására, a biztos módszer ugyanis a parancssorban lakozik: az IPCONFIG /ALL parancs szépen kiírja a képernyőre a Node Type beállítást. (Win98 esetén WINIPCFG)

Akármilyen úton-módon szerezte is meg gépünk a névhez tartozó IP címet, a választ egy helyen tárolja: a NetBIOS Cache-ben. Könnyedén meggyőződhetünk ennek tartalmáról az NBTSTAT -c paranccsal. Az így megjelenő listában nemcsak neveket, hanem szolgáltatáskódokat is találunk, a <0x20> például azt jelenti, hogy a feloldott nevű gépen van fájl-és nyomtatószolgáltatás, azaz fut a Server service.

Távoli gépek NetBIOS cache-e is kilistázható, egyszerű módszert adva a kétbalkezes hacker kezébe, hogy megállapíthassa: vajon egy távoli gépen ki van bejelentkezve?

Az [1] címről letölthető w98boot.cap fájl 23. csomagjában megfigyelhetünk egy NetBIOS névkérésre érkező választ, melynek kérdésrésze valahova elveszett, eltűnt a Network Monitor árgus tekintete elől, ami nem jó jel. Úgy látszik, ez is csak szoftver.

A 29. csomagban NETTERM98 NetBIOS Session építési kérelmet küld PLATAN-nak, mégpedig a feladó Workstation <00> szolgáltatása a címzett Server szolgáltatására <20>. Erre egyszerre, egy időben két válasz érkezik (30. és 31. csomag), mintha PLATAN dadogna, amit megint csak nem értek - ez is csak szoftver. Vagy a kannásbor miatt?

De térjünk vissza a második csomaghoz, nyissuk ki a NetBIOS névregisztrációt, s keressük meg benne a regisztrált gépnevet (NETTERM98). Nem fogjuk megtalálni! Helyette ez "olvasható":

A NETTERM98 név hexadecimálisan.

Ez nem egészen az ugye? Valami titkosítás, vagy átok ül rajta? Nem titkosítás, hanem átok. Úgy van lekódolva a név, hogy minden betűt két bájt tárol, de nem UNICODE, hanem BCD-jellegű, és még csak az sem. UUENCODE? Nem hinném! Az izgalom kedvéért fejtsük meg gyorsan a kódolást:

• Az (1) jellel mutatott szám a string hosszbájtja (0x20=16 bájt hosszú minden NetBIOS név)
• A következő két bájt (0x45, 0x4F) lenne az "N" betű a NETTERM98 névből (2)
• az "N" kódja az ASCII kódtáblában 78=0x4E.
• Ezt a 8 bitet vágjuk ketté, 4-4 bitre (0x4 és 0xE)
• Adjunk mindkettőhöz 0x41-et (Az ABC "A" betűje), s voilá, előáll a 0x45, 0x4F
• És így tovább a többi karakterre. Ebből látszik, hogy a név és a legutolsó szolgáltatásbájt között az üres hely szóközökkel van feltöltve (0x43, 0x41->0x20->space).

Hogy miért PONT így kódolják a neveket, tőlem akár ne is kérdezzék, fogalmam sincs! Ipartörténeti érdekesség.

ICMP Router Solicitation

A routerkeresésben talán a címzésmód érdemel kiemelt figyelmet. A címzett MAC Addresse (01005E000002) nem broadcast. Vajon kitől kéri le a Windows 98 a Default Gateway címét? Lássuk a cél IP címet: 224.0.0.2. Jesszus! Csak nem Amerikában keresi a routert? Nem-nem. Ez egy D osztályú Multicast cím, amely a Unicast és a Broadcast között helyezkedik el félúton: nem is egyetlenegy gépnek szól, de nem is mindnek, hanem csak azoknak, akik ugyanezzel a Multicast címmel rendelkeznek. A 224.0.0.2 cím a Multicast szabvány szerint: All IP Routers. Vagyis a gép bekiabál eme közismert Multicast címre, egy olyan csoportnak szólva, melynek tagja az összes, e szabványt ismerő útválasztó. Vagyis a Windows 98 MEGTANULJA, hol a Default Gateway!

A sok-sok NetBIOS regisztráció és routerfelfedezés után a Windows 98 rákapcsolódik a tartományvezérlő egyik könyvtárára. Minket a könyvtár neve és tartalma annyira nem is érdekel, az autentikáció sem fér e cikk kereteibe, így hát a fájl- és nyomtatószolgáltatás protokolljával, az SMB-vel ismerkedünk meg.

Server Message Block

A Windowsos fájlátvitel viszonylag magasszintű hálózati művelet, melynek során rendkívül sok finom részletet beszél meg egymással a munkaállomás és a kiszolgáló. A két gép között kiépülő TCP csatorna fölött NetBIOS réteg feszül, s e felett dolgozik a fájl- és nyomtatószolgáltatások alapvető protokollja, az SMB (Server Message Block). Az SMB egyelőre nincs rajta a Microsoft halállistáján (a MAPI, a NetBIOS és sok egyéb egyedi technológia mellé pedig odakívánkozna), de előbb-utóbb meghal. Inkább utóbb: a Whistler is SMB alapú. Amíg a WebDAV nem lesz képes ellátni az SMB által nyújtott összes szolgáltatást, az SMB marad.

A kapcsolatfelvétel során a részletek "megbeszélését" Negotiationnak, egyeztetésnek hívjuk. Többfajta egyezkedés zajlik a két gép között:

Milyen authentikációs protokollban állapodjanak meg? A csoportos házirend függvényében ez a Clear Texttől (hogy őslény Lan Manager 0.0 kiszolgálókkal is együtt tudjunk működni) NTLM-en át (hajrá L0PHTCrack!) a Kerberosig terjedhet. Ezekkel most nem foglalkozunk.

Melyik verziójú SMB-t beszéli a két fél? Ennek "letárgyalása" azért fontos, hogy kiderüljön, hogyan kell felépíteni az átküldött parancsot, s milyen információkat támogat a két fél a fájlok tartalmával, valamint a fájlnevekkel kapcsolatban? Csak a 8.3-as nevek mehetnek? Vagy hosszú fájlnevek is? Esetleg Unicode?

NTFS spécik: Az NTFS-en a fájlok egyedi attribútumokkal rendelkezhetnek. Át lehet-e vinni ezeket? A tömörített fájlok tömörítve kerüljenek a hálóra, vagy ki kell előbb bontani, mert a túloldal nem ismeri a tömörítési algoritmust? És az EFS-sel titkosított fájlok vajon titkosítva menjenek-e át a hálón? Nyilván igen. Vagy mégse.?

Az egyezkedés gyönyörűen látszik a NetMonnal, a 32. csomagban a kapcsolatfelvételt kezdeményező NETTERM98 felsorolja, hogy az SMB mely dialektusait, "tájszólásait" beszéli. Az alábbi ábra arról tanúskodik, hogy eszméletlen régi SMB változatok is a palettán vannak. Ez teszi lehetővé, hogy olyan ócskaságokkal is szóba álljon, mint egy Lan Manager 0.0. A lista elemei felülről lefelé egye "erősebbek", tehát a Windows 98 által "beszélt" legújabb SMB az NT LM 0.12.

A Windows 98 által ismert SMB változatok

Az alábbi ábrán a w2kboot.cap fájl 510. csomagja látható, ahol egy Windows 2000 Advanced Server kezdeményez fájlátvitelt, ennek érdekében felsorolja az általa ismert SMB változatokat:

A Windows 2000 Advanced Server által ismert SMB változatok

Mint azt láthatjuk, a legfejlettebb SMB dialektus itt is az NT LM 0.12, ugyanaz, mint a Windows 98 esetében! A 33. csomagban a dialektuslistából egyébként PLATAN a legerősebbet, az ötödiket választja (a sorszámozás nullától indul)

Emellett különböző flagbitek szolgálnak az operációs rendszer tudásszintjének pontosabb betájolására. A Windows 98 ezt tudja (gyakorlatilag semmi különöset, mindenütt nulla áll):

A nyomozás jelenlegi állása szerint nem tudnám megmondani, hogy a Windows 98 miért tagadta le a hosszú fájlneveket.

Talán nem lenne minden tanulság nélküli a Windows 98 fenti bitgyűjteményének összevetése a Windows 2000 hasonló listájával. Íme a különbségek (ahol egyes állt a Windows 2 -nél):

Case-insensitive fájlnevek (kis- és nagybetű különbözik) és Extended NTFS attribútumok kezelése. Ennyi a különbség, se több, se kevesebb. Ebből az következik, hogy:

Természetesen állításaim igazságáról bárki meggyőződhet saját hálózatán néhány spéci NTFS fájl lemásolásával. Ezzel megtaláltuk az okát annak, miért "írja elő" a marketingbrosúra IPSec alkalmazását még EFS-sel titkosított fájlok esetén is. Ugye megmondtam, hogy a NetMon mindenre jó?

Browse Service

Külön hálózati "szolgáltatás" (már ha lehet szolgáltatásnak nevezni) a Browse Service, mely még manapság is alapvető fontosságú a hálózati erőforrások megtalálásában (Network Neighborhood), annak ellenére, hogy számtalanszor bizonyította, nagy hálózatokon képtelen normálisan üzemelni. Hol kikapcsolt gépek virítanak a listájában, hol bekapcsolt gépek megjelenésére várunk - hiába. Ennek a megbízhatatlan működésnek az egyik alapvető oka, hogy amikor tallózunk, sohasem friss adatokat látunk (akárhogy csapkod is a zseblámpa, NEM azon ügyködik, hogy körbekérdezze a létező gépeket), hanem az úgynevezett Master Browser majdnem friss, illetve nagyobb hálózatok esetén a Backup Browserek garantáltan elavult erőforráslistájában kattintgathatunk önfeledten. A másik oka a Browser által használt kapcsolatmentes UDP szolgáltatás, mely olyannyira nem garantálja a lentebb felsorolt csomagok célbajuttatását, hogy még az RFC is említ olyan eseteket, amikor az UDP befuccsol. Például ha a célgép MAC Addresse nincs benn a feladó ARP cachében, akkor az UDP elkiabál a levegőbe. (Itt jegyzem meg, hogy igazi rendszergazda nem vacakol a Browse szolgáltatással, hanem egyszerűen megkerüli: ha UNC útvonalakkal [\\masina\printer], bemeppelt meghajtóval, vagy parancsikonon kattintva dolgozunk a hálón, és nem érintjük a Network Neigborhood ikont, elsiklunk a Browse mellett...) A Browse szolgáltatás hálózati forgalmának valamelyes megértése sajnos még napjainkban is szükséges. Milyen csomagokkal találkozhatunk?

Host Announcement: minden számítógép időről időre közli a Master Browserrel, hogy még mindig életben van. Emellett meglepő részletességgel közli az általa futtatott szolgáltatások listáját is. Pont, mint a WINS. A két szolgáltatás mégis különbözik, és nem is cserél adatot egymással

Browser Election: ez a vicces csomagtípus most sajnos nem sikerült elcsípnem. A lényeg az, hogy minden alhálózaton, azon belül minden protokollon, azon belül minden frame type csoportban saját Master Browsernek kell lennie. Ez tipikusan a legerősebb gép (nem hardverszempontból, hanem a futtatott operációs rendszer szerint mérjük az erősséget), de ha az ki van kapcsolva, akkor egy másik. Az erősebb gépek induláskor választást írnak ki, hogy ki legyen a Master Browser, és a választást azonnyomban meg is nyerik, hisz ők a legerősebbek. Tiszta politika :)

Browser lekérdezések: a Network Neighborhood kattogtatása váltja ki ezt a műveletet

Az alábbi táblázatban egy Announcement csomag azon részletét láthatjuk, mely a bejelentett szolgáltatásokat sorolja fel (w2kboot.cap fájl 369.csomag):

Egy Browser Announcement bitjei

Pestiesen szólva: nem semmi. Hackerként megtudhatjuk például - ha eddiga NetBIOS cache-ből nem listáztuk ki - hogy a gépen nemcsak a Workstation és a Server service fut, hanem van rajta egy SQL Server is. Külön érdekesség, hogy ez a kutyát sem érdekli. (Helyesbítek: az SQL Server Enterprise Managere ez alapján listázza ki a felvehető SQL Servereket.) Viszont az is feketén-fehéren kiderül, hogy ez a Windows 2000 nem Novell Netware, nincs rajta Time Service (de van, csak nem master), Browse szerepe pedig Backup Browser. És nem Windows for Workgroups. Hanem NT :-O

Fóti Marcell

marcellf@netacademia.net

Network Monitor VII. - NLBS

Az elmúlt alkalommal megígértem, hogy most a hitelesítések hálózati forgalmát vesszük sorra. Ígéret szép szó, nem tartom - úgy jó. Nem tartom a szavam, mert közben lezajlott egy NetAcademia tanfolyam a Windows 2000 fürttechnológiákról, s ezen készítettem néhány izgalmas pillanatfelvételt az NLBS (Network Load Balancing System) működéséről, melyek értéke vetekszik egynéhány ritka műkincs, például a Mona Lisa, vagy egy ritka bélyeg értékével. Ezt osztom meg önökkel ebben a cikkben, gazdagodjunk mindannyian!

Fürt és fürt

A Windows 2000 sokféle beépített fürtözési lehetőséggel rendelkezik. Van megoldás nagy rendelkezésre állású rendszer kiépítésére (Shared SCSI, vagy Failover Cluster) éppúgy, mint terheléselosztás használatára akár 32 gép között (NLBS). Ezekről ejtsünk pár szót, ha már volt szerencsém heteket tölteni a technológiákkal, s mind a könyökömön, mind a fülemen ez jön.

Failover Cluster

Osztott SCSI tárolón alapuló, vagy képletesebben "váltott lovakkal" fürt. Ez a fürtmegoldás - tipikus kiépítésben - két számítógép (Node) egyidejű működtetésével biztosítja, hogy a rajta futó szolgáltatások mindig elérhetőek legyenek, akár még az egyik gép teljes kiesése esetén is. Ebben a modellben központi szerep jut a két (vagy Datacenter Server esetén több) Node között elhelyezkedő osztott tároló alrendszernek, amelynek lemezeit a fürt végpontjai közösen használják. Ezek felett, úgynevezett virtuális kiszolgálókként, mindegy a kibertérben futnak az alkalmazások. Vagy méginkább: a Node a ló, a virtuális kiszolgáló a lovas, mely egy adott pillatanban egyszerre egy gép hátán ül, azt hajtja, sarkantyúzza. Ha a gazdagép rendetlenkedik, vagy leáll (a ló megdöglik), a hűtlen virtuális kiszolgáló szedi a sátorfáját, és IP címestül, mindenestül átül a másik, hibátlan Node-ra (Failover). Akárhol ül is a lovas, az adatokat mindig eléri, hisz azokat nem a lovon tárolja, hanem az istállóban: az osztott elérésű RAID alrendszeren.

Server Cluster Failover: NodeA kiesése esetén a rajta futó virtuális kiszolgálók átköltöznek a hibátlan NodeB-re

A Failover Cluster egyetlen különleges hálózati forgalma a két Node között zajló úgynevezett szívverés (Heartbeat), melynek értelmezéséhez sajnos a NetMon nem sokat tesz hozzá: nincs ilyen parser benne.

NLBS terheléselosztó fürt.

Az NLBS gyökeresen más elveken működik, mint az előbb említett Failover Cluster. Míg az előző fürtnél igen szigorú szoftver- és hardverkövetelményeknek kellett teljesülniük (osztott SCSI alrendszer, maximum 2 Node Advanced Server esetén, úgynevezett Cluster Aware (fürttűrő) alkalmazások stb.) addig az NLBS-hez semmi nem kell. A Node-ok száma is jelentősen több lehet: maximum 32. Valójában az NLBS, bár rendszerkomponens, idegen testként ékelődik be a Windows hálózati architektúrájába, és mindenkit ott csap be, ahol tud (mimikri). Még az NLBS-t futtató gazda operációs rendszer is csak "les", hogy mi történik, a rajta futó szolgáltatások ugyanis csak akkor kapnak adatot a hálózatról, ha ezt az NLBS eszközmeghajtó jónak látja. Mivel maga az oprendszer is csak "les", nem meglepő, hogy az NLBS-en fürtben futtatott alkalmazásoknak sincs halvány lila elképzelésük arról, hogy fürtben vannak. Egy IIS-nek, vagy egy Terminal Services-nek sejtelme sincs arról, hogy ők valójában - mondjuk - 32-en vannak!

A mimikri üzemmód az NLBS történelmi múltjából eredő feature, ugyanis nem Microsoft rendszerkomponensként kezdte az életét, hanem Convoy Cluster Software néven egy pici bété forgalmazta még az NT4-hez. Ez a zseniális kis cég azután felvásárlás áldozatául esett, így született előbb a WLBS (A Convoy NT4-es elnevezése) majd az NLBS (a Convoy Windows 2000-es neve).

Az egész fesztivált a 63 kilobájtos (!) WLBS.SYS csinálja, mely minden tagkiszolgálón közvetlenül a hálózati kártya meghajtója felett, de a TCP és UDP réteg alatt beékelődik a rétegzett hálózati architektúrába, és elvégzi a szükséges műveleteket ahhoz, hogy a fürt tagjai egységesen viselkedjenek a munkaállomások felé.

Az NLBS működése

Az NLBS tisztán TCP/IP trükkökkel dolgozik. A fürtbe kötött számítógépek az NLBS üzembe helyezésekor közös (!) IP címet kapnak (A régi egyedi címüket is megtarthatják persze. Már az is a WLBS.SYS okosságának tudható be, hogy nem kezdenek sírni a gépek IP cím ütközés miatt.) Tehát lesz mondjuk 32 gépünk, közös IP címmel. Ebből kitalálható, hogy a munkaállomások kérései a fürt összes tagjához befutnak. A WLBS.SYS-ek pedig szépen eldöntik, hogy a sok Node közül melyik vegye magára a kérdést, melyik válaszoljon.

Az NLBS fürtben - a közös IP cím miatt - mindegyik tag megkapja a felhasználó kérését, de csak egyikük válaszol

Ez roppant egyszerűen hangzik, de a valóságban nem az. Ugyanis nincs idő arra, hogy a WLBS.SYS-ek a kérés beérkezésekor nekiálljanak egyeztetni a többi ikertestvérrel, hogy melyikük érne rá jobban a feladat kiszolgálására. Ha az egyeztetés az igény beérkezésekor történne, odalenne a teljesítménynövekedés. A megvalósított szellemes megoldás ennél sokkal nagyobb teljesítményt biztosít:

A fürt tagjainak beállításakor, vagy a fürtszabályok módosításakor a tagok gyorsan előre leosztják egymás között a lapokat, azaz jó előre megállapodnak, hogy a világ minden sarkából érkező kérésekre melyikük fog reagálni (a lapok leosztását a fürt konvergálásának nevezik hivatalosan, s erről a tényről bejegyzés készül az Event Logba).

A kérés beérkezésekor - amely a közös IP cím miatt mindegyik taghoz eljut - mindegyik gép önállóan eldönti, hogy a leosztott lapok alapján vajon övé-e a feladat. Ha igen - a WLBS.SYS továbbengedi a kérést az oprendszernek, s ez a gép válaszol. Ha nem - a WLBS.SYS eldobja a csomagot.

Azt gondolhatnánk, hogy ezzel vége is minden load balance lehetőségnek, dinamikus terheléseloszlásnak, hisz ha az előre leosztott zsugák között nincs ott egy lap, akkor nincs ott.

Ám valójában a konvergencia során nem IP tartományokat osztanak el egymás között, hanem mindegyik tag közös szabályokhoz jut a saját DINAMIKUS döntésének meghozatalához! Vagyis a Node-ok összebeszélnek, és azután ahhoz tartják magukat. Megbeszélik a terheléselosztás szabályait (portok, címek, arányok, affinity stb.), majd ezzel felszerelkezve egyedileg, egymástól függetlenül döntenek egy-egy kérés megválaszolásáról - és sosem akadnak egymással össze! Zseniális!

A beállítható terhelési szabályokat most nem elemezném, hisz a Network Monitor miatt gyűltünk itt össze, így lassan rátérünk a lényegre. Ehhez meg kell ismerkednünk azzal, hogy vajon hogyan képesek a gépek közös IP címre reagálni. Úgyvan. Közös MAC addressel! Két módon érhető el közös MAC Address használata az NLBS alatt:

Unicast módban a kártyák elveszítik gyári eredeti MAC Addressüket (Hoppá!!), mert az NLBS mindegyik Node gépen azonos MAC Addresst vés a kártyákra. (A vésés túl erős kifejezés: reboot után visszajön a gyári MAC). Az eredeti MAC Address elveszítésével ezek a gépek többé a *<?$"@ életben nem lesznek külön-külön megcímezhetők, így jó előre tessenek felmásolni rájuk a közös weblapokat, mert később már ezen a kártyán keresztül nem lehet! Sőt, távolról egyáltalán nem fogjuk tudni megkülönböztetni a gépeket, egyszerre csak egyikük fog válaszolni - hisz erre való a fürt. Ez az üzemmód eléggé értelmetlen.

Multicast módban a kártyák megtartják eredeti MAC Addressüket, és ezzel a gépek is megtartják egyedi elérhetőségüket, menedzselhetőségüket, s a meglévő, gyári eredeti MAC Address mellé kerül fel egy Multicast MAC, melyre a fürt tagjai "harapni" fognak. Ez az üzemmód a tökéletes választás, ezen a nyomon haladunk tovább.

A Multicast MAC Address képzésének szabványos formája a következő: vedd a kártyához rendelt Multicast IP címet, és annak utolsó három bájtját tedd be a MAC Address utolsó három bájtjába, az első három bájt pedig legyen 01-00-5E. Valahogy így:

A Multicast MAC Address boszorkánykonyhája

(A Multicastról a BYTE magazin júniusi számában megjelent cikkem értekezik ennél részletesebben, ezt az ábrát is onnan loptam vissza.)

Ezek után már csak azt kell biztosítani, hogy a munkaállomások ARP kéréseire ez a Multicast MAC jöjjön vissza.

Szabványok határán

De megint bökkenőbe ütközünk, ugyanis itt nem valódi Multicastról van szó, ahol egy adó kiszolgál egy halmaz vevőt, hanem ál-Multicast, ami valójában Unicast - legalábbis a fürtöt használó munkaállomások szemszögéből. Ez a gond igazán nagy gond, ugyanis az eredeti Multicast szabványban [2] szó sincs ARP-ról; a Multicast csoporthoz csatlakozni az IGMP protokoll segítségével lehet. Ráadásul Mulitcast IP címekkel (D osztály, 224.0.0.0-239.255.255.255) sok végpont -beleértve a Windows operációs rendszereket - nem lenne hajlandó Unicast forgalmat kezdeményezni.

Emiatt az NLBS trükkhöz folyamodik: ha már ál-Multicast, legyen teljesen spéci! Ezért a fürt közös címe NE Mulitcast, hanem rendes, kutyaközönséges IP cím legyen, innentől a munkaállomások valóban ARP-vel fognak hozzá MAC Addresst keresni. A Multicast MAC Address sem a szabványban leírt 01-00-5E kezdetű lesz, hanem 03-BF, amely még mindig csoportos cím ugyan, de lokális (MAC Addressből is van lokális tartomány, úgy kell használni, mint IP-nél a belső címeket! Bizony!)

Nézzük meg e varázscímeket a Network Monitorral! E hónapban az [1] címről az NLBS.CAP fájl tölthető le, amelyben egy munkaállomás megpingel egy NLBS fürtöt. Pár oldal múlva ebből ki tudjuk majd olvasni, hogy a fürtnek hány csomópontja volt. A fájlnak vizsgáljuk most meg a harmadik csomagját (ICMP Echo), keressük meg a címzett MAC Addressét. Eddig még egyszer sem boncolgattuk magát a MAC Addresst, úgy tekintettük, mint monolitikus, felbonthatatlan számot. Most azonban kattintsunk rá kettőt, bontsuk ki! Ezt kell látni:

A legelső bájt alsó bitje mutatja, hogy ez egy csoportos MAC Address (Group Address), a második bit pedig arról árulkodik, hogy ez egy belső, lokális MAC Address.

Ha pedig decimálissá alakítjuk a számsorozatot (3-191-192-168-4-10) a NetAcademia tanfolyamok hallgatói fel fogják ismerni az egyik tanteremben használatos IP címet a MAC Address utolsó négy bájtján (192.168.4.10).

NLBS portszabályok

A következő ábrán egy pillantás erejéig megtekintjük az NLBS fő párbeszédpaneljét annak érdekében, hogy átfogó képet kapjunk az itt beállítható szabályok felépítéséről.

Az NLBS portaszabályai

Jól látható, hogy a WLBS.SYS terheléselosztási és egyéb szabályai, szűrései mind TCP, mind UDP portokra beállíthatók - másra azonban nem! A fenti ábra tanúsága szerint ha a fürt csomópontjára beérkező kérés nem TCP és nem is UDP, akkor ez nem esik az NLBS fennhatósága alá! Jól jegyezzük meg: az NLBS csak és kizárólag a TCP és UDP protokollok forgalmát fürtösíti. Vajon mit tesz a WLBS.SYS a szabályok alól "kilógó" csomagokkal (például ARP-vel, ICMP-vel, IGMP-vel, GRE-vel stb.)? Nem dobhatja el, hisz ezek nélkül nincs élet. Tehát átengedi, felküldi az operációs rendszernek, amely válaszol rá.

Lássuk az NLBS.CAP fájlban az ARP protokollt! Szűrjük meg az NLBS.CAP fájlt, hogy csak ARP protokoll maradjon a szemünk előtt. Hány csomagra számítunk, ha elárulom, hogy a felvétel zajmentes, tiszta környezetben készült? Én kettőre számítanék: egy ARP kérésre és egy válaszra. Ám nekünk három csomagunk maradt.

ARP az NLBS fürtben

A vak is láthatja: egy ARP kérdésre két válasz érkezett! Ahogy a fenti okfejtésből talán következtethettünk rá: a fürt összes csomópontja (mind a kettő :) válaszolt az ARP kérésre, mégpedig az alábbi ábra szerint nem a fent levezetett közös MAC Addressel, hanem a hálókártyák saját, beépített fizikai címével (0002A5095EB8 és 0002A509618B)!

Egy ARP kérdésre két válasz? És két különböző címről?

Ajaj! Mi lesz itt?

Vajon mi kerül szerencsétlen munkaállomás ARP cachébe? Az a MAC Address, amelyik előbb válaszolt (mert az győz)? Vagy amelyik később (mert felülüti a korábbi választ)? De az tisztán látszik, hogy a beígért Multicast MAC Addressnek nyoma sincs. Hacsak.

Hacsak ki nem bontjuk ezt az átkozott ARP Reply-t!

Ha összevetjük az (1) helyen olvasható MAC Addresst, (amely a feladó címe) a (2) ponton látható címmel (mely az ARP válasz tartalma szerinti feladócím) azt tapasztaljuk, hogy ez az ARP csomag kissé "hibás": látszólag nem attól a géptől jön, mint aki magáénak érezte a kérdéses IP címet! (És ez a csoda azután mégegyszer befut szerencsétlen munkaállomáshoz a fürt másik csomópontjáról is: győzze feldolgozni!) Amíg ugyanis Ethernet szinten a hálókártya eredeti MAC Addresse szerepel, addig a beágyazott ARP-ben már az a Multicast katyvasz van, amit egy oldallal korábban elemeztünk! A fürt tagjai Ethernetszinten letagadják a Mulitcast jelenlétét, míg a beágyazott ARP-ban már ott virít a Multicast MAC!

Miért, oh miért?

S ha a kezdeti kapcsolatfelvételkor használt ARP ilyen "letagadós", akkor vajon a többi hálózati forgalom milyen lehet?

Fürtök és switchek

A válasz nem a Microsoft háza táján keresendő. Bizonyos hálózati elemek MAC-kezelési furfangjai miatt van szükség a Multicast MAC elrejtésére a válaszcsomagokban. Hogyan is működik egy switch? Virtuális pont-pont kapcsolatot alakít ki a kommunikáló felek között arra az időre, amíg a csomag átkerül a címzettől a feladóhoz. A switch a kommunikáló felek közt "félúton" állva nulla milliszekundum alatt képes eldönteni, hogy melyik két portját kell összekötnie egy adott csomag elszállításához. Erre a rendkívül gyors cselekvésre azért képes, mert minden portjához megtanulja az azon lógó gép MAC Addressét - egyszerűen kiolvassa és megjegyzi a rajta áthaladó forgalomból. Sajnos a switcheket nem készítették fel NLBS-re, nem igazán van olyan szabály bennük, hogy egyszerre X portot kössenek össze. Még meg is bolondulhat némelyikük, ha több portján egyidőben ugyanaz a MAC Address bukkan fel. Az a biztos, ha nem hagyjuk, hogy "megtanulja" a Multicast MAC-et, hanem eldugjuk előle. Bújócska. Ennek záloga, hogy válaszcsomag Ethernet fejlécében sohase jelenjen meg a Multicast MAC, hogy switch pajtás ne tudja onnan kiolvasni és memorizálni. Emiatt válaszolnak a közös MAC Addressű fürtvégpontok a saját MAC-kel!

A feladó fürttagok sosem a Multicast címmel válaszolnak

Ha valaki hubot használ, vagy turbóokos switch áll rendelkezésére, a bújócskát ki is kapcsolhatja a

érték nullázásával. Én nem tenném.

PING a fürtre!

A munkaállomás a fenti ARP Reply csomagokból kihalászott Multicast MAC címet használatba véve ICMP Echo-ba kezd. Lássuk a fürt pingelését! A fenti MaskSourceMAC bekapcsolt állapotában zajló ICMP forgalom könnyebb értelmezése érdekében a MAC Addresseket elnevezésekkel láttam el.

Egy ICMP Echora két válasz?

Az ábra lényege így foglalható össze:

A pingelő parancssorban egyébként csak egyetlen válasz látszik, kizárólag a NetMon számára tárul fel a valóság.

Furcsa példáim láttán esetleg egyesekben az a kép ragad meg, hogy az NLBS fürt használhatatlan, mert mindig minden csomópont válaszol a munkaállomások kérdéseire, s ezzel eldugítja a hálózatot. Ne tévedjünk, eddigi példáim nem az NLBS üzemszerű működésére vonatkoznak! A TCP és UDP fölött futó alkalmazások (például IIS, Terminal Services stb.) természetesen nem ezt a multiválaszolós hálózati forgalmat mutatják, hisz azokra hatnak a portszabályok, és a WLBS.SYS csak egyetlen fürttag válaszolását teszi lehetővé.

Az NLBS korlátai

Most, hogy "mindent" tudunk az NLBS viselt dolgairól összefoglalnám a működtetés főbb kereteit:

Nem használható ez a fürttípus olyan környezetben, ahol valamelyik hálózati elem (például útválasztó) nem viseli el az ál-Multicastot (rendes IP cím+ Multicast MAC)

Nem lesz elérhető az NLBS fürt akkor sem, ha valamelyik hálózati elem nem tolerálja azt a működésmódot, hogy nem arról a MAC Addressről érkezik a válasz, ahová a kérdés irányult (ilyenkor kipróbálhatjuk a MaskSourceMAC kikapcsolását)

Legkönnyebben read only alkalmazások (IIS, Terminal Services, Proxy) futtatására használható, mivel ilyenkor nem kell gondoskodni a fürt csomópontjain szétszórtan felbukkanó adatok összesítéséről

AppCenter Server

A fürt beüzemeléséről egy szót sem ejtettem, s nem véletlenül. Nem egyszerű ugyanis puszta kézzel kialakítani 32 azonos paraméterezésű csomóponti gépet. Nem beszélve a változások követéséről! Megállapítottuk, hogy az alkalmazások (például IIS) nem tudják, hogy fürtön futnak. Emiatt nem is képesek a megváltozott adatokat (például ASP lapokat, ActiveX vezérlőket stb.) szinkronizálni. A hamarosan megjelenő AppCenter Server a fürtök körül felmerülő napi feladatok ellátásában nyújt hathatós segítséget. Két kattintással elvégezhetővé válik új fürtcsomópontok teljeskörű, alkalmazásszinkronizációs telepítése. Ezzel a termékkel külön cikkben fogunk foglalkozni.

Fóti Marcell

marcellf@netacademia.net

MCSE, MCT, MCDBA

NetMon VIII. - Szakértők, és Monitor Control Tool

Eddigi NetMon témaköreink esetében a Network Monitor offline elemzőképességét használták ki, azaz elkaptunk egy bizonyos hálózati forgalmat, s utólag, a kandalló melegénél elemezgettük. Nem vettünk igénybe semmilyen segédeszközt az elemzés elvégzéséhez a saját józan paraszti eszünkön kívül, pedig a NetMon kétféle lehetőséget is tartalmaz!

Az egyik elemzési eszköz az Experts névre hallgató jószág, melyet az elkapott hálózati forgalomra eresztve csodálatos statisztikákat kaphatunk. Sok esetben azonban az utólagos okoskodás késő bánat, mert a baj már megtörtént (például Distributed DOS támadás áldozatául esett kiszolgálónk, vagy a hálózat munkaállomásai egytől egyig elveszítették kapcsolatukat a külvilággal).

A másik elemzési eszköz a Monitor Control Tool, mely segítséget nyújt ismert hálózati problémák azonnali, real-time érzékelésében is. Futtatásával folyamatos hálózatmonitorozásra nyílik lehetőség; kihasználja a promiszkusz üzemmódban rejlő elemzési lehetőségeket, közismert hálózati problémák elég jelentős halmazát érzékeli, és jelenti számunkra. További érdekes lehetőség, hogy akár távoli hálózatok figyelése is megvalósítható, ha minden alhálózaton beizzítunk egy-egy Monitor Control Toolt, s ezeket központi helyszínről felügyeljük.

A cikk hátralévő részében szándékosan felváltva írok mindkét lehetőségről, ezzel is hangsúlyozva, hogy KETTŐ van belőlük, melyek felhasználói felülete eléggé hasonló - de ezzel a hasonlóságok listájának végére is értünk. A kavarodás csökkentése érdekében mindkét eszköz mellé odateszem a megfelelő ikont, így első pillantásra látszani fog, éppen meyikről van szó.

 

Baloldalon az Expertek, jobboldalon a Monitor Control Tool felhasználói felülete

Végül egy mondat erejéig megemlítem az általam ki NEM próbált, de olvasott lehetőséget: a NetMon WMI Provider segítségével programozási eszközökkel hozzáférhetünk a Monitor Control Tool riasztásaihoz, s tetszőleges módon reagálhatunk rájuk: SQL Serverbe naplózhatjuk, emailt írhatunk stb.

Hol találjuk az elemzési eszközöket?

A NetMon Experts fellelési helye

NetMon Tools->Experts.

A szakértők offline elemzésre használhatók

Vigyázzunk a NetMon ravasz menürendszerével, ez a menüpont csak akkor jelenik meg, ha egy elkapott hálózati forgalom részletező ablakában állunk!

A felhasználás módja inkább memória-, mint processzor vagy hálózatintenzív, hisz egy elmentett trace fájlon végzünk statisztikázást. Tipikus esetben néhány másodperc alatt lefut, így - ellentétben a másik eszközzel - különösebb tervezést nem igényel a használata.

 A Monitor Control Tool elérése

Külön programként található a Start menüben. Nem (csak) ebből következik, hogy ezt az eszközt nem érdemes egyidőben futtatni a NetMonnal: real-time elemzésével jelentősen leterheli azt a gépet, amelyiken futtatjuk.

A Monitor Control Tool nem azonos a NetMonnal!

Hálózat-, és processzorintenzív működése miatt általában dedikált gépen futtatjuk - ott viszont éjjel-nappal, mert a hálózati problémák (különösen a hackertámadások) nem csak nappal léphetnek fel.

Mit tudnak a szakértők (experts)?

Utólagos okoskodásra, jobbára statisztikakészítésre szolgálnak. Az alábbi táblázat röviden összefoglalja az expertek szerepét:

 Mit tud a Monitor Control Tool?

A real-time elemzés azon a felismerésen alapul, hogy a tipikus hálózati problémák tipikus hálózati forgalmat generálnak - magyarán a forgalom "mintázatának" (pattern) figyelésével lehetőség nyílik sok-sok esemény felismerésére. Az alábbi lista a beépített mintafelismerőket tartalmazza, melyeket a cikk hátralévő részében részletes elemzésnek vetünk alá, hisz első ránézésre - talán - nem egyértelmű, hogy milyen baj származhat ICMP Redirect üzenetek váratlan megjelenéséből. Tehát a lista:

Most pedig térjünk rá az egyes Expertek és Monitorok gyakorlati hasznára. Ha a főnök görcsöl a számítógépével, mert dög lassú, és rád fogja, hogy azért nem boldogul, mert lassú a hálózat, akkor a válasz.

 Average Server Response Time Expert

Ezzel az egyszerű eszközzel az elkapott hálózati forgalom alapján meg tudjuk állapítani az egyes kiszolgálók általunk kiválasztott portjain a válaszidőket. Gyárilag a következő portok szerepelnek a statisztikában: 20, 21, 25, 69, 79, 80, 119. Azaz FTP, SMTP, TFTP, Finger, HTTP és NNTP. Ez természetesen szabadon változtatható.

Mely portok válaszidejét mérjük?

Ha például egy webkiszolgáló válaszidejére vagyunk kíváncsiak, egyedül a 80-ast hagyjuk meg. Ha pedig az előbbi listában fel nem sorolt SQL Server reakcióidejére, vegyük fel a 1433-as portot. Futtassuk le ezt a szakértőt, mondjuk az áprilisi számhoz mellékelt http.cap fájlon, mely a szokásos helyről, az [1] címről tölthető le. Ebben a www.netacademia.net webkiszolgáló böngészésének hálózati forgalma szerepel, 5 hop távolságból. Az eredménynek 0,389009 másodpercnek kell lennie a fájlban lévő 78 HTTP kérés-válasz alapján. Bizonyító erejű információ került a kezünkbe ezáltal, hogy nem a hálózat a lassú, hanem a főnök XT-je :-)

Most legyen az a feladat, hogy megállapítsuk: egy adott gépnek mely portjain kopogtatnak a felhasználók? Nincs-e támadás-előkészítés? Port scanning?

 Property Distribution Expert

Ez a szakértő az elkapott hálózati forgalomból tetszőleges protokoll tetszőleges mezőjére képes statisztikát készíteni, jelen esetben a májusi w2kboot.cap fájl lesz kísérleti alanyunk az [1] címről. Állítsuk be az expertet, hogy a TCP protokoll Destination Portja alapján statisztikázzon nekünk egyet!

A TCP protokoll Destination Portjait számláljuk

Az eredmények megnyugtatóak. Összesen négy kiszolgálóport dolgozott (135, 139, 389, 445), hackernek nyoma sincs. Ezek összesen a kapcsolatok 7+3+10+7=27%-át adják.

A TCP protokoll Destination Portjait számláljuk

A 135-ös és 139-es porton futó szolgáltatásoknak a nevét is visszakaptuk. A 389-es port az LDAP szolgáltatásé, a 445-ös pedig a NetBIOS nélküli (letiltott NetBIOS-sal zajló) fájl-és nyomtatási szolgáltatás kapuja. Az összes többi (kliens)port használata elenyésző.

Következő feladatunk különleges: egy fájlt kell darabjaiból összeállítanunk. Az Ethernet szabvány korlátai miatt a maximális keretméret nem haladhatja meg az 1514 bájtot. Minden adat, mely ennél nagyobb (lenne), feldarabolva kerül a hálózatra, s a fogadógép feladata a darabok összeillesztése. Akkor mi miért vacakoljunk vele? Mert nem MI vagyunk a fogadóállomás! Nálunk a NetMonban "csak úgy" a maga nyers, töredezett formájában megjelent, s ebből kellene visszaállítani az eredeti adatot.

 Protocol Coalesce Tool

Végül is a probléma nem megoldhatatlan, hisz az edereti fájl darabkái egyazon TCP csatornán haladnak kijelölt céljuk felé. Amit a célállomás meg tud tenni, azt mi is! Összegyűjtjük egy adott TCP csatorna összes csomagját, és abból kihalásszuk az adatot. Ismét dolgozzunk a http.cap fájlon! Eredetileg 181 frame van benne. Ha erre ráuszítjuk a Protocol Coalesce Toolt, akkor összesen tíz marad, de azok jó nagyok ám! Az összevont adatok külön fájlba kerülnek, valami hasonló néven: http(Coalesced)01.cap. Nézzünk bele! Az ötödik csomag, mely egy HTTP Response, összesen 58524 bájtos lett; egy komplett GIF fájlt találunk benne! A teljesség kedvéért megmutatom, hogy ez az eszköz is finomhangolható:

A Protocol Coalesce Tool tuningolása

Használtam már a Protocol Coalesce-t XLS, illetve TXT fájlok összeszedésére, bár az előbbi némi utófeldolgozást igényelt, mielőtt az Excel hajlandó lett volna megnyitni.

Újabb kihívás: a főnök robbantott tortadiagramban szeretné látni a hálózatunkban használt egyes protokollok arányait.

 Protocol Distribution Tool

A feladat nem igazán életszerű, mert a főnökök jobbára nem tudják, mi az, hogy protokoll, de jobb nem jutott eszembe. Ki mást érdekelne a protokollok egymáshoz viszonyított aránya?

Ismét a wk2boot.cap fájlt kínozzuk, s a szakértő futása után az eredményeket egy hirtelen mozdulattal a vágólapra helyezzük, onnan pedig Excelbe. Mostantól a Kedves Olvasó fantáziájára bízom, hogy vajon hogyan állt elő e csodálatos eredmény (eredetileg színes volt!):

Hálózatunk protokolljainak megoszlása

E megalázó feladat után következzen egy szakmai kihívás: megfigyelhető-e a hálózatban olyan hiba, mely miatt egyes TCP csomagokat újra kell küldenie a feladónak?

 TCP Retransmit

Az ismételten elküldött TCP csomagok sok mindenről, többek közt bizonytalan hardverekről, illetve túlterhelés miatti csomagelvesztésről árulkodhatnak, mégis, sokszor rejtve maradnak, mert hiába gúvadunk a Network Monitor felett, az ember összpontosítási képessége véges: ezernyi csomag között garantáltan nem találjuk meg a tökéletesen azonosakat. Márpedig az újraküldés pontosan erről ismerhető fel: egy csomagot bitről bitre, pontosan megismétel a feladó. A feladat gépesítésért kiált!

Mi okozhat TCP újraküldést? TCP csomagvesztés! Ha akár egy adatcsomag, akár egy ACK nem érkezik meg a Retransmit időintervallumon belül, akkor újraküldésre kerül. Mitől veszhet el csomag? Természetesen ennek ezernyi oka lehet, beleértve a múló rosszullétet is, hisz egyetlen bit hibája miatt a csomag sorsa megpecsételődik: ha elromlik az ellenőrzőösszeg, az útválasztók elhajítják. Ennél kevésbé misztikus a torlódás esete. Ha van egy 128k-s bérelt vonalunk, s azt a belső 100 Mbites hálózatról rendesen meghajtjuk, bizony eldugul. Az útválasztók ilyenkor duguláselhárításképpen eldobálják azt a felesleget, amit semmiképpen sem tudnak kituszkolni a lassú vonalon. Továbbá ilyenkor visszaszólnak az eredeti feladónak, hogy lassítson (ICMP Source Quench), más kérdés, hogy ezt figyelembe veszik-e a gépek, vagy sem (általában igen).

Szerény véleményem szerint ez az expert éri a legtöbbet a készletből, mert közvetlenül felhasználható hálózati hibák keresésére. Rendszeres futtatásával elejét vehetjük valami nagyobb katasztrófa, tökéletes dugulás kialakulásának.

Utolsó expertünk éppen kapóra jön a főnök legújabb agymenésének kiszolgálásában: állapítsuk meg, mely felhasználók viszik el a sávszélességet.

Top Users Expert

Ennek a szakértőnek összesen annyit kell mondanunk, hogy az IP címet, vagy a MAC Addresst használja fel a forgalom szortírozásához, illetve, hogy mekkora toplistát készítsen (az alapértelmezés tíz "fő"). Ezt lefuttatva valami ilyen eredmény kapunk:

Toplista (vagy feketelista?)

A 172.16.0.17-es gépnél ülő kolléga jöhet a munkakönyvéért! :-)

És most térjün át a Monitor Control Toollal végezhető realtime elemzésekre.

 ICMP Redirect Monitor

Az ICMP Redirect üzenetek alkalmasak arra, hogy munkaállomásokon és más gépeken automatikusan módosuljanak az útvonaltábla-bejegyzések, ha egy új útválasztó bukkan fel a hálózaton, illetve ha egy munkaállomás nem a megfelelő útvonalat választva próbál forgalmazni. Az alábbi ábra egy tipikus paradox helyzetet mutat, ahol egy munkaállomás egyszerre két irányba is szeretne forgalmazni, amihez két Default Gatewayt kellene beállítani.

Gyakori, ám megoldhatatlan(nak tűnő) útválasztási feladat

Igen ám, de hiába gépelünk be két DG címet (R1 és R2), a Windows csak a legelsőt hajlandó használni mindaddig, amíg az él (úgynevezett dead gateway detection algoritmust használ), és csak akkor áll rá a másodikra, ha az első kimúlt. Ennek következtében két rossz megoldás közül választhatunk. Az első rossz megoldásban az R1, a második rossz megoldásban az R2 a legelső Default Gateway. Hogy ez miért rossz? Mert bárhová is kellene küldeni egy IP csomagot (az emeletre vagy az Internetre), munkaállomásunk mindig a DG-nek küldi, rábízva a továbbítást a routerre. Könnyen belátható, hogy ha egy csomag az emeletre való, de gépünk R1-nek küldi, akkor mandínerből jut el végleges rendeltetési helyére: egyszer megpattan R1-en, mely R2-n és R3-on keresztül ügyesen feldobja az emeletre. Eközben élénk sávszélességpazarlás zajlik, ugyanis a csomag kétszer megy át a földszinti alhálón! Mit lehetne ez ellen tenni? Valamilyen módon mégiscsak fel kellene okosítani a munkaállomásokat, hogy kapásból jó irányba induljon el az IP csomag!

Kézzel úgy okosíthatnánk fel, hogy felvennénk a munkaállomás Route táblájába egy bejegyzést arról, hogy merre van az emelet. Ezt kissé macerás megtenni, ha a gépek száma nagy.

DHCP Server esetén számításba jöhetne a 033-as számot viselő Static Route opció, melynek pontosan az a feladata, hogy a sok-sok IP paraméter átadása mellett lehetőség legyen a kliensek Ruote táblájának automatikus módosítására is. Milyen kár, hogy nem működik! (Not implemented yet.)

R1 pontosan tudja, hogy pazarló módon kerül fel a csomag az emeletre, hisz ő maga pumpálja vissza ugyanabba a subnetbe. R1 minden ilyen esetben ICMP Redirect üzenetet küld az eredeti feladónak, hogy nem jó gatewayt használ. Az okos munkaállomások pedig hálásan köszönik, és ez alapján módosítják Route táblájukat. A következő alkalommal már jó helyre, R2-nek megy az emeletre szánt csomag. A buták nem veszik figyelembe az ICMP Redirectet, s továbbra is "mandínerből" kommunikálnak az emeleti gépekkel. Az NT4 SP2 óta okos, előtte buta volt.

Az ICMP Redirect Monitor beállítása igen egyszerű: fel kell sorolnunk a valódi routereket, minden más címről érkező ilyen üzenet hamis!

Ez a monitor tehát egyfelől arra szolgál, hogy kiderüljön: valamely gépek sávszélességtékozló módon kommunikálnak a hálón, másfelől azért kell állandóan futnia, mert hibás/hamis routerek üzenetei tökéletesen rombadönthetik egy adott hálózat kommunikációját. Még az is előfordulhat, hogy két alhálózat összes keresztforgalmát magárairányítja valaki, például Claudia Sniffer (Így hívjuk egymás közt azt az információbúvárt, aki snifferrel dolgozik) lerakja laptopját a sarokba, és vár. Kis idő elteltével az összes inter-subnet forgalom átfolyik a laptopon, és kiválóan lehet NetMonozni, össze lehet szedni a jelszavakat.

Bizony, bizony! A switch nem akadály! (Elnézést, de ezúttal URL-t nem adnék a jutilitihoz, pedig nélkülözhetetlen NetMon segédeszköz. :-)

Most pedig engedtessék meg nekem, hogy a fent vázolt hackermegoldás alapján levezessem a lokális hálózatok teljeskörű lehallgatásának stratégiáját.

Azért osztom meg e bűnös gondolatokat Kedves Olvasóinkkal, mert nekem már akadt dolgom ilyen méretű összeesküvéssel. Ahol milliárdok utaznak a belső hálón, ott előbb-utóbb megjelennek a tolvajok! Azt mondhatják egyesek, hogy felesleges a Monitor Control Toollal hackerek nyomába eredni, mert a támadásokat a tűzfalak úgyis megfogják. A külső támadásokat valóban. De az NSA (National Security Agency) felmérése szerint az ártó szándékú számítógépes bűnelkövetések elsöprő többsége nem külső, hanem belső támadás!

A fentebb emlegetett "segédeszköz" óriási hátránya, hogy egy subneten belül nem jár túl a switch eszén. Miért akadályoz minket egy switch a NetMonozásban? Azért, mert hiába kapcsol a hálókártyánk promiszkusz üzemmódba (mely lehetővé tenné idegen csomagok elkapását is, lásd NetMon sorozat 1. rész), a várva várt csomagok nem jutnak el hallgatózó gépünkig. Ennek oka az, hogy a switch az eredetileg üzenetszórásos Ethernet csatornát pont-pont kapcsolatokkal váltja ki. Üzenetszórásos esetben (például vékony koaxra felfűzve, vagy UTP-t Hubbal használva) az összes hálózati forgalom eljut mindenhova, maximum a gépek nem veszik figyelembe, ami nem nekik szól. Ennek a megoldásnak tagadhatatlan előnye az olcsóság, ám minél több gép van a csatornában, annál kevesebb hasznos adat vihető át az ütközések (collision) miatt. Ezen segít a switch. Ha két masina egymással kommunikál, akkor a switch egy szempillantás alatt közvetlenül összeköti őket - majd bont. Ennek a megoldásnak óriási előnye, hogy - például - egy tíz megabites hálózat nem fog az üzenetszórás miatt telítődni (collision), hanem hébe-hóba akár sokszor tíz megabites (virtuális) teljesítményt is produkálhat. Igen ám, de ha nincs üzenetszórás, nem sokra megyünk a jó drága, SMS-béli full-featured Network Monitorral! Ugyanolyan keveset lát, mint ingyenes párja, hisz nem jut el hozzá minden.

Claudia Sniffer azonban nem esik kétségbe. Elgondolkodik: vajon le lehetne-e butítani egy switchet, hogy hubként működjön? Nos, igen. Gondoljunk csak a broadcastokra. Azokat a switch is teríti, nem is tehet mást. Hub módra viselkedik akkor is, ha nem ismeri fel a címzett MAC Addressét. Ez tipikusan a legelső néhány csomagot jelenti egy switchport életében. Ha tehát valahogy meg tudjuk akadályozni a switchet a MAC Addressek betanulásában, akkor szórni (szakszerűbben: floodolni) fog. Az elgondolás nem teljesen hülyeség, az NLBS például előszeretettel rejtegeti Multicast MAC Addressét a switchek árgus tekintete elől, de ez a megoldás Clauidának nem fog bejönni: nincs lehetősége az összes oprendszer kódjának módosítására. A switch tehát elvileg lebutítható, de a gyakorlatban ez kivitelezhetetlen.

Vagy mi lenne, ha az előző, ICMP Redirecthez hasonló trükkel egy adott gépen folyatnánk át az összes forgalmat? Ez már menni fog. Csak azt kell biztosítanunk, hogy az ÖSSZES gép külön subneten érezze magát, ugyanis ebben az esetben egy ROUTEREN keresztül kommunikálnának egymással.

Ki kell használnunk, hogy a tipikus vállalati hálózati számítógépek dinamikus IP cím felvételre (DHCP) vannak állítva. Ha sikerülne egy olyan DHCP Servert üzembe állítani, mely minden kérelmezőnek más-más IP subnetről ad címet, s ráadásul a Default Gatewayt is ránk állítja, nos akkor már majdnem célbaértünk. Az összes gép a mi "routerünkön" keresztül forgalmaz, így a switch tehet egy szívességet :-) Elárulom: van ilyen DHCP Sever a "piacon".

Hogy lehet védekezni ennyi gonoszság ellen? Hát Monitor Control Toollal!

 IPRange Monitor

A hálózaton kiosztott IP címektől eltérő címek felbukkanása ellen használható oly módon, hogy megadjuk az érvényes, illetve ha van tiltólistánk, az érvénytelen címeket, így a külön subnetre eső címek kiosztását azonnal lefülelhetjük.

Az IP Range Monitor: érvényes és érvénytelen feladó és célcímek beállítása

 Rouge DHCP and WINS

Hamis DHCP és/vagy WINS észlelésére! Eredetileg olyan problémák észlelésére találták ki, amiket a rendszergazda maga okoz, amikor vizsgára felkészülés közben DHCP és WINS Servereket telepít fel-le. Ha megjelenik egy idegen címeket osztó DHCP Server a hálózatban, akkor a munkaállomások sem az eredetitől, sem a próbakiszolgálótól nem fog címet elfogadni, mert egymásnak ellentmondó két IP cím ajánlatból nem tud választani. Emellett sikeresen felhasználható e monitor a bütykölt DHCP Server ellen is. Fel kell venni a megbízható DHCP és WINS Serverek címeit, s a többit elintézi a Monitor Control Tool.

 Security Monitor

Emlékszünk még a Bone protokollra? Ezzel jelzi minden NetMon, hogy éppen futtatják. A Security Monitor Control Toollal megakadályozható, hogy idegen gépről futhasson a NetMon. Ezt megint Claudia Sniffer ellen vethetjük be, de ne feledjük: nem csak Microsoft Network Monitor létezik a világon! A többi snifferprogramra ez a monitor - érthető okokból - hatástalan! NetMon ellen azonban kiváló. Nemcsak hogy észleli az idegen kukkolókat, de beléjük is fojtja a szót (leállítja a NetMont), és ha akarjuk barátságtalan üzenetet küld Claudiának.

Remélem a figyelmes olvasónak feltűnt, hogy a Security, a Rouge DHCP és az IP Range monitorok csak üzenetszórásos csatornán észlelik, amivel megbíztuk őket; switches környezetben NEM! Akkor talán mi magunk kényszerülünk a switch becsapására? Szerencsére nem. Okosabb switcheken van egy úgynevezett monitoring port, ahová minden beérkezett csomagot kilehet küldetni: ide kell feldugni a Monitor Control Toolt futtató gépet. A portok működése továbbra is kapcsolt marad, ám az általunk kiválasztott portok forgalma megjelenik a monitoring porton, a NetMonozók őszinte örömére.

 SYN Attack Monitor

A legbonyolultabb, de talán legkevésbé használható eszköz a SYN támadás felismerésére való monitor. Nem az a baj, hogy a SYN Attack Monitor használhatatlan lenne, hanem az, hogy ez a támadásfajta már nem létezik, senki sem használja, hisz ennél lényegesen körmönfontabb denial of service támadások léteznek manapság. Röviden a következőről van szó: amikor egy TCP csatorna felépül, akkor mindkét kommunikáló fél lefoglal 8-8k puffert a memóriában a csatorna gyors kiszolgálása érdekében. A korai TCP implementációk már a kapcsolatfelvétel legelső csomagjának megérkezésekor lefoglalták a puffert, amit ügyes hackerfiúk úgy fordítottak a TCP ellen, hogy kismillió csatornaépítést kezdeményeztek távoli gépeken - ám a háromutas kézfogás (chip-chip-choka, lásd NetMon sorozat 2. rész) sohasem jött létre, mert például hamis IP címről eregették a SYN jeleket. A kis buta webkiszolgáló meg addig foglalgatta a 8k-s puffereket, amíg a teljes fizikai memóriát el nem emésztette, s meghalt.

Tekintettel arra, hogy ma már egy hűtőgépben is óvatosabban kódolják a TCP stacket, ez a támadástípus kihaltnak tekinthető.

 Mit nem tud a Monitor Control Tool?

Sajnos a beépített monitorkészlete - érthető okokból - nem naprakész. Nem találunk a gyári készletben például olyan elemzőket, melyekkel tipikus hackertámadások felismerésére nyílna lehetőség: ezek ugyanis általában igen jól felismerhető mintázatot követnek. Az SDK publikus. Ki írja meg nekem azt a Monitor Control Toolt, amely lefüleli az IIS elleni CMD támadásokat?

Fóti Marcell

marcellf@netacademia.net

MCSE, MCT, MCDBA, MZ/X

Netmon IX: Jegyzetek a tűzvonalból

Egy probléma megkeresése és megoldása nem túl hálás feladat. Arról szól, hogy valami nem úgy működik, mint a nagykönyvben, mi megkeressük a hibát, azután meg minden úgy pöfög, ahogy kell. Elpocsékolunk egy csomó időt arra, hogy úgy működjenek az eszközeink, ahogyan maguktól is kellene. Néha csak egy-két órát kell rááldozni a feladatra, néha egy hetet, de igazából sohasem tudjuk az elején, hogy mennyi lesz a feláldozandó, "kárba vesző" idő. Azért lássuk be: nagyon sok "misztikus" eseménnyel találkozunk "kiszámítható" számítógépes világunkban, és ez felettébb bosszantó. Főleg akkor lehet dühös az ember, ha úgy érzi, nincs a kezében eszköz, amellyel a probléma felgöngyölíthető lenne. Logikai problémakizárással, próba-szerencse elven, vagy "kezdjünk mindent tiszta lappal" módszerrel dolgozunk ilyenkor, és csak reméljük, hogy sikerül. Már azt sem bánjuk, ha nem tudjuk meg a hiba pontos okát, csak legalább működjön már az a fránya rendszer.

Az alábbi eset megtörtént, és - okulására mindenkinek - szeretném megosztani, hogy akik nap mint nap a "tűzvonalban" tevékenykednek, azokat bátorítsam a problémák újfajta megközelítésére.

A környezet és a probléma

Pár héttel ezelőtt üzembe helyeztünk egy Windows 2000 szervert, rajta egy terminál szerviz szolgáltatást. Az eszközt hasznossága és népszerűsége miatt hamar túlterhelték a felhasználók - nosza, itt az alkalom egy hálózati terhelésmegosztás (Network Load Balancing Service) életre keltésével egy másik szervert is beállítani. Némi elméleti kérdés tisztázása (unicast és multicast üzemmód, MaskSourceMAC és switch elárasztás probléma stb.), olvasgatás és próbálkozás után felállt az NLBS cluster a következő konfigurációban: két Windows 2000 Advanced Server NLBS-sel telepítve és egy hubra kötve. A szerverek multicast üzemmódban működtek. (Csak dióhéjban: Az NLBS kétféle üzemmódban képes működni: unicast illetve multicast módban. Az unicast és multicast itt "level 2" szinten értendő, és nem IP szinten. Unicast esetén a szerverek elrejtik a saját MAC címüket, és egyetlen, közös MAC címmel jelennek meg. Ennek a megoldásnak előnye a kompatibilitás, hiszen egy unicast csomag a mindenki által ismert normál csomag. Hátrány viszont, hogy a szerverek az azonos MAC cím miatt nem tudnak egymással kommunikálni, ezért gyakran egy második hálózati csatolót is tesznek a szerverekbe, amellyel a node-ok közti forgalom lebonyolítható. További hátránya az unicast üzemmódnak, hogy a switcheket zavarja, ha két portján is ugyanaz a MAC cím jelenik meg. Ezt ugyan el lehet rejteni egy registry beállítással (MaskSourceMAC=1), ekkor viszont a switch egyáltalán nem tudja megtanulni a MAC címet és minden switchportot eláraszt forgalommal. A multicast üzemmód esetén az eredeti MAC cím megmarad, és "megállapodás születik" egy közös MAC címről is. Így elkerülhető a két hálókártya telepítése és a switch elárasztása is, kommunikálhatnak egymással a szerverek, viszont a multicast forgalom kompatibilitási gondokhoz vezethet elsősorban a routereknél.) Az 1. ábrán látható módon felállt a rendszer és ment is, ahogy az a nagykönyvben meg volt írva.

Aztán két hét múlva elromlott az NLBS. A jelenség nagyjából úgy festett, hogy a kliens megpróbált csatlakozni, már majdnem sikerült, feltűnt a halványkék bejelentkező képernyő, majd hirtelen megszakadt a kapcsolat, pontosabban a szerverek megszakították. A szolgáltatás pedig már épp eléggé fontossá vált ahhoz, hogy meg kelljen oldani a feladatot.

Problémamegoldás kizárásos módszerrel

Ahogy ez lenni szokott, először a problémát szerettük volna elhatárolni. Mindezt persze "takarékosan". Ugyan alapszabály, hogy egyszerre csak egy dolgot változtass, de ez annyira lelassíthatja a problémamegoldást, hogy a gyakorlatban ritkán van türelme a rendszergazdának alkalmazni. Mi is eltértünk néha a szabálytól. Biztosan az NLBS-sel van probléma - gondoltuk, mert a szerverek terminál szolgáltatása elérhető volt, ha a saját nevük, és nem a clusternév alapján akartuk elérni. A switch és a hub nem lehetett hibás, hiszen akkor forgalom sem lehetett volna. S valóban, unicast üzemmódra átkapcsolva, megjavulni látszott a helyzet. Csakhogy így elveszítettük a lehetőségét, hogy egyik node-ról a másikat el lehessen érni, ezt pedig nem akartuk. Mindenképp meg kellett oldani a multicast üzemmódú működést.

Kezdjünk mindent tiszta lappal!

A teljes újratelepítést a végső időkre tartogatva, először csak az NLBS-t vettük le, és telepítettük újra - az eredmény változatlan. Vagy nem tudja megjavítani a telepítő a jelenséget, vagy az NLBS-nek nincs köze az egészhez, ezért nincs is hatása az újratelepítésnek. De biztos az NLBS a hiba forrása.

Nem volt más hátra, újra kellett telepíteni legalább az egyik szervert. Megtörtént, és az NLBS-t újra beizzítva láss csodát: az eredmény ugyanaz, a hiba továbbra is jelentkezett. Ebből az következik, hogy: 1. Felesleges volt az újratelepítés. 2. Nem a Load Balacingben van a hiba, mert kizárt dolog, hogy egy frissen és hibátlanul felhúzott rendszeren sem működik hibátlanul. 3. Korábban már megállapítottuk, hogy az NLBS-sel van a hiba, hiszen az unicast/multicast átkapcsolás megszüntette a hibás működést. Láthatóan egymásnak ellentmondó következtetésekre jutottunk "holtbiztosan hibátlan" logikával. Valamit újítani kellett.

Próba - szerencse

Vajon tényleg hibátlan az új telepítés? S ha igen, akkor hogyan lehet erről meggyőződni? Hát például egy teljesen elszeparált mini hálózatban, ahol csak egy egytagú NLBS szerver üzemel, és egy ügyfél szeretne rákapcsolódni az eszközre. Ezt hamar össze lehetett hozni, hiszen csak egy hubra kellett kötni a klienst és a frissen telepített szervert, a hubot pedig le kellett választani a hálózatról. És a 2. számú csoda: az előbb még nem működő NLBS egyszerre megjavult.

Vagyis: 1. Az újratelepített NLBS-nek kutya baja. 2. Ha egy zsinórátdugással megoldható a rejtély, akkor egyáltalán nem a Windows 2000 táján kell keresni a megoldást. Hanem akkor hol? Nos - akármennyire is fura - a hálózatban "valahol". Végül is van ebben logika: az untig használt unicast forgalommal működik minden, de az "egzotikus" multicast gondot okoz.

No ez meghaladta a tudásunkat - szakértőket hívtunk. Jöttek. Hoztak egy sniffer programot, amely remek statisztikákat adott a hálózat forgalmáról, például, hogy a switch minden portján rengeteg a broadcast és multicast üzenet. A forrás az NLBS cluster közös MAC címe. Hát ez meg mi? Egy switch ugye azért switch, hogy megtanulja a MAC címeket, hogy azután csak a megfelelő portok között jöjjön létre kapcsolat. Egyébként a program nem ismerte fel a csomagok pontos típusát, viszont azt látta, hogy minden másodpercben jön egy. Kellene már valami, ami látja, hogy mi van azon a fene hálózaton!!!

Network Monitor

A szakértők sajnos nem értettek a Network Monitorhoz, illetve az volt a véleményük, hogy nem kell még a csomagokat mikroszkóp alatt vizsgálni, a napnál is világosabb, hogy az NLBS-sel van a hiba és a Windows 2000-ben, tehát egy, a Windows 2000-hez és a Load Balancinghoz értő másik szakértőre van szükség. Én viszont a NetMonra szavaztam (mégsem hiába jártatom a szám? - F.M.), és az alábbi eredményt kaptam:

q A nyomtató közbeszól

A "beszélgetés" normálisan kezdődik. A kliens egy DNS névfeloldás után felveszi a kapcsolatot az NLBS adta szerverrel. Háromcsomagos "kézfogás" (chip-chip-choka), aztán belemerülnek a terminálkapcsolat részleteibe. A harmincadik csomagot kiemeltem, mert az igen furcsa volt. A szekvenciaszám 0-0, az ack pedig a háromcsomagos "kézfogás" után az első csomagra vonatkozik. De ennél is érdekesebb, hogy a MAC címe nem azonos a korábbi szereplőkéivel. Egy idegen. Egy UFO. És mit csinál? ".A.R.." - vagyis: Reset Connection. Egészen pontosan végigböngészve a csomagot kiderült, hogy az állomás IP címe megegyezik a cluster IP címével: 10.0.0.152. És ettől kezdve az UFO folyamatosan válaszolgat a kliensnek: "Reset Connection", "Reset Connection" stb. stb.

Itt a bibi. - A MAC címet ellenőriztük. Volt ilyen állomás: az egy hete üzembe helyezett K. típusú szép új hálózati nyomtatónk. Csakhogy annak van saját IP címe, 10.0.0.74. Hoppá!

A történet most már kikerekedik: A switchünk képtelen megtanulni a multicast címeket, ezért kiküldi minden portra. (Ezért tapasztalt a szakértőnk rengeteg multicast címet.) Amikor az ügyfél és a cluster kommunikálni kezd, ezt is multicast csomagokkal végzik, amelyet szintén kiküld a switch minden portra. A K. nyomtató ezt a multicast folyamot a magáénak érzi (sic!), majd hazudik egy jó nagyot (sic!), és azt mondja, hogy az ő IP címe azonos a szerverével. Végül közli a klienssel, hogy neki nincs "terminal service" portja, ezért minden ilyen irányú kérésre "Kapcsolat megszakad" a válasza. És tényleg, ez megfelel a jelenségnek. Már majdnem felépül a kapcsolat, amikor megszakad. Ellenpróba: K. nyomtatót eltávolítjuk - és minden működik. A nyomtatót visszadugva a hiba újra előáll.

És a megoldás? Ideiglenesen kitöröltük a nyomtató alapértelmezett átjáróját, így a távoli telephelyek felhasználói újra birtokba vehették a clustert. Azután egy nyomtatószervert tettünk az - amúgy hálózati - nyomtatónk elé, és már helyben is használhattuk a clustert. Végül kaptunk egy ígéretet a gyártótól, hogy a nyomtató új firmware-t kap, amely majd nem tartalmazza a hibát. Egyelőre az örök rejtélyek birodalmában tanyázik, hogy vajon miért nem tudja az amúgy vadonatúj, C. típusú, nagyon korszerű switch megjegyezni, hogy honnan és hová kellene a multicast forgalmat irányítania.

Tanulságok

Nem mindig ott a hiba, ahol az felbukkan. Az egész hibakeresést hátráltatta, hogy végig a Windows 2000-re fogtuk a problémát, pedig az ártatlan volt. A "hagyományos" módszerek nem voltak célravezetők. Sok logikai hibát is elkövettünk - ezeket a történetben is benne hagytam, mert így őszinte. A szakértők néha nem tudnak segíteni. Végül: saját kútfőből és ingyenes eszközökkel megoldottuk a problémát, csak rá kellett szánnunk magunkat egy kis hálózati-forgalom elemzésre. - Szóval tényleg: Netmon, netmon, netmon.