Možnosti šifrované komunikace v prostředí MS Windows 7

MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY

Možnosti šifrované komunikace v prostředí MS Windows 7 BAKALÁŘSKÁ PRÁCE

Stanislav Špaček

Brno, jaro 2014

Prohlášení Prohlašuji, že tato práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal a nebo z nich čerpal, v práci cituji s uvedením úplného odkazu na příslušný zdroj.

Poděkování Tímto bych chtěl poděkovat RNDr. Marku Kumpoštovi, PhD. za vedení mé bakalářské práce. Zároveň děkuji Mgr. Karolovi Kubandovi za jeho rady, čas věnovaný konzultacím a pomoci při vypracování praktické části.

Shrnutí Cílem práce je prozkoumání, porovnání a doporučení možností šifrovaného VPN spojení pomocí protokolů nativně podporovaných operačním systémem Microsoft Windows 7. První část práce se zabývá autentizačními a kryptografickými algoritmy, nezbytnými k ustavení zabezpečeného spojení k privátní síti. Druhá část se podrobněji věnuje popisu VPN protokolů z hlediska zabezpečení, průchodnosti přenosovou sítí a míře podpory na zařízeních s odlišným operačním systémem. Třetí a poslední část práce je pak věnována konfiguraci serveru s operačním systémem FreeBSD tak, aby bylo možné připojit se k němu postupně pomocí všech VPN protokolů podporovaných ve Windows 7.

Annotation The aim of this bachelor's thesis is examination, comparation and recommendation of a VPN connection using protocols natively supported by operating system Microsoft Windows 7. The first part of this thesis deals with authentication and cryptographic algorithms necessary to establish a secure connection to a private network. The second part is focused on the description of VPN protocols in terms of security, throughpuu of the interlaced network and the level of support on devices with an operating system different from Windows 7. The third and final part is devoted to configuration of a server running FreeBSD so that it can be connected to by a client, using all VPN protocols supported by Windows 7.

Klíčová slova autentizace, FreeBSD, IKEv2, L2TP, PPTP, SSTP, šifrování, VPN, Windows 7

Keywords authentication, encryption, FreeBSD, IKEv2, L2TP, PPTP, SSTP, VPN, Windows 7

Obsah Úvod ........................................................................................................................................... 3 1.

Autentizační a šifrovací protokoly ...................................................................................... 5 1.1

1.1.1

Password Authentication Protocol ....................................................................... 5

1.1.2

Microsoft Challenge-Handshake Authentication Protocol .................................. 5

1.1.3

Microsoft Challenge-Handshake Authentication Protocol v2 ............................. 7

1.1.4

Internet Key Exchange v2 .................................................................................... 8

1.2

2.

3.

Autentizační protokoly ................................................................................................ 5

Šifrovací protokoly ...................................................................................................... 9

1.2.1

Microsoft Point-To-Point Encryption Protocol .................................................. 10

1.2.2

IP Security .......................................................................................................... 10

1.2.3

Secure Socket Layer/ Transport Layer Security ................................................ 12

VPN protokoly podporované Windows 7 ......................................................................... 14 2.1

PPTP, Point-to-Point Tunneling Protocol ................................................................. 15

2.2

L2TP, Layer 2 Tunneling Protocol ............................................................................ 18

2.3

SSTP, Secure Socket Tunneling Protocol ................................................................. 20

2.4

IKEv2, Internet Key Exchange v2 ............................................................................. 22

2.5

Srovnání VPN protokolů ........................................................................................... 25

Konfigurace serveru a klienta ........................................................................................... 27 3.1

PPTP .......................................................................................................................... 27

3.1.1

Server ................................................................................................................. 27

3.1.2

Klient .................................................................................................................. 29

3.1.3

Výsledek ............................................................................................................. 30

3.2

L2TP .......................................................................................................................... 30

3.2.1

Server ................................................................................................................. 30

3.2.2

Klient .................................................................................................................. 34

3.2.3

Výsledek ............................................................................................................. 34

3.3

SSTP .......................................................................................................................... 35

3.3.1

Server ................................................................................................................. 35

3.3.2

Klient .................................................................................................................. 39

3.3.3

Výsledek ............................................................................................................. 40

3.4

IKEv2......................................................................................................................... 40

3.4.1

Server ................................................................................................................. 40 1

3.4.2

Klient .................................................................................................................. 44

3.4.3

Výsledek ............................................................................................................. 44

Závěr......................................................................................................................................... 45 Slovník zkratek ......................................................................................................................... 46 Literatura a zdroje .................................................................................................................... 47 Příloha A, Konfigurační soubory PPTP ................................................................................... 50 Příloha B, Konfigurační soubory L2TP ................................................................................... 52 Příloha C, Konfigurační soubory SSTP ................................................................................... 55 Příloha D, Konfigurační soubory IKEv2.................................................................................. 56

2

Úvod Virtuální privátní síť, neboli VPN, nalézá v současné době mnoho různých využití. Soukromé, kde může sloužit pro vzdálený přístup do domácí sítě z jakéhokoli místa s přístupem k Internetu, i komerční. V komerční sféře značně zjednodušuje práci ve chvíli, kdy je potřeba zabezpečená komunikace mezi více různými pobočkami jedné společnosti. Vytvoření virtuální sítě v tomto případě poskytuje alternativu k položení fyzické sítě mezi pobočkami, což je řešení jak finančně, tak administrativně náročné a mnohdy úplně nemožné. Správně konfigurovaná virtuální privátní síť by měla být ekvivalentní lokální síti. Měla by umožňovat využití veškerých dat, zařízení a jiných služeb k ní připojených bez ohledu na to, kde se fyzicky nachází. V případě přístupu ke zdroji ve stejném fyzickém segmentu virtuální sítě probíhá komunikace stejně jako by probíhala po síti místní. Pokud je ovšem vyžadován přístup ke zdroji v jiném segmentu, musí se server vypořádat s přenosem soukromých dat přes veřejně dostupnou síť. Během něj je prioritou zajištění autentizace a dostatečné úrovně zašifrování přenosu při zachování co nejvyšší přenosové rychlosti tak, aby byla pokud možno zachována iluze přímého lokálního spojení. Práce se věnuje využití virtuálních privátních sítí v prostředí Windows 7, s nímž se lze na uživatelských zařízeních setkat nejčastěji. Tento operační systém funkčně nahradil oblíbený systém Windows XP, jehož podpora skončila v dubnu 2014. Protože Windows 8 zatím nepřináší natolik zásadní inovace, aby se k němu vyplatilo přejít soukromým uživatelům a firmám, zůstává systém Windows 7 nejpoužívanějším operačním systémem na trhu. Oproti tomu v komerční sféře se lze stále častěji setkat s využitím open-source softwaru, který není zatížen žádnými licenčními poplatky. V oblasti operačních systémů jsou často využity systémy postavené na jádru Unix, jako například FreeBSD. Praktická část této práce počítá právě s využitím systému FreeBSD jako VPN serveru. První a druhá kapitola práce se zabývá VPN protokoly z teoretického hlediska. Autentizační a šifrovací algoritmy popsané v první kapitole zajišťují autenticitu, integritu a důvěrnost dat během jejich přenosu veřejnou sítí. Bez těchto vlastností by existence VPN postrádala smyslu a proto mají pro její funkci zásadní význam. Při popisu algoritmů je věnována pozornost jejich již známým zranitelným místům a slabinám vůči některým typům útoků. Druhá kapitola pak obsahuje popis protokolů pro ustavení virtuální privátní sítě dostupných ve Windows 7. Zabývá se jimi z hlediska využití autentizačních a šifrovacích algoritmů, zmíněných v první kapitole, a rozebírá vlastnosti přenosové sítě, vyžadované pro jejich provoz. Třetí kapitola navazuje na předchozí dvě předvedením VPN protokolů v praxi. Obsahuje návody na konfiguraci serveru založeného na operačním systému FreeBSD tak, aby bylo možné připojit se k němu ze vzdálených klientských Windows 7 počítačů. Postup je vždy rozdělen na části konfigurace serveru, konfigurace klienta a na část dosaženého výsledku. Poslední jmenovaná část hodnotí vždy náročnost zprovoznění protokolu a případné nedostatky vzniklé chybějící dokumentací či špatnou kompatibilitou. Závěr práce shrnuje teoretické vlastnosti protokolů a konfrontuje je s výsledky dosaženými při provozu v praktické části. Obsahuje zhodnocení protokolů na základě jejich sledovaných vlastností a doporučení odpovídajícího řešení pro různé typy VPN.

3

Téma této bakalářské práce bylo vypsáno ve spolupráci s firmou Trusted Network Solutions, která se zabývá poradenstvím v oblasti bezpečnosti síťových spojení a vývojem softwaru zajišťujícího odolnost proti útokům zvenčí pro firemní sítě i jednotlivé uživatele.

4

1. Autentizační a šifrovací protokoly Pro správnou interpretaci všech bezpečnostních vlastností a funkcí, které musí být součástí každého VPN protokolu, se první kapitola věnuje autentizaci a šifrování. Různé protokoly VPN totiž podporují odlišné bezpečnostní algoritmy a jejich pochopení značně ulehčí porozumění problematice ustavení VPN spojení. Všechny následující bezpečnostní protokoly jsou součástí některého protokolu VPN.

1.1 Autentizační protokoly Protokoly náležící do této kapitoly zajišťují ověření identity účastníků zabezpečeného spojení. Často je také jejich výstupem klíč, od kterého se odvozují podřazené klíče k pozdějšímu zašifrování komunikace. V případě neprovedení procesu autentizace by se za klienta s povolením přístupu do sítě mohl vydávat kdokoliv, což by de facto zničilo koncept privátní sítě. Protože řada útoků cílí právě na přisvojení si identity uživatele s oprávněním přístupu jako na cíl jednodušší, než přímé prolamování šifry spojení, neměl by být výběr autentizačního protokolu nikterak podceněn. Následující výčet představuje protokoly obsažené ve vestavěném VPN klientském softwaru Windows 7. Protože není cílem této práce podrobně se věnovat autentizačním algoritmům, jejich popis se omezuje na postup samotné autentizace a zmínění zranitelností vůči různým typům útoku. Podrobnější informace lze získat v některé z dostupných publikací [1].

1.1.1 Password Authentication Protocol Základní verze autentizačního algoritmu, kterou je možné použít v protokolech založených na PPP, jako PPTP, L2TP a SSTP. Poskytuje pouze tu nejslabší formu ověření identity, kdy klient odesílá své identifikační údaje přenosovou sítí jako čistý, nijak nešifrovaný, text [2]. V prvním kroku autentizace klient pošle serveru žádost o spojení obsahující své jméno a heslo. Server tyto údaje ověří a odpoví v druhém kroku potvrzením či zamítnutím spojení . Na první pohled viditelnou slabinou takového postupu je možnost přečtení všech přihlašovacích údajů z odchyceného paketu klienta. Útočníkovi pak již nic nebrání tyto údaje zneužít a převzít identitu a oprávnění postiženého uživatele. Jedinou výhodou protokolu jsou snad jen zanedbatelné nároky na výpočetní výkon. Využití se omezuje na situace, kdy není dostupné řešení ve formě jiného protokolu.

1.1.2 Microsoft Challenge-Handshake Authentication Protocol Tento protokol byl vydán Microsoftem jako náhrada předchozího PAP v situacích vyžadujících určitou míru jistoty o totožnosti autentizovaného. Princip ověření spočívá v systému výzva-odpověď (challenge-response) [3]. Poskytuje autentizaci klient-server pro síťové služby systémů Microsoft Windows, mezi které patří i spojení PPTP, L2TP a SSTP. Vznikl modifikací algoritmu CHAP a používá velmi podobnou strukturu zpráv:

5

Obrázek 1 Schéma operací protokolu MsCHAP

Každá MsCHAP zpráva má rozměr přesně jednoho PPP paketu a obsahuje následující položky: typ zprávy, identifikátor, délku zprávy a data. Povoleny jsou čtyři typy zprávy – Challenge, Response, Success a Failure. Identifikátor k sobě jednoznačně přiřazuje zprávy typu Challenge a Response. Klient nejprve kontaktuje server se zájmem o spojení. Server odpovídá zprávou Challenge, která nese jako data náhodný řetězec znaků dlouhý 8 bytů. Klient pak spočítá 24B odpověď provedením funkce LANMAN nad obdrženým řetězcem, s využitím sdíleného hesla [4]. Poté hashuje řetězec ještě jednou funkcí MD4, opět za použití stejného hesla. Serveru odesílá dvě zprávy, jednu s výsledkem LANMAN, druhou s výsledkem MD4. Server porovná hashe získané od klienta se svými, pokud se alespoň jeden z nich shoduje, odpovídá zprávou typu Success, v opačném případě zprávou typu Failure. Tento postup může být v průběhu spojení opakován v libovolných intervalech. Slabinou protokolu je v první řadě užití funkce LANMAN, ke které se po zjištění fundamentálních bezpečnostních vad pouze přidala MD4, z důvodu zachování zpětné kompatibility. Heslo je při zpracování vždy převedeno do upper-case, takže pokud nemá dostatečnou délku a nepoužívá speciální symboly, stává se velice zranitelné slovníkovými útoky a útoky hrubou silou [5]. Druhý bezpečnostní problém se skrývá ve funkci MD4, jež je náchylná k útoku kolizí (collision attack) [6]. Ten spočívá v nalezení různých řetězců takových, aby MD4(řetězec1) = MD4(řetězec2). Jako poslední vadu bych zmínil spoléhání se na jedinou utajenou informaci – sdílené heslo. Všechny ostatní, jako například uživatelské jméno, jsou posílány mezi serverem a klientem nezašifrované. Případný útok tak stačí cílit výhradně na jediný šifrovaný údaj. Jako důsledek těchto snadno zneužitelných vad protokolu není jeho užití k autentizaci doporučeno.

6

1.1.3 Microsoft Challenge-Handshake Authentication Protocol v2 Protokol MsCHAPv2 měl plně nahradit MsCHAP poté, co v něm byly odhaleny zásadní bezpečnostní chyby designu. Slabiny předchůdce opravuje zejména následujícími změnami: 1. Hash funkce LANMAN není nadále podporována a již není obsahem autentizačních zpráv. K funkci MD4 se místo ní přidává SHA1. 2. Jedinou autentizační výměnou dojde k ověření totožnosti serveru i klienta. Protokol MsCHAP vyžadoval provést handshake klient-server a poté server-klient. 3. Pro šifrování odchozích a dešifrování příchozích dat jsou použity různé klíče. Vyjmenované změny si vyžádaly změnu schématu výměny zpráv mezi serverem a klientem. Některé prováděné hashovací operace ale lze vyhodnotit jako zbytečné, či alespoň zbytečně složité. Postup výměny autentizačních zpráv a kroky prováděné samostatně jednotlivými stanicemi proto přehledněji popisuje následující seznam operací a obrázek.

Obrázek 2 Schéma operací protokolu MsCHAPv2

Klient kontaktuje server s žádostí o spojení. Server odpovídá náhodným 16B řetězcem – ServerChallenge. Klient vygeneruje vlastní 16B náhodný řetězec – ClientChallenge. Klient vygeneruje 8B ChallengeHash ze ServerChallenge, ClientChallenge a uživatelského jména. 5. Klient spočítá MD4 hash sdíleného hesla – NTHash. 6. Klient vytvoří 24B ChallengeResponse z ChallengeHash za použití hesla uživatele v hashované podobě. Heslo je, stejně jako u MsCHAP, zarovnáno na 21 B a rozděleno na 3 klíče. 1. 2. 3. 4.

7

