Připojení na stroje v sandboxech projektu Kypo

M ASARYKOVA UNIVERZITA FAKULTA INFORMATIKY

}

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

Æ

Pˇripojení na stroje v sandboxech projektu Kypo ˇ B AKALÁ RSKÁ PRÁCE

Radim Fornusek ˚

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.

Radim Fornusek ˚

Vedoucí práce: Mgr. Dalibor Toth i

Podˇekování Rád bych na tomto místˇe podˇekoval nejprve svému vedoucímu Mgr. Daliboru Tothovi i ostatním vedoucím vizualizaˇcního týmu, RNDr. Radku Ošlejškovi, Ph.D. a RNDr. Zdenku Eichlerovi, pod jejichž vedením jsem se mohl podílet na projektu KYPO. Dále bych chtˇel podˇekovat Mgr. Andreji Luˇcanskému, na jehož pˇrehledný kód jsem pˇri své práci navazoval, a dalším, zkušenˇejším rˇ ešitelum ˚ z vizualizaˇcního týmu, jejichž rady mi pomohly pˇri implementaci mého rˇ ešení. Dík patˇrí i lidem pracujícím na cloudové cˇ ásti projektu KYPO. Jejich pomoc a spolupráce byla taktéž nezbytná pro úspˇešnost mé práce. Zmínit musím i svou rodinu a pˇrátele, kteˇrí mi poskytovali podporu nepˇrímo a nejspíše o tom ani sami nevˇedˇeli.

ii

Shrnutí Kybernetický polygon (KYPO) pˇredstavuje nástroj pro výzkum internetové bezpeˇcnosti. Tato bakaláˇrská práce je souˇcástí vizualizaˇcní cˇ ásti tohoto projektu a zabývá se problematikou vzdáleného pˇrístupu ke strojum ˚ v jeho testovacích prostˇredích. Ten je založen na technologii VNC pro pˇrístup ke vzdálené ploše a na protokolu SSH pro bezpeˇcné vzdálené pˇrihlášení. Výsledkem této práce je pˇrehled nástroju, ˚ které za tímto úˇcelem mohou být použity v prostˇredí webového prohlížeˇce, a implementace pˇripojení pomocí VNC jako rozšíˇrení stávajícího portletu pro portál Liferay.

iii

Klíˇcová slova SSH, VNC, Kybernetický polygon, vzdálené pˇripojení, vzdálená plocha, Liferay, portlet, topologie.

iv

Obsah 1 Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Projekt KYPO . . . . . . . . . . . . . . . . . . . . . . . . 2.1 O projektu KYPO . . . . . . . . . . . . . . . . . . . 2.2 Sandbox . . . . . . . . . . . . . . . . . . . . . . . . 2.3 OpenNebula a virtualizace . . . . . . . . . . . . . . 2.4 Možnosti pˇripojení k virtuálním uzlum ˚ . . . . . . 2.5 Vizualizace projektu KYPO . . . . . . . . . . . . . 3 Technologie pro vzdálený pˇrístup . . . . . . . . . . . . 3.1 Vzdálený pˇrístup . . . . . . . . . . . . . . . . . . . 3.1.1 VPN . . . . . . . . . . . . . . . . . . . . . . 3.1.2 Tunely . . . . . . . . . . . . . . . . . . . . . 3.1.3 SSH . . . . . . . . . . . . . . . . . . . . . . 3.2 Vzdálená plocha . . . . . . . . . . . . . . . . . . . . 3.2.1 VNC . . . . . . . . . . . . . . . . . . . . . . 3.2.1.1 Verze a kódování . . . . . . . . . . 3.3 Vzdálený pˇrístup pˇres webový prohlížeˇc . . . . . 3.3.1 SSH pˇres webový prohlížeˇc . . . . . . . . . 3.3.1.1 Emulace terminálu . . . . . . . . . 3.3.1.2 Architektura . . . . . . . . . . . . 3.3.1.3 Pˇrehled možných nástroju˚ . . . . 3.3.2 VNC pˇres webový prohlížeˇc . . . . . . . . 3.3.3 Univerzální rˇ ešení . . . . . . . . . . . . . . 4 Použité technologie a služby . . . . . . . . . . . . . . . 4.1 Portál Liferay . . . . . . . . . . . . . . . . . . . . . 4.2 noVNC . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 WebSocket . . . . . . . . . . . . . . . . . . . . . . . 4.4 Služba pro poskytování údaju˚ pro VNC pˇripojení 5 Implementace . . . . . . . . . . . . . . . . . . . . . . . . 5.1 Rozšiˇrování topologie . . . . . . . . . . . . . . . . 5.1.1 graph.js . . . . . . . . . . . . . . . . . . . . 5.1.2 init.js . . . . . . . . . . . . . . . . . . . . . . 5.1.3 init-remote.js . . . . . . . . . . . . . . . . . 5.1.4 vnc.html . . . . . . . . . . . . . . . . . . . .

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

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

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

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

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

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

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

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

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

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

1 3 3 4 6 7 7 9 9 9 10 10 11 12 13 14 14 14 15 16 18 20 23 23 24 24 24 26 26 26 27 27 29 v

5.2

Tvorba portletu . . . . . . . . . . . . 5.2.1 Struktura portletu . . . . . . 5.2.2 Webové stránky . . . . . . . 5.2.3 Konfigurace portletu Liferay 5.2.4 Editaˇcní mód . . . . . . . . . 5.3 Další aspekty vývoje . . . . . . . . . 5.3.1 Podpora prohlížeˇcu˚ . . . . . 5.3.2 Poloha kurzoru˚ . . . . . . . . 6 Závˇer . . . . . . . . . . . . . . . . . . . . . A Obsah elektronické pˇrílohy . . . . . . . . B Obrazové pˇrílohy . . . . . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

. . . . . . . . . . .

29 30 30 31 32 33 34 34 36 39 40

vi

1 Úvod Dnešní doba je charakteristická rostoucí rychlostí pokroku. Neustále pˇricházejí nové technologie, jsou vylepšovány ty stávající, ale pˇrestože se pohybujeme v této „pˇretechnizované” dobˇe, kdy nové technologie cˇ asto zastarají v rˇ ádu nˇekolika let, mužeme ˚ v lidské spoleˇcnosti stále najít jevy, které jsou zde od pravˇekých dob. I pˇres jakousi symbiotickou povahu souˇcasné spoleˇcnosti, kdy by bez spolupráce, dˇelby práce a specializace nebyl možný tak rychlý pokrok, se stále vyskytují predátoˇri, proti nimž se musí zbytek spoleˇcnosti bránit. Se vznikem virtuálního svˇeta v prostˇredí internetu, se takovým predátorum ˚ otevˇrelo nové bojištˇe a zmˇenil se zpusob ˚ boje i zbranˇe. Co se však od dávných dob nemˇení, je smysl hry: potenciální obˇet’, která hledá zpusoby ˚ jak se bránit, a predátor, jenž opˇet vylepšil své zbranˇe. Na úrovni druhu˚ se toto dˇelo a dˇeje v procesu evoluce pˇrirozeným výbˇerem, ve specializovaném virtuálním prostˇredí se tento boj odehrává vˇedomým procesem v rukou relativnˇe malého poˇctu odborníku. ˚ Právˇe pro zlepšení schopnosti obrany proti takovým virtuálním zloˇcincum ˚ má sloužit Kybernetický polygon [3]. Kybernetický polygon (zkrácenˇe KYPO) pˇredstavuje komplexní nástroj pro simulace bezpeˇcnostních útoku˚ ve virtuálním prostˇredí a je vyvíjen Ústavem výpoˇcetní techniky Masarykovy univerzity ve spolupráci s Fakultou informatiky. Praktickým cílem mé bakaláˇrské práce bylo implementovat rˇ ešení, které poskytuje vzdálený pˇrístup ke koncovým virtuálním strojum ˚ v uzavˇrených testovacích prostˇredích tohoto projektu, v takzvaných v sandboxech. Implementovaná funkcionalita navazuje na portlet Topologie Andreje Luˇcanského [6]. Integrace do zobrazení struktury sítˇe a jednotlivých koncových uzlu, ˚ které jmenovaný portlet zobrazuje, je logická – uživatel muže ˚ identifikovat stroj, ke kterému chce pˇristupovat, podle jeho umístˇení ve virtuální síti sandboxu nebo jiných atributu, ˚ které jsou uživateli poskytnuty tímto portletem. Ve své práci se nejprve zamˇerˇ ím na projekt Kybernetického polygonu, jeho úˇcel a strukturu, použité technologie a zmíním možnosti vzdáleného pˇripojení, které se nám nabízí. Tˇretí kapitola pˇriblíží technologie pro vzdálený pˇrístup nejprve z obecného hlediska a následnˇe se zamˇerˇ í na pˇripojení pomocí protokolu SSH a technologie VNC, které byly v požadavcích projektu KYPO. Pokusím se o krátké pˇriblížení každé z tˇechto technologií a výˇctu nástroju, ˚ které lze použít v prostˇredí webového 1

1. Ú VOD prohlížeˇce. Kapitoly cˇ tyˇri a pˇet jsou vztaženy k samotné implementaci vzdáleného pˇripojení. Jelikož se od požadavku pro pˇrístup protokolem SSH prozatím upustilo a nebylo vubec ˚ implementováno, bude tato cˇ ást popisovat pouze skuteˇcnˇe realizované pˇripojení pˇres VNC. Kromˇe samotného kódu budou krátce zmínˇeny nˇekteré použité technologie, knihovny a nástroje, jimiž byl výsledek pˇreveden do webové aplikace pro portál Liferay, tedy do portletu.

2

2 Projekt KYPO Tako kapitola pˇredstaví projekt KYPO, jeho úˇcel, cíle a moduly, z nichž se skládá. Pˇriblíží strukturu výzkumných prostˇredí – sandboxu, ˚ na nichž polygon stojí. Zmínˇena bude technologie, která umožnuje ˇ bˇeh tˇechto sandboxu, ˚ a nˇekteré další základní pojmy. Nakonec se teoreticky podíváme na možnosti pˇripojení ke koncovým uzlum ˚ v testovacích prostˇredích.

2.1

O projektu KYPO

Zamýšleným cílem projektu Kybernetického polygonu je výzkum oblasti kybernetické bezpeˇcnosti. Výsledkem tohoto projektu je prostˇredí, ve kterém lze simulovat kybernetické útoky – napˇríklad distribuované útoky odepˇrení služby (DDoS), phishing nebo šíˇrení trojských koní a cˇ ervu. ˚ Scénář 1

Scénář .... ....

Správa scenáře

LAN 1

LMN 1

Zpracování dat

Vizualizace

LMN n

Uzel správy scénáře

...

Vstupní portál

LMN 2

Konfigurace scénáře

LAN 2 LAN n

Scénář n


Databáze

Simulace & Měření

Obrázek 2.1: Schéma Kybernetického polygonu [3] Pro každý takový útok musí existovat scénáˇr, který kromˇe technické defi3

