Autentizační metody v operačních systémech typu Linux a UNIX

Vysoká škola ekonomická v Praze Fakulta informatiky a statistiky Vyšší odborná škola informačních služeb v Praze

Pavlína Chmelová

Autentizační metody v operačních systémech typu Linux a UNIX Bakalářská práce

2010

Prohlášení Prohlašuji, že jsem bakalářskou práci na téma Autentizační metody v operačních systémech typu Linux a UNIX zpracovala samostatně a použila pouze zdrojů, které cituji a uvádím v seznamu použité literatury. V Praze dne 14.5.2010

Pavlína Chmelová

PODĚKOVÁNÍ Ráda bych poděkovala touto cestou především mému vedoucímu bakalářské práce, panu RNDr. Tomáši Jeníčkovi, Dr. za jeho cenné rady, ochotu, vstřícnost a trpělivost při vedení této bakalářské práce. V neposlední řadě bych chtěla poděkovat svým rodičům, bez jejichž trpělivosti a ochoty bych tuto práci nemohla dokončit.

OBSAH 1. ÚVOD ..................................................................................................................................................... 4 2. ZÁKLADNÍ POJMY............................................................................................................................. 5 3. POPIS AUTENTIZAČNÍCH METOD................................................................................................ 7 3.1. AUTENTIZACE HESLEM...................................................................................................................... 7 3.2. AUTENTIZACE PŘEDMĚTEM ............................................................................................................... 9 3.2.1.

OTP tokeny ........................................................................................................................ 10

3.2.2.

Čipové karty (Smart Cards) ............................................................................................... 11

3.2.3.

USB tokeny........................................................................................................................ 12

3.3. BIOMETRICKÁ AUTENTIZACE ........................................................................................................... 13 3.3.1.

Verifikace otisku prstu ....................................................................................................... 16

3.3.2.

Verifikace hlasu ................................................................................................................. 18

3.3.3.

Verifikace podpisu ............................................................................................................. 18

3.3.4.

Verifikace oka.................................................................................................................... 19

3.3.5.

Verifikace ruky .................................................................................................................. 22

4. INTERNÍ AUTENTIZACE ................................................................................................................ 23 4.1. UŽIVATELSKÁ JMÉNA A HESLA ........................................................................................................ 23 4.1.1.

Uživatel .............................................................................................................................. 24

4.1.2.

Skupina .............................................................................................................................. 24

4.1.3.

Heslo a hašovací funkce..................................................................................................... 25

4.2. KERBEROS....................................................................................................................................... 26 4.2.1.

Autentizační proces............................................................................................................ 27

4.2.2.

Problémy systému Kerberos .............................................................................................. 30

4.3. NIS ................................................................................................................................................. 32 4.3.1.

Mapy .................................................................................................................................. 32

4.3.2.

NIS doména ....................................................................................................................... 34

4.4. LDAP ............................................................................................................................................. 35 4.4.1.

Adresářové služby.............................................................................................................. 35

4.4.2.

Protokol LDAP .................................................................................................................. 37

4.4.3.

Informační model............................................................................................................... 38

4.4.4.

Jmenný model .................................................................................................................... 41

4.4.5.

Funkční model ................................................................................................................... 42

4.4.6.

Bezpečnostní model ........................................................................................................... 45

4.4.7.

LDIF................................................................................................................................... 46

4.4.8.

Autentizace pomocí LDAP ................................................................................................ 48

-1-

5. IMPLEMENTACE LDAP .................................................................................................................. 50 5.1. INSTALACE ...................................................................................................................................... 50 5.2. KONFIGURACE ................................................................................................................................. 51 5.3. TVORBA OBSAHU ............................................................................................................................. 56 5.4. ZMĚNA OBSAHU .............................................................................................................................. 58 6. ZABEZPEČOVACÍ POLITIKA........................................................................................................ 60 6.1. VÝVOJ BEZPEČNOSTNÍ POLITIKY ...................................................................................................... 60 6.2. ZABEZPEČENÍ FYZICKÉHO PŘÍSTUPU ................................................................................................ 61 6.3. ZABEZPEČENÍ POČÍTAČOVÉHO SYSTÉMU ......................................................................................... 62 6.3.1.

Práce s elektronickou poštou.............................................................................................. 62

6.3.2.

Práce na internetu............................................................................................................... 63

6.4. ZABEZPEČENÍ INFORMACÍ ................................................................................................................ 64 6.5. EKONOMICKÉ A PRÁVNÍ ZABEZPEČENÍ............................................................................................. 64 6.6. POČÍTAČOVÁ KRIMINALITA ............................................................................................................. 64 6.6.1.

Přesměrování portů ............................................................................................................ 64

6.6.2.

Man-in-the-middle attack................................................................................................... 65

6.6.3.

DoS útoky .......................................................................................................................... 65

6.6.4.

Malicious code attacks ....................................................................................................... 66

7. ZÁVĚR ................................................................................................................................................. 68

-2-

ABSTRAKT Cílem práce je vytvořit ucelený přehled nejběžnějších autentizačních metod, které se používají na systémech typu Linux a UNIX se zaměřením na LDAP protokol. Jednotlivé metody jsou popsány a porovnány z hlediska jejich složitosti implementaci a bezpečnosti. U protokolu LDAP je popsána reálná implementace tohoto protokolu do systému včetně využití LDAP jako autentizačního mechanismu. Klíčová slova: autentizace, LDAP, Kerberos, šifrování, adresářové služby.

ABSTRACT The aim of the project is to create a comprehensive overview of the most common authentication methods used on systems like Linux and UNIX, with a focus on the LDAP protocol. The various methods are described and compared in terms of their complexity of implementation and security. The LDAP is described by a real implementation of this Protocol to the system including the use of LDAP as an authentication mechanism. Keywords: Authentication, LDAP, Kerberos, Cryptography, Directory Services

-3-

1. ÚVOD Snahou této práce je vytvořit ucelený přehled nejpoužívanějších autentizačních metod, které mohou být použity v systémech typu Unix a Linux. Zaměříme se zejména na standardizovaný protokol LDAP a využití adresářových služeb v praxi. V dnešní době je nejčastějším požadavkem, aby

systém byl zapojen do veřejné

informační sítě = Internetu. Snad každá firma potřebuje, aby byla ve veřejné síti (Internetu) „viděna“. Veřejná síť je však považována za síť nezabezpečenou. Je tedy nezbytné rozdělit přístup k systému tak, aby se všichni uživatelé z lokální podčásti systému mohli připojit do sítě veřejné, ale připojení v opačném směru aby bylo možné teprve tehdy, pokud uživatel prokáže, že má oprávnění se k danému systému (službě systému) připojit. Nejčastěji přitom také musí prokázat svou identitu. Autentizace je tak základním prvek bezpečnosti každého informačního systému či počítačové sítě. Každý administrátor si uvědomuje, že je nutné omezit přístup k informačnímu systému tak, aby se do něj nemohla dostat nepovolaná osoba či potencionální útočník, který by odtud mohl odcizit informace nebo znemožnit správný chod systému. Proto se zavádějí různé autentizační mechanismy umožňující kontrolu toho, zda je uživatel oprávněn k danému systému se přihlásit a jaké jeho služby může využívat. Autentizační metody lze odstupňovat dle jejich bezpečnosti. Platí tu však přímá úměrnost - čím bezpečnější autentizační mechanismus, tím dražší a nebo komplikovanější je jeho implementace a správa. Proto se používají kombinace těchto mechanismů, které zvyšují odolnost proti útoku a zároveň vzájemně kompenzují své nedostatky.

-4-

2. ZÁKLADNÍ POJMY Identifikace – Proces, který určuje identitu subjektu nebo objektu. Autentizace – Je to proces ověřování identity uživatele, který přistupuje k systému. Systém tedy ověřuje, zda se jedná opravdu o uživatele, který má oprávněný vstoupit do informačního systému. Autentizační systém – Systém, který má prostředky pro ověření oprávněnosti uživatelů a zároveň umožňuje řídit přístup k systému. Autorizace – Proces přiřazení oprávnění uživateli pro určitou činnost na základě autentizace. Počítačová síť – Označení pro technické prostředky, které realizují datová spojení a výměnu informací mezi jednotlivými počítači Heslo – Jedná se o skupinu písmen, číslic a dalších zvláštních znaků, které se uživatel snaží držet v tajnosti. Heslo je jedním z elementů, jimiž uživatel prokazuje svoji identitu. PIN – (Personal Identification Number) Jedná se o jedinečný identifikátor, pomocí kterého je možné se autentizovat. PIN se skládá pouze z číslic. Token – Jedná se o předmět či zařízení, který se používá při autentizace a potvrzuje identitu svého vlastníka. Biometrie – Vědní obor, který se zabývá rozpoznáváním živých organizmů na základě jejich jedinečných biologických (nejčastěji morfologických) vlastností. Distribuovaný systém – Technický termín, který označuje síť, která má jeden nebo více síťových serverů a jednu nebo více síťových pracovních stanic.

-5-

Bezpečnostní politika – Bezpečnostní politika je struktura pravidel a algoritmů, jejímž cílem je zajistit požadovanou úroveň bezpečnosti systému a současně definovat způsoby a typy oprávnění přístupu jednotlivých uživatelů k systému, respektive jeho službám. Hash – Specifický algoritmický produkt, nejčastěji ve formě řetězce znaků. Speciální algoritmus přiřadí vstupnímu řetězci výstupní řetězec. Přiřazení výstupního řetězce ke vstupnímu je jednoznačné.

-6-

3. POPIS AUTENTIZAČNÍCH METOD Jak již bylo řečeno v předchozí kapitole, autentizace je proces, kterým se ověřuje identita uživatele. Je proto nedílnou a důležitou součástí bezpečnostní politiky každého systému. Autentizační proces může být založen na několika základních skutečnostech: •

uživatel něco zná (například heslo),

•

uživatel něco má (autentizační předmět – čipovou kartu),

•

uživatel něčím je (je schopen poskytnout adekvátní biometrickou informaci).

Z těchto jednotlivých skutečností pak vycházejí základní metody, které se při autentizaci používají: 1. autentizace heslem 2. autentizace předmětem 3. biometrická autentizace Aby se co nejvíce kompenzovaly výhody a nevýhody, jsou jednotlivé metody mezi sebou často kombinovány. Mluvíme pak o autentizaci vícefaktorové. V případě, že jsou kombinovány 2 metody, jde o autentizaci dvoufaktorovou (například PIN s čipovou kartou) atd. Po autentizaci obvykle následuje fáze autorizace, v níž se již autentikovanému uživateli přiděluje určité oprávnění pro práci s daným systémem. Jednotlivé autentizační metody jsou blíže popsány v následujících kapitolách.

3.1. AUTENTIZACE HESLEM Autentizace s použitím hesla je jednou z nejjednodušších a zřejmě i nejpoužívanějších metod autentizace. Bohužel je potřeba říci, že i jednou z nejméně bezpečných. Pokud se chce uživatel přihlásit k nějakému zabezpečenému systému, musí většinou zadat tajné heslo. Toto tajné heslo je zahashováno a porovnáno s hashem, který je

-7-

uložen na autentizačním serveru. Heslo si buď uživatel vytvoří sám nebo je mu vygenerováno pomocí generátoru kódů. Když si uživatel má možnost vytvořit heslo sám, má obvykle tendenci si vymýšlet hesla lehce zapamatovatelná. Vzniká tak potenciální bezpečností „díra“ pro útok na systém. Na druhou stranu, pokud je uživateli heslo přiděleno, nezřídka si je někam poznamená, protože bývá špatně zapamatovatelné. Heslo je pak sice dostatečně bezpečné, ale uživatel není schopen si ho zapamatovat a tudíž ho „dává“ k dispozici např. na papíře potenciálnímu útočníkovi. Při tvorbě a používání hesla by měl uživatel nebo administrátor systému dodržovat určité zásady a to zejména: •

Minimální délka hesla by měla činit alespoň 8 znaků. Takovéto heslo je považováno za relativně silné. Čím více znaků použijeme, tím je heslo bezpečnější.

•

Heslo by mělo obsahovat kombinaci čísel, velkých a malých písmen a také zvláštní symbolů jako jsou například + , > < $ % & * atd.

•

Heslo by se mělo dát těžko odhadnout. Nemělo by vycházet z obecně známé věci o vlastníkovi. Máme zde na mysli hesla typu jméno dcery, telefonní číslo, datum narození, místo bydliště, jméno psa a podobně.

•

Nemělo by jít o běžnou frázi či slovo, aby heslo nemohlo být rozluštěno pomocí slovníkového útoku.

•

Uživatel by neměl mít heslo nikde napsané a neměl by ho za žádnou cenu sdělovat další osobě, a to ani v případě, že se jedná o manžela, přítelkyni či kamaráda.

•

Heslo by mělo být periodicky obměňováno.

Je vidět, že požadavky na heslo jsou velmi vysoké. Při dodržování těchto základních zásad však může uživatel minimalizovat úspěšnost eventuálního

útoku. Důležitou

součástí bezpečnosti systému je i kvalitní zabezpečení databáze z hesly a její důsledná správa s dodržením všech pravidel předem definované bezpečnostní politiky.

-8-

Autentizace za pomoci hesla má několik zásadních nevýhod. 1. Pokud není heslo dostatečně zabezpečené a nemá vhodnou strukturu, může dojít k tomu, že ho neoprávněná osoba použije pro útok na systém. Problém hesel je v tom, že mohou být odpozorovatelná. Což znamená, že ve chvíli, kdy uživatel zadává heslo a například neumí psát všemi deseti prsty, dochází k tomu, že heslo píše pomalu a jiná osoba v jeho blízkosti, ho může odpozorovat. 2. Dalším problémem může být obsahová stránka hesla. Lidé si často jako heslo dávají obecně známé informace. Stačí si tedy zjistit základní údaje o uživateli (datum narození, telefonní číslo, bydliště, jména dětí, atd.) a postupně tyto údaje vyzkoušet – s případnými obměnami - jako heslo. 3. Dalším důležitým problémem je možný slovníkový útok. Pokud uživatel má jako heslo zadané obyčejné, běžně používané slovo, pro neoprávněnou osobu není problém pomocí slovníkové databáze toto slovo identifikovat. Taková operace je překvapivě časově nenáročná. Dalším možnost odchycení hesla nastává při přenosu hesla mezi cílovými uzly. Proto by heslo mělo být přenášeno v nečitelné podobě. Na druhou stranu má tento druh autentizace i několik výhod. Tou nejdůležitější je jednoduchá a levná implementace, bohužel na úkor bezpečnosti. Ověření pomocí hesel je jednou z nejpoužívanějších metod autentizace vůbec.

3.2. AUTENTIZACE PŘEDMĚTEM Autentizace předmětem je založena na tom, že daný uživatel něco má – tedy vlastní nějaký fyzický předmět. Tento předmět se nazývá token a vlastník jím potvrzuje svou identitu. Vlastnosti tokenu by měly být následující: •

Token by neměl být vůbec anebo přinejmenším těžko kopírovatelný.

•

Měl by být zabezpečený proti krádeži

•

Musí nést autentizační informaci

•

Jeho použití by mělo být jednoduché

-9-

Vzhledem k tomu, že token je přenositelný, disponuje každý , kdo má k tokenu fyzický přístup a je schopen jej použít, současně i autentizační informací. Díky přenositelnosti tokenu tu nacházíme také potenciální hrozbu, a to jeho odcizení a zneužití. Pro použití tokenu je potřeba speciální komunikační (např. optické čtecí nebo bezdrátové) zařízení, které však zvyšuje nákladnost řešení. Výhodou a zároveň i nevýhodou takového tokenu je jeho přenositelnost. Díky přenositelnosti je snadno odcizitelný, a proto se používá většinou v kombinaci ještě s další metodou, aby se zabezpečilo jeho zneužití. Jedná se tedy často o vícefázovou autentizaci. Nejčastěji se v praxi můžeme setkat s následujícími tokeny: •