7. Výsledná odpověď serveru sestává z ChallengeResponse, ClientChallenge a uživatelského jména. 8. Server za pomoci sdíleného hesla ověří obsah odpovědi a pokud se shoduje s jeho výpočtem, klient je autentizovaný. 9. Server se klientu autentizuje zprávou obsahující hash ClientChallenge vytvořený pomocí hashe sdíleného hesla a dvou konstantních textových řetězců. Zejména postup v kroku 9, kde server počítá dvakrát za sebou SHA1 hash demonstruje zbytečné využití výpočetního výkonu a de facto zpomaluje celý autentizační proces. Stejně tak sporný přínos má přidání magických konstant "Magic server to client constant" a "Pad to make it do more than one iteration" na konec hashovaných řetězců [7]. Protokol MsCHAPv2 se, přes svou neefektivní konstrukci, dal považovat za bezpečný, pokud bylo zvoleno dostatečně silné heslo, přestože stále jako jeho předchůdce spoléhal pouze na utajení sdíleného hesla. Na bezpečnostní konferenci Defcon v červenci roku 2012 bezpečnostní expert Moxie Marlinspike představil postup značně snižující odolnost proti útoku hrubou silou. Tento postup popsal o něco později v článku na serveru cloudcracker.com [8]. Marlinspike ukazuje, jak využít útok typu divide-and-conquer na tři DES klíče, které vznikly rozdělením hashe sdíleného hesla. Zatímco čistý bruteforce attack na hash by měl složitost přibližně 2128, útok divide-and-conquer ji snižuje na součet (256 + 256 + 256). Ještě mnohem lepšího účinku lze dosáhnout, pokud útočník využije faktu, že třetí klíč je efektivně pouze dva znaky dlouhý, zbylé byly doplněny nulami. Po zjištění této části klíče zbývá 14 B posledních dvou a za použití algoritmu prezentovaného Marlinspikem se složitost snižuje až na pouhých 256, což odpovídá jedné úrovni šifrování DES. Marlinspike dále poskytuje nástroje nezbytné k prolomení této šifry v čase kratším než 24 hodin. V současnosti jsou tedy veřejnosti dostupné nástroje, které umí prolomit autentizaci MsCHAPv2 ve velice krátkém čase. Jeho použití je nadále doporučeno Microsoftem pouze v kombinaci s protokolem PEAP [9].

1.1.4 Internet Key Exchange v2 Poznámka: Tato podkapitola se věnuje pouze průběhu ustavení SA 1 . Informace o VPN protokolu se stejným názvem naleznete v druhé kapitole. Posledním z řady čistě autentizačních protokolů je IKEv2 [10]. Zajišťuje ustavení bezpečnostního přiřazení (SA) mezi dvěma stanicemi – výběr šifrovacího protokolu a dohodnutí klíčů pro další komunikaci. Princip protokolu vychází z předchozího IKE, oproti němu ale představuje několik vylepšení. 1. Sjednocuje původně několik dokumentů RFC se specifikacemi IKE do jediného. 2. Snižuje počet vyměněných zpráv při autentizaci z devíti na čtyři zprávy ve dvou fázích – IKE_SA_INIT a IKE_AUTH.

1

Z anglického výrazu Security Association – bezpečnostní přiřazení. Označuje souhrn bezpečnostních atributů a algoritmů, na nichž je postavena chráněná komunikace mezi dvěma stanicemi.

8

3. Obsahuje funkci Dead Peer Detection, která povoluje zrušit ustanovenou SA, pokud klient neodpovídá. 4. Lze povolit obranu proti DoS útokům pomocí cookie zpráv.

Obrázek 3 Výměna zpráv IKEv2

Schéma zpráv na obrázku ilustruje průběh ustavení SA. První výměna obsahuje seznam podporovaných šifrovacích algoritmů, pole s hodnotou Diffie-Hellman výměny klíčů a tzv. nonce – náhodný řetězec párující k sobě dvojice request/response, zajišťující ochranu proti útokům přehráním (replay attack). Pokud je využita funkce obrany proti DoS útokům, může si server vyžádat od klient potvrzení zasláním zprávy obsahující tzv. cookie – opět náhodně vygenerovaný řetězec. Pokud jej klient odešle zpět, potvrdí tím, že nejen zasílá žádosti o spojení, ale rovněž i čeká na odpověď. Druhá fáze již probíhá v zašifrované podobě a zprávy nesou autentizační informace stanic. Ověření totožnosti může proběhnout pomocí certifikátu nebo PSK. Zároveň tyto zprávy vytvoří pomocí identifikátorů podřízené šifrované spojení, tzv. CHILD_SA, po kterém bude probíhat přenos dat mezi stanicemi. Toto podřízené spojení bývá zpravidla zašifrováno dle protokolu IPsec. Nespornou výhodou protokolu IKEv2 je zašifrování celé komunikace ihned po výměně prvních dvou zpráv. Žádné autentizační informace díky tomu nejsou posílány ve formě plain textu a nedají se zjistit prostým odposlechem. Útokům man-in-the-middle lze do jisté míry odolat s využitím oboustranné autentizace ověřením náplně Auth ve třetí a čtvrté zprávě a replay útokům zamezuje použití identifikátoru zprávy (nonce). IKEv2 ve výsledku poskytuje zdaleka nejvyšší úroveň bezpečnosti autentizace ze všech tří představených protokolů.

1.2 Šifrovací protokoly Pokud klient úspěšně projde fází autentizace, vyvstává potřeba zabezpečit přenos dat mezi ním a zbytkem soukromé sítě proti zachycení a přečtení útočníkem. Protože datový paket může cestou veřejnou sítí odchytit téměř kdokoliv, důvěrnost dat je nutné zachovat jejich převedením do formy čitelné pouze adresátu. Tuto funkci zajišťují kryptografické protokoly, 9

šifrující data podle klíče známého pouze koncovým stanicím, obvykle některou ze symetrických blokových šifer. Následující protokoly poskytují důvěrnost dat přenášených v rámci virtuální privátní sítě. Kromě prvního jmenovaného, MPPE, mohou poskytnout i funkci autentizace před začátkem přenosu. V rámci VPN protokolů jsou ale často použité v kombinaci s některým z autentizačních algoritmů. Protože si tato práce neklade za cíl podrobně analyzovat procesy šifrování dat, je tento postup popsán u složitějších protokolů pouze povrchně, s důrazem na případné zranitelnosti vůči útoku. Podrobnější informace o šifrovacích protokolech a konkrétních šifrách lze získat v některé z publikací jim přímo věnované.

1.2.1 Microsoft Point-To-Point Encryption Protocol Šifrovací protokol MPPE byl navržen Microsoftem k zabezpečení vytáčených připojení [11]. Nejčastěji používaný k zašifrování tunelovaného přenosu PPTP mezi stanicemi Windows. Zajišťuje ale pouze důvěrnost dat, spolehlivost autentizace závisí na sdruženém autentizačním protokolu, kterým může být MsCHAP nebo MsCHAPv2. Tyto protokoly také generují informace, z nichž pak MPPE odvodí iniciální klíče k zašifrování komunikace. Klíče mohou mít délku 40-bit, 56-bit nebo 128-bit. Odvození MPPE klíčů po úspěšném dokončení autentizace MsCHAPv2 probíhá podle několika kroků (řetězce jsou označeny stejně jako ve schématu autentizace): 1. MPPE vytvoří společný SHA1 hash z řetězců NThash (16B), 24B odpovědi obdržené od druhé stanice a 27B magické konstanty "This is the MPPE Master Key". 2. Výsledek je zkrácen na 16 B master klíč. 3. Z master klíče vznikne pár klíčů SHA1 hashováním 16B master klíče, 40B řetězce 0x00, 84B magické konstanty a dalšího 40B řetězce 0xF2. RFC definuje různé konstanty pro klíč klient-server a server-klient, takže vygenerované klíče se pro oba směry liší. 4. Oba vzniklé klíče jsou před použitím zkráceny na 16 B. Zranitelné místo protokolu může ležet právě v užití magických konstant k vygenerování šifrovacích klíčů. Obzvláště při využití 40-bit klíče, kdy je horních 24 B klíče pro potřeby funkce RC4 nastaveno pevně na 0xD1269, což funkci značně oslabuje [7]. Vzhledem k tomu, že protokol MPPE vždy vyžaduje přítomnost jedné z verzí protokolu MsCHAP, který však bez kombinace s jiným protokolem (například EAP) poskytuje pouze nízkou úroveň zabezpečení, možnosti jeho využití jsou značně omezené. V současné době se s ním lze setkat prakticky výhradně u PPTP spojení.

1.2.2 IP Security IPsec je kompletní sada protokolů k zajištění komunikační bezpečnosti na sítích IPv4 i IPv6, do obou IP protokolů byl dodán jako volitelný modul. Veškeré funkce IPsec tedy probíhají na třetí (síťové) vrstvě modelu ISO/OSI. Protokol skrze autentizaci stanic a zašifrování každého zasílaného paketu poskytuje autenticitu, integritu i důvěrnost přenášených dat. Od svého vydání v roce 1993 byl několikrát přepracován a vybaven dalšími moduly, takže dokumentů 10

RFC s jeho specifikacemi existuje větší množství. Za stěžejní lze považovat RFC 2401 a 2411[12] [13]. K zabezpečení přenosu slouží zejména části protokolu Authentication Header (AH) a Encapsulating Security Payload (ESP). Před použitím některé z nich musí být mezi komunikujícími stanicemi ustaveno bezpečnostní přiřazení, jež určí i počáteční šifrovací klíče. Pak mohou být data obalena hlavičkou AH, ESP nebo i oběma. AH poskytuje, na rozdíl od ESP, pouze záruku zachování integrity [14]. Pokud mají být data utajena před potenciálním útočníkem, musí být zašifrována pomocí ESP [15]. Umístění IPsec hlaviček v rámci paketu závisí na zvoleném módu. Protokol nabízí buď transportní, nebo tunelovací. V transportním módu se AH nebo ESP hlavička zařadí za IP adresu cíle. Veškeré následující hlavičky jsou pak chráněny na úrovni jim předřazené IPsec hlavičky. V důsledku ale zůstává nechráněná původní IP adresa cíle, což může představovat bezpečnostní riziko. Tunelovací mód obalí IPsec hlavičkou celý datový paket včetně původní hlavičky IP. Nová IP adresa pak může paket směrovat na zabezpečený hraniční server, který se postará o odstranění IPsec obalu a datový paket zašle již nezabezpečený k cíli.

Obrázek 4 Paket chráněný Authentication Header

Hlavička AH obsahuje pouze několik informací. Next header nese informace o typu protokolu vyšší vrstvy (zpravidla TCP nebo UDP), Security parameters index obsahuje identifikátor SA po kterém komunikace probíhá a Sequence number označuje pořadí zprávy v komunikaci (brání útokům přehráním). Authentication data obsahují kontrolní hash, spočítaný z šifrovacího klíče a obsahu paketu pomocí funkce SHA1. Jakákoli změna paketu v průběhu přenosu, včetně změny adresy v předřazené IP hlavičce, je pak cílovou stanicí detekována při kontrole tohoto hashe. Tato vlastnost nedovoluje provoz IPsec AH přes jakoukoli formu NAT [16].

11

ESP v tunelovacím módu zajišťuje všechny vlastnosti zabezpečení dat – autenticitu, integritu i důvěrnost. Transportní mód oproti tomu postrádá garanci autenticity a integrity. Konstrukce paketu chráněného ESP se od AH mírně liší, hlavička ESP je totiž rozdělena na tři části: ESP Header, ESP Trailer a ESP Auth.

Obrázek 5 Paket chráněný Encapsulated Security Payload

ESP Header obsahuje parametry Security parameters index a Sequence number se stejným významem jako u AH. ESP Trailer s parametry Padding a Pad length zarovnává paket na délku použité blokové šifry. ESP Auth pak nese pouze hash přenášených dat, shodný s AH. Velmi zásadním rozdílem oproti AH je ale absence vnější IP hlavičky v kontrolním součtu. IPsec ESP tedy lze provozovat i přes lokální zařízení NAT. Kryptografická metoda šifrující obsah IPsec ESP komunikace není v RFC přesně specifikována. Záleží na výběru v průběhu ustavování SA. Lze se setkat nejčastěji se symetrickými blokovými šiframi DES, 3DES, Blowfish a AES, z nichž za nejsilnější je považována AES. Délka klíče AES může dosahovat 256-bit, s volitelnými kratšími klíči 192bit a 128-bit a šifrování provádí na 128-bit datových blocích a doba nutná k prolomení takové šifry bez jakékoliv znalosti o klíči se pohybuje od 1018 let pro nejkratší klíč až do 1056 let pro nejdelší [17].

1.2.3 Secure Socket Layer/ Transport Layer Security Bezpečnostní protokol Secure Socket Layer, který, obdobně jako IPsec, zajišťuje autenticitu, integritu a důvěrnost dat [18]. Po několika aktualizacích byl v roce 1996 nahrazen novějším protokolem Transport Layer Security, založeným na stejném principu [19]. Pracuje na čtvrté (transportní) vrstvě ISO/OSI modelu a používá jak symetrické kryptografie k zašifrování přenášených dat, tak asymetrické při autentizaci, ve formě x.509 certifikátů. Nasazení protokolu závisí na existenci hierarchie certifikačních autorit (CA) a infrastruktury veřejných klíčů (PKI). Každá stanice, například server, který potřebuje potvrdit svou identitu, vygeneruje vlastní certifikát navázaný na jeho FQDN a zašle jej k ověření některé CA. 12

Jakmile se pak k takovému serveru připojuje klient, server mu zašle kopii svého certifikátu a klient si jej může ověřit u podepsané CA. Následně se stejným postupem může prokázat i klient. V průběhu autentizace dojde k odvození klíče symetrické šifry pro další komunikaci. TLS handshake probíhá v následujících krocích [20]: 1. Klient odešle serveru žádost o navázání zabezpečeného spojení s údaji o podporovaných šifrách a verzí protokolu a další detaily SA. 2. Server odpovídá výběrem šifrovacího algoritmu, potvrzením SA a vlastním certifikátem k ověření. Může také požadovat certifikát klienta. 3. Klient ověří certifikát a pokud není platný spojení ukončí, jinak za použití dohodnutých detailů SA vytvoří master klíč spojení, zašifruje jej veřejným klíčem serveru a odešle jej. Pokud server vyžadoval certifikát, zašle i ten. 4. Server dešifruje master klíč svým privátním klíčem. 5. Klient i server z master klíče vygenerují tzv. master secret za použití pseudonáhodné funkce a z něj pak odvodí symetrické klíče pro zašifrování další komunikace. 6. Klient odešle dvě oddělené zprávy. První informuje server, že veškerá další komunikace bude zašifrovaná. Druhá obsahuje zprávu o ukončení fáze autentizace. Server odpoví stejným způsobem. Různé verze SSL i TLS projevily náchylnost k některým typům útoků. Útok typu rollback se pokouší donutit server k použití co nejslabšího typu šifry. Pokud server souhlasí, útočníkovi stačí pokusit se tuto šifru prolomit offline na odchycených paketech. Podobný útok využívá zpětnou kompatibilitu mezi SSL 3.0 a 2.0 a donutí server použít starší verzi s několika známými bezpečnostními chybami [21]. Dále byla v nedávné době objevena kritická chyba v zabezpečení OpenSSL verze 1.0.1, umožňující útočníkovi zcizit uživatelská data a soukromé klíče. Nese označení Heartbleed (postihuje OpenSSL komponent Heartbeat), oficiální kód chyby CVE-2014-0160. Nejnovější verze 1.0.1g již tuto chybu odstraňuje. Vzhledem k závažnosti chyby a možným následkům by postižené servery měly co nejdříve přejít na novou verzi programu OpenSSL [22].

13

2. VPN protokoly podporované Windows 7 Využití virtuální privátní sítě se sebou nese výhodu přístupu „zvenčí“ ke zdrojům dostupným na soukromé síti při relativně nízkých nárocích na správu poté, co byly nastaveny hraniční servery. Tyto servery mohou být nakonfigurovány pro neustálé statické spojení, jako v případě spojení dvou vzdálených poboček, v tzv. Site-to-Site VPN, nebo naslouchají na portech specifikovaných VPN protokolem a dynamicky přijímají připojení od vzdálených uživatelů v tzv. Point-to-Site VPN. Některé protokoly zmíněné v dalších kapitolách podporují obě konfigurace, nicméně Site-to-Site nastavení jsou k dispozici pouze v operačních systémech Microsoft Windows Server. Protože se práce věnuje šifrovaným spojením mezi počítači využívajícími operační systém Microsoft Windows 7, bude teoretická i praktická část soustředěna převážně na možnosti z hlediska Point-to-Site VPN.

