Bc. Antonín Procházka

Transkript

1 ƒeské vysoké u ení technické v Praze Fakulta elektrotechnická Katedra po íta Diplomová práce Distribuovaný WiFi Hot-Spot s platební bránou Bc. Antonín Procházka Vedoucí práce: Ing. Jan Kubr Studijní program: Elektrotechnika a informatika, strukturovaný, Navazující magisterský Obor: Výpo etní technika kv ten 2010

2 iv

3 Pod kování Na tomto míst bych rád pod koval Ji ímu Slámovi, mému p íteli a spolupracovníkovi na provozování sít AG-Net, za poskytnutí asu, podpory a technických prost edk k uskute n ní tohoto projektu a sepsání této diplomové práce a panu inºenýru Janu Kubrovi, vedoucímu této diplomové práce, za vynaloºené úsilí a cenné rady poskytnuté b hem práce na projektu a psaní tohoto textu. V neposlední ad bych rád znovu pod koval své matce, dal²ím len m rodiny a p átel m za trp livost a ve²kerou podporu, kterou mi poskytli nejen nyní v záv ru, ale i v celém pr b hu mého studia. Znovu také vzpomínám svého otce, který m b hem svého ºivota dokázal p ipravit na cestu, kterou se nyní ubírám. v

4 vi

5 Prohlá²ení Prohla²uji, ºe jsem práci vypracoval samostatn a pouºil jsem pouze podklady uvedené v p iloºeném seznamu. Nemám závaºný d vod proti uºití tohoto ²kolního díla ve smyslu Ÿ60 Zákona. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o zm n n kterých zákon (autorský zákon). V Praze dne... vii

6 viii

7 Abstract This thesis describes the analysis and implementation of HotSpot service with the possibility of payments via SMS at a decentralized WiFi network built on a Mikrotik platform. Further, it provides a summary of other payment options for this service and describes the characteristics of existing systems for HotSpot service for centralized networks. The thesis deals with the deployment of the service to the Internet Service Provider's network called AG-Net, but provides sucient information to allow the deployment of the service to any network built on the same platform. It begins with a verbal description of the problem and initial state of the network. After that follows its elaboration in the form of verbal denition of system requirements. Next parts are gradually dealing with each of service components, which are the WiFi network, Mikrotik platform, RADIUS - User Dialup Service for Remote Authentication and instant payment methods. Finally, it describes the deployment of the service to the AG-Net network. Abstrakt Tato práce popisuje analýzu a implementaci sluºby HotSpot s moºností platby pomocí SMS v decentralizované WiFi síti postavené na platform Mikrotik. Dále práce uvádí shrnutí dal²ích moºností plateb za tuto sluºbu a popisuje vlastnosti stávajících systém pro sluºbu HotSpot ur ených pro centralizované sít. Práce se zabývá nasazením sluºby do sít poskytovatele internetového p ipojení AG-Net, ale uvádí dostate né mnoºství informací pro moºnost nasazení této sluºby do libovolné sít postavené na stejné platform. Nejprve je uveden popis problému a výchozího stavu sít. Následuje rozpracování problému do podoby slovn formulovaných poºadavk na systém. Dal²í ásti se postupn zabývají jednotlivými komponentami sluºby, kterými jsou WiFi sí, platforma Mikrotik, Uºivatelská vytá ená sluºba pro vzdálenou autentizaci RADIUS a metody instantních plateb. Na záv r je popsáno vlastní nasazení sluºby do sít AG-Net. ix

8 x

9 Obsah Seznam obrázk Seznam tabulek xv xvii 1 Popis problému, specikace cíle 1 I Analýza poºadavk 3 2 Nutné funk ní poºadavky (Must Have) Ú tování podle doby p ipojení Platba pomocí Premium-SMS Informace zobrazující se neautorizovaným uºivatel m Volitelné funk ní poºadavky (Nice To Have) Dal²í metody ú tování Dal²í metody platby Omezení neplatících stálých zákazník Zpracování ú etních doklad P ístup k vybraným sluºbám bez placení Nefunk ní poºadavky Kongurace RouterOS Bezpe nost sít Monitorování systému Uºivatelské role 5 II Technologie x - WiFi 7 6 Topologie Ad-Hoc Infrastruktura (Infrastructure) Wireless Distribution System (WDS) Kombinace Fyzická vrstva b g a, h n Shrnutí xi

10 8 Zabezpe ení MAC autentizace Wired Equivalent Privacy (WEP) WiFi Protected Access (WPA2) WPA2 se sdíleným klí em (WPA2-PSK) WPA2 s roz²í ením EAP (WPA2-EAP) HotSpot 13 III Platforma Mikrotik Mikrotik RouterBOARD Mikrotik RouterOS Správa RouterOS Gracké uºivatelské rozhraní Winbox Textové uºivatelské rozhraní Webové rozhraní Vzorová kongurace Ve ejné rozhraní Rozhraní WiFi Sí ová vrstva HotSpot Správa uºivatelských oprávn ní IV Uºivatelská vytá ená sluºba pro vzdálenou autentizaci (RADIUS) Popis RADIUS protokolu pro autentizaci RADIUS vs. RouterOS Test RADIUS serveru Ov ení spolupráce s RouterOS Zát ºový test serveru Clutch.Radius Dynamické vytvá ení uºivatelských oprávn ní Analýza User Manageru Návrh User Manageru Implementace User Manageru Testování User Manageru V Instantní platby 37 xii

11 16 SMS platby Popis platby pomocí SMS Výb r SMS agregátora Modul pro SMS platby Analýza modulu pro SMS platby Návrh modulu pro SMS platby Implementace modulu pro SMS platby Testování modulu pro SMS platby Dal²í moºnosti instantních plateb Platba kreditní kartou Platba pomocí elektronické pen ºenky Platba prost ednictvím internetového bankovnictví VI Vyhodnocení a reálné nasazení Testování Pilotní provoz Komunikace s SMS agregátorem Autentiza ní sluºba P ipojení stálých uºivatel P ipojení stálých instantních uºivatel P ipojení náhodných instantních uºivatel Monitorování sít a sluºeb Pokrytí poºadavk Nutné funk ní poºadavky Volitelné funk ní poºadavky Nefunk ní poºadavky Záv r Rejst ík Seznam literatury 59 A Dostupná e²ení HotSpot 61 A.1 Provisio MyPublicHotSpot A.2 Antamedia HotSpot Software A.3 NoCatAuth a NoCatSplash A.4 CoovaChilli A.5 WiFiDog A.6 Public IP ZoneCD Gateway xiii

12 B Srovnání vybraných SMS agregátor 65 B.1 Nabídky oslovených agregátor B.1.1 Pay SMS lite - sms.sluzba.cz B.1.2 sms.cz Premium SMS - gonet B.1.3 mobilniplatby.cz B.1.4 Erika, a.s B.1.5 Materna mobilní platby B.1.6 PR SMS - Media Support s.r.o B.1.7 premiumsms.cz B.1.8 Tanger PRSMS B.1.9 Dal²í agregáto i B.2 Výb r agregátora C Postup nasazení serveru Clutch.Radius 69 C.1 Prerekvizity C.2 P íprava databáze C.3 Instalace sluºby D Postup nasazení sluºby HotSpot User Manager 71 D.1 Prerekvizity D.2 P íprava databáze D.3 Instalace sluºby E Obsah p iloºeného CD 73 xiv

13 Seznam obrázk 1 Topologie sít AG-Net WiFi - Ad-Hoc WiFi - Basic Service Set (BSS) WiFi - Extended Service Set (ESS) WiFi - Wireless Distribution System (WDS) WiFi - Kombinovaná topologie Ilustrace procesu autentizace protokolem RADIUS Test RADIUS serveru - kongurace prost edí HotSpot User Manager - model komponent HotSpot User Manager - model nasazení HotSpot User Manager - business model HotSpot User Manager - model dat HotSpot User Manager - t ídy jádra HotSpot User Manager - aspekty HotSpot User Manager - t ídy jádra SMS Gateway - business model SMS Gateway - model dat SMS Gateway - stavový diagram platby SMS Gateway - business t íd Srovnání nabízených provizí SMS agregátor xv

14 xvi

15 Seznam tabulek 1 RouterOS - licence Správa RouterOS SMS Gateway - tabulka pokrytí atribut sms_sessions stavy platby Tabulka pokrytí nutných funk ních poºadavk Tabulka pokrytí nefunk ních poºadavk Cenové hladiny SMS agregátor v K xvii

16 xviii

17 1 Popis problému, specikace cíle Pod obchodní zna kou AG-Net, internet-wi.eu je provozována bezdrátová sí pro pevné p ipojení domácností k síti Internet. V nabídce bylo dosud pouze stálé p ipojení za m sí ní poplatek vysoký dle poskytnuté rychlosti p ipojení. Pro roz²í ení nabídky sluºeb je t eba v síti implementovat sluºbu, která zákazník m nabídne moºnost asov omezeného p ipojení. Základem pro poskytnutí takové sluºby je umoºnit zákazníkovi co nejsnaz²í zp sob platby za takovou do asnou sluºbu. K tomuto ú elu slouºí hned n kolik produkt, jako jsou SMS platby, platby kreditní kartou, elektronická pen ºenka a dal²í. V²e je t eba zajistit s pouºitím stávající infrastruktury a s ohledem na bezpe nost. Sí je v sou asnosti provozována na za ízeních Mikrotik RouterBOARD s opera ním systémem Mikrotik RouterOS. Sí je tvo ena dvanácti uzly propojenými výhradn bezdrátovou sítí v pásmu 5GHz. Klienti jsou p ipojeni v t²inou v pásmu 5GHz, výjime n 2,4GHz. Sí je do internetu p ipojena pomocí t í poskytovatel. Kaºdý poskytovatel je p ipojen do jiného bodu v síti. K dispozici je jeden server s opera ním systémem Windows XP, který v sou asnosti slouºí k monitorování sít pomocí monitorovacího software Mikrotik Dude. Schéma sít je znázorn no na obrázku 1. 1 Obrázek 1: Topologie sít AG-Net

18 2 1 POPIS PROBLÉMU, SPECIFIKACE CÍLE

19 3 ƒást I Analýza poºadavk Protoºe as na tento projekt je omezený a poºadavk je mnoho, byly poºadavky rozd leny na nutné a volitelné. 2 Nutné funk ní poºadavky (Must Have) Tyto poºadavky je t eba splnit z po átku. Bez nich systém nem ºe fungovat. 2.1 Ú tování podle doby p ipojení 1. Zákazník bude mít moºnost zakoupit si dle ceníku p ipojení na ur itou dobu. 2. Zakoupená doba se bude po ítat od prvního p ihlá²ení. Není moºné zákazníkovi ú tovat dobu mezi platbou a p ipojením. 3. Zákazník bude mít moºnost opakovaného p ipojení po celou zaplacenou dobu. Není moºné, aby byl v p ípad výpadku uºivatel nucen znovu platit, pokud je²t neuplynula doba, kterou jiº zaplatil. A to a uº se jedná o výpadek na stran zákazníka i o výpadek na stran poskytovatele sluºby. 2.2 Platba pomocí Premium-SMS 4. Je t eba, aby systém p ijímal platby pomocí SMS zpráv. Tento zp sob platby umoºní komukoliv s mobilním telefonem instantní placený p ístup do sít s minimálními asovými a technickými nároky na uºivatele. 2.3 Informace zobrazující se neautorizovaným uºivatel m Na WiFi musí mít p ístup kaºdý uºivatel bez ohledu na to, zda má zrovna zaplacené p ipojení. Dále existují následující moºnosti: 5. Uºivatel platí m sí ní pau²ál (stálý zákazník) a má na aktuální období zaplaceno sí se pro n j stává transparentní a je mu umoºn n p ístup na internet. Nesmí být obt ºováni poºadavky o autorizaci i nevyºádanými informacemi. 6. Uºivatel, který má v tuto chvíli zaplaceno pomocí SMS i jiné metody instantní platby a je jiº autorizován sí se pro n j stává transparentní a je mu umoºn n p ístup na internet. Nesmí být obt ºováni poºadavky o autorizaci i nevyºádanými informacemi. 7. Uºivatel neplatí m sí ní pau²ál - nejde o stálého uºivatele p i pokusu o p ístup na web je p esm rován na stránku s informacemi o moºnostech p ipojení a je mu umoºn n p ístup na formulá pro p ípad platby SMS nebo kreditní kartou.

20 4 4 NEFUNKƒNÍ POšADAVKY 3 Volitelné funk ní poºadavky (Nice To Have) Volitelné poºadavky je moºné implementovat pozd ji. Systém m ºe fungovat i bez nich. 3.1 Dal²í metody ú tování 9. Uºivatel mimo asového omezení dostane také limit na mnoºství staºených dat. P ipojení mu pak bude zablokováno podle toho, zda d íve uplyne stanovená doba, i zda p enese stanovené mnoºství dat. 10. Zákazník bude mít moºnost zvolit si p enosovou rychlost. Vý²e platby se pak bude odvíjet od rychlosti. 3.2 Dal²í metody platby Vedle moºnosti placení pomocí SMS by m lo smysl poskytnout také dal²í moºnosti platby. Zde jsou uvedeny n které z nich. 11. Uºivatel bude mít moºnost platby kreditní kartou. 12. Uºivatel bude mít moºnost platby pomocí elektronické pen ºenky. (Sluºby PayPal, PaySec, PayPay, Seznam Pen ºenka a dal²í.) 13. Uºivatel bude mít moºnost platby pomocí internetového bankovnictví. 3.3 Omezení neplatících stálých zákazník 14. Uºivatel platí m sí ní pau²ál (stálý zákazník) a nemá na aktuální období zaplaceno p i pokusu o p ístup na web je p esm rován na stránku s informací o nedoplatku, p ístup na internet mu m ºe být omezen i zablokován podle vý²e dluhu a doby prodlení. Míru omezení volí administrátor individuáln. 3.4 Zpracování ú etních doklad 15. Uºivatel bude mít moºnost moºnost získat doklad o zaplacení staºením z webu. 3.5 P ístup k vybraným sluºbám bez placení 16. Po dohod s provozovateli n kterých sluºeb bude moºné poskytnout zákazníkovi p ístup k t mto sluºbám zdarma. Prot by tak plynul od poskytovatele dané sluºby. Jde nap. o vyhledávání dopravního spojení, hledání v mapách, adresá e rem, zpravodajské portály, aj. 4 Nefunk ní poºadavky Nefunk ní poºadavky specikují takové vlastnosti systému, které nevyplývají p ímo ze zadání poºadovaných funkcí, ale jsou nutné pro jeho správné fungování.

21 4.1 Kongurace RouterOS Kongurace RouterOS 17. Uzly sít nyní tvo í routery s opera ním systémem Mikrotik RouterOS. Je proto nutné nastudovat moºnosti této platformy a navrhnout vhodnou konguraci, která bude spl ovat v²echny poºadavky. 4.2 Bezpe nost sít 18. Je t eba zajistit nejvy²²í moºnou bezpe nost v síti. 4.3 Monitorování systému 19. V p ípad výpadku n kterých ástí sít musí být administrátor sít na tento stav upozorn n. 20. V p ípad neo ekávaných chyb p i zpracování uºivatelských poºadavk musí být administrátor systému na tento stav upozorn n. 21. Zm ny stavu sít a pokusy o zm nu stavu sít musí být zp tn dohledatelné. Jde o zm ny v nastavení a p ipojování a odpojování uzl sít. 22. Poºadavky uºivatel musí být zp tn dohledatelné. Jde o platby a pokusy o autentizaci. 5 Uºivatelské role Stálý pau²ální uºivatel platí pravidelný m sí ní poplatek za p ipojení a je mu umoºn no stálé transparentní p ipojení k internetu. Stálý instantní uºivatel je trvale p ipojený k síti, ale vyuºívá jí pouze náhodn na základ instantní platby i bezplatn v omezeném rozsahu. Náhodný instantní uºivatel vyuºívá sí do asn na základ instantní platby i bezplatn v omezeném rozsahu. Administrátor sít spravuje sí a stará se o její bezproblémový chod. Administrátor systému spravuje backend celého systému, middleware pro spolupráci se systémy t etích stran a stará se o bezproblémový chod celého systému.

22 6 5 UšIVATELSKÉ ROLE

