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

Transkript

1 MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY Ð Û Å«Æ ±²³ µ ¹º»¼½¾ Ý Pokročilé sít ové konfigurace v cloudu BAKALÁŘSKÁ PRÁCE Roman Jakubik Brno, podzim 2014

2 Prohlášení Prohlašuji, že tato bakalářská 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 nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj. Roman Jakubik Vedoucí práce: RNDr. Daniel Kouřil i

3 Klíčová slova KYPO, VPN, tunelovací mechanizmy, OpenVPN, l2tp, IPSec ii

4 Poděkování Děkuji vedoucímu práce panu RNDr. Danielu Kouřilovi za konzultaci a cenné rady při psaní bakalářské práce. iii

5 Obsah 1 Úvod KYPO Vlastnosti Architektura Přehled nedostatků Propojení virtuálních prostředí Překrývání VLAN Mechanizmus připojení fyzických zařízení Návrh řešení Připojení externího zařízení Infrastruktura Propojení dvou uzlů Infrastruktura Popis použitých VPN technologii OpenVPN Bezpečnost Komunikace IPSec/l2tpv L2tpv3 (Layer Two Tunneling Protocol version 3) IPSec (Internet Protocol Security) Bezpečnost Konfigurace Připojení externího zařízení do KYPO Řídicí část Tvorba VPN serverů Práce s databází Tvorba RSA klíčů Obslužné funkce Komunikace s propojovacím zařízením OpenVPN server na LMN uzlu Tvorba nového OpenVPN serveru Zrušení stávajícího OpenVPN serveru Konfigurační soubor Klientská část init_vpn close_vpn Test výsledné VPN iv

6 5.4.1 Připojení externích zařízení Test vytvořeného prostředí Propojení dvou vzdálených uzlů Sestavování tunelů - třída Tunnel L2tp IPSec Práce s databází - třída DbWorker Obslužné funkce Test výsledného tunelu Sestavení tunelu Test tunelu Ukončení tunelu Výsledek Závěr A Konfigurační soubor settings B Konfigurční OpenVPN soubor serverové části v

7 1 Úvod Kybernetický polygon nabízí prostředí pro detailní studování bezpečnostních incidentů na síti. Celé prostředí se nachází v cloudovém prostředí Masarykovy Univerzity a bylo budováno postupně. Tento projekt je relativně mladý a je tedy mnoho věcí, kterými je možné toto prostředí rozšířit. Bližší popis Kybernetického polygonu je uveden v kapitole 2, ve které podrobněji představuji i rozšíření navržené v oficiálním zadání této práce. V 3. kapitole nabízím návrh dvou rozšíření, která popisují možný přístup k vyřešení problematiky popsané v sekci 2.3. Obě řešení jsou zbudována na již vytvořených VPN technologiích. Tyto technologie tvoří podstatnou část fungování obou řešení a jsou detailněji vysvětleny v kapitole 4. Prvním rozšířením je sada nástrojů rozmístěných na různých uzlech Kybernetického polygonu a na propojovacím zařízení. Myšlenka tohoto řešení je automatizovaně připojit externí zařízení do virtuálního prostředí polygonu pomocí malé krabičky, plnící funkci propojovacího prvku.hlavním prvkem je centrální uzel, skrze který se uvedený propojovací prvek domluví s vnitřními uzly Kybernetického polygonu. Popis fungování jednotlivých částí je popsán v kapitole 5 a ukončen výpisy z úspěšného ukázkového příkladu. Druhým rozšířením je tunelovací nástroj. Tento nástroj nabízí možnost vytvoření virtuálního linkového propojení mezi dvěma navzájem viditelnými uzly. Výsledný tunelovací nástroj je alternativa k vytváření virtuálních lokálních sítí v rámci polygonu. Toto rozšíření nabízí i šifrování provozu a může být využito i na automatizované propojení prostřednictvím veřejné sítě. Bližšímu popisu a testovacímu provozu je věnována celá předposlední kapitola. V závěru této práce jsou shrnuty výsledky úspěšných testů obou řešení. Výsledkem práce jsou tedy dvě sady nástrojů, splňující oficiální zadání práce. Vytvořené nástroje jsou uloženy v elektronické podobě na přiloženém CD. 1

8 2 KYPO KYPO je zkratka pro Kybernetický polygon, který vytvořilo oddělení bezpečnosti na Masarykově univerzitě. Hlavním účelem KYPO je simulace bezpečnostních útoků proti různým sít ovým infrastrukturám a proti strojům, které jsou v těchto infrastrukturách umístěny. Veškerý provoz v polygonu je monitorován a nabízí tedy možnost detailně studovat dopady bezpečnostních útoků.[2] 2.1 Vlastnosti Prostředí KYPO je vytvořeno tak, aby bylo možné jej nainstalovat na libovolném cloudu založeným na modelu IaaS (Infrastructure as a Service). Poskytovatelé IaaS cloudů nabízejí provozování infrastruktury virtuálních strojů a KYPO již řeší jenom překryvné sítě nad existující sít ovou topologií. Momentálně je celá infrastruktura zbudována v cloudovém prostředí poskytovaném Masarykovou univerzitou a akademickým sdružením CESNET. Pro každý bezpečnostní scénář se vytváří izolovaný sandbox (virtuální pískoviště), ve kterém si nastavíme počet strojů a infrastrukturu sítě. 2.2 Architektura Uživatelé komunikují s prostředím KYPO skrze vstupní portál s uživatelským rozhraním. Každé vytvořené virtuální prostředí sandbox (obr. 2.1) obsahuje dedikovaný řídicí uzel (Scenario Management Node), který se stará o sestavení a správu daného prostředí. Tento řídicí uzel rovněž slouží jako vstupní bod do uzavřeného virtuálního prostředí a poskytuje doplňkové služby, jako jsou kolektory pro monitorování sít ového provozu apod. Klíčovým prvkem KYPO prostředí jsou uzly pro řízení simulovaných sítí LMN (LAN Management Node). Tyto uzly zajišt ují abstrakci LAN sítě. LMN uzly jsou virtuální stroje, na kterých běží linuxový systém se softwarovou implementací přepínače pomocí nástroje Open vswitch[1]. Na těchto uzlech je vytvořeno standardní sít ové rozhraní pro jakýkoli potřebný spoj. Každé rozhraní je propojeno s právě jedním dalším virtuálním strojem v sandboxu nebo s jiným LMN. Všechny spoje jsou uskutečněny na datové vrstvě pomocí VLAN. Spojením VLAN a softwarového přepínače je vytvořena stejná funkcionalita jako u hardwarového sít ového přepínače. Jelikož veškerý provoz proudí těmito uzly, je možnost na nich uskutečnit transparentní monitoring všech připojených uzlů. LMN jsou taky připojeny do ří- 2

9 2. KYPO dicí sítě, která slouží pro komunikaci mezi LMN uzly a řídicím uzlem scénáře. Tato sít slouží pouze k přenosu monitorovacích dat a řídicích pokynů tak, aby pozorovaná sít nebyla ovlivněna. Do řídicí sítě nejsou připojeny koncové uzly nacházející se v sandboxech. Na koncových uzlech se testují bezpečnostní incidenty a bylo tedy třeba vyhnout se možnosti kompromitování řídicí sítě nebezpečnými pakety. [4] Obrázek 2.1: KYPO infrastruktura[3] 2.3 Přehled nedostatků Od spuštění KYPO prostředí se objevilo několik různých nedostatků a možných vylepšení. Možnosti pro vylepšení testovacího prostředí se nacházejí zejména v řešení překryvných sítí. Aktuální nedostatky souvisí s propojením více fyzicky oddělených prostředí, s alternativními způsoby propojení virtuálních uzlů nebo s možnostmi připojení reálných zařízení do námi vybraného sandboxu. 3

