Komunikační sítě II pro integrovanou výuku VUT a VŠB-TUO

FAKULTA ELEKTROTECHNIKY A INFORMATIKY VYSOKÁ ŠKOLA BÁŇSKÁ - TECHNICKÁ UNIVERZITA OSTRAVA

Komunikační sítě II pro integrovanou výuku VUT a VŠB-TUO

Garant předmětu: Jaroslav Zdrálek Autor textu: Pavel Nevlud

OSTRAVA 2014

Vznik těchto skript byl podpořen projektem č. CZ.1.07/2.2.00/28.0062 Evropského sociálního fondu a státním rozpočtem České republiky.

Za odbornou náplň tohoto vydání odpovídá autor. Pavel Nevlud je asistentem na Fakultě elektrotechniky a informatiky VŠB-Technické univerzity v Ostravě, kde přednáší předmět Praktikum komunikačních sítí II pro studenty navazujícího magisterského studia, kurz PKSII je na fakultě nabízen ve studijním programu Informační a komunikační technologie. Vznik skript byl podpořen projektem č. CZ.1.07/2.2.00/28.0062 Evropského sociálního fondu a státním rozpočtem České republiky.

Tato publikace neprošla redakční ani jazykovou úpravou. ©Pavel Nevlud, 2014, VŠB-Technická univerzita Ostrava

Autor: Pavel Nevlud Katedra: Katedra telekomunikační techniky Název: Komunikační sítě II pro integrovanou výuku VUT a VŠB-TUO Místo, rok, vydání: Ostrava, 2014, 1. vydání Počet stran: 80 Vydala: Vysoká škola báňská-Technická univerzita Ostrava Náklad: CD-ROM, 100 ks

Neprodejné ISBN 978-80-248-3639-3


1

Obsah Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1 Distribuce operačních systémů

5 7

1.1

Síťové operační systémy . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

1.2

BSD Berkeley Software Distribution . . . . . . . . . . . . . . . . . . . . . .

7

1.2.1

FreeBSD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8

1.2.2

OpenBSD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

1.2.3

NetBSD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

1.3

1.4

Linux

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.3.1

Debian . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.3.2

Ubuntu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.3.3

Fedora . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.3.4

Centos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.3.5

Gentoo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

Live distribuce Linuxu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2 Virtualizace a zálohování dat

15

2.1

Použití virtualizace v praxi . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2

Typy virtualizací . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.3

Typy hypervizorů . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

2.4

Virtualizační nástroje . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.5

2.4.1

KVM Kernel-based Virtual Machine . . . . . . . . . . . . . . . . . 19

2.4.2

XEN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.4.3

Virtualbox . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.4.4

OpenVZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.4.5

Instalace a konfigurace virtualizace pomocí KVM . . . . . . . . . . 20

Zálohování dat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2

Fakulta elektrotechniky a informatiky, VŠB - TU Ostrava

2.5.1

Metody zálohování . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.5.2

Média pro zálohování . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.5.3

Rozdělení podle topologie úložiště . . . . . . . . . . . . . . . . . . . 23

2.5.4

Nástroje pro zálohování v Linuxu . . . . . . . . . . . . . . . . . . . 24

3 Reporty a logování dat

25

3.1

Syslog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3.2

Syslog protokol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.3

Syslog formát zpráv . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.4

Instalace a konfigurace Syslog serveru . . . . . . . . . . . . . . . . . . . . . 27 3.4.1

Syslog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

3.4.2

Syslog-ng . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4 Monitorování a management sítí 4.1

4.2

29

SNMP Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.1.1

SNMP verze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.1.2

SNMP popis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

4.1.3

MIB databáze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

NetFlow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 4.2.1

NetFlow architektura . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.3

Instalace a konfigurace SNMP . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.4

Instalace a konfigurace NetFlow . . . . . . . . . . . . . . . . . . . . . . . . 33

5 Vykreslování grafů pomocí nástroje RRDTool

35

5.1

Vytvoření databáze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

5.2

Vložení dat do databáze . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.3

Vytvoření grafu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

5.4

Výpis informací a dat z databáze . . . . . . . . . . . . . . . . . . . . . . . 37

6 Sledování provozu v IP sítích

39


3

6.1

Paketový analyzátor tcpdump . . . . . . . . . . . . . . . . . . . . . . . . . 39

6.2

Paketový analyzátor Wireshark . . . . . . . . . . . . . . . . . . . . . . . . 40

6.3

Paketový analyzátor pro bezdrátové sítě Kismet . . . . . . . . . . . . . . . 41

7 Adresářové služby

43

7.1

Adresářové služby LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

7.2

Informační model LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

7.3

Jmenný model LDAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

7.4

Funkční model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45

7.5

Bezpečnostní model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

7.6

Instalace a konfigurace OpenLDAP . . . . . . . . . . . . . . . . . . . . . . 46

8 Ověření identity objektu

49

8.1

Autentikace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

8.2

Autorizace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

8.3

Účtování . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

8.4

Autentikace pomocí PAM (Pluggable Authentication Modules) modulů . . 51

8.5

PAM autentikace pomocí USB Flash . . . . . . . . . . . . . . . . . . . . . 52

8.6

PAM autentikace pomocí otisku prstů . . . . . . . . . . . . . . . . . . . . . 52

8.7

RADIUS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

8.8

Instalace a konfigurace programu FreeRadius . . . . . . . . . . . . . . . . . 53

9 Jednotný autentizační systém Kerberos

55

9.1

Kerberos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

9.2

Instalace a konfigurace Kerberos serveru . . . . . . . . . . . . . . . . . . . 56

10 Autentizace na bázi jednotného přihlášení

59

10.1 SSO Single Sign On . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59 10.2 Standard SAML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60 10.3 Využití standardu v praxi . . . . . . . . . . . . . . . . . . . . . . . . . . . 60

4


10.4 Open-source implementace SAML pomocí SimpleSAMLphp . . . . . . . . 61 10.5 Instalace a konfigurace simpleSAMLphp . . . . . . . . . . . . . . . . . . . 62 10.6 Instalace a kofigurace simpleSAMLphp Identity Provider . . . . . . . . . . 63 10.7 Instalace a kofigurace simpleSAMLphp Service Provider . . . . . . . . . . . 64 11 Pokročilá autentizace na bázi federated Single Sign On

67

11.1 Shibboleth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 11.2 Princip činnosti Shibbolethu . . . . . . . . . . . . . . . . . . . . . . . . . . 67 12 Nástroje pro správu řešení problémů 12.1 Princip RT

71

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72

12.2 RTIR RT for Incident Response . . . . . . . . . . . . . . . . . . . . . . . . 73 13 Nástroje pro IM komunikaci

75

13.1 Unixový chatovací nástroj talk . . . . . . . . . . . . . . . . . . . . . . . . 75 13.2 IRC Internet Relay Chat . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 13.3 XMPP Extensible Messaging and Presence Protocol . . . . . . . . . . . . . 77 13.4 Komunikace pomocí aplikace Facebook . . . . . . . . . . . . . . . . . . . . 78 13.5 Komunikace pomocí aplikace Twitter . . . . . . . . . . . . . . . . . . . . . 79


5

ÚVOD Předmět Praktikum komunikačních sítí II navazuje na předmět Praktikum komunikačních sítí I. PKSII je nabízen v magisterském studiu studijního programu Informační a komunikační technologie. Tato skripta jsou rozdělelena do čtrnácti kapitol. Některé kapitoly na sebe navazují, jiné se zabývají samostatným tématem. První kapitola je úvodní a popisuje obsah skript. Druhá kapitola se zabývá různými síťovými operačními systémy. Velký důraz je kladen na otevřené operační systémy, které jsou založeny na jádře Linuxu. Krátce jsou také zmíněny tzv. Live distribuce. Třetí kapitola se zabývá virtualizacemi a možnostmi zálohování dat. Jsou krátce popsány základní typy virtualizačních nástrojů a různé metody zálohování dat. Další kapitola se zabývá logováním důležitých dat a je popsán protokol Syslog. Pátá kapitola popisuje dva protokoly SNMP a NetFlow. Protokol SNMP slouží pro monitorování a správu zařízení v IP sítítch. Protokol NetFlow je využíván pro monitorování a vyhledávání síťových incidentů v síti. Na předchozí kapitolu navazuje další kapitola, která popisuje nástroj RRDTool, který se zaměřuje na zpracování a ukládání časově závislých dat. Tato data mohou být následně vykreslena v přehledných grafech. Sedmá kapitola, je poslední kapitolou zabývající se monitorováním sítí. V této kapitole jsou popsány základní nástroje pro sledování provozu v sítích pomocí různých protokolových analyzátorů. Je také uveden jeden nástroj pro sledování v bezdrátových sítích. Osmá kapitola se zabývá Adresářovými službami, ve kterých jsou uloženy informace o pojmenovaných objektech. Tyto služby slouží pro ukládání a přístup k datům na adresářovém serveru. LDAP protokol umožňuje vkládat, modifikovat, mazat, ale zejména rychle vyhledávat požadované informace. Další kapitola se zabývá ověřováním identity objektů pomocí autentikace na bázi uživatelského účtu, biometrie a dalších metod. Je také popsán protokol Radius. Následující kapitola popisje systém jednotného přihášení SSO, který umožňuje pohodlný přístup k informačním a komunikačním službám pomocí jednotných přihlašovacích údajů. Krátce je popsán protokol Kerberos. Další kapitola navazuje na předchozí kapitolu a rozšiřuje ji o protokol SAML, který je standardem, pro výměnu autentikačních informací mezi poskytovatelem služby a poskytovatelem identity. Dvanáctá kapitola, je poslední kapitola, která se zabývá autentizačními funkcemi. Tato kapitola seznamuje s pokročilou autentizací na bázi federated Single sign on. Tato autentikace umožňuje pokročilou autentikace pro kooperativní prostředí mezi jednotlivými

6


institucemi. Další kapitola popisuje nástroje pro správu řešení problémů, které jsou dnes známé jako helpdesk. Poslední kapitola popisuje některé nástroje pro Instant messaging komunikaci. Tyto nástroje umožňují okamžitou výměnu zpráv s různými přídavnými funkcemi. Tato skripta se zabývají problematikou monitorování sítí, různými autentizačními technikami a poslední část se zabývá komunikačními nástroji.


1

7

DISTRIBUCE OPERAČNÍCH SYSTÉMŮ

Operační systém je základní programové vybavení zařízení (počítač, server, směrovač, telefón,..), které je zavedeno do paměti po jeho startu a zůstává v činnosti až do jeho vypnutí. Skládá se z jádra (kernel) a pomocných systémových nástrojů. Hlavním úkolem operačního systému je zajistit uživateli možnost ovládat zařízení, vytvořit pro procesy stabilní aplikační rozhraní API, a přidělovat jim systémové zdroje. První operační systémy byly vytvořeny pro sálové počítače, tzv mainframy. Prvním průlomovým operačním systémem je Multics, vyvíjený od roku 1964 v Bellových laboratořích. Multics je přímým historickým předchůdcem Unixu. Operační systém plní tři základní funkce: • ovládání zařízení - umožňuje uživateli spouštět programy, předávat jim vstupy a získávat jejich výstupy s výsledky • abstrakce hardware - vytváří rozhraní pro programy, které abstrahuje ovládání hardware a dalších funkcí do snadno použitelných funkcí • správa zdrojů - přiděluje a odebírá procesům systémové prostředky počítače.

1.1

Síťové operační systémy

Síťový operační systém je software, který běží na serveru, nebo na aktivním síťovém prvku a slouží pro spravování dat, uživatelů, skupin, bezpečnosti, aplikací a dalších síťových funkcí. Síťový operační systém je založen na architektuře klient/server. Server nabízí klientům své zdroje, služby, aplikace.

1.2

BSD Berkeley Software Distribution

Operační systém BSD byl průkopníkem mnoha inovací moderních systémů. BSD systémy jako první obsahovaly knihovny pro Internet Protokol. Dnes jsou BSD systémy používány jako testovací prostředí pro nové technologie v akademických prostředích a také v mnoha komerčních a svobodných produktech. Povaha BSD licence umožňuje distribuovat odvozené produkty jako proprietární řešení bez nutnosti zveřejnění zdrojového kódu. BSD licence možňuje volné šíření licencovaného obsahu, přičemž vyžaduje pouze uvedení autora a informace o licenci, spolu s upozorněním na zřeknutí se odpovědnosti za dílo (wikipedie). BSD bylo základem velkého množství operačních systémů.

8


Obrázek 1.1: Operační systém

1.2.1

FreeBSD

FreeBSD je vyvíjen jako kompletní operační systém - kernel, ovladače zařízení a všechny uživatelské utility. Na rozdíl od Linuxu jsou vyvíjeny ve stejném stromu systému pro správu verzí zdrojových kódů. Free BSD je pokládán za poměrně spolehlivý a robustní operační systém. Může být využíván pro multiprocesorové servery, desktop nebo různá embedded zařízení. Zaměření FreeBSD je na výkon, vytváření sítí a skladování dat v kombinaci s jednoduchou systémovou správou a velmi dobrou dokumentací. FreeBSD klade velký důraz na výkon při ukládání dat a paralelním zpracovávání, obsahuje souborový systém ZFS od firmy Sun a vysoce škálovatelné paralelní zpracovávání. FreeBSD je hodně využíváno jako základní stavební blok pro jiné operační systémy, ať už komerční, či s otevřeným kódem. PC-BSD je systém odvozený z FreeBSD s grafickou instalací a zajímavými desktopovými nástroji, které jsou zaměřené na jednoduché použití běžným počítačovým uživatelem. FreeSBIE je LiveCD založené na FreeBSD. Funguje přímo z CD, pevný disk se nevyžaduje. Systém také obsahuje jednoduchou a snadno rozšiřitelnou sadu nástrojů pro vytváření CD obrazů pro vestavěné systémy. Mac OS X firmy Apple je částečně založen na FreeBSD, díky čemuž kromě uživatelského rozhraní vytvořeného firmou Apple obsahuje i bohatý unixový základ.


9

Obrázek 1.2: Logo distribuce FreeBSD

1.2.2

OpenBSD

OpenBSD je volně šiřitelný, na mnoha platformách fungující operační systém unixového typu, jehož koncepce vychází ze systému BSD. Mezi hlavní vlastnosti patří přenositelnost, standardizace, správnost a bezpečnost. Tato distribuce je vhodná pro výstavbu firewalů a privátních síťových služeb v distribuovaném prostředí. Hlavní důraz OpenBSD je kladen na bezpečnost. Filosofií této distribuce je raději méně funkcí, ale o to více bezpečných. Tento systém je bezpečný i ve výchozím nastavení. Další cíle jsou zejména dodržování nejrůznějších standardů. Např. ANSI, POSIX a částečně X/Open. OpenBSD projekt je také autorem mnoha ostatních Open* projektů, které jsou následně využívány jinými platformamy. Patří mezi ně např. OpenSSH, OpenSSL, OpenBGPD, OpenOSPFD, OpenNTPD, ...