Obrázek 6 Site-to-Site VPN

Obrázek 7 Point-to-Site VPN

Pokud jsou klientské počítače vybaveny operačním systémem Windows 7, existuje několik možností výběru protokolu pro vytvoření virtuální sítě. Nejjednodušší volbou je protokol PPTP [23], který patří k součástem systémů Windows již od roku 1999. Zabezpečení, které poskytuje, už ale v současné době nezaručuje příliš vysokou odolnost dat proti změně nebo 14

přečtení během přenosu. O stupeň lepší zabezpečení poskytují protokoly L2TP a SSTP [24]. Výhodou L2TP je šifrování dat pomocí protokolu IPsec, ale oproti PPTP má vyšší režijní nároky. Zabezpečení SSTP je na srovnatelné úrovni a navíc spojení zajišťovaná tímto protokolem dokáží projít skrz část firewallů, která by zastavila spojení přes předchozí protokoly. Protože se ale jedná o protokol vyvíjený Microsoftem, jeho podpora na zařízeních od jiných výrobců je slabší. Nejmodernějším protokolem obsaženým ve Windows 7 je IKEv2 [25]. Podporuje IPsec šifrování a má implementovánu funkci automatického obnovení spojení při výpadku přenosové sítě. Rozbor VPN protokolů v této kapitole se věnuje fázím navázání spojení a přenosu dat. Dále uvádí podmínky, které musí být splněny k provozu protokolu. Jedná se o nároky v podobě otevřených portů, kde každý protokol vyžaduje otevření portů se specifickým číslem jak na všech zařízení přenosové sítě, jimiž prochází, tak na straně serveru. Třetím sledovaným hlediskem je bezpečnost s ohledem na podporované autentizační a šifrovací algoritmy z první kapitoly. V posledním odstavci lze nalézt shrnutí výhod a nevýhod pro každý protokol.

2.1 PPTP, Point-to-Point Tunneling Protocol RFC 2637, definující vlastnosti protokolu, bylo vydáno v červenci roku 1999 sdružením několika společností v čele s Microsoftem. PPTP má implementovány všechny služby očekávané od VPN, ale šifrování přenosu a autentizace jsou na nejnižší úrovni ze všech čtyř zde představených protokolů. Hlavní výhodou je relativně snadná konfigurace ve srovnání s ostatními dostupnými protokoly a stále ještě velice široká podpora mezi zařízeními různých výrobců. Z těchto důvodů je protokol obzvláště vhodný pro ustavení domácí VPN, kde umožňuje připojit širokou škálu zařízení s operačními systémy Unix, iOS, Android a jiné. Šifrování přenosu bylo v roce 2012 prolomeno útokem hrubou silou, použití pro jakékoli spojení vyžadující důvěrnost nebo autentičnost přenášených dat není nadále doporučeno [9]. Point-to-Point Tunneling Protocol vznikal ve druhé polovině 90. let, tedy v době, kdy bylo stále ještě běžné vytáčené připojení k Internetu pomocí telefonní linky a modemu.

Obrázek 8 Klasické vytáčené spojení

V tomto druhu připojení byl jeho poslední úsek, mezi ISP a klientem, zprostředkován protokolem Point-to-Point Protocol (PPP). IP pakety totiž nebylo možné posílat samotné po koncové telefonní lince, obalené hlavičkou PPP však ano. Pokud klient potřeboval vyšší rychlost připojení, mohl využít agregace linek – tzv. Multilink PPP, ovšem tato funkce 15

vyžadovala správné sdružování linek patřících jednomu klientu na straně ISP. Řešení tohoto problému vyústilo v protokol PPTP, který rozdělil Network Access Server na dvě zařízení, PPTP Access Concentrator (PAC) a PPTP Network Server (PNS).

Obrázek 9 Tunelované vytáčené spojení

Ustavení spojení tedy probíhalo následovně. Po vytočení linky byl nejprve klient připojen na PPTP Access Concentrator, který si vyžádal autentizaci a pak vytvořil PPTP tunel k PNS. Ten mohl sdružit linky se shodnou autentizací a poté zajistit efektivní směrování další komunikace. Vytáčené spojení od klienta díky tomuto rozdělení mohlo končit v lokálním PAC a nemuselo dosahovat až k samotnému NAS, což znamenalo úsporu nákladů při značných vzdálenostech mezi klientem a NAS. PPTP protokol tedy nebyl původně vyvíjen pro vytváření virtuálních sítí, byť se k tomuto účelu ukázal jako vhodný. Aby bylo možné PPTP využít, musí být mezi potenciálními koncovými body dostupná IP konektivita. Protože jakýkoli VPN tunel typicky probíhá Internetem, nepřináší tato vlastnost v praxi obvykle žádné omezení. Na všech mezilehlých síťových prvcích také musí být povoleny porty TCP 1723 pro kontrolní kanál a IP Protocol ID 47 pro datové spojení. PPTP spojení nebude funkční v případě umístění klienta za NAT, který není konfigurován na přeposílání GRE paketů. Ten sice povolí ustavení kontrolního kanálu, ale zahodí všechna přenášená data. Rovněž v případě připojení přes webový proxy server (WPS) nebude pokus o spojení úspěšný [26]. Pokud jsou splněny všechny podmínky kladené na přenosovou síť může být zahájen pokus o připojení k serveru. Protokol k vytvoření VPN využívá dva kanály. První je kontrolní a běží na protokolu TCP. Po tomto kanálu zasílají koncové stanice zprávy oznamující začátek nebo konec přenosu dat a potvrzují příjem. Dále umožňuje zasílání zpráv o změně stavu linky mezi oběma konci a neustále po něm probíhají keep-alive zprávy pro detekci selhání spojení. Každý pokus o PPTP přenos je tedy zahájen vytvořením TCP spojení mezi vzdáleným uživatelem a lokálním PPTP serverem na portu 1723. Vzápětí je vytvořeno i kontrolní spojení pomocí zpráv Start-Control-Connection-Request a Start-Control-Connection-Reply. Po ustavení kontrolního kanálu může být vytvořen druhý, sloužící již k vlastnímu přenosu dat. Ten probíhá za pomoci protokolu GRE následovně:

16

Obrázek 10 PPTP paket

Původní IP datagram je zašifrován některou z metod, kterou poskytuje protokol PPP a je k němu přidána odpovídající hlavička. K výsledku je dále přidána hlavička GRE – jednoduchého protokolu k zabalení dat pro přenos přes IP sítě. GRE je pro potřeby PPTP mírně modifikován. Poslední hlavička výsledného paketu patří protokolu IP a obsahuje adresu zdroje a adresu cíle. Výsledek již může být odeslán do přenosové sítě k doručení. Při zpracování paketu na straně PPTP serveru jsou postupně odebírány hlavičky až zbývá pouze zašifrovaný paket PPP. Ten server umí dešifrovat a získá datagram s lokální IP adresou cíle, kterému jej přepošle. Jak naznačilo schéma paketu putujícího nezabezpečenou sítí, PPTP šifrování přímo neřeší. Veškerou starost o bezpečnost nechává na podřízeném protokolu PPP. Ten musí v první řadě zajistit autentizaci stanic a poté zašifrovat každý paket směrovaný vytvořeným tunelem. Pro autentizaci je možné zvolit mezi několika možnostmi, z nichž ale část již poskytuje naprosto nedostačující zabezpečení. Nedoporučuje se výběr Password Authentication Protocol (PAP) nebo Microsoft Challenge Handshake Authentication Protocol (MsCHAPv1). Oba protokoly vykazují zásadní chyby a jsou náchylné k prolomení ve velmi krátkém čase. O něco lepší stupeň zabezpečení zaručuje MsCHAPv2, který opravuje většinu chyb svého předchůdce a umožňuje autentizaci pomocí uživatelského jména a hesla. Nejvyššího možného zabezpečení lze dosáhnout s Extensible Authentication Protocol. Ten umožňuje využít autentizaci s ověřením identity pomocí certifikační autority či MsCHAPv2 jméno a heslo nebo kombinaci obou možností. Zároveň definuje určité postupy pro přenos a uchovávání autentizačních dat, nadále zvyšující odolnost vůči útoku zvenčí. O šifrování PPP rámců se stará jediný protokol – Microsoft Point-To-Point Encryption Protocol. K zašifrování dat využívá algoritmus RSA RC4 na klíčích 40-bit, 56-bit nebo 128bit. Přesná délka klíčů je dohodnuta při ustavení spojení a v průběhu se již nemění. Oproti tomu samotné klíče je možné, a doporučené, měnit v určitých intervalech, nejčastěji až 1 různý klíč na paket. Přestože nejnovější aktualizace zabezpečovacích postupů odstranily většinu zásadních chyb v implementaci protokolu PPTP při použití doporučeného nastavení, stále zbývá několik trhlin obsažených v konstrukci protokolu samotného. Například neexistuje žádná ochrana proti slovníkovým útokům při použití přihlašovacího jména a hesla. To při stále stoupajícím výkonům osobních počítačů klade stále větší nároky na složitost hesla a zvyšuje náchylnost k podlehnutí slovníkovému útoku. Navíc kontrolní TCP spojení nepodléhá autentizaci 17

a zprávy po něm zasílané nejsou nijak zašifrovány, což zjednodušuje podvržení nebo modifikaci těchto zpráv a vytváří prostor k jejich zneužití [9]. Protokol PPTP tedy umožňuje poměrně jednoduché vytvoření VPN sítě s plnou funkcionalitou a slabším až průměrným zabezpečením. Plně dostačuje tam, kde bezpečnost není primárním cílem a výpadky dostupnosti v některých lokalitách nezpůsobí žádné škody – v domácím využití, pro testovací účely atp. Pro využití v komerční sféře bude vhodnější vybrat některý ze tří zbývajících protokolů L2TP, SSTP, IKEv2.

2.2 L2TP, Layer 2 Tunneling Protocol Související RFC 2661 vyšlo již v roce 1999, tedy téměř současně s RFC definujícím PPTP, ale v operačních systémech Windows je podporován až od verze 2000. Tento VPN protokol vznikl kombinací vlastností dvou již existujících protokolů. Prvním byl již zmíněný PPTP od Microsoftu, druhým pak L2F vyvinutý Cisco Systems. Jako jeho předchůdce umožňuje rozdělit NAS na dvě zařízení, tentokrát L2TP Access Concentrator (LAC) a L2TP Network Server (LNS) a poskytuje i naprosto stejné výhody, tedy oddělení konce vytáčeného L2 spojení (končí na LAC) od konce PPP spojení (přerušeno až na LNS) a podporu multilink. Přenášeným protokolem je v základu opět PPP, zajišťující autentizaci a šifrování, takže největší výhodou L2TP při použití v jeho základní verzi je schopnost vytvořit tunel přes jakoukoli síť podporující přepínání paketů. Je ovšem možné využít L2TP v kombinaci s protokolem IPsec, který se postará o autentizaci a šifrování namísto PPP, přičemž téměř všechny ostatní vlastnosti zůstanou zachovány. Použití IPsec omezí L2TP tunely pouze na sítě poskytující IP konektivitu, standardní tunel VPN ale typicky probíhá přes Internet, který tento požadavek splňuje. Kombinace protokolů L2TP a IPsec nese oficiální označení L2TP/IPsec a je představena v RFC 3193 [27]. Díky protokolu IPsec poskytuje zabezpečení na velice dobré úrovni a je proto často používaná pro vytváření VPN tam, kde PPTP již nedostačuje. Protože použití základní verze L2TP se sebou nese pouze nepatrné zlepšení bezpečnosti a neexistuje jiný důvod pro jeho preferenci, dále se ve své práci věnuji pouze L2TP za současného použití protokolu IPsec. Jedním z efektů obalení tunelovaných dat do IPsec je vyšší průchodnost skrz firewally nacházející se na veřejné síti mezi stanicemi a tedy mimo naši kontrolu. Není totiž nutné, aby byl port UDP 1701 pro L2TP tunel otevřen na všech těchto zařízeních, postačuje jeho dostupnost na koncových stanicích. Po veřejné síti IPsec komunikuje na portu UDP 500, přes který je ustavena vazba SA, a přes IP Protocol ID 50/51 pro ESP/Authentication Trailer. Tyto porty a protokoly zpravidla nebývají na přenosové síti blokovány, nicméně jejich dostupnost je nutnou podmínkou k úspěšnému uskutečnění spojení. Kontaktovat L2TP server není možné ze zařízení připojených přes WPS a pro průchod přes NAT musí server podporovat funkci NAT-Traversal. Tato funkce umožní v první fázi vyjednávání IPsec klíčů zjistit přítomnost NAT a za pomoci komunikace přes port UDP 4500 zajistit přístup do L2TP VPN. Samozřejmě port UDP 4500 musí být dostupný u klienta, serveru a po celé trase veřejnou sítí [28]. Ustavení L2TP tunelu mezi koncovými body probíhá následovně. Nejprve je nutné vytvoření kontrolního kanálu. Jeho význam je stejný jako u PPTP, tedy zasílání oznámení o vysílání, 18

příjmu, změně vlastností linky atp. Probíhá pomocí protokolu UDP na portu 1701 a v případě ztráty paketu se zprávou podporuje přeposlání. Pořadí kontrolních paketů je udržováno pomocí sekvenčních čísel v hlavičce každého takového paketu. Pokud některý dorazí mimo určené pořadí, je zahozen. Data jsou následně přenášena pomocí stejného protokolu i portu, ale na rozdíl od kontrolních zpráv nejsou datové pakety číslovány a pořadí tak nemusí být zachováno. Žádost o vytvoření je zahájena zprávou Start-Control-Connection-Request na kterou by měla protistrana odpovědět Start-Control-Connection-Reply, klient pak ještě jednou potvrdí zprávou Start-Control-Connection-Connected. Součástí výše uvedených zpráv může být volitelný 3-way handshake, podporovaný přímo L2TP a zajišťující autentizaci na úrovni MsCHAPv1. Po těchto třech krocích je možné pokračovat vytvořením datového spojení (session). Jeden L2TP tunel může obsahovat teoreticky až 65 536 jednosměrných session a mezi dvěma stanicemi může existovat libovolné množství tunelů. Každý z tunelů ale musí mít vlastní kontrolní kanál. Session je pak vytvořena žádostí o povolení k přenosu a jejím potvrzením na kontrolním kanálu příslušného tunelu. Původní IP pakety od klienta posílané do některé session jsou obaleny hlavičkami několika různých protokolů v pořadí ilustrovaném na obrázku.

Obrázek 11 L2TP paket

PPP rámec tentokrát není zašifrován, spoléhá na ochranu zprostředkovanou některou z vyšších vrstev, jinak se shoduje s PPP rámcem protokolu PPTP. Dále je přidána L2TP hlavička s identifikačním číslem tunelu a příslušné session. ID tunelu se přiřazuje každé stanicí nezávisle, takže každý konec jednoho tunelu bude mít obvykle rozdílný identifikátor. Tyto ID jsou přiřazeny a sděleny protistraně při vytvoření kontrolního spojení. Následující hlavička UDP obsahuje pouze číslo portu 1701 pro zdroj i cíl. IP hlavička obsahuje adresy zdroje a cíle, které jsou použity pro směrování paketu veřejnou sítí. Za IP hlavičku je přiřazena hlavička protokolu IPsec, ta obsahuje informace o algoritmech použitých k zajištění autentizace, integrity a důvěrnosti dat. Za zašifrovanými daty se nachází Encapsulated Security Payload (ESP) s daty zarovnávajícími obsah na délku nutnou pro zvolené blokové šifrování a Authentication Trailer umožňující per-packet ověření totožnosti příjemce a odesilatele.

19

Obrázek 12 L2TP/IPsec paket

