Informatika | Hálózatok » Fóti Marcell - Felhasználók azonosítása régen és ma

Alapadatok

Év, oldalszám:2003, 13 oldal

Nyelv:magyar

Letöltések száma:683

Feltöltve:2005. november 07.

Méret:196 KB

Intézmény:
-

Megjegyzés:

Csatolmány:-

Letöltés PDF-ben:Kérlek jelentkezz be!



Értékelések

11111 honvedz 2012. október 07.
  Nagyon hasznos információkat tartalmaz, még mai is!

Tartalmi kivonat

NetAcademia-tudástár Megjelent a Windows.HU magazin 1999. októberi és novemberi számában Felhasználók azonosítása régen és ma Kihívás/válasz, Azonosítók átadása és Kerberos A felhasználók azonosítása és a titkosított hálózati forgalom nem csupán az emberi gyengeség ellen tett óvintézkedés, hanem fontos szervezőerő. Munkahelyünk a második otthonunk, melynek kényelmét, lakályosságát egy-egy cserép virággal, otthoni bögrével, családi képekkel saját magunk is alakíthatjuk. A társadalmi normákat, az együttélés szabályait azonban nem mi találjuk ki, hanem hallgatólagos, vagy írott törvények rögzítik, melyeknek be nem tartása büntetéssel jár. Nos, hálózatunk a második társadalmunk Szabad országban élünk, azaz mindenki azt tehet, amit csak a társadalom még elvisel. Szabad országban élünk, azaz mindenki és minden egyedi azonosítóval rendelkezik (mi magunk, személygépkocsink, telkünk), szabályok igája alatt

nyögünk. A hálózatok “kényelmes és biztonságos” használatához szintén szabályok bevezetésére van szükség, a szolgáltatások testre szabásához, valamint a büntetések kiszabásához ugyanúgy nélkülözhetetlen a felhasználók azonosítása, mint a nagybetűs életben. Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  20002003, NetAcademia Kft 1 NetAcademia-tudástár Az azonosítást erre a célra üzembe állított hálózati kiszolgálók végzik. A főcímben szereplő Kihívás/válaszon (Challenge/Response) Azonosítók átadásán (Pass Through avagy amerikaiul: Pass Thru) és Kerberoson kívül még sok azonosítási technológia létezik, azonban ezek a legelterjedtebbek, és ráadásul a Windows 2000-ben is megtalálhatóak. A Kerberos a fiatalabb, de mivel a világ kereke lassan forog, s a régebbi megoldások is közöttünk lesznek néhány évig, megnézzük a Windows NTféle azonosítást, a

Kihívás/válasz algoritmust is, valamint a legjelentősebb, azonosítással kapcsolatos technikák is szóba kerülnek. Algoritmus helyett használhatjuk a protokoll szót is, mert e két eljárás valóban protokolláris lépések sorozatán át jut el a végcélig, a felhasználó azonosításáig. A lépések sora csipkegalléros, rizsporos parókás francia nemesek mulatságos köszöntési rítusára emlékeztet, ahol még a kalaplengetés ívének is fontossága, jelentéshordozó szerepe van. Mindezt azért bocsátom előre, mert nehéz dolgunk lesz: idegen kultúrát fedezünk fel, ahol a kalaplengetést hálózati csomagok helyettesítik, és ahol a sok körülményeskedés igazi célja a találkozó felek által ismert legerősebb titkosítás kiválasztása anélkül, hogy használható titkosító kulcs kerülne idegen kezekbe. Ez nem is olyan egyszerű, mint gondolnánk, hiszen a gépek közötti kommunikáció egyetlen eszköze az a hálózat, ahol gonosz hackerek

tömege figyeli a hálózati forgalmat. Ezért a titkosító kulcs átküldése elvileg csak titkosítottan történhet, ami látszólag feloldhatatlan problémához vezet: a partnernek továbbítandó kulcsot úgy kell titkosítanom, hogy ő, és csakis ő legyen képes azt kibontani (egy erre szolgáló kulccsal), de akkor meg minek küldök kulcsot, hisz a kulcs kibontási kulcsa ezek szerint már birtokában van. De mitől van ott, hisz még át sem küldtem? Münchausen báró üldögél nyakig a mocsárban. Nem esik kétségbe, hanem a saját hajánál fogva kirángatja magát! No ez a Kerberos. Igények, igények, igények A személycsereberék elkerülésének ősi eszköze a személyes, titkos jelszó. Az azonosítás megbízhatósága és a csalások kiszűrése érdekében már az időszámításunk előtti hálózati operációs rendszerekben is használtak valamiféle titkosítást az azonosítók és jelszavak továbbításakor, hiszen ha a hálózaton hallgatózva el