Obrázek 1.3: Logo distribuce OpenBSD

1.2.3

NetBSD

NetBSD klade důraz na jednoduchost, čistotu a přehlednost kódu. Díky široké podpoře hardwaru se NetBSD používá i v embedded zařízeních, přenosných počítačích, nebo na starším hardwaru. Poměrně často bývá využíván jako server, nebo firewall. NetBSD je svobodný software, šířený BSD licencí. Tento systém se snaží o implementaci API (Aplication Program Interface) podle normy POSIX, což by mělo umožnit bezproblémové používání všech unixových programů v nezměněné formě. NetBSD se vyvíjí jako kompletní systém, včetně jádra. Tento systém je poměrně rychlý a je velká čistota kódu. Obsahuje také obsáhlou a přehlednou dokumentaci. Nevýhodou je menší počet dostupných aplikací a menší počet uživatelů, který tento systém používají a případně umí poradit.

10


Obrázek 1.4: Logo distribuce NetBSD

1.3

Linux

Linux je operační systém, založený na principech unixových sytémů. Linux je šířen v podobě distribucí, které lze buď naistalovat, nebo přímo používat, tzv. Live distribuce. Operační systém Linux používá unixové jádro, které vychází z myšlenek Unixu a respektuje příslušné standardy POSIX a Single Unix Specification. Jádro Linuxu umožňuje spouštět více programů najednou. Každý program se může skládat z jednoho nebo více procesů, takže říkáme, že jde o víceúlohový systém. Každý proces potom může mít jeden nebo více podprocesů. Jádro Linuxu je víceuživatelské, takže umožňuje spouštět programy různých uživatelů, například jeden uživatel může obsluhovat systém přímo, zatímco další mohou obsluhovat stejný systém například přes síť. Příslušné uživatelské účty jsou před neoprávněným přístupem chráněny autentizací, například jménem a heslem. Uživatelé mají přidělena různá práva. Pod označením Linux je míněno nejen jádro operačního systému, ale zahrnuje i veškeré programové vybavení. Patří mezi ně zejména různé utility, aplikace, grafické uživatelské rozhraní, apod. Linux je šířen v podobě linuxových distribucí, které obsahují jádro a příslušný software v takové formě, aby usnadňoval instalaci a používání. Například Live distribuce se nemusí vůbec instalovat a po zavedení do RAM paměti je lze přímo používat. Toto je vhodné zejména pro vyzkoušení dané distribuce. Velmi často se také distribuce virtualizují, z důvodu snadné zálohy, lepšího využití hardwaru apod. Linuxová distribuce je obvykle šířena jako ISO obrazy, které lze vypálit na CD, DVD, nebo umístit na USB flash disk. Poté z tohoto média instalovat na zařízení, nebo přímo využívat. Jednotlivé programy jsou rozděleny do balíčků, které je možné pomocí balíčkovacího systému do systému přidávat nebo z něj odebírat, případně systém aktualizovat a udržovat. Linux je rošířený zejména na internetových a intranetových serverech a v oblasti vysoce výkonných výpočetních stanic. V posledních letech se Linux pozvolna rošiřuje do firemní sféry a na domácí počítače. Také se prosazuje v oblasti různých embedded zařízení, smart telefónů a tabletů.


11

Obrázek 1.5: Logo distribuce Linux

1.3.1

Debian

Debian patří mezi nejstarší distribuce, jehož zakladatelem je Ian Murdock. Je to přísná open-source distribuce, která je vyvíjena dobrovolníky z celého světa. Nabízí on-line repozitář, server, kde jsou uloženy zdrojové kódy softwarových balíčků. Debian je pro svou stabilitu a jednoduchou údržbu velmi oblíbený zejména pro serverové instalace. Tato distribuce má vlastní balíčkovací systém APT (Advanced Packaging Tool), který je velmi propracovaný a umožňuje velmi jednoduše provádět správu balíčků z různých zdrojů. Debian má tři hlavní větve, do kterých se software člení podle úrovně testování a míry funkčnosti. Stabilní verze je pečlivě otestovaná, chyb zbavená větev určená především pro nasazení u kritických aplikací. Testovací verze obsahuje novější software, ale může obsahovat chyby. Nestabilní, vývojářská větev je používána převážně vývojáři a nadšenci, kteří chtějí vyzkoušet nejnovější software.

Obrázek 1.6: Logo distribuce Debian

1.3.2

Ubuntu

Ubuntu je linuxová distribuce založená na Debianu. Je sponzorována společností Canonical Ltd. a je pojmenována z jihoafrického pojmu, znamenajícího "lidskost ostatním". Na rozdíl od Debianu pravidelně zveřejňuje nové verze každých 6 měsíců s podporou na dalších 9 měsíců. Verze LTS (long Term Support) mají podporu delší - 5 let. Ubuntu rozděluje software na čtyři základní sekce, nazývané komponenty, které od-

12


rážejí rozdíly v licencování a úroveň poskytované podpory. Standardně jsou instalované balíčky z komponenty main, tyto pokrývají základní potřeby běžných uživatelů počítače a některé balíčky z komponenty restricted, které jsou absolutně nevyhnutelné na to aby byl systém použitelný. Komponenta universe obsahuje široký záběr softwaru, který může a nemusí mít restriktivní licenci, ale není podporovaný Ubuntu týmem. Komponenta multiverse, která obsahuje nepodporované balíčky, nesplňující požadavky na svobodný software.

Obrázek 1.7: Logo distribuce Ubuntu

1.3.3

Fedora

Fedora Linux je vývojovou větví, z níž vychází Red Hat Linux. Jedná se o velmi progresivní distribuci Linuxu, v níž se objevují novinky, které pak přejímají jiné distribuce. Tato distribuce používá balíčkovací systém RPM (Red Hat Package Manager), který je zabudován v nástroji yum (The Yellowdog Updated, Modified).

Obrázek 1.8: Logo distribuce Fedora

1.3.4

Centos

CentOS (Community ENTerprise Operating System) je linuxová distribuce založená na Red Hat Enterprise Linux. CentOS obsahuje základní software pro práci v síti. Svým obsahem softwaru a zaměřením vůbec je směrován spíše pro práci na serveru a vývoj. Jako největší klad je jeho stabilita. CentOS je k dispozici zcela volně, avšak není spravován ani podporován firmou Red Hat, je podporován vlastní komunitou vývojářů. Využívá pro aktualizace nástroj yum, a proto jsou pozměněny jeho konfigurační soubory tak, aby odkazovaly do vlastních repozitářů.

1.3.5

Gentoo

Gentoo je distribuce operačního systému Linux vyvíjená, podobně jako Debian, komunitou. Je ovšem na rozdíl od ostatních založena na zdrojových kódech, takže si každý přeloží


13

Obrázek 1.9: Logo distribuce CentOS

svůj unikátní systém dle svých požadavků. Výhodou je maximální možnost nastavení jednotlivých aplikací a součástí, přehledná konfigurace systému, optimalizace pro konkrétní hardware, časté aktualizace. Nevýhodou je náročnost na výpočetní výkon v průběhu instalace nebo aktualizace systému a aplikací, délka kompilace, pokud se nevyužívají předkompilované balíky.

Obrázek 1.10: Logo distribuce Gentoo

1.4

Live distribuce Linuxu

Linuxová distribuce, která se zavádí z připojitelného média se nazývá Live distribuce. Systém nemusí být naistalovaný na pevný disk. Tyto Live distribuce jsou vhodné pro otestování operačního systému, instalace nového systému, zvýšení bezpečnosti, nebo pro opravu systému. Existují možnosti LiveCD, LiveDVD, nebo LiveUSB. Převážná většina LiveCD obsahuje operační postavený na základě GNU systému a linuxovém jádře, ale jsou zde také LiveCD postavené na ostatních operačních systémech, jako je Mac OS, Mac OS X, BeOS, FreeBSD, Minix, NetBSD, Plan 9 nebo Microsoft Windows. Stačí si stáhnout obraz libovolné distribuce a vytvořit si vlastní Live verzi. ISO obraz je potom možno uložit na libovolné externě připojitélné médium. Některé distribuce jsou Live a je možno je také po otestování přímo nainstalovat. Dnes se můžeme nejčastěji setkat s LiveUSB distribucí. Mají výhodu velké velikosti pro uložení dat. Je možno využít Flash disk, nebo externí disk. Výhoda LiveCD, nebo Live DVD je zejména v oblasti bezpečnosti, protože není možno na médium nic ukládat. Pro některé účely to může být naopak nevýhoda. Pomocí programu usb-creator-gtk, nebo UNetbootin můžeme vytvořit LiveUSB distribuci. Na obrázku 1.11 je náhled na spuštěný program usb-creator-gtk.

14


Obrázek 1.11: Náhled do programu usb-creator-gtk

Obrázek 1.12: Náhled do programu UNetbootin


2

15

VIRTUALIZACE A ZÁLOHOVÁNÍ DAT

Podstatou virtualizace je provoz více oddělených serverů na jednom fyzickém hardware. Toto přináší zásadní úspory v pořizovacích i provozních nákladech, zlepšuje správu, urychluje vytvoření a nasazení nového serveru, bezpečnost a další výhody. Také se často virtualizace nasazuje pro vývojové a testovací účely. Cílem je, aby několik virtuálních serverů společně sdílelo fyzické prostředky.

2.1

Použití virtualizace v praxi

Využití virtualizace pro vývoj softwaru je dnes velmi časté. Díky možnostem nasazení a běhu více systému současně (a to i více verzí jednoho softwaru) přináší virtualizace snažší možnost vývoje aplikací pro více systému současně, aniž by programátor musel mít přístup k fyzickým zařízením s různými operačními systémy, popř. s různými verzemi operačního systému. Virtualizační nástroje taktéž mají funkcionalitu pro ukládání stavu systému. Díky možnosti návratu systému do původní podoby je jednodušší návrat systému do původního stavu před testováním dané systémové aplikace. Virtuální systém může taktéž fungovat jako honeypot, jelikož pro hostující systém je snadné sledovat využívané prostředky virtuálního systému. O testovací účely se jedná v případě, že chceme testovat aplikaci, u které si nejsme jistí původem, popř. chceme otestovat daný systém na stabilitu při využití této aplikace. Testovací účely jsou velmi úzce spjaty s bezpečností, kdy např. můžeme využívat virtualizovaný operační systém např. na stahování pošty. V takovém případě (při přijetí viru) je infikován pouze virtualizovaný systém, nikoliv hostující systém. Virtualizovat můžeme taktéž systémy jiné architektury procesoru – např. procesorů ARM (Advanced RISC Machine) a vyvíjet tak aplikace pro mobilní zařízení, aniž bychom museli mít přístup k danému zařízení. Virtualizovaný systém je velice snadné obnovit do původní podoby. Při obnově virtutualizovaného systému do původní podoby není většinou potřeba hostující systém, popř. ostatní virtualizační systémy vyřazovat z provozu. Priorita hostujícího systému je mnohem vyšší a v případě havárie virtuálního systému, nedojde k ovlivnění stavu hostovaného systému. Tato skutečnost je úzce spjata s nasazením virtualizace v serverovém prostředí, kdy stabilita a funkčnost je jedním z hlavních požadavků na fungování celého systému. V serverovém prostředí velmi často funguje na jednom fyzickém zařízení větší počet virtuálních systémů a v případě selhání jednoho z virtuálních systémů nesmí dojít k ovlivnění ostatních systémů. V případě selhání virtuálního systému, může být tento systém okamžitě nahrazen jeho kopií, která je předpřipravena na hostujícím systému.

16


2.2

Typy virtualizací

Virtualizace se používá z různých důvodů. Pro každý druh využití virtualizační technologie se může hodit jiná virtualizační technika. Různá virtualizační řešení mají různý výkon, odlišnou kvalitu nástrojů pro správu systému, nebo dostupnost komerční podpory a certifikací. Virtualizací rozdělujeme výkon hardwaru mezi virtuální systémy. Existují však i jiné typy virtualizace, které provádějí opačnou úlohu. Tyto typy virtualizace seskupují více virtuálních systémů do jednoho, což často vede k virtualizaci vrstvy nad sdruženými virtuálními systémy a to buď z hlediska výkonu, nebo zabezpečení. Virtualizace systému v současné době nejčastěji využívá virtualizace platformy. Možnost virtualizace celé systémové platformy je dostupná na téměř na všech procesorech s architekturou x86 a x86-64. Velká rozsáhlost instrukční sady procesorů x86 vedla k několika různým přístupům ve vývoji hypervisorů. Emulace virtuálního systému na architektuře x86 je realizovatelná pomoci binárního překladu instrukcí a přímého vykonávání instrukcí. Mezi hostujícím a hostovaným operačním systémem neexistuje žádná vazba. Při realizaci virtualizace zcela odlišné architektury než je architektura hostujícího systému, musí být využita technika binárního překladu. Při tomto překladu jsou přeloženy veškeré instrukce z virtuálního systému do systému hostujícího. Podobná technika je využita taktéž při rekurzivní virtualizaci, která je realizovatelná pouze touto technikou. Paravirtualizace se rozumí technika, při které dochází k modifikaci hostujícího operačního systému, jenž je upraven do podoby, ve které se budou virtualizované systémy virtualizovat jednodušeji a hlavně rychleji. U tohoto typu virtualizace je zvolen jednodušší návrh hypervisora. Jednodušší návrh hypervisora může být zvolen pouze v případě, že se jedná o totožnou architekturu systému mezi hostujícím a virtualizovaným systémem. Virtualizace na úrovni jádra operačního systému je virtualizace, které se nenachází žádný hypervisor. Virtualizované systémy běží přímo nad společným jádrem a není potřeba virtualizovat hardware nebo překládat instrukce. Tento typ virtualizace dosahuje vysoké efektivity vzhledem k absenci virtualizovaného hardware. Neexistuje zde taktéž duplicita, jenž vzniká při běhu systému v plně virtualizovaném prostředí. Při běhu systému v plně virtualizovaném prostředí, běží každé jádro separátně v každém systému. Musíme taktéž počítat s jádrem hostujícího systému. Virtualizace na úrovni jádra operačního systému umožňuje virtualizovat systémy, jenž jsou shodné s hostujícím operačním systémem a virtualizovaný systém je schopný využívat stejné jádro operačního systému. Systémová virtualizace spočívá v simulaci kompletní hardware platformy pro virtuální stroj. Systémově virtuální stroje jsou nyní procesy řízené monitorem virtuálních strojů, hypervisorem, které mohou fungovat na dané platformě simultánně s vlastním operačním systémem a sadou programů nad přiděleným prostorem, který představuje virtuální úložiště ve formě souborů. Kontejnerová virtualizace je technika, při které běží pouze jeden operační systém,