OTP tokeny

•

čipové karty

•

USB tokeny

3.2.1. OTP TOKENY OTP (One Time Password) tokeny jsou tzv. autentizační kalkulátory nebo je také můžeme najít pod pojmem PIN kalkulátory. Jedná ze o dvou faktorové tokeny. Znamená to tedy, že uživatel něco má (token) a zároveň něco zná (PIN). Kalkulátor pracuje tak, že pokud uživatel zadá správně PIN, kalkulátor vygeneruje jednorázové heslo, které je pak použito pro danou relaci přístupu k systému. Důležitou podmínkou je, že obě komunikující strany musí znát parametry kalkulátoru. Je to dáno tím, že z předchozího jednorázového hesla se dá pomocí těchto parametrů určit heslo následující. S ohledem na bezpečnost tak parametry nesmějí být známy třetí osobě. Autentizace probíhá tak, že klient zadá PIN a pokud je PIN správný, jeho OTP token vygeneruje jednorázový kód, který je poslán autentizačnímu serveru. Ten, jelikož zná parametry daného autentizačního kalkulátoru, vygeneruje dle parametrů také kód, který potom porovná s příchozím kódem. Pokud jsou oba kódy shodné, je klient autentizován.

- 10 -

Výhodou použití OTP tokenu je jeho bezpečnost. Jak již bylo řečeno, už jen to, že uživatel nosí svoji autentizační informaci při sobě (tedy ji vlastní), zvyšuje míru bezpečnosti. Při odcizení je token stále chráněn PIN kódem, který útočník nezná, a tudíž je pro něj token jako takový bezcenný, pokud nějakým způsobem PIN nezjistí či neuhodne. Délka a bezpečnost PINu jsou tak klíčovými faktory tohoto způsobu ověřování identity. Jedna z forem ochrany OTP tokeny spočívá v tom, že při pokusu „uhodnout“ PIN opakovaným vkládáním číselných kombinací vede k nevratnému zablokování a znefunkčnění tokenu (obvykle po třech neúspěšných pokusech).

3.2.2. ČIPOVÉ KARTY (SMART CARDS) Čipová karta je plastická destička, která má v sobě zabudovaný čip, zpravidla s jednočipovým procesorem. Tím, že je procesor zabudován v čipu, je považována čipová karta za jedno z velmi bezpečných zařízení, která umožňují autentizaci uživatele. Čipové karty dokáží provádět s uloženými či zaslanými daty různé operace jako jsou například šifrování, hashovací funkce apod. Existují dva typy čipových karet - kontaktní a bezkontaktní. Již z názvu vyplývá, že kontaktní čipová karta musí přijít do fyzického (nejčastěji elektrického) kontaktu se čtecím zařízením. Jedná se tedy o čipovou kartu, na které je vidět skupina kontaktů, zpravidla jich je osm. Tyto kontakty musí přijít do přímého styku se čtečkou čipových karet. Známe je například jako telefonní karty (tzv. SIM karty) nebo platební karty. Druhým typem karet, jak už bylo řečeno, jsou karty bezkontaktní. Tyto čipové karty se nemusejí vkládat přímo do čtečky. Uživatel je může mít v peněžence, v kapse nebo pouze zavěšené na oděvu. Bezkontaktní čipové karty používají pro spojení se čtecím zařízením tzv. elektromagnetickou indukční smyčku. Na schopnostech čipu závisí veškeré vlastnosti čipové karty. Zřejmě nejznámějším a nejpoužívanějším typem čipových karet jsou kontaktní procesorové čipové karty.

- 11 -

Obr. 1 Ukázka čipové karty

V tomto druhu karty najdeme 3 základní paměti. Jsou to paměti: •

RAM (Random Access Memory) – Paměť slouží pro dočasné uložení výsledků. Ve chvíli, kdy je karta vyjmuta z napájení, paměť je vymazána a tudíž ztrácí svůj obsah.

•

ROM (Random Only Memory) – Na této paměti je uložen operační systém a samotná aplikace karty. Paměť ROM je nepřepisovatelná, což znamená, že je pouze ke čtení.

•

EEPROM (Electrically Erasable Programmable Read Only Memory) – Tuto paměť je možno mazat a zároveň programovat. Při odpojení od napájení si stále udržuje svůj obsah. V této paměti jsou uloženy veškerá data (soubory) aplikace. Soubory většinou bývají členěny do stromové struktury a jsou zabezpečeny pomocí přístupových práv. Pokud uživatel správně zadá svůj PIN (Personal Identification Number), jsou mu tyto práva přidělena.

Čipové karty jsou často těsně spjaty s informačními systémy, které vyžadují vyšší míru zabezpečení. V takovém případě je při jejich použití vyžadován ještě jeden způsob ověření a to většinou zadáním PIN kódu. Jde tu opět o dvoufázovou autentizaci. Pokud útočník odcizí čipovou kartu, je pořád omezen tím, že nezná příslušný PIN kód. Mezitím majitel nahlásí odcizení čipové karty a karta bude zablokována i pro případ, že útočník PIN kód zjistí. Dochází zde tedy k překažení útoku a zajištění, že bezpečnost systému nebude porušena.

3.2.3. USB TOKENY Jak již bylo řečeno, token je zařízení, které nese nějakou autentizační informaci. V dnešní době jsou stále oblíbenější tzv. USB tokeny. Je to z jednoduchého důvodu: tato zařízení bez větších problémů uživatel připojí k většině dnešních počítačů či jinému

- 12 -

zařízení díky jednoduché podpoře USB rozhraní. Implementace je tedy podstatně levnější, protože není třeba žádné speciální čtecí zařízení. USB tokeny jsou konstrukčně podobné čipovým kartám. Jejich velikou výhodou je možnost generování privátních klíčů přímo v tokenu. Je to zejména výhodné v tom, že klíče se nemusí posílat přes žádný nezabezpečený kanál a tím se minimalizuje i možnost útoku. Také USB token je používán v kombinaci s dalšími autentizačními metodami, a to zejména v kombinaci s heslem, PIN kódem nebo biometrickou informací. Jak již bylo uvedeno výše, důvodem je zvýšení bezpečnosti zejména při odcizení USB tokenu.

3.3. BIOMETRICKÁ AUTENTIZACE Slovo biometrie vzniklo v řečtině a to ze slov bios (= život) a metron (= měřit). Doslova bychom tedy mohli říci „měření živého“. Biometrie (biometric) je vědní obor, který se zabývá rozpoznáváním a měřením biologických vlastností živých organizmů, především tedy člověka. Jedná se tedy rozpoznávání živých organizmů na základě jejich jedinečných vlastností. Biometrická autentizace funguje na základě automatizovaného zjišťování a porovnávání biometrických charakteristik uživatelů systému. Původně byla biometrická autentizace používána v systémech, které vyžadovaly nejvyšší míru zabezpečení. V dnešní době je ale biometrie stále rozšířenější a dostává se i do oblastí jako například bankovnictví, veřejný sektor ale i soukromá sféra. Jedná se o jednu z nejbezpečnějších možností autentizace.[13.] Mezi základní biometrické charakteristiky patří především: •

otisky prstů

•

tón a zabarvení hlasu

•

tvar ruky

•

geometrie obličeje

•

obraz sítnice

- 13 -

•

obraz duhovky

•

dynamika podpisu

Jednou z prvních fází procesu biometrické autentizace je získání a zápis tzv. etalonů. Jedná se o získání referenčních vzorků dané biometrické charakteristiky. Tyto etalony pak při autentikaci slouží jako referenční vzorky, vůči kterým jsou aktuální údaje porovnávány. Vzorky proto musí být kvalitní, aby nedošlo k autentizaci neoprávněné osoby a aby zároveň nebyla odmítnuta osoba, která má na úspěšnou verifikaci právo. Odebírá se proto více etalonů, ty jsou následně zprůměrňovány a vznikne z nich jeden reprezentativní vzorek, který je uložen do databáze, proti které je při verifikaci biometrický údaj porovnáván. Často se ve spojení s biometrickou autentizací používají ještě další autentizační metody, a to buď autentizace pomocí čipové karty nebo hesla. K danému reprezentativnímu vzorku je tedy přiřazen další identifikátor (heslo, čipová karta, PIN atd.). Druhou částí procesu autentizace je ukládání etalonů. Referenční vzorky mohou být uloženy zároveň v typově různých a topologicky různě umístěných úložištích. Různé typy a různá umístění úložišť mají však své výhody a nevýhody. Úložištěm často bývají vzdálené centrální databáze. V oblasti IT se toto řešení nabízí jako nejjednodušší. Problémem můžou ale být výpadky sítě. Jakmile přestane fungovat sít, není autentizace možná, není-li zároveň dostupné jiné, náhradní úložiště. V tomto případě je tedy potřeba zajistit ještě záložní způsob verifikace – tedy uložit etalony na jiné místo. Řešením takového problému může být uložení reprezentativních vzorků přímo v biometrickém čtecím zařízení. Výhodou takovéhoto úložiště je rychlá interakce a není nutné mít výkonné datové spojení. Mezi nevýhody lze zařadit vysokou závislost na funkčnosti daného zařízení. Pokud autentizační zařízení nebude plně fungovat, autentizace bude opět nemožná. Dalším řešením tohoto problému může být uložení biometrických informací v přenosných tokenech. Mezi největší výhody tokenů patří jeho přenosnost. Bohužel tato vlastnost musí být zahrnuta i mezi nevýhody. Uživatel se sice může autentizovat kdekoliv, protože má token stále u sebe, ale zároveň hrozí i odcizení tokenu, který je nositelem etalonu. Proto nejlepším způsobem zabezpečení autentizace je použití kombinací uvedených biometrických způsobů autentizace.

- 14 -

Dalším krokem k úspěšné autentizaci je proces verifikace. Verifikační proces je vyvolán zadáním hesla nebo PINu do systému, případně použitím tokenu. Bezprostředně po zadání těchto informací je sejmut biometrický vzorek, který je porovnán s uloženým etalonem. Pokud souhlasí heslo, PIN či token a zároveň biometrický vzorek, je uživatel úspěšně verifikován a může být přihlášen do systému. Veškeré výsledky verifikace jsou ukládány. Důležitým prvkem zabezpečení je povolený počet neúspěšných pokusů o autentizaci. Je potřeba zajistit, aby uživatel měl možnost opravit si špatně zadaný vzorek či PIN k verifikaci, avšak zároveň omezit počet možných pokusů. Tedy je potřeba říci autentizačnímu systému, kolikrát uživatel může zadat dané údaje. Pokusů však nesmí být takové množství, aby umožňovalo neoprávněným uživatelům prolomit systém. Poslední fází autentizačního procesu je ukládání výsledků verifikačního procesu. V každém autentizačním systému je důležité vést určitou evidenci verifikačních výsledků. Tyto výsledky se většinou odesílají na jiné místo v síti, případně mohou být uloženy lokálně. Výhodou síťového uložení je možnost shromažďování úplné historie výsledků autentizačních procedur. Znamená to, že všechny výsledky jsou zaznamenány a nedochází k přepisu starých údajů novými z důvodu nedostatku místa. Lze zde tedy dohledat transakce od počátku používání systému. Výkonnost autentizačního systému se měří koeficienty. Jedná se zejména o koeficient nesprávného přijetí, koeficient nesprávného odmítnutí, koeficient vyrovnané chyby. Dále to je doba zápisu etalonu a doba ověření.[16.] •

Koeficient

nesprávného

odmítnutí

(False

Rejection

Rate)

vyjadřuje

pravděpodobnost, s jakou biometrický systém odmítne oprávněnou osobu. Tato chyba nemá vliv na bezpečnost, pouze ovlivňuje spokojenost uživatele.

FRR =

N FR ∗ 100 [%] N EIA

NFR – počet chybných odmítnutí NEIA – počet všech pokusů oprávněných osob k identifikaci

- 15 -

•

Koeficient

nesprávného

přijetí

(False

Acceptance

Rate)

vyjadřuje

pravděpodobnost, s jakou biometrický systém přijme neoprávněnou osobu jako oprávněnou. Tento koeficient tedy udává míru bezpečnosti.

FAR =

N FA ∗ 100 [%] N IIA

NFA – počet chybných přijetí NIIA – počet všech pokusů neoprávněných osob k identifikaci

•

Koeficient vyrovnané chyby vyjadřuje, že k nesprávnému přijetí nebo k nesprávnému odmítnutí může dojít se stejnou pravděpodobností.

Mezi výhody biometrické autentizace tedy patří: •

vysoký stupeň bezpečnosti

•

rychlost

•

praktičnost

•

efektivnost

•

nulové provozní náklady na autentizaci

3.3.1. VERIFIKACE OTISKU PRSTU Verifikace pomocí otisku prstu je jedna z nejznámějších a v dnešní době také jedna z nejpoužívanějších biometrických metod autentizace. Metoda používání obrazců papilárních linií na vnější straně prstů se začala používat již v 19. století, kdy vznikly tzv. Galtonovy body. Jedná se o charakteristické body na prstu, které jednoznačně identifikují člověka. Na vnitřním povrchu prstů se nacházejí brázdovité útvary, které vytvářejí vlastní otisk prstu. Pro porovnání takového otisku se používají tzv. markanty. Jedná se o identifikační body, které se nacházejí v rýhách vzoru. Mezi základní rozpoznávací vzory markant patří především oblouk, smyčka a vír.

- 16 -

Obr. 2 Základní rozpoznávací vzory markant

Z použití markant potom vycházejí základní metody zachycení otisků prstů. Pokud opomineme běžné získání otisku prstu pomocí inkoustu a papíru, dostaneme se k nejpoužívanějším metodám, jako je statické či šablonové snímání. Při statickém snímání uživatel položí svůj prst na senzor bez toho, aby s ním pohyboval. Výhodou takového snímání je jeho jednoduchost. Mnohem oblíbenější a častější metodou je dnes snímání šablonováním. Uživatel přejíždí svým prstem po senzoru a ten si otisk sestavuje postupně po pruzích.

Obr. 3 Ukázka snímání šablonováním

Nevýhodou takovéhoto snímání je obtížnost získání vyhovujícího otisku a určitý návyk uživatele. Uživatel se nejprve musí osvojit správnou polohu prstu a vhodnou rychlost přejíždění nad senzorem. Tato metoda se dnes používá například na přenosných počítačích (noteboocích) pro přihlášení do operačního systému. Základní používaný algoritmus při snímání otisků prstů (markantografu) vytváří obrazec tak, že spojuje spojnice mezi nalezenými markantami. Sleduje tedy přítomnost identifikačních bodů a umístění v daném otisku. Tyto body a dané umístění poté systém porovnává se vzorem, který má uložen v databází etalonů. Pokud údaj odpovídá, uživatel je autentizován a může pracovat s daným systémem. - 17 -

Metody získání otisku prstu mají poměrně velkou přesnost. Některé dokáží dokonce rozpoznat, zda se jedná o živý nebo o mrtvý prst. Biometrická autentizace pomocí otisku prstu je dnes jednou z cenově nejdostupnějších a zároveň také nejrozšířenějších metod biometrické autentizace.

