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
iv
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
vi
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
viii
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 su cient 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 de nition 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
x
Obsah Seznam obrázk·
xv
Seznam tabulek 1
xvii
Popis problému, speci kace cíle
1
I Analýza poºadavk·
3
2
Nutné funk£ní poºadavky (Must Have)
3
2.1
Ú£tování podle doby p°ipojení . . . . . . . . . . . . . . . . . . . . . . . .
3
2.2
Platba pomocí Premium-SMS
3
2.3
Informace zobrazující se neautorizovaným uºivatel·m
3
4
5
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3
Volitelné funk£ní poºadavky (Nice To Have)
4
3.1
Dal²í metody ú£tování
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
3.2
Dal²í metody platby
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
3.3
Omezení neplatících stálých zákazník·
. . . . . . . . . . . . . . . . . . .
4
3.4
Zpracování ú£etních doklad· . . . . . . . . . . . . . . . . . . . . . . . . .
4
3.5
P°ístup k vybraným sluºbám bez placení . . . . . . . . . . . . . . . . . .
4
Nefunk£ní poºadavky 4.1
Kon gurace RouterOS
4.2
Bezpe£nost sít¥
4.3
Monitorování systému
4 . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
Uºivatelské role
5
5
II Technologie 802.11x - WiFi
7
6
7
7
Topologie 6.1
Ad-Hoc
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
6.2
Infrastruktura (Infrastructure) . . . . . . . . . . . . . . . . . . . . . . . .
8
6.3
Wireless Distribution System (WDS)
. . . . . . . . . . . . . . . . . . . .
9
6.4
Kombinace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
Fyzická vrstva
9
7.1
802.11b
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
7.2
802.11g . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
7.3
802.11a, 802.11h . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10
7.4
802.11n
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
7.5
Shrnutí . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
11
xi
8
9
Zabezpe£ení
12
8.1
MAC autentizace
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
12
8.2
Wired Equivalent Privacy (WEP) . . . . . . . . . . . . . . . . . . . . . .
12
8.3
WiFi Protected Access (WPA2) . . . . . . . . . . . . . . . . . . . . . . .
12
8.3.1
WPA2 se sdíleným klí£em (WPA2-PSK)
. . . . . . . . . . . . . .
13
8.3.2
WPA2 s roz²í°ením EAP (WPA2-EAP) . . . . . . . . . . . . . . .
13
HotSpot
13
III Platforma Mikrotik
15
10 Mikrotik RouterBOARD
15
11 Mikrotik RouterOS
16
11.1 Správa RouterOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
11.1.1 Gra cké uºivatelské rozhraní Winbox . . . . . . . . . . . . . . . .
17
11.1.2 Textové uºivatelské rozhraní . . . . . . . . . . . . . . . . . . . . .
17
11.1.3 Webové rozhraní
. . . . . . . . . . . . . . . . . . . . . . . . . . .
17
11.2 Vzorová kon gurace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
11.2.1 Ve°ejné rozhraní 11.2.2 Rozhraní WiFi
. . . . . . . . . . . . . . . . . . . . . . . . . . .
18
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
11.2.4 HotSpot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
21
11.2.5 Správa uºivatelských oprávn¥ní
23
11.2.3 Sí´ová vrstva
. . . . . . . . . . . . . . . . . . .
IV Uºivatelská vytá£ená sluºba pro vzdálenou autentizaci (RADIUS) 25 12 Popis RADIUS protokolu pro autentizaci
25
13 RADIUS vs. RouterOS
26
14 Test RADIUS serveru
27
14.1 Ov¥°ení spolupráce s RouterOS
. . . . . . . . . . . . . . . . . . . . . . .
27
14.2 Zát¥ºový test serveru Clutch.Radius . . . . . . . . . . . . . . . . . . . . .
28
15 Dynamické vytvá°ení uºivatelských oprávn¥ní 15.1 Analýza User Manageru 15.2 Návrh User Manageru
28
. . . . . . . . . . . . . . . . . . . . . . . . . . .
29
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
32
15.3 Implementace User Manageru
. . . . . . . . . . . . . . . . . . . . . . . .
34
15.4 Testování User Manageru . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
V Instantní platby
37 xii
16 SMS platby
37
16.1 Popis platby pomocí SMS
. . . . . . . . . . . . . . . . . . . . . . . . . .
37
16.2 Výb¥r SMS agregátora . . . . . . . . . . . . . . . . . . . . . . . . . . . .
37
16.3 Modul pro SMS platby . . . . . . . . . . . . . . . . . . . . . . . . . . . .
38
16.3.1 Analýza modulu pro SMS platby 16.3.2 Návrh modulu pro SMS platby
. . . . . . . . . . . . . . . . . .
38
. . . . . . . . . . . . . . . . . . .
47
16.3.3 Implementace modulu pro SMS platby
. . . . . . . . . . . . . . .
47
16.3.4 Testování modulu pro SMS platby . . . . . . . . . . . . . . . . . .
48
17 Dal²í moºnosti instantních plateb 17.1 Platba kreditní kartou
48
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
17.2 Platba pomocí elektronické pen¥ºenky
. . . . . . . . . . . . . . . . . . .
17.3 Platba prost°ednictvím internetového bankovnictví
. . . . . . . . . . . .
48 49 49
VI Vyhodnocení a reálné nasazení
51
18 Testování
51
19 Pilotní provoz
51
19.1 Komunikace s SMS agregátorem . . . . . . . . . . . . . . . . . . . . . . .
52
19.2 Autentiza£ní sluºba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
52
19.3 P°ipojení stálých uºivatel· . . . . . . . . . . . . . . . . . . . . . . . . . .
52
19.4 P°ipojení stálých instantních uºivatel·
52
. . . . . . . . . . . . . . . . . . .
19.5 P°ipojení náhodných instantních uºivatel· 19.6 Monitorování sít¥ a sluºeb
. . . . . . . . . . . . . . . . .
52
. . . . . . . . . . . . . . . . . . . . . . . . . .
53
20 Pokrytí poºadavk· 20.1 Nutné funk£ní poºadavky
53 . . . . . . . . . . . . . . . . . . . . . . . . . .
20.2 Volitelné funk£ní poºadavky
53
. . . . . . . . . . . . . . . . . . . . . . . . .
53
20.3 Nefunk£ní poºadavky . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
54
21 Záv¥r
55
22
Rejst°ík
57
23
Seznam literatury
59
A Dostupná °e²ení HotSpot·
61
A.1
Provisio MyPublicHotSpot . . . . . . . . . . . . . . . . . . . . . . . . . .
61
A.2
Antamedia HotSpot Software
. . . . . . . . . . . . . . . . . . . . . . . .
61
A.3
NoCatAuth a NoCatSplash
. . . . . . . . . . . . . . . . . . . . . . . . .
62
A.4
CoovaChilli
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
A.5
WiFiDog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
62
A.6
Public IP ZoneCD Gateway
63
. . . . . . . . . . . . . . . . . . . . . . . . .
xiii
B Srovnání vybraných SMS agregátor· B.1
B.2
Nabídky oslovených agregátor·
65
. . . . . . . . . . . . . . . . . . . . . . .
65
B.1.1
Pay SMS lite - sms.sluzba.cz . . . . . . . . . . . . . . . . . . . . .
65
B.1.2
sms.cz Premium SMS - goNet
65
B.1.3
mobilniplatby.cz . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
B.1.4
Erika, a.s.
65
B.1.5
Materna mobilní platby
B.1.6
PR SMS - Media Support s.r.o.
. . . . . . . . . . . . . . . . . . .
66
B.1.7
premiumsms.cz
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
66
B.1.8
Tanger PRSMS . . . . . . . . . . . . . . . . . . . . . . . . . . . .
66
B.1.9
Dal²í agregáto°i . . . . . . . . . . . . . . . . . . . . . . . . . . . .
66
Výb¥r agregátora . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
66
. . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
65
C Postup nasazení serveru Clutch.Radius
69
C.1
Prerekvizity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
C.2
P°íprava databáze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
C.3
Instalace sluºby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
69
D Postup nasazení sluºby HotSpot User Manager
71
D.1
Prerekvizity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
D.2
P°íprava databáze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
D.3
Instalace sluºby . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
71
E Obsah p°iloºeného CD
73
xiv
Seznam obrázk· 1
Topologie sít¥ AG-Net
2
WiFi - Ad-Hoc
. . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
3
WiFi - Basic Service Set (BSS)
4
WiFi - Extended Service Set (ESS)
. . . . . . . . . . . . . . . . . . . . .
8
5
WiFi - Wireless Distribution System (WDS) . . . . . . . . . . . . . . . .
9
6
WiFi - Kombinovaná topologie . . . . . . . . . . . . . . . . . . . . . . . .
9
7
Ilustrace procesu autentizace protokolem RADIUS . . . . . . . . . . . . .
26
8
Test RADIUS serveru - kon gurace prost°edí . . . . . . . . . . . . . . . .
28
9
HotSpot User Manager - model komponent . . . . . . . . . . . . . . . . .
29
10
HotSpot User Manager - model nasazení
. . . . . . . . . . . . . . . . . .
30
11
HotSpot User Manager - business model
. . . . . . . . . . . . . . . . . .
31
12
HotSpot User Manager - model dat . . . . . . . . . . . . . . . . . . . . .
32
13
HotSpot User Manager - t°ídy jádra . . . . . . . . . . . . . . . . . . . . .
33
14
HotSpot User Manager - aspekty
. . . . . . . . . . . . . . . . . . . . . .
33
15
HotSpot User Manager - t°ídy jádra . . . . . . . . . . . . . . . . . . . . .
34
16
SMS Gateway - business model
41
17
SMS Gateway - model dat . . . . . . . . . . . . . . . . . . . . . . . . . .
43
18
SMS Gateway - stavový diagram platby . . . . . . . . . . . . . . . . . . .
45
19
SMS Gateway - business t°íd . . . . . . . . . . . . . . . . . . . . . . . . .
47
20
Srovnání nabízených provizí SMS agregátor· . . . . . . . . . . . . . . . .
67
. . . . . . . . . . . . . . . . . . . . . . .
. . . . . . . . . . . . . . . . . . . . . . .
xv
8
xvi
Seznam tabulek 1
RouterOS - licence
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
16
2
Správa RouterOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
17
3
SMS Gateway - tabulka pokrytí atribut·
sms_sessions stavy platby . .
46
4
Tabulka pokrytí nutných funk£ních poºadavk· . . . . . . . . . . . . . . .
53
5
Tabulka pokrytí nefunk£ních poºadavk·
. . . . . . . . . . . . . . . . . .
54
6
Cenové hladiny SMS agregátor· v K£ . . . . . . . . . . . . . . . . . . . .
66
xvii
xviii
1
1
Popis problému, speci kace 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.
Obrázek 1: Topologie sít¥ AG-Net
2
1 POPIS PROBLÉMU, SPECIFIKACE CÍLE
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.
4 NEFUNKNÍ POADAVKY
4
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. Pro t 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 speci kují 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í.
4.1 Kon gurace RouterOS
5
4.1 Kon gurace 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 kon guraci, 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.
6
5 UIVATELSKÉ ROLE
7
ást II
Technologie 802.11x - WiFi Standard 802.11, 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í ex-
istují 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 kon gurací 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
6 TOPOLOGIE
8
6.2 Infrastruktura (Infrastructure) Základním stavebním kamenem této topologie je takzvaný Basic Service Set (BSS, obr. 3) identi kovaný 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)
6.3 Wireless Distribution System (WDS)
9
6.3 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¥k-
teré, více roz²í°ené, fungují na frekvencích, které je moºné voln¥ vyuºívat. Jiné, draº²í, ale
7 FYZICKÁ VRSTVA
10
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 802.11 z roku 1997. 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 802.11x 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 de novány. V takových p°ípadech záleºí na jednotlivých výrobcích, jak danou funkci implementují.
7.1 802.11b 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.
7.2 802.11g Standard 802.11g je roz²í°ením standardu 802.11b 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 802.11b. 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 802.11a (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 802.11b je ale zatíºen nedostatky, které sniºují jeho propustnost oproti 802.11a p°ibliºn¥ o 21%. Dal²í nevýhodou zp¥tné kompatibility je, ºe kdyº se v jedné 802.11g síti objeví by´ jen jedno za°ízení, které podporuje pouze 802.11b, p°epne se celá sí´ na jednu z rychlostí tohoto p·vodního standardu. Standard 802.11g byl p°edstaven v roce 2003. Za°ízení podporující tento standard se ozna£ují jako 802.11b/g pro zd·razn¥ní moºnosti vyuºití p·vodního standardu 802.11b.
7.3 802.11a, 802.11h Standard 802.11a, 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 802.11 opou²tí. Pouºití nové frekvence
7.4 802.11n
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 802.11g. Prakticky to ale platí pouze p°i pouºití niº²ích p°enosových rychlostí. Standard 802.11a byl p°edstaven zárove¬ se standardem 802.11b v roce 1999. 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 802.11h. 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.
7.4 802.11n Tento dodatek je nejmlad²ím z rodiny 802.11x. 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 802.11n 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· 802.11b, 802.11g, 802.11a a nov¥ 802.11n. 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 802.11b, 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 802.11b. S výhodou m·ºeme ale vyuºít i technologie 802.11g, která je schopná s 802.11b spolupracovat. Pro obecné pokrytí klientských za°ízení jiº ale nelze vyuºít 802.11a ani 802.11n, 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
8 ZABEZPEENÍ
12
nelze a musíme se spokojit se standardem 802.11g, 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í metal-
ický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 1 adresu p°id¥le-
Kaºdé za°ízení ve WiFi síti je identi kováno globáln¥ unikátní MAC
nou 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 802.11 v roce 1999. 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 802.11i, který de nuje 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 802.11i. Útok
1 Media
Access Control
13
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:
8.3.1
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 kon guruje 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 802.11i. Zp·sob p°i°azení sdíleného klí£e, resp. klí£· v tomto standardu není popsán.
8.3.2
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
2 serverem.
zprost°edkováno RADIUS
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í.
2 Viz
£ást IV na stran¥ 25
14
9 HOTSPOT
15
á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¥ kon gurovatelný s moºností sdruºování do sí´ového mostu £i p°epína£e
3
voliteln¥ jeden Ethernet port pro PoE 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.
11 MIKROTIK ROUTEROS
16
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.
Licence
Tabulka 1: RouterOS - licence
0 (Volná)
1 (Demo)
3 (WISP CPE)
4 (WISP)
5 (WISP)
6 (Controller)
Podpora p°i první kon guraci
-
-
-
15 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
1
1
200
500
neomezen¥
PPTP tunely
limit 24h
1
1
200
neomezen¥
neomezen¥
L2TP tunely
limit 24h
1
1
200
neomezen¥
neomezen¥
OVPN tunely
limit 24h
1
1
200
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
1
1
200
500
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
1
10
20
50
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í gra cká konzole Winbox nebo libovolný webový prohlíºe£. V tabulce 2 jsou uvedeny moºné kombinace p°ipojení a uºivatelského rozhraní.
11.2 Vzorová kon gurace
17
Tabulka 2: Správa RouterOS
11.1.1
MAC
Sériová linka
TCP/IP
HTTP
Text
MAC-Telnet
Telnet
Telnet/SSH
-
GUI
Winbox
-
Winbox
-
WWW
-
-
-
WWW prohlíºe£
Gra cké uºivatelské rozhraní Winbox
Winbox je proprietární gra cká konzole pro správu RouterOS. Je to nejp°ehledn¥j²í
4 rozhraní, pomocí kterého lze
uºivatelské rozhraní, které RouterOS nabízí. Jde o MDI
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.
11.1.2
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.
11.1.3
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í.
11.2 Vzorová kon gurace 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 kon guraci, 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. Kon gurace kaºdého p°ístupového bodu bude vycházet z této vzorové kon gurace. 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 kon gurace zde jsou uvedeny také p°íkazy textového rozhraní. Jak bylo °e£eno vý²e, struktura textového a gra cké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 kon guraci a stav RouterOS.
11 MIKROTIK ROUTEROS
18
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·.
11.2.1
Ve°ejné rozhraní
Protoºe je pro ve°ejné rozhraní vyuºit Ethernet, není t°eba ºádná explicitní kon gurace fyzického rozhraní. Název rozhraní p°edpokládáme ether1. Za£neme tedy nastavením IP adresy. Pokud je adresa statická, nap°. 147.32.123.123 s maskou sít¥ 255.255.255.0 a branou 147.32.123.1, nastavíme tuto adresu a výchozí bránu p°íkazy
ip address add interface=ether1 address=147.32.123.123/24 ip route add dst-address=0.0.0.0/0 gateway=147.32.123.1 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ý.
11.2.2
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
5
bodem odmítáni . Mikrotik navíc vyuºil zmín¥né mezery ve standardu 802.11i 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.
11.2 Vzorová kon gurace
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 kon gurace je uveden dále. Pot°ebujeme tedy dva bezpe£nostní pro ly. 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-d120-4740-9fb0-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 pro lu zabezpe£ení Nyní m·ºeme nakon gurovat 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
11 MIKROTIK ROUTEROS
20
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 802.11g, 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-pro le ur£uje pro l zabezpe£ení, který jsme si p°ipravili v p°edchozích odstavcích. ssid ur£uje identi ká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°. 2412 MHz. Tuto frekvenci pak p°i°adíme na²emu rozhraní.
interface wireless set wlan1 frequency=2412 Nyní zbývá nakon gurovat 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í pro l a název sít¥. Po dokon£ení nastavení rozhraní m·ºeme bezdrátovou sí´ spustit:
interface wireless enable 0
11.2 Vzorová kon gurace 11.2.3
21
Sí´ová vrstva
Nyní máme p°ipravenou linkovou vrstvu a m·ºeme p°ejít ke kon guraci 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=10.0.0.1/24 interface=wlan1 Kon guraci sí´ové vrstvy ve°ejné sít¥ pro náhodné uºivatele provedeme v rámci následujícího kroku.
11.2.4
HotSpot
Abychom na síti odd¥lili placený a neplacený prostor, pouºijeme funkci HotSpot. Ta nám podle na²í kon gurace 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 nakon gurujeme 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:
11 MIKROTIK ROUTEROS
22
hotspot interface: test local address of network: 10.1.0.1/24 masquerade network: yes address pool of network: 10.1.0.2-10.1.0.254 Dále nepovinn¥ SSL certi ká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: 0.0.0.0 Povinn¥ uvedeme adresy DNS server·, které získáme od poskytovatele internetu
6 a
nakonec nepovinn¥ DNS název hotspot serveru:
dns servers: 77.77.77.1,77.77.77.2 dns name: Nyní je HotSpot p°ipraven ve své výchozí kon guraci spolu s ve²kerým pot°ebným nastavením jako je IP adresa rozhraní, DHCP server a HTTP Proxy. Ve výchozí kon guraci je povolena autentizace pomocí HTTP CHAP a Cookie, coº je pouºitelný stav. P°i získání d·v¥ryhodného certi ká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 modi kací 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.
11.2 Vzorová kon gurace
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.
11.2.5
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−da65−4671−947d−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-da65-4671-947d-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áºí
7
pro jaké sluºby je jeho autentiza£ní sluºba dostupná. Na výb¥r je PPP , p°ístup k RouterOS (login), HotSpot, p°ístup k bezdrátové síti (wireless) a DHCP server (dhcp). RADIUS server operující na adrese 147.32.123.234 na standardním portu 1812 s heslem 9009c00e−7866−4a35−ac35−4f916d7d103d p°idáme na seznam p°íkazem
radius add address=147.32.123.234 \ secret=9009c00e-7866-4a35-ac35-4f916d7d103d service=hotspot \ src-address=147.32.123.123 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
8 klienta. Pro jeho pouºití sta£í znát adresu NTP serveru a £asové pásmo, ve kterém
NTP
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·. Time Protocol - protokol pro synchronizaci £asu po IP síti.
8 Network
11 MIKROTIK ROUTEROS
24
server· - druhou pro p°ípad výpadku prvního serveru. P°edpokládejme, ºe NTP servery operují v reºimu unicast na adresách 147.32.123.245 a 147.32.123.246 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=147.32.123.245 \ secondary-ntp=147.32.123.246 mode=unicast enabled=yes
25
á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
13 RADIUS VS. ROUTEROS
26
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ý pro l, 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 modi kaci.
27
WCF RADIUS Service je propracovaný funk£ní a podporovaný projekt zaloºený na 9 frameworku WCF . Jde o pom¥rn¥ komplexní záleºitost, coº zp·sobuje v¥t²í £asové nároky na seznámení s projektem pro jeho dal²í modi kaci.
Po bliº²ím seznámení se s ob¥ma projekty a po provedení n¥kolika test· jsem se rozhodl pro modi kaci projektu Clutch.Radius. Nejprve bylo t°eba odladit drobné chyby a doplnit CHAP autentizaci (viz sekce 11.2.4 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í kon gura£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-speci c (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-speci c (26) s kódem výrobce 14122 (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 5.26 - Vendor-Speci c 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¥ 69.
14
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. Kon gurace 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é kon gurace 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.
15 DYNAMICKÉ VYTVÁENÍ UIVATELSKÝCH OPRÁVN
NÍ
28
Obrázek 8: Test RADIUS serveru - kon gurace 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 RADIUS 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
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.
15.1 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
30
15 DYNAMICKÉ VYTVÁENÍ UIVATELSKÝ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.
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í identi kátor oprávn¥ní shodný s identi ká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í identi kátor odebraného uºivatelského oprávn¥ní shodný s identi kátorem v databázi serveru Clutch.Radius
removed ... datum a £as odebrání uºivatelského oprávn¥ní
15 DYNAMICKÉ VYTVÁENÍ UIVATELSKÝCH OPRÁVN
NÍ
32
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 t°ídami
UserManagerData spolu s entitními
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í resp.
IManagementModule. Toto rozhraní obsahuje metody OnStart,
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 obrázku 13.
IManagementModule jsou znázorn¥ny na
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·. 10 O²et°ení výjimek se prolíná nap°í£ celým projektem. Proto je °e²eno pomocí AOP .
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
Pro-
jectInstaller 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í imple-
mentace 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.
34
15 DYNAMICKÉ VYTVÁENÍ UIVATELSKÝ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
HandleExceptionAt-
tribute, 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 kon gurace záznam událostí do souboru £i systémového logu, odesílání e-mailem, 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.
15.4 Testování User Manageru
35
15.4 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 16.3.4 na stran¥ 48.
36
15 DYNAMICKÉ VYTVÁENÍ UIVATELSKÝCH OPRÁVN
NÍ
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.
16.1 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.
16.2 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.
16 SMS PLATBY
38
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í.
16.3 Modul pro SMS platby 16.3.1
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ý identi ká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 90206.
srcNumber ... telefonní £íslo zákazníka. Nap°. 420602660307. 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ý identi kátor poºadavku shodný s hodnotou atributu id procedury
Receive().
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 upravit. Pokud je hodnota atributu
Receive()
Status false, musí být cena 0.
Text ... text zprávy, kterou uºivatel obdrºí. Druhou procedurou na²eho rozhraní je metoda
Con rm(). Tato metoda je volána pro
potvrzení £i zamítnutí platby a má následující atributy:
id ... jednozna£ný celo£íselný identi kátor poºadavku shodný s hodnotou atributu id procedury
Receive().
con rmed ... 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 Con rm() 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 identi kuje 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 90206 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 notou atributu
Con rm() s negativní hod-
status. Ná² modul pro SMS platby p°i tomto volání zru²í p°id¥lené
oprávn¥ní podle identi kátoru poºadavku. Pokud platba prob¥hne v po°ádku, ode²le
16 SMS PLATBY
40
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 pozitivní hodnotou atributu
Con rm() s
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
Con rm() 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·.
16.3 Modul pro SMS platby
Obrázek 16: SMS Gateway - business model
41
16 SMS PLATBY
42
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ásle-
dují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ý identi ká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 tového typu procedury
Status návra-
Receive().
type ... kód typu zprávy pro odpov¥¤ shodný s hodnotou atributu type návratového typu procedury
Receive().
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().
con rmer_address ... IP adresa klienta volajícího proceduru Con rm(). con rmer_port ... TCP port klienta volajícího proceduru Con rm(). con rmed ... datum a £as potvrzení £i zamítnutí platby shodný s hodnotou atributu con rmed procedury Con rm(). con rm_status ... boolská hodnota zna£ící úsp¥²nost platby shodná s hodnotou atributu status procedury Con rm(). user_id ... unikátní identi ká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.
16 SMS PLATBY
44
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 do stavu
keyword, není AG, p°ejde se
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 návratem z procedury
Odeslána negativní odpov¥¤, do kterého se p°echází
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 p°ejde do stavu
Receive(). Platba
Odeslána pozitivní odpov¥¤.
Z tohoto stavu ihned p°echází do stavu
Nepotvrzeno a £eká se na volání procedury
Con rm(). 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.
16.3 Modul pro SMS platby
Obrázek 18: SMS Gateway - stavový diagram platby
45
x x
x x x x x x x x
Neznámý kód sluºby
Odeslána negativní odpov¥¤
P°id¥leno oprávn¥ní
Odeslána pozitivní odpov¥¤
Nepotvrzeno
Potvrzeno
Zamítnuto
x
keyword x
x
x
x
x
x
x
x
x
x
id x
x
x
x
x
x
x
x
x
x
operator x
x
x
x
x
x
x
x
x
x
received x
x
x
x
x
x
x
x
x
x
dst_number x
x
x
x
x
x
x
x
x
x
src_number x
x
x
x
x
x
x
x
x
x
in_text x
x
x
x
x
x
x
x
x
x
received_status x
x
x
x
x
type x
x
x
x
x
price x
x
x
x
x
out_text x
x
x
x
x
con rmer_address x
x
con rmer_port x
x
con rmed x
x
con rm_status x
x
user_id x
x
x
x
x
username x
x
x
x
x
password x
x
x
x
x
added x
x
x
x
x
removed x
x
x
x
x
Tabulka 3: SMS Gateway - tabulka pokrytí atribut·
x
x
x
x
x
x
x
Chybné klí£ové slovo
Chybný po£et atribut·
receivers_address x
receivers_port
x
P°ijato
stav / atribut
46
16 SMS PLATBY
sms_sessions stavy platby
16.3 Modul pro SMS platby 16.3.2
47
Návrh modulu pro SMS platby
Procedury webové sluºby jsou deklarovány v rozhraní modul pro SMS platby je implementován ve t°íd¥ tuje jak metody rozhraní tak metody rozhraní
ISmsContract. Samotný
SmsManager. Tato t°ída implemen-
ISmsContract reprezentující procedury na²í webové sluºby,
IManagementModule pro moºnost zapojení tohoto modulu jako
komponentu sluºby HotSpot User Manager. Práci s databází zabezpe£uje t°ída spolu s entitními t°ídami
SmsData
Session a Service. T°ída ReceiveResponseType reprezenReceive().
tuje návratový typ procedury
Obrázek 19: SMS Gateway - business t°íd
16.3.3
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
11 ). Pro na²e o£ekávané mnoºství zákazník· toto dosta£uje
aplika£ního serveru (nap°. IIS
a p°ípadný budoucí p°echod na aplika£ní server je pouze otázkou kon gurace. Je²t¥ jedna
11 Microsoft
Internet Information Server - Aplika£ní a webový server pro Windows.
17 DALÍ MONOSTI INSTANTNÍCH PLATEB
48
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 kon gurace. To m·ºe usnadnit p°echod k jinému SMS agregátorovi, p°ípadn¥ p°ipojení více SMS agregátor·.
16.3.4
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 Test poºadavku s nesprávným kódem sluºby - metoda Test poºadavku s chyb¥jícím kódem sluºby - metoda Test n¥kolika soub¥ºných poºadavk· - metoda
WrongKeyword().
WrongService().
NoService().
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í.
17.1 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í.
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.
17.2 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.
17.3 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.
50
17 DALÍ MONOSTI INSTANTNÍCH PLATEB
51
á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 16.3.4 na stran¥ 48. Následn¥ bylo provedeno nasazení systému do produk£ního prost°edí, viz dal²í £ást, kde byly p°ed o ciá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. www.internet-wi .eu. Odeslání SMS ve tvaru AG 0. Odpov¥¤ byla Sluzba s kodem 0 nebyla nalezena. Opakujte prosim zadani. AG-Net. www.internet-wi .eu. Odeslání SMS ve tvaru AG 1. Odpov¥¤ byla Platba 20,- Kc prijata. Pro pripojeni pouzijte jmeno 285087 a heslo 201544. Dekujeme. AG-Net. www.internetwi .eu.
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 285087 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.
19 PILOTNÍ PROVOZ
52
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¥ 37.
19.2 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·.
19.3 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.
19.4 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 kon guraci HotSpot· dle popisu v téºe £ásti textu.
19.5 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=10.1.0.3
19.6 Monitorování sít¥ a sluºeb
53
kde 10.1.0.3 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.
19.6 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¥ 37
2
11.2.4 na stran¥ 21, IV na stran¥ 25
3
IV na stran¥ 25
4
16 na stran¥ 37
5
11.2.2 na stran¥ 18, 11.2.5 na stran¥ 23
6
11.2.4 na stran¥ 21
7
11.2.4 na stran¥ 21
20.2 Volitelné funk£ní poºadavky Z t¥chto poºadavk· se poda°ilo uspokojit pouze poºadavek £. 3.5. Ten je °e²en v £ásti 11.2.4 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.
20 POKRYTÍ POADAVK
54
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 17 18
ásti textu °e²ící poºadavek 11 na stran¥ 16 Prolíná se nap°í£ textem
19
19.6 na p°edchozí stran¥
20
15.2 na stran¥ 32
21
19.6 na p°edchozí stran¥
22
15.2 na stran¥ 32
55
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 speci kovaných poºadavk·. Dále byla navrºena vhodná kon gurace 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¥ speci ková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 speci kuje 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.
56
21 ZÁV
R
Rejst°ík log4net, 34
Ú£tování, 25 802.11a, 10
MAC, Media Access Control, 12
802.11b, 10
MAN, Metropolitan Area Network, 13
802.11b/g, 10
Mikrotik, 15
802.11g, 10
MIMO, Multiple-Input Multiple-Output, 11
802.11h, 11
MO, Mobile Originated, 37
802.11n, 11
Modul pro SMS platby, 38
802.11x, 7, 10
MT, Mobile Terminated, 37 AAA, Authentication, Authorization and Nefunk£ní poºadavky, 4, 54
Accounting, 25
NTP, Network Time Protocol, 23
Ad-Hoc, 7 ADO.NET, 34
Open System, 12
AG-Net, 1 AOP, Aspect Oriented Programming, 33, 34
PAP, Password Authentication Protocol, 21 Peer-To-Peer, 7
AP, Access Point, 8
PoE, Power over Ethernet, 15
Autentizace, 25
PostSharp, 34
Autorizace, 25
PSK, Preshared Key, 13
BSS, Basic Service Set, 8
RADIUS, 23, 25
CHAP, Challange Authentication Protocol, 21
RouterBOARD, 15 RouterOS, 15, 16, 26 RPC, Remote Procedure Call, 38
Client, 8 Clutch.Radius, 26
SMS agregátor, 37 SMS platby, 37
DFS, Dynamic Frequency Selection, 11
SMSTestClient, 48
Dude, 53
SQL Server 2008, 34
EAP, Extensible Authentication Protocol,
SSH, 16, 17 SSID, Service Set ID, 8
13 ESS, Extended Service Set, 8
Station, 8
Funk£ní poºadavky, 3, 4, 53
Telnet, 16, 17 TPC, Transmit Power Control, 11
HotSpot, 13, 21 User Manager, 28
HotSpot User Manager, 28, 48 IDE, Integrated Development Environment, 48 Infrastruktura, Infrastructure, 8 Kreditní karta, 48
VirtualBox, 27 Walled Garden, 22 WAN, Wide Area Network, 13 WDS, Wireless Distribution System, 9 Webová sluºba, Web Service, 38
LAN, Local Area Network, 13
WEP, Wired Equivalent Privacy, 12
LINQ to SQL, 34
WiFi, 7, 10
57
58
Winbox, 16, 17 WLAN, Wireless LAN, 10 WPA2, WiFi Protected Access, 12
REJSTÍK
23 SEZNAM LITERATURY 23 [1]
59
Seznam literatury Wikipedia - IEEE 802.11 http://en.wikipedia.org/wiki/IEEE_802.11
[2]
Introduction to Wi-Fi (802.11 or WiFi) http://en.kioskea.net/contents/wi /wi intro.php3
[3]
MikroTik Wiki http://wiki.mikrotik.com/
[4]
MikroTik RouterOS v2.9 Reference Manual http://www.mikrotik.com/testdocs/ros/2.9/
[5]
MikroTik http://www.mikrotik.com/
[6]
Kolektiv autor·,
RFC 2865 - Remote Authentication Dial In User Service (RA-
DIUS), The Internet Society, 2000 [7]
Sun VirtualBox http://www.virtualbox.org/
[8]
IEA Radlogin v4 http://www.iea-software.com/products/radlogin4.cfm
[9]
.NET Framework Developer Center http://msdn.microsoft.com/en-us/netframework/default.aspx
[10]
SharpCreafters - The Creators of PostSharp http://www.sharpcrafters.com/
[11]
Apache log4net http://logging.apache.org/log4net/
[12]
SQL Server 2008 Overview http://www.microsoft.com/sqlserver/2008/
[13]
Erika, a.s. - Placení za sluºby £i informace http://www.erika-as.cz/rubriky/produkty-a-sluzby/placeni-za-sluzby-ci-informace/
[14]
eská spo°itelna - E-commerce 3D-Secure http://www.csas.cz/banka/content/inet/internet/cs/sc_1585.xml
[15]
Komer£ní banka - Akceptace platebních karet http://www.kb.cz/cs/seg/seg3/products/acceptance_payment_cards.shtml
[16]
PayPal http://www.paypal.com/
[17]
PayPay http://www.paypay.com/
60
23 SEZNAM LITERATURY
61
A
Dostupná °e²ení HotSpot· Jak jiº bylo popsáno, v²echna nalezená °e²ení sdílejí jednu vlastnost, kterou je kon-
centrace 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 13 . Nabízí uºivatelsky p°ív¥tivé
MyPublicHotSpot je komer£ní projekt rmy Provisio
°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é 14 Webové
stránky rmy Provisio se nacházejí na adrese http://www.provisio.com/. stránky rmy Provisio se nacházejí na adrese http://www.antamedia.com/.
A DOSTUPNÁ EENÍ HOTSPOT
62
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 15 je komunitní sí´ nacházející se v Sonoma County, CA v USA. Sí´ b¥ºí na
NoCat
vlastním softwaru NoCatAuth napsaném v jazyce Perl a jeho portu do jazyka C NoCatSplash 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, CGI17 modul nebo jako modul redak£ního systému Drupal18 .
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 http://nocat.net/. Object Notation - jednoduchý textový formát pro vým¥nu dat vycházející z prvk· jazyka
16 JavaScript
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 http://drupal.org/. 19 Webová prezentace projektu WiFiDog je dostupná na adrese http://dev.wi dog.org/.
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é e-mailové adresy. Monitorování p°ístupových bod·. Automatická kon gurace 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. Kon gura£ní fronta, ve které se p°i zm¥n¥ kon gurace nashromáºdí v²echna kon gura£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í´ rekon guruje a restartuje. Na konec je správci
odeslán e-mail s informací o provedení kon gurace. 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 http://www.publicip.net/. prezentace projektu Dansguardian se nacházejí na adrese http://dansguardian.org/. 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 http://www.smarty.net/. 21 Webová
A DOSTUPNÁ EENÍ HOTSPOT
64
Upravitelné e-mailové zprávy odesílané uºivateli p°i uvítání, ztrát¥ hesla a ov¥°ení e-mailové adresy.
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 9022069, resp. 9022099. á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 90009xx, 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. 24 . Agregátor nabízí
Tento agregátor nepoºaduje ºádné z°izovací ani pau²ální poplatky
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í.
B SROVNÁNÍ VYBRANÝCH SMS AGREGÁTOR
66
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 15000 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 mobilniplatby.cz Erika, a.s. Media Support s.r.o. Tanger, s.r.o.
69, 99 10, 20, 30, 50, 79, 99 20, 30, 40, 50, 60, 70, 80, 90, 99 10, 15, 20, 99 6, 15, 30, 50, 79, 99
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.
68
B SROVNÁNÍ VYBRANÝCH SMS AGREGÁTOR
69
C
Postup nasazení serveru Clutch.Radius
C.1 Prerekvizity Sluºba Clutch.Radius pro sv·j b¥h vyºaduje tyto komponenty:
Microsoft Windows XP nebo vy²²í
25
Microsoft .NET Framework 3.5 SP1 nebo vy²²í
26
Microsoft SQL Server 2008 Express nebo vy²²í
C.2 P°íprava databáze Tento postup vyºaduje základní znalosti správy databázového serveru Microsoft SQL Server. Postup lze modi kovat podle bezpe£nostních zásad aplikovaných na databázovém serveru. 1. Na SQL Serveru vytvo°íme databázi
ClutchRadius.
2. Vytvo°íme databázové schéma pomocí SQL dávky v souboru ClutchRadius.sql. 3. Vytvo°íme uºivatelský ú£et SQL serveru s právem na spu²t¥ní v²ech vloºených procedur v této databázi.
C.3 Instalace sluºby Tento postup vyºaduje základní znalosti správy systému Windows. Postup lze modi kovat podle bezpe£nostních zásad aplikovaných na produk£ním serveru. Sluºbu a databázi není nutné provozovat na stejném stroji. 1. Sloºku Clutch Radius Server zkopírujeme na úloºi²t¥ dostupné produk£nímu serveru. Nap°. do C:\Program Files. 2. Z této sloºky spustíme instalaci sluºby pomocí p°íkazu InstallUtil.exe ClutchRadiusServer.exe. 3. Do registr· systému p°idáme do HKEY_LOCAL_MACHINE SYSTEM\CurrentControlSet\Services\ClutchRADIUSAuthServer hodnotu
De-
pendOnService typu MULTI_SZ. Obsahem této hodnoty bude název sluºby SQL Serveru. Standardn¥ je to
MSSQL$SQLEXPRESS pro Express edici a
MSSQL pro ostatní edice. Tímto krokem zajistíme automatické spou²t¥ní na²í sluºby aº po spu²t¥ní SQL Serveru. 4. Upravíme kon gura£ní soubor sluºby ClutchRadiusServer.exe.con g. Význam jednotlivých poloºek je uveden v komentá°ích p°ímo v souboru.
25 Lze
získat pomocí sluºby Windows Update £i na webu spole£nosti http://www.microsoft.com/. 26 Lze získat na webu spole£nosti Microsoft - http://www.microsoft.com/.
Microsoft
-
70
C POSTUP NASAZENÍ SERVERU
CLUTCH.RADIUS
5. Spustíme sluºbu Clutch RADIUS Authorization Service. Po restartu systému se sluºba spou²tí automaticky.
71
D
Postup nasazení sluºby HotSpot User Manager
D.1 Prerekvizity Sluºba HotSpot User Manager pro sv·j b¥h vyºaduje tyto komponenty:
Microsoft Windows XP nebo vy²²í
27
Microsoft .NET Framework 3.5 SP1 nebo vy²²í
28
Microsoft SQL Server 2008 Express nebo vy²²í Databázi sluºby Clutch.Radius
29
Vzhledem k pouºití b¥ºných knihoven a platformy .NET je teoreticky moºné sluºbu provozovat i na jiné platform¥ anebo jiném databázovém stroji. Takové pouºití ale nebylo testováno.
D.2 P°íprava databáze Tento postup vyºaduje základní znalosti správy databázového serveru Microsoft SQL Server. Postup lze modi kovat podle bezpe£nostních zásad aplikovaných na databázovém serveru. 1. Na SQL Serveru vytvo°íme databázi
UserManager.
2. Vytvo°íme databázové schéma pomocí SQL dávky v souboru UserManager.sql. Pro moduly sluºby vytvo°íme schémata pomocí jejich SQL dávkových soubor·. 3. Vytvo°íme uºivatelský ú£et SQL serveru s právem £tení a zápisu do celé databáze. 4. Dále tomuto ú£tu p°i°adíme práva ke spu²t¥ní vloºených procedur
sp_insert_user,
sp_delete_user a sp_update_user_attribute databáze ClutchRadius.
D.3 Instalace sluºby Tento postup vyºaduje základní znalosti správy systému Windows. Postup lze modi kovat podle bezpe£nostních zásad aplikovaných na produk£ním serveru. Sluºbu a databázi není nutné provozovat na stejném stroji. 1. Sloºku HotSpot User Manager zkopírujeme na úloºi²t¥ dostupné produk£nímu serveru. Nap°. do C:\Program Files. 2. Z této sloºky spustíme instalaci sluºby pomocí p°íkazu InstallUtil.exe HotSpotUserManager.exe.
27 Lze
získat pomocí sluºby Windows Update £i na webu spole£nosti Microsoft http://www.microsoft.com/. 28 Lze získat na webu spole£nosti Microsoft - http://www.microsoft.com/. 29 Viz p°íloha C. Samotná sluºba Clutch.Radius vyºadována není. Tyto sluºby jsou na sob¥ mimo databázi nezávislé.
D POSTUP NASAZENÍ SLUBY HOTSPOT USER MANAGER
72
3. Do registr· systému p°idáme do HKEY_LOCAL_MACHINE SYSTEM\CurrentControlSet\Services\HotSpotUserManager hodnotu
Depen-
dOnService typu MULTI_SZ. Obsahem této hodnoty bude název sluºby SQL Serveru. Standardn¥ je to
MSSQL$SQLEXPRESS pro Express edici a MSSQL
pro ostatní edice. Tímto krokem zajistíme automatické spou²t¥ní na²í sluºby aº po spu²t¥ní SQL Serveru. 4. Upravíme kon gura£ní soubor sluºby HotSpotUserManager.exe.con g. Význam jednotlivých poloºek je uveden v komentá°ích p°ímo v souboru. 5. Spustíme sluºbu HotSpot User Manager. Po restartu systému se sluºba spou²tí automaticky.
73
E
Obsah p°iloºeného CD
prochan2-dp.pdf Text diplomové práce v elektronické podob¥ ve formátu PDF s hypertextovými odkazy.
text Text diplomové práce ve zdrojovém formátu editoru Lyx, pouºité obrázky a diagramy pro nástroj Enterprise Architect a Microsoft Visio.
Clutch.Radius Projekt se zdrojovými soubory modi kovaného RADIUS serveru Clutch.Radius v jazyce C# pro Microsoft Visual C# 2008.
HotSpotUserManager Projekt se zdrojovými soubory serveru HotSpot User Manager s modulem pro SMS platby, testovacím nástrojem SMSTestClient a Unit testy v jazyce C# pro Microsoft Visual C# 2008.
usermanager_doc Dokumentace implementace serveru HotSpot User Manager s modulem pro SMS platby ve formátu HTML.
