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

Transkript

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: <info>
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
snmpget -v 3 -u user3 -l authPriv -a MD5 -A user3password -x DES -X user3encryption localh
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ě:
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE rrd SYSTEM "http://oss.oetiker.ch/rrdtool/rrdtool.dtd">
<!– Round Robin Database Dump –><rrd><version> 0003 </version>
<step> 3 </step> <!– Seconds –>
<lastupdate> 1383765043 </lastupdate> <!– 2013-11-06 20:10:43 CET –>
<ds>
<name> memory </name>
<type> GAUGE </type>
<minimal_heartbeat> 10 </minimal_heartbeat>
<min> 0.0000000000e+00 </min>
<max> NaN </max>
</ds>
<!– Round Robin Archives –><rra>
<cf> MAX </cf>
<pdp_per_row> 1 </pdp_per_row> <!– 3 seconds –>
<params>
<xff> 5.0000000000e-01 </xff>
</params>
<cdp_prep>
<ds>
<primary_value> 1.4253661808e+06 </primary_value>
<secondary_value> 1.4253661808e+06 </secondary_value>
<value> NaN </value>
<unknown_datapoints> 0 </unknown_datapoints>
</ds>
</cdp_prep>
<database>
<!– 2013-11-06 20:08:18 CET / 1383764898 –> <row><v> 1.1274096799e+06 </v></row>
<!– 2013-11-06 20:08:21 CET / 1383764901 –> <row><v> 1.3528471469e+06 </v></row>
</database>
</rra>
</rrd>
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]
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

Transkript

Podobné dokumenty

Poznámky k vydání

KOMUNIKACE

Nekonvenční zdroje elektrické energie

Sborník příspěvků

zde - Plavanimb.cz

openMagazin 7/2009

Sborník příspěvků

Mikrotik RouterOS: Vizualizace datových toků

RouterOS - Vizualizace datových toků

Zde - Europen

Fedora 12 Constantine

World wide web aplikace World Wide Web Applications

Federativní autentizační metody

nové číslo Informačního zpravodaje

Napište nám! OBSAH

Instalace systému Docházka 3000 na operační systém Linux s

bakalářská práce - Unicorn College

Vivotek IP7131