17

který vytváří vzájemně oddělená prostředí, tzv. kontejnery. Takto lze na jednom stroji provozovat např. několik webových serverů, aniž by bylo nutné mít pro každý z nich nainstalovaný kompletní systém.

Obrázek 2.1: Kontejnerová virtualizace

Každý virtuální systém má také uživatelem definovanou sadu virtualizovaných zařízení, která je značně variabilní a zahrnuje veškerá zařízení potřebná pro základní běh podporovaných operačních systémů. Virtualizovanému systému jsou přidělovany tyto prostředky hypervisorem, který zajišťuje alokaci těchto prostředků na hostujícím fyzickém stroji. Tento typ virtualizace je možný i na počítačich s instrukční sadou, která je odlišná od instrukční sady hostovaného počítače.

2.3

Typy hypervizorů

Za hypervisor můžeme označit komponentu virtualizačních nástrojů. Úkolem hypervisoru je zajištění komunikace mezi virtualizovaným systémem a systémem hostujícím, spravování a přidělování hardwarových prostředků virtuálním systémům. Samotné hypervisory je možno rozdělit do několika základních kategorií. Nativní hypervisor – je instalován přímo na hardware platformě bez přítomnosti nosného operačního systému. Cílem tohoto hypervisoru je pouze podpora pro běh virtuálních systémů a to jak podpora při přidělování prostředků pro samotnou funkci virtuálních systémů. Hypervisor funguje v režimu supervizora s nejvyšší prioritou. Ostatní virtuální systémy fungují s nižší prioritou. Hostovaný hypervisor funguje na operačním systému, do něhož byl nainstalován. Hostovaný hypervisor je možno rozdělit do dvou základních režimů a to do uživatelského režimu a dvojího režimu. Mezi představitele hypervisora v uživatelském režimu patří např. QEMU, jenž využívá binární překlad instrukcí. Pokud je použit bez modulu KVM, jedná

18


se o pouhý emulátor. Toto nepřináší dostatečné řešení, ačkoliv může emulovat instrukční sadu, která se liší od instrukční sady hostujícího systému. Dalším režimem hostovaného hypervisora je duální režim. V tomto režimu má hypervisor vyšší prioritu a umožňuje přímé spuštění bezpečných instrukcí na hostujícím systému z virtualizovaného systému. Virtualizace procesoru je možné dvěma základními způsoby a to emulací (binárním překladem instrukcí) nebo přímým spuštěním instrukcí na hostujícím systému. Pomoci emulace je možno pracovat na platformách s odlišnými instrukčními sadami. Postup pro zpracování instrukcí je následující: binárním překlaV případě, že u hostovaného systému a virtulizovaného systému se nachází stejná instrukční sada, lze provést přímé spouštění instrukcí. Přímé spuštění instrukcí přináší navýšení rychlosti u samotné virtualizace.dem instrukcí se zpracuje každá provedená instrukce, interpretuje se, emulovaná zařízení změní svůj stav na základě typu instrukce. Virtualizace vstupně/výstupních zařízení je poměrně složititá záležitost, z důvodu odlišných vlastností a ovládání jednotlivých zařízení. Nejčastěji dochází k virtualizací celého zařízení. Požadavky tohoto zařízení jsou zachyceny hypervisorem a ten je převede na požadavky, které jsou totožné pro dané zařízení. Implementace těchto zařízení se liší podle jejich využití.

2.4

Virtualizační nástroje

Existuje několik dostupných virtualizačních nástrojů. Některé jsou komerční, jiné jsou volně dostupné. V této části se budeme zabývat pouze volně dostupnými virtualizačními nástroji.

Obrázek 2.2: Porovnání virtualizace KVM a Xen


2.4.1

19

KVM Kernel-based Virtual Machine

S příchodem hardwarově asistované virtualizace začal vznikat nový hypervisor ve formě modulu jádra pro GNU/Linux, který by byl jednoduše použitelný a dosahoval vysokého výkonu. Rozšířením jádra linuxu o mudul hypervisora KVM je možno spravovat každý virtuální systém jako linuxový proces. Po připojení modulu jádra KVM, dochází ke změně linuxového jádra na hypervisora. Každý virtuální systém má vyhrazený svůj adresní prostor pro zajištění míry izolace mezi aktivními virtuálními systémy a procesy. Správa modulu jádra je realizována pomocí libvirt API a nástrojů pro libvirt, jako virt-manager a virsh. KVM je svým rozsahem mnohem menší než např. VirtualBox nebo VMware. Virtualizace procesoru je zajišťována pomocí technik hardwarové virtualizace Intel VT-x nebo AMD-V. Řízení paměti je spravováno přímo KVM. Emulovaná zařízení Jsou pouze softwarovou implementací reálných zařízení. Ke svému provozu nepotřebují reálné fyzické zařízení, mohou však využít připojená zařízení stejného typu. Tato zařízení jsou pouze překládovou vrstvou mezi hostovaným operačním systémem a hostujícím operačním systémem. Instrukce na úrovni virtualizovaných zařízení jsou překládány binárním překladem instrukcí. Virtualizovány mohou být i odlišné architektury, než na které je hostující operační systém. Emulaci zařízení provádí upravený emulátor QEMU. Tento emulátor překládá veškeré instrukce z hostovaného operačního systému do hostujícího a opačně. Sada virtualizovaných zařízení je shodná s virtualizovanými zařízeními ve virtualizačním nástroji VirtualBox, který rovněž využívá modifikovaného QEMU k virtualizaci těchto zařízení. Paravirtualizována zařízení se značně liší od emulovaných. Tato zařízení využívají paravirtualizovaných ovladačů, které omezují zpoždění a zvyšují u nich datovou propustnost. U paravirtualizovaných zařízení nejsou požadavky emulovány, nýbrž jsou předávány skrze univerzální rozhraní až do reálného systému.

2.4.2

XEN

XEN umožňuje paravirtualizaci, kdy se prostředí pro virtualizovaný stroj neemuluje úplně, ale část instrukcí se zpracovává přímo prostřednictvím reálného prostředí. To však předpokládá spolupráci virtualizovaného stroje s hostitelem. Podmínkou pro paravirtualizaci tedy je odpovídajícím způsobem nakonfigurované jádro hostitele resp. zavedené moduly které komunikaci mezi virtuály a jádrem zprostředkují. Při instalaci tohoto násroje je potřeba upravit systém hostitelský systém.

2.4.3

Virtualbox

Virtualbox využívá hostovaného hypervisora. Virtualbox je možno spouštět z příkazové řádky, ale je možno taktéž využívat grafické rozhraní programu. Architekturu Virtualboxu a jeho komponent můžeme rozdělit na 2 části a to na část klientskou a část serverovou.

20


Klienstská část obsahuje nástroje, které jsou určeny pro správu virtuálních systémů a to jak přes grafické, tak i přes příkazovou řádku. Grafické rozhraní klientské části Virtualboxu patří VirtualBox a VBoxSDL. VirtualBox je klientskou aplikací, grafické rozhraní je napsáno ve frameworku Qt. Jedná se o multiplatformní aplikaci, předává veškeré nastavení službě VboxSVC. VBoxSDL postrádá některé rozšířené funkce a je určena především pro ladění virtuálních systémů – obsahuje konzoli s veškerými chybovými zprávami. Virtuální disky v Virtualboxu představují soubory s příponou .vdi. Jejich velikost může být staticky nastavená popř. může být velikost proměnná s maximální velikostí, jenž nastavuje uživatel. VirtualBox nevyužívá pouze binární překlad instrukcí. Neprivilegované instrukce mohou být spouštěny nativně a to bez jakékoliv modifikace.

2.4.4

OpenVZ

OpenVZ využívá tzv. kontejnérové virtualizace, kdy v rámci jednoho operačního systému, se vytváří vzájemně oddělená prostředí. Lze tak na jednom zařízení provozovat několik www serverů, aniž by bylo nutné mít pro každý z nich nainstalovaný kompletní systém. Tato virtualizace neumožňuje nasazení jiného operačníhosystému.

2.4.5

Instalace a konfigurace virtualizace pomocí KVM

Nejdříve naistalujeme požadované balíčky, pomocí balíčkovacího programu: apt-get install kvm libvirt-bin Následně otestujeme, zda je na systému podpora kvm virtualizace příkazem: kvm-ok Na výstupu bychom měli obdrřen následující výpis: INFO: Your CPU supports KVM extensions INFO: /dev/kvm exists KVM acceleration can be used Nyní můžeme naistalovat nástroj virtinst pro instalaci jednotlivých virtuálů apt-get install virtinst Pomocí následujícího příkazu vytvoříme virtuální server s distribucí Slax:


21

virt-install -n web_devel -r 512 –disk path=/var/lib/libvirt/images/web_devel.img,\ bus=virtio,size=4 -c slax-Czech-7.0.8-i486.iso –accelerate \ –network network=default,model=virtio –connect=qemu:///system –vnc –noautoconsole -v

Na výstupu získáme následující výpis: Starting install... Allocating ’web_devel.img 100% |=========================| Creating domain... Domain installation still in progress. You can reconnect to the console to complete the installation process.

0 B

00:00 0 B 00:00

Nyní se můžeme připojit do virtuálu pomocí příkazu: virt-viewer -c qemu:///system web_devel

Obrázek 2.3: Virtualizovaný Slax

2.5

Zálohování dat

Zálohování dat je mechanismus, při kterém jsou vybraná data ukládána na jiném médiu. V případě ztráty původních dat, mohou být data obnovena ze zálohy. Záloha se provádí

22


podle předem stanovené zálohovací politiky. Je velmi důležité, stanovit, která data budou zálohována. Většinou se zálohují data, která jsou vytvořena uživateli, nebo různé nastavení systému apod. Zálohování se provádí z důvodu ochrany před ztrátou uložených dat. Data se mohou poškodit chybou hardwaru, softwaru, napadení virem, vinou uživatele, přírodní katastrofou, apod.

2.5.1

Metody zálohování

Existuje několik metod zálohování. Základní a nejjednodušší metodou je plná záloha, při které jsou zálohována veškerá data určená pro zálohování. Plná záloha by byla ideálním typem pro všechna zálohování, protože je nejvíce komplexní. Nicméně tento typ zálohování zabere mnoho času, a má velké nároky na zálohovací médium. Úplná záloha je často omezena na týdenní nebo měsíční periodu a je spuštěna převážně jen přes noc. Dalším typem je inkrementální (přírůstková) záloha, která ukládá pouze změny oproti oproti předchozí záloze. Přírůstkové zálohování poskytuje rychlejší způsob zálohování dat, než opakování plných záloh. Výhodou je úspora úložného prostoru, potřebného pro tento typ zálohování. Ovšem velkou nevýhodou je, že pokud dojde ke ztrátě nebo poškození jakékoliv části dat i v jednom z přírůstků, nelze již obnovit data ani z dalších přírůstků, které za tímto poškozeným následují. Posledním typem je diferenciální (rozdílová) zálohoha, která ukládá všechny změny oproti od poslední úplné zálohy. Výhodou diferenciální zálohy je, že se zkrátí čas obnovení v porovnání s plnou zálohou. Nicméně pokud bude diferenciální záloha prováděna velmi často, může její velikost být dokonce větší, než jak by tomu bylo u plné zálohy.

Obrázek 2.4: Princip jednotlivých typů zálohování


2.5.2

23

Média pro zálohování

Pro ukládání dat se používá několik typů datových médií. Nejčastěji se ve firmách používají magnetické pásky pro nízkou pořizovací cenu média. Dalším typem pro zálohování se používají magnetické pevné disky, kde je výhodou nízká přístupová doba, kapacita média. Dnes začínají být vytlačovány SSD (Solid-state drive) disky, které neobsahují pohyblivé mechanické části. Nevýhodou těchto médií je omezená životnost počtu zápisů. Pro osobní použití lze využít USB flash disky, nebo různé druhy paměťových karet.

2.5.3

Rozdělení podle topologie úložiště

Podle typu úložiště můžeme rozdělit technologie pro ukládání dat do tří typů. Prvním typem je úložiště DAS (Direct Attached Storage). Jedná se o jakékoliv úložiště, které je přímo kabelem propojeno k PC nebo serveru na dedikovanou sběrnici. Bývají to nejen běžné disky SATA a SAS, ale také externí disky připojené například přes rozhraní USB nebo FireWire. Výhodou DAS jsou nízké vstupní náklady a přiměřený výkon, problémem jsou omezené možnosti rozšíření. Dalším typem úložiště je NAS (Network Attached Storage). Jsou to souborově orientovaná úložná zařízení s integrovaným LAN rozhraním a variabilním počtem za chodu připojitelných pevných disků. Využití nacházejí převážně v menších firmách a u domácích uživatelů, kteří mají LAN síť, a postupně nashromáždili mnoho dat a projevila se u nich potřeba přístupu k nim z několika počítačů. Výhodné je rovněž lepší využití instalované kapacity disků.

Obrázek 2.5: Princip jednotlivých topologií zálohování

Posledním typem jsou systémy SAN (Storage Area Network). SAN dedikovaná

24


datová síť, navržená pouze k datovým přenosům – slouží pro zpracování a ukládání velkého množství dat. Architektura SAN vyžaduje infrastrukturu sestavenou z tzv. FC (Fiber Chanel) switchů , na rozdíl od DAS využívá SAN externí RAID (Redundant Array of Inexpensive/Independent Disks) řadiče, využívá optické kabely. SAN se proto hodí pro střední až velké společnosti, které požadují vysokou dostupnost svých služeb, rychlé odezvy a škálovatelnost.

2.5.4

Nástroje pro zálohování v Linuxu