2. P ROJEKT KYPO nice a dokumentace podrobností obsahovat napˇríklad i jeho slovní popis. Projekt KYPO pokrývá všechny aspekty simulace - od pˇrípravy scénáˇre daného útoku, pˇres vytvoˇrení virtuální infrastruktury a jeho provedení na ní. Dále v prubˇ ˚ ehu útoku poskytuje možnosti pro sledování této infrastruktury, kontrolní zásahy v reálném cˇ ase a zárovenˇ po skonˇcení umožnuje ˇ analýzu dat namˇerˇ ených v jeho prubˇ ˚ ehu. Tyto rˇ ízené simulace by mˇely sloužit napˇríklad k vývoji bezpeˇcnostních nástroju˚ nebo jako prostˇredek pro školení bezpeˇcnostního personálu. To muže ˚ probíhat napˇríklad jako „hra” dvou týmu˚ bezpeˇcnostních odborníku. ˚ Architektura projektu KYPO je složena ze cˇ tyˇr modulu, ˚ které spolu vzájemnˇe spolupracují. •

Správa scénáˇru˚ je hlavní modul. Pˇredává data definovaná scénáˇrem ostatním modulum ˚ a stará se o rˇ ízení scénáˇru˚ jak bˇehem jejich inicializace, tak i o kontrolní zásahy pˇri jeho vykonávání.

•

Správa cloudu poskytuje virtuální infrastrukturu, na níž jsou scénáˇre provádˇeny, a nástroje pro její správu.

•

Správa mˇerˇ ení se stará o mˇerˇ icí prvky v infrastruktuˇre.

•

Správa vizualizace umožnuje ˇ grafickou prezentaci probíhajícího scénáˇre nebo dat získaných mˇerˇ ením a také napˇríklad rozhraní k nˇekterým nastavením.

Jednotlivé bezpeˇcnostní scénáˇre jsou provádˇeny nad izolovanými sandboxy. Protože je nutná libovolná škálovatelnost a rychlá konfigurovatelnost podle aktuálních požadavku˚ na velikost (tedy poˇcet stroju) ˚ nebo konfiguraci topologie, vytváˇrení reálných fyzických infrastruktur je nereálné. Proto bylo pro Kybernetický polygon zvoleno použití cloudových technologií. Pro implementaci cloudu je v souˇcasné dobˇe používána OpenNebula [7] kvuli ˚ své veˇrejné licenci a vysoké míˇre konfigurovatelnosti.

2.2

Sandbox

Sandbox mužeme ˚ do cˇ eštiny pˇreložit jako pískovištˇe a v našem pˇrípadˇe jím rozumíme uzavˇrené prostˇredí pro bezpeˇcné provádˇení požadovaných scénáˇru˚ [3]. Za použití cloudového softwaru typu IaaS (Infrastructure as a service) jsou sandboxy vytváˇreny jako sít’ové infrastruktury skládající se pouze z virtuálních stroju. ˚ 4

2. P ROJEKT KYPO

; Obrázek 2.2: Moduly a konfigurace Kybernetického polygonu [3] Kromˇe koncových bodu˚ na síti, kterými mohou být osobní poˇcítaˇce, servery nebo i mobilní zaˇrízení, jsou nezbytné pro sandboxy v projektu KYPO dva specializované druhy uzlu˚ [5]. Prvním z nich je uzel správy sandboxu (SMN – Sandbox Management Node), druhým je uzel pro rˇ ízení simulovaných sítí (LMN – LAN Management Node). SMN je rˇ ídící uzel a každý sandbox má právˇe jeden. Tento uzel se stará o sestavení testovacího prostˇredí a umožnuje ˇ vstup do sandboxu [3]. Nachází se zde databáze s konfigurací pro daný scénáˇr, na webovém serveru zde bˇeží RESTová služba, která dokáže poskytovat informace o sestaveném prostˇredí, mohou tady být umístˇeny nástroje pro sbˇer namˇerˇ ených dat a další pomocné moduly [2]. Jeden nebo více uzlu˚ LMN zajišt’uje vytvoˇrení virtuální topologie LAN v sandboxu. Vybudování propojení mezi stroji je možné pomocí služeb poskytovaných cloudovým softwarem, vˇetšinou však není možné ovlivnit použité sít’ové protokoly na vrstvˇe L3. Použití LMN však dovoluje virtuálnˇe simulovat fyzické spojení na vrstvˇe L2; volba protokolu na vrstvˇe L3 pak zustává ˚ na uživateli nebo správci – muže ˚ si napˇríklad vybrat mezi protokolem IPv4 nebo IPv6. Díky použití nižší sít’ové vrstvy muže ˚ také být simulováno zpoždˇení paketu˚ nebo poruchy v komunikaci. Každý takový LMN je pˇredstavován strojem s operaˇcním systémem Linux a bˇežící softwarovou implementací pˇrepínaˇce [5]. 5

2. P ROJEKT KYPO Kromˇe této simulované topologie je vytváˇrena také rˇ ídicí sít’ mezi uzlem pro správu sandboxu a LMN. Slouží pˇredevším pro pˇrenos rˇ ídicích a monitorovacích dat, duležité ˚ je však zajistit, aby toto rozhraní bylo odstínˇeno od probíhajícího simulovaného útoku. LAN 1

Zpracování dat

LMN 1

Vstupní rozhraní

LMN 2

Pomocné moduly LMN n


LAN 2 LAN n

Simulovaná síť

Řídící síť

Obrázek 2.3: Schéma sandboxu [5]

2.3

OpenNebula a virtualizace

V souˇcasné dobˇe je k vytváˇrení a správˇe vlastní virtuální infrastruktury v cloudu pro projekt Kybernetického polygonu používán software OpenNebula. OpenNebula je jedním z mnoha ruzných ˚ cloudových rˇ ešení typu IaaS, která mohou být za tímto úˇcelem využita. Na rozdíl od vˇetšiny komerˇcních rˇ ešení však dovoluje nasazení na vlastních hardwarových prostˇredcích. Není tak závislá na externím poskytovateli, který vˇetšinou úˇctuje poplatky za výpoˇcetní cˇ as CPU, což muže ˚ být výhodnˇejší z hlediska celkových nákladu˚ [3]. V tomto pˇrípadˇe je jeho provozovatelem Masarykova univerzita a sdružení CESNET. Od ostatních open-source rˇ ešení se pak OpenNebula liší více možnostmi pro konfiguraci [11]. Duležitou ˚ souˇcástí cloudového softwaru je tzv. hypervisor, nˇekdy nazývaný také Virtual Machine Monitor. Tato komponenta se stará o jednotlivé virtuální stroje bˇehem jejich celého životního cyklu: provádí nasazení z šablony obrazu virtuálního stroje podle definovaných parametru: ˚ zapnutí, pozastavení nebo obnovení bˇehu, pˇrípadnˇe zastavení. Mezi tyto virtualizaˇcní technologie patˇrí napˇríklad KVM, Xen nebo VMware [7]. 6

2. P ROJEKT KYPO

2.4

Možnosti pˇripojení k virtuálním uzlum ˚

V tomto okamžiku bychom mˇeli mít dostateˇcné znalosti, abychom mohli uvažovat možnosti pˇripojení k jednotlivým uzlum. ˚ Konkrétním rˇ ešením nahlíženým z teoretického hlediska budu vˇenovat kapitolu tˇri, ve cˇ tvrté kapitole pak bude popsána prakticky realizovaná verze. Zde se jenom podíváme na konceptuální možnosti pˇripojení, jak jsou pˇredkládány ve zprávˇe o pˇrípravˇe experimentálního prostˇredí v cloudu [5]. Prvním z rˇ ešení je pˇripojení po klasických linkách tvoˇrících požadovanou topologii. Pokud vezmeme v úvahu reálnou situaci, kdy k útoku dochází mimo testovací prostˇredí, je tato cesta zˇrejmˇe jedinou možností komunikace, kterou muže ˚ bezpeˇcnostní tým použít pro zásah. V našem pˇrípadˇe, kdy se jedná o simulaci v testovacím prostˇredí, však nemusí být tento zpusob ˚ žádoucí, zvláštˇe pokud k dispozici máme jiné možnosti pˇrístupu. Jednak muže ˚ být tato komunikaˇcní cesta ovlivnˇena probíhajícím útokem nebo nechceme, aby zasahovala do dat mˇerˇ ených v prubˇ ˚ ehu útoku. Druhým zpusobem ˚ je pˇripojení pˇres rˇ ídicí sít’, která však v souˇcasné dobˇe existuje pouze mezi SMN a LMN. Za úˇcelem pˇripojení ke koncovým strojum ˚ by musela být rozšíˇrena. Tomu se však chceme vyhnout kvuli ˚ odlišnému chování stroju˚ se dvˇema sít’ovými rozhraními a kvuli ˚ možnosti napadení rˇ ídicí sítˇe z koncových uzlu. ˚ Tˇretí možností je využití pˇrímého pˇripojení ke koncovým uzlum, ˚ které není vedeno pˇres samotné rˇ ídicí uzly topologie a je poskytováno pˇrímo cloudovým softwarem. V našem pˇrípadˇe OpenNebula používá technologii VNC. VNC server, který spojení zprostˇredkuje, je nainstalován jako souˇcást všech koncových virtualizovaných stroju˚ v jejich základní konfiguraci.

2.5

Vizualizace projektu KYPO

Tato práce je primárnˇe souˇcástí vizualizaˇcní cˇ ásti projektu KYPO, využívá však i správy cloudu, která jednak poskytuje koncová zaˇrízení, ke kterým se pˇripojujeme, a také službu, jenž poskytuje potˇrebné informace pro pˇripojení. Vizualizaˇcní modul je vyvíjen jako specializovaný nástroj pro správu, sledování a analýzu bezpeˇcnostních scénáˇru˚ a je postaven na technologii webového portálu Liferay [12]. Ten poskytuje modularitu a rozšiˇritelnost tak, že každý sandbox je reprezentován jednou site – stránkou nasazenou v portálu Liferay. Každou tako7

2. P ROJEKT KYPO vou stránku je možné konfigurovat, dále ji hierarchicky dˇelit a vytváˇret logická seskupení portletu. ˚ Nˇekteré portlety mohou sloužit k poˇcáteˇcní konfiguraci testovacího prostˇredí, jiné mohou pˇredstavovat ruzné ˚ zpusoby ˚ vizualizace namˇerˇ ených dat. To, jestli urˇcitý pohled na data použijeme, muže ˚ ovlivnovat ˇ napˇríklad typ provádˇeného scénáˇre na daném sandboxu. Pˇri pruzkumu ˚ možných rˇ ešení se tedy hledala taková, která využívají webové technologie a bude je možné integrovat do webového portálu. Zárovenˇ by použité knihovny a software nemˇely podléhat komerˇcním licencím a je také žádoucí vyhnout se nutnosti instalace dalších programu˚ na uživatelský poˇcítaˇc, za úˇcelem poskytnutí funkcionality vzdáleného pˇripojení.

8

3 Technologie pro vzdálený pˇrístup V této cˇ ásti budou z teoretického hlediska popsány možnosti vzdáleného pˇripojení, zpusoby ˚ jakým muže ˚ být uchopeno a související pojmy. V puvodním ˚ zámˇeru implementace vzdáleného pˇrístupu ke koncovým stroju˚ v sandboxech se kromˇe technologie VNC plánovalo také použití SSH. Od tohoto požadavku se v praktické implementaci sice prozatím upustilo, pˇresto bude pˇrehled možných technologických rˇ ešení a nástroju˚ pro obˇe technologie zahrnut v této kapitole.