lehet kapni a jelszavakat, már semmi sem áll az emberi gyengeség útjában, és előbb-utóbb bekövetkezik a csalás. Sajnos a hamis digitális arcról utólag roppant nehéz letépni az álszakállt, ha valaki sikeresen „becsalta” magát a rendszerbe, ez a tény általában túl későn, vagy sohasem derül ki. Nagyban növeli a hálózat biztonságát, ha egyszeri bejelentkezéssel a vállalat összes rendelkezésünkre bocsátott eszközét el tudjuk érni, legyen az levelezés vagy nyomtatás. Ha ez nem teljesíthető, vagyis a felhasználóknak lépten-nyomon be kell jelentkezniük, esetleg ráadásul minden erőforrásnál más és más névvel és jelszóval, a biztonságos azonosításon maga a dolgozó üt rést, hiszen a neveket és jelszavakat ki fogja ragasztani a monitorára. Ami pedig a szándékos jelszólopást illeti, ez ellen a titkosító kulcs sűrű cseréjével védekezhetünk. Az eddig felvázolt igények kielégítésére a Windows-világban a tartomány

modell szolgál. Minden tartomány egy-egy önálló biztonsági zóna, egy kis társadalom, saját szabályokkal, ahol a titkosított jelszóküldés, egyszeri bejelentkezés, gyakori kulcscsere már a Windows NT 3.1 óta széleskörűen elérhető alapvető szolgáltatás A tartománymodell erejét érzékelteti az is, hogy bár óriási fejlesztések történtek a Windows NT operációs rendszeren, a Windows 2000 biztonsága továbbra is Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  20002003, NetAcademia Kft 2 NetAcademia-tudástár tartomány alapú. Az alábbi táblázat összefoglalja a Windows NT 40 és a Windows 2000 tartománykezelésének főbb jellegzetességeit. Windows NT 4.0 Windows 2000 Szervezés Sík terep - táblázat Hierarchikus Biztonsági adatbázis SAM (max. 40000 fiók) Active Directory Jelszótitkosítás Tördelőalgoritmus (hash) Szimmetrikus titkosítás Azonosítás Kihívás/válasz Kerberos

(Challenge/Response) Itt nem foglalkozom az Active Directory vadonatúj szolgáltatásaival, erről sokan és sokat írtak már. A táblázat érthetetlennek tűnő fogalmai közül először a tördelőalgoritmus kerül terítékre, mert általánosan használt titkosítási eljárás. HASH! A jelszótitkosítás egyik igen elterjedt és erőteljes módja a tördelőalgoritmus segítségével történő elváltoztatás, amely nem becsukom/kinyitom elrejtem/megfejtem típusú kétirányú titkosítást használ, hanem olyat, ahol a titkosítás egyirányú út: amit egyszer titkosítottam, abból többé nem állítható elő az eredeti! Ez első megközelítésben biztos használhatatlannak tűnik, olyasminek, mint a csak írható lemez, vagy a párhuzamos portra köthető iratmegsemmisítő, mellyel egyből csíkokra hasogatott dokumentumok állíthatók elő. Ha jobban belegondolunk, akkor azonban van értelme, hiszen nem csak ÉN nem tudom visszafejteni, hanem senki sem, azaz

örök biztonságban van! Hogyan lehet ezzel bejelentkeztetni? Igen egyszerűen. Nem csak a jelszavak, hanem az azonos módon előállított hash-ek azonossága is alkalmas a jelszó helyességének megállapítására. Az azonosítást végző tartományvezérlő a nála lévő jelszóváltozatot titkosítva megkapja ugyanazt (?) a hasht, amit összehasonlít a hálózaton beérkezettel. Ha ez a „helyben sütött” jelszó-hash megegyezik azzal, amit azonosítás céljából a hálózaton át megkapott, akkor a megadott jelszó helyes. Pofonegyszerű! Ezeket kell összehasonlítani Ö”*+§=h@ Hash Jelszó Ügyfél Tartományvezérlő Jelszó SAM Hash Ö”*+§=h@ A tördelőalgoritmusok eredménye általában kivonatolva, azaz jelentősen lerövidítve „tartalmazza” az eredeti adatot, hisz visszaállításra úgysincs szükség. Közeli rokonuk az ellenőrzőösszeg (checksum), ami szintén egy adott bájtsorozatra jellemző rövid kódot állít elő. A Windows NT

kétféle tördelőalgoritmust is használ, egy LanMan fedőnevű – eléggé gyatra – őskövületet, és egy újabb verziót, s ezek mindegyikével egyenértékűen képes dolgozni. Az Interneten talán a legelterjedtebb tördelőalgoritmus Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  20002003, NetAcademia Kft 3 NetAcademia-tudástár az MD5 (Message Digest), ami bármekkora bájtsorozatból 16 bájtnyi kivonatot képez, s jelen pillanatig nincs „ellene” orvosság, azaz feltörhetetlen. Kihívás/válasz (Challenge/Response) A tördelőalgoritmus ismeretében most már megvizsgálhatjuk a bejelentkezés menetét is, először is a Kihívás/válasz (Challenge/Response) protokollt. Felmerülhet a kérdés, hogy miért foglalkozunk még mindig ezzel a viszonylag elavult technológiával, hiszen pillanatokon belül megjelenik a Windows 2000 a Kerberossal. Nos, a Windows 2000 előbb-utóbb remélhetőleg valóban