10 2. KYPO Propojení virtuálních prostředí Kybernetický polygon se momentálně může nacházet jenom v jednom cloudovém prostředí. Pro vytváření testovacího prostředí nemusí být vždy k dispozici dostatečný výpočetní prostor pro zprovoznění žádoucích simulací. Někdy jsou dostupné výpočetní prostory v různých lokalitách a možnost propojení těchto cloudů pomocí tunelovacích mechanizmů v jednu infrastrukturu by byla příjemným doplňkem Překrývání VLAN Aktuálně se řeší připojování jednotlivých uzlů 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ře plní svou funkci. V polygonu jsou v jedné úrovni VLANy používané pro rozdělení sít ového provozu mezi fyzickými zařízeními. Další úroveň 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ě využívají dvě úrovně VLAN nad sebou, vyskytuje se problém s identifikací. Tento problém se projevuje zahazováním paketů na switchi Mechanizmus připojení fyzických zařízení Momentálně jsou součástí infrastruktury výhradně virtuální stroje, at už servisní nebo uživatelské. V rámci rozšíření funkcionalit kybernetického polygonu by tedy bylo velmi užitečné připojit do virtuálního prostředí vzdálený fyzický stroj. Ne všechny typy systému lze virtualizovat, a tedy rychlejší řešení může být připojit již existující fyzické zařízení. 4

11 3 Návrh řešení Nedostatky, na které jsem poukázal v minulé kapitole, nejsou konečné a pro každý problém existuje několik možností, jak jej vyřešit. V této práci se snažím nabídnout alternativní řešení na všechny tři zmíněné problémy. Propojení různých virtuálních prostředí i překrývaní VLAN je řešeno stejným přístupem. Rozdíl je jenom v možnosti zašifrování tunelu pro bezpečné tunelování veřejnými sítěmi. Výsledná řešení jsou tedy dvě sada nástrojů pro připojení externího zařízení a nástroj pro tvorbu tunelů. 3.1 Připojení externího zařízení Tento návrh je popsán a aplikován jako možný způsob pro řešení problematiky popsané v části Pro připojení externího zařízení do koncové sítě potřebujeme nastavit oba konce tak, aby byly schopny se domluvit a vytvořit mezi sebou tunel. Těmto nastavením se můžeme vyhnout pomocí reálné fyzické linky mezi soukromou sítí a zařízením. Toto je ale komplikované z hlediska realizace a pravděpodobně by to bylo i finančně velmi náročné. Dalším řešením je využít sít internetového poskytovatele. Provider může mít ve své síti nastavené MPLS (Multiprotocol Label Switching), který nabízí sít ovým administrátorům možnost přenášet sítí různé typy provozu a oddělovat je od sebe pomocí znakování. I když už internetový poskytovatel poskytuje VPN mechanizmy pro propojení dvou námi preferovaných uzlů, můžeme mít potřebu připojit zařízení nacházející se u jiného poskytovatele. V tomto případě bychom museli privátní linku řešit se dvěma poskytovateli. Pravděpodobně nejjednodušeji a nejlevněji můžeme propojit dva body vytvořením vlastního virtuálního propojení skrze již existující sítě. Pro toto je již vymyšleno mnoho mechanizmů a jejich popis se často označuje jako VPN (Virtual Private Network, Virtuální privátní sít ). Možným řešením, jež dále rozvíjím v této práci, je využití již vytvořené VPN technologie a na základě této technologie vytvořit potřebnou infrastrukturu pro připojení externího zařízení Infrastruktura Automatizované řešení by nebylo možné postavit čistě na jednom nástroji uloženém na jednom uzlu - a tedy součásti návrhu je využití nástrojů na jednotlivých uzlech Kybernetického polygonu a předprogramovaného pro- 5

12 3. NÁVRH ŘEŠENÍ pojovacího zařízení. Řídicí uzel Hlavním prvkem infrastruktury pro připojení externího zařízení je řídicí uzel, který je součástí vstupního portálu. Tento uzel bude inicializovat VPN servery na LMN uzlech. Inicializace bude probíhat skrze řídicí portál KYPO, který bude propojen s rozhraním řídicí části. Tento uzel bude mít uložené informace o všech aktuálních VPN serverech. Skrze tento uzel budou námi předprogramované propojovací zařízení nebo přímo cílové stroje stahovat detailní informace pro přihlášení k žádanému stroji. Tento uzel je tedy centrální části celého řešení, skrze kterou se jednotlivé části domlouvají. LMN uzel Na tomto uzlu budou vytvořené VPN servery, skrze které se budou externí zařízení připojovat do sandbox prostředí. VPN server bude mít nastavena přístupová práva pro vybrané propojovací zařízení tak, aby nebylo možné připojit nežádoucí zařízení. SMN uzel Tento uzel je vstupním bodem k LMN uzlům. Je tedy třeba zajistit, aby správně přesměrovával provoz mezi LMN uzlem a externími zařízeními. Propojovací zařízení Toto řešení pro přihlašování externího zařízení počítá s malým propojovacím zařízením, tedy malým počítačem se základními předprogramovanými funkcemi. Toto zařízení bude mít dvě sít ová rozhraní. Propojovací prvek bude zajišt ovat, po připojení do sítě, stáhnutí detailních informací z řídicího uzlu a spuštění VPN klienta.výsledek bude takový, že po připojení propojovacího zařízení do sítě a do externího zařízení, bude externí zařízení automaticky připojeno k žádané privátní síti. Externí zařízení Externím zařízením může být jakékoli zařízení, které připojíme k veřejné síti skrze propojovací zařízení. 6

13 3. NÁVRH ŘEŠENÍ 3.2 Propojení dvou uzlů Tento scénář je určen k propojení dvou uzlů, které máme plně pod kontrolou. V rámci této práce jsou v tomto scénáři řešeny dvě problematiky popsané v sekcích a Nástroj, pokrývající obě zmíněné problematiky, bude mezi dvěma body vytvářet tunel - imitující fyzické propojení na bázi Ethernet. Součásti nástroje bude volitelné zabezpečení vzniklého tunelu. Vytvořený tunel bude možné použít pro propojení virtuálních strojů. V případě zbudování více tunelů, je možné vytvořit představu společné linkové sítě mezi více uzly a nahradit tak aktuální řešení pomocí VLAN. Nástroj bude taky schopen vytvořit zabezpečený tunel mezi dvěma vzdálenými uzly. Takto vzniklý tunel může být využit jako propoj mezi dvěma námi využívanými cloudy Infrastruktura Toto řešení je navrženo na sestavování tunelu mezi dvěma uzly, které je řízeno z centrálního uzlu. Řídicí uzel Centrální uzel, na kterým se nachází nástroj pro tvorbu tunelů. Tento uzel má neomezený vzdálený přístup k cílovým uzlům. Koncové body Jedná se vždy o dvojicí zařízení s operačním systémem Linux Debian, mezi kterými se vytvoří statický tunel. Zařízení musí vlastnit veřejný klíč řídicího uzlu, jenž vzdáleně nastavuje jednotlivé detaily tunelu. 7