3.1

Vzdálený pˇrístup

Pod termínem vzdálený pˇrístup si mužeme ˚ pˇredstavit více jevu. ˚ V dnešní mobilní dobˇe se s našimi elektronickými zaˇrízeními cˇ asto pohybujeme mezi ruznými ˚ fyzickými sítˇemi a už nesedáváme u poˇcítaˇce permanentnˇe zapojeného do jedné sítˇe, který má vždy dostupná všechna potˇrebná data a zdroje v síti. Logicky pak vyvstává požadavek na pˇrístup do jiné vzdálené sítˇe. Hlavními požadavky pˇri navazování takového spojení je jeho zabezpeˇcení a dostupnost pouze autorizovanému uživateli. K zabezpeˇcení se dnes cˇ asto vytváˇrejí virtuální privátní sítˇe oznaˇcované také jako VPN nebo napˇríklad protokol pro bezpeˇcnou komunikaci SSH. Jiným pˇrípadem je, že ne vždy nám staˇcí pˇrístup k síti. Z jednoho fyzického místa chceme pˇristupovat k jinému poˇcítaˇci ve stejné síti, napˇríklad k serveru nebo k virtuální pracovní stanici. Muže ˚ to být pˇres emulovaný textový terminál nebo také pomocí protokolu˚ poskytujících vzdálenou plochu. Kombinací obou pˇrípadu˚ je, když se nacházíme v jiné síti a pˇripojujeme se k urˇcitému koncovému stroji. V pˇrípadˇe že není takové pˇripojení poskytováno pˇrímo, je naším hlavním zámˇerem získat pˇrístup nejprve do cílové vzdálené sítˇe a následnˇe jsme vˇetšinou schopni pˇristupovat k jednotlivým strojum ˚ v této síti. 3.1.1

VPN

Bezpeˇcnosti privátních sítí bylo puvodnˇ ˚ e dosahováno díky pronajatým nesdíleným pˇrenosovým linkám [13]. Tento typ VPN – trusted1 (duvˇ ˚ erná) – je vˇetšinou nahrazován flexibilnˇejším zpusobem ˚ pro pˇripojení pˇres sdílené sítˇe. Jedná se 1. Podle jiného zdroje [8] však tento zpusob ˚ nelze oznaˇcit za virtuální privátní sít’, protože tato linka je nesdílená a vytváˇrí skuteˇcnou privátní sít’.

9

ˇ 3. T ECHNOLOGIE PRO VZDÁLENÝ P RÍSTUP

o secure (zabezpeˇcené) VPN a ty jsou tvoˇreny pomocí šifrování a použití softwarových aplikací i hardwarových komponent. Obecnˇe mužeme ˚ VPN spojení kategorizovat na ta mezi dvˇema sítˇemi LAN a tˇemi, co umožnují ˇ vzdálený pˇrístup do privátní sítˇe z jednoho zaˇrízení. Pro náš úˇcel, kdy se uživatel pˇripojuje na vzdálený poˇcítaˇc, se dá lépe aplikovat druhý ze jmenovaných typu. ˚ Vzdálený pˇrístup je realizován softwarem s architekturou klient-server. Klientská cˇ ást se nachází na našem stroji, ze kterého se pˇripojujeme. Server vzdáleného pˇripojení pak slouží jako brána (gateway) do vzdálené sítˇe, do které vˇetšinou patˇrí. Tento server obvykle poskytuje služby, které provedou autentizaci a autorizaci pˇripojujícího se uživatele. Po navázání vzdáleného pˇripojení má uživatel stejné možnosti, jako by byl do této sítˇe fyzicky pˇripojen. 3.1.2

Tunely

Jedním ze zpusob ˚ u, ˚ jak vytváˇríme vzdálený pˇrístup nebo spojení sítí do VPN, je takzvané tunelování. Tunel tvoˇrí spojení mezi dvˇema body tak, že všechna zaˇrízení na cestˇe jsou pro poˇcáteˇcní a koncový bod transparentní. Proces tunelování znamená, že posílaný paket je celý zapouzdˇren, smˇerˇ ován a vˇetšinou šifrován [13]. Na tomto procesu se podílejí ruzné ˚ protokoly. Pˇríkladem muže ˚ být L2TP (Layer 2 Tunneling Protocol ) pˇres IPsec. Jedná se o protokoly na vrstvˇe L2 a L3 modelu ISO/OSI. Pro vytvoˇrení VPN vzdáleného pˇripojení však muže ˚ být použito i protokolu˚ SSL/TLS obvykle používaných pro bezpeˇcnou komunikaci klienta se serverem protokolem HTTP a tvoˇrících tak jeho bezpeˇcnou verzi HTTPS. Tento druh bezpeˇcného protokolu používají napˇríklad nˇekterá rˇ ešení poskytující vzdálené pˇripojení pˇres webový prohlížeˇc. Tunelování umožnuje ˇ i dále zmínˇené SSH. 3.1.3

SSH

SSH, neboli Secure Shell, pˇredstavuje alternativu k vytváˇrení bezpeˇcného pˇripojení VPN [1]. SSH je protokol, který rˇ íká, jak provádˇet bezpeˇcnou komunikaci po síti, zárovenˇ však pod stejným oznaˇcením mužeme ˚ najít produkty, které tento protokol používají. Na rozdíl od VPN, které je realizováno protokoly na nižších úrovních, je SSH spojení vytváˇreno na aplikaˇcní vrstvˇe. K cˇ emu je dnes protokol SSH nejˇcastˇeji používán, je umožnˇení pˇrihlášení ke vzdálenému SSH serveru a zprostˇredkování terminálu, podobnˇe, jako pˇri použití nezabezpeˇceného 10


programu telnet [1]. Jedná se o softwarové rˇ ešení s architekturou klient-server. V Unixových OS jsou obvykle obˇe cˇ ásti nativnˇe zakomponovány. Na jiných operaˇcních systémech, odkud se chceme pˇripojit k Unixovým nebo Linuxovým systémum, ˚ cˇ asto vidíme 2 použití klientu˚ od tˇretích stran, napˇríklad PuTTY . Existují však i serverové aplikace, které napˇríklad z poˇcítaˇce, na kterém bˇeží operaˇcní systém Windows, vytvoˇrí server pro pˇripojení pomocí SSH.

3.2

Vzdálená plocha

Pˇripojení ke vzdálené ploše mužeme ˚ považovat za formu vzdáleného pˇrístupu [13]. Nepˇripojujeme se však jenom do sítˇe, ale k urˇcitému vzdálenému stroji v této síti, a je nám pˇredkládáno grafické rozhraní operaˇcního systému bˇežícího na tomto stroji. Pro uživatele na klientské stranˇe je tedy simulován fyzický pˇrístup k obrazovce, myši a klávesnici (pˇrípadnˇe dalším periferiím) vzdáleného poˇcítaˇce. Software pro pˇripojení ke vzdálené ploše (remote desktop software) využívá speciální protokoly, které vytváˇrí bezpeˇcné VPN spojení pro vzdálený pˇrístup a jsou uzpusobené ˚ k úspornému pˇrenosu dat. Mezi dnes používané protokoly pro vzdálené pˇripojení patˇrí: •

RDP (Remote Desktop Protocol) – slouží pro pˇripojení k systémum ˚ Windows

•

RFB (Remote Frame Buffer Protocol) – protokol používaný v rˇ ešení VNC

•

ICA (Independent Computing Architecture) – používaný v komerˇcních produktech spoleˇcnonsti Citrix

•

ARD (Appple Remote Desktop) – pro systémy s operaˇcními systémy Macintosh

•

X Window System v X11 – nejˇcastˇeji používán na Linuxových operaˇcních systémech

Tyto protokoly a aplikace, ve kterých jsou používány, mužeme ˚ rozdˇelit na dvˇe skupiny podle principu, jakým jsou pˇredávána zobrazovaná data [14]. První skupina využívá pˇríkazu˚ operaˇcního systému pro zobrazování. Data, která se mají zobrazit, jsou serverovou stranou posílána v podobˇe sémantických 2.

http://www.putty.org/

11


zobrazovacích pˇríkazu˚ a interpretována klientskou cˇ ástí aplikace. To znamená, že tato skupina rˇ ešení je znaˇcnˇe platformnˇe závislá, ale umožnuje ˇ dosáhnout lepší optimalizace pro daný systém. Do této skupiny patˇrí napˇríklad protokol RDP. Druhou skupinou jsou protokoly, které pˇrenášejí data jako informaci o obrazových bodech. Z duvodu ˚ omezení využití sítˇe je nutná komprese a jiné metody pro snížení nároˇcnosti na sít’ pˇri datovém pˇrenosu. Tím muže ˚ být napˇríklad posílání pouze té cˇ ásti obrazovky, která se zmˇenila. Tento druh pˇripojení také vˇetšinou nemá informaci o uživatelském pˇrihlášení do operaˇcního systému, které probíhá na vzdáleném poˇcítaˇci. Pokud je tento poˇcítaˇc fyzický a je pˇred ním jiný uživatel, vzdálenˇe pˇripojenému uživateli jsou zobrazovány stejné informace. Možnost takového sdílení obrazovky muže ˚ být vhodné napˇríklad pro výukové úˇcely. Toto naopak nemusí platit u první skupiny protokolu: ˚ pˇrihlášení na vzdáleném poˇcítaˇci muže ˚ být navázáno právˇe pˇres vzdálené pˇripojení a muže ˚ být soukromé – tedy viditelné pouze z klientské strany. V našem pˇrípadˇe se nepˇripojujeme pˇrímo k fyzickým poˇcítaˇcum, ˚ ale k virtuálním strojum, ˚ které jsou umístˇeny ve virtuálních sítích poskytovaných cloudovou službou. 3.2.1

VNC

Technologie VNC pˇrestavuje zpusob ˚ pˇripojení ke vzdálenému grafickému rozhraní pˇripojeného do sítˇe internet [10]. Pojmem VNC oznaˇcujeme vˇetšinou pˇrímo software, nˇekdy je tak však oznaˇcen i samotný protokol. Správnˇe se však protokol, na kterém technologie VNC stojí, nazývá RFB (Remote Framebuffer) protokol [9]. RFB protokol pˇrenáší data z pamˇeti vzdáleného poˇcítaˇce, která jsou vykreslována na jeho zobrazovací zaˇrízení (nebo by mˇela být zobrazena, monitor nemusí být pˇripojen). Díky tomu, že se pracuje pˇrímo s obrazovými daty, je tento zpusob ˚ pˇripojení nezávislý na specifickém operaˇcním systému a je tedy možné VNC používat pro pˇripojení k ruzným ˚ grafickým prostˇredím vˇcetnˇe Windows, Mac OS nebo Linuxu. V opaˇcném smˇeru jsou posílány informace ze vstupních zaˇrízení, obvykle klávesnice, myši, touchpadu nebo dotykové obrazovky. Architektura tohoto rˇ ešení je opˇet postavena na komunikaci mezi klientem (ˇcasto oznaˇcovaném jako viewer) a serverem, který se nachází na poˇcítaˇci, ke kterému se pˇripojujeme. Bezstavový klient je v pˇrípadˇe VNC velmi tenký a jednoduchý na implementaci. Bezstavovost umožnuje ˇ to, že více uživatelu˚ muže ˚ pˇristupovat k jednomu vzdálenému serveru souˇcasnˇe a jsou jim všem pˇredklá12


