FreeBSD kézikönyv
Előző | Fejezet 14. Biztonság | Következő

# 14.8. Kerberos5

Írta: Tillman Hodgson. Eredetileg írta: Mark Murray.

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.

## 14.8.1. A Kerberos története

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.

## 14.8.2. A Heimdal kulcselosztójának telepítése

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.ORG

Vegyü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.ORG

> Itt 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

## 14.8.3. Szerverek kerberizálása a Heimdal használatával

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.

## 14.8.4. Kliensek kerberizálása a Heimdal használatával

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.

## 14.8.5. A felhasználók konfigurációs állományai: a `.k5login` és a `.k5users`

Á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.

## 14.8.6. Tippek, trükkök a Kerberos használatáról és hibaelhárítás

- 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.

## 14.8.7. Eltérések az MIT porttól

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.

## 14.8.8. A Kerberosban talált korlátozások enyhítése

### 14.8.8.1. A Kerberos a “mindent vagy semmit” megközelítést követi

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.

### 14.8.8.2. A Kerberos az egyfelhasználós munkaállomások számára készült

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.

### 14.8.8.3. A kulcselosztó a rendszer legsebezhetőbb pontja

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.

### 14.8.8.4. A Kerberos hiányosságai

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.

## 14.8.9. Erőforrások és további információk

- A Kerberos GYIK (angolul)

- Egy hitelesítési rendszer kidolgozása: párbeszéd négy színben (angolul)

- RFC 1510: A Kerberos hálózati hitelesítési szolgáltatás (V5) (angolul)

- Az MIT Kerberos holnapja (angolul)

- A Heimdal Kerberos honlapja (angolul)

Előző | Tartalom | Következő
KerberosIV | Fel | OpenSSL

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>.