Řešení virtuální privátní sítě v podnikovém informačním systému

Mendelova zemědělská a lesnická univerzita v Brně Provozně ekonomická fakulta

Řešení virtuální privátní sítě v podnikovém informačním systému Diplomová práce

Vedoucí práce: Ing. Ludmila Kunderová

Bc. Lubomír Vichta

Brno 2008

2 Na tomto místě bude strana se zadáním.

Rád bych tímto poděkoval vedoucí mé diplomové práce Ing. Ludmile Kunderové, za její cenné rady a připomínky při tvorbě práce a zapůjčení materiálů, odkud jsem čerpal potřebné informace. Dále bych rád poděkoval Ing. Petrovi Tomanovi za jeho praktické rady a připomínky technického charakteru.

Prohlašuji, že jsem tuto diplomovou práci vyřešil samostatně s použitím literatury, kterou uvádím v seznamu. Tato diplomová práce vznikla v rámci rešení výzkumného záměru VZ MSM 6215648904/03/03/06.

V Brně 26. května 2008

....................................................

5

Abstract Vichta, L. Developing a virtual private network withing a corporate information system. Diploma thesis. Brno, 2008. This diploma work deals with the implementation of an virtual private network within a specific company, taking into account company requirements. Before final implementation, several approaches are tested. The results serve as a base in the development of the final solution.

Abstrakt Vichta, L. Řešení virtuální privátní sítě v podnikovém informačním systému. Diplomová práce. Brno, 2008. Diplomová práce se zabývá implementací virtuální privátní sítě v konkrétní organizaci. Před samotnou realizací je testováno několik variant a získané výsledky slouží, s ohledem na požadavky podniku, jako podklad pro volbu konkrétního řešení.

6

OBSAH

Obsah 1 Úvod a cíl práce 1.1 Úvod do problematiky . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Cíl práce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9 9 9

2 Přehled literatury

10

3 Metodika

11

4 Bezpečnost sítí 4.1 Způsoby zabezpečení . . . . . . . . 4.2 Systémy na detekci útoku (průniku) 4.3 Vzdálený přístup, VPN, Certifikáty 4.4 Antivirová ochrana . . . . . . . . . 4.5 Firewall . . . . . . . . . . . . . . .

. . . . .

12 12 12 13 13 13

. . . . . . .

15 15 15 16 16 16 17 17

. . . . . . . . . . .

18 18 19 19 19 20 21 21 21 22 22 24

5 Řízení přístupu 5.1 Autentizace . . . . . . . . . . . . . 5.2 Autorizace a účtování . . . . . . . . 5.3 Systémy řízení přístupu . . . . . . . 5.3.1 TACACS . . . . . . . . . . 5.3.2 RADIUS . . . . . . . . . . . 5.3.3 Diameter . . . . . . . . . . 5.3.4 Porovnání systémů přístupu

. . . . .

. . . . . . .

. . . . .

. . . . . . .

. . . . .

. . . . . . .

. . . . .

. . . . . . .

. . . . .

. . . . . . .

. . . . .

. . . . . . .

. . . . .

. . . . . . .

6 Šifrování 6.1 Symetrické šifrování . . . . . . . . . . . . . . . . 6.1.1 DES . . . . . . . . . . . . . . . . . . . . 6.1.2 AES . . . . . . . . . . . . . . . . . . . . 6.1.3 Kerberos . . . . . . . . . . . . . . . . . . 6.2 Asymetrické šifrování . . . . . . . . . . . . . . . 6.2.1 Diffie-Hellman . . . . . . . . . . . . . . . 6.2.2 RSA . . . . . . . . . . . . . . . . . . . . 6.2.3 Otisky zprávy . . . . . . . . . . . . . . . 6.2.4 Digitální podpis . . . . . . . . . . . . . . 6.2.5 Digitální certifikát a certifikační autorita 6.3 Hybridní šifrování . . . . . . . . . . . . . . . . .

. . . . .

. . . . . . .

. . . . . . . . . . .

. . . . .

. . . . . . .

. . . . . . . . . . .

. . . . .

. . . . . . .

. . . . . . . . . . .

. . . . .

. . . . . . .

. . . . . . . . . . .

. . . . .

. . . . . . .

. . . . . . . . . . .

. . . . .

. . . . . . .

. . . . . . . . . . .

. . . . .

. . . . . . .

. . . . . . . . . . .

. . . . .

. . . . . . .

. . . . . . . . . . .

. . . . .

. . . . . . .

. . . . . . . . . . .

. . . . .

. . . . . . .

. . . . . . . . . . .

. . . . .

. . . . . . .

. . . . . . . . . . .

7 Virtuální privátní sítě (VPN) 25 7.1 Vymezení a definice VPN . . . . . . . . . . . . . . . . . . . . . . . . 25 7.2 Základní prvky VPN . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

7

OBSAH

7.3 7.4 7.5 7.6

Adresace ve VPN . . . . . . . . . . . . . . . . . . Rozdělení VPN . . . . . . . . . . . . . . . . . . . Tunel, tunelování . . . . . . . . . . . . . . . . . . Technologie VPN . . . . . . . . . . . . . . . . . . 7.6.1 GRE . . . . . . . . . . . . . . . . . . . . . 7.6.2 PPTP (Point-to-Point Tunneling Protocol) 7.6.3 L2TP (L2TP/IPSec) . . . . . . . . . . . . 7.6.4 IPSec . . . . . . . . . . . . . . . . . . . . 7.6.5 MPLS . . . . . . . . . . . . . . . . . . . . 7.6.6 SSL/TLS . . . . . . . . . . . . . . . . . . 7.6.7 Porovnání technologie . . . . . . . . . . .

8 Vlastní práce 8.1 Výchozí stav . . . . . . . . . . . . . . . 8.1.1 Charakteristika společnosti . . . 8.1.2 Vybavenost výpočetní technikou 8.1.3 Požadavky na řešení a motivace 8.2 Testované VPN řešení . . . . . . . . . 8.2.1 Testovací prostředí . . . . . . . 8.2.2 Poptop – PPTP . . . . . . . . . 8.2.3 OpenVPN . . . . . . . . . . . . 8.2.4 TINC . . . . . . . . . . . . . . 8.2.5 L2TP/IPSec . . . . . . . . . . . 8.3 Porovnání, hodnocení variant . . . . . 8.3.1 Kompatibilita . . . . . . . . . . 8.3.2 Škálovatelnost . . . . . . . . . . 8.3.3 Bezpečnost . . . . . . . . . . . 8.3.4 Výkon . . . . . . . . . . . . . . 8.3.5 Použitelnost . . . . . . . . . . . 8.4 Výběr řešení . . . . . . . . . . . . . . . 8.5 Realizace VPN ve společnosti . . . . . 8.6 Hodnocení implementace . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . . . . . . . . . .

. . . . . . . . . . .

26 26 28 29 30 30 31 32 34 36 36

. . . . . . . . . . . . . . . . . . .

38 38 38 38 40 41 42 43 46 53 55 59 59 60 60 61 64 64 65 68

9 Závěr

70

10 Literatura

71

Přílohy

73

A Statistiky měření – odezva

74

B Statistiky měření – propustnost

78

OBSAH

8

C Aplikační balíček

83

D Webová aplikace – doprava certifikátů

86

1

ÚVOD A CÍL PRÁCE

1 1.1

9

Úvod a cíl práce Úvod do problematiky

Stále zvyšující se nároky a požadavky na zpracování dat vedly v 70. letech ke vzniku prvních počítačových sítí. Převážně to byly sítě privátní, které měly pouze omezený vstup uživatelů a nebylo potřeba příliš chránit datové přenosy. Jednalo se obvykle o uzavřené firemní sítě (LAN). Také s nástupem Internetu se situace příliš nezměnila. Zpočátku byl počet uživatelů omezený a veřejné spoje vlastnily velké korporace a monopoly, které dokázaly zajistit bezpečnost. Vše se změnilo s rychlým rozvojem informačních technologií a globálním nasazením Internetu nejen v obchodní sféře, ale i v soukromé. Vybavenost domácností osobními počítači neustále narůstala. Od roku 1993 do roku 1995 se počet uživatelů připojených k Internetu zdvojnásobil. Zvyšoval se i počet poskytovatelů, kteří museli uspokojovat vysokou poptávku po kvalitním připojení. To vše mělo za následek obrovský nárůst sítě a snížení bezpečnosti – Internet byl nesmírně heterogení (mnoho podsítí, které nemohly být kontrolovány). Nechráněná veřejná síť již nebyla dostačující a objevují se nové požadavky na kvalitu a bezpečnost. Jedna z technik, která dokáže zabezpečit přenos, je VPN. V současné době se stalo VPN velmi oblíbené řešení a využívá ho stále více klientů. Existuje mnoho různých technik, jejichž výběr je závislý na charakteru problému. Neustále přibývají nové softwarové i hardwarové varianty. Celý proces realizace má různou složitost v závislosti na velikosti sítě a očekávaných požadavků. I přes značný zájem ještě stále mnoho subjektů na Internetu nevyužívá výhody, které by jim toto nové technické řešení přineslo.

1.2

Cíl práce

Cílem této práce je implementace takového řešení, které by umožňovalo v konkrétní firmě přistupovat k podnikovým zdrojům a zajistilo všeobecnou výměnu dat s důrazem na bezpečnost přenosu. Při průzkumu současných možností zabezpečení firemních sítí jsem za nejlepší a současně nejrychleji realizovatelnou možnost označil řešení pomocí virtuální privátní sítě. Samotné implementaci ve firmě předchází porovnání a testování několika VPN řešení v simulačním prostředí. Varianta splňující nejlépe specifické požadavky bude zavedena v konkrétní firmě. Dílčím cílem je seznámit s problematikou bezpečnosti a spolehlivosti sítí připojených k Internetu. Teoretické informace použité v této práci tvoří základ k pochopení virtuálních privátních sítí.

2

2

PŘEHLED LITERATURY

10

Přehled literatury

VPN je poměrně nová technika. Ještě před několika lety bylo nedostatek informačních zdrojů v dané oblasti a k jejich získání bylo nutné vyvinout značné úsilí. Nyní se situace změnila. VPN používá stále více subjektů a informace se staly snadno dostupné. Existuje mnoho knižních publikací, ale i elektronických dokumentů nacházejících se na Internetu, které se věnují oblasti VPN a bezpečnosti. Práce čerpala jak z monografických publikací, tak i z elektronických zdrojů. Podpůrný zdroj informací poskytla velice rozsáhlá kniha Mistrovství v počítačových sítích (autor Bigelow), která se věnuje nejen základům sítí, ale i jejich správě a konfiguraci v oblasti softwaru i hardwaru. V knize se vyskytuje zmínka i o VPN a protokolu IPsec. Za stěžejní literaturu lze považovat publikaci TCP/IP v kostce od autorky Rity Pužmanové, z které vychází většina citací. Především desátá kapitola o bezpečnosti podrobně popisuje šifrování a jeho jednotlivé algoritmy, řízení přístupu (autentizace, autorizace), digitální podpis a certifikáty, bezpečnostní protokoly (IPSec, PPTP) a VPN (technologie, rozdělení, . . . ). Na formování díla měla i určitý vliv kniha Velký průvodce protokoly TCP/IP s podnadpisem bezpečnost od autora Dostálka. Knihu tvoří kapitoly zabývající se různými bezpečnostními mechanismy například normy PKI, certifikační autorita, SSL/TLS, SSH, IPsec, Kerberos, OpenSSL a další. Při implementaci jednotlivých řešení bylo čerpáno především z nejrůznějších manuálových stránek a návodů, které se vyskytují na veřejné síti. Tyto návody (how to) jsou velice často napsány v anglickém jazyce. Diskusní fóra nabízí zkušenosti realizátorů, které poskytly cenné informace při řešení konkrétního problému související s realizací.

3

3

METODIKA

11

Metodika

Dílo lze rozdělit na tři relativně samostatné celky. V první části se práce zabývá teoretickými základy počítačových sítí, které jsou nezbytné k pochopení dalšího výkladu. Na tyto informace se často odkazuje dále v textu, a proto je důležité jejich objasnění. Následně se tato kapitola zabývá principy bezpečnosti, které tvoří základ VPN sítí. Druhý blok se věnuje již samotnému VPN, ovšem pouze z teoretického hlediska. Popisuje jednotlivé technologické řešení, základní principy a význam VPN sítí. Tyto informace slouží jako zdroj, ze kterého se vychází v praktické části práce. Praktické řešení se nachází v poslední části. Nejprve jsou popsány a vybrány některé nejběžnější VPN realizace, včetně postupu jejich implementace. Každé řešení se testuje v simulačním prostředí domácí sítě. Výsledky implementací jsou porovnány mezi sebou v přehledných tabulkách a okomentovány. Součástí praktické činnosti je i realizace v konkrétní firmě. Aplikuje se právě to řešení, které nejlépe splňuje požadavky kladené firmou. Na závěr bude zhodnocen přínos plynoucí ze zavedení VPN do lokální sítě společnosti.

4

BEZPEČNOST SÍTÍ

4

12

Bezpečnost sítí

S rostoucí závislostí společnosti na výpočetní technice rostou i požadavky na ochranu a zabezpečení dat. Útoky na soukromé informace mohou mít různou formu a charakter. Aby se minimalizovala zranitelnost sítě, je důležité se řídit určitými pravidly (například bezpečnostní politikou). Bezpečnostní politiku lze charakterizovat jako globální koncepci, která se implementuje pomocí různých mechanismů s cílem poskytnout řadu bezpečnostních služeb. Za nejznámější ochranné mechanismy, ze kterých bezpečnostní politika vychází, považujeme kódování, šifrování, řízení přístupu, řízení směrování a další. Některé z těchto mechanismů budou v práci dále vysvětlovány. Bezpečnostní politika podnikové sítě musí podporovat cíle celého podniku, být přesně definovaná jako součást organizačního řízení a také musí být pravidelně prověřována, zda-li splňuje požadované cíle. Mechanismy bezpečnostní politiky poskytují podle autorky Pužmanové (2004, s. 490) následující služby: • autentizace (authentication) – ověření identity komunikujících uživatelů (příslušných vrstvových entit) nebo věrohodnosti zdroje dat, • řízení přístupu (access control) – na základě identifikace uživatele umožnění přístupu do sytému na základě přidělených práv, • zajištění utajení a důvěrnosti přenášených dat (data confidentiality a privacy) – zajištění dat proti odposlechu a ujištění informací o komunikujících uživatelích a charakteru jejich komunikace, • zabezpečení integrity dat (data integrity) – ochrana proti neautorizované změně dat zabráněním modifikaci, duplikaci, nebo zničení posílaných dat, • ochrana proti odmítnutí původu zprávy (nepopiratelnost, nonrepudiation) – zabránění odesílateli nebo příjemci odmítnout potvrzení o vyslání nebo přijetí zprávy (popření odpovědnosti) pomocí důkazu o původu a/nebo důkazu o doručení.

4.1

Způsoby zabezpečení

V současné době se používá mnoho způsobů, jak zajistit potřebnou ochranu sítě. Jednotlivé komponenty se mohou používat samostatně, nebo i vzájemnou kombinací. Jedná se o produkty nejen softwarové (antivirové programy, aplikace VPN, firewally), ale i o hardwarové (firewall, VPN routery).

4.2

Systémy na detekci útoku (průniku)

Tyto systémy se také označují jako IDS (Intrusion Detection Systems). Jejich hlavní náplní je sledovat provoz v síti a zjišťovat, zda-li nedochází k nějaké podezřelé akti-

4.3

Vzdálený přístup, VPN, Certifikáty

13

vitě. IDS ovšem neposkytuje prevenci před útoky, pouze informuje nebo na ně nějakým způsobem zareaguje. Tyto systémy lze rozdělit podle různých kritérií. Podle typu detekce rozlišujeme: • detekce zneužití – nově získané informace se porovnávají se známými hodnotami z databáze znalostí o průnicích. Výsledek závisí na kvalitě databáze, ovšem vyhodnocení útoku je téměř bezchybné. • detekce anomálií – správce sítě na začátku definuje „normálníÿ stav. Systém pak zkoumá dlouhodobě chování a zjišťuje odchylky. Tento způsob dokáže zjistit i nové typy útoků. Mezi známější open source IDS patří Snort, který monitoruje provoz na síti a porovnává ho s databází známých vzorků.

4.3

Vzdálený přístup, VPN, Certifikáty

Bezpečný přístup k podnikovým informacím včetně zpráv elektronické pošty, který je realizován různými varianty připojení. Právě této problematice se práce podrobně věnuje v dalších kapitolách.

4.4

Antivirová ochrana

Dnes již naprosto běžná metoda softwarové ochrany. Antivirový systém se skládá ze samotného programu na detekci a databáze obsahující informace o virech a špiónech (spyware). Většina současných antivirových programů tedy vyhledává škodlivé kódy tak, že obsah zkoumaného souboru porovnává se vzorky známých virů z databáze. Databáze by se měla průběžně aktualizovat, aby byl test dostatečně účinný. V současné době se antivirový program využívá téměř všude a kontroluje veškerý síťový provoz, zejména webovou a e-mailovou komunikaci.

4.5

Firewall

Firewall je systém tvořený jedním nebo více počítači vyhrazený k „bezpečnémuÿ oddělení vnitřní sítě od Internetu tak, aby mohli uživatelé vnitřní sítě přistupovat k informacím dostupným na Internetu (Dostálek, 2003). Ochranná zeď (firewall) má za úkol chránit síť před vnějšími útoky a zároveň neomezovat provoz sítě. Rovněž kontroluje příchozí a odchozí komunikaci. Za firewall se může považovat hardwarové zařízení (router, který filtruje provoz), ale i softwarový produkt. Hlavní funkce, které by měl firewall splňovat: • filtrace paketů – filtrace na úrovni síťové vrstvy. Podle IP adresy rozhodne, které pakety jsou potenciálně nebezpečné a zamezí jim přístup. Aby firewall příliš nezatěžoval přenos, vyžaduje se jednoduché prohlížení záhlaví datagramu,

4.5

Firewall

14

• aplikační brána – zadržuje všechny pakety pro specifikované aplikace do té doby, než zajistí autentizaci vnějšího uživatele a teprve potom umožní komunikaci, • zástupný server (proxy server) – server, který zprostředkovává komunikaci mezi klientem a cílovým serverem. Proxy nejdříve ověří platnost dat a teprve potom se rozhodne, zda-li zprostředkuje komunikaci, • řízení přístupu – autentizace, autorizace, • šifrování zpráv – utajení přenosu informací.

5

ŘÍZENÍ PŘÍSTUPU

5

15

Řízení přístupu

Řízení přístupu tvoří architektura skládající se z autentizace, autorizace a účtovaní, někdy označovaná jako AAA (Authentication, Authorization a Accounting).

5.1

Autentizace

Tento proces slouží k ověření totožnosti uživatele (entity) a dokáže tedy zjistit, zda-li je osoba (entita) skutečně ta, za kterou se vydává. Autentizovat se nemusí pouze osoby, ale i například komunikační entity. Právě autentizaci využívají i směrovací protokoly (RIPv2, OSPF). Autentizace může probíhat jednosměrně (autentizuje se pouze jedna strana) nebo obousměrně. S narůstající složitostí (vlivem Internetu) se velice často využívá důvěry třetích stran, které sdílejí požadovanou tajnou informaci (Kerberos, PKI). Autentizační metody lze rozdělit do různých kategorií. První z nich ověřuje totožnost uživatele podle znalostí tajných informací (hesla, osobní kódy, atd.). Tento způsob se používá velmi často díky jednoduchosti, avšak má i značné slabiny. Nebezpečí hrozí především v podobě zapomenutí nebo krádeže hesla. Osoba by proto měla volit hesla podle určitých pravidel – více znaků, kombinace číslic a písmen, nesmyslná slova, pravidelná obměna hesla apod. Držet se ovšem takových pravidel je časově i paměťově náročné. Proto mnoho lidí volí nevhodná hesla, která se dají lehce zjistit. Druhá metoda autorizace spoléhá na magnetické nebo čipové karty a další předměty, které má subjekt ve svém držení. Tyto předměty se označují jako memory tokens nebo smart tokens a obsahují obvykle potřebné údaje pro identifikaci nositele karty. Pokud ovšem někdo tento předmět ztratí nebo je mu ukraden, plynou z toho značné problémy. Nálezce či zloděj může tento předmět zneužít ve svůj prospěch. Proto se často předměty (karty) kombinují i s hesly (PINY), čímž se bezpečnost značně zvyšuje. Třetí a poslední nejznámější způsob autentizace využívá charakteristických znaků jedince (otisky, DNA, zornice očí, . . . ). Každá osoba se odlišuje od ostatních lidí specifickými vlastnostmi (např. DNA, řetězec aminokyselin, barva hlasu, otisky prstů), kterých se využívá pro autentizaci. Tato metoda se považuje se nejbezpečnější a nezatěžuje příliš uživatele. Vyznačuje se ovšem vysokými náklady.

