Kerberos is een netwerkdienst, protocol en systeem waarmee gebruikers zich kunnen aanmelden met behulp van een dienst op een veilige server. Diensten als op een andere server aanmelden, op afstand kopiëren, veilig tussen systemen kopiëren en andere taken met een hoog risico worden aanmerkelijk veiliger en beter controleerbaar.
Kerberos kan omschrijven worden als identiteitbevestigend proxy systeem. Het kan ook omschreven worden als een vertrouwd autenticatiesysteem van een derde partij. Kerberos vervult maar één taak: het veilig autenticeren van gebruikers op het netwerk. Het vervult geen autorisatietaken (wat gebruikers mogen) en controleert ook niets (wat gebruikers hebben gedaan). Nadat een cliënt en server Kerberos hebben gebruikt om hun identiteit vast te stellen kunnen ze ook al hun communicatie coderen om hun privacy en gegevensintegriteit te garanderen.
Daarom wordt het sterk aangeraden om Kerberos samen met andere beveiligingsmechanismen te gebruiken die autorisatie en controlemogelijkheden bieden.
De aanwijzingen die nu volgen kunnen gebruikt worden als werkinstructie om Kerberos in te stellen zoals dat wordt meegeleverd met FreeBSD. Een complete beschrijving staat in de handleiding.
Voor demonstratie van de installatie van Kerberos wordt gebruik gemaakt van de volgende naamgeving:
Het DNS domein (“zone”) is example.org.
De Kerberos wereld is EXAMPLE.ORG.
Het advies is voor installaties van Kerberos echte domeinnamen te gebruiken, zelfs als het alleen intern wordt gebruikt. Hiermee worden DNS problemen voorkomen is een goede samenwerking met andere Kerberos werelden verzekerd.
Kerberos is ontworpen door MIT als oplossing voor netwerkbeveiligingsproblemen. Het Kerberos protocol gebruikt sterke codering zodat een cliënt zijn identiteit kan bewijzen aan een server (en andersom) over een onveilige netwerkverbinding.
Kerberos is zowel de naam van een netwerkautorisatieprotocol als een bijvoeglijk naamwoord om de programma's te beschrijven die gebruik maken van het programma (zoals Kerberos telnet). De huidige versie van het protocol is versie 5 en is beschreven in RFC 1510.
Er zijn een aantal vrij beschikbare implementaties van dit protocol beschikbaar voor veel systemen. Het Massachusetts Institute of Technology (MIT), waar Kerberos ooit is ontwikkeld, ontwikkelt nog steeds door aan hun Kerberos pakket. Het wordt in de VS veel gebruikt als coderingspakket en daarom wordt het ook geraakt door de exportwetgeving van de VS. Kerberos van MIT is beschikbaar als port (security/krb5). Heimdal Kerberos is een andere implementatie van versie 5 die expliciet buiten de VS is ontwikkeld om de exportwetgeving de omzeilen (en wordt daarom vaak gebruikt in niet-commerciële UNIX® varianten). De Heimdal Kerberos distributie is beschikbaar als port (security/heimdal) en er zit een minimale installatie in de basisinstallatie van FreeBSD.
Om het grootst mogelijke publiek te bereiken gaan deze instructies ervan uit dat de Heimdal distributie die bij FreeBSD zit wordt gebruikt.
Het Sleutel Distributie Centrum (KDC, voluit “Key Distribution Center”) is de gecentraliseerde autenticatiedienst die Kerberos levert. Het is de computer die Kerberos tickets uitgeeft. Het KDC wordt “vertrouwd” door alle andere computer in de Kerberos wereld en daarom dient er een strenger beveiligingsregime op van kracht te zijn.
Hoewel het draaien van de Kerberos dienst erg weinig van een systeem vraagt, wordt het wel aangeraden om een machine in te richten exclusief voor het KDC om beveiligingsredenen.
Het opzetten van een KDC begint met de
controle of de instellingen in
/etc/rc.conf
juist zijn om te functioneren
als KDC (misschien moeten paden veranderd
worden voor een eigen systeem):
kerberos5_server_enable="YES" kadmind5_server_enable="YES"
Daarna wordt het
Kerberos-instellingenbestand
/etc/krb5.conf
aangemaakt:
[libdefaults] default_realm = EXAMPLE.ORG [realms] EXAMPLE.ORG = { kdc = kerberos.example.org admin_server = kerberos.example.org } [domain_realm] .example.org = EXAMPLE.ORG
/etc/krb5.conf
gaat ervan uit dat de
KDC de volledig gekwalificeerde hostnaam kerberos.example.org
heeft. Als de
KDC een andere hostnaam heeft, moet er nog
een CNAME (alias) toegevoegd aan de zonefile.
Voor grotere netwerken met een juist ingestelde BIND DNS server kan het bovenstaande voorbeeld ingekort worden tot:
[libdefaults] default_realm = EXAMPLE.ORG
Door de volgende regels toe te voegen aan het
zonebestand voor example.org
:
_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
Om cliënten de
Kerberos-diensten te kunnen laten
vinden, moet er een volledig ingestelde
/etc/krb5.conf
zijn of een minimaal
ingestelde /etc/krb5.conf
en een correct ingestelde DNS-server.
Nu wordt de Kerberos
database aangemaakt. Deze database bevat de sleutels voor
alle principals en zijn versleuteld met een hoofdwachtwoord.
Dit wachtwoord hoeft niet onthouden te worden omdat het wordt
opgeslagen in (/var/heimdal/m-key
). De
hoofdsleutel wordt aangemaakt door kstash
te starten en een wachtwoord in te voeren.
Als de hoofdsleutel is gemaakt, kan de database
ingeschakeld worden met kadmin
met de optie -l
(die staat voor
“local”). Deze optie geeft
kadmin
de opdracht om de databasebestanden
direct te wijzigingen in plaats van via de
kadmind
netwerkdienst. Hiermee wordt het
kip-ei-probleem opgelost waarbij een verbinding wordt gemaakt
met de database voordat hij bestaat. Op het prompt van
kadmin
kan met init
de database met de werelden aangemaakt worden.
Tenslotte, nog steeds in kadmin
, kan
de eerste principal gemaakt worden met
add
. De standaardopties voor de principal
worden nu aangehouden. Deze kunnen later altijd
nog gewijzigd worden met modify
. Met
het commando ?
kunnen alle beschikbare
mogelijkheden getoond worden.
Hieronder een sessie waarin een voorbeelddatabase wordt aangemaakt:
#
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
Nu kan de KDC dienst gestart worden
met service kerberos start
en
service kadmind start
. Op dit moment
draait er nog geen enkele daemon die gebruik maakt van
Kerberos. Bevestiging dat
KDC draait is te krijgen door een ticket te
vragen en dat uit te lezen voor de principal (gebruiker)
die zojuist is aangemaakt vanaf de commandoregel van het
KDC zelf:
%
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
Het ticket kan worden ingenomen wanneer u klaar bent:
%
kdestroy
Als eerste is een kopie van het instellingenbestand van
Kerberos nodig,
/etc/krb5.conf
. Dit bestand kan
eenvoudigweg op een veilige manier (met netwerkprogramma's
als scp(1), of fysiek via een floppy) naar de
cliëntcomputer gekopieerd worden vanaf de
KDC.
Hierna is het /etc/krb5.keytab
nodig. Dit is het belangrijkste verschil tussen een server
die een daemons met Kerberos
aanbiedt en een werkstation: de server heeft het bestand
keytab
nodig. Dit bestand bevat de
hostsleutel van de server waardoor het werkstation en de
KDC elkaars identiteit kunnen bevestigen.
Dit bestand dient veilig overgebracht te worden omdat de
beveiliging van de server doorbroken kan worden als de
sleutel openbaar wordt gemaakt. Dit betekent expliciet dat
overdracht via een protocol dat platte tekst gebruikt,
bijvoorbeeld FTP, een slecht idee is.
Meestal wordt keytab
naar de
server gebracht met kadmin
. Dat
werkt handig omdat ook de host principal (het
KDC onderdeel van
krb5.keytab
) aangemaakt moet
worden met kadmin
.
Let wel op dat er al een ticket moet zijn en dat dit
ticket de kadmin
interface moet mogen
gebruiken in kadmind.acl
. Zie
“Beheer op Afstand” in de Heimdal
informatiepagina's (info heimdal
) voor
details over het ontwerpen van toegangscontrole. Als
kadmin
via het netwerk geen toegang mag
hebben, dan kan ook op een veilige verbinding gemaakt worden
met de KDC (via het lokale console,
ssh(1) of Kerberos
telnet(1)) zodat alles lokaal uitgevoerd kan worden met
kadmin -l
.
Na het installeren van
/etc/krb5.conf
kan
kadmin
van de
Kerberos server gebruikt worden.
Met add --random-key
kan de host
principal toegevoegd worden en met ext
kan
de host principal van de server naar zijn eigen keytab
getrokken worden. Bijvoorbeeld:
#
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
Let op: ext
slaat de sleutel standaard
op in /etc/krb5.keytab
.
Als kadmind
niet beschikbaar is op de
KDC (wellicht om beveiligingsredenen) en
er via het netwerk dus geen toegang is tot
kadmin
, dan kan de host principal
(host/myserver.EXAMPLE.ORG
) ook direct
aan de KDC toegevoegd worden en daarna in
een tijdelijk bestand gezet worden. Het volgende kan
gebruikt worden om te voorkomen dat
/etc/krb5.keytab
op de
KDC) wordt overschreven:
#
kadmin
kadmin>ext --keytab=/tmp/example.keytab host/myserver.example.org
kadmin>exit
Hierna kan de keytab veilig gekopieerd worden naar de
server (met scp
of een floppy). Geef
een niet-standaard naam op voor de keytab om te voorkomen
dat de keytab op de KDC wordt
overschreven.
Nu kan de server communiceren met de
KDC (vanweg
krb5.conf
) en zijn identiteit bewijzen
(vanwege krb5.keytab
). Nu is de server
klaar om er een aantal Kerberos
diensten op te activeren. In dit voorbeeld wordt de dienst
telnet
geactiveerd door de volgende regel
in /etc/inetd.conf
te zetten en dan
inetd(8) te herstarten met
service inetd restart
:
telnet stream tcp nowait root /usr/libexec/telnetd telnetd -a user
Het belangrijkste is dat de typering
-a
(van autenticatie) op user staat. Meer
details zijn in telnetd(8) te vinden.
Het opzetten van een cliëntcomputer is eigenlijk
kinderlijk eenvoudig. Wat betreft de
Kerberos instelling is alleen het
Kerberos instellingenbestand
(/etc/krb5.conf
) nodig. Dat kan
eenvoudigweg naar de cliëntcomputer gekopieerd worden
vanaf de KDC.
Test de cliënt met kinit
,
klist
en kdestroy
vanaf de cliënt om een ticket te krijgen, te bekijken en
daarna te verwijderen voor de principal die hierboven is
aangemaakt. Nu moeten ook
Kerberos applicaties gebruikt
kunnen worden om verbindingen te maken met servers waarop
Kerberos is geactiveerd. Als dat
niet lukt en het verkrijgen van een ticket is wel mogelijk,
dan ligt dat hoogstwaarschijnlijk aan de server en niet aan
de cliënt of de KDC.
Bij het testen van een applicatie als
telnet
kan het beste een pakketsnuffelaar
(bijvoorbeeld tcpdump(1)) gebruikt worden om te bevestigen dat
een wachtwoord niet als tekst wordt verzonden. Gebruik
telnet
met de optie -x
.
Dan wordt de complete gegevensstroom versleuteld (vergelijkbaar
met ssh
).
Er worden standaard ook andere
Kerberos applicaties op de
cliënt geïnstalleerd. Hier komt de
“minimalistische” natuur van de basisinstallatie
van Heimdal boven drijven: telnet
is
de enige dienst waarvoor Kerberos
geactiveerd is.
De port Heimdal voegt een aantal ontbrekende
cliëntapplicaties toe: versies met ondersteuning voor
Kerberos van
ftp
, rsh
,
rcp
, rlogin
en een paar
minder gebruikelijke programma's. De MIT
port bevat ook een volledig gamma aan
Kerberos cliëntapplicaties.
Voor gebruikers binnen een wereld wijst hun
Kerberos principal (bv.
tillman@EXAMPLE.ORG
) gewoonlijk naar
een lokale gebruikersaccount (bijvoorbeeld een lokale account
met de naam tillman
). Voor
cliëntapplicaties als telnet
is
gewoonlijk geen gebruikersnaam of principal nodig.
Soms moet iemand zonder bijpassende
Kerberos principal toch toegang
hebben tot een lokale gebruikersaccount.
tillman@EXAMPLE.ORG
zou bijvoorbeeld
toegang nodig kunnen hebben tot de lokale gebruikersaccount
webdevelopers
. Andere principals zouden
die toegang wellicht ook nodig kunnen hebben.
De bestanden .k5login
en
.k5users
uit de gebruikersmap kunnen op
eenzelfde manier gebruikt worden als
.hosts
en .rhosts
.
Zo wordt het voorgaande probleem opgelost. Als bijvoorbeeld
een .k5login
met de volgende
inhoud:
tillman@example.org jdoe@example.org
in de thuismap van de lokale gebruiker
webdevelopers
gezet wordt dan zouden
beide principals toegang hebben tot die account zonder dat
ze een wachtwoord hoeven te delen.
We raden aan de handleidingen voor deze commando's
te lezen. Let op dat de ksu
handleiding
.k5users
behandelt.
Als de Heimdal of MIT
Kerberos port wordt gebruikt
dan dient de PATH
omgevingsvariabele
de Kerberos versies van de
cliëntapplicaties te tonen voor de systeemversies.
Hebben alle computers in de wereld hun tijd gesynchroniseerd? Als dat niet zo is, dan slaagt de autenticatie wellicht niet. Paragraaf 29.10, “Tijd synchroniseren met NTP” beschrijft hoe klokken met NTP gesynchroniseerd kunnen worden.
MIT en Heimdal werken prima samen.
Dit geldt niet voor kadmin
omdat
daarvoor geen protocolstandaard is.
Als een hostnaam wordt gewijzigd, dan moet ook de
host/
principal aangepast en de
keytab. Dit geldt ook voor bijzondere instellingen
in de keytab zoals de www/
principal
voor www/mod_auth_kerb van
Apache.
Alle hosts in een wereld moeten oplosbaar
(resolvable) zijn (zowel vooruit als achteruit) in de
DNS (of tenminste in
/etc/hosts
). CNAMEs werken wel,
maar de A en PTR records moeten juist en actief zijn. De
foutmelding is niet erg duidelijk: Kerberos5
refuses authentication because Read req failed: Key table
entry not found.
Sommige besturingssystemen van cliënten voor een
KDC zetten wellicht geen setuid
root
voor ksu
.
Dit betekent dat ksu
niet werkt. Dat
is vanuit beveiligingsoogpunt een prima idee, maar wel
lastig. Dit is dus geen KDC-fout.
Als met MIT
Kerberos een principal een
ticket moet krijgen dat langer geldig is dan de standaard
van tien uur, dan moet
modify_principal
in
kadmin
gebruikt worden om de maximale
geldigheidsduur (maxlife) van zowel de principal waar het
om gaat als de krbtgt
principal aan
te passen. Dan kan de principal kinit
-l
gebruiken om een ticket met een
langere levensduur aan te vragen.
Als een pakketsnuffelaar op de
KDC draait bij om te helpen bij het
oplossen van problemen en dan kinit
vanaf een werkstation wordt gestart, dan wordt zichtbaar
dat de TGT meteen wordt verstuurd als
kinit
start, zelfs nog voor het
wachtwoord! De reden hiervoor is dat de
Kerberos server vrijelijk een
TGT (Ticket Granting
Ticket) verstuurt op iedere niet geautoriseerd verzoek.
Maar iedere TGT is versleuteld met een
sleutel die is afgeleid van het wachtwoord van de
gebruiker. Als een gebruiker zijn wachtwoord ingeeft,
wordt dat dus niet naar de KDC
gezonden, maar ontcijfert het de TGT
die kinit
al heeft ontvangen. Als de
ontcijfering resulteert in een geldige ticket met een
geldige tijdstempel, dan heeft de gebruiker geldige
Kerberos rechten. Deze
rechten bevatten ook een sessiesleutel voor het opzetten
van beveiligde communicatie met de
Kerberos server in de toekomst
en de eigenlijke ticket-granting ticket, die is
versleuteld met de sleutel van de
Kerberos server zelf. Deze
tweede laag van versleuteling is niet bekend voor de
gebruiker, maar het stelt de
Kerberos server in staat om de
juistheid van iedere TGT te
bevestigen.
Als tickets worden gebruik die lang geldig zijn (bv.
een week) en OpenSSH wordt
gebruikt om een verbinding te maken met de machine waarop
het ticket staat, zorg er dan voor dat de
Kerberos optie
TicketCleanup
op no
staat in sshd_config
want anders
worden tickets verwijderd bij afmelden.
Hostprincipals kunnen ook een langere levensduur hebben. Als een gebruikers principal een levensduur van een week heeft, maar de host waar de verbinding mee gemaakt wordt heeft een levensduur van negen uur, dan heb staat er een verlopen host principal in de cache en dan werkt een en ander niet zoals verwacht.
Een krb5.dict
bestand om het
gebruik van bepaalde slechte wachtwoorden te voorkomen
(dit wordt kort behandeld in de handleiding voor
kadmind
) heeft alleen betrekking op
principals waar een wachtwoordbeleid voor geldt. De
opmaak van krb5.dict
is eenvoudig:
een rij tekens per regel. Een symbolische link maken naar
/usr/share/dict/words
is misschien
handig.
Het belangrijkste verschil tussen de
MIT en Heimdal installatie heeft
betrekking op kadmin
, dat een andere (maar
gelijkwaardige) set commando's kent en een andere protocol
gebruikt. Dit betekent nogal wat als een
KDC MIT is, omdat
dan de kadmin
van Heimdal niet gebruikt
kan worden om de KDC vanaf afstand te
beheren (dat geldt trouwens ook vice versa).
De cliëntapplicaties kunnen ook commandoregelopties
gebruiken die een beetje verschillen, maar waarmee wel
hetzelfde wordt bereikt. We raden aan de instructies op de
MIT Kerberos
website (http://web.mit.edu/Kerberos/www/
) te volgen.
Wees voorzichtig met paden: de MIT-port
installeert standaard in
/usr/local/
en dus kunnen de
“normale” systeemapplicaties gestart worden in
plaats van die van MIT als de
PATH
omgevingsvariabele de systeemmappen als
eerste weergeeft.
Als de MIT
security/krb5 port die
bij FreeBSD zit wordt gebruikt, dan zorgt het lezen van
/usr/local/share/doc/krb5/README.FreeBSD
dat bij de port wordt geïnstalleerd voor een beter
begrip over waarom het aanmelden via
telnetd
en klogind
soms wat vreemd verloopt. Als belangrijkste wijzen we erop
dat het bij het corrigeren van
“onjuiste rechten op het cachebestand”
noodzakelijk is dat het binaire bestand
login.krb5
wordt gebruikt voor
autenticatie zodat het op de juiste wijze eigenaarschap kan
wijzigen voor de doorgegeven rechten.
Het bestand rc.conf
moet ook gewijzigd
worden zodat het de volgende configuratie bevat:
kerberos5_server="/usr/local/sbin/krb5kdc" kadmind5_server="/usr/local/sbin/kadmind" kerberos5_server_enable="YES" kadmind5_server_enable="YES"
Dit is gedaan omdat de applicaties voor
MIT-Kerberos binairen in de hiërarchie
/usr/local
installeren.
Iedere ingeschakelde dienst op het netwerk moet
aangepast worden om met Kerberos
te werken (of op een andere manier beschermd zijn tegen
netwerkaanvallen), want anders kunnen gebruikersrechten
worden gestolen en herbruikt. Een voorbeeld hier van is
het inschakelen van Kerberos
voor alle shells op afstand (via rsh
en
telnet
bijvoorbeeld), maar de
POP3 mailserver die wachtwoorden als
platte tekst verzend ongemoeid laten.
In een meergebruikersomgeving is
Kerberos minder veilig. Dit
komt doordat de tickets worden opgeslagen in de map
/tmp
, waar gelezen kan worden
door alle gebruikers. Als een gebruiker een computer deelt met
andere gebruikers op hetzelfde moment (dus multi-user), dan
is het mogelijk dat een ticket van een gebruiker wordt
gestolen (gekopieerd) door een andere gebruiker.
Dit kan voorkomen worden met de commandoregeloptie
“-c
bestandsnaam” of (bij
voorkeur) de omgevingsvariabele KRB5CCNAME
,
maar dat wordt zelden gedaan. In principe kan het opslaan
van een ticket in de thuismap van een gebruiker in
combinatie met eenvoudige bestandsrechten dit probleem
verhelpen.
Zoals het is ontworpen, moet de KDC zo goed mogelijk beveiligd zijn, omdat de hoofdwachtwoorddatabase erop staat. De KDC hoort geen enkele andere dienst aan te bieden en moet ook fysiek afgeschermd worden. Het gevaar is groot, omdat Kerberos alle wachtwoorden versleutelt met dezelfde sleutel (de “master” sleutel) die als een bestand op de KDC staat.
Toch is een gecompromitteerde mastersleutel niet zo'n groot probleem als wellicht wordt verondersteld. De mastersleutel wordt alleen gebruikt om de Kerberos database te versleutelen en als zaad voor de generator van willekeurige nummers. Zo lang als de toegang tot de KDC is beveiligd, kan een aanvaller niet echt iets doen met de mastersleutel.
Als de KDC niet beschikbaar is (misschien door een ontzeggen van dienst aanval of netwerkproblemen) kunnen de netwerkdiensten niet gebruikt worden omdat er geen autenticatie uitgevoerd kan worden; een recept voor een ontzeggen van dienst aanval. Dit risico kan omzeild worden door meerdere KDC's (één master en één of meer slaven) en een zorgvuldige implementatie van secundaire of fall-back autenticatie. PAM is hier uitermate geschikt voor.
Kerberos stelt gebruikers,
hosts en diensten in staat om elkaar te autenticeren.
Maar het heeft geen mechanisme om de KDC
te autenticeren aan de gebruikers, hosts of diensten. Dit
betekent dat bijvoorbeeld een vervalste
kinit
alle gebruikersnamen en
wachtwoorden zou kunnen afluisteren. Iets als
security/tripwire of
andere controle-instrumenten voor de integriteit van
bestandssystemen kunnen hier verlichting brengen.
All FreeBSD documents are available for download at https://download.freebsd.org/ftp/doc/
Questions that are not answered by the
documentation may be
sent to <freebsd-questions@FreeBSD.org>.
Send questions about this document to <freebsd-doc@FreeBSD.org>.