14 4 Popis použitých VPN technologii Pro implementaci řešení popsaných v kapitole 3 jsem využil již existující VPN technologie. Výsledné nástroje pracují nad VPN technologiemi a řeší automatizované nastavení těchto VPN systémů. Každé výše popsané řešení využívá jiný typ VPN a tady i jiné technologie. Systém, řešící připojení externího zařízení, je vybudován na softwaru OpenVPN. Nástroj, propojující dva uzly, pracuje s tunelovacím mechanizmem l2tpv3 v kombinaci se zabezpečením IPSec. 4.1 OpenVPN OpenVPN je otevřený software, který implementuje VPN techniky pro tvoření zabezpečených tunelů mezi dvěma uzly. Byl vytvořen Jamesem Yonanem a je publikován pod licencí GPL (GNU General Public Licence). Tento otevřený software má taky placenou část, která se ale týká jenom více uživatelsky přívětivé serverové části spojení. Pomocí otevřené verze můžeme vytvořit klient-server i klient-klient spojení. Nabízí možnost vytvoření tzv. přemostění, tedy simulování linkové vrstvy nebo imitaci směrovače. Implementace OpenVPN je dostupna na všech široce rozšířených operačních systémech. Je podporována jak na klasických stolních a serverových distribucích tak i na mobilních zařízeních. OpenVPN je taky dostupný na veřejných distribucích ve směrovacích zařízeních jako jsou OpenWRT nebo IPFire. OpenVPN není kompatibilní s IPSecem nebo jinými VPN balíčky. Implementace obsahuje stejný binární soubor pro klienta i server. Součástí VPN uzlu jsou i volitelné konfigurační soubory, šifrovací a autentizační klíče. Počet klíčů záleží od zvoleného způsobu autentizace. OpenVPN je nejrozšířenější veřejně používaný VPN mechanizmus nejenom pro jeho širokou podporu ale i pro velmi jednoduché nastavení. Jednoduchost konfigurace rovněž usnadňuje pochopení, jak tento software funguje. Přehledné manuálové stránky v kombinaci s jednoduchosti základního návrhu ulehčují pochopení případných komplikovanějších nastavení. OpenVPN jde rozšířit pomocí skriptů nebo pluginů třetích stran, které mohou být definovány na různých místech konfigurace. Součástí distribuce jsou ukázkové scripty, které můžeme použít přímo nebo je pro své účely upravit. Účelem těchto rozšíření je doplnit OpenVPN pokročilejšími způsoby logování, autentizací, dynamickou úpravou firewallů, prací s pokročilejšími databázemi atd. [8][13] 8

15 4. POPIS POUŽITÝCH VPN TECHNOLOGII Bezpečnost Pro zabezpečení komunikace byl vybrán protokol TLS (Transport Layer Security) původně 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ěna knihovnou OpenSSL.[12] Každý paket, který je posílán přes vytvořený tunel, je nejdřív zašifrován a následně podepsán. Tímto procesem se splní všechny požadavky na bezpečnou komunikaci - tedy autentizace, autorizace, důvěrnost a integrita dat. OpenVPN používá pro šifrování přenášených dat symetrickou šifru. Ve výchozím nastavení se pro šifrování používá bloková šifra Blowfish s délkou klíče 128 bitů. Je možnost nastavit jakoukoli jinou šifru z knihovny OpenSSL. Podporované šifry jsou Blowfish, Camellia, DES, RC2, RC4, RC5 a IDEA. Bezpečnost je rozdělena na dva autentizační mody, statický mód a TLS mód. Obě tyto možnosti plní svou funkci, ale pro dlouhodobou bezpečnost je doporučena druhá možnost, využívající certifikační autoritu, privátní a veřejné klíče. OpenVPN podporuje taky nešifrované spojení, ale to se nedoporučuje. Implicitně je nastaveno statické šifrování komunikace, které je nejjednodušší na správu a je podstatně méně náročné na výpočetní výkon než asymetrické šifrování. Pro zajištění bezpečné komunikace poskytuje OpenVPN hlavně šifrovací technologie. Mimoto je pro zvýšení bezpečnosti možnost využít další zajímavé bezpečnostní mechanizmy na úrovni operačního systému jako jsou neprivilegovaný režim, chroot, autentizace jménem a heslem. [8] V neprivilegovaném režimu se nejdřív provede inicializace tunelu pod právy superuživatele. Když již je tunel plně funkční a práva superuživatele již nejsou potřeba, změní 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čník získá kontrolu nad OpenVPN procesem, získá přístup jenom do zvoleného podstromu a má tedy velmi omezené možnosti působnosti. Údaje, poskytnuté klientem, jsou pomocí OpenVPN předány k ověření aplikaci třetí strany. 9

16 4. POPIS POUŽITÝCH VPN TECHNOLOGII Komunikace OpenVPN byla navrhnuta tak, aby ideálně fungovala nad protokolem UDP. Protokol UDP funguje na transportní vrstvě a je považován za nespolehlivý protokol. Na rozdíl od protokolu TCP totiž nezaručuje doručení všech paketů ve správném pořadí, vícenásobné doručení nebo kontrolu, zda pakety dorazily do cíle. Takový přenos v mnohém připomíná reálný provoz na fyzické vrstvě nebo na veřejné sítí. V reálném provozu je totiž komunikace na síti často ztrátová. Na spodních 3 úrovních ISO/OSI modelu se nepočítá s dodatečnou režii provozu pro zajištění spolehlivého přenosu dat. Pokud je třeba, je tato režie řešena protokolem TCP na transportní vrstvě nebo eventuálně samotnými aplikacemi ve vyšších vrstvách. Pokud je provoz pomocí UDP blokován firewallem, můžeme použít protokol TCP nebo HTTP proxy. Tato řešení mohou způsobit viditelný pokles rychlosti přenosu dat. Tento pokles je způsoben mechanizmem pro spolehlivé doručení paketů u protokolu TCP. Na pomalejších linkách tedy může být OpenVPN, využívající protokol TCP, výrazně pomalejší. Řešení tunelu přes HTTP/HTTPS proxy může náš tunel ještě víc zpomalit, ale nabízí možnost vytvoření VPN v místech, kde je povolen jen HTTP/HTTPS provoz.[8] OpenVPN využívá pro zakončení tunelů dva různé ovládače - TUN a TAP. Tyto ovládače jsou napojené na OpenVPN proces v uživatelském prostředí a chovají se jako virtuální sít ová rozhraní. Nabízí standardní způsob, jak mohou aplikace, běžící v uživatelském prostoru, komunikovat se sít ovými rozhraními aniž by potřebovaly oprávnění superuživatele. Tyto ovládače jsou pro většinu operačních systémů standardem. Na obou stranách spojení musí být vždy bud jen TAP rozhraní nebo TUN rozhraní. Ovládač TAP nabízí nízkoúrovňovou podporu pro tunelování Ethernetu, zapouzdřuje totiž provoz do rámců Ethernet Je tedy využit k vytvoření přemostění mezi dvěma koncovými body. Toto přemostění vytváří iluzi přímého fyzického propojení. Na sít ové vrstvě můžeme tedy využít námi preferované protokoly. Pomocí řešení s TAP můžeme taky využít celou vysílací (broadcast) doménu. Naproti tomu ovládač TUN zapouzdřuje provoz do IPv4 rámců a vytváří tím IPv4 tunel na sít ové vrstvě. Řešení pomocí rozhraní TUN je úspornější díky tomu, že je oproštěno o jednu vrstvu zapouzdření. Při využití rozhraní TUN můžeme simulovat směrovanou topologii i s rozdělením do různých podsítí a s využitím našeho vlastního adresního rozsahu. [11] 10