5.2

Autorizace a účtování

Autorizace následuje po úspěšné autentizaci a zajišťuje uživateli podle jeho práv dostupné operace a data. Stanoví tedy, co může uživatel v systému provádět a k jakým datům má přístup. Autorizace může být konkrétně založena na omezeních, například omezení provádět určité příkazy. Účtování zase obstarává záznam všech

5.3

Systémy řízení přístupu

16

činností uživatele v systému, který může být použit pro správu, plánování, účtování, nebo další účely.

5.3

Systémy řízení přístupu

Architekturu AAA podporuje několik systémů. Za nejznámější se považují TACACS (rozšířený TACACS+), RADIUS a Diameter. 5.3.1

TACACS

Tento systém přístupu umožňuje ověřit každého uživatele ještě před přístupem ke směrovači nebo komunikačnímu serveru. Protokol zajišťuje řízení a kontrolu přístupu do sítě pomocí jednoho nebo více centralizovaných serverů. TATACS (Terminal Access Controller Access Control System) lze používat vzájemně se systémem Kerberos. Uživatel nejprve od serveru systému Kerberos získá podklady pro autentizaci, aniž by se heslo přenášelo v síti a na jejich základě se pak autentizuje přístupovému serveru, kdykoliv potřebuje vzdálený přístup. Z protokolu TACACS bylo později vyvinuto rozšíření TACACS+, které podporuje všechny tři složky architektury AAA a poskytuje detailnější účtovací informace. Hesla přenáší s použitím otisku MD5 a umožňuje šifrování komunikace (v původním TACACS informace nebyly šifrovány). Kvůli rozsáhlým změnám není TATACS+ zpětně kompatibilní s TACACS. 5.3.2

RADIUS

Jedná se o protokol typu klient-server. Celý systém se skládá ze serveru (RADIUS server) a klientů (přístupové servery, NAS, Network Access Server). RADIUS server zajišťuje autentizaci, autorizaci a zpřístupnění služeb vzdáleným uživatelům, kteří se snaží získat přístup do systému. Komunikace probíhá na UDP portu, kde autentizace mezi klienty a serverem vychází ze sdíleného hesla (secret), které se nikdy nepřenáší sítí. Hesla uživatelů se posílají v zašifrované podobě a tím je vyloučena snaha získat nechráněné heslo na síti. Proto se jako hlavní rys RADIUS (Remote Authentication Dial-In User Service) považuje vysoká bezpečnost. Komunikace v rámci RADIUS zachycuje obrázek č. 1 a probíhá následovně: 1. Uživatel, který se chce připojit do sítě, nejprve naváže spojení se serverem NAS. Tento přístupový server požaduje od uživatele jméno a heslo. 2. Jakmile získá NAS tyto údaje, vyšle žádost serveru RADIUS (tzv. access request). 3. Požadavek je poslán přes lokální síť nebo rozlehlou síť. Pokud daný server neodpovídá, může ho zastoupit alternativní RADIUS server.

5.3

17

Systémy řízení přístupu

4. RADIUS server ověří správnost údajů a vyšle odpověď podle výsledku. Pokud je jméno a heslo správné, server vyšle povolení přístupu pro daného klienta do sítě. V opačném případě odešle zákaz.

Obr. 1: Schéma komunikace RADIUS

5.3.3

Diameter

Vzhledem k tomu, že RADIUS byl navržen pouze pro uživatele s vytáčeným spojením využívající protokoly SLIP nebo PPP, nemohli tento systém využívat klienti mobilních sítí. Proto byl také navržen nový systém Diameter, který vychází z protokolu RADIUS a rozšiřuje možnost přístupu do sítě i z bezdrátových mobilních sítí. Protokol také využívá k autentizaci jméno a heslo, tj. dvojici atribut-hodnota (AVP, Atrribute Value Pairs), avšak adresní prostor rozšiřuje na 32 bitů a tím umožňuje uplatnění nových atributů pro mobilní IP. 5.3.4

Porovnání systémů přístupu

Specifické rozdíly mezi systémy RADIUS a TACACS jsou uvedeny v tabulce č. 1. Tab. 1: Odlišnosti TACACS+ a RADIUS

TACACS+ transportní port TCP šifrování celého paketu hesla v databázi šifrování volitelné

RADIUS UDP pouze heslo zašifrována

6

ŠIFROVÁNÍ

6

18

Šifrování

Počátky primitivního šifrování lze nalézt již v době antiky. Obor zabývající se šifrovacími algoritmy a postupy se nazývá kryptografie. Hlavním úkolem kryptografie je utajit informaci takovým způsobem, aby ji mohl získat pouze oprávněný subjekt. Šifrování neslouží pouze k utajení přenášených dat, ale také k autentizaci. Existují tři základní přístupy k šifrování, z nichž každý definuje rozdílné technologie: • symetrické šifrování (soukromým klíčem), • asymetrické šifrování (veřejným klíčem), • hybridní šifrování.

6.1

Symetrické šifrování

Podstatu tvoří jediný šifrovací klíč, který slouží pro šifrování, dešifrování i autentizaci. Aby byla zajištěna bezpečnost, musí znát tento klíč pouze oprávnění uživatelé. Z toho vyplývá, že před vlastní komunikací je nejprve nutné předat druhé straně důvěryhodným způsobem šifrovací klíč a údaje o použitém algoritmu. Metoda využívá skutečnosti, že i při relativně malé délce klíče je i pro současnou techniku velmi časově náročně, klíč uhádnout. Navíc s prodlužováním klíče tento čas exponenciálně roste. Za výhodu se v tomto přístupu považuje rychlost (až 1000-krát menší náročnost na výpočetní výkon než u asymetrického šifrování), za nevýhodu zase nemožnost zjistit, kdo zprávu odeslal nebo přijal. Na ilustraci číslo 2. je zachyceno symetrické šifrování.

Obr. 2: Symetrické šifrování

Symetrické šifrování rozeznává dvě kategorie technik šifrování. Jedná se o šifrování proudové a blokové. Proudové šifry jsou založeny na bázi symetrického šif-

6.1

Symetrické šifrování

19

rování. Šifrování/dešifrování probíhá pomocí klíče bit po bitu, tedy každý bit je zvlášť zašifrován/dešifrován. Blokové šifry rozdělí výchozí data na bitové úseky a ty poté vhodně doplní bitovou šifrou tak, aby měly všechny bloky shodnou velikost. V poslední době se nejvíce používá šifrování 64 bitů, 128 bitů a 256 bitů. Jedná se o rozšířenější způsob než proudové šifry. Mezi typické algoritmy blokových šifer patří DES, AES, BLOWFISH, KERBEROS, 3DES, GOST, IDEA, RC2, RC5, . . . 6.1.1

DES

Tato norma byla vyvinuta roku 1974 a dlouhou dobu se považovala za nerozluštitelnou. Algoritmus se však povedl překonat roku 1997, a proto se jej doporučuje využívat nejvýše pro ochranu dat druhé nejvyšší priority. DES (Data Encryption Standard) používá klíč o délce 56 bitů. Ten lze použít na blok dat o délce 64 bitů (každý osmý bit se používá jako parita). DES tak nabízí 7,2×1016 možných klíčů. Nároky na zvýšení bezpečnosti vedly k úpravě algoritmu a vzniku nového algoritmu 3DES (Data Encryption Algorithm Modes of Operation). Tento algoritmus představuje trojnásobnou aplikaci šifry DES. Nejčastěji pracuje s klíčem o délce 168 bitů. Zvýšení bezpečnosti přineslo i negativní vlastnosti – 3DES je třikrát pomalejší než DES a daleko pomalejší než AES, proto se přestává postupně používat. 6.1.2

AES

Standard vytvořený v roce 1997 institutem NIST (National Institute of Standards and Technology) jako nástupce DES. AES (Advanced Encryption Standard) specifikuje použití klíčů o délkách 128 (3,4×1038 možných klíčů), 192 (6,2×1057 možných klíčů) nebo 256 bitů (1,1×1077 možných klíčů) na šifrování bloků o délkách 128, 192 nebo 256 bitů. Šifrované bloky lze libovolně kombinovat s různými varianty klíčů, takže AES nabízí o 1021 více 128-bitových klíčů než DES. Šifra se vyznačuje vysokou rychlostí šifrování. V současné době není veřejně znám žádný případ plného prolomení této metody ochrany dat. 6.1.3

Kerberos

Jedná se o specifický systém navržený k zabezpečení distribuovaných výpočetních prostředí. Základ tvoří autentizační server, který musí být vysoce zabezpečen, protože obsahuje informace o heslech a přístupových právech všech uživatelů. Přístupové servery neautentizují klienty přímo, ale využívají služeb centralizovaného serveru. Tento systém zavádí lístky (ticket), které prokazují totožnost klienta. Jejich vydávání obstarává centrální autorizační server nebo speciální samostatný server. Lístky se velice podobají certifikátům veřejných klíčů, ale na rozdíl od nich jsou založeny výhradně na použití symetrické kryptografie. Kromě ticket se v systému

6.2

Asymetrické šifrování

20

používá i speciální zpráva (authenicator) obsahující potvrzení identity daného klienta serverem. Ticket může uživatel použít několikrát, dokud jeho platnost nevyprší, avšak authenticator se mění pokaždé. Doba platnosti lístků se obvykle stanoví pouze na několik hodin a vždy obsahují informaci, pro kterou konkrétní koncovou službu jsou určeny.

6.2

Asymetrické šifrování

Tento typ šifrování využívá dva klíče – soukromý a veřejný. Veřejný klíč je přístupný všem, zatímco soukromý pouze tomu, kdo má právo danou zprávu odšifrovat. Klíče se generují hned na začátku před zahájením komunikace. Veřejný klíč se pak rozešle potřebným uživatelům. Odesílající strana použije k zašifrování zprávy veřejný klíč, zatímco přijímající strana dešifruje zprávu svým soukromým klíčem. Neoprávněný uživatel tak nutně potřebuje i soukromý klíč, jinak zprávu nerozluští. Tento postup slouží k ochraně přenášených dat, ale nikoliv k autentizaci původce zprávy. V případě opačného použití klíčů, kdy odesílající uživatel použije k zašifrování svůj soukromý klíč, může pak zprávu dešifrovat téměř každý (veřejný klíč je veřejně dostupný). Odesílatel může být autentizován, protože pouze on vlastní soukromý klíč, kterým zašifroval zprávu. Aby dvě stanice mohly mezi sebou bezpečně komunikovat bez předchozího předávání klíčů, využívá se dvojí šifrování. Odesílající strana nejprve zprávu zašifruje svým soukromým klíčem a ještě jednou jí znovu zašifruje veřejným klíčem cílové stanice. Cílová stanice použije na dešifrování zprávy svůj soukromý klíč a získá zašifrovanou zprávu zdrojové stanice. K dešifrování tedy použije veřejný klíč zdrojové stanice. Asymetrické šifrování ukazuje ilustrace č. 3.

Obr. 3: Asymetrické šifrování

6.2

Asymetrické šifrování

21

Asymetrické šifrování přináší výhodu v podobě správy klíčů. Zatímco u symetrického šifrování se klíč musel bezpečně dostat k uživateli, u asymetrického šifrování tento problém odpadá. Veřejné klíče všech zúčastněných stran se mohou přenést i nezabezpečenou cestou, aniž by to mělo nějaký vliv. Naopak soukromé klíče zůstávají v bezpečí lokální sítě. Mezi hlavní nevýhody asymetrických šifer lze spatřovat ve větší složitosti a náročnosti na výpočetní výkon – jsou pomalejší. Mezi nejznámější asymetrické algoritmy patří Diffie-Hellman, RSA, DSA a další. 6.2.1

Diffie-Hellman

Tento algoritmus vznikl v roce 1976, jehož tvůrci byli W. Diffie a M. Hellman. DiffieHellman (D-H) představuje první algoritmus, založený na použití veřejného klíče. D-H není určen pro šifrování samotných dat, ale pouze pro bezpečnou distribuci klíčů určených k šifrování (jedná se o symetrické klíče – DES, 3DES, IDEA, atd.). Teprve algoritmická modifikace D-H nazývaná ElGamal se využívá k šifrování dat. V D-H se komunikující strany vzájemně neautentizují, což představuje slabinu proti útokům typu man-in-middle. Útočník totiž může odposlechnout veřejné klíče obou stran a podsunout svoje falešné klíče. 6.2.2

RSA

Z počátečních písmen tvůrců Rivesta, Shamira a Adlemana získal tento algoritmus svůj název. Byl vydán o rok později než D-H, tedy v roce 1977. Stal se jedním z nejznámějších a nejpoužívanějších kryptografických algoritmů. RSA je založen na NP-složitosti faktorizace velkých celých čísel. Spolehlivost algoritmu závisí na délce použitelného klíče. RSA umožňuje kromě šifrování i autentizaci. Proto nachází široké uplatnění v elektronické poště, digitálních podpisech, ve webovém zabezpečení nebo při budování VPN. 6.2.3

Otisky zprávy

Asymetrické šifrování se vyznačuje značnou výpočetní náročností a proto by šifrování dlouhých zpráv trvalo neúnosně dlouho. V praxi se nešifruje celá zpráva, ale pouze její tzv. otisk. Otisk vychází z původní zprávy, která je zaznamenána do malého objemu. To provádí specifická matematická funkce. Pokud dojde v původní zprávě k jakékoliv změně, bude se nový otisk lišit od původního. K vytváření otisků zprávy se využívají dva nejznámější algoritmy: • Sekvenční algoritmus MD (Message Digest), který z jakékoliv zprávy vytvoří otisk o délce 128 bitů. Původní zprávu již nelze ze vzniklého otisku získat, ovšem jakákoliv změna ve zprávě způsobí, že nový otisk bude zcela jiný. Jedná se tedy o jednosměrnou funkci. Hlavní význam spočívá v kontrole, zda nedošlo

6.2

Asymetrické šifrování

22

ve zprávě v průběhu přenosu k nějakým změnám. V současnosti se algoritmus vyskytuje v několika verzích: MD2, MD4 a MD5. MD5 se využívá nejčastěji. • Algoritmus SHA (Secure Hash Algoritmus) se velice podobá MD, ale na rozdíl od MD produkuje otisky zprávy o délce 160 bitů. Toto navýšení objemu přináší větší bezpečnost, avšak algoritmus se vyznačuje značnou náročností výpočtu (je asi o čtvrtinu pomalejší než MD). 6.2.4

Digitální podpis

Digitální podpis představuje účinný prostředek pro zajištění integrity odesílaných dat a bezpečné ověření jejich odesílatele. Lze tedy jednoznačně určit, kdo zprávu podepsal a jestli nebyl obsah zprávy pozměněn. Proto jsou digitální podpisy považovány za ještě důvěryhodnější než klasické podpisy na papíře. V papírové podobě lze totiž nahlédnout do obsahu dokumentu, pozměnit jeho obsah nebo zfalšovat podpis, aniž by si toho někdo povšiml. To se u digitálních podpisů stát nemůže. Digitální podpis funguje následovně: ke zprávě určené k odeslání se vypočítá její jedinečný otisk (pomocí hash funkce). Ten se pak zašifruje soukromým klíčem a jako příloha odešle společně se zprávou. Právě otisk zašifrovaný soukromým klíčem se považuje za digitální podpis, protože změna v textu se projeví odlišným podpisem. Příjemce zprávy nejprve na přijatý text použije hashovací funkci a získá tak otisk. V příloze se nachází digitální podpis, který příjemce dešifruje veřejným klíčem a získá původní otisk. Následně se oba otisky porovnají (otisk z původního textu a otisk z digitálního podpisu). Pouze v případě souhlasu lze důvěřovat obsahu zprávy i potvrdit totožnost jejího odesílatele. Aby digitální podpis správně fungoval, musí se ochránit soukromý klíč a zamezit padělání veřejného klíče. Zabezpečit soukromý klíč nepředstavuje nic náročného. Soukromé klíče jsou bezpečně uloženy (někdy i zašifrovány), aby se k nim nikdo nepovolaný nedostal. Mohou se nacházet na disku počítače spravovaného nějakým kryptografickým programem, nebo se často hned při jejich generování uloží na speciální kryptografický hardware, který nikdy neopustí. U veřejného klíče je situace poněkud složitější, protože ho může získat téměř každý. Proto se zavedl digitální certifikát, který se skládá jednak z veřejného klíče majitele certifikátu a také z informací o uživateli nebo zařízení (jedinečné jméno v celém systému, sériové číslo, společnost, oddělení, IP adresa, živnost certifikátu, . . . ). Pravost certifikátu zajišťuje důvěryhodná třetí strana – certifikační autorita (CA). 6.2.5

Digitální certifikát a certifikační autorita

Digitální certifikát je soubor dat ve stanoveném formátu, který identifikuje osobu (Vás, Vašeho obchodního partnera . . . ) nebo server (elektronický obchod, server s internetovým bankovnictvím, poštovní server, VPN server, . . . ) a může během elektronické komunikace mezi dvěma subjekty (osoba/osoba, osoba/server, server/server)

6.2

Asymetrické šifrování

23

zajistit šifrování přenášených dat, ověření jedné a/nebo druhé strany, rozpoznání neoprávněné modifikace dat a s tím související digitální podpis. (Business communication s. r. o, 2003–2008) Rozlišujeme několik typů certifikátů podle účelu, způsobu vystavení či oblasti použití. Z hlediska způsobu vystavení rozeznáváme: • Komerční certifikát – tento certifikát vystaví CA za určitý finanční poplatek a ověří žadatele certifikátu podle své certifikační politiky. V případě osobních certifikátů zjišťuje identitu uživatele; v případě serverových certifikátů i navíc vlastnictví domény. Některé CA nabízejí i nadstandardní služby jako instantní certifikáty (vystavení během několika minut) nebo certifikáty s rozšířeným ověřením (určeno především pro banky). • Kvalifikovaný certifikát – vydávání tohoto certifikátu stanovuje zákon č. 227/2000 Sb., o elektronickém podpisu. Kvalifikované certifikáty obsahují rozšířené identifikační údaje (např. u firemních certifikátů je součástí IČ organizace). Podle zákona může tyto certifikáty vydávat pouze kvalifikovaná CA, jejíž certifikační politiku upravuje rovněž zákon. • Self-signed, vlastní CA – certifikát, který podepíše sám sebe. V tomto typu certifikátu se nevyužívá žádná důvěryhodná CA, ale vytvoří se vlastní CA. S touto vlastní CA se pak podepisují ostatní certifikáty. Aplikace pracující s certifikáty ovšem tuto CA neznají, proto se musí explicitně určit, že je důvěryhodná. Jinak by docházelo při použití k hlášení o nedůvěryhodnosti. Uživatel, který se snaží získat digitální certifikát, nejdříve vygeneruje žádost. Tato žádost obsahuje identifikační údaje žadatele a také příslušný veřejný klíč. Certifikační autorita (vystavitel certifikátu) prověří žadatele a pokud je vše v pořádku podle certifikační politiky, daný certifikát vystaví. Tím se také certifikační autorita (CA) zaručuje za správnost informací uvedených v certifikátu. CA lze rozdělit na důvěryhodné a nedůvěryhodné. Právě seznam těch nejznámějších a nejbezpečnějších CA implementuje řada výrobců softwaru do svých produktů. Seznam důvěryhodných autorit si může ovšem uživatel upravovat sám, podle vlastní vůle (odstraňovat ty, kterým nedůvěřuje, nebo naopak přidávat vlastní, kterým důvěřuje). Na certifikační autority se kladou přísná bezpečnostní opatření (fyzická bezpečnost, prověřený personál, kontrolovatelný postup vydávání certifikátů, atd.). CA kromě vydávání certifikátů také zveřejňuje tzv. revokační listy. Jedná se o seznam obsahující certifikáty, které dříve CA vydala, ovšem nejsou již platné (například došlo k úniku informací a někdo zcizil certifikát). Před použitím veřejného klíče se musí nejdříve ověřit platnost certifikátu. Tuto platnost zajišťuje digitální podpis certifikátu od CA a říká nám, že veřejný klíč patří k dané identitě. Při ověřování platnosti se doporučují následující činnosti: 1. ověřit, zda-li certifikát vydala důvěryhodná CA, 2. zjistit čas platnosti certifikátu (jestli nevypršel),

6.3

Hybridní šifrování

24

