Kerberos, PAM

Jakub Mahdal, xmahdal@fi.muni.cz

Obsah

• Kerberos
  • Úvod
  • Historie
  • Koncepce protokolu
  • Postup přístupu ke zdroji
  • Konfigurace (Debian)
  • Odkazy
• PAM
  • Úvod
  • Konfigurace
  • Odkazy

Kerberos

Úvod

Kerberos - z řecké mytologie - pes se třemi hlavami, strážce vchodu do podsvětí.
V našem pojetí je Kerberos systémem pro autentizaci a autorizaci uživatelů v rámci sítě. Celá jeho koncepce vychází z předpokladu, že prostředí sítě není důvěryhodné a vždy je zde potenciální možnost "odchycení" přenášených informací cizí osobou, následné předstírání cizí identity, neoprávněné využití služby nebo změny či pouze odposlouchávání přenosu. Tyto problémy jsou částečně řešeny použitím firewallu, ale jedná se pouze o obranu před vnějším útočníkem.
Systém Kerberos byl vyvinut k odstranění těchto nedostatků.

Historie

První verze byly vyvinuty v rámci projektu Athena v letech 1983-1991 v laboratořích MIT (Massachusetts Institute of Technology) a první veřejnou verzí byla verze v4. Po zhruba šestiletém vývoji a upravování na základě zkušeností uživatelů vznikla verze v5, která se v současnosti používá.
Z důvodu omezení na vývoz šifrovacích algoritmů mimo území USA vzniká paralelní projekt Heimdal v Evropě a výsledkem je kód, který je již volně šiřitelný. Oba tyto systémy jsou založeny na shodném API rozhraní, a tak by aplikace neměly mít problémy se shodným přístupem k oběma z nich.

Koncepce protokolu

Hlavní částí systému Kerberos je KDC (Key Distribution Center - Needham-Schroeder Schema), které je tzv. důvěryhodnou třetí stranou umožňující bezpečnou autentizaci a autorizaci přístupu ke zdrojům a která bezpečně uchovává data o uživatelích a službách v síti. KDC se dělí na dva subsystémy:

• AS - autentizační server, je odpovědný za autentizaci a autorizaci uživatelů a služeb
• TGS - Ticket Grantig Server, je odpovědný za přidělování oprávnění - lístků - k použití zdroje (služby)

Dále v systému vystupují klientské aplikace a servery na nichž běží služby.
Při přístupu ke službě je (velmi zjednodušeně) potřeba ověřit autentizační údaje klienta serverem AS, který mu po úspěšné autentizaci vydá lístek umožňující požádat TGS o udělení přístupu ke službě. Jakmile ho klient obdrží a prokáže se jím požadované službě, která ověří jeho platnost, může být služba používána po dobu platnosti tohoto lístku.

Postup přístupu ke zdroji

Popišme nyní detailněji celý proces přístupu k požadované službě.

