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

# 14.7. KerberosIV

Írta: Mark Murray. Eredetileg írta: Mark Dapoz.

A Kerberos egy olyan járulékos rendszer/protokoll, amellyel a felhasználók egy biztonságos szerver szolgáltatásain keresztül tudják hitelesíteni magukat. Ilyen szolgáltatás többek közt a távoli bejelentkezés, távoli másolás, a rendszeren belüli biztonságos másolás és minden olyan egyéb veszélyes feladat, amit számottevően megbízhatóbbá és irányíthatóbbá tettek.

A következő utasítások a FreeBSD-hez mellékelt Kerberos beállításához adnak útmutatást. A teljes leíráshoz azonban érdemes fellapoznunk a menet közben hivatkozott man oldalakat is.

## 14.7.1. A KerberosIV telepítése

A Kerberos a FreeBSD egyik választható komponense. Legkönnyebben úgy tudjuk feltelepíteni, ha a FreeBSD telepítése során a sysinstall programban kiválasztjuk a `krb4` vagy `krb5` terjesztések valamelyikét. Ezzel felrakhatjuk a Kerberos “eBones” (KerberosIV) vagy “Heimdal” (Kerberos5) elnevezésű változatait. A FreeBSD azért tartalmazza ezeket az implementációkat, mert nem az Amerikai Egyesült Államokban vagy Kanadában fejlesztették, így az Egyesült Államok titkosításokkal kapcsolatos kiviteli korlátozások korában minden olyan rendszer adminisztrátora el tudta érni, aki nem ezekben az országokban lakott.

A Kerberos MIT által fejlesztett implementációját egyébként a Portgyűjteményből a `security/krb5` porton keresztül érhetjük el.

## 14.7.2. A kezdeti adatbázis létrehozása

Ezt a lépést csak a Kerberos szerveren kell elvégezni. Először is győződjünk meg róla, hogy semmilyen korábbi Kerberos adatbázis nem található a gépen. Váltsunk az `/etc/kerberosIV` könyvtárra és ellenőrizzük a következő állományok meglétét:

    # cd /etc/kerberosIV
    # ls
    README		krb.conf        krb.realms

Ha rajtuk kívül további állományok is feltűnnének (mint például a `principal.*` vagy `master_key`), akkor a `kdb_destroy` paranccsal pusztítsuk el a régi Kerberos adatbázist, vagy ha nem fut már a Kerberos, akkor egyszerűen csak törüljük le ezeket.

Ezután lássunk neki a `krb.conf` és `krb.realms` állományok átírásán keresztül a Kerberos egyes övezeteinek (realm) létrehozásához. Itt most az `EXAMPLE.COM` lesz a létrehozandó övezet, a hozzátartozó szerver pedig a `grunt.example.com`. Így szerkesszük át vagy készítsünk el a neki megfelelő `krb.conf` állományt:

    # cat krb.conf
    EXAMPLE.COM
    EXAMPLE.COM grunt.example.com admin server
    CS.BERKELEY.EDU okeeffe.berkeley.edu
    ATHENA.MIT.EDU kerberos.mit.edu
    ATHENA.MIT.EDU kerberos-1.mit.edu
    ATHENA.MIT.EDU kerberos-2.mit.edu
    ATHENA.MIT.EDU kerberos-3.mit.edu
    LCS.MIT.EDU kerberos.lcs.mit.edu
    TELECOM.MIT.EDU bitsy.mit.edu
    ARC.NASA.GOV trident.arc.nasa.gov

A többi övezetnek valójában nem feltétlenül kell itt lennie. Ezek csupán azért szerepelnek itt, hogy bemutassák miként lehet egyetlen géphez hozzárendelni egyszerre több övezetet is. Az egyszerűség kedvéért nyugodtan elhagyhatóak.

Az első sor nevezi meg a rendszer által működtetett övezeteket. Az utána következő sorokban övezeteket és hálózati neveket láthatunk. Itt az első elem egy övezetet nevez meg, a második elem pedig az övezet “kulcselosztó központját” (key distribution center). A hálózati nevet követő `admin server` kulcsszavak arra utalnak, hogy az adott gép adminisztratív szerepet ellátó adatbázist is tartalmaz. Ezeket a fogalmakat részleteiben a Kerberos man oldalain ismerhetjük meg.