megjelenik, de a régebbi operációs rendszerekkel való kompatibilitás miatt továbbra is használható a Kihívás/válasz, ha pedig netán kikapcsoljuk a tartományvezérlőn ezt a szolgáltatást, akkor abban a pillanatban elveszítjük a Windows NT 4.0, a Windows 95-98 és az ennél még régebbi ügyfeleket. Az előbbiek szerint a tartományvezérlő akkor fogad el egy jelszót helyesnek, ha a hálózaton át beérkezett titkosított példány megegyezik a „helyben sütött” titkosított verzióval. Nyilván mindkét gép ugyanazt az algoritmust futtatja Továbbmegyek, ugyanazt a titkosító kulcsot kell, hogy használják, különben nem jutnának azonos eredményre, és senki sem tudna bejelentkezni! Ezek szerint nem csak az algoritmus közismert, hanem a kulcs is? Igen is, meg nem is. A Kihívás/válasz az azonosításkor használt titkosító (hash) kulcsok egyediségét biztosító protokoll, amely lehetővé teszi, hogy a bejelentkezésben résztvevő két gép

azonos, ámde egyszer használatos kulccsal dolgozzon a jelszavak titkosításakor. A jelszavak titkosítását tehát megelőzi egy egyezkedési (negotiation) fázis, amikor mindkét oldal megegyezik a használandó kulcsban. Mielőtt átadnánk magunkat az (algo)ritmus élvezetének, hadd kapjon szót a kisördög: tessék mondani, az egyezkedés hálózati forgalmából nem lehet kilopni a kulcsot? De, ki lehet. Viszont semmire sem megyünk vele, mert • Egyszer használatos. Nincs újrahasznosítás, felhasználás után egyenesen megy a kukába • A hash egyirányú titkosítás, vagyis a kulcs NEM alkalmas visszafejtésre (L0phtcrack?? az ellenvéleményeket emailben kérem) Az alábbi ábrán a Kihívás/válasz menete látható. A tisztánlátás érdekében élőben közvetítem a meccset: 5. 3. Hash! Hash! 1. Be szeretnék jelentkezni 2. Ezt használd titkosításkor! (KIHÍVÁS) 4. Név, VÁLASZ (a jelszó helyett) 6. Rendben/Elutasítva SAM 1. Az ügyfél jelzi a

tartományvezérlőnek, hogy bejelentkezésre lenne szükség Az ügyfélgépen bejelentkezni kívánó Sárga Úr begépeli a jelszavát, ami megtalálható a tartományvezérlő SAM adatbázisában is, így össze lehet e kettőt vetni. Nem kell más, mint egy titkosító kulcs. Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  20002003, NetAcademia Kft 4 NetAcademia-tudástár 2. Már jön is a kulcs A tartományvezérlő átküld a hálózaton egy KIHÍVÁS-t az ügyfélgépre (8 bájtos kód), amely a tördelőalgoritmus (hash), vagyis a titkosítás alapjául szolgál a következő lépésben. 3. HASH! Az ügyfélgép titkosítja a Sárga Úr által begépelt jelszót A szakirodalomban néha azt olvashatjuk, hogy nem a KIHÍVÁS-sal titkosítjuk a jelszót, hanem a jelszóval a KIHÍVÁS-t, de ez pusztán nézőpont kérdése. Előáll a hash, a Kihívás/válasz-ból a VÁLASZ! 4. Sárga felhasználó neve (titkosítatlanul)

és a VÁLASZ visszautazik a tartományvezérlőre. 5. A tartományvezérlő a név alapján most tudja meg, hogy ki akar bejelentkezni, kikeresi a SAM-ból Sárga Úr bejegyzését, ahol megtalálja Sárga Úr letárolt jelszavát. HASH! A gép az eredeti KIHÍVÁS-sal titkosítja az általa ismert jelszót, s az eredményt összeveti azzal, amit a 4. lépésben a hálózaton át megkapott 6. Két esélyes a dolog: a két hash vagy megegyezik, vagy nem, ennek megfelelően a válasz vagy engedélyezés vagy tiltás. Tökéletes ugye? Valóban, két gép esetén a Kihívás/válasz megfelelő teljesítményt nyújt. Én azonban láttam már három, öt, sőt több száz, sőt több ezer gépes hálózatot is. Lásd később Access Token Végre egy szakkifejezés, ahol nem kell a különböző magyar változatok közül választani, mert nincs magyar változat. Nem mintha nem lenne fontos az Access Token ismerete - ám valljuk be: a mai napig elég kevesen hallottak róla. Miért van

az, hogy bejelentkezés után a felhasználó nem tehet meg bármit, amihez kedve van? Miért nem okoz kárt a makro-vírus, ha egy utolsó senki gépét fertőzi meg, s miért tarolja le az egész vállalatot, ha ugyanezt a vírust a rendszergazda „futtatja”? A válasz: Access Token. Vegyünk egy bankot, ahol kártyával nyíló ajtók mögött találhatóak a kincsek, a kiszolgálók, az iratok stb. Miért van az, hogy egy utolsó senki nem képes hibátlan kártyájával bemenni a páncélterembe, míg a pénztáros előtt kinyílik az ajtó? Nos, az ő ajtónyitogató kártyájuknak a Windows-tartományban az Access Token felel meg. Olvasható rajta a felhasználó neve, valamit az általa igénybe vehető szolgáltatások jogosságának megállapításánál is fontos szerepe van. Tételesen a következő adatok találhatók az Access Tokenen: • A felhasználó SID-je (DC) • A globális csoportok SID-jei (DC) • A lokális csoportok SID-jei (WS) • Rendszerszintű