3. zkontrolovat revokační list, zda-li se tam certifikát nevyskytuje, výpočet a porovnání otisku. Efektivní využívání veřejných klíčů vyžaduje zavedenou infrastrukturu, která definuje způsob, jak manipulovat s certifikáty vydanými certifikační autoritou. Nejčastěji používaná infrastruktura veřejného klíče se nazývá PKI (Public Key Infrastructure), která přestavuje hierarchický přistup autorit. Na vrcholu hierarchické struktury se nachází kořenové certifikační autority, které jsou všeobecně uznávané a každý jim důvěřuje. Kořenové CA podepisují sami sebe (tzv. self-signed), protože je nemá kdo podepsat. Tato kořenová autorita může pak vydávat certifikáty podřízeným autoritám, kterým se také důvěřuje, protože získaly certifikát od kořenové autority. Podřízené autority mohou opět vydávat certifikáty na ještě nižší úroveň atd. Aby celý systém fungoval, musí všichni důvěřovat kořenové CA.

6.3

Hybridní šifrování

Zatímco symetrické šifrování má problémy s distribucí klíče, tak asymetrické je velmi náročné na matematické operace, tedy i na výkon počítače. Proto vzniklo i šifrování hybridní, které kombinuje obě předchozí šifrování. Využívá rychlost symetrického šifrování a „použitelnostÿ asymetrického šifrování. Je velice oblíbené v praxi.

7

VIRTUÁLNÍ PRIVÁTNÍ SÍTĚ (VPN)

7 7.1

25

Virtuální privátní sítě (VPN) Vymezení a definice VPN

Virtuální neveřejné (privátní) sítě (VPN, Virtual Private Network) jsou novou kategorií podnikových sítí, které nejsou specifické svou technologií, ale způsobem efektivního využití veřejných sítí a komunikačních služeb. Vyžadují totiž úzkou spolupráci klienta (organizace využívající zmíněnou síť) a provozovatele veřejné sítě. VPN jsou zásadní pro realizaci bezpečného vzdáleného přístupu, kdy uživatel připojující se z domova, od klientů nebo na cestách, je nutno jednotně autentizovat a autorizovat jejich přístup k síti a jejím prostředkům (Pužmanová, 2004, s. 534). Virtuální privátní síť (VPN) je šifrované připojení mezi dvěma zařízeními, které zajišťuje zabezpečenou komunikaci mezi dvěma důvěryhodnými sítěmi v nedůvěryhodné doméně. Připojení či virtuální tunelové připojení prochází nedůvěryhodnou sítí, jako je například síť Internet, a nezbytné je proto šifrování důvěrných informací (Biegelow, 2004, s. 219). VPN se poprvé začaly využívat u přepínačů, kde bylo na jedné fyzické vrstvě vytvořeno několik vzájemně oddělených sítí. Využití je nyní trochu odlišné, ale princip zůstal. Zásadní vliv na rozvoj VPN měl vývoj Internetu. Stále zvyšující se počet připojených uživatelů znamenal snížení bezpečnosti komunikace a hledání bezpečných způsobů ochrany. VPN tedy využívá veřejnou komunikační infrastrukturu a vytváří v ní vlastní logickou strukturu (síť). Přestože veřejnou síť používá mnoho uživatelů, VPN se řídí vlastními pravidly, které zajišťují vyšší bezpečnost a kvalitu. Realizace VPN se může uskutečnit na různých vrstvách síťové architektury. Data, která vstupují do veřejné sítě musí nejdříve projít speciálním zařízením (branou VPN), která se nachází na hranici mezi veřejnou a privátní sítí. Než jsou data poslána, musí se upravit tak, aby mohla být bezpečně odeslána k cíli, kde se nachází další VPN brána. Toto zařízení data zpracuje a odešle do cílové privátní sítě. Komunikace VPN se řídí dohody o kvalitě služeb SLA (Service Level Agreements), které jsou na domluvě mezi zákazníkem a provozovatelem služby. VPN přináší celou řadu výhod. Především díky ekonomickým výhodám se stále častěji zavádí do podnikových informačních systémů. Současné komunikační systémy se vyznačují poměrně vysokými fixními náklady a relativně nižšími variabilními. Proto je výhodné spojit diskrétní komunikační služby do jedné větší platformy a rozdělit tak fixní náklady na větší počet klientů. Díky tomu se VPN staly velice populární a aktuální. Aby mohlo ke spojení služeb do jedné platformy vůbec dojít, musí být zajištěna „privátnostÿ komunikace.

7.2

7.2

Základní prvky VPN

26

Základní prvky VPN

Rita Pužmanová (2004, s. 536) uvádí, že VPN tvoří následující složky: 1. brány VPN (VPN gateway) – zařízení pro připojení celé sítě k VPN; 2. klient VPN – software na koncovém zařízení umožňující připojení k VPN; 3. autentizační servery – systémy jako certifikační autority nebo servery RADIUS, které zajišťují identitu bran a klientů VPN; 4. servery pro správu VPN – systémy na řízení, monitorování a informování o stavu VPN; 5. fyzický přenos – spojení po IP nebo Internetu. Brány představují nejdůležitější prvky. Zajišťují bezpečný přístup oprávněných uživatelů do sítě, šifrování, překlad NAT adres a autentizační mechanismy (digitální podpisy, . . . ). Brány tvoří rozhraní mezi důvěryhodnou sítí (intranetem) a veřejnou. Brány VPN také slouží k přidělování adres klientům VPN.

7.3

Adresace ve VPN

Přidělování adres zajišťují VPN brány, které tvoří rozhraní mezi privátní sítí a veřejnou. Každému subjektu ve VPN musí být přidělena adresa. Rozeznáváme několik typu adresace. Většina bran podporuje více způsobů. Základní metody adresace: • statická – každý klient má rezervovanou svoji vlastní IP adresu, kterou získá vždy, když se připojí, • dynamická – IP adresa je přiřazena náhodně nově připojenému klientovi. Subjekt tedy nemusí získat vždy stejnou adresu, ale může se měnit v závislosti na pořadí připojení. Bráně přiřazující IP adresy se obvykle stanoví určitý rozsah adres (DHCP server), • definovaná klienty – klient si sám vybere, kterou IP adresu by chtěl (vzácné). Systém adresace se může lišit podle zvolené techniky. Velice důležitým kritériem bývá rozsah IP adres, který má podniková síť k dispozici. Adresy VPN mohou příslušet k lokální síti, nebo se vytvoří nová virtuální podsíť s novou adresou. Dynamická adresace se nejčastěji používá u běžných uživatelů, statická zase u správců, kterým se na danou IP povolí potřebné aplikace.

7.4

Rozdělení VPN

VPN lze použít pro řešení různých požadavků, které v sobě zahrnují potřebu bezpečně komunikovat přes veřejnou síť, které lze kategorizovat podle Pužmanové (2004, s. 535) následovně: • propojení geograficky distribuovaných pobočkových intranetů (site-to-site, nebo LAN-to-LAN) do jednoho velkého podnikového intranetu; tyto VPN mohou být kvůli statické adresaci snadnou kořistí útočníků, proto je třeba dbát na

7.4

Rozdělení VPN

27

autentizaci jednotlivých poboček (pro každé propojení zvlášť, aby při útoku nedošlo k průniku do celé sítě), zachyceno na obrázku č. 4; • vzdálený přístup (remote access) – připojení vzdáleného uživatele (mobilního nebo domácího pracovníka, teleworker/telecommuter) k podnikovému intranetu, kdy brána VPN musí vykonávat ještě funkce DHCP a DNS; VPN pro vzdálený přístup kladou nároky na řešení autentizace klientů, protože se uživatelé mohou připojovat opravdu odkudkoli a kdykoli; řešení pro vzdálený přístup je zobrazeno na obrázku č. 5; • řešení extranetu – vytvoření sítě vně podnikového intranetu, která je přístupná pouze partnerským organizacím.

Obr. 4: VPN typu site-to-site

Obr. 5: VPN pro vzdálený přístup

7.5

Tunel, tunelování

28

Dále můžeme VPN rozdělit podle toho, na které vrstvě pracuje: • VPN na síťové vrstvě, • VPN na spojové vrstvě, • VPN na transportní a aplikační vrstvě – příkladem mohou být e-mailové systémy s kódovaným přenosem zpráv. V rámci VPN rozlišujeme i dva základní modely: • překryvné VPN – nejčastěji mechanismus tunelování. Tento model vytváří přímé spojení (virtuální okruhy) mezi koncovými zařízeními. Zákaznická zařízení spolu sousedí, tudíž se jedná o překryvnou architekturu. U rozlehlých sítí mohou nastat problémy z důvodů vysoké výpočetní náročnosti. Nejčastěji se využívá u veřejných sítí ATM nebo Frame Relay. • přímý model (peer) – provozování služby již nezajišťují celou dobu pouze koncová zařízení, ale i poskytovatel IP služby. Směrovací výpočty se provádí vždy v každém uzlu na dráze paketu k cíly. Jednotlivé uzly jsou si tedy rovny. Příkladem mohou být klasické sítě založené na směrovačích.

7.5

Tunel, tunelování

Tunelování je jedna z metod tvorby VPN, která vytváří dvoubodové spoje – tunely. Tunel obvykle prochází nechráněnou veřejnou sítí, proto se přenášená data musí zabezpečit a datagramy chránit proti útokům. To obstarává mechanismus přenosu paketů. Původní paket se zapouzdří do jiného paketu a jeho obsah (původní paket) zůstává nečitelný pro transportní síť po celou dobu přenosu tunelem. Každý tunel obsahuje vstup a výstup. Tyto koncové body musí zajišťovat autentizaci a řízení přístupu k privátní síti. Existuje několik způsobů realizací, z nichž se nejčastěji používá end-to-end, ale i další jako POP-to-POP, LAN-to-POP, LAN-to-LAN, endto-POP, end-to-LAN. Tunely podporují aktivní síťové prvky jako směrovače a přepínače. Správce sítě prostřednictvím jejich konfigurace vybuduje tunel mezi dvěma místy a specifikuje jeho vlastnosti, jako typ přenášeného protokolu, typ přenosového (tunelovacího) protokolu, mechanizmus tunelování a adresy koncových uzlů tvořících začátek a konec tunelu (Pužmanová, 2003). Síťový tunel je na obrázku č. 6.

7.6

Technologie VPN

29

Obr. 6: Tunel veřejnou sítí

Tunelování lze provádět na různých vrstvách síťové architektury (Pužmanová, 2004, s. 540): • tunelování na druhé vrstvě (Layer 2 tunneling, Layer 2 VPN, L2VPN) – tunelování rámců PPP Internetem do domácí sítě, mezi přístupovým koncentrátorem a síťovým serverem (L2TP, GRE). L2VPN je generické označení pro řešení připravovaná pracovními skupinami IETF Provider-Provisioned VPN (IETF PPVPN) a Pseudo Wire Emulation Edge to Edge (PWE3), které se zabývají specifikacemi přenosu rámců druhé vrstvy přes IP sítě. L2 protokoly jsou založeny na protokolu PPP a využívají jeho následujících schopností s ohledem na potřeby VPN: autentizace uživatele, dynamická adresace klientů, komprese dat, šifrování dat, management klíčů a multiprotokolová podpora. • tunelování na třetí vrstvě (Layer 3 tunneling, Layer 3 VPN, L3VPN) – zapouzdření IP datagramu do jiného datagramu (IP v IP), čímž se potlačí některé potenciálně problematické záležitosti adresace a protokolu; bezpečnostní mechanizmus je nejčastěji IPSec. Veškerá konfigurace tunelů se provádí mimo vlastní provoz, předem, obvykle manuálně. Tunel v tomto případě nemusí mít udržovací fázi, zatímco u L2 tunelovacích protokolů musí být tunel vytvořen, udržován a ukončen samostatným protokolem druhé vrstvy. Autentizace uživatele, podle typu protokolu, může probíhat buď v rámci L3VPN nebo se může vyžadovat autentizace komunikujících stran před vlastním sestavením tunelu.

7.6

Technologie VPN

Technologie na nichž je VPN postavena se neustále vyvíjí. Tvůrci se snaží vytvářet nové metody a zlepšovat tak vlastnosti VPN sítí. Navzdory nárůstu nových variant existují mechanismy, které jsou osvědčené a standardizované. Právě těmito technikami se bude práce zabývat.

7.6

Technologie VPN

7.6.1

30

GRE

Tento mechanismus tunelování byl vyvinut společností Cisco. Směrovače tvořící konce tunelů zajišťují zapouzdření původních paketů, které se mají přenést tunelem přes transportní síť. Zabalené pakety obsahují GRE hlavičku a cílovou adresu odpovídající směrovači na konci tunelu. Typ přenášeného provozu se specifikuje v poli protokolu. GRE tunely bývají nejčastěji bod-bod což znamená, že existuje jen jedna zdrojová a jedna cílová adresa. Vyskytují se ovšem i firemní implementace typu bod-více bodů. GRE není závislý na transportních a přenášených protokolech. 7.6.2

PPTP (Point-to-Point Tunneling Protocol)

Tento protokol nebyl původně schválen ani navržen jako standard IETF1 , ale byl vyvinut konsorciem firem Microsoft, 3COM a dalšími. Tvůrci časem vydali o tomto protokolu informace v dokumentu RFC a mnoho firem ho začalo používat. Především díky společnosti Microsoft se stal velice rozšířeným a populárním. PPTP navazuje na starší protokol PPP, z něhož vychází a přidává možnost šifrování obsahu. Data se nejdříve zabalí do rámců typu PPP opatřených běžným záhlavím protokolu IP – vznikne PPP hlavička (klasický způsob z PPP). Tento paket se znovu zabalí do bezpečného záhlaví PPTP (relace PPP s GRE), který zajišťuje ochranu proti čtení a zneužití. Ovšem takto vytvořený rámec by nevěděl, kam se má na veřejné síti dostat, a proto se musí znovu rámec opatřit IP záhlavím (vnějším). Celá hlavička se skládá z vnějšího veřejného IP záhlaví, následuje PPTP záhlaví (GRE hlavička), potom opět IP záhlaví (vnitřní, které je již chráněno), TCP/UDP a nakonec samotná data. Na ilustraci č. 7 je znázorněno zapouzdření paketu protokolem PPTP.

Obr. 7: Schéma zapouzdření protokolu PPTP rámce PPP

Přenos VPN může být chráněn nepovinným šifrováním MPPE (Microsoft Pointto-Point Encryption). V průběhu ověřování MS-CHAP nebo EAP-TLS se vygenerují šifrovací klíče zajišťující ochranu. Tento protokol lze považovat za méně bezpečný, 1

Internet Engineering Task Force „Komise techniky Internetuÿ – vyvíjí a podporuje internetové standardy a úzce spolupracuje s konsorciem W3C a s orgány ISO/IEC.

7.6

Technologie VPN

31

než třeba IPSec či L2TP, protože jeho šifrovací klíče jsou odvozeny přímo z uživatelského hesla. PPTP používá stejné klíče jak k autentizaci, tak k samotnému šifrování dat. Tato technologie přináší výhody i nevýhody. Mezi hlavní výhody patří zachování vlastností PPP protokolu (např. mechanismus ověřování klienta – autentizace, výměna šifrovacích klíčů, možnost komprese, lehké zapouzdření, . . . ). Jednoduchá realizace, snadná rozšiřitelnost a implementace v operačních systémech Windows z něj udělaly velmi oblíbený protokol. Největší slabinu lze spatřit v nedostatečně kvalitním šifrování. 7.6.3

L2TP (L2TP/IPSec)

Tento protokol vznikl vzájemnou spoluprací firem Microsoft a Cisco. Technologie je postavena na protokolu PPTP (Microsoft) s využitím nového záhlaví L2F (Cisco). Šifrovací mechanismus PPTP byl zcela nahrazen mnohem dokonalejším IPSec. Kombinace protokolu L2TP a zabezpečení IPSec se označuje jako L2TP/IPSec. Podobně jako PPTP umožňuje L2TP paketovat rámce PPP přes danou síť (nejčastěji Frame Relay, Ethernet nebo ATM), avšak nepoužívá k šifrování datagramů standard MPPE. Místo toho využívá šifrovací službu IPSec. Pro vytvoření tunelu a zahájení jeho řízení používá spojení UDP. V rámci tunelu umožňuje L2TP autorizaci uzlů, šifrování dat a kompresi rámců. Obrázek č. 8 znázorňuje zapouzdření paketu pomocí L2TP a IPSec. Zapouzdření paketů L2TP se skládá ze dvou vrstev: 1. zapouzdření L2TP – rámec PPP je vnořen do hlavičky protokolu L2TP a do hlavičky UDP, 2. zapouzdření IPSec – výsledná zpráva protokolu L2TP je vnořena do hlavičky a do koncové části protokolu IPSec ESP (Encapsulating Security Payload) a opatřena koncovou částí zabezpečení IPSec, která zajišťuje integritu a ověření zprávy a koncovou hlavičkou protokolu IP. V hlavičce protokolu IP je uvedena zdrojová a cílová adresa IP, která odpovídá klientovi a serveru VPN.

Obr. 8: Zapouzdření protokolu L2TP a IPSec datagramu PPP

7.6

Technologie VPN

32

Zabezpečení se realizuje standardem DES (Data Encryption Standard) nebo trojnásobným algoritmem 3DES pomocí šifrovacích klíčů generovaných v procesu vyjednávání protokolu IKE (Internet Key Exchange). 7.6.4

IPSec

Technologie, kterou plně podporuje organizace IETF. Je tedy popsána normami RFC2 a dalšími veřejnými dokumenty – plně standardizována. Původně byl tento protokol navržen jako součást nově navrhovaného síťového protokolu IPv6. Jeho vývoj se ovšem opozdil, a proto byl IPSec vydán předčasně. Díky kvalitnímu řešení se rychle uplatnil především pro zabezpečení VPN tunelů v modelu gatway-to-gatway i client-to-gatway. Microsoft začal tento protokol zabudovávat do svých operačních systému (od Windows 2000 a výš). Tím se stal značně populární a to i přes poměrně složitou implementaci. IPSec pracuje ve dvou základních režimech. Každý se vyznačuje různým uplatněním a také odlišnou složitostí (režií): • transportní mód – IP hlavička je modifikována jen mírně, aby původní informace o cestě paketu v lokální síti zůstala zachována. Tento režim zajišťuje bezpečný provoz mezi jednotlivými koncovými počítači a žádný další provoz netuneluje. Využívá se především pro autentizaci vzdálených klientů VPN. Podporuje i nadstandardní mechanismy (např. QoS – Quality of Service), protože již dopředu zná informace o cílovém zařízení (adresa v IP hlavičce je zachována). Nižší režie než u tunelovacího módu. • tunelovací mód – původní data jsou i s IP hlavičkou zcela zabalena a opatřena novým záhlavím určeným pro přenos nezabezpečenou veřejnou sítí. Jakmile paket dorazí k cílovému zařízení, je opět rozbalen. Složitá režie zvyšuje nároky na výkon koncových zařízení. Využívá se u modelu gatway-to-gatway. Častější způsob realizace IPSec. Protokoly AH (Autentification Header) a ESP (Encapsulating Security Payload) tvoří základ technologie IPSec. Zajišťují bezpečnost paketů změnou původní IP hlavičky. Především umí obstarat autorizaci, integritu, utajení přenášených paketů a ochranu před zneužitím. Oba protokoly mohou fungovat samostatně i společně. Technologie se odlišuje podle režimu, v kterém pracují. Protokol AH Tento protokol obstarává ověřování a integritu odesílaných paketů. Data jsou chráněna proti zneužití či změnám. Chybí zde ovšem šifrování a proto data nejsou utajena – možnost čtení dat. Integritu paketů zajišťuje podpis hash funkce s klíčem. 2

