PAM a Kerberos

Obsah

Úvod

PAM (pluggable authentication modules)

Konfigurace PAM

Struktura a místo uložení konfiguračních souborů se může na jednotlivých systémech lišit. Původě se nastavení ukládalo v jedniném souboru /etc/pam.conf. V poslední době se však prosazuje používání adresáře s jenotlivými konfiguračními soubory (RedHat, Debian), které se nachází ve složce /etc/pam.d/

Položky v konfiguračních souborech PAM jsou strukturovány takto:

module-type	control-flag   		module-path   				arguments


Příklad souboru /etc/pam.d/rlogin na RedHatu6.0:

#%PAM-1.0

auth       	required	/lib/security/pam_securetty.so

auth       	sufficient      /lib/security/pam_rhosts_auth.so

auth       	required	/lib/security/pam_pwdb.so 		shadow nullok

auth       	required	/lib/security/pam_nologin.so

account    	required	/lib/security/pam_pwdb.so

password   	required	/lib/security/pam_cracklib.so

password   	required	/lib/security/pam_pwdb.so 		nullok use_authtok md5 shadow

session    	required	/lib/security/pam_pwdb.so

(při použití jediného konfiguračního souboru /etc/pam.conf se před module-type uvádí ještě service-name)

Základní moduly PAM

pam_unix.so

Tento modul poskytuje klasickou Unixovou autentizaci, správu hesel a nastavení uživatelských účtů. Využívá standardní systémová volání pro zjišťování a nastavování hesla a informací týkajících se účtu. Modul je napojen na /etc/shadow a /etc/passwd.

account
Nastavuje pravidla pro platnost uživatelského účtu a hesla, má schopnost nabádat ke změně hesla nebo dokonce může změnu hesla vyžadovat. Přímá spojitost se soubory /etc/passwd a /etc/shadow .

Argumenty: audit, debug.

auth
Tato část modulu porovnává uživatelské heslo s databázemi hesel. Konfigurace této komponenty se provádí v /etc/nsswitch.conf. Pomocný program unix_chkpwd umožňuje komponentě přístup pro čtení do chráněných databází aniž by musel mít celý modul práva superuživatele.

Argumenty: audit, debug, nodelay, nullok, try_first_pass, use_first_pass.

password
Tato komponenta umožňuje měnit uživatelské heslo. Ve spojitosti s modulem pam_cracklib.so můžeme tuto komponentu využívat pro kontrolu bezpečnosti hesla.

Argumenty: audit, bigcrypt, debug, md5, nis, not_set_pass, nullok, remember, try_first_pass, use_authtok, and use_first_pass.

session
Tato součást modulu zaznamenává na začátku a na konci relace (přihlášení a odhlášení) jméno uživatele a typ relace do systémového logu (syslog). Tato komponenta nevyužívá žádné další argumenty.

argumenty

• audit -- Obsáhlejší forma debugu
• bigcrypt -- Použítí DEC "C2" rozšíření ve funkci crypt().
• debug -- Ukládání informací do systémového logu (syslog)
• md5 -- Použití md5 kódování namísto funkce crypt().
• nis -- Použití (Network Information Service) hesel.
• nodelay -- Standardně se při chybě modulu čeká jendu sekundu. Toto nastavení ruší čekání.
• not_set_pass -- Nepoužívat hesla z jiných modulů ve skupině. Nepředá nové heslo ostatním modulům ve skupině.
• nullok -- Standardně se při přihlašování považuje zadaní prázdného hesla za neúspěšnou autentizaci. Tento argument toto pravidlo ruší.
• remember (remember=n) -- Uloží n posledních hesel, aby se zamezilo uživateli v jejich dalších změnách.
• try_first_pass -- Použije se heslo z předchozího modulu ve skupině auth, a požádá uživatele o zadání hesla pokud původně získané heslo bylo prázdné nebo chybné.
• use_authtok -- Nastaví heslo na hodnotu zadanou předcházejícím modulem.
• use_first_pass -- Použije výsledek předcházejícího modulu ve skupině auth, nežádá uživatele o zadání hesla, ohlásí selhání pokud získaný výsledek bylo selhání.

pam_warn.so

Tento modul ukládá informace o pokusu o přihlášení nebo o pokusu o změnu hesla do systémového logu (syslog).

Tento modul nepodporuje žádné argumenty a umožnuje použití pouze komponent auth a password.

pam_deny.so

Tento modul blokuje přístup k aplikaci. Jako komponenta auth nebo account, brání uživatelům v přihlášení nebo vytvoření účtu. Jako komponenta password zakazuje uživatelům měnit si heslo. Jako komponenta session, může být ve skupině s moduly typu pam_motd.so, které zobrazují zprávy a brání uživateli ve spuštění shellu.

Tento modul nepodporuje žádné argumenty, a zároveň podporuje všechny komponenty. Opačnou funkci zastává modul pam_permit.so.

pam_nologin.so

Poskytuje standardní Unixovou autentizaci s využítím nologin. Pokdu existuje soubor /etc/nologin, má do systému přístup pouze superuživatel a ostatním uživatelům se ukáže obsah /etc/nologin. Tento modul uspěje, pokud soubor /etc/nologin není v odpovídajícím adresáři přítomen.

Tento modul nepodporuje žádné argumenty, a podporuje pouze komponentu auth. Měl by být ve všech konfiguracích a metodách přihlášení zahrnut jako required, a to před jakýmkoliv modulem sufficient.

Kerberos

Kerberós měl tři hlavy, hady ovinuté kolem šíje a ocas končící dračí hlavou. Bdělý strážce podsvětní Hádovy říše; pouze jediný Héraklés vyvedl Kerbera na světlo dne, když ho z příkazu krále Eurysthea přivedl do Mykén.

