Informatika | Hálózatok » Fóti Marcell - Microsoft Network Monitor

NetAcademia-tudástár Network Monitor A hálózati forgalom elemzése - 1. rész, elméleti alapok Ha minden Active Directory probléma megoldását a DNS-ben kell keresni, akkor ugyancsak ökölszabály alapján minden, elsőre zavaros hálózati hiba felderítésekor a Network Monitort KELL használni. Mondogatom ezt már jó ideje mindenféle fórumon, de úgy vettem észre, nem átütő sikerrel. Vannak, akik fel sem telepítik, s vannak, akik az első elkapott hálózati forgalom megtekintésekor borzadnak el, s hiszik, hogy itt a tudomány és a fantasztikum számukra soha meg nem világosodó keverékéről van szó pedig dehogy. Kedves Olvasóim bizony megtanulták, és sikeresen le is vizsgáztak anno a hálózati architektúrák témaköréből: ez volt az OSI modell. Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 1 NetAcademia-tudástár A sikeres vizsgához néhányan versike formájában be

is magolták, hogy: "Physical, Datalink, Network, Transport, Session, Presentation, Application" ami magyarul így hangzik: "Minden vízbe mártott test." ja nem, ez egy másik versike :) Csak hát az elmúlt X évben gyakorlatilag egyetlen esetben sem vették hasznát e tudásnak, s így az szép lassan elkopott. Határozottan kijelenthetem azonban, hogy nem tekinthető komoly szakembernek az, aki nem képes olvasni az Ethernet csomagokban. Napjaink hálózati operációs rendszerei és az arra épülő komplex alkalmazások kommunikációja bizony néha olyan pofonegyszerű beállítási (vagy tervezési) hibán múlik, hogy utólag a fejünket verjük a falba, hogyan is nem vettük észre azonnal, hogyan is lehettünk annyira vakok! A látáshoz azonban eszköz is kell. A hálózati forgalom nyers adatainak megtekintésére úgynevezett sniffert használunk (sniff=szimatol), amellyel az Ethernet (Token Ring stb.) hálózati forgalom bitszintű elemzésére is

lehetőség nyílik Snifferből van buta és okos, drága és olcsó, de érdekes módon az egyik legokosabb ilyen szoftver ingyenes: a Windows NT és a Windows 2000 telepítőlemezén találjuk a Network Monitor programot, melynek funkciókészlete a több százezer forintos egyedi snifferek tudásával vetekszik. A teljesség jegyében mindjárt megjegyzem, hogy a NetMon két változatban áll rendelkezésünkre: a beépített ingyenesben a hackerfunkciók le vannak tiltva, ám a Systems Management Server CD-jén található NM extra a csomagkivonatolástól (coalesce) a csomagok átirkálásán keresztül Ethernet keretek hálózatba pumpálásáig mindent tud: kész hackerarzenál. Mit is tud a NetMon? Elsősorban arra képes, hogy a hálózati forgalmat minden adatával egyetemben elénk tárja, hogy abból következtetéseket vonhassunk le. Ezt a rétegzett hálózati architektúra egy alacsony szintjének (NDIS, Network Driver Interface Specification eszközmeghajtó)

megcsapolásával éri el. Mivel az NDIS meghajtó a lehető legalacsonyabb szoftverréteg a hierarchiában (alatta már a hálókártya hardvere dolgozik) gyakorlatilag minden olyan bitet láttatni enged a NetMon, amit a hálózati kártya felfelé, az operációs rendszer felé kibocsát magából. Itt álljunk meg egy pillanatra Mintha az OSI modellben nem lenne NDIS réteg! Nincs bizony! Az OSI modell csak egy ajánlás arra nézvést, hogy hogyan kell(ENE) rétegzett hálózati architektúrákat építeni, ám ezt történelmi okokból gyakorlatilag egyetlenegy gyártó sem tartja be - nem is teheti, hisz az OSI modell helyett a TCP/IP modellt követjük, mely nem szabványos ugyan, de mindenki azt használja, mert mindenki azt használja. Az alábbi ábra a Windows 2000 Helpjéből származik, és tökéletesen mutatja az OSI és a TCP/IP össze (nem) függéseit. Az OSI elkésett. Addig vacakoltak vele az ISO szabványügyi hivatalban, míg mire készen lett, a világot