RFC (Request For Comments „žádost o komentářeÿ – označuje řadu standardů a dalších dokumentů popisujících internetové protokoly, systémy apod. RFC jsou považovány spíše za doporučení než normy, přesto se podle nich řídí drtivá většina Internetu.

7.6

Technologie VPN

33

AH používá bezpečnostní kontrolní součet HMAC, který jako hashovací funkci může využívat buď MD5 nebo SHA-1. MD5 se lépe hodí pro vzdálený přístup, zatímco SHA-1 pro VPN typu site-to-site. SHA-1 se totiž vyznačuje větším zabezpečení díky více výpočetním cyklům než MD5. Vypočítaná hodnota u SHA-1 má délku 160 bitů, na rozdíl od MD5, který má délku pouze 128 bitů. Podepisuje se celý paket (na rozdíl od ESP) kromě polí, která se během přenosu neustále mění např. TTL – Time to Live. V transportním režimu se hlavička protokolu AH vkládá mezi IP protokol a data IP. Rámec se podepisuje celý, jak ukazuje následující obrázek č. 9.

Obr. 9: Podepsání rámce protokolem AH v transportním režimu

U tunelového propojení AH zapouzdří paket IP, opatří jej hlavičkou protokolu AH a celý paket podepíše pro integritu a ověřování. Upravený paket je znázorněn na následujícím schématu č. 10.

Obr. 10: Upravený datagram protokolem AH v tunelovacím režimu

Protokol ESP Protokol slouží jako doplněk k AH. Umožňuje totiž navíc utajit data, což AH protokol neuměl. Utajení obstarává šifrovací mechanismus DES nebo 3DES. V transportním režimu podepisuje pouze data, nikoliv hlavičku. Tudíž jsou utajená pouze data. Obrázek č. 11 znázorňuje umístění hlavičky protokolu ESP před data IP a umístění koncové části ESP s ověřovací koncové části ESP za data IP. Hlavička se nepodepisuje. Na další ilustraci č. 12 je zachycen režim tunelového propojení ESP, který zapouzdří paket IP, opatří jej hlavičkami protokolů ESP a IP a ověřovací koncovou částí ESP.

7.6

Technologie VPN

34

Obr. 11: Podepsání rámce protokolem ESP v transportním režimu

Obr. 12: Datagram upravený protokolem ESP v tunelovacím režimu

7.6.5

MPLS

Tento mechanismus umožňuje vytvářet VPN sítě. MPLS (MultiProtocol Label Switching) se využívá pro VPN typu propojení podnikových sítí, ovšem nehodí se pro vzdálený přístup. Technologie umí zajistit požadovanou kvalitu služby (QoS) a regulovat provoz. Vyznačuje se vyšší výkonností díky své nové technologii, kde se složité výpočty přenechávají pouze okrajovým zařízením. MPLS může pracovat jak na druhé, tak i na třetí vrstvě. Dále pracuje s nejrůznějšími síťovými protokoly a technologiemi. Není závislý na konkrétním přenosovém médiu. Základem tohoto protokolu je přepínání značek. Směrování paketů se oddělí od vlastního předávání. Směrovače na okrajích sítě přidají k datagramům značky (label). Přenos uvnitř sítě se pak řídí výhradě přes tyto značky. Nedochází k prohledávání směrovacích tabulek a přenos se tak výrazně urychlí. Značka, která se přidává mezi záhlaví druhé a třetí vrstvy obsahuje kromě informace o dalším skoku také úroveň priority datagramu (tím je zajištěna QoS) a další specifické údaje pro řízení. MPLS/BGP L3VPN Toto technologické řešení patří do modelu rovnocenných sítí (peers). Pracuje na úrovni třetí vrstvy. Samotné přepínání datagramů zajišťuje MPLS, zatímco směrování vykonává protokol BGP. Celá VPN lze rozdělit na správu poskytovatele (P, provider) a síť zákazníka (C, customer).

7.6

Technologie VPN

35

V části spravované poskytovatelem se nachází okrajové zařízení (PE, Provider Edge), které zajišťují veškeré řízení provozu. Uvnitř sítě propojují okrajové směrovače jednotky, nazývané centrální směrovače (LSR). LSR slouží pouze jako výkonné přepínače na základě MPLS (nezabývají se VPN směrováním). Zákazníci připojují své sítě pomocí zákaznických směrovačů (CE, Customer Edge). Tyto zákaznické směrovače sousedí s okrajovými směrovači PE a předávají jim směrovací informace pro privátní síť. Každý směrovač PE pak obsahuje jednu globální směrovací tabulku a odděleně jednotlivé směrovací tabulky VRF (Virtual Routing and Forwarding). Pro každou VPN má přiřazenou jinou VRF, takže PE může mít uložen i několik VRF tabulek. Pro tok paketů s podobnými charakteristikami (např. podle adres, typu aplikačního protokolu, QoS) se definují cesty LSP (Label Switched Path). Právě LSP realizuje cesty pro jednotlivé VPN na základě směrovací tabulky VRF. VRF umožňuje propojit síť MPLS provozovatele s rozšířeným protokolem BGP a síť zákazníka, která používá interní směrovací protokol nebo statickou cestu. Z hlediska BGP přestavují PE a CE partnery (peers) pro externí eBGP a PE s PE tvoří partnery v rámci interního iBGP. Toto rozšíření BGP umožňuje koexistenci VPN cest s konvenčními cestami přes síť provozovatele, a to i cest VPN, které se z hlediska používaných privátních adres překrývají. Každá VPN se vyznačuje svojí vlastní adresou. Aby byla tato adresa jedinečná a nedocházelo by ke konfliktu více stejných adres, používá se tzv. rozlišovač cesty. Jedná se o osmibytovou hodnotu, která se přiřazuje k prefixu adresy IPv4. Komunikace mezi příjemcem a odesílatelem PE je ošetřena pomocí značky VPN. Odesílající okrajový směrovač nejprve upraví směrovací informaci – přeloží tuto informaci z IPv4 do pojetí VPN. To zahrnuje přiřadit rozlišovač cesty, místo původu (SoO, Sito of Origin) a cíl exportu cesty. Směrovací informaci pošle na rozhraní smyčky PE a odeslání na další směrovač se odloží. Přijímací PE přeloží adresy VPN do IPv4. Tímto se přijímací PE dozví potřebné informace (místo vzniku, umístění VRF tabulky, . . . ). MPLS L2VPN MPLS umí pracovat i na úrovni druhé vrstvy. Tato implementace patří do překryvného modelu. Podstatu tvoří způsob zapouzdření rámců do paketů MPLS, způsoby distribuce značek MPLS a propojení koncových zákazníků. Tato technologie je založena na vytváření tunelů, které prochází páteřní sítí na bázi MPLS. Způsob zapouzdření závisí na konkrétní realizaci druhé vrstvy (Ethernet, Frame Relay, ATM, . . . ). Vztah mezi PE a CE není rovnocenný, jak tomu bylo u MPLS/BGP. Také nejsou udržovány žádné samostatné směrovací tabulky. Místo toho se vytvoří dvoubodový tunel (pseudowrite), takže se data z okrajových sítí musí zapouzdřit pro přenos sítí L2.

7.6

Technologie VPN

7.6.6

36

SSL/TLS

SSL (Secure Socket Layer) byl vyvinut společností Netscape Communications. SSL pracuje na aplikační vrstvě, avšak nová verze TLS (Transport Layer Security) zasahuje do vrstvy transportní. Používá se hlavně pro zabezpečení webové komunikace (například webový přístup, přenos souborů či e-mail). SSL a TLS se rozšířilo i do oblasti VPN, kde našlo také důležité uplatnění. Technologie zajišťuje autenticitu odesílatele, integritu a šifrování dat. SSL má poměrně silné nástroje na ochranu dat, kterou obstarává asymetrické šifrování. Používá se tedy kombinace šifrování veřejného a soukromého klíče. Autentizaci lze opatřit jménem a heslem (RADIUS), jménem a tokenem (RSA) nebo digitálními certifikáty. Nabízený certifikát musí uživatel přijmout a potvrdit jeho identitu. Tato skutečnost představuje slabinu a proto je SSL náchylný na útoky typu man-in-the-middle. SSL zabezpečuje pouze konkrétní aplikaci (nikoliv všechny). V mnoha případech není třeba instalovat další software, protože uživatelé se mohou připojit pomocí webového prohlížeče na základě URL. SSL se využívá u aplikací typu klient-server. Klient, který chce navázat spojení pošle serveru požadavek spolu s dalšími doplňujícími informacemi. Server odešle odpověď klientovi na jeho požadavek, která obsahuje potřebné informace a hlavně certifikát serveru. V této fázi si klient a server stanoví algoritmy, které budou používat. Klient si prověří pravost certifikátu serveru a vytvoří základ šifrovacího klíče, jenž zašifruje veřejným klíčem serveru. Server dešifruje základ šifrovacího klíče pomocí svého soukromého klíče a stanoví se hlavní šifrovací klíč. Klient a server si navzájem potvrdí šifrování tímto hlavním klíčem. 7.6.7

Porovnání technologie

Každá technologie se vyznačuje specifickými vlastnostmi, které jsou určující pro výběr a nasazení v praxi. Nelze stanovit nejlepší řešení, protože se pro každý případ může hodit jiné. Složitost implementace, způsob realizace, metoda zabezpečení, rozšiřitelnost nových uživatelů, výkonnost, kompatibilita, cena, dostupnost a další vlastnosti mají podstatný vliv na výběr konkrétního řešení. V současné době patří mezi nejpopulárnější VPN realizace právě IPSec. Implementace této metody je poměrně složitá, ovšem bezpečnost patří mezi její silnou stránku. Je určena pro všechny aplikace TCP/IP díky tomu, že pracuje na třetí vrstvě, na rozdíl od SSL. To se využívá pouze pro omezenou sadu aplikací, které ho podporují. SSL se ovšem začíná využívat stále častěji a jeho význam roste. Také u mechanismu MPLS se předpokládá slibná budoucnost. Především díky rostoucím požadavkům na rychlost a propustnost sítě. Stručný přehled technik VPN zachycuje tabulka č. 2. Tabulka č. 3 zachycuje šifrovací protokoly a algoritmy v PPTP, L2TP, IPSec.

7.6

37

Technologie VPN

Tab. 2: Přehled technologií a uplatnění v různých VPN

Typ technologie MPLS PPTP L2TP IPSec SSL/TLS SSH

Vrstva Site-to-site 2/3 ano 2 ne 2 ne 3 ano 4 ne 4 ne

Vzdálený přístup ne ano ano ano ano ano

Tab. 3: Porovnání šifrovacích protokolů

Protokol Šifrování Algoritmy PPTP

L2TP IPSec

MPPE

RSA RC4

IPSec

DES 3DES AES AES AES

Klíče 40-bit 56-bit 128-bit 56-bit 112-bit 128-bit 192-bit 256-bit

Generování klíče LM (DES), hash, hesla LM (DES), hash, hesla NTLMv2 (MD4), hash, hesla náhodný klíč Diffie-Hellman group 1, 2, 14

8

VLASTNÍ PRÁCE

8

38

Vlastní práce

8.1

Výchozí stav

8.1.1

Charakteristika společnosti

Realizace VPN se vztahuje ke společnosti A. KTI s. r. o, která je známá jako zemědělská a lesnická projekční kancelář zabývající se projektováním lesních cest, potoků, přehrad, cyklostezek a dalších. Firma se rovněž zaměřuje na opravu historických památek, u kterých je kladen důraz na zachování historického vzhledu. Tento požadavek vychází nejen z celospolečenského významu restaurovaného objektu, ale také z požadavků historiků, kteří do daného procesu nemalou měrou zasahují. Kromě zmíněného se tato firma zabývá dodávkou veškerého sortimentu, která s realizací výše uvedených činností souvisí. Náplní pracovníků je také vytvářet návrhy, které mají zabránit různým jevům typickým pro přírodu, jako jsou například povrchové eroze zeminy. Navíc společnost pomáhá zahrádkářům a pěstitelům tím, že jim poskytuje a dodává vázací pásky, které usměrňují růst nových stromů a také obecně vším, co nás v oblasti zahrádkářství, restaurátorství a projektování různých cest vyššího společenského významu napadne. 8.1.2

Vybavenost výpočetní technikou

A. KTI disponuje následujícím technickým vybavením: • • • • • • •

router, síťový plotter, dvě síťové tiskárny, 12 pracovních stanic (mezi nimi i notebooky), přístupový bod, switch, další příslušenství.

Za nejvýznamnější prvek celé sítě se považuje router. Jedná se o linuxový server (Linux Slackware 12), který zprostředkovává komunikaci mezi Internetem a lokální sítí. Internetové připojení obstarává poskytovatel Netbox s garancí agregace 2 Mbit obousměrně (2 Mbit download i upload). I přes menší požadavky společnosti na rychlost, představuje toto připojení slabší článek – nestabilní odezva a kolísavá propustnost. Router dále zajišťuje tyto služby: DHCP, SAMBA, DNS, FIREWALL. Součástí serveru jsou i rozšířená disková pole, která slouží pro centrální ukládání a archivaci firemních dat a také dvě síťová rozhraní (první pro uživatele 100 Mbit, druhé pro Gbit). Router rovněž podporuje VLAN. Všechny prvky lokální sítě (tiskárny, stanice, . . . ) tvoří jednu VLAN, druhá je určena pro připojení externích uživatelů a dočasných hostů. Tento způsob realizace zvyšuje bezpečnost, protože se „neznámíÿ uživatelé nemohou dostat k firemním zdrojům a zneužít je

8.1

Výchozí stav

39

tak. VLAN je implementována pomocí portů (port trunk). Server se prezentuje veřejnou IP adresou 83.240.26.178 nebo názvem akti.netbox.cz ve vnější síti. V lokální síti 192.168.1.0/24 má přidělenou adresu 192.168.1.2. Zjednodušenou (např. mezi switchem a stanicemi) topologii sítě znázorňuje obrázek č. 13.

Obr. 13: Topologie firemní sítě

Síť se dále skládá z 12 pracovních stanic, plotteru, dvou síťových tiskáren, switche a přístupového bodu (Access Point), který umožňuje bezdrátový přístup klientům k firemní síti. Switch dovoluje připojit až 28 zařízení, z nichž 24 rychlostí 100 Mbit a 4 rychlostí 1 Gbit. Na pevných počítačích jsou nainstalovány multilicence dražších nástrojů, které slouží pro 3D návrhy realizovaných projektů. Jedná se hlavně o AutoCAD, AutoDESK a Civil3D. Licence softwaru Civil3D je řešena pomocí sdílených klíčů, které jsou generovány na základě názvů jednotlivých pracovních stanic. Jelikož je počet sdílených klíčů omezen na počet licencí, je nutné dbát ochrany každé licence jednotlivého softwaru.

8.1

Výchozí stav

8.1.3

40

Požadavky na řešení a motivace

Hlavním důvodem pro vybudování VPN v podniku je bezpečný přístup k firemním datům a prostředkům i ze vzdálených míst. Od toho se odvíjí celá řada výhod. Jednou z nich je správa jednotlivých stanic přes vzdálený přístup. Tento mechanismus umožňuje připojení na vzdálený počítač (v tomto případě stanici) a ovládat ji. Na této stanici musí být aktivována příslušná aplikace (například Real VNC Server) tvořící server. Klient se pak připojí na tento server, kde se mu zobrazí pracovní plocha, jako by seděl přímo u tohoto počítače. Neméně zajímavou funkcí vzdáleného přístupu je wake-on-line. Jedná se o schopnost „oživitÿ počítač na dálku. Správce tedy může konkrétní počítač zapnout, nastavit na něm potřebné věci a opět ho vypnout, aniž by byl v jeho blízkosti. Funkce wake-on-line musí být podporována síťovou kartou a BIOSem, kde se tato možnost nastavuje. Zaměstnanci využívají při práci několik komerčních programů, které vyžadují platné licence. Ty mohou mít charakter pevných licencí (pouze na konkrétní počítač) nebo flexibilních. Společnost využívá právě flexibilních licencí, které umožňují před každým spuštěním vygenerovat licenci pro konkrétní počítač a následně na něm spustit požadovanou aplikaci. Celý systém spravuje licenční server a podmínky se řídí podle smlouvy poskytovatele (např. časové omezení, maximální počet klientů, atd.). Licenční server firmy A. KTI pracuje pouze v rámci lokální sítě, a proto je pro využívání licencí z Internetu nezbytné připojit se do VPN. S ohledem na současnou situaci a budoucí vývoj si společnost stanovila následující požadavky nového řešení virtuální privátní sítě: Počet uživatelů V současné době se nachází ve firmě 12 pracovních stanic. Tento počet ovšem nemusí být zdaleka konečný. S realizací VPN se totiž očekává nárůst nových uživatelů, kteří se budou připojovat do VPN sítě přes Internet. Může se jednat o současné zaměstnance, kteří využívají výhod VPN a připojují se odkudkoliv, ale i o nově příchozí zákazníky, partnery, atd. Proto by mělo výsledné řešení podporovat snadné přidávání klientů. Maximální počet současně připojených uživatelů v síti by neměl přesáhnout hodnotu 30. Rychlost a odezva Společnost se zabývá hlavně projektováním, kde se nepředpokládá požadavek na maximální propustnost či okamžitou odezvu. Poskytnuté internetové připojení tomu také částečně odpovídá. Podmínkou je alespoň třetinová rychlost linky, tzn. 85 Kbyt/s.

8.2

Testované VPN řešení

41

Podporované platformy Server, který plní roli routeru, běží na operačním systému Linux. Nejen, že se Linux vyznačuje poměrně slušnou stabilitou a výkonností, ale také je zcela zdarma. Společnost proto nasadila Linux (namísto Windows Server 2003) a ušetřila tak na licencích nejméně 16 tisíc Kč. Drtivá většina klientů naopak běží pod operačním systémem Windows. Z těchto důvodů je hlavním požadavkem na VPN podpora operačních systému Linux (pro server) a Windows (pro klienty). Cena Společnost se řadí mezi menší podniky a také tomu odpovídá topologie (není samostatná serverovna), způsob realizace, počet klientů, rozpočet, . . . Cena proto hraje významnou roli při výběru vhodné implementace. Z tohoto pohledu se jeví jako nejlepší řešení open source a freeware produkty. Bezpečnost Na lokální síti se vyskytují důležitá firemní data, jejíchž vyzrazení by mělo pro společnost katastrofální důsledky. Tato podniková data mají větší hodnotu než samotné softwarové či hardwarové vybavení. Proto se bezpečnost považuje za nejdůležitější složku VPN. Nabízí se několik možností zabezpečení, avšak nejlepší variantu dostupných řešení představují X.509 certifikáty. Takový stupeň zabezpečení se v počítačových systémech používá stále častěji díky výhodám, které přináší. Ostatní požadavky Další parametry jako ovladatelnost, správa logů, přehlednost, design či paměťová náročnost závisí spíše na celkové kontextu řešeného problému a přístupu řešitele.

8.2

Testované VPN řešení

Virtuální privátní sítě lze realizovat mnoha způsoby, které se vyznačují odlišnými vlastnostmi. Tam, kde se realizuje příslušná VPN se obvykle vyskytují hardwarová zařízení v podobě routeru či firewallů. Je proto nezbytné, aby VPN podporovala na příslušné vrstvě. Tato zařízení vykonávají mnoho síťových činností včetně VPN. Jejich hlavní výhodou je vysoká bezpečnost a snadná správa, protože zařízení není součástí počítače a nezatěžuje příliš server. Nevýhodou bývá nejčastěji cena, avšak i ta se v poslední době značně snížila. Softwarové produkty lze rozdělit podle typu licence na několik druhů. Pro realizaci VPN se software rozlišuje do těchto základních typů:

8.2

Testované VPN řešení

42

• Proprietární SW je ten, jehož volné/svobodné užívání, redistribuce a modifikace je zakázána nebo vyžaduje souhlas autora spolu se zaplacením licenčního poplatku. Typickým příkladem je MS Windows. • Komerční SW bývá nejčastěji vyvinut za účelem zisku autora z jeho užívání. „Komerčníÿ a „proprietárníÿ software nejsou totéž, ale většina komerčního SW je i proprietární. Je tedy důležité tyto termíny rozlišovat a zmínit, že i některý komerční SW je v plné míře svobodný/open source. • Freeware je SW, který umožňuje volnou redistribuci, avšak zakazuje jeho modifikaci a prodej (podobně jako u shareware a proprietárního SW). Je tedy velmi nutné rozlišovat „Freewareÿ a „Free softwareÿ. • Open source – termín „open sourceÿ znamená obecně otevřený zdrojový kód. Open source software je pak software šířený pod určitými licencemi, které svým nabyvatelům zaručují určitá práva. Zejména se jedná o možnost zdrojový kód softwaru volně užívat, modifikovat nebo dále svobodně distribuovat (tedy i prodávat). Komerční aplikace v oblasti sítí obvykle integrují více služeb (firewall, ftp, vpn, antivirový program, mail server a další) a vyznačují se často uživatelsky přívětivým prostředím se zaměřením na intuitivní chování klienta. Je to dáno tím, že aplikace se prodávají na trhu a ze zisku si tak společnost může dovolit více investovat do vývoje (více programátorů, více grafiků, apod.). Nevýhodou je vysoká cena a silná závislost na jednom programu (při výpadku dojde k zastavení všech služeb). Mezi výhody pak patří komplexnost a jednoduchost. Naopak řešení open source se vyvíjí v omezených podmínkách, kdy se na tvorbě podílejí často dobrovolníci a nadšenci, kteří nepožadují žádné finanční ohodnocení. I přes to se tyto aplikace mohou svou funkčností rovnat komerčním produktům, ačkoliv jsou určeny pouze pro konkrétní operace (nepodporují komplexní správu). Hlavním požadavkem při výběru ukázkových realizací byla podpora operačních systému Windows i Linux. Nízká cena, vysoká bezpečnost, stabilita a snadná rozšiřitelnost tvoří vedlejší kritéria. Také z tohoto důvodu byla vyloučena komerční řešení. Naopak otevřené realizace se pro své vlastnosti staly hlavním předmětem zájmu. 8.2.1

Testovací prostředí

Všechny testy a zkoušky byly prováděny v simulačním prostředí, které mělo napodobit reálnou situaci. Vzhledem k omezeným zdrojům je však testovací soustava zastaralá a také proto mohou být výsledky testů do určité míry ovlivněny. Rovněž propustnost datové linky neodpovídá skutečnosti, avšak pro stanovení závěru je to postačující prostředí. Testovací soustava se skládala ze dvou strojů a switche. Počítač č. 1: server • operační systém: Linux Fedora Core 5,

8.2

• • • • •

Testované VPN řešení

43

procesor: AMD K6 500 MHz, síťový adaptér: Realtek RTL8139 Family PCI Fast Ethenet 100 Mbit/s, operační paměť: 256 MB RAM, IP adresa: 192.168.2.99, VPN adresa: 10.0.1.99 .

Počítač č. 2: klient • • • • • •

operační systém: Windows XP service pack 1, procesor: Intel Celeron 3,4 GHz, síťový adaptér: Marvell Yukon PCI-E Gigabit Ethernet 1 Gbit/s, operační paměť: 1 GB RAM, IP adresa: 192.168.2.2, VPN adresa: 10.0.1.1.

Switch • Edimax 5 Port Fast Ethernet Switch, • 10/100 Mbit/s. Aby byly výsledky věrohodnější, byly testy prováděny ve dvou odlišných prostředích: • lokální síť: 100 Mbit/s, oba PC propojeny přes swich kroucenou dvoulinkou, • bezdrátová síť (subnet). K měření maximální propustnosti sítě a latence (odezvy) se používala grafická utilita Netdoppler. Tento program posílá na určenou IP adresu paketový tok (packet stream) i jednotlivé pakety (single packets) a zjišťuje tak maximální propustnost. Naměřené hodnoty umí software také zobrazit prostřednictvím přehledného grafu a histogramu četností. Druhou nasazenou utilitou je iperf. Jedná se o textovou aplikaci typu klient-server, která se spouští z příkazové řádky a testuje rychlost mezi komunikujícími stranami. Server představuje stranu, která naslouchá, zatímco klient na něj odesílá data a měří tak propustnost. 8.2.2

Poptop – PPTP

Jak již název napovídá, tato implementace pracuje s protokolem PPTP, který je postaven na protokolu PPP vytvářející relace s GRE. Vzhledem k tomu, že byl tento protokol vytvořen společností Microsoft a dalšími velkými softwarovými giganty, je PPTP klient běžně součástí operačních systémů Windows. Pro platformu Linux byla vyvinuta aplikace Poptop, která slouží k vytvoření serveru. Klientskou část Linuxu zase umí obstarávat grafická utilita pptp-php-gtk nebo novější ppptpconfig.

8.2

Testované VPN řešení

44

Poptop spadá pod licenci GNU/GPL3 a je tedy k dostání zcela zdarma. Přenos lze šifrovat pomocí MPPE v rozsahu 40-128 bitového šifrování. Protokol využívá porty 1723 TCP, 1723 UDP a 47 IP (GRE) pro navázání spojení a proto mu mohou dělat firewally značné problémy. Poptop podporuje připojení více klientů (standardně 100) a to nejen z operačního systému Windows, ale i z Linux. Podporuje několik typů autentizace: • • • • • •

PAP (Password Authentication Protocol), EAP (Extensible Authentication Protocol), SPAP (Shiva Password Authentication Protocol), CHAP (Challenge Handshake Authentication Protocol), MS-CHAP (Microsoft Challenge Handshake Authentication Protocol), MS-CHAP2 (Microsoft Challenge Handshake Authentication Protocol verze 2).

Konfigurace serveru - Linux Ještě před samotnou instalací Poptop je důležité si systém nachystat. Obecně platí, že pokud systém neobsahuje danou utilitu nebo potřebnou verzi programu, je nezbytné si nainstalovat požadovaný balíček z distribuce nebo z webových stránek. Poptop využívá protokolu PPP a proto musí být v Linuxu zaveden PPP démon (pppd), který zajišťuje PPTP komunikaci. Démon musí podporovat příslušný autentizační protokol, v mém případě MS-CHAP verzi 2, který se považuje za nejbezpečnější. Následující příkaz vypíše na obrazovku podporované autentizační protokoly (musí se vytisknout mschap-v2 nebo chapms-v2). strings ‘which pppd‘ | grep -i chap

Aby mohl být přenos přes VPN šifrován, musí být MPPE podporováno nejen ppp démonem, ale zároveň musí být podpora MPPE zabudována přímo do jádra operačního systému. První příkaz slouží k ověření podpory démonem a druhý k zjištění podpory jádrem. modprobe ppp-compress-18 strings ‘which pppd‘|grep -i mppe|wc --lines

Pokud vše proběhlo v pořádku, může se přejít k samotné instalaci Poptop. Po stáhnutí příslušného balíčku z domovské stránky se nainstaluje do systému pomocí příkazů: 3

GNU General Public License, GNU GPL (česky „všeobecná veřejná licence GNUÿ) je licence pro svobodný software, která spolu s licencí GFDL tvoří základ celého GNU projektu. Zdrojové kódy software pod GPL mohou být svobodně upravovány a používány, šířeny však musí být opět pod GPL (jestliže se je rozhodnete dále šířit), a to obvykle bezplatně (příp. za cenu distribučních nákladů).

8.2

Testované VPN řešení

45

./configure make make install (lépe checkinstall)

nebo pomocí rpm balíčků: rpm -i název balíčku

Další důležitý krok spočívá ve vytvoření nebo úpravě tří významných souborů pptpd.conf, options.pptpd, chap-secrets. /etc/pptpd.conf: #virtuální adresa serveru localip 10.0.0.99 #adresy virtuálních vzdálených strojů (mohou být ve formě rozsahu) remoteip 10.0.0.1-90 #cesta k~souboru s~nastavením ppp démona option /etc/ppp/options.pptpd /etc/ppp/options.pptpd: #jméno serveru pro autentizaci (stejné jako v~/etc/ppp/chap-secrets) name pptpd #server nebude sám sebe autentizovat noauth #zamítnutí autentizace pomoci pap, chap a mschap refuse-pap refuse-chap refuse-mschap #požadovaná autentizace MS-CHAPv2 require-mschap-v2 #šifrování pomocí 128bit MPPE require-mppe-128 #vypnutí komprese nobsdcomp nodeflate novj lock novjccomb /etc/ppp/chap-secrets: #v tomto souboru jsou uloženy všechny přihlašovací údaje včetně hesel, také existuje možnost přiřadit klientovi konkrétní IP adresu #klient server klíč IP adresy client1 pptpd heslo1 10.0.1.1 client2 pptpd heslo2 10.0.1.2 client3 pptpd heslo3 * #adresa se přidělí automaticky

Samotné spuštění Poptop serveru lze buď příkazem pptpd, nebo service pptpd start, kdy se server spustí jako služba. Výpis logů zaznamenává server do démona

8.2

Testované VPN řešení

46

syslog. Tyto logovací údaje se nachází v souboru /var/log/messages. Výpis vypadá následovně: Server pptpd[2628]: MGR: Maximum of 100 connections reduced to 90, not enough IP addresses given Server pptpd[2629]: MGR: Manager process started Apr 19 13:31:34 Server pptpd[2629]: MGR: Maximum of 90 connections available Server pptpd[2631]: CTRL: Client 192.168.2.2 control connection started Server pptpd[2631]: CTRL: Starting call (launching pppd, opening GRE) Server pppd[2632]: Plugin /usr/lib/pptpd/pptpd-logwtmp.so loaded. Server pppd[2632]: pppd 2.4.3 started by root, uid 0 Server pppd[2632]: Using interface ppp0 Server pppd[2632]: Connect: ppp0 <--> /dev/pts/3 Server pptpd[2631]: GRE: Bad checksum from pppd. Server pptpd[2631]: CTRL: Ignored a SET LINK INFO packet with real ACCMs! Server pppd[2632]: MPPE 128-bit stateless compression enabled Server pppd[2632]: local IP address 10.0.1.99 Server pppd[2632]: remote IP address 10.0.1.1 Server kernel: audit(1208604703.017:18): avc: denied { write } for pid=2632 comm="pppd" name="wtmp" dev=dm-0 ino=69191 scontext=root:system_r: pppd_t:s0 tcontext=system_u:object_r:wtmp_t:s0 tclass=file

Konfigurace klienta – Windows Nastavení klienta PPTP v platformě Windows lze považovat za triviální záležitost. Stručný postup: 1. vytvořit nové připojení, 2. připojit k firemní síti, 3. připojení k virtuální síti, 4. zadat název připojení, 5. nevytáčet počáteční připojení, 6. zadat IP adresu serveru (v LAN to bude 192.168.2.99). Důležité je ještě nastavit vlastnosti připojení. V záložce zabezpečení vyžádat povinně šifrování a povolit pouze autentizaci MS-CHAPv2, v nastavení sítě potom vybrat typ serveru jako PPTP VPN. Nyní již stačí kliknout na přihlásit, vyplnit potřebné uživatelské jméno (client1) a heslo (heslo1) a připojit se. Více na adrese http://www.ucs.ed.ac.uk/. 8.2.3

OpenVPN

Tento produkt je možné rovněž získat zdarma, protože patří do skupiny open source VPN, jejíž licenci spravuje GNU/GPL (veřejná licence). Na rozdíl od aplikací na bázi IPsec, využívá tento projekt zabezpečení SSL/TLS. Mezi jeho hlavní přednosti patří (Hladík, 2004): • Podpora mnoha platforem - Linux, Solaris, OpenBSD, FreeBSD, NetBSD, Mac .OS X a Windows 2000/XP.

8.2

Testované VPN řešení

47

• Celý program běží v user mode, a není tedy potřeba patchovat kernel (za předpokladu, že máte zapnutou podporu pro TUN/TAP zařízení). • Podpora režimů 1:1 (tunel) nebo N:1 (režim client/server). • Možnost použití sdíleného klíče a/nebo SSL certifikátů. • Jednoduchá konfigurace a perfektní logy. • Bezpečnost. • Vysoká odolnost při použití na nekvalitních linkách. • Volitelná komprese. • Podpora HTTP a SOCKS proxy. To je výhodné především pro RoadWarrior režim, klient se tak může připojit téměř odkudkoliv. • a mnoho dalšího . . . Z uvedeného textu vyplývá několik významných předností. Především podpora více operačních systémů (hlavně Windows a Linux) a režim RoadWarrior (client/server), který umožňuje vzdálený přistup klientů do VPN sítě. OpenVPN vytváří dva typy síťového rozhraní. TUN se používá pro dvoubodové (point-to-point) rozhraní a pracuje s IP rámci, zatímco TAP zastupuje ethernetové rozhraní pracující s ethernet rámci. OpenVPN používá pouze jediný port, který lze libovolně zvolit (číslo portu, UDP nebo TCP). Komunikace tedy lépe prochází přes firewally než v případě PPTP (využívá více portů). Program dokáže rovněž při přenosu využívat kompresní knihovnu LZO, která v určitých případech (záleží na struktuře dat a výkonnosti hardwaru) dokáže zvýšit rychlost přenosu. Autentizaci realizuje OpenVPN pomocí sdíleného klíče (sdílené klíče se mezi komunikujícími stranami používají i pro šifrování paketů) nebo X.509 (ověřování prostřednictvím SSL certifikátů). Ověření uživatele se může doplnit i uživatelským jménem a heslem, což vede ke zvýšení bezpečnosti. Šifrování zajišťuje buď sdílený klíč nebo nástroj OpenSSL implementující různé šifrovací algoritmy. OpenVPN má kromě zmíněných výhod i pár slabších míst. Vzhledem k tomu, že SSL/TLS pracuje až na čtvrté vrstvě, dotýká se toto řešení pouze některých aplikací. Také výměna sdílených klíčů nebo distribuce certifikátů představuje určitý bezpečnostní problém. Jak již bylo uvedeno, OpenVPN nabízí dva základní způsoby realizace: pointto-point (tunel) a client-server (pro připojení RoadWarrior klientů). S ohledem na požadavky kladené společností se budu zabývat pouze módem client-server. Zvolené charakteristiky testu • • • • • • •

režim client/server, autentizace pomocí X.509 certifikátů bez přihlašovacích jmen a hesel, síťové rozhraní TAP, zvolený port 10 000, povolena kompresní knihovna LZO, server – Linux, klient – Windows.

8.2

Testované VPN řešení

48

X.509 Certifikáty Pro autorizaci se v režimu client-server používá především SSL a X.509 autorizace, zatímco sdílený klíč pouze jako doplněk. V podstatě existují dva způsoby, jak získat platné certifikáty. První možností je získání certifikátu od důvěryhodné komerční certifikační autority. Tyto „oficiálníÿ autority vystavují certifikáty za určitý poplatek a pouze na omezenou dobu. Avšak většina subjektů a aplikací bude těmto certifikátům plně důvěřovat, protože za ně odpovídají kvalifikované autority. Tyto certifikáty se hodí především pro veřejné servery. Druhým způsobem je vytvoření vlastních certifikátů specializovaným softwarem. Naopak nasazení takto vytvořených certifikátů se hodí pro omezený počet uživatelů (například právě firemní síť). V tomto případě se bude jednat o open source OpenSSL. Aby byl certifikát použitelný, musí být vždy podepsán. Buď může být podepsán sám sebou (tzv. Self-signed Certificate), nebo je podepsán jiným certifikátem, tzv. certifikační autoritou (Certificate Authority, CA). Postup tvorby vlastních certifikátů pomocí OpenSSL je následující: 1. Po instalaci balíčku openSSL následuje sestavení vhodné adresářové struktury a vytvoření požadovaných souborů, které openSSL vyžaduje. mkdir /etc/ssl/demoCA mkdir /etc/ssl/certs mkdir /etc/ssl/crl mkdir /etc/ssl/newcerts mkdir /etc/ssl/demoCA/private touch /etc/ssl/demoCA/index.txt echo 01 > /etc/ssl/demoCA/serial

2. Průběh pokračuje vytvořením vlastní certifikační autority, která bude podepisovat všechny certifikáty používané v lokální síti pomocí svého soukromého klíče. Certifikát této vytvořené CA potom uživatelé naimportují do svých počítačů a zamezí tak výpisu hlášek o nedůvěryhodných certifikátech. openssl req -new -x509 -nodes -out cacert.pem -keyout cakey.pem -days 1098

Tímto příkazem se vytvoří nová certifikační žádost, která se sama podepíše (self-signed). Soukromý klíč nebude zašifrován heslem, doba platnosti certifikátu bude 3 roky a výstupem bude certifikát cacert.pem a soukromý klíč cakey.pem. K podepisování ostatních certifikátu musí být klíč CA umístěn ve složce /etc/ssl/demoCA/privates. Průběh tvorby generování CA vypadá následovně: openssl req -new -x509 -nodes -out cacert.pem -keyout cakey.pem -days 1098 Generating a 1024 bit RSA private key ............++++++ ................++++++

8.2

Testované VPN řešení

49

writing new private key to ’cakey.pem’ ----You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter ’.’, the field will be left blank. ----Country Name (2 letter code) [AU]:CZ State or Province Name (full name) [Some-State]:Czech republic Locality Name (eg, city) []:Brno Organization Name (eg, company) [Internet Widgits Pty Ltd]:testVPN Organizational Unit Name (eg, section) []:Certifikacni autorita Common Name (eg, YOUR name) []:Anonym Email Address []:[email protected]

3. Nyní přichází na řadu vytvoření žádostí o certifikát jednotlivých uživatelů a serveru. Každý uživatel by si tedy měl sám vytvořit dvojici žádost-soukromý klíč, žádost poslat certifikační autoritě na podepsání a klíč bezpečně uschovat. Vzhledem k tomu, že zastupuji klienty, CA i server, budu vše provádět na jednom stroji a vytvořené žádosti budu rovnou podepisovat. Soukromé klíče a podepsané certifikáty potom bezpečně dopravím na potřebná místa. Při vytváření se požaduje, aby bylo pole organization name a state or province name pro všechny certifikáty stejné. openssl req -new -nodes -out request.pem -keyout key.pem -days 1098

Tento příkaz zajistí vytvoření nové žádosti pro server request.pem a soukromého klíče key.pem s platností 3 roky. Podobně lze vytvořit i žádost a soukromý klíč klientovi: openssl req -new -nodes -out request2.pem -keyout client.key -days 1098

4. Nakonec se musí vytvořené žádosti podepsat certifikační autoritou a nastavit výstupní soubory. openssl ca -in request.pem -out server.crt openssl ca -in request2.pem -out klient.crt

Úspěšné podepsání certifikátu serveru vypadá následovně: openssl ca -in request.pem -out server.crt Using configuration from /opt/csw/ssl/openssl.cnf Check that the request matches the signature Signature ok Certificate Details:

8.2

Testované VPN řešení

50

Serial Number: 1 (0x1) Validity Not Before: Apr 18 22:46:22 2008 GMT Not After : Apr 18 22:46:22 2009 GMT Subject: countryName = CZ stateOrProvinceName = Czech republic organizationName = testVPN organizationalUnitName = Server commonName = ServerVPN X509v3 extensions: X509v3 Basic Constraints: CA:FALSE Netscape Comment: OpenSSL Generated Certificate X509v3 Subject Key Identifier: 1D:62:78:D2:BD:28:F1:C2:08:90:31:BE:80:94:96:8B:FB:32:29:0F X509v3 Authority Key Identifier: keyid:76:48:FC:F1:1A:66:E2:2A:06:60:5E:F3:62:31:94:B0:CF:5C:03:F8 Certificate is to be certified until Apr 18 22:46:22 2009 GMT (365 days) Sign the certificate? [y/n]:y 1 out of 1 certificate requests certified, commit? [y/n]y Write out database with 1 new entries Data Base Updated

5. OpenVPN využívá pro výměnu klíčů protokol Diffi-Hellman (1024 nebo 2048 bitový), který se vytvoří příkazem: openssl dhparam -out dh1024.pem 1024

6. Nyní zbývá jen potřebné soubory dopravit bezpečně na určená místa. V případě OpenVPN tedy na: Server (Linux) /etc/openvpn/cacert.pem /etc/openvpn/server.crt /etc/openvpn/key.pem /etc/openvpn/dh1024.pem Klienti (Windows) C:\program files\openvpn\config\cacert.pem C:\program files\openvpn\config\klient.crt C:\program files\openvpn\config\client.key

8.2

Testované VPN řešení

51

Konfigurace serveru – Linux Systém musí podporovat nejen SSL šifrování, ale i kompresi dat pomocí knihovny LZO, které bude VPN používat. Proto je nutnou podmínkou balíčky OpenSSL a LZO do systému zavést. Vlastní instalace balíku OpenVPN pak probíhá opět pomocí známých příkazů: ./configure make make install (lépe checkinstall)

Klíčový konfigurační soubor (např. server.conf) umístěný implicitně v adresáři /etc/openvpn musí obsahovat následující údaje: #režim server mode server #tls jako server (označení serveru) tls-server # používaný port, 1194 = default port 10000 # protokol transportní vrstvy, tcp/udp proto tcp-server #zvolené síťové rozhraní dev tap0 # virtuální adresa VPN serveru ifconfig 10.0.1.99 255.255.255.0 # rozsah VPN adres pro klienty ifconfig-pool 10.0.1.1 10.0.1.90 255.255.255.0 # současné přihlášení více klientu pod stejným certifikátem duplicate-cn #nastavení SSL certifikátů pro server (umístění v~/etc/openvpn/) #cesta k~certifikátu certifikační autority ca /etc/openvpn/cacert.pem #cesta k~certifikátu serveru cert /etc/openvpn/server.crt #cesta ke klíči serveru key /etc/openvpn/key.pem #parametry pro Diffie-Hellman protokol dh /etc/openvpn/dh1024.pem #status serveru status /etc/openvpn/vpn.status 10 #výpis logů do souboru log-append /var/log/openvpn #udržuje spojení naživu, 10 (ping) a 120 (ping-restart) keepalive 10 120 #komprese přenášených dat pomocí LZO comp-lzo #ukecanost serveru

8.2

Testované VPN řešení

52

verb 4

Spuštění serveru se provede příkazem: openvpn --config /etc/openvpn/server.conf

Výpis hlášení o stavu připojení se může tisknout buď přímo na terminál serveru, nebo do příslušného textového souboru, v tomto případě se jedná textový soubor openvpn. Konfigurace klienta – Windows Instalace na straně klienta se rovněž nepovažuje za obtížnou. Instalační software v podobě OpenVPN GUI klienta provede automaticky všechny potřebné operace včetně vytvoření nového TAP/TUN připojení. Postup při instalaci klienta s grafickými ukázky se nachází na adrese http://support.zcu.cz/. V jediném souboru se nastaví veškerá konfigurace klienta. Jedná se o soubor client.ovpn, který by měl v tomto testu obsahovat následující informace: #server ke kterému se připojujeme remote 192.168.2.99 tls-client port 10000 proto tcp-client dev tap #povoluje staženi konfigurace ze severu pull #nastavení SSL certifikátů pro klienta #certifikát certifikační autority ca cacert.pem #certifikát klienta cert klient.crt #klíč klienta key client.key #opakování řádků v~logu mute 10 comp-lzo verb 4

Po nainstalování se v systémovém tray (ikony vpravo dole) objeví ikona dvou červených monitorů (OpenVPN), na kterou stačí dvakrát rychle kliknout (dvojklik). Otevře se okno s informacemi o připojování (zde můžete být vyzváni na zadání uživatelského jména a hesla); po korektním připojení se toto okno automaticky minimalizuje.

8.2

Testované VPN řešení

8.2.4

53

TINC

Tinc představuje opět volný software, jehož licence spadá pod GNU. Tato utilita je tvořena VPN démonem, který zajišťuje tunelování a šifrování přenosu. Veškerý přenos se může komprimovat pomocí knihoven lzo nebo zlib. Tinc komunikuje přes SSL spojení a šifrování obstarává OpenSSL (podobně jako u OpenVPN). Tinc běží pod více operačními systémy (Linux, FreeBSD, OpenBSD, NetBSD, MacOS/X, Solaris, WindowsXP, . . . ) a podporuje i IPv6. Hlavním rozdílem oproti většině podobných řešení je podpora automatické full-mesh topologie sítě. To zapříčiňuje, že pakety jdou (pokud je to možné) přímo do cíle bez meziskoků – každý komunikuje přímo s každým. V autentizaci Tinc zaostává, protože nabízí pouze metodu RSA klíčů – soukromé a veřejné. I když je to principielně jednoduché, vzniká problém s přenosem veřejných klíčů. K zašifrování dat se standardně používá šifrování blowfish se 128 bitovým klíčem. Při vytváření spojení Tinc automaticky vytvoří virtuální síťové rozhraní tap/tun, které je využíváno pro přenos (ve Windows si toto zařízení musíme nainstalovat sami příslušnou aplikací). Tinc používá standardně port 655, který lze však změnit. Konfigurace serveru – Linux Linux musí obsahovat následující prvky: • podpora tun/tap rozhraní (většina novějších verzí jádra to již má zavedeno), • knihovna OpenVPN pro šifrování, • volitelné balíky lzo nebo zlib pro kompresi (někdy to Tinc vyžaduje již při kompilaci). Jakmile jsou balíky nainstalovány, přejde se k instalaci Tinc (klasickým způsobem). V adresáři /dev/net/ se musí nacházet síťové zařízení. Pokud tam není, vytvoří se příkazem: mknod -m 600 /dev/net/tun c 10 200

Tinc podporuje více než jedno připojení (až 16), a proto by se mělo pro identifikaci každému spojení přiřadit vlastní jméno. V adresáři, kde se nachází Tinc (defaultně /usr/local/etc/tinc), vytvoříme složky nesoucí název konkrétního připojení. V této situaci se jedná o složku vpn. Ta bude obsahovat soubory: rsa key.priv (soukromý klíč), tinc-up (script pro vytváření virtuálního rozhraní), tinc.conf (konfigurace serveru) a adresář hosts. Do adresáře hosts se umístí veřejné klíče komunikujících stran včetně svého. Vytvoření adresářů a souborů: mkdir vpn mkdir vpn/hosts vim tinc.conf vim tinc-up vim server

8.2

Testované VPN řešení

54

Obsah souborů: tinc.conf #jméno serveru Name = server #jaké zařízení bude použito Device = /dev/net/tun tinc-up #nastavení virtuálního zařízení #!/bin/sh ifconfig vpn 10.0.1.99 netmask 255.255.255.0 broadcast 10.0.1.255 rsa_key.priv #obsah soukromého klíče -----BEGIN RSA PRIVATE KEY----soukromý klíč -----END RSA PRIVATE KEY----hosts/server Address = 192.168.2.99 Subnet = 10.0.1.99 -----BEGIN RSA PUBLIC KEY----veřejný klíč serveru -----END RSA PUBLIC KEY----hosts/klient1 Address = 192.168.2.2 Subnet = 10.0.1.2 -----BEGIN RSA PUBLIC KEY----veřejný klíč klienta1 -----END RSA PUBLIC KEY-----

Postup tvorby RSA klíčů: tincd -n vpn -K

Tímto příkazem se vytvoří soukromý a veřejný klíč. Cestu zadáme tak, aby se soukromý klíč nacházel ve složce vpn (např /usr/local/etc/tinc/vpn) a soukromý klíč vložil do již vytvořeného souboru serveru (veřejný klíč se přidá na konec). Výpis níže ukazuje proces tvorby klíčů. tincd -n vpn -K Generating 1024 bits keys: ......++++++ p ..................................................................++++++ q Done. Please enter a file to save private RSA key to [/etc/tinc/vpn/rsa_ke y.priv]: Please enter a file to save public RSA key to [/etc/tinc/vpn/hosts/server]:

8.2

Testované VPN řešení

55

Spuštění tinc démona se provede příkazem: tincd -n vpn

Konfigurace klienta – Windows Pro operační systém Windows existuje spustitelná aplikace, která navíc obsahuje i instalaci síťového rozhraní tap 32. Je tedy nezbytné kromě instalace samotného Tinc nainstalovat i právě toto rozhraní. Adresářová struktura se velmi podobá linuxové, jen se nachází ve složce Program Files. Tvorba klíčů i ostatních souborů je totožná až na soubor tinc-up, který chybí. Místo něj se musí nastavení rozhraní provést ručně: najít toto rozhraní – vlastnosti – protokol TCP/IP – vlastnosti – nastavit IP adresu VPN a masku podsítě (IP 10.0.1.2, masku 255.255.255.0). Název tohoto rozhraní se musí upravit podle jména, které je v souboru tinc.conf u parametru interface (v tomto případě VPN). Aby komunikace fungovala, je nezbytné dopravit do všech komunikujících strojů (do složky hosts) veřejné klíče s jejich IP adresami (veřejnými i lokálními). Obsah souboru: /tinc.conf #jméno klienta Name = klient1 #připojím se k~serveru s~názvem ConnectTo = server #jaké zařízení bude použito Interface = VPN

Tinc se spouští úplně stejně jako v Linuxu. Navíc lze tuto aplikaci přidat do služeb a poté nastavit, aby se pouštěla automaticky. Více na adrese http://www.tinc-vpn.org/examples/windows-install. Příkazy pro přidání a spuštění služby: tincd -n vpn tinc.vpn service installed tinc.vpn service started

8.2.5

L2TP/IPSec

Toto proprietární řešení využívá stejně jako PPTP protokol PPP, avšak díky implementaci IPSec se považuje za daleko bezpečnější, protože nabízí modernější algoritmy na šifrování (3DES, DES, AES), integritu dat (MD5, SHA1) a mechanismy autentizace (sdílené klíče, RSA, certifikáty X.509). Pro operační systém Windows lze použít standardního klienta, ovšem pro Linux je nezbytné nainstalovat potřebné

8.2

Testované VPN řešení

56

nástroje. Celý mechanismus se skládá ze tří základních složek PPP, L2TP a IPSEC. Pro připojení do VPN sítě se postupuje následovně: 1. Nejprve se musí obě komunikující strany dohodnout na pravidlech, které budou používat. To představuje především použité šifrování, autentizaci, integritu dat a další vyjednávání zabezpečení. Tento mechanismus se nazývá IKE (Internet Key Exchange). Jedná se o složitý postup, který probíhá v několika fázích, kde se nejprve nabídne několik možností a postupně se omezuje výběr až na konkrétní dohodnuté hodnoty. Jakmile se dohodnou pravidla, předá se iniciativa na L2TP. 2. Protokol L2TP využívá PPP. Nejprve vytvoří kanál pro přenos řídících paketů mezi klientem (LAC) a serverem (LNS), kde se dohodnou parametry spojení – vytvoření, zrušení tunelu, zřizování relací a ověření uživatele založené na protokolu PPP. Poté se vytvoří tunel L2TP-DC, který již přestavuje vlastní datové spojení. Datové pakety obsahují rámce PPP. Konfigurace serveru – Linux Pro technologii IPSec, která pracuje pod linuxem, bylo vyvinuto několik nástrojů. Mezi nejznámější patří Freeswan nebo nástupce Openswan, avšak já si vybral ipsectools, který bývá standardně součástí jádra od verze kernelu 2.6. Mezi nejdůležitější nástroje, které ipsec-tools obsahuje patří racoon a setkey. Racoon zajišťuje vyjednávání spojení mezi komunikujícími stranami – jedná se o IKE démona. Úloha setkey zase spočívá ve správě bezpečnostních politik. Kromě ipsec-tools je nezbytné implementovat do operačního systému i nástroje L2TP (démon l2tpd) a ppp. Jednotlivé části: 1. Bezpečnostní politiky – bezpečnostní politika obsahuje pravidla, které bude dané spojení dodržovat. Všechny pravidla jsou uloženy v databázi bezpečnostních politik SPD (Security Policy Database). Jednotlivé záznamy SAD (Security Association Database) obsahují veškeré informace o spojení (bezpečnostní protokol, šifrovací algoritmus, countery, atd.). SAD lze spravovat manuálně, ovšem pouze pokud známe informace o protistraně. V případě větších sítí nebo neznámých stran (anonymních) byl navržen protokol ISAKMP (Internet Association and Key Management Protocol). V simulaci je známá IP adresa protistrany (v LAN se jedná o 192.168.2.2), proto lze použít manuální nastavení politiky. Nejlepším řešením je uložit si příslušné příkazy do scriptu (soubor) a následně spouštět tento script pro stanovení politik. Konkrétní soubor obsahuje: #!/sbin/setkey -f flush; spdflush; spdadd 192.168.2.99/32[1701] 192.168.2.2/32[1701] any -P out ipsec esp/transport//require; spdadd 192.168.2.2/32[1701] 192.168.2.99/32[1701] any -P in ipsec esp/transport//require;

8.2

Testované VPN řešení

57

Touto politikou ošetříme spojení mezi 192.168.2.99 a 192.168.2.2 v obou směrech na portu 1701. Také se doporučuje tento script zavést do init, aby se politika automaticky stanovila hned po startu počítače. Pokud neznáme komunikující strany nebo by byla správa politik příliš komplikovaná, je lepší přenechat tuto činnost démonu Racoon a protokolu ISAKMP. Pouze se Racoonu stanový parametry politik a zbytek se vykoná automaticky. 2. Racoon – jak již bylo uvedeno výše, Racoon představuje IKE démona pro vyjednávání spojení. Podporuje několik typů autentizace. Pro testovací účely je postačující předsdílený klíč, který byl také zvolen při realizaci, ale pro praktické nasazení se upřednostňují X.509 certifikáty. Obsah konfiguračního souboru Racoona (/etc/racoon/racoon.conf) je vypsán níže. #autentizace bude pomocí předsdíleného klíče uloženého v~souboru psk.txt path pre_shared_key "/etc/racoon/psk.txt"; #způsob výpisu, debug - ladění log debug; #podmínky pro vyjednání, anonymous -- kdokoliv remote anonymous { exchange_mode main; doi ipsec_doi; situation identity_only; #pokud politky není v~databázi, vytvoří se nová generate_policy on; proposal_check obey; proposal { #požadované šifrování encryption_algorithm 3des; hash_algorithm md5; authentication_method pre_shared_key; dh_group 1; } } sainfo anonymous { lifetime time 28800 sec; encryption_algorithm 3des; authentication_algorithm hmac_md5 ; compression_algorithm deflate ; }

Do souboru psk.txt se zapíše předsdílený klíč (buď na konkrétní IP adresu, nebo na všechny). 192.168.2.2

tajneheslo

8.2

Testované VPN řešení

58

3. L2TP a PPP – pro sestavení L2TP tunelu se modifikuje soubor /etc/l2tpd/l2tpd.conf do tvaru: [lns default] #určení rozsahu VPN adres pro klienty a pro server ip range = 10.0.1.1-10.0.1.90 local ip = 10.0.1.99 #stanovení autentizačních protokolů require chap = yes refuse pap = yes require authentication = yes name = LinuxVPNserver #nastavení ppp démna ppp debug = yes pppoptfile = /etc/ppp/options.l2tpd length bit = yes

V následujícím souboru /etc/ppp/options.l2tpd jsou uloženy klasické parametry určené pro ppp démona. ipcp-accept-local ipcp-accept-remote ms-dns 192.168.1.1 auth crtscts idle 1800 mtu 1400 mru 1400 nodefaultroute debug lock deflate 9 proxyarp connect-delay 5000

Soubory /etc/ppp/chap-secrets a /etc/ppp/options.pptpd jsou totožné jako v případě PPTP s těmito rozdíly: • v chap-secrets v poli server není pptpd, ale LinuxVPNserver nebo lépe *, • v options.pptpd se nesmí vyskytovat parametr require-mppe-128. Aby spojení fungovalo, musí se spustit oba démoni současně. Pro testovací účely se doporučuje aktivace v debug módu: racoon -F l2tpd -D

8.3

Porovnání, hodnocení variant

59

Konfigurace klienta – Windows Pod operačním systémem Windows lze použít nativního klienta (stejně jako u PPTP), což představuje značnou výhodu oproti řešení využívajících softwaru třetích stran. Postup realizace se velice podobá PPTP. Na rozdíl od PPTP není potřeba vybírat pouze možnost MS-CHAP-v2 (strany se vzájemně dohodnou). Při použití metody pre-share (sdílený klíč) se musí tento klíč zadat do pole: nový klíč a zaškrtnout možnost použít pro autorizaci předsdílený klíč. Tato nastavení se nachází v záložce zabezpečení – nastavení protokolu IPSec. V případě X.509 certifikátů stačí pouze importovat certifikáty do systému. Pro připojení stačí již vyplnit požadované údaje a potvrdit. Pokud se klient nachází za NAT, musí se upravit registry. To však přesahuje již náplň této práce.

8.3

Porovnání, hodnocení variant

Každé řešení se vyznačuje charakteristickými rysy. Některé prvky mohou mít realizace společné, jiné jsou typické pouze pro danou implementaci. Většina těchto vlastností se těžko porovnává nebo určuje, proto zde uvedu pouze základní. Patří sem: • kompatibilita, • škálovatelnost, • bezpečnost, • výkon, • použitelnost. 8.3.1

Kompatibilita

Hlavním požadavkem společnosti byla podpora Linuxu a Windows. Také proto všechna testovaná řešení fungují v těchto dvou operačních systémech a nejen v nich, jak je patrné v tabulce č. 4. U většiny řešení je multiplatformní podpora velice bohatá a vyrovnaná. Tab. 4: Podporované platformy VPN

Linux FreeBSD Solaris OpenBSD NetBSD MacOS/X Windows XP Pocket PC 2003

TINC OpenVPN L2TP/IPSec PPTP ano ano ano ano ano ano openswan ano ano ano openswan ano ano ano openswan ano ano ano openswan ano ano ano ano ne ano ano ano ano ne ne ano ne

8.3

60

Porovnání, hodnocení variant

8.3.2

Škálovatelnost

Tato vlastnost nabývá významu právě tehdy, pokud se jedná o větší VPN s více uživateli a předpokládá se přírůstek nových uživatelů. Škálovatelnost lze také definovat jako určitou složitost, která souvisí s činností při rozšiřování sítě. Stanovení úrovně škálovatelnosti u jednotlivých řešení vyžaduje přesnou znalost algoritmů a značné zkušenosti. Touto oblastí se již zabývá řada odborníků, díky kterým vznikl projekt VOLANS. Rozšiřitelnost se pak hodnotí podle způsobu distribuce tajných klíčů, nutnosti úprav směrovacích informací a editace konfiguračních souborů. Hodnocení variant zobrazuje tabulka č. 5, kdy se předpokládá N uživatelů. Tab. 5: Škálovatelnost VPN

PPTP L2TPD OpenVPN Tinc

Úprava konf. souborů N 2(N 2(N

Úprava Distribuce směr. tajných informací klíčů 2(N − 1) − 1) N −1 − 1) 1 1 2

Celková Náročnost náročnost s 10 uživateli N (5N − 2) 480 N (2, 5N ) 250 N (2N − 1) 190 N (4) 40

Výsledek závisí rovněž na použitých metodách nasazených v daném řešení. V případě standardního použití vykazuje nejlepší škálovatelnost Tinc. Naopak protokol PPTP dosahuje vysokých hodnot (značná náročnost), což by pro rozsáhlejší síť bylo zcela nevhodné nasazení. 8.3.3

Bezpečnost

Jedná se o základní kritérium, které má majoritní vliv na výběr specifického řešení. Na bezpečnost VPN lze nahlížet z několika hledisek: na jaké pracuje vrstvě, jakou oblast pokrývá, režim přenosu, které mechanismy zabezpečení podporuje, atd. Zřejmě nejlepším měřítkem pro porovnání bezpečnosti se jeví mechanismy autentizace, šifrování a otisku, které VPN umožňuje. Tyto algoritmy byly vysvětleny v teoretické části, proto zde nebudou dále vysvětlovány. Přehled o podporovaných protokolech zachycuje tabulka č. 6.

8.3

61

Porovnání, hodnocení variant

Tab. 6: Podporované protokoly VPN

PPTP Poptop OpenVPN Tinc L2TP IPSec

Ověřování PAP, CHAP, MS-CHAP, MS-CHAPv2, EAP-TLS X.509, Sdílený klíč RSA X.509, Sdílený klíč RSA, Kerberos

Šifrování MPPE

Integrita dat

Blowfish, DES, 3DES, EAS Blowfish DES, 3DES, AES

MD5, SHA SHA MD5, SHA

Z testovaných řešení se jeví jako nejbezpečnější L2TP/IPSec. Nabízí nejširší škálu osvědčených protokolů. IPSec navíc pracuje na nižší vrstvě a dokáže zabezpečit veškerý přenos síťové vrstvy. Implementace OpenVPN disponuje také kvalitními způsoby zabezpečení. Podpora X.509 certifikátů ji činí dobře použitelnou i v reálném provozu. K šifrování využívá knihovnu OpenSSL, která se považuje za poměrně bezpečnou. Projekt Tinc již má několik nedostatků, především v oblasti autentizace. I přes to se dá v některých případech s úspěchem realizovat. Zřejmě nejhorší možností v oblasti bezpečnosti považuji protokol PPTP (Poptop). Proprietrání šifrování MPPE většina odborníků považuje za nedostatečné, chybí zde prvky ověření integrity a možnost ověření uživatele jsou omezené. Zároveň je nutno podotknout, že i nejdokonalejší bezpečnostní mechanismy nemusí být zcela účinné, pokud se uživatelé neřídí pravidly a bezpečnostní politikou. Například volba nevhodných hesel, neopatrné vystavování tajných klíčů, hesel či certifikátů a další. 8.3.4

Výkon

Mezi nejvýznamnější charakteristiky patří bezesporu propustnost a odezva datové linky. Na měření těchto ukazatelů jsem nasadil grafický program Netdoppler. Vzhledem k netradičnímu měření agregace programem Netdoppler (posílá kromě jednotlivých paketů i toky paketů), bylo žádoucí použít i jiný program (iperf), aby nebyl výsledek příliš zkreslený. Navíc měl Netdoppler značné problémy při průchodu NATem u některých realizaci – L2TP/IPSec, PPTP u nichž vykazoval určité anomálie. Jak je uvedeno výše, měření bylo aplikováno ve dvou různých prostředí. První z nich představuje 100 Mbitovou LAN, která se vyznačuje vysokou propustností, rychlou odezvou, stabilitou a izolovaností od ostatních vlivů, které by mohly způsobovat rušení. Typickou vlastností VPN je vyšší režie přenosu, což způsobuje větší nároky na hardwarovou vybavenost. Z tohoto pohledu VPN značně zpomalují přenosy v rámci LAN, které jsou úměrné kvalitě technického vybavení. V odborných publikacích se uvádí maximální skutečné využití datové linky 100 Mbitové sítě asi kolem 70 až 77 % přenosové kapacity v závislosti na topologii sítě, kvalitě hardwarových komponent, výkonností stanic a dalších. Použité vybavení neodpovídá vysokým nárokům rychlých sítí (v tomto případě 100 Mbit), a proto jsou naměřené

8.3

Porovnání, hodnocení variant

62

hodnoty spíše ukazatelem režie jednotlivých řešení. Obecně platí čím větší režie, tím pomalejší propustnost. Tato skutečnost mě přinutila realizovat testy i v odlišném prostředí, kde by se vliv režie přenosu eliminoval. Jedná se o bezdrátovou podsíť. Jejím charakteristickým rysem je kolísavost, nestabilita, citlivost na rušení, pomalá odezva a menší propustnost asi od 80 Kbyt/s do 300 Kbyt/s. V tomto prostředí se při měření propustnosti Netdoppler jevil jako nevhodný nástroj (prokazoval nesmyslné výsledky), a proto byla použita jednoduchá utilita iperf. Tabulka č. 7 znázorňuje celkový přehled naměřených rychlostí jednotlivých řešení programem Netdoppler a Iperf v prostředí LAN. Podrobnější informace o provedených testech i s grafy se nacházejí v příloze A a B (str. 74). V tabulce číslo 8 je zachycena latence, která byla naměřena v lokální síti. Tab. 7: Naměřená propustnost v LAN Netdoppler OpenVPN PPTP TINC L2TP UDP TCP IPSec Pkt Pkts Pkt Pkts Pkt Pkts Pkts Pkts Pkts stream single stream single stream single single single single průměrná 8,86 3,25 2,12 1,03 0,33 1,40 1,17 0,97 0,44 minimální 8,09 3,09 0,51 0,34 0,26 0,37 1,10 0,94 0,32 maximální 8,99 3,42 2,98 1,81 0,52 1,79 1,20 0,98 0,77 celková prům. 4,76 1,08 0,50 1,17 0,97 0,44 Iperf Propustnost bez VPN OpenVPN PPTP TINC L2TP [MB/s] UDP TCP IPSec průměrná 6,79 1,05 0,76 1,27 0,86 0,91 minimální 6,63 1,04 0,62 1,19 0,84 0,9 maximální 7,02 1,06 0,86 1,3 0,95 0,91 Propustnost [MB/s]

bez VPN

Tab. 8: Naměřené odezva v LAN

Odezva bez VPN OpenVPN PPTP TINC L2TP [ms] UDP TCP IPSec průměrna 0,445 11,019 2,39 1,246 1,899 1,505 minimální 0,433 1,635 1,436 1,036 1,787 1,414 maximální 0,519 106,06 3,816 2,403 2,082 2,226

8.3

Porovnání, hodnocení variant

63

Výsledkům v prostředí bezdrátové sítě odpovídá tabulka č. 9. Tab. 9: Naměřený výkon v bezdrátové podsíti

Agregace [KB/s] bez VPN OpenVPN PPTP TINC L2TP UDP TCP IPSec průměrná 139 170 128 61 143 118 minimální 53 125 88 31 70 88 maximální 161 260 208 94 246 189 Odezva [ms] průměrná 17 30 27 21 35 23 minimální 5 6 6 5 7 5 maximální 65 115 155 70 160 86 Z naměřených hodnot v obou prostředí plyne několik zajímavých závěrů. V lokální síti se VPN považuje za brzdící mechanismus, který snižuje výkon. Nejen propustnost, ale i odezva je u VPN několikrát nižší. Poměrně vyrovnané a dostačující výsledky propustnosti prokazují OpenVPN (přes UDP port), Tinc a PPTP. Naopak u L2TP/IPSec a OpenVPN (přes TCP port) je agregace nižší, což je dáno větší režií přenosu. Odezva je ve všech realizací poměrně vyrovnaná, až na OpenVPN přes UDP. V naměřených hodnotách se objevují tři enormně vysoké hodnoty, které ovlivnily i průměrnou latenci. Tento jev přisuzuji hardwarovým odmlkám nebo zahlcením některých periferií. V bezdrátové síti se závěry poněkud změnily. Rozdíl mezi přímým spojením a VPN se značným způsobem eliminoval. Velice rychlou odezvu mají PPTP a L2TP/IPSec, zatímco Tinc a OpenVPN mírně zaostávají. U propustnosti jsou výsledky velice pozoruhodné. Některé implementace vykazují vyšší rychlost, než přímé spojení. Tento fakt je dán především typem prostředí a způsobem měření. V praxi je ovšem typické, že rychlost VPN nepřesáhne hodnoty reálného spoje. OpenVPN spolu s Tinc považuji za nejrychlejší variantu; PPTP naopak za nejpomalejší. Výsledky nevyjadřují přesné hodnoty konkrétních implementací, protože existuje příliš ovlivňujících faktorů. Proto je také potřeba naměřené hodnoty chápat jako určitá doporučení, kterými by se měl realizátor řídit. Jako nerychlejší řešení vyšlo v tomto testu OpenVPN při použití portu UDP, které má ovšem o něco delší dobu odezvy. Při porovnání výkonnosti hraje i určitou roli stabilita. Nedostatkem všech VPN řešení je fakt, že využívají existující komunikační kanály, na kterých jsou zcela závislá. Při výpadku fyzické linky tedy dojde vždy k přerušení VPN spojení. Jedinou možností jak zmírnit tyto výpadky je automatická obnova sítě. V tomto ohledu prokazuje nejlepší schopnosti OpenVPN.

8.4

Výběr řešení

8.3.5

64

Použitelnost

I nejkvalitnější software se nemusí prosadit, pokud má silně omezenou oblast použití. Z mých zkušeností jsem odvodil závěry o vhodnosti nasazení softwaru v konkrétních situacích. Za nejvíce použitelnou aplikaci považuji OpenVPN. Komunikace běží pouze na jediném portu, který lze velice snadno nastavit. Tím se podstatně snižují problémy při průchodu NATem, Firewallem, či dalšími prvky bránícím v cestě. Stačí jen povolit libovolný port. Snadná instalace, modifikovatelnost, spustitelnost a vysoká bezpečnost předurčuje OpenVPN nejen do oblastí domácích VPN, ale i nasazení v podnikovém prostředí. Součástí je i podpora uživatelů typu road-warrior (tzv. obchodních cestujících). Tito uživatelé jsou charakterističtí neznámou IP adresou, která se může neustále měnit – vychází z cestování pracovníků, kdy se připojují z různých míst. IPSec již prokazuje určité problémy při průchodu NATem (požaduje více portů) a jeho implementace není tak snadná, jako v případě OpenVPN. Mezi výhody patří vysoká bezpečnost, podpora road-warrior a použití standardního klienta ve Windows (není třeba instalovat další software). IPSec se svou charakteristikou hodí nejvíce na propojení (vytvoření tunelu) dvou firemních sítí. Tinc obsahuje určité bezpečností nedostatky, ale jeho zavedení je snadné a velice se podobá OpenVPN. Z toho důvodu ho považuji jako vhodné řešení pro domácí účely – herní sítě apod. PPTP bych nasadil pouze pro testovací účely či krátkodobou komunikaci. Tento protokol je již značně zastaralý a nedrží s ostatními implementacemi krok. Za jediné pozitivum označuji nativního klienta ve Windows. Kromě nedostatečného zabezpečení má protokol i problémy s NATem.

8.4

Výběr řešení

Před samotnou realizací konkrétního VPN řešení hraje klíčovou roli informovanost. Proto jsem provedl potřebné testy, abych porovnal nejvhodnější varianty. Také jsem prostudoval mnoho manuálů a diskuzí na Internetu a na základě těchto zkušeností jsem usoudil za nejvhodnější implementaci OpenVPN. Hlavní motivy volby OpenVPN: • řešení podporuje požadované platformy (Unix a Linux), • jednoduchá konfigurace a implementace, • podpora X.509 certifikátů, které považuji za velice bezpečné, • osvědčené řešení, charakteristické minimální chybovostí, • slušné výsledky výkonnosti, • vysoká informovanost (mnoho návodů a diskuzí na webu), • přijatelná škálovatelnost, • řešení je zdarma, • podpora uživatelů typu road-warrior, • široká použitelnost a kompatibilita.

8.5

8.5

Realizace VPN ve společnosti

65

Realizace VPN ve společnosti

Při realizaci OpenVPN v podniku jsem vycházel ze svých zkušeností získaných při testování. Ve většině případů se implementace shoduje s testovanou verzí, kterou práce již podrobně popsala v předcházející kapitole. Také z toho důvodu, budu popisovat pouze ty části, které se nějakým způsobem odlišují. Pro VPN síť byl stanoven rozsah IP adres 172.16.0.0/16, který se považuje ve firmě za nekonfliktní. Zvolený port VPN odpovídá defaultní hodnotě 1194, který se povolil na firewallu. Bezpečností pravidla společnosti omezují fyzický přistup k serveru na minimum. Proto se veškerá konfigurace na serveru odehrávala přes chráněný SSH kanál. Přístup se odehrával v rámci lokální sítě, a proto se požadavek poslal na lokální adresu serveru 192.168.1.2. SSH server běží na portu 700, což není tradiční řešení. Důvodem změny portu z 22 na 700 byl značný zájem útočníků na známý port. Komunikace klienta probíhala přes jednoduchou utilitu putty. Po nezbytné autorizaci se naváže spojení a uživatel má schopnost ovládat server pomocí příkazů (jako by seděl přímo u serveru). Drobná změna se týká také generování certifikátů, kde byl přidán parametr extensions TLS. Tento příkaz specifikuje certifikát pro konkrétní účel. Pokud by parametr nebyl v OpenSSL obsažen, mohl by vlastník použít certifikát pro více služeb a tím by došlo k porušení bezpečnosti. S ohledem na zabezpečení informací bylo nutné stanicím v lokální síti znemožnit přístup k Internetu v případě, kdy se připojí do VPN. To bylo realizováno pomocí routingu. Konfigurační soubor serveru: proto udp port 1194 dev tun ;dev-node MyTap ca /etc/openvpn/cacert.pem cert /etc/openvpn/akti.pem key /etc/openvpn/akti.pem dh /etc/openvpn/dh1024.pem server 172.16.0.0 255.255.255.0 ifconfig-pool-persist ipp.txt ;server-bridge 10.8.0.4 255.255.255.0 10.8.0.50 10.8.0.100 push "route 192.168.1.0 255.255.255.0" ;push "route 192.168.20.0 255.255.255.0" ;push "redirect-gateway" push "dhcp-option DNS 192.168.1.2" ;push "dhcp-option WINS 10.8.0.1" ;client-to-client ;duplicate-cn keepalive 10 120

8.5

Realizace VPN ve společnosti

tls-auth /etc/openvpn/ta.key 0 # This file is secret cipher BF-CBC # Blowfish (default) cipher AES-128-CBC # AES ;cipher DES-EDE3-CBC # Triple-DES comp-lzo max-clients 100 user nobody group nobody persist-key persist-tun status openvpn-status.log log /var/log/openvpn.log ;log-append openvpn.log verb 3 ;mute 20

Konfigurační soubor klienta (z Internetu): client dev tun ;dev-node MyTap proto udp remote 83.240.26.178 1194 ;remote my-server-1 1194 ;remote my-server-2 1194 ;remote-random resolv-retry infinite nobind ;user nobody ;group nobody persist-key persist-tun ca cacert.pem cert klient.pem key klient.key ;ns-cert-type server tls-auth ta.key 1 ;cipher x cipher BF-CBC cipher AES-128-CBC comp-lzo verb 3

# Blowfish (default) # AES

66

8.5

Realizace VPN ve společnosti

67

;mute 20

Zálohování dat V situaci, kdy se pracuje s důležitými podnikovými informacemi, je nutné zajistit i jejich zálohování. Při poruše hardwaru nebo softwaru někdy dojde ke ztrátě dat, což může mít bez kvalitního zálohování trvalý charakter. Intenzita zálohování závisí na charakteru podniku a informací. Pravidelné denní zálohování snižuje riziko ztráty dat. Proto jsem se také rozhodl zavést zálohovací mechanismus i do VPN sítě, kde jsou výpadky díky využívaným veřejným linkám poměrně běžné. Jako vhodný nástroj pro zálohování se jeví freeware software Cobian Backup. U daného software jsou splněny základní podmínky, které jsem kladl na zálohovací software, a to jsou přírůstkové zálohy, kdy jsou zálohovány pouze soubory, které byly změněny od poslední zálohy. Tudíž je přenášeno minimální množství dat a tím je splněn další požadavek na firemní síť, kterým je minimální zátěž sítě. Software disponuje pěkným grafickým rozhraním a nabízí širokou škálu možností. Lze si vybrat konkrétní soubor, adresář nebo celý obsah disku a určit cíl archivace. Cobian Backup umí i zálohovaná data zašifrovat několika algoritmy (DES, RSA, Blowfish), komprimovat, případně opatřit archiv heslem. Jak již bylo uvedeno, aplikace nabízí zálohování celého objemu dat nebo jen části (přírůstku, rozdílu). Utilita může být spuštěna i jako proces. Zálohování lze zahájit ručně, nebo automaticky podle nějakého podmětu (nějaká činnosti, určitý čas). Snímek programu Cobian zachycuje obrázek č. 14.

Obr. 14: Zálohovací program Cobian Backup

8.6

Hodnocení implementace

68

Program Cobian Backup byl instalován na většinu stanic, kde byl spuštěn jako proces. Zálohování se ukládá na síťový disk, který má kapacitu 500 GB. Počáteční zálohování bylo časově náročnější, ovšem následný provoz již pracuje plynule (ukládá se pouze přírůstek). Doprava certifikátů – webová aplikace Určité problémy mohou nastat při „dopravěÿ certifikátů a tajných klíčů na konkrétní stroje. Z efektivního hlediska se všechny certifikáty vytvářely a podepisovaly na jednom stroji, kde byla přímá podpora OpenSSL (konkrétně na serveru) a posléze se rozmístily do příslušných počítačů pomocí běžného přenosového média – USB Flash disk. Aby byla zachována vysoká bezpečnost, musí mít každý stroj vlastní certifikát. V samotném OpenVPN pak nesmí být v konfiguračním souboru parametr duplicatecn, který povoluje stejné certifikáty na více strojích. Při rozšiřování sítě pak nastává problém, kdy uživatel není v blízkosti a potřebuje získat požadované certifikáty a klíč. Taková situace obvykle vede k problémům a dochází k různým nesrovnalostem – špatnému klíči, nevhodné přenosové médium apod. Z tohoto důvodu jsem vytvořil webovou aplikaci, která zajišťuje tvorbu a dopravu certifikátů uživatelům, kteří mají požadované oprávnění (znají heslo). Testovací aplikce se nachází na adrese akela.mendelu.cz/~xvichta. Uživatel, který zná přístupové heslo si může vygenerovat potřebný certifikát, který se rovnou podepíše certifikační autoritou. Potřebné soubory se odešlou klientovi na e-mail a dojde upozornění správci. Program umožňuje i přehledný výpis v tabulce, kde správce vidí vystavené certifikáty seřazené podle času (více viz. příloha D, str. 86). Aplikace vyžaduje server, kde běží php a OpenSSL. Rovněž musí být v php povolená funkce system umožňující přístup do OS. Bohužel se nedávno na serveru akela tato funkce zakázala, proto je testování této aplikace velice omezené. Generování ani podepisování nelze uskutečnit, proto jsem na server umístil již vytvořené soubory, které se odešlou uživateli na e-mail. Pokud by se aplikace nahrála na jiný server s požadovanou podporou (např. server A. KTI), vše by fungovalo. Pro praktické nasazení je potřeba několik drobných změn. Buď by se vytvořené soubory nejdříve odeslaly správci, který by si ověřil jejich pravost a v kladném případě by je přeposlal uživateli, nebo by si potřebné certifikáty správce generoval sám a přeposílal je uživatelům. V obou případech alikace přináší výhody v podobě vyšší bezpečnosti, přehlednosti, jednoduchosti a rychlosti.

8.6

Hodnocení implementace

OpenVPN bylo realizováno v podniku A. KTI přibližně před půl rokem. Za tuto dobu nebyly zaznamenány žádné významnější problémy. Komunikace přes UDP port prokázala přibližně o 30 % vyšší propustnost než v případě TCP portu a odezva je v obou variantách poměrně vyrovnaná. Na 2 Mbitové lince se průměrná rychlost pohybuje kolem 150-180 KB/s, což představuje přibližně 70 % využití linky. Výkon

8.6

Hodnocení implementace

69

VPN ovlivňuje i více současně připojených uživatelů. Vzácné výpadky spojení se týkají nejčastěji externích klientů, což je důsledkem nekvalitního internetového připojení. Z bezpečnostního hlediska nebyly zaznamenány žádné nedostatky, a proto lze celkově implementaci OpenVPN v podniku hodnotit jako úspěšnou. V rámci hodnocení projektu je žádoucí uvést i přínosy, které plynou společnosti z realizace a zdůvodňují tak rozhodnutí nasadit implementaci. Obecně se přínosy rozdělují na kvantifikovatelné a nekvantifikovatelné. Kvantifikovatelné výnosy se dají vyjádřit v peněžní podobě a to buď přímo a nebo nepřímo. Nekvantifikovatelné výnosy nelze vyčíslit a nebo by to bylo příliš obtížné. I přes to se mohou nějakým způsobem projevit na kvantifikovatelných přínosech. Do měřitelných přínosů patří především sdílení podnikových zdrojů, které by si jinak zaměstnanec musel opatřit. V tomto případě se jedná o: • síťovou tiskárnu, • plotter, • sdílený disk, • software (grafické nástroje pro práci) – dostupné licence. Využívání firemních zdrojů je typické pro lokální síť, ovšem v případě zaměstnance, který nemá podnikovou LAN v dosahu, by každé rozšíření nového uživatele stálo společnost obrovské peníze. Nepřímo přináší VPN i zvýšení efektivity práce (zaměstnanci mohou pracovat z různých míst v libovolném čase – z domova, z pracovních cest, apod.) a snížení nákladů (kromě úspory za síťové prostředky dochází i k ušetření za pracovní prostor – v práci není potřeba tolik stanic, menší spotřeba el. proudu, atd.). Z nekvantifikovatelných výhod pramení komfort, který VPN přináší. Zaměstnanci mohou mít pružnou pracovní dobu, protože se připojují z domu, kde získají vše potřebné. Také obchodní partneři mnohdy ocení nadstandardní služby a tím podnik získá dobré jméno.

9

9

ZÁVĚR

70

Závěr

Cílem mé práce bylo realizovat virtuální privátní síť, která nejlépe splňovala požadavky kladené podnikem s ohledem na výsledky a zkušenosti získané při testování. Při zkoumání způsobů zabezpečení jsem získal potřebné teoretické poznatky, které jsem následně uplatnil v praktické části. Aby byla realizace úspěšná, musí jí předcházet testovací fáze, která pomáhá odhalit nedostatky řešení. U virtuálních privátních sítí, které umožňují přístup k důležitým strategickým zdrojům podniku, je opatrnost obzvláště důležitá. Proto jsem se rozhodl nejdříve provést testy nejvhodnějších variant a na základě dosažených výsledků vybrat nejlepší z nich. Tato fáze byla nejdelší a také nejproblematičtější částí práce. Zprovoznění každého řešení mě stálo značné úsilí a čas strávený hledáním chyb. Na druhou stranu jsem pochytil cenné praktické vědomosti. Získané výsledky mi pak napomohly při výběru konkrétního kandidáta. Samotná realizace ve firmě pak proběhla relativně rychle a bezproblémově, kdy jsem využíval všech získaných praktických i teoretických zkušeností. Zabudovanou VPN ve společnosti považuji za bezpečnou a s ohledem na současnou situaci také nejvhodnější. I přes uspokojivé výsledky se musí brát v úvahu neustalé riziko zneužití či napadnutí útočníkem a příjmout taková opatření, která by tyto hrozby minimalizovala. Doporučuji především sledovat situaci v oblasti bezpečnosti a předcházet novým typům útokům inovacemi zastaralých bezpečnostních mechanismů. Závěry, kterých jsem dosáhl mají obecnou platnost a mohou sloužit i jiným realizátorům jako zdroj inspirace. VPN jsou v současnosti na vzestupu a do budoucna se očekává jejich nasazení v téměř všech podnikových sítí, protože jsou přínosy pramenící z implementace mnohem vyšší než náklady. Navíc je zavedení VPN ve srovnání s jinými realizacemi levné a mohou si to dovolit i malé podniky. Pro případ, kdyby se někdo potýkal s obdobnou situací a chtěl by realizovat OpenVPN, vytvořil jsem balíček, který obsahuje všechny potřebné moduly včetně návodu. Manuál je součástí přílohy a potřebné aplikace jsou dodávány společně s prací (viz. příloha C, str. 83). Při tvorbě této práce jsem načerpal mnoho nových zkušeností a poznatků, které považuji za největší přínos. Dílo mi rozšířilo obzory a doplnilo cenné informace. Právě v oblasti počítačových sítí bych chtěl nadále působit a hodnotím proto práci jako velice přínosnou pro můj další odborný rozvoj.

10

10

LITERATURA

71

Literatura

Bigelow, S. J. Mistrovství v počítačových sítích: správa, konfigurace, diagnostika a řešení problémů. 1. vyd. Brno: Computer Press, 2004. 990 s. ISBN 80-2510178-9. Business communication s. r. o. Informace o certifikátech: Co jsou digitální certifikáty? [online]. 2003-2008 [cit. 2008-05-10]. Text v češtině. Dostupný z WWW: . Cameron, J. Red Hat pptpd HOWTO [online]. 2007 [cit. 2008-05-12]. Text v angličtině. Dostupný z WWW: . Červinka, M. IPSec v kernelu 2.6 [online]. 2004 [cit. 2008-05-05]. Text v češtině. Dostupný z WWW: . ISSN 1214-126. Dostálek, L. Velký průvodce protokoly TCP/IP: Bezpečnost. 2. vyd. Praha: Computer Press, 2003. 571 s. ISBN 80-7226-849-X. Hladík, R. OpenVPN – VPN jednoduše [online]. 2004 [cit. 2008-01-05]. Text v češtině. Dostupný z WWW: . ISSN 1212-8309. Kára, M. Jak na OpenSSL [online]. 2003 [cit. 2008-01-05]. Text v češtině. Dostupný z WWW: . ISSN 1212-8309. Khanvilkar, S., Khonkhar, A. Experimental evaluations of Open-Source: Linux-based VPN Solutions [online]. 2007 [cit. 2008-05-11]. Text v angličtině. Dostupný z WWW: <mia.ece.uic.edu/ papers/publications/ICCCN presentationv2.ppt>. Martin B. Creating a VPN with tinc [online]. 2008 [cit. 2008-05-11]. Text v angličtině. Dostupný z WWW: . OpenVPN, Inc. HOWTO [online]. 2002-2008 [cit. 200803-15]. Text v angličtině. Dostupný z WWW: . Pužmanová, R. TCP/IP v kostce. 1. vyd. České Budějovice: Kopp, 2004. 607 s. ISBN 80-7232-236-2. Sliepen G. Tinc: manual [online]. 2006 [cit. 2008-04-25]. Text v angličtině. Dostupný z WWW: . Spenneberg R. IPsec HOWTO [online]. 2003, 2006 [cit. 2008-05-12]. Text v češtině. Dostupný z WWW: . Šťastný, P. Zprovoznění VPN pomocí protokolu PPTP [online]. 2007 [cit. 2008-05-12]. Text v češtině. Dostupný z WWW: .

10

LITERATURA

72

Touchwood. Jak na OpenVPN: minimanuál [online]. 2006 [cit. 2008-04-14]. Text v češtině. Dostupný z WWW: .

Přílohy

A

STATISTIKY MĚŘENÍ – ODEZVA

A

74

Statistiky měření – odezva

Tab. 1: Naměřená odezva v LAN

Měřený pokus 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 prům. max. min.

Latence [ms] LAN bez OpenVPN OpenVPN PPTP TINC L2TP VPN UDP TCP Poptop IPSec 0,456 11,882 3,737 1,586 1,787 1,466 0,443 2,071 3,195 1,036 1,887 1,482 0,434 2,195 1,845 1,108 1,89 1,604 0,442 1,748 2,819 1,381 1,848 1,436 0,44 1,655 1,571 1,101 1,857 1,421 0,446 1,69 2,986 1,123 1,972 1,472 0,442 4,878 1,724 2,403 1,994 1,478 0,439 2,772 3,034 1,385 1,841 1,454 0,433 17,546 1,766 1,916 2,01 1,45 0,519 4,075 3,178 1,121 1,952 1,525 0,444 52,038 1,834 1,587 1,814 1,441 0,443 4,353 1,436 1,187 1,88 1,456 0,439 14,531 1,723 1,222 1,853 1,49 0,433 2,902 3 1,205 1,886 1,5 0,439 3,003 1,73 1,132 1,93 1,76 0,445 2,84 2,813 1,136 2,049 1,436 0,444 7,4 1,83 1,115 1,834 1,437 0,443 2,866 2,801 1,113 2,082 1,571 0,436 5,973 1,737 1,1 1,908 1,467 0,456 56,349 1,789 1,128 1,873 1,487 0,456 1,683 1,909 1,205 1,947 1,437 0,46 2,817 3,514 1,115 1,847 1,508 0,434 1,635 1,828 1,114 1,93 1,44 0,433 106,063 2,803 1,133 1,887 1,433 0,435 1,642 1,72 1,083 1,922 1,517 0,443 3,252 2,899 1,13 1,861 2,226 0,446 1,964 1,928 1,124 1,807 1,424 0,436 2,775 2,792 1,114 1,825 1,414 0,455 1,702 1,929 1,1 1,835 1,458 0,444 4,283 3,816 1,174 1,96 1,449 0,445 11,018 2,390 1,246 1,899 1,505 0,519 106,063 3,816 2,403 2,082 2,226 0,433 1,635 1,436 1,036 1,787 1,414

A

STATISTIKY MĚŘENÍ – ODEZVA

Obr. 1: Latence bez VPN

Obr. 2: Latence OpenVPN přes UDP

75

A

STATISTIKY MĚŘENÍ – ODEZVA

Obr. 3: Latence OpenVPN přes TCP

Obr. 4: Latence PPTP – Poptop

76

A

STATISTIKY MĚŘENÍ – ODEZVA

Obr. 5: Latence TINC

Obr. 6: Latence L2TP/IPSec

77

B

B

STATISTIKY MĚŘENÍ – PROPUSTNOST

Statistiky měření – propustnost

Tab. 2: Naměřená propustnost v LAN – první část Propustnost [MB/s] Měřený LAN bez OpenVPN pokus VPN UDP TCP Pkt Single Pkt Single Pkt Single Stream Pkts Stream Pkts Stream Pkts 1 8,828 3,130 2,435 1,104 0,262 1,703 2 8,878 3,132 2,701 1,098 0,368 1,695 3 8,841 3,133 1,137 0,996 0,308 0,472 4 8,944 3,156 2,642 0,460 0,279 1,738 5 8,898 3,391 0,872 0,658 0,415 1,595 6 8,954 3,312 1,338 0,799 0,359 1,558 7 8,839 3,326 1,608 0,392 0,305 1,638 8 8,930 3,195 2,443 1,430 0,267 1,637 9 8,861 3,346 2,624 0,391 0,269 0,931 10 8,916 3,170 2,925 1,731 0,326 1,771 11 8,890 3,148 2,426 1,078 0,264 0,520 12 8,989 3,375 2,248 0,666 0,298 0,861 13 8,907 3,291 0,737 0,337 0,359 1,630 14 8,921 3,130 2,592 0,458 0,296 1,786 15 8,890 3,384 2,537 1,239 0,273 1,577 16 8,868 3,406 2,471 0,882 0,376 1,712 17 8,878 3,112 1,690 1,479 0,344 0,421 18 8,887 3,314 2,711 0,509 0,292 1,579 19 8,091 3,353 2,327 1,484 0,418 1,642 20 8,882 3,359 2,239 0,603 0,355 1,752 21 8,916 3,416 1,466 1,729 0,347 0,374 22 8,820 3,202 2,101 1,493 0,262 1,740 23 8,889 3,250 2,213 0,792 0,376 1,688 24 8,802 3,131 2,563 1,611 0,403 0,839 25 8,921 3,235 0,828 0,926 0,523 1,645 26 8,870 3,357 2,980 1,794 0,408 1,775 27 8,840 3,093 0,513 0,980 0,299 0,589 28 8,906 3,208 2,876 1,814 0,302 1,652 29 8,904 3,326 2,449 0,459 0,266 1,685 30 8,911 3,297 2,913 1,595 0,381 1,733 prům. 8,862 3,256 2,120 1,033 0,333 1,398 min. 8,091 3,093 0,513 0,337 0,262 0,374 max. 8,989 3,416 2,980 1,814 0,523 1,786 celková prům. 4,758 1,084 0,500

78

B

STATISTIKY MĚŘENÍ – PROPUSTNOST

Tab. 3: Naměřená propustnost v LAN – druhá část

Měřený pokus

Propustnost [MB/s] PPTP TINC

L2TP IPSec Pkt Single Pkt Single Pkt Single Stream Pkts Stream Pkts Stream Pkts 1 * 1,190 * 0,975 * 0,672 2 * 1,186 * 0,970 * 0,666 3 * 1,177 * 0,983 * 0,765 4 * 1,204 * 0,979 * 0,639 5 * 1,176 * 0,980 * 0,605 6 * 1,168 * 0,975 * 0,364 7 * 1,184 * 0,973 * 0,341 8 * 1,118 * 0,976 * 0,422 9 * 1,179 * 0,974 * 0,453 10 * 1,199 * 0,976 * 0,432 11 * 1,189 * 0,939 * 0,348 12 * 1,165 * 0,983 * 0,329 13 * 1,199 * 0,975 * 0,465 14 * 1,173 * 0,967 * 0,369 15 * 1,180 * 0,970 * 0,401 16 * 1,196 * 0,976 * 0,377 17 * 1,177 * 0,961 * 0,462 18 * 1,186 * 0,971 * 0,353 19 * 1,186 * 0,968 * 0,352 20 * 1,113 * 0,973 * 0,386 21 * 1,186 * 0,978 * 0,318 22 * 1,171 * 0,973 * 0,399 23 * 1,122 * 0,979 * 0,373 24 * 1,176 * 0,972 * 0,398 25 * 1,204 * 0,974 * 0,387 26 * 1,147 * 0,965 * 0,367 27 * 1,186 * 0,949 * 0,366 28 * 1,175 * 0,956 * 0,385 29 * 1,095 * 0,949 * 0,562 30 * 1,169 * 0,959 * 0,317 prům. * 1,173 * 0,970 * 0,436 mini. * 1,095 * 0,939 * 0,317 max. * 1,204 * 0,983 * 0,765 celková prům. 1,173 0,970 0,436

79

B

STATISTIKY MĚŘENÍ – PROPUSTNOST

Obr. 7: Propustnost bez VPN

Obr. 8: Propustnost OpenVPN přes UDP

80

B

STATISTIKY MĚŘENÍ – PROPUSTNOST

Obr. 9: Propustnost OpenVPN přes TCP

Obr. 10: Propustnost PPTP – Poptop

81

B

STATISTIKY MĚŘENÍ – PROPUSTNOST

Obr. 11: Propustnost TINC

Obr. 12: Propustnost L2TP/IPSec

82

C

C

APLIKAČNÍ BALÍČEK

83

Aplikační balíček

*************** * Úvod, obsah * *************** Pro případ, kdyby se někdo potýkal s~obdobnou situací a chtěl by realizovat VPN (OpenVPN), vytvořil jsem balíček, který obsahuje všechny potřebné moduly. Obsah balíčku: -------------openvpn-2.0_rc18-gui {openvpn pro Windows} lzo-1.08.tar {komprimační knihovna} Manuál {textový dokument s~návodem} Klient {složka s~testovacími soubory pro klienta - obsahuje certifkáty a konfigurační soubor} Server {složka s~testovacími soubory pro server - obsahuje certifkáty a konfigurační soubor} openssl-0.9.8e.tar {openssl pro linux} openvpn-2.0.9.tar {openvpn pro linux}

*********************** * Konfigurace serveru * *********************** pozn. konfigurace serveru je určená pro Linux! Nejprve je nezbytné naistalovat všechny potřebné aplikace. Před tím si zkontrolujte, zda-li některé programy již nemáte v~systému (nejčastěji openSSL již bývá standardně součástí jádra). Postup instalace jednotlivých balíčků: Rozbalení archívů: tar -xjf openssl-0.9.8e.tar tar -xjf openvpn-2.0.9.tar tar -xjf lzo-1.08.tar Instalace z~jednotlivých adresářů: ./configure make make install Po té se do stanovénoho adresáře umístí všechny potřebné soubory: -cacert.pem -server.crt -key.pem -dh1024.pem

C

APLIKAČNÍ BALÍČEK

84

-server.conf Veškerá nastavení se odehrává v~konfiguračním souboru server.conf, který rovněž přidávám do balíčku. Různé varianty a možnosti si může uživatel nastavit podle manuálů vyskytujících se na Internetu. Spuštění programu openvpn se nastavuje příkazem (musí se připojit i konfigurační soubor): openvpn --config /etc/openvpn/server.conf Nebo můžete z~adresáře, kde máte openvpn: ./openvpn --config server.conf

**************************** * Tvorba X.509 certifikátů * **************************** Vlastní tvorba certifikátů je nezbytná činnost k~úspěšnému propojení počítačů. Podle umístění adresáře s~openSSL (v~mém případě /etc/ssl) zkontrolujte adresářovou strukturu, která musí mít následující podobu: /etc/ssl/demoCA /etc/ssl/certs /etc/ssl/crl /etc/ssl/newcerts /etc/ssl/demoCA/private Požadovaná adresářová struktura lze také ovlivnit přenastavením konfiguračního souboru openSSL. Následně vytvořte dva sobory, které evidují vydané certifikáty: touch /etc/ssl/demoCA/index.txt echo 01 >/etc/ssl/demoCA/serial 1) Vytvořte certifikační autoritu (heslo a klíč): openssl req -new -x509 -nodes -out cacert.pem -keyout cakey.pem -days 1098 2) Klíč certifikační autority přesuňte do /etc/ssl/demoCA/privates. 3) Vytvořte jednotlivé certifikáty pro server (request.pem, key.pem), klienta 1 (request1.pem, client.key), klienta 2 (request2.pem, client2.key), ... openssl req -new -nodes -out request.pem -keyout key.pem -days 1098 openssl req -new -nodes -out request1.pem -keyout client.key -days 1098 openssl req -new -nodes -out request2.pem -keyout client2.key -days 1098 4) Podepiště všechny vytvořené certifikáty certifikační autoritou:

C

APLIKAČNÍ BALÍČEK

85

openssl ca -in request.pem -out server.crt openssl ca -in request1.pem -out client.crt openssl ca -in request2.pem -out client2.crt 5) Pro server vytvořte D-H pro výměnu klíčů: openssl dhparam -out dh1024.pem 1024 6) Umístěte vytvořené soubory na požadovaná místa.

*********************** * Konfigurace klienta * *********************** pozn. konfigurace klienta je určené pro Windows!

1) Přiložený soubor openvpn-2.0_rc18-gui nainstalujete do systému (doporučuji zanechat defaultní nastavení). Při instalaci se zobrazí upozornění na nekompatibilitu (je dáno komerční politikou Microsoft) kterou můžete ingorovat. 2) Do adresáře config (defaultně C:\Program Files\OpenVPN\config) vložte tyto soubory: pozn. soubor client.ovpn se vytvoří sám, je třeba ho přepsat nebo editovat! -konfigurační soubor (client.ovpn) -soukromý klíč (client.key) -certifikát klienta (client.crt) -certifikát certifikační autority (cacert.pem) Všechny tyto soubory je nezbytné vytvořit. První z~nich nakonfigurováním konkrétních potřeb sítě, zbývájící tři soubory pomocí openSSL. Pro vyzkoušení přikládám testovací soubory, avšak nedoporučuji používat jako konečné řešení. U~konfiguračního souboru je nejdůležitější parametr remote, který určuje na jakou IP adresu se budete připojovat (server). V~ukázkovém souboru je stanovena vnitří adresa serveru A. KTI, proto pro vlastní potřebu musíte změnit adresáta. 3) Na hlavním panelu se vám vytvoří ikona OpenVPN GUI (pokud ne, musíte aplikaci spustit). Po té stačí dvojklik nebo pravým tlačítkem a zvolit connect. Edit config umožňuje nejrychlejším způsobem měnit parametry spojení.