Kerberos je systém pro autentizaci uživatelů a služeb v rámci sítě. Základním předpokladem, z něhož jeho koncepce vychází je, že síť není bezpečnou zónou pro volný pohyb informací. Data zasílaná po síti mohu být kupříkladu odposlouchávána a pozměňována a síťové adresy mohou být falšovány. Proto nemůžeme považovat autentizaci pomocí těchto prostředků za důvěryhodnou.

Kerberos je důvěryhodná autorita zprostředkovávající komunikaci dvou stran. To znamená, že zde existuje důvěryhodná třetí strana (server Kerberos), která je považována všemi účastníky (principals) síťové komunikace (uživatelé a služby) za důvěryhodnou a která dohlíží nad jejich vzájemnou komunikací. Všichni komunikující účastníci sdílejí tajné heslo neboli klíč s Kerberos serverem a pomocí tohoto klíče si mohou ověřit, zda jsou zprávy přicházející z kerberos serveru autentické. Pokud tímto způsobem důvěřují účastníci Kerberos serveru, mohou se ověřovat i navzájem mezi sebou.

Kerberos v datech

Princip ověřování v systému Kerberos

(Následuje popis autentizačního mechanizmu Kerberos verze 4, která se od aktuální verze 5 liší jen minimálně)

V systému Kerberos využívají účastníci lístky (tickets), pomocí kterých prokazují, že jsou těmi, za něž se vydávají. V následujícím příkladě je A iniciátor spojení a vysílá požadavek na B, což  je služba , kterou chce A využít.

Pokud chce A získat lístek pro službu B, musí zaslat žádost o lístek na kerberos server. Žádost obsahuje jména účastníků A a B (plus další doplňkové údaje). Kerberos server si ověří, zda jsou A a B platnými účastníky.

Potom, co server ověří pravost účastníků, vytvoří paket, který bude obsahovat jména A a B, síťovou adresu A (A <adresa>), aktuální čas (t <čas podání>), dobu platnosti lístku (platnost) a tajný klíč relace (session key K<AB>). Tento paket bude zakódován tajným heslem B (K<B>). Samotný lístek (T <AB>)bude vypadat  takto: ({A, B, A<adresa>, t <čas vydání >, platnost, K<AB>}K<B>).

Odpověď účastníkovi A se bude skládat z lístku (T<AB>), jména B, aktuálního času, platnosti lístku a klíče relace, vše zakódované pomocí  tajného klíče A ({B, t<čas vydání >, platnost , K<AB>, T<AB>}K<A>). A si zprávu rozluští a uchová pro pozdější využití.

Předtím, než zašle A zprávu  B, vytvoří ověřovací zprávu (authenticator), která se skládá ze jména A, adresy A, aktuálního času, a  kontrolního součtu, který A zvolí  – to vše se zakóduje tajným klíčem relace ({A, A<adresa>, t<aktuální čas>, kontrolní součet}K<AB>). Tyto údaje se spolu s lístkem, který účastník obdržel od kerberos serveru, zašlou entitě B. Po přijetí těchto dat B dekóduje lístek pomocí svého tajného klíče. Protože lístek obsahuje klíč relace, může nyní B dekódovat ověřovací zprávu, která byla pomocí něj zakódována. Aby si B nyní ověřil, že A je opravdu A, musí porovnat obsah lístku s obsahem ověřovací zprávy. Pokud údaje souhlasí, bude B považovat A za řádně ověřené.

Příklady možných útoků

Vydávání se za A

Neseriózní strana C může zachytit ověřovací zprávu a lístek během jejich cesty po síti a začít se s jejich pomocí vydávat za A. Síťová adresa v lístku a ověřovací zprávě slouží k tomu, aby se takovým situacím předcházelo a útok tohoto typu byl mnohem obtížnější. Z toho důvodu by uživatel C musel být buďto na stejném počítači jako A, nebo by musel zfalšovat zdrojové adresy paketů ze svého počítače. Protože je v ověřovací zprávě zahrnuta časová známka, nemá C mnoho času, aby svůj útok provedl.

Vydávání se za B

C se může zmocnit síťové adresy B a když A zašle požadavek k ověření, C bude předstírat, že ho autorizoval. C si však nemůže být nikdy jist, že opravdu komunikuje s A.

Způsoby jak čelit útokům

Na straně serveru by bylo možné zavést tzv. replay cache. Princip tohoto řešení je v tom, že by se ukládaly ověřovací zprávy zaslané během poslední doby, takže by B mohlo zjistit, že se někdo snaží znovu zaslat jíž použitou ověřovací zprávu. Toto řešení je poměrně nepraktické (hlavně co se týče efektivity), a není součástí Kerberosu 4, MIT Kerberos 5 však tuto funkci obsahuje.

Pro ověření B, by mohlo A požadovat od B zpětné zaslání nějakého důkazu o tom, že má B přístup ke klíči relace. Například by mohlo jít o kontrolní součet který vytvořilo A jako součást ověřovací zprávy. Typicky se to řeší tak, že B připočte ke kontrolnímu součtu jedničku, zakóduje výsledek pomocí klíče relace a pošle vše zpět A. Tomuto procesu se říká vzájemné ověření.

Klíč relace lze také použít pro přidání kryptografických kontrolních součtů ke zprávám posílaným mezi A a B (což se nazývá celistvost, integrita zprávy). Může se též přidat šifrovaní (utajení zprávy). To je asi nejlepší postup jak se chránit ve všech případech útoků.

Zdroje