}w !"#$%&'()+,-./012345
M ASARYKOVA UNIVERZITA FAKULTA INFORMATIKY
Generátor základních filtrovacích pravidel pro konfiguraci firewallu˚ na sít’ových zaˇrízeních ˇ B AKALÁ RSKÁ PRÁCE
Jan Vyhnánek
Brno, jaro 2013
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.
Jan Vyhnánek
Vedoucí práce: RNDr. Martin Jakubiˇcka ii
Podˇekování Dˇekuji vedoucímu mé práce, RNDr. Martinu Jakubiˇckovi, za ochotu a rady, které mi bˇehem zpracovávání této bakaláˇrské práce poskytl.
iii
Shrnutí Cílem této bakaláˇrské práce je vytvoˇrit mobilní aplikaci pro platformu Android, která zaprvé generuje základní filtrovací pravidla pro firewally sít’ových zaˇrízení a zadruhé uskuteˇcnuje ˇ samotné pˇripojení k takovému zaˇrízení. Práce se skládá ze tˇrí hlavních celku, ˚ kterými jsou analýza, návrh a implementace a její výstup je k dispozici na internetovém obchodˇe Google Play pod názvem Firewall Builder.
iv
Klíˇcová slova Android, firewall, access control list, iptables, RouterOS, filtrovací pravidla
v
Obsah 1 2
3
4
Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Analýza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1 Využití aplikace . . . . . . . . . . . . . . . . . . . . . . . 2.2 Popis technologií užívajících k filtrování paketu˚ pravidla 2.2.1 ACL syntaxe . . . . . . . . . . . . . . . . . . . . . 2.2.2 IPtables syntaxe . . . . . . . . . . . . . . . . . . . 2.2.3 RouterOS syntaxe . . . . . . . . . . . . . . . . . . 2.2.4 Pˇríklady k jednotlivým syntaxím . . . . . . . . . 2.3 Popis existujících rˇ ešení . . . . . . . . . . . . . . . . . . Návrh . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.1 Omezení aplikace . . . . . . . . . . . . . . . . . . . . . . 3.1.1 Vynechané parametry ACL . . . . . . . . . . . . 3.1.2 Vynechané parametry iptables . . . . . . . . . . 3.1.3 Vynechané parametry RouterOS . . . . . . . . . 3.1.4 Další omezení . . . . . . . . . . . . . . . . . . . . 3.2 Navržené syntaxe . . . . . . . . . . . . . . . . . . . . . . 3.2.1 Navržená syntaxe ACL . . . . . . . . . . . . . . 3.2.2 Navržená syntaxe iptables . . . . . . . . . . . . . 3.2.3 Navržená syntaxe RouterOS . . . . . . . . . . . 3.3 Výbˇer SSH klienta . . . . . . . . . . . . . . . . . . . . . . 3.3.1 Integrace ConnectBotu . . . . . . . . . . . . . . . 3.4 Proˇc programovat v Androidu . . . . . . . . . . . . . . 3.5 Architektura . . . . . . . . . . . . . . . . . . . . . . . . . 3.6 User-friendly aplikace . . . . . . . . . . . . . . . . . . . Implementace . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.1 Popis firewallu . . . . . . . . . . . . . . . . . . . . . . . . 4.1.1 Cisco IOS firewall – access control lists . . . . . 4.1.2 IPtables . . . . . . . . . . . . . . . . . . . . . . . 4.1.3 MikroTik – RouterOS . . . . . . . . . . . . . . . . 4.2 Android a struktura aplikací na této platformˇe . . . . . 4.3 Vývoj aplikace . . . . . . . . . . . . . . . . . . . . . . . . 4.3.1 Pˇrizpusobení ˚ pro ruzné ˚ displeje . . . . . . . . . 4.3.2 Struktura jednotlivých aktivit . . . . . . . . . . . 4.3.3 Publikace na Google Play . . . . . . . . . . . . . 4.4 Problémy bˇehem vývoje . . . . . . . . . . . . . . . . . .
1 4 4 6 6 7 8 8 9 11 11 11 12 12 13 13 14 14 15 15 16 17 18 20 22 22 22 23 23 23 26 26 29 35 36 vi
5 6 7
Závˇer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 Pˇríloha . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 Seznam použitých zdroju˚ . . . . . . . . . . . . . . . . . . . . 41
vii
1 Úvod V posledních letech se stále více rozvíjí oblast informaˇcních technologií (dále IT) a to pˇredevším poˇcítaˇcové sítˇe. Bez Internetu si dnes témˇerˇ nikdo nedokáže své fungování pˇredstavit, je na nˇem závislých nespoˇcet organizací od dopravy, pˇres bankovnictví, až po bezpeˇcnost. S rozvojem IT se také cˇ ím dál více rozšiˇruje poˇcítaˇcová kriminalita, hackeˇri blokují webové stránky duležitých ˚ organizací, napadají servery a zaˇrízení. V dnešní dobˇe existuje velké množství typu˚ poˇcítaˇcových útoku˚ a nejruznˇ ˚ ejších softwaru, ˚ které k tˇemto útokum ˚ napomáhají. Aˇckoliv je téma poˇcítaˇcové kriminality velmi aktuální a je stále cˇ astˇeji rˇ ešeno v nejruznˇ ˚ ejších médiích, mnoho lidí stále netuší, jak se proti ní bránit. Klíˇcovým ochranným prvkem každého poˇcítaˇce cˇ i sít’ového zaˇrízení je firewall1 , který pˇri správné konfiguraci dokáže odrazit vˇetšinu pˇricházejících útoku˚ a viru. ˚ Firewally pro eliminaci hrozeb filtrují pˇríchozí i odchozí pakety. Existuje mnoho technik filtrování paketu˚ od zónových firewallu˚ až po filtrovací pravidla. V této práci se ovšem zamˇerˇ ujeme pouze na druhou zmínˇenou techniku. V oblasti filtrování paketu˚ za pomoci filtrovacích pravidel existují tˇri poskytovatelé. Nejvˇetším z nich je firma Cisco následovaná Linuxem a MikroTikem. Bližší informace o filtrovacích pravidlech je možné v pˇrípadˇe spoleˇcnosti Cisco nalézt v knižních dílech CCNA Security Official Exam Certification Guide [1] a Cisco ASA: All-in-One Firewall, IPS, and VPN Adaptive Security Appliance [2] a na webové stránce Cisco Networking Academy [3]. V ostatních pˇrípadech vystaˇcíme s Internetem, kde nalezneme jak linuxový manuál [4], který nám poskytuje detailnˇejší pochopení Linuxu a jeho tvorby pravidel, tak i dokumentaci od MikroTiku [5]. Cílem této bakaláˇrské práce je vytvoˇrit generátor základních filtrovacích pravidel pro konfiguraci firewallu˚ na sít’ových zaˇrízeních pro mobilní platformu Android. V dnešní dobˇe je viditelný výrazný vzestup telefonu, ˚ které jsou oznaˇcovány pˇrízviskem chytrý. Tyto telefony podporují nejruznˇ ˚ ejší platformy, pˇriˇcemž mezi nejznámˇejší 1
Prvek korigující tok dat mezi poˇcítaˇcovými sítˇemi.
1
1. Ú VOD patˇrí operaˇcní systémy Android a iOS, z nichž nejpoužívanˇejší je právˇe první zminovaný ˇ [6]. Vyvíjený software dle uživatelem zadaných parametru˚ generuje základní filtrovací pravidla pro daný firewall a je vhodný jak pro bˇežného, tak i pro odborného uživatele, pˇrípadnˇe jej mohou využít i firmy zabývající se problematikou pocˇ ítaˇcových sítí. Jako pomocník pˇri implementaci poslouží publikace Android 2 [7]. Aplikace je dále schopná pˇripojit se k sít’ovému zarˇ ízení pomocí SSH (secure shell) protokolu a dokáže do nˇej vložit vygenerovaná pravidla. K vytvoˇrení požadovaného výstupu bylo zapotˇrebí problém nejdˇríve analyzovat, následnˇe navrhnout a implementovat samotné rˇ ešení. V první cˇ ásti práce jsou vybrány dostupné technologie, které jsou poté v návrhové cˇ ásti vymezeny tak, aby generovaly pouze základní filtrovací pravidla. Pˇri návrhu je použito UML (Unified modeling language), tj. diagramy pro zachycení chování a struktury programu. Jako vývojové prostˇredí je vybráno prostˇredí Eclipse, které oficiálnˇe nabízí modul pro vývojáˇre programující na platformˇe Android a programovacím jazykem je objektový jazyk Java. Aplikace tedy poskytuje plnohodnotný generátor bázových filtrovacích pravidel, který napomáhá k ochranˇe sítˇe spravované pod daným smˇerovaˇcem cˇ i poˇcítaˇcem. Je zdarma ke stažení na internetovém obchodˇe Google Play, což umožnuje ˇ interakci s uživateli a tím pádem i ruzné ˚ modifikace a opravy podle jejich zpˇetné vazby. Tento program by mohl být do budoucna rozšíˇren ve dvou smˇerech. Zaprvé se jedná o samotnou funkˇcnost a vzhled. Jak bylo rˇ eˇceno, v tomto stavu jsou vytváˇrena pouze základní filtrovací pravidla, což vˇetšinˇe uživatelu, ˚ hlavnˇe tˇem bˇežným, postaˇcí. Ovšem v pˇrípadˇe sít’ového experta by bylo potˇreba pˇridat chybˇející parametry a umožnit tak uživateli úplnou svobodu pˇri konfiguraci jeho zaˇrízení. Jelikož je grafická stránka rˇ ešena pouze za pomoci dostupných Android komponent, byla by možnost i pro grafika tuto aplikaci vylepšit. Zadruhé, v pˇrípadˇe úspˇechu a velké odezvy uživatelu˚ by byla vhodná implementace na další platformy, která by pˇrispˇela k získání nových potenciálních uživatelu. ˚
2
1. Ú VOD Práce se skládá ze tˇrí cˇ ástí – analýza, návrh a implementace. V první z nich vysvˇetlujeme, pro koho je software urˇcen, analyzujeme dostupné technologie pro filtrování paketu˚ a hledáme již existující rˇ ešení. V druhé cˇ ásti definujeme, na základˇe jakých parametru˚ software omezuje provoz na síti, vybíráme SSH klienta, uvádíme du˚ vody výbˇeru platformy Android, pˇribližujeme komunikaci tˇríd a navrhujeme prvky uživatelsky pˇrívˇetivého rozhraní. V závˇeru popisujeme firewall, strukturu Android aplikací, samotnou implementaci celého programu a problémy, které se bˇehem vývoje objevily.
3
2 Analýza Prvním krokem pˇri zpracování této bakaláˇrské práce je analyzování její problematiky. To znamená, že definujeme cílovou skupinu uživatelu, ˚ zjistíme, jaká je souˇcasná situace na trhu mobilních aplikací, jaké technologie pro filtrování paketu˚ existují a blíže se podíváme na existující rˇ ešení.
2.1 Využití aplikace Vyvíjená aplikace je orientována na dvˇe cílové skupiny. První z nich je reprezentována osobami, které se nastavováním filtrovacích pravidel firewallu˚ živí. Nazývejme tyto lidi tzv. sít’ovými techniky. Druhá skupina je tvoˇrena všemi ostatními osobami, které vlastní nˇejaké sít’ové zaˇrízení s nastavitelným firewallem. Tˇem nadále rˇ íkejme bˇežní uživatelé. Tím jsme definovali, kdo aplikaci bude používat. Nyní je duležité ˚ kdy. Skoro každá firma, byt’ sebemenší, má v dnešní dobˇe vlastní firemní sít’, kde schranuje ˇ nejruznˇ ˚ ejší citlivá data. At’ už jde o data ekonomická, o zákaznících, zamˇestnancích cˇ i jiná. Tato data musí být zabezpeˇcena proti neautorizovanému pˇrístupu, protože i sebemenší únik dat by mohl mít za následek zniˇcení dobré povˇesti firmy a tím ji pˇripravit o zákazníky. S tím je také spojena ztráta zisku, což se stalo napˇríklad spoleˇcnosti Sony [8][9]. V horším pˇrípadˇe muže ˚ dojít i ke zkrachování firmy. Pro úˇcely zabezpeˇcení a správy sítˇe si vˇetšina firem najímá sít’ové techniky a právˇe v tuto chvíli muže ˚ být aplikace využita. Sít’ový technik se nemuže ˚ spoléhat na to, že zákazník bude mít na svém poˇcítaˇci nainstalován software, který by mu ulehˇcil práci pˇri vytváˇrení filtrovacích pravidel firewallu, a jelikož je množství filtrovacích pravidel a možností jejich syntaxe obrovské, je témˇerˇ nemožné je všechny znát. Zárovenˇ je neprofesionální chtít po zákazníkovi, aby se dopˇredu na návštˇevu sít’ového technika pˇripravoval provedením instalace ruznorodých ˚ softwaru. ˚ Sít’ový technik si tedy do svého chytrého telefonu nainstaluje aplikaci, cˇ ímž se zbaví závislosti na dostupných zdrojích u zákazníka a sám nemusí 4
2. A NALÝZA nosit nadbyteˇcný poˇcítaˇc cˇ i notebook, na kterém má sofistikovaný software nainstalovaný. Jediné, co mu k vykonání práce staˇcí, je jeho mobilní telefon, který na základˇe vložených dat vygeneruje požadovaná filtrovací pravidla firewallu pro dané sít’ové zaˇrízení. Co se týká bˇežného uživatele, ten aplikaci muže ˚ využít na nastaˇ si nakonfiguruje vení firewallu na vlastním sít’ovém zaˇrízení. Cili domácí sít’ pˇresnˇe podle svých potˇreb, k cˇ emuž mu napomuže ˚ podrobná nápovˇeda aplikace urˇcená pˇredevším pro takového uživatele. To, co je pro bˇežného uživatele pˇrínosem u této aplikace na rozdíl od podobného softwaru pro stolní poˇcítaˇce a notebooky, je redukce znaˇcného množství parametru, ˚ které jsou ve velké vˇetšinˇe pˇrípadu˚ stejnˇe nevyužity. Tím se celý software stává pˇrehlednˇejší a srozumitelnˇejší pro uživatele. Jelikož je tato aplikace s nejvˇetší pravdˇepodobností jediná svého druhu, pokud bereme v potaz pouze mobilní platformy a aplikace na nˇe vyvíjené, a je urˇcena jak pro odborníky, tak pro neznalé uživatele, je potenciál jejího budoucího používání vysoký.
Obrázek 2.1: Diagram pˇrípadu˚ užití
5
2. A NALÝZA
2.2 Popis technologií užívajících k filtrování paketu˚ pravidla Na dnešním trhu se nachází celá rˇ ada nejruznˇ ˚ ejších typu˚ sít’ových zaˇrízení podporujících specifické technologie pro rˇ ízení provozu sítˇe, tedy pro filtrování paketu, ˚ avšak pouze tˇri z tˇechto technologií umožnují ˇ blokovat cˇ i propouštˇet pakety pomocí filtrovacích pravidel, která jsou pˇredmˇetem této bakaláˇrské práce. Mezi tyto technologie patˇrí Access Control List (ACL) od spoleˇcnosti Cisco, linuxové iptables a RouterOS od spoleˇcnosti MikroTik. Tyto technologie se vzájemnˇe liší pˇredevším v syntaxi pravidel, v názvech jednotlivých atributu˚ a v cenˇe, která je u Linuxu nejnižší a u ACL nejvyšší, a naopak se ve vˇetšinˇe pˇrípadu˚ shodují v poskytované funkcionalitˇe. 2.2.1 ACL syntaxe ACL se dˇelí na tˇri základní typy a to na standard (standardní), extended (rozšíˇrený) a named (jmenný), z nichž se každý liší svojí syntaxí. Syntaxe standard ACL je následující: access-list cˇ íslo_listu {permit|deny} zdrojová_adresa zdrojová_maska ˇ Císlo listu nabývá hodnot od 1 do 99 nebo od 1300 do 1999 a znaˇcí cˇ íslo ACL. Druhý parametr definuje, jak bude s pakety zacházeno. Bud’ budou propuštˇeny, anebo zahozeny. Pˇredposlední údaj je IP adresa zdrojového sít’ového zaˇrízení, která muže ˚ být pouze v podobˇe IPv4. Posledním parametrem je zdrojová maska, která stejnˇe jako zdrojová adresa muže ˚ mít syntaxi pouze IPv4. Rozšiˇrující verzí standard ACL je extended ACL, který má tuto syntaxi: access-list cˇ íslo_listu [dynamic dynamické_jméno [timeout minuty]] {deny|permit} protokol zdrojová_adresa zdrojová_maska cílová_adresa cílová_maska [precedence precedens] [tos tos] [log|log-input] [time-range název_ˇcasového_rozsahu] Je evidentní, že extended ACL ze standard ACL vychází a doplnuje ˇ ho o mnoho dalších parametru. ˚ Pˇresto je nutné nˇekteré parametry znovu zmínit, jelikož se liší v množinˇe akceptovatelných hodnot. 6
2. A NALÝZA Na rozdíl od standard ACL je u extended ACL cˇ íslo listu v rozsahu od 100 do 199 nebo od 2000 do 2699 a zdrojová adresa a maska mohou být jak ve tvaru IPv4, tak i IPv6. Cílová adresa a maska mají stejný formát jako údaje pro zdroj, avšak týkají se cílového zaˇrízení. Jako poslední parametr je možno zmínit log, který zaznamenává veškeré události do systémového logu. Zbylé parametry není potˇreba definovat, jelikož nadále nebudou využity. Uvedená syntaxe extended ACL není ani zdaleka úplná, ale pro pochopení funkcionality je dostaˇcující. Posledním typem ACL je named ACL. Named ACL navazuje na své dva pˇredchudce ˚ a umožnuje ˇ ACL pojmenovávat libovolnými jmény, které usnadnují ˇ jeho zapamatování. Syntaxe je následující: ip access-list {standard|extended} jméno [ˇcíslo_ˇrádku] {permit|deny} . . . Hlavní rozdíl oproti pˇredchozím ACLs je v tom, že se filtrovací pravidlo skládá ze dvou pˇríkazu. ˚ V prvním se definuje typ ACL a jeho jméno, druhý pak následuje syntaxi zvoleného typu ACL s tím rozdílem, že je možno na zaˇcátek pˇridat cˇ íslo rˇ ádku, což umožnuje ˇ daná pravidla mazat a vkládat na urˇcité pozice. Druhou odlišností je, že se zcela vynechává cˇ íselné oznaˇcení listu. [1][2][10][11][12][13] 2.2.2 IPtables syntaxe „IPtables je mocný nástroj, který umožnuje ˇ linuxovému nebo unixovému systému plnˇe pracovat se sít’ovou komunikací“ [14]. Na rozdíl od ACL a RouterOS se zde filtrovací pravidla nenastavují na daném smˇerovaˇci, ale pˇrímo na stroji s nainstalovaným operaˇcním systémem Linux. Základní syntaxe vypadá následovnˇe: iptables [tabulka] [akce] [ˇretˇezec] [ip_ˇcást] [match] [cíl] [cíl_informace] Parametr tabulka definuje, jakým smˇerem jsou pˇrenášeny pakety – tedy jestli do sítˇe, nebo pryˇc z ní. Akce rˇ íká, jakou cˇ innost chceme provádˇet, od pˇridávání až po mazání pravidel. Nejduležitˇ ˚ ejším parametrem je rˇ etˇezec, protože obsahuje vˇetšinu filtrovacích podmínek 7
2. A NALÝZA založených na podobném principu jako u ACL. Poslední parametr, který zmíníme, je cíl, jenž definuje, jestli budou pakety zahozeny cˇ i propuštˇeny. [4][14][15][16] 2.2.3 RouterOS syntaxe Jelikož je syntaxe podobná syntaxi iptables, bude staˇcit nastínit, jak tato syntaxe zaˇcíná: add [ˇretˇezec] [akce] . . . ˇ ezec zde definuje obal filtrovacích pravidel, akce a ostatní paRetˇ rametry jsou bud’ ekvivalentní, anebo velmi podobné parametrum ˚ u iptables. [5][17] Vyjma standard ACL všechny zmínˇené technologie podporují kromˇe klasické IPv4 také IPv6, která se ve svˇetˇe IT zaˇcíná stále více rozmáhat. Aplikace tedy bude zamˇerˇ ena na tyto tˇri technologie a v pˇrípadˇe, že se na trhu objeví nová, je možné ji implementovat. 2.2.4 Pˇríklady k jednotlivým syntaxím Pro získání lepší pˇredstavy o tom, jak vypadají reálná filtrovací pravidla, budou v této sekci uvedeny k výše zmínˇeným syntaxím vždy jedna cˇ i dvˇe ukázky, jejichž funkcionalita bude následnˇe vysvˇetlena. 2.2.4.1 Standard ACL ukázka access-list 83 permit 192.89.1.10 access-list 36 deny 192.63.2.1 První pˇríkaz povolí pakety ze zdrojové adresy 192.89.1.10, zatím co druhý naopak pakety ze zdrojové adresy 192.63.2.1 zakáže.
8
2. A NALÝZA 2.2.4.2 Extended ACL ukázka access-list 154 permit udp 63.5.12.0 0.0.0.255 any eq 80 Tento pˇríkaz povolí zaˇrízením ze sítˇe s adresou 63.5.12.0/24 pˇrístup k portu 80 na cílovém hostu, což je služba http. 2.2.4.3 IPtables ukázka iptables -A INPUT -p TCP -i eth0 -s 192.168.1.8 --dport 80 Tento pˇríkaz do tabulky INPUT pˇridá pravidlo, kterému odpovídají všechny pakety, které jsou pˇrijaty sít’ovou kartou eth0, mají zdrojovou IP adresu 192.168.1.8, pˇríjemce je libovolný a cílový TCP port je 80, tedy HTTP. 2.2.4.4 RouterOS ukázka add chain=forward action=accept protocol=dhcp in-interface=ether2 Tímto pravidlem jsou povoleny všechny pakety DHCP protokolu procházející rozhraním ether2.
2.3 Popis existujících rˇešení Cílem této bakaláˇrské práce je vytvoˇrit aplikaci pro mobilní telefony, a proto bylo první vyhledávání existujících rˇ ešení smˇerˇ ováno právˇe na nˇe. V souˇcasnosti je trh pˇredevším rozdˇelen mezi dva technologické giganty, kterými jsou Apple a Google. Tyto dvˇe spoleˇcnosti poskytují svým zákazníkum ˚ internetové obchody, odkud lze získat aplikace volnˇe ke stažení cˇ i placené, a jelikož jsou tyto obchody oficiálními úložišti pro mobilní aplikace, bylo prvotní hledání provedeno zde. Z duvodu ˚ velké specifiˇcnosti celé aplikace bylo hledání podobných aplikací problematické. Po zadání všech klíˇcových slov, která jistým zpusobem ˚ souvisí s tématem této bakaláˇrské práce, do vyhledávaˇcu˚ výše zmínˇených obchodu˚ bylo dosaženo závˇeru, že ani 9
2. A NALÝZA pro iOS od spoleˇcnosti Apple ani pro Android od spoleˇcnosti Google prozatím neexistuje mobilní aplikace umožnující ˇ vytváˇret filtrovací pravidla a aplikovat je na daném sít’ovém zaˇrízení. Kvuli ˚ absenci podobné aplikace na mobilních zaˇrízeních bylo další hledání zamˇerˇ eno na aplikace pro stolní poˇcítaˇce a notebooky. Zde již bylo hledání úspˇešné. Existuje celá rˇ ada poˇcítaˇcových programu˚ pro konfiguraci firewallu. ˚ Pro porovnání se zde vyvíjenou aplikací byl zvolen pouze jeden program a to zdarma dostupný Firewall Builder. Na zaˇcátek je nutné rˇ íci, že Firewall Builder je mnohem komplexnˇejší aplikace než software, který bude výstupem této bakaláˇrské práce. Dokáže pracovat nejenom s technologiemi podporujícími filtrovací pravidla, ale i s mnoha dalšími, které ovšem nebudou pˇredmˇetem dalšího porovnávání. První a nejduležitˇ ˚ ejší porovnávací kritérium je, jestli daná aplikace podporuje všechny existující technologie fungující na bázi filtrovacích pravidel. Již zde se obˇe aplikace liší, protože Firewall Builder nepodporuje RouterOS od MikroTiku. Na druhou stranu je nutné podotknout, že Firewall Builder u zbylých dvou technologií umožnuje ˇ nakonfigurovat všechny existující filtrovací parametry. Obˇe aplikace umí jak validovat a generovat filtrovací pravidla, tak je následnˇe aplikovat na sít’ovém zaˇrízení. Za zmínku navíc stojí i samotná velikost programu, ˚ která je v pˇrípadˇe Firewall Builderu šedesátkrát vˇetší. [18] Závˇerem lze dodat, že obˇe aplikace si jsou v poskytované funkcionalitˇe velmi podobné. Porovnávat je na jiné úrovni, jako je tˇreba GUI (graphical user interface) a další, není vhodné a to z duvodu ˚ implementace na zcela rozdílná zaˇrízení a vývoje v odlišných prostˇredích.
10
3 Návrh Jelikož jsme analyzovali vše potˇrebné, mužeme ˚ se nyní pˇresunout k návrhu softwaru. V této cˇ ásti nejdˇríve definujeme globální omezení softwaru a vlastní syntaxe. Dále vybereme vhodného SSH klienta, zduvodníme ˚ výbˇer platformy Android a navrhneme architekturu projektu aplikace a uživatelsky pˇrívˇetivé prvky.
3.1 Omezení aplikace Pˇri návrhu aplikace bylo nutné vzít v potaz, že výstupem má být generátor základních filtrovacích pravidel, a tudíž není potˇreba implementovat všechny filtrovací parametry jednotlivých technologií. Dalším duvodem ˚ k tomuto kroku je i fakt, že vˇetšina atributu˚ není pˇri filtrování použita. Cílem tedy bylo odebrat takové cˇ ásti z filtrovacích pravidel, které by uživatel postrádal co nejménˇe a vystaˇcil si s tím, co rozhraní nabízí. Níže vždy uvedeme pro každý zpusob ˚ propouštˇení paketu˚ funkci nˇekolika parametru, ˚ které byly eliminovány, avšak stojí za zmínku. 3.1.1 Vynechané parametry ACL Parametr interval
operator
protocol_obj_grp_id
text
Definice Nepovinné klíˇcové slovo, které specifikuje cˇ asový interval, bˇehem kterého má být vygenerována další systémová zpráva [2]. Nepovinné klíˇcové slovo používané k porovnání zdrojových nebo cílových portu˚ [2]. Název objektu obsahujícího list protokolu, ˚ které mají být filtrovány [2]. Text, o maximální velikosti 100 znaku, ˚ který má být pˇridán jako poznámka [2]. 11
3. N ÁVRH time_range
Klíˇcové slovo definující jméno cˇ asového rozsahu [2].
3.1.2 Vynechané parametry iptables Parametr -F nebo --flush [ˇretˇezec] -S nebo --list-rules [ˇretˇezec] -c nebo --set-counters
-g nebo --goto (ˇretˇezec)
-x nebo --exact
Definice Vyprázdní vybraný rˇ etˇezec [4]. Vypíše všechna pravidla z vybraného rˇ etˇezce [4]. Umožní, aby administrátor mohl inicializovat paketová a bajtová poˇcítadla pro dané pravidlo [4]. Specifikuje, že by mˇel proces pokraˇcovat v rˇ etˇezci definovaném uživatelem [4]. Rozšiˇruje cˇ ísla. Zobrazuje pˇresnou hodnotu paketových a bajtových poˇcítadel namísto zaokrouhlené hodnoty. [4]
3.1.3 Vynechané parametry RouterOS Parametr connection-bytes (integer-integer)
connection-rate (Integer 0..4294967295) fragment (yes | no)
Definice Propouští, nebo zakazuje pakety, které se shodují pouze v pˇrípadˇe, že dané množství bajtu˚ bylo pˇreneseno prostˇrednictvím konkrétního spojení [5]. Umožnuje ˇ odchytávat tok paketu˚ na základˇe souˇcasné rychlosti spojení [5]. Filtruje fragmentované pakety. První paket se nebere v úvahu. Pokud je povoleno sledování spojení, tak nebudou pˇrítomny žádné fragmenty, jelikož systém automaticky pakety spojuje. [5] 12
3. N ÁVRH p2p (all-p2p | bit-torrent | blubster | direct-connect | edonkey | fasttrack | gnutella | soulseek | warez | winmx) time (time-time, sat | fri | thu | wed | tue | mon | sun)
Filtruje pakety z ruzných ˚ peerto-peer (P2P) protokolu. ˚ Nefunguje na zašifrovaných p2p paketech. [5] Umožnuje ˇ vytvoˇrit filtr na základˇe pˇríchozího cˇ asu a data paketu, nebo odchozího cˇ asu a data pro lokálnˇe generované pakety [5].
3.1.4 Další omezení Kromˇe limitování množiny pravidel, jež lze generovat, je tˇreba zmínit, pro která zaˇrízení je aplikace navržena. Cílovou skupinou mobilních telefonu˚ jsou ty, které disponují operaˇcním systémem Android verze 2.1 (Software development kit 7) a vyšší, což umožní pokrýt vˇetšinu uživatelu˚ tohoto systému. Posledním omezujícím prvkem je jazyk. Všechny textové údaje jsou v angliˇctinˇe a to z toho duvodu, ˚ že v ní jsou psány veškeré syntaxe jednotlivých filtrovacích pravidel, a že se jedná jak o hlavní svˇetový jazyk, tak i o jazyk používaný v informatice nejˇcastˇeji. Pˇri vˇetším poˇctu požadavku˚ od uživatelu˚ na urˇcitý jazyk jej bude možné do programu implementovat.
3.2 Navržené syntaxe Již nˇekolikrát zde bylo rˇ eˇceno, že aplikace generuje pouze základní filtrovací pravidla, a jelikož jsou úplné syntaxe jednotlivých technologií velmi obsáhlé, bylo nutné snížit poˇcet atributu, ˚ které uživatel muže ˚ vložit, a upravit zmínˇené syntaxe. Cílem je, aby modifikované syntaxe poskytovaly ve všech tˇrech technologiích podobnou množinu parametru˚ a tak bylo zamezeno mnohem vˇetší rozpracovanosti jedné nad druhou. Níže si tedy pro každou technologii ukážeme, jaké atributy podporuje, ovšem ještˇe pˇred tím si vysvˇetlíme použité znaˇcení. Tuˇcnˇe psané výrazy jsou nemˇenné, to znamená, že v této podobˇe budou i ve vygenerovaném pravidle. Hranaté závorky znaˇcí, že údaj je nepovinný a složené oznaˇcují množinu.
13
3. N ÁVRH 3.2.1 Navržená syntaxe ACL Opˇet je nezbytné rozlišovat mezi standard, extended a named ACL, jelikož každý z tˇechto typu˚ nabízí jinou skupinu parametru. ˚ 3.2.1.1 Syntaxe standard ACL access-list cˇ íslo akce adresa maska [systémové zprávy] 3.2.1.2 Syntaxe extended ACL access-list cˇ íslo akce protokol zdrojová_adresa zdrojová_maska cílová_adresa cílová_maska [podmínka] [stav] [systémové zprávy] 3.2.1.3 Syntaxe named ACL Na rozdíl od pˇredchozích dvou typu, ˚ u tohoto ACL již máme možnost výbˇeru mezi IPv4 a IPv6. Podle zvolené IP rozlišujeme dvˇe ruz˚ né syntaxe. Dalším odlišným rysem je fakt, že se filtrovací pravidlo skládá ze dvou pˇríkazu. ˚ Syntaxe pro IPv4 je následující: ip access-list {standard|extended} jméno Podle zvoleného typu ACL, je pak druhý pˇríkaz tvoˇren stejnˇe jako tento typ, avšak již bez poˇcáteˇcní cˇ ásti „access-list cˇ íslo“. Syntaxe pro IPv6 je tato: ipv6 access-list jméno Za tímto pˇríkazem následuje druhý, jehož skladba má tento tvar: akce protokol zdrojová_adresa[/zdrojová maska] cílová_adresa[/cílová maska] [podmínka] [stav] [systémové zprávy] 3.2.2 Navržená syntaxe iptables {iptables|ip6tables} akce [tabulka] [protokol] [zdrojové rozhraní] [cílové rozhraní] [zdrojová adresa[/zdrojová maska]] [zdrojový port] [cílová adresa[/cílová maska]] [cílový port] [stav] [cíl] 14
3. N ÁVRH 3.2.3 Navržená syntaxe RouterOS add rˇ etˇezec akce [zdrojová adresa[/zdrojová maska]] [cílová adresa[/cílová maska]] [zdrojový port] [cílový port] [zdrojové rozhraní] [cílové rozhraní] [protokol] [stav] Výše uvedené syntaxe jsou si velmi podobné a liší se pˇredevším v povinnosti pˇrítomnosti daného atributu. Další odlišností je názvosloví parametru, ˚ které se v nˇekterých pˇrípadech odlišuje napˇríˇc technologiemi. Napˇríklad „ˇretˇezec“ u RouterOS je témˇerˇ ekvivalentem „tabulka“ u iptables.
3.3 Výbˇer SSH klienta V pˇredchozí kapitole jsme popsali, jak budou vypadat generovaná pravidla. Kromˇe vytváˇrení pravidel je dalším cílem, aby se software dokázal pˇripojit k sít’ovému zaˇrízení, zobrazil jeho pˇríkazový rˇ ádek (ˇci terminál) a vložil do nˇeho dané pravidlo. K tomuto úˇcelu jsme se rozhodli využít již existující aplikaci, jelikož pˇredmˇetem této bakaláˇrské práce není implementace komunikaˇcního klienta. Pˇri výbˇeru vhodného programu bylo zapotˇrebí vzít v úvahu, co mají všechny tˇri technologie spoleˇcné. Touto spojnicí je SSH protokol, díky kterému je možné se pˇripojit jak na smˇerovaˇc od Cisca cˇ i MikroTiku, tak i na zaˇrízení, na kterém je OS Linux. Hledání bylo provedeno na Google Play a pro nalezení více výsledku˚ bylo zamˇerˇ eno na dva typy softwaru. Prvním byl ten, jenž podporuje komunikaci pomocí SSH, zatímco druhý musel umˇet zobrazit terminál pˇripojeného klienta. Na základˇe tˇechto podmínek bylo nakonec vybráno šest aplikací: Android Terminal, Terminal IDE, Android Terminal Emulator, ConnectBot, SSH Tunnel a SSHDroid. Android Terminal byl zcela nevhodný, jelikož umožnuje ˇ pouze simulovat linuxový terminál, a tudíž nepodporuje vzdálený pˇrístup [19]. Terminal IDE je plnohodnotný program, který nabízí jak SSH, tak i zobrazení terminálu. Jeho slabinou ovšem je celková složitost,
15
3. N ÁVRH která je u uživatelsky pˇrívˇetivé aplikace nežádoucí [20]. Software Android Terminal Emulator je na tom velmi podobnˇe jako první zmínˇený, a tedy je také nepoužitelný [21]. Jak už názvy napovídají, SSH Tunnel a SSHDroid zprostˇredkovávají komunikaci pomocí SSH protokolu. Oba dva se jeví jako vhodní kandidáti, ovšem druhý zmínˇený má nízké hodnocení od jeho uživatelu˚ a první, i pˇres dobré hodnocení, nabízí pouze jednu uživatelskou recenzi, ve které je navíc hlášena chyba [22][23]. Zbývá nám tedy poslední aplikace a to ConnectBot. Tento SSH klient umí pˇresnˇe to, co potˇrebujeme. Na základˇe pˇrihlašovacího jména se spojí se zaˇrízením, zobrazí jeho pˇríkazový rˇ ádek a pomocí copy (kopírování) a paste (vkládání) dokáže do této rˇ ádky cokoliv zkopírovat – v našem pˇrípadˇe budeme samozˇrejmˇe vkládat generovaná pravidla. Duvodem ˚ k integrování ConnectBotu je i pˇrívˇetivost k uživateli v podobˇe jednoduchého a srozumitelného ovládání, vysoké hodnocení a miliony stažení, což vypovídá o kvalitˇe tohoto programu [24]. 3.3.1 Integrace ConnectBotu Puvodnˇ ˚ e bylo uvažováno, že by se po prvním spuštˇení naší aplikace automaticky nainstaloval z Google Play ConnectBot. Ten by se následnˇe zapnul ve chvíli, kdy by uživatel chtˇel vygenerované pravidlo použít. Takovýto pˇrístup není ale ideální. Zaprvé, náš software by byl závislý na pˇrítomnosti ConnectBotu v zaˇrízení. Zadruhé, jedna aplikace by se startovala z druhé a to by vedlo k nepˇrehlednosti a ke zbyteˇcnˇe složitému vypínání obou programu. ˚ Zatˇretí, vzájemná komunikace by byla zdlouhavá, jelikož by se ConnectBot musel po každém novˇe vytvoˇreném pravidlu vypnout a znovu zapnout, anebo by uživatel musel pˇrepínat aplikace na pozadí. Z výše uvedených duvod ˚ u˚ bylo nalezeno lepší rˇ ešení. Ponˇevadž je ConnectBot open-source software, byly z Google Code staženy jeho zdrojové kódy [25]. Ty budou upraveny pro potˇreby našeho programu a spojeny s celým projektem. Díky tomu se vyhneme existenci dvou samostatných aplikací a uživateli tak usnadníme práci.
16
3. N ÁVRH
3.4 Proˇc programovat v Androidu Abychom mohli zduvodnit ˚ výbˇer platformy Android, musíme se nejdˇríve zamˇerˇ it na její programovací jazyk, kterým je Java. Java patˇrí mezi objektovˇe orientované jazyky, což zjednodušenˇe znamená, že program napsaný v tomto jazyce lze rozdˇelit na jednotlivé objekty, které jsou definované jejich atributy a metodami. Síla tohoto pˇrístupu neboli OOP (object oriented programming) je v efektivnˇejším využití kódu oproti neobjektovˇe zamˇerˇ eným programovacím jazykum ˚ a v zajištˇení robustnˇejšího rˇ ešení problému. ˚ Velikou výhodou Javy je, že programy v ní napsané lze používat na libovolném operaˇcním systému. Tento systém musí ovšem splnovat ˇ jednu podmínku a tou je schopnost pracovat s JVM (Java virtual machine) – v dnešní dobˇe to umí jak operaˇcní systém Windows, tak i Linux, Mac a další. JVM slouží k interpretaci bajtkódu, což je kód zkompilovaného programu napsaného v Javˇe. Dalším duvodem, ˚ proˇc programovat v Javˇe je její jednoduchost a to pˇredevším, pokud mluvíme o alokování pamˇeti. Na rozdíl od C++ a dalších jazyku, ˚ ve kterých je nezbytné neustále myslet na alokování a dealokování pamˇeti, zde existuje tzv. Garbage Collection, který vše dˇelá za nás. Pˇri inicializování promˇenné cˇ i objektu si alokuje potˇrebné místo v pamˇeti a po nˇejaké dobˇe, kdy již pamˇet’ není používána, ji uvolní. Duležitým ˚ faktorem je dále bezpeˇcnost. „Java má velmi dobrou podporu pro výjimky a další události, které mohou nastat pˇri bˇehu programu. Tento fakt snižuje riziko vzniku nˇejakého problému na systémové vrstvˇe zpusobeného ˚ 1 hackerem cˇ i škodlivým kódem.“ [26] Nakonec mužeme ˚ dodat, že samotný kód Javy je dobˇre cˇ itelný, a že má Java velmi bohatou dokumentaci, která je skvˇelým pomocníkem pˇri programování [27]. Jelikož jsme si právˇe rˇ ekli nˇekolik hlavních duvod ˚ u, ˚ proˇc programovat v Javˇe, mužeme ˚ nyní pˇristoupit k samotnému Androidu. Již bylo rˇ eˇceno, že Android je nejrozšíˇrenˇejší mobilní platformou, a že každý den je aktivováno milion nových zaˇrízení. Dusledkem ˚ toho je Android v souˇcasné dobˇe nejrychleji se vyvíjející platformou. V po1
pˇreloženo z: „Java has great support for exceptions, or issues that occur during runtime. These exceptions reduce the ease for hackers and malicious code from causing an issue on the system level.“
17
3. N ÁVRH rovnání s internetovým obchodem iOS je na Google Play mnohem snazší vaši aplikaci prosadit a dostat se mezi nejlepších sto v libovolné kategorii. Vyhledávání je provádˇeno pˇredevším na základˇe klícˇ ových slov a až sekundárnˇe se zapojuje i hodnocení programu. Dalším kladem jsou nižší poˇrizovací náklady úˇctu na Google Play a levnˇejší a více efektivní reklama vaší aplikace než u Apple Store. To, co každý vývojáˇr ocení, je rychlá pˇrizpusobitelnost. ˚ Google Play umožnuje ˇ rychle reagovat na pˇripomínky uživatelu˚ a dokáže poskytnout novou verzi vaší aplikace bˇehem nˇekolika hodin (Apple Store na tento proces potˇrebuje cˇ asto i více jak sedm dní). Jako poslední pozitivum uvedeme delší možnost setrvání na dosažené úrovni. Jakmile vaše aplikace nabude vyššího postavení v hierarchii Google Play a následnˇe její poˇcet stažení zaˇcne radikálnˇe klesat, její pád zpátky dolu˚ trvá pomˇernˇe dlouho. [28][29]
3.5 Architektura Architektura se nebude nijak lišit od bˇežné struktury Android programu˚ dodržujících konvence jazyka Java. Aplikace bude složena z nˇekolika balíˇcku, ˚ ve kterých budou jednotlivé tˇrídy zamˇerˇ ující se na funkcionalitu specifickou pro rodiˇcovský balíˇcek. Pojmenování tˇechto obalu˚ tˇríd podléhá pˇrísným pravidlum ˚ [30]. Název musí být psán malými písmeny a mˇel by odpovídat pozpátku napsané webové adrese organizace, která software vyvíjí. V našem pˇrípadˇe (jako studenti MU) zvolíme adresu FI MU [31], ze které nám vznikne název cz.muni.fi. Jelikož pojmenování musí být unikátní, je potˇreba jej ještˇe více rozšíˇrit. Za tímto úˇcelem použijeme školní pˇrihlašovací jméno (login), který zaruˇcuje chtˇenou unikátnost a je velmi nepravdˇepodobné, že by jej použil nˇekdo cizí. Výsledným výchozím názvem balíˇcku˚ pro aplikaci je tedy výraz cz.muni.fi.xvyhnan. V kapitole 3.3 bylo rˇ eˇceno, že jsou využity zdrojové kódy ConnectBotu, a tudíž se v projektu kromˇe našich balíˇcku˚ nachází i mnoho dalších. Ty ovšem popisovat nebudeme a nastíníme funkˇcnost tˇech, které obsahují námi vytvoˇrené tˇrídy. V programu se budou nacházet dva hlavní balíˇcky.
18
3. N ÁVRH První bude zastˇrešovat tˇrídy, které reprezentují jednotlivé dialogy (v Android terminologii mluvíme o tzv. aktivitách). Hlavní tˇrídou v této skupinˇe bude Launcher, která bude mít na starost spouštˇení celé aplikace a nabídne uživateli možnost výbˇeru technologie pro filtrování paketu˚ a zobrazení nápovˇedy, tutoriálu a oken pro konfiguraci filtrovacích pravidel. Tˇrídy Tutorial a Help budou mít za cíl provést uživatele základními dovednostmi programu a definovat používané pojmy. Dále budeme mít tˇri aktivity pro nastavování filtrovacích parametru˚ – pro každou technologii jednu, ze kterých se bude otevírat jedna spoleˇcná aktivita. Tato tˇrída bude zobrazovat vygenerované pravidlo a bude propojovat naši aplikaci s ConnectBotem, který se postará o navázání spojení se sít’ovým zaˇrízením a zobrazení jeho terminálu. Jelikož budou konfiguraˇcní dialogy provádˇet v mnoha pˇrípadech stejné operace, pˇridáme ještˇe jedno rozhraní, které bude definovat spoleˇcné metody tˇechto aktivit a ty jej budou implementovat.
ˇ Obrázek 3.1: Zjednodušený analytický model diagramu tˇríd znázornující hlavní balík projektu (více na obrázku 6.1)
Kvuli ˚ velkému množství dat, které muže ˚ uživatel zadat, budou v druhém balíˇcku umístˇeny tˇrídy pro jejich validaci. Každá tˇrída bude kontrolovat jiný typ vstupních dat, od IPv4, IPv6, až po zadané porty a masky, a pˇri zadání nekorektních dat je bud’ v reálném cˇ ase pˇrepíše na akceptovatelné hodnoty, anebo vubec ˚ nepovolí jejich zapsání.
19
3. N ÁVRH
3.6 User-friendly aplikace Jestliže chceme, aby si naši aplikaci uživatel hned po spuštˇení neodinstaloval, musíme klást obzvlášt’ duraz ˚ na její pˇrívˇetivost vuˇ ˚ ci nˇemu. Za tímto úˇcelem bude v programu implementováno nˇekolik prvku, ˚ které budou mít za cíl ulehˇcit jak jeho celkové pochopení, tak i manipulaci s ním. Z duvodu ˚ velkého množství specializovaných pojmu˚ z IT, které tato aplikace obsahuje, je prvním krokem vytvoˇrit podrobnou nápovˇedu. Nápovˇedu bude možné otevˇrít z hlavního menu a uživateli bude doporuˇceno její pˇreˇctení po prvním spuštˇení softwaru. Její obsah bude rozdˇelen do cˇ tyˇr cˇ ástí. V první budou definovány používané pojmy a bude popsán jejich význam pˇri filtrování paketu. ˚ Ve druhé, tˇretí a cˇ tvrté bude pro jednotlivé filtrovací technologie vysvˇetleno, jaké parametry jsou za daných podmínek povinné a naopak. Pokud mluvíme o nápovˇedˇe, je vhodné zmínit tzv. „hinty“. Tímto atributem budou opatˇreny veškeré prvky GUI, za pomoci nichž mu˚ že uživatel vkládat data. „Hint“ je pˇrednastavený text, který svým obsahem poradí, co má být vloženo do dané komponenty, cˇ ímž je cˇ ásteˇcnˇe umožnˇeno omezit poˇcet špatnˇe zadaných vstupu. ˚ Aby se uživatel v našem programu neztratil a pochopil jeho hlavní funkce, bude z hlavního menu pˇrístupný i tutoriál, který bude, stejnˇe jako nápovˇeda, pˇri prvním spuštˇení automaticky nabídnut. Touto cestou se uživatel seznámí s procesem sestavení pravidla od prvotního vybrání technologie až po vkládání do konzole sít’ového zaˇrízení. V pˇredchozí kapitole již byla zmínˇena existence validace vstupních dat, a jelikož nyní mluvíme o prvcích uživatelsky pˇrívˇetivé aplikace, popíšeme ji zde detailnˇeji. Kontrola vložených dat bude probíhat na dvou úrovních. V první budou vstupy validovány v reálném cˇ ase. To znamená, že pokud uživatel zadá hodnotu, která nebude splnovat ˇ omezující kritéria, bude její obsah ihned pˇrepsán tak, aby byl vyhovující, anebo bude hodnota ponechána v pˇredchozím stavu, kdy ještˇe byla validní. Ve druhé bude kontrola probíhat pˇri vyslání 20
3. N ÁVRH požadavku na vytvoˇrení filtrovacího pravidla na základˇe uživatelem specifikovaných dat. V tomto pˇrípadˇe bude zjišt’ováno, jestli jsou vyplnˇeny všechny povinné parametry a znovu se provede kontrola získaných hodnot. Pokud bude nalezena chyba, uživatel bude pomocí tzv. alert dialogu upozornˇen, kde k ní došlo a proˇc. Závˇerem mužeme ˚ zmínit kontrolu zapnutí wi-fi pˇrijímaˇce a využití aplikace ConnectBot. Jelikož program bude vyžadovat pˇripojení k síti, aby bylo umožnˇeno spojení s cílovým zaˇrízením, bude vždy pˇri zapnutí softwaru zkontrolována dostupnost wi-fi sítˇe a uživatel bude informován o pˇrípadném neúspˇechu. Integrování ConnectBotu nám zaruˇcí uživatelskou pˇrívˇetivost na stranˇe SSH klienta a to díky již zmínˇenému hodnocení na Google Play a obrovskému poˇctu stáhnutí (více v kapitole 3.3) [24].
21
4 Implementace V této chvíli již máme pˇripraveny všechny podklady pro zahájení vývoje softwaru. V první fázi implementace teoreticky popíšeme firewall. Ve druhé následnˇe vylíˇcíme strukturu Android programu. ˚ Ve tˇretí se podíváme na samotnou aplikaci a její jednotlivé celky a nakonec uvedeme problémy, které bˇehem tohoto procesu vznikly.
4.1 Popis firewallu Firewall je nejduležitˇ ˚ ejším klíˇcovým termínem celé této práce, a proto je nezbytné na nˇej nahlédnout z pohledu jednotlivých technologií a vysvˇetlit základní odlišnosti. 4.1.1 Cisco IOS firewall – access control lists Hlavním cílem firewallu je ochránit vnitˇrní sít’ pˇred nebezpeˇcími pˇricházejícími z vnˇejší sítˇe. Firewally nám dovolují rozdˇelit sít’ do podsítí, cˇ ímž napomáhají omezit potencionální hrozby, které by se mezi podsítˇemi mohly šíˇrit. Firewall muže ˚ být bud’ fyzické zaˇrízení (hardware), nebo se muže ˚ jednat pouze o programové vybavení (software). Prakticky je firewall skupina pravidel, která prosazují pˇrístupové politiky mezi dvˇema nebo více sítˇemi. Základem firewallu jsou dva mechanismy, které vykonávají dvˇe separované funkce. První mechanismus proud dat blokuje, druhý propouští. Firewally filtrují data na základˇe nejruznˇ ˚ ejších parametru, ˚ nejˇcastˇeji jsou tˇemito parametry zdrojové a cílové IP adresy a cˇ ísla portu˚ nebo protokoly. [1] ACL je seznam definující oprávnˇení pˇrístupu k urˇcitému zaˇrízení cˇ i cˇ ásti sítˇe. Urˇcuje nejen, kdo má povolen pˇrístup, ale i jaké operace muže ˚ vykonávat. Duvod ˚ u˚ proˇc konfigurovat ACL je hned nˇekolik – je jimi možné omezit smˇerovací aktualizace, poskytují kontrolu datového toku, ovšem nejduležitˇ ˚ ejší je, že umožnují ˇ zabezpeˇcení sítˇe. [1]
22
4. I MPLEMENTACE 4.1.2 IPtables Nejznámˇejší a nejpoužívanˇejší open-source firewall technologií jsou iptables, které jsou volnˇe k dispozici u všech novˇejších distribucí Linuxu. Podle manuálových stránek Linuxu je iptables administraˇcní nástroj pro filtrování paketu˚ IPv4, IPv6 a pro NAT (network address translation). Je možné definovat nˇekolik odlišných tabulek. Každá tabulka obsahuje nˇekolik vestavˇených rˇ etˇezcu˚ a umožnuje ˇ také deˇ finovat rˇ etˇezce vlastní. Retˇezec je seznam pravidel, která se mohou shodovat s pakety (tedy podobný princip jako u ACL). Každé pravidlo specifikuje, co dˇelat s paketem, který danému pravidlu odpovídá. [4] 4.1.3 MikroTik – RouterOS MikroTik je firma, která se pˇredevším specializuje na bezdrátové technologie. Vyvíjí software RouterOS a zaˇrízení nazývající se RouterBOARD. Aˇckoliv software tohoto zaˇrízení vychází z Linuxu, MikroTik neposkytuje uživateli zdrojové kódy. To ovšem nemusí být pˇrekážkou, protože do zaˇrízení je možné nahrát i jiný systém, než právˇe RouterOS. Stejnˇe tak lze naopak RouterOS nahrát do jiného zaˇrízení než od MikroTiku. [32][33] RouterBOARD zaˇcíná být mezi uživateli velmi oblíbený díky jeho nízké cenˇe, rychlosti, pomˇernˇe snadné konfiguraci a velkému množství funkcí. Zaˇrízení muže ˚ sloužit jako server, pˇrepínaˇc, smˇerovaˇc, firewall a další. My se zamˇerˇ íme právˇe na firewall. Jak již bylo rˇ ecˇ eno, RouterOS vychází z Linuxu, ovšem firewall se od linuxových iptables liší. Implementace muže ˚ být složitˇejší, protože kromˇe klasických pravidel je možné nastavit i pokroˇcilé detekování provozu. Dle složitosti firewallu je také potˇreba pˇríslušný RouterBOARD s dostateˇcným výkonem. Složitˇejší firewall a slabý výkon by mohli mít za následek problémy na síti. [32][33]
4.2 Android a struktura aplikací na této platformˇe „Android pohání stovky milionu˚ mobilních zaˇrízení ve více než 190 zemích po celém svˇetˇe. Je to nejrozšíˇrenˇejší mobilní platforma – kaž23
4. I MPLEMENTACE dý den poprvé zapne Android zaˇrízení další milion uživatelu˚ a zaˇcne hledat aplikace, hry a další digitální obsah. Android nabízí zaprvé prvotˇrídní platformu pro vytváˇrení softwaru a her pro Android uživatele na celém svˇetˇe a zadruhé otevˇrený trh pro okamžitou distribuci.“1 [28] Jelikož je Android dnes tak masivnˇe rozšíˇrený, je vhodné se blíže seznámit se strukturou aplikací vyvíjených na této platformˇe. Mezi hlavní komponenty Android programu˚ patˇrí aktivity, dodavatelé obsahu, služby a zámˇery [7]. Aktivita je základním stavebním kamenem, který zprostˇredkovává komunikaci s uživatelem. Ve vˇetšinˇe pˇrípadu˚ reprezentuje jedno zobrazované okno s urˇcitým grafickým rozhraním. Otevˇrené aktivity, chcete-li otevˇrená okna, jsou vkládána do zásobníku, díky cˇ emuž je uživatel po zavˇrení zobrazovaného okna pˇresmˇerován do pˇredchozího, ze kterého byla zavˇrená aktivita spuštˇena. Z toho vyplývá, že aktivity mají svuj ˚ životní cyklus, bˇehem kterého jsou všechny zmˇeny v nich provedené (uživatel vložil data) ukládány a opˇetovnˇe naˇcteny pˇri návratu na vrchol zásobníku. Jakmile je aktivita zavˇrena, tedy odebrána ze zásobníku, všechna data jsou smazána a její životní cyklus konˇcí. [7][34] Dodavatel obsahu umožnuje ˇ pˇristupovat ke strukturovanému úložišti dat, ve kterém mohou být data jak z integrovaných aplikací, tak i ze stáhnutých. Dobrým pˇríkladem je seznam kontaktu. ˚ Pomocí dodavatele obsahu tedy mužeme ˚ pˇristupovat k datum ˚ ostatních programu˚ a poskytovat data našeho vlastního softwaru. Jedním z du˚ vodu˚ pro implementování této služby je napˇríklad umožnˇení kopírování komplexních dat z naší aplikace do jiné pomocí „copy and paste“. [7][35][36] Služby na rozdíl od aktivit, které mohou být ukonˇceny témˇerˇ okamžitˇe po jejich spuštˇení, pˇredstavují obvykle déle bˇežící procesy. 1
pˇreloženo z: „Android powers hundreds of millions of mobile devices in more than 190 countries around the world. It’s the largest installed base of any mobile platform and growing fast — every day another million users power up their Android devices for the first time and start looking for apps, games, and other digital content. Android gives you a world-class platform for creating apps and games for Android users everywhere, as well as an open marketplace for distributing to them instantly.“
24
4. I MPLEMENTACE Služba muže ˚ být spuštˇena v rámci aktivity, avšak její životní cyklus na ni není vázán. To znamená, že po ukonˇcení aktivity muže ˚ služba ˇ nadále existovat. Casto jsou provádˇeny ve vlastním vláknˇe, aby nezatˇežovaly bˇeh ostatních procesu. ˚ Pˇríkladnou ukázkou je pˇrehrávání hudby, které je zpravidla spuštˇeno pomocí rozhraní daného programu, který je následnˇe ukonˇcen. Tato služba i pˇresto nadále pˇrehrává všechny dostupné skladby a je skrytá na pozadí. [7][37] Zámˇery jsou systémové zprávy, které primárnˇe slouží ke spouštˇení aktivit. Umožnují ˇ reagovat na výskyt ruzných ˚ událostí, jako je napˇríklad pˇrijetí SMS zprávy. Jinými slovy, popisují operaci, která má být provedena. [7][38] Dalšími souˇcástmi Android aplikací jsou XML (extensible markup language) soubory, manifest, preference, soubory s rˇ etˇezci. . . Již bylo rˇ eˇceno, že aktivita zastupuje jedno zobrazované okno, které má urˇcitý grafický vzhled. Ten je definován pomocí XML, které je nacˇ teno vždy pˇri startu aktivity. XML soubor má vždy jeden rodiˇcovský element, který definuje, jak v nˇem budou jeho potomci rozloženi. Potomci mohou být jednotlivé, pro uživatele viditelné, komponenty, jako jsou tlaˇcítka, rolovací lišty, editovací pole a mnoho jiných, anebo mohou pouze specifikovat vybrané vlastnosti svých dalších potomku. ˚ Samozˇrejmˇe je možné vytváˇret komponenty dynamicky v kódu nˇekteré tˇrídy, ovšem toto rˇ ešení je složitˇejší (jak z hlediska programátora, tak i ve velikosti kódu oproti tomu v XML) a je náchylné k chybám, protože je potˇreba ošetˇrovat parametry, které XML rˇ eší automaticky. [7] Manifest je XML soubor, ve kterém je deklarován obsah aplikace. Nalezneme zde tedy pˇredevším, jakou verzi OS Android program podporuje, jaká práva aplikace pro její správnou funkˇcnost potˇrebuje (napˇríklad pˇrístup k Internetu), která aktivita se spustí po zapnutí softwaru, deklaraci všech aktivit a služeb. . . V pˇrípadˇe, že nebudou v manifestu uvedeny všechny aktivity cˇ i služby, aplikace pˇri pokusu o jejich nastartování zahlásí chybu a spadne. [7]
25
4. I MPLEMENTACE Systém preferencí umožnuje ˇ ukládat uživatelem vložená data, která jsou ve tvaru klíˇc a hodnota a jejichž úˇcelem je uchovávat uživatelské nastavení. Napˇríklad volbu vyzvánˇecího tónu nebo výbˇer barvy nˇekterého prvku grafického rozhraní. Toto nastavení je v zaˇrízení uloženo trvale a je zachováno i po ukonˇcení aplikace. [7] Nakonec zmíníme ještˇe soubory s rˇ etˇezci, jejichž cílem je zaprvé uchovávání textových údaju˚ cˇ i celých polí za pomoci specifického klíˇce, kterým jsou následnˇe volány ze tˇríd, kde jsou potˇreba, a zadruhé zjednodušení internacionalizace. [7]
4.3 Vývoj aplikace V této kapitole se dostáváme k tomu nejduležitˇ ˚ ejšímu a to k postupné implementaci celé aplikace. Pro lepší orientaci a pˇrehlednost nebudeme jednotlivé etapy vývoje popisovat, jak šly za sebou chronologicky, ale budeme je prezentovat podle logických celku˚ programu. Nejprve se tedy podíváme na problematiku ruzných ˚ rozlišení displeju˚ na zaˇrízeních s OS Android a poté nastíníme postup implementace jednotlivých cˇ ástí softwaru. 4.3.1 Pˇrizpusobení ˚ pro ruzné ˚ displeje Každý, kdo chce zaˇcít vyvíjet aplikace pro Android, si musí uvˇedomit, že vzhled výsledného programu muže ˚ být na ruzných ˚ zaˇrízeních odlišný. Tento fakt je zpusoben ˚ nejednotným rozlišením displeju˚ mobilních telefonu˚ (dnes už i tabletu) ˚ podporujících tuto platformu. K docílení stejného cˇ i velmi podobného vzhledu na všech displejích je potˇreba pochopit funkcionalitu jednotlivých kontejneru˚ používaných v XML a nauˇcit se je správnˇe používat. Za tímto úˇcelem zde popíšeme tˇri základní typy kontejneru˚ a demonstrujeme jejich využití v naší aplikaci. Prvním kontejnerem, se kterým se pravdˇepodobnˇe zaˇcínající programátor setká, je kontejner typu LinearLayout. Tento XML element umist’uje své potomky za sebe bud’ vertikálnˇe, anebo horizontálnˇe a je charakterizován pˇeti hlavními atributy: orientace, výplnˇ modelu, 26
4. I MPLEMENTACE váha, gravitace a výplnˇ mezi potomky. Význam parametru orientace již byl rˇ eˇcen – urˇcuje, zdali budou potomci umist’ováni na rˇ ádek cˇ i do sloupce. Výplnˇ modelu je zastoupena dvˇema atributy, které rˇ íkají, jak má kontejner zaplnit své rodiˇce na výšku a na šíˇrku. Bud’ se zadá pˇrímo nˇejaký cˇ íselný údaj, anebo se vloží pˇreddefinovaná konstanta. Pˇri použití konstanty element bud’ zaplní veškerý prostor v rodiˇci, anebo je velikost pˇrizpusobena ˚ jeho obsahu. Pokud chceme, aby se o dostupný prostor dˇelilo dva a více elementu˚ v urˇcitém pomˇeru, zavedeme váhu. Typickým pˇríkladem je umístˇení dvou tlaˇcítek vedle sebe na rˇ ádek tak, aby mˇely stejnou šíˇrku. Za tímto úˇcelem staˇcí jednoduše obˇema nastavit váhu na hodnotu jedna, cˇ ili pomˇer jejich šíˇrek bude 1:1. Dalším atributem je gravitace, která slouží k nastavení pozice obsahu v závislosti na zvolené orientaci – typicky nabývá hodnot nalevo, napravo, uprostˇred, nahoˇre a dole. Nakonec mužeme ˚ ještˇe nastavit výplnˇ mezi potomky (ve všech cˇ tyˇrech smˇerech dané komponenty) a díky tomu dosáhnout lepšího vzhledu. [7] Druhý, velmi cˇ asto používaný, kontejner je TableLayout. Jak název napovídá, jeho primárním úˇcelem je zobrazování dat v tabulkové struktuˇre. Toho je docíleno za pomoci elementu TableRow, který zastupuje jednotlivé rˇ ádky tabulky. Každý potomek takového rˇ ádku pak znázornuje ˇ jeden sloupec, tedy jednu bunku ˇ tabulky. TableLayout umožnuje ˇ svým potomkum ˚ specifikovat atributy jako je cˇ íslo sloupce cˇ i poˇcet sloupcu, ˚ které bude komponenta zabírat. Mezi jednotlivé rˇ ádky lze kromˇe TableRow vkládat i bˇežné elementy, u kterých se TableLayout následnˇe chová podobnˇe jako LinearLayout. [7] Poslední kontejner, který uvedeme, je RelativeLayout. Pilíˇrem tohoto kontejneru je urˇcování relativní pozice jednoho potomka vuˇ ˚ ci ostatním a také vuˇ ˚ ci samotnému rodiˇci. Ve vztahu k rodiˇci muže ˚ být potomek umístˇen k levé, pravé, horní a dolní stˇenˇe cˇ i do stˇredu a tyto vlastnosti se mohou libovolnˇe kombinovat. Pˇri deklarování vztahu˚ mezi potomky je tˇreba každé komponentˇe, na kterou se budeme odkazovat, explicitnˇe nastavit hodnotu parametru id. Pomocí nˇej pak mužeme ˚ rˇ íci, že element B bude napravo od elementu A, kde B má referenci na identifikátor A. Kromˇe „napravo“ lze samozˇrejmˇe definovat i ostatní smˇery umístˇení. Dále je možné pomocí identifiká27
4. I MPLEMENTACE toru potomky zarovnávat podle levého, pravého, horního a dolního okraje cˇ i podle úrovnˇe textu vepsaného do komponenty. [7] Z tˇechto tˇrí kontejneru˚ v naší aplikaci nejvíce využíváme RelativeLayout a to z toho duvodu, ˚ že nabízí zarovnávání konkrétních prvku˚ GUI podle zadané specifikace napˇríˇc celým XML souborem (tudíž nemusíme mít obavy, že by nˇekde nˇejaký element vyˇcníval). Díky nˇemu je práce v aktivitách pro konfiguraci filtrovacích pravidel velmi usnadnˇena. Vyvíjená aplikace má tedy ve všech XML souborech definujících vzhled dané aktivity jako hlavní kontejner a rodiˇce všech ovládacích prvku˚ RelativeLayout. V nˇem velmi cˇ asto užíváme LinearLayout pro obalení elementu, ˚ které spolu sdílejí nˇekteré vlastnosti, nebo na které je potˇreba se odkazovat jako na celek z jiné komponenty. RelativeLayout je v aplikaci zpravidla obalen ještˇe jedním rodiˇcem. Bud’ se jedná o tzv. ScrollView, který zprostˇredkovává posouvání obsahu obrazovky v pˇrípadˇe, že je moc dlouhý, anebo je to TabHost, jehož funkcí je vytváˇrení záložek a možnost jejich pˇrepínání (a tím pádem i zobrazování rozdílného obsahu). V jednom pˇrípadˇe jsme implementovali i TableLayout, který zde slouží k vizualizaci filtrovacích pravidel uložených v databázi. Kromˇe správného používání kontejneru, ˚ je nezbytné kontrolovat i textové rˇ etˇezce a jejich zobrazení na ruzných ˚ displejích. V pˇrípadˇe, kdy vedle sebe máme textový rˇ etˇezec A a napˇríklad editovací pole B, kde B má nastaveno, že se nachází napravo od A, a používáme displej s velikým rozlišením, vše bude vypadat, tak, jak chceme – A je celé cˇ itelné a B je dostateˇcnˇe široké pro zadání vstupu od uživatele. Situace se ovšem s velkou pravdˇepodobností zmˇení, jakmile použijete displej s nižším rozlišením. Šíˇrka A zustane ˚ stejná ovšem na úkor délky B, která se zmenší. V horším pˇrípadˇe bude tak malá, že uživatel ani neuvidí, co do B napsal. Pokud by byla nastavena závislost naopak, tedy A je nalevo od B, pak by sice B mˇelo šíˇrku stejnou, ale A by bylo oˇrezáno, a tudíž by nebyl vidˇet jeho celý text. My toto riziko rˇ ešíme dvˇema zpusoby. ˚ Zaprvé, aplikace je primárnˇe testována na displeji s nejmenším rozlišením zaˇrízení s OS Android. Díky tomu máme jistotu, že pokud se program správnˇe zobrazuje na tomto displeji, pak bude dobˇre prezentován i ostatními. Zadruhé, 28
4. I MPLEMENTACE vˇetšina textových rˇ etˇezcu, ˚ pˇredevším ty delšího rozsahu, jsou umist’ovány samostatnˇe na vlastní rˇ ádek, díky cˇ emuž se zcela eliminuje výše popisovaný problém. Jestliže jsme si definovali obecnou poziˇcní logiku textových rˇ etˇezcu, ˚ je vhodné uvést i rozmístˇení ostatních prvku. ˚ Veškeré komponenty jsou koncipovány tak, aby pro sebe mˇely dostatek místa, a to z toho duvodu, ˚ aby bylo snadné na nˇe kliknout cˇ i pˇreˇcíst vložený text. Pˇri zmˇenˇe orientace zaˇrízení z vertikální polohy do horizontální a naopak se všechny prvky GUI pˇrizpusobí ˚ nové šíˇrce displeje. 4.3.2 Struktura jednotlivých aktivit Hlavní aktivitou celé aplikace je Launcher. Tato tˇrída pˇredstavuje hlavní menu programu (obrázek 4.1), které plní dvˇe základní funkce. V první rˇ adˇe, uživatel si muže ˚ pomocí vyskakovací lišty vybrat jednu ze tˇrí technologií podporujících filtrování paketu˚ na základˇe pravidel. Tento výbˇer lze následnˇe stvrdit pomocí potvrzovacího tlaˇcítka, jež podle vybrané technologie spustí aktivitu pro konfiguraci filtrovacích pravidel. V druhé rˇ adˇe, pro nové uživatele jsou zde umístˇena tlaˇcítka spouštˇející aktivity Tutorial a Help, jejichž úˇcel byl již zmínˇen v návrhové cˇ ásti. Jelikož je tˇrída Tutorial celkovˇe obsáhlá (tím pádem i ménˇe pˇrehledná), co se rozsahu textu˚ a poˇctu obrázku˚ týká (obrázek 4.2), její obsah jsme rozˇclenili do sedmi samostatných logických celku. ˚ Za tímto úˇcelem jsme použili element ViewFlipper, který dovede samostatnˇe zobrazit každého svého potomka. Máme tedy celkem sedm potomku, ˚ pro jejichž pˇrepínání bylo nutné ještˇe pˇridat dvˇe tlaˇcítka – jedno pro návrat k pˇredchozímu potomkovi a druhé pro posunutí k tomu následujícímu. Jednotliví potomci sestávají z textových údaju, ˚ které jsou doplnˇené adekvátním obrázkem cˇ i pˇrímo popisovaným GUI. Používání obrázku˚ ovšem vyvolalo jeden problém související s již zminovanou ˇ ruznorodostí ˚ rozlišení displeju. ˚ Aby byly obrázky dobˇre cˇ itelné na všech displejích, vytvoˇrili jsme je ve vˇetším rozlišení, než jaké je pro vˇetšinu Android zaˇrízení potˇrebné. Velikost celé aplikace tím sice výraznˇe vzrostla (o rˇ ády kilobajtu), ˚ nicménˇe 29
4. I MPLEMENTACE primárním cílem je v tomto pˇrípadˇe dobrá cˇ itelnost. Aktivita Help je složena pouze z textových údaju, ˚ které jsou rozˇclenˇeny do cˇ tyˇr záložek, jejichž názvy jasnˇe specifikují, co v nich bude k nalezení (obrázek 4.3).
Obrázek 4.1: Menu
Obrázek 4.2: Tutoriál
ˇ Obrázek 4.3: Nápoveda
Zˇrejmˇe nejzajímavˇejší jsou konfiguraˇcní aktivity, jejichž implementace byla nejvíce cˇ asovˇe nároˇcná (obrázky 4.4, 4.5 a 4.6). Náleží sem tyto tˇri tˇrídy: ConfigCiscoACL, ConfigIPtables a ConfigRouterOS. Každá z nich má v závislosti na poˇctu filtrovacích parametru˚ ruzné ˚ množství a odlišné typy komponent. Pro atributy, které oˇcekávají nˇejaké údaje od uživatele, jsme použili editovací pole. Rolovací lišty jsme pak využili pro parametry, jejichž hodnoty jsou pˇredem známé. Pokud ovšem tento výˇcet možných hodnot má pouze dvˇe položky, upˇrednostnuje ˇ se komponenta tzv. rádiových tlaˇcítek. Duvod ˚ je prostý. V pˇrípadˇe, kdy je poˇcet hodnot nízký, jejich pˇrímé zobrazení nezaplní velký prostor, a tudíž je vhodnˇejší uživateli existující hodnoty ukazovat pˇrímo. V opaˇcném pˇrípadˇe není adekvátní tento postup aplikovat, jelikož by celý výˇcet zaplnil neúmˇernˇe velké místo na obrazovce. Z tohoto duvodu ˚ používáme rolovací lištu, která po kliknutí zobrazuje svuj ˚ obsah. Poslední používanou komponentou je zaškrtávací políˇcko, které indikuje, jestli má být nˇekterý atribut použit cˇ i 30
4. I MPLEMENTACE nikoliv, anebo jestli chce uživatel vkládat svoji vlastní hodnotu na místˇe, kde je možné si vybrat z již existující nabídky. Zajímavým problémem byla tvorba komponenty pro vkládání IP adresy. Nabízela se dvˇe rˇ ešení, jak by tento GUI prvek mohl vypadat. Prvním bylo použít jedno editovací pole. Do nˇej by uživatel zadával IP adresu bud’ s teˇckami (u IPv6 s dvojteˇckami) – 192.168.0.10, anebo bez nich – 192168010. Jelikož je délka hodnoty každého oktetu jeden až tˇri (u IPv6 nula až cˇ tyˇri) znaky, mužeme ˚ druhou možnost hned vylouˇcit. Duvodem ˚ je neschopnost pˇresného urˇcení konce jednoho a zaˇcátku druhého oktetu (napˇríklad prvních pˇet cˇ íslic by bylo možné rozdˇelit na dva oktety více zpusoby ˚ – 192.16 nebo 19.216). První možnost je jistˇe pˇrehlednˇejší a lépe zpracovatelná pro aplikaci, avšak problém nastává ve chvíli, kdy chceme data kontrolovat s každým novˇe vloženým znakem. Jelikož zadávaná data obsahují jak cˇ ísla, tak i teˇcky (u IPv6 dvojteˇcky a ještˇe písmena), musel by se vložený rˇ etˇezec bud’ rozdˇelovat na jednotlivé oktety, které by se samostatnˇe kontrolovaly, anebo by se musel použít regulární výraz, který by byl v takovém pˇrípadˇe zbyteˇcnˇe složitý. Kdyby se používala pouze IPv4, tak bychom o této možnosti mohli eventuálnˇe uvažovat, nicménˇe pˇrítomnost IPv6 nás nutí vytvoˇrit univerzální rˇ ešení. Druhým rˇ ešením tedy bylo zavedení cˇ tyˇr editovacích polí (osmi u IPv6). Každé reprezentuje jeden oktet. Tento pˇrístup je pˇrehlednˇejší a umožnuje ˇ mnohem jednodušší kontrolu vložených dat. Uživatel je takto omezen pouze na vkládání cˇ íslic (a písmen u IPv6) a navíc jsme zcela eliminovali použití regulárních výrazu. ˚ Jednoduše staˇcí kontrolovat, jestli je hodnota mˇenˇeného oktetu v povoleném rozmezí (u IPv6 se oproti IPv4 kontroluje pouze poslední vložený znak, a pokud se nejedná o cˇ íslo, pˇrevedeme znak na jeho cˇ íselnou hodnotu v ASCII kódu a opˇet zjišt’ujeme, zdali je ve správném rozsahu).
31
4. I MPLEMENTACE
Obrázek 4.4: Konfigurace Cisco ACL
Obrázek 4.5: Konfigurace iptables
Obrázek 4.6: Konfigurace RouterOS
Co se týká kontroly vstupu˚ ostatních komponent, rozlišujeme ty, které má smysl validovat a ty, u kterých je validace bezúˇcelná. Nemá význam kontrolovat data, která mohou nabývat libovolných hodnot. V naší aplikaci jsou tˇemito atributy napˇríklad název tabulky, protokolu cˇ i rozhraní. Naopak mezi další validované parametry patˇrí cˇ íslo ACL, masky a portu. Stejnˇe jako v pˇrípadˇe IP adresy i zde je vstup kontrolován pˇri každé zmˇenˇe poˇctu znaku˚ v daném editovacím poli. Této funkcionality je dosaženo následujícím zpusobem. ˚ V konfiguraˇcní aktivitˇe je vždy v promˇenné uložena instance pole, které editujeme. Této promˇenné je pˇriˇrazen posluchaˇc, jenž reprezentuje instanci námi vytvoˇrené tˇrídy implementující rozhraní TextWatcher spoleˇcnˇe i s jeho metodami. V našem pˇrípadˇe je duležitá ˚ metoda afterTextChanged, která je zavolána, kdykoli dojde ke zmínˇené obmˇenˇe dat, a které je jako parametr pˇredán novˇe vložený rˇ etˇezec. Metoda svuj ˚ parametr následnˇe zpracuje a v pˇrípadˇe nekorektního vstupu jej zmˇení na správnou hodnotu. Dodateˇcné kontroly poté ještˇe provádíme pˇri požadavku na vygenerování pravidla (pˇríkladem je pˇrítomnost všech povinných atributu). ˚ Abychom mohli uzavˇrít konfiguraˇcní aktivity, musíme zmínit i samotné generování filtrovacího pravidla. Tato akce je svázána se stisk32
4. I MPLEMENTACE nutím tlaˇcítka pro vytvoˇrení oˇcekávaného výstupu, tedy pravidla. Jakmile k této události dojde, jsou postupnˇe kontrolovány všechny vložené informace. Jestliže je nalezena chyba, vloží se do pˇredem vytvoˇrené množiny typu HashSet (množina je použita k zaruˇcení unikátnosti konkrétních chyb) a po dokonˇcení této kontroly jsou na obrazovku všechny nalezené chyby vypsány (obrázek 4.7) a soucˇ asnˇe jsou barevnˇe oznaˇceny nekorektní komponenty (obrázek 4.8). Pokud žádná chyba nalezena není, inicializuje se promˇenná textového typu a ta je postupnˇe doplnována ˇ zadanými parametry tak, aby skladba výsledného pravidla odpovídala syntaxi deklarované v návrhové cˇ ásti této bakaláˇrské práce.
Obrázek 4.7: Hlášení chyb
ˇ Obrázek 4.8: Zvýraznení chyb
Obrázek 4.9: Náhled vygenerovaného pravidla
Ve chvíli, kdy je pravidlo vygenerováno, nás program pˇresmˇeruje do aktivity ShowCommand (obrázek 4.9). Zde zobrazované pravidlo je souˇcástí tzv. extras, což jsou pˇrídavné soubory dat, které jsou pˇrirˇ azeny urˇcité aktivitˇe. Tato data jsou uložena v pamˇeti po celou dobu existence jejich aktivity. Díky tomu je po pˇrímé editaci pravidla (pomocí tlaˇcítka Edit) umožnˇeno jeho obnovení do puvodní ˚ podoby (tlaˇcítko Restore). Abychom mohli vubec ˚ vysvˇetlit význam obnovovacího tlaˇcítka, popíšeme nejprve smysl editovacího. Tato komponenta je zde z toho duvodu, ˚ že vyvíjená aplikace generuje pouze základní filtrovací pravidla, a tedy je vhodné umožnit uživateli pra33
4. I MPLEMENTACE vidla doplnit o další parametry. Funkce pro obnovení se muže ˚ následnˇe hodit zejména v situaci, kdy uživatel upraví pravidlo do nevalidní podoby, kvuli ˚ své neznalosti cˇ i chybˇe. Druhá polovina této aktivity implementuje samotný ConnectBot (obrázek 4.10). Jak bylo zmínˇeno v návrhu, využili jsme celý projekt ConnectBotu a do nˇej jsme vložili naši aplikaci. Opaˇcný proces, tedy vepsání kódu ConnectBotu do našeho projektu, by byl kvuli ˚ znaˇcné obsáhlosti tohoto SSH klienta pˇríliš zdlouhavý, a proto jsme zvolili efektivnˇejší cestu. Prvním krokem slouˇcení projektu˚ bylo kopírování všech balíku˚ a XML souboru˚ na pˇríslušná místa. Ve druhém kroku jsme spojili soubory s textovými rˇ etˇezci a manifesty a to z toho du˚ vodu, že jejich pouhé pˇresunutí by vytvoˇrilo duplicity, a tudíž by vznikl nekorektní Android projekt. V pˇrípadˇe rˇ etˇezcu˚ bylo nutné zkontrolovat unikátnost všech klíˇcu˚ jednotlivých textových hodnot. U manifestu došlo k vˇetším zmˇenám. Jako výchozí balík jsme nastavili ten, který obsahuje spouštˇecí aktivitu. S tím dále souvisí zmˇena deklarace spouštˇecí tˇrídy a cesty ke tˇrídám ConnectBotu. Tˇretím krokem byla úprava kódu a to jak našich tˇríd, tak i tˇech z ConnectBotu. V hlavní aktivitˇe ConnectBotu HostListActivity jsme odstranili volbu výbˇeru protokolu pro pˇripojení k sít’ovému zaˇrízení, protože pouze SSH je podporováno všemi technologiemi. Tuto tˇrídu jsme následnˇe slouˇcili s ShowCommand aktivitou. Výsledek tohoto spojení je rozdˇelen do dvou záložek, kde první zobrazuje naši cˇ ást aplikace (popsána výše) a druhá znázornuje ˇ úvodní obrazovku ConnectBotu. Další nutné zmˇeny jsme provedli ve tˇrídˇe ConsoleActivity, která slouží k vizualizaci samotné konzole pˇripojovaného zaˇrízení (obrázek 4.11). Zmˇeny se týkají menu, jež nyní obsahuje tzv. „pre-paste“ pˇríkazy a vygenerované pravidlo (obrázek 4.12). Zmínˇené pˇríkazy jsou potˇrebné pro zpˇrístupnˇení editace filtrovacích pravidel. Duležitým ˚ faktem je, že u ACL nelze zadávání pravidel aktivovat jedním pˇríkazem, ale dvˇema. Tudíž je i v menu o položku víc. Jakmile jsme úspˇešnˇe aplikovali tyto pˇríkazy, mužeme ˚ již vkládat konkrétní filtrovací pravidla, která jsme získali díky jejich uložení v systémových preferencích. I zde máme jednu výjimku u named ACL, jehož pravidla jsou tvoˇrena dvˇema pˇríkazy. To se opˇet projeví v poˇctu položek 34
4. I MPLEMENTACE v menu konzole. Podoba menu se tedy ruzní ˚ podle vybrané technologie, která je stejnˇe jako vygenerované pravidlo ukládána v preferencích. Z toho vyplývá jedno logické omezení – pokud uživatel vytvoˇrí pravidlo napˇríklad pro RouterOS a poté se za pomoci ConnectBotu pˇripojí k Cisco smˇerovaˇci, zcela jistˇe nebude moci použít pˇríkazy pro pˇrístup k filtrovacím pravidlum ˚ a také samotná pravidla.
Obrázek 4.10 ConnectBot rozhraní
Obrázek 4.11: Konzole
Obrázek 4.12: Menu pro vkládání pravidel
4.3.3 Publikace na Google Play Nyní si ještˇe nˇeco povíme o zveˇrejnˇení této aplikace na Google Play. Zaprvé, pro publikování vlastního softwaru na tomto webu je potˇreba mít úˇcet na Googlu (napˇríklad v podobˇe Gmailu) a zaplatit jednorázový poplatek pro pˇrístup ke konzoli Google Play. Zadruhé, je nutné vytvoˇrit certifikát s minimální platností padesát let, cˇ ehož lze snadno docílit ve vývojovém prostˇredí Eclipse, a vygenerovat nový .apk soubor (instalaˇcní Android soubor) s tímto certifikátem. Zatˇretí, nejpodstatnˇejší je vybrat aplikaci takové jméno, aby byla co nejsnadnˇeji vyhledatelná nejvˇetším možným poˇctem lidí. Za tímto úˇcelem jsme vybrali jedno klíˇcové slovo, které je nejvíce charakteristické pro náš program, a doplnili jej pˇrívlastkem pro dobré zapamatování názvu [39]. Finální jméno tedy je Firewall Builder. Posledním krokem 35
4. I MPLEMENTACE je nahrání certifikovaného instalaˇcního souboru do konzole a doplnˇení dodateˇcných informací a obrázku. ˚ Za nˇekolik hodin je potom aplikace volnˇe dostupná ke stažení.
4.4 Problémy bˇehem vývoje Jak název napovídá, v této kapitole popíšeme problémy, které nás bˇehem implementace potkaly. Nebudeme rozebírat všechny neplánované pˇrekážky, nýbrž se zamˇerˇ íme pouze na ty, jež jsou nˇecˇ ím zajímavé. Do této skupiny jistˇe patˇrí potíže s vytvoˇrením certifikovaného .apk souboru. Aplikace puvodnˇ ˚ e využívala tˇrí externích knihoven v podobˇe .jar souboru, ˚ které jsme ovšem pozdˇeji odstranili. Duvo˚ dem k tomuto kroku byla neschopnost nástroje pro vytváˇrení instalaˇcního souboru s certifikací tyto knihovny najít. Pro vyˇrešení tohoto problému jsme se pokusili explicitnˇe definovat cesty k tˇemto .jar souborum. ˚ Díky tomu byla úspˇešnˇe dokonˇcena tvorba .apk souboru, a tudíž jsme se domnívali, že je problém vyˇrešen. Situace byla ale taková, že vzniklý výstup neobsahoval zmínˇené knihovny vubec, ˚ a proto jejich používání v programu zpusobilo ˚ vždy jeho spadnutí. Nakonec jsme došli k závˇeru, že nejlepší bude je z projektu odstranit. Další nesnází bylo zvýraznování ˇ komponent se špatnˇe zadanými vstupy od uživatele. Android za tímto úˇcelem nabízí u editovacích polí metodu setError, která do nˇej pˇri zavolání vloží ikonku vykˇriˇcníku a ve vyskakovací bublinˇe zobrazí chybovou hlášku. Oba tyto prvky pˇrinesly více problému˚ než užitku. Duvod, ˚ proˇc je ikonka na obtíž, je zvˇetšování daného prvku grafického rozhraní. K tomuto jevu dochází pˇredevším u menších komponent, které mají vlastní „hint“, jenž ve vˇetšinˇe pˇrípadu˚ zcela vyplnuje ˇ jejich obsah. Editovací pole se pak nelogicky (navzdory jasnˇe definovaným rozmˇerum) ˚ snaží svoji velikost pˇrizpusobit ˚ jak „hintu“, tak i chybové ikonˇe, což ve výsledku vyústí v narušení rozmístˇení jednotlivých komponent. Bublina s chybovou hláškou se naproti tomu chová velmi nedeterministicky. Jednou se zobrazí tak, jak cˇ lovˇek oˇcekává, podruhé se
36
4. I MPLEMENTACE nezobrazí vubec, ˚ potˇretí se namísto horizontální polohy umístí vertikálnˇe a poˇctvrté se ukáže jenom její cˇ ást a zbytek pokraˇcuje nˇekde mimo displej. Funkci setError jsme se tedy vyhnuli a místo ní jsme použili metodu setColorFilter. Ta dokáže libovolnému prvku grafického rozhraní nastavit barevný filtr, který zmˇení jeho barvu. Tímto zpusobem ˚ jednoduše dosáhneme zvýraznˇení chybných komponent bez vedlejších efektu. ˚ Poslední úskalí vývoje, které popíšeme, je nefunkˇcnost konzole softwaru ConnectBot. Po dokonˇcení implementace této aplikace do našeho projektu jsme pˇri testování na smˇerovaˇci od MikroTiku zjistili, že se sice na sít’ové zaˇrízení prostˇrednictvím SSH pˇripojíme, ovšem nedostane se nám žádné reakce po zadání jakéhokoli pˇríkazu. Dlouho jsme hledali chybu v našem kódu, jelikož pˇri použití originálního ConnectBotu staženého z Google Play, který byl naposledy aktualizován v roce 2010, vše fungovalo správnˇe [24]. Protože se nám nedaˇrilo dohledat žádnou chybu, zkusili jsme ovˇerˇ it funkˇcnost samotného ConnectBotu staženého z Google Code [25]. Pˇrekvapivˇe jsme dospˇeli ke stejným chybám jako v pˇrípadˇe naší implementace. Poslední možností tedy bylo znovu stáhnout zdrojové kódy ConnectBotu a doufat, že tato chyba byla odstranˇena. Po opˇetovné implementaci jsme již úspˇešnˇe mohli do konzole zadávat filtrovací pravidla.
37
5 Závˇer Cílem této bakaláˇrské práce bylo vytvoˇrit generátor základních filtrovacích pravidel pro konfiguraci firewallu˚ na sít’ových zaˇrízeních pro mobilní platformu Android. Tento úkol jsme splnili ve všech smˇerech. Bˇehem nˇekolika mˇesícu˚ jsme úspˇešnˇe vytvoˇrili mobilní aplikaci pro platformu Android s názvem Firewall Builder, která korektnˇe generuje elementární filtrovací pravidla a díky implementaci již existujícího SSH klienta (ConnectBot) tato pravidla snadno aplikuje na sít’ovém zaˇrízení. Firewall Builder byl prubˇ ˚ ežnˇe testován nˇekolika uživateli a na základˇe jejich zkušenosti byl i upravován. Pro globálnˇejší otestování jsme ho umístili na Google Play. Zde jsme alesponˇ pˇetkrát nahráli novou aktualizovanou verzi a prubˇ ˚ ežnˇe jsme kontrolovali, zdali nˇekterý uživatel nemá pˇripomínky cˇ i návrhy k vylepšení celého programu. Firewall Builder je s velkou pravdˇepodobností první aplikace, která sjednocuje všechny technologie pro filtrování paketu˚ na bázi pravidel. Díky této práci jsme se pˇredevším nauˇcili techniky pro rˇ ízení toku v síti za použití filtrovacích pravidel, základní principy programovaní softwaru v OS Android a jak publikovat aplikace na Google Play. Do budoucna by mohl být Firewall Builder implementován na mobilní zaˇrízení s operaˇcním systémem iOS a Windows Phone.
38
6 Pˇríloha
ˇ Obrázek 6.1: Analytický model diagramu tˇríd znázornující podstatné tˇrídy projektu vˇcetneˇ balíku, ˚ do kterých náleží
39
ˇ 6. P RÍLOHA
Obrázek 6.2: Kontrola wi-fi pˇrijímaˇce
Obrázek 6.3: Konfigurace standard ACL
Obrázek 6.4: Nastavení aplikace
Obrázek 6.5: Editace vygenerovaného pravidla
Obrázek 6.6: Manipulace s pravidly v databázi
Obrázek 6.7: Seznam použitých sít’ových zaˇrízení
40
7 Seznam použitých zdroju˚ [1] WATKINS, Michael a Kevin WALLACE. CCNA security: official exam certification guide. 7. pˇreprac. vydání. Indianapolis: Cisco Press, c2008, xxxv, 637 s. ISBN 978-1-58720-220-9. [2] FRAHIM, Jazib a Omar SANTOS. Cisco ASA: all-in-one firewall, IPS, and VPN adaptive security appliance. 7. pˇreprac. vydání. Indianapolis, Ind.: Cisco Press, c2006, xxxii, 798 p. ISBN 15-8705209-1. [3] Cisco Networking Academy. Cisco [online]. 2006 [cit. 2012-1103]. Dostupné z:
. [4] Iptables(8): Linux man page. Die.net [online]. [17 June 2003] [cit. 2012-11-03]. Dostupné z: . [5] Manual:IP/Firewall/Filter. MikroTik [online]. 2011 [cit. 2012-1103]. Dostupné z: . [6] MIF. Nejpoužívanˇejší mobilní platformou je podle Seznamu Android. Novinky.cz [online]. 2012 [cit. 2012-11-03]. Dostupné z: . [7] MURPHY, Mark L. Android 2: pruvodce ˚ programováním mobilních aplikací. Vyd. 1. Brno: Computer Press, 2011, 375 s. ISBN 978-80251-3194-7. ˇ Jakub. Hackeˇri se dostali k citlivým údajum [8] KYNCL, ˚ miliónu˚ uživatelu˚ Sony PlayStation. Novinky.cz [online]. 2011 [cit. 201211-09]. Dostupné z: . ˇ [9] CTK. Sony potvrdila, že její weby opˇet napadli hackeˇri. Novinky.cz [online]. 2011 [cit. 2012-11-09]. Dostupné z:
7. S EZNAM POUŽITÝCH ZDROJ U˚ w.novinky.cz/internet-a-pc/bezpecnost/235337-sony-potvrdil a-ze-jeji-weby-opet-napadli-hackeri.html>. [10] Access Control List. Samuraj-cz [online]. 2007 [cit. 2012-11-09]. Dostupné z: . [11] Access Control Lists (ACLs). Orbit Computer Solutions [onc line]. 2012 [cit. 2012-11-09]. Dostupné z: . [12] DAVIS, David. What you need to know about Cisco IOS accesslist filtering. TechRepublic [online]. 2008 [cit. 2012-11-09]. Dostupné z: . [13] Access Point ACL Filter Configuration Example. Cisco [online]. 2006. vyd. [cit. 2012-11-09]. Dostupné z: . [14] BOTOŠ, Csaba. Vše o iptables: úvod. Root.cz [online]. 2006 [cit. 2012-11-09]. Dostupné z: . ˇ ˇ CEK, [15] PETRÍ Miroslav. Stavíme firewall (1). Root.cz [online]. 2001 [cit. 2012-11-09]. Dostupné z: . c [16] Ip access-list (named). HowToNetwork [online]. 2006-2012 [cit. 2012-11-09]. Dostupné z: . [17] ŠTRAUCH, Adam. Konfigurace firewallu na RouterOS od Mikrotiku. Root.cz [online]. 2011 [cit. 2012-11-09]. Dostupné z: . c [18] FirewallBuilder [online]. 2000-2012 [cit. 2012-11-09]. Dostupné z: . 42
7. S EZNAM POUŽITÝCH ZDROJ U˚ [19] Android Terminal. Google Play [online]. 2012 [cit. 2012-11-09]. Dostupné z: . [20] Terminal IDE. Google Play [online]. 2012 [cit. 2012-11-09]. Dostupné z: . [21] Terminal Emulator. Google Play [online]. 2012 [cit. 2012-11-09]. Dostupné z: . [22] SSH Tunnel. Google Play [online]. 2012 [cit. 2012-11-09]. Dostupné z: . [23] SSHDroid. Google Play [online]. 2012 [cit. 2012-11-09]. Dostupné z: . [24] ConnectBot. Google Play [online]. 2010 [cit. 2012-11-09]. Dostupné z: . [25] Connectbot. Google Code [online]. 2010 [cit. 2012-11-09]. Dostupné z: . c [26] Why Java?. Thousand Codes [online]. 2010-2011 [cit. 2012-1206]. Dostupné z: . 43
7. S EZNAM POUŽITÝCH ZDROJ U˚ c [27] Java SE Technical Documentation. Oracle [online]. 2011 [cit. 2012-12-06]. Dostupné z: . [28] Android, the world’s most popular mobile platform. Anc droid Developers [online]. 2012 [cit. 2012-11-30]. Dostupné z: . [29] PALLI, Craig. 10 Reasons to Develop for Android First. Marketing Pilgrim [online]. 2012, roˇc. 2012, cˇ . 05 [cit. 2012-12-06]. Dostupné z: . c [30] Naming a Package. Oracle [online]. 1995, 2012 [cit. 2012-1109]. Dostupné z: . c [31] Fakulta informatiky Masarykovy univerzity [online]. 2008 [cit. 2012-11-09]. Dostupné z: . c [32] MikroTik [online]. 2000 - 2012 [cit. 2012-11-24]. Dostupné z: . [33] ŠTRAUCH, Adam. Mikrotik: seznámení s Wi-Fi krabiˇckou. Root.cz [online]. 2008 [cit. 2012-11-24]. Dostupné z: . [34] Activity. Android Developers [online]. 2012 [cit. 2012-11-30]. Dostupné z: . [35] Content Providers. Android Developers [online]. 2012 [cit. 201211-30]. Dostupné z: . [36] Content Providers Basics. Android Developers [online]. 2012 [cit. 2012-11-30]. Dostupné z: . [37] Service. Android Developers [online]. 2012 [cit. 2012-11-30]. Dostupné z: . 44
7. S EZNAM POUŽITÝCH ZDROJ U˚ [38] Intent. Android Developers [online]. 2012 [cit. 2012-11-30]. Dostupné z: . [39] The Art of Google Play; Increase Android App Discovery. AppsGeyser Blog [online]. 2012 [cit. 2012-12-27]. Dostupné z: .
45