3.3.2. VERIFIKACE HLASU Verifikace hlasu využívá rozšířenou analýzu digitalizované formy hlasu. Hrají tu roli rozdíly ve tvarech hlasivek, ústní dutiny, jazyka, zubů. Díky nim je interpretace jedné věty u každého člověka odlišná. Pro ověření identity uživatele slouží uložený vzor hlasu – zpravidla se jedná o větu. Věta nese více akustických informací než samotné slovo. Každý člověk vysloví danou větu jiným hlasem a s jinou intonací. Pomocí určení těchto faktorů může systém spolehlivě určit mluvčího. Věta má velký význam i v bezpečnostní politice. Neoprávněný uživatel neví jakou větu oprávněný uživatel používá, natož aby věděl, jakou intonací ji má říci. Ve verifikaci hlasu však nastává jeden zásadní problém, a to problém okolního prostředí. I sebelepší systém stále nedokáže odstranit šum a ostatní zvuky z okolí. Verifikace proto může být někdy obtížná. Často také záleží na zdravotním stavu verifikované osoby. Pokud je člověk nastydlý, má jinou intonaci a hlavně jiný tón hlasu, což může verifikační systém také zmást a může to vést k neúspěšné autentizaci. Mezi hlavní výhody verifikace hlasu patří nižší cena, nízké hardwarové nároky, vysoká spolehlivost, rychlost, jednoduchost a naprostá nezávaznost technologie. Nevýhody jsou hlavně vliv okolního prostředí a zdravotní stav uživatele. Autentizace za pomoci hlasu se dnes začíná čím dál více uplatňovat. Používá se zejména při ověřování uživatele prostřednictvím telefonu – například v telefonním bankovnictví nebo pro vzdálený přístup do informačního systému.

3.3.3. VERIFIKACE PODPISU Pro verifikace podpisu se používá metoda dynamického podpisu. Tato metoda byla použita již v roce 1977. Využívá vlastností člověka, které se projeví, když se - 18 -

podepisuje. Pro ověření používá tedy dynamiku podpisu, provedení tahů, časování, sílu, tlak na podložku a rychlost psaní a tvar písma. Při tvorbě vzoru se používá speciální podložka se speciálním perem, která je citlivá na dotek. Technologie je tedy podobná jako u dotykových tabulí či PDA. Tato podložka zaznamenává veškeré vlastnosti podpisu v souřadnicovém systému. Osy „x“ a „y“ slouží k zachycení rychlosti a směru tahu, osa „z! slouží k zachycení tlaku na podložku.

Obr. 4 Verifikace pomocí podpisu

Tento způsob verifikace je zařazen mezi metody s vyšším stupněm bezpečnosti. Pro potencionální útočníky není problém naučit se vzhled podpisu podle obrázku, ale již nemohou z podpisu okoukat jeho dynamiku, tlak a další vlastnosti, na kterých je tato metoda založena. Implementace verifikace podpisu není vůbec složitá ani nákladná. Stačí pouze do systému přidat vhodné zařízení (PDA) a správný software. Mezi výhody tedy patří nižší náklady, spokojenost uživatelů, jednoduchost. Metoda dynamiky podpisu patří mezi méně používané biometrické metody autentizace, i když pro uživatele patří k jedněm z nejoblíbenějších. Je to dáno tím, že jsou již zvyklí se na některých místech podepisovat podle vzoru, i když ne elektronicky. Tato metoda se používá nejčastěji v bankovním sektoru.

3.3.4. VERIFIKACE OKA Mezi verifikace oka patří dvě metody. Jedná se o verifikace sítnice a verifikaci duhovky. Každá z těchto metod má svoje výhody a nevýhody. Nicméně oba druhy verifikace jsou považovány za jedny z nejbezpečnějších metod vůbec.

- 19 -

3.3.4.1. VERIFIKACE SÍTNICE Sítnice je vlastním orgánem zraku. Jedná se o tenkou vrstvu, která zevnitř pokrývá oční stěnu. Sítnice má vlastně stejnou funkci jako film ve fotoaparátu. Jejím úkolem je snímat světelné signály, které přicházejí na sítnici skrz čočku. Pomocí těchto signálů zachycuje obraz, který poté posílá pomocí zrakových nervů do mozku. Na vnitřní straně sítnice najdeme fotoreceptorické buňky, které jsou děleny na čípky a tyčinky. Najdeme zde také tzv. slepou skvrnu, na které čípky a tyčinky úplně chybí. Biometrická technika verifikace sítnice zkoumá okolí slepé skvrny oka a to tak, že používá zdroj světla s nízkou intenzitou záření ve spojení s optoelektronickým systémem. Obraz je poté převeden do vzorku, který má délku cca 40 bitů. Tento vzorek je porovnávám se vzorky v referenční databázi. Verifikace sítnice je pro uživatele nepříjemnou záležitostí. Za prvé se uživatel musí dívat do přesně vymezeného bodu a zda druhé musí mít těsný kontakt se snímacím zařízením. Tato metoda je proto nevhodná pro lidi s brýlemi a pro ty, jimž vadí těsný kontakt. Mezi výhody patří nejvyšší míra bezpečnosti, vysoká spolehlivost, obtížná napodobitelnost. Nevýhodami je vyšší cena zařízení, nepříjemnost uživatelů. Díky těmto nevýhodám je tento způsob verifikace málo využívaný. Používá se pouze na místech, kde je nutná nejvyšší míra zabezpečení. 3.3.4.2. VERIFIKACE DUHOVKY Duhovka je orgán v oku, který odděluje s čočkou přední a zadní komoru oční. Hlavní funkcí duhovky je funkce světelné clony a ohraničení předního a zadního segmentu oka. Barva duhovky závisí na množství pigmentu a skladbě duhovkové tkáně. Každý člověk má tedy jedinečnou duhovku, a proto ho lze podle duhovky rozpoznat. Zajímavostí je, že člověk má obě duhovky oka rozdílné.

- 20 -

Obr. 5 Rozdělení duhovky

Verifikace duhovky patří k novějším metodám biometrické autentizace. Vznikla teprve v roce 1994 v USA. Stejně jako u verifikace sítnice je i tato metoda jednou z nejspolehlivějších a nejbezpečnějších metod vůbec. Pro snímání duhovky stačí mít kvalitní digitální kameru s vysokým rozlišením a infračervené světlo. Pro mapování duhovky se používají tzv. fázorové diagramy. V těchto diagramech se nacházejí informace o četnosti, orientaci a pozici specifických plošek. Tyto informace jsou poté použity pro vytvoření duhové mapy a šablony pro identifikaci.

Obr. 6 Duhová mapa a šablona pro identifikaci duhovky

Při ověřování uživatele se tedy srovnává sejmutá duhová mapa s referenční duhovou mapou, která je uložena v databázi. Pro uživatele je snímání duhovky příjemnější metoda než snímání sítnice. Je to proto, že nepřicházejí do těsného kontaktu se snímacím zařízením. Za výhody lze tedy považovat příjemnost pro uživatele, vysokou bezpečnost, vysokou spolehlivost. Největší nevýhodou je vyšší cena a menší zkušenost s tímto způsobem verifikace. Vzhledem k tomu, že se jedná o poměrně nový systém ověřování uživatele, lze usuzovat, že ho čeká ještě velký rozvoj.

- 21 -

3.3.5. VERIFIKACE RUKY Metoda verifikace podle geometrie ruky je jednou z nejstarších metod biometrické verifikace. Již v roce 1985 byla tato metoda patentována a v roce 1986 byla již komerčně využívána. Při této metodě se měří fyzikální charakteristiky ruky a prstů a to z třídimensionální perspektivy. Na ruce je snímána její délka, šířka, tloušťka a povrch. Ruka musí být položena na podložce s 5 speciálně umístěnými kolíky a je snímána CCD kamerou.

Obr. 7 Verifikace ruky

Snímaná data poté systém redukuje na 9 bitové jednotky. Tato metoda je tedy výhodná pro systémy, které nemají velkou paměťovou kapacitu. Uživatel tedy musí vložit ruku do speciálního optického zařízení, které mu udělá snímek ruky. Data, která zjistí ze snímku jsou vyhodnocena a poté porovnávána s databází vzorků. Tento způsob verifikace není vhodný pro osoby, které mají revmatické ruce nebo podobné poruchy. Systémy s verifikací geometrie ruky patří k bezpečným systémům, protože verifikace pomocí geometrie ruky je unikátní. Vhodný je zejména u organizací, které nemají vysoké požadavky na bezpečnost a do systému má přístup větší množství uživatelů. Nejčastěji se tento způsob ověření používá u docházkových a přístupových systémů.

- 22 -

4. INTERNÍ AUTENTIZACE 4.1. UŽIVATELSKÁ JMÉNA A HESLA S uživatelskými jmény a hesly přichází běžný uživatel do styku téměř denně. Jedná se o nejjednodušší způsob autentizace. Autentizace pomocí uživatelských jmen a hesel se používá většinou v kombinaci s jednou z metod, které jsou uvedeny v dalších kapitolách interní autentizace. Pro tvorbu uživatelských jmen a hesel se používají dvě metody. Buď si jméno a heslo uživatel vymyslí sám nebo jsou mu vygenerovány. Oba tyto způsoby, jejich výhody a nevýhody jsou již popsány v kapitole 3.1. Při autentizaci za pomoci uživatelského jména a hesla v operačních systémech typu Linux a Unix se lze setkat s následujícími pojmy.
Uživatel (user) – Uživatel je osoba, která je schopná interaktivně využívat možností počítače.
UID (user ID) – Celé číslo, které jednoznačně identifikuje uživatele v systému typu Linux a Unix.
Uživatelské jméno (username) – Jméno, pod nímž se uživatel přihlašuje do systému.
Skupina (group) – Množina uživatelů, kteří potřebují sdílet společná data.
GID (group ID) – Celé číslo, které jednoznačně identifikuje skupinu v systému typu Linux a Unix
Heslo (password) – Druh bezpečnostního opatření, které zpřístupňuje dané prostředky pouze osobám, které toto heslo znají. V principu je heslo vždy spřaženo s uživatelským jménem.
Hešování (hashing) – Jedna z metod indexace databáze založená na použití hashovací funkce. Hashovací funkce přiřazuje každému klíči nějaký číselný kód, který ukazuje buď přímo pozici klíče v databázi nebo alespoň pozici pro dohledání za pomoci jiné metody.

- 23 -

4.1.1. UŽIVATEL Každý člověk, který je přihlášen do systému, je jeho uživatelem. V případě operačního systému Linux je tento uživatel (user) identifikován podle jednoznačného uživatelského jména a jedinečného čísla tzv. UID (User ID number). Oba údaje musí být v systému naprosto unikátní. Uživatelská jména a UID se ukládají do úložišť různých typů. V nejjednodušším případě je lze v operačním systému Linux nalézt v souboru /etc/passwd. Dříve se do tohoto souboru ukládala i hesla, ale od této metody se časem ustoupilo kvůli zajištění větší bezpečnosti. Tento soubor zahrnuje i skutečné jméno uživatele a jeho domovský adresář. Dalším důležitým souborem v námi uvažovaném nejjednodušším případě ukládání autentizačních informací je soubor /etc/shadow, do kterého se zapisují veškerá hesla uživatelů, a to v hashované podobě. Hesla tak nejsou čitelná. Tento soubor má nastavena přístupová práva pouze pro čtení s výjimkou speciálního uživatele, který jako jediný má právo do souboru i zapisovat. Znamená to, že běžný uživatel ho nemůže upravovat, respektive může ho upravovat pouze v přísně vymezeném případě – při změně vlastního hesla. V tomto případě uživatel získá oprávnění změnit položku v daném souboru.

4.1.2. SKUPINA Občas potřebují různí uživatelé společně používat - sdílet některé soubory. Přidělení přístupových práv k těmto datům každému jednotlivému uživateli zvlášť by bylo příliš složité, a proto nám systémy typu Linux a Unix nabízí jednoduchý nástroj – uživatelské skupiny. Uživatelé mohou být přidány do jedné skupiny, členství v této skupině jim pak přidělí určitá práva k daným datům. Každý uživatel systému je členem nejméně jedné skupiny (group). Každá skupina je označena jedinečným identifikačním číslem, tzv. GID. Seznam všech skupin včetně jejich GID se opět v námi uvažovaném nejjednodušším případě nachází v souboru /etc/groups.

- 24 -

Výchozí stav je ten, že uživatel náleží do privátní skupiny, které má stejné jméno jako je jeho username; systém tuto speciální skupinu vytváří automaticky při přidání uživatele do systému. Primární skupiny jsou důležité, protože soubor vytvořený uživatelem automaticky dědí oprávnění privátní skupiny. Uživatel může být přidán ještě do tzv. sekundární skupiny či skupin, ty mu udělují další práva k souborům a adresářům, které může sdílet s ostatními členy skupiny.

4.1.3. HESLO A HAŠOVACÍ FUNKCE Každé uživatelské jméno je těsně svázáno s heslem. Toto heslo je uloženo v autentizačním úložišti, kterým může být kupř. soubor na lokálním souborovém systému nebo databáze na vzdáleném síťovém serveru dostupná pomocí definovaného autentizačního protokolu, apod.. Je ovšem jasné, že heslo nemůže být uloženo v čitelné podobě, ta by byla lehce zneužitelná. Proto se využívá při ukládání hesla do databáze hashovací funkce. Výstup hashovací funkce se nazývá otisk, hash či výtah. Hashovací funkce vezme řetězec, ze kterého se heslo skládá, a transformuje ho na řetězec s pevnou délkou, který je pak uložen do databáze autentizačního serveru (tento termín používáme v širším významu i pro lokálně uložené autentizační údaje). Konečná velikost hashe je velmi malá, což je výhodné zejména z důvodu úspory místa na autentizačním serveru. Výhodou hashovací funkce je její jednocestnost. Znamená to, že pokud se k hashovaným heslům dostane útočník, je téměř nemožné, aby z nich zjistil původní řetězec znaků. Při autentizaci uživatel tedy zadá své uživatelské jméno a heslo, které je hashovací funkcí převedeno do otisku. Výsledný hash je potom porovnán s otiskem, který je uložen v databázi autentizačního serveru. Pokud otisk odpovídá, uživatel je úspěšně autentizován.

- 25 -

4.2. KERBEROS Kerberos je síťový autentizační protokol, který dovoluje jednotlivým uzlům sítě komunikaci přes nezabezpečenou síť a to tak, že si vzájemně prokáží svoji identitu a to zabezpečeným způsobem. Tento protokol byl vyvinut v Massachusetts Institute of Technology při projektu Athena v letech 1983 až 1991. Cílem projektu bylo vyvinout autentizační a autorizační postup, který by bezpečným způsobem ověřoval identitu a přiděloval přístupová práva, aniž by přitom bylo nutné přes potenciálně nezabezpečenou síťovou infrastrukturu přenášet jakákoli citlivá data, zejména hesla. Kerberos zabezpečoval síťové služby, které poskytoval projekt Athena. Své jméno získal podle antického trojhlavého psa, který hlídal bránu do podsvětí. [22.] Kerberos používá jako základ symetrický Needham-Schroeder protokol, který využívá důvěru ve třetí stranu, tzv. Key distribution center (KDC). KDC obsahuje dvě logické části a těmi jsou:


autentikační server (Authentication Server)




Ticket Granting Server

Kerberos tedy pracuje na základě tzv. ticketů, které slouží k ověření identity uživatele. Znamená to tedy, že Key distribution center udržuje databázi tajných klíčů každého uživatele v síti. Sdílený klíč (například heslo) zná tedy pouze uživatel a Key distribution center. Pro komunikaci mezi serverem a klientem generuje KDC tzv. session key, který je použit pro bezpečnou komunikaci. Jedná se o systém, jehož základem je jeden zabezpečený počítač, na kterém jsou uloženy veškeré autentizační údaje. Jde tedy zejména o hesla, uživatele, přístupová práva další důležité údaje. Tento zabezpečený počítač se nazývá důvěryhodný server a pracuje s distribuovanými systémy. Zabezpečení systému provozujícího službu KDC tak logicky určuje zabezpečení všech dalších přístupů a služeb v infrastruktuře distribuovaného systému.

- 26 -

Distribuovaný systém je technicky definován jako síť, která má jeden nebo více síťových serverů a jednu nebo více síťových pracovních stanic. Jedná se zejména o nezabezpečené počítače. Mezi základní charakteristiky Kerberosu patří: •

existuje pouze jeden důvěryhodný server,

•

systém pracuje s omezeným počtem běžných počítačů,

•