Použití protokolu IPsec přidává k navázání tunelového L2TP spojení několik akcí, nezbytných pro zajištění určité úrovně zabezpečení. Nejprve je nutné vytvoření tzv. Security Association (SA). Tato vazba určuje typ a délku použitých šifrovacích klíčů, druh šifrovacích algoritmů a další parametry. Pro IPsec bývá zpravidla realizována přes protokol Internet Key Exchange (IKE). Po dohodnutí bezpečnostních parametrů SA může být vytvořen zabezpečený kanál pomocí IPsec ESP v transportním módu. Teprve po těchto krocích lze zahájit vyjednávání se vzdáleným serverem o ustavení L2TP tunelovaného připojení. Díky protokolu IPsec jsou chráněna nejen přenášená data, ale také i veškeré informace o tunelovaném přenosu, což znemožňuje útočníkovi snadno zjistit typ probíhající komunikace. Protokol L2TP vykazuje vyšší bezpečnost přenášených dat a vyšší průchodnost přenosovou sítí než protokol PPTP. V rámci jednoho tunelu také může probíhat více než jedna session, takže tento tunel může sloužit pro přenos více VLAN. Pravděpodobně jedinou nevýhodou oproti svému předchůdci je potenciálně nižší rychlost přenosu. Tu se sebou nese využití protokolu IPsec, který má oproti PPP mnohem vyšší režijní náklady na zajištění zabezpečení. Přes tuto negativní vlastnost je zvýšení bezpečnosti natolik výrazné, že preference L2TP před PPTP je doporučená ve všech případech snad kromě jednoduchých domácích VPN sítí.

2.3 SSTP, Secure Socket Tunneling Protocol Po výrazném zvýšení bezpečnosti poskytovaných VPN služeb, které přineslo L2TP, zbývalo vyřešit problém dostupnosti spojení mezi klientem a serverem. Nedostupnost serveru velice často způsobil jeden z následujících důvodů: 1) Na cestě mezi klientem a serverem se nachází zařízení blokující některý z portů nutných pro komunikaci užitého VPN protokolu. 2) Klient se pokouší připojit z místa se soukromým IP adresovým prostorem a zařízení NAT nepodporuje, nebo má zakázáno přeposílání paketů užitého VPN protokolu. 3) Připojení klienta k přenosové síti (Internetu) je zprostředkováno webovým proxy serverem. SSTP měl tyto problémy odstranit, což se díky využití protokolu SSL/TLS povedlo. SSL/TLS je totiž vyžadován pro zabezpečenou HTTP komunikaci (HTTPS) a je proto propouštěn a přeposílán prakticky všemi zařízeními zajišťující směrování v Internetu. Protokol byl představen společností Microsoft v roce 2007. RFC nebylo nikdy vydáno, což ve svém důsledku zavinilo pomalejší rozšíření do zařízení konkurenčních společností a tím i slabší podporu mimo operační systémy Windows. V těch je obsažen ve všech verzích od 20

Windows Vista Service Pack 1 a Windows Server 2008. Dokumentace k protokolu SSTP byla nedávno uvolněna a nyní je volně dostupná na internetových stránkách Microsoftu. Kromě vysoké průchodnosti dále umí vytvořit tunel přes sítě založené na aktualizované verzi protokolu IPv6 a dokáže IPv6 pakety také přenášet uvnitř tunelu. Nutné podmínky, které musí přenosová síť splnit jsou tentokrát minimální. SSTP má pouze jediný požadavek, potřebuje na zařízeních po celé své trase otevřený port TCP 443. Poradí si i s web proxy serverem a NAT bez jakýchkoli úprav jakéhokoli z účastnících se zařízení. Vytvoření zabezpečeného tunelu se tentokrát skládá z více kroků a několika málo volitelných možností. Jednotlivé kroky jsou očíslovány podle pořadí, ve kterém se musí vykonat. 1) Klient kontaktuje SSTP server na jeho veřejné IP adrese na TCP portu 443. Je vytvořeno TCP spojení. 2) Klient odesílá iniciační zprávu protokolu SSL/TLS žádající o ustavení zabezpečeného spojení. V tuto chvíli se musí server prokázat zasláním svého certifikátu. 3) Obdržený certifikát je klientem ověřen. Pokud odpovídá, klient může zvolit klíč relace a zašifrovaný jej odeslat serveru. Jako volitelný krok je možné v této fázi vyžadovat autentizaci klienta jeho vlastním certifikátem. 4) SSTP server obdrží klíč k SSL komunikaci, všechny další zprávy již mohou být zašifrovány. 5) Proběhne request-response vytvoření HTTPS spojení iniciované klientem. 6) Může být vytvořen SSTP tunel zprávou Call-Connect-Request (klient) a Call-ConnectAck (server). Tento tunel slouží jak pro přenos dat, tak i kontrolních zpráv. 7) V této fázi se autentizuje klient pomocí některé metody, kterou poskytuje protokol PPP. Pokud je úspěšná, klient dostane přidělenu lokální IP adresu a získá přístup k funkcím uvnitř VPN.

Obrázek 13 SSTP paket

Před odesláním dat tunelem k cílové stanici je nutné postupně je obalit hlavičkami protokolů využitých k přenosu. Výstupní aplikační data nejprve dostanou číslo cílového portu a poté IPv4 nebo IPv6 hlavičku podle verze IP protokolu běžící na VPN síti. Následuje obalení protokolem PPP a SSTP hlavička. Ta obsahuje verzi protokolu, bit určující zda se jedná o kontrolní zprávu a délku připojených dat. Všechna tato data se posílají výhradně zašifrovaná klíčem relace SSL. Druhá TCP hlavička obsahuje číslo portu TCP 443 a nakonec je přiřazena výslednému paketu i druhá IP hlavička s veřejnou adresou SSTP serveru. I tato IP adresa může být verze IPv6 nebo IPv4 podle typu přenosové sítě. V rámci přenosové sítě může útočník tedy zjistit pouze zdrojovou a cílovou adresu a typ přenášené komunikace – SSL. Informace o tunelovaném připojení je skrytá v zašifrované části. 21

Protokol SSL vyžaduje k autentizaci použití certifikátů ověřených certifikační autoritou. Jedná se o jeden z nejbezpečnějších způsobů autentizace a v případě využití možnosti povinného ověření totožnosti klienta již v SSL fázi poskytuje velmi vysokou míru ochrany. Každý klient připojující se k takovému SSTP serveru ale musí mít instalovaný vlastní ověřitelný certifikát. Vzrůstají tedy nároky na správu takové sítě. SSTP předčí protokoly PPTP a L2TP téměř ve všech ohledech. Poskytuje spolehlivější spojení dostupné i přes síťové prvky blokující ostatní protokoly a autentizace i šifrování je na mnohem vyšší úrovni. Přes tyto výhody má využití protokolu i svá úskalí. Vzhledem k tomu, že byl dlouhou dobu považován chráněným vlastnictvím Microsoftu, nebyl integrován do ostatních operačních systémů. Pokud je tedy nutné do VPN sítě připojit i zařízení s operačním systémem jiným než Microsoft Windows, je třeba využít podpůrný software třetí strany. To může představovat další zvýšení nároků na správu sítě a dotyčných zařízení, pokles spolehlivosti, bezpečnostní problémy atp. Jako další nevýhodu oproti předchozím protokolům lze zmínit chybějící podpora vytváření Site-to-Site VPN spojení.

2.4 IKEv2, Internet Key Exchange v2 Jinak také VPN Reconnect nebo Agile VPN. Jedná se o poslední z řady protokolů dostupných ve Windows 7, v nichž byl poprvé představen, a jeho konstrukce je zaměřena zejména na řešení problému mobility. V případě vzdáleného přístupu ze zařízení, které je v pohybu, může nastat situace, kdy klient na okamžik ztratí spojení k přenosové síti. Jako příklad lze uvést uživatele s notebookem a 3g mobilním připojením k Internetu v jedoucím autě. Jakmile dojde ke ztrátě signálu mobilní sítě, byť pouze na okamžik – třeba při průjezdu tunelem, ustavené spojení k VPN serveru je ukončeno. Obnovení a restart všech v tu dobu probíhajících datových přenosů musí uživatel provést manuálně. K řešení obdobných problémů byl k IKEv2 přidán protokol Mobility and Multihoming Protocol (MOBIKE). Ten umožňuje změnit IP adresy již ustaveného tunelu, tedy u existujícího bezpečnostního přiřazení (SA). Mobilní klient tak zůstává připojen k serveru při přechodu mezi různými přístupovými body. Obdobně může při pádu rozhraní použitého k vyjednání tunelového spojení využít jiné, pokud jím disponuje a rozhraní je připojeno k přenosové síti. Mobilní zařízení se tak může libovolně pohybovat mezi přístupovými body i bezdrátovými sítěmi a plynule přecházet mezi wi-fi, 3g (nebo jakýmkoli jiným mobilním připojením, jako starší GPRS nebo EDGE) a fyzickým spojením jako Ethernet při zachování původní autentizace. Protokol MOBIKE je do IKEv2 ve Windows 7 integrován skrze tzv. Mobility Manager, který se stará automaticky o výše uvedené funkce a nechá se do jisté míry konfigurovat uživatelem. Klient může nastavit dobu, po kterou MOBIKE vyčkává na obnovení síťové konektivity, nebo podporu mobility úplně vypnout. Mobility Manager umožňuje VPN tunel přepínat mezi třemi stavy. Stav Connected odpovídá ostatním VPN protokolům a umožňuje přenos dat a funkci aplikací komunikujících se zařízeními v privátní síti. Pokud dojde k pádu rozhraní či jakémukoli jinému problému způsobujícímu nedostupnost VPN serveru a zároveň není dostupné žádné jiné aktivní rozhraní, přepne manager tunel do stavu Dormant. Všechny datové přenosy jsou pozastaveny, nicméně pokud dojde k obnovení spojení, mohou 22

pokračovat od bodu přerušení. Jakmile manager detekuje nějaké aktivní rozhraní, přepne tunel do stavu Waiting -to-reconnect a pokouší se kontaktovat VPN server. Pokud server odpoví, tunel přechází zpět do Connected stavu [29]. Protože zabezpečení IKEv2 spoléhá na IPsec, neposkytuje natolik robustní průchodnost přenosovou sítí jako SSTP. Ta, jakož i požadavky na dostupné porty, odpovídá spíše L2TP. IKEv2 vyžaduje otevřený port UDP 500 pro datové přenosy, případně i UDP 4500 pokud server i klient podporují IPsec NAT-Traversal. Posledním požadavkem je port IP Protocol ID 50 pro IPsec ESP. IKEv2 tunel dokáže projít přes NAT při použití NAT-Traversal verze protokolu IPsec. V takovém případě se chová obdobně jako L2TP (viz podkapitola L2TP – nutné podmínky). Pokud se klient ovšem nachází za web proxy serverem, nebude schopen IKEv2 VPN server kontaktovat. Pokud jsou splněny všechny podmínky kladené na přenosovou síť může být zahájen pokus o připojení k serveru. Jako první krok při ustavování spojení musí být domluveno bezpečnostní přiřazení (SA). Vyžadováno je ustavení dokonce minimálně dvou SA. Jedno pro IKEv2 jako kontrolní kanál spravující druhý typ podřízených SA. Tato podřízená bezpečnostní přiřazení se nazývají CHILD_SA a pro potřeby IKEv2 VPN se řídí protokolem IPsec. Vyjednávání se skládá ze dvou fází. V první fázi, IKE_SA_INIT, klient kontaktuje server na portu UDP 500, zpráva obsahuje seznam algoritmů podporovaných klientem pro šifrovanou komunikaci. Server může spojení odmítnout v případě, že se v přijatém seznamu nenachází žádný společný algoritmus. Pokud žádost o spojení přijme, odešle klientu potvrzovací zprávu s šifrovacím algoritmem, který bude použit. Obě zprávy také obsahují Diffie-Hellman výměnu k ustavení tzv. master klíče. Po této výměně je veškerá další IKEv2 komunikace zašifrovaná, ale žádná z koncových stanic se zatím neautentizovala. Autentizaci má na starost druhá fáze, IKE_AUTH, která ověří totožnost stanic podle certifikátu nebo pomocí PSK. Zároveň dojde automaticky k ustavení první CHILD_SA. IKEv2 umožňuje později vytvořit další pomocí kontrolních zpráv. Ty mohou být zasílány právě po úspěšné autentizaci obou zařízení a slouží k vytváření, rušení a změnu parametrů jednoho nebo i více IPsec tunelů a musí striktně dodržovat pravidlo request/response (jsou vždy párové). Vytvoření CHILD_SA může zahájit kterákoli z autentizovaných stanic zasláním kontrolní zprávy CREATE_CHILD_SA, protějšek akceptuje odpovědí stejnou zprávou. Pouze v těchto dvou zprávách dojde k dohodnutí bezpečnostních parametrů, odvození prvních IPsec klíčů z master klíče IKEv2 a výběru šifrovacího algoritmu pro nově vzniklé SA. Tunelové spojení k serveru je pak připraveno k přenosu dat. Ukončení spojení může vyvolat rovněž kterýkoli z účastníků a to dvěma způsoby. Zrušením některé CHILD_SA kontrolní zprávou DELETE_PAYLOAD s příslušným identifikátorem, nebo celého IKEv2 kanálu toutéž zprávou, obsahující na místě identifikátoru nulu. Při terminaci kanálu dojde i k automatickému ukončení všech jemu podřízených CHILD_SA spojení.

23

Standardní datový paket přenášený tunelem mezi klientem a serverem vypadá následovně:

Obrázek 14 IKEv2 paket

Původní IP hlavička cílového zařízení v privátní síti a data jsou zašifrovány protokolem IPsec. Nová přidělená IP adresa odpovídá adrese IKEv2 serveru a hlavička Encapsulated Security Payload provádí stejnou funkcí jako u L2TP, tedy zarovnává data na určitou délku. Největší výhodou oproti předchozím protokolům je bezesporu podpora mobility. Nejen že dovoluje uživatelům pohybovat se a při tom měnit přístupové body do sítě. Výhodu přináší i statickým uživatelům ve formě automatické změny rozhraní v případě pádu původního. To vše vždy bez nutnosti znovu zadávat autentizační informace. Poskytovaná úroveň zabezpečení je srovnatelná s L2TP (IPsec) a tedy velice dobrá. Jako nevýhoda se nabízí snad pouze nižší průchodnost přenosovou sítí, kterou, opět obdobně jako u L2TP, zaviňuje IPsec. Ovšem pouze ve srovnání s SSTP, jenž jediný dokáže projít skrz web proxy server. IKEv2 také podporuje vytváření výhradně Point-to-Site VPN.

24

2.5 Srovnání VPN protokolů Tabulka 1 Shrnutí VPN protokolů

Tabulka shrnuje základní vlastnosti rozebíraných protokolů. PPTP nabízí nejvyšší míru podpory jak mezi operačními systémy firmy Microsoft, tak i v systémech jiných společností jako iOS nebo tzv. Unix-based, s unixovým jádrem. Ve srovnání s alternativami ale zaostává na poli zabezpečení a to jak v autentizaci, tak v šifrování. Datové přenosy, byť zašifrované, mohou být odposlechnuty či pozměněny s využitím chyb zmíněných v první kapitole. Průchodnost prvky přenosové sítě je rovněž nízká. L2TP oproti tomu poskytuje vyšší bezpečnostní úroveň autentizace i šifrování a lepší průchodnost sítí. Podpora na ostatních zařízeních je mírně nižší než u PPTP, ale stále velmi dobrá. Největší výhoda protokolu SSTP nad ostatními spočívá v průchodnosti sítí, poradí si prakticky se všemi mezilehlými prvky, na které může narazit. Zabezpečení poskytované pomocí certifikátů, PSK a symetrického šifrování splňuje i vysoké nároky na důvěrnost a integritu dat. Zásadním problémem je ale jeho podpora, která na operačních systémech jiných než Windows prakticky neexistuje. Také vylučuje možnost připojení počítačů se systémem Windows XP, který je přes nedávné ukončení podpory stále oblíben u řady, převážně domácích, uživatelů. Internet Key Exchange v2 jako jediný nabízí podporu mobility, tedy automatické navázání spojení se serverem, pokud bylo na okamžik ztraceno. Zabezpečení v podobě vylepšeného postupu autentizace IKE v kombinaci s protokolem IPsec rovněž nemá příliš mnoho slabých 25