elborította a TCP/IP, amely szintén rétegzett, csak másképp, és van vele baj bőven. Itt és most nem elemezném az OSI modell rétegeit és előnyeit, elégedjünk meg azzal, ha azt mondom: minden, ami hiányzik a TCP/IP-ből az OSI modellre épített hálózatokon elérhető lenne (tömörítés, titkosítás, irányított csatornák). Ne áltassuk magunkat, a TCP/IP-ben nics titkosítás Az IPsec, az SSL, a S/MIME, a PPTP, az L2TP mind-mind toldozgatás-foldozgatás! És nincs irányított csatorna sem, a WinSock és a Named Pipes - protézis, hogy szép legyen a TCP/IP mosolya. De térjünk vissza az NDIS-megcsapoláshoz. Ezek szerint van olyan adat, amit nem látunk a NetMonnal, mert a kártya hardverből "lekeveri"? Van bizony! Ilyen az Ethernet fejlécet megelőző, órajelszinkronizációs szerepű Preamble (8 bájtnyi 10101010) és a bithibák kiszűrését segítő CRC kód a keret legvégén. Ha a CRC jó, megkapjuk a csomagot (de a CRC-t nem), ha pedig

rossz, semmit sem kapunk! Ebből máris leszűrhető az a tanulság, hogy a NetMonnal a hálózat hardveres hibáinak megtalálására csak áttételesen, véletlenül, vagy nagyfokú ravaszsággal nyílik mód, ugyanis ha a HW rossz - nem látunk semmit. Ez az eszköz a magasszintű szoftverek botlásainak felderítésére való, kábelhibák kimérésére hívjunk szakembert. A NetMonnal alapvetően kétféle hálózaton dolgozhatunk, pont-pont kapcsolatot megvalósító és üzenetszórásos csatornán. A pont-pont kapcsolatra a legjobb példa a kapcsolt telefonvonalak használata, ahol a tárcsázáskor kialakuló kommunikációs útvonal a későbbiekben nem változik, így az elküldött csomagok címzésére semmi szükség nincs, hisz az egyik oldalon Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 2 NetAcademia-tudástár feladott adat csakis a kábel másik végén pottyanhat ki. Ide sorolható az

ATM is, bár ott virtuális csatornaazonosítókkal meg kell határozni, hogy melyik "kábelen" kommunikálunk. Üzenetszórásos csatornánál azonban egy adott alhálózat minden gépe "hallja" az összes adást, maximum nem vesz róla tudomást, és nem küldi "fel" az operációs rendszernek. Így működik az Ethernet, a Token Ring és még több más, kihalt hálózati rendszer. Ezeken minden egyes elküldött csomag tartalmazza a feladó és a címzett egyedi azonosítóját, úgynevezett MAC (Media Access Control) címét, hogy a hálózati eszközök eldönthessék, vajon a beérkezett csomag nekik szól-e vagy sem. Kezdeti próbálkozásunk szempontjából egyelőre közömbös, hogy HUB vagy SWITCH köt minket össze a hálózattal, mert az ingyenes NetMon úgyis csak azokat a csomagokat képes megjeleníteni, amelyeket gépünk az Ethernet címzés miatt valóban megkap. (A „vájtszeműbbek” észrevehetik, hogy a főképernyőn található

kijelzők a teljes hálózati forgalmat és terhelést mutatják, azaz a NetMon driver valójában mégiscsak promiszkusz üzemmódba kapcsolja az Ethernet kártyát, és csak a felhasználói felület van lebutítva. Ugyanez igaz a NetMon által a rendszerbe illesztett Performance Monitor számlálóról, a "% Network Segment"-ről is: minden Ethernet keretet beszámít, még azokat is, amelyek nem a mi gépünknek szólnak.) Indítsuk el a NetMont, és játszadozzunk vele egy kicsit! Telepítés NT4-nél Crtl Panel->Network->Services->Add, Network Monitor Tools and Agent (vigyázat, TOOLS és Agent, nem sima Agent!), Windows 2000-nél Ctrl Panel->Add/Remove Software->Windows Components, Network & Monitoring Tools vagy ehhez hasonló név alatt. Szépen beköltözik a rendszergazda szokásos eszközei közé Elindítás után így néz ki: Alapvető használata rém egyszerű, a felhasználói felület nem nagyban különbözik a videomagnóétól, s azt