23 7 ƒást II Technologie x - WiFi Standard , b ºn známý jako WiFi, se svými dodatky je v po íta ových sítích podobn revolu ní technologie jako mobilní telefon v telekomunikacích. V roce 1997 oprostil po íta ové sít od kabel a umoºnil tak ²irokopásmové p ipojení mobilním za- ízením. P vodní ur ení této technologie je pro vnit ní uºití, ale postupem asu se rozvinulo její vyuºití pro venkovní spoje. P inesla tak nap íklad rychlý internet do míst, kam se pomocí kabelových technologií dostal aº o n kolik let pozd ji. Mimo na²e území existuje nespo et míst, kde je WiFi p ipojení jediným zdrojem internetové konektivity. Dnes se mimo soukromých, remních a univerzitních bezdrátových sítí vyskytuje také mnoho sítí ve ejných - nap. v kavárnách, restauracích, hotelích, ale i v autobusech, vlacích a na palubách dopravních letadel. 6 Topologie WiFi dnes umoº uje podle standardu t i zp soby zapojení. Mimo tyto základní existují je²t od jednotlivých výrobc r zná proprietární e²ení. Kaºdý zp sob propojení bezdrátových za ízení má svá pro a proti. Spole nou vlastností v²ech topologií je omezení plynoucí z média, které tato technologie vyuºívá. Na jednom komunika ním kanále m ºe komunikovat vºdy pouze jedno za ízení v jednom okamºiku. Díky tomu také není po jednom kanále moºný pln duplexní provoz. 6.1 Ad-Hoc Ad-Hoc, nebo také Peer-To-Peer topologie je vhodná pouze pro propojení men²ího mnoºství za ízení na krátkou vzdálenost. Její název vyplývá ze skute nosti, ºe k jejímu vytvo ení není pot eba ºádná výchozí infrastruktura. Sí se sestavuje pouhou kongurací koncových uzl sít. Pouºívá se jako do asné e²ení i jako alternativa k Bluetooth pro bezdrátové p ipojení periferií. Jde o decentralizovanou strukturu s dynamickou správou sm rování. Jelikoº v²echna za ízení sdílí stejné médium a neexistuje zde ídící uzel, dochází k astým kolizím, coº sniºuje propustnost. Obrázek 2: WiFi - Ad-Hoc

24 8 6 TOPOLOGIE 6.2 Infrastruktura (Infrastructure) Základním stavebním kamenem této topologie je takzvaný Basic Service Set (BSS, obr. 3) identikovaný pomocí názvu Service Set ID (SSID) a sestávajícího z p ístupového bodu (Access Point, AP) a klient (Client, Station) k tomuto bodu p ipojených. P ístupový bod pravideln vysílá své SSID. Díky tomu m ºe klient danou sí vyhledat a následn se k síti p ipojit. V²ichni klienti zde komunikují p es p ístupový bod. To znamená, ºe jedinou fyzickou podmínkou ke komunikaci s libovolným za ízením v síti je dostupnost p ístupového bodu. P ístupový bod do jisté míry ídí provoz v síti a sniºuje tak mnoºství kolizí. Dosahuje se tak vy²²í propustnosti. P ístupový bod bývá obvykle p ipojen k metalické i optické síti, která nabízí vlastní sluºby i p ipojení k internetu. Toto propojení m ºe nabídnout i n které z klientských za ízení, ímº se ale propustnost sít sníºí na polovinu, protoºe kaºdý paket od tohoto klienta musí vºdy p ístupový bod opakovat. Obrázek 3: WiFi - Basic Service Set (BSS) Jednotlivé BSS lze navíc propojit do tzv. Extended Service Set (ESS, obr. 4). Jednotlivé p ístupové body jsou propojeny pomocí metalické i optické sít a sdílejí stejné SSID. Mohou také sdílet stejný kanál. Pouºitím r zných kanál lze zvý²it propustnost. Obrázek 4: WiFi - Extended Service Set (ESS)

25 6.3 Wireless Distribution System (WDS) Wireless Distribution System (WDS) Tato topologie je roz²í ením p edchozí. Existují situace, kdy není moºné nebo je p íli² nan n i technicky náro né propojit p ístupové body pomocí kabel. Topologie WDS umoº uje toto propojení pomocí vlastního média bezdrátové sít. Nevýhodou je, ºe se na kaºdé skoku sniºuje propustnost o polovinu oproti p edchozímu. Obrázek 5: WiFi - Wireless Distribution System (WDS) 6.4 Kombinace Zmín né topologie lze libovoln kombinovat a vytvo it tak propojení, které z hlediska pokrytí i propustnosti zajistí spln ní poºadavk. Na obrázku 6 je moºné vid t men²í p íklad. Obrázek 6: WiFi - Kombinovaná topologie 7 Fyzická vrstva Fyzické propojení je moºné uskute nit pomocí n kolika standardních technologií. N které, více roz²í ené, fungují na frekvencích, které je moºné voln vyuºívat. Jiné, draº²í, ale

26 10 7 FYZICKÁ VRSTVA rychlej²í fungují v pásmech, na které je t eba získat licenci od ƒeského telekomunika ního ú adu. Co se tý e klientských za ízení, je volba jasná. V²echna klientská za ízení vyuºívají pouze voln dostupné frekvence. Volba licencovaného pásma pak zbývá pouze pro páte ní sí, která není p edm tem této práce. V²echny dále zmín né technologie jsou dodatky k p vodní technologii IEEE z roku Tato p vodní technologie umoº uje p enos dat pomocí radioreléových spoj na frekvenci 2,4 GHz i infra erveného zá ení a s modulacemi FHSS, resp. DSSS dosahuje teoretickou p enosovou rychlost 1, resp. 2 Mbit/s. Mezi rychlostmi lze manuáln i automaticky p epínat. ƒím niº²í je pouºitá rychlost, tím více je spoj odolný v i ru²ení a tím del²ích vzdáleností lze dosahovat. Zmín né dodatky upravují zp sob modulace, p ípadn pouºité frekven ní spektrum a vysílací výkon, ímº zvy²ují pouºitelnou p enosovou rychlost. V dal²ích dodatcích je také upravena bezpe nost bezdrátových spoj, která bude probrána dále v této práci. Spolu s dodatky je x rodina standard, které sdílejí stejný komunika ní protokol, pouze vyuºívají r zná frekven ní spektra a r zné modulace. Následující vý et není úplný, ale obsahuje v²echny standardy, které se b ºn pouºívají na na²em území v bezlicen ním frekven ním pásmu. Ve standardu a jeho dodatcích lze také narazit na detaily, které nejsou nijak zmín ny a denovány. V takových p ípadech záleºí na jednotlivých výrobcích, jak danou funkci implementují b Tento dodatek p idává k teoretickým rychlostem je²t rychlosti 5,5 a 11 Mbit/s a pouºitelnou vzdálenost ve volném prost edí zvy²uje aº na 12 km. Tato technologie také jako první nesla dnes v²eobecn p ijatý a v²emi pouºívaný název WiFi. Pro svou vysokou propustnost a velkou spolehlivost byla p ijata jako první technologie pro bezdrátové lokální po íta ové sít (Wireless LAN). Tento standard byl publikován v roce 1999 a první WiFi produkty se na trhu za aly objevovat o rok pozd ji g Standard g je roz²í ením standardu b a je s ním téº zp tn kompatibilní. Pro rychlosti 1, 2, 5,5 a 11 Mbit/s pouºívá stejné schéma jako b. Dále p idává rychlosti 6, 9, 12, 18, 24, 36, 48 a 54 Mbit/s, pro které pouºívá modulaci OFDM. Tento standard vychází ze standardu a (viz dále). Pouºívá stejné rychlosti i modulaci, pouze namísto frekvence 5 GHz vyuºívá p vodních 2,4 GHz. Kv li zp tné kompatibilit s b je ale zatíºen nedostatky, které sniºují jeho propustnost oproti a p ibliºn o 21%. Dal²í nevýhodou zp tné kompatibility je, ºe kdyº se v jedné g síti objeví by jen jedno za ízení, které podporuje pouze b, p epne se celá sí na jednu z rychlostí tohoto p vodního standardu. Standard g byl p edstaven v roce Za ízení podporující tento standard se ozna ují jako b/g pro zd razn ní moºnosti vyuºití p vodního standardu b a, h Standard a, jak jiº bylo e eno, vyuºívá namísto p vodní frekvence 2,4 GHz nov frekvenci 5 GHz. Poskytuje teoretické p enosové rychlosti 6, 9, 12, 18, 24, 36, 48 a 54 Mbit/s. Rychlosti i modulaci standardu opou²tí. Pouºití nové frekvence

27 n 11 p iná²í výhodu v místech, kde je p vodní pásmo 2,4 GHz siln ji vyuºito. Zárove ale díky krat²í vlnové délce nemá takovou schopnost prostupu p ekáºkami a dosah této technologie je tedy teoreticky niº²í neº u g. Prakticky to ale platí pouze p i pouºití niº²ích p enosových rychlostí. Standard a byl p edstaven zárove se standardem b v roce Jeho roz²í ení ale bránila generální licence pro bezlicen ní vyuºití pásma 5 GHz, která u nás aº do roku 2005 omezovala vyuºití tohoto pásma pouze na sít provozované uvnit budov. Po uvoln ní tohoto pásma pro venkovní vyuºití nastal boom této technologie. Vedlo k tomu velké zaru²ení pásma 2,4 GHz, ke kterému do té doby do²lo. Pro korektní vyuºití pásma 5 GHz na na²em území je nutné vyuºívat n kolik vylep²ení popsaných ve standardu h. Jsou jimi: ˆ Dynamický výb r frekvence (DFS - Dynamic Frequency Selection), díky kterému p ístupový bod p ed zahájením provozu prov í radiové spektrum a vybere si pro dal²í fungování takový kanál, který je nejmén vytíºen a na kterém v danou chvíli nepracuje ºádný radar i satelit. ˆ ízení vysílacího výkonu (TPC - Transmit Power Control), které omezuje interferenci mezi bezdrátovými sít mi samotnými i mezi nimi a dal²í technikou pracující ve stejném frekven ním pásmu n Tento dodatek je nejmlad²ím z rodiny x. Díky úprav fyzické a pod ásti linkové vrstvy je schopný dosahovat rychlostí v ádu stovek Mbit/s. V sou asnosti je nejvy²²í dostupná teoretická p enosová rychlost 600 Mbit/s. Mimo odli²né modulace vyuºívá také technologii MIMO (Multiple-Input Multiple-Output), kdy je za pouºití více antén na kaºdém za ízení vyuºito r zné ²í ení signálu odrazem od p ekáºek, ímº se rapidn zvy²uje propustnost. Standard n byl IEEE uve ejn n v roce 2009, ale za ízení ho pro jeho p evratnou propustnost vyuºívají jiº od roku 2007, kdy byl uveden návrh tohoto standardu. 7.5 Shrnutí V klientských za ízeních se v sou asnosti vyuºívá standard b, g, a a nov n. Takto jsou se azeny chronologicky podle doby, kdy byly uvád ny na ná² trh a zárove podle své p enosové rychlosti a dosahované vzdálenosti. Star²í za ízení tedy um jí pouze b, nov j²í postupn p idávají dal²í standardy, nejnov j²í umoº ují vyuºití v²ech ty t chto technologií. P ístupový bod tedy musí kaºdopádn nabízet normu b. S výhodou m ºeme ale vyuºít i technologie g, která je schopná s b spolupracovat. Pro obecné pokrytí klientských za ízení jiº ale nelze vyuºít a ani n, protoºe bychom znemoºnili p ístup na sí pomocí star²ích za ízení. Poslední dv technologie jsou vyuºitelné pouze v p ípad, kdy dop edu víme, ºe se v síti nebudou vyskytovat za ízení, které tyto dv technologie nepodporují. Takový p ípad nastává nap íklad ve chvíli, kdy k síti p ipojujeme domácnosti pomocí xních klientských stanic. Zde m ºeme p edem ur it jaké parametry budeme u klientských za- ízení vyºadovat. U sítí, kde si zákazník m ºe p inést nap. notebook i PDA toto stanovit

28 12 8 ZABEZPEƒENÍ nelze a musíme se spokojit se standardem g, který dnes ale ve v t²in takový p ípad pln posta uje. 8 Zabezpe ení Zabezpe ení v bezdrátových sítích p edstavuje obecn v t²í problém neº u sítí metalických i optických. Díky tomu, ºe je zde signál ²í en volným prostorem, je daleko snaz²í jej odposlouchávat. Kaºdá WiFi sí navíc funguje na svém xním kanále, coº odposlech je²t více zjednodu²uje. Existují p ístupové body, které dokáºí kanály automaticky p epínat v závislosti na vytíºení radiového spektra, ale tato p epnutí se d jí pouze p i restartu sít a je p i tom nutné znovu sestavit v²echna spojení. Práv kv li snadnému odposlechu bylo okolo WiFi vyvinuto n kolik bezpe nostních standard. 8.1 MAC autentizace Kaºdé za ízení ve WiFi síti je identikováno globáln unikátní MAC 1 adresu p id lenou výrobcem. Tento princip je p evzatý ze sítí typu Ethernet. Nabízí se tedy triviální zp sob zabezpe ení p ístupu k síti, a to pomocí omezení komunikace pouze pro za ízení, jejichº MAC adresy budou uvedeny na seznamu. Tímto zp sobem lze zdánliv bezpe n e²it problém p ipojení cizích klient do na²í sít. V bec to ale ne e²í problém odposlech. Navíc je takové zabezpe ení snadno napadnutelné. Díky moºnosti odposlechu si totiº potenciální úto ník m ºe snadno zjistit, jaké MAC adresy mají za ízení, která spolu v síti komunikují a jednu z t chto adres jednodu²e podvrhnout. MAC autentizace je tedy jednoduché a levné zabezpe ení, které ale lze velmi snadno obejít. 8.2 Wired Equivalent Privacy (WEP) WEP je bezpe nostní technologie, která zaji² uje jak autentizaci klient, tak ²ifrování p ená²ených dat. Autentizaci lze z procesu vylou it (tzv. Open System authentication) nebo autentizaci provést pomocí sdíleného klí e. P i autentizaci sdíleným klí em se klientovi po²le výzva, které má podobu textového et zce, klient výzvu za²ifruje pomocí svého klí e, p ístupový bod se ²ifru pokusí de²ifrovat a výsledek porovná s p vodní výzvou. Na základ tohoto srovnání je pak klient p ijat i odmítnut. I kdyº se m ºe zdát tento zp sob autentizace bezpe n j²í neº Open System, opak je pravdou. Z pozorování pr b hu autentiza ního mechanismu lze totiº vypo ítat sdílený klí. Pomocí stejného sdíleného klí e pak probíhá v obou p ípadech ²ifrování. Ani jedna varianta tedy není p íli² bezpe ná. Tento zp sob zabezpe ení byl p ipojen ke standardu v roce O p t let pozd ji byl pak ozna en za nedoporu ený, protoºe pomocí dostupných algoritm a výpo etní techniky lze sdílený klí zjistit b hem n kolika málo minut. 8.3 WiFi Protected Access (WPA2) Bezpe nostní problém s WEP vy e²il v roce 2004 nový dodatek i, který denuje nový zp sob autentizace a ²ifrování WPA2 a zneplat uje tak p vodní WEP. P ed WPA2 se pouºíval je²t WPA, který implementoval pouze podmnoºinu standardu i. Útok 1 Media Access Control