míst. V průchodnosti sítí se řadí po bok protokolu L2TP, vyžaduje otevření stejných portů a neporadí si s webovým proxy serverem. Jeho podpora v operačních systémech je ucházející, ale protokol již nebyl implementován ve Windows XP, ani Windows Vista, což tyto dva systémy vylučuje z IKEv2 VPN.

26

3. Konfigurace serveru a klienta Poznámka: Všechny uvedené příkazy ke konfiguraci FreeBSD serveru vždy předpokládají spuštění uživatelem s oprávněním superuser (root), pokud není uvedeno jinak. Nastavení Windows 7 klienta je možné provádět i s pouhým uživatelským oprávněním. VPN server představuje virtuální stroj založený v programu VirtualBox verze 4.2.16_OSE s jediným síťovým rozhraním, připojeným přímo k přenosové síti – Internetu. Používá operační systém FreeBSD ve verzi 8.4 modifikovaný softwarem Kernun2 3.8.1 virtual edition, jehož autorem je společnost Trusted Network Solution. Kernun upravuje původní FreeBSD kernel a obsahuje podporu funkcí jako vlastní firewall a antivirový a antispywarový software. Jediná zjištěná odlišnost, mající vliv na konfiguraci VPN, se nalézá v podpoře IPsec, který je v jádru Kernunu již obsažen, zatímco do kernelu systému FreeBSD musí být přidán. Ve chvíli, kdy se konfigurace čistého FreeBSD liší od Kernun FreeBSD, uvádí text oba dva způsoby nastavení. Jako klientská zařízení slouží dva notebooky s operačním systémem Windows 7 Ultimate SP1, verze 6.1, build 7601. Při testování funkce spojení využívají vestavěný VPN klientský software bez jakýchkoli jiných než uvedených úprav.

3.1 PPTP 3.1.1 Server Operační systém FreeBSD ve verzi 8.4 vytvoření PPTP serveru přímo nepodporuje. Pokud jej ale nainstalujete včetně nabídky doporučených aplikací, tzv ports collection, nachází se všechen potřebný software již v datovém úložišti počítače ve složce /usr/ports a stačí jej nainstalovat a konfigurovat. Pokud se ports collection na počítači nenachází, lze ji získat pomocí následujících příkazů v pořadí [30]: portsnap fetch

– stáhne komprimovanou nabídku aplikací do složky /var/db/portsnap

portsnap extract

– extrahuje staženou nabídku do složky /usr/ports

Nabídka aplikací obsahuje program mpd5, který je navržen pro příjem různých verzí příchozích PPP spojení, mezi nimi i PPTP. Nachází se ve složce /usr/ports/net/mpd5. Podle specifikace by mělo být možné přijímat a spravovat velké množství PPTP tunelů při zachování únosných nároků na výpočetní výkon. Podporuje autentizační protokoly MsCHAPv1 a v2 i EAP, bohužel ale jinou verzi EAP než využívá protokol PPTP (EAPMsCHAPv2) a tedy tuto možnost nelze k autentizaci využít.

2

oficiální webová stránka: http://www.kernun.cz/

27

Cíl Cílem je vytvořit PPTP VPN server, schopný přijmout a směrovat do privátní sítě více souběžných tunelů. Jako autentizační protokol slouží MSCHAPv2 – nejsilnější podporovaný, data šifruje MPPE 128bit. 1. Krok – instalace mpd5 Instalaci zahájí příkaz: make install clean -C /usr/ports/net/mpd5 Po jeho spuštění se objeví konfigurační obrazovka instalace mpd5, kterou můžete ponechat v nabízeném nastavení. Samotná instalace by měla zabrat několik minut a po úspěšném dokončení zobrazit bezpečnostní upozornění (Security Report). Jakmile je instalace dokončena, ve složce /usr/local/etc/mpd5 se objeví několik souborů s příklady konfigurace (mpd.conf.sample, mpd.secret.sample, mpd.script.sample), na nastavení programu ale nemají vliv. Všechny vlastnosti serveru jako adresní prostor, použité bezpečnostní algoritmy atd. se nastavují v téže složce v souboru mpd.conf. Mpd5 se skládá z několika vrstev, přičemž každá se stará o správu své části spojení. Hierarchie vypadá následovně [31]: 1. Link Layer – představuje jedno point-to-point spojení. V tomto případě jeden PPTP tunel mezi vzdáleným klientem a serverem. Nabízí nastavení Maximum Transmit Unit (MTU), keep-alive interval a výběr autentizačního protokolu. 2. Bundle Layer – sdružuje více spojení od jednoho klienta do jedné virtuální linky. Umožňuje PPP multilink. 3. IP Control Protocol Layer – má na starost přidělování IP adres klientům. Při konfiguraci je nunté definovat lokální IP rozsah. 4. Interface Layer – tato vrstva odpovídá rozhraní mezi serverem a klientem, které přijímá pakety po jejich cestě tunelovaným spojením. Konfiguruje mimo jiné idle timeout, po kterém může být spojení ukončeno. 2. Krok – konfigurace mpd5 Celý konfigurační soubor mpd.conf, použitý k nastavení FreeBSD 8.4 PPTP serveru, se nachází k nahlédnutí v příloze. Jednotlivé příkazy jsou rozděleny podle vrstev mpd5 ke kterým přísluší. Aby PPTP server startoval s uvedeným nastavením automaticky po každém restartu hostitelského počítače, musí být přidány následující řádky do souboru /etc/rc.conf: mpd_enable="YES" mpd_flags="-b -s mpd5" Seznam uživatelů, kteří mají povoleno PPTP připojení ze vzdáleného počítače, obsahuje soubor /usr/local/etc/mpd5/mpd.secret. Jednoho uživatele definuje dvojice povinných údajů: uživatelské jméno a heslo. Nepovinné je uvedení preferované IP adresy, náležející do rozsahu adres poskytovaných PPTP serverem. Formát zápisu má následující tvar (konkrétní příklad lze najít v souboru mpd.secrets v příloze A): 28

jméno"whitespace znak"heslo"whitespace znak"IP_adresa 3. Krok – omezení přístupu ke klíčům Po vytvoření obou souborů zbývá zabezpečit je proti změně jiným uživatelem. Oprávnění ke změně by mělo zůstat pouze uživateli superuser. To provedete příkazem chmod s následujícími parametry: chmod 0700 /usr/local/etc/mpd5 4. Krok – Spuštění serveru Nakonec již stačí spustit server příkazem: /usr/local/etc/rc.d/mpd5 start Konzoli pro konfiguraci za běhu vyvolá příkaz telnet 0.0.0.0 5005 kde 0.0.0.0 reprezentuje IP adresu, na které PPTP server naslouchá. Změna souboru mpd.conf se projeví nejdříve po restartu serveru. Od této chvíle se mohou uživatelé definovaní v souboru mpd.secret připojovat do PPTP VPN sítě ze vzdálených zařízení. Jejich maximální počet omezuje teoreticky počet volných IP adres v lokálním rozsahu, prakticky pak výpočetní výkon PPTP serveru.

3.1.2 Klient Konfigurace Windows 7 PPTP klienta je relativně přímočará. V Centru síťových připojení a sdílení zvolte volbu Nastavit nové připojení nebo síť, poté možnost Připojit k firemní síti a Použít připojení k Internetu (VPN). V okně, které se otevře vyplňte IP adresu, na které naslouchá PPTP server, název spojení (PPTP VPN), zaškrtněte Nyní nepřipojovat a potvrďte. Následující okno vyžaduje jedno z definovaných uživatelských jmen a příslušné heslo. Po vyplnění a potvrzení je vytvořen nový síťový adaptér pro VPN spojení. Tento adaptér lze nastavit ještě o něco optimálněji. V jeho vlastnostech, na záložce Zabezpečení, vyberte Typ sítě VPN: Protokol PPTP a zkontrolujte, zda je jako možnost šifrování dat vybráno Vyžadovat šifrování. Ověřování by mělo být konfigurováno následovně: zaškrtněte Povolit tyto protokoly a pak již pouze Protokol MS-CHAPv2. Jako další změnu doporučuji na záložce Sítě otevřít Vlastnosti protokolu IPv4, zvolit možnost Upřesnit a zrušit zaškrtnutí Používat výchozí bránu vzdálené sítě. Tak bude veškerá komunikace, která není přímo určena některému zařízení virtuální sítě, směrována přes místní NAS. V opačném případě by musel veškerou komunikaci klienta směrovat PPTP server, což by způsobovalo zbytečnou zátěž na jeho výpočetní výkon.

29

3.1.3 Výsledek Jakmile je konfigurace klienta kompletní, připojení k VPN síti lze vyvolat vybráním příslušného adaptéru, vyplněním jména a hesla a potvrzením. PPTP server je schopen přijmout spojení od většího množství klientů, až do naplnění IP adresového rozsahu pro lokální síť, nebo do využití veškeré své výpočetní kapacity pro správu příchozích spojení. Klient pro připojení k PPTP serveru musí znát své přihlašovací jméno a heslo. Pokud má ale přidělenu IP adresu pouze s lokální platností, připojení k serveru se nezdaří. Rovněž nemůže klient využívat webový proxy server. Pro PPTP server platí stejné podmínky. Žádná další omezení nebyla při testování PPTP VPN s FreeBSD 8.4 serverem a Windows 7 klienty nalezena.

3.2 L2TP 3.2.1 Server K vytvoření L2TP serveru musí být FreeBSD instalováno s celým source tree, nejlépe i s ports collection. Bez source tree by se nepodařilo zkompilovat nový kernel, nezbytný pro funkci IPsec, a v ports collection se nachází programy mpd5 a IPsec Tools. Pokud chybí ports collection, lze ji získat pomocí postupu z předchozí kapitoly (PPTP). Chybějící source tree indikuje prázdná složka /usr/src. Pro jeho získání existují dva postupy. Jednodušší řešení spočívá ve spuštění příkazu: sysinstall Soubory source tree se nachází v následujícím okně v podsložce Configure –> Distributions – > src –> base a sys [32]. Protože ale FreeBSD verze 8.4 není nejaktuálnější dostupnou, oficiální ftp servery ji nadále neposkytují a k instalaci je třeba původní instalační DVD. V případě, že instalace z DVD nepřichází v úvahu, zbývá možnost stažení ze subversion úložiště. To musí být nejdříve instalováno: cd /usr/ports/devel/subversion make install clean A poté spárováno s odpovídající FreeBSD verzí a lokální složkou: svn co svn://svn.freebsd.org/base/release/8.4.0 /usr/src Potřebné zdrojové soubory jsou ihned staženy a umístěny do specifikované složky [30]. Cíl Cílem je vytvořit L2TP VPN server, schopný přijmout a směrovat do privátní sítě více souběžných tunelů. Jako autentizační protokol lze u L2TP mezi prostředími FreeBSD 30

a Windows využít pouze starší MSCHAP. Zašifrování komunikace má probíhat pomocí ESP části protokolu IPsec. 1. Krok – modifikace kernelu Upozornění: Tento a následující krok jsou vyžadovány pouze při instalaci serveru na čisté FreeBSD 8.4. Kernel kombinující FreeBSD 8.4 a Kernun nemusí být nijak upravován a v případě konfigurace takového zařízení přeskočte prosím až ke kroku 3. Jakmile FreeBSD obsahuje source tree i ports collection, přichází na řadu první krok k vytvoření L2TP serveru – modifikace stávajícího kernelu moduly IPsec a IPFirewall. Postup kompilace a aktivace nového kernelu podrobně popisuje FreeBSD Handbook 3 a proto mu nebudu věnovat ve své práci příliš prostoru [30]. Konfigurační soubor nového kernelu se od původního liší následujícími řádky, přidanými na konec souboru: options options device options device options options options options options options options

IPSEC IPSEC_NAT_T crypto IPSEC_FILTERTUNNEL enc IPFIREWALL IPFIREWALL_VERBOSE IPFIREWALL_VERBOSE_LIMIT=5 IPFIREWALL_FORWARD IPFIREWALL_NAT LIBALIAS IPDIVERT

První dva řádky zapnou podporu IPsec s funkcí NAT Traversal, třetí poskytuje subsystém podpory kryptografických operací v rámci kernelu. Čtvrtý a pátý řádek vytváří virtuální rozhraní k filtraci paketů tunelu přes firewall. Implementace firewallu do kernelu obsahují zbývající řádky, kromě posledních dvou. LIBALIAS obsahuje sbírku funkcí pro aliasing a dealiasing IP adres paketů, tedy podpůrné funkce k Network Address Translation. K podobnému účelu je přítomen i IPDIVERT. 2. Krok – konfigurace firewallu Nově vytvořený firewall by nepropouštěl žádná příchozí spojení bez následující změny souboru /etc/rc.conf: # IPsec IPFirewall konfigurace firewall_enable="YES" firewall_script="/etc/rc.firewall" firewall_type="OPEN" firewall_quiet="NO" firewall_logiging="YES"

3

Kapitoly 9.4 a 9.5 se věnují úpravě a instalaci vlastního kernelu.

31

Tak dojde ke spuštění firewallu po každém startu hostujícího počítače automaticky. Firewall bude používat defaultní nastavení (skript) poskytované FreeBSD. 3. Krok – instalace a nastavení mpd5 Na rozdíl od PPTP, mpd5 zde zařizuje pouze autentizaci, šifrování přenosu ponechává na IPsec Tools. Instalace probíhá stejně jako u PPTP a konfigurace použitá k zajištění služeb L2TP serveru bude velice podobná předchozí. Soubor mpd.conf se liší od předchozího v použití MsCHAPv1 k autentizaci stanic a povolení menší MTU, aby nedocházelo k fragmentaci paketů zapouzdřených ESP. Celý konfigurační soubor můžete nahlédnout v příloze k L2TP. Druhý soubor mpd5, mpd.secret, má naprosto stejnou syntax jako v předchozím případě a pokud jsou uživatelé a hesla stejní jako u PPTP, není jej třeba ani nijak měnit. Po dokončení všech úprav v těchto dvou souborech by, opět obdobně jako v předchozím případě, mělo následovat omezení jejich přístupových práv pouze na uživatele superuser: chmod 0700 /usr/local/etc/mpd5 4. Krok – instalace a nastavení IPsec Tools Instalace probíhá z ports collection z umístění /usr/ports/security/ipsec-tools příkazem: make install clean -C /usr/ports/security/ipsec-tools Na obrazovce nastavení možností instalace lze ponechat nabízené nastavení a pokračovat. Část právě nainstalované nástrojové sady s názvem racoon zajišťuje šifrování v rámci tunelovaného spojení. Následovat bude tedy konfigurace této komponenty. Do složky /usr/local/etc/racoon vytvořte nový soubor racoon conf. Musí obsahovat v první řadě IP adresu a porty, na nichž má L2TP server naslouchat. Dále globální nastavení IPsec, jako povolení fragmentace a módu NAT Traversal a v neposlední řadě také profily spojení, které bude postupně nabízet připojujícím se klientům. Profily mohou obsahovat různé metody autentizace i šifrování a přijat je první profil, na kterém se server a klient shodnou. Soubor racoon.conf použitý ke konfiguraci FreeBSD L2TP serveru je obsažen v příloze. 5. Krok – výběr IPsec klíče Ani po nastavení z předchozího kroku ještě IPsec Tools racoon není připraven dojednávat SA. K ustavení bezpečnostního přiřazení zbývá určit sdílený klíč (Preshared Key, PSK), nezbytný k autentizaci stanice před vytvořením SA. Definuje se v souboru /usr/local/etc/racoon/psk.txt v obdobném formátu, jako dvojice uživatelské jméno a heslo v souboru mpd.secret (příklad takového souboru se nachází v příloze): IP_adresa"whitespace znak"PSK Vzdálená stanice při prokazování identity používá IP adresu ke stejnému účelu, jako uživatel své uživatelské jméno a tato adresa je pevně svázána s PSK jí příslušícím. Takový přístup umožňuje L2TP serveru jednoznačně určit identitu vzdáleného počítače ve fázi IPsec autentizace, ale rovněž představuje funkční problém. Jakmile je klientu přidělována IP adresa dynamicky z nějakého rozsahu adres místního DHCP serveru, není možné předem tuto adresu 32