Ukážeme si jednoduchý postup zálohování dat pomocí nástroje rsync, který bývá standardně na linuxových distribucích naistalován. Zálohu můžeme provádět manuálně, příkazem: rsync -av data/* backup Pokud chceme zálohování zautomatizovat, využijeme program cron, který zajistí pravidelné spouštění programu rsync. crontab -e * * * * * rsync -av /home/student/data/* /home/student/backup Adresář backup, může být připojený přes protokol NFS (Network File System). Data se automaticky budou ukládat na NFS server. Program rsync je velmi flexibilní a lze využívat různé přepínače. Pro bližší použití programu lze využít zabudované manuálové stránky. man rsync


3

25

REPORTY A LOGOVÁNÍ DAT

Pro lepší správu počítačových systémů a sítí je velmi žádoucí používat záznamy činností a operací, které již proběhly. Jedním ze způsobů jsou různé logovací zařízení. Výhodou tohoto řešení je, že se data ukládají na centrální server, kde mohou být následně dále zpracovávána. Jedná se o komunikaci typu klient server, kdy syslog daemon přijímá informace, které jsou posílány jednotlivými klienty daných zařízení. Původní syslog vznikl v roce 1980 jako součást projektu Sendmail. Následně se stal standardem v unixovém světě. Nakonec byl standardizován skupinou IETF jako RFC 3164 v roce 2001 a v roce 2009 byl nahrazen novým standardem 5424.

3.1

Syslog

Syslog je standard pro logování počítačových dat. Tento systém sbírá data z různých zařízení, ukládá je do souborů, nebo databáze a následně je může analyzovat a vytvářet různé reporty. Syslog protokol komunikuje přes protokol UDP na portu 514. Syslog může být použit pro systémový management a jako bezpečnostní audit počítačových systémů. Také může být využíván pro shromažďování, analýzu a odlaďování dat z různých zařízení. Je podporován na řadě různých zařízení, jako jsou směrovače, přepínače, servery, tiskárny a mnoho dalších síťových zařízení. Jednolivé zprávy se mohou odkazovat na různá úrovně zařízení (facility), například kernel, uživatel, mail, daemon, authentikace, cron, atd. Těmto zprávám jsou přiřazeny příslušné priority (severity), které definují důležitost dané zprávy. Jednotlivé priority jsou emergency, alert, critical, error, warning, notice, informational, a debug. Nejdůležitější jsou zprávy emergency, které znamenají nefunkčnost daného zřízení, jedná se například o hlášku kernel panic. Další v pořadí důležitosti je zpráva alert, kdy je nutný okamžitý zásah na daném zařízení, může se například jednat o ztracení konektivity na poskytovatele internetových služeb. Třetí nejdůležitější zprávou je critical, která by také měla být co nejdříve opravena. Může se jednat například o výpadek záložního internetového připojení. Další zprávou je zpráva error, která ohlašuje chybu, která může být opravena v určitém časovém intervalu. Zpráva warning upozorňuje na důležitou informaci, která není chybou, ale upozorňuje na důležitý stav. Poslední tři zprávy jsou pouze informativní a neznamenají žádnou chybu systému. Zprávy debug slouží pro vývojáře pro odlaďování aplikací.

26


3.2

Syslog protokol

Syslog protocol se skládá ze tří vrstev. Na následujícím obrázky jsou zobrazeny jednotlivé vrstvy Syslog protokolu.

Obrázek 3.1: Syslog vrstvy

Syslog se skládá z jednotlivých komponent. Originator generuje syslog obsah, který je přenášen pomocí systémových zpráv. Collector sbírá jednotlivé zprávy pro další zpracování. Relay přeposílá jednotlivé zprávy.

3.3

Syslog formát zpráv

Formát zpráv je definován v doporučení RFC 5424. Skládá ze tří částí: PRI, HEADER, MSG. Celková délka paketu by neměla převýšit hodnotu 1024 oktetů. Část PRI obsahuje informace o důležitosti zprávy (severity) a kdo zprávu vygeneroval (facility). Tato část má osm bitů, kde tři nižší bty jsou určeny pro důležitost zprávy a pět vyšších bitů je určeno pro facility dané zprávy. Hodnota PRI se počítá jako 𝑃 𝑅𝐼 = 𝑓 𝑎𝑐𝑖𝑙𝑖𝑡𝑦 * 8 + 𝑠𝑒𝑣𝑒𝑟𝑖𝑡𝑦. Část HEADER obsahuje časovou značku, kdy byla zpráva vygenerována a IP adresu, nebo hostname daného zařízení. Z tohoto důvodu je velmi důležité mít synchronizované časy jednak na zařízení, které zprávy generuje a na Syslog serveru. Pro udržení stejného času v síti se používá protokol NTP (Network Time Protocol). Poslední část MSG obsahuje dvě pole. První pole TAG určuje program, nebo proces, který zprávu vygeneroval. Druhé pole CONTENT obsahuje vlastní textovou zprávu. Následuje výpis systémové zprávy: Jul 27 14:54:46 student NetworkManager:


27

DHCP: device wlan0 state changed bound -> renew

3.4 3.4.1

Instalace a konfigurace Syslog serveru Syslog

Syslog server bývá na Linuxu již standardně nainstalován. Většinou je pro server použit program rsyslogd. Spuštený Syslog server nejlépe zjistíme příkazem: ps -A | grep log Nastavení Syslog serveru provedeme pomocí textového editoru: nano /etc/rsyslog.conf Standardně jsou logovací informace ukládány lokálně do adresáře /var/log. Pokud chceme posílat logovací informace na Syslog server v síti, musíme to nakonfigurovat: nano /etc/rsyslog.d/50-default.conf kde stačí vložit jeden řádek, kde bude informace, co se má posílat a na jakou IP adresu. *.*

@192.168.1.10

Pokud provedeme nejaké změny v konfiguračním souboru, je nutné restartovat Syslog server příkazem: service rsyslog restart Informace, které jsou ukládány na Syslog server, můžeme sledovat v reálném čase příkazem: tail -f /var/log/syslog Také můžeme otestovat, zda jsou informace posílany na Syslog server příkazem: logger -p user.info "Testovací zpráva"

3.4.2

Syslog-ng

Syslog-ng se trochu liší od klasického syslogu. Je mnohem víc konfigurovatelný, snadno se dají zadávat vlastní třídící pravidla. Server pro sběr logů můžete nastavit celkem jednoduše, je třeba udělat pár změn v souboru: source s_net {

28


udp(); };

Použijeme UDP z důvodu zpětné kompatibility se starým syslogem. Lze udělat více zdrojů, třeba pro každý server který bude na loghosta logovat jeden zdroj. Pak se to zadává pomocí: udp(ip(10.0.0.1) port(514)); Dále nadefinujeme samostatný soubor do kterého se budou ukládat logy ze sítě. destination d_net { file("/var/log/net.log"); }; A nakonec nastavíme vlastní logování dat ze sítě do samostatného souboru: log { source(s_net); destination(d_net); };

Cílový soubor pro logy můžete udělat pro každý stroj samostaný: source s_net {udp();}; destination d_net{ file("/logy/$HOST/$YEAR/$MONTH/$FACILITY-$YEAR$MONTH" \ owner(root) group(root) perm(0600) dir_perm(0700) create_dirs(yes));}; log { source(s_net); destination(d_net); };

Lze nastavit i logování po síti protokolem TCP tcp(ip(0.0.0.0) port(5000)); Nastavení na straně klienta nadefinujete jako cíl UDP: udp("loghost" port(514));


4

29

MONITOROVÁNÍ A MANAGEMENT SÍTÍ

Monitorování umožňuje sledování vybraných parametrů sítě v reálném čase. Slouží zejména pro odhalování problémů v síti a ke kontrole provozu. Management sítě je souhrn funkcí požadovaných pro kontrolu, plánování, rozvržení, rozmístění, koordinaci a monitorování zdrojů sítě.

4.1

SNMP Protocol

SNMP (Simple Network Management Protocol) je standard pro správu zařízení v IP sítích. Mezi zařízení, která lze spravovat patří zejména směrovače, přepínače, koncové stanice, servery, tiskárny a mnoho dalších zařízení. Hodnoty se z jednotlivých zařízení získávají pravidelně a pak se mohou ukládat do databáze společně s časem a následně vykreslit do grafu. Přehledně tak můžeme zobrazit třeba vytížení procesoru, spotřeba paměti, průběh teploty, nebo datový tok na portu přepínače.

Obrázek 4.1: Zobrazení průběhu při získání dat pomocí SNMP

4.1.1

SNMP verze

Protokol SNMP existuje ve třech verzích. SNMPv1 posílá informace v otevřeném textu a neumožňuje šifrování. SNMPv2c používá pro autentikaci tzv. community string, což je v podstatě textové heslo. SNMPv3 využívá jak autentikaci pomocí jména a hesla, tak umožňuje šifrování přenášených dat.

4.1.2

SNMP popis

SNMP se skládá ze tří základních komponent. NMS (Network Management System) je software pro monitorování a řízení jednotlivých zařízení. Agent je softwarový modul na

30


monitorovaném zařízení. MIB (Management Information Base) je databáze kterou používajá NMS a agent pro čtení, nebo nastavení určitých parametrů. Tato databáze má hierarchickou strukturu a je popsána pomocí OID (Object Identifiers).

Obrázek 4.2: Princip komunikace pomocí SNMP protokolu

SNMP pracuje na aplikační vrstvě. Na transportní vrstvě je využíván protokol UDP s portem 161, kdy NMS posílá požadavky na agenta. Nebo je využíván port 162 pro zprávy zasílané agentem (Trap, InformRequest), pokud je například překročena nastavená prahová hodnota nějakého parametru. SNMP používá pro výměnu informací několik typů zpráv. Některé zprávy posílá NMS stanice a některé zprávy posílá agent. Zprávu GetRequest, GetNextRequest a GetBulkRequest posílá stanice NMS pro zjištění požadovaných parametrů na základě MIB databáze. Agent odpovídá zprávou Response, která obsahuje požadované informace. Zprávu SetRequest používá NMS stanice pro nastavení požadovaného parametru na agentovi. Agent může odeslat zprávu Trap jestliže byla překročena hodnata některého parametru. Pro potvrzený přenos informací se používá zpráva InformRequest.

4.1.3

MIB databáze

Každá hodnota v SNMP je jednoznačně identifikována pomocí číselného identifikátoru OID - Object Identifier. OID je tvořeno posloupností čísel oddělených tečkou, tato hodnota vznikne tak, že se vezme OID nadřazeného prvku a doplní se tečka a aktuální číslo. Celá tato stromová struktura je uložena v MIB databázi. Navíc MIB databáze obsahuje jména a popisy jednotlivých hodnot (OID). MIB databáze může být doplněna o další hodnoty pomocí části struktury uložené v MIB souboru.

4.2

NetFlow

NetFlow je protokol jehož hlavním úkolem je monitorování síťového provozu na základě IP toků, které jsou potom analyzovány. Tento protocol může být využíván například pro


31

Obrázek 4.3: Náhled do MIB databáze

statistiky provozu, vyhledávání různých síťových incidentů, zjišťování úzkých míst v síti, apod.

4.2.1

NetFlow architektura

NetFlow architektura se typicky skládá z několika NetFlow exportérů a jednoho NetFlow kolektoru. NetFlow exportér je připojen k monitorované lince a analyzuje procházející pakety. Na základě zachycených IP toků generuje NetFlow statistiky a ty exportuje na NetFlow kolektor. NetFlow kolektor je zařízení s velkou úložnou kapacitou, které sbírá statistiky z většího počtu NetFlow exportérů a ukládá je do dlouhodobé databáze. Nad těmito daty obvykle běží aplikace, která je umí efektivně vizualizovat a generovat z nich přehledy v podobě grafů a tabulek, které umožňují jednoduše analyzovat monitorovaný provoz i běžnému uživateli. Základem NetFlow jsou IP toky, které obsahují statistiky provozu. Pro každý tok je zaznamenán čas vzniku, délka jeho trvání, počet přenesených paketů a bajtů a další údaje. Tyto statistiky neobsahují uživatelská data. Technologie NetFlow statistik umožňuje vyhodnotit data online na bázi modelu SaaS (Software as a Service). NetFlow protokol postupně vznikl v několika verzích. Nejčastěji se stále ještě používá verze 5. Pro podporu IPv6 je nutné používat verzi 9. Poslední verze je verze 10, která rozšiřuje předchozí verzi o Enterprise-defined typů polí a proměnlivou délku jednotlivých položek.

32


Obrázek 4.4: NetFlow architektura

Obrázek 4.5: NetFlow statistiky

4.3

Instalace a konfigurace SNMP

SNMP agenta nainstalujeme pomocí příkazu: apt-get install snmpd Pokud chceme získat více informací je vhodné odkomentovat jeden řádek v konfiguračním souboru:

nano /etc/snmp/snmpd uncoment: com2sec readwrite default

private

Následně restartujeme službu SNMP agenta: service snmpd restart NMS aplikace naistalujeme pomocí příkazu: apt-get install snmp


33

Nyní můžeme vyzkoušet SNMP protokol na vlastním stroji příkazem: snmpwalk -v 2c -c private localhost Na výstupu získáme všechny informace, které jsou k dispozici na lokálním zařízení. Pokud budeme chtít používat SNMPv3, je nutné vytvořit v konfiguračním souboru příslušné účty: nano /etc/snmp/snmpd.conf createUser user1 createUser user2 MD5 user2password createUser user3 MD5 user3password DES user3encryption rouser user1 noauth 1.3.6.1.2.1.1 rouser user2 auth 1.3.6.1.2.1 ... authentication rwuser user3 priv 1.3.6.1.2.1 ... privacy

Nyní lze vyzkoušet SNMPv3, kdy vyčteme jeden parametr pomocí OID: snmpget -v 3 -u user1 -l NoauthNoPriv localhost 1.3.6.1.2.1.1.1.0 SNMPv2-MIB::sysDescr.0 = STRING: Linux student 2.6.32-52-generic-pae #114-Ubuntu SMP Wed Sep 11 19:15:42 UTC 2013 i686 snmpget -v 3 -u user2 -l authNoPriv -a MD5 -A user2password localhost 1.3.6.1.2.1.1.1.0 SNMPv2-MIB::sysDescr.0 = STRING: Linux student 2.6.32-52-generic-pae #114-Ubuntu SMP Wed Sep 11 19:15:42 UTC 2013 i686

snmpget -v 3 -u user3 -l authPriv -a MD5 -A user3password -x DES -X user3encryption localh SNMPv2-MIB::sysDescr.0 = STRING: Linux student 2.6.32-52-generic-pae #114-Ubuntu SMP Wed Sep 11 19:15:42 UTC 2013 i686

4.4

Instalace a konfigurace NetFlow

Nejdříve nainstalujeme program pro posílánání NetFlow informací, tzv NetFlow exporter, příkazem: apt-get install fprobe Upravíme konfigurační soubor: nano /etc/default/fprobe INTERFACE = "eth0" FLOW_COLLECTOR = "10.0.0.2:10000" OTHER_ARGS = "-fip"

34


Nyní můžeme na druhém PC naistalovat NetFlow Collector pro sběr dat, příkazem: apt-get install nfdump A nakonec můžeme sbírat data do adresáře netflow pomocí příkazu: nfcapd -p 10000 -n p2,10.0.0.1, netflow Data lze zobrazit příkazem: nfdump -R netflow/data Následuje zkrácený výpis dat: Date flow start Duration Proto Src IP Addr:Port 2013-02-23 18:54:13.326 3.998 ICMP 10.0.0.2:0 -> 2013-02-23 18:54:13.326 3.998 ICMP 10.0.0.1:0 -> 2013-02-23 18:55:01.358 0.000 TCP 10.0.0.1:39199 -> 2013-02-23 18:55:01.359 0.000 TCP 10.0.0.2:10000 -> 2013-02-23 18:55:11.135 0.000 UDP 10.0.0.1:53315 -> 2013-02-23 18:55:11.035 0.000 UDP 10.0.0.1:53314 -> 2013-02-23 18:55:23.000 55.000 UDP 10.0.0.1:49849 ->

Dst IP Addr:Port Pkts Bytes Flows 10.0.0.1:0.0 5 420 1 10.0.0.2:8.0 5 420 1 10.0.0.2:10000 1 44 1 10.0.0.1:39199 1 40 1 10.0.0.2:10000 1 28 1 10.0.0.2:10000 1 28 1 10.0.0.2:10000 3 444 1


5

35

VYKRESLOVÁNÍ GRAFŮ POMOCÍ NÁSTROJE RRDTOOL

RRD Tool (Round-Robin Database tool) je opensource nástroj, který se zaměřuje na zpracování a ukládání časově závislých dat, například teplota, zatížení procesoru, síťový provoz a další. Tato data mohou být vykreslována v přehledných grafech. Round Robin je technika, která pracuje s pevným množství dat, a ukazatelem na aktuální prvek. Nejdříve se musí vytvořit vhodná databáze, která se následně postupně plní příslušnými daty. Dato data jsou nakonec vykreslována do grafů. Pro pravidelné aktualizace dat a vykreslování grafů se používají skriptovací jazyky bash, perl, python, ruby, lua, nebo tcl aplikace.

5.1

Vytvoření databáze

Funkce create vytvoří nový soubor s databází RRD. Takto vytvořená databáze je naplněna neznámými daty pro všechny vzorky. Syntaxe k vytvoření databáze je následující: rrdtool create filename [–start|-b start time] [–step|-s step] [–no-overwrite] [DS:ds-name:DST:dst arguments] [RRA:CF:xff:steps:rows]

Vytvořený soubor by měl mít příponu .rrd. Dále definujeme čas, kdy začneme sbírat data a interval ve kterém jsou data sbírána. DS (Data Source) definuje zdroj dat, které budou ukládány do databáze. Do jedné databáze můžeme vkládat hodnoty více proměnných. RRA (Round Robin Archive) určuje, jak se budou data ukládat. Pomocí RRA si určujeme, kolik hodnot na určený interval si databáze uchová. Můžeme tedy uchovat více hodnot pro interval jednoho měsíce, méně hodnot pak pro interval jednoho roku. V závislosti na RRA a počtu proměnných DS je určena velikost souboru. Příklad vytvořené databáze: rrdtool create mem.rrd –start N –step 3 DS:memory:GAUGE:10:0:U RRA:MAX:0.5:1:100

Vytvoří se soubor s názvem mem.rdd. Základní krok budou tři sekundy. Jedinná proměnná memory, minimální hodnota bude 0 a maximální hodnota bude neznámá. Archiv bude sbírat každou hodnotu, těchto hodnot bude 100. Maximální časový interval je proto 300 sekund, Starší hodnoty budou smazány.

36


5.2

Vložení dat do databáze

Příkaz update slouží k vkládání nových dat do databáze. Data jsou v databázi automaticky přeskládána podle zadaných parametrů při vytvoření databáze. Syntaxe pro vkládání dat do databáze je následující: rrdtool update filename [–template|-t ds-name[:ds-name]...] [–daemon address] [–] N|timestamp:value[:value...]

Příklad vložení dat do databáze: mem=‘free | grep ’Mem:’ | awk {’print $3’}‘ rrdtool update mem.rrd –template memory N:$mem

Do proměnné mem si uložíme jen číselnou hodnotu paměti. Data z proměnné mem se budou ukládat do předen vytvořene databáze mem.rrd.

5.3

Vytvoření grafu

Používá se k reprezentaci dat v podobě čitelné pro člověka. Hlavním cílem je vytvoření grafické podoby dat, může ale generovat i číselné zprávy. Příkaz potřebuje k práci nějaké hodnoty, je tedy nutné připojit alespoň jednu proměnnou z RRD souboru. Hodnot může být více z vícero souborů. Syntaxe pro vytvoření grafu je následující: rrdtool graph filename [option ...] [data definition ...] [data calculation ...] [variable definition ...] [graph element ...] [print element ...]

Příklad pro vytvoření grafu rrdtool graph mem2.png –start 1352235465 –end 1352235510 –title Graf_vyuziti_pameti -w 800 -h 600 DEF:mymem=mem.rrd:memory:MAX LINE2:mymem#ff0000


37

Vytvoří se obrázek s názvem mem2.png. Graf bude vykreslovat data od start do hodnoty end. Název grafu bude Graf vyuziti pameti. Velikost obrázku v pixelech bude 800x600. Budou použita data z databáze mem.rrd a jeho proměnné memory. Graf bude vykreslen červenou barvou, jak je vidět na obrázku 5.1.

Obrázek 5.1: Využití nástroje RRDtool pro zobrazení vytížení paměti

5.4

Výpis informací a dat z databáze

Pokud potřebujeme zjistit základní informace o nastavení databáze můžeme zadat příkaz: rrdtool info mem.rdd Výpis může vypadat následovně: filename = "mem.rrd" rrd_version = "0003" step = 3 last_update = 1383765043 ds[memory].type = "GAUGE" ds[memory].minimal_heartbeat = 10 ds[memory].min = 0.0000000000e+00 ds[memory].max = NaN ds[memory].last_ds = "1393276" ds[memory].value = 2.1836341034e+06

38


ds[memory].unknown_sec = 0 rra[0].cf = "MAX" rra[0].rows = 100 rra[0].cur_row = 43 rra[0].pdp_per_row = 1 rra[0].xff = 5.0000000000e-01 rra[0].cdp_prep[0].value = NaN rra[0].cdp_prep[0].unknown_datapoints = 0

Případně můžeme vypsat obsah databáze pomocí příkazu: rrdtool dump mem.rrd Zkrácený výpis může vypadat následovně: 0003 <step> 3 1383765043 memory GAUGE <minimal_heartbeat> 10 <min> 0.0000000000e+00 <max> NaN MAX 1 <params> <xff> 5.0000000000e-01 <primary_value> 1.4253661808e+06 <secondary_value> 1.4253661808e+06 NaN 0 1.1274096799e+06 1.3528471469e+06


6

39

SLEDOVÁNÍ PROVOZU V IP SÍTÍCH

Pro zvýšení bezpečnosti a řešení problémů v sítích potřebujeme různé paketové analyzátory, které umožňují sledovat provoz v reálném čase a analyzovat data podle různých kritérií. Někdy bývají tyto analyzátory součástí většího projektu, jindy jsou to jednoúčelové programy. V této kapitole se budeme zabývat dvěma programy se kterými se můžeme nejčastěji setkat. Výhoda textových analyzátorů je možnost využívat skripty, které mohou určité činnosti automatizavat a lépe potom využít možnsti nasbíraných dat. Grafické analyzátory jsou zase přehlednější a názornější.

6.1

Paketový analyzátor tcpdump

Paketový analyzátor tcpdump umožňuje sledovat provoz v reálném čase a nebo analyzovat již uložená data. Pro svou činnost využívá knihovnu libpcap a analyzuje provoz od druhé vrstvy OSI (Open System Interconnection) modelu.

Obrázek 6.1: Náhled na výstup programu tcpdump

Program tcpdump je používán pro analýzu chování sítí, jejjich výkonu a aplikací, které generují nebo příjímají pakety. Může také být použít pro analýzu síťové infrastruktury, kde je možno vyhledávat různé síťové problémy. Také je možno použít tento program pro specifičtější účely zachytávání a zobrazování komunikace uživatele, nebo zařízení. Uživatel s právy správce může například na routeru sledovat komunikaci nezašifrovaných služeb, jako je telnet nebo HTTP, ze kterých lze zobrazit uživatelské údaje, jako je uživatelské jméno nebo heslo, URL adresu, obsah webové stránky, která je právě zobrazována nebo jiné informace.

40


6.2

Paketový analyzátor Wireshark

Program Wireshark je open-source grafický paketový analyzátor, který umožňuje sledovat provoz v reálném čase, nebo analyzovat již zachycená data. Umožňuje nastavovat různé fitry tak, aby se daly zachytit pouze data, která nás zajímají. Dají se také použít různé pluginy pro podporu nových protokolů. Wireshark v linuxu také sleduje provoz na USB rozhraní. Na obrázku 6.2 je náhled na Wireshark s vykresleným grafem vytížení linky.

Obrázek 6.2: Náhled na Wireshark s vykresleným grafem

Wireshark umožňuje uživateli nastavit síťová rozhraní, která to podporují, do promiskuitního módu, čímž umožní vidět veškerý provoz na těchto rozhraních, včetně broadcastu a multicastu, ne jen provoz určený jedné určité adrese rozhraní. Při zachytávání paketů analyzátorem v promiskuitním modu na portu switche se nemusí veškerý provoz skrze switch nutně dostat na port, kde se zrovna zachytává, takže zachytávání v promiskuitním modu nebude dostačující pro veškerý provoz na síti. Je nutné využít port mirroring nebo různá zařízení rozšiřující příjem do zvolené části sítě. Existuje také terminálová verze tshark, která umí to samé co grafická verze s tím, že je možno využít různé skripty a zejména nastavit fitry, které budou vybírat pouze požadovaný provoz v síti. Na následujícím obrázku je výstup programu tshark.


41

Obrázek 6.3: Náhled na výstup programu tshark

6.3

Paketový analyzátor pro bezdrátové sítě Kismet

Kismet je 802.11 L2 bezdrátový síťový detektor, který slouží pro sledování sítí a také může sloužit jako IDS (Intrusion Detection System). Tento program pracuje s bezdrátovými síťovými kartami, které podporují tzv. raw monitoring. Kismet identifikuje sítě pasivním sběrem paketů a detekuje SSID (Service Set Identifier) názvy sítí, případně u skrytých sítí detekuje jejich názvy z provozu. Podporuje logování paketů do formátu, který může být dále zpracováván programy tcpdump, tshark, wireshark apod. Podporuje také gpsmap pro lokalizaci objektů na mapě. Pro spuštění programu Kismet je zapotřebí nastavit v konfiguračním souboru zdroj, odkud budou data snímána. nano /etc/kismet/kismet.conf source=iwlagn,wlan0,test

První položka je ovladač bezdrátové karty, druhá položka je označení bezdrátového rozhraní a poslední položka je popis zařízení. Na obrázku 6.4 je náhled na program kismet. Na obrázku Kismet zobrazuje v reálném čase jednotlivé bezdrátové sítě, použití zabezpečení, přidělené IP adresy, počty paketů a další informace. V průběhu lze zobrazovat také různé statistické údaje. Na obrázku je vidět jaké kanály používají jednotlivé sítě.

42


Obrázek 6.4: Náhled na výstup programu kismet


7

43

ADRESÁŘOVÉ SLUŽBY

Adresářové služby (Directory Services) jsou databázové služby, ve kterých jsou uloženy informace o pojmenovaných objektech. Tyto objekty jsou organizovány a sdružovány do skupin. Tyto služby jsou vhodné pro časté čtení a vyhledávání a pouze pro občasný záznam, nebo změnu záznamu. V adresáři mohou být uchovávána data různých typů, text, obrázek, digtální certifikáty. Můžeme také omezovat přístup k těmto datům pomocí ACL (Acces Control List). Data jsou ukládána formou záznamů a jsou uspořádána do stromové struktury.

7.1

Adresářové služby LDAP

Adresářové služby slouží pro ukládání a přístup k datům na adresářovém serveru. LDAP (Lightweight Directory Access Protocol) je aplikační protokol pro dotazování a modifikaci adresářových služeb. Adresářové služby mohou obsahovat seznamy zaměstnanců, jejich přihlašovací jména, domovské adresáře, osobní informace, emailové a telefonní informace. Mohou se také uchovávat nastavení uživatelských programů, nebo se mohou ukládat informace o různých zařízení, včetně jejich evidenčních údajů. LDAP je protokol, který umožňuje vkládat, modifikovat, mazat a zejména rychle vyhledávat požadované informace na základě různých vstupních parametrů, neboli atributů. Jednotlivé záznamy mají definovány povinné a volitelné atributy, které se definují pomocí objektů, které jsou nadefinovány na serveru ve stromové hierarchii.

Obrázek 7.1: Hierarchická struktura LDAP stromu

LDAP používá LDIF (LDAP Data Interchange Format) pro standardizovaný textový formát výměny dat. Data jsou při přenosu kódována pomocí standardních pravidel. Ná-

44


sleduje výpis dat ve formátu LDIF: dn: uid=petr.novak,dc=abc,dc=cz objectClass: person cn: Petr Novák sn: Novák userPassword: {SSHA}NYvO6jDBU1cJ11nhol37Xo9T5eOLe9Ci telephoneNumber: 2114 description: Petr Novák je průměrný český muž.

LDAP protokol standardně využívá tcp port 389, nebo při zabezpečené komunikaci se používá tcp port 636. Pro bezpečnou komunikaci se používá SASL (Simple Authentication and Security Layer), což je framework pro vzájemnou autentikaci a šifrovaný přenos dat pomocí internetových protokolů. SASL je definován v doporučení RFC4422.

7.2

Informační model LDAP

Informačí model popisuje strukturu informací v adresáři. Definuje datové typy a informace formou záznamů. Jednotlivé záznamy jsou uloženy pomocí stromové struktury, z důvodu snadnějšího vyhledávání informací na základě vzorů. Každý záznam musí mít definovány atributy. Ty se definují pomocí objektů (object class), jak je vidět na následujícím výpisu. objectclass ( 2.5.6.6 NAME ’person’ DESC ’RFC2256: a person’ SUP top STRUCTURAL MUST ( sn $ cn ) MAY ( userPassword$telephoneNumber$seeAlso$description )) attributetype ( 2.5.4.4 NAME ( ’sn’ ’surname’ ) DESC ’RFC2256: last (family) name(s) for which the entity is known by’ SUP name )

Implementace informačního modelu se označuje jako schéma. Schéma je sada objektů, které definují strukturu a obsah každého objektu, který může být vytvořen v adresářové službě. Schéma definuje všechny možné třídy objektů a atributy. Třídy objektů objectClass jsou kategorie objektů, které mohou být vytvořené v adresáři. Může se jednat např. o objekty user, computer, domain, container, group. Atributy objektů jsou vlastnosti jednotlivých objektů. Atribut může obsahovat jednu, nebo více hodnot, např. jméno, příjmení, e-mail. Určité atributy patří k určité třídě


45

objektů a schéma také definuje, které hodnoty musí být vyplněny a které jsou volitelné. Schéma také určuje, jaké typy hodnot může atribut nabývat, například textový řetězec, celé číslo.

7.3

Jmenný model LDAP

Jmenný model popisuje jak jsou informace organizovány a odkazovány. Pro identifikaci objektů se používá DN (Distinguished Name), což je jednoznačný identifikátor objektu a obsahuje úplnou cestu k záznamu, nebo-li určuje pozici ve stromě. DN se skládá ze jména objektu a jmen jednotlivých kontejnérů a domén, které obsahují objekt, oddělený čárkou. Jednotlivé položky obsahují název atributu a přiřazenou hodnotu atributu, např. ou=zamestnanci.

Na následujícím obrázku 7.2 je pro doménu firma.cz v kontejneru ou=zamestnanci umístěn uživatel Jan Novák, pro kterého je DN = cn=Jan Novák,ou=zamestnanci,dc=firma,dc

Obrázek 7.2: Jmenný model LDAP

Každá část DN je vyjádřena pomocí typ atributu=hodnota. V LDAP se používá několik jmenných atributů, CN Common Name, OU Organization Unit, O Organization, C country.

7.4

Funkční model

Funkční model definuje, co se může provádět s informacemi v adresářích. Celkem existuje devět základních operací, které jsou rozdělěny do tří skupin. První skupinu tvoří aktualizace záznamů, kde můžeme přidávat nové informace, modifikovat stávající, přesouvat

46


informace, nebo mazat informace. Druhou skupinu tvoří dvě dotazovací funkce, jedna je vyhledávací a druhá porovnávací funkce. Poslední skupinu tvoří tři autentikační funkce pro vytvoření spojení a ukončení spojení s daty, nebo bez dat. Nejdůležitější je dotazovací funkce search, která může obsahovat řadu vstupních parametrů. Jedním z nich může být výchozí bod hledání, který určuje část od které se začne vyhledávat. Dalším parametrem mohou být různé filtry. Tyto filtry mohou používat různé matematické operace, shoda (atribut = hodnota), větší než (atribut >= hodnota), apod.

7.5

Bezpečnostní model

Bezpečnostní model určuje, jakým způsobem se přistupuje k jednotlivým datům a jak jsou data chráněna proti neoprávněnému přístupu. Využívá se různých autentikačních služeb, také mohou být definovány přístupové seznamy, tzv ACL. access to * by self write by * read access to attr = userPassword by self write by * none

U LDAP v2 bylo zabezpečení často řešeno tunelováním veškeré komunikace přes SSL (Secure Socket Layer). LDAP v3 přidává nový příkaz StartTLS, který zahájí komunikaci prostřednictvím TLS (Transport Layer Security). Pro ověření identity serveru a volitelně i klienta, je použít X.509 certifikát.

7.6

Instalace a konfigurace OpenLDAP

Instalaci openldap serveru provedeme příkazem: apt-get install slapd Instalaci clientských nástrojů provedem příkazem: apt-get install ldap-utils Po instalaci je nutno nakonfigurovat základní parametry do konfiguračního souboru: nano /etc/ldap/ldap.conf LDAP server lze spustit manuálně z terminálu pomocí příkazu: slapd -256


47

Nyní můžeme spustit z terminálu příkaz ldapsearch Při tomto spuštění vypisuje LDAP server průběh komunikace:

conn=1001 fd=10 ACCEPT from IP=[::1]:43432 (IP=[::]:389) conn=1001 op=0 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" conn=1001 op=0 SRCH attr=supportedSASLMechanisms conn=1001 op=0 SEARCH RESULT tag=101 err=0 nentries=1 text= conn=1001 op=1 BIND dn="" method=163 conn=1001 op=1 RESULT tag=97 err=14 text=SASL(0): successful result: security flags do not conn=1001 op=2 BIND dn="" method=163 SASL [conn=1001] Failure: no secret in database conn=1001 op=2 RESULT tag=97 err=49 text=SASL(-13): user not found: no secret in database conn=1001 fd=10 closed (connection lost)

Příkazem ldapadd přidáváme nový záznam do databáze. A příkazem ldapdelete můžeme smazat záznam z databáze

48



8

49

OVĚŘENÍ IDENTITY OBJEKTU

Autentikace je proces ověření identity objektu. Po úspěšné dokončení autentikace obvykle následuje autorizace, což je souhlas, schválení, umožnění přístupu, či provedení konkrétní operace daným subjektem. Také se dost často využívá i účtování, nebo-li záznam o činnosti využívání služeb.

Obrázek 8.1: Využití principu autentikace při přihlášení na www stránkách

8.1

Autentikace

Autentikace je ověření identity uživatele, zařízení, objektu, programu, aplikace, apod. Autentikace znamená ověření pravosti a využívá se zejména při bezpečnostních opatřeních. Zajišťuje ochranu před falšováním identity. Autentikace uživatele, může být podle toho co zná. Například, kombinace uživatelského jména a hesla, nebo jenom podle PINu. Autentikace uživatele podle toho co vlastní. Například, hardwarový klíč, smart karta, USB token apod. Autentikace podle toho čím uživatel je. Existují různé biometrické vlastnosti. Například autentikace na bázi otisku prstu, snímek oční duhovky, nebo sítnice, otisk dlaně apod. Více-faktorová autentikace využívává několika metod ověření. Například využití USB tokenu a hesla.

50


Obrázek 8.2: Využití principu biometrické autentikace

8.2

Autorizace

Autorizace je proces získávání souhlasu s provedením nějaké operace, povolení přístupu někam, k někomu nebo něčemu. Mohou existovat různé restrikce, například časové omezení. Autorizace na základě seznamu oprávnění se používá například pro řízení přístupu k souborům, adresářům, operacím a přístupu k prostředkům v počítači. Autorizaci provádí obvykle operační systém nebo specializovaný software na základě seznamů pro řízení přístupu. Například po úspěšné autentikaci přístupu na routeru, máme autorizaci vykonávat jen určité příkazy, nastavení, výpisy, apod.

8.3

Účtování

Účtování znamená sledování využívání síťových služeb uživateli. Tyto informace mohou být použity pro správu, plánování, účtování, nebo další účely. Účtování v reálném čase je doručeno současně s využíváním zdrojů. Dávkové účtování ukládá informace o účtech dokud není později doručena. Běžně se sbírají informace o identitě uživatele, povaze dodaných služeb a časy počátků a konců dodaných služeb. Účtování je v podstatě logování zpráv.


8.4

51

Autentikace pomocí PAM (Pluggable Authentication Modules) modulů

PAM (Pluggable Authentication Modules) je sada knihoven, používaná pro autentikaci uživatele vůči programům v Linuxu, BSD systémech a dalších unixových systémech. Cílem je oddělit aplikace od konkrétních autentikačních mechanismů. V aplikacích se nemusejí implementovat jednotlivé metody autentikace, ale pouze se přidá knihovna pro obsluhu PAM modulů. Výhoda je také v tom, že není potřeba upravit a znovu kompilovat program, když se objeví nový způsob autentikace. PAM poskytuje služby ve čtyřech oblastech, pro různé fáze autentizačního procesu. Tyto oblasti jsou označovány jako management groups. • Auth - samotné ověření identity a přidělení oprávnění. • Account - ověření, zda uživatel již není přihlášen odjinud, kontrola možných omezení na účtu nebo heslu (např. platnost hesla může vypršet). • Session - vytvoření/zrušení patřičného prostředí (např. připojení šifrovaného domovského adresáře po přihlášení uživatele), logování. • Password - změny vlastního (uživatel) i cizího (administrátor) hesla nebo jiného mechanismu. Konfigurace bývá uložena v adresáři /etc/pam.d/ a to modulárně - ve více souborech, které lze do sebe vkládat. Soubory se musí jmenovat po službě, kterou nastavují. Jestli PAM název služby nezná (neexistuje soubor /etc/pam.d/sluzba), použije nastavení pro službu other. Syntaxe konfigurace PAM modulů obsahuje jednu z následujících hodnot: • Requisite - pokud modul selže, PAM ihned skončí a ohlásí volající službě selhání. • Required - pokud modul selže, PAM bude pokračovat následujícími předepsanými moduly, ale na konci vždy ohlásí volající službě selhání. Pokud selhalo více modulů označených jako required, bude v logu označen za viníka první z nich. • Sufficient - pokud neselhal tento modul, ani žádný předchozí modul označený jako required, PAM ihned skončí a ohlásí volající službě úspěch. • Optional - pokud byly prováděny pouze moduly označené jako optional a žádné jiné, určují úspěch/selhání tyto moduly. Pokud byl prováděn byť i jediný modul označený jinak, nebere se na jejich návratový stav zřetel. Příklad - /etc/pam.d/login auth required pam_unix.so auth optional pam_deny.so

52


8.5

PAM autentikace pomocí USB Flash

Nejdříve nainstalujeme příslušné balíčky příkazem: apt-get install pamusb-tools libpam-usb Následně vytvoříme USB zařízení pro ukládání informací: pamusb-conf –add-device my-usb A vytvoříme na něm účet pro uživatele student: pamusb-conf –add-user student Nyní můžeme vložit autentikační informace do souboru common-auth: nano /etc/pam.d/common-auth auth

8.6

sufficient

pam_usb.so

PAM autentikace pomocí otisku prstů

Nejdříve naistalujeme balíček pro podporu čtečky otisku prstů: apt-get install fprintd Potom vytvoříme vzory otisku prstu uživatele pomocí příkazu: fprintd-enroll -f right-index-finger student Systém požaduje 5x sejmutí otisku příslušného prstu pro vytvoření vzoru. Ověřit to můžeme příkazem: fprintd-verify -f right-index-finger student Pokud je vše funkční přejdeme na instalaci a konfiguraci PAM modulu: apt-get install libpam-fprintd Nyní můžeme vložit autentikační informace do souboru common-auth: nano /etc/pam.d/common-auth auth

sufficient

pam_fprintd.so


8.7

53

RADIUS

RADIUS (Remote Authentication Dial In User Service) je AAA protokol používaný pro přístup k síti nebo pro IP mobilitu. Mezi nejdůležitější vlastnosti patří jeho vysoká síťová bezpečnost, neboť transakce mezi klientem a RADIUS serverem je autentizována pomocí sdíleného tajemství, které není nikdy posíláno přes síť. Všechna uživatelská jména jsou přes síť zasílána šifrovaně. Uživatel vydá klientovi Požadavek na autentizaci, klient vytvoří Požadavek na přístup (Access Request) obsahující uživatelské jméno, heslo a ID portu, přes který je uživatel připojen. Požadavek na přístup je odeslán RADIUS serveru a čeká se na odpověď. Pokud nepřijde do určeného času, žádná odezva, Požadavek na přístup se opakuje, zpravidla 3 až 5 krát. Pokud není splněna některá z podmínek, RADIUS server odešle Zamítnutí přístupu (Access Reject). Do datové oblasti paketu je dovoleno umístit maximálně textovou zprávu, která smí být zobrazena pomocí klienta uživateli. Žádné další atributy nejsou v odpovědi Access Reject povoleny. Jestliže jsou všechny podmínky splněny, RADIUS server odešle Povolení přístupu (Access Accept), kde v datové oblasti paketu jsou uloženy všechny potřebné konfigurační informace, IP adresa, maska sítě, login uživatele a vše, co je potřeba předat požadované službě.

Obrázek 8.3: Využití protokolu RADIUS pro vzdálený přístup do sítě

8.8

Instalace a konfigurace programu FreeRadius

Instalaci Radius serveru provedeme příkazem: apt-get install freeradius

54


Po instalaci je potřeba nakonfigurovat dva soubory: nano /etc/freeradius/clients.conf kde nastavíme sdílené heslo mezi RADIUS serverem a klientem. client localhost {

secret = test}

Dále musíme vytvořit uživatele na serveru: nano/etc/freeradius/users

student Cleartext-Password := "student"

Nyní musíme službu RADIUS restartovat, nebo spustit v ladicím režimu příkazem: freeradius -X RADIUS lze otestovat příkazem: radtest student student localhost 1 test


9

9.1

55

JEDNOTNÝ AUTENTIZAČNÍ SYSTÉM KERBEROS Kerberos

Kerberos je síťový autentizační protokol umožňující komukoli komunikujícímu v nezabezpečené síti prokázat bezpečně svoji identitu někomu dalšímu. Kerberos zabraňuje odposlechnutí nebo zopakování takovéto komunikace a zaručuje integritu dat. Byl vytvořen primárně pro model klient-server a poskytuje vzájemnou autentizaci – klient i server si ověří identitu své protistrany. Základním pojmem je Principal, který představuje identitu uživatele, služby, nebo objektu v rámci domény. Tato doména se u Kerberosu nazývá REALM. Zapisuje se velkými písmeny,v podstatě odpovídá DNS doméně. Kerberos je postavený na symetrické kryptografii a potřebuje proto důvěryhodnou třetí stranu. Volitelně může využívat asymetrického šifrování v určitých částech autentizačního procesu. Standardně používá port 88.

Obrázek 9.1: Princip autentikace pomocí Kerberosu

Kerberos je založen na Needham-Schroeder Symmetric Key Protocol. Používá důvěryhodné třetí strany nazývané též Key Distribution Center (KDC) sestávající ze dvou logicky oddělených částí: Autentizačního serveru (AS) a Ticket-Granting Serveru (TGS). Kerberos pracuje na principu tiketů sloužících k ověření identity uživatelů, služeb, objektů.. KDC si udržuje databázi tajných klíčů; každá entita v sítí, ať už klient nebo server, vlastní svůj tajný klíč známý pouze jí a KDC. Znalost tohoto klíče slouží k prokázání identity dané entity. Pro komunikaci mezi entitami KDC vygeneruje „session key“, kterým obě protistrany zabezpečí vzájemnou komunikaci. Bezpečnost tohoto protokolu významně závisí na vzájemné synchronizaci času protistran a krátké životnosti tiketů.

56


Klient se jednorázově autentizuje AS pomocí navzájem známého tajemství (např. heslo) a dostane TGT. Později, když chce klient kontaktovat nějaké SS, použije se (i opakovaně) tohoto TGT k ověření u TGS a tím k získání tiketu pro komunikaci se SS bez toho, aby bylo znovu využíváno původního známého tajemství. Kerberos má přísné požadavky na synchronizaci času klientů a serverů. Tikety mají danou životnost a pokud není čas klienta synchronizován s časem serveru, autentizace selže. Standardní nastavení podle MIT požaduje, aby se tyto časy nerozcházely o více jak 5 minut. V praxi se používá NTP (Network Time Protocol) démonů k synchronizaci hodin.

9.2

Instalace a konfigurace Kerberos serveru

Nejdříve naistalujeme KDC server a Kadmin server příkazem: apt-get install krb5-{admin-server,kdc}

Kromě těchto dvou serverů se naistalují i příslušné knihovny. Pokud vše proběhne správně získáme na výstupu oznámení: Starting Kerberos KDC krb5kdc Starting Kerberos administrative servers kadmind

Po instalaci je nezbytné nakonfigurovat tři soubory: vim /etc/krb5.conf ... Kerberos client Configuration File [libdefaults] default_realm = EXAMPLE.CZ dns_lookup_realm = false dns_lookup_kdc = false [realms] EXAMPLE.CZ = { kdc = krb.example.cz:88 admin_server = krb.example.cz:749 default_domain = example.cz } [domain_realm] .example.cz = EXAMPLE.CZ example.cz = EXAMPLE.CZ [login] krb4_convert = true krb4_get_tickets = false [logging] kdc = FILE:/var/log/kerberos/krb5kdc.log admin_server = FILE:/var/log/kerberos/kadmind.log


vim /etc/krb5kdc/kdc.conf ... [kdcdefaults] kdc_ports = 88

57

Kerberos Key Distribution Center - Configuration File

[realms] EXAMPLE.CZ = { database_name = /var/lib/krb5kdc/principal admin_keytab = FILE:/etc/krb5kdc/kadm5.keytab acl_file = /etc/krb5kdc/kadm5.acl key_stash_file = /etc/krb5kdc/stash kdc_ports = 750,88 max_life = 10h 0m 0s max_renewable_life = 7d 0h 0m 0s master_key_type = des3-hmac-sha1 supported_enctypes = aes256-cts:normal arcfour-hmac:normal des3-hmac-sha1:normal d default_principal_flags = +preauth kdc_ports = 88 kadmin_port = 749 } vim /etc/krb5kdc/kadm.acl */[email protected] *