29 na WPA2 je velice komplikovaný, takºe jeho nasazení v t²inu úto ník odradí. Pro sít, které slouºí pouze k p ístupu na internet je v sou asnosti WPA2 naprosto dosta ující a zárove nejlep²í dostupný. Problém je ale s tím, ºe n která star²í za ízení tento zp sob zabezpe ení nepodporují - jde o stejný problém jako u kompatibility standard na fyzické vrstv. Pokud na p ístupovém bodu nastavíme zabezpe ení WPA2, star²í za ízení, která podporují pouze WEP, se do sít nep ipojí. Pro autentizaci m ºeme zvolit dv moºnosti: WPA2 se sdíleným klí em (WPA2-PSK) Sdílený klí, anglicky Preshared Key (PSK), je nejpouºívan j²í v domácích sítích. Pro p ístup do sít je nutné znát heslo, které je stejné pro v²echny klienty. Z toho plynou dva problémy. Je to jednak problém s odhalením hesla - pokud n kdo cizí heslo zjistí, má do sít p ístup z libovolného za ízení. Toto lze do jisté míry omezit kombinací tohoto zabezpe ení s MAC autentizací. Druhý problém spo ívá v e²ení toho prvního. Kdyº pot ebujeme sdílený klí zm nit, musí se o tom dozv d t v²ichni, kte í se na p ístupový bod se zm n ným klí em p ipojují. To také omezuje asté pouºití sdíleného klí e v p ípadech, kdy tento klí zná pouze administrátor a sám konguruje klientská za ízení. Pod stejným názvem ale existují i implementace, kde m ºeme kaºdému za ízení p i adit vlastní klí. Toto je jedna ze zmín ných mezer ve standardu i. Zp sob p i azení sdíleného klí e, resp. klí v tomto standardu není popsán WPA2 s roz²í ením EAP (WPA2-EAP) EAP, tedy Extensible Authentication Protocol, umoº uje ov it kaºdého klienta individuáln. Vyzrazení jednoho hesla tedy znamená zm ny pouze u jednoho klienta. Navíc je moºné bez dal²ích technik individuáln ídit p ístup klient. Ov ování bývá nej ast ji zprost edkováno RADIUS 2 serverem. 9 HotSpot HotSpot je obecn místo, v n mº je dostupné bezdrátové p ipojení k síti internet. V na²em kontextu jde o sluºbu, kde je uºivateli poskytnut p ístup do sít na základ autentizace. I kdyº na²e sluºba bude poskytována prost ednictvím bezdrátové sít, lze HotSpot provozovat i na metalických i optických sítích. Pro vytvo ení HotSpotu existují r zná hotová e²ení, viz p íloha A na stran 61. V²echna fungují tak, ºe mezi sí a bránu do internetu umístíme proxy server, který zaji² uje ízení p ístupu. Z toho plyne jedno podstatné omezení, kterým je centralizace autentiza ní sluºby do jednoho bodu. Takové e²ení je vhodné do sítí s minimem p ístupových bod, které fungují nap íklad v rámci budovy (LAN, Local Area Network). Pro sít typu MAN (Metropolitan Area Network) nebo WAN (Wide Area Network), které pokrývají v t²í oblast a vyuºívají n kolik vzájemn zastupitelných p ístupových cest do internetu, je vhodn j²í dedikovat autentiza ní sluºbu na jednotlivé p ístupové body. Mimo zvý²ení dostupnosti sluºeb tím také umoºníme individuální p ístup ke skupinám zákazník podle té ásti sít, ve které se zrovna nacházejí Viz ást IV na stran 25

30 14 9 HOTSPOT

31 ƒást III Platforma Mikrotik Jak bylo e eno, uzly sít jsou v sou asné dob tvo eny za ízeními s opera ním systémem RouterOS. Jde o sí ový opera ní systém vytvo ený a udrºovaný loty²skou rmou Mikrotik. Spolu s hardwarem RouterBOARD tvo í velice oblíbenou platformu pouºívanou v sítích po celém sv t. Mimo dále popsaných technických vlastností tkví jejich oblíbenost také v nízké cen oproti konkuren ním produkt m. Firma Mikrotik byla zaloºena v roce 1995 v Rize[5]. Po prvních zku²enostech s bezdrátovými za ízeními vyvinula v roce 1997 vlastní sí ový opera ní systém RouterOS. V roce 2002 doplnila své produkty vlastním hardwarem RouterBOARD. Dnes tato rma pokrývá svou sítí distributor v t²inu sv ta. 10 Mikrotik RouterBOARD I kdyº systém RouterOS b ºí i na klasické platform x86, jeho síla tkví ve spolupráci s platformou RouterBOARD. Jde o sérii hardwaru ²itého na míru práv pro RouterOS. Jednotlivé produkty se li²í architekturou a mnoºstvím roz²i ujících slot a rozhraní. Podle konkrétního typu jsou tato za ízení vybavena následujícími komponentami: ˆ CPU Atheros nebo Power PC ˆ hardwarová akcelerace IPSec ˆ DDR RAM a NAND i Flash pam ˆ aº 9 Fast Ethernet i Gigabit Ethernet port, kaºdý samostatn kongurovatelný s moºností sdruºování do sí ového mostu i p epína e ˆ voliteln jeden Ethernet port pro PoE 3 ˆ aº 4 minipci sloty ˆ aº dva USB porty ˆ sériový port Díky minipci slot m a USB port m lze za ízení dále roz²í it o WiFi rozhraní, GSM, 3G, ISDN i ADSL modem a dal²í. Vedle optimálního výkonu, dostatku sí ových rozhraní a roz²i ujících slot je velkou výhodou t chto za ízení také nízká spot eba a kompaktní velikost. Spolu s moºností napájení po Ethernetu tak lze za ízení umístit jako WiFi router ven k anténám na stoºár a minimalizovat tak ztráty na vedení signálu mezi za ízením a anténou. Znamená to také, ºe pro za ízení nemusíme pronajímat i budovat ºádné provozní prostory. Za ízení m ºe fungovat kdekoliv, kde je p ístup k elektrické energii. 3 Power Over Ethernet - umoº uje napájet za ízení po Ethernetu. 15

32 16 11 MIKROTIK ROUTEROS 11 Mikrotik RouterOS RouterOS je sí ový opera ní systém pro hardware RouterBOARD. Protoºe je postavený na linuxovém jád e, lze ho provozovat i na platform x86. Primárn je ur en pro operátory bezdrátových sítí, ale lze jej vyuºít pro libovolné e²ení. Nabízí ²irokou ²kálu nástroj, protokol a technologií. Moºnost vyuºití jednotlivých funkcí je omezena zakoupenou licencí. Mikrotik nabízí i zku²ební licenci, která je zdarma, poskytuje bez omezení ve²kerou funkcionalitu, ale po 24 hodinách b hu systému zp sobí jeho deaktivaci a systém pak jiº nelze spustit. Jednotlivá omezení licencí jsou uvedena v tabulce 1. Tabulka 1: RouterOS - licence Licence 0 (Volná) 1 (Demo) 3 (WISP CPE) 4 (WISP) 5 (WISP) 6 (Controller) Podpora p i první konguraci dní 15 dní 30 dní Bezdrátový p ístupový bod limit 24h - - ano ano ano Bezdrátový klient limit 24h ano ano ano ano ano protokoly RIP, OSPF, BGP limit 24h ano ano ano ano ano EoIP tunely limit 24h 1 1 neomezen neomezen neomezen PPPoE tunely limit 24h neomezen PPTP tunely limit 24h neomezen neomezen L2TP tunely limit 24h neomezen neomezen OVPN tunely limit 24h neomezen neomezen VLAN rozhraní limit 24h 1 1 neomezen neomezen neomezen P2P pravidla rewallu limit 24h 1 1 neomezen neomezen neomezen NAT pravidla limit 24h 1 neomezen neomezen neomezen neomezen Aktivní uºivatelé HotSpotu limit 24h neomezen Klient RADIUS limit 24h - ano ano ano ano Fronty (Queues) limit 24h 1 neomezen neomezen neomezen neomezen Web proxy limit 24h - ano ano ano ano Aktivní relace User Manageru limit 24h neomezen 11.1 Správa RouterOS RouterOS je moºné spravovat n kolika zp soby. Lze vyuºít t í uºivatelských rozhraní a ty zp sob p ipojení. P ipojení je moºné pomocí protokolu TCP/IP, sériové linky, HTTP a pomocí tzv. MAC serveru p ímo p es linkovou vrstvu. P ipojení p es linkovou vrstvu se hodí pro po áte ní nastavení nebo nouzové p ípady, kdy není správn nastaveno IP prost edí. Pokud je na lince více za ízení nebo pokud se n jaký software snaºí na lince o komunikaci, stává se tento zp sob p ipojení nespolehlivý. Jako uºivatelské rozhraní slouºí Telnet, SSH klient, proprietární gracká konzole Winbox nebo libovolný webový prohlíºe. V tabulce 2 jsou uvedeny moºné kombinace p ipojení a uºivatelského rozhraní.

33 11.2 Vzorová kongurace 17 Tabulka 2: Správa RouterOS MAC Sériová linka TCP/IP HTTP Text MAC-Telnet Telnet Telnet/SSH - GUI Winbox - Winbox - WWW WWW prohlíºe Gracké uºivatelské rozhraní Winbox Winbox je proprietární gracká konzole pro správu RouterOS. Je to nejp ehledn j²í uºivatelské rozhraní, které RouterOS nabízí. Jde o MDI 4 rozhraní, pomocí kterého lze ovládat v²echny parametry a nástroje systému. V²e je hierarchicky rozd leno do p ehledného menu. Winboxem je moºné se p ipojit p es linkovou vrstvu i TCP/IP Textové uºivatelské rozhraní RouterOS poskytuje i textové uºivatelské rozhraní dostupné pomocí Telnetu a SSH. SSH má oproti Telnetu výhodu zabezpe eného komunika ního protokolu. U Telnetu lze komunikaci jednodu²e odposlouchávat. Textové rozhraní má obdobu linuxového shellu. Místo adresá je zde ale hierarchie parametr a nástroj, která je obdobná jako ve Winboxu. Pokud má tedy uºivatel zku²enost s Winboxem, snadno se nau í ovládat i textové rozhraní. St ºejní pro práci v textovém prost edí je klávesa tabelátor, jejímº stiskem se doplní rozepsaný p íkaz nebo se zobrazí seznam moºností v daném kontextu. Díky textovému rozhraní je moºné router spravovat i pomocí jednodu²²ích za ízení, jako je nap. chyt ej²í mobilní telefon nebo za ízení, která disponují pouze sériovým portem Webové rozhraní Webové rozhraní je v sou asnosti velmi omezené. Lze pomocí n j spravovat pouze malou podmnoºinu parametr systému. Je to obdoba webových rozhraní jednoduchých sí ových router. K tomuto ú elu ho lze také vyuºít - pokud budeme za ízení s RouterOS pouºívat pouze jako jednoduchý router mezi LAN a WAN, je toto rozhraní dosta ující Vzorová kongurace Popsat v²echny prost edky, které nám RouterOS nabízí a která pro ná² projekt m ºeme vyuºít, by vydalo na n kolik diplomových prací. Proto zde uvedu vzorovou konguraci, která vyhovuje poºadavk m na na²í sluºbu s omezeným popisem moºných alternativ. Pro lov ka se základními znalostmi platformy je takový popis pln posta ující. Sí bude sestávat z n kolika p ístupových bod tvo ených routery s RouterOS. Kongurace kaºdého p ístupového bodu bude vycházet z této vzorové kongurace. Vzorová kon- gurace p edpokládá pouºití routeru s jedním sí ovým rozhraním Ethernet p ipojeným do internetu a jedním rozhraním WiFi ur eným pro p ipojení klient. Vedle slovního popisu kongurace zde jsou uvedeny také p íkazy textového rozhraní. Jak bylo e eno vý²e, struktura textového a grackého rozhraní je více mén ekvivalentní, takºe tento 4 Multiple Document Interface - v okn aplikace je moºné mít otev ených více podoken s r znými pohledy na data aplikace, v tomto p ípad na konguraci a stav RouterOS.

34 18 11 MIKROTIK ROUTEROS zp sob popisu pln dosta uje. Rozd lení jednoho p íkazu na více ádk se ozna uje zp tným lomítkem (\) na konci ádk Ve ejné rozhraní Protoºe je pro ve ejné rozhraní vyuºit Ethernet, není t eba ºádná explicitní kongurace fyzického rozhraní. Název rozhraní p edpokládáme ether1. Za neme tedy nastavením IP adresy. Pokud je adresa statická, nap s maskou sít a branou , nastavíme tuto adresu a výchozí bránu p íkazy ip address add interface=ether1 address= /24 ip route add dst-address= /0 gateway= Je-li adresa ve ejného rozhraní dynamická, p idáme DHCP klienta, který se o její nastavení postará: ip dhcp-client add interface=ether1 add-default-route=yes disabled=no Parametr add default route zajistí nastavení výchozí cesty, parametr disabled je v tomto p ípad t eba explicitn uvést, protoºe jeho výchozí hodnota je v tomto p ípad výjime n yes. Pro nastavení sm rovací tabulky lze vyuºít i n který podporovaný protokol pro dynamickou správu cest, jako je OSPF, RIP nebo jiný Rozhraní WiFi Jak bylo uvedeno, máme na na²em vzorovém za ízení k dispozici pouze jedno rozhraní WiFi. Je pot eba ale zárove uspokojit pot ebu t ech r zných druh uºivatel (viz. popis uºivatelských rolí na stran 5) za dodrºení poºadavku maximální bezpe nosti. Moºnosti zabezpe ení sít WiFi, popsané v ásti 8 na stran 12, nám toto s vyuºitím pouze jednoho rozhraní na první pohled nedovolují. RouterOS ale pro tento problém nabízí e²ení v podob virtuálních p ístupových bod. Díky nim lze na jednom rozhraní provozovat n kolik sítí s r zným SSID a r znou úrovní zabezpe ení. Není to samoz ejm ekvivalent n sítí na n rozhraních - tyto virtuální sít sdílejí jedno rozhraní a jednu frekvenci a d lí se tak o p enosové pásmo. Pokud by tedy byl tento model nedosta ující, lze pouºít více fyzických rozhraní. Nejprve si p ipravíme nastavení zabezpe ení. P edpokládejme, ºe stálí uºivatelé, a uº pau²ální i instantní, budou pouºívat WPA2-PSK. Mohli bychom pouºít i WPA2-EAP, ale to vyºaduje pouºití RADIUS serveru. V p ípad výpadku RADIUS serveru i ásti sít, která jej propojuje n kterým p ístupovým bodem, by uºivatelé byli p ístupovým bodem odmítáni 5. Mikrotik navíc vyuºil zmín né mezery ve standardu i a implementoval moºnost p i adit jednotlivým klient m individuální klí e, coº e²í p vodní nedostatky WPA2-PSK. Pro generovaní klí m ºeme s výhodou pouºít n který z b ºn dostupných generátor hesel, který nám pom ºe maximáln vyuºít sílu tohoto zabezpe ení tím, ºe vygeneruje heslo dostate n dlouhé s náhodnou kombinací povolených znak. 5 Tento nedostatek m ºeme asto vid t v akademické WiFi síti Eduroam. Od jeho zprovozn ní se pom rn asto stává, ºe je klientské za ízení odpojeno a uºivatel je stále dokola dotazován a p ístupové údaje k síti.

35 11.2 Vzorová kongurace 19 Náhodní uºivatelé nebudou na úrovni linkové vrstvy vyuºívat ºádné zabezpe ení. Tím se zajistí moºnost informování uºivatele o poskytované sluºb, p ípadn p ístup k n kterým sluºbám zdarma. Autentizaci pro p ístup k placeným sluºbám zajistíme pomocí funkce HotSpot, jejíº popis a postup kongurace je uveden dále. Pot ebujeme tedy dva bezpe nostní proly. Nazv me je secret pro WPA2-PSK a free pro nezabezpe enou sí. interface wireless security-profiles add \ authentication-types=wpa-psk,wpa2-psk mode=dynamic-keys \ radius-mac-authentication=yes \ wpa-pre-shared-key="6b908e76-d fb0-50d92995c5fe" \ wpa2-pre-shared-key="9223f560-1f4a-46c0-82a1-b103f162d52d" \ unicast-ciphers=tkip,aes-ccm group-ciphers=tkip,aes-ccm name="secret" interface wireless security-profiles add name="free" Význam jednotlivých parametr a jejich hodnot je následující. Parametry ozna ené hv zdi kou obsahují hodnoty, které umoºní vyuºití star²ího typu zabezpe ení WPA z d vodu zp tné kompatibility. authentication-type* ur uje zp sob ov ení klientských za ízení. mode ur uje algoritmus pro p id lování klí pro ²ifrování p enosu. WPA2 vyuºívá dynamické p id lování klí. radius-mac-authentication nastaví zabezpe ení pomocí ov ení MAC adres. Slovo radius je zde zavád jící - ov ení MAC adres je moºné i bez RADIUS serveru. Ov ení MAC adres nám zvý²í bezpe nost - za ízení s neznámou MAC adresou bude p ístupový bod odmítat p ístup je²t p ed autentizací, ímº se o malou ást omezí prostor pro moºný pokus o neoprávn né p ipojení k síti. wpa(2)-preshared-key* výchozí klí e pro p ipojení k síti. Tyto klí e jsou p i pouºití WPA(2)-PSK vyºadovány bez ohledu na to, zda následn p i adíme individuální klí e kaºdému klientovi. V na²í síti tyto výchozí klí e dále nebudeme pouºívat. unicast-ciphers* ur uje algoritmus pro ²ifrování p enosu. group-ciphers* dtto name ur uje název prolu zabezpe ení Nyní m ºeme nakongurovat vlastní rozhraní. Protoºe se rozhraní v systému jiº fyzicky nachází, vypí²eme si seznam bezdrátových rozhraní, abychom zjistili hodnoty jeho indexu a názvu, se kterými pak budeme dále pracovat. interface wireless print Na výstupu se objeví výpis podobný tomuto s dal²ími, v tuto chvíli nepodstatnými detaily: Flags: X - disabled, R - running 0 X name="wlan1" mtu=1500 mac-address=00:12:34:56:78:90 arp=enabled interface-type=atheros AR5413 mode=station