- ugye - az egész család tudja kezelni, így ezzel sem lehet gond bár a "lejátszás" gomb éppenséggel felvesz. Próbaképpen kapjunk el néhány másodpercnyi hálózati forgalmat, és nézzük, hányféleképpen elemezhetjük. Amíg a csomagok elkapása, gyűjtése folyik, addig a főképernyőn az éppen zajló forgalom statisztikáit láthatjuk. Mely gépek küldenek csomagot és kinek, milyen címzéssel (unicast, multicast, broadcast) Már itt lehetőségünk van arra, hogy ha egy MAC addressről pontosan tudjuk, hogy melyik gépé, akkor a címen jobb gombbal kattintva átírhatjuk a megnevezést, ami a későbbiekben nagyban meg fogja könnyíteni az adatok értelmezését. Ha esetleg nem tudjuk fejből a hálózat összes gépének MAC addressét, ne csüggedjünk: a NetMon majd azt is kideríti! Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 3 NetAcademia-tudástár Promiszkusz

mód Ez a fogalom nem egy nemi eltévelyedést takar, hanem a hálózati kártyáknak egy olyan üzemmódját, amikor azokat a csomagokat is "felküldik" az operációs rendszernek, amelyeket nem is az adott gépnek küldtek. Akkor hogy kerültek oda? Az Ethernet, a Token Ring és még sok társuk úgynevezett üzenetszórásos módon közvetítik az adatokat: mindenki hallja, de csak az veszi az adást, akinek szól. Olyan, mintha egy teremben kiabálnék valakinek: mindenki hallja, aki ott van, de nem vesz róla tudomást csak az, akinek szólok. a promiszkusz üzemmódba kapcsolt hálózati kártya minden egyes "meghallott" csomagot felküld az operációs rendszernek. 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 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 a saját hálózatán: PING 172.1602 gombon, majd pingeljünk meg egy, a belső hálózaton található gépet, ki-ki Ha megérkezett a négy válasz, állítsuk meg a felvételt, és tekintsük meg az eredményt a Ha valóban

csendes volt a hálózat, körülbelül ezt láthatjuk: (megállít+megtekint) gombbal. 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 Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 4 NetAcademia-tudástár • 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 Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 5 NetAcademia-tudástár PING 172.1601 é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.1603? 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 Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 6 NetAcademia-tudástár 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 Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 7 NetAcademia-tudástár 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. 4 . réteg Protokoll 4 4 . Réteg „Sürgősség” Interfész 3/4 Protokoll 3 3 . réteg Interfész 2/3 3 . réteg „Titkosítás, Tömörítés stb.” 2 . réteg 2 . réteg „Csomagsorrend” 1. réteg 1 . réteg „Tördelés” Fizikai közeg 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 172160001 To 172160003 PLATAN 1721603 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.160001 To 172160003 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 Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 8 NetAcademia-tudástár 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. Ez a dokumentum a NetAcademia Kft.

tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 9 NetAcademia-tudástár 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 65500 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. Terminológia I. Cikkemben teljesen vegyesen használom a hálózatról elkapott adatokra a keret és csomag szavakat. Valójában mindig ugyanarról beszélek. A megkülönböztetés szőrszálhasogatás esetén fontos lehet, de itt nem ezzel foglalkozunk Történelmi okokból ugyanis ugyanazt az adathalmazt ugyanis más-más névvel illetjük a rétegzett hálózati architektúra különböző szintjein: Ehternet szinten keretről beszélünk (frame) IP szinten csomagról (datagram) TCP szinten pedig szegmensről (segment) De én már csak maradok az összevissza keverésnél 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.microsoftcom 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.1603? -Az enyém! Itt a MAC Addressem! Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető

 2000-2003, NetAcademia Kft 10 NetAcademia-tudástár 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.1603 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: ARP RARP: ARP RARP: ARP RARP: ARP RARP: ARP RARP: ARP RARP: ARP RARP:

ARP RARP: Hardware Protocol Hardware Protocol Opcode = Senders Senders Targets Targets Type = Ethernet (10Mb) Type = 2048 (0x800) Address Length = 6 (0x6) Address Length = 4 (0x4) Request Hardware Address = 002018A1B9D2 Protocol Address = 172.1601 Hardware Address = 000000000000 Protocol Address = 172.1603 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: 1. feliratkozás a technet-join@lyrisnetacademianet címre írott üres levéllel 2. Megfejtés beküldése a technet@lyrisnetacademianet 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? Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 11 NetAcademia-tudástár 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: IP: IP: IP: IP: IP: IP: IP: IP: IP: IP: IP: IP: IP: Version = 4 (0x4) Header Length = 20 (0x14) Precedence = Routine Type of Service = Normal Service Total Length = 60 (0x3C) Identification = 58458 (0xE45A) Flags Summary = 0 (0x0) IP: .0 = Last fragment in datagram IP: .0 = May fragment datagram if necessary Fragment Offset = 0 (0x0) bytes Time to Live = 128 (0x80) Protocol = ICMP - Internet Control Message

Checksum = 0xFE41 Source Address = 172.1601 Destination Address = 172.1603 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): Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 12

NetAcademia-tudástár PC R1 R3 R2 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 E heti rejtvényünk a következő: hogyan dolgozik a TRACERT? Hogyan képes megállapítani az elküldött csomagok útvonalát, ha akár minden csomag eltérő útvonalon kerülhet el a címzetthez? Elő a NetMont, tessék utánanézni! (Hint: nem véletlenül a TTL-hez írtam a rejtvényt.) 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 80-as? WWW! 25-ös? SMTP! 110-es? POP3! Terminológia II. Ahogy a csomag elnevezése is változik rétegről rétegre, ugyanígy az osztályozást segítő mező neve is. Történelmi okokból ugyanis ugyanazt a mezőt ugyanis más-más névvel illetjük a rétegzett hálózati architektúra különböző szintjein: Ehternet szinten kerettípusról beszélünk (frame type) IP

szinten protokollról (Protocol mező) TCP szinten pedig portról Ezt sajnos nem keverhetem össze-vissza, mert a kifejezések (különösen a port) hétköznapi szavakká váltak nyelvünkben 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 Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 13 NetAcademia-tudástár 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 wwwmicrosoftcom) gép kártyájának a címe, hisz 1. 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. 2. 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: ICMP: ICMP: ICMP: ICMP: ICMP: Packet Type = Echo Echo Code = 0 (0x0) Checksum = 0x3A5C Identifier = 512 (0x200) Sequence Number = 4352 (0x1100) 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.internetszolgaltatohu 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 Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 14 NetAcademia-tudástár Network Monitor III. Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 15 NetAcademia-tudástár 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: PING –l 10000 www.netacademianet Először madártávlatból vessünk egy pillantást az elkapott hálózati forgalomra: 1 2 3 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: IP: ID = 0x343D; Proto = ICMP; Len: 1500, Frag.  Offset = 1480 (0x5C8) . 7 IP: Total Length = 1500 (0x5DC) IP: Identification = 13373 (0x343D) 5 IP: Flags Summary = 201 (0xC9) IP: .1 = More fragments in datagram  after this one IP: .0 = May fragment datagram if  necessary IP: Fragment Offset = 1480 (0x5C8) bytes 4 IP: Time to Live = 128 (0x80) IP: Protocol = ICMP - Internet Control Message IP: Fragmented Datagram Data: Number of data 6  bytes remaining = 1480 (0x05C8) 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 Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon

terjeszthető  2000-2003, NetAcademia Kft 16 NetAcademia-tudástár 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! “Hasznos” adat, 10000 bájt Feldarabolandó 10000+ICMP fejléc Eth. IP ICMP abcdefghijklmonpqrstuvwabcdefghijklmnopq 1514 bájt 1480 1480 még 3x1480 1128 A 10000 bájtos ICMP Echo darabolás előtt 1514 bájt Eth. IP ICMP abcdefgh 1472 Eth. IP ijklmnopqrstuv 1480 Eth. IP wabcdefghijklm 1480 Eth. IP nmnopqrstuvwa 1480 Eth. IP bcdefghijklmno 1480 Eth. IP pqrstuvwabcdef 1480 Eth. IP ghijklmn 1128 1514 bájt é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. Kulcs neve: MTU, alapértelmezésben nincs ott Helye: HKLMSYSTEMCurrentControlSetServicesTcpipParametersInterfaces<interface-name> Adattípus: REG DWORD Tartomány: 0x44 – dinamikusan