17 4. POPIS 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 různých platforem. Díky tomu můžeme tvořit šifrované l2tp tunely mezi různými operačními systémy od stolních, serverových, mobilních a až po sít ová zařízení. Oba tyto protokoly jsou navzájem nezávislé ale tím, že se mohou tak dokonale doplňovat, jsou velmi často využívány pro zabezpečené tunely přes veřejné sítě. Pro bližší pochopení, jak kombinace obou těchto protokolů funguje, nejdřív popíši tyto dva protokoly samostatně a následně základní principy společné komunikace a zabezpečení vytvořeného tunelu 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řejné sítě. Motivací pro vznik l2tp byla potřeba vytvořit tunelovací protokol pro rámce PPP (Point-to-Point Protocol). Původní 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 protokolů jako IP, AppleTalk, ATM, SONET atd. L2tp může být použit jako tunelovací protokol na veřejném internetu nebo i na různorodých interních sítích. Nejviditelnějším rozdílem mezi l2tpv2 a l2tpv3 je možnost zapouzdřit přenášená data do různých rámců linkové vrstvy. Této možnosti se dosáhlo rozdělením jednotlivých mechanizmů v l2tp a tím pádem vytvořením modulárního řešení. Druhá verze totiž umožňovala jenom zapouzdření do protokolu PPP. Protokol l2tpv3, s veškerou funkcionalitou popsanou v RFC, je implementován pouze jako komerční produkt. Základní podpora tohoto protokolu je již součástí některých linuxových distribucí obsahující jádro a vyšší - například Debian od verze Squeezy. Základní podpora taky nabízí zapouzdření různých rámců linkové vrstvy - například velmi rozšířený protokol Ethernet. [16] IPSec (Internet Protocol Security) IPSec je otevřený standart stanovený přes IETF. V sérii RFC, věnované IP bezpečnosti, jsou popsány jeho části a možná rozšíření. Implementace standardů IPSec představuje sadu protokolů, určených pro autentizaci a šifrování jednotlivých paketů, které jsou součástí zabezpečené komunikace. 11

18 4. POPIS POUŽITÝCH VPN TECHNOLOGII Standardně pakety nejsou nijak zabezpečeny. Pokud si někdo přeje určitou míru soukromí a autenticity přenášených dat, vybere si nějakou VPN nebo tunelovací aplikaci a o bezpečnost komunikace se starají tyto aplikace. Tato bezpečnost ale bude na úrovni aplikační vrstvy a tedy kdykoli někdo zachytí takto šifrovanou komunikaci, může z hlavičky IP paketů vyčíst cílovou a zdrojovou adresu, popřípadě pakety nějak pozměnit a ovládnout komunikaci. Vidíme tedy, že šifrování na vyšších vrstvách nemusí být to nejbezpečnější řešení. Standard zabezpečení sít ové vrstvy byl ale navržen pro zabezpečení veškeré komunikace - tedy komunikace na sít ové vrstvě a veškerých dalších protokolů a dat, které jsou sít ovou vrstvou zapouzdřeny. Dokonce u nové verze internetového protokolu IPv6 byl nějaký čas zamýšlen jako povinnost. Od toho se nakonec ustoupilo, ale i přesto se tomuto protokolu začíná dostávat větší pozornosti. IPSec nabízí bezpečnostní služby na sít ové vrstvě tím, že umožňuje komunikujícím stranám zvolit si šifrovací algoritmus pro komunikaci a vzájemnou výměnu klíčů - pokud si zvolí asymetrický způsob šifrování. IPSec může být použit pro ochranu jednotlivých komunikačních kanálů pro různé aplikace nebo celého provozu. Může propojovat dva samostatné uzly, slučovat dvě brány do privátních sítí, nebo sloužit jako brána do privátní sítě pro samostatné uzly. Termín Brána odkazuje na prostředníka v privátní sítí, přes kterého se můžeme do sítě připojit - tedy router nebo firewall, které mají nainstalovanou implementaci IPSecu.[17] Bezpečnost Protokol l2tp neposkytuje žádné pokročilé bezpečnostní mechanizmy. Jenom buduje tunel a poskytuje základní autentizaci druhé strany pomocí identifikace tunelu a identifikace spojení. Pokud má být tunel nějak zabezpečen, využívá se protokol IPSec. IPSec můžeme využít pro zabezpečení jenom l2tp tunelu pomocí čísla IP protokolu 17 pro UDP a 115 pro l2tp.[9] Při využití UDP protokolu se zabezpečení specifikuje pro jednotlivé porty. Security Association (SA) SA jsou jádrem celé bezpečnostní architektury IPSec. Jednotlivé SA definují, jaký způsob zabezpečení se má aplikovat na pakety v závislosti na tom, kdo je odesílá, kde směřují a jaký náklad je zapouzdřen uvnitř. Možnosti zabezpečení nabízené přes SA záleží na zvoleném bezpečnostním protokolu a módu komunikace. SA mohou být dynamicky sjednané mezi dvěma komunikujícími uzly v závislosti na bezpečnostní politice nastavené adminis- 12

19 4. POPIS POUŽITÝCH VPN TECHNOLOGII trátory uzlů. Další možností (častěji používanou) je nastavení SA manuálně administrátory na každém uzlu zvlášt. Každá SA je jedinečně identifikovatelná pomocí cílové IP adresy, bezpečnostního protokolu a SPI (Security Parameters Index). Bezpečnostním protokolem může být AH nebo ESP. SPI je 32 bitové číslo, obvykle zvolené cílovým uzlem dané SA, které je součástí každého ESP nebo AH paketu a má hlavní význam pro vzdálený uzel. Každá SA je dohoda mezi dvěma uzly o zabezpečení jednosměrné komunikace a tedy pokud si dva uzly potřebují zabezpečit data v obou směrech, potřebují mít SA pro každý směr. Taky pokud je potřeba zabezpečit komunikaci současně pomocí ESP a AH, vytváří 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ční vrstvy. V tunelovacím módu se celý paket stává součástí zabezpečené části a před bezpečnostní hlavičku se přidá nová IP hlavička. Bezpečnostní brány, které zabezpečují provoz mezi sítěmi, potřebují mít pro správnou funkčnost nastaven tunelovací mód. Pokud se IPSec nastavuje na koncových uzlech, můžeme si vybrat, jaký mód upřednostníme. [5] Bezpečnostní databáze Každý IPSec uzel má ve své správě dvě databáze, Security Policy Database (SPD) a Security Association Database (SAD). Při jakékoliv komunikaci se kontrolují záznamy v SPD a hledá se pro ně informace o bezpečnostních politikách. Tyto informace následně odkazují na SA uložené v SAD. Pakety se následně zpracují podle nalezených Bezpečnostních asociací. [5] Authentication Header AH protokol je součástí IPSec standardu. Funguje přímo nad sít ovou vrstvou s IP protokolovým číslem 51.[9] Poskytuje autentizaci jednotlivých paketů, tedy ujištění, že paket přišel v nepozměněném tvaru od adresáta uloženého v IP hlavičce. AH nabízí různou úroveň nepopíratelnosti původu paketu v závislosti na důvěryhodnosti použitého šifrovacího algoritmu a zvoleného systému výměny klíčů. Autentizační hlavička může být použita ve dvou módech. Tunelovací mód, kdy je vytvořena nová IP hlavička a celý původní paket je uložen za AH nebo transportní mód s AH umístěnou mezi původní IP hlavičku a ostatní data. Tunelovací mód nabízí kompletní autentizaci paketu, ale za cenu větší robustnosti. Transportní mód za cenu několika bajtů dat navíc 13

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