odhadnout a přiřadit jí PSK. IPsec Tools racoon tuto funkci nepodporuje záměrně. Nedovoluje zadat místo IP adresy ani rozsah, ani tzv. wildcard (*), která by se aplikovala na jakoukoli neznámou IP adresu žádající o spojení. Racoon tak poskytuje vyšší než obvyklou úroveň zabezpečení, nicméně požaduje od všech klientů pevné IP adresy. Stejně jako soubor mpd.conf s uživatelskými jmény a hesly, u psk.txt povolte přístupová práva pouze uživateli superuser: chmod 0700 /usr/local/etc/racoon/psk.txt Toto omezení přístupu je povinné. Pokud by nebylo provedeno, racoon při každém pokusu o L2TP připojení odmítne porovnat PSK serveru s klientským a zaloguje ERROR: /usr/local/etc/racoon/psk.txt has weak file permission. 6. Krok – IP forwarding a automatický start Přeposílání paketů musí fungovat, aby se po přijetí L2TP serverem dostali k příslušnému zařízení na privátní síti a naopak. V souboru /etc/sysctl.conf se musí nacházet dva následující řádky: net.inet.ip.forwarding=1 net.inet6.ip6.forwarding=1 Aby všechny procesy serveru startovaly automaticky, aktivujte je v souboru /etc.rc.conf: ipsec_enable="YES" ipsec_program="/usr/local/sbin/setkey" ipsec_file="/usr/local/etc/racoon/setkey.conf" racoon_enable="YES" racoon_flags="-l /var/log/racoon.log" mpd_enable="YES" 7. Krok – otevření portů L2TP vyžaduje otevřené porty 1701, 500, 4500 a IP port ESP. Zkontrolujte, zda jsou otevřené v souboru filtrování portů – /etc/pf.conf: pass in on $ext_if inet proto udp from any to (self) port { 1701, 500, 4500 } pass in on $ext_if inet proto esp 8. Krok – spuštění serveru Restartováním hostitelského počítače dojde ke spuštění všech procesů L2TP serveru. Nakonec již stačí spustit server příkazem: /usr/local/etc/rc.d/mpd5 start Konzoli pro konfiguraci za běhu vyvolá příkaz telnet 0.0.0.0 5005 33

kde 0.0.0.0 reprezentuje IP adresu, na které L2TP server naslouchá. Velice užitečný racoon debug v případě nesprávné funkce serveru můžete vyvolat restartováním procesu a zobrazením logu v popředí: service racoon stop racoon -ddF Od této chvíle se mohou uživatelé definovaní v souboru mpd.secret připojovat do L2TP VPN sítě, ale pouze ze vzdálených zařízení, jejichž IP adresy obsahuje soubor psk.txt, a s pomocí PSK příslušného k jejich IP adrese. Jejich maximální počet omezuje teoreticky počet volných IP adres v lokálním rozsahu, prakticky pak i výpočetní výkon L2TP serveru.

3.2.2 Klient Konfigurace Windows 7 L2TP klienta je relativně přímočará. V Centru síťových připojení a sdílení zvolte volbu Nastavit nové připojení nebo síť, poté možnost Připojit k firemní síti a Použít připojení k Internetu (VPN). V okně, které se otevře vyplňte IP adresu, na které naslouchá L2TP server, název spojení (L2TP VPN), zaškrtněte Nyní nepřipojovat a potvrďte. Následující okno vyžaduje jedno z definovaných uživatelských jmen a příslušné heslo. Po vyplnění a potvrzení je vytvořen nový síťový adaptér pro VPN spojení. Tento adaptér lze nastavit ještě o něco optimálněji. V jeho vlastnostech, na záložce Zabezpečení, vyberte Typ sítě VPN: Protokol L2TP a zkontrolujte, zda je jako možnost šifrování dat vybráno Vyžadovat šifrování. Dále musíte otevřít podokno Upřesnit nastavení a zadat PSK příslušející klientskému počítači podle jeho IP adresy. Ověřování by mělo být konfigurováno následovně: zaškrtněte Povolit tyto protokoly a pak již pouze Protokol CHAP. Jako další změnu doporučuji na záložce Sítě otevřít Vlastnosti protokolu IPv4, zvolit možnost Upřesnit a zrušit zaškrtnutí Používat výchozí bránu vzdálené sítě. Tak bude veškerá komunikace, která není přímo určena některému zařízení virtuální sítě, směrována přes místní NAS. V opačném případě by musel veškerou komunikaci klienta směrovat L2TP server, což by způsobovalo zbytečnou zátěž na jeho výpočetní výkon.

3.2.3 Výsledek Jakmile je konfigurace klienta kompletní, připojení k VPN síti lze vyvolat vybráním příslušného adaptéru, vyplněním jména a hesla a potvrzením. L2TP server je schopen přijmout spojení od většího množství klientů, až do naplnění IP adresového rozsahu pro lokální síť, nebo do využití veškeré své výpočetní kapacity pro správu příchozích spojení. Správa L2TP spojení má vyšší nároky na výkon serveru než PPTP z důvodu vyšší složitosti podporovaných šifrovacích metod. Klient pro připojení k PPTP serveru musí znát své přihlašovací jméno, heslo a PSK spárovaný na serveru s jeho IP adresou. Klient nesmí využívat webový proxy server, připojení přes NAT je možné, ale PSK musí pak být na straně serveru spárováno s IP adresou NAT. Zpoza NAT může tak v jeden čas probíhat pouze jedno spojení. 34

Proces zajišťující ve FreeBSD ustavení SA nepovoluje z bezpečnostních důvodů autentizaci z neznámých IP adres. Přestože existuje několik neoficiálních patchů, které by měly umožnit využití tzv. wildcard, ani jeden z nich nebyl po aplikaci funkční. Možnost přihlašování k FreeBSD 8.4 L2TP serveru je tím pro počítače vybavené Windows 7 značně omezena.

3.3 SSTP 3.3.1 Server Podpora protokolu SSTP je pro operační systém FreeBSD na velice špatné úrovni. V současné době existuje pouze jediný program umožňující správu SSTP spojení – SoftEther VPN4. Jedná se o serverový software podporující řadu VPN protokolů, včetně předchozích PPTP a L2TP, a lze jej nakonfigurovat i jako SSTP server. Jeho dokumentace uvádí mezi podporovanými operačními systémy i FreeBSD, bohužel ale není k instalaci na tento systém dostupná žádná oficiální (a jen velice malé množství neoficiální) dokumentace. Domovská stránka projektu navíc uvádí několik omezení při užití SoftEther VPN na FreeBSD – nižší výkon aplikace a nedostupnost funkce Local Bridging. Ta naštěstí není pro provoz serveru kritická a lze ji nahradit. Kvůli zmíněným omezením není použití SoftEther VPN v kombinaci s FreeBSD doporučeno5 [33]. SoftEther VPN vyžaduje v systému přítomnost několika modulů. Jedná se o knihovny: gcc software binutils software tar, gzip or other software for extracting package files chkconfig system utility cat, cp or other basic file operation utility EUC-JP libc (glibc) library zlib library openssl library readline library ncurses library pthread library (převzato ze SoftEther VPN Manual, kapitola 7.3 Install on Linux and Initial Configurations)

Z výše uvedených se pouze knihovna OpenSSL v systému po instalaci nenachází. Je nutné ji nejprve nainstalovat z ports collection z umístění /usr/ports/security/openssl.

4

oficiální webová stránka: https://www.softether.org/

5

„Because of these limitations, we do not recommend installing SoftEther VPN Server to systems other than Windows or Linux. Using SoftEther VPN Server on these operating systems requires a very detailed understanding of the operating system, SoftEther VPN Server, and network operations, so caution must be exercised.“

35

Cíl Cílem je vytvořit funkční SSTP VPN server, schopný přijímat a směrovat do privátní sítě více souběžných tunelů. Softwarovou část bude zajišťovat SoftEther VPN. 1. Krok – instalace SoftEther VPN Program je k dispozici ke stažení ze své oficiální stránky. Ke stažení odpovídající verze programu vyberte: Select Componet: SoftEther VPN Server Select Platform: FreeBSD Select CPU: Intel x64/AMD64 Zobrazí se seznam dostupných verzí, tato práce bude využívat SoftEther VPN v4.06, build 9437. Získaný soubor (softether-vpnserver-v4.06-9437-beta-2014.04.09-freebsd-x6464bit.tar.gz) rozbalte: tar xzvf "nazev_souboru" Bude vytvořena nová složka ./vpnserver. Přesuňte se do této složky a zkompilujte SoftEther VPN příkazem: make Zobrazí se licenční ujednání, které po přečtení musíte potvrdit. Pak by už měla proběhnout bezproblémová kompilace. Pokud dojde k chybě, systém pravděpodobně neobsahuje všechny knihovny zmíněné v požadavcích. 2. Krok – přesun složky serveru, omezení přístupu Příkazem cd postupte o úroveň výše a spusťte příkazy: mv vpnserver /usr/local cd /usr/local/vpnserver chmod 0600 * chmod 0700 vpnserver chmod 0700 vpncmd Program SoftEther VPN tak bude umístěn v prostoru pro uživatelské aplikace v souladu s politikou FreeBSD, jeho soubory budou chráněny proti změnám jiným uživatelem než superuser a povolení spouštět je omezeno pouze na soubory vpnserver a vpncmd.

36

3. Krok – kontrola splnění požadavků SoftEther VPN obsahuje několik testů, které mají vyzkoušet součásti operačního systému, zda splňují požadavky k provozu serveru. spouští se ze složky programu (/usr/local/vpnserver) příkazem: ./vpncmd Na následující obrazovce zvolte možnost 3. Use of VPN Tools, do nově otevřené příkazové řádky zadejte příkaz check a proběhne automatická kontrola systému. Obsahuje testy 'Kernel System', 'Memory Operation System', 'ANSI/Unicode string processing system', 'File system', 'Thread processing system' a 'Network system. Pokud se po proběhnutí všech testů nezobrazí hlášení „Passed all checks. It is likely that VPN Server / Bridge will operate properly on this system.“, zkontrolujte ještě jednou, zda se v operačním systému nachází všechny knihovny z počátečních požadavků. 4. Krok – skript ke spuštění/zastavení serveru Na rozdíl od programů z ports collection se u SoftEther VPN musí vytvořit spouštěcí skript manuálně. Jakmile jej uložíte do souboru /usr/local/etc/rc.d/vpnserver, můžete spouštět, restartovat a zastavovat běh SoftEther VPN na pozadí pomocí příkazů: /usr/local/etc/rc.d/vpnserver start /usr/local/etc/rc.d/vpnserver restart /usr/local/etc/rc.d/vpnserver stop U souboru by měla být omezena přístupová práva k úpravě a spuštění pouze uživateli superuser, v opačném případě by kterýkoli uživatel mohl měnit parametry spouštění či dokonce zastavit server. Navíc musí být vytvořena složka pro uložení informací o běhu aplikace. V případě, že by neexistovala, dojde k chybě a program vypíše při spuštění hlášení „touch: /var/lock/subsys/vpnserver: No such file or directory“. mkdir /var/lock mkdir /var/lock/subsys 5. Krok – Vytvoření SSTP serveru Ujistěte se, že SoftEther VPN běží jako služba na pozadí. Pokud je tomu tak, spusťte ve složce /usr/local/vpn příkaz: ./vpncmd

37

Zobrazí se úvodní informace Command Line Management Utility, stejné, jako ve 3. kroku. Tentokrát vyberte 1.Management of VPN Server or VPN Bridge6 [33]. Další dva dotazy pouze potvrďte bez vyplnění – jde o IP adresu a název serveru ke konfiguraci, budete přihlášeni k lokálnímu SoftEthernet VPN serveru jako administrátor. První akcí by mělo být nastavení hesla správce příkazem: ServerPasswordSet Vámi zvolené heslo bude od teď vyžadováno před každým přístupem ke konfiguraci serveru. Protože SoftEther VPN podporuje několik různých protokolů ke správě spojení, následuje příkaz k vytvoření virtuálního serveru pro jeden tento protokol, tzv. Virtual Hub (VH). HubCreate SSTPServer Kde za SSTPServer lze dosadit libovolný jiný název. Program bude požadovat lokální heslo pro tento hub. Lze jej využít k delegaci oprávnění správy – správce s heslem pouze k určitému hubu nebude schopen provádět změny na úrovni celého SoftEther VPN serveru. Po vytvoření hubu jej vyberte jako aktivní. Dále prováděné změny tak budou aplikovány výhradně na tento hub. Hub SSTPServer Propojení hubu s fyzickou sítí serveru by mohlo probíhat dvěma způsoby, přes Secure NAT nebo Local Bridging. Protože ale FreeBSD funkci Local Bridging nepodporuje, bude muset stačit Secure NAT. SecureNatEnable 6. Krok – Vygenerování SSL certifikátu Certifikát je nezbytný k ověření identity serveru v první fázi navazování spojení. Pokud již nějaký takový certifikát máte, můžete jej nahrát na server pomocí příkazu: ServerCertSet Jestliže žádný certifikát není dostupný, SoftEther VPN umí vygenerovat vlastní podepsaný certifikát: ServerCertRegenerate IP_adresa ServerCertGet [/usr/local/vpnserver/SSTPCertficate.cer]

6

Pravidla použití nástroje Management of VPN Server or VPN Bridge a všechny platné příkazy jsou dostupné v kapitolách 6.3 a 6.4 SoftEther VPN manuálu.

38

Kde IP_adresa označuje adresu, na které má SSTP server naslouchat. Právě na ni bude certifikát vázán. Druhý příkaz tento certifikát vyexportuje do specifikované složky. Cesta k souboru musí být v příkazu ohraničena závorkami. Po exportu je nutné poskytnout vygenerovaný certifikát všem klientským zařízením a instalovat jej podle postupu v příští kapitole. Zbývá aktivovat SSTP server, aby mohl přijímat příchozí spojení: SstpEnable yes 7. Krok – uživatelské účty V posledním kroku na straně serveru zbývá vytvořit uživatelské účty pro všechny klienty, kterým chcete povolit přístup do privátní sítě. Účty se vytváří přímo na hubu, ke kterému mají umožňovat přístup, proto se vždy před vytvořením nového účtu ujistěte, že je vybrán správný hub. Pokud na serveru existuje více hubů, účet platí vždy pouze pro ten, na kterém byl vytvořen. Při vytváření účtu je dále požadováno několik dalších údajů: skupina (doporučuji nechat prázdné), celé jméno uživatele a popis. Heslo, nezbytné k autentizaci při přihlašování zadává nezávislý příkaz, bez jeho spuštění a vytvoření hesla se nebude uživatel moci přihlásit. Vytvoření nového účtu: UserCreate jmeno_uctu UserPasswordSet jmeno_uctu Další užitečné příkazy: UserSet jmeno_uctu UserDelete jmeno_uctu UserList UserSet dovoluje změnit detaily účtu (kromě hesla) a UserList vrací seznam všech účtů přítomných na hubu včetně všech jejich detailů. 8. Krok – nepovinný, kontrola konfiguračního souboru Všechny změny serveru i hubu provedené v předchozích krocích ukládá SoftEther VPN do souboru /usr/local/vpnserver/vpn_server.conf, který může být upraven i v libovolném textovém editoru. Syntaxe je relativně jednoduchá a lze přidávat například uživatele rychleji než by bylo možné příkazy v konzoli vpncmd, ale mimo hesel, která jsou uchována v hashované podobě. Soubor vpn_server.conf vzniklý po konfiguraci FreeBSD SSTP serveru je obsažen v příloze, kvůli svému rozsahu ale pouze v elektronické podobě.

3.3.2 Klient Přestože program SoftEther VPN poskytuje i klientskou verzi, k připojení stačí vestvěný VPN klient nastavený podobně, jako u předchozích protokolů. Typ sítě VPN vyberte SSTP, autentizačním protokolem je MsCHAPv2. Ostatní možnosti zůstávají stejné jako u L2TP a PPTP. 39