dána stejná obrazová data. Po ukonˇcení relace VNC však uživatelské pˇrihlášení do operaˇcního systému na vzdáleném poˇcítaˇci stále pokraˇcuje a vzdálený klient na nˇej muže ˚ opˇet kdykoliv navázat. Mezi nejznámˇejší software poskytující VNC pˇripojení mužeme ˚ zaˇradit napˇríklad UltraVNC, RealVNC nebo TeamViewer. 3.2.1.1 Verze a kódování Základní verze protokolu RFB byla vyvinuta ve výzkumných laboratoˇrích Olivetti & Oracle. Puvodní ˚ protokol byl ruznˇ ˚ e rozšiˇrován a dnes jsou VNC a protokol RFB nadále udržovány spoleˇcností RealVNC [9]. Protokolem RFB je specifikováno navázání a ukonˇcení komunikace, zasílané zprávy, zpusoby ˚ kódování obrazové informace, zabezpeˇcení a také možná rozšíˇrení. Protože pˇrenášíme velké množství obrazových dat, je právˇe komprimace du˚ ležitým prvkem. Dˇríve byla problémem pomalá rychlost pˇripojení k internetu, dnes pro nutnost komprimace mluví rostoucí rozlišení monitoru˚ a využívání mobilního pˇripojení, které se stále v mnoha pˇrípadech úˇctuje podle objemu pˇrenesených dat. Základní kódování (Raw) je založeno na vykreslování cˇ tvercu˚ obrazových dat na urˇcité souˇradnice. Copy-rectangle (také CopyRect ) kódování je využito napˇríklad pˇri pˇresunování okna po obrazovce nebo použití posuvníku. Je postaveno na tom, že klientovi byla cˇ ást novˇe zobrazovaných dat již poslána v pˇredchozím stavu. Namísto opˇetovného pˇrenosu dat je pak poslána pouze instrukce popisující pˇresun dané oblasti. V praxi se pak obvykle používají napˇríklad kódování Hextile nebo ZRLE [9]. Aktualizace obecnˇe jsou posílány pouze pro cˇ ást obrazovky, která se skuteˇcnˇe zmˇenila, a navíc jsou rˇ ízeny požadavky klienta, které se pˇrizpusobují ˚ rychlosti sítˇe [10]. Zpˇetná kompatibilita je zajištˇena bˇehem navazování spojení, kdy si klient a server vymˇení zprávy o rozlišení obrazovky, barevné hloubce a dohodnou se na vhodném kódování, které podporují obˇe strany. Jedním z pozdˇejších rozšíˇrení jsou také typy zabezpeˇcení. V puvodním ˚ pojetí bylo totiž VNC nezabezpeˇcené. Pro omezení odposlouchávání dat v internetu se tedy muselo použít napˇríklad vytvoˇrení virtuální privátní sítˇe. Pozdˇeji bylo možné použít zabezpeˇcenou VNC autentizaci, samotná komunikace však dále probíhala nešifrovanˇe. Další bezpeˇcnostní typy však poskytují i takovou funkcionalitu, že komunikace muže ˚ probíhat jiným protokolem, než je RFB, pod podmínkou, že se na nˇem klient i server shodnou. Bezpeˇcnostní typ Tight projektu TightVNC napˇrí13


klad umožní navazování bezpeˇcných tunelu˚ 3 .

3.3

Vzdálený pˇrístup pˇres webový prohlížeˇc

Protože má být vzdálený pˇrístup k sandboxu integrován do webového portálu, bylo nutné hledat nástroje, které by bylo možné použít v tomto prostˇredí bez toho, aby uživatel používající portál musel instalovat nˇejaký dodateˇcný software. Pokud nechceme být omezeni napˇríklad tím, zdali je na uživatelovˇe poˇcítaˇci nainstalována a v prohlížeˇci povolena Java, jsme vˇetšinou odkázáni na použití kombinace HTML, CSS a JavaScriptu – tyto technologie jsou však podporovány všemi moderními webovými prohlížeˇci. 3.3.1

SSH pˇres webový prohlížeˇc

Podobnˇe jako samostatný software pro pˇripojení pomocí SSH bˇežící pˇrímo v prostˇredí daného operaˇcního systému, má i rˇ ešení pomocí webového prohlížeˇce architekturu typu klient-server. 3.3.1.1 Emulace terminálu Emulace samotného terminálu muže ˚ probíhat v ruzných ˚ cˇ ástech aplikace. To do urˇcité míry muže ˚ ovlivnit podobu celého rˇ ešení, serveru i klienta. K emulaci muže ˚ docházet bud’ na stranˇe serveru nebo klienta a podle toho jsou také kladeny vˇetší výpoˇcetní nároky na jednu nebo druhou stranu [15]. Nejprve k pˇrípadu emulace na stranˇe serveru. Serverovou cˇ ást rˇ ešení terminálu pˇres webový prohlížeˇc obvykle pˇredstavuje webová aplikace. Právˇe ta navazuje relaci s SSH serverem na cílovém poˇcítaˇci a reprezentace terminálu je pak posílána klientské cˇ ásti napˇríklad v podobˇe kódu HTML zabezpeˇceným protokolem HTTPS. Výhodou serverové emulace muže ˚ být napˇríklad to, že relace není ukonˇcena po zavˇrení webového prohlížeˇce a je tedy možné na ni zpˇetnˇe navázat z jakéhokoliv místa. Naopak v pˇrípadˇe emulace na klientské stranˇe je terminálová relace navázána pˇrímo z webového prohlížeˇce a v pˇrípadˇe jeho zavˇrení je také ukonˇcena. Webová aplikace na serveru v tomto pˇrípadˇe pˇreposílá neinterpretovaná data komunikace se SSH serverem4 a o zpracování a pˇrevedení do podoby HTML kódu se stará 3. 4.

podle community verze specifikace na https://github.com/rfbproto/rfbproto/ pˇrípadnˇe zprostˇredkujícím proxy serverem

14


aplikace na klientské stranˇe. Zde pak mužeme ˚ narazit na omezení zpusobená ˚ možnostmi JavaScrpitového kódu. 3.3.1.2 Architektura Pro naše použití není pˇríliš žádoucí, abychom na každý koncový stroj, ke kterému pˇristupujeme, instalovali dodateˇcný software. Pˇridáním dalšího softwaru zvýšíme hardwarovou nároˇcnost tohoto stroje, muže ˚ to znamenat další konfiguraci navíc a obecnˇe na uzel pˇridáváme prvek, který muže ˚ ovlivnovat ˇ probíhající scénáˇr. Nutnosti instalovat na koncový uzel webový aplikaˇcní server se tedy chceme vyhnout. Navíc bychom ke každému stroji takto umožnovali ˇ pˇrímý pˇrístup z internetu. Uživatel Webový prohlížeč

SMN

Koncový uzel

Webová aplikace

SSH server

AJAX / Web Socket LMN

SSH

SSH SSH klient knihovna

Koncový uzel SSH

SSH server

Obrázek 3.1: Architektura rˇ ešení SSH v sandboxu Vhodnˇejší variantou je umístˇení webové aplikace na uzel správy sandboxu. V kapitole pojednávající o projektu KYPO bylo zmínˇeno, že na tomto uzlu již bˇeží aplikaˇcní server a uzel pˇredstavuje vstupní bod do sandboxu. Nachází se zde i databáze, která by mohla být po rozšíˇrení využita napˇríklad k ukládání pˇrístupových údaju˚ pro jednotlivé uzly. Webový SSH server na SMN tak bude pˇredstavovat prostˇredníka, který bude dále používat vlastního SSH klienta nebo knihovny, které budou tvoˇrit souˇcást webové aplikace, k pˇrístupu ke koncovým uzlum ˚ sandboxu. Pro Linuxové stroje mužeme ˚ spoléhat na jejich nativnˇe zabudovaný SSH server, pokud bychom pˇrístup pomocí SSH chtˇeli napˇríklad k systémum ˚ Windows, bylo by na nˇe tˇreba SSH server doinstalovat. Vzdálené pˇripojení bude smˇerováno pˇres uzly LMN, ke kterým vede rˇ ídicí sít’. Otázkou je, zdali by bylo vhodnˇejší rozšíˇrit rˇ ídicí sít’ až na koncové uzly, nebo 15


pro tunelování z LMN na koncový uzel použít virtuální linku tvoˇrící samotnou topologii sandboxu. 3.3.1.3 Pˇrehled možných nástroju˚ Nástroje jsou vˇetšinou poskytovány jako ucelená rˇ ešení zahrnující klienta i server. Klientská cˇ ást je však v mnoha pˇrípadech použita ze samostatných externích projektu, ˚ pˇríkladem muže ˚ být term.js5 . Serverové cˇ ásti jsou napsány v ruzných ˚ programovacích jazycích, zatímco klient je ve vˇetšinˇe pˇrípadu˚ z hlediska funkcionality pˇredstavován kódem JavaScript. Projekty existují pod ruznými ˚ licencemi a nachází se v odlišných stupních aktivity. Gate One Gate One6 je emulátor terminálu s otevˇrenou licencí a využívá technologie WebSockets. Klientská strana využívá JavaScript a HTML5, zatímco serverová cˇ ást je napsaná v jazyce Python. Projekt poskytuje obsáhlou dokumentaci. Instalaˇcní soubory serverové cˇ ásti jsou však vhodné pouze pro Linuxové OS. K dispozici jsou pak dvˇe možnosti licencování: komerˇcní licence pro Gate One, nebo licence AGPLv3, která však pˇredpokládá zveˇrejnˇení zdrojového kódu projektu, ve kterém je Gate One zabudován. AjaxTerm4j Tento projekt7 vznikl pˇreportováním projektu AjaxTerm8 do jazyka Java. Klientská strana je opˇet tvoˇrena JavaScriptovým modulem; se serverovou stranou komunikuje pomocí objektu˚ XmlHttpRequest. Tato serverová strana je pak poskytována v podobˇe zdrojového kódu webové aplikace a je nutné ji nejprve zkompilovat. Nativnˇe používá knihovnu trilead-ssh9 , která této aplikaci zajišt’uje právˇe pˇripojení k SSH serveru. Její nasazení pak záleží na volbˇe uživatele, napˇríklad na webový server Apache. Shell In a Box Dalším projektem, který umožnuje ˇ emulaci terminálu ve webo10 vém prohlížeˇci, je Shell In a Box (nˇekdy psáno také jako shellinabox). Na stroj, 5. https://github.com/chjj/term.js/ 6. http://liftoff.github.io/GateOne 7. http://ajaxterm4j.kohsuke.org/ 8. http://antony.lesuisse.org/software/ajaxterm/HEADER.html, je však již nˇekolik let neaktivní 9. https://github.com/jenkinsci/trilead-ssh2/ 10. https://code.google.com/p/shellinabox/

16