21 4. POPIS POUŽITÝCH VPN TECHNOLOGII 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řijímající stranou. Na obou koncových uzlech můžeme nastavit, zda bude tunel vytvořen nad protokolem IP nebo nad protokolem UDP. Pokud je vybrán protokol UDP, je nutné při specifikaci tunelu popsat lokální a vzdálený UDP port. Pro vytvoření tunelu se zadává taky identifikace tunelu a IP adresy obou uzlů. Konfigurace l2tpv3 koncového uzlu je velmi jednoduchá. Nejdřív je třeba přidat jednotlivé l2tp moduly do linuxového jádra. Aktuálně jsou možnosti v Ethernetovém nebo PPP zapouzdření. Moduly se přidávají příkazem modprobe. Pro vytvoření tunelu se parametry zadávají přímo za příkazem ip l2tp add tunnel. Podobně se nastavují jednotlivé komunikační kanály. Algoritmus 4.1 Pří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 remote # 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ěco komplikovanější. Pro linuxové distribuce jsou v současné době dostupné dvě 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 můžeme přímo v příkazovém řádku, ale přehlednější konfigurace se provádí pomocí textových konfiguračních souborů ipsec.secrets a ipsec.conf, které se implicitně nachází v adresáři /etc. Soubor ipsec.secrets obsahuje odkazy nebo textovou formu privátních bezpečnostních prvků pro jednotlivé směry komunikace. Privátní klíče i hesla jsou definovány zdrojovou a cílovou adresou a typem zabezpečení. Typ může být PSK (Pre Shared Key) nebo RSA. Soubor ipsec.conf obsahuje detailní informace, jak se mají jednotlivá spojení zpracovávat. 15

22 4. POPIS POUŽITÝCH VPN TECHNOLOGII Algoritmus 4.2 Příklad nastavení Ipsec-Esp tunelu pomocí hesla # sample /etc/ipsec.secrets file for : 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= leftprotoport = 17/111 right= 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ěno, že bude šifrován pouze tunelovaný provoz.[18] 16

23 5 Připojení externího zařízení do KYPO Pro připojení externího zařízení do kybernetického polygonu jsem využil VPN řešení OpenVPN. Pro automatizaci VPN prostředí jsem využil programovací jazyk Python[20], skriptovací jazyk bash a SQL databázi postgresql[19]. Infrastruktura LMN uzlů, SMN uzlů a taky řídicí uzel fungují pod operačním systémem Debian a tedy moje práce je přizpůsobena tomuto systému. Tato práce nabízí řešení centrálního uzlu, skripty pro spuštění OpenVPN na LMN uzlech a skripty pro nastavení externího zařízení pro připojení k LMN uzlu.3.1 Myšlenka tohoto řešení je vytvořit prostředí, 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řeném serveru se uloží. Následně, když se klient přihlásí do sítě, automaticky si vyžádá konfigurační soubor pro přihlášení k LMN uzlu a připojí se skrze tento uzel k žádanému sandboxu. 5.1 Řídicí část Řídicí část poskytuje jednoduché rozhraní pro vytvoření a smazání Open- VPN serverů a uložení podrobnosti o každé spuštěné instanci do SQL databáze. Centrální uzel taky nabízí cgi skript (Common Gateway Interface) pro zaslání konfiguračního souboru externím zařízením. Tato část je řešena pomocí programovacího jazyka Python a jako celek uložena v souboru kypochief. Soubor kypochief obsahuje tři objektové třídy a několik obslužných funkcí pro obsluhu specifických parametrů z příkazového řádku a práci s hlavními třídami. Hlavní třídy v programu kypochief jsou DbWorker, KeyMaker a VpnMaster Tvorba VPN serverů 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í. Řídicí část tedy nenastavuje pří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řejný klíč od řídicího uzlu a tedy můžeme se přihlásit z řídicího uzlu na jakýkoliv uzel v KYPO infrastruktuře. 17

24 5. PŘIPOJENÍ EXTERNÍHO ZAŘÍZENÍ DO KYPO VpnMaster Třída obsahující dvě hlavní metody run_vpn() a close_vpn(). Během inicializace třídy se pomocí parametrů předávají IPv4 adresy SMN a LMN uzlů a x509-jméno klienta. Během nastavování parametrů jsou IP adresy kontrolovány pro validní IPv4 tvar. Jméno klienta musí být identické s x509-jménem ve veřejném klíči klienta, jinak nedojde k vytvoření 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řív vygeneruje a podepíše RSA klíče pro server s x509- jménem ve tvaru server_[jméno klienta]. Tento pár klíčů je následně poslán v textové formě skriptu na LMN uzlu v podobě parametrů. Poté se pomocí knihovny paramiko přihlásí na SMN uzel a spustí na tomto uzlu příkaz, který se pomocí SSH přihlásí k LMN uzlu a spustí tam skript new_client (viz kapitola 5.2.1). Metoda čeká na ukončení programu a načte standardní výstup pro načtení použitého UDP portu. V případě vyskytnutí problému, se veškeré nastavení na LMN uzlu smaže a vygeneruje se výjimka s odůvodněním. Pokud spuštění OpenVPN serveru proběhlo v pořádku, uloží se mezi argumenty třídy UDP port, na kterým naslouchá server. V poslední části se nastaví přeposílání OpenVPN provozu skrze SMN uzel na vnitřní uzel pomocí iptables[22]. Pro správné fungování přidávám do NAT (Network Address Translation) tabulky prerouting pravidlo pro překlad sít ových adres podle cílové adresy. Překlad adres je nastaven na veřejnou adresu SMN uzlu a specifický UDP port, který je zrcadlením UDP portu otevřeného pro OpenVPN server na LMN uzlu. Provoz, splňující tyto dvě podmínky, se přeposí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ě jako metoda run_vpn(). Nejdří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

25 5. PŘIPOJENÍ EXTERNÍHO ZAŘÍZENÍ DO KYPO kapitola 5.2.2). Následně se zruší pravidlo v iptables na SMN uzlu přeposílající provoz na zrušený OpenVPN server Práce s databází Tato práce využívá pro ukládaní detailů o aktivních VPN serverech objektověrelační databázový systém PostgreSQL. Tento systém nabízí funkce pro tvorbu vlastních tabulek a veškerou práci s těmito tabulkami. V jazyce Python je pro práci s PostgreSQL databází implementován balíček psycopg2[23]. Tento balíček používám ve třídě 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řída DbWorker. Tato třída poskytuje specializované funkce pro přístup k SQL databázi. Jednotlivé funkce jsou přizpůsobeny požadavkům třídy VpnMaster (viz kapitola 5.1.1). Při inicializaci třídy se mohou nastavit argumenty se jménem databáze, tabulky a uživatele. Pro testovací prostředí jsou nastaveny implicitní hodnoty. Během inicializace se třída pokusí přihlásit pomocí metody psycopg2.connect ke zvolené databázi. Pokud je přihlášení úspěšné, uloží se aktivní spojení s databází mezi argumenty třídy. Pro tuto třídu je vytvořena výjimka DbException a pokud nějaká výjimka nastane během používání této třídy, bude to vždy DbException s vysvětlením, kde se nachází problém. Tabulka pro účely této práce obsahuje x509-jméno klienta, port, na kterým je otevřen OpenVPN server a IP adresy SMN a LMN uzlu. Pro tvorbu tabulky je vytvořena metoda DbWorker.create_db(), která se pokusí vytvořit novou tabulku. Pokud tabulka se stejným jménem již existuje, nová tabulka se nevytváří a v databázi je ponechána původní tabulka. Pokud již nepotřebujeme držet aktivní spojení s databází, ukončíme relaci pomocí metody DbWorker.close() Tvorba RSA klíčů Autentizace klientské a serverové části OpenVPN funguje na základě privátních a veřejných RSA klíčů podepsaných stejnou certifikační autoritou. Certifikační autorita pro účely této práce byla vytvořena pomocí OpenSSL knihovny a podepsána sama sebou[24]. Pro testovací účely to je dostačující řešení. Při tvorbě VPN serveru na LMN uzlech je každému serveru při- 19