pro řízení přístupu je používán lístek (ticket = šifrovaný soubor),

•

Kerberos používá tzv. principal names, které jednoznačně identifikují uživatele,

•

oblast, kterou spravuje důvěryhodný server, se nazývá říše (realm names).

Kerberos je velmi sofistikovaný autentizační systém, který nabízí široké bezpečností služby, a to nejen pro sítě unixového typu, nýbrž i pro sítě využívající systémy a protokoly MS Windows.

4.2.1. AUTENTIZAČNÍ PROCES Důvěryhodný server má jako jediný počítač právo autentizovat uživatele. Tato autentizace je podmínkou zahájení jakékoli další síťové transakce. Existují dvě metody, jak může autentizační server ověřit klientovu identitu. První metoda je následující: 1. Klient si chce otevřít soubor, který má uložen na síťovém disku na serveru, který je zabezpečen proti přístupu neoprávněných uživatelů. Je tedy nutné, aby se uživatel autentizoval. Klient tedy musí požádat autentizační server, o pověření k serveru, na kterém se nachází daný soubor. Žádá tedy autentizační server o lístek a šifrovací klíč. Klient tedy zašle požadavek pro přístup k souboru přímo autentizačnímu serveru a to tak, že ho nejdříve podepíše svým privátním klíčem a poté ho zašifruje pomocí veřejného klíče důvěryhodného serveru.

- 27 -

Obr. 8 Klient vysílá zašifrovanou zprávu autentizačnímu serveru.

2. Zašifrované pověření poté odešle autentizačnímu serveru. Server tuto žádost rozšifruje pomocí svého soukromého klíče a zároveň ověří identitu klienta tím, že aplikuje klientův veřejný klíč na digitální podpis, který byl použit u pověření. Tímto způsobem se zajistí, že data jsou opravdu od klienta, který je vytvořil a nebyly cestou pozměněny třetí osobou. 3. Důvěryhodný server zkontroluje oprávnění přístupu klienta k systému a jeho identitu pomocí digitálního podpisu. 4. Pokud klient nemá oprávnění přistupovat k danému souboru, autentizační server jeho žádost zamítne. Nepřidělí mu tedy lístek. 5. Pokud klient je oprávněným uživatelem souboru, důvěryhodný server mu přidělí lístek, který zašifruje veřejným klíčem klienta. Tento lístek obsahuje další lístek pro zdrojový server a zároveň s tím i dočasný šifrovací klíč (klíč relace). Klíč relace je důležitý pro komunikaci mezi klientem a serverem, na kterém je uložen potřebný soubor.

Obr. 9 Server zašifruje lístek a odešle klientovi

6. Zároveň s posláním lístku klientovi pošle autentizační server i ticket serveru, na kterém je daný soubor uložen, ve kterém mu říká, aby akceptoval komunikaci s daným klientem. Tento lístek autentizační server zašifruje pomocí veřejného klíče potřebného serveru. - 28 -

Obr. 10 Server zašifruje lístek a odešle ho serveru.

7. Když klient obdrží lístek, spojí se serverem, na kterém je uložen potřebný soubor a vymění si vzájemně lístky. Ty jsou zašifrovány veřejným klíčem protistrany. Tyto lístky jsou navzájem porovnány a pokud jsou shodné, tak server umožní klientovi, připojit se k danému souboru. V opačném případě je přístup k souboru zamítnut.

Obr. 11 Klient s daným serverem porovnávají lístky

8. Po ukončení spojení s klientem server kontaktuje autentizační server a dá mu informaci o tom, že spojení s klientem bylo ukončeno. Důvěryhodný server tedy zruší platnost lístku, který náležel k dané relaci. Druhá metoda je považována za metodu bezpečnější. 1. Klient pošle požadavek autentizačnímu serveru jako obyčejný text. Žádá tím o tzv. lístek TGT (Ticket-Granting Ticket = lístek na přidělení lístku). Server ověřuje identitu klienta tím, že použije sdílený tajný klíč (heslo) a odešle

- 29 -

uživateli TGT lístek. TGT lístek opět obsahuje klíč relace (session key), který je důležitý pro komunikaci mezi klientem a serverem, na kterém je soubor uložen.

Obr. 12 Postup žádosti o TGT

2. Klient použije TGT lístek místo veřejného klíče k tomu, aby od autentizačního serveru získal lístek pro přístup k danému serveru. Tento ticket již obsahuje konkrétní klíč, který je potřebný ke konkrétní operaci. Což znamená, že klient může tento lístek použít pouze pro přístup k danému souboru, ale už ho nemůže použít například pro tisk.

Obr. 13 Klient posílá TGT lístek a dostává lístek pro přístup

3. Po získání ticketu klient kontaktuje potřebný server a vymění si s ním lístky. Pokud lístky souhlasí, server klientovi povolí přístup k danému souboru. Dá se tedy říci, že následující postup je již stejný jako v případě předchozí metody.

4.2.2. PROBLÉMY SYSTÉMU KERBEROS


Dostupnost autentizačního serveru: Je nutné, aby byl stále centrální server dostupný. Pokud server, na kterém je Kerberos, bude nedostupný, nikdo se nebude moci autentizovat. Tento problém lze vyřešit použitím více

- 30 -

redundantních serverů, na kterých bude nainstalovaný Kerberos, nebo eventuálním přechodem na jiný nouzovým autentizační mechanismus.


Synchronizace času: Důležitým údajem při autentizaci je čas. Kerberos požaduje po klientovi přesný čas, a proto je nutné, aby byly časové údaje na jednotlivých systémech správně synchronizovány. Pokud čas, který uživatel zašle při autentizaci, neodpovídá času na autentizačním serveru, server žádost o autentizaci zamítne. Tento problém lze vyřešit za pomoci Network Time protokolu, který umožňuji synchronizaci času podle vzdáleného serveru.




Přehrávání: Jedná se o krádež lístku, kdy hacker okopíruje lístek a díky němu může prolomit metodu šifrování, použít lístek a může se pokusit dostat se do systému jako klient, který má oprávněný přístup k systému. Z tohoto důvodu je nutné, aby klient poslal autentizačnímu serveru ještě dodatečnou informaci, která umožňuje důvěryhodnému serveru ověřit, zda se jedná o daného uživatele a zda je lístek aktuální. Takovým nástrojem je přidání časového razítka k lístku. Uživatel tedy dodatečně posílá autentizátor (informace, která ověří původ zprávy), který je zašifrován klíčem relace a je k němu přidáno časové razítko. Úkolem časového razítka je zobrazit datum a čas, kdy byl lístek vytvořen. Autentizační server má proto možnost ověřit, že zpráva s lístkem byla vytvořena nedávno a lístek tedy nebyl použit třetí osobou. Nebylo tedy přehrávání použito.




Dešifrování offline: Hacker může zaútočit ve chvíli, kdy autentizační server posílá odpověď klientovi. Jak již bylo řečeno, tato odpověď obsahuje lístek, který je zašifrovaný privátním klíčem klienta. Útočník tedy může poté za pomoci slovníkového útoku (dictionary-based attack) zjistit privátní klíč klienta a tím i dešifrovat celou zprávu.




Útok odmítnutím služby: Denial service attacks je další z hrozeb, kterým se Kerberos neumí bránit. Útočník zamezí aplikaci, aby se zúčastnila správných autentizačních kroků. Jediným řešením je správné nastavení zabezpečení, které může realizovat každý administrátor daného autentizačního serveru a jeho říše.

- 31 -

4.3. NIS Mobilita uživatelů a narůstající stupeň distribuce dat v sítích vyžadují, aby docházelo k synchronizace důležitých dat, jako jsou například informace o uživatelských účtech. Znamená to tedy, že uživatel nemá a nemusí být vázán pouze na jediný (svůj) počítač, ale může přecházet libovolně mezi všemi počítači v síti, přihlásit se k nim pod svým uživatelským jménem a tím získat přístup ke svým datům. Je tedy nutné, aby veškeré informace byly uloženy na jednom centrálním úložišti nebo aby byly z jednoho centrálního úložiště periodicky distribuovány – replikovány – na další, podřízená úložiště. Dvěma protichůdnými požadavky tu jsou možnost centrální správy určitých dat na straně jedné a jejich spolehlivá a bezpečná distribuce na straně druhé. Samozřejmě je tento systém jednodušší i pro administrátora, protože musí spravovat pouze jednu centralizovanou kopii těchto dat. Na základě uvedených důvodů vyvinula firma Sun systém Yellow pages (YP, žluté stránky). Bohužel ale tento název byl vlastnictvím anglického Telecomu, a proto firma Sun byla nucena systém přejmenovat. Vznikl tedy nový název a to NIS (Network Information System). Tento systém umožňuje definovaný síťový přístup k databázím a jmenné vyhledávání v těchto databázích Ty lze využít třeba k ukládání informací, které bývají jinak ukládány například v lokálních souborech /etc/passwd nebo /etc/hosts. Z venku tedy síť vypadá jako jeden systém s identickými účty na všech počítačích. Komunikace mezi jednotlivými systémy v síti a systémem poskytujícím údaje z databáze je postaven na architektuře klient-server. Původní iniciály Yellow Pages přežívají v názvech jednotlivých balíků a příkazů i poté, co byl tento systém přejmenován na NIS. Serverová část tak v nejčastější implementaci nese název ypserv, klientská ypbind. Funkce klientské i serverové části je postavena na portmapperu a RPC (Remote Procedure Call).

4.3.1. MAPY Systém NIS tedy umožňuje centrálně ukládat různá data. Tyto databázové informace potom uchovává ve speciálních souborech, které se nazývají mapy. Ty vždy obsahují dvě hodnoty a to klíč a hodnotu, například uživatelské jméno a k němu zašifrované - 32 -

heslo. Veškeré mapy jsou uloženy v centrálním stroji, na němž běží server NIS. Klienti za pomoci volání RPC mohou tedy tyto informace číst. Pro každý typ vyhledávacího klíče je vytvořena samostatná mapa a pro některé soubory se vytvoří několik map. V následující tabulce je ukázka hlavních map systému NIS. Hlavní mapy NIS a odpovídající soubory Hlavní soubor /etc/hosts

/etc/networks

Mapa/Mapy hosts.byname, hosts.byaddr

networks.byaddr

jména

/etc/group

group.byname, group.bygid

/etc/protocols

/usr/lib/aliases

hostitelů Mapování síťových IP adres na

passwd.byname, passwd.byuid

/etc/rpc

Mapování IP adres na jména

networks.byname,

/etc/passwd

/etc/services

Popis

Mapování hesel na uživatelská jména Mapování identifikátorů skupin na jejich názvy

services.byname,

Mapuje popis služeb na názvy

services.bynumber

služeb

rpc.byname, rpc.bynumber

Mapuje čísla Sun RPC služeb na jejich názvy

protocols.byname,

Mapuje čísla protokolů na jejich

protocols.bynumber

názvy Mapuje poštovní aliasy na jejich

mail.aliases

názvy

Některé mapy jsou zastoupeny přezdívkami. Výhodou je, že jsou kratší a lépe se tedy píší. Pokud chceme vidět, přehled přezdívek, použijeme příkaz ypcat s parametrem x. Výpis tedy může vypadat následujícím způsobem. $ ypcat -x Use ţpasswdţ for ţpasswd.bynameţ Use ţgroupţ for ţgroup.bynameţ Use ţnetworksţ for ţnetworks.byaddrţ Use ţhostsţ for ţhosts.byaddrţ Use ţprotocolsţ for ţprotocols.bynumberţ Use ţservicesţ for ţservices.bynameţ Use ţaliasesţ for ţmail.aliasesţ Use ţethersţ for ţethers.bynameţ

- 33 -

Jak již bylo řečeno, server NIS se obyčejně nazývá ypserv. Zpravidla na menší síť postačí jediný server. Pokud se jedná o síť rozsáhlejší, je vhodné rozdělit NIS server na více počítačů kvůli rozložení zátěže a zkrácení doby odezvy. Samozřejmě se musejí data těchto serverů vzájemně synchronizovat. Musí se tedy nastavit jeden hlavní NIS server tzv. master server a ostatní servery se nastaví jako slave servery. Znamená to tedy, že mapy jsou generovány pouze na hlavním serveru a odtud se periodicky nebo při jakékoli změně redistribuují na slave servery.

4.3.2. NIS DOMÉNA Systém NIS používá systém NIS domén. Jedná se skupinu hostitelů, které vzájemně sdílejí konfigurační data právě přes NIS. Tyto NIS domény nemají nic společného s doménami DNS. Plní pouze administrativní funkci a běžný uživatel ji vůbec nezaznamená. Názvy NIS domén v jedné síti musí být jedinečné. Nemůže se tedy použít stejný název pro dvě NIS domény. Častým schématem je ale logicky použití stejných doménových jmen v NIS i v DNS. Příslušnost k NIS doméně tedy určuje, jakého NIS serveru se má systém aplikace dotazovat. Každého nyní napadne, jak daná aplikace zjistí, s jakým serverem má komunikovat. Existují dva možné způsoby. Prvním využívá konfigurační soubor, ve kterém se pevně stanoví NIS server, s nímž mají aplikace komunikovat. Nicméně tento způsob nepatří mezi nejefektivnější, protože klient se může chtít přihlásit na jiném počítači, který zrovna nepoužívá stejnou NIS doménu, což znamená, že by aplikace potřebovaly komunikovat s jiným serverem. Řešením je použití tzv. NIS deamona, který se nazývá ypbind. Tento deamon umí detekovat, jaký server má aplikace v dané doméně použít. Zjistí to tak, že vysílá dotazy do sítě, a který server odpoví nejrychleji, ten je považován za nejvhodnější NIS server pro komunikace s danou aplikací. Je zde ale jeden bezpečností problém. Ypbind je spokojen s jakoukoliv odpovědí od serveru a ten považuje za důvěryhodný. Nemusí se přitom jednat o správný server, ale může jít o počítač útočníka. Proto Linux umožňuje, aby ypbind načítal servery buď dynamicky nebo přímo z konfiguračního souboru.

- 34 -

Systém NIS tedy není obecně považován za nejbezpečnější metodu pro centrální úložiště dat a autentizaci, na rozdíl od následující metody.

4.4. LDAP LDAP je zkratka pro komunikační protokol, který se nazývá Lightweight Directory Access Protocol. Jedná se o standardizovaný protokol pro adresářové služby, které používají protokol TCP/IP. Tento protokol byl původně určen pro komunikace s protokolem X.500, a vznikl jeho redukcí, odlehčením. První LDAP specifikace byla publikována v RFC 1487. [5.] Dnešní LDAP je postaveno tak, aby podporovalo různé aplikace a to jak na intranetu, tak na extranetu. Spolupracuje dobře s různými službami, které fungují na základě internetových protokolů, jako SMTP protokol, HTTP a další. Zároveň nabízí dobré administrátorské nástroje za dostupnou cenu. Stal se tak jedním z nejlepších a nejdostupnějších nástrojů pro práci s adresářovými službami.

4.4.1. ADRESÁŘOVÉ SLUŽBY Adresářové služby pracují na základě adresářů. Adresář je speciální databáze. Lidé se s adresáři setkávají denně a to například v podobě telefonních seznamů, televizního programu apod. Tyto adresáře se nazývají offline adresáře. Funkce adresářů je tedy pomoci lidem najít informace podle nějakého popisu, atributu či klíče . Údaje mohou být tříděny podle názvu, času, telefonního čísla, abecedy apod. Adresáře počítačové a „předpočítačové“ (klasický telefonní seznam, knihovní kartotéka) jsou si v mnoha případech podobné, ale mají několik zásadních rozdílů. Počítačové nazýváme online adresáře a mají několik důležitých výhod oproti offline adresářům: •

dynamičnost – lze snadno přidávat, opravovat a mazat záznamy

•

flexibilita – lze ukládat data, která jsou různého typu

•

možnost kvalitního zabezpečení – možnost použití Access Control Listů