jogosultságok (WS) A SID, avagy Security Identifier a felhasználó belső azonosítója, egyedi sorszáma, olyan, mint a személyi szám. A felhasználó különböző csoportok tagja, s a csoportoknak is van SID-jük, ezek is felkerülnek bejelentkezéskor az Access Tokenre. Emellett a rendszerszintű jogosultságok „olvashatók” rajta, például, hogy van-e joga az illetőnek mentést készíteni, átállítani a rendszerórát, leállítani a gépet stb. A SID-ek a fájlokon és nyomtatókon érvényesíthető jogosultságok kiértékelésénél játszanak fontos szerepet, mert itt sem a nevek, hanem a SID-ek alapján ellenőrizhető a jogosultság. Tulajdonképpen bejelentkezés után a felhasználó bármit is próbál végrehajtani, csak az Access Token „árnyékában” mozoghat. Elavult technológia az Access Token? Szó sincs róla, a Windows 2000 változatlanul ezzel a módszerrel dolgozik. Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon

terjeszthető  20002003, NetAcademia Kft 5 NetAcademia-tudástár Azonosítók átadása (Pass Thru) Figyelem! Aki Kihívás/válasz magyarázatánál elveszítette a fonalat, most menjen szépen vissza megkeresni, mert e nélkül az azonosítók átadását nemhogy élvezni nem fogja, de még ideges is lesz! Bővítsük hálózatunkat. No nem nagyon, csak 50%-kal Minden cég megirigyelné ezt a bővülési ütemet, itt azonban az eddigi két gép után csak három lesz. Ezek közül egy a tartományvezérlő, a másik kettő pedig munkaállomás. Az egyik munkaállomás előtt üldögélve, lábunkat meg nem mozdítva szeretnénk igénybe venni a másik gép megosztott erőforrását, mondjuk egy CD meghajtót. 7. Hash! 6. 3. Hash! Né v, KI HÍ 8. VÁ Re S, nd be VÁ n /E l LA SAM uta SZ sít va 1, 2, 3, 4 ugyanúgy, mint az előbb 5. Hoppá! 9. Rendben/Elutasítva A bal oldali gép előtt ülünk, nevünk Sárga Úr. A jobboldali géphez csatlakozást

kezdeményezünk, ami csak megfelelő azonosítás után lehetséges. Beindul a Kihívás/válasz a két gép között(!), a tartományvezérlő tudta nélkül. Miért próbálja meg a jobboldali munkaállomás egymaga elvégezni az azonosítást? Mert van rá esély, hogy egy helybéli felhasználót adunk meg, a például lokális Administrator nevét és jelszavát. Ezért az első 4 lépés majdnem teljesen megegyezik az eredetileg felvázolt Kihívás/válasszal, vagyis: 1. A baloldali gép jelzi a jobboldalinak, hogy bejelentkezésre lenne szükség Az átjelentkezni kívánó Sárga Úr nem gépeli be újra a jelszavát, mert egyszer már bejelentkezett vele baloldalon. Nem kell más, mint egy titkosító kulcs 2. Már jön is a kulcs A jobboldali gép átküld a hálózaton egy KIHÍVÁS-t a baloldali gépre (8 bájtos kód), amely a hash algoritmus, vagyis a titkosítás alapjául szolgál a következő lépésben. 3. HASH! Az ügyfélgép titkosítja a Sárga Úr által

korábban már begépelt jelszót Előáll a hash, a Kihívás/válasz-ból a VÁLASZ! 4. Sárga felhasználó neve (titkosítatlanul) és a VÁLASZ visszautazik a jobboldali gépre. 5. Az ötödik lépésnek a „Hoppá” nevet adtam Itt derül ki ugyanis, hogy a beérkezett név és jelszó helyben nem értékelhető ki, mert a felhasználó a központi adatbázisban, a tartományvezérlőn található, ezért nincs a jobboldali gépen egyetlenegy példány sem Sárga Úr jelszavából, így nincs mivel összehasonlítani a beérkezett jelszó-hash-t. Vagyis a jelszó helyességének megállapításához külső segítségre lesz szükség. Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  20002003, NetAcademia Kft 6 NetAcademia-tudástár 6. A baloldali gép mindent (név, eredeti KIHÍVÁS, beérkezett VÁLASZ) beleteszi egy szeretetcsomagba, és egy az egyben átküld a tartományvezérlőnek, dolgozzon az helyette! 7. A