... Access Control List configuration File

Nyní můžeme vytvořit databázi Kerberos serveru: kdb5_util create -s Loading random data Initializing database ’/var/lib/krb5kdc/principal’ for realm ’EXAMPLE.CZ’, master key name ’K/[email protected]’ You will be prompted for the database Master Password. It is important that you NOT FORGET this password. Enter KDC database master key: Re-enter KDC database master key to verify:

Vytvoříme principal krbadmin/[email protected], který bude sloužit pro administraci databáze. kadmin.local -q "addprinc krbadmin/admin" Authenticating as principal root/[email protected] with password. WARNING: no policy specified for krbadmin/[email protected]; defaulting to no policy Enter password for principal "krbadmin/[email protected]": Re-enter password for principal "krbadmin/[email protected]": Principal "krbadmin/[email protected]" created.

Nakonec restartujeme oba servery příkazem: /etc/init.d/krb5-admin-server restart /etc/init.d/krb5-kdc restart

58


Je velmi vhodné mít v jiném terminálu spuštěné automatické výpisy serverů: tail -f /var/log/kerberos/{krb5kdc,kadmin}.log

Nyní můžeme přistoupit ke kontrole databáze a vytvoření principalu uživatele: kadmin -p krbadmin/admin Authenticating as principal krbadmin/admin with password. Password for krbadmin/[email protected]: kadmin: list_principals K/[email protected] kadmin/[email protected] kadmin/[email protected] kadmin/[email protected] krbadmin/[email protected] krbtgt/[email protected] kadmin: addprinc student WARNING: no policy specified for [email protected]; defaulting to no policy Enter password for principal "[email protected]": Re-enter password for principal "[email protected]": Principal "[email protected]" created.