felismert MTU vagy 0xFFFFFFFF Alapértelmezett érték, ha a kulcs hiányzik: 0xFFFFFFFF (=Autodetect) Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 17 NetAcademia-tudástár 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 ;) C:Documents and Settingsfm.NETACADEMIADesktopigping(Coalesced)02cap 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? 8 Ö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. Ez a dokumentum a NetAcademia Kft. tulajdona

Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 18 NetAcademia-tudástár 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: C:>tracert www.netacademianet Tracing route to www.netacademianet [21297836] over a maximum of 30 hops: 1 2 3 510 ms 351 ms 310 ms 361 ms 240 ms 240 ms 260 ms as5200-0.aholcom [2129791] 221 ms core-if.router0huaholcom [2129781] 241 ms hofeherke.netacademianet [21297836] Trace complete. 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.netacademianet 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-0aholcom [2129791] 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 Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 19 NetAcademia-tudástár 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ő: IP: ID = 0x8214; Proto = ICMP; Len: 56 IP: Precedence = Internetwork Control A Precedence értéke megváltozott Routine-ről (0x00) Internetwork Controlra (0xC0). IP: Data: Number of data bytes remaining = 36 (0x0024) ICMP: Time Exceeded: 212.97836 (See frame 2) ICMP: Packet Type = Time Exceeded ICMP: Time Exceeded Code = Time To Live Exceeded In Transit ICMP: Data: Number of data bytes remaining = 28 (0x001C) 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: ICMP: Description of original IP frame ICMP: (IP) Version = 4 (0x4) eredeti IP cím, checksum stb. ICMP: (IP) Data: Number of data bytes remaining

= 8 (0x0008) ICMP: Description of original ICMP frame ICMP: Checksum = 0xDEFF ICMP: Identifier = 768 (0x300) ICMP: Sequence Number = 5632 (0x1600) 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 ;) Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 20 NetAcademia-tudástár 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ó: STATS: STATS: STATS: STATS: STATS: STATS: STATS: STATS: STATS: STATS: STATS: STATS: STATS: STATS: STATS: Number of Frames Captured = 2048 Elapsed Time = 5 Minutes 18 Seconds 439786

MicroSeconds Total Frames Captured = 2048 (0x800) Total Bytes Captured = 262073 (0x3FFB9) Total MultiCasts Received = 94 (0x5E) Total BroadCasts Received = 26 (0x1A) Total Frames Dropped From Capture = 0 (0x0) Total Frames Dropped From Buffer = 0 (0x0) MAC Frames Received = 1875 MAC CRC Errors = 0 MAC Bytes Received = 0x000000000009C036 MAC Frames Dropped due to No Buffers = 0 MAC MultiCasts Received = 30 MAC BroadCasts Received = 26 MAC Frames Dropped due to HardWare Errors = 0 A statisztikacsomagot mindig a NetMon Trace utolsó csomagjában, az itt felhasznált fájlokat (pigping.cap, tracertcap, pathping.cap) pedig a weben találják Lelkes Olvasóim Fóti Marcell marcellf@netacademia.net Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 21 NetAcademia-tudástár 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. Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 22 NetAcademia-tudástár El lehet tűnődni azon, hogy vajon ez a hibakezelés elég intelligens-e, vajon mindig egyértelműen törölni kell-e a hibás csomagokat (a Voice Over IP például „jobban megy” még

hibás csomagokkal is, mint újraküldött hibátlanokkal, mert a csomagismétlés késleltetése sokkal zavaróbb a beszédértésben, mint holmi bithibák). 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 FONTOSXLS-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 tcpipsys 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 Kérdés, melyre a tech.net@lyrisnetacademianet csomagduplázódás? Talán dadog valamelyik router? című levlistán várom a válaszokat: hogyan képzelhető el 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. Itt most megint elfilozofálhatnánk azon, hogy vajon minden esetben érdemes-e bármi áron, vérző fejjel leszállítani az üzenetet, vagy értelmesebb lenne talán feladni a próbálkozást, ha az átbocsátóképesség X bit/s alá csökken. QoS, Quality of Service! 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: Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 23 NetAcademia-tudástár 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.netacaemianet-re tekeredik, másik a www.microsoftcom-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.netacademianet 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 SMTPtő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 80-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 Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 24 NetAcademia-tudástár 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: http://www.matavhu: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: 80-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 netstat -p TCP 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 80-as porti forgalomnak négy változata van! 1 Befelé 2 Kifelé 3 Befelé 4 Kifelé Feladó portja 80 Fogadó A forgalom típusa portja kliensport weblapkérésre külső kiszolgáló válasza 80 kliensport a belső webkiszolgáló válasza kliensport 80 a belső webkiszolgálót kívülről zaklatják kliensport 80 weblapkérés bentről, kinti címre 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. Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 25