tartományvezérlő a szeretetcsomagból veszi ki, hogy ki akar bejelentkezni, kikeresi a SAM-ból Sárga Úr bejegyzését, ahol megtalálja Sárga Úr letárolt jelszavát. HASH! A gép a szeretetcsomagban talált KIHÍVÁS-sal titkosítja az általa ismert jelszót, s az eredményt összeveti azzal a verzióval, amit a szeretetcsomagban megkapott. 8. Két esélyes a dolog: a két hash vagy megegyezik, vagy nem, ennek megfelelően a válasz vagy engedélyezés vagy tiltás, ami a jobboldali géphez kerül, aki ezt csak elismétli a 9. lépésben a baloldalinak: „Azt üzeni a tartományvezérlő, hogy” Hát nem bájos? Még mindig az. De már megfigyelhető a később elhatalmasodó kór: itt az azonosítók már kétszer mentek át a hálózaton, ami sem nem túlságosan sávszélesség-takarékos, sem pedig kifejezetten biztonságos. Tartományok összekapcsolása (trust) Minden Windows NT és Windows 2000 tartomány önálló biztonsági zóna, saját név/jelszó

adatbázissal és saját szabályokkal. Ezt bizonyítja, hogy minden tartománynak önálló szabályai lehetnek a minimális jelszóhosszra, a kitiltások feltételeire stb. Az is megfigyelhető, hogy ha egy szomszédos tartományban lévő gép erőforrására fáj a fogam, akkor bizony meg kell adnom egy odaát érvényes név-jelszó párost – vagy akkora mázlim van, hogy odaát véletlenül létezik egy velem azonos nevű és jelszavú felhasználó, s elmaradhat a jelszómegadás. Ha az eredeti igények közül az egyszeres bejelentkezést most is használni óhajtjuk, akkor a két (vagy több) tartományt össze kell kapcsolnunk, a felhasználók számára átjárást kell biztosítanunk. Lényeges eltérés a Windows NT és a Windows 2000 között, hogy míg az előbbinél a rendszergazda maga építi fel a kapcsolatot a tartományok közt, addig a Windows 2000-nél ez automatikusan, a tartomány létrehozásakor megtörténik. A kapcsolatot megbízotti viszonynak nevezzük,

mert ilyenkor az egyik tartomány rendszergazdája megbízza (?), felhatalmazza a másik tartomány felhasználóit a belépésre és erőforrás-felhasználásra. A kapcsolat kiépítése után a felhasználók • szabadon vándorolhatnak, és bármelyik gép elé lehuppanva saját nevükkel és jelszavukkal bejelentkezhetnek (Mohamed megy a hegyhez) • a hálózatban bárhol nekik felkínált erőforrásokat egy helyből, a kényelmes karosszékből ki nem mozdulva használhatják (a hegy megy Mohamedhez) Mindkét esetben a Kihívás/válasz és az azonosítók átadása megfeszítve dolgozik a háttérben. Mégpedig sokat, és a hálózati sávszélességet pusztítva! Mohamed megy a hegyhez A felhasználó őrhelyét elhagyva átballag a szomszéd szobában/épületben/országban/földrészen/bolygón található tartomány egyik gépéhez, leül, és saját eredeti, otthoni nevével és jelszavával bejelentkezik Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás

nélkül szabadon terjeszthető  20002003, NetAcademia Kft 7 NetAcademia-tudástár 2 3 1 4 Trust Európa Antarktisz Jól látható, hogy Sárga Úr hol kíván bejelentkezni (Európa egyik gépén), és hol, melyik tartományvezérlőn található meg (az Antarktiszon). A piros villámlások pedig itt is a hash algoritmus futásának helyét mutatják. Az egyes számmal jelölt nyíl az áttekinthetőség érdekében most két lépést foglal magában: KIHÍVÁS kérést Európától, és a VÁLASZ megadását. A második lépésben Európa tartományvezérlője átküldi az Antarktiszra Sárga Úr nevét, a KIHÍVÁS-t, és a VÁLASZ-t. A harmadik és negyedik lépés az azonosítás visszaérkezésének útvonalát mutatja. Ez még mindig csak duplázott hálózati forgalom. A hegy megy Mohamedhez A felhasználó szokásos íróasztalánál ül, ám a szomszéd szobában/épületben/országban/földrészen/bolygón található tartomány egyik megosztott erőforrását

szeretné használni (CD meghajtó). 1,2,3,4 5. Hoppá! 6 7. Hoppá! 11 10 8 9 Trust Európa Antarktisz Nos, ez itt már a pokol. Lassan jöhet Hádész kutyája, Kerberos, hogy rendet harapjon ebben a dzsungelben. Úgy vélem nem fontos lépésről lépésre végigvezetnem, hogy mi történik ilyenkor. Nem azért nem teszem, mert már magam sem látom át: az ábra hibátlan, akit ennél mélyebben érdekel, nézze meg Network Monitorral az ilyenkor lezajló hálózati forgalmat. Egyébként a nyilak sűrűségének dacára a név és a jelszó csak (CSAK?) háromszor megy át a hálózaton. Most már megfigyelhető, hogy a protokoll működése leginkább a mesebeli kiskakas történetére hasonlít, aki félrenyelt egy bogyócskát, s most innia kellene egy kortyocskát. Elszalad a tehénkéhez, hogy adjon neki tejecskét, de a tehén elküldi őt a rétre füvecskéért, a rét elküldi, hogy hozzon öntözővizet, s szegényt küldik tovább és tovább mindaddig, míg