Ezután hozzá kell adnunk a `grunt.example.com` nevű gépet az `EXAMPLE.COM` övezethez, valamint az `.example.com` tartományban levő összes géphez létre kell hoznunk egy bejegyzést az `EXAMPLE.COM` övezetben. A `krb.realms` állományt ehhez a következőképpen kellene módosítanunk:

    # cat krb.realms
    grunt.example.com EXAMPLE.COM
    .example.com EXAMPLE.COM
    .berkeley.edu CS.BERKELEY.EDU
    .MIT.EDU ATHENA.MIT.EDU
    .mit.edu ATHENA.MIT.EDU

Ismét hozzátesszük, hogy a többi övezetnek nem kötelező itt szerepelnie. Ezek csupán azt demonstrálják, hogy miként kell egy gépet egyszerre több övezethez is beállítani. Az átláthatóság kedvéért minden további nélkül eltávolíthatjuk ezeket.

Itt az első sor az adott rendszert elhelyezi egy nevesített övezetbe. A többi sor azt mutatja meg, hogyan kell alapértelmezett módon a meghatározott altartományokba tartozó gépeket egy nevesített övezethez hozzárendelni.

Most már készen állunk az adatbázis létrehozására. Ehhez egyedül a Kerberos szerverét (avagy Kulcselosztó központját) kell elindítanunk. Adjuk ki a `kdb_init` parancsot:

    # kdb_init
    Realm name [default  ATHENA.MIT.EDU ]: EXAMPLE.COM
    You will be prompted for the database Master Password.
    It is important that you NOT FORGET this password.

    Enter Kerberos master key:

Az üzenet fordítása:

    Most az adatbázis mesterkulcsát kell megadni.  Fontos, hogy
    NE FELEJTSÜK EL ezt a jelszót.

Most el kell mentenünk a kulcsot, így a helyi gépen futó szerverek fel tudják szedni. Ehhez a `kstash` parancsra van szükségünk:

    # kstash

    Enter Kerberos master key:

    Current Kerberos master key version is 1.

    Master key entered. BEWARE!

Az üzenet fordítása:

    A Kerberos mesterkulcsának jelenlegi változata: 1.

    VIGYÁZAT, megadták a mesterkulcsot!

Ez elmenti a titkosított mesterkulcsot az `/etc/kerberosIV/master_key` állományba.

## 14.7.3. Az egész beüzemelése

Mindegyik Kerberosszal őrzött rendszerrel kapcsolatban két ún. szereplőt (principal) kell még hozzátennünk az adatbázishoz. A nevük `kpasswd` és `rcmd`. Minden rendszerhez létre kell hoznunk ezeket a szereplőket, példányonként (instance) az egyes rendszerek neveivel.

A kpasswd és rcmd démonok teszik lehetővé a többi rendszer számára, hogy megváltoztathassák a Kerberos jelszavukat, valamint hogy futtathassák az rcp(1), rlogin(1) és rsh(1) parancsokat.

Vegyük fel ezeket a bejegyzéseket is:

    # kdb_edit
    Opening database...

    Enter Kerberos master key:

    Current Kerberos master key version is 1.

    Master key entered.  BEWARE!
    Previous or default values are in [brackets] ,
    enter return to leave the same, or new value.

    Principal name: passwd
    Instance: grunt

    <Not found>, Create [y] ? y

    Principal: passwd, Instance: grunt, kdc_key_ver: 1
    New Password:                    <---- írjuk be, hogy “RANDOM”
    Verifying password

    New Password: <---- írjuk be, hogy “RANDOM”

    Random password [y] ? y

    Principal's new key version = 1
    Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?
    Max ticket lifetime (*5 minutes) [ 255 ] ?
    Attributes [ 0 ] ?
    Edit O.K.
    Principal name: rcmd
    Instance: grunt

    <Not found>, Create [y] ?

    Principal: rcmd, Instance: grunt, kdc_key_ver: 1
    New Password:		<---- írjuk be, hogy “RANDOM”
    Verifying password

    New Password:           <---- írjuk be, hogy “RANDOM”

    Random password [y] ?

    Principal's new key version = 1
    Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?
    Max ticket lifetime (*5 minutes) [ 255 ] ?
    Attributes [ 0 ] ?
    Edit O.K.
    Principal name:         <---- ha nem adunk meg semmit, akkor kilép

## 14.7.4. A szerver állomány létrehozása

Most pedig kivonatolni kell azokat a példányokat, amelyek szolgáltatást definiálnak a gépen. Erre az `ext_srvtab` parancsot használjuk. Ennek eredményeképpen keletkezik egy állományt, amelyet biztonságos eszközökkel át kell másolni vagy át kell mozgatni az egyes Kerberos kliensek `/etc` könyvtárába. Ennek az állománynak egyaránt jelent kell lennie a szerveren és a kliensen is, nélküle a Kerberos működésképtelen.

    # ext_srvtab grunt
    Enter Kerberos master key:

    Current Kerberos master key version is 1.

    Master key entered. BEWARE!
    Generating 'grunt-new-srvtab'....