- 35 -

•

možnost personalizace – jednoduché uchovávání nastavení přímo pro daného uživatele

S adresáři jsou těsně spjaty tzv. adresářové služby. Ty jsou primárně určeny nejprve k ukládání a posléze snadnému vyhledávání různých druhů dat. Adresářové služby lze také využít pro uložení autentizačních údajů uživatelů systému. Znamená to tedy, že adresářové servery mají vlastně možnost ověřovat, zda má uživatel oprávnění (přístupová práva) k tomu, aby použil danou službu (např. přihlášení do systému, přihlášení k e-mailové službě a další). Součásti adresářových služeb jsou: •

Informace, které jsou uloženy v adresáři

•

Software pro server, který poskytuje informace, které jsou uloženy v adresáři

•

Klientský software

•

Hardware, který je potřebný pro práci klientů a i serveru

•

Podporující software – ovladače

•

Infrastruktura sítě

•

Bezpečnostní politika

•

Software, který je nutný pro údržbu a sledování adresářových služeb

Veškeré adresářové služby běží na tzv. adresářovém serveru nebo na skupině adresářových serverů, které jsou vzájemně v definovaných vztazích - hierarchii. Tyto služby by měly být dostupné všem klientům. Mezi velkou výhodu adresářového serveru je jeho centralizovaná správa. Administrátor nemusí sahat na různé servery a spravovat data, která jsou na nich uložená. Vše je uloženo na jediném místě, a to umožňuje jednoduchý přístup k datům a tedy i jednodušší správu těchto dat. Pokud se ovšem jedná o velké množství dat, může být adresářový server poměrně vytížený. Řešením je použití tzv. replikací pro distribuci kopií dat nebo podčástí datové sady.

- 36 -

Obr. 14 Centralizace adresářových dat na jednom serveru

„Replikace je proces, který slouží pro správu a údržbu mnoha kopií dat mezi několika lokalitami.“ Tyto replikace sníží míru dotazování klientů na hlavním serveru a tedy sníží jeho celkové zatížení. Z replik lze pouze číst. Princip replikací je vhodné použít ve firmách, které mají více poboček například po celé republice. Každá pobočka by tak měla vlastní server, na kterém by se nacházely replikované adresářové služby. Pokud by replikace na daném serveru nebyla, klienti by se dotazovali přímo adresářového serveru a tím by zatěžovali jak adresářový server, tak hlavně internetovou linku.

Obr. 15 Replikované adresářové služby

4.4.2. PROTOKOL LDAP Jak již bylo řečeno, LDAP je standardizovaný komunikační protokol, který pracuje s adresářovými službami. Standardizace protokolu měla obrovskou výhodu v tom, že klientský i serverový software od různých prodejců umí vzájemně spolupracovat. LDAP standart zahrnuje 4 základní modely: [5.] 1. LDAP informační model – Definuje typy dat, které mohou být uloženy v adresářích

- 37 -

2. LDAP jmenný model – Definuje, jak jsou data organizovány a jak jsou vytvořeny odkazy na data v adresáři. 3. LDAP funkční model – Definuje, jak se k datům bude přistupovat a jak budou aktualizovány. 4. LDAP bezpečnostní model – Definuje, jak budou informace v adresářích chráněny proti neautorizovaným přístupům. LDAP protokol je protokol orientovaný na zprávy, což znamená, že klient se serverem vzájemně komunikují pomocí zpráv. Klient vytvoří LDAP zprávu - žádost pro hledání v databázi -, a tu odešle serveru. Server zpracuje žádost o pošle její výsledek opět jako sérii LDAP zpráv. Běžná komunikace mezi klientem a serverem při hledání záznamů za pomoci LDAP vypadá tedy následujícím způsobem: 1. Klient začne spojení s LDAP serverem a pošle příkaz bind (používá se pro autentizace uživatele). 2. Server musí ověřit identitu klienta a pokud ověření proběhne v pořádku, tak dojde k úspěšné autentizaci klienta a ten je tedy ověřen i pro další operace. Pokud klient není úspěšně verifikován, server s klientem ukončí spojení. 3. Uživatel vytvoří žádost a odešle ji serveru, aby byl daný záznam nalezen. 4. Server nalezne příslušný záznam a odešle ho klientovi. Pokud nalezne více záznamů, které odpovídají žádosti, pošle klientovi sérii záznamů, které nalezl. 5. Server odešle návratový kód 6. Po vyřízení operace, klient pošle serveru žádost o ukončení spojení, žádost o operaci unbind. 7. Server na tuto žádost reaguje tím, že ukončí spojení s klientem.

4.4.3. INFORMAČNÍ MODEL Informační model definuje typy dat a základní části informací, které mohou být uloženy v adresáři. LDAP informační model tedy popisuje stavbu, kterou obsahuje adresář.

- 38 -

Základní části informací uložených v adresářích jsou:


vstup (entry) – informace o objektu




atribut (attribute) – popisuje konkrétní typ objektu




typ (type) – popisuje druh informace, kterou obsahuje atribut




hodnota (value) – obsahuje konkrétní data

Důležitá jsou také syntaktická omezení jednotlivých atributů. Ta mimo jiné definují, jak adresářová služba porovnává hodnoty při hledání. Atributy jsou dále rozděleny do dvou základních skupin:


user (uživatelské) – Běžný vstupní atribut.




operational (operativní) – Speciální atributy, které jsou modifikovány. 4.4.3.1. ADRESÁŘOVÉ SCHÉMA

Některé vstupy v adresářích mají některé atributy povinné a ostatní volitelné. Například při popisu osoby jsou požadovány atributy cn (common name - jméno) a sn (surname – příjmení). Ostatní atributy jsou volitelné a nemusí být uvedeny. Veškeré informace o povinných a volitelných atributech a jejich syntaktických omezeních jsou definovány v adresářovém schématu. Adresářové schéma je sada pravidel, která určuje, co se musí nalézat v adresářových službách a jak musí adresářové servery a klienti zacházet s informacemi během adresářových operací. Schéma také určuje omezení například velikosti, formátu dat, hodnot atd. Elementy adresářového schématu jsou atributy (attributes), syntaxe atributů (attribute syntaxe) a objektové třídy (object classes).

- 39 -

•

Jak již bylo řečeno výše, adresářové záznamy obsahují sbírku atributů a jejich hodnot. Atributy obsahují specifická data jako jsou telefonní čísla, seznam klientů atd. Definice atributu v LDAP zahrnuje:


jméno, které jednoznačně identifikuje typ atributu




identifikátor objektu (OID), který jednoznačně identifikuje atribut – Jde o strukturovanou sekvenci čísel, které jsou odděleny tečkami.




indikátor, zda se do atributu může zadat pouze jedna hodnota nebo více hodnot




syntaxi mezi atributy včetně pravidel




restrikce velikosti hodnoty atributu

Jméno atributu (attribute names) obsahuje následující vlastnosti:


Ve jméně atributu se nerozlišují velká a malá písmena (CN a cn označují stejný atribut).




Jméno atributu musí začínat písmenem a je limitováno použitím ASCII.




Jméno atributu musí být v adresářové službě jedinečné.

Každý atribut má jednu nebo více hodnot (attribute values), které jsou s atributem spojené. Typ atributu ovlivňuje typ hodnoty.


Syntaxe mezi atributy přesně specifikuje, jak jsou hodnoty atributu reprezentovány a jakým způsobem jsou poté porovnávány při hledání.




Objektové třídy (Object classes) se používají jako skupiny, do kterých se řadí informace určitého typu. Slouží tedy pro popis konkrétního objektu. Každý adresářový záznam patří do jedné nebo do více objektových tříd. Jméno takovéto třídy se skládá z atributu, který umožňuje vložení více hodnot a jmenuje se objectclass. Objektové třídy se většinou skládají z několika atributů a jsou odvozeny z některé z nadřazených tříd.

- 40 -

LDAP object classes zahrnují následující informace:


jméno, které jednoznačně identifikuje třídu




OID, které jednoznačně identifikuje třídu




nastavení povolených typů atributů




typ (structural, auxiliary, abstract)

Strukturální třídy (Structural Classes) popisují základní aspekty objektů. V každém záznamu musí být minimálně jedna třída typu structural. Auxiliary classes – jedná se o třídu doplňkovou. Tato třída může být přirazena ke každému typu záznamu, podmínkou však je, že záznam musí obsahovat alespoň jednu třídu typu structural. Abstract classes – jedná se o abstraktní třídu, od které budou odvozovány nové třídy.

4.4.4. JMENNÝ MODEL Jmenný model se zaměřuje na to, jak budou data tříděna, respektive v jakých budou vzájemných vztazích a jak se k nim bude přistupovat. Ve své podstatě tak definuje datový strom – strukturu vzájemného řazení jednotlivých datových položek. Popisuje tedy typy struktur, které lze v LDAP použít. Jmenný model umožňuje data uložit tak, aby byly co nejrychleji přístupná a zároveň, aby jejich správa byla co nejjednodušší. Takovéto vlastnosti poskytuje stromová struktura, kterou LDAP používá.

Obr. 16 Typický adresářový strom

- 41 -

Jmenný model přiřazuje jednoznačné jméno každé položce v adresáři. Toto unikátní jméno se nazývá distinguished name (DN) a odkazuje na polohu položky v adresářovém stromu. Jednotlivé části jména jsou odděleny čárkami a reprezentují tak jednotlivé úrovně adresářového stromu. Jméno by tedy mohlo vypadat následujícím způsobem: dn: uid=chmelova, ou=Users, dc=archa, dc=cz Při čtení DN se nejvíce vpravo nachází odkaz na hierarchicky nejvyšší úroveň adresářového stromu, část úplně vlevo se nazývá relative distinguished name (RDN) a nese vlastně informaci o konkrétním datovém „individuu. RDN musí být tedy unikátní. Díky RDN je zajištěno, že žádné DN nebude stejné. 4.4.4.1. ALIASY Aliasy v LDAP adresáři umožňují existenci více odkazů v adresářovém stromu na jediný datový obsah. Znamená to tedy, že daný vstup nemusí být umístěn přímo fyzicky v dané hierarchii, ale může být na konkrétní místě pouze zastoupen odkazem. Aliasy tedy fungují podobně jako symbolické linky v systémech typu Unix. Pokud chceme vytvořit alias je nutné vytvořit objektovou třídu alias a přiřadit ji jméno atributu aliasedObjectName. Hodnota tohoto atributu musí být DN vstupu, na který chceme aliasem odkazovat.

4.4.5. FUNKČNÍ MODEL Funkční model popisuje operace, které jsou potřebné pro vykonávání činností LDAP protokolu. Model je rozdělen do třech základních operací. Jsou to operace dotazovací, aktualizační a autentizační a řídící. Již podle názvu kategorie poznáme, s jakou činností bude daná operace souviset. 1. operace autentizační a řídící - Patří sem operace bind, unbind, abandon. Tyto operace klientovi umožňují navázat a ukončit spojení s adresářovým serverem vůbec.

- 42 -

2. dotazovací operace – Jedná se o operace search a compare. Již podle názvu operací lze poznat, že díky těmto operacím je klient schopen se adresářového serveru dotazovat na různá data. 3. Aktualizační operace – Jde o operace add, delete, modify, modify RDN (rename). Tyto operace klientovi umožňují přidávat, upravovat a mazat záznamy, které jsou uloženy na adresářovém serveru. 4.4.5.1. AUTENTIZAČNÍ A ŘÍDÍCÍ OPERACE Mezi autentizační operace patří operace bind a unbind. Jedinou řídící operaci v LDAP je abandon. Tyto operace jsou nejdůležitější, protože bez nich by se klient nemohl připojit k adresářovému serveru. Operace ověřují identitu klienta a umožňují mu navázat fyzické spojení s adresářovým serverem. První operací, kterou klient udělá, když chce přistoupit k adresářovému serveru, je operace bind. Tato operace slouží k autentizaci uživatele. Ověřuje tedy identitu klienta. Po ověření následuje autorizace, po které uživatel může již pracovat s potřebnými daty. Práci mu však omezují přístupová práva, která mu byla po autorizaci přidělena. Operace unbind žádá adresářový server o ukončení spojení mezi ním a klientem. Po této operaci adresářový server přeruší spojení. Abandon je operace, která oznamuje adresářovému serveru, že klient chce ukončit spojení. Používá se v případě, že klient chce ukončit spojení dříve, než adresářový server splnil jeho požadavky – tedy našel potřebný záznam. 4.4.5.2. AKTUALIZAČNÍ OPERACE Jak již bylo řečeno mezi aktualizační operace patří operace add (přidání), delete (mazání), modify ( změna údajů), rename (změna DN). Operace add umožňuje přidat nový vstup do LDAP stromu. Tato operace má 2 základní parametry a těmi jsou název DN záznamu a množina atributů s jejich hodnotami. Operace delete vymaže existující záznam z adresářového serveru. Tato operace má pouze jeden parametr a tím je název DN záznamu. - 43 -

Operace rename přejmenuje DN a přesune záznam mezi jednotlivými větvemi adresářového stromu. Samozřejmě dané DN musí existovat a nové DN nesmí odpovídat již existujícímu DN jiného záznamu. Operace modify umožňuje změnit hodnotu atributů jednotlivých záznamů. Základní podmínkou pro úspěšnou operaci je opět existence daného záznamu. Obecně se doporučuje, aby veškeré aktualizační operace byli prováděny pomocí LDIF souboru (viz kapitola 4.4.7.). Je to z důvodu jednoduššího ovládání. 4.4.5.3. DOTAZOVACÍ OPERACE Dotazovací operace slouží pro vyhledávání a přenášení dat z adresáře. Nejsou to však operace pro čtení. Mezi tyto operace patří zejména operace search a compare. Operace search má za úkol vyhledávat v adresářovém stromu záznamy, které odpovídají dotazu klienta. Jako výsledek vrací jednotlivé záznamy. Tato operace má 8 vstupních parametrů: •

Bod, od kterého začíná hledat – prohledává pouze určitou část adresářové větve.

•

Oblast, kterou bude prohledávat – určuje do jaké hloubky se má adresářový strom prohledávat. Má tři parametry •

base – vrací pouze hodnotu výchozího bodu, z kterého se hledalo

•

onelevel – vrací všechny záznamy, které mají první úroveň od výchozího bodu

•

sub – vrací všechny záznamy od výchozího hledání

•

Dereference zástupců – určuje, jak se bude nakládat s aliasy

•

Limit, kolik navrácených hodnot chce uživatel vrátit – uživatel tím omezuje maximální počet záznamů.

•

Časový limit – Počet sekund, jak dlouho chce klient přijímat záznamy od adresářového serveru

•

Pouze atributy – booleovská proměnná, která určuje, zda uživatel chce vidět název či hodnotu atributů. Pokud je tedy proměnná nastavená na true, vrací se pouze seznam atributů. - 44 -

•

Filtry pro vyhledávání – vyjadřují hledané výrazy na adresářovém serveru.

•

Seznam atributů pro navrácení – klient určí atributy, které chce vypsat.

Operace compare testuje zadanou hodnotu atributu s hodnotami uloženými v záznamu na adresářovém serveru. Výsledkem této operace je pouze logická hodnota true nebo false.

