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.
Opmerking: 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.
Opmerking: Voor grotere netwerken met een juist ingestelde BIND DNS server kan het bovenstaande voorbeeld ingekort worden tot:
[libdefaults] default_realm = EXAMPLE.ORGDoor 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
Opmerking: 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 /etc/rc.d/kerberos start en /etc/rc.d/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 /etc/rc.d/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 30.10 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.
Opmerking: 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.
Opmerking: 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.