D

WEBOVÁ APLIKACE – DOPRAVA CERTIFIKÁTŮ

D

86

Webová aplikace – doprava certifikátů

Pro přístup do systému je nezbytné znát potřebná hesla. Ke zkušebním účelům jsou stanovená hesla pro uživatele: zkouška (pro generování certifikátů) a pro správce: root (např. pro výpis). Aplikace je vytvořena v programovacím jazyku php s využitím objektového přístupu. Skládá se z několika souborů, z nich většina zajišťuje potřebný vzhled. Nejdůležitějším místem jsou openssl příkazy, posílání souborů na e-maily a práce s databází. Tyto funkce jsou zachyceny v následujících částech zdrojových kódů: sloupce,",")+1; $select="select $this->sloupce from $this->tabulka"; $vysl1=OCIParse($this->spoj,$select); $v=OCIExecute($vysl1); while (ocifetchinto($vysl1,&$result,OCI_RETURN_NULLS)){ echo ""; for ($i=0; $i<$delka; $i++) { echo ""; echo $result[$i]; echo ""; } echo ""; } } } //Objekt určený pro práci s OpenSSL - generování, podepsání, konverze, smazání. class certifikaty { var $heslo; var $login; var $lokace; function generuj() { system("openssl req -new -nodes -text -days 720 -keyout key.pem -out request.pem -subj /C=CZ/ST=ČR/L=$this->lokace/O=A.KTI,s.r.o./CN=$this->login