4.4.6. BEZPEČNOSTNÍ MODEL Bezpečnostní model má za úkol chránit informace, které jsou uloženy na adresářovém serveru, proti neoprávněnému přístupu. Model je závislý na faktu, že LDAP je protokol orientovaný na spojení. Klient tedy otevře spojení s LDAP serverem a provádí množství operací na stejném spojení. Klient se během tohoto spojení může autentikovat proti adresářovému serveru a může díky tomu získat další privilegia. Při jednoduché autentizaci LDAP klient poskytne LDAP serveru distinguished name a heslo, které je posláno adresářovému serveru v nezašifrované podobě. LDAP server vyhledá klienta pomocí jeho DN a zkontroluje zda heslo, které mu bylo zasláno, je stejné s heslem, které se nachází v hodnotě atributu userpassword u daného DN. Pokud jsou hodnoty stejné, klient je ověřen. V opačném případě je operace autentizace neúspěšná a klientovi je vrácen error kód. LDAP používá více druhů autentizačních mechanismů. Záleží však na verzi LDAP, která je používána. 4.4.6.1. SSL A TLS SSL (Societ Security Layer) a TLS (Transport Security Layer) jsou bezpečnostní technologie, které používají šifrování všech dat, které putují mezi klientem a serverem. SSL je protokol, který byl vytvořen firmou Netscape. SSL je obecně používaný transportní bezpečnostní mechanismus, který zajišťuje bezpečnost aplikačním protokolům jako je například LDAPS. SSL je založen na šifrování pomocí veřejného klíče a tím umožňuje vysokou míru zabezpečení.

- 45 -

TLS je transportní bezpečnostní protokol. Jedná se o novější protokol, který je podobný SSL. LDAP protokol využívá standardně pro komunikaci TCP port 389. Při nechráněném spojení může útočník bez větších problémů odposlechnout komunikace na tomto portu a může ji využít pro útok na daný systém. Proto se používá zabezpečený protokol tzv. LDAPS, jehož komunikace probíhá na TCP portu 635. Tento protokol využívá zabezpečení vrstvou SSL. Jednodušší je používání protokolu TLS jako bezpečnostní vrstvy. Tento protokol pracuje se standardním portem LDAP protokolu (tedy 389), přes který se při navazování komunikace server s klientem dohodnou, jestli budou používat chráněné spojení či nikoliv. Komunikace tedy může vypadat následujícím způsobem: 1. Otevře se TCP/IP spojení mezi klientem a serverem. 2. Klient se serverem se dohodnout, že budou používat zabezpečený kanál. Spustí se tedy operace StartTLS 3. Následuje operace bind, která se spustí za pomoci dalšího zabezpečovacího mechanismu. Chránit komunikace s adresářovým serverem je velice důležité a to zejména v prostředí, kde komunikace probíhá v nedůvěryhodném prostředí jako je například Internet, protože zabezpečený kanál zamezí odposlechu komunikace třetí osobou (zamezí tedy útoku „muž uprostřed“), respektive zamezí tuto komunikace rozšifrovat. Útočník by pro rozluštění komunikace potřeboval soukromý klíč klienta nebo serveru. Je nutné tedy zabezpečit, aby klient i server používali platné digitální certifikáty typu X.509, které jsou podepsány minimálně jednou z certifikačních autorit.

4.4.7. LDIF LDIF je zkratkou pro Data Interchange Format. Jde o textový formát, který se používá při popisu adresářových záznamů. Tento formát je definován v RFC 2849. LDIF

- 46 -

umožňuje snadný transport mezi jednotlivými adresářovými servery, které používají různé databázové formáty. Při psaní LDIF souboru se používá kódování ASCII, UTF-8 nebo base64. Díky tolika rozličným způsobům kódování, lze do LDIF formátu uložit různé druhy dat jako například fotografie, obrázky, certifikáty, seznamy jmen apod. Běžně se používají dva typy LDIF souborů.


LDIF reprezentující adresářové vstupy




LDIF reprezentující úpravu hodnot atributů 4.4.7.1. LDIF REPREZENTUJÍCÍ ADRESÁŘOVÉ VSTUPY

Tento druh souboru LDIF se používá při tvorbě nového záznamu a popisuje nový vstup. Soubor musí obsahovat dvě základní části: •

distinguished name,

•

hodnoty atributů.

Na začátku prvního řádku musí být vždy použit vstup DN, který je komponován jako dn oddělné dvojtečkou a následuje distinguished name vstupu. Po DN přichází na řadu atributy vstupu. Každá hodnota atributu je od jeho názvu opět oddělena dvojtečkou. Žádný řádek v LDIF souboru nemůže mít na jedné řádce více typů atributů. Když LDIF soubor obsahuje hodnoty atributů, které nejsou v ASCII, hodnota musí být dekódována do speciálního formátu base64. Pokud jsou atributy převedeny do tohoto kódování, potom typ atributu a hodnota jsou odděleny dvěma dvojtečkami. Běžný LDIF soubor může mít např. tuto podobu: dn: uid=chmelova,ou=Users,dc=archa,dc=cz uid: chmelova cn: chmelova objectClass: account objectClass: posixAccount objectClass: top objectClass: shadowAccount shadowLastChange: 13829 shadowMin: 0

- 47 -

shadowMax: 99999 shadowWarning: 7 shadowFlag: 0 loginShell: /bin/bash uidNumber: 502 gidNumber: 503 homeDirectory: /home/chmelova gecos: Pavlina Chmelova userPassword: {crypt}!

4.4.7.2. LDIF REPREZENTUJÍCÍ ÚPRAVU HODNOT ATRIBUTŮ LDIF reprezentující úpravu hodnot atributů se používá pro úpravu jednotlivých záznamů. Pomocí LDIF souboru lze provést čtyři základní operace a to: •

Add – přidání nového vstupu

•

Delete – vymazání vstupu

•

Modify – změna existujícího vstupu

•

Rename – přejmenování existujícího vstupu

Obecně platí a doporučuje se, aby informace na adresářovém serveru byly upravovány pomocí LDIF souborů. Důvod je ten, že LDIF soubor si může každý administrátor po sobě zkontrolovat a lépe dohledat chyby. Správa pomocí LDIF souborů je tedy podstatně jednodušší a rychlejší než vkládání a upravování jednotlivých záznamů pomocí příkazů s jednotlivými parametry.

4.4.8. AUTENTIZACE POMOCÍ LDAP Jak již bylo v předešlých kapitolách mnohokrát řečeno, základním úkolem autentizace je ověření identity klienta. Uživatel svoji identitu ověřuje buď něčím, co zná nebo něčím co vlastní nebo nějakou vlastností. V případě nějaké znalosti se jedná o uživatelské jméno a heslo nebo se může jednat o digitální certifikát. V případě LDAP serveru je použita většinou právě tato první možnost. V případě použití jednoduché autentizace, jsou autentizační údaje uživatele zaslány při operaci bind. Zasílá tedy své DN a heslo. Heslo se porovnává s heslem, které je uloženo na LDAP serveru v šifrované či hashované podobě.

- 48 -

Autentizace může probíhat i přes bezpečný kanál. Při posílání autentizačních údajů je tedy použit kanál TLS/SSL. V tomto případě se jedná o dvoucestnou autentizaci. Znamená to tedy, že před začátkem samotné autentizace si klient i adresářový server vymění informace o svých digitálních certifikátech a spojí se přes zabezpečený TLS/SSL kanál. Teprve poté následuje operace bind, s kterou jsou zaslány údaje, které jsou potřebné pro autentizaci – tedy DN jméno a heslo. Při autentizaci je možné použít místo DN jména a hesla i PKI certifikáty. Tento certifikát ale musí být uložen na adresářovém serveru ve stromové struktuře a to v atributu userCertificate. Uživatel si tak ve svém tokenu vybere PKI certifikát a při jeho ověření na adresářovém serveru je nucen použít heslo, které se ověřuje proti údaji, který je uložen na adresářovém serveru. Server tedy kontroluje zda přijatý certifikát je shodný s certifikátem, který má uložený ve své adresářové struktuře. Pokud oba certifikáty jsou shodné, dojde k ověření identity uživatele.

- 49 -

5. IMPLEMENTACE LDAP Nyní si ukážeme jednoduchou implementaci LDAP. LDAP budeme instalovat v prostředí operačního systému Linux přesněji na distribuci Fedora 10 ve verzi x86_64. Cílem implementace bude nainstalovat LDAP server (OpenLDAP), vytvořit objekty (přesněji uživatele chmelova a jeho vlastní skupinu chmelova) v databázi LDAP, uživateli chmelova změnit home adresář na /home/pavlina. Pro LDAP službu bude použito schéma Samby. Je zde předpoklad, že na daném serveru již Samba běží. Samba je implementace protokolu SMB (Server Message Block). Umožňuje vzdálený přístup k souborům, které jsou uloženy na linuxových strojích, ze stanic s operačním systémem Microsoft Windows .

5.1. INSTALACE Pro instalaci LDAP jsou důležité následující balíčky, které lze nainstalovat z balíčkovacího systému distribuce. •

openldap

•

openldap-clients

•

openldap-servers

Dané balíčky nainstalujeme za pomoci příkazu yum. Příkaz bude mít podobu: [root@ntb ~]# yum install openldap openldap-clients opeldap-servers

Po úspěšné instalaci ještě zkontrolujeme, zda jsem opravdu nainstalovali vše, co je zapotřebí k instalaci OpenLDAP: [root@ntb ~]# yum list \*openldap\* Loaded plugins: dellsysidplugin2, refresh-packagekit Existing lock /var/run/yum.pid: another copy is running as pid 3454. Another app is currently holding the yum lock; waiting for it to exit... The other application is: PackageKit Memory : 29 M RSS (265 MB VSZ) Started: Fri Aug 14 18:00:29 2009 - 00:10 ago State : Sleeping, pid: 3454 Installed Packages

- 50 -

openldap.x86_64 openldap-clients.x86_64 ; openldap-servers.x86_64

2.4.12-1.fc10 2.4.12-1.fc10 2.4.12-1.fc10

installed @fedora @fedora

5.2. KONFIGURACE Konfigurace je nejdůležitější část implementace LDAP. Pokud špatně nastavíme konfigurační soubory, OpenLDAP nebude fungovat správně. Nejtěžším úkolem je zvolit vhodnou strukturu LDAP databáze. Dále je pro přístup do LDAP databáze třeba definovat přístupová práva, která se přiřazují pro jednotlivé objekty, skupiny objektů nebo atributy, aby uživatel mohl adresářovou službu využívat. Soubory, které je třeba nakonfigurovat: •

slapd.conf

•

ldap.conf

Nejprve nastavíme konfigurační soubor slapd.conf. Tento soubor konfiguruje stand alone LDAP deamona (slapd), který obsluhuje LDAP. Soubor obsahuje globální nastavení jako jsou například přístupová práva, schémata, která deamon používá, bezpečnostní restrikce, druh databáze, suffix, replikace atd. 1. V první řadě musíme upravit kořen stromu (tzv. suffix). Obecná syntaxe suffixu je: suffix „dc=my-domain,dc=com“ V našem případě bude suffix vypadat takto: suffix

"dc=archa,dc=cz"

2. Dále přidáme schéma, které je potřebné pro podporu Samby. Schéma se nalézá v instalačním

balíku

Samby

a

po

její

instalaci

ho

nalezneme

v

/usr/share/doc/samba-3.0.33/LDAP/. Nicméně slapd nemá přístup k tomuto schématu, dokud ho nepřekopírujeme do složky /etc/openldap/schema/, nepřivlastníme ho správnému uživateli a neupravíme bezpečností kontext. [root@ntb ~]# cp /usr/share/doc/samba-3.0.33/LDAP/samba.schema /etc/openldap/schema/ [root@ntb ~]# ll –Z /etc/openldap/schema/samba.schema -rw-r--r--

root root system_u:object_r:etc_t

- 51 -

corba.schema

-rw-r--r-- root root -rw-r--r-- root root -rw-r--r-- root root -rw-r--r-- root root -rw-r--r-- root root inetorgperson.schema -rw-r--r-- root root -rw-r--r-- root root -rw-r--r-- root root -rw-r--r-- root root -rw-r--r-- root root -rw-r--r-- root root -rw-r--r-- root root drwxr-xr-x root root -rw-r--r-- root root

system_u:object_r:etc_t system_u:object_r:etc_t system_u:object_r:etc_t system_u:object_r:etc_t system_u:object_r:etc_t

core.ldif core.schema cosine.schema dyngroup.schema

system_u:object_r:etc_t system_u:object_r:etc_t system_u:object_r:etc_t system_u:object_r:etc_t system_u:object_r:etc_t system_u:object_r:etc_t system_u:object_r:etc_t system_u:object_r:etc_t root:object_r:etc_t

java.schema misc.schema nis.schema openldap.ldif openldap.schema ppolicy.schema README redhat samba.schema

[root@ntb ~]# chcon –u system_u /etc/openldap/schema/samba.schema [root@ntb ~]# ll –Z /etc/openldap/schema/samba.schema -rw-r--r-- root root -rw-r--r-- root root -rw-r--r-- root root -rw-r--r-- root root -rw-r--r-- root root -rw-r--r-- root root inetorgperson.schema -rw-r--r-- root root -rw-r--r-- root root -rw-r--r-- root root -rw-r--r-- root root -rw-r--r-- root root -rw-r--r-- root root -rw-r--r-- root root drwxr-xr-x root root -rw-r--r-- root root

system_u:object_r:etc_t system_u:object_r:etc_t system_u:object_r:etc_t system_u:object_r:etc_t system_u:object_r:etc_t system_u:object_r:etc_t

corba.schema core.ldif core.schema cosine.schema dyngroup.schema

system_u:object_r:etc_t system_u:object_r:etc_t system_u:object_r:etc_t system_u:object_r:etc_t system_u:object_r:etc_t system_u:object_r:etc_t system_u:object_r:etc_t system_u:object_r:etc_t system_u:object_r:etc_t

java.schema misc.schema nis.schema openldap.ldif openldap.schema ppolicy.schema README redhat samba.schema

Pokud máme upravený bezpečnostní kontext, můžeme vložit schéma do konfiguračního souboru slapd.conf. include

/etc/openldap/schema/samba.schema

3. Musíme vytvořit superuživatele a přidělit mu heslo. Heslo můžeme napsat do konfiguračního souboru buď v holém textu nebo ho můžeme zapsat v hashované podobě. rootdn rootpw

"cn=ldapadm,dc=archa,dc=cz" {SSHA}5IBqvx/ustjllnzNmUFQvzrsEb+Ir2g6

Hashovanou podobu administrátorského hesla získáme příkazem slappasswd bez parametrů. Tento příkaz nám umožní vytvořit heslo, které zadáme a vypíše ho v hashované podobě. Hash je třeba zkopírovat do příslušné řádky v konfiguračním souboru /etc/openldap/slapd.conf - 52 -

[root@ntb ~]# slappasswd New password: Re-enter new password: {SSHA}5IBqvx/ustjllnzNmUFQvzrsEb+Ir2g6

4. Důležité je také nastavení databáze. Použijeme výchozí nastavení slapd.conf a to s databází Berkeley. Berkeley DB je databáze, kterou lze integrovat přímo do aplikací. Jedná se o velmi výkonnou databázi, která je schopná pracovat s rozsáhlými daty a obsluhovat současně velké množství klientů, a proto je vhodná pro použití v LDAP. database

bdb

Konfigurační soubor databáze najdeme ve složce /usr/share/doc/openldapservers-2.4.12/. Soubor DB_CONFIG_example musíme zkopírovat do složky /var/lib/ldap/ a přejmenovat ho na DB_CONFIG. Konfigurační soubor k databáze přivlastníme správnému uživateli – uživatel ldap. [root@ntb ~]# cp /usr/share/doc/openldap-servers2.4.12/DB_CONFIG.example /var/lib/ldap/DB_CONFIG [root@ntb ~]# chown ldap.ldap /var/lib/ldap/DB_CONFIG

Konfigurační soubor slapd.conf má nyní takovouto podobu: [root@ntb ~]# less /etc/openldap/slapd.conf # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /etc/openldap/schema/corba.schema include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/duaconf.schema include /etc/openldap/schema/dyngroup.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/java.schema include /etc/openldap/schema/misc.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/openldap.schema include /etc/openldap/schema/ppolicy.schema include /etc/openldap/schema/collective.schema include /etc/openldap/schema/samba.schema # Allow LDAPv2 client connections. allow bind_v2

This is NOT the default.

- 53 -

# Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openldap.org pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args # # # # # # # # # # # # # # # # # #

Load dynamic backend modules: modulepath /usr/lib/openldap # or /usr/lib64/openldap moduleload accesslog.la moduleload auditlog.la moduleload back_sql.la moduleload denyop.la moduleload dyngroup.la moduleload dynlist.la moduleload lastmod.la moduleload pcache.la moduleload ppolicy.la moduleload refint.la moduleload retcode.la moduleload rwm.la moduleload syncprov.la moduleload translucent.la moduleload unique.la moduleload valsort.la

# The next three lines allow use of TLS for encrypting connections using a # dummy test certificate which you can generate by changing to # /etc/pki/tls/certs, running "make slapd.pem", and fixing permissions on # slapd.pem so that the ldap user or group can read it. Your client software # may balk at self-signed certificates, however. # TLSCACertificateFile /etc/pki/tls/certs/ca-bundle.crt # TLSCertificateFile /etc/pki/tls/certs/slapd.pem # TLSCertificateKeyFile /etc/pki/tls/certs/slapd.pem # Sample security restrictions # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 63-bit encryption for simple bind # security ssf=1 update_ssf=112 simple_bind=64 # Sample access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access # Allow authenticated users read access Allow anonymous users to authenticate # Directives needed to implement policy: # access to dn.base="" by * read # access to dn.base="cn=Subschema" by * read # access to * # by self write # by users read # by anonymous auth # # if no access controls are present, the default policy

- 54 -

# allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING! ###################################################################### # ldbm and/or bdb database definitions ###################################################################### database bdb #suffix "dc=my-domain,dc=com" checkpoint 1024 15 #rootdn "cn=Manager,dc=my-domain,dc=com" suffix "dc=archa,dc=cz" rootdn "cn=ldapadm,dc=archa,dc=cz" # Cleartext passwords, especially for the rootdn, should # be avoided. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. # rootpw secret # rootpw {crypt}ijFYNcSNctBYg rootpw {SSHA}5IBqvx/ustjllnzNmUFQvzrsEb+Ir2g6 # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /var/lib/ldap # Indices to maintain for this database index objectClass index ou,cn,mail,surname,givenname index uidNumber,gidNumber,loginShell index uid,memberUid index nisMapName,nisMapEntry

eq,pres eq,pres,sub eq,pres eq,pres,sub eq,pres,sub

# Replicas of this database #replogfile /var/lib/ldap/openldap-master-replog #replica host=ldap-1.example.com:389 starttls=critical # bindmethod=sasl saslmech=GSSAPI # authcId=host/[email protected] # enable monitoring database monitor # allow onlu rootdn to read the monitor access to * by dn.exact="cn=ldapadm,dc=archa,dc=cz" read by * none

Pokud jsme s konfigurací hotovi, je třeba udělat konfigurační test, ve kterém nás shell upozorní na případné chyby, které máme v konfiguračním souboru. [root@ntb ~]# service ldap configtest

Pokud nejsou nalezeny žádné chyby konfigurační soubor je syntakticky v pořádku. - 55 -

Nyní si nastavíme konfigurační soubor ldap.conf, který najdeme v /etc/openldap/. V něm konfigurujeme základní nastavení pro běh klienta LDAP. Jedná se zejména o výchozí DN, specifikujeme URI LDAP serveru, můžeme specifikovat porty pro připojení k LDAP serveru atd. Konfigurační soubor ldap.conf bude vypadat následujícím způsobem: # #LDAP Defaults # # See ldap.conf(5) for details # This file should be world readable but not world writable. #BASE dc=example, dc=com #URI ldap://ldap.example.com ldap://ldap-master.example.com:666 #SIZELIMIT 12 #TIMELIMIT 15 #DEREF never URI ldap://127.0.0.1/ BASE dc=archa,dc=cz #BASE dc=example,dc=com TLS_CACERTDIR /etc/openldap/cacerts

Nyní máme veškerou konfiguraci hotovou a můžeme spustit LDAP deamona a to příkazem: root@ntb ~]# service ldap start Spouštím slapd:

[

OK

]

Nyní máme již spuštěný funkční LDAP server, ale neobsahuje žádné záznamy.

5.3. TVORBA OBSAHU V této části přidáme do LDAP databáze objekty, které následně budeme modifikovat. Jak již bylo řečeno v předchozích kapitolách, nejjednodušším způsobem, jak vkládat data do LDAP je použití LDIF souboru. Do LDAP databáze vložíme nového uživatele (Users) a novou skupinu (Groups). Nejdříve však musíme vytvořit kořenový objekt, objekt Users, který bude obsahovat seznam uživatelů a objekt Groups, který bude obsahovat seznam skupin uživatelů.

- 56 -

Veškeré tyto vstupy můžeme napsat do jednoho LDIF souboru, který bude vypadat následovně: [root@ntb ~]# vim obsah.ldif dn: dc=archa,dc=cz objectClass: dcObject objectClass: organization dc: archa o: archa dn: ou=Users,dc=archa,dc=cz objectClass: organizationalUnit ou: Users dn: ou=Groups,dc=archa,dc=cz objectClass: organizationalUnit ou: Groups dn: cn=chmelova,ou=Groups,dc=archa,dc=cz objectClass: posixGroup objectClass: top cn: chmelova userPassword: {crypt}x gidNumber: 503 dn: uid=chmelova,ou=Users,dc=archa,dc=cz uid: chmelova cn: chmelova objectClass: account objectClass: posixAccount objectClass: top objectClass: shadowAccount shadowLastChange: 13829 shadowMin: 0 shadowMax: 99999 shadowWarning: 7 shadowFlag: 0 loginShell: /bin/bash uidNumber: 502 gidNumber: 503 homeDirectory: /home/chmelova gecos: Pavlina Chmelova userPassword: {crypt}!

LDIF soubor uložíme a přidáme ho do LDAP databáze za pomoci příkazu ldapadd: [root@ntb ~]# ldapadd -x -W -D "cn=ldapadm,dc=archa,dc=cz" -f obsah.ldif Enter LDAP adding new adding new adding new adding new adding new

Password: entry "dc=archa,dc=cz" entry "ou=Users,dc=archa,dc=cz" entry "ou=Groups,dc=archa,dc=cz" entry "cn=chmelova,ou=Groups,dc=archa,dc=cz" entry "uid=chmelova,ou=Users,dc=archa,dc=cz

- 57 -

Nyní si zkusíme nalézt uživatele chmelova pomocí příkazu ldapsearch. Zkontrolujeme si tak, že data se opravdu zapsala do databáze. [root@ntb ~]# ldapsearch -x -W -D "cn=ldapadm,dc=archa,dc=cz" -b "uid=chmelova,ou=Users,dc=archa,dc=cz" Enter LDAP Password: # extended LDIF # # LDAPv3 # base with scope subtree # filter: (objectclass=*) # requesting: ALL # # chmelova, Users, archa.cz dn: uid=chmelova,ou=Users,dc=archa,dc=cz uid: chmelova cn: chmelova objectClass: account objectClass: posixAccount objectClass: top objectClass: shadowAccount shadowLastChange: 13829 shadowMin: 0 shadowMax: 99999 shadowWarning: 7 shadowFlag: 0 loginShell: /bin/bash uidNumber: 502 gidNumber: 503 homeDirectory: /home/chmelova gecos: Pavlina Chmelova userPassword:: {crypt}! # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1

Nyní máme databázi naplněnou daty.

5.4. ZMĚNA OBSAHU Nyní změníme uživateli chmelova domovský adresář a to na /home/pavlina. Změnu uděláme opět přes LDIF soubor, ale tentokrát modifikační. Do souboru tedy musíme vložit řádku changetype: modify.

- 58 -

[root@ntb ~]# vim zmena.ldif dn: uid=chmelova,ou=Users,dc=archa,dc=cz changetype: modify replace: homeDirectory homeDirectory: /home/pavlina

LDIF soubor opět uložíme a pomocí příkazu ldapmodify promítneme změny do databáze. [root@ntb ~]# ldapmodify -x -W -D "cn=ldapadm,dc=archa,dc=cz" -f zmena.ldif Enter LDAP Password: modifying entry "uid=chmelova,ou=Users,dc=archa,dc=cz"

Nyní opět zkontrolujeme, zda se změna promítla do LDAP databáze pomocí příkazu ldapsearch. [root@ntb ~]# ldapsearch -x -W -D "cn=ldapadm,dc=archa,dc=cz" -b "uid=chmelova,ou=Users,dc=archa,dc=cz" Enter LDAP Password: # extended LDIF # # LDAPv3 # base with scope subtree # filter: (objectclass=*) # requesting: ALL # # chmelova, Users, archa.cz dn: uid=chmelova,ou=Users,dc=archa,dc=cz uid: chmelova cn: chmelova objectClass: account objectClass: posixAccount objectClass: top objectClass: shadowAccount shadowLastChange: 13829 shadowMin: 0 shadowMax: 99999 shadowWarning: 7 shadowFlag: 0 loginShell: /bin/bash uidNumber: 502 gidNumber: 503 homeDirectory: /home/pavlina gecos: Pavlina Chmelova userPassword:: {crypt}! # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1

- 59 -

6. ZABEZPEČOVACÍ POLITIKA Počítačová bezpečnost je obor informatiky, který se zabývá zabezpečením informací, které jsou uloženy v počítačových systémech. Snaží se tedy snížit či odhalit rizika, která jsou spojená s používáním počítače a přístupu k uloženým datům. Základními bezpečnostními požadavky tedy jsou: •

Důvěrnost – Data mohou používat pouze uživatelé, kteří k tomu mají oprávnění

•

Integrita – Data mohou měnit pouze uživatelé, kteří jsou autorizovaní

•

Dostupnost – Data by měla být vždy dostupná, nemělo by dojít k zablokování systému útočníkem.

•

Nepopiratelnost – Slouží k tomu, aby protistrana nemohla popřít, že k dané akci nedošlo

6.1. VÝVOJ BEZPEČNOSTNÍ POLITIKY S vývojem Internetu a se zvýšením potřeby připojení k veřejné síti vyvstala nutnost důvěrná data spolehlivě chránit. Znamená to většinou, že každá organizace, která provozuje počítačovou síť by měla primárně vytvořit bezpečnostní politiku dané sítě. Ta by měla zahrnovat zejména tyto cíle: •

Měla by informovat uživatele, zaměstnance a vedoucí o ochraně technologií a informačních zařízení.

•

Měla by specifikovat mechanismy, která by měly být používány včetně toho, jak mají být dodržovány.

•

Měla by poskytovat základ, jak získat, konfigurovat a prověřovat počítačové systémy v síti tak, aby byly dodrženy určité požadavky.

Protože bezpečnostní politika je důležitým a širokým tématem, vydala organizace ISO a IEC

dokument,

který

udává

přehled

a

doporučeních

ohledně

základních

standardizovaných zásad vývoje bezpečnostní politiky každé organizace. Tento standard

- 60 -

se nazývá dokument bezpečnostních standardů ISO/IEC 27002 a obsahuje celkem 9 částí: •

Bezpečnostní politika

•

Organizace bezpečnosti

•

Klasifikace a řízení aktiv

•

Bezpečnost lidských zdrojů

•

Fyzická bezpečnost a bezpečnost prostředí

•

Řízení komunikace a řízení provozu

•

Řízení přístupu

•

Vývoj, údržba a rozšíření informačního systému

•

Zvládání bezpečnostních incidentů

Jedná se tedy o efektivní praktiky, které by měla každá organizace používat. Organizace by tedy měla vytvořit jakýsi bezpečnostní projekt, který bude spočívat ve třech krocích a to v prevenci, detekci a nápravě. Bezpečnostní projekt by měl být tedy tvořen z následujících částí: •

Zabezpečení fyzického přístupu

•

Zabezpečení počítačového systému

•

Zabezpečení informací

•

Ekonomické a právní zabezpečení

6.2. ZABEZPEČENÍ FYZICKÉHO PŘÍSTUPU Zabezpečení fyzického přístupu spočívá v tom, aby se do systému nemohl dostat uživatel, který k tomu nemá oprávnění. Nejedná se zde pouze o použití různých autentizačních metod, ale mimo jiné o skutečně často opomíjené zabránění nebo definování fyzické manipulace se zařízeními informační infrastruktury. Lze se nezřídka setkat s případy, kdy infrastruktura je vysoce zabezpečena proti útokům zvenčí, avšak do vnitřní sítě se dá fyzicky jednoduše připojit přes aktivní prvky sítě umístěné v nestřežených veřejně přístupných prostorách nebo přes bezdrátové přístupový bod šířící signál i vně toho, co je považováno za zabezpečený perimetr. Je tedy důležité, aby - 61 -

organizace určila, jaká míra zabezpečení je nutná. V případě běžné sítě, ve které nejsou sdíleny tajná data, stačí autentizace za pomoci hesla a jména. Pokud se jedná například o počítačovou síť v bance, je dobré zvolit vyšší míru zabezpečení. Například kombinaci autentizačních metod, které jsou popsány výše. Tedy čipová karta s otiskem prstů nebo USB token s heslem apod. V takovém případě je tedy použita znalost či vlastnost k tomu, aby byla ověřena identita uživatele a autentizační server zjistil, zda je uživatel oprávněn vstoupit a pracovat s daty v počítačové síti či v daném systému.

6.3. ZABEZPEČENÍ POČÍTAČOVÉHO SYSTÉMU Zabezpečení počítačového systému znamená zabezpečit systém před napadením různých škodlivých programů či před útokem crackerů. Jednotlivé škodlivé programy a útoky jsou popsány v kapitole 6.6. Je tedy nutné, aby na každém počítači byl nainstalován antivirový program, který bude neustále aktualizován a bude bránit případnému nakažení systému. Další důležitou složkou počítačové bezpečnosti systému je správné zaškolení uživatelů o základech bezpečného chování. Znamená to tedy vysvětlit uživatelům, že jsou součástí bezpečnostní politiky a tudíž musí dodržovat určité zásady, aby předcházeli hrozbám.

6.3.1. PRÁCE S ELEKTRONICKOU POŠTOU Uživatel by si měl dát zejména pozor při práci s elektronickou poštou. Zde se v poslední době objevilo nejvíce hrozeb. Je tedy nutné uživatele upozornit, aby neotvíral poštu od lidí, které nezná, případně v cizím jazyce. Může se jednat o spam, který obsahuje různé nebezpečné programy. Uživatel by tedy neměl otevírat e-maily s následujícími vlastnostmi: •

E-mail je psán v cizím jazyce.

•

Zpráva má neznámého odesílatele.

- 62 -

•

V předmětu zprávy se nacházejí slova jako „happy day“, „birthday“, „how are you“, „love“ či „erotic“.

•

E-mail byl poslán od známého člověka, ale je v cizím jazyce, k čemuž daný člověk neměl důvod.

•

Zpráva obsahuje několik nesouvislých částí, vět a odstavců.

•

E-mail obsahuje podezřelou přílohu a v textu je upozornění, aby uživatel nezapomněl přílohu otevřít.

•

Tělo zprávy vybízí k tomu, aby uživatel klikl na link, které odkazuje na určité stránky.

•

Obsah e-mailu vyzývá k tomu, aby uživatel zadal osobní či jiné tajné údaje (PIN z banky, uživatelské jméno a heslo apod.).

E-maily s takovýmito příznaky by měl každý uživatel ihned smazat, protože při jejich otevření může dojít k narušení bezpečnosti. Dále by měl být uživatel upozorněn, že je vhodné, aby v poštovním klientovi byly vypnuty automatické aktivace JavaScriptu či ActiveX komponent a maker, které mohou obsahovat další hrozby.