A nakonec zkotrolujeme, zda získáme tiket pro uživatele student: kinit student Password for [email protected]: klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: [email protected] Valid starting Expires 22.09.2014 20:10:47 23.09.2014 06:10:47 renew until 23.09.2014 20:10:43

Service principal krbtgt/[email protected]


10

59

AUTENTIZACE NA BÁZI JEDNOTNÉHO PŘIHLÁŠENÍ

Systém jednotného přihlášení SSO (Single Sign On) umožňuje pohodlný přístup k informačním a komunikačním službám pomocí jednotných přihlašovacích údajů. Uživatelé využívají jednu identitu pro přístup k různým službám bez nutnosti opětovného požadavku na novou autentikaci. Uživatelé si potom pamatují menší počet různých účtů a hesel.

10.1

SSO Single Sign On

Systém SSO (Single Sign On) umožňuje jednotné přihlašování na více webů. Nějaký portál autentizuje uživatele. Uživatel se připojí k jinému portálu a ten si vyžádá informace z předcházejícího portálu. Pokud dostane správné a ověřené informace, dojde k již zmíněnému prosazení důvěry i na tento portál a uživatel bude i zde automaticky autentizován. Systém jednotného přihlášení na VŠB-TUO je založen na systému CAS (Central Authentication Service). SSO umožňuje uživateli po přihlášení do jedné aplikace automaticky přístup do všech aplikací, které jsou součástí SSO. Chce-li aplikace využít SSO, musí implementovat definovaný protokol. Pro mnoho systémů jsou připraveni tzv. klienti, kteří zařídí potřebnou komunikaci mezi uživatelem a SSO serverem. SSO pak Aplikaci poskytne informaci o přihlášeném uživateli.