26 5. PŘIPOJENÍ EXTERNÍHO ZAŘÍZENÍ DO KYPO dělen pár RSA klíčů, který musí být podepsán naší certifikační autoritou. Pro tyto potřeby a také pro generování klientských klíčů je vytvořena třída KeyMaker. KeyMaker Tato třída poskytuje metody pro tvorbu a podepsání RSA klíčů. Pro práci s OpenSSL knihovnou jsem použil balíček PyOpenssl.crypto. Tento balíček poskytuje metody pro veškerou práci s šifrovacími RSA klíčí. Proces vytváření použitelných klíčů začíná inicializací třídy. Následně nám stačí jenom zavolat metodu create_rsa_key() pro vytvoření privátního klíče a požadavku pro podepsání. Implicitně jsou klíče tvořeny s typem certifikátu nastaveným na hodnotu server. Pokud chceme klíč bez tohoto rozšíření, je třeba zavolat metodu s parametrem server nastaveným na False. Metodou sign_key() se požadavek podepíše certifikační autoritou, jejíž veřejný a privátní klíč musí být přítomny na lokálním stroji, a uloží se jako veřejný klíč. Následně můžeme klíče uložit do souboru anebo pomocí get metod dostat klíče v textové podobě. Během vytváření RSA klíčů se do požadavku pro certifikační autoritu přidávají informace o majiteli klíče tedy x509-jméno, zkratka státu: Cs, město: Brno a jméno organizace: Masaryk univerzity. Klíče jsou tedy tvořeny na míru pro naší infrastrukturu externích zařízení Obslužné funkce Kypochief nabízí tři hlavní funkcionality - přidat nový VPN server, odstranit VPN server a vytvořit pár RSA klíčů. Veškerou práci dělají jednotlivé třídy, ale pro základní uživatelské rozhraní jsem vytvořil pár jednoduchých funkcí, které přeberou parametry z příkazového řádku a provedou žádanou práci. add() Metoda, zpracovávající parametry příkazového řádku, pokud je první parametr add. Pro správné fungovaní jsou požadovány další tři parametry s IP adresami SMN a LMN uzlů a x509-jménem klienta. Tato metoda vytvoří instanci třídy VpnMaster a zavolá metodu run_vpn(). Následně je vytvořena instance třídy DbWorker a pomocí save_to_db() uloží detaily Open- VPN serveru z třídy VpnMaster do databáze. 20

27 5. PŘIPOJENÍ EXTERNÍHO ZAŘÍZENÍ DO KYPO 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ří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řídy. Následně je zavolána metoda close_vpn() a smaže se záznam v databázi. key_generator() Jednoduchá metoda, která vytvoří pár RSA klíčů podepsaných certifikační autoritou zastřešující naší VPN infrastrukturu. Pro správné fungování potřebuje tato metoda 3 parametry x509-jméno a názvy souboru pro privátní a veřejný klíč. Tyto parametry se zadávají z příkazového řádku za kypochief gen v pořadí jméno, název souboru pro privátní klíč a název souboru pro veřejný klíč. 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ří metod popsaných dříve v této sekci Komunikace s propojovacím zařízením V rámci automatizování celého procesu bylo třeba vymyslet způsob, jak se ke klientovi dostane aktuální informace o tom, na který uzel a na který port se má přihlásit pomocí OpenVPN. Řeš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čního souboru pro OpenVPN klienta a poslány na standardní výstup. Standardní výstup u CGI skriptů je přeposlán na zařízení, které poslalo curl dotaz. 5.2 OpenVPN server na LMN uzlu Pro inicializaci a rušení OpenVPN serverů na LMN uzlech jsou připraveny jednoduché skripty napsané v bashi. Tyto skripty jsou na LMN uzly zkopírovány nezávisle na řídicím uzlu. Je možné, že zkopírování skriptu na LMN uzel bude taky automatizováno, ale pro prokázání funkčnosti je to 21

28 5. PŘIPOJENÍ EXTERNÍHO ZAŘÍZENÍ DO KYPO zatím dostačující. Pro inicializaci se volá skript new_client. Zrušení nastavení zajistí skript del_client. Oba tyto skripty používají lokální konfigurační soubor, který obsahuje detaily nastavení OpenVPN serveru a taky soupis aktivních spojení Tvorba nového OpenVPN serveru Vytvoření nové OpenVPN instance a všechna potřebná nastavení, která jsou s tvorbou spojena, zajišt uje skript new_client. Tento skript je volán z řídicího uzlu. Mezi parametry, které tento uzel potřebuje, jsou RSA klíče pro nový server v textové podobě - 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řejný klíč popřípadě volitelnou cestu ke konfiguračnímu souboru. Pokud není konfigurační soubor mezi parametry, načítá se automaticky soubor settings (viz. příloha A), který se nachází ve stejném adresáři. Nejdřív skript zkontroluje, zda již je na stroji nainstalován balíček OpenVPN. Pokud se balíček na stroji nevyskytuje, je nainstalován. V další části se načtou detaily pro nastavení serveru z konfiguračního souboru (viz. kapitola 5.2.3). Ted již má skript veškeré informace pro správné vytvoření nového virtuálního sít ového TAP rozhraní, připojení tohoto vytvořeného rozhraní do virtuálního přepínače a vygenerování konfiguračního souboru(viz. příloha B).[10] Tento konfigurační text se uloží a spustí se nový openvpn daemon s parametry config a log, obsahující cesty k právě vygenerovanému konfiguračnímu souboru a log souboru. Pokud vše proběhlo bez problému, uloží se informace o nové OpenVPN instanci do konfiguračního souboru pro skripty (viz. příloha A) Zrušení stávajícího OpenVPN serveru Abychom ukončili běžící OpenVPN server, potřebujeme 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řebuje pro svou činnost parametr x509-jména klienta a popřípadě konfigurační soubor. Pokud není konfigurační soubor mezi parametry, načítá se automaticky soubor settings, který se nachází ve stejném adresáři. Del_client nejdřív načte detaily o lokálních OpenVPN instancích ze svého konfiguračního souboru a prohledá také řádky s aktivními instancemi, zda 22

29 5. PŘIPOJENÍ EXTERNÍHO ZAŘÍZENÍ DO KYPO se tam nachází informace o jméně obdrženém jako parametr. Pokud mezi aktivními instancemi není žádná, která by vyhovovala, je skript ukončen. Naopak, pokud se jména shodují, načtou se zbývající informace o portu a sít ovém rozhraní. Na bázi těchto údajů je ukončen OpenVPN server, smazány všechny soubory spojené s tímto serverem a smazáno sít ové rozhraní. Pokud všechno proběhlo v pořádku, je řádek s informacemi o smazaném serveru vymazán z konfiguračního souboru Konfigurační soubor Skripty na LMN uzlu komunikují spolu pomocí lokálního konfiguračního souboru settings (viz. příloha A). V konfiguračním souboru jsou zapsány informace o adresáři s OpenVPN konfiguračními a log soubory, adresáři s šifrovacími klíči, aktuální UDP port a rozsah portů pro OpenVPN. Po každém úspěšném spuštění skriptu new_client, jsou do konfiguračního souboru přidány informace o nově vytvořeném OpenVPN spojení, obsahující - jméno klienta, číslo UDP portu a jméno virtuálního sít ového rozhraní. Při zrušení jakéhokoli aktuálního spojení jsou informace o tomto spojení smazány. 5.3 Klientská část Na straně fyzického zařízení je v plánu využití malých propojovacích zařízení typu raspberry pi [25] se dvěma sít ovými rozhraními. Propojovací prvek se vloží mezi připojované zařízení a nejbližší sít ový prvek - rozbočovač nebo přepínač. Propojovací prvky budou fungovat na linuxovém systému - nejpravděpodobněji Debian. Pro propojovací zařízení je přichystaný skript, který se spustí při připojení propojovacího zařízení do sítě. Inicializační skript stáhne konfiguraci určenou pro sebe a spustí ji. Nastaví přemostění mezi OpenVPN rozhraním a rozhraním na straně koncového zařízení a povolí přeposílání paketů. Při odpojení propojovacího prvku ze sítě, je automaticky zavolán druhý skript, který ukončí běžící OpenVPN instanci a s ní spojené běžící procesy. Protože jsem neměl možnost řešení přizpůsobit na míru zařízení typu raspberry pi, je třeba před nasazením názvy sít ových rozhraní ve skriptu upravit na žádané hodnoty init_vpn Tento skript je napsán v jazyce Python a pro svou funkčnost využívá knihovny Request a subprocess. Pomocí knihovny Request vyšle požadavek k řídi- 23