na který se chceme pˇripojit, je nainstalován program shellinaboxd, který bˇeží jako webový server. Ten muže ˚ být nakonfigurován, aby poskytoval služby pro pˇripojení na ruzných ˚ URL adresách. Klientská strana je pˇredstavována emulátorem vt100.js napsaném v JavaScriptu a se serverem komunikuje pomocí technologie AJAX. Serverová aplikace je na oficiálním webu ke stažení jako instalaˇcní balíˇcek pro linuxovou distribuci Debian nebo v podobˇe zdrojového kódu, který je napsán v programovacím jazyce C. Na jiných místech pak lze nalézt i návody pro instalaci na dalších distribucích Linuxu11 . Použití shellinaboxd vˇcetnˇe konfigurace je na webových stránkách projektu dobˇre dokumentováno. Shell In a Box je licencován pod GNU General Public License verze 2. KeyBox Projekt KeyBox12 jako svou hlavní výhodu nabízí centralizovanou správu uživatelu˚ a jejich pˇrístupu˚ ke koncovým strojum. ˚ K tomuto úˇcelu také nabízí webové rozhraní. Kromˇe konfigurace uživatelu˚ umožnuje ˇ napˇríklad distribuci SSH klíˇcu˚ na stanice, k nimž bude s jejich pomocí pˇristupovat. Svým pojetím architektury se snadnou centralizovanou správou by pˇredstavoval vhodné rˇ ešení pro nasazení na uzel LMN. Zajímavou funkcionalitou je možnost provádˇení pˇríkazu˚ na více systémech souˇcasnˇe. Ze strany klienta je založen na externím skriptu term.js a od prohlížeˇce požaduje podporu WebSocket. Server je pˇredstavován aplikací napsanou v jazyce Java. K dispozici je volnˇe pˇrístupný zdrojový kód i instalaˇcní balíˇcky pro operaˇcní systémy Linux, Unix, OS X i Windows. Balíˇcek kvuli ˚ jednoduchosti již obsahuje aplikaˇcní server Jetty. KeyBox je licencován pod Apache License verze 2.0 a v souˇcasné dobˇe je stále aktivní. MindTerm MindTerm13 pˇredstavuje ponˇekud odlišný pˇrístup. Ve své základní podobˇe je pˇredstavován Java aplikací, nás však bude spíše zajímat jeho podoba pˇredstavována Java appletem. Výhodou MindTerm je to, že není potˇreba serverová strana, muže ˚ tak pˇredstavovat napˇríklad pˇrímou náhradu klienta PuTTY. Odpadá tedy nutnost instalace a konfigurace webového serveru a uživatel muže ˚ vytvoˇrit tunel pˇres uzly SMN a LMN pomocí použití parametru ProxyCommand 11. http://www.tecmint.com/shell-in-a-box-a-web-based-ssh-terminal-to-access-remote-linuxservers/ 12. http://sshkeybox.com/ 13. http://tech.cryptzone.com/mindterm

17


programu ssh. Pokud bychom však chtˇeli automatizovat toto pˇripojení, museli bychom implementovat další logiku na klientské stranˇe, která by se starala o automatickou konfiguraci takového tunelu. Nevýhodou tohoto rˇ ešení je v první rˇ adˇe nutnost instalace Java Virtual Machine na poˇcítaˇci, ze kterého pˇristupujeme a pˇrípadné další konfigurace ve webovém prohlížeˇci. Omezení také mohou pˇredstavovat vhodné licence. Kromˇe tˇrí komerˇcních je nabízena pouze jedna otevˇrená, která je limitována deseti uživateli a povolená pouze pro osobní a omezené komerˇcní použití14 . Pro toto použití je však dostupný zdrojový kód i dokumentace. Secure Shell a hterm Ještˇe odlišnˇejším rˇ ešením je kombinace nástroju˚ hterm15 a Secure Shell16 . Secure Shell je Chrome aplikace, která spoleˇcnˇe s emulátorem terminálu hterm poskytuje SSH klienta pro webový prohlížeˇc Chrome. To pro celé rˇ ešení pˇredstavuje dvˇe omezení. Prvním je nutnost použití prohlížeˇce Chrome a druhým je instalace pluginu Secure Shell do tohoto prohlížeˇce. Díky oblíbenosti zmínˇeného prohlížeˇce a jednoduchosti instalace pluginu˚ se však hodí uvažovat i o tomto rˇ ešení. hterm – jinak známý také jako HTML Terminal – pˇredstavuje pouze emulátor terminálu v tom smyslu, že sám nenavazuje spojení k serveru. To je zprostˇredkováno právˇe cˇ ástí Secure Shell, která dále nepotˇrebuje žádné prostˇredníky – napˇríklad tzv. relay server. hterm je napsán pouze v JavaScriptu tak, aby se co nejvíce podobal nativnímu terminálu xterm. Podle tvurc ˚ u˚ byla pˇri vývoji také prioritou rychlost, s níž je terminál schopný zpracovávat množství pˇricházejícího textu. Web projektu hterm obsahuje rˇ adu instrukcí pro vlastní úpravy vzhledu, návodu˚ jak vkládat a kopírovat text z terminálu nebo posílání klávesových kombinací, které jsou ve vˇetšinˇe prohlížeˇcu˚ namapovány na urˇcité funkce. 3.3.2

VNC pˇres webový prohlížeˇc

Použití webového prohlížeˇce jako klienta pro pˇrístup k VNC serveru není nikterak nová myšlenka. Tato možnost byla realizována již v poˇcátcích vývoje VNC 14. http://www.cryptzone.com/pdfs/Cryptzone_Datasheet_MindTerm_EN.pdf 15. https://github.com/macton/hterm 16. https://chrome.google.com/webstore/detail/secure-shell/pnhechapfaindjhompbnflcldabbghjo?hl=en

18


v podobˇe Java appletu [10], dnes existují i nástroje založené na jiných technologiích. Zdá se však, že oproti poˇctu technologií pro emulaci terminálu je výbˇer v oblasti VNC ponˇekud užší, snad kvuli ˚ vˇetší nároˇcnosti zpusobené ˚ prací s obrazovými daty. Z pohledu architektury se nám pak – i vzhledem k použitelným nástrojum ˚ – nabízí nˇekolik možností. V nˇekterých pˇrípadech muže ˚ být VNC spojení klientovi zprostˇredkováno webovou aplikací, jindy je možné použít VNC repeater, nˇekdy také nazýván VNC reflector. Tato zaˇrízení se chovají jako proxy pro VNC spojení. Umožnují ˇ pˇripojení k více zaˇrízením umístˇeným v lokální síti pˇres jeden port17 . Pro jejich umístˇení se tedy opˇet nabízí uzel SMN. TightVNC Projekt TightVNC18 nabízí kompletní rˇ ešení VNC pod komerˇcní i otevˇrenou licencí, jehož souˇcástí je i klient pro webový prohlížeˇc realizovaný jako Java applet. TightVNC Java Viewer muže ˚ být používán pˇrímo na klientském pocˇ ítaˇci. To však vyžaduje pˇrítomnost Java Virtual Machine na tomto poˇcítaˇci. Druhou možností je nasazení tohoto appletu do webového serveru. Webový server s tímto appletem je pˇrímo souˇcástí TightVNC serveru, je však možná i instalace na vlastní webový server. Podle dokumentace19 by však mˇel být tento webový server nainstalován na stejném poˇcítaˇci jako samotný VNC server kvuli ˚ bezpeˇcnostním omezením Javy. TightVNC nabízí pouze VNC autentizaci a pro bezpeˇcnou komunikaci je nutné využít jiných prostˇredku, ˚ napˇríklad vytváˇrení SSH tunelu. ˚ FlashLight-VNC Klient FlashLight-VNC20 je postaven na technologii Adobe Flash a licencován pod General Public License verze 3. Klient je postaven na kódování Tight, výpoˇcetní nároˇcnost je pak snížena využitím technologie Flash. Právˇe použití Tight kódování omezuje množinu použitelných VNC serveru, ˚ které 21 také musí toto kódování podporovat . Na cílovém poˇcítaˇci dále musí být nainstalován takzvaný socket policy server, který umožnuje ˇ pˇripojení pomocí technologie Flash. Kromˇe pˇrímého pˇripojení je možné použít i kompatibilní VNC repeater. 17. 18. 19. 20. 21.

http://home.gna.org/vncssld/ http://www.tightvnc.com/docs.php http://www.tightvnc.com/doc/java/README.txt http://flashlight-vnc.sourceforge.net/index.html podle specifikace se jedná napˇríklad o TightVNC, UltraVNC, TurboVNC, VineVNC, X11VNC

19


noVNC Knihovna noVNC22 pˇredstavuje VNC klienta napsaného v jazyce JavaScript a používajícího HTML5. Deklarována je podpora všemi moderními prohlížeˇci, dokonce i tˇemi mobilními v operaˇcních systémech Android a iOS. Komunikace probíhá pomocí protokolu WebSocket a podporuje i jeho šifrovanou verzi. V pˇrípadˇe, že prohlížeˇc WebSocket nepodporuje, je použit emulátor web-socketjs (pˇribalený s knihovnou) používající technologii Adobe Flash. noVNC podporuje základní operace schránky a ruzná ˚ kódování VNC. Pro pˇripojení je nezbytný bud’ VNC server, který podporuje WebSocket, nebo použití proxy websockify, která pˇredstavuje most mezi obvyklým TCP protokolem a komunikací pomocí WebSocket. Projekt je stále aktivní, dobˇre dokumentován a je kryt licencí Mozilla Public License verze 2.0. Jiná rˇešení Vˇetšina dalších nástroju, ˚ které nabízí webového klienta, je nˇejakým zpusobem ˚ omezená. Bud’ z hlediska podporované platformy nebo tím, že nabízí pouze komerˇcní licenci. OnlineVNC23 poskytuje klienta pˇrímo skrze vlastní web a pro pˇrístup je potˇreba mít vytvoˇren uživatelský úˇcet. Server je pˇri nekomerˇcním užití možné používat bez placené licence, omezen je však platformou, jíž je operaˇcní systém Windows. Spoleˇcnost Cybele Software24 nabízí klienta používajícího HTML5 pro pˇripojení ke vzdálené ploše systému Windows na bázi komerˇcních licencí. Jeho dˇrívˇejší vývoj však zahrnoval i klienta pro VNC pod názvem ThinVNC25 licencovaný pod General Public License verze 2. Bohužel se jedná o alfa verzi a ani samotný výrobce na tohoto klienta samostatnˇe neodkazuje. 3.3.3

Univerzální rˇešení

Jak už bylo zmínˇeno výše, ne všechny operaˇcní systémy mají SSH server jako souˇcást své cˇ isté instalace. Napˇríklad u operaˇcních systému˚ Windows by musel být vždy doinstalován a nakonfigurován. Pokud bychom tedy chtˇeli zajisti pˇrístup ke všem koncovým strojum, ˚ nejen tˇem podporujícím vzdálené pˇripojení pomocí SSH, a zárovenˇ se chtˇeli vyhnout instalaci externích SSH serveru˚ a využívat 22. 23. 24. 25.

https://github.com/kanaka/noVNC http://www.onlinevnc.com/ http://www.cybelesoft.com/ http://sourceforge.net/projects/thinvnc

20


jenom nativní programy pro každý operaˇcní systém, potˇrebovali bychom univerzální rˇ ešení, které dokáže emulovat pˇrístup k ruzným ˚ protokolum ˚ pomocí stejného rozhraní. Guacamole Guacamole26 pˇredstavuje komplexní rˇ ešení, které je zajímavé právˇe svou univerzálností. Jedná se o otevˇrený, volnˇe šiˇritelný projekt pod licencí MIT. Na webových stránkách je poskytnuta pomˇernˇe rozsáhlá dokumentace. Instalaˇcní balíky a návody Guacamole serveru jsou míˇreny na linuxovou platformu. Architekturu projektu zobrazuje následující schéma, které bylo pˇrekresleno z webu projektu27 a mírnˇe upraveno. Uživatel