NetAcademia-tudástár 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: .AS 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 .AF .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 .AS .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! Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 26 NetAcademia-tudástár 1 2 3 4 Synchronize Sequence Numbers Ethernetben IP-ben TCP. A feladó portszáma (1), a 0x047A egy kliensport, hisz ez a szám nagyobb, mint 1024 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! 5 6 7 Synchronize Sequence Numbers válasz Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 27 NetAcademia-tudástár 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ó:

Acknowledgement Number = 302666184 (0x120A51C8) 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: Telnet www.netacademianet 80 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 82-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 csukott82cap fájlban található, s így fest: Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül

szabadon terjeszthető  2000-2003, NetAcademia Kft 28 NetAcademia-tudástár 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 .AR 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: pop3cap) Telnet mail.netacademianet 110 9 8 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! 10 A pop3.cap fájl Te jó ég! Ez a két parancs 62 csomagot generált (10)! Hiszen összesen 3-4 kérdés és válasz történt! Mi lehet ez? Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 29 NetAcademia-tudástár 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! 11 Number of data bytes remaining Csak nézzük meg szúrópróbaszerűen a Number of data bytes remaining-et mondjuk a 30. 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: ->HELO mail.netacademianet <-OK ->MAIL FROM: marcellf@netacademia .net <-OK ->RCPT TO: akarki@sehol.com <-OK ->DATA és jöhet a levél. 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 Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 30 NetAcademia-tudástár 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 Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 31 NetAcademia-tudástár 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. Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 32 NetAcademia-tudástár 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. 1 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 http://wwwnetacademianet 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. Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 33 NetAcademia-tudástár 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. Fontos! A MAC Address szintű szűrés félreértésekre adhat okot, hiszen távoli hálózaton lévő gépek esetén nem a távoli gép MAC Addressét látom, hanem a Default Gateway hálókártyájának innenső lábát! Miért? Mert a MAC Address nem alkalmas végponntól-végpontig történő címzésre, erre a feladatra az IP való. A kemény félrediagnosztizálások elkerülése érdekében szűrjünk inkább a feladó és címzett IP címére! 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? gombjára, ezzel Használjuk azt is bátran!) Mielőtt teljesen belemerülnénk, hadd hívjam fel a figyelmet az eszközsáv 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. Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 34 NetAcademia-tudástár 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 HTTPnek, é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): HTTP: GET Request (from client using port 1075) HTTP: Request Method = GET HTTP: Uniform Resource Identifier = / 2 HTTP: Protocol Version = HTTP/1.1 HTTP: Accept = */ 3 HTTP: Accept-Language = en-us HTTP: Accept-Encoding = gzip, deflate HTTP: User-Agent = Mozilla/4.0 (compatible;  MSIE 5.5; Windows NT 50; COM+ 102204) HTTP: Host = www.netacademianet 4 HTTP: Connection = Keep-Alive HTTP: Cookie = Language=hu;  ASPSESSIONIDGQGQGBDY=OHOFAODBOJJAHCFNBAJDKAIE • 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 Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 35 NetAcademia-tudástár • • 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.netacademianet 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/maincss 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 11-nél tart Talán a legszembetűnőbb különbség az 10 és az 11 között a TCP csatornák újrafelhasználásában mutatkozik. Míg az 10 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. 5 6 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 11 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 .AS .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: Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 36 NetAcademia-tudástár 7 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 = 0x2 .AS = 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 Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 37 NetAcademia-tudástár 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 1076-os (a feladó a 80-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 A cikkben szereplő URL-ek: [1] http://technet.netacademianet/feladatok/netmon Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 38 NetAcademia-tudástár 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! Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 39 NetAcademia-tudástár 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 2000 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: - Fiúk, kinek az IP címe az én IP címem? 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.345678share !) 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 NETACADEMIA <00> 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: 00 03 20 Workstation Service (ez a gép képes fájl- és