Před prvním pokusem o připojení musí mít klient instalován certifikát získaný od serveru mezi důvěryhodnými. Pokud server použil již existující certifikát ověřený některou certifikační autoritou, stačí jej na klientském počítači nainstalovat přes konzoli správce (vyžaduje administrátorské oprávnění). V případě, že byl certifikát generován programem SoftEther VPN a tedy je podepsán pouze jím, musí být přidán přímo mezi důvěryhodné kořenové certifikační autority. Takový certifikát je i součástí elektronické přílohy. Certifikát neinstalujte jeho spuštěním, uložil by se pouze jako certifikát uživatele, zatímco k autentizaci je vyžadován certifikát počítače. Spusťte administrátorskou konzoli systému Windows (Start –> Spustit –> mmc). V nabídce Soubor vyberte Přidat nebo odebrat modul snap-in a přidejte modul Certifikáty. Zaškrtněte volbu spravování certifikátů pro Účet počítače a Místní počítač a potvrďte. V modulu Certifikáty (místní) se přesuňte do složky Důvěryhodné kořenové certifikační autority –> Certifikáty. Pak v menu Akce vyberte Všechny úkoly a Importovat. Nyní zadejte cestu k souboru obsahujícímu certifikát a dokončete import(v průběhu zkontrolujte, zda je ukládán do složky Důvěryhodné kořenové certifikační autority). Poté můžete konzoli uzavřít, certifikát byl úspěšně nainstalován. Při zadávání uživatelského jména a hesla je nezbytné zadat jej v následujícím formátu: Uživatelské jméno: jmeno_uctu@SSTPServer Heslo: ****** Za uživatelským jménem musí následovat @ a pak název hubu, na který se uživatel v rámci serveru přihlašuje. Pokud bude tato informace chybět, spojení neprojde autentizační fází uživatele, protože server nenajde ve své databázi uživatelské jméno a heslo.

3.3.3 Výsledek Po dokončení konfigurace klienta a zadání přihlašovacích údajů ve správném formátu je Windows 7 klient schopen připojit se k FreeBSD 8.4 serveru pomocí protokolu SSTP. Jako autentizační protokol uživatele slouží MsCHAPv2, data jsou zašifrována 128-bit šifrou RC4. Před zahájením komunikace se server klientu prokazuje SSL certifikátem.

3.4 IKEv2 3.4.1 Server IKEv2 server lze na systému s FreeBSD spravovat pomocí programu StrongSwan7 (aktuální verze 5.1.1), který se nachází v ports collection. Před jeho instalací je třeba ověřit přítomnost několika modulů v operačním systému. V první řadě kernel musí obsahovat modul IPsec, pokud tomu tak není, viz postup přidání do kernelu u L2TP. Druhým požadavkem je port OpenSSL, rovněž dostupný v ports collection ve složce /usr/ports/security/openssl.

7

oficiální webová stránka: http://www.strongswan.org/

40

Cíl Cílem je vytvořit funkční IKEv2 VPN server, schopný přijímat a směrovat do privátní sítě více souběžných tunelů. Server poběží na softwaru StrongSwan, který poskytuje šifrovací i autentizační protokoly odpovídající požadavkům klientských Windows 7 stanic. Autentizace serveru bude probíhat za pomoci x.509 certifikátu, autentizace klienta PSK (EAPMsCHAPv2). Dalším hlavním požadavkem na server je podpora protokolu MOBIKE k zajištění mobility připojených zařízení. 1. Krok – instalace StrongSwan Jakmile se v operačním systému nachází všechny požadované moduly, můžete přistoupit k instalaci aplikace StrongSwan: cd /usr/ports/security/strongswan make install clean Na obrazovce výběru volitelných komponent není třeba provádět žádné změny. Jakmile instalace skončí, přesuňte se do složky /etc a v souboru rc.conf povolte spouštění StrongSwan přidáním řádku: strongswan_enable="YES" 2. Krok – vygenerování certifikátu serveru K získání certifikátu, kterým se musí server klientu prokazovat v autentizační fázi, slouží knihovna OpenSSL 8 . Pokud již certifikát ověřený některou certifikační autoritou máte, můžete tento krok přeskočit. Jinak následujícími příkazy vygenerujete tzv. self-signed certifikát (podobný certifikátu využívanému v předchozí kapitole k ověření totožnosti SSTP serveru) podepsaný pouze serverem, který jej generoval. Nejprve se přesuňte do složky, ve které má být certifikát uložen. mkdir /usr/local/ikev2certs cd /usr/local/ikev2certs Aby bylo možné podepsat certifikát serveru, musí existovat lokální certifikační autorita. Její pověření definují následující příkazy aplikace OpenSSL. openssl genrsa -des3 -out ca.key 4096 openssl req -new -key ca.key -out ca.csr openssl x509 -req -days 3650 -in ca.csr -signkey ca.key -out ca.crt

8

návod ke generování OpenSSL certifikátů ve FreeBSD obsahuje FreeBSD Handbook v kapitole 14.6.

41

První příkaz vytvoří náhodný RSA klíč, ze kterého druhý příkaz vygeneruje klíč certifikační autority. Ten ještě vyžaduje zadání hesla, které bude vyžadováno při každém podpisu. Podpis nového certifikátu serveru vyvolá právě třetí příkaz, potvrďte jej vyplněním předchozího hesla a dalších údajů. Tyto údaje můžete zvolit libovolně, ale Common Name/Fully Qualified Domain Name (CN/FQDN) by se mělo shodovat s FQDN IKEv2 serveru. Po dokončení příkazů se ve složce nachází tři soubory s pověřením certifikační autority. Nyní můžete přejít k vytvoření a podpisu certifikátů serveru a klienta. Předem ve složce musíte vytvořit soubor server.conf k modifikaci klíče klienta. Windows 7 klade specifické požadavky na parametry Subject Alternative Name (musí se shodovat s Fully Qualified Domain Name serveru) a Extended Key Usage. Soubor tedy bude obsahovat tyto parametry, kde za kernun.sensei.tns.cz doplňte FQDN vašeho serveru (zjistíte příkazem hostname -f): extendedKeyUsage = serverAuth, 1.3.6.1.5.5.8.2.2 subjectAltName = DNS:kernun.sensei.tns.cz První dva příkazy generování klíče serveru se shodují s příkazy vytváření certifikační autority. Stejně postupujte i při vyplňování požadovaných údajů. Heslo zadané při vytváření certifikátu bude potřebné při vytváření uživatelských účtů. CN/FQDN se tentokrát musí shodovat s FQDN IKEv2 serveru. openssl genrsa -des3 -out server.key 4096 openssl req -new -key server.key -out server.csr openssl x509 -req -days 3650 -in server.csr -CA ca.crt -CAkey ca.key -out server.crt extfile server.conf Třetí příkaz podepíše klíč serveru klíčem certifikační autority za použití modifikace ze souboru server.conf. Všechny nezbytné certifikáty se nyní nachází v aktuální složce. K provozu server potřebuje zejména server.crt a server.key. Přesuňte je do struktury složek IPsec: cp server.crt /usr/local/etc/ipsec.d/certs/server.crt cp server.key /usr/local/etc/ipsec.d/private/server.key 3. Krok – Nastavení IPsec Konfigurační soubor ipsec.conf obsahující nastavení spojení serveru se nachází ve složce /usr/local/etc. Pokud nebyl po instalaci StrongSwan vytvořen automaticky, založte jej a editujte v tomto umístění. Příklad souboru s funkční konfigurací serveru přijímajícího spojení ze stanic Windows 7 je k nahlédnutí v příloze. Soubor obsahuje první část s obecným nastavením, které definuje způsob autentizace klientů, povolené autentizační a šifrovací algoritmy a způsob řešení ztráty kontaktu s klientem. Druhou část tvoří nastavení spojení specificky pro Windows 7 stanice. Všechny příkazy začínající slovem left se vztahují vždy na stranu serveru, případně k lokální síti, zatímco klíčové slovo right označuje nastavení aplikovaná na vzdálené klienty. Tato část zahrnuje 42

mimo jiné cestu k certifikátu, kterým má server prokazovat svou identitu a jeho FQDN. Pokud jste v předchozím kroku umístili soubor server.crt na předepsanou pozici, stačí jako parametr příkazu leftcert jméno souboru. V opačném případě použijte absolutní cestu k souboru s certifikátem. FQDN zadané do leftid se musí shodovat se jménem použitým v podepsaném certifikátu, jinak autentizace serveru selže. 4. Krok – Definice uživatelských klíčů Uživatelské účty se nastavují, podobně jako u L2TP, v souboru ipsec.secrets ve složce /usr/local/etc. V úvodu souboru by měla být uvedena cesta k soukromému klíči serveru – server.key. Na dalších řádcích budou definováni uživatelé s povoleným přístupem do IKEv2 VPN ve formátu EAP-MsCHAPv2: uziv_jmeno : EAP "heslo" Příklad souboru se zadanými dvěma IKEv2 uživateli se nachází v příloze D. 5. Krok – DNS a WINS server Stanice Windows 7 vyžadují při IKEv2 vyjednávání adresy lokálního DNS a WINS serveru. WINS server funguje obdobně jako DNS, ale pracuje s NetBIOS jmény. Pro provoz sítě není kritický a pokud se na ní nevyskytuje, nemusí být zadán. Pokud na lokální síti není přítomen ani DNS server, použijte některý veřejný DNS server, například Google (IP adresa 8.8.8.8). Adresy serverů zadejte do souboru /usr/local/etc/strongswan.conf: charon { dns1 = 8.8.8.8 dns2 = 8.8.4.4 [nbns1 = adresa_lokalniho_WINS_serveru1] [nbns2 = adresa_lokalniho_WINS_serveru2] } Položky dns2, nbns1 a nbns2 jsou nepovinné a pokud se tyto servery na lokální síti nenachází, vůbec je nezadávejte. Konfigurační soubor strongswan.conf je opět uveden v příloze, obsahuje pouze jeden veřejný server DNS. 6. Krok – spuštění serveru Po provedení všech předchozích kroků můžete IKEv2 server spustit. Fungují příkazy: /usr/local/etc/rc.d/strongswan start /usr/local/etc/rc.d/strongswan restart /usr/local/etc/rc.d/strongswan stop

43

3.4.2 Klient Klient používá k připojení k IKEv2 serveru, jako ve všech předchozích případech, software obsažený přímo ve Windows 7. Jeho nastavení se liší pouze ve výběru protokolu (IKEv2) a v Ověřování zaškrtnutím Použít protokol EAP a zvolením EAP-MsCHAPv2. Tlačítko Upřesnit nastavení obsahuje dobu, po kterou má stanice vyčkávat na obnovení spojení v případě ztrát signálu, nebo zde lze podporu mobility úplně vypnout. Poté nainstalujte certifikát serveru (server.crt) mezi důvěryhodné kořenové certifikační autority stejným postupem, jaký je uveden u konfigurace SSTP klienta. Připojení zahájíte vyplněním uživatelského jména a hesla. Pokud jste dodrželi popsaný postup, měla by úspěšně proběhnout autentizace a přidělení IP adresy z lokálního rozsahu. Je ale možné, že spojení bude ze strany klienta ukončeno chybovým hlášením 13801 [34]. To je obvykle vyvoláno kvůli chybějícímu Enhanced Key Usage (EKU). Windows 7 vyžaduje vyplnění tohoto jinak nepovinného atributu certifikátu při jeho vygenerování. Rovněž vyžaduje, aby se atribut Subject Alternative Name rovnal FQDN serveru. Oba dva atributy by měly být nastaveny na odpovídající hodnoty v kroku 2, díky souboru server.conf. Chybové hlášení je možné obejít i vypnutím kontroly obou atributů. Přes nástroj regedit (Start –> Spustit –> regedit) vytvořte ve složce \HKEY_LOCAL_MACHINE\ SYSTEM\CurrentControlSet\services\RasMan\Parameters nový klíč DWORD s názvem DisableIKENameEkuCheck a jeho hodnotu nastavte na 1 [35]. Pokud pak připojení proběhne bez problémů, byla chyba právě v hodnotách obou atributů.

3.4.3 Výsledek S použitím popsané konfigurace je Windows 7 klient schopen připojit se k FreeBSD 8.4 serveru. Ověřování totožnosti serveru probíhá za pomoci certifikátu podepsaného lokální certifikační autoritou, klientská stanice se prokazuje sdíleným klíčem protokolu EAPMsCHAPv2. Vzdáleným zařízením jsou přiděleny virtuální IP adresy z definovaného rozsahu, jejich IP adresy získané z lokálních DHCP serverů se mohou v průběhu spojení libovolně měnit díky využití protokolu MOBIKE. Jeho dostupnost je pro každého klienta ověřena před ustavením spojení a uživatel si může na zařízení s operačním systémem Windows 7 zvolit, zda podporu mobility využít či nikoliv.

44

Závěr Cílem práce bylo prozkoumat možnosti VPN spojení pomocí protokolů obsažených ve Windows 7. Hodnocení teoretických vlastností jednotlivých protokolů lze nalézt ve shrnutí druhé kapitoly. Test provozu ve třetí kapitole pak ukázal některá omezení, vyvstávající ze zvolené kombinace operačních systémů serveru a klienta. Nicméně spojení bylo pomocí všech čtyř protokolů PPTP, L2TP, SSTP a IKEv2 nakonec úspěšně navázáno. PPTP se ukázal jako VPN protokol s velice jednoduchou a přímočarou konfigurací, kterou dokáže zvládnout i člověk neorientující se v detailech informační bezpečnosti a směrování. Tato vlastnost jej činí ideálním k použití pro ustavení domácí privátní sítě se vzdáleným přístupem k čemuž je také stále hojně využíván. Široká podpora dovoluje pak do domácí sítě připojit libovolné počítače notebooky i například mobilní telefony s operačním systémem Android. Bohužel protokol obsahuje jednoduše zneužitelné bezpečnostní chyby, jež jej činí nepoužitelným k jakémukoliv účelu, spoléhajícímu na utajení přenášených dat. Protokol L2TP netrpí žádnou vážnou bezpečnostní vadou jako jeho předchůdce, alespoň tedy dosud žádnou známou vadou, ale zároveň neposkytuje ani výhody jako protokoly SSTP a IKEv2. Serverový software pro FreeBSD navíc váže uživatelské jméno a heslo na určitou IP adresu klientského zařízení, což znemožňuje připojení klientů s dynamicky přidělovanými adresami. Třetí z testovaných protokolů, SSTP, dovoluje připojit se k VPN serveru přes naprostou většinu mezilehlých zařízení, jako jsou firewally, proxy servery nebo NAT. Značně ale omezuje výběr připojitelných zařízení svojí nízkou podporou. Pro testovaný systém FreeBSD existuje pouze jediný program poskytující SSTP konektivitu. Posledním zkoušeným protokolem byl IKEv2, který přináší podporu mobility, při snížení průchodnosti sítí oproti SSTP zpět na úroveň L2TP. Při konfiguraci na FreeBSD serveru se Windows 7 klient ukázal jako poněkud vybíravý při ověřování platnosti certifikátu a na jednom z testovacích notebooků bylo třeba vypnout rozšířené ověřování certifikátu serveru pomocí změny v registru, jak je popsána v kapitole tři, části konfigurace IKEv2 klienta. Při výběru protokolu vhodného pro vytvářenou VPN je v první řadě nezbytné vzít v úvahu všechna zařízení, která mohou být k takové síti, třeba i v budoucnu, připojována. Některé dostupné protokoly s nižší úrovní podpory totiž tak mohou být vyřazeny hned ze začátku. Z bezpečnostních důvodů však nedoporučuji využívat protokol PPTP, a to pro žádné připojení spoléhající na utajení dat po dobu delší než 24 hodin (viz slabiny protokolu MsCHAPv2). Kde není omezující chybějící podpora na některých zařízeních, doporučuji využít IKEv2, jako nejmodernější protokol s dostatečným zabezpečením a funkcí mobility. Pokud bude kladen důraz na dostupnost, či pokud se některá zařízení nebudou moci připojit k IKEv2 serveru kvůli omezení v rámci přenosové sítě, zvážil bych užití VPN ustavené pomocí protokolu SSTP.

45

Slovník zkratek AH

Autentication Header, RFC 4302

EAP

Extensible Authentication Protocol, RFC 3748

ESP

Encapsulating Security Payload, RFC 4303

GRE