HTML5 webový prohlížeč

Webový aplikační server

Gucamole protokol přes HTTP Guacamole Guacamole protokol

guacd

RDP

SSH

VNC

RDP server

SSH server

VNC server

Koncový uzel

Koncový uzel

Koncový uzel

Obrázek 3.2: Architektura rˇ ešení Guacamole Klientská strana je opˇet napsána v jazyce JavaScript, a využívá technologie HTML5. Komunikuje se serverovou stranou, realizovanou jako webová aplikace, pˇres HTTP pomocí vlastního protokolu Guacamole jako alternativy k protokolu WebSocket. Pro pˇripojení k jednotlivým koncovým strojum, ˚ které (at’ už nativnˇe nebo doinstalováním) podporují ruzné ˚ protokoly vzdáleného pˇripojení, obsahuje serverová cˇ ást také vlastní proxy nazývanou guacd. Guacd se stará o zprostˇredkování komunikace mezi webovou aplikací (Guacamole protokol) a žádaným pro26. http://guac-dev.org/ 27. http://guac-dev.org/doc/gug/guacamole-architecture.html

21


tokolem. Tím muže ˚ být VNC, RDP nebo i SSH. Pro nˇekteré protokoly je však nutné do Guacamole doinstalovat potˇrebné knihovny. Zajímavé je rˇ ešení terminálu SSH. Jelikož se jedná o textový, nikoliv grafický protokol, je terminál emulován již na serveru a až tento obrazový výstup je posílán na klientskou cˇ ást podobnˇe jako u protokolu RDP nebo VNC.

22

4 Použité technologie a služby V koneˇcných požadavcích bylo rozhodnuto o implementaci pˇripojení pouze pomocí technologie VNC. Vzdálené pˇripojení pˇres VNC, v podobˇe, jak bylo prakticky rˇ ešeno, se však cˇ ásteˇcnˇe liší od navrhovaných architektur uvedených v pˇredchozí kapitole. Hlavním rozdílem je to, že toto vzdálené pˇripojení poskytuje pˇrímo OpenNebula. To znamená, že se vyhýbáme nutnosti vedení spojení skrze sandbox, což by znamenalo pomocí rozšiˇrování rˇ ídicích linek na koncové uzly nebo používání linek tvoˇrících topologii. Tím se zbavíme nechtˇeného ovlivnˇení mˇerˇ ených dat nebo možnosti napadení speciálních uzlu˚ v topologii provádˇenými útoky. OpenNebula používá pro virtualizaci hypervisor QEMU, který na každém emulovaném virtuálním stroji integruje VNC server. To umožnuje ˇ zejména nezávislost na operaˇcním systému, který bˇeží na virtuálním koncovém stroji. Mužeme ˚ tak stejným zpusobem ˚ pˇristupovat napˇríklad k linuxovým terminálum, ˚ operaˇcním systémum ˚ Windows i systému Android. V této cˇ ásti bude detailnˇeji popsán portál Liferay a jeho možnosti. Dále bude ještˇe krátce zmínˇena knihovna noVNC, protokol WebSocket, který tato knihovna používá, a rozhraní pro získání údaju˚ potˇrebných pro pˇripojení.

4.1

Portál Liferay

Podle Riche Sezova portálem mužeme ˚ oznaˇcit jednotné webové prostˇredí, které umožnuje ˇ bˇeh a používání aplikací, které uživatel potˇrebuje, a umožnuje ˇ jejich logické a systematické uspoˇrádání [12]. Nejedná se však o oficiální definici, existují i další definice; v našem pˇrípadˇe mužeme ˚ tvrdit, že Liferay portál slouží jako open source platforma pro tvorbu takových webových stránek. To také pˇredpokládá jeho bˇeh na aplikaˇcním serveru jako je napˇríklad Apache Tomcat. Kromˇe otevˇrené verze je k dispozici také placená komerˇcní Enterprise edice, která mimo jiné zahrnuje zákaznickou podporu, bezpeˇcnostní aktualizace, stabilnˇejší prostˇredí nebo zvýšený výkon. Liferay umožnuje ˇ vlastní nastavení vzhledu, poskytuje nástroje pro spolupráci, muže ˚ sloužit pro správu webového obsahu1 , kdy je napˇríklad možné definovat workflow (posloupnost operací) požadovaných procesu. ˚ V neposlední 1.

tedy jako Web Content Management System, zkrácenˇe WCM

23

4. P OUŽITÉ TECHNOLOGIE A SLUŽBY rˇ adˇe také nabízí funkce pro implementaci sociálních aplikací. Jednou ze schopností, které budeme využívat, je multi-site hosting. Každá jednotlivá site – stránka bude v našem pˇrípadˇe pˇredstavovat jeden sandbox. Dále je pak pro každou takovou webovou stránku možné konfigurovat hierarchické uspoˇrádání „podstránek”. Na ty je možné pˇridávat aplikace, které se v prostˇredí portálu nazývají portlety. Mnoho takových univerzálních aplikací patˇrí do základní výbavy portálu Liferay. Napˇríklad portlet notifikací nebo kalendáˇr. Duležitá ˚ je také integrovaná správa pˇrístupu: ˚ možnost definování uživatelu˚ a skupin na ruzných ˚ úrovních a jejich pˇrístupu˚ od jednotlivých stránek až po sites.

4.2

noVNC

Knihovna noVNC byla vybrána pro pˇripojení pˇres VNC kvuli ˚ tomu, že je používána cloudovým softwarem OpenNebula, respektive jeho modulem OpenNebula Sunstone, který pˇredstavuje grafické rozhraní pro správu cloudové infrastruktury. Postup konfigurace modulu Sunstone a instalace noVNC klienta spoleˇcnˇe s VNC proxy, která pˇrekládá mezi obvyklou sít’ovou komunikací a komunikací protokolem WebSocket, je popsána v dokumentaci projektu OpenNebula. Celé toto nastavení bylo již provedeno a výsledné pˇripojení používáno právˇe pˇres grafické rozhraní cloudu.

4.3

WebSocket

Protokolem, kterým jsou vedena data pˇredstavující komunikaci VNC po síti internet, je WebSocket protokol [4]. Byl navržen pro oboustrannou komunikaci mezi klientem a serverem pomocí jedné linky v prostˇredí webového prohlížeˇce. Tento protokol je navržen tak, aby fungoval na stávajících HTTP portech 80 a 443, není na nˇe však vázán. Spojení je vytvoˇreno, tak, že bˇehem navazování spojení je požádáno o upgrade protokolu HTTP na protokol WebSocket.

4.4

Služba pro poskytování údaju˚ pro VNC pˇripojení

Jak již bylo zmínˇeno, pˇripojení pomocí VNC není vedeno pˇres rˇ ídicí uzly sandboxu. Namísto toho je realizováno pˇrímo pˇres poskytovatele cloudových prostˇredku˚ jímž je sdružení CESNET. To poskytuje výpoˇcetní infrastrukturu nazva24

4. P OUŽITÉ TECHNOLOGIE A SLUŽBY nou MetaCentrum2 , která pˇredstavuje cˇ eskou národní gridovou infrastrukturu. Poskytovaná RESTová služba je rˇ ešena jako cˇ ást knihovny pro interakci s cloudem. Adresa tohoto volání má následující strukturu: <server>:5000/scenario/sandbox/host//getVNC

Serverem, na kterém tato služba momentálnˇe bˇeží pro úˇcely vývoje, je kypodevel.ics.muni.cz. Jedineˇcným názvem koncového stroje pak identifikujeme virtuální poˇcítaˇc, pro který chceme poskytnout údaje pro pˇripojení. Tento údaj získáme z vizualizace topologie jako parametr name objektu pˇredstavující uzel v topologii. Jméno je zobrazeno také v popisku pˇri umístˇení kurzoru nad uzel. Jako odpovˇed’ volání je vrácen objekt JSON: { "params" : { "sandboxName" : "název" }, "password" : "heslo", "call" : "getVNC", "token" : "h5obni4d1s21durf97sxxk", "message" : "HASH(0x1eb3440), 1" }

Ze získaného objektu nás zajímají dva údaje: atribut token pˇredstavující cloudovým softwarem náhodnˇe generovaný rˇ etˇezec znaku˚ a heslo, kterým je hodnota atributu password. Zatímco token je pro pˇripojení nezbytný, heslo nemusí být poskytnuto. V takovém pˇrípadˇe je vrácen rˇ etˇezec "null" a uživateli je pak heslo poskytnuto jinou cestou.

2.

http://www.metacentrum.cz/cs/

25

5 Implementace Vzdálený pˇrístup pomocí VNC je integrován pˇrímo do stávajícího portletu topologie. V této kapitole bude popsáno rozšíˇrení puvodní ˚ funkcionality, její pˇrevedení do podoby portletu, jeho editaˇcního módu a problémy, které se bˇehem tohoto procesu vyskytly.

5.1

Rozšiˇrování topologie

Puvodní ˚ funkcionalita topologie je pˇredstavována dvˇema hlavními skripty [6]. •

Prvním z nich je graph.js, který pˇredstavuje prototyp objektu vizualizace topologie. Kromˇe promˇenných obsahuje funkcionalitu zajišt’ující její vykreslení, animace, polohování nebo napˇríklad pˇriˇrazení fyzických rolí uzlum. ˚ Prototyp také obsahuje tzv. mock events – atributy, na nˇež bude navazována funkcionalita pro hlavní interakce uživatele s grafem topologie.

•

Skript init.js objekt grafu inicializuje z jeho prototypu. V tomto souboru je implementována funkcionalita hlavních událostí pˇredstavující interakce uživatele nad topologií a po události naˇctení okna $(window).load jsou pak nezbytné funkce na objekt grafu navázány.

Pˇri zakomponování vzdáleného pˇrístupu do tohoto portletu jsem se snažil o kompromis mezi množstvím zásahu˚ do puvodního ˚ projektu a zárovenˇ o dodržení urcˇ ité konzistence dosavadního kódu. Pro zpracování vlastní funkcionality byl pˇridán soubor init-remote.js, odkud je otevírána stránka knihovny noVNC obstarávající navázání vzdáleného pˇripojení. 5.1.1

graph.js

Do tohoto souboru byl pˇridán HTML kód pˇredstavující kontextové menu. Podobným zpusobem ˚ se zde napˇríklad skládá tooltip pro poskytnutí informací o urˇcitém uzlu, který se zobrazí pˇri události mouseover. Menu je pˇredstavováno elementem
, jemuž je pˇriˇrazena tˇrída connection-menu. Toto menu pak obsahuje elementy
oznaˇcené tˇrídou menu-item, které pˇredstavují tlacˇ ítka pro požadovaná pˇripojení. Tato tlaˇcítka jsou oznaˇcena atributem id jako 26