nyomtatószolgáltatás igénybevételére) Messenger Service (az adott névre üzenetet lehet küldeni Net Send paranccsal, vagy Winpopuppal) Server Service (ez a gép képes fájl- és Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 40 NetAcademia-tudástár nyomtatószolgáltatás nyújtására. A 20-as rekord az alapértelmezett, ez nem írja ki külön a NetMon, lásd fenn.) 1B 1C 1E 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 Cacheben. 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ó”: EOEFFEFEEFFCENDJDICACACACACACAAA Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 41 NetAcademia-tudástár 1 2 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: 224002 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 224002 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őbbutó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 EFSsel 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 00 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 Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 42 NetAcademia-tudástár 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): SMB: Flags Summary = 128 (0x80) .0 = Lock & Read and Write & Unlock not supported .0 = Send No Ack not supported .0 = Using case sensitive pathnames .0 = No canonicalized pathnames .0 = No Opportunistic lock .0 = No Change Notify SMB: flags2 Summary = 0 (0x0) .0 = Understands only DOS 83 filenames .0 = Does not understand

extended attributes .0 = No DFS namespace .0 = No paging of IO .0 = Using SMB status codes 0. = Using ASCII strings 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 2000-nél): SMB: Flags Summary = 24 (0x18) .1 = Using caseless pathnames .1 = Canonicalized pathnames SMB: flags2 Summary = 51283 (0xC853) .1 = Understands long filenames .1 = Understands extended attributes .1 = Using NT status codes 1. = Using UNICODE strings Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 43 NetAcademia-tudástár 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: Az SMB protokoll mind a mai napig nem támogatja az NTFS speciális fájltárolását (az attribútumokat igen!). 1. Az NTFS tömörített fájljai kitömörítve utaznak a hálón még akkor is, ha mindkét fél Windows NT/2000 2. Az EFS-sel titkosított fájlok kibontva, titkosítás nélkül utaznak a hálón, mivel az SMB nem tudja lekezelni a titkosítást 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 [\masinaprinter], 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 369csomag): 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 Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 44 NetAcademia-tudástár Fóti Marcell marcellf@netacademia.net A cikkben szereplő URL-ek: [1] http://technet.netacademianet/feladatok/netmon Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 45 NetAcademia-tudástár 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! Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 46 NetAcademia-tudástár 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. RAID 5 NodeA NodeB tual Server Exchange 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 WLBSSYS 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 WLBSSYS-ek pedig szépen eldöntik, hogy a sok Node közül melyik vegye magára a kérdést, melyik válaszoljon. Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 47 NetAcademia-tudástár NLBS NLBS NLBS 172.1601 172.1602 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 WLBSSYS-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: 1. 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). 2. 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 WLBSSYS továbbengedi a kérést az oprendszernek, s ez a gép válaszol. Ha nem – a WLBSSYS 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: IP cím MAC Address 01 00 224 13 45 1 5E 0D 2D 01 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 Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 48 NetAcademia-tudástár segítségével lehet. Ráadásul Mulitcast IP címekkel (D osztály, 224000-239255255255) 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: ETHERNET: Destination address : 03BFC0A8040A ETHERNET: .1 = Group address ETHERNET: .1 = Locally administered address 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.168410) 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 WLBSSYS 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 NLBSCAP 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 Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 49 NetAcademia-tudástár 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! ETHERNET: ETYPE = 0x0806 : Protocol = ARP: Address Resolution Protocol ETHERNET: Destination address : 0090272CE129 ETHERNET: Source address : 0002A5095EB8 1 ETHERNET: Frame Length : 60 (0x003C) ETHERNET: Ethernet Type : 0x0806 (ARP: Address Resolution Protocol) ETHERNET: Ethernet Data: Number of data bytes remaining = 46 (0x002E) ARP RARP: ARP: Reply, Target IP: 192.1684200 Target Hdwr Addr: 0090272CE129 ARP RARP: Hardware Type = Ethernet (10Mb) 2 ARP RARP: Protocol Type = 2048 (0x800) ARP RARP: Hardware Address Length = 6 (0x6) ARP RARP: Protocol Address Length = 4