Ez a parancs most létrehozott egy ideiglenes állományt, amit át kell nevezni az `srvtab` névre, hogy megtalálhassák a szerverek. Az eredeti rendszeren a mv(1) paranccsal tudjuk a helyére rakni:

    # mv grunt-new-srvtab srvtab

Ha egy kliensnek szánjuk az állományt és a hálozatunkat nem tekinthetjük biztonságosnak, akkor a ``kliens`-new-srvtab` állományt másoljuk egy mozgatható adathordozóra és megbízható módon jutassuk el. Ne felejtsük el az állományt `srvtab` néven átrakni a kliens `/etc` könyvtárába és az engedélyeit 600-ra állítani:

    # mv grumble-new-srvtab srvtab
    # chmod 600 srvtab

## 14.7.5. Az adatbázis feltöltése

Ezt követően rögzítenünk kell néhány felhasználót is adatbázisban. Először is hozzunk létre egy bejegyzést a `janos` nevű felhasználónak. Ezt a `kdb_edit` parancs kiadásával tesszük meg:

    # kdb_edit
    Opening database...

    Enter Kerberos master key:

    Current Kerberos master key version is 1.

    Master key entered.  BEWARE!
    Previous or default values are in [brackets] ,
    enter return to leave the same, or new value.

    Principal name: janos
    Instance:

    <Not found>, Create [y] ? y

    Principal: janos, Instance: , kdc_key_ver: 1
    New Password:                <---- adjunk meg egy biztonságos jelszót
    Verifying password

    New Password:                <---- itt ismét adjuk meg a jelszót
    Principal's new key version = 1
    Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?
    Max ticket lifetime (*5 minutes) [ 255 ] ?
    Attributes [ 0 ] ?
    Edit O.K.
    Principal name:		   <---- ha nem írunk be semmit, akkor kilép

## 14.7.6. Próbáljuk ki

Elsőként a Kerberos démonait kell beindítanunk. Ezzel kapcsolatban megjegyeznénk, hogy ha ehhez megfelelően átírtuk az `/etc/rc.conf` állományunkat, akkor ez az újraindítással együtt magától lezajlik. Ezt csak a Kerberos szerveren kell megcsinálni. A Kerberos kliensei maguktól összeszedik a működésükhöz szükséges adatokat az `/etc/kerberosIV` könyvtárból.

    # kerberos &
    Kerberos server starting
    Sleep forever on error
    Log file is /var/log/kerberos.log
    Current Kerberos master key version is 1.

    Master key entered. BEWARE!

    Current Kerberos master key version is 1
    Local realm: EXAMPLE.COM
    # kadmind -n &
    KADM Server KADM0.0A initializing
    Please do not use 'kill -9' to kill this job, use a
    regular kill instead

    Current Kerberos master key version is 1.

    Master key entered.  BEWARE!

A fenti figyelmeztetés fordítása:

    A program leállítására ne a 'kill -9' parancsot, hanem a
    normális kill parancsot használjuk

Ezután a `kinit` parancs használatával próbáljunk meg az előbb létrehozott `janos` azonosítónak kérni egy jegyet:

    % kinit janos
    MIT Project Athena (grunt.example.com)
    Kerberos Initialization for "janos"
    Password:

A `klist` paranccsal most próbáljuk meg kilistázni a tokeneket és így ellenőrizni, hogy valóban rendelkezünk velük:

    % klist
    Ticket file:    /tmp/tkt245
    Principal:      janos@EXAMPLE.COM

      Issued           Expires          Principal
    Apr 30 11:23:22  Apr 30 19:23:22  krbtgt.EXAMPLE.COM@EXAMPLE.COM

Ezután a passwd(1) használatával próbáljuk meg megváltoztatni a jelszavunkat. Ezzel tudjuk ellenőrizni, hogy a kpasswd démon hozzáfér a Kerberos adatbázisához:

    % passwd
    realm EXAMPLE.COM
    Old password for janos:
    New Password for janos:
    Verifying password
    New Password for janos:
    Password changed.

## 14.7.7. Adminisztrátori jogosultságok felvétele