36 20 11 MIKROTIK ROUTEROS Nás zajímá íslo na za átku popisu rozhraní, zde 0, a název rozhraní, zde wlan1. Nyní nastavíme základní vlastnosti sít a rozhraní: set antenna-mode=ant-a antenna-gain=14 band=2.4ghz-b/g \ country="czech republic" frequency-mode=regulatory-domain \ mode=ap-bridge security-profile=secret ssid="nasesit_soukroma" Význam jednotlivých parametr a jejich hodnot je následující: antenna-mode nám ur uje, jak naloºit s p ipojenými anténami. Hodnota ant-a íká, ºe se má pouºít pouze jedna anténa p ipojená k primárnímu konektoru. antenna-gain je zisk antény v dbi. Hodnota tohoto parametru závisí na p ipojené antén. band ur uje pouºitý standard WiFi. Zde pouºíváme g, abychom sí nabídli co nejv t²ímu mnoºství druh klientských za ízení. country ur uje zemi, ve které je sí provozována. Umoºní to zajistit dodrºení podmínek, které na bezdrátové sít kladou regula ní ú ady. frequency-mode ur uje zp sob vyuºití frekvence. Zde je vybrán zp sob, který za v²ech okolností dodrºuje normy regula ního ú adu. mode ur uje reºim, v jakém za ízení operuje. Tedy zda p jde o p ístupový bod, klienta, i jiný typ uzlu bezdrátové sít. Zde jsme zvolili, ºe budeme provozovat p ístupový bod. security-prole ur uje prol zabezpe ení, který jsme si p ipravili v p edchozích odstavcích. ssid ur uje identikátor SSID bezdrátové sít. Dále je t eba zvolit vhodnou frekvenci na které budeme operovat. Tuto volbu je moºné nechat na RouterOS, ale v takovém p ípad se m ºe stát, ºe se p i restartu za ízení frekvence zm ní a n která klientská za ízení si s tím neporadí a p estanou komunikovat. Proto je lep²í frekvenci zvolit na pevno a p ípadné potíºe e²it ru n ve chvíli, kdy nastanou. Necháme si tedy vypsat vyuºití frekven ního pásma: interface wireless frequency-monitor number=0 Zobrazí se nám tabulka, kde v prvním sloupci vidíme frekvenci a v druhém její percentuální vytíºení. Zvolíme takovou frekvenci, která má vytíºení nejniº²í. Nap MHz. Tuto frekvenci pak p i adíme na²emu rozhraní. interface wireless set wlan1 frequency=2412 Nyní zbývá nakongurovat virtuální p ístupový bod pro náhodné uºivatele. interface wireless add masters-interface=wlan1 name="wlan2" \ security-profile=free ssid="nasesit_verejna" Zde je navíc parametr master-interface, který ur uje k jakému fyzickému rozhraní se má virtuální p ístupový bod p i adit a zárove tím oznamujeme ºe jde práv o p ístupový bod virtuální. Parametry fyzické vrstvy virtuální p ístupový bod p ejímá od svého hostitelského rozhraní, takºe sta í uvést uº jen bezpe nostní prol a název sít. Po dokon ení nastavení rozhraní m ºeme bezdrátovou sí spustit: interface wireless enable 0

37 11.2 Vzorová kongurace Sí ová vrstva Nyní máme p ipravenou linkovou vrstvu a m ºeme p ejít ke konguraci IP adres. V na²em p ípad pot ebujeme pouze nastavit IP adresu zabezpe ené sít. P edpokládáme, ºe adresy klientských za ízení budeme nastavovat ru n. ip address add address= /24 interface=wlan1 Konguraci sí ové vrstvy ve ejné sít pro náhodné uºivatele provedeme v rámci následujícího kroku HotSpot Abychom na síti odd lili placený a neplacený prostor, pouºijeme funkci HotSpot. Ta nám podle na²í kongurace umoºní ur it adresy, na které se uºivatelé budou sm t p ipojit zdarma. Zbytek sít bude vyºadovat autentizaci, kterou lze provést následujícími zp soby: ˆ Ov ením MAC adresy, ˆ HTTP PAP (Password Authentication Protocol), kde se uºivatel ov uje jménem a heslem, které je p ená²eno protokolem HTTP ne²ifrovan, ˆ HTTPS PAP, kde jsou tyto údaje za²ifrované protokolem SSL, ˆ HTTP CHAP (Challange Authentication Protocol), kde se uºivatelské jméno za- ²ifruje pomocí hash funkce, coº vyºaduje JavaScript na stran uºivatelova prohlíºe e, ˆ ov ení Cookie, které za²le prohlíºe, jenº uº byl jednou ov en n kterým z p edchozích t í mechanism, ˆ nebo lze nastavit, aby m l kaºdý uºivatel jednou za zvolený asový interval sí p ístupnou na zvolenou dobu - nap. jednou za den na 30 minut. Metody vyuºívající protokol HTTP i HTTPS fungují pomocí HTTP Proxy, která p i pokusu o vstup uºivatele na libovolnou webovou stránku p esm ruje uºivatel v webový prohlíºe na svou stránku, kde se uºivatel m ºe do íst o zp sobu p ipojení k síti, o nabízených sluºbách a je mu zde umoºn no provést autentizaci. U ov ení MAC adresy lze p esm rování HTTP poºadavk zakázat, ímº se pro takto ov ené uºivatele stává HotSpot transparentní a nejsou kladeny ºádné nároky na jejich technické vybavení. Zobrazovanou webovou stránku si lze se základní znalostí jazyka HTML libovoln upravit a lze také tvo it její jazykové mutace. Pro nastavení HotSpotu m ºeme s výhodou vyuºít pr vodce, pomocí kterého v²e snadno nakongurujeme z jednoho místa: ip hotspot setup Postupn zvolíme rozhraní, na kterém budeme HotSpot provozovat, jeho adresu, ma²karádu (p eklad) IP adres a rozsah IP adres dynamicky p id lovaných DHCP serverem:

38 22 11 MIKROTIK ROUTEROS hotspot interface: test local address of network: /24 masquerade network: yes address pool of network: Dále nepovinn SSL certikát a adresu SMTP serveru na který budou p esm rovány SMTP poºadavky cílené na ná² p ístupový bod (na TCP port 25): select certificate: none ip address of smtp server: Povinn uvedeme adresy DNS server, které získáme od poskytovatele internetu 6 nakonec nepovinn DNS název hotspot serveru: a dns servers: , dns name: Nyní je HotSpot p ipraven ve své výchozí konguraci spolu s ve²kerým pot ebným nastavením jako je IP adresa rozhraní, DHCP server a HTTP Proxy. Ve výchozí konguraci je povolena autentizace pomocí HTTP CHAP a Cookie, coº je pouºitelný stav. P i získání d v ryhodného certikátu by bylo moºné povolit také HTTPS autentizaci, coº by pomohlo v p ípadech, kdy uºivatel nemá povolený JavaScript. Navíc to ale klade podmínku podpory protokolu SSL. Autentizace pomocí Cookies navíc uspokojuje poºadavek na minimální obt ºování uºivatele v p ípad krátkého výpadku. P i výpadku dojde pouze k rychlému p esm rování na autentiza ní stránku a následn bez zásahu uºivatele zp t na stránku, kterou p vodn poºadoval. Chceme-li si upravit webové stránky, které jsou uºivateli prezentovány p ístupovým bodem, m ºeme tak u init modikací soubor v adresá i hotspot v za ízení s RouterOS. K soubor m m ºeme p istupovat pomocí Winboxu, SCP, SFTP i FTP. Variabilita moºností úpravy je veliká, proto zde odkáºu na m j p íklad, který je k nalezení na p iloºeném CD a wiki Miktoriku[3], kde jsou v²echny moºnosti detailn popsány. Je také moºné uºivatel v prohlíºe p esm rovat na jiný HTTP server, který za²le zp t p ihla²ovací údaje p i ov ení uºivatele. To ale vyºaduje neustálou dostupnost tohoto serveru, jehoº výpadky mohou ohrozit dostupnost celé sluºby. Posledním poºadavkem na ná² HotSpot je zmín ná moºnost povolení p ístupu k vybranému obsahu bez autentizace. Toto je moºné nastavit pomocí funkce Walled Garden, kde m ºeme povolovat HTTP poºadavky a Walled Garden IP List, kde m ºeme povolovat IP spojení. Obojí zde lze nejen povolovat, ale i zakazovat. Pro úplnost zde uvedu dva p íklady: První p íklad dovoluje bez autentizace vyuºít sluºbu pro zji² ování dopravních spoj : ip hotspot walled-garden add action=allow dst-host=idos.cz ip hotspot walled-garden add action=allow \ dst-host=jizdnirady.idnes.cz Druhý p íklad dovoluje bez autentizace sledovat lm Star Wars pomocí Telnetu: 6 RouterOS umoº uje provozovat také DNS relay. Z praktické zku²enosti toto ale není spolehlivá sluºba. Dost asto se stává, ºe RouterOS odpoví negativn, coº se uloºí do vyrovnávací pam ti DNS klienta na klientské stanici a náhodn se tak na n kolik minut zablokuje p ístup na n které servery.

39 11.2 Vzorová kongurace 23 ip hotspot walled-garden ip add action=accept \ dst-host=towel.blinkenlights.nl dst-port=23 protocol=tcp Informaci o dostupnosti vybraných sluºeb m ºeme také umístit vý²e zmín ným zp sobem a úvodní webovou stránku p ístupového bodu Správa uºivatelských oprávn ní Oprávn ní k p ipojení klientských za ízení stálých uºivatel budeme spravovat p ímo na kaºdém p ístupovém bodu. Nap íklad pro povolení p ipojení za ízení s MAC adresou 00:01:02:03:04:05:06:07 a sdíleným klí em 0ebb68d4 da d ae0a19c4dc3f pouºijeme p íkaz interface wireless access-list add \ mac-address=00:01:02:03:04:05:06:07 interface=wlan1 \ private-pre-shared-key=0ebb68d4-da d-ae0a19c4dc3f Oprávn ní k p ístupu náhodných uºivatel bude t eba spravovat dynamicky. Existují dv moºnosti. Bu budeme n jakým zp sobem spravovat tabulku uºivatel na kaºdém p ístupovém bod nebo vyuºijeme RADIUS server. RADIUS serveru se v nuje ást IV na stran 25. V tuto chvíli sta í v d t, ºe jde o protokol umoº ující autentizaci a ú tování. Jeho vyuºití je oproti první moºnosti p ímo aré a umoº uje zvý²enou spolehlivost sluºby nasazením více redundantních server. V RouterOS existuje seznam RADIUS server, které m ºe router vyuºít. Pro p idání RADIUS serveru do seznamu pot ebujeme znát jeho IP adresu, UDP port a heslo (secret). U kaºdého serveru se také uváºí pro jaké sluºby je jeho autentiza ní sluºba dostupná. Na výb r je PPP 7, p ístup k RouterOS (login), HotSpot, p ístup k bezdrátové síti (wireless) a DHCP server (dhcp). RADIUS server operující na adrese na standardním portu 1812 s heslem 9009c00e a35 ac35 4f916d7d103d p idáme na seznam p íkazem radius add address= \ secret=9009c00e a35-ac35-4f916d7d103d service=hotspot \ src-address= Poslední parametr ur uje adresu, ze které budeme s RADIUS serverem komunikovat. Protoºe RADIUS server ov uje RADIUS klienty podle hesla a zdrojové IP adresy, je dobré tuto zdrojovou adresu explicitn uvést. Pokud by k RADIUS serveru vedlo více cest, mohlo by se stát, ºe by RouterOS automaticky pouºil pro komunikaci s RADIUS serverem r zné adresy. Druhou moºností je povolit na RADIUS serveru v²echny adresy kaºdého RADIUS klienta, coº ale vyºaduje více pé e p i zm nách v síti. Standardní port není t eba v p íkazu uvád t. Pro správnou funkci dále popsaného zp sobu omezení maximální doby p ipojení instantních uºivatel bude t eba, aby byl na routeru p esný as. K tomu pouºijeme funkci NTP 8 klienta. Pro jeho pouºití sta í znát adresu NTP serveru a asové pásmo, ve kterém se nacházíme. Pro komunikaci se servery lze také vyuºít n kolik reºim komunikace - unicast, manycast, multicast a broadcast. RouterOS umoº uje nastavit adresy dvou NTP 7 Point To Point protokol linkové vrstvy pro spojení dvou komunika ních uzl. 8 Network Time Protocol - protokol pro synchronizaci asu po IP síti.

40 24 11 MIKROTIK ROUTEROS server - druhou pro p ípad výpadku prvního serveru. P edpokládejme, ºe NTP servery operují v reºimu unicast na adresách a a router se nachází v Praze, tedy ve st edoevropském asovém pásmu (central-european time zone, CET) p echázejícím na letní as (daylight saving time, DST). ƒasovou synchronizaci pak nastavíme p íkazy system clock set time-zone-name=europe/prague system ntp client set primary-ntp= \ secondary-ntp= mode=unicast enabled=yes

41 ƒást IV Uºivatelská vytá ená sluºba pro vzdálenou autentizaci (RADIUS) Abychom do sít umoºnili p ístup náhodným uºivatel m, musíme zajistit dynamickou správu uºivatelských oprávn ní. Pouºíváme sice platformu Mikrotik, která má vlastní produkt pro správu uºivatelských oprávn ní, User Manager, ale tento produkt slouºí pouze pro jejich statickou správu. Pro ná² poºadavek dynamické správy uºivatel se tak nabízí druhá moºnost, kterou je standardizovaný autentiza ní, autoriza ní a ú tovací (Authentication, Authorization and Accounting, AAA) protokol RADIUS. RADIUS tedy nabízí 3 sluºby. Autentizaci, coº je ov ování uºivatel, autorizaci, coº je p id lování p ístupu k ur eným sluºbám uºivatel m na základ autentizace a ú tování, coº je v tomto kontextu sb r informací o vyuºití sluºeb uºivatelem - v na²em p ípad nap. doba p ipojení, mnoºství p enesených dat a dal²í. Pro spln ní nutných poºadavk pouºijeme pouze autentiza ní a autoriza ní sluºbu RADIUS serveru. 12 Popis RADIUS protokolu pro autentizaci Protokol RADIUS je zaloºený na protokolu UDP. Tento protokol oproti protokolu TCP umoº uje vy²²í dostupnost serveru. V p ípad výpadku spojení totiº protokol TCP eká del²í dobu, neº ozna í spojení za poru²ené. UDP naproti tomu spojení ne e²í - pouze vy²le datagram, který v p ípad nedostupné cesty jednodu²e zmizí. Komunikace mezi RADIUS klientem a RADIUS autentiza ním serverem spo ívá v zasílání poºadavk a odpov dí na n. Jedna strana vy²le poºadavek a pokud do stanoveného limitu neobdrºí odpov, poºadavek opakuje. Pokud po t etím opakování odpov ve stanoveném ase neobdrºí, povaºuje tento stav za chybu sít. ƒasový limit na odpov je standardn 300ms, ale lze ho stejn jako po et opakování nastavit tak, aby vyhovoval parametr m sít, na které sluºbu provozujeme. U autentiza ní sluºby RADIUS protokolu existují ty i typy zpráv: Access-Request, tedy poºadavek na ov ení, je zasílán RADIUS klientem jako ºádost o autentizaci uºivatele. Access-Challenge, tedy výzva k ov ení, se pouºívá pro získání dodate ných informací pot ebných pro autentizaci i pro implementaci sloºit j²ích vícecestných autentiza- ních metod. Access-Reject, tedy zamítnutí autentizace, se pouºívá jako negativní odpov na ºádost o autentizaci. Access-Accept, tedy p ijetí autentiza ních dat, se pouºívá jako pozitivní odpov na ºádost o autentizaci. Na obrázku 7 je znázorn n vlastní proces autentizace. RADIUS klient za²le RADIUS serveru poºadavek o autentizaci (zpráva Access-Request) a RADIUS server má následn 3 moºnosti. Pokud klient nedodal dostate né informace pot ebné pro ov ení, za²le server 25

