15.7. Kerberos5

Bijgedragen door Tillman Hodgson. Gebaseerd op een bijdrage van Mark Murray.

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:

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.

15.7.1. Geschiedenis

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.

15.7.2. Opzetten van een Heimdal KDC

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

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

15.7.3. Kerberos inschakelen op een server met Heimdal diensten

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.

15.7.4. Kerberos activeren op een cliënt met Heimdal

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.

15.7.5. Instellingenbestanden voor gebruikers: .k5login en .k5users

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.

15.7.6. Kerberos tips, trucs en problemen oplossen

15.7.7. Verschillen met de MIT port

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.

15.7.8. Beperkingen in Kerberos

15.7.8.1. Kerberos is een alles of niets aanpak

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.

15.7.8.2. Kerberos is bedoeld voor werkstations met een gebruiker

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.

15.7.8.3. De KDC is een single point of failure

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.

15.7.8.4. Tekortkomingen van Kerberos

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.

15.7.9. Bronnen en verdere informatie