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.
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.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.
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
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. szakasz - Az órák egyeztetése az NTP használatávalbó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.
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.
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):
<questions@FreeBSD.org>.
Ha ezzel a dokumentummal kapcsolatban van kérdése, kérjük erre a címre írjon:
<gabor@FreeBSD.org>.