Generic Routing Protocol, RFC 1701 a 1702

IPsec

IP security, RFC 2401 a 2411

IKE

Internet Key Exchange, RFC 2409

ISP

Internet Service Provider

L2F

Layer 2 Forwarding protocol, RFC 2341

MD4

Message Digest 4

MOBIKE

Mobility and Multihoming Protocol, RFC 4555

MPPE

Microsoft Point-To-Point Encryption Protocol, RFC 3078

MsCHAP

Microsoft Challenge Handshake Authentication Protocol

NAS

Network Access Server

PAC

PPTP Access Concentrator

PAP

Password Authentication Protocol

PNS

PPTP Network Server

PPP

Point-to-Point Protocol, RFC 1661

PSK

Preshared Key

NAT

Network Address Translation

SA

Security Association, bezpečnostní přiřazení

SSL

Secure Socket Layer, RFC 6101

TLS

Transport Layer Security, RFC 5246

VPN

Virtual Private Network

WPS

Web Proxy Server

46

Literatura a zdroje [1] BOYD, C. a A. MATHURIA. Protocols for authentication and key establishment. Berlin: Springer, c2010, xxiv, 321 s. Information security and cryptography. ISBN 978-364-2077166. [2] LLOYD, B. a W. SIMPSON. PPP Authentication Protocols. Request for Comments: 1334 [online]. 1994 [cit. 2014-05-15]. Dostupné z: http://tools.ietf.org/html/RFC1334 [3] ZORN, G. a S. COBB. Microsoft PPP CHAP Extensions. Request for Comments: 2433 [online]. 1998 [cit. 2014-05-15]. Dostupné z: http://tools.ietf.org/html/rfc2433 [4] SANDERS, C. How I Cracked your Windows Password. WindowSecurity [online]. 2010 [cit. 2014-05-14]. Dostupné z: http://www.windowsecurity.com/articlestutorials/authentication_and_encryption/How-Cracked-Windows-Password-Part1.html [5] GOLANDER, A. Cryptanalysis of Microsoft’s Point-to-Point Tunneling Protocol. [online]. 2007 [cit. 2014-05-04]. Dostupné z: http://www.slidefinder.net/c/cryptanalysis_microsoft_point_point_tunneling/ms_pptp_6mar0 7/18495976 [6] WANG, X. et al. Cryptanalysis of the Hash Functions MD4 and RIPEMD. Jinan, China, 2005. Dostupné z: http://www.infosec.sdu.edu.cn/uploadfile/papers/Cryptanalysis%20of%20the%20Hash%20Fu nctions%20MD4%20and%20RIPEMD.pdf. Shandong University. [7] BAUMGART, By Rainer. Secure Networking -- CQRE [Secure] ' 99 International Exhibition and Congress Düsseldorf, Germany, November 30 - December 2, 1999 Proceedings [online]. Berlin, Heidelberg: Springer-Verlag Berlin Heidelberg, 1999, s. 192203 [cit. 2014-05-16]. ISBN 9783540467014. [8] MARLINSPIKE, M. Divide and Conquer: Cracking MS-CHAPv2 with a 100% success rate. [online]. 2012 [cit. 2014-05-05]. Dostupné z: https://www.cloudcracker.com/blog/2012/07/29/cracking-ms-chap-v2/ [9] Microsoft Security Advisory 2743314: Unencapsulated MS-CHAP v2 Authentication Could Allow Information Disclosure. [online]. [cit. 2014-04-22]. Dostupné z: https://technet.microsoft.com/library/security/2743314 [10] KAUFMAN, C. et al. Internet Key Exchange Protocol Version 2 (IKEv2). Request for Comments: 5996 [online]. 2010 [cit. 2014-05-15]. Dostupné z: http://tools.ietf.org/html/rfc5996 [11] ZORN, G. Deriving Keys for use with Microsoft Point-to-Point Encryption (MPPE)Deriving Keys for use with Microsoft Point-to-Point Encryption (MPPE). Request for Comments: 3079 [online]. 2001 [cit. 2014-05-16]. Dostupné z: http://www.ietf.org/rfc/rfc3079.txt 47

[12] KENT, S. Security Architecture for the Internet Protocol. Request for Comments: 2401 [online]. 1998 [cit. 2014-05-16]. Dostupné z: http://www.ietf.org/rfc/rfc2401.txt [13] THAYER, R. et al. IP Security Document Roadmap. Request for Comments: 2411 [online]. 1998 [cit. 2014-05-16]. Dostupné z: https://www.ietf.org/rfc/rfc2411.txt [14] KENT, S. IP Authentication Header. Request for Comments: 4302 [online]. 2005 [cit. 2014-05-16]. Dostupné z: http://tools.ietf.org/html/rfc4302.html [15] KENT, S. IP Encapsulating Security Payload (ESP). Request for Comments: 4303 [online]. 2005 [cit. 2014-05-16]. Dostupné z: http://tools.ietf.org/html/rfc4303.html [16] FRIEDL, S. An Illustrated Guide to IPsec. Unixwiz.net Tech Tips [online]. 2005 [cit. 2014-05-11]. Dostupné z: http://www.unixwiz.net/techtips/iguide-ipsec.html [17] ARORA, M. How secure is AES against brute force attacks?. EETimes [online]. 2012 [cit. 2014-05-11]. Dostupné z: http://www.eetimes.com/document.asp?doc_id=1279619 [18] FREIER, A., P. KARLTON a P. KOCHER. The Secure Sockets Layer (SSL) Protocol Version 3.0. Request for Comments: 6101 [online]. 2011 [cit. 2014-05-16]. Dostupné z: http://tools.ietf.org/html/rfc6101 [19] DIERKS, T. a E. RESCORLA. The Transport Layer Security (TLS) Protocol Version 1.2. Request for Comments: 5246 [online]. 2008 [cit. 2014-05-16]. Dostupné z: http://tools.ietf.org/html/rfc5246 [20] VANDEVEN, S. SSL/TLS: What's Under the Hood. In: SANS Institute InfoSec Reading Room [online]. 2013 [cit. 2014-05-11]. Dostupné z: http://www.sans.org/readingroom/whitepapers/authentication/ssl-tls-whats-hood-34297 [21] ZHANG, H. Three attacks in SSL protocol and their solutions. In: [online]. 2003 [cit. 2014-05-11]. Dostupné z: https://www.cs.auckland.ac.nz/courses/compsci725s2c/archive/termpapers/725zhang.pdf [22] KIRK, J. Tests confirm Heartbleed bug can expose server's private key. PC World [online]. 2014 [cit. 2014-05-14]. Dostupné z: http://www.pcworld.com/article/2143080/testsconfirm-heartbleed-bug-can-expose-servers-private-key.html [23] HAMZEH, K. et al. Point-to-Point Tunneling Protocol (PPTP). Request for Comments: 2637 [online]. 1999 [cit. 2014-05-16]. Dostupné z: http://www.ietf.org/rfc/rfc2637.txt [24] TOWNSLEY, W. et al. Layer Two Tunneling Protocol "L2TP". Request for Comments: 2661 [online]. 1999 [cit. 2014-05-16]. Dostupné z: http://www.ietf.org/rfc/rfc2661.txt [25] KAUFMAN, C. Internet Key Exchange (IKEv2) Protocol. Request for Comments: 4306 [online]. 2005 [cit. 2014-05-16]. Dostupné z: http://tools.ietf.org/html/rfc4306

48

[26] DAVIES, J. The Cable Guy: The Secure Socket Tunneling Protocol. TechNet Magazine [online]. 2007, č. 6 [cit. 2014-04-22]. Dostupné z: http://technet.microsoft.com/enus/magazine/2007.06.cableguy.aspx [27] PATEL, B. et al. Securing L2TP using IPsec. Request for Comments: 3193 [online]. 2001 [cit. 2014-05-16]. Dostupné z: https://www.ietf.org/rfc/rfc3193.txt [28] BRAGG, R. The Tips and Tricks Guide to Securing Windows Server 2003 [online]. 2011 [cit. 2014-04-22]. Dostupné z: http://searchwindowsserver.techtarget.com/feature/L2TP-overIPSec-and-NAT-NAT-Traversal [29] The Mobility Manager: Managing mobility for VPN reconnect connections (IKEv2 based VPN connections). In: ASTHANA, A. K. Routing and Remote Access Blog [online]. 2008 [cit. 2014-04-23]. Dostupné z: http://blogs.technet.com/b/rrasblog/archive/2008/12/31/the-mobility-manager-managingmobility-for-agile-vpn-connections.aspx [30] The FreeBSD Documentation Project. FreeBSD Handbook [online]. 1995, 2014 [cit. 2014-05-14]. Dostupné z: https://www.freebsd.org/doc/handbook/index.html [31] COBBS, A. Mpd 5.7 User Manual [online]. 2013 [cit. 2014-05-14]. Dostupné z: https://www.freebsd.org/doc/handbook/index.html [32] CRAFT, N. How do I install FreeBSD kernel source code?. NixCraft [online]. 2007 [cit. 2014-05-14]. Dostupné z: http://www.cyberciti.biz/faq/freebsd-install-kernel-source-code/ [33] SoftEther VPN Manual [online]. 2014 [cit. 2014-05-14]. Dostupné z: http://www.softether.org/4-docs/1-manual [34] Troubleshooting IKEv2 VPN Connections. Microsoft Technet [online]. 2009 [cit. 201405-14]. Dostupné z: http://technet.microsoft.com/cscz/library/dd941612%28v=ws.10%29.aspx [35] Networking Keys. Microsoft Technet [online]. 2009 [cit. 2014-05-14]. Dostupné z: http://technet.microsoft.com/en-us/library/dd672621%28v=ws.10%29.aspx

49

Příloha A, Konfigurační soubory PPTP /usr/local/etc/mpd5/mpd.conf startup: # uzivatelske jmeno a heslo pro spravce serveru set user administrator admin set user administrator Admin*2014 # otevreni konfiguracni konzole pro zmenu nastaveni za # behu serveru set console self 0.0.0.0 5005 set console open default: load pptp_server pptp_server: # vytvoreni rozsahu IP adres pro vzdalene klienty set ippool add pool1 192.168.1.2 192.168.1.200 # nastaveni vrstvy bundle create bundle template bundle1 # nastaveni vrstvy rozhrani set iface enable proxy-arp set iface idle 1800 set iface enable tcpmssfix # nastaveni vrstvy IPCP set ipcp yes vjcomp set ipcp ranges 192.168.1.1/32 ippool pool1 set ipcp dns 8.8.8.8 # definice povolene verze MPPE set bundle enable compression set ccp yes mppc set mppc yes e128 set mppc yes stateless # nasteveni vrstvy linky create link template template1 pptp set link action bundle bundle1 # povoleni komprese prenosu set link enable multilink set link yes acfcomp protocomp # povoleni autentizace pouze MSCHAPv2 set link no pap chap eap set link enable chap-msv2 # IP adresa, na ktere ma PPTP server naslouchat set pptp self 95.129.96.211

50

# povoleni prijimani prichozich spojeni set link enable incoming

/usr/local/etc/mpd5/mpd.secret uzivatel1 uzivatel2

Heslo1*2014 Heslo2*2014

192.168.1.2

51

Příloha B, Konfigurační soubory L2TP /usr/local/etc/mpd5/mpd.conf startup: # uzivatelske jmeno a heslo pro spravce serveru set user administrator admin set user administrator Admin*2014 # otevreni konfiguracni konzole pro zmenu nastaveni za # behu serveru set console self 0.0.0.0 5005 set console open default: load l2tp_server l2tp_server: # vytvoreni rozsahu IP adres pro vzdalene klienty set ippool add pool1 192.168.1.2 192.168.1.200 # nastaveni vrstvy bundle create bundle template bundle1 # nastaveni vrstvy rozhrani set iface enable proxy-arp set iface enable tcpmssfix # nastaveni vrstvy IPCP set ipcp yes vjcomp set ipcp ranges 192.168.1.1/32 ippool pool1 set ipcp dns 8.8.8.8 # nastaveni vrstvy linky create link template template1 l2tp set link action bundle bundle1 set link enable multilink # povoleni autentizace pouze MSCHAP set link no pap chap eap set link enable chap # vypnuti zasilani keep alive zprav set link keep-alive 0 0 # snizeni mtu aby se zamezilo fragmentaci paketu set link mtu 1280 # IP adresa, na ktere ma PPTP server naslouchat set l2tp self 95.129.96.211 set l2tp enable length # povoleni prijimani prichozich spojeni set link enable incoming

52

/usr/local/etc/racoon/racoon.conf # cesta k souboru obsahujicimu pary IP adresa/autentizacni klic # slouzi k autentizaci stanic path pre_shared_key "/usr/local/etc/racoon/psk.txt"; listen { # IP adresa a porty, na kterych ma server naslouchat isakmp 95.129.96.211 [500]; isakmp_natt 95.129.96.211 [4500]; strict_address; } # nastaveni pro vsechny pripojujici se klienty remote anonymous { exchange_mode main; # server nebude iniciovat spojeni passive on; # server prizpusobi vyber z proposal klientu proposal_check obey; support_proxy on; nat_traversal on; # povoleni fragmentace v prubehu ustavovani SA ike_frag on; dpd_delay 20; # povolene dva zpusoby sifrovani, AES preferovany proposal { encryption_algorithm aes; hash_algorithm sha1; authentication_method pre_shared_key; dh_group modp1024; } proposal { encryption_algorithm hash_algorithm authentication_method dh_group

3des; sha1; pre_shared_key; modp1024;

} } # povoleni ustaveni SA s jakymkoli klientem se spravnym klicem # za pouziti nasledujicich algoritmu sainfo anonymous { encryption_algorithm aes,3des; authentication_algorithm hmac_sha1; compression_algorithm deflate;

53

# typ vymeny Diffie-Hellman pri vytvareni SA pfs_group modp1024; }

/usr/local/etc/racoon/psk.txt 147.251.225.62

PredsdilenyIPsecKlic*2014

54

Příloha C, Konfigurační soubory SSTP /usr/local/etc/rc.d/vpnserver DAEMON=/usr/local/vpnserver/vpnserver LOCK=/var/lock/subsys/vpnserver test -x $DAEMON || exit 0 case "$1" in start) $DAEMON start touch $LOCK ;; stop) $DAEMON stop rm $LOCK ;; restart) $DAEMON stop sleep 3 $DAEMON start ;; *) echo "Usage: $0 {start|stop|restart}" exit 1 esac exit 0

55

Příloha D, Konfigurační soubory IKEv2 /usr/local/ikev2certs/server.conf extendedKeyUsage = serverAuth, 1.3.6.1.5.5.8.2.2 subjectAltName = DNS:kernun.sensei.tns.cz

/usr/local/etc/ipsec.conf config setup # vypina podporu IKEv1, autentizace povolena pouze pres IKEv2 # ve StrongSwan 5.1.1 jiz vypnuto defaultne plutostart=no conn %default auto=add # zpusob autentizace keyexchange=ikev2 # nastaveni algoritmu podporovanych Windows 7 ike=aes256-sha1-modp1024! esp=aes256-sha1! # Dead Peer Detection, pokud klient neodpovida, smaze # prislusne IKE a IPsec SA dpdaction=clear dpddelay=300s rekey=no conn ikev2connection # left odpovida nastaveni lokalni site a serveru left=192.168.10.1 # default route a tedz veskera IP komunikace bude # smerovana vzdy pres server leftsubnet=0.0.0.0/0 leftauth=pubkey leftcert=server.crt leftid=kernun.sensei.tns.cz # right nastavuje vlastnosti klienta # povoli spojeni z jakekoli IP adresy right=%any # IP pool adres pro klienty rightsourceip=192.168.10.2/24 # zpusob autentizace rightauth=eap-mschapv2 rightsendcert=never eap_identity=%any

/usr/local/etc/ipsec.secrets # v uvozovkach musi byt uvedeno heslo zadane pri # vytvareni certifikatu : RSA server.key "Heslo*2014" spaceks : EAP "Heslo1*2014"

56

dubovskyp : EAP "Heslo2*2014"

/usr/local/etc/strongswan.conf: charon { dns1 = 8.8.8.8 }

57