30 5. PŘIPOJENÍ EXTERNÍHO ZAŘÍZENÍ DO KYPO címu uzlu, ze kterého si stáhne konfigurační soubor pro vlastní OpenVPN instanci. Následně se soubor uloží a pomocí knihovny subprocess spustí vlastní OpenVPN klient používající k připojení uložený konfigurační soubor. Knihovna subprocess je taky využita pro oživení TAP rozhraní spojeného s OpenVPN instancí a přemostění TAP rozhraní a fyzického rozhraní na straně koncového klienta pomocí bridge-utils close_vpn Jednoduchý Bash skript, který se volá, když je sít ové rozhraní na straně sítě odpojeno. Po zavolání zruší přemostění a běžící OpenVPN instanci. 5.4 Test výsledné VPN Testovací infrastruktura byla složena z centrálního řídicího uzlu na adrese kypo-devel.ics.muni.cz, na kterém jsem měl pro své účely vytvořen účet. Dalším strojem byl SMN uzel KYPO na adrese s dvěma LMN uzly. Pro simulaci koncových zařízení jsem využíval dva virtuální stroje na cloudu Metacentra a můj osobní počítač. Pro testovací účely jsem bohužel neměl zařízení typu raspberry pi. Simuloval jsem tedy propojovací zařízení pomocí mého osobního počítače a koncovým zařízením byl virtuální stroj, běžící ve virtuálním prostředí VirtualBox [26]. Skripty pro koncová zařízení jsou tedy trochu poupravené ve srovnání s verzí pro krabičku, ale funkcionalita je identická. Pro simulaci propojovacího zařízení jsem ve skriptu zakomentoval část vytvářející přemostění, protože přemostění je řešeno v prostředí VirtualBox. Před testováním bylo potřeba na LMN uzly zkopírovat soubory new_client, del_client, settings a veřejný klíč certifikační autority. V plánu pro nasazení se počítá s tím, že tyto soubory budou kopírovány na LMN uzly během jejich inicializace Připojení externích zařízení Spuštění OpenVPN serverů pro klienty roman, mirek a pepa. Po spuštění OpenVPN serverů na LMN uzlu, se informace o běžících instancích uloží do konfiguračního souboru (viz. příloha A).Pro klienta pepa je zobrazen i výpis, zobrazený při spuštění. Všechny úspěšně spuštěné OpenVPN servery mají podobný výpis. 24

31 5. PŘIPOJENÍ EXTERNÍHO ZAŘÍZENÍ DO KYPO add roman add mirek add pepa 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: TUN/TAP device tap_openvpn_0 opened Sat Dec 27 19:17: Persist state set to: ON Config file for client pepa is prepared in file /etc/openvpn/setup/srv_pepa.conf port OpenVPN instance for client pepa is ready to use Pohled na SQL databázi na řídicím uzlu @kypo-devel:~$ psql road_warriors psql (9.1.14) Type "help" for help. road_warriors=> SELECT * FROM vpns; name port smn lmn roman mirek pepa Zrušení OpenVPN serveru pro klienta papa @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: TUN/TAP device tap_openvpn_0 opened Sat Dec 27 19:15: Persist state set to: OFF Interface tap_openvpn_0 has been removed 25

32 OpenVPN instance for client pepa is shut down 5. PŘIPOJENÍ EXTERNÍHO ZAŘÍZENÍ DO KYPO Pohled na SQL databázi na řídicím uzlu po zrušení instance pro klienta pepa psql road_warriors psql (9.1.14) Type "help" for help. road_warriors=> SELECT * FROM vpns; name port smn lmn roman mirek Spuštění OpenVPN klientů Pro co nejbližší simulaci funkce propojovacího zařízení jsem na svém počítači spustil skript init_vpn a ve virtuálním prostředí VirtualBox propojil nově vytvořené 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 Test vytvořeného prostředí Vytvořené ukázkové prostředí bylo během několika chvil funkční. Koncové uzly dostaly IP adresy od DHCP (Dynamic Host Configuration Protocol) serveru, který se nacházel na LMN uzlu. Pomocí testu komunikace prostřednictvím programu ping jsem otestoval vzájemnou viditelnost připojených klientů. Částečný výpis z ip addr show na virtuálním stroji tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen link/ether 08:00:27:13:4f:22 brd ff:ff:ff:ff:ff:ff inet /24 brd scope global tap0 26

33 Částečný výpis z ip addr show na stroji cloud55 5. PŘIPOJENÍ EXTERNÍHO ZAŘÍZENÍ DO KYPO tap0: <BROADCAST,MULTICAST,UP,LOWER_UP> 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 /24 brd scope glob Ping mezi strojem cloud55 a virtuálním strojem na mém počítači root@cloud55:/etc/openvpn# ping PING ( ) 56(84) bytes of data. 64 bytes from : icmp_req=1 ttl=64 time=35.2 ms 64 bytes from : icmp_req=2 ttl=64 time=36.2 ms 64 bytes from : icmp_req=3 ttl=64 time=35.0 ms 64 bytes from : icmp_req=4 ttl=64 time=35.5 ms Zachycený provoz Na mém osobním počítači 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ěchto obrázku jde vidět, že veřejný provoz je skrytý, zatímco privátní data jsou dobře č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řeném novou OpenVPN instancí 27

34 6 Propojení dvou vzdálených uzlů Propojení dvou vzdálených uzlů je v této práci řešeno pomocí tunelovacího protokolu l2tpv3 (viz. kapitola 4.2.1). Tento protokol vytváří představu přímého Ethernetového propojení mezi dvěma body. Pokud jsou dva vzdálené uzly odděleny veřejnou sítí, nabízí toto řešení i IPSec (viz. kapitola 4.2.2) zabezpečení l2tpv3 tunelu. Moje ř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řeba vytvářet implementace pro různé distribuce. Součástí zadání bylo vytvoření tunelu mezi zařízeními, která máme pod plnou kontrolou, a tedy vytvořený program tunel.py počítá s přihlášením na vzdálené uzly jako uživatel root. Program tunel.py obsahuje dvě hlavní třídy - Tunnel a DbWorker, a několik obslužných funkcí. 6.1 Sestavování tunelů - třída Tunnel Tato třída nabízí možnost vzdáleně nastavit dva uzly jako koncové body pro l2tpv3 tunel. Nabízí taky možnost zabezpečit tunel pomocí IPSec s vygenerovaným před-sdíleným klíčem. Optimální postup při použití této třídy je posloupnost gen_port(), set_ipsec(), set_l2tp() pro vytvoření tunelu a del_l2tp(), del_ipsec() pro zrušení tunelu. Metoda gen_port() vygeneruje náhodný UDP port a následně zkontroluje, zda je tento port na koncových uzlech volný. Pokud ano, je port uložen mezi argumenty třídy, jinak je vygenerován další a opět otestován. Metody pro nastavení tunelu čerpají z argumentů třídy, uložených při inicializaci třídy nebo nastavených pomocí set metod třídy L2tp Třída Tunnel obsahuje dvě metody pro nastavení l2tp tunelu - set_l2tp a del_l2tp. set_l2tp() Sestavení l2tpv3 tunelu na koncových uzlech je nastaveno manuálně. Na obou uzlech jsou tedy nastaveny identické parametry. Jenom IP adresy lokálního a vzdáleného uzlu jsou přehozené. Tato funkce se tedy pomocí 28