5. I MPLEMENTACE vnc-item, pˇrípadnˇe ssh-item. Menu je pˇridáváno do DOM pod element identifikovaný jako graph, který pˇredstavuje celou vizualizaci topologie, a ve výchozím stavu je skryto. Protože je implementováno jenom VNC pˇripojení, je položka pro SSH skryta. Dále byl k prototypu grafu pˇridán mock event endpointMenuOpen. Jeho navázání na událost click probíhá pˇri každém volání funkce update, tedy když se mˇení data grafu a celé grafické zobrazení topologie je znovu vytváˇreno. Dˇeje se tak pomocí následujícího kódu: svg.selectAll(".desktop, .server, .mobile") .on("click", graph.endpointMenuOpen);

Element <svg> obsahuje grafické objekty tvoˇrící topologii. Jeden druh identifikátoru˚ tˇríd, které jsou tˇemto objektum ˚ pˇriˇrazovány, pˇredstavuje fyzickou roli koncového bodu. V našem pˇrípadˇe poskytujeme možnost otevˇrení menu pro výbˇer vzdáleného pˇripojení pro fyzické role desktop, server a mobile. 5.1.2

init.js

Do tohoto souboru bylo nutné provést dva nepatrné zásahy. První funkcionalitou, kterou pˇridáváme do init.js, je zajištˇení skrývání našeho kontextového menu pˇri události click kdekoliv v oknˇe. O to se stará následující kód. $(window).click(function (event) { d3.select(".connection-menu") .style("opacity", 0); });

Dále je v tomto skriptu zajištˇeno navázání funkcionality pro otevˇrení kontextového menu na mock event endpointMenuOpen. To se dˇeje voláním funkce a pˇredáním parametru pˇredstavujícího graf: endpointMenuOpen(graph). Tato funkce je obsažena ve skriptu init-remote.js. 5.1.3

init-remote.js

Tento skript je zcela nový a obsahuje dvˇe funkce. První z nich je již výše zmínˇená funkce endpointMenuOpen(graph). Následující kód pˇredstavuje právˇe navázání na mock event objektu grafu: graph.endpointMenuOpen = function(d){...}. Protože stisknutí tlaˇcítka myši muže ˚ znamenat kromˇe otevˇrení menu také pocˇ átek události drag, je tˇreba v této funkci nejprve ošetˇrit tento pˇrípad. Dále je zde 27

5. I MPLEMENTACE

Obrázek 5.1: Topologie s otevˇreným menu pro pˇripojení implementováno zvýraznˇení pˇri pˇresunu kurzoru nad položkou menu. Protože je v souˇcasné dobˇe používáno jenom VNC pˇripojení, je tato událost navázána pouze na tuto položku. Samozˇrejmou cˇ ástí je samotné zobrazení kontextové nabídky. Je zde použit grafický efekt pˇrechodu trvající 500 milisekund, podobnˇe jako pˇri zobrazování informací o uzlu v tooltipu. graph.connectionMenu.transition() .delay(0) .duration(500) .style("opacity", 1);

Kromˇe toho zde musíme zajistit vyvolání požadované funkcionality na jednotlivých položkách menu. V našem pˇrípadˇe se jedná o funkci openVNC(d), parametr d zde pˇredstavuje objekt, na kterém byla vyvolána událost click. Její implementace obsahuje získání potˇrebných údaju˚ pro pˇripojení, k cˇ emuž je použita již výše popsaná RESTová služba. Pokud se podaˇrí získat potˇrebné údaje, je z nich a nˇekolika dalších konstant sestaven query string, jehož pomocí jsou pˇredány potˇrebné parametry souboru vnc.html pˇri jeho otevírání v nové záložce webového prohlížeˇce. Konstantami jsou host, pˇredstavující název cílového poˇcítaˇce, port, který je použit pro pˇripojení, a parametr encrypt, kterým urˇcíme, že chceme navázat zabezpeˇcené pˇripojení. 28

5. I MPLEMENTACE 5.1.4

vnc.html

Tento HTML soubor je použit pˇrímo z knihovny noVNC. V této podobˇe je také používán grafickým uživatelským rozhraním OpenNebula Sunstone. Zachování stejného grafického prostˇredí proto muže ˚ pˇredstavovat výhodu pro uživatele, kteˇrí VNC pˇrístup používali pˇres grafické rozhraní cloudového softwaru. Tento soubor obsahuje také JavaScript kód, který naˇcte potˇrebné skripty a další soubory obsažené v knihovnˇe noVNC, jejichž pomocí jsou zpracovány pˇredávané parametry. Pokud nebylo posláno heslo, je pro jeho ruˇcní vložení vykresleno vstupní textové pole. Následnˇe je navázáno pˇripojení ke vzdálené ploše.

Obrázek 5.2: Vstup pro ruˇcní zadání hesla

5.2

Tvorba portletu

Obsah portletu je možné vyvíjet stejnˇe jako webovou stránku zpracovávanou pouze internetovým prohlížeˇcem uživatele, která neobsahuje serverovou cˇ ást. V tomto pˇrípadˇe nedochází k žádné kompilaci kódu a pro vývoj postaˇcí i obyˇcejný textový editor. Výstupem, který reprezentuje portlet, je však soubor archivu webové aplikace s pˇríponou war. Abychom vytvoˇrili portlet, který je možno integrovat do portálu, je nutné použít sofistikovanˇejšího vývojového prostˇredí. Liferay nabízí integrované vývojáˇrské prostˇredí Eclipse se zakomponovanými nástroji pro vývoj portletu. ˚ Pro vývoj portletu je dále nutné do tohoto vývojového prostˇredí doplnit Liferay Plugins SDK a pˇripojit instanci lokálnˇe nainstalovaného portálu. Ten je možné stáhnout pˇrímo v balíku s aplikaˇcním serverem Tomcat. Je však možné použít i jiná obvyklá vývojová prostˇredí pro programovací jazyk Java, napˇríklad NetBeans. Aby požadovaná funkcionalita pracovala i mimo prostˇredí portálu, jsou pro tento vývojový mód ve zdrojovém kódu provedeny urˇcité úpravy. To, jestli je kód provádˇen zakomponován v portletu nasazeném v portálu Liferay, se urˇcuje podmínkou 29

5. I MPLEMENTACE if (typeof Liferay != "undefined")

Portlet topologie je pˇri nasazení v portále navázán na takzvané Liferay events. Závisí také na portletu Time Manager, ze kterého topologie získává napˇríklad IP adresu sandboxu a který musí být umístˇen na stejné stránce. Pokud se nacházíme ve vývojovém módu mimo portál, musíme toto obcházet pomocí výše uvedené podmínky a musíme ruˇcnˇe deklarovat nˇekteré údaje a vyvolávat inicializaˇcní události. 5.2.1

Struktura portletu

Struktura projektu portletu je však složitˇejší oproti struktuˇre, v jaké byla puvodní ˚ topologie uložena v repozitáˇri projektu KYPO a bylo ji nutno do potˇrebné podoby pˇrevést a rozšíˇrit. V pozdˇejší cˇ ásti vývoje bylo rozhodnuto o použití jednotného frameworku Spring MVC pro všechny vyvíjené portlety projektu KYPO. V této sekci bude proto popsána právˇe tato výsledná podoba projektu. Aplikace portletu je sestavována pomocí nástroje Maven podle konfiguraˇcního souboru pom.xml. Zde je pˇridána závislost na rodiˇcovském projektu kypoParent. Ten zajistí jednotnou deklaraci závislostí pro ostatní portlety projektu KYPO. Tˇemi jsou napˇríklad knihovny pro použití portálu Liferay, podporu testování a logování událostí a také knihovny pro frameworku Spring. 5.2.2

Webové stránky

Základní soubory pˇredstavující klientskou stranu jsou rozdˇeleny do složek css, html, images a js. Soubor main.css byl rozšíˇren o styly pro zobrazované kontextové menu. Mezi HTML soubory byl pˇridán dokument vnc.html z knihovny noVNC, zatímco zbytek této knihovny byl ponechán ve složce js. V té se dále nachází vlastní soubory JavaScriptu a knihovny tˇretích stran v podsložce lib. Zobrazovanou cˇ ást portletu však pˇredstavují soubory typu JavaServer Pages s pˇríponou jsp. Soubor view.jsp pˇredstavuje obsah elementu ze souboru graph.html1 . Kromˇe toho zde mohou být pˇridány direktivy taglib, které umožnují ˇ použití urˇcitých identifikátoru˚ v tomto souboru. Následující kód dovolí použití Alloy UI pro snadné vytváˇrení jednotných formuláˇru˚ v portálu. 1. Soubor graph.html byl ponechán ve struktuˇre projektu, pˇrestože není pˇrímo používán po sestavení portletu a jeho nasazení do portálu. Použít však muže ˚ být pro vývojové úˇcely, kdy chceme spouštˇet topologii mimo aplikaˇcní server.

30

5. I MPLEMENTACE <%@ taglib uri="http://liferay.com/tld/aui" prefix="aui" %>

Následující direktiva pˇredstavuje import tˇrídy PortletPreferences, pomocí které mužeme ˚ spravovat vlastní parametry pro daný portlet. <%@ page import= "javax.portlet.PortletPreferences" %>

Kód mezi znaky <% %> je interpretován jako programovací jazyk Java. Tímto kódem se tedy pokusíme o naˇctení parametru vncUrl. Pokud se v databázi nastavení takový parametr nenachází, je použita hodnota pˇredstavovaná druhým parametrem, v našem pˇrípadˇe serverem kypo-devel. String vncUrl = portletPreferences.getValue("vncUrl", "http://kypo-devel.ics.muni.cz");

V tagu <script> je pak deklarována globální promˇenná pro JavaScript a je jí pˇriˇrazena hodnota ze stejnojmenné promˇenné z kódu Java. Ta je pak dále používaná ve skriptu init-remote.js. Editace této promˇenné bude popsána v sekci níže. var vncUrl = "<%= vncUrl %>";

5.2.3

Konfigurace portletu Liferay

Struktura projektu portletu Liferay také obsahuje nˇekolik speciálních konfiguraˇcních souboru˚ 2 . Prvním z nich je topology-portlet.xml v podsložce context. Zde mu˚ žeme importovat ruzné ˚ zdroje pro daný portlet. Kromˇe jiného jsou zde do koˇrenového kontextu aplikace pˇridány controllers. Ty pˇredkládají k zobrazení cˇ ásti view webové aplikace pˇredstavované soubory JavaServer Pages.

Kromˇe standardních souboru˚ web.xml sloužícímu ke konfiguraci webového projektu MVC a souboru portlet.xml pro konfiguraci obecného portletu, jsou pˇridány konfigurace specifické pro portál Liferay. Soubor liferay-display.xml obsahuje název a kategorii, kterými bude tento portlet identifikován po nasazení v portálu. Do souboru liferay-portlet.xml je nutné pˇridat reference na používané knihovny JavaScript a soubory stylu. ˚ Ty jsou mimo portál deklarovány v tagu souboru graph.html. Protože je však do souboru view.jsp zkopírováno pouze tˇelo to2.

http://www.springbyexample.org/examples/contact-webapp-spring-config.html

31

5. I MPLEMENTACE hoto souboru, je nutné provést import právˇe ve zmínˇeném souboru. Pˇríklady takových referencí mohou vypadat následovnˇe. /css/main.css /js/lib/jquery-2.0.0.min.js /js/init-remote.js

5.2.4

Editaˇcní mód