egyszer csak végre valaki ad neki valami használhatót, s visszarohan az úton amerről jött, torkában a bogyócskával majd meg fullad, és végül mégiscsak kap a tehénkétől egy korty tejecskét. Happy end, a felhasználó már olvassa is a CD-t. Kettőnél több tartomány összekapcsolása Meddig fajul a dolog, ha további tartományokat csatlakoztatunk a hálózathoz? Nos, ennél több azonosító-átadás nem(igen) lesz már, mégpedig azért, mert a Windows NT nem enged ennél többet. A megbízotti viszonyok ezért, az azonosítóátadás körülményessége miatt nem „tranzitívek”, azaz ha Európa kapcsolatra lép Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  20002003, NetAcademia Kft 8 NetAcademia-tudástár Antarktisszal, Antarktisz pedig LegoLanddel ez még nem jelenti azt, hogy Európa kapcsolatban állna LegoLanddel. Külön fel kell építenünk a megbízotti viszonyt Európa és LegoLand között. Ha

pedig tíz tartományunk van, amelyek között teljes körű átjárhatóságot szeretnénk biztosítani, akkor bizony 180 megbízotti viszonyt kell puszta kézzel felépítenünk, és karbantartanunk. Jöhet a Windows 2000? Igen, itt a helye! Ha a Windows NT megbízotti viszonyát manuális, egyirányú, nem tranzitív jelzőkkel írhatjuk le, a Windows 2000 megoldása ennek mindenben ellenkezője: automatikus, kétirányú és tranzitív. A rendszergazda által létrehozandó kapcsolatok száma tíz tartomány esetén 180-ról nullára esik vissza! Hogyan lehetséges mindez? A Kihívás/válasz, és az azonosítók átadása nem modernizálható tovább: a kiskakas-elv helyett valami másra volt szükség: így került a fejlesztők látószögébe a Kerberos, amely jegyeket (ticket) „árul”, s ezzel egy csapásra mintegy 6-8 legyet ütünk. Kerberos A görög mitológiában Kerberosnak hívják Hádész, az alvilág kapuőrzőjének kutyáját. Sajnos a legenda homályába

vész, hogy miért pont erről az állatról nevezték el a szabadszoftver formájában évtizedek óta kerengő, UNIX-okon régóta használatos azonosítási protokollt. A Kerberos ma már RFC-vel rendelkező szabványos technológia, így elvileg semmi akadálya, hogy a Windows 2000 és a sarokban álló UNIX azonosítási szolgáltatását egyesítsük. Gyakorlati akadályok persze lehetnek, eltérhet a Kerberos verziószáma (a Windows 2000 az V-ös verziót használja), eltérő típusú jegyekre lehet szükség stb. A Windows 2000 rendkívül sok, a Windows NT-nek megoldhatatlannak tűnő problémát szüntet meg. Nagyot változott a világ a Windows NT 40 piacra dobása óta Akkoriban még csak nyiladozott az Internet értelme – ma már Internetes kereskedelemről beszélünk. Akkoriban még csak a bennfentesek tudták, mi is az a DNS – ma már a középiskolás diákok is tudják. Akkoriban gyakorlatilag nem létezett chipkártya – hát ez számomra most sem létezik

még, de például minden diák rendelkezik ilyen kártyával, sokan az ösztöndíjukhoz is ezzel jutnak hozzá. Akkoriban nagynak számítottak a néhány száz gépes hálózatok – ma a milliós nagyságrend a divat. Ezen újdonságok mindegyike önmagában is hosszú távon ellehetetleníti a Windows NT 4.0-t De itt a Windows 2000! Ahol a DNS és a Windows tartomány egybe esik. Ahol a tartományokból hierarchiát lehet építeni, amelyek közt automatikusan létre jönnek a kétirányú, tranzitív kapcsolatok, és amelyek belső felépítése is hierarchikus. Itt a chipkártya támogatás, ahol a kis kártya használható bejelentkezésre a CTRL+ALT+DEL helyett, lehetővé téve a vállalatok evilági (pl. ajtónyitogatás) és hálózatos biztonsági rendszereinek az összehangolását. Mindezek alapjául a Kerberos nyújtotta azonosítási szolgáltatást használja a Windows 2000. Emlékszünk még a Kihívás/válasz protokoll kiskakas-elvére? Felejtsük el! A Kerberos

rendszerben a felhasználók a Kerberos kiszolgálótól jegyeket kapnak a többi gép szolgáltatásainak igénybevételére. Nem a kiszolgálók dobálják egymásnak a feladatot, hanem a központtól (tartományvezérlő) kapott megfelelő jegy birtokában egyszerűen besétálunk a moziba. Ha más szolgáltatásra, például foghúzásra is szükségünk van, megint csak a központtól lehet rá jegyet venni. A folyamatban résztvevő gépek optimális száma tehát három: jegykibocsátó, vevő és jegyszedő. Nagyon fontos továbbá, hogy a jegyszedő néni biztosan tudja: a jegy Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  20002003, NetAcademia Kft 9 NetAcademia-tudástár eredeti, nem pedig házilag barkácsolt példány – ezt titkosítással biztosítjuk. Titkosításra eredetileg DES (Digital Encription Standard) algoritmust használtak, de a mai számítógépekkel ez igen könnyen, akár néhány óra leforgása