42 26 13 RADIUS VS. ROUTEROS zp t informaci o nutnosti dopln ní informací (zpráva Access-Challenge). Pokud klient dodal platné informace, za²le server zp t pozitivní odpov (zpráva Access-Accept), v opa ném p ípad odpov negativní (zpráva Access-Reject). Obrázek 7: Ilustrace procesu autentizace protokolem RADIUS Jednotlivé zprávy navíc nejsou atomické. Kaºdá zpráva je opat ena atributy. N které atributy jsou standardizované, dal²í p idávají jednotliví producenti produkt vyuºívajících RADIUS protokol. N které atributy jsou vázané na pouºitou metodu autentizace, jiné slouºí pro ur ení parametr sluºeb v rámci autorizace. V procesu autentizace a autorizace se atributy vyuºijí tak, ºe ve zpráv Access-Request klient poskytne parametry pot ebné pro autentizaci, nap. uºivatelské jméno a heslo. Ve zpráv Access-Accept pak server posílá údaje pot ebné pro autorizaci - nap. uºivatelský prol, maximální p enosovou rychlost, atp. Tyto autoriza ní atributy jsou pevn p i azeny kaºdému uºivateli, p ípadn skupin uºivatel. Kaºdý druh atributu je ur en íselným kódem typu (type). Proprietární roz²i ující atributy jsou navíc ur eny íselným kódem výrobce (vendor ID). 13 RADIUS vs. RouterOS RouterOS implementuje RADIUS klienta dle standardu, takºe zde zdánliv není v kooperaci t chto dvou technologií ºádný problém. Jeden ale vyvstává v souvislosti s na²ím poºadavkem na asové omezení p ipojení instantních uºivatel. RouterOS má sice prost edky pro spln ní tohoto poºadavku na autorizaci, ale nelze je jednodu²e vyuºít pomocí standardního RADIUS serveru. Jako volitelný atribut lze ve zpráv Access-Accept zaslat informaci o asu konce platnosti oprávn ní. Dle poºadavku se ale doba platnosti po ítá od asu p ihlá²ení. P i vytvá ení uºivatelského oprávn ní, tj. po úsp ²né platb, tedy není as jeho konce znám. Nastavit as konce oprávn ní na del²í dobu, neº si uºivatel zaplatil, není moºné, protoºe dobu mezi platbou a p ístupem k síti nelze nijak odhadnout. Je tedy t eba vytvo it vlastní implementaci RADIUS serveru nebo upravit n jakou stávající. První moºnost je p íli² asov náro ná, proto jsem p istoupil k moºnosti druhé. Abych u²et il co nejvíce asu, hledal jsem implementaci v jazyce C#, se kterým mám nejv t²í zku²enosti. Nabízely se dva projekty: Clutch.Radius je jiº nepodporovaný projekt jednoho vývojá e, který jej implementoval pro svou pot ebu a následn na internetu zve ejnil zdrojové kódy k volnému pouºití. Server obsahuje stále chyby a není úpln implementovaný. Na druhou stranu má dob e itelný a komentovaný zdrojový kód, coº usnad uje jeho modikaci.

43 WCF RADIUS Service je propracovaný funk ní a podporovaný projekt zaloºený na frameworku WCF 9. Jde o pom rn komplexní záleºitost, coº zp sobuje v t²í asové nároky na seznámení s projektem pro jeho dal²í modikaci. 27 Po bliº²ím seznámení se s ob ma projekty a po provedení n kolika test jsem se rozhodl pro modikaci projektu Clutch.Radius. Nejprve bylo t eba odladit drobné chyby a doplnit CHAP autentizaci (viz sekce na stran 21). Dále jsem v autentiza ním mechanismu publikoval dv události - jedna je volaná p i úsp ²ném ov ení, druhá p i neúsp ²ném. Pro reakci na tyto události lze vytvo it t ídu, která implementuje jedno i ob rozhraní pro obsluhu t chto událostí. Knihovnu s touto t ídou pak lze zapojit pomocí kongura ního souboru serveru. Nakonec jsem p ipravil knihovnu obsluhující událost úsp ²ného ov ení. Ta se pokusí najít mezi uºivatelovými atributy dobu p ipojení. Jde o atribut typu vendor-specic (26) s kódem výrobce 0. Jeho hodnotou je celé íslo vyjad ující dobu v minutách, po kterou bude uºivateli umoºn n p ístup k síti. Pokud takový atribut nalezne, spo ítá as konce relace p i tením jeho hodnoty k aktuálnímu asu, atribut doby odebere a as konce relace p idá jako atribut typu vendor-specic (26) s kódem výrobce (wi-.org). Jde o atribut WISPr-Session-Terminate-Time s proprietárním kódem 9, viz [3]. Formát data a asu je dán manuálem k RouterOS[4] v kapitole RADIUS Client, binární podoba atributu pak standardem RFC 2865[6] v kapitole Vendor-Specic Attributes. Takto je uºivateli dle poºadavk vypo ten as konce p ipojení podle asu jeho po átku a zaplacené doby p ipojení. V p ípad výpadku a p ípadné op tovné autentizace pak jiº RADIUS server ode²le d íve vypo tený atribut asu konce relace a uºivateli se tak op tovnou autentizací neprodlouºí povolená doba p ipojení. V databázi je pak t eba zajistit, aby se uºivatelské ú ty s pro²lou dobou p ipojení pravideln promazávaly. Postup nasazení serveru je popsán v p íloze C na stran Test RADIUS serveru 14.1 Ov ení spolupráce s RouterOS Pro testování mé úpravy pro spolupráci serveru Clutch.Radius s RouterOS jsem vytvo il zku²ební prost edí sestávajícího ze stroje se serverem Clutch.Radius, stroje s RouterOS a stroje s Linuxem, který slouºil jako klientské za ízení. K virtualizaci tohoto e²ení jsem pouºil nástroj Sun VirtualBox[7], který dokáºe pln simulovat pot ebný hardware v etn sí ových adaptér a jejich propojení. VirtualBox jsem zvolil pro svou dobrou zku²enost s ním a protoºe poskytuje ve²keré pot ebné virtualiza ní nástroje. Kongurace tohoto prost edí je znázorn na na obrázku 8. Pomocí tohoto prost edí bylo moºné snadno testovat r zná sestavení serveru Clutch.Radius a zárove r zné kongurace RouterOS, aniº bych zasahoval do produk ního prost edí. 9 Windows Communication Foundation - framework pro implementaci a provozování sí ových sluºeb na platform Microsoft.NET.

44 28 15 DYNAMICKÉ VYTVÁ ENÍ UšIVATELSKÝCH OPRÁVN NÍ Obrázek 8: Test RADIUS serveru - kongurace prost edí 14.2 Zát ºový test serveru Clutch.Radius Abych ov il správné fungování serveru v podmínkách, kdy bude o autentizaci ºádat více uºivatel v jeden okamºik a pro ov ení správného fungování serveru b hem del²í doby a v t²ího po tu zpracovaných ºádostí, nalezl jsem nástroj pro testování RADIUS server IEA Radlogin v4[8]. Jde o multiplatformní voln dostupný software s webovým rozhraním, který se chová jako RADIUS klient a umoº uje RADIUS server zaplavovat velkým mnoºstvím ºádostí o autentizaci i ú tovacími pakety. Jeho nasazení spo ívá ve staºení instala ního balíku a provedení automatické instalace. Po instalaci se otev e webový prohlíºe s uºivatelským rozhraním, kde se do seznamu server p idají servery, které chceme testovat a následn je moºné provád t n který z nabízených test. Já vyuºil testu nazvaného Radlogin, který jednodu²e ºádá RADIUS server o autentizaci. Mimo uºivatelského jména a hesla se volí také mnoºství ºádostí, které se má v rámci jednoho testu provést. Tím se dá nasimulovat dlouhý b h RADIUS serveru, b hem kterého obdrºí v t²í mnoºství ºádostí. Soub ºné ºádosti se pak dají nasimulovat provedením testu z více oken webového prohlíºe e nebo z více stroj. Server jsem testoval pomocí dvaceti t chto test spu²t ných soub ºn po deseti na dvou strojích. Kaºdý test provedl sto tisíc ºádostí. B hem tohoto testu jsem sledoval odezvu serveru, která se pohybovala v ádu milisekund, coº odpovídalo zpoºd ní sít a vyuºití jím alokované opera ní pam ti, která se po n kolika tisících ºádostí ustálila na hodnot necelých 18 MB a dále nerostla, coº vypovídá o správném fungování serveru, který tak b hem svého b hu správn uvol uje v²echny alokované systémové prost edky. 15 Dynamické vytvá ení uºivatelských oprávn ní Ve chvíli, kdy instantní zákazník úsp ²n provede instantní platbu, je t eba na RA- DIUS serveru vytvo it uºivatelské oprávn ní, které uºivateli umoºní p ipojení na práv zaplacenou dobu. K tomuto ú elu jsem vytvo il middleware HotSpot User Manager, který toto zaji² uje. V této ásti uvádím podstatné informace týkající se analýzy, návrhu a implementace tohoto softwaru, v ásti V jsou pak uvedeny informace stejného charakteru týkající se modul pro jednotlivé platební systémy. V p íloze D je uveden postup

45 15.1 Analýza User Manageru 29 nasazení sluºby. Kompletní dokumentace implementace softwaru v etn modul je ve form hypertextového dokumentu dostupná na p iloºeném CD Analýza User Manageru Je pot eba, aby r zné platební systémy m ly moºnost vytvá et uºivatelská oprávn ní pro p ístup k síti na dobu odpovídající vý²i poplatku. Tato oprávn ní mají být vytvá ena v databázi serveru Clutch.Radius. Je tedy zapot ebí modulární sluºbu roz²i itelnou o komponenty poskytující komunikaci s jednotlivými platebními systémy. Zárove musí mít sluºba p ístup k uºivatelským ú t m a atribut m v databázi Clutch.Radius a být schopná s t mito daty pracovat. Na obrázcích 9 a 10 je zobrazen p íklad tohoto e²ení. Obrázek 9: HotSpot User Manager - model komponent

46 30 15 DYNAMICKÉ VYTVÁ ENÍ UšIVATELSKÝCH OPRÁVN NÍ Obrázek 10: HotSpot User Manager - model nasazení Jak bude software fungovat je ukázáno na obrázku 11. Uºivatel poºádá prost ednictvím n kterého poskytovatele instantních plateb o provedení platby. Zp sob ºádosti a detaily pr b hu platby záleºí na konkrétním poskytovateli. Poskytovatel platby ºádost ov í a pokud je v po ádku, informuje o platb ná² middleware. Ten provede její dal²í ov ení a podle platebních údaj vygeneruje p íslu²ná oprávn ní, umoº ující uºivateli p ístup k síti na zaplacenou dobu. Tato oprávn ní vloºí do databáze RADIUS serveru a autentiza ní údaje k tomuto oprávn ní p edá zp t poskytovateli platební sluºby. Ten potvrdí platební transakci a získané údaje p edá uºivateli, který jiº m ºe vyuºít sluºbu. Pokud v n kterém míst selºe zpracování uºivatelovy ºádosti, je o d vodu neúsp chu uºivatel informován a má moºnost ºádost opakovat.

47 15.1 Analýza User Manageru 31 Obrázek 11: HotSpot User Manager - business model Teoreticky bychom pro samotný software nepot ebovali ºádná perzistentní data. Pro zp tnou evidenci událostí bude ale dobré uchovávat informace o p idaných oprávn ních. K tomu slouºí entita added_users - viz. obrázek 12. Význam atribut je následující: id... unikátní identikátor oprávn ní shodný s identikátorem v databázi serveru Clutch.Radius username... uºivatelské heslo password... heslo pro p ístup k síti time_limit... maximální povolená doba p ipojení k síti v minutách added... datum a as p idání uºivatelského oprávn ní do databáze B hem návrhu modulu pro SMS platby vyvstal navíc poºadavek pro dodate né odebrání oprávn ní v p ípad, kdy uºivatel v operátor mobilní sít odmítne uskute nit platbu. Proto je zde navíc entita removed_users, která obsahuje informace i takto odebraných oprávn ních. Význam jejích atribut je následující: id... unikátní identikátor odebraného uºivatelského oprávn ní shodný s identikátorem v databázi serveru Clutch.Radius removed... datum a as odebrání uºivatelského oprávn ní

48 32 15 DYNAMICKÉ VYTVÁ ENÍ UšIVATELSKÝCH OPRÁVN NÍ Obrázek 12: HotSpot User Manager - model dat 15.2 Návrh User Manageru Pro komunikaci s databází serveru Clutch.Radius slouºí t ída RadiusManager. Poskytuje pot ebné metody pro p idání (AddUser()) a odebrání (RemoveUser()) uºivatelského oprávn ní. Pro správu vý²e popsaných entit slouºí t ída UserManagerData spolu s entitními t ídami AddedUser a RemovedUser. Jádrem softwaru je singleton t ída UserManager. Ta nabízí metody pro p idání (AddUser) a odebrání (RemoveUser) uºivatelského oprávn ní jednotlivým modul m pro komunikaci s poskytovateli instantních plateb. Tyto moduly pro komunikaci s poskytovateli instantních plateb se vytvá ejí implementací rozhraní IManagementModule. Toto rozhraní obsahuje metody OnStart, resp. OnStop, které se volají p i spou²t ní, resp. ukon ování User Manageru a umoº ují modul m efektivní a bezpe nou práci se systémovými prost edky. V²echny tyto t ídy spolu s rozhraním IManagementModule jsou znázorn ny na obrázku 13.

49 15.2 Návrh User Manageru 33 Obrázek 13: HotSpot User Manager - t ídy jádra Je²t jedna t ída je pot ebná pro chod User Manageru, a to t ída HandleException- Attribute. Tato t ída implementuje aspekt o²et ení výjimek, tedy neo ekávaných stav. O²et ení výjimek se prolíná nap í celým projektem. Proto je e²eno pomocí AOP 10. Obrázek 14: HotSpot User Manager - aspekty Software bude implementován jako sluºba Windows - proto pot ebujeme t ídy zobrazené na obrázku 15, pomocí nichº tento zp sob implementace provedeme. T ída ProjectInstaller slouºí k instalaci sluºby do opera ního systému. T ída Program obsahuje metodu Main(), která je vstupním bodem do programu. T ída Service je vlastní implementace sluºby. Inicializuje a uvol uje v²echny pot ebné systémové prost edky jak t ídy UserManager, tak v²ech modul, tj. implementací rozhraní IManagementModule. 10 Aspect Oriented Programming, Aspektov orientované programování. e²í problémy, které se prolínají nap í business logikou, zp ehled uje zdrojový kód.

50 34 15 DYNAMICKÉ VYTVÁ ENÍ UšIVATELSKÝCH OPRÁVN NÍ Obrázek 15: HotSpot User Manager - t ídy jádra 15.3 Implementace User Manageru Projekt HotSpot User Manager jsem implementoval pomocí jazyka C# pro platformu Microsoft.NET Framework 3.5[9]. I kdyº jsem v²e implementoval a odladil pod Windows, nevylu uje volba tohoto frameworku provoz sluºby pod jinými opera ními systémy. Pro implementaci aspektu o²et ení výjimek, tj. t ídy HandleExceptionAttribute, jsem pouºil knihovnu PostSharp od SharpCrafters[10] pro aspektov orientované programování pro.net a knihovnu Apache log4net[11] pro zpracování vzniklých událostí. Tato knihovna umoº uje dle kongurace záznam událostí do souboru i systémového logu, odesílání em, záznam do databáze, výpis do terminálu i do pam ti, posílání p es TCP i UDP a dal²í. Databáze serveru Clutch.Radius i User Manageru b ºí na databázovém stroji Microsoft SQL Server 2008[12]. Tato volba je ideální pro spolupráci s.net aplikacemi. Microsoft navíc uvolnil neplacenou verzi tohoto produktu s ozna ením Express, která pln vyhovuje náro nosti na²ich dvou produkt. Pro komunikaci s databází serveru Clutch.Radius je s výhodou pouºito volání p vodních vloºených procedur prost ednictvím b ºné knihovny ADO.NET[9]. Pro komunikaci s databází User Manageru je vyuºito objektov -rela ní mapování LINQ to SQL[9]. Ob knihovny ADO.NET i LINQ jsou dnes b ºn pouºívané pro komunikaci.net aplikací s perzistentními úloºi²ti dat.

51 15.4 Testování User Manageru Testování User Manageru Testování User Manageru jsem provedl v rámci testování modulu pro SMS platby, které je popsáno v ásti na stran 48.

52 36 15 DYNAMICKÉ VYTVÁ ENÍ UšIVATELSKÝCH OPRÁVN NÍ