Obrázek 10.1: Princip systému jednotného přihlášení

60


10.2

Standard SAML

SAML (Security Assertion Markup Language) je standard založený na značkovacím jazyku XML (Extensible Markup Language), poskytující mechanismus pro výměnu autentizačních a autorizačních dat mezi zúčastněnými stranami, tj. poskytovatelem služeb SP (Service Provider) a poskytovatelem identity IdP (Identity Provider). Je vyvíjen organizací OASIS (Organization for the Advancement of Structured Information Standards). Funguje na principu „prosazení“ důvěry, tedy aplikace může prosadit, že jde o určitého uživatele a ten má určitá privilegia. V praxi řeší SAML problém jednotného přihlašování na více webů - SSO (Single SignOn). Nějaký portál autentizuje uživatele, který se připojí k jinému portálu a ten si vyžádá informace z předcházejícího portálu. Pokud dostane správné a ověřené informace, dojde k již zmíněnému prosazení důvěry i na tento portál a uživatel bude i zde automaticky autentizován. Je tedy vhodné rozdělení na poskytovatele identity a poskytovatele služeb. Pokud chce uživatel přistupovat ke zdrojům poskytovatele služeb, pak jeho identitu zkontroluje jeho poskytovatel identity a ten posílá informace poskytovateli služeb, u kterého uživatel žádá o poskytnutí služby. Tímto se odpovědnost za ověření identity přesunuje vždy na poskytovatele identity. Tato koncepce vede k ustanovení tzv. federací, které si mohou navzájem vyměňovat informace o autentizaci subjektu. SAML poskytuje pouze distribuci samotné informace mezi zúčastněnými stranami, a proto nezáleží na jejím počtu. Standard nespecifikuje konkrétní implementaci samotného ověřování identity u poskytovatele identit.

10.3

Využití standardu v praxi

Standard SAML lze využít v praxi zejména pro autentizační a autorizační mechanismy. Nejčastěji se SAML využívá jako Web Browser SSO. Uživatel se přihlásí na serveru A a je zde autentizován. Později se chce přihlásit na server B. Bez užití SSO by musel své údaje zadávat znovu. Pokud je užit SAML, pak B pošle požadavek na A s dotazem, zda se již uživatel na A autentizoval. A odpoví prohlášením, že uživatel je autentizován. Poté B zpřístupňuje své zdroje, aniž by vyžadoval znovu přihlašovací údaje. Nejčastější řešení SSO je pomocí tzv. poskytovatele identity a poskytovatele služeb. Na obrázku 10.2 je zobrazen průběh výměny zpráv mezi uživatelem, poskytovatelem služby a poskytovatelem identity. Postup výměny zpráv je následující. 1. Uživatel požaduje určitou službu u poskytovatele služeb prostřednictvím svého prohlížeče. 2. Poskytovatel služby určí uživatelova preferovaného poskytovatele identity a přesměruje jeho prohlížeč na SSO poskytovatele identity. 3. Uživatel požaduje SSO službu u poskytovatele identity.


61

Obrázek 10.2: Výměna zpráv pro Web Browser SSO

4. Od poskytovatele identity přichází formulář pro uživatelské přihlášení. 5. Uživatel požaduje určité služby na základě tvrzení od poskytovatele služeb (Assertion Consumer Service). 6. Poskytovatel služby přesměruje uživatele na požadované stránky. 7. Poskytovatel služby poskytne příslušné požadované informace. Základem zprávy je SAML tvrzení, na jehož základě je prosazena důvěra na jiném serveru. V podstatě se jedná o XML dokument, který obsahuje bezpečnostní informace, které učinila tzv. identifikační autorita. Tvrzení SAMLu neprovádějí autentizaci, ale slouží pouze k obalení, zapouzdření tohoto procesu autentizace.

10.4

Open-source implementace SAML pomocí SimpleSAMLphp

Existuje mnoho open-source projektů, které využívají standard SAML. V části se zaměříme pouze na simpleSAMLphp.

62


Aplikace SimpleSAMLphp je napsaná v jazyce PHP určená k řešení autentizace pomocí technologie SAML. Může fungovat jako Service Provider, nebo i Identity Provider. SimpleSAMLphp podporuje několik protokolů, založených na SAML verze 2.0. Webová aplikace simpleSAMLphp je schopná v plném rozsahu posloužit pro ochranu obsahu na straně Poskytovatele služeb. Na začátku každé chráněné stránky by měl být kód, který během načítání stránky zjistí, zda je uživatel přihlášen. Pokud uživatel není přihlášen, je přeměrován na přihlašovací stránku Poskytovatele služeb (simpleSAMLphp SP). Ten ho přesměruje na poskytovatele identity, kde se uživatel přihlásí. Uživatel je následně přesměrován zpět k Poskytovateli služeb. SimpleSAMLphp pak na konci svého běhu předá původnímu skriptu informace o uživateli, jenž se pokouší načíst stránku.O zobrazení či nezobrazení stránky ale samozřejmě musí rozhodnout skript obsluhující načítání stránky a to na základě údajů předaných od simpleSAMLphp. S jedním SP je možné přihlásit se k více IdP, slouží k tomu aplikace SAML 2.0 Discovery Service. Součástí aplikace simpleSAMLphp je i poskytovatel identity. Poskytovatel má široké možnosti autentizace proti velkému množství databází. Nejjednodušší variantou je ověřování proti textovému souboru, ve kterém jsou uloženy jména, hesla a podrobnosti jednotlivých uživatelů. Tato varianta najde své realné využití snad jen při testovacím provozu. K ostrému provozu se hodí spíš ověřování proti LDAP, MySQL, MSSQL, popřípadě proti doméně nebo přeposílání požadavků na další IdP. Velkou výhodou je, že simpleSAMLphp již obsahuje všechny moduly pro výše zmíněné způsoby ověřování, takže není třeba psát či shánět nové moduly. V případě, že je pro jeden IdP k dispozici více zdrojů ověřování, rozhodne se buď automaticky základě struktury uživatelského jméno případně se uživateli zobrazí nabídka se seznam možných autentizačních zdrojů.

10.5

Instalace a konfigurace simpleSAMLphp

Nejdříve se přepneme do adresáře var a stáhneme aktuální verzi: cd /var wget https://simplesamlphp.org/res/downloads/simplesamlphp-1.13.2.tar.gz

Nyní upravíme cestu v již naistalovaném webovém serveru: vim /etc/apache2/sites-available/default DocumentRoot /var/simplesamlphp/www

Následně spustíme prohlížeč a vložíme jméno WWW serveru, kde běží simpleSAMLphp aplikace. Na obrázku 10.3 je vidět přihlášení na web a instalační stránka simpleSAMLphp.


63

Obrázek 10.3: Ukázka přihlášení simpleSAMLphp

10.6

Instalace a kofigurace simpleSAMLphp Identity Provider

Upravíme soubor, který povoluje SAML a Shibboleth:

vim config/config.php ’enable.saml20-idp’ => true, ’enable.shib13-idp’ => true,

A následně povolíme moduly:

touch modules/exampleauth/enable

Vytvoříme certifikát pro server a umístíme ho do adresáře pro certifikáty:

openssl req -newkey -new -x509 -days 365 -nodes -out localhost.crt -keyout localhost.pem mkdir cert; mv localhost.* cert/

64


Obrázek 10.4: Ukázka výpisu metadat simpleSAMLphp Identity Provider

10.7

Instalace a kofigurace simpleSAMLphp Service Provider

Musíme minimálně vytvořit příslušnou entitu v config/authsources.php: vim config/authsources.php ’entityID’ => ’http://localhost/’, ’example-userpass’ => array( ’exampleauth:UserPass’, ’student:studentpass’ => array( ’uid’ => array(’student’), ’eduPersonAffiliation’ => array(’member’, ’student’), ), ’employee:employeepass’ => array( ’uid’ => array(’employee’), ’eduPersonAffiliation’ => array(’member’, ’employee’), ), ), );


Obrázek 10.5: Ukázka výpisu metadat simpleSAMLphp Service Provider

65

66



11

67

POKROČILÁ AUTENTIZACE NA BÁZI FEDERATED SINGLE SIGN ON

Federated Single Sign On je pokročilá autentizace, určená pro kooperativní prostředí. Instituce mohou využívat jednotný autentizační systém, typicky univerzitní prostředí, knohovny apod. Tyto instituce se sdružují a sdílejí prostředky i politiky přístupu k nim. Takováto skupina institucí je označována jako federace.

11.1

Shibboleth

Shibboleth vychází z předpokladu, že každý uživatel má určitou domácí instituci, a ta provozuje autentizační služby, například v podobě LDAP serveru. Cílem je, aby uživatel byl autentizován u svého domácího systému, přestože projevil zájem o stránky umístěné někde jinde. Prostředky provádějící vlastní ověření uživatele a poskytující informace o něm jsou zde označovány termínem poskytovatel identity (Identity Provider, IdP). Druhým významným účastníkem komunikace je poskytovatel služeb (Service Provider, SP). Tento pojem označuje WWW server, o jehož chráněné stránky uživatel projevil zájem. Shibboleth definuje postupy a poskytuje softwarové nástroje, jak ověřit uživatelovo přístupové právo pro cílové stránky. Zároveň řeší i otázku soukromí. Ve většině případů totiž poskytovatel služeb nepotřebuje znát konkrétní identitu přicházejícího uživatele. Mnohdy stačí daleko obecnější informace typu „ano, to je náš uživatel“ či „studuje u nás mineralogii“. Proto Shibboleth omezuje sortiment informací podávaných poskytovatelům služeb a dokonce umožňuje uživatelům, aby si individuálně nastavili, co o nich smí prozradit. Identifikace uživatele může probíhat na základě e-mailu, SMS, nebo poštovní adresou. Technologickým základem Shibboletu je SAML. Vzhledem k tomu, že Shibboleth řeší jen autentizaci WWW služeb, využívá z něj pouze vybranou podmnožinu, konkrétně profily Browser/POST a Browser/Artifact určené pro tento účel.

