A FreeBSD 5.1 után következő mindegyik FreeBSD kiadás már csak a Kerberos5 támogatást tartalmaz. Ezért bennük csak a Kerberos5 található meg, és a beállítása sok szempontból hasonlít a KerberosIV beállításához. A most következő információk csak és kizárólag a FreeBSD 5.0 kiadás után következőkben található Kerberos5 változatra vonatkoznak. A KerberosIV szolgáltatásait a felhasználók csomagként, a security/krb4 porton keresztül érhetik el.
A Kerberos egy hálózati kiegészítő rendszer/protokoll, amivel a felhasználók egy biztonságos szerveren keresztül képesek magukat azonosítani. A távoli bejelentkezések, távoli másolások, a rendszer belüli védett másolások valamint egyéb nagyon kockázatos feladatok, szolgáltatások biztonsága és felügyelete így jelentős mértékben javítható.
A Kerberos úgy írható le, mint az személyazonosságok ellenőrzésére feljogosított rendszer. Vagy tekinthetjük egy megbízható külső megfigyelő által végzett hitelesítési rendszernek is. A Kerberos csak egyetlen funkciót kínál fel -- ez a felhasználók biztonságos hitelesítése a hálózaton. Viszont nem nyújt semmilyen felhatalmazási (mit csinálhatnak a felhasználók) vagy vizsgálati (mit csináltak végül a felhasználók) lehetőséget. Miután egy kliens és a szerver a Kerberos használatával azonosították egymást, az egymás közt folyó kommunikációjuk titkosításával képesek megőrzi az átáramló adatok sértetlenségét és lehallgathatatlanságát.
Ennek tükrében a Kerberos használata csak más olyan biztonsági módszerekkel együttesen javasolt, amelyek felhatalmazást és vizsgálati szolgáltatásokkal is rendelkeznek.
A most következő utasítások arra igyekeznek útmutatást adni, hogy miként használjuk a FreeBSD-vel együtt terjesztett Kerberos verziót. Azonban a teljes leírást csak a témához tartozó man oldalak átolvasásával együtt kapjuk meg.
A Kerberos telepítésének bemutatásához az alábbi névtereket fogjuk használni:
A DNS tartomány (“zóna”) az example.org lesz.
A Kerberos övezet az EXAMPLE.ORG lesz.
Megjegyzés: Kérjük, hogy még abban az esetben is valódi tartományneveket adjuk meg, amikor a Kerberos használatát csak a belső hálózaton tervezzük. Ezzel elkerülhetjük az egyes Kerberos övezetek együttműködése során felmerülő DNS problémákat.
A Kerberost az MIT hozta létre a hálózati biztonsággal kapcsolatos problémák egyik megoldásaként. A Kerberos erős titkosítást használ, ezért a kliensek képesek egy nem biztonságos hálózaton is azonosítani magukat a szerver felé (és fordítva).
A Kerberos egyaránt utal egy hálózati protokoll nevére és azokra programokra, amelyek implementálják (például Kerberos telnet). Az 5 a protokoll jelenlegi verziója, amit az RFC 1510 ír le.
A protokollnak számos szabad változata létezik, rengeteg típusú operációs rendszerre. A Massachusettsi Műszaki Intézet (Massachusetts Institute of Technology, MIT), ahol a Kerberost eredetileg kifejlesztették, napjainkban is folytatja a saját Kerberos csomagjának fejlesztését. Többnyire az Egyesült Államokban használják titkosításra, mivel régebben az amerikai kiviteli korlátozások voltak rá érvényesek. Az MIT Kerberos változata portként érhető el (security/krb5). A Heimdal Kerberos egy másik 5 verziójú implementáció, amit a kiviteli korlátozások elkerülése érdekében határozottan az Egyesült Államokon kívül fejlesztettek ki (ezért gyakran megtalálhatjuk a különböző nem kereskedelmi UNIX® variánsokban). A Heimdal Kerberos terjesztés portként elérhető (security/heimdal) és kisebb méretben a FreeBSD alaptelepítésének is része.
Mivel ezzel az írással a legtöbb felhasználót kívánjuk segíteni, ezért a következő utasítások a FreeBSD telepítésében mellékelt Heimdal terjesztés használatát feltételezik.
A kulcselosztó központ (Key Distribution Center, avagy KDC) az a centralizált hitelesítési szolgáltatás, amit a Kerberos nyújt -- lényegében az a számítógép, amely Kerberos-jegyeket bocsájt ki. A KDC “megbízhatónak” tekinthető a Kerberos által kialakított övezetben levő többi számítógép számára, ezért védelme kiemelten fontos.
Itt jegyeznénk meg, hogy habár a Kerberos szerver futtatása nagyon kevés számítógépes erőforrást igényel, ennek ellenére biztonsági szempontból egy külön számítógépet javasoljunk a kulcselosztó szerepének betöltéséhez.
Mielőtt nekifognánk a KDC konfigurálásának, ellenőrizzük, hogy az /etc/rc.conf tartalmazza a KDC működéséhez szükséges beállításokat (az elérési utakat természetesen a saját rendszerünk szerint állítsuk be):
kerberos5_server_enable="YES" kadmind5_server_enable="YES"
A következő lépésben vegyük szemügyre a Kerberos beállításait tartalmazó /etc/krb5.conf állományt:
[libdefaults]
default_realm = EXAMPLE.ORG
[realms]
EXAMPLE.ORG = {
kdc = kerberos.example.org
admin_server = kerberos.example.org
}
[domain_realm]
.example.org = EXAMPLE.ORGVegyük észre, hogy az itt szereplő /etc/krb5.conf állomány szerint a kulcselosztónk teljes hálózati neve kerberos.example.org. Ha a kulcselosztónknak nem ez a neve, akkor a zónákat leíró állományba vegyünk még fel egy ilyen CNAME (álnév) bejegyzést.
Megjegyzés: Ha egy nagyobb hálózatban vagyunk, ahol a DNS szervert is megfelelően beállították, akkor az iménti példa ennyire leszűkíthető:
[libdefaults] default_realm = EXAMPLE.ORGItt már a következő sorokat hozzáadták example.org zónát leíró állományhoz:
_kerberos._udp IN SRV 01 00 88 kerberos.example.org. _kerberos._tcp IN SRV 01 00 88 kerberos.example.org. _kpasswd._udp IN SRV 01 00 464 kerberos.example.org. _kerberos-adm._tcp IN SRV 01 00 749 kerberos.example.org. _kerberos IN TXT EXAMPLE.ORG
Megjegyzés: A kliensek csak akkor lesznek képesek elérni a Kerberos szolgáltatásait, ha vagy kötelező jelleggel megadunk egy teljesen beállított /etc/krb5.conf állományt, vagy egy minimális /etc/krb5.conf állományt és egy helyesen beállított DNS szervert használunk.
Ezután létrehozzuk a Kerberos adatbázisát. Ez az adatbázis tartalmazza az összes szereplő kulcsát a mesterkulcssal titkosítva. Erre a jelszóra nem kell feltétlenül emlékeznünk, mivel ez egy állományban tárolódik (/var/heimdal/m-key). A mesterkulcsot a kstash parancs kiadásával és egy jelszó megadásával tudjuk létrehozni.
Ahogy a mesterkulcs elkészült, a kadmin parancs -l (mint “lokális”, azaz helyi) opciójával inicializálni tudjuk az adatbázist. Ez az opció arra utasítja a kadmin programot, hogy ne a kadmind hálózati szolgáltatást használja, hanem közvetlenül az adatbázis állományait módosítsa. Ezzel oldható meg az adatbázis kezdeti létrehozásának problémája. Miután megkaptuk a kadmin parancssorát, az övezetünkhöz tartozó adatbázis inicializálásához adjuk ki az init parancsot.
Végül, még mindig a kadmin parancssorát használva, az add paranccsal hozzuk létre az első szereplőnket. Egyelőre érjük be az alapértelmezett értékekkel, a modify paranccsal később úgyis meg tudjuk változtatni ezeket. Hozzátesszük, hogy itt a ? parancs segítségével bármikor lekérhetjük az opciók ismertetését.
Példa egy adatbázis létrehozására:
# kstash Master key: xxxxxxxx Verifying password - Master key: xxxxxxxx # kadmin -l kadmin> init EXAMPLE.ORG Realm max ticket life [unlimited]: kadmin> add tillman Max ticket life [unlimited]: Max renewable life [unlimited]: Attributes []: Password: xxxxxxxx Verifying password - Password: xxxxxxxx
Most már ideje elindítani a KDC szolgáltatásait. Ezeket az /etc/rc.d/kerberos start és /etc/rc.d/kadmind start parancsok kiadásával tudjuk felhozni. Megjegyezzük, hogy most még semmilyen kerberizált démont nem kell elindítanunk. Ellenben igyekezzünk ellenőrizni a KDC működőképességét azzal, hogy KDC parancssorából kérünk egy jegyet a frissen hozzáadott szereplőnknek (felhasználónknak) és kilistázzuk:
% kinit tillman tillman@EXAMPLE.ORG's Password: % klist Credentials cache: FILE:/tmp/krb5cc_500 Principal: tillman@EXAMPLE.ORG Issued Expires Principal Aug 27 15:37:58 Aug 28 01:37:58 krbtgt/EXAMPLE.ORG@EXAMPLE.ORG
Miután végeztünk, nyugodtan törölhetjük a jegyet:
% kdestroy
Ehhez először is szükségünk lesz a Kerberos konfigurációs állományának, az /etc/krb5.conf másolatára. Ezt úgy tudjuk megtenni, ha egyszerűen átmásoljuk a kulcselosztóról az egyik kliensre valamilyen megbízható módon (vagy az scp(1) programhoz hasonló hálózati segédprogramok, vagy például fizikailag egy floppy lemez használatával).
Ezután szükségünk lesz egy /etc/krb5.keytab nevű állományra. Ez az alapvető különbség a kerberizált démonokat felkínáló szerver és egy munkaállomás közt -- a szervernek rendelkeznie kell egy keytab állománnyal. Ez az állomány tartalmazza a szerver kulcsát, amivel így a kulcselosztóval kölcsönösen azonosítani tudják egymást. Ezt a szerverre biztonságosan kell eljuttatnunk, mivel ennek napvilágra kerülésével a szerver védelme komoly veszélybe kerül. Tehát, ha egy titkosítás nélküli csatornán, például FTP-n keresztül visszük át, akkor kifejezetten rossz ötlet.
A szerverre általában a kadmin program használatával érdemes átvinni a keytab állományt. Ez azért is hasznos, mert ehhez a kadmin segítségével létre kell hoznunk a befogadó szereplőt is (a kulcselosztó a krb5.keytab állomány végén).
Vegyük észre, hogy már kaptunk egy jegyet és ezzel a jeggyel jogosultaknak kell lennünk a kadmind.acl állomány kadmin felület használatára. A hozzáférést vezérlő listák (ACL-ek) tervezésével kapcsolatban olvassuk el Heimdal info oldalán található “Remote administration” című szakaszt (info heimdal). Amennyiben nem kívánjuk engedélyezni a kadmin távoli elérését, egyszerűen csak csatlakozzunk valamilyen biztonságos módon (helyi konzolon, ssh(1) vagy egy kerberizált telnet(1) használatával) a kulcselosztóhoz, és a kadmin -l paranccsal végezzük el helyben az adminisztrációt.
Miután telepítettük az /etc/krb5.conf állományt, a Kerberos szerverről el tudjuk érni a kadmin felületét. Az add --random-key paranccsal most már hozzáadhatjuk a szerver befogadó szereplőjét és az ext paranccsal ki tudjuk vonni a szerver befogadó szereplőjét a saját keytab állományából. Például:
# kadmin kadmin> add --random-key host/myserver.example.org Max ticket life [unlimited]: Max renewable life [unlimited]: Attributes []: kadmin> ext host/myserver.example.org kadmin> exit
Itt jegyeznénk meg, hogy az ext parancs (az “extract” rövdítése) a kivont kulcsot alapértelmezés szerint az /etc/krb5.keytab állományba menti ki.
Ha a kulcselosztón nem fut a kadmind szolgáltatás (valószínűleg biztonsági okokból) és ezért távolról nem tudjuk elérni a kadmin felületét, akkor így tudjuk közvetlenül hozzáadni a befogadó szereplőt (host/myserver.EXAMPLE.ORG), majd kivonatolni azt egy ideiglenes állományba (elkerülve az /etc/krb5.keytab felülírását):
# kadmin kadmin> ext --keytab=/tmp/example.keytab host/myserver.example.org kadmin> exit
Ezután valamilyen biztonságos eszközzel (például scp vagy floppy használatával) át tudjuk másolni keytab állományt a szerverre. A kulcselosztón levő keytab felülírását elkerülendő, ne feledkezzünk el egy megfelelő név megadásáról sem.
Ezen a ponton már a szerver képes felvenni a kapcsolatot a kulcselosztóval (a krb5.conf állomány miatt) és bizonyítani a személyazonosságát (a krb5.keytab állomány miatt). Így tehát készen állunk a szolgáltatások kerberizálására. Ebben a példában most a telnet szolgáltatást vesszük célba úgy, hogy először az /etc/inetd.conf állományba berakjuk az alábbi sort, majd újraindítjuk az inetd(8) szolgáltatást az /etc/rc.d/inetd restart paranccsal:
telnet stream tcp nowait root /usr/libexec/telnetd telnetd -a user
Itt az a legfontosabb, hogy az -a (mint authentication, azaz hitelesítés) paramétert a “user” beállítással adjuk meg. A telnetd(8) man oldalán olvashatunk ennek pontos részleteiről.
A kliensek beállítása szinte majdnem gyerekjáték. A Kerberos beállításához egyedül az /etc/krb5.conf állományra lesz szükségünk. Valamilyen biztonságos eszközzel másoljuk át a kulcselosztóról a kliensre.
Úgy tudjuk letesztelni klienst, ha megpróbáljuk róla kiadni a kinit, klist és kdestroy parancsokat a fentebb létrehozott szereplő jegyének megszerzéséhez, lekérdezéséhez és megsemmisítéséhez. A Kerberos használatával megpróbálkozhatunk csatlakozni valamelyik kerberizált szerverre is, ha viszont ez nem működik még egy jegy megszerzése után sem, akkor a gond többnyire a szerverrel van, nem pedig a klienssel vagy a kulcselosztóval.
Amikor egy telnet vagy egy hozzá
hasonló alkalmazást tesztelünk, egy
csomaglehallgató (mint amilyen például a
tcpdump(1)) elindításával
győzödjünk meg róla, hogy a jelszavak
ilyenkor titkosítva mennek át.
Próbáljuk meg titkosítani a teljes
kommunikációt a telnet
-x paraméterével
(hasonlóan az ssh parancshoz).
Alapból még számos más kiegészítő Kerberos kliensalkalmazás is telepítődik. Ezeken érezhető meg valójában az alaprendszerhez tartozó Heimdal változat “minimalitása”: ebben a telnet az egyedüli kerberizált szolgáltatás.
A Heimdal port igyekszik pótolni a hiányzó klienseket a kerberizált ftp, rsh, rcp, rlogin és néhány kevéséb ismert program telepítésével. Az MIT változat portja szintén tartalmazza a Kerberos kliensek teljes kelléktárát.
Általában az övezetben található felhasználók mindegyikéhez tartozik egy Kerberos-szereplő (mint például a tillman@EXAMPLE.ORG), ami a felhasználó helyi hozzáférésére mutat (mint például a tillman nevű helyi hozzáférés). A telnet és a hozzá hasonló kliensalkalmazások általában nem igényelnek felhasználót vagy szereplőt.
Előfordulhat azonban, hogy valaki olyan szeretné elérni egy helyi felhasználó hozzáférését, aki nem rendelkezik a hozzátartozó Kerberos-szereplővel. Például a tillman@EXAMPLE.ORG nevű felhasználó el szeretné érni a helyi számítógépen levő webdevelopers hozzáférést. Más szereplők is elérhetik a helyi hozzáféréseket.
A probléma megoldásához a felhasználók könyvtárában található .k5login és a .k5users állományok használhatóak a .host és .rhosts állományok kombinációjához hasonlóan. Például a .k5login így néz ki:
tillman@example.org jdoe@example.org
Ezt a webdevelopers nevű helyi felhasználó könyvtárában kell elhelyeznünk, így a felsorolt szereplőt megosztott jelszó használata nélkül képesek elérni a hozzáférést.
Az említett parancsok man oldalának elolvasása ajánlott. Megjegyezzük, hogy a ksu man oldal foglalkozik a .k5users állománnyal.
Akár a Kerberos Heimdal vagy az MIT változatát használjuk, ne felejtsük úgy beállítani a PATH környezeti változóban felsorolt elérési utakat, hogy a kliensalkalmazások kerberizált változatai a rendszerben használatos verziók elé kerüljenek.
Az övezetben minden számítógép órája ugyanúgy jár? Ha nem, akkor a hitelesítés csődöt mondhat. A 29.10 Szakaszból tudhatjuk meg hogyan szinkronizáljunk órákat az NTP segítségével.
Az MIT és a Heimdal verziók a kadmin kivételével remekül megvannak egymással, mivel az általa használt protokollt még nem szabványosították.
Ha megváltoztatjuk a gépünk hálózati nevét, akkor a ugyanígy a host/ szereplőnket is meg kell változtatni és frissíteni a keytab állományunkat. Ez olyan speciális keytab bejegyzésekre is vonatkozik, mint például az Apache www/mod_auth_kerb moduljához tartozó www/ szereplő.
Az övezetünkben levő összes számítógépnek (mind a két irányba) feloldható DNS névvel kell rendelkeznie (vagy legalább egy /etc/hosts állománnyal). Erre a CNAME rekord megfelelő, de az A és PTR rekordoknak mindenképpen rendben kell lenniük. Az ilyenkor keletkező hibaüzenet nem éppen fogja meg a lényeget: “Kerberos5 refuses authentication because Read req failed: Key table entry not found”.
A kulcselosztó számára kliensként viselkedő bizonyos operációs rendszerek nem állítják be megfelelően a ksu engedélyeit, ezért nem lehet root jogokkal futtatni. Ezért a ksu parancs nem fog működni, ami alapvetően nem egy rossz ötlet, de idegesítő. Ez nem a kulcselosztó hibája.
Ha a Kerberos
MIT változatát
használjuk és a meg akarjuk
hosszabbítani a szereplőknek kiadott jegyek
élettartamát az alapértelmezett
tíz óráról, akkor a
kadmin felületén a
modify_principal paranccsal tudjuk
megváltoztatni mind a kérdéses
szereplő, mind pedig a krbtgt
jegyeinek élettartamának maximumát.
Ezt követően a szereplő a
kinit -l
opciójával tud egy nagyobb
élettartammal rendelkező jegyet
kérni.
Megjegyzés: Amikor egy kulcselosztóval kapcsolatos hibát próbálunk felderíteni a csomagok lehallgatásával, és a munkaállomásunkról kiadjuk a kinit parancsot, akkor arra lehetünk figyelmesek, hogy a TGT már egyből a kinit indításakor átküldésre kerül -- még mielőtt egyáltalán megadtuk volna a jelszavunkat! Ezt azzal lehet magyarázni, hogy a Kerberos szerver bármilyen hitelesítetlen kérésre elküld egy TGT-t (Jegyadó jegy, azaz Ticket Granting Ticket). Azonban mindegyik ilyen TGT a felhasználó jelszavából származtatott kulccsal titkosítódik. Ezért amit a felhasználó jelszóként megad, nem megy el a kulcselosztónak, hanem vele a kinit a már megkapott TGT-t kódolja ki. Amennyiben a visszakódolás egy érvényes időbélyeggel rendelkező, használható jegyet eredményez, akkor a felhasználó érvényes Kerberos hitelesítést szerez. Ez a hitelesítés magában foglal egy kulcsot, amellyel a későbbiekben a Kerberos szerverekkel tudjuk felvenni biztonságos módon a kapcsolatot, és rajta kívül egy újabb jegyadó jegyet, amelyet a Kerberos szerver a saját kulcsával titkosított. A titkosítás második vonala a felhasználó számára ismeretlen, de segítségével a Kerberos szerer képes ellenőrizni az egyes jegyadó jegyek hitelességét.
Ha a jegyeket hosszabb (például egyhetes)
élettartammal akarjuk használni és a
jegyeket tároló géphez
OpenSSH
segítségével csatlakozunk, akkor
mindenképpen ellenőrizzük, hogy az
sshd_config állományban a
Kerberos
TicketCleanup
beállításának
értéke no,
máskülönben a kijelentkezés
után automatikusan törlődnek a
jegyeink.
Ne hagyjuk figyelmen kívül azt sem, hogy a befogadó szereplők is rendelkezhetnek nagyobb élettartamú jegyekkel. Ha a felhasználónkhoz tartozó szereplő jegye például egy hét alatt évül el, de a számítógép, amire bejelentkezük, csupán kilenc óráig tartja életben ezeket, akkor a jegyeket tároló gyorsítótárunkban hamarabb elévül a hozzátartozó jegy, ami miatt pedig hibák keletkeznek.
Ha a rossz jelszavak használata ellen beállítjuk a krb5.dic állományt (erről a kadmind man oldalán találunk egy rövid leírást), akkor nem szabad elfelejteni, hogy ez csak olyan szereplőkre vonatkozik, akiknek a jelszavára is állítottunk be szabályozásokat. A krb5.dict állományok felépítési nem bonyolult: minden sorban egyetlen karakterlánc szerepel. Érdemes lehet például létrehozni ezen a néven egy szimbolikus linket a /usr/share/dict/words állományra.
A Heimdal és az MIT változatok közti egyik legnagyobb eltérés a kadmin programmal kapcsolatban van, ami eltérő (de egyébként ekivalens) parancskészlettel rendelkezik és más protokollt használ. Ennek komoly következménye, hogy ha az MIT-féle kulcselosztót használjuk, akkor azt a Heimdal kadmin felületével nem tudjuk távolról adminisztrálni (és vica versa).
A kliensalkalmazások paraméterezése is eltérhet ugyanazon feladatoknál. Ezért velük kapcsolatban az MIT Kerberos honlapja (http://web.mit.edu/Kerberos/www/) a mérvadó. Vigyázzunk az elérési utakkal: az MIT port magát alapértelmezés szerint a /usr/local könyvtárba telepíti, ezért az általuk kiváltani kívánt “normális” rendszerprogramokat esetleg hamarabb találja meg a rendszer, ha nem jól állítottuk be a PATH környezeti változónkat.
Megjegyzés: Ha nem értjük, hogy miért működnek olyan furcsán a telnetd és a klogind által kezelt bejelentkezések, akkor olvassuk el a FreeBSD security/krb5 portjával települő MIT változat /usr/local/share/doc/krb5/README.FreeBSD állományt (angolul). Az a legfontosabb, hogy a “incorrect permissions on cache file” hiba eltüntetéséhez a login.krb5 binárist kell használnunk, így a továbbított jogosultságoknak megfelelően át tudja állítani a tulajdonost.
Az rc.conf állományt is módosítani kell a következő beállítás kialakításához:
kerberos5_server="/usr/local/sbin/krb5kdc" kadmind5_server="/usr/local/sbin/kadmind" kerberos5_server_enable="YES" kadmind5_server_enable="YES"
Erre azért van szükség, mert a Kerberos MIT változata a /usr/local könyvtáron belülre telepíti fel a hozzátartozó alkalmazásokat.
A hálózaton minden szolgáltatást módosítanunk kell ahhoz, hogy együtt tudjanak működni a Kerberosszal (vagy valamilyen más módon védenünk kell ezeket a támadások ellen), különben a felhasználók jogait el lehet lopni vagy újra fel lehet használni. Erre jó példa lehet az összes távoli parancssoros elérés (például az rsh valamint a telnet) kerberizálása, de a jelszavakat titkosítatlanul küldő POP3 levelező szerver kihagyása.
Többfelhasználós környezetben a Kerberos már nem annyira biztonságos. Ez azért mondható el, mert a jegyeket a mindenki által olvasható /tmp könyvtárban tárolja. Ha az adott felhasználó számítógépét egyszerre több emberrel is megosztja (tehát többfelhasználós), akkor a felhasználó jegyeit egy másik felhasználó bármikor lemásolhatja (ellophatja).
Ezt a -c opció után
megadott állománynévvel vagy
(inkább) a KRB5CCNAME környezeti
változó megfelelő
beállításával tudjuk
áthidalni, habár ezt ritkán teszik is
meg. Ha a felhasználók
könyvtárában és a megfelelő
engedélyekkel tároljuk ezeket a jegyeket, akkor
némileg visszaszoríthatjuk a probléma
kockázatát.
A rendszer kialakításából fakadóan a kulcselosztónak legalább annyira megbízhatónak kell lennie, mint a rajta levő központi jelszóadatbázisnak. A kulcselosztón semmilyen más szolgáltatás nem futhat és fizikailag is biztonságba kell helyezni. A kockázat nagy, mivel a Kerberos az összes jelszót ugyanazzal a kulcssal (a “mesterkulcssal”) titkosítja, amelyet a kulcselosztó egy állományban tárol.
Széljegyzet gyanánt hozzátesszük, hogy a mesterkulcs elvesztése nem annyira rossz, mint azt első gondolnánk. A mesterkulcsot csupán a véletlenszám-generátor inicializálásához használják a Kerberos adatbázisának titkosításakor. Amíg a kulcselosztóhoz nem tudnak illetéktelenek hozzáférni, addig nem tudnak sokat kezdeni a mesterkulccsal.
Mellesleg ha a kulcselosztó nem elérhető (talán pontosan egy DoS támadás vagy éppen hálózati problémák miatt), akkor a hitelesítés nem végezhető el, mivel így a hozzá szükséges hálózati szolgáltatások sem használhatóak. Ez remek eszköz egy DoS támadáshoz. Ezen több (egy központi és egy vagy több alárendelt) kulcselosztó telepítésével, valamint a másodlagos vagy tartalékként használt hitelesítési eszközök (a PAM erre tökéletes) körültekintő megvalósításával enyhíthetünk.
A Kerberos révén a felhasználók, számítógépek és szolgáltatások tudják egymást hitelesíteni. Ellenben semmilyen eszközt nem kínál fel a kulcselosztó hitelességének ellenőrzésére. Így tehát (például) egy eltérített kinit képes ellopni az összes felhasználói nevet és jelszót. Az ilyen incidensek elkerülésére a security/tripwire és a hozzá hasonló segédprogramok segítségével lehet megőrizni a rendszer sértelenségét.
Ha kérdése van a FreeBSD-vel kapcsolatban, a következő
címre írhat (angolul): <freebsd-questions@FreeBSD.org>.
Ha ezzel a dokumentummal kapcsolatban van kérdése,
kérjük erre a címre írjon: <gabor@FreeBSD.org>.