(0x4) ARP RARP: Opcode = Reply ARP RARP: Senders Hardware Address = 03BFC0A8040A ARP RARP: Senders Protocol Address = 192.168410 ARP RARP: Targets Hardware Address = 0090272CE129 ARP RARP: Targets Protocol Address = 192.1684200 ARP RARP: Frame Padding 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 NLBSre, 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! Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 50 NetAcademia-tudástár Kérdés (Multicast MAC-ra) Válasz (saját MAC-ról) MAC: 03BFC0A8040A NLBS NLBS NLBS 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 HKEY LOCAL MACHINESYSTEMCurrentControlSetServicesWLBSParametersMaskSourceMAC é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: Munkaallomas -> ICMP Echo -> Kozos MAC Munkaallomas <- ICMP Reply <- Node A MAC Munkaallomas <- ICMP Reply <- Node A MAC 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) Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 51 NetAcademia-tudástár • 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 A

cikkben szereplő URL-ek: [1] http://technet.netacademianet/feladatok/asp [2] RFC 1112 Host Extensions for IP Multicasting http://www.ietforg/rfc/rfc1112txt?number=1112 [3] RFC 1700 Assigned Numbers http://www.ietforg/rfc/rfc1700txt?number=1700 Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 52 NetAcademia-tudástár 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). Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 53 NetAcademia-tudástár 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ó. Eszköz Ikon Monitor Control Tool Expert 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. Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 54 NetAcademia-tudástár 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: Expert Mire való? Average Server Response Általunk kiválasztott (pl. Time FTP, SMTP stb.) kiszolgálóalkalmazások válaszidejének kiszámítása Property Distribution Egyes protokollok mezőinek megoszlása (pl.: TCP – Destiantion Port) Protocol Coalesce Tool Protokoll-összevonó. Töredezett csomagok összevonása egyetlen nagyobba Protocol Distribution Protokolleloszlás. Mennyi egyedi protokoll van az elkapott forgalomban? TCP Retransmit Újraküldött TCP csomagok száma Top Users A legtöbbet forgalmazó felhasználók kilistázása 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: Monitor Mire való? ICMP Redirect Hibás routerüzenetek észlelésére IP Router A hálózat routereinek életjeleinek figyelése IPRange A hálózaton kiosztott IP címektől eltérő címek felbukkanása ellen IPX Router Ugyanaz, mint az IP Router Monitor, azzal a különbséggel, hogy nem használjuk, mert úgysincs IPX a hálózatunkon :-) Rouge DHCP and WINS Hamis DHCP és/vagy WINS észlelésére Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft

55 NetAcademia-tudástár Security SYN Attack NetMon kukkolók kitiltása SYN támadás felismerésére 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 wwwnetacademianet 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áselő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! Ez a dokumentum a NetAcademia Kft.

tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 56 NetAcademia-tudástár 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 httpcap 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? Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 57 NetAcademia-tudástár 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!): LLC SNAP

SMB IP ARP RARP ICMP UDP NBT TCP DNS MSRPC Browser TRAIL STATS R LOGON LDAP 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: Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 58 NetAcademia-tudástár Toplista (vagy feketelista?) A 172.16017-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 Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 59 NetAcademia-tudástár 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. Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 60 NetAcademia-tudástár 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 Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 61 NetAcademia-tudástár é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 A cikkben szereplő URL-ek: [1] http://technet.netacademianet/download/netmon Ez a dokumentum a

NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 62 NetAcademia-tudástár 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. Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 63 NetAcademia-tudástár 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 SWITCH 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 Minden más lebonyolítható. További hátránya

az unicast üzemmódnak, hogy a HUB 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 Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 64 NetAcademia-tudástár 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:  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? „AR” – 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.00152 É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, 100074 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 Lepenye Tamás, MCSE lepenyet@mal.hu Ajánlott irodalom: 1. Network Load Balancing Technical Owerview, (TechNet, 2001 május) 2. Windows 2000 Server Training, Network Load Balancing, (TechNet 2001 május) 3. Q238219; Q240997; Q243523; 4. Q247297; Q256124; Q264645; 5. Windows 2000 Resource Kit, Chapter 19: Network Load Balancing 6. Windows 2000 Network Load Balancing Help Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  2000-2003, NetAcademia Kft 65