Pokročilé sít ové konfigurace v cloudu

M ASARYKOVA UNIVERZITA FAKULTA INFORMATIKY

}

w A| y < 5 4 23 1 0 / -. , )+ ( %&' $ # !"

Æ

Pokroˇcilé sít’ové konfigurace v cloudu ˇ B AKALÁ RSKÁ PRÁCE

Roman Jakubik

Brno, podzim 2014

Prohlášení Prohlašuji, že tato bakaláˇrská práce je mým puvodním ˚ autorským dílem, které jsem vypracoval samostatnˇe. Všechny zdroje, prameny a literaturu, které jsem pˇri vypracování používal nebo z nich cˇ erpal, v práci rˇ ádnˇe cituji s uvedením úplného odkazu na pˇríslušný zdroj.

Roman Jakubik

Vedoucí práce: RNDr. Daniel Kouˇril i

Klíˇcová slova KYPO, VPN, tunelovací mechanizmy, OpenVPN, l2tp, IPSec

ii

Podˇekování Dˇekuji vedoucímu práce panu RNDr. Danielu Kouˇrilovi za konzultaci a cenné rady pˇri psaní bakaláˇrské práce.

iii

Obsah 1 2

3

4

5

Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . KYPO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 Vlastnosti . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Architektura . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Pˇrehled nedostatku˚ . . . . . . . . . . . . . . . . . . . . . . 2.3.1 Propojení virtuálních prostˇredí . . . . . . . . . . . 2.3.2 Pˇrekrývání VLAN . . . . . . . . . . . . . . . . . . 2.3.3 Mechanizmus pˇripojení fyzických zaˇrízení . . . . Návrh rˇešení . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 Pˇripojení externího zaˇrízení . . . . . . . . . . . . . . . . . 3.1.1 Infrastruktura . . . . . . . . . . . . . . . . . . . . 3.2 Propojení dvou uzlu˚ . . . . . . . . . . . . . . . . . . . . . 3.2.1 Infrastruktura . . . . . . . . . . . . . . . . . . . . Popis použitých VPN technologii . . . . . . . . . . . . . . . . 4.1 OpenVPN . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.1 Bezpeˇcnost . . . . . . . . . . . . . . . . . . . . . . 4.1.2 Komunikace . . . . . . . . . . . . . . . . . . . . . 4.2 IPSec/l2tpv3 . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.1 L2tpv3 (Layer Two Tunneling Protocol version 3) 4.2.2 IPSec (Internet Protocol Security) . . . . . . . . . 4.2.3 Bezpeˇcnost . . . . . . . . . . . . . . . . . . . . . . 4.2.4 Konfigurace . . . . . . . . . . . . . . . . . . . . . . Pˇripojení externího zaˇrízení do KYPO . . . . . . . . . . . . . ˇ 5.1 Rídicí cˇ ást . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.1.1 Tvorba VPN serveru˚ . . . . . . . . . . . . . . . . . 5.1.2 Práce s databází . . . . . . . . . . . . . . . . . . . 5.1.3 Tvorba RSA klíˇcu˚ . . . . . . . . . . . . . . . . . . 5.1.4 Obslužné funkce . . . . . . . . . . . . . . . . . . . 5.1.5 Komunikace s propojovacím zaˇrízením . . . . . . 5.2 OpenVPN server na LMN uzlu . . . . . . . . . . . . . . . 5.2.1 Tvorba nového OpenVPN serveru . . . . . . . . . 5.2.2 Zrušení stávajícího OpenVPN serveru . . . . . . 5.2.3 Konfiguraˇcní soubor . . . . . . . . . . . . . . . . . 5.3 Klientská cˇ ást . . . . . . . . . . . . . . . . . . . . . . . . . 5.3.1 init_vpn . . . . . . . . . . . . . . . . . . . . . . . . 5.3.2 close_vpn . . . . . . . . . . . . . . . . . . . . . . . 5.4 Test výsledné VPN . . . . . . . . . . . . . . . . . . . . . .

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

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

1 2 2 2 3 4 4 4 5 5 5 7 7 8 8 9 10 11 11 11 12 15 17 17 17 19 19 20 21 21 22 22 23 23 23 24 24 iv

5.4.1 Pˇripojení externích zaˇrízení . . . . 5.4.2 Test vytvoˇreného prostˇredí . . . . 6 Propojení dvou vzdálených uzlu˚ . . . . . . . . 6.1 Sestavování tunelu˚ - tˇrída Tunnel . . . . . 6.1.1 L2tp . . . . . . . . . . . . . . . . . 6.1.2 IPSec . . . . . . . . . . . . . . . . . 6.2 Práce s databází - tˇrída DbWorker . . . . . 6.3 Obslužné funkce . . . . . . . . . . . . . . 6.4 Test výsledného tunelu . . . . . . . . . . . 6.4.1 Sestavení tunelu . . . . . . . . . . 6.4.2 Test tunelu . . . . . . . . . . . . . 6.4.3 Ukonˇcení tunelu . . . . . . . . . . 6.5 Výsledek . . . . . . . . . . . . . . . . . . . 7 Závˇer . . . . . . . . . . . . . . . . . . . . . . . . A Konfiguraˇcní soubor „settings” . . . . . . . . . B Konfigurˇcní OpenVPN soubor serverové cˇ ásti

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

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

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

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

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

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

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

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

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

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

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

24 26 28 28 28 29 30 30 31 31 32 33 33 34 38 39

v

1 Úvod Kybernetický polygon nabízí prostˇredí pro detailní studování bezpeˇcnostních incidentu˚ na síti. Celé prostˇredí se nachází v cloudovém prostˇredí Masarykovy Univerzity a bylo budováno postupnˇe. Tento projekt je relativnˇe mladý a je tedy mnoho vˇecí, kterými je možné toto prostˇredí rozšíˇrit. Bližší popis Kybernetického polygonu je uveden v kapitole 2, ve které podrobnˇeji pˇredstavuji i rozšíˇrení navržené v oficiálním zadání této práce. V 3. kapitole nabízím návrh dvou rozšíˇrení, která popisují možný pˇrístup k vyˇrešení problematiky popsané v sekci 2.3. Obˇe rˇ ešení jsou zbudována na již vytvoˇrených VPN technologiích. Tyto technologie tvoˇrí podstatnou cˇ ást fungování obou rˇ ešení a jsou detailnˇeji vysvˇetleny v kapitole 4. Prvním rozšíˇrením je sada nástroju˚ rozmístˇených na ruzných ˚ uzlech Kybernetického polygonu a na propojovacím zaˇrízení. Myšlenka tohoto rˇ ešení je automatizovanˇe pˇripojit externí zaˇrízení do virtuálního prostˇredí polygonu pomocí malé „krabiˇcky”, plnící funkci propojovacího prvku.Hlavním prvkem je centrální uzel, skrze který se uvedený propojovací prvek domluví s vnitˇrními uzly Kybernetického polygonu. Popis fungování jednotlivých cˇ ástí je popsán v kapitole 5 a ukonˇcen výpisy z úspˇešného ukázkového pˇríkladu. Druhým rozšíˇrením je tunelovací nástroj. Tento nástroj nabízí možnost vytvoˇrení virtuálního linkového propojení mezi dvˇema navzájem viditelnými uzly. Výsledný tunelovací nástroj je alternativa k vytváˇrení virtuálních lokálních sítí v rámci polygonu. Toto rozšíˇrení nabízí i šifrování provozu a muže ˚ být využito i na automatizované propojení prostˇrednictvím veˇrejné sítˇe. Bližšímu popisu a testovacímu provozu je vˇenována celá pˇredposlední kapitola. V závˇeru této práce jsou shrnuty výsledky úspˇešných testu˚ obou rˇ ešení. Výsledkem práce jsou tedy dvˇe sady nástroju, ˚ splnující ˇ oficiální zadání práce. Vytvoˇrené nástroje jsou uloženy v elektronické podobˇe na pˇriloženém CD.

1

2 KYPO KYPO je zkratka pro Kybernetický polygon, který vytvoˇrilo oddˇelení bezpeˇcnosti na Masarykovˇe univerzitˇe. Hlavním úˇcelem KYPO je simulace bezpeˇcnostních útoku˚ proti ruzným ˚ sít’ovým infrastrukturám a proti strojum, ˚ které jsou v tˇechto infrastrukturách umístˇeny. Veškerý provoz v polygonu je monitorován a nabízí tedy možnost detailnˇe studovat dopady bezpeˇcnostních útoku.[2] ˚

2.1

Vlastnosti

Prostˇredí KYPO je vytvoˇreno tak, aby bylo možné jej nainstalovat na libovolném cloudu založeným na modelu IaaS (Infrastructure as a Service). Poskytovatelé IaaS cloudu˚ nabízejí provozování infrastruktury virtuálních stroju˚ a KYPO již rˇ eší jenom pˇrekryvné sítˇe nad existující sít’ovou topologií. Momentálnˇe je celá infrastruktura zbudována v cloudovém prostˇredí poskytovaném Masarykovou univerzitou a akademickým sdružením CESNET. Pro každý bezpeˇcnostní scénáˇr se vytváˇrí izolovaný sandbox (virtuální pískovištˇe), ve kterém si nastavíme poˇcet stroju˚ a infrastrukturu sítˇe.

2.2

Architektura

Uživatelé komunikují s prostˇredím KYPO skrze vstupní portál s uživatelským rozhraním. Každé vytvoˇrené virtuální prostˇredí sandbox (obr. 2.1) obsahuje dedikovaný rˇ ídicí uzel (Scenario Management Node), který se stará o sestavení a správu daného prostˇredí. Tento rˇ ídicí uzel rovnˇež slouží jako vstupní bod do uzavˇreného virtuálního prostˇredí a poskytuje doplnkové ˇ služby, jako jsou kolektory pro monitorování sít’ového provozu apod. Klíˇcovým prvkem KYPO prostˇredí jsou uzly pro rˇ ízení simulovaných sítí LMN (LAN Management Node). Tyto uzly zajišt’ují abstrakci LAN sítˇe. LMN uzly jsou virtuální stroje, na kterých bˇeží linuxový systém se softwarovou implementací pˇrepínaˇce pomocí nástroje Open vSwitch[1]. Na tˇechto uzlech je vytvoˇreno standardní sít’ové rozhraní pro jakýkoli potˇrebný spoj. Každé rozhraní je propojeno s právˇe jedním dalším virtuálním strojem v sandboxu nebo s jiným LMN. Všechny spoje jsou uskuteˇcnˇeny na datové vrstvˇe pomocí VLAN. Spojením VLAN a softwarového pˇrepínaˇce je vytvorˇ ena stejná funkcionalita jako u hardwarového sít’ového pˇrepínaˇce. Jelikož veškerý provoz proudí tˇemito uzly, je možnost na nich uskuteˇcnit transparentní monitoring všech pˇripojených uzlu. ˚ LMN jsou taky pˇripojeny do rˇ í2

2. KYPO dicí sítˇe, která slouží pro komunikaci mezi LMN uzly a rˇ ídicím uzlem scénáˇre. Tato sít’ slouží pouze k pˇrenosu monitorovacích dat a rˇ ídicích pokynu˚ tak, aby pozorovaná sít’ nebyla ovlivnˇena. Do rˇ ídicí sítˇe nejsou pˇripojeny koncové uzly nacházející se v sandboxech. Na koncových uzlech se testují bezpeˇcnostní incidenty a bylo tedy tˇreba vyhnout se možnosti kompromitování rˇ ídicí sítˇe nebezpeˇcnými pakety. [4]

Obrázek 2.1: KYPO infrastruktura[3]

2.3

Pˇrehled nedostatku˚

Od spuštˇení KYPO prostˇredí se objevilo nˇekolik ruzných ˚ nedostatku˚ a možných vylepšení. Možnosti pro vylepšení testovacího prostˇredí se nacházejí zejména v rˇ ešení pˇrekryvných sítí. Aktuální nedostatky souvisí s propojením více fyzicky oddˇelených prostˇredí, s alternativními zpusoby ˚ propojení virtuálních uzlu˚ nebo s možnostmi pˇripojení reálných zaˇrízení do námi vybraného sandboxu. 3

2. KYPO 2.3.1 Propojení virtuálních prostˇredí Kybernetický polygon se momentálnˇe muže ˚ nacházet jenom v jednom cloudovém prostˇredí. Pro vytváˇrení testovacího prostˇredí nemusí být vždy k dispozici dostateˇcný výpoˇcetní prostor pro zprovoznˇení žádoucích simulací. Nˇekdy jsou dostupné výpoˇcetní prostory v ruzných ˚ lokalitách a možnost propojení tˇechto cloudu˚ pomocí tunelovacích mechanizmu˚ v jednu infrastrukturu by byla pˇríjemným doplnkem. ˇ 2.3.2 Pˇrekrývání VLAN Aktuálnˇe se rˇ eší pˇripojování jednotlivých uzlu˚ do testovací LAN pomocí virtuálních lokálních sítí (VLAN, Virtual Local Area Netvork). VLAN mechanizmy se využívají široce ve všech sítích a i v polygonu dobˇre plní svou funkci. V polygonu jsou v jedné úrovni VLANy používané pro rozdˇelení sít’ového provozu mezi fyzickými zaˇrízeními. Další úrovenˇ VLAN se nachází v sít’ování provozu mezi virtuálními stroji, kde jednotlivé propoje mají jinou identifikaci linky. Když se reálnˇe využívají dvˇe úrovnˇe VLAN nad sebou, vyskytuje se problém s identifikací. Tento problém se projevuje zahazováním paketu˚ na switchi. 2.3.3 Mechanizmus pˇripojení fyzických zaˇrízení Momentálnˇe jsou souˇcástí infrastruktury výhradnˇe virtuální stroje, at’ už servisní nebo uživatelské. V rámci rozšíˇrení funkcionalit kybernetického polygonu by tedy bylo velmi užiteˇcné pˇripojit do virtuálního prostˇredí vzdálený fyzický stroj. Ne všechny typy systému lze virtualizovat, a tedy rychlejší rˇ ešení muže ˚ být pˇripojit již existující fyzické zaˇrízení.

4

3 Návrh rˇešení Nedostatky, na které jsem poukázal v minulé kapitole, nejsou koneˇcné a pro každý problém existuje nˇekolik možností, jak jej vyˇrešit. V této práci se snažím nabídnout alternativní rˇ ešení na všechny tˇri zmínˇené problémy. Propojení ruzných ˚ virtuálních prostˇredí i pˇrekrývaní VLAN je rˇ ešeno stejným pˇrístupem. Rozdíl je jenom v možnosti zašifrování tunelu pro bezpeˇcné tunelování veˇrejnými sítˇemi. Výsledná rˇ ešení jsou tedy dvˇe – sada nástroju˚ pro pˇripojení externího zaˇrízení a nástroj pro tvorbu tunelu. ˚

3.1

Pˇripojení externího zaˇrízení

Tento návrh je popsán a aplikován jako možný zpusob ˚ pro rˇ ešení problematiky popsané v cˇ ásti 2.3.3. Pro pˇripojení externího zaˇrízení do koncové sítˇe potˇrebujeme nastavit oba konce tak, aby byly schopny se domluvit a vytvoˇrit mezi sebou tunel. Tˇemto nastavením se mužeme ˚ vyhnout pomocí reálné fyzické linky mezi soukromou sítí a zaˇrízením. Toto je ale komplikované z hlediska realizace a pravdˇepodobnˇe by to bylo i finanˇcnˇe velmi nároˇcné. Dalším rˇ ešením je využít sít’ internetového poskytovatele. Provider muže ˚ mít ve své síti nastavené MPLS (Multiprotocol Label Switching), který nabízí sít’ovým administrátorum ˚ možnost pˇrenášet sítí ruzné ˚ typy provozu a oddˇelovat je od sebe pomocí znakování. I když už internetový poskytovatel poskytuje VPN mechanizmy pro propojení dvou námi preferovaných uzlu, ˚ mužeme ˚ mít potˇrebu pˇripojit zaˇrízení nacházející se u jiného poskytovatele. V tomto pˇrípadˇe bychom museli privátní linku rˇ ešit se dvˇema poskytovateli. Pravdˇepodobnˇe nejjednodušeji a nejlevnˇeji mužeme ˚ propojit dva body vytvorˇ ením vlastního virtuálního propojení skrze již existující sítˇe. Pro toto je již vymyšleno mnoho mechanizmu˚ a jejich popis se cˇ asto oznaˇcuje jako VPN (Virtual Private Network, Virtuální privátní sít’). Možným rˇ ešením, jež dále rozvíjím v této práci, je využití již vytvorˇ ené VPN technologie a na základˇe této technologie vytvoˇrit potˇrebnou infrastrukturu pro pˇripojení externího zaˇrízení. 3.1.1 Infrastruktura Automatizované rˇ ešení by nebylo možné postavit cˇ istˇe na jednom nástroji uloženém na jednom uzlu - a tedy souˇcásti návrhu je využití nástroju˚ na jednotlivých uzlech Kybernetického polygonu a pˇredprogramovaného pro5

ˇ 3. N ÁVRH REŠENÍ

pojovacího zaˇrízení. ˇ Rídicí uzel Hlavním prvkem infrastruktury pro pˇripojení externího zaˇrízení je rˇ ídicí uzel, který je souˇcástí vstupního portálu. Tento uzel bude inicializovat VPN servery na LMN uzlech. Inicializace bude probíhat skrze rˇ ídicí portál KYPO, který bude propojen s rozhraním rˇ ídicí cˇ ásti. Tento uzel bude mít uložené informace o všech aktuálních VPN serverech. Skrze tento uzel budou námi pˇredprogramované propojovací zaˇrízení nebo pˇrímo cílové stroje stahovat detailní informace pro pˇrihlášení k žádanému stroji. Tento uzel je tedy centrální cˇ ásti celého rˇ ešení, skrze kterou se jednotlivé cˇ ásti domlouvají. LMN uzel Na tomto uzlu budou vytvoˇrené VPN servery, skrze které se budou externí zaˇrízení pˇripojovat do sandbox prostˇredí. VPN server bude mít nastavena pˇrístupová práva pro vybrané propojovací zaˇrízení tak, aby nebylo možné pˇripojit nežádoucí zaˇrízení. SMN uzel Tento uzel je vstupním bodem k LMN uzlum. ˚ Je tedy tˇreba zajistit, aby správnˇe pˇresmˇerovával provoz mezi LMN uzlem a externími zaˇrízeními. Propojovací zaˇrízení Toto rˇ ešení pro pˇrihlašování externího zaˇrízení poˇcítá s malým propojovacím zaˇrízením, tedy malým poˇcítaˇcem se základními pˇredprogramovanými funkcemi. Toto zaˇrízení bude mít dvˇe sít’ová rozhraní. Propojovací prvek bude zajišt’ovat, po pˇripojení do sítˇe, stáhnutí detailních informací z rˇ ídicího uzlu a spuštˇení VPN klienta.Výsledek bude takový, že po pˇripojení propojovacího zaˇrízení do sítˇe a do externího zaˇrízení, bude externí zaˇrízení automaticky pˇripojeno k žádané privátní síti. Externí zaˇrízení Externím zaˇrízením muže ˚ být jakékoli zaˇrízení, které pˇripojíme k veˇrejné síti skrze propojovací zaˇrízení. 6

ˇ 3. N ÁVRH REŠENÍ

3.2

Propojení dvou uzlu˚

Tento scénáˇr je urˇcen k propojení dvou uzlu, ˚ které máme plnˇe pod kontrolou. V rámci této práce jsou v tomto scénáˇri rˇ ešeny dvˇe problematiky popsané v sekcích 2.3.1 a 2.3.2. Nástroj, pokrývající obˇe zmínˇené problematiky, bude mezi dvˇema body vytváˇret tunel - imitující fyzické propojení na bázi Ethernet. Souˇcásti nástroje bude volitelné zabezpeˇcení vzniklého tunelu. Vytvoˇrený tunel bude možné použít pro propojení virtuálních stroju. ˚ V pˇrípadˇe zbudování více tunelu, ˚ je možné vytvoˇrit pˇredstavu spoleˇcné linkové sítˇe mezi více uzly a nahradit tak aktuální rˇ ešení pomocí VLAN. Nástroj bude taky schopen vytvoˇrit zabezpeˇcený tunel mezi dvˇema vzdálenými uzly. Takto vzniklý tunel muže ˚ být využit jako propoj mezi dvˇema námi využívanými cloudy. 3.2.1 Infrastruktura Toto rˇ ešení je navrženo na sestavování tunelu mezi dvˇema uzly, které je rˇ ízeno z centrálního uzlu. ˇ Rídicí uzel Centrální uzel, na kterým se nachází nástroj pro tvorbu tunelu. ˚ Tento uzel má neomezený vzdálený pˇrístup k cílovým uzlum. ˚ Koncové body Jedná se vždy o dvojicí zaˇrízení s operaˇcním systémem Linux Debian, mezi kterými se vytvoˇrí statický tunel. Zaˇrízení musí vlastnit veˇrejný klíˇc rˇ ídicího uzlu, jenž vzdálenˇe nastavuje jednotlivé detaily tunelu.

7

4 Popis použitých VPN technologii Pro implementaci rˇ ešení popsaných v kapitole 3 jsem využil již existující VPN technologie. Výsledné nástroje pracují nad VPN technologiemi a rˇ eší automatizované nastavení tˇechto VPN systému. ˚ Každé výše popsané rˇ ešení využívá jiný typ VPN a tady i jiné technologie. Systém, rˇ ešící pˇripojení externího zaˇrízení, je vybudován na softwaru OpenVPN. Nástroj, propojující dva uzly, pracuje s tunelovacím mechanizmem l2tpv3 v kombinaci se zabezpeˇcením IPSec.

4.1

OpenVPN

OpenVPN je otevˇrený software, který implementuje VPN techniky pro tvorˇ ení zabezpeˇcených tunelu˚ mezi dvˇema uzly . Byl vytvoˇren Jamesem Yonanem a je publikován pod licencí GPL (GNU General Public Licence). Tento otevˇrený software má taky placenou cˇ ást, která se ale týká jenom více uživatelsky pˇrívˇetivé serverové cˇ ásti spojení. Pomocí otevˇrené verze mužeme ˚ vytvoˇrit klient-server i klient-klient spojení. Nabízí možnost vytvoˇrení tzv. pˇremostˇení, tedy simulování linkové vrstvy nebo imitaci smˇerovaˇce. Implementace OpenVPN je dostupna na všech široce rozšíˇrených operaˇcních systémech. Je podporována jak na klasických stolních a serverových distribucích tak i na mobilních zaˇrízeních. OpenVPN je taky dostupný na veˇrejných distribucích ve smˇerovacích zaˇrízeních jako jsou OpenWRT nebo IPFire. OpenVPN není kompatibilní s IPSecem nebo jinými VPN balíˇcky. Implementace obsahuje stejný binární soubor pro klienta i server. Souˇcástí VPN uzlu jsou i volitelné konfiguraˇcní soubory, šifrovací a autentizaˇcní klíˇce. Poˇcet klíˇcu˚ záleží od zvoleného zpusobu ˚ autentizace. OpenVPN je nejrozšíˇrenˇejší veˇrejnˇe používaný VPN mechanizmus nejenom pro jeho širokou podporu ale i pro velmi jednoduché nastavení. Jednoduchost konfigurace rovnˇež usnadnuje ˇ pochopení, jak tento software funguje. Pˇrehledné manuálové stránky v kombinaci s jednoduchosti základního návrhu ulehˇcují pochopení pˇrípadných komplikovanˇejších nastavení. OpenVPN jde rozšíˇrit pomocí skriptu˚ nebo pluginu˚ tˇretích stran, které mohou být definovány na ruzných ˚ místech konfigurace. Souˇcástí distribuce jsou ukázkové scripty, které mužeme ˚ použít pˇrímo nebo je pro své úˇcely upravit. Úˇcelem tˇechto rozšíˇrení je doplnit OpenVPN pokroˇcilejšími zpu˚ soby logování, autentizací, dynamickou úpravou firewallu, ˚ prací s pokrocˇ ilejšími databázemi atd. [8][13] 8

4. P OPIS POUŽITÝCH VPN TECHNOLOGII 4.1.1 Bezpeˇcnost Pro zabezpeˇcení komunikace byl vybrán protokol TLS (Transport Layer Security) puvodnˇ ˚ e znám jako SSL (Secure Sockets Layer).Tyto protokoly nabízejí možnosti symetrického i asymetrického šifrování ale i hašovací algoritmy. Funkcionalita SSL/TLS je zajištˇena knihovnou OpenSSL.[12] Každý paket, který je posílán pˇres vytvoˇrený tunel, je nejdˇrív zašifrován a následnˇe podepsán. Tímto procesem se splní všechny požadavky na bezpeˇcnou komunikaci - tedy autentizace, autorizace, duvˇ ˚ ernost a integrita dat. OpenVPN používá pro šifrování pˇrenášených dat symetrickou šifru. Ve výchozím nastavení se pro šifrování používá bloková šifra Blowfish s délkou klíˇce 128 bitu. ˚ Je možnost nastavit jakoukoli jinou šifru z knihovny OpenSSL. Podporované šifry jsou Blowfish, Camellia, DES, RC2, RC4, RC5 a IDEA. Bezpeˇcnost je rozdˇelena na dva autentizaˇcní mody, statický mód a TLS mód. Obˇe tyto možnosti plní svou funkci, ale pro dlouhodobou bezpeˇcnost je doporuˇcena druhá možnost, využívající certifikaˇcní autoritu, privátní a veˇrejné klíˇce. OpenVPN podporuje taky nešifrované spojení, ale to se nedoporuˇcuje. Implicitnˇe je nastaveno statické šifrování komunikace, které je nejjednodušší na správu a je podstatnˇe ménˇe nároˇcné na výpoˇcetní výkon než asymetrické šifrování. Pro zajištˇení bezpeˇcné komunikace poskytuje OpenVPN hlavnˇe šifrovací technologie. Mimoto je pro zvýšení bezpeˇcnosti možnost využít další zajímavé bezpeˇcnostní mechanizmy na úrovni operaˇcního systému jako jsou neprivilegovaný režim, chroot, autentizace jménem a heslem. [8] •

V neprivilegovaném režimu se nejdˇrív provede inicializace tunelu pod právy superuživatele. Když již je tunel plnˇe funkˇcní a práva superuživatele již nejsou potˇreba, zmˇení se vlastník procesu na uživatele s omezenými možnostmi.

•

Chroot nabízí možnost omezit OpenVPN proces jenom do podstromu souborového systému. Pokud se stane, že útoˇcník získá kontrolu nad OpenVPN procesem, získá pˇrístup jenom do zvoleného podstromu a má tedy velmi omezené možnosti pusobnosti. ˚

•

Údaje, poskytnuté klientem, jsou pomocí OpenVPN pˇredány k ovˇerˇ ení aplikaci tˇretí strany. 9

4. P OPIS POUŽITÝCH VPN TECHNOLOGII 4.1.2 Komunikace

OpenVPN byla navrhnuta tak, aby ideálnˇe fungovala nad protokolem UDP. Protokol UDP funguje na transportní vrstvˇe a je považován za nespolehlivý protokol. Na rozdíl od protokolu TCP totiž nezaruˇcuje doruˇcení všech paketu˚ ve správném poˇradí, vícenásobné doruˇcení nebo kontrolu, zda pakety dorazily do cíle. Takový pˇrenos v mnohém pˇripomíná reálný provoz na fyzické vrstvˇe nebo na veˇrejné sítí. V reálném provozu je totiž komunikace na síti cˇ asto ztrátová. Na spodních 3 úrovních ISO/OSI modelu se nepoˇcítá s dodateˇcnou režii provozu pro zajištˇení spolehlivého pˇrenosu dat. Pokud je tˇreba, je tato režie rˇ ešena protokolem TCP na transportní vrstvˇe nebo eventuálnˇe samotnými aplikacemi ve vyšších vrstvách. Pokud je provoz pomocí UDP blokován firewallem, mužeme ˚ použít protokol TCP nebo HTTP proxy. Tato rˇ ešení mohou zpusobit ˚ viditelný pokles rychlosti pˇrenosu dat. Tento pokles je zpusoben ˚ mechanizmem pro spolehlivé doruˇcení paketu˚ u protokolu TCP. Na pomalejších linkách tedy ˇ muže ˚ být OpenVPN, využívající protokol TCP, výraznˇe pomalejší. Rešení tunelu pˇres HTTP/HTTPS proxy muže ˚ náš tunel ještˇe víc zpomalit, ale nabízí možnost vytvoˇrení VPN v místech, kde je povolen jen HTTP/HTTPS provoz.[8] OpenVPN využívá pro zakonˇcení tunelu˚ dva ruzné ˚ ovládaˇce - TUN a TAP. Tyto ovládaˇce jsou napojené na OpenVPN proces v uživatelském prostˇredí a chovají se jako virtuální sít’ová rozhraní. Nabízí standardní zpusob, ˚ jak mohou aplikace, bˇežící v uživatelském prostoru, komunikovat se sít’ovými rozhraními aniž by potˇrebovaly oprávnˇení superuživatele. Tyto ovládaˇce jsou pro vˇetšinu operaˇcních systému˚ standardem. Na obou stranách spojení musí být vždy bud’ jen TAP rozhraní nebo TUN rozhraní. Ovládaˇc TAP nabízí nízkoúrovnovou ˇ podporu pro tunelování Ethernetu, zapouzdˇruje totiž provoz do rámcu˚ Ethernet 802.3. Je tedy využit k vytvoˇrení pˇremostˇení mezi dvˇema koncovými body. Toto pˇremostˇení vytváˇrí iluzi pˇrímého fyzického propojení. Na sít’ové vrstvˇe mužeme ˚ tedy využít námi preferované protokoly. Pomocí rˇ ešení s TAP mužeme ˚ taky využít celou vysílací (broadcast) doménu. Naproti tomu ovládaˇc TUN zapouzdˇruje provoz do IPv4 rámcu˚ a vyˇ tváˇrí tím IPv4 tunel na sít’ové vrstvˇe. Rešení pomocí rozhraní TUN je úspornˇejší díky tomu, že je oproštˇeno o jednu vrstvu zapouzdˇrení. Pˇri využití rozhraní TUN mužeme ˚ simulovat smˇerovanou topologii i s rozdˇelením do ruzných ˚ podsítí a s využitím našeho vlastního adresního rozsahu. [11] 10

4. P OPIS POUŽITÝCH VPN TECHNOLOGII

4.2

IPSec/l2tpv3

Pro šifrovaný tunel je toto opravdu velmi zajímavá kombinace. Oba tyto protokoly jsou také známy jako sít’ové standardy a tak jsou podporovány na široké skále ruzných ˚ platforem. Díky tomu mužeme ˚ tvoˇrit šifrované l2tp tunely mezi ruznými ˚ operaˇcními systémy od stolních, serverových, mobilních a až po sít’ová zaˇrízení. Oba tyto protokoly jsou navzájem nezávislé ale tím, že se mohou tak dokonale doplnovat, ˇ jsou velmi cˇ asto využívány pro zabezpeˇcené tunely pˇres veˇrejné sítˇe. Pro bližší pochopení, jak kombinace obou tˇechto protokolu˚ funguje, nejdˇrív popíši tyto dva protokoly samostatnˇe a následnˇe základní principy spoleˇcné komunikace a zabezpeˇcení vytvoˇreného tunelu. 4.2.1 L2tpv3 (Layer Two Tunneling Protocol version 3) Tento protokol vznikl jako standard, navazující na protokol l2tp, navržený pro tunelování linkové vrstvy skrze veˇrejné sítˇe. Motivací pro vznik l2tp byla potˇreba vytvoˇrit tunelovací protokol pro rámce PPP (Point-to-Point Protocol). Puvodní ˚ protokol se inspiroval kombinací protokolu PPTP (Pointto-Point Tunneling Protocol ) od Microsoftu a tunelovací technologie L2F (Layer 2 Forwarding Protocol) od Cisca. L2tp je podporován širokým spektrem sít’ových protokolu˚ jako IP, AppleTalk, ATM, SONET atd. L2tp muže ˚ být použit jako tunelovací protokol na veˇrejném internetu nebo i na ruz˚ norodých interních sítích. Nejviditelnˇejším rozdílem mezi l2tpv2 a l2tpv3 je možnost zapouzdˇrit pˇrenášená data do ruzných ˚ rámcu˚ linkové vrstvy. Této možnosti se dosáhlo rozdˇelením jednotlivých mechanizmu˚ v l2tp a tím pádem vytvoˇrením modulárního rˇ ešení. Druhá verze totiž umožnovala ˇ jenom zapouzdˇrení do protokolu PPP. Protokol l2tpv3, s veškerou funkcionalitou popsanou v RFC, je implementován pouze jako komerˇcní produkt. Základní podpora tohoto protokolu je již souˇcástí nˇekterých linuxových distribucí obsahující jádro 2.6.35 a vyšší - napˇríklad Debian od verze Squeezy. Základní podpora taky nabízí zapouzdˇrení ruzných ˚ rámcu˚ linkové vrstvy - napˇríklad velmi rozšíˇrený protokol Ethernet. [16] 4.2.2 IPSec (Internet Protocol Security) IPSec je otevˇrený standart stanovený pˇres IETF. V sérii RFC, vˇenované IP bezpeˇcnosti, jsou popsány jeho cˇ ásti a možná rozšíˇrení. Implementace standardu˚ IPSec pˇredstavuje sadu protokolu, ˚ urˇcených pro autentizaci a šifrování jednotlivých paketu, ˚ které jsou souˇcástí zabezpeˇcené komunikace. 11

4. P OPIS POUŽITÝCH VPN TECHNOLOGII Standardnˇe pakety nejsou nijak zabezpeˇceny. Pokud si nˇekdo pˇreje urcˇ itou míru soukromí a autenticity pˇrenášených dat, vybere si nˇejakou VPN nebo tunelovací aplikaci a o bezpeˇcnost komunikace se starají tyto aplikace. Tato bezpeˇcnost ale bude na úrovni aplikaˇcní vrstvy a tedy kdykoli nˇekdo zachytí takto šifrovanou komunikaci, muže ˚ z hlaviˇcky IP paketu˚ vyˇcíst cílovou a zdrojovou adresu, popˇrípadˇe pakety nˇejak pozmˇenit a ovládnout komunikaci. Vidíme tedy, že šifrování na vyšších vrstvách nemusí být to nejbezpeˇcnˇejší rˇ ešení. Standard zabezpeˇcení sít’ové vrstvy byl ale navržen pro zabezpeˇcení veškeré komunikace - tedy komunikace na sít’ové vrstvˇe a veškerých dalších protokolu˚ a dat, které jsou sít’ovou vrstvou zapouzdˇreny. Dokonce u nové verze internetového protokolu IPv6 byl nˇejaký cˇ as zamýšlen jako povinnost. Od toho se nakonec ustoupilo, ale i pˇresto se tomuto protokolu zaˇcíná dostávat vˇetší pozornosti. IPSec nabízí bezpeˇcnostní služby na sít’ové vrstvˇe tím, že umožnuje ˇ komunikujícím stranám zvolit si šifrovací algoritmus pro komunikaci a vzájemnou výmˇenu klíˇcu˚ - pokud si zvolí asymetrický zpusob ˚ šifrování. IPSec muže ˚ být použit pro ochranu jednotlivých komunikaˇcních kanálu˚ pro ruzné ˚ aplikace nebo celého provozu. Muže ˚ propojovat dva samostatné uzly, sluˇcovat dvˇe brány do privátních sítí, nebo sloužit jako brána do privátní sítˇe pro samostatné uzly. Termín Brána odkazuje na prostˇredníka v privátní sítí, pˇres kterého se mužeme ˚ do sítˇe pˇripojit - tedy router nebo firewall, které mají nainstalovanou implementaci IPSecu.[17] 4.2.3 Bezpeˇcnost Protokol l2tp neposkytuje žádné pokroˇcilé bezpeˇcnostní mechanizmy. Jenom buduje tunel a poskytuje základní autentizaci druhé strany pomocí identifikace tunelu a identifikace spojení. Pokud má být tunel nˇejak zabezpeˇcen, využívá se protokol IPSec. IPSec mužeme ˚ využít pro zabezpeˇcení jenom l2tp tunelu pomocí cˇ ísla IP protokolu – 17 pro UDP a 115 pro l2tp.[9] Pˇri využití UDP protokolu se zabezpeˇcení specifikuje pro jednotlivé porty. Security Association (SA) SA jsou jádrem celé bezpeˇcnostní architektury IPSec. Jednotlivé SA definují, jaký zpusob ˚ zabezpeˇcení se má aplikovat na pakety v závislosti na tom, kdo je odesílá, kde smˇerˇ ují a jaký náklad je zapouzdˇren uvnitˇr. Možnosti zabezpeˇcení nabízené pˇres SA záleží na zvoleném bezpeˇcnostním protokolu a módu komunikace. SA mohou být dynamicky sjednané mezi dvˇema komunikujícími uzly v závislosti na bezpeˇcnostní politice nastavené adminis12

4. P OPIS POUŽITÝCH VPN TECHNOLOGII trátory uzlu. ˚ Další možností (ˇcastˇeji používanou) je nastavení SA manuálnˇe administrátory na každém uzlu zvlášt’. Každá SA je jedineˇcnˇe identifikovatelná pomocí cílové IP adresy, bezpeˇcnostního protokolu a SPI (Security Parameters Index). Bezpeˇcnostním protokolem muže ˚ být AH nebo ESP. SPI je 32 bitové cˇ íslo, obvykle zvolené cílovým uzlem dané SA, které je souˇcástí každého ESP nebo AH paketu a má hlavní význam pro vzdálený uzel. Každá SA je dohoda mezi dvˇema uzly o zabezpeˇcení jednosmˇerné komunikace a tedy pokud si dva uzly potˇrebují zabezpeˇcit data v obou smˇerech, potˇrebují mít SA pro každý smˇer. Taky pokud je potˇreba zabezpeˇcit komunikaci souˇcasnˇe pomocí ESP a AH, vytváˇrí se SA pro oba protokoly zvlášt’. SA funguje ve dvou módech - transportním a tunelovacím. Transportní mód se využívá, pokud chceme ochránit jenom protokoly transportní a aplikaˇcní vrstvy. V tunelovacím módu se celý paket stává souˇcástí zabezpeˇcené cˇ ásti a pˇred bezpeˇcnostní hlaviˇcku se pˇridá nová IP hlaviˇcka. Bezpeˇcnostní brány, které zabezpeˇcují provoz mezi sítˇemi, potˇrebují mít pro správnou funkˇcnost nastaven tunelovací mód. Pokud se IPSec nastavuje na koncových uzlech, mužeme ˚ si vybrat, jaký mód upˇrednostníme. [5] Bezpeˇcnostní databáze Každý IPSec uzel má ve své správˇe dvˇe databáze, Security Policy Database (SPD) a Security Association Database (SAD). Pˇri jakékoliv komunikaci se kontrolují záznamy v SPD a hledá se pro nˇe informace o bezpeˇcnostních politikách. Tyto informace následnˇe odkazují na SA uložené v SAD. Pakety se následnˇe zpracují podle nalezených Bezpeˇcnostních asociací. [5] Authentication Header AH protokol je souˇcástí IPSec standardu. Funguje pˇrímo nad sít’ovou vrstvou s IP protokolovým cˇ íslem 51.[9] Poskytuje autentizaci jednotlivých paketu, ˚ tedy ujištˇení, že paket pˇrišel v nepozmˇenˇeném tvaru od adresáta uloženého v IP hlaviˇcce. AH nabízí ruznou ˚ úrovenˇ nepopíratelnosti puvodu ˚ paketu v závislosti na duvˇ ˚ eryhodnosti použitého šifrovacího algoritmu a zvoleného systému výmˇeny klíˇcu. ˚ Autentizaˇcní hlaviˇcka muže ˚ být použita ve dvou módech. Tunelovací mód, kdy je vytvoˇrena nová IP hlaviˇcka a celý puvodní ˚ paket je uložen za AH nebo transportní mód s AH umístˇenou mezi puvodní ˚ IP hlaviˇcku a ostatní data. Tunelovací mód nabízí kompletní autentizaci paketu, ale za cenu vˇetší robustnosti. Transportní mód za cenu nˇekolika bajtu˚ dat navíc 13

4. P OPIS POUŽITÝCH VPN TECHNOLOGII nabízí autentizaci pˇrenášených dat. Autentizaˇcní cˇ ást paketu je generována na vysílající stranˇe na základˇe SA pro cílovou adresu. Vytvoˇrí se HMAC (hash Message Authentication Code) celého IP paketu, zahrnující IP hlaviˇcku, AH hlaviˇcku a pˇrenášená data. Na stranˇe pˇríjemce se pakety ovˇerˇ ují na základˇe zvolené SA, identifikace které je v AH hlaviˇcce. Pomocí šifrovacích mechanizmu˚ zvolených v SA se vytvoˇrí HMAC otisk paketu a zkontroluje se s hodnotou v AH hlaviˇcce.[7] Encapsulating Security Payload ESP protokol je podobnˇe jako AH souˇcástí IPSec standardu. Nabízí autentizaci, duvˇ ˚ ernost a integritu dat. Funguje pˇrímo nad sít’ovou vrstvou s IP protokolovým cˇ íslem 50. Hlavní vlastností tohoto protokolu je šifrování obsahu pˇrenášených dat pomocí symetrických šifrovacích algoritmu. ˚ ESP podporuje rozšíˇrené algoritmy jako jsou 3DES, AES, Blowfish. Výbˇer algoritmu záleží na dohodˇe obou stran komunikace pomocí ISAKMP protokolu. Protokoly ESP a AH jsou si velmi podobné a tedy stejnˇe jako u Authentication Header protokolu mužeme ˚ data pˇrenášet ve dvou modech. Transportní mód zapouzdˇrí a zašifruje jenom pˇrenášená data. Tunelovací mód zapouzdˇrí celý IP paket a vytvoˇrí nový paket, který vloží pˇred ESP hlaviˇcku. ESP zapouzdˇruje pˇrenášená data mezi ESP hlaviˇcku a ESP pˇrívˇes (trailer), popˇrípadˇe se ještˇe za ESP pˇrívˇes muže ˚ pˇridat autentizaˇcní paket, který ovˇerˇ í puvod ˚ celého paketu.[6] ISAKMP/IKE ISAKMP (Internet Security Association and Key Management Protocol) definuje procedury pro autentizaci a komunikaci uzlu. ˚ Dále popisuje techniky vytváˇrení a udržování bezpeˇcnostních asociací a generování klíˇcu. ˚ Všechny tyto procedury jsou nezbytné pro nastavení a udržování bezpeˇcné komunikace pomocí IPSecu ale i jiných bezpeˇcnostních protokolu. ˚ Pomocí ISAKMP se vytvoˇrí bezpeˇcnostní asociace (SA) pro spojení, ve kterém se provádí výmˇena klíˇcu˚ a ustanovení bezpeˇcnostních asociací pro jiné bezpeˇcnostní protokoly. ISAKMP nabízí rozhraní pro autentizaci a výmˇenu klíˇcu, ˚ ale pˇrímá výmˇena klíˇcu˚ je již provádˇena pomocí jiného protokolu. V pˇrípadˇe IPSecu je výmˇena šifrovacích klíˇcu˚ mezi uzly rˇ ešena pomocí IKE (Internet Key Exchange). [15] 14

4. P OPIS POUŽITÝCH VPN TECHNOLOGII 4.2.4 Konfigurace Protokol l2tpv3 je zatím v linuxové distribuci dostupný jenom v manuální verzi. Nastavení obou stran tunelu se musí shodovat, jinak pakety budou zahozeny pˇrijímající stranou. Na obou koncových uzlech mužeme ˚ nastavit, zda bude tunel vytvoˇren nad protokolem IP nebo nad protokolem UDP. Pokud je vybrán protokol UDP, je nutné pˇri specifikaci tunelu popsat lokální a vzdálený UDP port. Pro vytvoˇrení tunelu se zadává taky identifikace tunelu a IP adresy obou uzlu. ˚ Konfigurace l2tpv3 koncového uzlu je velmi jednoduchá. Nejdˇrív je tˇreba pˇridat jednotlivé l2tp moduly do linuxového jádra. Aktuálnˇe jsou možnosti v Ethernetovém nebo PPP zapouzdˇrení. Moduly se pˇridávají pˇríkazem „modprobe“. Pro vytvoˇrení tunelu se parametry zadávají pˇrímo za pˇríkazem „ip l2tp add tunnel“. Podobnˇe se nastavují jednotlivé komunikaˇcní kanály.

Algoritmus 4.1 Pˇríklad nastavení l2tp tunelu # modprobe l2tp_eth # ip l2tp add tunnel tunnel_id 11 peer_tunnel_id 22 encap udp udp_sport 111 udp_dport 222 local 1.1.1.1 remote 2.2.2.2 # ip l2tp add session tunnel_id 11 session_id 111 peer_session_id 222 [ name název_rozhraní ] # ifconfig název_rozhraní (l2tpeth0) up

Konfigurace IPSec protokolu je již o nˇeco komplikovanˇejší. Pro linuxové distribuce jsou v souˇcasné dobˇe dostupné dvˇe implementace IPSecu - Openswan a Racoon v kombinaci s ipsec-tools. Konfigurace jednotlivých implementací jsou si podobné. Nastavení IPSec uzlu popíši pomocí implementace Openswan. Specifikovat parametry pro IPSec mužeme ˚ pˇrímo v pˇríkazovém rˇ ádku, ale pˇrehlednˇejší konfigurace se provádí pomocí textových konfiguraˇcních souboru˚ ipsec.secrets a ipsec.conf, které se implicitnˇe nachází v adresáˇri /etc. Soubor ipsec.secrets obsahuje odkazy nebo textovou formu privátních bezpeˇcnostních prvku˚ pro jednotlivé smˇery komunikace. Privátní klíˇce i hesla jsou definovány zdrojovou a cílovou adresou a typem zabezpeˇcení. Typ muže ˚ být PSK (Pre Shared Key) nebo RSA. Soubor ipsec.conf obsahuje detailní informace, jak se mají jednotlivá spojení zpracovávat. 15

4. P OPIS POUŽITÝCH VPN TECHNOLOGII Algoritmus 4.2 Pˇríklad nastavení Ipsec-Esp tunelu pomocí hesla # sample /etc/ipsec.secrets file for 10.1.0.1 10.1.0.1 10.2.0.1: PSK "secret shared by two hosts" # basic main ipsec configuration config setup protostack=netkey #sample connection conn my_connection authby=secret auto=start type=tunnel left=10.1.0.1 leftprotoport = 17/111 right=10.2.0.1 ike=aes256-sha1;modp2048 phase2=esp phase2alg=aes256-sha1;modp2048 Na obrázcích 4.1 a 4.2 byl nastaven jednoduchý l2tp tunel šifrovaný pomocí ESP. Pomocí parametru „leftprotoport” je zajištˇeno, že bude šifrován pouze tunelovaný provoz.[18]

16

5 Pˇripojení externího zaˇrízení do KYPO Pro pˇripojení externího zaˇrízení do kybernetického polygonu jsem využil VPN rˇ ešení OpenVPN. Pro automatizaci VPN prostˇredí jsem využil programovací jazyk Python[20], skriptovací jazyk bash a SQL databázi postgreSQL[19]. Infrastruktura LMN uzlu, ˚ SMN uzlu˚ a taky rˇ ídicí uzel fungují pod operaˇcním systémem Debian a tedy moje práce je pˇrizpusobena ˚ tomuto systému. Tato práce nabízí rˇ ešení centrálního uzlu, skripty pro spuštˇení OpenVPN na LMN uzlech a skripty pro nastavení externího zaˇrízení pro pˇripojení k LMN uzlu.3.1 Myšlenka tohoto rˇ ešení je vytvoˇrit prostˇredí, pomocí kterého se inicializují OpenVPN servery pro jednotlivé klienty v LMN uzlech, DNAT (Destination Network Address Translation) pravidla na SMN uzlu a detaily o vytvoˇreném serveru se uloží. Následnˇe, když se klient pˇrihlásí do sítˇe, automaticky si vyžádá konfiguraˇcní soubor pro pˇrihlášení k LMN uzlu a pˇripojí se skrze tento uzel k žádanému sandboxu.

5.1

ˇ Rídicí cˇ ást

ˇ Rídicí cˇ ást poskytuje jednoduché rozhraní pro vytvoˇrení a smazání OpenVPN serveru˚ a uložení podrobnosti o každé spuštˇené instanci do SQL databáze. Centrální uzel taky nabízí cgi skript (Common Gateway Interface) pro zaslání konfiguraˇcního souboru externím zaˇrízením. Tato cˇ ást je rˇ ešena pomocí programovacího jazyka Python a jako celek uložena v souboru kypochief. Soubor kypochief obsahuje tˇri objektové tˇrídy a nˇekolik obslužných funkcí pro obsluhu specifických parametru˚ z pˇríkazového rˇ ádku a práci s hlavními tˇrídami. Hlavní tˇrídy v programu kypochief jsou DbWorker, KeyMaker a VpnMaster.

5.1.1 Tvorba VPN serveru˚ Na jednotlivých LMN uzlech se nachází skripty napsané v bashi (viz kapitola 5.2), které se starají o nastavení OpenVPN serveru a virtuálního síˇ t’ového rozhraní. Rídicí cˇ ást tedy nenastavuje pˇrímo LMN uzly, ale jenom spustí skripty na LMN uzlech se správnými parametry. Komunikace s LMN uzly je ustanovena pomocí SSH spojení na uživatele root. Všechny LMN a SMN uzly obsahují veˇrejný klíˇc od rˇ ídicího uzlu a tedy mužeme ˚ se pˇrihlásit z rˇ ídicího uzlu na jakýkoliv uzel v KYPO infrastruktuˇre. 17

ˇ ˇ 5. P RIPOJENÍ EXTERNÍHO ZA RÍZENÍ DO KYPO

VpnMaster Tˇrída obsahující dvˇe hlavní metody run_vpn() a close_vpn(). Bˇehem inicializace tˇrídy se pomocí parametru˚ pˇredávají IPv4 adresy SMN a LMN uzlu˚ a x509-jméno klienta. Bˇehem nastavování parametru˚ jsou IP adresy kontrolovány pro validní IPv4 tvar. Jméno klienta musí být identické s x509-jménem ve veˇrejném klíˇci klienta, jinak nedojde k vytvoˇrení tunelu mezi LMN uzlem a klientem. Pro komunikaci se vzdálenými uzly pomocí SSH používám knihovnu paramiko, která poskytuje implementaci SSHv2 protokolu[21]. Paramiko má srozumitelné a jednoduché použití metod a je to kvalitní pomocník pro použití SSH v programovacím jazyce Python. run_vpn() Tato metoda nejdˇrív vygeneruje a podepíše RSA klíˇce pro server s x509jménem ve tvaru server_[jméno klienta]. Tento pár klíˇcu˚ je následnˇe poslán v textové formˇe skriptu na LMN uzlu v podobˇe parametru. ˚ Poté se pomocí knihovny paramiko pˇrihlásí na SMN uzel a spustí na tomto uzlu pˇríkaz, který se pomocí SSH pˇrihlásí k LMN uzlu a spustí tam skript new_client (viz kapitola 5.2.1). Metoda cˇ eká na ukonˇcení programu a naˇcte standardní výstup pro naˇctení použitého UDP portu. V pˇrípadˇe vyskytnutí problému, se veškeré nastavení na LMN uzlu smaže a vygeneruje se výjimka s oduvodnˇ ˚ ením. Pokud spuštˇení OpenVPN serveru probˇehlo v poˇrádku, uloží se mezi argumenty tˇrídy UDP port, na kterým naslouchá server. V poslední cˇ ásti se nastaví pˇreposílání OpenVPN provozu skrze SMN uzel na vnitˇrní uzel pomocí iptables[22]. Pro správné fungování pˇridávám do NAT (Network Address Translation) tabulky „prerouting” pravidlo pro pˇreklad sít’ových adres podle cílové adresy. Pˇreklad adres je nastaven na veˇrejnou adresu SMN uzlu a specifický UDP port, který je zrcadlením UDP portu otevˇreného pro OpenVPN server na LMN uzlu. Provoz, splnující ˇ tyto dvˇe podmínky, se pˇreposílá na UDP port, na kterým naslouchá OpenVPN server na LMN uzlu. close_vpn() Metoda, rušící OpenVPN server na LMN uzlu. Funguje velmi podobnˇe jako metoda run_vpn(). Nejdˇrív se zruší OpenVPN instance na LMN uzlu zavoláním skriptu del_client s jedním parametrem a to jménem klienta (viz 18


kapitola 5.2.2). Následnˇe se zruší pravidlo v iptables na SMN uzlu pˇreposílající provoz na zrušený OpenVPN server. 5.1.2 Práce s databází Tato práce využívá pro ukládaní detailu˚ o aktivních VPN serverech objektovˇerelaˇcní databázový systém PostgreSQL. Tento systém nabízí funkce pro tvorbu vlastních tabulek a veškerou práci s tˇemito tabulkami. V jazyce Python je pro práci s PostgreSQL databází implementován balíˇcek psycopg2[23]. Tento balíˇcek používám ve tˇrídˇe DbWorker pro práci s lokální SQL databází. DbWorker Pro veškerou práci s databází se v kypochief nachází tˇrída DbWorker. Tato tˇrída poskytuje specializované funkce pro pˇrístup k SQL databázi. Jednotlivé funkce jsou pˇrizpusobeny ˚ požadavkum ˚ tˇrídy VpnMaster (viz kapitola 5.1.1). Pˇri inicializaci tˇrídy se mohou nastavit argumenty se jménem databáze, tabulky a uživatele. Pro testovací prostˇredí jsou nastaveny implicitní hodnoty. Bˇehem inicializace se tˇrída pokusí pˇrihlásit pomocí metody psycopg2.connect ke zvolené databázi. Pokud je pˇrihlášení úspˇešné, uloží se aktivní spojení s databází mezi argumenty tˇrídy. Pro tuto tˇrídu je vytvoˇrena výjimka DbException a pokud nˇejaká výjimka nastane bˇehem používání této tˇrídy, bude to vždy DbException s vysvˇetlením, kde se nachází problém. Tabulka pro úˇcely této práce obsahuje x509-jméno klienta, port, na kterým je otevˇren OpenVPN server a IP adresy SMN a LMN uzlu. Pro tvorbu tabulky je vytvoˇrena metoda DbWorker.create_db(), která se pokusí vytvorˇ it novou tabulku. Pokud tabulka se stejným jménem již existuje, nová tabulka se nevytváˇrí a v databázi je ponechána puvodní ˚ tabulka. Pokud již nepotˇrebujeme držet aktivní spojení s databází, ukonˇcíme relaci pomocí metody DbWorker.close(). 5.1.3 Tvorba RSA klíˇcu˚ Autentizace klientské a serverové cˇ ásti OpenVPN funguje na základˇe privátních a veˇrejných RSA klíˇcu˚ podepsaných stejnou certifikaˇcní autoritou. Certifikaˇcní autorita pro úˇcely této práce byla vytvoˇrena pomocí OpenSSL knihovny a podepsána sama sebou[24]. Pro testovací úˇcely to je dostaˇcující rˇ ešení. Pˇri tvorbˇe VPN serveru na LMN uzlech je každému serveru pˇri19


dˇelen pár RSA klíˇcu, ˚ který musí být podepsán naší certifikaˇcní autoritou. Pro tyto potˇreby a také pro generování klientských klíˇcu˚ je vytvoˇrena tˇrída KeyMaker. KeyMaker Tato tˇrída poskytuje metody pro tvorbu a podepsání RSA klíˇcu. ˚ Pro práci s OpenSSL knihovnou jsem použil balíˇcek PyOpenssl.crypto. Tento balíˇcek poskytuje metody pro veškerou práci s šifrovacími RSA klíˇcí. Proces vytváˇrení použitelných klíˇcu˚ zaˇcíná inicializací tˇrídy. Následnˇe nám staˇcí jenom zavolat metodu create_rsa_key() pro vytvoˇrení privátního klíˇce a požadavku pro podepsání. Implicitnˇe jsou klíˇce tvoˇreny s typem certifikátu nastaveným na hodnotu server. Pokud chceme klíˇc bez tohoto rozšíˇrení, je tˇreba zavolat metodu s parametrem server nastaveným na False. Metodou sign_key() se požadavek podepíše certifikaˇcní autoritou, jejíž verˇ ejný a privátní klíˇc musí být pˇrítomny na lokálním stroji, a uloží se jako veˇrejný klíˇc. Následnˇe mužeme ˚ klíˇce uložit do souboru anebo pomocí get metod dostat klíˇce v textové podobˇe. Bˇehem vytváˇrení RSA klíˇcu˚ se do požadavku pro certifikaˇcní autoritu pˇridávají informace o majiteli klíˇce – tedy x509-jméno, zkratka státu: „Cs“, mˇesto: „Brno“ a jméno organizace: „Masaryk univerzity“. Klíˇce jsou tedy tvoˇreny na míru pro naší infrastrukturu externích zaˇrízení. 5.1.4 Obslužné funkce Kypochief nabízí tˇri hlavní funkcionality - pˇridat nový VPN server, odstranit VPN server a vytvoˇrit pár RSA klíˇcu. ˚ Veškerou práci dˇelají jednotlivé tˇrídy, ale pro základní uživatelské rozhraní jsem vytvoˇril pár jednoduchých funkcí, které pˇreberou parametry z pˇríkazového rˇ ádku a provedou žádanou práci. add() Metoda, zpracovávající parametry pˇríkazového rˇ ádku, pokud je první parametr „add“. Pro správné fungovaní jsou požadovány další tˇri parametry s IP adresami SMN a LMN uzlu˚ a x509-jménem klienta. Tato metoda vytvoˇrí instanci tˇrídy VpnMaster a zavolá metodu run_vpn(). Následnˇe je vytvorˇ ena instance tˇrídy DbWorker a pomocí save_to_db() uloží detaily OpenVPN serveru z tˇrídy VpnMaster do databáze. 20


delete() Tato metoda je zavolána, pokud je „del“ první parametr za Kypochief. Druhým parametrem je x509-jméno klienta, které se vyhledá pomocí tˇrídy DbWorker v lokální SQL databázi. Pokud je nalezen záznam pro toto jméno, jsou informace z databáze použity pro inicializování VpnMaster tˇrídy. Následnˇe je zavolána metoda close_vpn() a smaže se záznam v databázi. key_generator() Jednoduchá metoda, která vytvoˇrí pár RSA klíˇcu˚ podepsaných certifikaˇcní autoritou zastˇrešující naší VPN infrastrukturu. Pro správné fungování potˇrebuje tato metoda 3 parametry – x509-jméno a názvy souboru pro privátní a veˇrejný klíˇc. Tyto parametry se zadávají z pˇríkazového rˇ ádku za „kypochief gen“ v poˇradí – jméno, název souboru pro privátní klíˇc a název souboru pro veˇrejný klíˇc. usage() Jednoduchý návod pro použití programu kypochief. Vypíše na standardní výstup návod k použití pokaždé, když se parametry neshodují s jednou ze tˇrí metod popsaných dˇríve v této sekci. 5.1.5 Komunikace s propojovacím zaˇrízením V rámci automatizování celého procesu bylo tˇreba vymyslet zpusob, ˚ jak se ke klientovi dostane aktuální informace o tom, na který uzel a na který ˇ port se má pˇrihlásit pomocí OpenVPN. Rešením pro moji práci je CGI skript init_openvpn.py napsaný v jazyce Python, který obdrží pomocí curl dotazu jméno klienta. Jméno klienta je vyhledáno v databázi. Pokud jsou nalezeny detaily OpenVPN serveru pro daného klienta v lokální databázi, jsou tyto detaily použity pro vygenerování konfiguraˇcního souboru pro OpenVPN klienta a poslány na standardní výstup. Standardní výstup u CGI skriptu˚ je pˇreposlán na zaˇrízení, které poslalo curl dotaz.

5.2

OpenVPN server na LMN uzlu

Pro inicializaci a rušení OpenVPN serveru˚ na LMN uzlech jsou pˇripraveny jednoduché skripty napsané v bashi. Tyto skripty jsou na LMN uzly zkopírovány nezávisle na rˇ ídicím uzlu. Je možné, že zkopírování skriptu na LMN uzel bude taky automatizováno, ale pro prokázání funkˇcnosti je to 21


zatím dostaˇcující. Pro inicializaci se volá skript new_client. Zrušení nastavení zajistí skript del_client. Oba tyto skripty používají lokální konfiguraˇcní soubor, který obsahuje detaily nastavení OpenVPN serveru a taky soupis aktivních spojení. 5.2.1 Tvorba nového OpenVPN serveru Vytvoˇrení nové OpenVPN instance a všechna potˇrebná nastavení, která jsou s tvorbou spojena, zajišt’uje skript new_client. Tento skript je volán z rˇ ídicího uzlu. Mezi parametry, které tento uzel potˇrebuje, jsou RSA klíˇce pro nový server v textové podobˇe - lokální použití tohoto skriptu je tedy velmi omezeno. Skript new_client dostává jako parametry x509-jméno klienta, pro kterého je tento server budován, privátní a veˇrejný klíˇc popˇrípadˇe volitelnou cestu ke konfiguraˇcnímu souboru. Pokud není konfiguraˇcní soubor mezi parametry, naˇcítá se automaticky soubor „settings“ (viz. pˇríloha A), který se nachází ve stejném adresáˇri. Nejdˇrív skript zkontroluje, zda již je na stroji nainstalován balíˇcek OpenVPN. Pokud se balíˇcek na stroji nevyskytuje, je nainstalován. V další cˇ ásti se naˇctou detaily pro nastavení serveru z konfiguraˇcního souboru (viz. kapitola 5.2.3). Ted’ již má skript veškeré informace pro správné vytvoˇrení nového virtuálního sít’ového TAP rozhraní, pˇripojení tohoto vytvoˇreného rozhraní do virtuálního pˇrepínaˇce a vygenerování konfiguraˇcního souboru(viz. pˇríloha B).[10] Tento konfiguraˇcní text se uloží a spustí se nový openVPN daemon s parametry „–config“ a „–log“, obsahující cesty k právˇe vygenerovanému konfiguraˇcnímu souboru a log souboru. Pokud vše probˇehlo bez problému, uloží se informace o nové OpenVPN instanci do konfiguraˇcního souboru pro skripty (viz. pˇríloha A). 5.2.2 Zrušení stávajícího OpenVPN serveru Abychom ukonˇcili bˇežící OpenVPN server, potˇrebujeme znát x509-jméno klienta, pro kterého byl tento server zbudován. Zrušení OpenVPN daemona a všeho, spojeného s touto instancí, provede skript del_client. Tento skript potˇrebuje pro svou cˇ innost parametr x509-jména klienta a popˇrípadˇe konfiguraˇcní soubor. Pokud není konfiguraˇcní soubor mezi parametry, nacˇ ítá se automaticky soubor „settings“, který se nachází ve stejném adresáˇri. Del_client nejdˇrív naˇcte detaily o lokálních OpenVPN instancích ze svého konfiguraˇcního souboru a prohledá také rˇ ádky s aktivními instancemi, zda 22


se tam nachází informace o jménˇe obdrženém jako parametr. Pokud mezi aktivními instancemi není žádná, která by vyhovovala, je skript ukonˇcen. Naopak, pokud se jména shodují, naˇctou se zbývající informace o portu a sít’ovém rozhraní. Na bázi tˇechto údaju˚ je ukonˇcen OpenVPN server, smazány všechny soubory spojené s tímto serverem a smazáno sít’ové rozhraní. Pokud všechno probˇehlo v poˇrádku, je rˇ ádek s informacemi o smazaném serveru vymazán z konfiguraˇcního souboru. 5.2.3 Konfiguraˇcní soubor Skripty na LMN uzlu komunikují spolu pomocí lokálního konfiguraˇcního souboru „settings“ (viz. pˇríloha A). V konfiguraˇcním souboru jsou zapsány informace o adresáˇri s OpenVPN konfiguraˇcními a log soubory, adresáˇri s šifrovacími klíˇci, aktuální UDP port a rozsah portu˚ pro OpenVPN. Po každém úspˇešném spuštˇení skriptu new_client, jsou do konfiguraˇcního souboru pˇridány informace o novˇe vytvoˇreném OpenVPN spojení, obsahující - jméno klienta, cˇ íslo UDP portu a jméno virtuálního sít’ového rozhraní. Pˇri zrušení jakéhokoli aktuálního spojení jsou informace o tomto spojení smazány.

5.3

Klientská cˇ ást

Na stranˇe fyzického zaˇrízení je v plánu využití malých propojovacích zarˇ ízení typu „raspberry pi”[25] se dvˇema sít’ovými rozhraními. Propojovací prvek se vloží mezi pˇripojované zaˇrízení a nejbližší sít’ový prvek - rozboˇcovaˇc nebo pˇrepínaˇc. Propojovací prvky budou fungovat na linuxovém systému - nejpravdˇepodobnˇeji Debian. Pro propojovací zaˇrízení je pˇrichystaný skript, který se spustí pˇri pˇripojení propojovacího zaˇrízení do sítˇe. Inicializaˇcní skript stáhne konfiguraci urˇcenou pro sebe a spustí ji. Nastaví pˇremostˇení mezi OpenVPN rozhraním a rozhraním na stranˇe koncového zaˇrízení a povolí pˇreposílání paketu. ˚ Pˇri odpojení propojovacího prvku ze sítˇe, je automaticky zavolán druhý skript, který ukonˇcí bˇežící OpenVPN instanci a s ní spojené bˇežící procesy. Protože jsem nemˇel možnost rˇ ešení pˇrizpuso˚ bit na míru zaˇrízení typu „raspberry pi”, je tˇreba pˇred nasazením názvy sít’ových rozhraní ve skriptu upravit na žádané hodnoty. 5.3.1 init_vpn Tento skript je napsán v jazyce Python a pro svou funkˇcnost využívá knihovny Request a subprocess. Pomocí knihovny Request vyšle požadavek k rˇ ídi23


címu uzlu, ze kterého si stáhne konfiguraˇcní soubor pro vlastní OpenVPN instanci. Následnˇe se soubor uloží a pomocí knihovny subprocess spustí vlastní OpenVPN klient používající k pˇripojení uložený konfiguraˇcní soubor. Knihovna subprocess je taky využita pro oživení TAP rozhraní spojeného s OpenVPN instancí a pˇremostˇení TAP rozhraní a fyzického rozhraní na stranˇe koncového klienta pomocí bridge-utils. 5.3.2 close_vpn Jednoduchý Bash skript, který se volá, když je sít’ové rozhraní na stranˇe sítˇe odpojeno. Po zavolání zruší pˇremostˇení a bˇežící OpenVPN instanci.

5.4

Test výsledné VPN

Testovací infrastruktura byla složena z centrálního rˇ ídicího uzlu na adrese „kypo-devel.ics.muni.cz“, na kterém jsem mˇel pro své úˇcely vytvoˇren úˇcet. Dalším strojem byl SMN uzel KYPO na adrese 147.251.252.206 s dvˇema LMN uzly. Pro simulaci koncových zaˇrízení jsem využíval dva virtuální stroje na cloudu Metacentra a muj ˚ osobní poˇcítaˇc. Pro testovací úˇcely jsem bohužel nemˇel zaˇrízení typu „raspberry pi”. Simuloval jsem tedy propojovací zaˇrízení pomocí mého osobního poˇcítaˇce a koncovým zaˇrízením byl virtuální stroj, bˇežící ve virtuálním prostˇredí VirtualBox [26]. Skripty pro koncová zaˇrízení jsou tedy trochu poupravené ve srovnání s verzí pro krabiˇcku, ale funkcionalita je identická. Pro simulaci propojovacího zaˇrízení jsem ve skriptu zakomentoval cˇ ást vytváˇrející pˇremostˇení, protože pˇremostˇení je rˇ ešeno v prostˇredí VirtualBox. Pˇred testováním bylo potˇreba na LMN uzly zkopírovat soubory new_client, del_client, settings a veˇrejný klíˇc certifikaˇcní autority. V plánu pro nasazení se poˇcítá s tím, že tyto soubory budou kopírovány na LMN uzly bˇehem jejich inicializace. 5.4.1 Pˇripojení externích zaˇrízení Spuštˇení OpenVPN serveru˚ pro klienty roman, mirek a pepa. Po spuštˇení OpenVPN serveru˚ na LMN uzlu, se informace o bˇežících instancích uloží do konfiguraˇcního souboru (viz. pˇríloha A).Pro klienta pepa je zobrazen i výpis, zobrazený pˇri spuštˇení. Všechny úspˇešnˇe spuštˇené OpenVPN servery mají podobný výpis.

24


395854@kypo-devel:~$ ./kypoChief.py add roman 147.251.252.206 172.16.1.2 395854@kypo-devel:~$ ./kypoChief.py add mirek 147.251.252.206 172.16.1.2 395854@kypo-devel:~$ ./kypoChief.py add pepa 147.251.252.206 172.16.1.3 Installing package openvpn. Reading package lists... Building dependency tree... Reading state information... openvpn is already the newest version. 0 upgraded, 0 newly installed, 0 to remove and 47 not upgraded. Sat Dec 27 19:17:40 2014 TUN/TAP device tap_openVPN_0 opened Sat Dec 27 19:17:40 2014 Persist state set to: ON Config file for client pepa is prepared in file /etc/openvpn/setup/srv_pepa.conf port 40006 OpenVPN instance for client pepa is ready to use Pohled na SQL databázi na rˇ ídicím uzlu 395854@kypo-devel:~$ psql road_warriors psql (9.1.14) Type "help" for help. road_warriors=> SELECT * FROM vpns; name | port | smn | lmn ——-+——-+—————–+———— roman | 40054 | 147.251.252.206 | 172.16.1.2 mirek | 40055 | 147.251.252.206 | 172.16.1.2 pepa | 40005 | 147.251.252.206 | 172.16.1.3 Zrušení OpenVPN serveru pro klienta papa 395854@kypo-devel:~$ ./kypoChief.py del pepa OpenVPN deamon for client pepa has been terminated Files /etc/openvpn/setup/srv_pepa.conf and /etc/openvpn/setup/srv_pepa.log has been removed Files /etc/openvpn/keys/srv_pepa.key and /etc/openvpn/keys/srv_pepa.crt has been removed Sat Dec 27 19:15:29 2014 TUN/TAP device tap_openVPN_0 opened Sat Dec 27 19:15:29 2014 Persist state set to: OFF Interface tap_openVPN_0 has been removed 25


OpenVPN instance for client pepa is shut down Pohled na SQL databázi na rˇ ídicím uzlu po zrušení instance pro klienta pepa 395854@kypo-devel:~$ psql road_warriors psql (9.1.14) Type "help" for help. road_warriors=> SELECT * FROM vpns; name | port | smn | lmn ——-+——-+—————–+———— roman | 40054 | 147.251.252.206 | 172.16.1.2 mirek | 40055 | 147.251.252.206 | 172.16.1.2 Spuštˇení OpenVPN klientu˚ Pro co nejbližší simulaci funkce propojovacího zaˇrízení jsem na svém pocˇ ítaˇci spustil skript init_vpn a ve virtuálním prostˇredí VirtualBox propojil novˇe vytvoˇrené OpenVPN rozhraní s Virtuálním strojem. roman@komputerek:~$ sudo ./init_openvpn.py roman root@cloud67:/etc/openvpn# ./init_openvpn.py pepa root@cloud55:/etc/openvpn# ./init_openvpn.py mirek 5.4.2 Test vytvoˇreného prostˇredí Vytvoˇrené ukázkové prostˇredí bylo bˇehem nˇekolika chvil funkˇcní. Koncové uzly dostaly IP adresy od DHCP (Dynamic Host Configuration Protocol) serveru, který se nacházel na LMN uzlu. Pomocí testu komunikace prostˇrednictvím programu ping jsem otestoval vzájemnou viditelnost pˇripojených klientu. ˚ ˇ Cásteˇ cný výpis z „ip addr show” na virtuálním stroji tap0: mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100 0 link/ether 08:00:27:13:4f:22 brd ff:ff:ff:ff:ff:ff inet 10.10.10.7/24 brd 10.10.10.255 scope global tap0 26


ˇ Cásteˇ cný výpis z „ip addr show” na stroji cloud55 tap0: mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 100 link/ether 36:fe:cc:00:db:7e brd ff:ff:ff:ff:ff:ff inet 10.10.10.7/24 brd 10.10.10.255 scope glob Ping mezi strojem cloud55 a virtuálním strojem na mém poˇcítaˇci root@cloud55:/etc/openvpn# ping 10.10.10.6 PING 10.10.10.6 (10.10.10.6) 56(84) bytes of data. 64 bytes from 10.10.10.6: icmp_req=1 ttl=64 time=35.2 ms 64 bytes from 10.10.10.6: icmp_req=2 ttl=64 time=36.2 ms 64 bytes from 10.10.10.6: icmp_req=3 ttl=64 time=35.0 ms 64 bytes from 10.10.10.6: icmp_req=4 ttl=64 time=35.5 ms Zachycený provoz Na mém osobním poˇcítaˇci jsem zachytil komunikaci mezi lokálním virtuálním strojem a strojem cloud55 pomocí programu Wireshark (viz obrázky 5.1 a 5.2). Z obou tˇechto obrázku jde vidˇet, že veˇrejný provoz je skrytý, zatímco privátní data jsou dobˇre cˇ itelná pro aplikace na cílových uzlech.

Obrázek 5.1: Ukázka zachycené komunikace na fyzickém sít’ovém rozhraní.

Obrázek 5.2: Ukázka zachycené komunikace na rozhraní tap0, vytvoˇreném novou OpenVPN instancí

27

6 Propojení dvou vzdálených uzlu˚ Propojení dvou vzdálených uzlu˚ je v této práci rˇ ešeno pomocí tunelovacího protokolu l2tpv3 (viz. kapitola 4.2.1). Tento protokol vytváˇrí pˇredstavu pˇrímého Ethernetového propojení mezi dvˇema body. Pokud jsou dva vzdálené uzly oddˇeleny veˇrejnou sítí, nabízí toto rˇ ešení i IPSec (viz. kapitola 4.2.2) zabezpeˇcení l2tpv3 tunelu. Moje rˇ ešení v této práci je implementováno pro správu uzlu s linuxovou distribucí Debian. Tento systém je nasazen na strojích Kybernetického polygonu a tedy nebylo tˇreba vytváˇret implementace pro ruzné ˚ distribuce. Souˇcástí zadání bylo vytvoˇrení tunelu mezi zaˇrízeními, která máme pod plnou kontrolou, a tedy vytvoˇrený program tunel.py poˇcítá s pˇrihlášením na vzdálené uzly jako uživatel root. Program tunel.py obsahuje dvˇe hlavní tˇrídy - Tunnel a DbWorker, a nˇekolik obslužných funkcí.

6.1

Sestavování tunelu˚ - tˇrída Tunnel

Tato tˇrída nabízí možnost vzdálenˇe nastavit dva uzly jako koncové body pro l2tpv3 tunel. Nabízí taky možnost zabezpeˇcit tunel pomocí IPSec s vygenerovaným pˇred-sdíleným klíˇcem. Optimální postup pˇri použití této tˇrídy je posloupnost gen_port(), set_ipsec(), set_l2tp() pro vytvoˇrení tunelu a del_l2tp(), del_ipsec() pro zrušení tunelu. Metoda gen_port() vygeneruje náhodný UDP port a následnˇe zkontroluje, zda je tento port na koncových uzlech volný. Pokud ano, je port uložen mezi argumenty tˇrídy, jinak je vygenerován další a opˇet otestován. Metody pro nastavení tunelu cˇ erpají z argumentu˚ tˇrídy, uložených pˇri inicializaci tˇrídy nebo nastavených pomocí „set“ metod tˇrídy. 6.1.1 L2tp Tˇrída Tunnel obsahuje dvˇe metody pro nastavení l2tp tunelu - set_l2tp a del_l2tp. set_l2tp() Sestavení l2tpv3 tunelu na koncových uzlech je nastaveno manuálnˇe . Na obou uzlech jsou tedy nastaveny identické parametry. Jenom IP adresy lokálního a vzdáleného uzlu jsou pˇrehozené. Tato funkce se tedy pomocí 28

6. P ROPOJENÍ DVOU VZDÁLENÝCH UZL U˚ knihovny Paramiko[21] pˇrihlásí pˇres SSH tunel k cílovým uzlum ˚ a spustí na obou uzlech potˇrebné pˇríkazy. Tato metoda generuje výjimku ConnectionException, pokud se nepovedlo pˇrihlásit na cílový uzel a výjimku L2tpException, pokud nejsou dostupny všechny potˇrebné argumenty pro vytvoˇrení tunelu. del_l2tp() Smazání l2tp tunelu musí byt opˇet provedeno na obou koncových uzlech. Tato metoda tedy opˇet pomocí knihovny Paramiko vytvoˇrí SSH tunel k jednotlivým uzlum ˚ a provede pˇríkazy potˇrebné ke zrušení tunelu. Tato metoda vyhodí výjimku ConnectionException, pokud se nepovedlo pˇrihlásit na cílový uzel a výjimku L2tpException, pokud tunel neexistuje nebo nejsou dostupny potˇrebné argumenty pro smazání tunelu. 6.1.2 IPSec Obˇcas je potˇreba vytvoˇrený tunel zašifrovat a právˇe pro tyto situace obsahuje tˇrída Tunnel metody, které pro tunel vytvoˇrený objektem tˇrídy Tunnel nabízí možnost nastavit IPSec zabezpeˇcení. set_ipsec() Aktuálnˇe nabízí tato metoda vytvoˇrení IPSec zabezpeˇcení pomocí pˇredsdíleného hesla. V rámci parametru˚ mužeme ˚ pˇredat metodˇe jméno vytvoˇreného IPSec spojení. Tato metoda nejdˇrív vytvoˇrí pˇred-sdílené heslo o délce 32 znaku. ˚ Následnˇe jsou pro každý uzel zvlášt’ vytvoˇreny soubory obsahující nastavení IPSecu a heslo. Tyto soubory se uloží na koncové uzly pod jménem spojení a služba IPSec je restartována. V pˇrípadˇe nepovedeného pˇrihlášení k cílovým uzlum ˚ je generována výjimka ConnectionException. Pokud je problém v parametrech potˇrebných k vytvoˇrení IPSecu, je generována výjimka IpsecException. del_ipsec() Tato metoda smaže soubory, uložené v koncových uzlech pod jménem spojení. Následnˇe se na koncových uzlech restartuje služba IPSec. V pˇrípadˇe nepovedeného pˇrihlášení k cílovým uzlum ˚ je generována výjimka ConnectionException. Pokud je problém v parametrech potˇrebných ke smazání IPSecu, je generována výjimka IpsecException. 29

6. P ROPOJENÍ DVOU VZDÁLENÝCH UZL U˚

6.2

Práce s databází - tˇrída DbWorker

Tato tˇrída je v mnohém podobná tˇrídˇe v rˇ ídicí cˇ ásti systému pro pˇripojení vzdáleného zaˇrízení do Kybernetického polygonu (viz. kapitola 5.1). Tato tˇrída obsahuje metody pro uložení, cˇ tení a mazání údaju˚ o vytvoˇrených tunelech. Údaje jsou uložené v SQL databázovém systému PostgreSQL. Každý rˇ ádek v tabulce obsahuje identifikaci tunelu, IP adresy propojených uzlu, ˚ cˇ íslo UDP portu a informaci o použití IPSecu. Identifikace tunelu je taky primárním klíˇcem pro vyhledávání v tabulce. IP adresy propojených ˇ uzlu˚ musí být adresy formátu IPv4. Císlo UDP portu souvisí s l2tp tunelem, který na obou uzlech poslouchá právˇe na tomto portu. Jako informace o použití IPSecu mohou být hodnoty „yes“, znamenající šifrování tunelu, a hodnota „no“.

6.3

Obslužné funkce

Veškerou funkcionalitu potˇrebnou k práci s tunely a s databází poskytují výše popsané tˇrídy. Meziˇclánek mezi tˇrídami a uživatelem rˇ eší obslužné funkce, které zpracovávají parametry z pˇríkazového rˇ ádku a volají jednotlivé metody hlavních tˇríd. add() Tato funkce je zavolána, pokud je prvním parametrem „add“. Funkce add() následnˇe zpracovává další parametry a vytváˇrí pomocí nich instanci tˇrídy Tunnel. Pokusí se sestavit l2tp tunel. V pˇrípadˇe, že je posledním parametrem –ipsec, pˇripojí k vytvoˇrenému tunelu šifrování pomocí IPSecu. Informace o úspˇešnˇe vytvoˇreném tunelu jsou následnˇe pomocí tˇrídy DbWorker uloženy do lokální SQL databáze. delete() Tato funkce je zavolána, pokud je prvním parametrem „del“. Tunel muže ˚ být specifikován pomocí identifikace tunelu nebo koncových zaˇrízení. Pokud se najde shoda v lokální SQL databázi, jsou další informace o tunelu naˇcteny z databáze a pomocí nich je vytvoˇren objekt tˇrídy Tunnel. Pokud byl tunel zabezpeˇcen, je nejdˇrív zrušeno IPSec zabezpeˇcení. Následnˇe je zrušen l2tp tunel. Pokud vše probˇehlo v poˇrádku, jsou informace o tunelu vymazány z databáze. 30

6. P ROPOJENÍ DVOU VZDÁLENÝCH UZL U˚ show() Tato funkce je zavolána, pokud je prvním parametrem „show“. Funkce vytiskne na standardní výstup všechny aktuálnˇe vytvoˇrené tunely. usage() Tato funkce se zavolá v pˇrípadˇe, kdy parametry pˇríkazového rˇ ádku neodpovídají potˇrebám metod add(), delete() nebo show().

6.4

Test výsledného tunelu

Pro otestování funkˇcnosti programu tunel.py jsem vytvoˇril zabezpeˇcený tunel mezi dvˇema virtuálními stroji v cloudu Metacentra. Vytvoˇreným strojum ˚ jsem nastavil statické cesty skrze tunel. 6.4.1 Sestavení tunelu Spuštˇení zabezpeˇceného tunelu mezi dvˇema body roman@komputerek:~$ tunel.py add 147.251.252.200 147.251.252.188 –ipsec Port for l2tp tunnel: 5613 147.251.252.200: Ipsec for l2tp tunnel is set. 147.251.252.188: Ipsec for l2tp tunnel is set. Interface for l2tp tunnel: tunel5613 l2tp tunnel 93740 at 147.251.252.200 is up Interface for l2tp tunnel: tunel5613 l2tp tunnel 93740 at 147.251.252.188 is up root@cloud55:~# ip addr add 10.10.1.2 peer 10.10.1.1 dev tunel5613 Pohled na SQL databázi roman@komputerek:~$ psql road_warriors psql (9.3.5) Type "help" for help. road_warriors=> SELECT * FROM tunnels; id | lefthost | righthost | port | ipsec ——-+—————–+—————–+——+——93740 | 147.251.252.200 | 147.251.252.188 | 5613 | yes 31

6. P ROPOJENÍ DVOU VZDÁLENÝCH UZL U˚ (1 row)

Kontrola spuštˇených l2tp a IPSec tunelu˚ root@cloud55:~# service ipsec status IPsec running - pluto pid: 30689 pluto pid 30689 2 tunnels up some eroutes exist root@cloud55:~# ip l2tp show tunnel Tunnel 93740, encap UDP From 147.251.252.200 to 147.251.252.188 Peer tunnel 93740 UDP source / dest ports: 5613/5613

6.4.2 Test tunelu Bˇehem testování jsem pomocí programu ping nejdˇrív testoval spojení na privátní adresu v tunelu, následnˇe spojení na veˇrejnou adresu druhého uzlu a test jsem zakonˇcil opˇet kontrolou spojení na privátní adresu v tunelu.

Test viditelnosti uzlu˚ skrze tunel root@cloud55:~# ping 10.10.1.1 PING 10.10.1.1 (10.10.1.1) 56(84) bytes of data. 64 bytes from 10.10.1.1: icmp_req=1 ttl=64 time=0.029 ms 64 bytes from 10.10.1.1: icmp_req=2 ttl=64 time=0.017 ms 64 bytes from 10.10.1.1: icmp_req=3 ttl=64 time=0.018 ms 64 bytes from 10.10.1.1: icmp_req=4 ttl=64 time=0.016 ms Bˇehem testu viditelnosti mezi koncovými uzly tunelu jsem zachytil provoz programem tcpdump. Z výsledného výpisu jde dobˇre rozeznat test spojení postupnˇe na veˇrejnou adresu, adresu v tunelu a pak opˇet na veˇrejnou adresu. Situace spojení skrze tunel je na obrázku 6.1 oznaˇcena cˇ ervenou barvou. 32

6. P ROPOJENÍ DVOU VZDÁLENÝCH UZL U˚

Obrázek 6.1: Provoz, zachycený mezi koncovými uzly. 6.4.3 Ukonˇcení tunelu Pro smazání tunelu a veškerých nastavení s ním spojených potˇrebujeme znát identifikaci tunelu nebo koncové body. Ukonˇcení tunelu pomocí tunnel_id roman@komputerek:~$ tunel.py del –id 93740 l2tp tunnel 93740 at 147.251.252.200 is down l2tp tunnel 93740 at 147.251.252.188 is down 147.251.252.200: Ipsec for l2tp tunnel is removed 147.251.252.188: Ipsec for l2tp tunnel is removed

6.5

Výsledek

Vzniklý tunel i jeho fungování splnuje ˇ zadání a ukazuje, že tento program je možné použít k propojení uzlu, ˚ které máme pod kontrolou. Na obrázku 6.1 lze vidˇet, že IPSec je aplikován pouze na vytvoˇrený l2tp tunel a veškerá další komunikace je nepozmˇenˇena.

33

7 Závˇer Cílem této práce bylo nastudovat VPN a tunelovací technologie a vytvorˇ it sady nástroju˚ pˇrizpusobených ˚ k použití v Kybernetickým polygonu. V úvodních kapitolách jsem nastínil zpusoby ˚ fungování VPN a tunelovacích technologií a následnˇe popsal vytvoˇrené nástroje. Infrastruktura, vytvoˇrena pro automatizované pˇripojování externích zarˇ ízení, je ve funkˇcním stavu a ve výpisu v kapitole 5.4.2 mužeme ˚ vidˇet, že systém rˇ eší problematiku popsanou v kapitole 2.3.3. Myslím si, že zpusob ˚ rˇ ešení pro pˇripojení externího zaˇrízení je touto práci dobˇre nastínˇen a cˇ asem by mohl byt uplatnˇen v reálném provozu. Z využitím pˇredprogramovaných propojovacích krabiˇcek bude tento systém velmi jednoduchý pro použití. Druhá cˇ ást zadání poskytuje rˇ ešení pro vzájemné propojení virtuálních uzlu˚ v rámci KYPO a propojení dvou vzdálených uzlu˚ skrz veˇrejnou sít’. Aktuálnˇe jsou virtuální uzly v KYPO propojeny pomocí technologie VLAN. Tunelovací nástroj je vytvoˇren jako alternativa k souˇcasnému rˇ ešení, které aktuálnˇe vykazuje obˇcas nežádané chování. Propojení jednotlivých virtuálních stroju˚ pomocí vytvoˇreného nástroje je možné a jeho další využití je tedy na správcích Kybernetického polygonu. V pˇrípadˇe potˇreby propojit dva vzdálené cloudy, nástroj poskytuje šifrovaný tunel. Splnuje ˇ tedy požadavky, kladené pro propojení vzdálených uzlu˚ oddˇelených veˇrejnou sítí. Oba nástroje jsou tedy funkˇcní a splnují ˇ oficiální zadání práce. Práce na nástrojích popsaných v tomto textu mˇe bavila, dovˇedˇel jsem se totiž bˇehem ní mnoho zajímavých vˇecí.

34

Literatura [1] Open vSwitch. Open vSwitch [online]. [cit. 2015-01-05]. Dostupné z:http://openvswitch.org/ ˇ ˇ [2] KOURIL, D., REBOK, T., JIRSÍK, T.,CEGAN, J.,DRAŠAR, M., VIZVÁRY, M. a VYKOPAL, J. Cloud-based testbed for simulation of cyber attacks. Network Operations and Management Symposium (NOMS) [online]. 2014 [cit. 2015-01-04]. Dostupné z:http://ieeexplore.ieee.org/xpl/articleDetails.jsp? arnumber=6838298 [3] Projekt KYPO. Kybernetický polygon [online]. [cit. 2015-01-05]. Dostupné z: http://www.muni.cz/research/projects/23884/ web/?lang=cs ˇ [4] KOURIL, Daniel, LAGO, Dušan, PROCHÁZKA, Michal a REBOK, Tomáš. Pˇríprava experimentálního prostˇredí v cloudu. Technická zpráva. Ústav výpoˇcetní techniky, Masarykova univerzita. 2013.[cit. 2015-0104] [5] KENT, S. a SEO, K. Security Architecture for the Internet Protocol. RFC [online]. 2005[cit. 2015-01-04]. Dostupné z: https://tools.ietf. org/html/rfc4301 [6] KENT, S. a ATKINSON, R. IP Encapsulating Security Payload. RFC [online]. 2005[cit. 2015-01-04]. Dostupné z: https://tools.ietf. org/html/rfc2406 [7] KENT, S. IP Authentication Header. RFC [online]. 2005 [cit. 2015-0104]. Dostupné z: https://tools.ietf.org/html/rfc4302 [8] KORTUS, Jiˇrí. Laboratorní úloha Virtuální sítˇe typu OpenVPN [online]. Brno, 2012 [cit. 2015-01-04]. Dostupné z:https://dspace.vutbr.cz/bitstream/handle/11012/ 10538/BP_Kortus_Laboratorni_uloha_Virtualni_site_ typu_OpenVPN.pdf?sequence=1 . Bakalaˇrská práce. Vysoké uˇcení technické v Brnˇe. [9] Protocol Numbers. Iana.org [online]. 1981, 25.11.2014 [cit. 2015-01-04]. Dostupné z: http://www.iana.org/ assignments/protocol-numbers/protocol-numbers. xhtml#protocol-numbers-1 35

ˇ 7. Z ÁV ER

[10] How to install and set-up OpenVPN in Debian 7. Stavroski.net [online]. 2014 [cit. 2015-0105]. Dostupné z:https://stavrovski.net/blog/ how-to-install-and-set-up-openvpn-in-debian-7-wheezy [11] Bridging vs. routing. Community.openvpn.net [online]. 2014 [cit. 2015-01-05]. Dostupné z:https://community.openvpn.net/ openvpn/wiki/BridgingAndRouting [12] OpenSSL manual. openssl.org [online]. [cit. 2015-01-05]. Dostupné z:https://www.openssl.org/docs/apps/openssl.html [13] SCHRODER, Carla. Linux: kuchaˇrka administrátora sítˇe. Vyd. 1. Brno: Computer Press, 2009, s. 269-290. ISBN 978-80-251-2407-9. [14] Ip-l2tp - L2TPv3 static unmanaged tunnel configuration. Man7.org [online]. 2012 [cit. 2015-01-05]. Dostupné z: http://man7.org/ linux/man-pages/man8/ip-l2tp.8.html [15] Internet Security Association and Key Management Protocol. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001- [cit. 2015-01-05]. Dostupné z:http://en.wikipedia.org/wiki/Internet_Security_ Association_and_Key_Management_Protocol [16] Introduction to L2TPv3. Prol2tp.com [online]. 2012 [cit. 2015-0105]. Dostupné z:http://prol2tp.com/documentation.html? page=l2tpv3.html [17] What is IPSEC and how IPSEC does the job of securing data communication. slashroot.in [online]. 2013 [cit. 2015-01-05]. Dostupné z:http://www.slashroot.in/ what-ipsec-and-how-ipsec-does-job-securing-data-communication [18] Ipsec(8) - Linux man page. Linux.die.net [online]. [cit. 2015-01-05]. Dostupné z: http://linux.die.net/man/8/ipsec [19] PostgreSQL. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001- [cit. 2015-01-05]. Dostupné z:http://cs.wikipedia.org/wiki/PostgreSQL [20] Python. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001- [cit. 2015-01-05]. Dostupné z:http://cs.wikipedia.org/wiki/Python 36

ˇ 7. Z ÁV ER

[21] Welcome to Paramiko!. Paramiko [online]. [cit. 2015-01-05]. Dostupné z: http://www.paramiko.org/ [22] Vše o iptables: úvod.root.cz [online]. [cit. 2015-01-05]. Dostupné z:http://www.root.cz/clanky/vse-o-iptables-uvod/ #ic=serial-box&icc=text-title [23] Psycopg – PostgreSQL database adapter for Python. initd.org [online]. [cit. 2015-01-05]. Dostupné z: http://initd.org/psycopg/docs/ [24] LEVITTE, Richard. HOWTO certificates. Openssl.org [online]. [cit. 2015-01-05]. Dostupné z: https://www.openssl.org/docs/ HOWTO/certificates.txt [25] What is a Raspberry pi?. Raspberrypi.org [online]. [cit. 201501-05]. Dostupné z: http://www.raspberrypi.org/help/ what-is-a-raspberry-pi/ [26] VirtualBox. In: Wikipedia: the free encyclopedia [online]. San Francisco (CA): Wikimedia Foundation, 2001- [cit. 2015-01-05]. Dostupné z:http://cs.wikipedia.org/wiki/VirtualBox

37

A Konfiguraˇcní soubor „settings” Algoritmus A.1 pˇríklad souboru „settings” ############################### # setings for openvpn server ###############################

#

#Directory, where configs and logs will be generated dir /etc/openvpn/setup #Directory with keys and certificates keys /etc/openvpn/keys #IP address of interface, where openvpn server will be listening local_ip 172.16.1.2 #name of tap device(must start with word ’tap’) #for each interface number is added after the word tap_name tap_openVPN_ #minimum for port range min_port 40050 #maximum for port range max_port 40100 #port number from wich will be connect with tap0 device. Port for every else tap device will be increased by 1 port 40057 common name,port and tap device of connected clients: mirek 40055 tap_openVPN_1 roman 40056 tap_openVPN_2

38

B Konfigurˇcní OpenVPN soubor serverové cˇ ásti Algoritmus B.1 konfiguraˇcní soubor pro OpenVPN ## # Configuration openvpn file for client $client_name ## local (IPv4 adresa rozhraní, na kterém bude OpenVPN server naslouchat) port (ˇcíslo UDP portu, na kterém bude OpenVPN server naslouchat) proto udp dev (jméno rozhraní, se kterým se propojí nová OpenVPN instance) server-bridge #authentication and security tls-server ca (cesta k veˇrejnému klíˇci certifikaˇcní autority) cert (cesta k veˇrejnému klíˇci serveru) key (cesta k privátnímu klíˇci serveru) dh (cesta k Diffie-Hellman klíˇci) tls-remote (x509-jméno klienta pro autentizaci spojení) keepalive 10 120 comp-lzo persist-key persist-tun log (cesta k log souboru) verb 3

39

Pokročilé sít ové konfigurace v cloudu

Recommend Documents