35 6. PROPOJENÍ DVOU VZDÁLENÝCH UZLŮ knihovny Paramiko[21] přihlásí přes SSH tunel k cílovým uzlům a spustí na obou uzlech potřebné příkazy. Tato metoda generuje výjimku ConnectionException, pokud se nepovedlo přihlásit na cílový uzel a výjimku L2tpException, pokud nejsou dostupny všechny potřebné argumenty pro vytvoření tunelu. del_l2tp() Smazání l2tp tunelu musí byt opět provedeno na obou koncových uzlech. Tato metoda tedy opět pomocí knihovny Paramiko vytvoří SSH tunel k jednotlivým uzlům a provede příkazy potřebné ke zrušení tunelu. Tato metoda vyhodí výjimku ConnectionException, pokud se nepovedlo přihlásit na cílový uzel a výjimku L2tpException, pokud tunel neexistuje nebo nejsou dostupny potřebné argumenty pro smazání tunelu IPSec Občas je potřeba vytvořený tunel zašifrovat a právě pro tyto situace obsahuje třída Tunnel metody, které pro tunel vytvořený objektem třídy Tunnel nabízí možnost nastavit IPSec zabezpečení. set_ipsec() Aktuálně nabízí tato metoda vytvoření IPSec zabezpečení pomocí předsdíleného hesla. V rámci parametrů můžeme předat metodě jméno vytvořeného IPSec spojení. Tato metoda nejdřív vytvoří před-sdílené heslo o délce 32 znaků. Následně jsou pro každý uzel zvlášt vytvořeny 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řípadě nepovedeného přihlášení k cílovým uzlům je generována výjimka ConnectionException. Pokud je problém v parametrech potřebných k vytvoření 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ě se na koncových uzlech restartuje služba IPSec. V případě nepovedeného přihlášení k cílovým uzlům je generována výjimka ConnectionException. Pokud je problém v parametrech potřebných ke smazání IPSecu, je generována výjimka IpsecException. 29

36 6.2 Práce s databází - třída DbWorker 6. PROPOJENÍ DVOU VZDÁLENÝCH UZLŮ Tato třída je v mnohém podobná třídě v řídicí části systému pro připojení vzdáleného zařízení do Kybernetického polygonu (viz. kapitola 5.1). Tato třída obsahuje metody pro uložení, čtení a mazání údajů o vytvořených tunelech. Údaje jsou uložené v SQL databázovém systému PostgreSQL. Každý řádek v tabulce obsahuje identifikaci tunelu, IP adresy propojených uzlů, číslo UDP portu a informaci o použití IPSecu. Identifikace tunelu je taky primárním klíčem pro vyhledávání v tabulce. IP adresy propojených uzlů musí být adresy formátu IPv4. Číslo UDP portu souvisí s l2tp tunelem, který na obou uzlech poslouchá právě 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řebnou k práci s tunely a s databází poskytují výše popsané třídy. Mezičlánek mezi třídami a uživatelem řeší obslužné funkce, které zpracovávají parametry z příkazového řádku a volají jednotlivé metody hlavních tříd. add() Tato funkce je zavolána, pokud je prvním parametrem add. Funkce add() následně zpracovává další parametry a vytváří pomocí nich instanci třídy Tunnel. Pokusí se sestavit l2tp tunel. V případě, že je posledním parametrem ipsec, připojí k vytvořenému tunelu šifrování pomocí IPSecu. Informace o úspěšně vytvořeném tunelu jsou následně pomocí třídy DbWorker uloženy do lokální SQL databáze. delete() Tato funkce je zavolána, pokud je prvním parametrem del. Tunel může být specifikován pomocí identifikace tunelu nebo koncových zařízení. Pokud se najde shoda v lokální SQL databázi, jsou další informace o tunelu načteny z databáze a pomocí nich je vytvořen objekt třídy Tunnel. Pokud byl tunel zabezpečen, je nejdřív zrušeno IPSec zabezpečení. Následně je zrušen l2tp tunel. Pokud vše proběhlo v pořádku, jsou informace o tunelu vymazány z databáze. 30

37 6. PROPOJENÍ DVOU VZDÁLENÝCH UZLŮ show() Tato funkce je zavolána, pokud je prvním parametrem show. Funkce vytiskne na standardní výstup všechny aktuálně vytvořené tunely. usage() Tato funkce se zavolá v případě, kdy parametry příkazového řádku neodpovídají potřebám metod add(), delete() nebo show(). 6.4 Test výsledného tunelu Pro otestování funkčnosti programu tunel.py jsem vytvořil zabezpečený tunel mezi dvěma virtuálními stroji v cloudu Metacentra. Vytvořeným strojům jsem nastavil statické cesty skrze tunel Sestavení tunelu Spuštění zabezpečeného tunelu mezi dvěma body roman@komputerek:~$ tunel.py add ipsec Port for l2tp tunnel: : Ipsec for l2tp tunnel is set : Ipsec for l2tp tunnel is set. Interface for l2tp tunnel: tunel5613 l2tp tunnel at is up Interface for l2tp tunnel: tunel5613 l2tp tunnel at is up root@cloud55:~# ip addr add peer 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 yes 31

38 6. PROPOJENÍ DVOU VZDÁLENÝCH UZLŮ (1 row) Kontrola spuštěných l2tp a IPSec tunelů root@cloud55:~# service ipsec status IPsec running - pluto pid: pluto pid tunnels up some eroutes exist root@cloud55:~# ip l2tp show tunnel Tunnel 93740, encap UDP From to Peer tunnel UDP source / dest ports: 5613/ Test tunelu Během testování jsem pomocí programu ping nejdřív testoval spojení na privátní adresu v tunelu, následně spojení na veřejnou adresu druhého uzlu a test jsem zakončil opět kontrolou spojení na privátní adresu v tunelu. Test viditelnosti uzlů skrze tunel root@cloud55:~# ping PING ( ) 56(84) bytes of data. 64 bytes from : icmp_req=1 ttl=64 time=0.029 ms 64 bytes from : icmp_req=2 ttl=64 time=0.017 ms 64 bytes from : icmp_req=3 ttl=64 time=0.018 ms 64 bytes from : icmp_req=4 ttl=64 time=0.016 ms Během testu viditelnosti mezi koncovými uzly tunelu jsem zachytil provoz programem tcpdump. Z výsledného výpisu jde dobře rozeznat test spojení postupně na veřejnou adresu, adresu v tunelu a pak opět na veřejnou adresu. Situace spojení skrze tunel je na obrázku 6.1 označena červenou barvou. 32

39 6. PROPOJENÍ DVOU VZDÁLENÝCH UZLŮ Obrázek 6.1: Provoz, zachycený mezi koncovými uzly Ukončení tunelu Pro smazání tunelu a veškerých nastavení s ním spojených potřebujeme znát identifikaci tunelu nebo koncové body. Ukončení tunelu pomocí tunnel_id roman@komputerek:~$ tunel.py del id l2tp tunnel at is down l2tp tunnel at is down : Ipsec for l2tp tunnel is removed : Ipsec for l2tp tunnel is removed 6.5 Výsledek Vzniklý tunel i jeho fungování splňuje zadání a ukazuje, že tento program je možné použít k propojení uzlů, které máme pod kontrolou. Na obrázku 6.1 lze vidět, že IPSec je aplikován pouze na vytvořený l2tp tunel a veškerá další komunikace je nepozměněna. 33