Keberos je autentizačný systém so súkromnými kľúčmi a dôveryhodnou treťou stranou. Z toho vyplývajú určité výhody aj nevýhody v porovnaní s autentizačnými systémami s verejnými kľúčmi a certifikáciou. Hlavné výhody protokolov ako SSL spočívajú v tom, že pre ich fungovanie nie je nevyhnutná tretia strana a že dokážu vytvoriť bezpečné spojenie aj keď komunikujúce strany nezdieľajú spoločné tajomstvo. Tieto vlastnosti ich predurčujú na idealné použitie pre aplikácie ako je bezpečná komunikácia na webe, kde sa očakáva veľká skupina dopredu neznámych užívateľov. Takýto model prináša so sebou aj niekoľko problémov. Stornovanie kompromitovaných kľúčov je komplikované a ťažkopádne. Buď je nutné aby boli medzi všetky relevantné servery pravidelne distribuované a následne uchovávané zoznamy neplatných kľúčov alebo servery musia overovať prichádzajúce užívateľské certifikáty voči revokačnému serveru. V druhom prípade sa revokačný server stáva kritickou treťou stranou, čím systém s verejným kľúčom prichádza o jednu zo svojich hlavných výhod. Oproti tomu kľúče Kerbera možu byť kedykoľvek zablokované bez zásahu klientov a serverov a stanú sa nepoužiteľné hneď po vypršaní lístkov. Ďalšou slabinou je bezpečnosť asymetrických súkromných kľúčov. Užívateľom pridelené certifikáty musia byť uložené na disku a aj keď sú chránené šifrovaním, predstavujú určité bezpečnostné riziko oproti užívateľským heslám Kerbera, ktoré nemusia byť ukladané vôbec. Kerberos je tiež otvorený štadard, ktorý sa neviaže na žiadne patenty, na rozdiel od spomínaného SSL. Jeho výhodou je aj pomerne veľká miera flexibility v používaní rôznych autentizačných technológií. Vďaka existencií všeobecného šifrovacieho rozhrania stačí vcelku jednoducho pozmeniť AS a TGS, aby podporovali napríklad algoritmus špecifickej smart karty a Kerberos ho bude schopný používať so štandardnými lístkami a s akoukoľvek kerberizovanou aplikáciou, kým situácia pri SSL je opať komplikovanejšia (nutné upraviť všetky aplikácie).
Kerberos v podstate slúži na centralizáciu databáz hesiel, čo sa prejavuje hlavne zvýšenou bezpečnosťou siete, jednoduchšou správou užívateľských kont a zníženými prevádzkovým nákladmi (teda prináša výhody hlavne na strane správcov a nie užívateľov). Medzi nepríjemné vlastnosti patrí spominaný single point of failure a niektoré neštandardizované operácie (zmena hesiel) v rôznych impelmentáciách. Hlavný spôsob kompromitácie infraštruktúry Kerbera je útok na KDC server. Ak útočník získa prístup na koreňový server, bude mať k dispozícií datábazu zašifrovaných kľúčov a bude schopný pozmeniť software aj konfiguračné súbory. Kompromitácia KDC znamená kompromitáciu celej príslušnej oblasti. Klasickými metódami sú hádanie hesiel a znovupoužitie lístkov. Na zachytený lístok sa dá zaútočiť brute-force hádaním hesla. Ďalším nebezpečenstvom je kompromitácia pracovnej stanice. Keberos predpokláda, že beží na bezpečných staniciach spojených nebezpečnou sieťou. Ak je úspešný útok na stanicu, kde sú uložené lístky pre viacerých užívateľov, útočník sa potom dokáže vydávať za každého z nich, ale len po dobu životnosti týchto lístkov. Slabým miestom bezpečnosti sú zastaralé implementácie Kerbera založené na jeho štvrtej verzií, ktorá trpí problémami s rizikovým DES šifrovaním (Kerberos 5 používa 3-DES v móde CBC), slabou ochranou voči znovupoužitiu autentifikátorou a v originálnej implementácií aj zneužiteľnými buffer overflowmi. Podstatné pre bezpečnosť Kerbera sú tiež silné heslá.
Kerberos vznikol na MIT ako súčasť projektu Athena. Tento projekt vznikol v roku 1983 a jeho cieľom bolo vytvoriť pre užívateľov jednotné pracovné prostredie nezávislé na použitom hardware a ktoré by bolo maximálne škálovateľné (až 10 000 pracovných staníc). Verzia 1, 2 a 3 bola určená pre internú potrebu MIT. Od verzie 4 je Kerberos verejne dostupný pod licenciou podobnou BSD, ale vláda USA zakázala jeho distribúciu do zahraničia, pretože obsahoval implementáciu kryptografického algoritmu DES. Preto vznikla v Kráľovskom technologickom inžtitúte (Kungliga Tekniska Högskolan) v Stockholme alternatívna implementácia Kerbera 4 - KTH-KRB. Je založená na osekanej verzii MIT Kerbera, ktorá neobsahuje kryptografické funkcie. Heimdal, implementácia Kerbera 5, bola vydaná prakticky tou istou skupinou ľudí ako KTH-KRB.
Kerberos pre autentizáciu dokáže použiť nasledujúci software:
Podpora Kerbera v aplikáciách nie je vždy jednoznačná. Na základnej úrovni znamená overenie nešifrovaného hesla voči databáze, čo môže a nemusí byť bezpečné. V prípade lokálneho overovania je tento postup v poriadku, v prípade verifikácie príkazom PASS na POP3 servery sa heslo prenáša po sieti nezabezpečené. Dôveryhodný spôsob overenia možno očakávať len vtedy, ak proces prebehol na základe použitého TGT lístka na získanie lístka pre službu. Ďalšia úroveň podpory je skutočne kerberizovaná aplikácia, ktorá používa lístky na overenie identity a šifrovanie dát. Napríklad AFS používa lístky pri každom prístupe k súborom a bez platného lístka s nimi nie je možné nijakým spôsobom manipulovať. Pred použitím softwareu podporujúceho Kerberos je vhodné si overiť akú úroveň podpory poskytuje a či je dostatočna pre požadovaný účel. Všetky služby, ktoré su súčasťou distribúcie MIT implementácie Kerbera sú plne kerberizované.
Kerberos funguje na princípe prideľovania tzv. lístkov (tickets), pomocou ktorých sa preukazuje identita užívateľov. V sieti existuje tzv. Centrum distribúcie kľúčov (Key Distribution Center, KDC), ktoré sa skladá z dvoch logických častí:
Kerberos si udržuje databázu tajných kľúčov. Každý klient alebo server v sieti zdieľa s Kerberom tajnú informáciu - kľúč. Na základe znalosti tohto kľúča sa preukazuje totožnosť užívateľov. Ak chce klient komunikovať so serverom, Kerberos vygeneruje jednorázový 'session key', ktorý sa použije na zabezpečenie spojenia medzi klientom a serverom.
Podrobnejší popis procesu autentizácie:
TGT a pridelené lístky expirujú v definovanom čase, takže klient musí občas žiadať o obnovenie lístka (ticket renewal). Pomocou TGT lístka klient získava lístky na konkrétne služby od konkrétnych serverov. Prideľovanie týchto dalších lístkov je z hľadiska užívateľa transparentné a nevyžaduje od neho žiadnu dodatočnú interakciu.
Kerberos pracuje s administratívnou doménou zvanou realm. Realm obsahuje údaje o tzv. principáloch, čo sú vlastne užívatelia (klienti) a servery, ktorí sa budú chcieť navzájom autentizovať. Údaje o principáloch sú uložené v databáze. Každý užívateľ Kerbera musí mať v databáze svoj záznam a tieto záznamy sú asociované s konkrétnym realmom. Realmov môže byť viac a sú definované v konfiguračnom súbore.
Príklad jednoduchého konfiguračného súboru:
$ cat /etc/krb5.conf
[libdefaults]
default_realm = LAB.FI.MUNI.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
[appdefaults]
dns_lookup_kdc = false
dns_lookup_realm = false
[realms]
LAB.FI.MUNI.CZ = {
kdc = speo_beta.lab.fi.muni.cz:88
admin_server = speo_beta.lab.fi.muni.cz:749
}
[domain_realm]
.lab.fi.muni.cz = LAB.FI.MUNI.CZ
lab.fi.muni.cz = LAB.FI.MUNI.CZ
[logging]
kdc = SYSLOG
admin_server = SYSLOG
default = SYSLOG Ďalšie možné sekcie sú [kdc] a [kadmin], ktoré definujú nastavenie KDC a administratívneho servera. Názvy realmov sa podľa konvencie píšu veľkými písmenami a mali by sa zhodovať s doménovým názvom, ak neexistuje pádny dôvod prečo by tomu malo byť inak. Ak sa zhoduje názov realmu s doménovým názvom, v ktorom máme Kerbera, nemusíme uvádzať sekcie [libdefaults] a [domain_realm]. Ak máme v DNS SRV záznam pre náš realm alebo CNAME záznam v tvare kerberos.my.realm, môžeme vynechať aj sekciu [realm]. Toto chovanie tiež ovplivňujú parametre dns_lookup_kdc a dns_lookup_realm. Viac informacií o konfigurácii DNS je v manuáli Kerbera.
Teraz môžeme vytvoriť databázu, ktorá skladuje údaje o principáloch.
Implicitne je databáza uložená vo /var/heimdal, ale
v konfiguračnom súbore sa dá cesta predefinovať.
Príkazom kstash sa vygeneruje nový master-key, ktorým bude šifrovaná
databáza. Heslo sa zároveň uloží do /var/heimdal/m-key. Práve tento
súbor by sme mali zálohovať, pretože bez neho je nám databáza k
ničomu.
$ mkdir /var/heimdal $ kstash Master key: Verifying password - Master key:Pustíme program kadmin na lokálnu databázu (prepínač -l) a inicializujeme náš realm príkazom init. Nového principála pridáme príkazom add. Ak chceme spravovať iný realm ako defaultný, môžme použiť prepínač -r REALM.
$ kadmin -l kadmin> init LAB.FI.MUNI.CZ Realm max ticket life [unlimited]: Realm max renewable ticket life [unlimited]: kadmin> add janko_mrkvicka Max ticket life [1 day]: Max renewable life [1 week]: Principal expiration time [never]: Password expiration time [never]: Attributes []: janko_mrkvicka@LAB.FI.MUNI.CZ's Password: Verifying - janko_mrkvicka@LAB.FI.MUNI.CZ's Password:Ďalšie príkazy:
Ak máme databázu vytvorenú, môžeme spustiť démonov kdc a kadmind a skúsiť požiadať o TGT:
$ kinit janko_mrkvicka
janko_mrkvicka@LAB.FI.MUNI.CZ's Password:
$ klist
Credentials cache: FILE:/tmp/krb5cc_0
Principal: janko_mrkvicka@LAB.FI.MUNI.CZ
Issued Expires Principal
Mar 10 09:21:21 Mar 10 09:31:21 krbtgt/LAB.FI.MUNI.CZ@LAB.FI.MUNI.CZ
Ak chceme na serveri používať autentizáciu pomocou Kerbera, musíme
ho správne nastaviť. K tomu potrebujeme dostať na server
konfiguračný súbor /etc/krb5.conf a súbor /etc/krb5.keytab.
krb5.keytab obsahuje názov principála (názov servera v databáze
Kerbera) a svoj tajný kľúč. Kľúč je tajná informácia, takže tento
súbor by mal mať reštriktívne prístupové práva.
kadmin> add --random-key host/my.host.name Max ticket life [unlimited]: Max renewable life [unlimited]: Attributes []: kadmin> ext host/my.host.name kadmin> exitPríkaz ext bez parametrov extrahuje keytab do súboru /etc/krb5.keytab. Pomocou parametru je možné špecifikovať iný cieľový súbor.
Stačí na klienta skopírovať súbor /etc/krb5.conf a možeme používať
kerberizované programy (kinit, klist...)
Niekedy je vhodné mať záložné (slave) servery s bežiacim serverom v prípade, že hlavný server prestane fungovať. Je preto žiadúce, aby všetky servery mali rovnakú databázu, čo dosiahneme pomocou replikácie. Na replikáciu databázy slúžia programy hprop a hpropd. hpropd je spúšťaný na slave serveroch zvyčajne démonom inetd. Aby replikácia fungovala, musi byť v databáze na každom slave serveri principál hprop. Existuje tiež inkrementálna replikácia, keď sa na slave servery posielajú len zmeny. Popis nastavenia replikácie je v manuáli.
Čo sa stane, ak klient potrebuje komunikovať so serverom z iného realmu? Lokálny KDC nemá prístup ku kľúčom cudzieho realmu, takže nemôze bezpečne vygenerovať "Client-server session key".
Tento problém sa rieši tak, že klient si od svojho lokálneho KDC vypýta TGT platné v cudzom realme. Lokálne KDC sa spojí s cudzím KDC a získa TGT, ktore pošle klientovi. Klient následne môže požadovať od cudzieho KDC lístky k serverom v cudzom realme. Aby tento mechanizmus fungoval, zúčastnené realmy si musia doverovat. Je možná jednosmerná alebo obojsmerná dovera.
Presný postup konfigurácie je uvedený v manuáli, v podstate spočíva v pridaní špeciálnych pomenovaných principálov do oboch realmov.
PAM (Pluggable Authentication Modules) je sada knižníc, ktorá integruje viaceré nízko-úrovňové autentizačné mechanizmy do jedného API. Použitie stabilného API pomáha oddeliť detaily a spôsob autentizácie od programu, ktorý potrebuje overovať totožnosť užívateľov.
Pôvodne bol PAM vyvinutý v Sun Microsystems. V súčasnosti je podporovaný vo vačšine UNIXových systémov, napr. AIX, HP-UX, Solaris, Linux, FreeBSD, MacOS X a NetBSD. Pokiaľ viem, tak nie je podporovaný v Slackware a OpenBSD.
Keďže PAM uplatňuje modulárny princíp, je jednoduché napríklad pridať nový spôsob autentizácie (čítačku odtlačkov prstov)
či zmeniť spôsob autentizácie v nejakom programe (chcem overovať heslá pomocou Kerbera namiesto /etc/shadow).
Celý systém sa skladá z troch súčastí:
libpam - oproti nej sú linkované programy, ktoré chcú PAM využívať/lib/security (Solaris a niektoré UNIXy /usr/lib/security) a do pamäte sú zavádzané dynamickyKeďže PAM je vo väčšine linuxových distribúcii už predinštalovaný, nebudem tu popisovať, ako ho do systému nainštalovať, a rovno sa vrhneme na konfiguráciu.
Konfigurácia PAMu je uložená v súbore /etc/pam.conf alebo rozdelená do viacerých súborov v adresári /etc/pam.d. Ak tento adresár existuje,
súbor pam.conf sa ignoruje. Dovolím si tvrdiť, že z dôvodu prehľadnosti sa používa väčšinou varianta s /etc/pam.d.
Konfiguračný súbor /etc/pam.conf obsahuje riadky v tvare:
service type control module-path module-args
Syntax súborov v /etc/pam.d/ je rovnaká, až na pole service. Toto pole sa neuvádza a namiesto neho sa použije názov konfiguračného súboru.
Každý riadok predstavuje pravidlo, ktoré sa uplatní pri autentizácii v programe service. Čo konkrétne treba uviesť do tohoto poľa (resp. ako pomenovať konfiguračný súbor)
už závisí na onom programe, zväčša to býva práve názov programu. Ak v poli service použijeme kľúčové slovo other, nastavíme implicitné správanie pre ostatné programy. Z
bezpečnostných dôvodov sa tu používa len modul pam_deny.so, ktorý užívateľovi prístup zakáže.
Pravidlá sa samozrejme môžu reťaziť, čím dosiahneme kombinácie rôznych autentizačných mechanizmov. K slovu sa dostávajú postupne tak, ako sú za sebou zapísané.
Pole type musí obsahovať jedno z kľúčových slov account, auth, password a session. Každé z nich pokrýva jeden z aspektov autentizačného procesu. Ich význam je nasledovný:
Pole control určuje, aký vplyv má modul na prebiehajúci autentizačný proces. Môže nadobúdať tieto hodnoty:
Pole control môže obsahovať i relatívne nové kľúčové slovo include, ktoré spôsobí vloženie pravidiel zo súboru špecifikovaného v poli module-path. To nám umožňuje vložiť spoločné nastavenia do jediného súboru, takže pri zmene stačí upraviť len tento súbor.
Do poľa module-path sa uvádza cesta k modulu. Táto cesta môže byť buď absolútna, alebo relatívna vzhľadom k adresári, v ktorom sú PAM moduly (väčšinou /lib/security).
V poslednom poli module-args sa nachádzajú parametre modulu. Tie môžu byť pre každý modul iné, zistiť sa dajú v dokumentácii daného modulu. Väčšina modulov podporuje parameter debug, ktorý spôsobí podrobnejší výpis do systémového logu.
Moduly, ktoré vyžadujú po užívateľovi heslo, tiež zvyknú podporovať parametre try_first_pass a use_first_pass. Rozdiel medzi nimi je v tom, že try_first_pass sa snaží použiť heslo od niektorého z predchádzajúcich modulov a v prípade, že žiadne neexistuje, si ho vyžiada od užívateľa. Parameter use_first_pass naopak od užívateľa heslo nežiada a rovno zlyhá.
Väčšina modulov má svoju manuálovú stránku, v ktorej je popísaná činnosť modulu a podporované parametre.