6.3.2. PRÁCE NA INTERNETU Dalším potencionální hrozbou je služba WWW. Internet je v dnešní době neomezeným zdrojem dat, ale také neomezeným zdrojem různých virů, trojských koní a dalších nebezpečných programů. Není tedy vhodné, aby uživatel stahoval každou zajímavou utilitu či program, který potká. Je tedy důležité, aby si uživatelé byli vědomi toho, že programy mohou stahovat pouze ze stránek, které jsou důvěryhodné. Dalším nebezpečným problémem může být otevírání různých zahraničních stránek, kde se mohou také nalézat různé nebezpečné programy. Některé webové stránky v dnešní době obsahují kód, který využívá děr v internetových prohlížečích a tudíž si uživatel může jednoduše infikovat počítač, aniž by o tom věděl. Je tedy dobré nastavit v prohlížeči co nejvyšší míru zabezpečení, která nebude uživatele omezovat a zároveň vypnout v prohlížeči podporu ActiveX a podobných kódů.

- 63 -

6.4. ZABEZPEČENÍ INFORMACÍ Další zásadou je správné zabezpečení informací. Pokud jsou data posílána po síti, je nutné je zabezpečit tak, aby nebyli čitelné pro ostatní účastníky. Znamená to tedy použít nějakou šifrovací metodu. Dále je důležité, aby data byla zálohována. Jak je již obecně známo zálohy uživatel nejvíce ocení ve chvíli, kdy je nemá a nejvíce by je potřeboval. Záloha by měla být vytvořena tak, aby ji neohrožoval žádný útočník a ani žádná živelná pohroma (požáry, záplavy apod.).

6.5. EKONOMICKÉ A PRÁVNÍ ZABEZPEČENÍ Ekonomické a právní zabezpečení zahrnuje uvědomění zaměstnanců, že jsou součástí bezpečností politiky systému. Znamená to tedy, že je třeba je motivovat, aby dodržovali základní pravidla bezpečnosti počítače a zároveň trestat jejich nekázeň.

6.6. POČÍTAČOVÁ KRIMINALITA Bezpečnostní politiky vznikla z důvodu zvyšující se počítačové kriminality. Každý administrátor by v dnešní době měl znát běžné hrozby, které ohrožují jeho počítačovou síť. V dalších kapitolách jsou popsány nejčastější způsoby počítačové kriminality.[2.]

6.6.1. PŘESMĚROVÁNÍ PORTŮ Útok pomocí přesměrování portů zneužívá důvěryhodných hostů k tomu, aby útočník byl vpuštěn do systému přes firewall. Využívá tedy hostů, kteří se nacházejí v tzv. demilitarizované zóně. Demilitarizovaná zóna je veřejný segment sítě, který je dostupný z venku. Host v demilitarizované zóně může dosáhnout jak na hosta ve veřejné síti, tak i hosta v lokální síti. Útočník tedy ovládne hosta, který se nachází v demilitarizované zóně a za pomoci přesměrování portů se dostane do vnitřku počítačové sítě.

- 64 -

Tomuto typu útoku lze předejít nastavením správných důvěryhodných modelů, které specifikují síť.

6.6.2. MAN-IN-THE-MIDDLE ATTACK V překladu znamená man-in-the-middle „muž ve středu“. Jak již vyplývá z názvu, útočník zaujme místo mezi dvěma klienty a odposlouchává jejich konverzaci, případně ji může pozměňovat. Příkladem by mohl být proxy útok. Útočník použije phishing e-mail nebo přesměrování stránek a tím zachytí svoji oběť. Jako stánku webového serveru použije svoji IP adresu a tu potom předsune před adresu serveru. Pokud se uživatel chce připojit na daný server a vyšle požadavek na webový server, připojí se na počítač útočníka. Útočník tak může ukrást citlivé informace z počítače oběti.

Obr. 17 Man-in-the-Middle útok

Riziko těchto útoků můžeme snížit použitím VPN tunelů. Ty se používají ve veřejných sítích k tomu, aby komunikace byla oddělena od ostatního provozu. Zároveň s tím jsou veškerá data, která procházejí tunelem zašifrovaná. Dále tyto útoky lze zmírnit použitím zabezpečených portů na LAN switchích.

6.6.3. DOS ÚTOKY DoS útoky nebo-li Denial of Services útoky jsou neznámější formou útoků. Mezi útočníky jsou považovány za triviální, a proto jsou ještě nebezpečnější. Cílem DoS útoků je zahlcení systému na takové úrovni, aby nemohl vyřizovat již jiné požadavky. Mezi nejznámější útoky tohoto typu patří Ping of death, SYN flood attack, Smurf útok a Email bombs. - 65 -

•

Ping of Death využívá slabin starších operačních systémů. Jeho základem je chyba v implementaci TCP/IP protokolu. Program ping má za úkol zjistit, zda vzdálený server či počítač pracuje. Běžný ping není schopen zpracovat více než 65535 bajtů, což je maximální velikost TCP/IP protokolu. Útočníkovi tedy stačilo poslat ping, který přesahoval tuto velikost. Poslání takovéhoto pingu mohlo zničit konektivity cílových počítačů. V dnešní době je už ale většina sítí proti útoku Ping of Death chráněna.

•

SYN flood attack může být uskutečněn z jednoho nebo více počítačů útočníka. Útok se skládá ze záplavy SYN paketů, které mají v hlavičce neplatnou zdrojovou IP adresu. Server tedy na tyto pakety odpovídá za pomoci SYN-ACK na neexistující nebo na cizí zdrojové zařízení. Cílový server potom čeká na odpověď ACK. Odpověď ale nepřijde, díky tomu se velice rychle zaplní tabulka spojení a spotřebuje tak všechny dostupné zdroje na neplatný požadavek.

•

Smurf útok používá broadcast k zaplavení cílového zařízení. Útočník tedy posílá velké množství ICMP echo paketů na všeobecnou IP adresu s falešnou zdrojovou adresou. Zdrojový počítač (oběť) je tedy zahlcen mnoha odpověďmi. Tomuto útoku se dá zabránit tím, že se zablokují zprávy se všeobecnou IP adresou, které přicházejí z cizí sítě.

•

Email bombs využívá emailových zpráv. Útočník tedy posílá velké množství emailů jedincům, seznamům či doménám a tím zahltí emailové služby.

6.6.4. MALICIOUS CODE ATTACKS Tato skupina útoků je zřejmě nejčastější a nejvíce ohrožuje konečné uživatele počítačů. Patří sem červi, viry a trojské koně. 6.6.4.1. ČERVI Jedná se o nebezpečný kód, který nainstaluje svoji kopii do operační paměti počítače nebo se ukládá na disk do samotných souborů. Parazituje tak na hostitelském počítači a využívá jeho propojení s dalším počítači pro vlastní šíření. Narozdíl od virů se červ na lokálním disku dále nešíří.

- 66 -

Červ se dostane do systému tak, že využívá slabiny systému či přímo koncového uživatele (příloha e-mailu). Červ se po otevření přílohy e-mailu nakopíruje do počítače a útočník tak získává privilegovaný přístup do systému. V obraně proti červům můžou posloužit antivirové či spywarové a malwarové programy. Musí však být aktuální. Při napadení červem je důležitý rychlý zásah, aby přístup útočníka do systému trval co nejkratší dobu. 6.6.4.2. VIRY Virus je pojem, který označuje nebezpečný kód, který se bez vědomí uživatele sám ukládá do ostatních programů. Působí v počítači s cílem přepisovat nebo jinak modifikovat ostatní programy, dokumenty či systémové oblasti pevného disku. Ve chvíli, kdy uživatel spustí infikovaný program, aktivuje tím zároveň i vir. Nebezpečí virů spočívá v tom, že se rychle šíří a mají možnost ničit uživatelská data. Případně mohou otevřít útočníkovi cestu do systému. Virus je obvykle doručen za pomoci komprimovaného či spustitelného souboru. Je tedy potřeba zásah uživatele, aby byl virus nainstalován. Jako prevence proti virům slouží aktualizované antivirové programy jako je například AVG, Avast, Norton a další. 6.6.4.3. TROJSKÉ KONĚ Jedná se o program, který se na první pohled tváří jako program užitečný. Jako jeho vedlejší produkt je však škodit uživateli počítače. Trojské koně jsou schopny mazat data uživatele, formátovat disk, otevřít počítač útočníkovi apod. Na rozdíl od virů se trojské koně nejsou schopny samostatně šířit na další počítače. Vždy se na počítači nachází pouze jedna verze. Trojským koňům lze opět předcházet použitím aktualizovaných antivirových programů a dodržováním základních bezpečnostních zásad, které jsou popsány v kapitolách výše.

- 67 -

7. ZÁVĚR V této práci jsem se snažila vytvořit komplexní přehled nejběžnějších autentizačních metod, které jsou používány v operačních systémech typu Linux s hlavním zaměřením na LDAP. Autentizace je jeden ze základních prvků, které jsou používány v bezpečnostní politice každé organizace. Zabraňuje neoprávněnému přístupu k systému a to je v dnešní „nebezpečné“ době důležité. Při implementaci LDAP jsem mohla zúročit své znalosti implementace LDAP serveru a jednoduchou správu uživatelů v LDAP databázi. Použití adresářových služeb a samotného LDAP má veliký přínos pro správu systému, ke kterému bude přistupovat velké množství uživatelů. A to zejména svou komplexností a jednodušší správou. LDAP je stále používanějším systémem pro autentizační mechanismus a sdílení dat mezi uživateli převážně ve větších firmách.

- 68 -

SEZNAM POUŽITÝCH ZDROJŮ [1.] KOLEKTIV AUTORŮ. Linux – dokumentační projekt, 2. aktualizované vydání. Praha: Computer Press, 2001. 990 s. [2.] HEINIGE, Karel. Viry a počítače. Praha: Mobil Media, 2001. 80 s. [3.] DOSTÁLEK, Libor a KABELOVÁ, Alena. Velký průvodce protokoly TCP/IP a systémem DNS, 2. aktualizované vydání. Praha: Computer Press, 2000. 426 s. [4.]

HLAVENKA, Jiří a kolektiv. Výkladový slovník výpočetní techniky a komunikací. Praha: Computer Press, 1997. 452 s.

[5.] HOWES, Timothy A. a SMITH, Mark C. a Good. Understanding and Deploying LDAP Directory Services. Macmillan Technical Publishing, 1999. 846 s. [6.] HÁK, Igor. Moderní počítačová infiltrace (bakalářská práce). Hradec Králové: 2003. 93 s. [7.] HATCH, Brian a LEE, James a KURTZ, Gerge. Hacking bez tajemství: Linux. Brno: Computer Press, 2003. 644 s. [8.] KOCMAN, Rostislav a LOHNINSKÝ, Jakub. Jak se bránit virům, spamu a spyware. Praha: Computer Press 2005. 152 s.

Internetové odkazy [9.] SITERA, Jiří. Adresářové služby – úvod do problematiky. 2000 [cit. 20.5.2009]. [dokument ve formátu PDF] dostupný z: http://www.cesnet.cz/doc/techzpravy/2000-4/ldap.pdf [10.] BENÁK, Karel. Použití adresářových služeb v informačních systémech (bakalářská práce). Praha: 2004 [cit. 20.5.2009]. [dokument ve formátu PDF] dostupný z: http://ldap.benak.net/diplom.pdf [11.] BURDA, Zdeněk. Použití LDAPu v praxi. Praha: 2005 [cit. 20.5.2009]. [www dokument] dostupný z: http://ldap.zdenda.com/ - 69 -

[12.] Adresářové služby a LDAP. 2007 [cit. 21.5.2009]. [www dokument] dostupný z: http://www.samuraj-cz.com/clanek/adresarove-sluzby-a-ldap/ [13.] JANEČEK, Tomáš. Biometrika. [cit. 1.5.2009]. [dokument ve formátu RTF] dostupný z: https://akela.mendelu.cz/~lidak/bif/janecek.rtf [14.] HORKÝ, Richard. Biometrika. [cit. 1.5.2009]. [dokument ve formátu DOC] dostupný z: https://akela.mendelu.cz/~lidak/bif/horky.doc [15.] ŠROM, Pavel a TARAJČÁK, Martin. Šifrování, digitální podpisy, autentizace. [cit.

1.5.2009].

[dokument

ve

formátu

DOC]

dostupný

z:

http://axpsu.fpf.slu.cz/~sos10um/trendy/Sifrovani.doc [16.] Š ČUREK, Radomír. Biometrické metody identifikace osob v bezpečnostní praxi. Ostrava: 2008 [cit. 1.5.2009]. [dokument ve formátu PDF] dostupný z: http://www.fbi.vsb.cz/shared/uploadedfiles/fbi/biometricke_metody.pdf [17.] BAY, Robin. Čipové karty a USB tokeny, aneb bezpečnější autentizace a šifrování.

2003

[cit.

25.4.2009].

[www

dokument]

dostupný

z:

http://www.svetsiti.cz/view.asp?rubrika=Tutorialy&temaID=264&clanekID=265 [18.] KRHOVÁK, Jan a MATYÁŠ, Václav. Autentizace a identifikace uživatelů. Zpravodaj ÚVT MU [online]. 2007, roč. XVIII, č. 1, s. 1-5 [cit. 25.4.2009]. Dostupný z: http://www.ics.muni.cz/zpravodaj/articles/560.html [19.] HÄRING, David. Jak zvolit bezpečné heslo?. 2002 [cit. 25.4.2009]. [www dokument] dostupný z: http://www.linuxzone.cz/index.phtml?idc=398&ids=1 [20.] BITTO, Ondřej. Špatná paměť a bezpečná hesla. 2007 [cit. 25.4.2009]. [www dokument] dostupný z: http://www.czechnationalteam.cz/view.php?nazevclanku=spatna-pamet-abezpecna-hesla&cisloclanku=2007090003 [21.] KUBA, Martin. Principy operačních systémů. 1995 [cit. 1.5.2009]. [dokument ve formátu PDF] dostupný z: http://tf.czu.cz/~votruba/WAN/Principy%20operacnich%20systemu.pdf

- 70 -

[22.] BUREŠ, Michal. Kerberos. [cit. 1.5.2009]. [www dokument] dostupný z: http://nb.vse.cz/~zelenyj/it380/eseje/xburm10/kerberos.htm [23.] ŠKANTA, Jan. Systém Kerberos. [cit. 1.5.2009]. [www dokument] dostupný z: http://nb.vse.cz/~zelenyj/it380/eseje/xskaj07/Kerberos.htm [24.] Kerberos: The Network Authentication Protocol. 2009 [cit. 3.6.2009]. [web site] dostupný z: http://web.mit.edu/Kerberos/ [25.] MACHÁČKOVÁ, Zuzana. NIS – Síťový informační systém. 2001 [cit. 3.6.2009]. [www dokument] dostupný z: http://pit.wz.cz/nis.php [26.] KUKUK, Thorsten. The Linux NIS(YP)/NYS/NIS+ HOWTO. 2003 [cit. 3.6.2009]. [www dokument] dostupný z: http://info.sks.cz/users/ku/citace.htm [27.] WESTPHAL, Kristy. NFS and NIS Security. 2001 [cit. 3.6.2009]. [www dokument] dostupný z: http://www.securityfocus.com/infocus/1387 [28.] KORČ, Tomáš. Řízení a správa uživatelských oprávnění v informačním systému. 2008 [cit. 3.6.2009]. [www dokument] dostupný z: http://peakpointnet.cz/cz/piseme/clanky/rizeni-a-sprava-uzivatelskych-opravneniv-informacnim-systemu [29.] MIKULEC, Martin. Bezpečnost sítí (2. díl), počítačová kriminalita. 2009 [cit. 3.6.2009]. [www dokument] dostupný z: http://www.owebu.cz/pcsite/vypis.php?clanek=2488 [30.] HANÁČEK, Petr. Bezpečnostní funkce v počítačových sítích. Zpravodaj ÚVT MU [online]. 1999, roč. X, č. 2, s. 5-9 [cit. 3.6.2009]. Dostupný z: http://www.ics.muni.cz/zpravodaj/articles/171.html

- 71 -