Návrh řešení správy autentizace pomocí lístkových služeb Ing. Zbyněk Hubínka, HF TU v Liberci Abstrakt Text pojednává o možném řešení problému autentizace v nedůvěryhodném prostředí nasazením lístkové služby Kerberos, integrace Kerbera s existujícími datovými a jmennými službami a aplikace takto vzniklého bloku v prostředí virtuálních sítí. Je kladen důraz na bezpečnost autentizačního provozu a uživatelský komfort, stejně tak jako na schopnost systému zapojit se do stávající infrastruktury a schopnost systému akceptovat budoucí rozšíření nabídky služeb.
Úvod Problematika nepopiratelné autentizace v počítačových sítích byla řešena již mnohokrát. Většina řešení je buď nepraktická (biometrie), nebo nedostatečně účinná. Předkládaný návrh vychází ze zkušeností z provozu heterogenní sítě středního rozsahu, ve které se nachází několik datových úložišť spravovaných servery Samba dostupných ze všech pracovních stanic. Každý uživatel je autorizován k čtení a zápisu nad dedikovaným adresářem, přičemž správa oprávnění probíhá po dvou liniích – propojení uživatelských adresářů s účty podle nastavení systému v souborech /etc/passwd a zároveň evidence uživatelů Samby a jejich přístupů v databázi LDAP. Zabezpečení výměny autentizačních informací je dáno implementací OpenSSL nad LDAP – Samba deleguje autentizaci na LDAP. Nedostatkem současného řešení je jednak roztříštěnost autentizačních informací, jednak nutnost opakovaného přihlašování k dalším požadovaným službám. Rovněž rozšíření nabídky služeb znamená někdy i podstatné zásahy do jejich konfigurace, aby byly schopny autentizace proti LDAPu, a to většinou za cenu duplicitní evidence hesel, resp. jejich otisků. Proto byl vypracován tento návrh využívající samostatnou správu autentizačních informací pomocí lístkové služby. Koncepce lístkových služeb 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. Lístkové služby byly vyvinuty k odstranění těchto nedostatků. Lístkové autentizační služby jsou navrženy pro provoz v nedůvěryhodných sítích jako autentizace pomocí důvěryhodné třetí strany, s níž klient i server sdílí tajemství. Autentizace uživatele probíhá proti důvěryhodné třetí straně, která na základě úspěšného ověření identity uživatele vydá klientu lístek, jímž se bude nadále prokazovat místo obvyklé interaktivní autentizace (zadání uživatelského jména a hesla). Pokud klient žádá po serveru autentizaci pomocí lístku, server si vyžádá jeho kopii (autentizátor) u třetí strany a porovná obě kopie. Je podstatné, aby se nelišil příliš okamžik vytvoření od od okamžiku žádosti o autentizaci, protože lístek se vytváří vždy na dobu určitou a to poměrně krátkou. Většina lístkových služeb dokáže i opakovaně na žádost klientu platnost lístku prodloužit, nicméně po uběhnutí této lhůty je lístek zahozen a je třeba se autentizovat třetí straně znovu. Lístek lze použít pro libovolnou službu, o které třetí strana ví, tedy má ji uloženou ve své databázi a naopak služba samotná dokáže s lístkovou službou spolupracovat. Pro uživatele to znamená, že kromě prvního přihlášení, které bývá zároveň přihlášením k jeho pracovní stanici už pro žádnou službu vyžadující autentizaci a známou třetí straně nemusí explicitně uvádět svoje přihlašovací informace. 1
Existují v podstatě dvě různá provedení lístkové služby, rozšířená a často používaná. Prvním je Microsoft Active Directory, resp. jeho lístkový modul. MS AD je komplexní balík aplikací sdružující adresářové služby a lístkové služby s hierarchií a strukturou záznamů obdobnou jiným službám. Jeho nedostatkem je provázanost s platformou Microsoft Windows a uzavřenost, dále problematické chování v heterogenních a složených sítích a obtížná dostupnost z jiných platforem. Druhým řešením je nasazení LDAP na evidenci uživatelů a jejich hierarchie a systému Kerberos na vlastní správu autentizace. Tato varianta je náročnější na nastavení, ale má výhodu v tom, že ji lze jednoduše i za běhu nastavovat podle momentální konfigurace informačního systému. Jak LDAP, tak i Kerberos existují ve volně šiřitelných a otevřených implementacích, jejich konfigurace je známá a dobře dokumentovaná a existuje mnoho úspěšně fungujících instalací. Následující dokument popisuje metodiku harmonizace adresářových a autentizačních služeb za účelem realizace systému lístkové autentizace, a to na bázi otevřeného softwaru. Protože neexistuje akceptovatelné a dostatečně robustní řešení, je celý systém navrhován od počátku, tj. postupně podle požadavků jednotlivých služeb na autentizaci. Systém je modulární a do značné míry minimalistický – v navržené podobě poskytuje autentizaci pouze pro službu Samba, ovšem s tím, že jej lze definovaným způsobem rozšířit pro další služby. Využívá se toho, že v rámci jedné domény (realmu) lze definovat libovolné hostitele služeb a služby jimi poskytované jednoduchým zásahem administrátora bez nutnosti poskytovat tuto informaci klientům, tedy veškeré změny v seznamu služeb vyžadujících autentizaci se provádějí na jednom místě, na důvěryhodném serveru poskytujícím lístkové služby. Dalším důvodem pro navržené řešení byla možnost provozu ve virtuálních sítích. Principy virtuálních sítí jsou popsané v literatuře a není předmětem tohoto dokumentu je popisovat, proto jen ve stručnosti: jedná se o logickou síťovou infrastrukturu postavenou nad fyzickými sítěmi, která má povahu sítě lokální. Využívá tzv. IP tunnelingu, tj. schopnosti některých protokolů komunikační vrstvy zabalit svůj síťový provoz do šifrované obálky, která znemožní subjektům v komunikaci nezúčastněným vůbec tento datový tok vidět. Tunel probíhá od jednoho rozhraní k druhému a právě jeho povaha „krátkého spojeníÿ připomínajícího logický síťový kabel dala vzniknout virtuálním sítím sestávajícím právě z IP tunelů. Kerberos narozdíl od AD lze bez problémů na virtuální síť implementovat, protože autentizační provoz Kerbera běží i na tcp portech a lze jej tedy tunelovat (o problematice pozadí provozu ve virtuálních sítích více v [5]).
Adresáře a adresářové služby Autentizační data se obvykle centralizují do speciálních databází, tzv. adresářů. Obvyklá představa databáze víceméně koresponduje s tzv. relačním modelem, tedy strukturou sestávající z neuspořádaných, ale uspořadatelných stejně dlouhých záznamů. V praxi jsou relační databáze stále nejčastější podobou, ovšem často narazíme na problém, který je sice relační strukturou postižitelný, ale za cenu neekonomičnosti. Typickým příkladem je databáze uživatelů informačního systému, který slouží velkému množství heterogenních účastníků, jako je třeba univerzitní síť nebo systém sdílení výrobních dat v rámci spolupráce více podniků. Jakmile je struktura uživatelů a jejich charakteristik příliš různorodá, máme na výběr ze tří variant. Jednak zachovat stávající podobu databáze, což ovšem vyžaduje neustálé rozšiřování záznamu o položky, které pro určité skupiny uživatelů jsou buď nevýznamné, nebo nesmyslné (např. číslo pokoje na koleji má smysl sledovat u studenta, kdežto u pedagoga je taková položka zcela 2
zbytečná). Takový přístup vede ke vzniku tzv. řídkých tabulek, v nichž nakonec převažují prázdná pole nad obsazenými, což prodlužuje prohledávání a v neposlední řadě zbytečně zabírá diskový prostor. Druhá varianta znamená rozdělit původně jedinou tabulku do několika dílčích, přičemž společné údaje (jméno, příjmení, bydliště, registrační číslo. . .) jsou umístěny v centrální tabulce a podle toho, do které podskupiny uživatelů ten který patří, podle toho jsou jeho další charakteristiky rozvedeny v odpovídajících záznamech v odvozených tabulkách. Tento model je ekonomičtější, ale stále zůstává uzavřený — pokud chceme charakteristiku některé skupiny uživatelů rozšířit, musíme změnit samotnou podstatu datového modelu a přidat další položku do odpovídajícího záznamu. V souvislosti s tím je zpravidla nutné přeformulovat některé typy dotazů, aby po rozšíření modelu byly stále validní. Třetí variantou je úplná rekonstrukce databáze a vytvoření adresáře. Adresář je datová struktura ne nepodobná papírovému adresáři, v němž se uchovávají údaje o osobních, pracovních nebo jiných kontaktech. Jedná se o strukturu hierarchickou, stromovou, kde je u kořene uvedena obecná charakteristika platná pro všechny záznamy a všem záznamům společná, a čím výše se v adresáři pohybujeme, tím další položky přibývají a charakteristika subjektu se stává podrobnější. Adresář oproti zažité podobě nemusí mít nutně podobu binárního stromu, tím méně hromady, přesto cesta zpět od konkrétního subjektu ke kořenu musí být vždy daná a jediná. Adresáře jsou tedy charakterizovány proměnlivou délkou jednotlivých záznamů podle toho, na jaké větvi adresářového stromu se daný záznam nachází. V adresáři můžeme uchovávat data různých typů, jako text, digitální certifikát či obrázek, obvykle ovšem uschovávají data textová. Ze své podstaty je adresář navržen k rychlému čtení a prohledávání a jen občasnému záznamu. Následující obrázek ilustruje jednoduchý adresář a směr prohledávání.
Obr. 1: Jednoduchý adresář Adresářovou službou rozumíme aplikaci nebo balíku aplikací, které přistupují k adresáři, čtou a upravují data v něm uložená. Protože záznamy v adresáři nemají danou strukturu, může při prostém zápisu docházet i ke změně počtu položek v dané větvi, dílčímu rozvětvení nebo naopak zjednodušení stromu. Adresářová služba také funguje jako centrální autentizační autorita, která umožňuje autentizaci zdrojů (uživatelů, služeb, počítačů). Parametry přístupu udává tzv. Access Control List – ACL, který vymezuje autorizace jednotlivých přistupujících subjektů. Adresářová služba narozdíl od relačních databázových strojů si těžko poradí s referenční integritou dat, což je dáno variabilitou záznamů a odlišnou implementací datových typů, má problémy s konstrukcí horizontálních dotazů (pokrývajících více větvení na stejné úrovni).
LDAP. Adresářový model LDAPu LDAP představuje pokročilý protokol adresářové služby odvozený od dnes již historického protokolu DAP (Directory Access Protocol) a protokolů souvisejících, popsaných 3
normou X.500. Zjednodušením této normy (písmeno L znamená Lightweight) a zúžením transportního pozadí na sadu protokolů TCP/IP vzniká LDAP jako standard. Datový formát LDAPu se označuje jako LDIF (LDAP Data Interchange Format). Jedná se o jednoduchý textový formát, který sestává z jednotlivých objektů (analogie záznamů relační databáze) rozpadajících se do párů atribut-hodnota, přičemž termínem třída je označován souhrn atributů typických pro určitou skupinu objektů. LDAP je popisován pomocí čtyř modelů: • • • •
informační model (schéma), který udává vlastní strukturu dat v adresáři jmenný model, popisující organizaci dat; funkční model, souhrn akcí, které lze nad adresářem provádět; bezpečnostní model, jak jsou data v adresáři chráněna.
Informační model nastavuje základní parametry vlastního adresáře. Základem informačního modelu je definice kořenu, který obsahuje základní specifikaci celého stromu. Kořen (rootDSE) nemá definováno jednoznačné jméno (distinguished name, dn), ani třídu. Jednotlivé typy objektů jsou potom definovány schématy, která obsahují všechny použitelné atributy pro danou třídu (např. Samba, NFS, elektronická pošta aj.). Schéma samo o sobě představuje třídu, ovšem velmi specifickou – všechny její atributy mají unikátní hodnoty. Z podstaty věci ale není nijak složité schémata dále rozšiřovat, ev. nechat prolínat více schémat zároveň. Třídy objektů, jak již bylo řečeno, představují abstrakci objektu. Objekty jedné třídy mají zpravidla stejnou strukturu atributů, což vyplývá ze sémantické povahy třídy. Příkladem může být třída user sdružující uživatele, computer sdružující počítače, group pro pracovní skupiny aj. Jeden objekt může splňovat charakteristiky více tříd zároveň, například student vedený ve třídě user je zároveň v nižší (konkrétnější) třídě student, stejně tak ve vyšší třídě person a nejvyšší top. Třídou top se rozumí příslušnost k vlastnímu stromu, jak je definováno v kořenu (organisation (o), domain component (dc) aj.). Pokud objekt shrnuje vlastnosti více objektů, nazývá se kontejner a je potom rodičem tzv. listů, objektů bez potomků. Typickým kontejnerem je definice třídy user, listem je potom jeden uživatel spadající do dané třídy.
Obr. 2: LDAP adresář Uvedený přístup s sebou nese určitou komplikaci vyhledávání, proto se zavádí pojem kategorie objektů. Kategorie objektů uchovává informaci o nejspecifičtější třídě objektu, aniž by to narušilo vlastní schéma. Vyhledávání potom probíhá nikoli po třídách, nýbrž po kategoriích, které jsou danému objektu jednoznačné. Protože kategorie představuje zároveň objekt třídy schéma, je i vyhledávání optimalizováno prostřednictvím specifického atributu, uvádějícího implicitní kategorii objektu. Každý objekt třídy schéma 4
obsahuje atribut, jehož hodnotou je přímo název třídy, takže vyhledávání probíhá na úrovních kategorie a nikoli na úrovni konkrétních objektů. Atributem objektu se rozumí konkrétní charakteristika objektu. Atribut zpravidla obsahuje jednu hodnotu, může ovšem nabývat i více hodnot. Atributy jsou vůči třídám specifické, jsou uvedeny ve schématu a to včetně jejich eventuální obligatornosti. Na úrovni atributů je uveden i typ očekávané hodnoty, zpravidla po linii číslo-řetězec. Názvy atributů podléhají konvenci podle použitých schémat a není předmětem tohoto článku je vyjmenovávat. Typ atributu představuje informaci o tom, jaké hodnoty může atribut nabývat a jak se s jeho hodnotou má zacházet při provádění operací. Následuje seznam základních typů atributů. - ces (case sensitive string) – řetězec znaků s rozlišením malých a velkých písmen - cis (case insensitive string) – totéž bez rozlišení malých a velkých písmen - tel – telefonní číslo; jsou ignorovány mezery, pomlčky a rozlišení malých a velkých písmen - bin – binární data (ve smyslu sekvence osmibitových čísel), může uchovávat třeba obrázek nebo zvukový záznam - dn – distinguished name, jednoznačný identifikátor objektu (pozn.: hodnoty jsou samozřejmě ukládány v původní podobě, eventuelní nerozlišování je na úrovni funkce vyhledávání, např. pokud je „Jan Novákÿ typu tel, bude v adresáři uložen jako „Jan Novákÿ, ale pude odpovídat vyhledávání sekvence „jan novákÿ stejně jako „jannovákÿ) Každý objekt adresáře, ať kontejner nebo list, má ve své struktuře obsažen jednoznačný identifikátor, který je unikátní v rámci celého stromu. Nazývá se distinguished name (dn) a obsahuje úplnou cestu k objektu počínaje kořenem. Jednotlivé položky cesty, reprezentující nadřazené objekty (kontejnery, domény) jsou v dn od sebe odděleny čárkou a zapisují se ve směru zpět ke kořenu. Tedy uživatel Jan Novák může mít atribut dn například následující podoby: uid=Jan.Novak,ou=People,dc=kin.vslib,dc=cz kde uid je atribut určující identifikaci uživatele (user identificator, někdy se používá atribut cn – common name), ou určuje třídu objektu (v našem případě organisation unit) a poslední dvě části dn představují kořen stromu. Pokud není třeba z nějakého důvodu uvádět celou cestu, vystačíme si s rdn (relative distinguished name), které nám udává jednoznačné umístění objektu v rámci objektu nadřazeného (kontejneru). Zde může být rdn například sekvence uid=Jan.Novak v rámci kontejneru People. LDAP verze 3 podporuje v rámci jmenného modelu jak výše uvedenou podobu, která je kompatibilní s Microsoft Active Directory, tak původní LDAP strukturu, kde místo atributů dc se používají atributy o (organisation) a c (country). Na následujícím obrázku vidíte příklad výpisu jednoho listu z adresáře LDAP provozovaného na katedře informatiky TUL. # zbynek.hubinka, People, kin.vslib.cz dn: uid=zbynek.hubinka,ou=People,dc=kin.vslib,dc=cz uid: zbynek.hubinka cn: zbynek.hubinka sn: zbynek.hubinka 5
objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: posixAccount objectClass: top objectClass: shadowAccount objectClass: sambaSamAccount shadowMax: 99999 shadowWarning: 7 loginShell: /bin/bash uidNumber: 1004 gidNumber: 100 homeDirectory: /home/zbynek.hubinka sambaSID: S-1-5-21-394859400-385291240-3741148699-3008 sambaPrimaryGroupSID: S-1-5-21-394859400-385291240-3741148699-1201 sambaPwdMustChange: 2147483647 sambaPasswordHistory: 0000000000000000000000000000000000000000000000000 000000000000000 sambaAcctFlags: [U ] sambaPwdCanChange: 1169652514 sambaPwdLastSet: 1169652514 shadowLastChange: 13573 sambaLMPassword: 80FD37AA5EF7BEDA09752A3293831D17 sambaNTPassword: CF9E88E4BFB1FE7F1F9789C86BD4B7B8 userPassword:: e01ENX1OSTdxdGU5aWtyVDJ4Vi8zNnVYUkVnPT0= Obr. 3: Příklad objektu LDAPu Za povšimnutí stojí několik detailů: některé atributy mají stejné hodnoty (uid, cn, sn) a některému atributu je přiřazeno více hodnot. Nikde totiž není psáno, že by jeden atribut musel mít jen jedinou hodnotu, příkladem budiž atribut objectClass, který v sobě zahrnuje všechny třídy, do nichž objekt náleží.
Funkční model LDAPu Funkční model LDAPu zahrnuje základní sadu funkcí, kterými lze přistupovat k obsahu adresáře. Konkrétní syntaxe je závislá na implementaci a prostředí, v následujícím seznamu jsou vyjmenovány jejich obecné významy. Autentizační funkce • bind – ověření loginu, autentizace; výstupem je identifikátor spojení • unbind – odpojení • abandon – žádost o ukončení posílání výsledků na předchozí dotaz Dotazy (čtení adresáře) • search – prohledávání stromu pomocí filtru; výstupem je objekt nebo skupina objektů • compare – na úrovni atributů porovná zadanou hodnotu; výstupem je 0 nebo 1
6
Úprava obsahu (modifikace adresáře) • • • •
add – přidá nový objekt modify – upraví existující objekt na úrovni atributů modifyRDN– přesouvá objekt v rámci adresáře (změna cesty) delete – maže objekt Tyto operace jsou definovány v RFC 3377 a jsou postačující pro lakce nad adresářem.
Bezpečnostní model LDAPu. SSL/TLS, SASL. Autorizace. Bezpečnostní model LDAPu se rozpadá do dvou úkolů – autentizace a autorizace. Autentizace, tj. ověření identity uživatele může být řízena interními mechanismy LDAPu, nebo může být předána třetí straně. Z vnitřních mechanismů se nejčastěji (a prakticky výhradně) používá autentizace anonymní pro veřejný přístup a jednoduchá (basic). LDAP je připraven pro aplikaci bezpečnostní mezivrstvy, takže autentizaci typu basic lze bez dalších problémů šifrovat pomocí SSL nebo TLS. Zpravidla je nutné vybrat jeden šifrovací kanál, protože jejich implementace se navzájem vylučuje. Pro iniciaci zabezpečeného spojení je kromě obecných podmínek SSL/TLS popsaných v [1] resp. [2] třeba v parametrech funkce bind uvést URI LDAP serveru v podobě ldaps://, což plně postačuje pro inicializaci spojení nad bezpečnostní mezivrstvou. Autentizace externími nástroji je rovněž často využívána. Její výhodou je aplikace jednotných ověřovacích prostředků pro více služeb a daleko větší množství variant ověření, včetně aplikace lístkových služeb. LDAP zde používá prostředníka, kterým je unifikační konektor nebo přímo správa autentizace. Výhradně se používá SASL (Simple Authentication and Security Layer), což je konektor pro přidávání nebo zlepšování bezpečnosti autentizace. SASLu se předává dn objektu k autentizaci, autentizační mechanismus a credentials, tedy data prokazující identitu. SASL ovládá několik základních ověřovacích mechanismů. Následuje seznam implementovaných metod. • PLAIN – nejjednodušší, lze šifrovat pomocí TLS • OTP – určen pro jednorázová hesla, proto neobsahuje algoritmy ověřování • DIGEST-MD5 – mechanismus založený na sdíleném hesle (credentials). Výzva serveru je klientem zašifrována a odeslána zpět, server následně pomocí téhož hesla vlastní výzvu rovněž zašifruje a výsledek porovná s odpovědí klientu. • KERBEROS – využívá mechanismu stejnojmenného protokolu, který je primárně určen pro oboustrannou autentizaci v nezabezpečených sítích prostřednictvím lístkové služby. Pro obsáhlost tématu bude vysvětleno samostatně. Kromě uvedených metod je k dispozici implicitní metoda anonymní autentizace určená pro předávání otevřených zpráv. Obvykle je LDAP nastaven tak, aby umožňoval číst některé atributy záznamu bez autentizace. dn: uid=zbynek.hubinka,ou=People,dc=kin.vslib,dc=cz uid: zbynek.hubinka cn: zbynek.hubinka sn: zbynek.hubinka objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson 7
objectClass: posixAccount objectClass: top objectClass: shadowAccount objectClass: sambaSamAccount shadowMax: 99999 shadowWarning: 7 loginShell: /bin/bash uidNumber: 1004 gidNumber: 100 homeDirectory: /home/zbynek.hubinka shadowLastChange: 13573 Obr. 4: Výpis objektu LDAP při anonymní autentizaci Samotná autentizace je podmínkou otevření spojení. Funkce bind otevírá sezení a vrací identifikátor sezení. Tento identifikátor je k dispozici funkcím volaným klientem a pomocí něj se udržuje vzájemné spojení až do odeslání funkce unbind, která dané spojení zruší. Autorizace je obecně vymezení práv daného uživatele. LDAP dokáže nastavit autorizaci na několika úrovních – nic nevidět, jen číst, číst i psát. Úroveň autorizace je pro různé atributy různá, přičemž některé LDAP servery lze nastavit tak, aby ani kořenový uživatel (cn=root,o=organizace,c=země) nebyl schopen určité atributy měnit. Ukládá se v řetězcích access to attr=
by <úroveň>, kde místo dn uživatele lze použít zástupnou sekvenci self označující vlastníka objektu. Pokud není specifikován atribut a je místo něj uveden symbol *, předpokládá se, že dané nastavení platí pro všechny atributy.
Základní konfigurace LDAP serveru. Předpokládejme instalaci LDAP na OS Linux. Hlavní konfigurační soubor slapd.conf naleznete v adresáři etc. Jeho umístění je závislé na distribuci a lze jej rozdělit do tří logických celků. Nejprve to jsou datová schémata pro konkrétní služby – důležité je uvést přinejmenším následující: include include include include
/etc/openldap/schema/core.schema /etc/openldap/schema/cosine.schema /etc/openldap/schema/inetorgperson.schema /etc/openldap/schema/nis.schema
Následují deklarace platné pro celý server a nezávislé na implementaci. allow bind v2 # abyste mohli používat LDAP funkce PHP password-hash md5 # nebo nějakou jinou z SMD5, SHA, SSHA, CRYPT loglevel 255 # pro debugging pidfile /var/run/openldap/slapd.pid TLSCertificateFile /etc/openldap/servercrt.pem TLSCertificateKeyFile /etc/openldap/serverkey.pem TLSCACertificateFile /etc/openldap/cacert.pem Cesty k certifikátům. LDAP (a Samba a Apache atd.) nepracují dobře se sebou podepsanými certifikáty. Ideální je certifikát podepsaný skutečnou autoritou, což ovšem 8
není zadarmo. Certifikát i soukromý klíč by měl mít nastavena práva na 600 (čtení povoleno pouze vlastníkovi). Následuje nastavení samotné databáze. database suffix directory rootdn rootpw index
ldbm # typ databáze; může být například bdb (Berkeley DB) "dc=kin.vslib,dc=cz" # kořen stromu /var/lib/openldap-data/ # adresář s databází "cn=root,dc=kin.vslib,dc=cz" # záznam superuživatele [TAJNE] # šifrované heslo objectClass eq
Hash hesla superuživatele (může se jmenovat úplně jinak a nemusí mít vůbec záznam v /etc/passwd, tedy vůbec nemusí pro systém existovat) vytvoříte příkazem # slappasswd -h MD5 Konfigurace LDAP klientu je platformně specifická. Z tohoto dokumentu je vypuštěna, lze ji najít včetně návodu na migraci uživatelů v [1].
Kerberos Kerberos je univerzální autentizační protokol pro použití v nedůvěryhodných sítích. Je definován v RFC 1510 a je založen na principu důvěryhodné třetí strany, která spravuje autentizační informace. Klient se serverem si tedy autentizační informace nevyměňují přímo, ale prostřednictvím důvěryhodného subjektu, který na základě sdíleného tajemství vydá časově omezený lístek, obsahující autorizaci k serveru a autentizaci klienta. Tento lístek se nazývá TGT (Ticket Granting Ticket), který slouží k získání dalších lístků určených pro konkrétní služby. Autentizace ke vzdáleným strojům potom neprobíhá tradiční cestou, tedy předáním autentizačních informací klientem serveru, ale pouze předáním lístku, což je operace, která se obejde bez přímé účasti uživatele. K přihlášení stačí prvotní autentizace proti AS (Authentication Server) a všechny další služby vyžadující autentizaci startují automaticky bez nutnosti explicitního zadání uživatelského jména a hesla. Autentizace proti AS probíhá následovně: 1. Uživatel pošle svoji autentizaci AS. 2. AS vygeneruje přístupový klíč, zkopíruje ho, jednu kopii doplní identifikací serveru a zašifruje klíčem klientu, druhou doplní identifikací klientu a zašifruje klíčem serveru a vrátí obě kopie klientu. 3. Klient vlastním klíčem rozšifruje kopii určenou pro něj a získaným přístupovým klíčem zašifruje informaci o aktuálním čase a další údaje, které spolu s kopií přístupového klíče získanou od AS (zašifrovanou klíčem serveru), tedy vlastním lístkem odešle na server; 4. Server rozšifruje kopii přístupového klíče získanou od klientu, rozšifruje informaci o aktuálním čase (autentizátor) a porovná s aktuálním časem; je-li autentizátor dostatečně aktuální, je to považováno za platnou autentizaci a klientu je umožněn přístup. Opakovaná autentizace probíhá obdobně, jen s tím rozdílem, že klient místo rozšifrování pošle znova již získaný lístek (TGT) další službě systému Kerberos, tzv. Ticket Granting Serveru (TGS). Žádosti o autentizaci od toho momentu nevyřizuje klient sám, ale provádí to za něj TGS, kterému se klient pouze prokazuje vygenerovaným lístkem, 9
a to až do okamžiku, kdy platnost lístku vyprší. Klient tedy pouze k požadavku o autentizaci připojí TGT a požadavek směruje nikoli na server, ale na TGS. Oba uvedené servery systému Kerberos, TGS a AS spolu obvykle úzce spolupracují, bývají dokonce umístěny na jednom počítači. Dohromady se nazývají KDC, Key Distribution Center. Z uvedeného vyplývá hlavní nedostatek služby Kerberos, a to nutnost přesné synchronizace všech komunikujících subjektů. Nejjednodušší způsob, jak tento nedostatek odstranit, je používání tzv. síťového času, který je distribuován protokolem ntp ze speciálního hodinového serveru. Tak lze zajistit, že se hodiny reálného času, od nichž se odvozuje časové razítko lístku na jednotlivých počítačích nebudou významně lišit. Dalším podstatným nedostatkem je riziko poruchy. Pokud Kerberos přestane běžet, nastane situace, kdy se nikdo nikam nepřihlásí. V návrhu implementace se proto počítá s klonováním serveru pomocí démona krbpropd.
Obr. 5: Schéma prvotní autentizace (vygenerování TGT). Plnou čarou je naznačena cesta autentizace proti AS, tečkovanou cesta zašifrovaného soukromého klíče klienta pro zamknutí autentizátoru, čárkovanou cesta TGT, čerchovanou cesta autentizátoru.
Obr. 6: Schéma opakované autentizace. Čárkovanou čarou je naznačena cesta TGT, čerchovanou cesta autentizátoru. Protože Kerberos vznikal na začátku osmdesátých let, používá poněkud neobvyklou terminologii. Uživatel je označován jako principal, doména jako realm. Za principal je považován i server (ve smyslu služba), protože z pohledu KDC je jedno, na žádost které strany se autentizace provádí.
Konfigurace Kerbera Základní konfigurační soubory jsou krb5.conf a kdc.conf. První nastavuje vlastní server, v druhém jsou základní parametry KDC. První lze rozdělit do tří sekcí: [libdefaults] default realm = KIN.VSLIB.CZ ticket lifetime = 600 clockskew = 60 default etypes = des3-hmac-sha1 des-cbc-crc des-cbc-md5 default etypes des = des3-hmac-sha1 des-cbc-crc des-cbc-md5 10
Sekce má pochopitelně více nastavení, tyto jsou ale nejdůležitější. První řádek nastavuje doménu – měla by odpovídat DNS doméně počítače, na kterém Kerberos běží, není to ale podmínkou. Druhý řádek nastavuje dobu platnosti lístku a třetí řádek povolenou odchylku, která bude brána v úvahu jako rozdíl způsobený špatnou synchronizací hodin reálného času. Následují potom názvy povolených šifrovacích algoritmů. Pro budoucí použití na autentizaci uživatelů MS Windows je zapotřebí, aby Kerberos ovládal šifru des-cbc-crc. [realms] KIN.VSLIB.CZ = { kdc = ilex.kin.vslib.cz:88 admin server = ilex.kin.vslib.cz:749 } [domain realm] .kin.vslib.cz = KIN.VSLIB.CZ kin.vslib.cz = KIN.VSLIB.CZ Tyto dvě sekce nastavují jednak základní realm serveru, jednak jeho propojení na DNS domény. Pro dostupnost serveru je třeba uvolnit na firewallu (je-li nainstalován) uvedené porty. Další nastavení se týkají logování a nejsou pro obecnou představu podstatné. Druhý soubor, kdc.conf zpravidla není nutné vůbec upravovat. Obsahuje parametry KDC – umístění implicitní keytab, dobu životnosti obnovovaného lístku atd.
Kerberos a LDAP Proč tedy podpora protokolu Kerberos v LDAP? Důvodů může být víc, primární je možnost opakovaného autentizovaného přístupu k datům v adresáři bez explicitní autentizace (tedy úspora času při opakovaném přihlašování) a následně úplné delegování autentizace na Kerberos. Je třeba si uvědomit, že LDAP sám o sobě umožňuje autentizaci pouze sám vůči sobě, a nelze tedy bez příslušných konektorů použít údaje z adresáře pro autentizaci vůči jiným službám (telnet, ssh, ftp, Samba, elektronická pošta. . . ). V Unixu lze přimět službu PAM (Password Authentication Module) k použití databáze LDAPu místo běžných souborů /etc/passwd, resp. /etc/shadow pro přihlášení k terminálu, analogicky potom lze podporu LDAPu implementovat autentizačnímu modulu Apache, srozumět LDAP s CIFS/SAMBA a vzdálenými souborovými systémy je ještě problematičtější, nicméně i to se dá spolehlivě realizovat. Výsledkem je heterogenní prostředí a komplikovaná struktura objektů v LDAPu – např. pro možnost přihlášení k síťovému disku distribuovanému Sambou potřebujete mít kromě hesla do LDAPu ještě dvě hesla pro Sambu. Protože většina služeb se dá poměrně úspěšně kerberizovat, lze následně přejít na pohodlné používání TGT bez nutnosti udržovat separátní autentizační struktury v adresáři LDAPu a tento soustředit na ukládání jiných informací. LDAP, jak bylo uvedeno dříve, nepodporuje přímo jinou autentizaci než simple. Proto je nutné mít přímo v LDAPu povolenou podporu SASL a stejně tak i v Kerberu. SASL z tohoto pohledu hraje pouze úlohu konektoru. Pokud máme k dispozici oba konektory, je postup následující: - vytvořit principal služby LDAP pomocí nástroje kadmin a exportovat klíč principalu. Tento je potřeba umístit někam, kde bude pro server LDAP čitelný (záleží na nastavení 11
práv a na uživateli, pod kterým je LDAP server pouštěn, nejlépe do tabulky .keytab příslušné dané instalaci). - přimět démona služby LDAP, aby klíč principalu v příslušné tabulce hledal. To je již platformně závislé a překračuje rámec tohoto dokumentu. Zpravidla stačí nastavit příslušnou systémovou proměnnou. Aby byl server schopen propojit identitu uživatele z Kerberos realmu s příslušným objektem v LDAPu, je třeba v jeho konfiguraci nastavit odpovídající extrakci uživatelského jména ze jmenného prostoru SASL (což je standardní výstup) a jeho doplnění na jednoznačnou podobu ve jmenném prostoru LDAP. Výsledkem je transparentní proces, během něhož si uživatel neuvědomí, že místo s LDAP serverem komunikuje s Kerberem a teprve ten přes SASL konektor se samotným adresářem.
Delegování autentizace Princip delegování je zhruba následující: uživatel předá při přihlášení k LDAP serveru svoje dn a heslo. Pokud atribut userPassword daného dn začíná sekvencí {SASL}, je provedení autentizace delegováno na SASL s tím, že text za uvedenou sekvencí je předán jako uživatelské jméno (zpravidla ve tvaru principal@realm). Jak je z předchozího patrné, není vůbec nutné, aby autentizaci prováděl Kerberos, stejně dobře lze použít i jiný mechanismus, který lokální implementace SASL zná. Je tedy ještě třeba nakonfigurovat propojení mezi SASL a Kerberem. K tomu slouží autentizační démon SASLauth, kterému se předá informace o tom, jaký konkrétní autentizační mechanismus má být použit. Kerberos bude potřebovat znát principal počítače, na němž SASLauthd poběží a klíč v umístění čitelném pro SASLauthd. Nyní je autentizace delegována na Kerberos a LDAP nemusí žádné informace o heslech dále udržovat.
Samba Samba je volně šiřitelný nástroj pro sdílení systémových zdrojů, tj. diskového prostoru, tiskáren a jiných periférií nad komunikační vrstvou TCP/IP. Protokol SMB, nad kterým je postavena, je takřka totožný s protokolem CIFS firmy Microsoft, a to do té míry, že bývá někdy omylem považován za jeho volně šiřitelnou implementaci. Narozdíl od NFS je její implementace podstatně jednodušší (vystačí si s třemi, v nouzovém případě i s jedním portem), v prostředí MS Windows nepotřebuje dodatečnou podporu, jako klient je schopná akceptovat CIFS doménu a jako server je tuto doménu schopna řídit. Správně nakonfigurovaný Samba server je pro stanici s MS Windows nerozeznatelná od nativního CIFS serveru. Standardní instalace Samba serveru obsahuje nejméně dva základní démony, a to smbd a nmbd. Smbd je odpovědný za správu sdílených zdrojů mezi klienty a Samba serverem. Naslouchá na portu 139/TCP, pro každé spojení vytvoří nový proces, který bude klienta obsluhovat a ukončí se až poté, co se klient odpojí. Démon obsluhuje SMB požadavky, stará se o autentizaci klientů a zamykání souborů. Pokud je démon ukončen řádně, doběhnou nedokončené přenosy a proces se ukončí. Náhlý konec může způsobit ztrátu přenášených dat. Nmbd je nameserver, tj. démon, který plní funkci jednoduchého WINS (Windows Internet Name Service) a NetBIOS (Network Basic Input/Output System) serveru, čeká na dotazy stanic a příslušně na ně odpovídá. Implicitně NetBIOS jméno počítače odpovídá jeho hostname. Mimo jiné umožňuje zjištění (browsing) sdílených prostředků. Může sloužit jako local master browser nebo domain master browser, 12
dokonce může i vytvářet samostatnou NT doménu. Tyto funkce jsou v nativním CIFS nedokonale implementovány a lze je naplno využít pouze mimo MS Windows. Moderní linux kernely (verze 2.6) jsou připraveny na klientskou podporu svazků poskytovaných Sambou nebo MS Windows sdílením. Mají implementovány speciální souborové systémy smbfs a cifs, které jsou k dispozici pro připojení vzdálených Samba disků. Smbfs je starší a postrádá některé možnosti cifs, jako například podporu šifrovaných souborových systémů. Jsou to virtuální souborové systémy, skutečná struktura připojovaných svazků se tedy může do určité míry lišit. Bohužel dodnes přetrvávají problémy s kompatibilitou znakových sad v názvech souborů, proto se doporučuje držet se následující konvence: - v názvech souborů jsou přípustné pouze alfanumerické znaky z dolní poloviny ASCII tabulky, tj. A-Z, a-z, 0-9, podtržítko a tečka. Mezera je nepřípustná z důvodu možné publikace na Internetu, kdy v URI první mezera znamená konec adresy, znaky s diakritikou jsou na různých systémech interpretovány různě a nealfanumerické znaky mívají speciální význam; - název souboru by neměl překročit 50 znaků. Některé operační systémy mohou mít omezení délky názvu souboru a hrozí nebezpečí, že by se na jednom svazku v jednom adresáři objevily dva soubory se stejným názvem. OS to obvykle řeší indexací, ale na to se nelze spolehnout. Konfigurace Samby je jednoduchá a bezproblémová, obtíže mohou nastat, pokud chcete zajistit přístup uživatelům do oblastí na disku, kam nemají přístup. Řízení přístupových práv je odlišné od MS Windows a je zapotřebí, aby do adresářů, do nichž je uživatelům povolen zápis v konfiguraci Samby, měli titíž uživatelé otevřený přístup i přímo v systému. Samba autentizuje přihlašované uživatele jak podle systémové evidence (zpravidla soubor /etc/passwd), tak i podle vlastní evidence (smbpasswd). Pokud je nastavena příslušná direktiva, synchronizuje se změna hesla do Samby (vlastně páru otisků) se změnou systémového hesla. Vzorová konfigurace Samba serveru následuje. [global] domain master = yes workgroup = HFIS netbios name = QUERCUS server string = Quercus robur L. log file = /var/log/samba/log.%m max log size = 50 hosts deny = all hosts allow = 147.230. 127. map to guest = bad user security = user encrypt passwords = yes socket options = TCP NODELAY SO RCVBUF=8192 SO SNDBUF=8192 local master = yes dos charset = cp1250 unix charset = ISO8859-2 [homes] comment = Home Directories browseable = yes 13
writable = yes [public] comment = For public use path = /public/read security = share read only = yes browseable = yes guest ok = yes [images] comment = Only for updates path = /media hosts deny = all hosts allow = 147.230.24.104 147.230.50.200 147.230.26.17 security = share browseable = yes writable = yes guest ok = yes Obr. 7: Vzor konfigurace Samba serveru Sekce [global] obsahuje obecná nastavení Samba serveru. Je zde uvedeno, zda je daný server stanoven jako master v dané NT doméně, jak se jmenuje pro NetBIOS a jak pro uživatele, kdo k němu smí přistupovat a odkud, jak bude vyhodnocen pokus o neautorizovaný přístup atd. Za zmínku stojí parametry security, kde je při tomto nastavení autentizace vyžadována povinně, a poslední dva řádky sekce, které se snaží o správné překódování českých znaků při připojování vzdálených svazků. Jak bylo řečeno dříve, nelze se na tento mechanismus spolehnout. Další sekce doplňují nastavení pro speciální druhy přístupu. Sekce [homes] je vyhrazená pro domácí adresáře uživatelů, sekce [public] pro veřejně přístupná data a poslední sekce je volitelná, zde sloučí pro image soubory se zálohami instalací počítačů na učebnách. V rámci sekcí se především nastavuje cesta, prohlížitelnost a zapisovatelnost. Definice ze sekce [global] jsou v dílčích sekcích libovolně předefinovatelné, takže do sekce [public] je povolen přístup bez autentizace, ovšem pouze pro čtení (security = share). Z historických důvodů se udržuje nejednoznačná syntax, takže například nastavení writable je negací nastavení read only.
Kerberos a Samba Kerberizace Samby se obvykle provádí z důvodu bezpečnosti – kritický je okamžik autentizace. Samba nemá implementován žádný vnitřní mechanismus šifrování autentizačního kanálu, takže po síti běží nechráněné otisky hesel. V zájmu zvýšení bezpečnosti lze správu autentizace přesunout na LDAP server, jak jsem uvedl v článcích [3] a [4]. Tím se ovšem nezbavíme nutnosti vést evidenci tří otisků jednoho hesla, jakkoli je jejich změna nyní proveditelná bez větších problémů. Ukazuje se, že synchronizace změn hesel uživatelů mezi systémem a Sambou v případě nasazení LDAPu na správu autentizace není ideální, za určitých okolností mechanismus nefunguje správně. Řešením tohoto problému je využití služby Kerberos, která správu autentizace převezme, resp. Samba server na Kerberos správu autentizace deleguje. Postup při implementaci následuje: 14
• Samba serveru je vytvořen jeho vlastní principal. Klíč je opět třeba umístit do .keytab tak, aby k němu měl Samba server oprávnění. • V konfiguračním souboru Samby je třeba v sekci [global] nastavit správný realm a direktivu use Kerberos keytab. • Tak je zajištěno, že Samba ví, kde má nalézt identity přihlašujících se uživatelů a deleguje správu autentizace do příslušného realmu. Ještě jedna poznámka ke kerberizaci Samby: pokud je nutné nebo vhodné použít virtuální souborový systém smbfs nebo cifs pro připojení vzdálených svazků, pro kerberizovanou sambu není vhodný souborový systém cifs. Implementace Kerbera je zde nedokonalá a v testovacím provozu vykazuje značné nedostatky. Autoři modulu tvrdí, že implementace je v pořádku, nicméně realizovat cifs konexi na kerberizovanou Sambu se bohužel nepodařilo.
MS Windows klient pro kerberizovanou Sambu Pracovní stanice MS Windows může být jak členem Samba domény, tak i Kerberos realmu. Nejprve je třeba pro stanici vytvořit vlastní principal, tentokrát s příslušným heslem. Toto heslo bude zapotřebí při zpětné registraci stanice do realmu. Na straně klientu nejprve pomocí speciálních nástrojů, které jsou součástí instalační sady systému zařadíme počítač do příslušné domény a k doméně přiřadíme principal KDC serveru. Pro první přihlášení je nutné zadat i heslo principalu, jak byl v předchozím kroku vytvořen na serveru. Pro úplnou aktivaci přístupu do Kerberos realmu je třeba každou stanici restartovat. V tomto okamžiku Windows dokáží autentizovat uživatele pomocí Kerbera, ale protože neexistuje žádný odpovídající uživatelský účet, nemá se uživatel kam přihlásit. Informace o uživatelích jsou dostupné na domain-master, pokud existuje, jinak jsou použiti uživatelé lokálně definovaní.
Očekávané výsledky implementace Kerbera V současné době je v rámci Hospodářské fakulty provozován jeden Samba server, na němž je umístěn depozitář studijních materiálů. Kromě toho server poskytuje databázové služby (MYSQL, PostgreSQL), prostor pro individuální webové stránky a distribuované grafické rozhraní pro tenké klienty. Všechny tyto služby vyžadují autentizaci. Zatím se podařila první fáze – autentizace, kterou si dříve řídily jednotlivé aplikace byla předána LDAP serveru, čímž se odstranily mnohdy ne zrovna bezpečně uložené databáze uživatelů. LDAP běží na samostatném počítači a v současné době integruje správu autentizace osobních počítačů, datových úložišť a autorizovaných přístupů k webovému serveru fakulty. Problémem zůstává nutnost opakovaných loginů a nedostupnost většiny služeb, především síťových svazků mimo doménu 147.230. V současné době je tento nedostatek vnímán stále silněji a pro mnoho uživatelů je nepřijatelné používat náhradní metody přenosu dat (například využití klientu WinSCP). Vzhledem k zvyšování přenosových rychlostí veřejných sítí nastává čas na řešení. Navrhované řešení, budou-li dodrženy zásady a postupy uvedené v tomto dokumentu zajistí následující zlepšení: • Zvýšení bezpečnosti autentizace. Z důvodu problematického zabezpečení přenosu autentizačních dat nebylo doposud možné uvolnit Samba svazky pro přístup mimo 15
doménu 147.230 (ve skutečnosti jsou omezeny na podsíť 147.230.24.0/21 ze stejných důvodů). Pokud se implementace zdaří, bude možno přistupovat k Samba svazkům odkudkoli a dokonce bude možné uvolnit další služby, kde to doposud nebylo možné kvůli problematické podpoře SSL/TLS, jako například MySQL a jiné databáze. • Zvýšení uživatelského komfortu. Doposud bylo nutné se ke každé službě zvlášť přihlašovat, takto obstará autentizaci po dobu trvání lístku Kerberos sám a uživatel není obtěžován dalšími loginy. Současný model využívá společnou autentizaci pro všechny služby a mimoto uživatelé zpravidla používají jedno jediné heslo na všechna přihlášení, takže budou brát tuto změnu pozitivně. S tím souvisí • Omezení důsledků uživatelské nekázně. Odpadnou různě v privátních datech prohlížečů uschovaná hesla a další zdroje potenciálních narušení. Uživatele nelze přinutit dodržovat pravidla přístupu na zabezpečené zdroje a takto budou do značné míry eliminovány případné důsledky jejich nekázně, protože autentizace bude prováděna výhradně proti Kerberos serveru a to jen v případě, že uživatelův TGT vypršel. • Menší šance pro útočníky. Přenos autentizačních dat bude probíhat nikoli směrem ke službě, ale k důvěryhodnému serveru. Protože je komunikace šifrována na základě sdíleného tajemství, potenciální účastník by měl mít při pokusu o odposlech mizivou šanci na úspěch. Cizí lístek je útočníkovi k ničemu, protože je na něm uložena identifikace neshodující se s jeho vlastní, kromě toho bude pravděpodobně KDC neznámý. Navržené řešení je prozatím ve stavu experimentů. V krátké době, nejlépe do začátku akademického roku by mělo být dosaženo plné implementace Kerbera na stávající služby při zachování existujících omezení a následně během testovacího provozu, kdy budou simulovány různé způsoby útoků a vyhodnocován jejich výsledek by se přistoupilo po zhodnocení k otevření služeb mimo doménu 147.230. Předpokládá se úplná realizace do konce roku 2009.
Literatura [1]DIERKS, T., ALLEN, C. The TLS Protocol Version 1.0. RFC 2246. Certicom, 1999. [online] http://www.ietf.org/rfc/rfc2246.txt [2]KOHL, J., NEUMAN, C. The Kerberos Network Authentication Service (V5). RFC 1510. Digital Equipment Corporation, 1993 [online] http://www.faqs.org/rfcs/rfc1510.html [3]HUBÍNKA, Z. Poznámky k LDAP. 30. 8. 2006 [online] http://www.root.cz/clanky/poznamky-k-ldap/. ISSN 1212-8309 [4]HUBÍNKA, Z. Nastavení LDAP serveru. 13. 9. 2006 [online] http://www.root.cz/clanky/nastaveni-ldap-serveru/. ISSN 1212-8309 [5]GLEESON, B., LIN, A., HEINANEN, J a kol. IP Based Virtual Private Networks. RFC 2764. Nortel Networks, 2000. [online] http://www.ietf.org/rfc/rfc2764.txt [6] OpenLDAP Software 2.3 Administrator’s Guide. University of Michigan, 1998 – 2005. [online] www.openldap.org/doc/admin23/guide.pdf [7] Kerberos V5 System Administrator’s Guide. Massachusetts Institute of Technology, 1985 – 2002. [online] http://web.mit.edu/kerberos/www/krb5-1.4/krb5-1.4/doc/krb5-admin.html [8] VERNOOIJ, J. R., TERPSTRA, J. H., CARTER, G. The Official Samba 3.2.x HOWTO and Reference Guide. [online] http://samba.org/samba/docs/man
16