Jedním z požadavku, ˚ které se objevily bˇehem vývoje, byla nutnost konfigurace promˇenné, která pˇredstavuje adresu, na které se nachází služba poskytující pˇrístupové údaje pro pˇripojení pˇres VNC. Jak již bylo zmínˇeno, portlet se nasazuje do portálu v podobˇe archivu webové aplikace. Zmˇena hodnoty promˇenné pˇrímo ve zdrojovém kódu je samozˇrejmˇe obtížná, zdlouhavá a vyžaduje opˇetovné sestavení a nasazení portletu do portálu. Proto je žádoucí poskytnout možnost zmˇeny této promˇenné pˇrímo v prostˇredí portálu Liferay3 . Za tímto úˇcelem byl pro portlet definován editaˇcní mód v souboru portlet.xml. <supports> <portlet-mode>VIEW <portlet-mode>EDIT

Podoba editaˇcního módu je definována v souboru edit.jsp. Po deklaraci potˇrebných tˇríd a knihoven tagu, ˚ je pomocí Alloy UI vytvoˇren jednoduchý formuláˇr pro konfiguraci obsahující textové pole a tlaˇcítka pro potvrzení a zrušení akce. Podobnˇe jako v souboru view.jsp je naˇctena promˇenná vncUrl z preferencí portletu. Dále následuje deklarace actionURL do promˇenné configurationURL následujícím kódem:

Ta je následnˇe použita v atributu action formuláˇre deklarovaného pomocí Alloy UI. " method="post">

Stisknutí tlaˇcítka pro potvrzení pak vyvolá požadavek o zpracování této akce. Ten je zpracován v controlleru TopologyEditController, který kromˇe metody stara3.

http://www.springbyexample.org/examples/contact-webapp-spring-config.html

32

5. I MPLEMENTACE

Obrázek 5.3: Pˇripojení k OS Android v prohlížeˇci Chrome jící se o zpracování požadavku o vykreslení anotovanou jako @RenderMapping, musí obsahovat i metodu pro zpracování oznaˇcenou anotací @ActionMapping. Pomocí následujícího kódu je pak z objektu ActionRequest získána promˇenná vncUrl a je uložena do databáze preferencí portletu. String vncUrl = request.getParameter("vncUrl"); PortletPreferences prefs = request.getPreferences(); if (vncUrl != null) { prefs.setValue("vncUrl", vncUrl); prefs.store(); }

5.3

Další aspekty vývoje

Výsledkem této implementace je funkˇcní rozšíˇrení puvodního ˚ portletu. Jisté omezení však pˇredstavují internetové prohlížeˇce. Za zmínku pak stojí i úprava nutná 33

5. I MPLEMENTACE

Obrázek 5.4: Pˇripojení ke vzdálenému terminálu pomocí noVNC pro správné zobrazení kurzoru. ˚ 5.3.1

Podpora prohlížeˇcu˚

Použití noVNC pro pˇripojení ke vzdálenému virtuálnímu stroji je nefunkˇcní pˇri použití prohlížeˇce Firefox4 . Tento problém není ojedinˇelý a i na samotném webu projektu noVNC je popsán. Pˇrestože se podaˇrilo tento problém v urˇcitém bodˇe vyˇrešit zvýšením hodnot parametru˚ network.websocket.timeout.close a network.websocket.timeout.open v nastavení prohlížeˇce, po jeho automatické aktualizaci se tento problém opˇet projevil. Bohužel výše zmínˇené rˇ ešení podruhé již nepomohlo a ani žádným jiným zpusobem ˚ jsem dosud nebyl schopen odstranit tento problém a zustává ˚ tak otevˇrený spoleˇcnˇe s pokraˇcujícím vývojem tohoto portletu. Druhým omezením je použití portletu v prohlížeˇci Internet Explorer, což je však zpusobeno ˚ tím, že tento prohlížeˇc není podporován portletem Time Manager, na nˇemž topologie závisí. Pˇri použití mimo portál je však pˇripojení VNC funkˇcní i pˇres tento prohlížeˇc. Plná funkˇcnost rozšíˇrené verze portletu topologie je tedy podporována prohlížeˇci Opera a Chrome. 5.3.2

Poloha kurzoru˚

Další záležitostí, se kterou bylo nutné se vypoˇrádat, byla rozdílná poloha vzdáleného a lokálního kurzoru. Jakmile se místní kurzor dostane mimo oblast zobrazované vzdálené plochy, která bývá obvykle menší než velikost místní obrazovky, pˇrestane se vzdálený kurzor pohybovat. Toto chování bylo pro uživatele velmi nepohodlné. 4. Chybová hláška má následující podobu: Firefox nemuže ˚ navázat spojení se serverem wss://cloud.metacentrum.cz:29876/websockify?token=6scdvxxxxx

34

5. I MPLEMENTACE Tento problém však má rˇ ešení. První možností je spuštˇení hypervisoru QEMU s atributem --usbdevice tablet. Druhým zpusobem ˚ je pˇridání INPUT = [TYPE=tablet, BUS=usb] jako parametru do šablony pro vytvoˇrení virtuálního stroje. Aplikace tˇechto úprav pak byla úspˇešnˇe provedena pracovníky zabývajícími se cloudovou cˇ ástí projektu.

35

6 Závˇer Cílem této práce byl pruzkum ˚ možných nástroju˚ pro vzdálený pˇrístup k virtuálním koncovým uzlum ˚ v testovacích prostˇredích projektu KYPO, které by se daly zakomponovat do webového portálu Liferay. Dvˇema druhy tˇechto nástroju˚ jsou vzdálené pˇrihlášení pˇres protokol SSH a pˇrístup ke vzdálené ploše pomocí technologie VNC. Praktickým cílem bylo rozšíˇrení stávajícího portletu topologie tak, aby bylo umožnˇeno interaktivní pˇripojení pomocí VNC k požadovanému uzlu zobrazenému v tomto portletu a to bez nutnosti ruˇcní konfigurace nebo použití jiných aplikací než webového prohlížeˇce. Pokud by bylo v budoucnu implementováno i pˇripojení protokolem SSH, je možné vybrat nˇekterý z nástroju˚ zmínˇených v pˇrehledové cˇ ásti této práce. Bˇehem vývoje jsem se potýkal napˇríklad se sporadicky nefunkˇcní službou pro poskytování údaju˚ pro pˇripojení VNC a musel jsem se pˇrizpusobovat ˚ mˇenícím se požadavkum ˚ bˇehem vývoje. Pˇresto však vˇerˇ ím, že tyto požadavky byly ve své koneˇcné podobˇe splnˇeny. Výsledné rozšíˇrení topologie je souˇcasné dobˇe nasazeno na vývojovém i demonstraˇcním prostˇredí projektu KYPO. Použití implementovaného VNC pˇripojení je souˇcástí nˇekolika bezpeˇcnostních scénáˇru˚ a bylo pˇredvádˇeno jako soucˇ ást možností Kybernetického polygonu. Mezi potencionální zákazníky patˇrí jak ˇ tak i firmy – státní instituce jako je Národní bezpeˇcnostní úˇrad nebo Policie CR, ˇ napˇríklad bezpeˇcnostní oddˇelení spoleˇcnosti CEZ. Vývoj portletu topologie není u konce a i další rˇ ešitelé v souˇcasnosti pracují na rozšiˇrování jeho funkcionality.

36

Literatura [1] Barrett, Daniel J; Silverman, Richard E: SSH, the Secure Shell: the definitive guide. O’Reilly Media, Inc., první vydání, 2001. ˇ [2] Cegan, Jakub; Velan, Petr; Jirsík, Tomáš; aj.: Návrh a vývoj prototypu Kybernetického polygonu - etapa I. Technická zpráva, Ústav výpoˇcetní techniky, Masarykova univerzita, 2013. ˇ [3] Celeda, Pavel; Velan, Petr; Jirsík, Tomáš; aj.: Projekt KYPO: Analýza a návrh architektury. Technická zpráva, Ústav výpoˇcetní techniky, Masarykova univerzita, Brno, 2013. [4] Fette, Ian; Melnikov, Alexey: The WebSocket Protocol. 2011, [online] [cit. 22.12.2014] Dostupné z: . [5] Kouˇril, Daniel; Lago, Dušan; Procházka, Michal; aj.: Projekt KYPO: Pˇríprava experimentálního prostˇredí v cloudu. Technická zpráva, Ústav výpoˇcetní techniky, Masarykova univerzita, Brno, 2013. [6] Luˇcanský, Andrej: Portlet for the Visualization of Network Topology. Diplomová práce, Masarykova univerzita, 2014. [7] Moreno-Vozmediano, Rafael; Montero, Rubén S.; Llorente, Ignacio M.: IaaS Cloud Architecture: From Virtualized Datacenters to Federated Cloud Infrastructures. Computer, roˇcník 45, cˇ . 12, 2012: s. 65–72, ISSN 0018-9162, [online] [cit. 12.12.2014] Dostupné z: . [8] Peterson, Larry L; Davie, Bruce S: Computer Networks ISE: A Systems Apˇ proach. San Francisco: Morgan Kaufmann Publishers Inc., Ctvrté vydání, 2007, ISBN 0123740134, 9780123740137. [9] Richardson, Tristan: The RFB Protocol, Version 3.8. 2010, [online] [cit. 22.12.2014] Dostupné z: . [10] Richardson, Tristan; Stafford-Fraser, Quentin; Wood, Kenneth R; aj.: Virtual network computing. IEEE Internet Computing, roˇcník 2, cˇ . 1, 1998: s. 33–38, 37

ˇ 6. Z ÁV ER

[online] [cit. 18.12.2014] Dostupné z:

stamp/stamp.jsp?tp=\&arnumber=656066> .

[11] Sempolinski, Peter; Thain, Douglas: A Comparison and Critique of Eucalyptus, OpenNebula and Nimbus. 2010 IEEE Second International Conference on Cloud Computing Technology and Science, 2010: s. 417–426, [online] [cit. 22.11.2014] Dostupné z: . [12] Sezov, Rich: Liferay in action. Manning Publications Co., 2012, ISBN 9781935182825. [13] Sosinsky, Barrie: Networking Bible. Wiley Publishing, první vydání, 2009, ISBN 9780470431313. [14] Tang, Wei; Lee, Jun-hyung; Song, Biao; aj.: Multi-Platform Mobile Thin Client Architecture in Cloud Environment. Procedia Environmental Sciences, roˇcník 11, 2011: s. 499–504, ISSN 18780296, [online] [cit. 5.12.2014] Dostupné z: . [15] Wikipedia: Web-based SSH. 2014, [Online] [cit. 26.11.2014] Dostupné z: .

38

A Obsah elektronické pˇrílohy Pˇríloha pˇredstavující praktický výsledek této práce se nachází v informaˇcním systému Masarykovy univerzity. Archiv vnc-attachments.zip obsahuje dva adresáˇre: •

deploy - obsahuje soubor war, který muže ˚ být nasazen do portálu Liferay

•

src - obsahuje zdrojové soubory projektu

39

B Obrazové pˇrílohy Struktura projektu ve vývojovém prostˇredí

40

ˇ B. O BRAZOVÉ P RÍLOHY

Pˇrístup ke vzdálené ploše OS Linux

41

Připojení na stroje v sandboxech projektu Kypo

Recommend Documents