53 37 ƒást V Instantní platby Cílem tohoto projektu je roz²í it na²í WiFi sí pro p ístup k internetu o moºnost plateb za omezené p ipojení a roz²í it tak okruh potenciálních zákazník. Nabízí se mnoho voleb pro instantní platby - SMS platby, platby kreditní kartou, on-line bankovní p evody nebo r zné internetové platební brány, tzv. elektronické pen ºenky, jako jsou PayPal, PaySec, PayPay, Seznam Pen ºenka a jiné. 16 SMS platby V první fázi projektu jsem se rozhodl zavést SMS platby, protoºe je to dnes nejroz²í en j²í a nejsnaz²í zp sob instantních plateb. Snad kaºdý lov k dnes vlastní nejmén jeden mobilní telefon a tém v²ichni také umí poslat textovou zprávu. Nevýhodou tohoto zp sobu platby je relativn nízký podíl z placené ástky. D vodem je mnoºství mezi lánk v procesu platby. Iniciátorem platby je mobilní operátor, který platbu uskute ní prost ednictvím tzv. SMS agregátora. To je rma, která integruje sluºby r zných operátor a svým partner m nabízí jednotný platební systém a umoº uje sluºbu provozovat pod jednotným telefonním íslem. Operátor navíc pro ú tování vyuºívá externí spole nosti. To v²e sniºuje podíl poskytovatele sluºby, který se tak pohybuje mezi 50 aº 70 procenty z ceny SMS bez DPH. Podíl se navíc v t²inou li²í podle operátora Popis platby pomocí SMS Existují dva druhy platby pomocí SMS. Mobile Originated (MO) a Mobile Terminated (MT). Platba Mobile Originated, tedy zapo atá mobilním za ízením, funguje tak, ºe uºivatel za²le SMS na telefonní íslo a ihned po odeslání je mu ode tena p íslu²ná ástka. Poslední dvoj íslí telefonního ísla navíc zna í cenu SMS s DPH. Pokud je zákazníkovi zasílána zp t potvrzující SMS, je mu zaslána na náklady poskytovatele sluºby. Cena této zp tné SMS se pohybuje okolo jedné Koruny. Naproti tomu platba Mobile Terminated, tedy zakon ená na mobilním za ízení, probíhá tím zp sobem, ºe zákazník po²le SMS na jednotné telefonní íslo bez ohledu na cenu sluºby a ástka je mu ú tována aº p i doru ení potvrzující SMS. To má pro ná² p ípad dv výhody. Jednak ob SMS, jak odchozí, tak zp tnou p íchozí, hradí zákazník. Druhá výhoda je, ºe p i potenciálním výpadku komunikace kdekoliv mezi operátorem, SMS agregátorem a poskytovatelem sluºby není uºivateli ú továno nic a není tak t eba e²it dodate né storno platby. Ob tyto výhody pak podtrhuje fakt, ºe MT platby nabízejí v t²í podíl z ceny kaºdé SMS neº jaký je nabízen u MO plateb Výb r SMS agregátora Na eském trhu dnes p sobí n kolik SMS agregátor. 11 z nich jsem oslovil s ºádostí o nabídku sluºby placení p ístupu k WiFi síti pomocí SMS. Od t ech z nich jsem nedostal odpov. Mezi ostatními jsem vybíral podle následujících kritérií: ˆ Agregátor musí podporovat MT platby.

54 38 16 SMS PLATBY ˆ Agragátor musí umoºnit propojení s na²ím AAA serverem. ˆ Vý²e poplatku za z ízení a provoz sluºby musí být co nejniº²í. ˆ Podíl z ceny SMS musí být co nejvy²²í. ˆ Agregátor musí nabídnout co nej²ir²í moºnost volby ceny SMS. Seznam oslovených SMS agregátor v etn popisu jejich nabídky a srovnání se nachází v p íloze B na stran 65. Vít zem výb ru se stala spole nost Erika, a.s.[13] díky své druhé nelep²í cenové nabídce, nejvy²²ímu rozsahu nabízených cenových hladin SMS zpráv a ideálnímu technickému e²ení Modul pro SMS platby Analýza modulu pro SMS platby S vít zným agregátorem jsme dohodli zp sob pr b hu plateb a propojení jeho systému s na²ím. Propojení bude uskute n no pomocí webové sluºby. Na obou stranách bude software b ºící na.netu, takºe p jde o ideální e²ení. Webová sluºba (Web Service) je RPC (Remote Procedure Call, vzdálené volání procedur) komunikující pomocí protokolu HTTP. Na²e strana bude fungovat jako server a bude pro obsluhu SMS plateb publikovat dv procedury. První z nich je procedura Receive(), kterou bude agregátor volat p i p ijetí ºádosti o platbu. Tato procedura bude mít následující parametry: keyword... klí ové slovo zadané uºivatelem p evedené na velká písmena. V na²em p ípad vºdy AG. id... jednozna ný celo íselný identikátor poºadavku generovaný agregátorem. operator... jednoznakový kód mobilního operátora zákazníka. 420_E pro O2, 420_T pro T-mobile a 420_O pro Vodafone. received... datum a as p ijetí zprávy SMS centrem operátora. dstnumber... telefonní íslo, na které zákazník zaslal sv j poºadavek. V na²em p ípad vºdy srcnumber... telefonní íslo zákazníka. Nap Sluºba bude fungovat pouze na mobilních telefonech s eským telefonním íslem, takºe délka telefonního ísla bude vºdy 12 íslic. text... celý text zprávy v podob, jaké jí zákazník odeslal. Maximální délka jedné SMS zprávy je 160 znak. Návratovou hodnotou této procedury bude strukturovaný typ s následujícími atributy: Status... boolská hodnota udávající, zda byl poºadavek zpracován úsp ²n i ne. Neúsp ²né zpracování znamená nap. chybný text zprávy, neznámý kód sluºby, atp. (viz dále). ID... jednozna ný celo íselný identikátor poºadavku shodný s hodnotou atributu id procedury Receive().

55 16.3 Modul pro SMS platby 39 Type... kód typu zprávy pro odpov. My budeme odpovídat vºdy pomocí SMS, která má kód 1. Jiné typy sluºeb mohou odpovídat nap. pomocí MMS i Wap Push. Price... cena sluºby v K s DPH. Cena sluºby m ºe být jedna z hodnot uvedených ve smlouv, tzn. 20, 30, 40, 50, 60, 70, 80, 90 nebo 99. Jinou cenu je moºné vytvo it zasláním dvou a více SMS. Pro takové chování by ale bylo t eba metodu Receive() upravit. Pokud je hodnota atributu Status false, musí být cena 0. Text... text zprávy, kterou uºivatel obdrºí. Druhou procedurou na²eho rozhraní je metoda Conrm(). Tato metoda je volána pro potvrzení i zamítnutí platby a má následující atributy: id... jednozna ný celo íselný identikátor poºadavku shodný s hodnotou atributu id procedury Receive(). conrmed... datum a as potvrzení i zamítnutí platby. status... boolská hodnota zna ící úsp ²nost platby. True zna í potvrzení platby, false zamítnutí. Metody Receive() a Conrm() umí kaºdá jedním voláním obslouºit jednu SMS zprávu. Takto byla sluºba navrºena s ohledem na p edpoklad, ºe frekvence plateb nebude p íli² vysoká. Pokud by byla, je moºné metody upravit tak, aby dokázaly v rámci jednoho volání zpracovat více SMS naráz. Agregátor ve smlouv prohla²uje, ºe je schopen zpracovat aº 80 tisíc SMS za minutu. Domluvený zp sob pr b hu plateb je znázorn ný na obrázku 16 na stran 41. Platbu zahájí zákazník odesláním SMS. Tvar této zprávy bude ve tvaru [klí ové slovo] [kód sluºby]. Klí ové slovo identikuje poskytovatele sluºby a pro nás bude vºdy stejné. Jako jeho hodnotu jsme zvolili písmena AG, která jsou za átkem názvu na²í sít (AG-Net) a zárove umoº ují snaz²í psaní na klávesnici mobilního telefonu. Jsou pouze dv a na klasické 12místné klávesnici se na p íslu²ných klávesách nacházejí vºdy na prvním míst, coº minimalizuje po et stisk kláves. Za klí ovým slovem následuje mezera a kód sluºby. Kódy sluºeb a jejich význam si budeme volit dle svého uváºení. Doporu ení agregátora zní pouºít jako kód sluºby pouze jednu íslici. D vodem je znovu snaz²í psaní zprávy. Odeslaná zpráva tak m ºe mít tvar nap. AG 1. Telefonní íslo, na které uºivatel takovou zprávu ode²le, je bez ohledu na mobilního operátora, ke kterému je uºivatel p ipojen. Pokud má klí ové slovo uvedené v SMS hodnotu AG, volá agregátor na²í proceduru Receive(). Ná² server ov í tvar SMS a vyhledá uvedený kód sluºby. Pokud má zpráva neplatný tvar nebo pokud uºivatel zadal neznámý kód sluºby, vrací metoda chybový stav a text zprávy popisující d vod neúsp chu. V opa ném p ípad se uºivateli vytvo í p ístupová práva do sít s asovým omezením dle kódu sluºby a metoda vrátí kladný p íznak, cenu objednané sluºby a text zprávy obsahující p ístupové informace, tj. uºivatelské jméno a heslo. Pokud agregátor obdrºí zp t chybový stav, zru²í platbu a chybovou SMS zprávu ode²le uºivateli. Pokud obdrºí kladnou odpov, pokusí se platbu dokon it. Pokud se platbu nepoda í dokon it, volá agregátor na²í proceduru Conrm() s negativní hodnotou atributu status. Ná² modul pro SMS platby p i tomto volání zru²í p id lené oprávn ní podle identikátoru poºadavku. Pokud platba prob hne v po ádku, ode²le

56 40 16 SMS PLATBY agregátor uºivateli na²í SMS zprávu s p ístupovými údaji a uºivatel tak m ºe po autentizaci za ít vyuºívat svou sluºbu. Zárove agregátor zavolá proceduru Conrm() s pozitivní hodnotou atributu status. Na toto volání modul SMS platby nijak nereaguje. Odesláním p ístupových údaj jiº procedurou Receive() omezíme proces komunikace mezi agregátorem a modulem pro SMS platby pouze na jedno kritické místo. Pokud následn selºe volání procedury Conrm() v obou p ípadech jejího pouºití, nebude to mít vliv na kvalitu sluºby. Pokud totiº platba prob hla v po ádku, obdrºí uºivatel p ístupové údaje od agregátora bez dal²ího volání webové sluºby, pokud neprob hla, agregátor p ístupové údaje uºivateli neode²le a on tak nebude mít moºnost neoprávn n vyuºívat na²ich sluºeb a selhání volání procedury pro zamítnutí platby tak bude mít pouze mizivý vliv na pravd podobnost zneuºití vytvo ených p ístupových údaj.

57 16.3 Modul pro SMS platby 41 Obrázek 16: SMS Gateway - business model

58 42 16 SMS PLATBY Pro provoz modulu pro SMS platby budeme pot ebovat ukládat informace o poskytovaných sluºbách a o platbách reprezentované entitami znázorn nými na obrázku 17. Informace o poskytovaných sluºbách reprezentuje entita sms_services. Význam jejích atribut je následující: code... jednoznakový kód sluºby odpovídající kódu sluºby, který zákazník zadá ve své SMS zpráv. P ednostn bude tento atribut nabývat dle doporu ení SMS agregátora íselných hodnot. Pouze pokud by se vy erpalo dostupných 10 íslic, pouºijí se písmena abecedy nebo jiné znaky. time_limit... maximální doba povoleného p ipojení v celých minutách. price... cena sluºby v K. Povolené hodnoty tohoto atributu jsou dle smlouvy s SMS agregátorem 20, 30, 40, 50, 60, 70, 80, 90 nebo 99. comment... komentá slouºící k p ehlednosti seznamu poskytovaných sluºeb. Informace o platbách reprezentuje entita sms_sessions. Význam jejích atribut je následující: receivers_address... IP adresa klienta volajícího proceduru Receive(). receivers_port... TCP port klienta volajícího metodu Receive(). keyword... klí ové slovo zadané uºivatelem p evedené na velká písmena shodné s hodnotou atributu keyword procedury Receive(). id... jednozna ný celo íselný identikátor poºadavku shodný s hodnotou atributu id procedury Receive(). operator... kód mobilního operátora zákazníka shodný s hodnotou atributu operator procedury Receive(). received... datum a as p ijetí zprávy SMS centrem mobilního operátora shodný s hodnotou atributu received procedury Receive(). dst_number... telefonní íslo, na které zákazník zaslal sv j poºadavek shodné s hodnotou atributu dstnumber procedury Receive(). src_number... telefonní íslo zákazníka shodné s hodnotou atributu srcnumber procedury Receive(). in_text... celý text zprávy v podob, jaké jí zákazník odeslal shodný s hodnotou atributu text procedury Receive(). receive_status... boolská hodnota udávající, zda byl poºadavek procedury Receive() zpracován úsp ²n i ne. Tato hodnota odpovídá hodnot atributu Status návratového typu procedury Receive(). type... kód typu zprávy pro odpov shodný s hodnotou atributu type návratového typu procedury Receive().

59 16.3 Modul pro SMS platby 43 price... cena sluºby v K s DPH shodná s hodnotou atributu Price návratového typu procedury Receive(). out_text... text zprávy, kterou uºivatel obdrºí, shodný s hodnotou atributu text návratového typu procedury Receive(). conrmer_address... IP adresa klienta volajícího proceduru Conrm(). conrmer_port... TCP port klienta volajícího proceduru Conrm(). conrmed... datum a as potvrzení i zamítnutí platby shodný s hodnotou atributu conrmed procedury Conrm(). conrm_status... boolská hodnota zna ící úsp ²nost platby shodná s hodnotou atributu status procedury Conrm(). user_id... unikátní identikátor uºivatelského oprávn ní vygenerovaného pro danou platbu. username... p ístupové uºivatelské jméno vygenerované pro danou platbu. password... p ístupové heslo vygenerované pro danou platbu. added... datum a as p id lení uºivatelského oprávn ní pro danou platbu. removed... datum a as odebrání uºivatelského oprávn ní pro danou platbu. Obrázek 17: SMS Gateway - model dat Z popisu komunikace mezi SMS agregátorem a na²ím modulem pro SMS platby vychází model stav, ve kterých se m ºe platba nacházet. Tento model je zobrazen na obrázku 18. V kaºdém stavu navíc entita sms_sessions nabývá r zných volitelných hodnot. Vý et atribut s hodnotami p i azenými v jednotlivých stavech je sepsán v tabulce 3.

60 44 16 SMS PLATBY ˆ Po zavolání procedury Receive() vznikne nová instance entity sms_sessions. Platba se nachází ve stavu P ijato. ˆ Následuje kontrola poºadavku, která m ºe p i neúsp chu skon it v jednom ze t ech stav. Pokud klí ové slovo, tedy hodnota atributu keyword, není AG, p ejde se do stavu Chybné klí ové slovo. Vedle klí ového slova o ekáváme je²t kód sluºby. Pokud tedy po et atribut není 1, p echází se do stavu Chybný po et atribut. Pokud je po et atribut správný, ale kód sluºby neodpovídá ºádné instanci entity sms_services, p ejde se do stavu Neznámý kód sluºby. Z t chto t ech stav vede cesta do stavu Odeslána negativní odpov, do kterého se p echází návratem z procedury Receive() v p ípad jedné z t chto t í chyb. Toto je koncový stav. ˆ Pokud kontrola prob hne v po ádku, vytvo í se ºádajícímu uºivateli oprávn ní a platba p echází do stavu P id leno oprávn ní. ˆ Po p id lení oprávn ní je moºné provést návrat z procedury Receive(). Platba p ejde do stavu Odeslána pozitivní odpov. ˆ Z tohoto stavu ihned p echází do stavu Nepotvrzeno a eká se na volání procedury Conrm(). ˆ Nakonec po zavolání této procedury p ejde platba do jednoho ze dvou koncových stav, Potvrzeno nebo Zamítnuto, podle významu volání této procedury.

61 16.3 Modul pro SMS platby 45 Obrázek 18: SMS Gateway - stavový diagram platby

62 46 16 SMS PLATBY Tabulka 3: SMS Gateway - tabulka pokrytí atribut sms_sessions stavy platby receivers_address receivers_port keyword id operator received dst_number src_number in_text received_status type price out_text conrmer_address conrmer_port conrmed conrm_status user_id username password added removed stav / atribut P ijato x x x x x x x x x Chybné klí ové slovo x x x x x x x x x Chybný po et atribut x x x x x x x x x Neznámý kód sluºby x x x x x x x x x Odeslána negativní odpov x x x x x x x x x x x x x P id leno oprávn ní x x x x x x x x x x x x x x Odeslána pozitivní odpov x x x x x x x x x x x x x x x x x x Nepotvrzeno x x x x x x x x x x x x x x x x x x Potvrzeno x x x x x x x x x x x x x x x x x x x x x x Zamítnuto x x x x x x x x x x x x x x x x x x x x x x