alatt is feltörhető (jó sok gép kell hozzá), ezért a Kerberos V verzióban már triple-DES van. Nyitott szemmel járva észrevehetjük, hogy a kedves felhasználó a mai modern gépeket nem kapcsolja ki, a nap végén nem jelentkezik ki, mert mindenki azt verte a fejébe, hogy a rendszer stabil, hát ki is használja e stabilitást. Nálunk a Windows NT Workstationok háromhavonta, vagy áramszünet esetén indulnak újra, a felhasználók a munkanap végén maximum zárolják a rendszert, de sohasem jelentkeznek ki. Azaz az Access Token háromhavonta értékelődik ki. Következésképpen a rendszergazda hiába változtatja meg a felhasználók csoporttagságát, nem történik semmi a már megszerzett jogosultságokkal! Windows NT 4.0 esetében jogot elvenni például úgy kell, hogy első lépésben elveszem, majd második lépésben erőszakkal kirúgom a felhasználót. A Kerberos erre is ad megoldást A jegyek, amiket kiad a felhasználóknak csak egy bizonyos ideig -

alapértelmezésben 8 órán keresztül – érvényesek, vagyis szakaszjegyek, a határidő lejárta után új jegyet kell kérni, ami már az új feltételek mentén áll össze, azaz minden nyolcadik órában új Access Token születhet. A Kerberos kiszolgáló több komponensből áll, amelyek általában ugyanazon a gépen futnak. • Key Distribution Center (KDC): a jegyek küldözgetéséhez használt titkosító kulcsok (session key, folyamatkulcs) generálását és karbantartását végzi. • Authentication Service (AS): a felhasználó kezdeti azonosítása a Kerberos színe előtt. Hogyan azonosíthatna minket Kerberos mások számára, ha ő maga nem győződik meg valódiságunkról? Az azonosítás díja egy speciális jegy (Ticket Granting Ticket, TGT), amellyel azután a TGS-től további jegyeket lehet „vásárolni”. • Ticket Granting Service (TGS): jegykiadó automata. Jegyeladás, elővétel, letiltás, szakaszjegy. A kért szolgáltatástípus

használatához bocsát ki jegyeket. A jegy csak a felhasználó azonosítására való, nem pedig jogosultságainak kiértékelésére, mert ahhoz Access Token kell! A Kerberos egyik előnye a sok közül, hogy mivel nem kell a felhasználó azonosítóit átküldözgetni a hálózaton minden egyes újabb szolgáltatás igénybevételekor, sokkal nagyobb biztonságban vannak a felhasználói jelszavak. Míg a Kihívás/válasz minden egyes alkalommal, minden újabb igénybe vett géphez elküldi a nevet és a jelszó(hash)-t, addig a Kerberos kizárólag az eredeti azonosításhoz (Authentication Service) igényli a felhasználó saját jelszavát, később már csak a jegyek jönnek-mennek a hálózaton, véletlenszerűen generált triple-DES kulcsokkal titkosítva. Bejelentkezés A munkaállomáson történő bejelentkezés érdekessége, hogy ebben az esetben a felhasználó a saját gépére kér jegyet, azaz a sajátgép szolgáltatásainak igénybevételéhez is ugyanolyan

módon jut hozzá, mint egy távoli géphez. A tripleDES szimmetrikus titkosítását használva minden titkosított kulcsküldés alapja, hogy már kezdetben is van legalább egy kulcs, amit mindkét fél ismer: ez a felhasználó jelszava. Az ábrán ez a zöld kulcs Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  20002003, NetAcademia Kft 10 NetAcademia-tudástár AD 1. A felhasználó felveszi a kapcsolatot az Authentication Service-szel (AS) Az igény a felhasználó jelszavával van titkosítva, amit az AS kikereshet az Active Directory-ból (AD), hogy hozzáférjen az üzenet tartalmához. Ha az AD-ból elővett jelszó nyitja a titkosított bejelentkezési igényt, akkor a felhasználó az, akinek mondja magát – vagy valaki ellopta a jelszavát, de ez már nem a Kerberos problémája. 2. Az AS szól a KDC-nek, hogy újabb kulcsra (session key) lesz szükség A KDC legenerál egy kulcsot (ez a szürke), amit az ügyfélhez