11.2

Princip činnosti Shibbolethu

Základní myšlenkou je, že při prvním pokusu o přístup ke chráněným stránkám je uživatel automaticky přesměrován na svého poskytovatele identity. Zde prokáže svou totožnost a vrátí se zpět na původní server. Detaily se poněkud liší v závislosti na profilu. Pro Browser/POST vypadá komunikace následovně. Transakce začíná požadavkem na určité stránky (cílový zdroj). Pokud poskytovatel služeb uživatele dosud nezná, bude odpovědí WWW serveru přesměrování vedoucí na poskytovatele identity. Lokátor tohoto přesměrování v sobě obsahuje informace o posky-

68


Obrázek 11.1: Princip výměny zpráv pro identitu uživatele.

tovateli služeb, požadované stránce i adresu, kam se má uživatel vrátit s odpovědí. Uživatelův klient se proto obrátí na svého domácího poskytovatele identity, který ověří jeho totožnost. Pokud se na něj již daný klient nedávno obracel (po přesměrování z jiného serveru), pravděpodobně už tu má vytvořen bezpečnostní kontext, který bude využit i tentokrát. Odtud přístup Single Sign-On: jednou se prokážete a následně se tato informace automaticky využije, aniž byste museli opakovat své uživatelské jméno a heslo. Výsledkem činnosti poskytovatele identity je WWW stránka s formulářem, který ve skrytých položkách obsahuje informace pro poskytovatele služeb – identifikaci zdroje a SAML odpověď s výsledkem autentizace. Cílová adresa, jež má zajistit zpracování formuláře, se nachází opět u poskytovatele služeb. Konkrétně se jedná o jeho službu vyhodnocující autentizační informace (Assertion Consumer Service). Doporučuje se, aby odeslání formuláře zajistil automaticky JavaScript ihned po načtení stránky a uživatel měl život co nejpohodlnější. Když poskytovatel služeb z dat uvedených ve formuláři vidí, že autentizace dopadla úspěšně, vytvoří bezpečnostní kontext (identifikovaný prostřednictvím cookie) a přesměruje uživatele na původně požadovaný zdroj. Klient proto v kroku zopakuje svůj původní požadavek, tentokrát však již opatřený cookie odkazujícím se na bezpečnostní kontext. Proto mu bude požadovaná stránka poskytnuta. Bude-li požadovat další stránky stejné aplikace, má už k dispozici cookie, a


69

dostane je proto rovnou. Celá operace tedy proběhne jen jednou, když poprvé vstupuje do určitého chráněného prostoru. Poskytovatel služeb nemusí vědět, odkud uživatel pochází, a na kterého poskytovatele identit se tudíž obrátit. Proto vstupuje do hry další prvek nazvaný WAYF (Where Are You From). Ve druhém kroku uživatel není odkázán na konkrétního poskytovatele identity, ale na obecnou službu WAYF. Ta zjistí, kam uživatel patří (typické řešení: předloží mu formulář s nabídkou spolupracujících institucí a uživatel si sám vybere, informace se do budoucna opět uloží do cookie, aby se dotaz neopakoval), a přesměruje jej na patřičného poskytovatele identity. Díky tomu není nutné, aby všichni poskytovatelé služeb znali všechny poskytovatele identit. Stačí, když se všichni budou odkazovat na společnou WAYF službu. Shibboleth verze 1 používá službu WAYF (Where Are You From) a Shibboleth verze 2 používá službu DS (Discovery Service). Služba WAYF přesměruje uživatelův prohlížeč na vybraného poskytovatele identity. Služba DS využívá posytovatele identity definovaného poskytovatelem služby. Na následujícím obrázku je vidět rozdíl mezi jednotlivými službami.

Obrázek 11.2: Rozdíl výměny informací mezi jednotlivými verzemi aplikace Shibboleth.

Uživatelské atributy jsou uloženy v databázi poskytovalete identity a předávají poskytovateli služeb jen informace, které si může sám uživatel nastavit. Mezi tyto atributy patří uživatelský email, telefonní číslo, skupinu do které je zařazen, informace o roli uživatele u organizace, a specifické privilegia. Shibboleth verze 3 je připravovaná nová verze, která umožní autentizaci aplikací nevyužívající prohlížeč. Nová verze umožní jednodušší nastavení a konfigurace uživatelského autentizačního procesu, snadnější přizpůsobení alternativám bez ztráty bezpečnostních mechanismů.

70


Česká akademická federace identit eduID je federace postavená na projektu Shibboleth a je jejím oprátorem je Cesnet. Tato služba je využívána zejména v akademickém prostředí univerzit. Bližšší informace jsou na stránkách https://www.eduid.cz/.

Obrázek 11.3: Náhled na přihlášení pomocí eduID.

Sdružení CZ.NIC provozuje mojeID, které je také možno využít jako jednotné heslo pro přístup na chráněné stránky. Tato služba může být využívána jak ve firemním prostředí, tak i pro osobní účely. Bližší informace o poskytovaných službách je na stránkách https://www.mojeid.cz/.

Obrázek 11.4: Výběr a potvrzení údajů, které budou předávány při ověřování.


12

71

NÁSTROJE PRO SPRÁVU ŘEŠENÍ PROBLÉMŮ

Mezi nástroje pro správu řešení problémů patří tzv. RT (Request Tracker), někdy se také nazývá helpdesk, nebo idesk, apod. RT je tiketovací systém napsaný v perlu, který je určen pro koordinaci úkolů. RT problémy neřeší, ale pomáhá je řešit, snadno se v nich orientovat a umožňuje i zpětnou kontrolu. Tento systém lze také použít pro zpracování různých úkolů. RT běží na webovém serveru, a data ukládá do SQL databáze. Pro bezpečnou komunikaci umožňuje používat SSL vrstvu. Pro autentizaci může používat LDAP.

Obrázek 12.1: Náhled do systému pro řešení prolémů

72

12.1


Princip RT

Nejdříve uživatel posílá požadavek na RT systém prostřednictvím emailu, webovým formulářem, SMS zprávou, telefonicky, apod. U problému se vyplní předmět požadavku, popíše se daný problém, případně se přiloží soubor se screenshotem. RT server uloží požadavek do databáze a vytvoří tzv. tiket, kterému přiřadí pořadové číslo. Toto číslo požadavku oznámí zpět uživateli.

Obrázek 12.2: Náhled na vytvoření nového tiketu.

RT systém zároveň posílá požadavek na vyřešení problému na správce, což může být technik, sekretářka, administrátor, apod.


73

Následně příslušný správce problém buď vyřeší, nebo ho může přeposlat někomu dalšímu. Pokud s problém vyřeší pošle se zpráva do RT systému a zároveň je informován uživatel o vyřešení problému. Uživatel může sledovat stav řešení svého požadavku, případně vyřešení reklamovat a požádat o znovuvyřešení. RT umožňuje graficky zobrazit např. stavy jednotlivých tiketů.

Obrázek 12.3: Náhled na grafické zobrazení všech řešených tiketů.

12.2

RTIR RT for Incident Response

RTIR (RT for Incident Response) je otevřený systém pro správu bezpečnostních incidentů. Tento systém vychází ze systému RT a rozděluje požadavky do následujících bloků: 1. Hlášení incidentů - přicházejí z emailů, nebo jsou vkládány ručně. 2. Incidenty - zde se zjišťuje, zda je incident již evidován, v případě nového incidentu je vytvořen. 3. Vyšetřování - informování a požadavek na řešení incidentu třetí stranou, do jejíž kompetence řešení spadá. 4. Blokace - v závažných případech mohou být blokovány části sítí, požadavky na dohledové síťové centrum.

74


Obrázek 12.4: Náhled na systém pro správu bezpečnostních incidentů RTIR


13

75

NÁSTROJE PRO IM KOMUNIKACI

IM (Instant Messaging) je nástroj pro okamžitou výměnu zpráv. Umožňuje nastavit stav uživatele, neruší činnost uživatele. Zrychluje komunikaci, umožňuje výměnu souborů, sdílení obsahu, a audio/video komunikaci.

13.1

Unixový chatovací nástroj talk

Nejjednodušším unixovým nástrojem je program talk, který zajistí textovou výměnu zpráv mezi uživateli. Na počítači musí být spuštěn démon talkd. Pokud si chceme vyměňovat informace, tak se musíme připojit na počítač jiného uživatele příkazem: talk user@ip_adresa

Obrázek 13.1: Náhled na spuštěný program talk

V případě, že jsou uživatelé na jednom počítači, serveru, mohou komunikovat přímo pomocí programu talk. Stačí zadat příkaz: who, talk user tty

76

13.2


IRC Internet Relay Chat

IRC (Internet Relay Chat) je jeden z prvních protokolů pro komunikaci v reálném čase přes síťové rozhraní. Pracuje na principu klient-server. Je nutné mít v sítí spuštěný IRC server a uživatelé se připojují na tento server a komunikují jeho prostřednictvím.

Obrázek 13.2: Náhled na spuštěnou IRC textovou komunikaci

IRC se většinou používá pro komunikaci různých zájmových a odborných skupin. Velmi často se využívá pro řešení odborných unixových problémů, také je využíván pro komunikaci síťových hráčů.


13.3

77

XMPP Extensible Messaging and Presence Protocol

XMPP (Extensible Messaging and Presence Protocol), dříve známý jako Jabber, je rozšiřitelný protokol pro posílání zpráv a zjištění stavu. Může být také používán pro vzájemnou komunikaci programů, nebo ovládání různých automatických služeb. Síť využívající XMPP protokol není centralizovaná do jednoho místa, ale je distribuovaná na servery po celém světě, na kterých je možno založit uživatelský účet. Nebo může být využíván pouze v rámci jedné instituce pro vzájemnou komunikaci. Základ XMPP je specifikován v doporučení RFC 3920 a RFC 3921, ale řada vlastností je popsána v dalších RFC. Díky tomu, že se jedná o otevřený standard, může kdokoliv vytvářet aplikace, které využívají XMPP. Výhodou XMPP je jeho univerzálnost a otevřenost. Můžeme jej jednoduše používat pro soukromé účely jako jiné IM systémy. Ale také můžeme XMPP nasadit ve firemním prostředí a vybudovat tak komunikační infrastrukturu, která může být uzavřená nebo připojená do veřejné sítě a komunikovat s ostatními účty v XMPP. XMPP pracuje na principu klient-server, a síť je decentralizovaná, podobně jako u e-mailu. Uživatel si může zřídit účet u již běžícího serveru, nebo si zřídit vlastní server. Uživatel je identifikován uživatelským jménem a názvem serveru. Tyto dvě hodnotu jsou odděleny @. Například, [email protected]. Tento řetězec se nazývá JID, neboli Jabber ID.

Obrázek 13.3: Princip výměny zpráv

XMPP komunikace probíhá následujícím způsobem: 1. 2. 3. 4. 5.

Klient se přihlásí k serveru, kde se ověří jeho totožnost. Pokud pošlu zprávu, tak ji můj klient zašle na můj server a ten provede směrování. Spojí se s cílovým serverem (pokud není cílový on sám), dle adresy serveru v JID. Server odešle zprávu na cílový server. Cílový server předá zprávu klientovi (ve chvíli, kdy bude přihlášen).

78

13.4


Komunikace pomocí aplikace Facebook

Facebook je rozsáhlý společenský webový systém, sloužící hlavně k tvorbě sociálních sítí, komunikaci mezi uživateli, sdílení multimediálních dat, udržování vztahů a zábavě. Jádro aplikace Facebook je založeno na LAMP (Linux, Apache, MySQL, PHP) aplikacích. Systém využívá AJAX, Java a Flash programy. V současné době je aplikace Facebook více rozšířena pro zábavu a šíření informací, než pro firemní komunikaci. Firmy využívají Facebook pro propagaci a možnosti komunikace s externími uživateli.

Obrázek 13.4: Náhled do aplikace Facebook


13.5

79

Komunikace pomocí aplikace Twitter

Komunikace založená na Twitteru je založena na technologii Web 2.0 Instant Messaging. V podstatě to je Web-based IRC klient. Tweet je textový příspěvek o délce 140 znaků. Twitter web interface využívá Ruby on Rails framework, který je určený pro vývoj webových aplikací napojených na databázi.

Obrázek 13.5: Náhled do aplikace Twitter

80


Reference [1] Kolektiv autorů Linux Dokumentační projekt. Computer Press 2007. ISBN: 978-80251-1525-1 [2] Toxen, B. Bezpečnost v linuxu Prevence a odvracení napadení systému Computer Press 2003. ISBN 80-7226-716-7 [3] Ruest, D., Ruest, N. Virtualizace: Podrobný průvodce. Brno, ComputerPress 2010. ISBN-13 978-80-251-2676-9 [4] Preston, W.C. Backup and RecoveryInexpensive Backup Solutions for Open Systems. O’Reilly Media 2007. ISBN 978-0-596-10246-3 [5] Chirillo, J., Blaul, S. Storage Security: Protecting SANs, NAS and DAS. Wiley 2003 ISBN: 978-0-7645-1688-7 [6] Hagen, S. IPv6 Essential. O’Reilly 2014. ISBN 978-1449319212 [7] Chuvakin, A., Schmidt, K., Phillips, Ch. Logging and Log Management: The Authoritative Guide to Understanding the Concepts Surrounding Logging and Log Management. Syngress 2012 ISBN-13: 978-1597496353 [8] Mauro, D., Kevin Schmidt, K. Essential SNMP. O’Reilly Media 2005. ISBN-13: 9780596008406 [9] Lucas, M. W. Network Flow Analysis. No Starch Press 2010. ISBN-13: 978-1593272036 [10] Ligus, S. Effective Monitoring and Alerting: For Web Operations. O’Reilly Media 2012. ISBN-13: 978-1449333522 [11] Howes, T.H., Smith, M.C. Understanding and Deploying LDAP Directory Services. Addison-Wesley Professional 2003. ISBN-13: 978-0672323164 [12] Hassell, J. Radius O’Reilly Media 2002. ISBN-13: 978-0596003227 [13] Garman, J. Kerberos: The Definitive Guide. O’Reilly Media 2003. ISBN-13: 9780596004033 [14] Smith, R.E. Authentication: From Passwords to Public Keys. Addison-Wesley Professional 2001. ISBN-13: 978-0201615999 [15] RT Request Tracker [online 24.3.2013] http://requesttracker.wikia.com/wiki/ HomePage

Komunikační sítě II pro integrovanou výuku VUT a VŠB-TUO

Recommend Documents