63 16.3 Modul pro SMS platby Návrh modulu pro SMS platby Procedury webové sluºby jsou deklarovány v rozhraní ISmsContract. Samotný modul pro SMS platby je implementován ve t íd SmsManager. Tato t ída implementuje jak metody rozhraní ISmsContract reprezentující procedury na²í webové sluºby, tak metody rozhraní IManagementModule pro moºnost zapojení tohoto modulu jako komponentu sluºby HotSpot User Manager. Práci s databází zabezpe uje t ída SmsData spolu s entitními t ídami Session a Service. T ída ReceiveResponseType reprezentuje návratový typ procedury Receive(). Obrázek 19: SMS Gateway - business t íd Implementace modulu pro SMS platby Modul SMS Gateway pro SMS platby jsem implementoval pomocí jazyka C# pro platformu Microsoft.NET Framework 3.5[9] jako DLL knihovnu. Pro komunikaci s databází User Manageru je vyuºito objektov -rela ní mapování LINQ to SQL[9]. Webovou sluºbu jsem implementoval pomocí frameworku Windows Communication Foundation[9]. Tato volba skýtá dv výhody. První je omezení psaní vlastního kódu pouze na vlastní procedury webové sluºby. Druhou výhodou je moºnost provozovat tuto webovou sluºbu bez aplika ního serveru (nap. IIS 11 ). Pro na²e o ekávané mnoºství zákazník toto dosta uje a p ípadný budoucí p echod na aplika ní server je pouze otázkou kongurace. Je²t jedna 11 Microsoft Internet Information Server - Aplika ní a webový server pro Windows.

64 48 17 DAL Í MOšNOSTI INSTANTNÍCH PLATEB výhoda, kterou ale v tuto chvíli nevyuºijeme, je moºnost pouºití libovolného komunika ního protokolu znovu pouhou zm nou kongurace. To m ºe usnadnit p echod k jinému SMS agregátorovi, p ípadn p ipojení více SMS agregátor Testování modulu pro SMS platby Pro testování tohoto modulu slouºí dva projekty. Prvním z nich je SMSTestClient, coº je GUI aplikace, která volá webovou sluºbu s parametry zadanými uºivatelem. Slouºí pro simulaci klientské strany, tzn. SMS agregátora a byla pouºita pro odlad ní projektu. Druhým projektem je SmsGatewayTest, coº je sada Unit Test pro testovací sluºbu, která je sou ástí IDE 12 Microsoft Visual Studio[9]. Byly implementovány tyto testy: ˆ Test korektního poºadavku - metoda OK(). ˆ Test poºadavku s nesprávným klí ovým slovem - metoda WrongKeyword(). ˆ Test poºadavku s nesprávným kódem sluºby - metoda WrongService(). ˆ Test poºadavku s chyb jícím kódem sluºby - metoda NoService(). ˆ Test n kolika soub ºných poºadavk - metoda ParallelTest(). Tyto testy automaticky ov ují správné fungování modulu pro SMS platby i samotného HotSpot User Manageru. Mimo ov ení správného fungování bylo také b hem vícenásobného volání tohoto testu sledováno vyuºití systémových prost edk, zejména mnoºství alokované opera ní pam ti. Po n kolika voláních se maximální velikost alokované opera ní pam ti ustálila na necelých 30 MB, coº ov ilo správné nakládání sluºby s vyuºitými systémovými prost edky. 17 Dal²í moºnosti instantních plateb Do budoucna je moºné systém roz²í it o dal²í moºnosti instantních plateb. Dále jsou stru n popsány n které z nich. V²echny tyto zp soby plateb vyuºívají stejný technický princip. Platba probíhá tak, ºe je zákazník v webový prohlíºe po objednání sluºby z webu obchodníka p esm rován na platební bránu, kde zákazník zadá poºadované údaje a po ov ení transakce je jeho prohlíºe p esm rován zp t na web obchodníka, který zárove obdrºí informace o stavu transakce, se kterými pak naloºí dle svého uváºení Platba kreditní kartou V t²ina platebních karet dnes poskytuje moºnost p ímých plateb prost ednictvím internetu bez pouºití terminál. Pro poskytnutí takové sluºby je t eba navázat spolupráci s n kterou z bank[14, 15] poskytující takovou sluºbu. Podmínky pouºívání této sluºby se zdají být obdobné podmínkám pouºívání sluºby SMS plateb. Nap. ƒeská spo itelna tuto sluºbu nabízí bez z izovacího a m sí ního poplatku a bere si sv j podíl pouze z uskute n ných plateb[14]. U tohoto druhu plateb existuje velké riziko zneuºití platebních údaj. Tyto údaje jsou totiº u kaºdé platební karty stále stejné a p i zcizení je moºné tyto údaje do doby 12 Integrated Development Environment - integrované prost edí pro vývoj aplikací.

65 17.2 Platba pomocí elektronické pen ºenky 49 zablokování karty na ºádost uºivatele neomezen vyuºívat. Na stran obchodníka je t eba zajistit, aby nedocházelo k úniku informací o transakcích. Zákazník v po íta pak musí být dob e chrán n antivirovým programem a rewallem a b hem provád ní transakce nesmí být pozorován cizí osobou Platba pomocí elektronické pen ºenky Elektronická pen ºenka je platební nástroj p vodn ur ený pro p ímé platby prost ednictvím internetu. Existují r zné druhy elektronických pen ºenek (nap. [16, 17]). N které vyºadují udrºování stavu konta, ze kterého se ode ítají jednotlivé platby, jiné platby strhávají p ímo z platební karty i bankovního ú tu. V²echny ale poskytují lep²í zabezpe ení neº samotná platební brána pro kreditní kartu. Elektronické pen ºenky vyuºívají r zné zp soby autentizace a autorizace uºivatel. I ten základní, ov ení uºivatelským jménem a heslem, nabízí vy²²í úrove bezpe nosti neº on-line platba kreditní kartou. I kdyº si uºivatel tyto údaje poznamená, nalézt je je obtíºn j²í neº pouhý pohled na kreditní kartu. Své heslo si navíc uºivatel m ºe kdykoliv zm nit. Nevýhoda této sluºby tkví v tom, ºe je zákazník nucen seznámit se s novou, pro n j neznámou sluºbou a musí si pamatovat dal²í platební údaje Platba prost ednictvím internetového bankovnictví Co se tý e bezpe nosti, poskytuje platba prost ednictvím internetového bankovnictví ve v t²in p ípad vy²²í úrove zabezpe ení neº elektronická pen ºenka. Zárove je komfortn j²í pro uºivatele, protoºe mu umoº uje vyuºít sluºbu, na kterou je jiº zvyklý. Problém tohoto zp sobu platby je v implementaci. Kaºdá banka má totiº sv j vlastní systém a je proto nutné nabízet tuto sluºby individuáln pro zákazníky kaºdé z bank.

66 50 17 DAL Í MOšNOSTI INSTANTNÍCH PLATEB

67 ƒást VI Vyhodnocení a reálné nasazení 18 Testování Testování probíhalo na dvou úrovních. B hem vývoje a po jeho dokon ení byly provedeny testy v laboratorním prost edí, které ov ily správnou funkci jednotlivých komponent. Tyto testy jsou popsány v ásti 14 na stran 27 a na stran 48. Následn bylo provedeno nasazení systému do produk ního prost edí, viz dal²í ást, kde byly p ed ociálním uvedením do provozu provedeny záv re né testy, které prokázaly fungování systému jako celku. Pro tento test byla vytvo ena sluºba s cenou 20 K, kódem 1 a asovým limitem 10 minut. Zkou²eny byly následující scéná e: ˆ Odeslání SMS ve tvaru AG. Odpov byla Neplatne zadani. Pro vyuziti nasich sluzeb pouzijte tvar AG kod sluzby. AG-Net. ˆ Odeslání SMS ve tvaru AG 0. Odpov byla Sluzba s kodem 0 nebyla nalezena. Opakujte prosim zadani. AG-Net. ˆ Odeslání SMS ve tvaru AG 1. Odpov byla Platba 20,- Kc prijata. Pro pripojeni pouzijte jmeno a heslo Dekujeme. AG-Net. ˆ Pokus o p ipojení s náhodným jménem a heslem. P ipojení bylo odmítnuto s chybovou hlá²kou Nespravne uzivatelske jmeno nebo heslo.. ˆ Pokus o p ipojení se získaným jménem a heslem. P ipojení bylo úsp ²né. ˆ Restart PC a nový pokus o p ipojení b hem 5 minut. P ipojení prob hlo úsp ²n bez dotázání na p ístupové údaje. ˆ Spu²t ní internetového rádia. P enos byl po jedné minut od prvního p ihlá²ení p eru²en. P i pokusu o p ístup na webovou stránku rádia byl webový prohlíºe p esm rován zp t na p ihla²ovací stránku HotSpotu. ˆ Pokus o p ipojení se získaným jménem a heslem po více jak deseti minutách od prvního p ihlá²ení. P ipojení bylo odmítnuto s chybovou hlá²kou Uºivatel dosáhl maximální doby p ipojení.. 19 Pilotní provoz B hem psaní tohoto textu byl v na²í síti spu²t n pilotní provoz tohoto projektu. V následujících odstavcích je popsané konkrétní e²ení. Výchozí stav byl popsán v úvodu na stran 1. 51

68 52 19 PILOTNÍ PROVOZ 19.1 Komunikace s SMS agregátorem Sluºba HotSpot User Manager (viz ást 15 na stran 28) byla nasazena na server, kde dosud b ºel pouze dohledový systém. Z router, které slouºí jako brány do internetu, byly p esm rovány porty na tuto sluºbu. S SMS agregátorem Erika, a.s. byla podepsána smlouva, která nám umoºnila vyuºití SMS plateb tak, jak jsou popsány v ásti 16 na stran Autentiza ní sluºba Autentiza ní a autoriza ní server Clutch.Radius (viz ást 9 na stran 27) byl nasazen na tentýº stroj jako sluºba HotSpot User Manager. V tuto chvíli bohuºel není dostupný jiný stroj, který by mohl fungovat jako záloºní, ale v p ípad, ºe se sluºba do asného p ipojení k internetu mezi zákazníky uchytí, bude t eba tuto v c vy e²it a zajistit co nejlep²í vykrytí potenciálních výpadk P ipojení stálých uºivatel Na²e sí své stálé uºivatele m la jiº p ed spu²t ním tohoto pilotního projektu. Jejich p ipojení funguje dle popisu v ásti 11.2 na stran 17, takºe na tomto stavu nebylo t eba nic m nit P ipojení stálých instantních uºivatel Pro moºnost p ipojení stálých instantních uºivatel bylo t eba p idat ke kaºdému fyzickému p ístupovému bodu chrán ného pomocí WPA2-PSK vºdy jeden virtuální bez zabezpe ení a provést konguraci HotSpot dle popisu v téºe ásti textu P ipojení náhodných instantních uºivatel Protoºe náhodní instantní uºivatelé budou k p ipojení vyuºívat p eváºen mobilní za ízení, která nedisponují dostate ným vysílacím výkonem a navíc budou umíst na u zem, tzn. pod zna ným vertikálním úhlem v i na²im anténám umíst ným na st echách a stoºárech a sm ujících p eváºn vodorovn, bylo nutné vy e²it v t²í pokrytí zajímavých míst na²ím signálem. T mito místy jsou v sou asnosti autobusové zastávky. Pozd ji by to m ly být parky, nám stí a jiná ve ejná prostranství, p ípadn provozovny podnik nabízejících sluºby jako jsou restaurace, kavárny nebo kade nictví i budovy typu obecního ú adu nebo po²ty. Jako první byla pokryta autobusová zastávka na To né. S výhodou jsme k tomu vyuºili klientské za ízení zákazníka, který má d m hned u zastávky a na jehoº za ízení je ze zastávky p ímá viditelnost. Toto za ízení jsme p epnuli do reºimu WDS (viz ást 6.3 na stran 9), p ipojili k virtuálnímu p ístupovému bodu, který jsme vytvo ili paraleln k fyzickému p ístupovému bodu, kam byl zákazník p vodn p ipojen. Adresu jeho po íta e jsme nastavili jako pr chozí p íkazem ip hotspot ip-binding add type=bypassed address=

69 19.6 Monitorování sít a sluºeb 53 kde je p íklad adresy, kterou chceme nastavit jako pr chozí. Tímto jsme tomuto zákazníkovi zajistili stejnou sluºbu, jako m l dosud a zárove jsme bez dal²ích náklad vy e²ili pokrytí To enské zastávky. Stejný a stejn e²itelný problém existuje na autobusových zastávkách v Dolních B eºanech. Tyto zastávky jsou vybaveny informa ními tabulemi, které zobrazují nejbliº²í asy p íjezd autobus a dal²í uºite né informace. Tyto tabule jsou p ipojeny k internetu pomocí na²í sít. V tuto chvíli probíhá jednání s provozovatelem t chto tabulí o dohod na p epnutí jeho WiFi klientských za ízení do reºimu WDS. V Cholupicích a Zlatníkách taková moºnost zatím není a lep²í pokrytí t chto míst se prozatím odloºilo Monitorování sít a sluºeb Samotná sí jiº byla monitorována dohledovým systémem Mikrotik Dude, který nabízí i HTTP a RADIUS sondy, pomocí nichº jsme zajistili sledování webové sluºby pro komunikaci s SMS agregátorem i autentiza ní a autoriza ní sluºby Clutch.Radius. 20 Pokrytí poºadavk 20.1 Nutné funk ní poºadavky V²echny nutné funk ní poºadavky se poda ilo vy e²it. Tabulka 4 uvádí odkazy na ásti tohoto textu, které jednotlivé nutné funk ní poºadavky e²í. Tyto ásti pro e²ení problému v t²inou vyuºívají poznatky z ástí p edchozích. V takových p ípadech je pak odkaz na pot ebné znalosti uveden p ímo v textu. Tabulka 4: Tabulka pokrytí nutných funk ních poºadavk ƒíslo poºadavku ƒásti textu e²ící poºadavek 1 V na stran na stran 21, IV na stran 25 3 IV na stran na stran na stran 18, na stran na stran na stran Volitelné funk ní poºadavky Z t chto poºadavk se poda ilo uspokojit pouze poºadavek Ten je e²en v ásti na stran 21. Dále byly stru n shrnuty n které alternativní zp soby instantních plateb zmín ných v poºadavcích 3.2, 12 a 13. Popis t chto sluºeb se nachází v ásti 17 na stran 48.

70 54 20 POKRYTÍ POšADAVK 20.3 Nefunk ní poºadavky Nefunk ní poºadavky byly stejn jako nutné funk ní poºadavky v²echny spln ny. Pokrytí t chto poºadavk tímto textem je uveden v tabulce 5. I zde platí, ºe odkazované ásti textu vyuºívají poznatky z jiných jeho ástí. Tabulka 5: Tabulka pokrytí nefunk ních poºadavk ƒíslo poºadavku ƒásti textu e²ící poºadavek na stran Prolíná se nap í textem na p edchozí stran na stran na p edchozí stran na stran 32

71 21 Záv r Byla navrºena a implementována serverová aplikace poskytující autentiza ní a autoriza ní rozhraní pro sluºbu HotSpot router Mikrotik. Ú tovací sluºba RADIUS serveru nebyla vyuºita, protoºe pro ní nebylo nalezeno uplatn ní v rámci specikovaných poºadavk. Dále byla navrºena vhodná kongurace sm rova zachovávající moºnost p ipojení stálých zákazník a umoº ující p ipojení uºivatel prost ednictví libovolného routeru v síti. Z moºných zp sob p ímých plateb bylo implementováno placení pomocí SMS zpráv, které umoºní sluºbu vyuºívat nej²ir²ímu spektru uºivatel. Dal²í moºnosti plateb byly stru n specikovány. Uºivatelé si SMS platbou p edplatí p ístup k internetu na dobu odpovídající cen zprávy. Celé e²ení bylo testováno jak v laboratorním, tak produk ním prost edí a po odlad ní nedostatk byl spu²t n jeho pilotní provoz. Tím bylo spln no zadání této diplomové práce. Byl vytvo en produkt, který umoº uje provozovateli sít AG-Net pokrýt dosud nevyuºitou ást dostupného trhu. Pro jeho nasazení byla vyuºita stávající infrastruktura sít a nebylo tak zapot ebí investic do nových za ízení. Projekt je nyní moºné provozovat v komer ním prost edí a zárove ho dále roz²i ovat. Práce specikuje volitelné poºadavky, kterými je moºné systém vylep²it. Dal²í poºadavky pak mohou p inést zku²enosti ze samotného provozu systému. 55