D

WEBOVÁ APLIKACE – DOPRAVA CERTIFIKÁTŮ

-batch",$retval); } function podepis() { system("openssl ca -batch -in request.pem -out client.crt",$retval); } function konverze() { system("openssl pkcs12 -export -in client.crt -inkey key.pem -out cert.p12 -nodes -passout pass:$this->heslo",$retval); } function smaz() { system("rm system("rm system("rm system("rm

request.pem",$retval); key.pem",$retval); client.crt",$retval); cert.p12",$retval);

} } ?> heslo=$_POST[heslo]; $certifikat->lokace=$_POST[lokace]; $certifikat->login=$_POST[login]; $certifikat->generuj(); $certifikat->podepis(); $certifikat->konverze(); ?>

87

D

WEBOVÁ APLIKACE – DOPRAVA CERTIFIKÁTŮ

$mail->From = "akela.mendelu.cz/~xvichta"; $mail->FromName = "Lubomír Vichta"; $mail->AddAddress($_POST[mail],"Certifikaty"); $mail->AddReplyTo($_POST[mail],"Information"); $mail->WordWrap = 50; $mail->AddAttachment("key.pem"); $mail->AddAttachment("client.crt"); $mail->AddAttachment("./demoCA/cacert.pem"); $mail->AddAttachment("cert.p12"); $mail->IsHTML(true); $mail->Subject $mail->Body