biztonságosan el kell majd juttatni. Az AS válaszként egy speciális jegyet küld vissza a felhasználónak, amit Ticket Granting Ticketnek (TGT) hívunk, s amely a további jegyek igénylésének jegye. A TGT tartalma: Kedves Sárga Úr! Használja bátran ezt a jegyet és a mellékelt kulcsot további jegyek igénylésére 1999 augusztus 14-én 18 óráig Üdvözlettel: AS A TGT a felhasználó jelszavával van titkosítva, így biztonságban utazhat a hálózaton a benne lévő szürke kulcs (session key), amely a további kommunikáció titkosítására szolgál. Továbbá a TGT belsejében megtalálható a lejárat határideje a Kerberos saját mesterkulcsával titkosítva, azaz határidő módosításra, vagy hasonló csalásra nincs esélyünk. Mostantól a TGT érvényességéig a felhasználó jelszava nem csak jelszavakban, hanem ténylegesen többé nem fog semmilyen formában megjelenni a hálózaton. 3. A felhasználó a TGT-t megőrzi, s ennek birtokában jegyet

kér, és kap a Ticket Granting Service-től (TGS) a saját gépéhez, és mindaddig kérhet vele újabb jegyeket, amíg a TGT érvényessége le nem jár. Mindez persze a felhasználó számára észrevétlenül történik. Kettőnél több gép Ennél csak egy icipicit bonyolultabb, amikor a felhasználó egy szomszédos géphez kér jegyet. A bonyolultságot az okozza, hogy a kommunikáló feleknek hozzá kell jutniuk egy olyan kulcshoz, amit csak ők ketten (meg a KDC, de benne megbízunk) ismernek. Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  20002003, NetAcademia Kft 11 NetAcademia-tudástár AD 2 KDC AS 1 TGS 3 A kiindulási helyzet annyiban más, hogy a felhasználó gépén már ott van a TGT, ezzel együtt pedig a szürke kulcs, amit a további jegyek igénylésekor használnia kell. 1. Sárga Úr igényét a GÉP nevű szomszéd gép használatára közvetlenül a TGS-nek küldi el. Már nem kell az AS-sel

foglalkozni, hiszen az eredeti hitelesítés az előbb megtörtént. Viszont be kell mutatnia TGS-nél a TGT-t, ami a jegyvétel feltétele A TGT-t az eredeti bejelentkezéskor megkapott szürke kulccsal titkosítva juttatja el a TGS-nek. 2. TGS szól KDC-nek, hogy újabb kulcsra lesz szükség a két partner kommunikációjához. Ez lesz a piros kulcs TGS visszaküldi a jegyet Sárga Úrnak, amely ebben az esetben tartalmazza a piros kulcsot is, mégpedig két példányban. Az egyiket Piros Úrnak címezve, a szürke session kulccsal bezárva, a másikat pedig a GÉP-nek címezve, kék kulccsal bezárva, valahogy így: Kedves Sárga Úr! Használja bátran ezt a jegyet és a mellékelt kulcsot a GÉP nevű géphez Kedves GÉP! Használja bátran a mellékelt kulcsot a ha Sárga Úrral kommunikál Üdvözlettel: TGS Üdvözlettel: TGS Megfigyelhető, hogy nem a Kerberos kiszolgáló vacakol a kulcsok megfelelő helyre juttatásával, hanem rábízza ezt az ügyfélgépre. Az

ügyfél nyújtja át a jegyet ellenőrzésre a szomszéd gépen. A két dokumentumrész közül az egyiket tehát – a jobb oldalit – tovább kell küldeni! Meg tudnánk hamisítani továbbküldés előtt? A válasz: nem, mert a kék kulcsról halvány sejtelmünk sincs. Olyannyira, hogy aki idáig – netalán – követte a protokollt, most biztosan elveszítette a fonalat, mert a kék kulcs csak úgy egyszerűen felbukkant. Azt javaslom azon kedves olvasóim számára, akiknek a kék kulcs nem okozott gondot, hogy olvassák el az eddigieket elölről, mert itt bizony logikai bukfenccel állunk szemben. A kék kulcs rejtélye A kék kulcs egy olyan, a Kerberos által előre ismert kulcs, amelyről biztosan tudja, hogy párja megtalálható a GÉP nevű gépen, és csak ott. De ki tette oda? És mikor? A tartományvezérlő, és akkor, amikor a gép csatlakozott a tartományhoz. A kék kulcs Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon

terjeszthető  20002003, NetAcademia Kft 12 NetAcademia-tudástár nem más ugyanis, mint a GÉP számítógépfiókjának (computer account) jelszava! Hisz minden olyan gép, ami a tartomány része, rendelkezik saját fiókkal és jelszóval, és induláskor maga a gép ugyanúgy végigmegy a Kerberos procedúrán, mint Sárga Úr, vagyis a Windows 2000 Professional operációs rendszer jegyet kér a hardverre, hogy ott elindulhasson. Ezzel végigjártuk a Kerberos megértéséhez szükséges utat. Ennél mélyebbre a biztonsággal kapcsolatos tanfolyamokon ásunk. Köszönöm mindazoknak a fáradságos és kitartó munkáját, akik velem együtt végigkövették ezt a néhol bizonyára bonyolult ismertetőt. Remélem, akad olyan olvasóm, aki meglátta menet közben a rizsporos parókás franciák kalaplengetését. Fóti Marcell MCP, MCSE, MCDBA, MCT Ez a dokumentum a NetAcademia Kft. tulajdona Változtatás nélkül szabadon terjeszthető  20002003, NetAcademia Kft

13