72 56 21 ZÁV R

73 Rejst ík Ú tování, a, b, b/g, g, h, n, x, 7, 10 AAA, Authentication, Authorization and Accounting, 25 Ad-Hoc, 7 ADO.NET, 34 AG-Net, 1 AOP, Aspect Oriented Programming, 33, 34 AP, Access Point, 8 Autentizace, 25 Autorizace, 25 BSS, Basic Service Set, 8 CHAP, Challange Authentication Protocol, 21 Client, 8 Clutch.Radius, 26 DFS, Dynamic Frequency Selection, 11 Dude, 53 EAP, Extensible Authentication Protocol, 13 ESS, Extended Service Set, 8 Funk ní poºadavky, 3, 4, 53 HotSpot, 13, 21 HotSpot User Manager, 28, 48 IDE, Integrated Development Environment, 48 Infrastruktura, Infrastructure, 8 Kreditní karta, 48 LAN, Local Area Network, 13 LINQ to SQL, 34 log4net, 34 MAC, Media Access Control, 12 MAN, Metropolitan Area Network, 13 Mikrotik, 15 MIMO, Multiple-Input Multiple-Output, 11 MO, Mobile Originated, 37 Modul pro SMS platby, 38 MT, Mobile Terminated, 37 Nefunk ní poºadavky, 4, 54 NTP, Network Time Protocol, 23 Open System, 12 PAP, Password Authentication Protocol, 21 Peer-To-Peer, 7 PoE, Power over Ethernet, 15 PostSharp, 34 PSK, Preshared Key, 13 RADIUS, 23, 25 RouterBOARD, 15 RouterOS, 15, 16, 26 RPC, Remote Procedure Call, 38 SMS agregátor, 37 SMS platby, 37 SMSTestClient, 48 SQL Server 2008, 34 SSH, 16, 17 SSID, Service Set ID, 8 Station, 8 Telnet, 16, 17 TPC, Transmit Power Control, 11 User Manager, 28 VirtualBox, 27 Walled Garden, 22 WAN, Wide Area Network, 13 WDS, Wireless Distribution System, 9 Webová sluºba, Web Service, 38 WEP, Wired Equivalent Privacy, 12 WiFi, 7, 10 57

74 58 REJST ÍK Winbox, 16, 17 WLAN, Wireless LAN, 10 WPA2, WiFi Protected Access, 12

75 23 SEZNAM LITERATURY Seznam literatury [1] Wikipedia - IEEE [2] Introduction to Wi-Fi ( or WiFi) [3] MikroTik Wiki [4] MikroTik RouterOS v2.9 Reference Manual [5] MikroTik [6] Kolektiv autor, RFC Remote Authentication Dial In User Service (RA- DIUS), The Internet Society, 2000 [7] Sun VirtualBox [8] IEA Radlogin v4 [9].NET Framework Developer Center [10] SharpCreafters - The Creators of PostSharp [11] Apache log4net [12] SQL Server 2008 Overview [13] Erika, a.s. - Placení za sluºby i informace [14] ƒeská spo itelna - E-commerce 3D-Secure [15] Komer ní banka - Akceptace platebních karet [16] PayPal [17] PayPay

76 60 23 SEZNAM LITERATURY

77 A Dostupná e²ení HotSpot Jak jiº bylo popsáno, v²echna nalezená e²ení sdílejí jednu vlastnost, kterou je koncentrace celého mechanismu ov ování a zabezpe ení do jednoho bodu. Tím je vylou eno pouºití kteréhokoliv z nich pro na²e ú ely. Dal²í spole nou vlastností je ov ování uºivatel pomocí p esm rování jejich webových prohlíºe na ov ovací webovou stránku. V²echny uvedené produkty také nabízejí omezení doby p ipojení, mnoºství p enesených dat a ²í ky pásma. A.1 Provisio MyPublicHotSpot MyPublicHotSpot je komer ní projekt rmy Provisio 13. Nabízí uºivatelsky p ív tivé e²ení s n kolika zajímavými funkcemi za cenu $399 bez DPH. Disponuje t mito hlavními vlastnostmi: ˆ Neomezený po et uºivatel. ˆ Moºnost vlastního vzhledu uºivatelského rozhraní. ˆ Snadná instalace na PC s jedním rozhraním do internetu a druhým do sít p ístupových bod. ˆ Pro p ístup do sít lze vyuºít uºivatelské jméno a heslo, PIN vyti²t ný nap. na poukázce nebo kuponu a PayPal. ˆ Ú tování. ˆ Sledování nav²tívených URL. ˆ Moºnost p ístupu na n které webové stránky bez p edchozí autentizace. ˆ Moºnost propojení s produktem Ticket Station pro automatizovaný prodej kupon s PINem pro p ístup do sít. A.2 Antamedia HotSpot Software HotSpot Software je také komer ní projekt, tentokrát od rmy Antamedia 14. Nabízí o n co více funkcí neº p edchozí produkt. Cena se pohybuje od $199 bez DPH za HotSpot pro 20 klient s omezeným mnoºstvím funkcí po $1200 bez DPH za HotSpot pro neomezený po et uºivatel s vlastním vzhledem uºivatelského rozhraní. Nabízené vlastnosti jsou následující. ˆ Po et uºivatel podle licence. S po tem uºivatel roste cena. ˆ Moºnost vlastního vzhledu uºivatelského rozhraní pouze s nejdraº²í licencí. ˆ Snadná instalace na PC s jedním rozhraním do internetu a druhým do sít p ístupových bod. 13 Webové stránky rmy Provisio se nacházejí na adrese 14 Webové stránky rmy Provisio se nacházejí na adrese 61

78 62 A DOSTUPNÁ E ENÍ HOTSPOT ˆ ƒasov omezené uºivatelské ú ty. ˆ Trvalé uºivatelské ú ty. ˆ Vymezení denní doby s povoleným p ístupem. ˆ Ú tování. ˆ Platba kreditní kartou za p íplatek $70 bez DPH. ˆ Volný p ístup s omezeným p ipojením. ˆ P esm rování prohlíºe e na vybranou adresu po p ihlá²ení. ˆ Automatizace opakovaného úsp ²ného pokusu o p ihlá²ení. Uºivatel není ºádán o ov ení více neº jednou. ˆ Filtr IP adres a TCP/UDP port a URL adres. ˆ Sledování nav²tívených URL, mnoºství p enesených dat, vyuºité ²í ky pásma, atp. A.3 NoCatAuth a NoCatSplash NoCat 15 je komunitní sí nacházející se v Sonoma County, CA v USA. Sí b ºí na vlastním softwaru NoCatAuth napsaném v jazyce Perl a jeho portu do jazyka C NoCat- Splash pro ízení p ístupu k síti. Jde o aplikace slouºící pro p esm rování uºivatele na autentiza ní webovou stránku a provedení vlastní autentizace. Ob aplikace jsou psané pro Linux a jsou schopné b ºet na routerech s linuxovým jádrem. A.4 CoovaChilli CoovaChilli je Open Source projekt navazující na p vodní ukon ený projekt ChilliSpot. Jde o obdobu p edchozího e²ení. Navíc ho lze ale integrovat do webových portál jako JSON 16 modul, CGI 17 modul nebo jako modul redak ního systému Drupal 18. A.5 WiFiDog WiFiDog 19 je komunitní Open Source projekt vytvo ený jako náhrada pro sít b ºící na NoCatAuth nebo NoCatSplash. Stejn jako tyto dv e²ení slouºí WiFiDog pro p esm rování uºivatele na autentiza ní webovou stránku, provedení vlastní autentizace a stejn tak je psaný pro Linux a je schopen b ºet na routerech s linuxovým jádrem. Dále WiFiDog poskytuje tyto moºnosti: ˆ Administrace obsahu p ístupného uºivatel m. 15 Webová prezentace sít NoCat je dostupná na adrese 16 JavaScript Object Notation - jednoduchý textový formát pro vým nu dat vycházející z prvk jazyka Java. 17 Common Gateway Interface - protokol pro propojení externích aplikací s webovým serverem. 18 Webová prezentace projektu Drupal se nachází na adrese 19 Webová prezentace projektu WiFiDog je dostupná na adrese

79 A.6 Public IP ZoneCD Gateway 63 ˆ Vícejazy ná podpora. (ƒeský p eklad není dostupný.) ˆ Uºivatelé si mohou vytvo it ú et sami. Po registraci mají na 15 minut zp ístupn nou sí pro ov ení své ové adresy. ˆ Monitorování p ístupových bod. ˆ Automatická kongurace nového p ístupového bodu. ˆ Generování r zných report pro lep²í p ehled o d ní na síti. A.6 Public IP ZoneCD Gateway ZoneCD Gateway je Open Source produkt od rmy Public IP 20. Tento produkt je moºné voln vyuºívat ve své síti s vlastní správou. Druhou moºností je vyuºití nabídky jedné ze ty sluºeb rmy Public IP a nechat si sv j HotSpot provozovat od ní. Tyto sluºby se pohybují od $7,95 do $15,95 bez DPH m sí n s moºností 10% slevy p i platb na rok. Tento produkt poskytuje následující moºnosti: ˆ Upravená verze produktu WiFiDog umoº ující lépe ovládat moºnosti uºivatele a zaji² ující spolupráci s dal²ími komponentami. ˆ Firewall umoº ující blokování a p esm rování port a separaci sí ových rozhraní. ˆ Rozd lení uºivatelských ú t na ty i skupiny podle míry oprávn ní. ˆ Filtrování obsahu pomocí upraveného projektu Dansguardian 21. ˆ Zp ístupn ní sít pouze na ur enou denní dobu. ˆ Moºnost p edp ipravených uºivatelských ú t jako náhradu za individuální registraci nabízenou ve WiFiDogu. ˆ Sledování d ní na síti formou RSS 22 kanálu. ˆ Adresá HotSpot publikovatelný na webu pro nové uºivatele. ˆ Kongura ní fronta, ve které se p i zm n kongurace nashromáºdí v²echna kongura ní data, klient m (pouze Windows 2000 a vy²²í) se roze²le zpráva s informací o údrºb sít a b hem 5 minut se sí rekonguruje a restartuje. Na konec je správci odeslán s informací o provedení kongurace. ˆ Volba vzhledu uºivatelského rozhraní zaloºená na ²ablonovém systému Smarty 23. K dispozici je n kolik p edp ipravených ²ablon. Dal²í je moºné p idat. ˆ Proxy server. ˆ Sdílení sí ových tiskáren. 20 Webová prezentace rmy Public IP se nacházejí na adrese 21 Webová prezentace projektu Dansguardian se nacházejí na adrese 22 RSS je rodina XML formát ur ených pro tení novinek na webových stránkách. Samotná zkratka má n kolik výklad. 23 Webová prezentace projektu Smarty se nacházejí na adrese

80 64 A DOSTUPNÁ E ENÍ HOTSPOT ˆ Upravitelné ové zprávy odesílané uºivateli p i uvítání, ztrát hesla a ov ení ové adresy.

81 65 B Srovnání vybraných SMS agregátor B.1 Nabídky oslovených agregátor Nabídky oslovených agregátor se li²í ve vý²i poplatk, které za své sluºby poºadují, ve vý²i provize a v technických detailech. Provize je podíl z ceny SMS bez DPH, který agregátor odvádí nám jako svému partnerovi. B.1.1 Pay SMS lite - sms.sluzba.cz Tento agregátor nabízí pouze cenové hladiny 69 a 99 K. Vý²e provize je 68% a je moºný pouze reºim Mobile Originated. Telefonní ísla tak jsou , resp šádné poplatky za tuto sluºbu nejsou poºadovány. B.1.2 sms.cz Premium SMS - gonet Aktiva ní poplatek za sluºby tohoto agregátora iní 2000 K bez DPH. Jako klí ové slovo lze vyuºít slovo WEB. Pokud bychom cht li vyuºít jiné klí ové slovo, je nutné poplatek navý²it o dal²ích 1000 K bez DPH. Pro obsluhu sluºby je dostupné webové rozhraní. Nabízené cenové hladiny jsou 3, 6, 9, 10, 15, 30, 50, 79 a 99 K. Provize se pohybují od 18% do 52% v závislosti na cenové hladin a mobilním operátorovi zákazníka. Agregátor nabízí pouze reºim Mobile Originated. Telefonní ísla tak mají formát xx, kde xx je hodnota cenové hladiny. B.1.3 mobilniplatby.cz Agregátor nabízí cenové hladiny 10, 20, 30, 50, 79 a 99 K. Provize se pohybují od 32% do 52% v závislosti na cenové hladin a mobilním operátorovi zákazníka. Více informací agregátor v nabídce neuvedl. B.1.4 Erika, a.s. Tento agregátor nepoºaduje ºádné z izovací ani pau²ální poplatky 24. Agregátor nabízí cenové hladiny 20, 30, 40, 50, 60, 70, 80, 90 a 99 K. Navíc je moºné vyuºít i b ºné SMS pro testování s minimálními náklady. Provize je 70% bez ohledu na cenovou hladinu a mobilního operátora zákazníka. B.1.5 Materna mobilní platby Tento agregátor nepoºaduje ºádné vstupní ani pau²ální poplatky, ale jeho nabídka je velmi omezená a nan n nezajímavá. Nenabízí reºim Mobile Terminated a jeho provize je maximáln 56% podle cenové hladiny a mobilního operátora zákazníka. Výjimkou je zvýhodn ný premium SMS tarif, který je ur en pro výjime né sluºby z terciární sféry, nap. SMS jízdné, parkovné, atp., kde je provize 75%, ale jediná cenová hladina je 99 K a stále jde o reºim Mobile Originated. 24 Z izovací poplatek ve vý²i 1000 K bez DPH se objevil ve smlouv bez p edchozího upozorn ní.

82 66 B SROVNÁNÍ VYBRANÝCH SMS AGREGÁTOR B.1.6 PR SMS - Media Support s.r.o. Media Support nabízí zajímavé provize ve vý²i od 76% do 78%, ale cenové hladiny jsou pouze 10, 15, 20 a 99 K. Za zprovozn ní jiné hladiny si ú tuje poplatek 5000 K. Dále nabízí odli²né technické e²ení, kdy by se zákazník m zasílaly p edem dohodnuté p ístupové údaje. B.1.7 premiumsms.cz Tento agregátor poºaduje nejvy²²í z izovací poplatek ve vý²i K. Více informací poskytuje na vyºádání, ale uº takto vysoký poplatek p evy²uje rozpo et na tento projekt, který po ítá s minimálními náklady na z ízení. B.1.8 Tanger PRSMS Agregátor Tanger nabízí provize od 32% do 66%, nulový z izovací a m sí ní poplatek a cenové hladiny 6, 15, 30, 50, 79 a 99 K. B.1.9 Dal²í agregáto i Tito agregáto i neodpov d li na poptávku: ˆ SMS IN - ATS Praha ˆ Airtoy mplatby ˆ SMS platby - Topic Press B.2 Výb r agregátora Protoºe vý²e nejvy²²ích provizí se mezi agregátory poºadujícími z izovací poplatek p íli² neli²í, byli z výb ru ihned vylou eni ti, kte í tento poplatek poºadují. Dal²ími kritérii pro výb r byl rozsah nabízených cenových hladin a podíl na cen SMS zpráv. Rozsah cenových hladin srovnává tabulka 6, vý²e provizí v závislosti na mobilním operátorovi zákazníka pak graf na obrázku 20. Srovnání provizí je provedeno na cenové hladin 99 K, protoºe to je jediná cenová hladina, kterou nabízejí v²ichni porovnávaní agregáto i. Tabulka 6: Cenové hladiny SMS agregátor v K PaySMS lite 69, 99 mobilniplatby.cz 10, 20, 30, 50, 79, 99 Erika, a.s. 20, 30, 40, 50, 60, 70, 80, 90, 99 Media Support s.r.o. 10, 15, 20, 99 Tanger, s.r.o. 6, 15, 30, 50, 79, 99

83 B.2 Výb r agregátora 67 Obrázek 20: Srovnání nabízených provizí SMS agregátor Co se tý e vý²e provize, je na tom nejlépe agregátor Media Support s.r.o. Bohuºel ale nenabízí takový rozsah cenových hladin SMS zpráv. Navíc p edstavuje komplikaci z pohledu technického e²ení. Proto byl nakonec zvolen agregátor Erika, a.s., který nabízí druhé nejvy²²í provize a nejvy²²í rozsah cenových hladin SMS zpráv. Po dal²ím jednání také bylo moºné dohodnout technické e²ení ideální pro ob strany.