A Kerberos lehetővé teszi, hogy mindegyik olyan felhasználónak, akinek rendszergazdai jogokra lenne szüksége, a su(1) eléréséhez külön meg tudjunk adni egy jelszót. Most már tudunk mondani egy olyan azonosítót is, amely jogosult a su(1) használatával `root` jogokat szerezni. Ezt úgy tudjuk megoldani, ha az adott szereplőhöz társítunk egy `root` példányt. A `kdb_edit` használatával készíteni tudunk egy `janos.root` bejegyzést a Kerberos adatbázisában:

    # kdb_edit
    Opening database...

    Enter Kerberos master key:

    Current Kerberos master key version is 1.

    Master key entered.  BEWARE!
    Previous or default values are in [brackets] ,
    enter return to leave the same, or new value.

    Principal name: janos
    Instance: root

    <Not found>, Create [y] ? y

    Principal: janos, Instance: root, kdc_key_ver: 1
    New Password:                    <---- ide csak egy BIZTONSÁGOS jelszót adjuk meg!
    Verifying password

    New Password:    	 	 <---- adjuk meg ismét a jelszót

    Principal's new key version = 1
    Expiration date (enter yyyy-mm-dd) [ 2000-01-01 ] ?
    Max ticket lifetime (*5 minutes) [ 255 ] ? 12 <--- ne állítsuk nagyon hosszúra!
    Attributes [ 0 ] ?
    Edit O.K.
    Principal name:		         <---- ha nem adunk meg semmit, akkor kilép

Ezt követően úgy tudunk megbizonyosodni a működéséről, hogy megpróbálunk neki tokeneket szerezni:

    # kinit janos.root
    MIT Project Athena (grunt.example.com)
    Kerberos Initialization for "janos.root"
    Password:

Most rakjuk bele a felhasználót a `root` `.klogin` állományába:

    # cat /root/.klogin
    janos.root@EXAMPLE.COM

Ezután próbáljunk meg kiadni a su(1) parancsát:

    % su
    Password:

Nézzük meg milyen tokenjeink is vannak:

    # klist
    Ticket file:	/tmp/tkt_root_245
    Principal:      janos.root@EXAMPLE.COM

      Issued           Expires          Principal
    May  2 20:43:12  May  3 04:43:12  krbtgt.EXAMPLE.COM@EXAMPLE.COM

## 14.7.8. Más parancsok használata

Az iménti példában létrehoztunk egy `janos` nevű szereplőt, amihez a `root` egy példányát rendeltük. Ez egy olyan felhasználón alapján történt, akinek a neve megegyezik a hozzátartozó szereplővel, ami a Kerberosban alapértelmezés. Amennyiben a szükséges megjegyzések megtalálhatóak a `root` könyvtárában levő `.klogin` állományban, akkor a ``felhasználó`.`root`` formátumú ``szereplő`.`példány`` azonosító megengedi a ``felhasználó`` számára, hogy végrehajtsa a su(1) parancsot.

    # cat /root/.klogin
    janos.root@EXAMPLE.COM

Ehhez hasonlóan, ha a felhasználó saját könyvtárában megtalálható egy ilyen állomány:

    % cat ~/.klogin
    janos@EXAMPLE.COM
    jozsef@EXAMPLE.COM

Ezzel a konfigurációval bárki, aki `janos` felhasználóként vagy `jozsef` felhasználóként (a `kinit` parancson keresztül) hitelesítette magát `EXAMPLE.COM` övezetből, ezen a rendszeren (`grunt`) bejelentkezhet a `janos` nevű felhasználóként vagy hozzáférhet az állományaihoz az rlogin(1), rsh(1) vagy rcp(1) használatával.

Például `janos` most egy másik Kerberost használó rendszerre jelentkezik be:

    % kinit
    MIT Project Athena (grunt.example.com)
    Password:
    % rlogin grunt
    Last login: Mon May  1 21:14:47 from grumble
    Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
            The Regents of the University of California.   All rights reserved.

    FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995

Vagy `jozsef` jelentkezik be ugyanazon a gépen `janos` hozzáférésével (a `janos` nevű felhasználónak a fentebb bemutatt `.klogin` állomány található a könyvtárában és a Kerberos üzemeltetéséért felelős személy létrehozott egy jozsef nevű szereplőt egy null példánnyal):

    % kinit
    % rlogin grunt -l janos
    MIT Project Athena (grunt.example.com)
    Password:
    Last login: Mon May  1 21:16:55 from grumble
    Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
            The Regents of the University of California.   All rights reserved.
    FreeBSD BUILT-19950429 (GR386) #0: Sat Apr 29 17:50:09 SAT 1995

Előző | Tartalom | Következő
A TCP kapcsolatok burkolása | Fel | Kerberos5

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