= =

$mail->AltBody

=

"Certifikáty"; "Zasíláme vygenerované soubory. Návod najdete na akela.mendelu.cz/~xvichta"; "Zasíláme vygenerované soubory. Návod najdete na akela.mendelu.cz/~xvichta";

if($mail->Send()) { exit; }

$mail = new phpmailer(); //odeslání upozornění správci $mail->From = "akela.mendelu.cz/~xvichta"; $mail->FromName = $_POST[jmeno]; $mail->AddAddress("[email protected]","Certifikaty"); $mail->AddReplyTo($_POST[mail],"Information");

$mail->Subject $mail->Body $mail->AltBody

= = =

"Certifikáty"; "Generování certifikátů uživatelem: $_POST[jmeno]. "; "Nový ceritfikát vygenerovaný uživatelem: $_POST[jmeno]. ";

if($mail->Send()) { exit; } //odstranění vytvořených souborů $certifikat->smaz(); ?> spoj=$spojeni;

88

D

WEBOVÁ APLIKACE – DOPRAVA CERTIFIKÁTŮ

$vypis->tabulka=’logy’; $vypis->sloupce=’to_char(cas,\’HH:MI DD.MM.RRRR\’),jmeno,id,telefon,mail’; $vypis->proved(); ?>

Obr. 13: Formulář pro tvorbu certifikátů

89

D

WEBOVÁ APLIKACE – DOPRAVA CERTIFIKÁTŮ

Obr. 14: Výpis logů generování certifikátů

90