1. Klientský proces si vyžádá username, které pošle v plain textu AS (tzn. klient tímto žádá o přidělění TGT (viz. dále). AS má centrální databázi uživatelů a služeb, kde se nalezá heslo uživatele, které musí být shodné s heslem na klientu.
2. AS přijme tuto žádost (většinou tyto žádosti ukládá kvůli větší bezpečnosti do cache), následně podle username vyhledá v centrální databázi heslo uživatele a z něj vygeneruje dočasný klíč - session_key. Vygeneruje dále tzv. TGT lístek - Ticket Granting Ticket, který se skládá
   z {username,TGSname(vydává oprávnění použít zdroj),useraddress(síťová adresa klienta),session_key}
   Tento TGT lístek je poté zašifrován pomocí tajného klíče který je bezpečně sdílen pouze AS a TGS.
3. AS posílá klientskému procesu tento TGT lístek a spolu s ním mu posílá také dvojici
   {session_key, n (nonce, náhodný idefikátor či timestamp kvůli zvýšení bezpečnosti}
   která je zašifrována pomocí tajného klíče, získaného z klientského hesla uloženého v centrální databázi AS.
4. Klientský proces pomocí klíče vygeneroveného ze svého uživatelského hesla dešifruje tuto dvojici a získá tak session_key a může také zkontrolovat platnost n. Klient tedy nyní vlastní TGT a session_key, které budou dále použity v komunikaci s TGS. To že klient správně dešifruje a získá session_key v podstatě znamená úspěšnou autentizaci a autorizaci vůči AS.
5. Klientský proces žádá nyní o použití služby tímto způsobem: vytvoří si tzv. autentifikátor, který obsahuje {username,useraddress,timestamp}, timestamp udává čas vytvoření autentifikátoru a jeho platnost. Tento autentifikátor je zašifrován pomocí session_key a odeslán TGS spolu s žádostí o využití požadované služby a TGT lístkem.
6. TGS přijme tyto údaje a pomocí klíče, který bezpečně sdílí s AS dešifruje TGT lístek, z něhož získá session_key. Pomocí tohoto klíče dešifruje autentifikátor a zkontroluje jestli souhlasí informace na TGT lístku (username,useraddress) a v autentifikátoru. Dále zkontroluje jeho platnost - timestamp.
   Po kladném ověření generuje nový lístek = pověření použít požadovanou službu běžící na serveru S. TGS generuje nový klíč TGS_session_key, který bude použit v komunikaci klienta a serveru S. TGS vytvoří lístek {username,useraddress,timestamp}, který zašifruje pomocí klíče TGS_session_key a odešle jej klientskému procesu spolu s novým TGS_session_key šifrovaným pomocí session_key.
7. Klient přijme tyto lístky dešifruje pomocí session_key a tak získá TGS_session_key. Vlastní tedy tento klíč a současně lístek opravňující použít službu serveru S. Klientský proces vytváří další autentifikátor {username,useraddress,timestamp} šifrovaný pomocí TGS_session_key a posílá jej na server S, kde běží požadovaná služba.
8. Server S ověří údaje z autentifikátoru tak, že dešifruje klíčem, který sdílí s TGS lístek, získá z něj TGS_session_key, kterým dešifruje autentifikátor a zkontroluje zda údaje souhlasí.

Obr.: 1. Schéma fungování Kerbera

Konfigurace (Debian)

K instalaci jsou potřebné balíčky krb5-config, krb5-kdc, krb5-user, libkadm55, krb5-admin-server.
Ke konfiguraci slouží dva hlavní soubory: /etc/krb5.conf a /etc/krb5kdc/kdc.conf

krb5.conf:

	#používá knihovna Kerberos v5
	[libdefaults]
		#název oblasti, kterou spravuje Kerberos
		default_realm = SPEO-BETA.LAB.FI.MUNI.CZ
		kdc_timesync = 1		
		#typy session key, které umí KDC
		default_tgs_enctypes = aes256-cts arcfour-hmac-md5 des3-hmac-sha1 des-cbc-crc des-cbc-md5
		#typy session key, které budou požadovány po klientu
		default_tkt_enctypes = aes256-cts arcfour-hmac-md5 des3-hmac-sha1 des-cbc-crc des-cbc-md5
		#permitted_enctypes = aes256-cts arcfour-hmac-md5 des3-hmac-sha1 des-cbc-crc des-cbc-md5
		
	#subsekce definovanované svými REALM jmény, zde je pouze jedna
	[realms]
	SPEO-BETA.LAB.FI.MUNI.CZ = {
	        kdc = speo-beta.lab.fi.muni.cz
	        admin_server = speo-beta.lab.fi.muni.cz	#běží zde kadmin
	        master_kdc = speo-beta.lab.fi.muni.cz	#v případě neúspěšné autentizace se sem obrátí klient
	}
	
	#mapování doménových jmen na  REALMy 
	[domain_realm]
	        speo-aplha = SPEO-BETA.LAB.FI.MUNI.CZ
	        speo-beta = SPEO-BETA.LAB.FI.MUNI.CZ
	
	#definuje autentizační cesty na přímou nehierarchickou "cross-realm" autentizaci
	#[capaths]
	
	#logování Kerbera
	#[logging]	
	

	#základní chování KDC
	[kdcdefaults]
	    kdc_ports = 750,88
	
	#každá REALM zde definuje KDC parametry pro REALM v krb5.conf
	[realms]
	SPEO-BETA.LAB.FI.MUNI.CZ = {
		database_name = /var/lib/krb5kdc/principal
		admin_keytab = FILE:/etc/krb5kdc/kadm5.keytab	#používá se k autentizaci
		acl_file = /etc/krb5kdc/kadm5.acl 		#definice kdo má jaké práva v databázi.
		key_stash_file = /etc/krb5kdc/stash		#uložení master key
		kdc_ports = 750,88
		max_life = 10h 0m 0s
		max_renewable_life = 7d 0h 0m 0s
		master_key_type = des3-hmac-sha1
		supported_enctypes = des3-hmac-sha1:normal des-cbc-crc:normal des:normal des:v4 des:norealm des:onlyrealm des:afs3		
	}

Nejprve je nutné vytvořit databázi klíčů příkazem kdb5_util create -s, který si také současně vyžádá hlavní heslo pro server.
Do souboru /etc/krb5kdc/kadm5.acl se nadefinují práva pro administraci. Například následující příklad definuje pro všechny uživatele ze skupiny admin a oblasti SPEO-BETA.LAB.FI.MUNI.CZ plná práva:

*/admin@SPEO-BETA.LAB.FI.MUNI.CZ     *

Příkazem kadmin.local -q "add_principal xmahdal/admin" vytvoříme uživatele administrátora s výše definovanými právy.
Spustíme démony krb5kdc a kadmin.
Je vhodné zajistit synchronizaci času klienta a serveru pomocí ntpdate.
Aplikace (servery), které mají používat Kerberos musí být přidány do databáze - příkaz addprinc -randkey host/speo-alpha.fi.muni.cz zadaný v kadmin módu.
Příkazem ktadd -k /etc/krb5kdc/krb5.keytab host/speo-alpha.fi.muni.cz vytvoříme soubor /etc/krb5kdc/krb5.keytab.

Pro větší odolnost proti výpadku, můžeme definovat sekundární Kerberos servery, které v případě výpadku hlavního převezmou jeho úlohu. Provedeme to následujícím způsobem: pro všechny servery provedeme výše uvedené kroky - addprinc -randkey host/speo-alpha.fi.muni.cz a ktadd -k /etc/krb5kdc/krb5.keytab host/speo-alpha.fi.muni.cz .
V /etc/krb5kdc se vytvoří soubor kpropd.acl, který bude sloužit k šíření databáze Kerbera. Do tohoto souboru se nadefinují sekundární KDC servery. Nyní je nutné replikovat databáze na sekundární servery, to se děje příkazy kdb5_util dump /etc/krb5kdc/slave_datatrans a kprop -f /etc/krb5kdc/slave_datatrans. Poté na nich spustit démony kpropd.

Odkazy

http://cryptnet.net/fdp/admin/kerby-infra/en/kerby-infra.html
ftp://athena-dist.mit.edu/pub/kerberos/doc/krb_evol.PS
http://web.mit.edu/kerberos/www/dialogue.html
http://www.fi.muni.cz/~kas/p090/referaty/

PAM - Pluggable Authentification Module

Úvod

Původní autentizační schéma v UNIXu tvořila (a stále tvoří) dvojice username-password, kterou byl nucen uživatel správně zadat a která byla kontrolována nejdříve oproti /etc/passwd (zde byl bezpečnostní problém s právy souboru nastavenými na "644", takže každý uživatel ho mohl číst), později také oproti souboru /etc/shadow (ten už běžným uživatelům čitelný není).

Hlavní myšlenka UNIXových systémů - každý program se specializuje na jednu konkrétní věc a tu dělá dobře - je v rozporu s výše uvedeným schématem, jelikož každá aplikace si tím pádem musí sama řešit svou autentizaci oproti těmto souborům. Druhý a velmi závažný nedostatek se objeví, je-li vytvořeno nové autentizační schéma. Aby mohlo být využíváno, je nutné jeho podporu doprogramovat do všech existujících aplikací, které jej mají používat - login, ftp... Tyto skutečnosti vedly k vytvoření PAM. PAM umožňuje odstínít aplikace od konkrétních autentizačních schémat (statická hesla, čtečky čipových karet, jednorázová hesla, biometriky...). Také umožňuje umístit hesla například do SQL databáze, kde se s nimi mnohem lépe pracuje.

PAM je realizován knihovnou libpam a aplikace, která chce autentizaci využívat bude komunikovat s touto knihovnou. Konkrétní metody autentizace jsou realizovány jednotlivými pluginy do této knihovny.

Konfigurace

Konfigurační soubor může být pouze jeden - /etc/pam.conf anebo je PAM konfigurován skupinou souborů z v adresáři /etc/pam.d/, kde každému programu odpovídá jeden konfigurační soubor.

Uvádím příklad /etc/pam.d/ssh:

# PAM configuration for the Secure Shell service

# Pokud existuje soubor /etc/nologin nedovolí přes SSH přihlásit nikomu mimo root
auth       required     pam_nologin.so

# Použítí proměnných prostředí z /etc/environment a /etc/security/pam_env.conf.
auth       required     pam_env.so # [1]

# Definuje autentizační mechanismus - zde je možné použít Kerberos, LDAP...
# Defaultně je zde standardní UNIX autentizace přes /etc/shadow
# Ke změně je potřeba editovat soubor common-auth
@include common-auth

# Standard Un*x authorization.
@include common-account

# Standard Un*x session setup and teardown.
@include common-session

# Vytiskne uvítací hlášku po úspěšném přihlášení
session    optional     pam_motd.so # [1]

# Stav mailboxu
session    optional     pam_mail.so standard noenv # [1]

# Nastaví user limity definované v  /etc/security/limits.conf.
session    required     pam_limits.so

# jakým způsobem lze změnit heslo (4-8 znaků, MD5...)
@include common-password 

Konfigurační soubory jsou ve tvaru:
[module-type][control-flag][module-path][arguments]

• auth - oveření uživatele pomocí jeho hesla, nebo jiné metody
• account - oveření existence účtu uživatele, jestli se může v danou dobu přihlásit...
• session - definice seznamu akcí které je potřeba udělat před a po vykonaním služby, výpis počtu nových zpráv v mailboxu, uvítací hlášení, definice limitu na spotřebovaný čas, loggovaní...
• password - umožnit uživateli změnu jeho přihlašovacího hesla, požadavky na tvar hesla, kontrola oproti slovníku lehce napadnutelných hesel...

• required - určuje, že úspěch modulu je nutný k úspěchu celé autentizace
• requisite - podobně jako required, ale po neúspěchu předá řízení okamžitě zpět aplikaci
• sufficient - úspěch tohoto modulu dostačuje pro ukončení celé autentizace jako úspěšné
• optional - úspěch/neúspěch tohoto modulu se zvažuje pouze tehdy, pokud předchozí sufficient a optional moduly skončí neúspěchem

module-path
Definuje se zde cesta k PAM pluginům - modulům zodpovědným za proces autentizace, implicitně se moduly hledají v /usr/lib/security, pokud není zadána absolutní cesta.

arguments
Definují seznam argumetů, který je předán modulům při jejich spuštění.

Jednotlivé moduly lze vzájemně řetězit využitím modulu pam_stack.
Ukázka pro soubor /etc/pam.d/passwd:

#%PAM-1.0
auth       required     pam_stack.so service=system-auth
account    required     pam_stack.so service=system-auth
password   required     pam_stack.so service=system-auth

Dílčí nastavení pro /etc/pam.d/passwd je možné provést v souboru /etc/pam.d/system-auth

#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth        required      /lib/security/pam_env.so
auth        sufficient    /lib/security/pam_unix.so likeauth nullok
auth        required      /lib/security/pam_deny.so

account     required      /lib/security/pam_unix.so
account     sufficient    /lib/security/pam_succeed_if.so uid < 100 quiet
account     required      /lib/security/pam_permit.so

password    requisite     /lib/security/pam_cracklib.so retry=3
password    sufficient    /lib/security/pam_unix.so nullok use_authtok md5 shadow
password    required      /lib/security/pam_deny.so

session     required      /lib/security/pam_limits.so
session     required      /lib/security/pam_unix.so

Autentizace pomocí systému Kerberos by se mohla v PAM definovat takto:

#%PAM-1.0
auth       required     pam_krb.so

Odkazy

http://www.kernel.org/pub/linux/libs/pam/
http://www.linuxdocs.org/HOWTOs/User-Authentication-HOWTO/x101.html
http://www.fi.muni.cz/~kas/p090/referaty/