ˇ e vysok´e uˇcen´ı technick´e v Praze Cesk´ Fakulta elektrotechnick´a
Diplomov´a pr´ace
Utajen´ı hovor˚ u v s´ıti IP (VoIP) Michal Vanˇek
Vedouc´ı pr´ace: ing. Josef Semr´ad
Studijn´ı program: Elektrotechnika a informatika, dob´ıhaj´ıc´ı magistersk´ y Obor: Informatika a v´ ypoˇcetn´ı technika kvˇeten 2008
iv
Podˇ ekov´ an´ı Na tomto m´ıstˇe bych r´ad podˇekoval vedouc´ımu m´e diplomov´e pr´ace ing. Josefu Semr´adovi za z´ajem, pˇripom´ınky a ˇcas, kter´e vˇenoval m´e pr´aci. Podˇekovat bych chtˇel tak´e ing. Janu Rudinsk´em za ˇreˇsen´ı technick´ ych probl´emu pˇri zprovozˇ nov´an´ı jednotliv´ ych u ´kol˚ u. D´ale bych chtˇel podˇekovat dr. Luk´aˇsi Kenclovi a vˇsem lidem z projektu ACC v RDC v Dejvic´ıch, za vˇsechny pˇripom´ınky, rady a n´apady. Nakonec bych chtˇel podˇekovat rodinˇe za podporu a porozumˇen´ı bˇehem studia. v
vi
Prohl´ aˇ sen´ı Prohlaˇsuji, ˇze jsem svou diplomovou pr´aci vypracoval samostatnˇe a pouˇzil jsem pouze podklady uveden´e v pˇriloˇzen´em seznamu. Nem´am z´avaˇzn´ y d˚ uvod proti uˇzit´ı tohoto ˇskoln´ıho d´ıla ve smyslu §60 Z´akona ˇc. 121/2000 Sb., o pr´avu autorsk´em, o pr´avech souvisej´ıc´ıch s pr´avem autorsk´ ym a o zmˇenˇe nˇekter´ ych z´akon˚ u (autorsk´ y z´akon).
V Uhersk´em Hradiˇsti 20.5. 2008
.............................................................
vii
viii
Abstract Today’s VoIp boom is similar to boom of Internet in 90s. Much cheaper phone calls, independence from building new specialized networks, ability to connect everywhere you want, these are only few advantages from classical PSTN network. There is one big disadvantage too. Security area. Security in VoIP systems needs different procedures like it was in PSTN. Many new problems appeared. In this thesis I am describing mostly open source VoIP technologies, focusing on analysis of security issues and finding the best solution for given part of the VoIP architecture. Key words: SIP, H.323, MGCP, MEGACO/H.248, VPN, IPsec, TLS, SNORT, Skype, IAX, RTP, SRTP, ZRTP, Zfone, SCTP, Asterisk
Abstrakt Boom, kter´ y v dneˇsn´ı dobˇe zaˇz´ıv´a VoIP je srovnateln´ y s dobou, kdy se zaˇcal vyuˇz´ıvat internet v devades´at´ ych letech. Mnohem levnˇejˇs´ı hovory, nez´avislost na vybudov´an´ı nov´ ych s´ıt´ı, moˇznost pˇripojen´ı se kdekoliv na svˇetˇe, to je jen zlomek v´ yhod oproti PSTN. Je zde tak´e ale podstatn´a nev´ yhoda a tou je pr´avˇe zabezpeˇcen´ı. Bezpeˇcnost VoIP vyˇzaduje jin´e postupy, neˇz bylo zvykem u PSTN. V pr´aci moˇzn´e technologie popisuji, analyzuji a snaˇz´ım se naj´ıt co nejlepˇs´ı ˇreˇsen´ı pro dan´ y provek VoIP s´ıtˇe. Kl´ıˇcov´a slova: SIP, H.323, MGCP, MEGACO/H.248, VPN, IPsec, TLS, SNORT, Skype, IAX, RTP, SRTP, ZRTP, Zfone, SCTP, Asterisk
ix
x
Obsah
1
Seznam obr´ azk˚ u
xiv
Seznam tabulek
xv
´ Uvod
1
2 Signalizaˇ cn´ı protokoly pro VoIP 2.1 H.323 . . . . . . . . . . . . . . . . . . . . . . . . 2.2 SIP - Session initation protocol . . . . . . . . . . 2.2.1 Session Description Protocol . . . . . . . . 2.3 Gateway Decomposition . . . . . . . . . . . . . . 2.3.1 MGCP - Media Gateway Control Protocol 2.3.2 MEGACO/H.248 . . . . . . . . . . . . . . 2.4 IAX - Inter Asterisk Exchange . . . . . . . . . . . 2.5 Dalˇs´ı protokoly pro VoIP . . . . . . . . . . . . . . 2.5.1 Jabber/XMPP - Jingle . . . . . . . . . . . 2.6 Skype . . . . . . . . . . . . . . . . . . . . . . . . 3 Protokoly pro 3.1 RTP . . . 3.2 RTCP . . 3.3 SCTP . .
. . . . . . . . . .
3 3 6 8 8 8 9 10 12 12 12
pˇ renos hlasu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
15 15 16 17
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
4 Bezpeˇ cnost VoIP syst´ em˚ u obecnˇ e 4.1 Moˇzn´e u ´toky na VoIP . . . . . . . . . . . . . . . . . . . . . . . . 4.1.1 Misrepresentation (Faleˇsn´e informace) . . . . . . . . . . . 4.1.2 Theft of Services (Kr´adeˇz sluˇzby) . . . . . . . . . . . . . . 4.1.3 Unwanted Contact (Nevyˇz´adan´a spojen´ı) . . . . . . . . . . 4.1.4 Eavesdropping (Odposlouch´av´an´ı) . . . . . . . . . . . . . . 4.1.5 Interception and Modification (Zachyt´av´an´ı a modifikace) . 4.1.6 Service Abuse (Zneuˇzit´ı sluˇzeb) . . . . . . . . . . . . . . . 4.1.7 Intentional Interruption of Service (Pˇreruˇsen´ı sluˇzeb) . . . 4.1.8 Specific Denial of Service (DoS) . . . . . . . . . . . . . . . 4.1.9 Loss of Power . . . . . . . . . . . . . . . . . . . . . . . . . 4.1.10 Resource Exhaustion . . . . . . . . . . . . . . . . . . . . . 4.1.11 Performance Latency . . . . . . . . . . . . . . . . . . . . . 4.1.12 Physical Intrusion (Fyzick´e napojen´ı) . . . . . . . . . . . . 4.2 SPIT - VoIP Spam . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Bezpeˇcnostn´ı z´avˇer . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Univerz´ aln´ı bezpeˇ cnostn´ı protokoly 5.1 TLS Transport Layer Security . . 5.1.1 Bezpeˇcnost . . . . . . . . . 5.2 IPsec . . . . . . . . . . . . . . . . . 5.3 VPN - Virtual private network . . . 5.3.1 OpenVPN . . . . . . . . . . xi
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . .
. . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . .
. . . . . . . . . .
. . . . . . . . . . . . . . .
. . . . .
. . . . . . . . . . . . . . .
21 21 22 22 22 22 23 23 23 23 24 24 24 24 24 25
. . . . .
27 27 28 28 29 29
5.4 5.5
5.6 5.7
VoIP VPN . . . . . . . . . . . . . . Ochrana pro hraniˇcn´ı prvky . . . . 5.5.1 VoIP firewall a SIP firewall . 5.5.2 NIPS and NIDS . . . . . . . Obecn´a doporuˇcen´ı . . . . . . . . . Srovn´an´ı moˇznost´ı a z´avˇer . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
6 Zabezpeˇ cen´ı signalizaˇ cn´ıch protokol˚ u 6.1 Zabezpeˇcen´ı signalizace SIPu . . . . . . . . . 6.1.1 Shrnut´ı bezpeˇcnostn´ıch moˇznosti SIPu 6.2 H.323 . . . . . . . . . . . . . . . . . . . . . . 6.3 XMPP/Jingle . . . . . . . . . . . . . . . . . . 6.4 Media Gatewayes . . . . . . . . . . . . . . . . 6.4.1 MGCP . . . . . . . . . . . . . . . . . . 6.4.2 Megaco/H.248 . . . . . . . . . . . . . . 6.5 IAX . . . . . . . . . . . . . . . . . . . . . . . 6.6 Skype . . . . . . . . . . . . . . . . . . . . . . 6.7 Srovn´an´ı zabezpeˇcen´ı . . . . . . . . . . . . . 7 Mechanismy pro zabezpeˇ cen´ı hovoru 7.1 SRTP a SRTCP . . . . . . . . . . . . 7.2 ZRTP . . . . . . . . . . . . . . . . . 7.3 Mikey . . . . . . . . . . . . . . . . . 7.4 Zfone . . . . . . . . . . . . . . . . . . 7.5 Srovn´an´ı protokol˚ u . . . . . . . . . . 7.6 Shrnut´ı zabezpeˇcen´ı pro pˇrenos hlasu 8 VoIP klienti a VoIP servery 8.1 VoIP klienti . . . . . . . . . . . . 8.1.1 Ekiga . . . . . . . . . . . 8.1.2 X-Lite . . . . . . . . . . . 8.1.3 SJphone . . . . . . . . . . 8.1.4 Minisip . . . . . . . . . . 8.2 Pˇrehled server˚ u pro IP telefonii . 8.2.1 SIP Express Router (SER) 8.2.2 Asterisk . . . . . . . . . . 8.2.3 H.323plus . . . . . . . . . 8.3 Z´avˇer . . . . . . . . . . . . . . . .
. . . . . . . . . .
. . . . . . . . . .
. . . . . .
. . . . . . . . . .
. . . . . .
. . . . . . . . . .
. . . . . .
. . . . . . . . . .
. . . . . .
. . . . . . . . . .
. . . . . .
. . . . . . . . . .
. . . . . .
. . . . . . . . . .
. . . . . .
. . . . . . . . . .
9 Testov´ an´ı VoIP klient˚ u a server˚ u prakticky 9.1 Nastaven´ı skriptu pro program SIPp . . . . . . 9.2 Testov´an´ı VoIP klient˚ u . . . . . . . . . . . . . . 9.3 Testov´an´ı SIP proxy a registrar server˚ u . . . . . 9.3.1 Testov´an´ı Asterisku . . . . . . . . . . . . 9.3.2 Testov´an´ı SER serveru iptel.org . . . . . 9.3.2.1 Test SIP URI v INVITE zpr´avˇe 9.3.2.2 Test SIP URI v INVITE paketu 9.4 Registration hijacking . . . . . . . . . . . . . . . xii
. . . . . .
. . . . . . . . . .
. . . . . .
. . . . . . . . . .
. . . . . .
. . . . . . . . . .
. . . . . .
. . . . . . . . . .
. . . . . . . . . . . . 2. . .
. . . . . .
. . . . . . . . . .
. . . . . .
. . . . . . . . . .
. . . . . . . .
. . . . . .
. . . . . . . . . .
. . . . . .
. . . . . . . . . .
. . . . . . . .
. . . . . .
. . . . . . . . . .
. . . . . .
. . . . . . . . . .
. . . . . . . .
. . . . . .
. . . . . . . . . .
. . . . . .
. . . . . . . . . .
. . . . . . . .
. . . . . .
. . . . . . . . . .
. . . . . .
. . . . . . . . . .
. . . . . . . .
. . . . . .
. . . . . . . . . .
. . . . . .
. . . . . . . . . .
. . . . . . . .
. . . . . .
. . . . . . . . . .
. . . . . .
. . . . . . . . . .
. . . . . . . .
. . . . . .
. . . . . . . . . .
. . . . . .
. . . . . . . . . .
. . . . . . . .
. . . . . .
. . . . . . . . . .
. . . . . .
. . . . . . . . . .
. . . . . . . .
. . . . . .
. . . . . . . . . .
. . . . . .
. . . . . . . . . .
. . . . . . . .
. . . . . .
. . . . . . . . . .
. . . . . .
. . . . . . . . . .
. . . . . . . .
. . . . . .
30 30 30 31 31 32
. . . . . . . . . .
33 33 34 34 36 37 37 37 37 38 38
. . . . . .
41 41 42 42 43 43 44
. . . . . . . . . .
45 45 45 45 45 46 48 48 48 49 49
. . . . . . . .
51 51 52 55 55 56 56 57 57
9.5 9.6 9.7 9.8
9.4.1 Pˇri vypnut´e autentizaci 9.4.2 Pˇri zapnut´e autentizaci Odposlouch´av´an´ı RTP paket˚ u Zruˇsen´ı sestaven´eho hovoru . . Moˇznosti obrany . . . . . . . Z´avˇer . . . . . . . . . . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
10 Zabezpeˇ cen´ı proti DoS pomoc´ı syst´ emu SNORT 10.1 Popis situace . . . . . . . . . . . . . . . . . . . . 10.2 Ochrana proti DoS - Snort Inline . . . . . . . . . 10.2.0.1 Konfigurace Snort Inline . . . . . 10.3 Implementace zabezpeˇcen´ı a testov´an´ı . . . . . . . 10.4 Testov´an´ı . . . . . . . . . . . . . . . . . . . . . . 10.5 Z´avˇer . . . . . . . . . . . . . . . . . . . . . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
57 59 60 61 61 62
. . . . . .
63 63 64 64 65 65 65
11 Z´ avˇ er
67
12 Literatura
69
A Seznam pouˇ zit´ ych zkratek
71
B N´ astroje pro u ´ toky B.1 Wireshark . . . . . . . . . . . . . . . . . . B.2 SIPp - v´ ykonnostn´ı tester pro SIP servery B.3 SiVus - The VoIP Vulnerability Scanner . B.4 Cain Abel . . . . . . . . . . . . . . . . . . B.5 Nmap . . . . . . . . . . . . . . . . . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
73 73 73 73 74 74
C UAC XML pro testov´ an´ı klient˚ u
75
D Sc´ en´ aˇ r pro testov´ an´ı Asterisku
77
E Registration hijacking pakety
78
F Uk´ azka pravidel pro Snort Inline
80
G Obsah pˇ riloˇ zen´ eho DVD
81
xiii
Seznam obr´ azk˚ u 2.1
Pˇr´ıklad pr˚ ubˇehu signalizace pro RAS, H.255 a H.245 mezi termin´aly T1 a T2 pˇres gatekeeper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Architektura H.323 s´ıtˇe . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 H.323 Stack - soubor protokol˚ u . . . . . . . . . . . . . . . . . . . . . . . 2.4 SIP architektura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.5 SIP zpr´ava . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.6 Architektura a pouˇzit´ı protokolu MGCP . . . . . . . . . . . . . . . . . . 2.7 Architektura a pouˇzit´ı protokolu MEGACO/H.248 . . . . . . . . . . . . 2.8 Vyuˇzit´ı protokolu IAX . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.9 Struktura r´amce Full Frame . . . . . . . . . . . . . . . . . . . . . . . . . 2.10 Struktura r´amce Mini Frame . . . . . . . . . . . . . . . . . . . . . . . . 2.11 Decentralizovan´a architektura s´ıtˇe protokolu XMPP . . . . . . . . . . . 2.12 Architektura s´ıtˇe Skype . . . . . . . . . . . . . . . . . . . . . . . . . . .
4 5 6 7 8 9 10 10 11 11 12 13
3.1 3.2 3.3
Struktura RTP paketu . . . . . . . . . . . . . . . . . . . . . . . . . . . . Struktura RTCP paketu . . . . . . . . . . . . . . . . . . . . . . . . . . . Struktura SCTP paketu . . . . . . . . . . . . . . . . . . . . . . . . . . .
15 17 18
4.1
Moˇznost obrany proti SPITu . . . . . . . . . . . . . . . . . . . . . . . . .
25
5.1
Architektura VoIP VPN s´ıtˇe . . . . . . . . . . . . . . . . . . . . . . . . .
30
6.1 6.2 6.3 6.4
H.323 H.323 H.323 H.323
. . . .
35 35 36 36
7.1 7.2
Struktura paketu SRTP . . . . . . . . . . . . . . . . . . . . . . . . . . . GUI aplikace Zfone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
41 43
9.1
Pˇr´ıklad u ´toku REGISTRATION hijacking . . . . . . . . . . . . . . . . .
60
10.1 Architektura automatizovan´eho call centra od IBM . . . . . . . . . . . .
63
G.1 Obsah pˇriloˇzen´eho DVD . . . . . . . . . . . . . . . . . . . . . . . . . . .
81
Baseline Security Profile . Signature Security Profile Voice Encryption . . . . Hybrid Security Profile .
. . . .
. . . .
xiv
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
Seznam tabulek 3.1
Srovn´an´ı trasportn´ıch protokol˚ u 4. vrstvy . . . . . . . . . . . . . . . . . .
19
5.1
Srovn´an´ı bezpeˇcnostn´ıch protokol˚ u a dalˇs´ıch bezpeˇcnostn´ıch moˇznost´ı . .
32
6.1 6.2
Moˇznosti zabezpeˇcen´ı protokolu SIP . . . . . . . . . . . . . . . . . . . . . Moˇznosti zabezpeˇcen´ı MG protokol˚ u . . . . . . . . . . . . . . . . . . . .
34 38
7.1
Protokoly pro pˇrenos hlasu a jejich moˇznosti . . . . . . . . . . . . . . . .
44
8.1 8.2
VoIP klienti a jejich moˇznosti . . . . . . . . . . . . . . . . . . . . . . . . VoIP servery a u ´stˇredny . . . . . . . . . . . . . . . . . . . . . . . . . . .
47 50
9.1 9.2 9.3 9.4
10 invites/s . . . . . . . . . . 100 invites/s . . . . . . . . . . 500 invites/s . . . . . . . . . . V´ ysledky testov´an´ı Asterisku .
53 53 53 56
. . . .
. . . .
. . . .
xv
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
xvi
´ KAPITOLA 1. UVOD
1
1
´ Uvod
Voice over Internet Protocol (zkratkou VoIP) [2] je technologie, umoˇzn ˇuj´ıc´ı pˇrenos digitalizovan´eho hlasu v tˇele paket˚ u rodiny protokol˚ u UDP/TCP/IP prostˇrednictv´ım poˇc´ıtaˇcov´e s´ıtˇe nebo jin´eho m´edia, prostupn´eho pro protokol IP. Vyuˇz´ıv´a se pro telefonov´an´ı prostˇrednictv´ım Internetu, intranetu nebo jak´ehokoliv jin´eho datov´eho spojen´ı. Technologie VoIP postupnˇe nahrazuje klasickou PSTN s´ıt’. VoIP na rozd´ıl od PSTN nepouˇz´ıv´a uzavˇrenou s´ıt’, ale veˇsker´ y provoz prob´ıh´a po Internetu. To pˇrin´aˇs´ı probl´emy s tarifikac´ı, nouzov´ ym vol´an´ım, zabezpeˇcen´ım datov´eho toku atd. Hovor ve VoIP prob´ıh´a ve 2 f´az´ıch. Nejprve je potˇreba hovor sestavit pomoc´ı signalizace. Signalizac´ı se zab´ yvaj´ı signalizaˇcn´ı protokoly, nezn´amˇejˇs´ı jsou protokoly H.323 nebo SIP. Jakmile jsou dohodnuty podm´ınky hovoru(porty, ˇsifrov´an´ı, hlasov´ y kodek. . . ), prob´ıh´a pˇrenos hlasu protokolem napˇr RTP. VoIP je st´ale jeˇstˇe velmi mlad´a technologie, pˇrestoˇze jiˇz pˇrekonala poˇc´ateˇcn´ı probl´emy, ˇ sen´ı nouzov´ zb´ yv´a jich jeˇstˇe spousta vyˇreˇsit (nouzov´a vol´an´ı, bezpeˇcnost a dalˇs´ı). Reˇ ych vol´an´ı pro protokol SIP je st´ale jeˇstˇe ve f´azi v´ yvoje. Vˇenuj´ı se mu na Kolumbijsk´e univerzitˇe - NY pod veden´ım prof. Henninga Schulzrinnea (spoluautor protokol˚ u RTP, SIP). Moje pr´ace se vˇenuje druh´emu z t´emat. Bezpeˇcnosti IP telefonie. Bezpeˇcnost IP telefonie neznamen´a jen zabezpeˇcen´ı hovoru proti odposlechu, jak m˚ uˇze napadnout kaˇzd´eho laika. U bezpeˇcnosti jde tak´e o zp˚ usob zabezpeˇcen´ı dat tak, aby pˇriˇsla ve stejn´e podobˇe tak jak odeˇsla, zda mˇel k dat˚ um pˇr´ıstup jeˇstˇe nˇekdo jin´ y a jak je modifikoval. Obecnˇe je potˇreba zabezpeˇcit d˚ uvˇernost, autentiˇcnost a integritu. Bezpeˇcnost je tak´e ot´azkou stability syst´emu, ochrana uˇzivatel˚ u pˇred zneuˇzit´ım jejich u ´ˇct˚ u... Pr´ace je pojata jako n´avrhovˇe-srovn´avac´ı. C´ılem je popsat technologie, kter´e se pouˇz´ıvaj´ı dnes v oblasti VoIP. D´ale analyzovat st´avaj´ıc´ı bezpeˇcnostn´ı moˇznosti pro jednotliv´e technologie, pokusit se odhalit jejich nedostatky a pokud to jde, navrhnout zlepˇsen´ı situace. V kapitol´ach 2 a 3 pˇredstavuji nejpouˇz´ıvanˇejˇs´ı protokoly pro signalizaci a pro pˇrenos ˇ hovoru. Ctvrt´ a kapitola se vˇenuje obecnˇe moˇzn´ ym u ´tok˚ um v oblasti VoIP. V kapitole 5 se vˇenuji obecn´ ym bezpeˇcnostn´ım standard˚ um, kter´e jsou vyuˇziteln´e nejen pro VoIP technologii a jsou d´ale uv´adˇeny jako jedna z bezpeˇcnostn´ıch moˇznost´ı. Kapitola 6 konkr´etnˇe pˇredstavuje moˇznosti zabezpeˇcen´ı signalizace. Je zde uvedeno srovn´an´ı jednotliv´ ych ˇreˇsen´ı a doporuˇcen´ı nejlepˇs´ıho ˇreˇsen´ı pro danou technologii. Kapitola 7 se zab´ yv´a d˚ uvˇernost´ı pˇri pˇrenosu hlasu. V kapitole 8 pˇredstavuji konkr´etn´ı open source technologie vyuˇz´ıvan´e v oblasti VoIP, jak na klientsk´e, tak serverov´e stranˇe. V kapitole 9 ukazuji prakticky nˇekter´e z u ´tok˚ u na SIP protokol. C´ılem je uk´azat, ˇze i nezkuˇsen´ y ’ uˇzivatel, m˚ uˇze pouˇzit´ım nˇekolik volnˇe dostupn´ ych program˚ u zahltit VoIP s´ıt a zp˚ usobit tak spoustu probl´em˚ u. Kapitola 10 je jak´ ymsi praktick´ ym u ´vodem do vyuˇzit´ı NIPS syst´em˚ u ve VoIP.
2
´ KAPITOLA 1. UVOD
ˇ ´I PROTOKOLY PRO VOIP KAPITOLA 2. SIGNALIZACN
3
2 Signalizaˇ cn´ı protokoly pro VoIP Signalizaˇcn´ı protokoly slouˇz´ı pro nav´az´an´ı komunikace mezi volaj´ıc´ımi, spr´avu a modifikaci parametr˚ u hovoru. Pˇres tyto protokoly se pˇren´aˇs´ı jak citliv´e uˇzivatelsk´e u ´daje, tak informace kter´e se t´ ykaj´ı parametr˚ u spojen´ı. Mezi nejzn´amˇejˇs´ı protokoly v dneˇsn´ı dobˇe patˇr´ı SIP a H.323. Signalizace hovoru se pro oba protokoly SIP a H.323 m´ırnˇe liˇs´ı, principi´alnˇe je vˇsak podobn´a. O tom, kter´e jsou dalˇs´ı signalizaˇcn´ı protokoly a jak vypad´a architektura s´ıtˇe, kter´a vyuˇz´ıv´a tyto protokoly, pojedn´av´a tato kapitola. Vˇetˇsina obr´azk˚ u je pˇrevzata z [23]. Uk´azka, jak vypad´a signalizace hovoru pro protokol H.323, je na obr. 2.1. Popis jednotliv´ ych krok˚ u signalizace • 1. T1 pos´ıl´a RAS zpr´avu ARQ (admission request) gatekeeperu pro povolen´ı pˇr´ıstupu. • 2. Gatekeeper potvrzuje pˇr´ıstup pˇr´ıkazem ACF (admission confirmation). • 3. T1 pos´ıl´a H.255 zpr´avu ”setup” termin´alu T2. • 4. Termin´al odpov´ıd´a zpr´avou ”call proceeding” - prob´ıh´a sestaven´ı spojen´ı. • 5. a 6. T2 se registruje u gatekeeperu (stejnˇe jako T1 v bodech 1. a 2.). • 7. T2 pos´ıl´a ”alerting” zpr´avu o sestaven´ı spojen´ı. • 8. T2 potvrzuje sestaven´ı spojen´ı zpr´avou”connect”.
2.1
H.323
Protokol H.323 [1], [9] je jedn´ım z hlavn´ıch standard˚ u pro VoIP komunikaci. D´ale je tak´e nejpouˇz´ıvanˇejˇs´ım protokolem pro videokonference. Protokol H.323 vyuˇz´ıv´a pro pˇrenos informac´ı sluˇzeb protokolu TCP. To zajiˇst’uje spolehliv´ y pˇrenos mezi jednotliv´ ymi u ´ˇcastn´ıky spojen´ı. Vlivem v´ yˇse zm´ınˇen´ ych nedostatk˚ u IP s´ıtˇe vˇsak m˚ uˇze vyuˇzit´ı sluˇzeb protokolu TCP s sebou pˇrin´est i probl´emy, kter´e se projev´ı velk´ ym zpoˇzdˇen´ım relac´ı protokolu H.323. Na vlastnostech protokolu se v´ yraznˇe projevila skuteˇcnost, ˇze tv˚ urci protokolu mˇeli velice bl´ızko k technologi´ım telefonn´ıch s´ıt´ı a ponˇekud opomnˇeli v´ yhodn´e vlastnosti a zvyklosti ze s´ıt´ı poˇc´ıtaˇcov´ ych. Protokol definuje v s´ıti nˇekolik center a na jejich existenci a funkˇcnosti je z´avisl´a funkˇcnost cel´eho syst´emu. Tento pˇr´ıstup vn´aˇs´ı do cel´eho syst´emu potenci´aln´ı nebezpeˇc´ı selh´an´ı celku z d˚ uvodu poruchy pouze jedn´e z jeho ˇc´ast´ı. Odborn´ıci z prostˇred´ı poˇc´ıtaˇcov´ ych s´ıt´ı se snaˇz´ı maxim´alnˇe oprostit od tohoto modelu a cel´ y syst´em decentralizovat a t´ım zv´ yˇsit jeho odolnost proti moˇzn´ ym poruch´am. Na druhou stranu existence tˇechto center pˇrin´aˇs´ı ˇradu v´ yhod, kter´e umoˇzn ˇuj´ı napˇr´ıklad moˇznost adresace s vyuˇzit´ım telefonn´ıch ˇc´ısel, sbˇer dat nutn´ ych pro tarifikaci provozu, definovat centr´alnˇe br´any pro urˇcit´e smˇery atd 2.2.
4
ˇ ´I PROTOKOLY PRO VOIP KAPITOLA 2. SIGNALIZACN
Obr´azek 2.1: Pˇr´ıklad pr˚ ubˇehu signalizace pro RAS, H.255 a H.245 mezi termin´aly T1 a T2 pˇres gatekeeper
ˇ ´I PROTOKOLY PRO VOIP KAPITOLA 2. SIGNALIZACN
5
Obr´azek 2.2: Architektura H.323 s´ıtˇe Logick´ a topologie s´ıtˇ e pro pˇ renos hlasov´ ych dat s vyuˇ zit´ım protokolu H.323 je definovan´ a pomoc´ı nˇ ekolika z´ akladn´ıch pojm˚ u: • Entita - Kaˇzd´a komponenta H.323, vˇcetnˇe termin´al˚ u, bran (Gateway), ˇradiˇc˚ u spojen´ı (Gatekeeper), ˇradiˇc˚ u konferenc´ı (Multipoint Controller) a dalˇs´ıch jednotek nutn´ ych pro zajiˇstˇen´ı spojen´ı. • Koncov´ y bod (Endpoint) - Jedn´a se o koncov´e termin´aly, br´any (Gateway) a ˇradiˇce konferenc´ı (Multipoint Controler). Kaˇzd´ y koncov´ y bod s´ıtˇe H.323 m˚ uˇze sestavovat a ruˇsit spojen´ı, pˇr´ıpadnˇe b´ yt vol´an. Kaˇzd´e hovorov´e spojen´ı v s´ıti H.323 zaˇc´ın´a a konˇc´ı vˇzdy koncov´ ym bodem. • Br´ ana (Gateway) - Br´anou se rozum´ı rozhran´ı mezi s´ıt´ı H.323 a jin´ ymi s´ıtˇemi. ’ Br´ana je koncov´ ym bodem H.323 s´ıtˇe a zajiˇst uje v re´aln´em ˇcase dvoucestnou komunikaci mezi koncov´ ymi body H.323 a koncov´ ymi body jin´ ych s´ıt´ı. ˇ c spojen´ı je H.323 entita zajiˇst’uj´ıc´ı pˇreklad ˇ • Radiˇ c spojen´ı (Gatekeeper) - Radiˇ adres a ˇr´ızen´ı pˇr´ıstupu pro vˇsechny H.323 koncov´e body tj. termin´aly, br´any a ˇ c spojen´ı m˚ ostatn´ı pˇr´ısluˇsenstv´ı. Radiˇ uˇze pomoc´ı signalizace dohl´ıˇzet nad vˇsemi sluˇzbami, kter´e s´ıt’ nab´ız´ı koncov´ ym u ´ˇcastn´ık˚ um, vˇcetnˇe ˇr´ızen´ı, dohledu a sbˇer tarifn´ıch informac´ı. •
ˇ c konference (zkr´acenˇe ˇ Radiˇ c konference (Multipoint Controler) - Radiˇ oznaˇcovan´ y MC) je stanic´ı, kter´a ˇr´ıd´ı v re´aln´em ˇcase konferenci v´ıce uˇzivatel˚ u. Pˇresn´a a u ´pln´a definice jednotliv´ ych pojm˚ u je souˇc´ast doporuˇcen´ı ITU-T H.323.
6
ˇ ´I PROTOKOLY PRO VOIP KAPITOLA 2. SIGNALIZACN
Obr´azek 2.3: H.323 Stack - soubor protokol˚ u
2.2
SIP - Session initation protocol
Protokol SIP [18], [9] vych´az´ı z osvˇedˇcen´ ych a prax´ı ovˇeˇren´ ych protokol˚ u jako HTTP (Hyper Text Transfer Protocol), ˇci SMTP (Simle Mail Transfer Protocol). Protokol je znakovˇe orientovan´ y a pˇri odchycen´ı velmi dobˇre ˇciteln´ y obr. 2.5. To umoˇzn ˇuje pouˇzit´ı (v IP s´ıti) bˇeˇzn´ ych technick´ ych prostˇredk˚ u pro diagnostiku pˇrenosu, jako napˇr´ıklad softwarov´ y n´astroj tcpdump, zn´am´ y z prostˇred´ı operaˇcn´ıho syst´emu Unix, k monitorov´an´ı druhu a obsahu pˇren´aˇsen´ ych paket˚ u. Nen´ı proto nutn´ y n´akup speci´aln´ıho programov´eho vybaven´ı, pˇr´ıpadnˇe zaˇr´ızen´ı pro diagnostiku provozu jako napˇr. u protokolu H.323. Na rozd´ıl od protokolu H.323 je pouˇzita strategie maxim´aln´ı decentralizace ˇr´ızen´ı 2.4, protokol nedefinuje ˇz´adn´a centr´aln´ı m´ısta v s´ıti, komunikace prob´ıh´a v´ yluˇcnˇe mezi koncov´ ymi body. Tento pˇr´ıstup podstatnˇe zvyˇsuje odolnost cel´eho syst´emu vystavˇen´eho na sluˇzb´ach protokolu SIP jak proti v´ ypadk˚ um nˇekter´ ych jeho ˇc´ast´ı, tak proti v´ ypadk˚ um IP s´ıtˇe. Na druhou stranu je velk´ y probl´em se sbˇerem u ´daj˚ u nutn´ ych pro zpoplatˇ nov´an´ı hovor˚ u. Nen´ı t´emˇeˇr moˇzn´e vyuˇz´ıt syst´em zpoplatˇ nov´an´ı telekomunikaˇcn´ıch sluˇzeb zn´am´ y z prostˇred´ı tradiˇcn´ıch telefonn´ıch s´ıt´ı. Zpoplatˇ nov´an´ı telefonn´ıch hovor˚ u je nutn´e pˇrev´adˇet na platby za mnoˇzstv´ı pˇrenesen´ ych dat do okoln´ıch s´ıt´ı, ˇci pauˇs´aln´ı poplatky. V doporuˇ cen´ı IETF pro protokol SIP jsou definov´ any ˇ ctyˇ ri z´ akladn´ı prvky s´ıtˇ e: Uˇ zivatelsk´ y agent (User Agent) - Uˇzivatelsk´a aplikace, umoˇzn ˇuj´ıc´ı koncov´ ym u ´ˇcastn´ık˚ um s´ıtˇe obousmˇernou komunikaci pomoc´ı protokolu SIP. User Agent (UA) je d´ale rozdˇelen na dvˇe ˇc´asti: 1. UA Client - klientsk´a ˇc´ast UA slouˇz´ıc´ı k sestavov´an´ı a ˇr´ızen´ı odchoz´ıch relac´ı 2. UA Server - serverov´a ˇc´ast UA slouˇz´ıc´ı k pˇrijet´ı a ˇr´ızen´ı pˇr´ıchoz´ıch relac´ı SIP Proxy Server - prov´ad´ı funkce jako: hled´an´ı u ´ˇcastn´ıka v koncov´e s´ıti, smˇerov´an´ı hovor˚ u (spolupr´ace s Firewallem ˇci NATem), zprostˇredkov´an´ı styku s jinou s´ıt´ı. SIP Redirect Server - smˇeruje vol´an´ı jin´ ym server˚ um v s´ıti. SIP Registrar - slouˇz´ı k registraci koncov´ ych uˇzivatel˚ u
ˇ ´I PROTOKOLY PRO VOIP KAPITOLA 2. SIGNALIZACN
7
Obr´azek 2.4: SIP architektura Pˇresn´a definice pojm˚ u je souˇc´ast´ı patˇriˇcn´ ych doporuˇcen´ı RFC od IETF. Pˇri sestavov´an´ı spojen´ı se vˇzdy vyuˇz´ıv´a dom´enov´e jm´eno stroje v s´ıti IP. V prvn´ım kroku se provede hled´an´ı IP adresy koncov´eho u ´ˇcastn´ıka pˇr´ıpadnˇe SIP serveru pomoc´ı DNS (Domain Name Service). Pˇri dalˇs´ım kroku se sestav´ı spojen´ı s koncov´ ym u ´ˇcastn´ıkem, pˇr´ıpadnˇe se vyuˇzije sluˇzeb nˇejak´eho SIP serveru, nen´ı-li moˇzn´e sestavit spojen´ı pˇr´ımo (napˇr´ıklad kdyˇz je u ´ˇcastn´ık um´ıstˇen´ y za Firewallem ˇci NATem, nebo je mobiln´ı). Smˇeruje-li se spojen´ı mimo s´ıt’ SIP protokolu, mus´ı volaj´ıc´ı u ´ˇcastn´ık vˇzdy s´am rozhodnout, kterou br´anu pro spojen´ı pouˇzije a zn´at jej´ı dom´enovou, pˇr´ıpadnˇe IP adresu. Identifikace uˇ zivatele v s´ıti: Identifikace koncov´eho uˇzivatele v s´ıti prob´ıh´a pomoc´ı Uniform Resource Identifier (URI). Struktura identifikaˇcn´ı hlaviˇcky vypad´a n´asledovnˇe:
sip:user[:password]@host[:port][;uri-parameters][?headers] Takto zaveden´a identifikaˇcn´ı struktura definuje jak uˇzivatele, tak i server, od kter´eho se oˇcek´av´a, ˇze zn´a adresu uˇzivatele. Pro n´asleduj´ıc´ı pˇr´ıklad je uˇzivatel michalvanek a server iptel.org.
[email protected] Protokol SIP umoˇzn ˇuje tak´e vytvoˇren´ı k´odovan´eho pˇripojen´ı Secure SIP, kter´e v identifikaˇcn´ı hlaviˇcce m´ısto prefixu sip zav´ad´ı prefix sips. Toto k´odov´an´ı je vytvoˇreno za pouˇzit´ı Transport Layer Security (TLS). Velk´e mnoˇzstv´ı registraˇcn´ıch server˚ u podporuje sluˇzbu registrace jednoho uˇzivatele souˇcasnˇe na v´ıce telefon˚ u. SIP URI tak nekoresponduje pouze s jedn´ım telefonem, ale se vˇsemi, na kter´ ych je uˇzivatel dostupn´ y. Vˇsechny tyto telefony pak mohou b´ yt adresovan´e a zvonit souˇcasnˇe. Nastaven´ı parametr˚ u pˇ renosu: Pro dohodnut´ı parametr˚ u pˇrenosu multimedi´aln´ıch dat jako je zvukov´ y kodek, ˇc´ıslo portu, frekvence vzorkov´an´ı nebo pouˇzit´ y transportn´ı protokol se vyuˇz´ıv´a Session Description Protocol (SDP). Tento protokol je podobnˇe jako SIP textov´ y.
8
ˇ ´I PROTOKOLY PRO VOIP KAPITOLA 2. SIGNALIZACN
Obr´azek 2.5: SIP zpr´ava 2.2.1
Session Description Protocol
Session Description Protocol (SDP) je urˇcen´ y pro pˇrenos parametr˚ u, kter´e jsou d˚ uleˇzit´e pro stanoven´ı spojen´ı. Jedn´a se o textov´ y protokol a je definov´an IETF RFC 4566 [5]. Pouˇz´ıv´a se pro popis multemidi´aln´ıch sessions, ˇz´adost´ı o hovor, v´ ybˇer portu, kodeku a dalˇs´ı parametry nutn´e pro zapoˇcet´ı spojen´ı (distribuce kl´ıˇc˚ u pro zabezpeˇcen´ı spojen´ı). SDP tedy nenese dan´ y hovor, ale pom´ah´a koncov´ ym uˇzivatel˚ um domluvit si podm´ınky, za jak´ ych bude hovor uskuteˇcnˇen, a zajist´ı potvrzen´ı pro obˇe strany. SDP byl p˚ uvodnˇe vyvinut jako komponenta Session Announcement Protocol (SAP), z´ıskal vˇsak velkou oblibu ve spojen´ı s RTP, SRTP a SIP, proto se stal samostan´ ym form´atem pro popis multicastov´ ych sessions.
2.3
Gateway Decomposition
Media Gateway Control Protocols slouˇz´ı pro adresov´an´ı zaˇr´ızen´ı v s´ıti, kter´a sest´avaj´ı z rozprostˇren´ ych VoIP bran. Tyto br´any obsahuj´ı Media Gateways (MGs) a Media Gateway Controllers (MGCs). Pro okol´ı se tv´aˇr´ı jako jedna Gateway. MGCs umoˇzn ˇuj´ı komunikaci mezi MGs a ostatn´ımi komponenty s´ıtˇe, jako jsou H.323 Gatekeeper nebo SIP Proxy Server. MGs jsou urˇceny pro konverzi pˇren´aˇsen´eho audio sign´alu mezi obvodovˇe pˇrep´ınan´ ymi s´ıtˇemi a paketov´ ymi s´ıtˇemi. MGCs slouˇz´ı pro ovl´ad´an´ı jednotliv´ ych MCs, kter´e m´a ve sv´e spr´avˇe. Jako pˇr´ıklady tˇechto protokol˚ u m˚ uˇzeme uv´est Media Gateway Control Protocol (MGCP) a protokol Megaco/H.248. 2.3.1
MGCP - Media Gateway Control Protocol
Media Gateway Control Protocol [15] [2] je urˇcen pro komunikaci jednotliv´ ych VoIP bran. Jedn´a se o doplˇ nkov´ y protokol k H.323 a SIP. MGCP je definovan´ y IETF a je textov´eho tvaru, podobnˇe jako SIP. MGCP m´a 2 hlavn´ı ˇc´asti - Call Agent a Media Gateway, kter´a se star´a o pˇrenos hovoru mezi IP s´ıtˇemi a PSTN. Dalˇs´ı ˇc´ast´ı je Signalling Gateway, kter´a je pˇripojena k PSTN. Call Agent se star´a o ˇr´ızen´ı hovoru a podporuje dalˇs´ı funkce pˇri pˇrenosu hlasu - napˇr. konverze hlasu z form´atu TDM do form´atu VoIP.
ˇ ´I PROTOKOLY PRO VOIP KAPITOLA 2. SIGNALIZACN
9
Obr´azek 2.6: Architektura a pouˇzit´ı protokolu MGCP
Popis architektury MGCP: J´adrem MGCP je MGC server neboli Call Agent, je povinn´ y prvkem MGCP protokolu. Star´a se o ˇr´ızen´ı hovor˚ u, konferenc´ı a podporuje jednotliv´e sluˇzby. MG jsou nezbytn´e pro hovory a konference, avˇsak nespravuj´ı jednotliv´e f´aze hovoru. MGs prov´ad´ı pˇr´ıkazy na z´akladˇe poˇzadavk˚ u od MGC call agent˚ u. MGCP pˇredpokl´ad´a vz´ajemnou synchronizaci jednotliv´ ych Call Agent˚ u pomoc´ı tzv. koherentn´ıch pˇr´ıkaz˚ u avˇsak nedefinuje vlastn´ı mechanismus, jak se dan´a synchronizace m´a prov´est. 2.3.2
MEGACO/H.248
Protokol MEGACO [16] byl vyvinut IETF a ITU-T jako kompromis mezi protokoly MGCP a MDCP. Roku 1999 vznikla jeho specifikace H.GCP (H-series, Gateway Control Protocol) pozdˇeji oznaˇcena jako H.248. Pozdˇeji byly tyto standardy sjednoceny pod spoleˇcn´ ym n´azvem MEGACO/H.248.V MEGACO z˚ ustalo stejn´e jako v MGCP s´emantika ˇr´ıd´ıc´ıch pˇr´ıkaz˚ u, ˇr´ıd´ıc´ı sign´aly, pˇrenos po UDP. rozd´ıly mezi MEGACO/H.248 a MGCP: • rozˇs´ıˇren´e sluˇzby a moˇznosti pro konferenˇcn´ı hovory • jednoduˇsˇs´ı navazov´an´ı konferenˇcn´ıch hovor˚ u • vylepˇsen´a syntaxe pro jednoduˇsˇs´ı zpracov´an´ı zpr´av • podpora pˇrenosu po TCP a UDP • moˇznost volby mezi textov´ ym a bin´arn´ım k´odov´an´ım • rozˇs´ıˇren´ y popis bal´ıˇck˚ u Architektura Megaco/H.248 je v z´akladˇe stejn´a jako u MGCP - obr. 2.7 , ale model protokolu je zcela odliˇsn´ y. Megaco specifikuje dvˇe z´akladn´ı entity: ,,Terminations” (zdroj multimedi´aln´ıho toku) a ,,context” (mnoˇzina zdroj˚ u, zapojen´ ych do vol´an´ı). Doporuˇcen´ y port pro textov´ y reˇzim protokolu je 2944 (UDP, TCP) a 2945 pro bin´arn´ı podobu protokolu.
10
ˇ ´I PROTOKOLY PRO VOIP KAPITOLA 2. SIGNALIZACN
Obr´azek 2.7: Architektura a pouˇzit´ı protokolu MEGACO/H.248
Obr´azek 2.8: Vyuˇzit´ı protokolu IAX
2.4
IAX - Inter Asterisk Exchange
IAX [2] [26] [3] je protokol p˚ uvodnˇe urˇcen´ y pro komunikaci mezi softwarov´ ymi u ´stˇrednami Asterisk. V dneˇsn´ı dobˇe je vˇsak ˇsiroce podporov´an softwarov´ ymi switchi a dalˇs´ımi PBX u ´stˇrednami obr. 2.8. Pouˇz´ıv´a se jak pro komunikaci mezi servery, tak i pro komunikaci klient-server. Dnes se ve vˇetˇsinˇe pˇr´ıpad˚ u pouˇz´ıv´a druh´a verze protokolu IAX2. Z´ akladn´ı vlastnosti: IAX2 je VoIP protokol, kter´ y pro pˇrenos signalizace a dat vyuˇz´ıv´a jeden datov´ y tok [3]. Pˇr´ıkazy a parametry jsou pos´ıl´any v bin´arn´ım form´atu. Jedn´a se tedy o bin´arn´ı protokol. Byl vyvinut proto, aby vyuˇzil v´ yhod z prostˇred´ı PSTN v paketovˇe pˇrep´ınan´ ych s´ıt´ıch. Pro komunikaci mezi koncov´ ymi body se vyuˇz´ıv´a samostatn´eho UDP datov´eho toku - jak pro data tak pro signalizaci. Hlas je pˇren´aˇsen v hovorov´em p´asmu, coˇz umoˇzn ˇuje lepˇs´ı propustnost pˇres firewall a lze l´epe vyuˇz´ıt pˇrekladu adres. Tato vlastnost jej odliˇsuje od protokol˚ u SIP, H.323 a MGCP, kter´e vyuˇz´ıvaj´ı dalˇs´ı RTP stream pro pˇrenos informac´ı. IAX2 podporuje sluˇcov´an´ı (trunking)a multiplexov´an´ı kan´al˚ u pˇres jeden spoj. Pˇri sluˇcov´an´ı jsou data z r˚ uzn´ ych hovor˚ u slouˇcena dohromady do paket˚ u tak, ˇze jeden IP datagram m˚ uˇze pˇren´aˇset informace od v´ıce hovor˚ u, coˇz umoˇzn ˇuje sn´ıˇzen´ı latence hovoru. Jedn´a se o velkou v´ yhodu pro VoIP uˇzivatele, kde IP hlaviˇcky zab´ıraj´ı velkou ˇc´ast ˇs´ıˇrky p´asma. Pˇrihl´aˇsen´ı k s´ıt´ı je velmi podobn´e jako u protokolu SIP. Vyuˇz´ıv´a se URI adresa v dan´em
ˇ ´I PROTOKOLY PRO VOIP KAPITOLA 2. SIGNALIZACN
11
Obr´azek 2.9: Struktura r´amce Full Frame
Obr´azek 2.10: Struktura r´amce Mini Frame form´atu. iax:[username@]host[:port][/number[?context]]
Struktura r´ amc˚ u: IAX vyuˇz´ıv´a pro pˇrenos dat 2 typ˚ u r´amc˚ u, dle poˇzadavk˚ u t´ ykaj´ıc´ı se spolehlivosti doruˇcen´ı. Doruˇcen´ı garantuj´ı tzv. Full Frames obr. 2.9. Pouˇz´ıvaj´ı se zejm´ena pro identifikaci u ´ˇcastn´ık˚ u a dalˇs´ı synchronizaˇcn´ı u ´daje ohlednˇe signalizace. M˚ uˇzou tak´e pˇren´aˇset multimedi´aln´ı informace. Mini Frames obr. 2.10 se pouˇz´ıvaj´ı pro pˇrenos multimedi´aln´ıch dat a jejich doruˇcen´ı nen´ı zaruˇceno. Popis struktury r´ amc˚ u: • F - urˇcuje, zda se jedn´a o r´amec typu Full Frame nebo Mini Frame • Source call number - specifikuje ˇc´ıslo vol´an´ı, kter´e pouˇz´ıv´a vys´ılac´ı klient k jedineˇcn´e identifikaci vol´an´ı • R bit - urˇcuje, zda byl r´amec opˇetovnˇe pˇren´aˇsen • Destinationcall number - specifikuje ˇc´ıslo vol´an´ı, kter´e pouˇzije vys´ılaj´ıc´ı k identifikaci vol´an´ı na stranˇe pˇr´ıjemce. Tato hodnota je shodn´a s hodnotou Source call number na stranˇe pˇr´ıjemce • Timestamp - ˇcasov´a zn´amka • Seqno - poˇc´ıtadlo odeslan´ ych Full Frame r´amc˚ u • ISeqno - poˇc´ıtadlo pˇrijat´ ych Full Frame r´amc˚ u • Frametype - definuje typ zpr´avy obsaˇzen´e v r´amci (definov´ano deset typ˚ u) • C bit - popisuje, jak je n´asleduj´ıc´ıch 7b Subclass k´odov´ano. Pokud C=l pak je hodnota Sub-class interpretov´ana jako mocnina dvou. Pokud C=0, interpretuje se jako 7b ˇc´ıslo
ˇ ´I PROTOKOLY PRO VOIP KAPITOLA 2. SIGNALIZACN
12
Obr´azek 2.11: Decentralizovan´a architektura s´ıtˇe protokolu XMPP
2.5 2.5.1
Dalˇ s´ı protokoly pro VoIP Jabber/XMPP - Jingle
Jabber [24] [2] je komunikaˇcn´ı protokol zaloˇzen´ y na XML pro pos´ıl´an´ı zpr´av (Instant messaging). V´ yhodou je otevˇrenost protokolu a z n´ı vypl´ yvaj´ıc´ı velk´e mnoˇzstv´ı klient˚ ua snadn´a implementace nov´ ych funkc´ı. N´asledn´ıkem protokolu Jabber je protokol XMPP. Extensible Messaging and Presence Protocol (XMPP) [24] [2], neboli rozˇsiˇriteln´ y protokol pro pos´ıl´an´ı zpr´av a zjiˇstˇen´ı stavu, p˚ uvodnˇe vznikl jako protokol pro instant messaging s´ıt’ Jabber. XMPP je implementac´ı obecn´eho znaˇckovac´ıho jazyka XML. Specifikace jsou zcela otevˇren´e a dostupn´e vˇsem, kdo maj´ı z´ajem o implementaci software s podporou XMPP. Servery XMPP protokolu bˇeˇz´ı standardnˇe na TCP portu 5222. Pro vz´ajemnou komunikaci server˚ u je pak vyhrazen port 5269. ’ S´ıt protokolu XMPP nen´ı centralizovan´a do jednoho m´ısta obr 2.11, jako je zvykem u vˇetˇsiny ostatn´ıch IM, ale je distribuovan´a na servery po cel´em svˇetˇe, na kter´ ych je moˇzno si zaloˇzit uˇzivatelsk´e konto. Identifik´atory uˇzivatel˚ u jsou v z´akladn´ım tvaru syntakticky i s´emanticky podobn´e e-mailov´ ym adres´am. Identifik´ ator uˇ zivatele pro pˇ rihl´ aˇ sen´ı k s´ıti XMPP.
[email protected] IM sluˇzba spoleˇcnosti Google, nazvan´a Google Talk, takt´eˇz pracuje na protokolu XMPP. Google dokonce s touto sluˇzbou pˇrinesl rozˇs´ıˇren´ı slouˇz´ıc´ı k internetov´e telefonii, jehoˇz specifikace zveˇrejnil a n´aslednˇe se staly z´akladem XEP dokument˚ u pod n´azvem Jingle, kter´e se d´ale rozv´ıjej´ı. Jinlge je tedy signalizaˇcn´ım protokolem Googlu.
2.6
Skype
Skype je peer-to-peer program, kter´ y umoˇzn ˇuje provozovat internetovou telefonii (VoIP) a Instant messaging [6] [2]. Vzhledem k tomu, ˇze Skype v´ ych´az´ı z technologie P2P, odpov´ıd´a tomu taky jeho architektura. Architektura s´ıtˇe skype je decentralizovan´a obr 2.12. Hlavn´ım prvkem architektury je centr´aln´ı Skype login server, Super Node, coˇz je uˇzivatel, pˇres kter´eho jsou smˇerov´any dalˇs´ı hovory a nakonec koncov´ y uˇzivatele Node. Pˇrestoˇze je Skype uzavˇren´ y protokol, bylo jiˇz provedeno nˇekolik pokus˚ u o jeho rozk´odov´an´ı pomoc´ı zpˇetn´eho inˇzen´ yrstv´ı. Dle Philla Zimmermana (tv˚ urce PGP), tyto snahy nem˚ uˇzou
ˇ ´I PROTOKOLY PRO VOIP KAPITOLA 2. SIGNALIZACN
13
Obr´azek 2.12: Architektura s´ıtˇe Skype ohrozit zabezpeˇcen´ı a funkce Skype, jelikoˇz mal´ ymi zmˇenami v k´odu lze vˇse zmˇenit a m˚ uˇze se zaˇc´ıt od zaˇc´atku. Z d˚ uvodu, ˇze je Skype uzavˇren´ y protokol, nen´ı mu v t´eto pr´aci vˇenov´ano tolik prostoru, prestoˇze pro sv´e svˇetov´e rozˇs´ıˇren´ı by si to jistˇe zaslouˇzil.
14
ˇ ´I PROTOKOLY PRO VOIP KAPITOLA 2. SIGNALIZACN
ˇ KAPITOLA 3. PROTOKOLY PRO PRENOS HLASU
15
3 Protokoly pro pˇ renos hlasu Plynul´ y pˇrenos hlasu je nejd˚ uleˇzitejˇs´ı vlastnost´ı VoIP. Po sestaven´ı hovoru pomoc´ı signalizaˇcn´ıho protokolu nast´av´a pˇrenos hlasu protokolem ˇctvrt´e vrstvy. Tyto protokoly pracuj´ı na p´at´e, aplikaˇcn´ı vrstvˇe TCP/IP modelu. Mezi tyto protokoly patˇr´ı protokol RTP a jeho sestersk´ y protokol RTCP. Protokoly pro pˇrenos VoIP se tedy nerozum´ı protokoly TCP, UDP pˇr´ıp. SCTP, kter´e se vyuˇz´ıvaj´ı obecnˇe pro pˇrenos jak´ ychkoliv dat a pracuj´ı na ˇctvrt´e(transportn´ı) vrstvˇe. Jelikoˇz protokol SCTP je pomˇernˇe nov´ y a na sv´e prosazen´ı ve VoIP teprve ˇcek´a, je mu vˇenov´an z´avˇer kapitoly.
3.1
RTP
Real-time Transport Protocol (RTP) definuje standardn´ı paketov´ y form´at pro doruˇcov´an´ı zvukov´ ych a video dat po internetu [17] [2]. RTP byl p˚ uvodnˇe vyv´ıjen jako protokol pro v´ ybˇerov´e vys´ıl´an´ı, ale pouˇz´ıv´an byl v mnoha unicast aplikac´ıch. Protokol se ˇcasto pouˇz´ıv´a v streaming media syst´emech (proudˇen´ı medi´aln´ıch dat), ve spojen´ı s RTSP jako Video telefonn´ı konference nebo videokonference, ve spojen´ı s H.323 nebo SIP, ˇc´ımˇz je protokol technick´ ym z´akladem VoIP technologie. Funkcionalita RTP zahrnuje: • urˇcen´ı uˇziteˇcn´eho zat´ıˇzen´ı • ˇc´ıslov´an´ı sekvenc´ı • ˇcasov´e raz´ıtkov´an´ı • sledov´an´ı pˇrenosu RTP zajiˇst’uje nepˇreruˇsovan´ y pˇrenos hlasov´ ych paket˚ u na internetu. Struktura RTP paketu - obr 3.1. • Ver - (2 bity) verze protokolu(souˇc. 2.0)
Obr´azek 3.1: Struktura RTP paketu
ˇ KAPITOLA 3. PROTOKOLY PRO PRENOS HLASU
16
• P - 1 bit pro indikaci paddingu na konci RTP paketu • X - 1 bit pro indikaci zda je pouˇzito rozˇs´ıˇren´ı protokolu • CC - (4 bity) CSRC identifik´ator • M - (1 bit) pouˇz´ıv´a ho aplikaˇcn´ı vrstva, pˇri pouˇzit´ı slouˇz´ı jako indikace speci´aln´ıch dat pro konkr´etn´ı aplikaci • PT - (7 bit˚ u) payload type • SSRC - indikace synchronizace zdroje • CSRC - zdrojov´e ID • Extension header - obsahuje d´elku EHL(extension header length0, kromˇe vlastn´ıch 32 bit˚ u
3.2
RTCP
Real-time Transport Control Protocol (RTCP) je sestersk´ ym protokolem protokolu RTP [17]. RTCP umoˇzn ˇuje vnˇejˇs´ı kontrolu dat pro RTP tok. Zajiˇst’uje pro RTP zapouzdˇren´ı a pˇrenos multimedi´aln´ıch dat, s´am vˇsak ˇz´adn´ y pˇrenos dat nepodporuje. Vyuˇz´ıv´a se pro pˇrenos ˇr´ıd´ıcich sign´al˚ u mezi u ´ˇcastn´ıky spojen´ı pˇri hovoru. Z´akladn´ı funkc´ı RTCP je poskytnout zpˇetnou vazbu o kvalitˇe hovoru pro protokol RTP. RTCP shromaˇzd’uje statistiky o spojen´ı a dalˇs´ı informace, jako je poˇcet odeslan´ ych paket˚ u, byt˚ u, ztracen´ ych paket˚ u, jitter a ”round trip delay”. Aplikace m˚ uˇzou dan´a data vyuˇz´ıt pro zv´ yˇsen´ı kvality hovoru, pravdˇepodobnˇe omezen´ım datov´eho toku nebo pouˇzit´ım jin´eho kodeku. Existuje nˇ ekolik typ˚ u RTCP paket˚ u obr. 3.2: • ender • report paket • Receiver report paket • Source Description RTCP Paket • Goodbye RTCP Paket • Application Specific RTCP paket. RTCP jako takov´ y s´am nenab´ız´ı ˇz´adn´e zabezpeˇcen´ı nebo autentizaci. Pro tyto u ´ˇcely byl vyvinut protokol SRTCP.
ˇ KAPITOLA 3. PROTOKOLY PRO PRENOS HLASU
17
Obr´azek 3.2: Struktura RTCP paketu
3.3
SCTP
Stream Control Transmission Protocol (SCTP) je transportn´ı protokol, kter´ y navrhla v roce 2000 pracovn´ı skupina IETF Signaling Transport (SIGTRAN) zab´ yvaj´ıc´ı pˇrenosem telefonn´ı signalizace (SS7) po IP [19] [2]. Odtud poch´az´ı poˇzadavek na nˇekolik navz´ajem nez´avisl´ ych kan´al˚ u, kter´e jsou pˇrepravov´any paralelnˇe. Pr´avˇe to je zˇrejmˇe nejvˇetˇs´ı odliˇsnost´ı SCTP od st´avaj´ıc´ıch transportn´ıch protokol˚ u. Po nav´az´an´ı spojen´ı, kter´emu se v terminologii SCTP ˇr´ık´a asociace, po nˇem lze pˇren´aˇset ˇradu navz´ajem nez´avisl´ ych proud˚ u (stream). V r´amci kaˇzd´eho z nich dok´aˇze SCTP garantovat doruˇcen´ı vˇsech dat ve spr´avn´em poˇrad´ı. Pˇr´ıpadn´ y v´ ypadek (a pozdˇejˇs´ı opakov´an´ı, ˇcili zdrˇzen´ı) v nˇekter´em z proud˚ u se vˇsak nijak net´ yk´a proud˚ u ostatn´ıch. Jejich komunikace pokraˇcuje bez pˇreruˇsen´ı. SCTP je transportn´ı protokol, mezi kter´e patˇr´ı TCP a UDP. SCTP m´a oproti pˇredchoz´ım dvˇema protokol˚ um velk´e v´ yhody (tab. 3.1), bohuˇzel ve VoIP syst´emech se zat´ım nijak v´ yznamnˇe neprosadil. SCTP m´ a mnohem jednoduˇ sˇ s´ı strukturu neˇ z UDP nebo TCP viz obr. 3.3. Skl´ad´a se ze 2 hlavn´ıch ˇc´ast´ı. 1. hlaviˇcka o velikosti 12 byt˚ u 2. data chunks, kter´e tvoˇr´ı zbytek paketu. Chunk˚ u je nˇekolik typ˚ u, pro r˚ uzn´e typy pˇren´aˇsen´ ych dat.
ˇ KAPITOLA 3. PROTOKOLY PRO PRENOS HLASU
18
Obr´azek 3.3: Struktura SCTP paketu V´ yhody protokolu SCTP • Multihoming - situace, kdy komunikuj´ıc´ı uzel m´a nˇekolik IP adres. Dostupn´e adresy si partneˇri vymˇen ˇuj´ı pˇri vytvoˇren´ı asociace, m˚ uˇze se jednat o libovolnou smˇes IPv4 a IPv6 adres. Bˇehem komunikace je jedna z nich br´ana jako prim´arn´ı a na ni jsou odes´ıl´ana data. Pro opakov´an´ı vˇsak vyb´ır´a jinou a pokud m´a prim´arn´ı adresa ˇcastˇejˇs´ı probl´emy s dostupnost´ı, pˇrejde odes´ılatel na jinou (je-li k dispozici). SCTP monitoruje vˇsechny cesty a udrˇzuje si pˇrehled o jejich stavu. • Doruˇcen´ı dat v bal´ıc´ıch (chunks) pomoc´ı proud˚ u eliminuje nechtˇen´e, chybˇej´ıc´ı bloky dat, jako je tomu v pˇr´ıpadˇe TCP. • V´ ybˇ er a sledov´ an´ı cesty - M˚ uˇzete si vybrat hlavn´ı (prim´arn´ı) adresu a pokud m´a prim´arn´ı adresa ˇcastˇejˇs´ı probl´emy s dostupnost´ı, pˇrejde odes´ılatel na jinou (je-li k dispozici). • Ovˇ eˇ rovac´ı a potvrzovac´ı mechanismy - SCTP komplikuje nˇekter´e u ´toky smˇeˇruj´ıc´ı k nedostupnosti sluˇzeb (DoS). Zajiˇst’uje ovˇeˇren´ı opakuj´ıc´ıch se a chybˇej´ıc´ıch bal´ık˚ u. Pro u ´plnost jeˇstˇe uv´ad´ım srovn´an´ı protokol˚ u UDP, TCP a SCTP v tab. 3.1:
ˇ KAPITOLA 3. PROTOKOLY PRO PRENOS HLASU
vlastnost spojovˇe orientovan´ y spolehliv´ y transport Preserve message boundary uspoˇr´adan´e doruˇcen´ı neuspoˇr´adan´e doruˇcen´ı datov´ y checksum velikost checksum (bit) MTU ˇr´ızen´ı toku v´ıcen´asobn´ y tok dat multihoming sluˇcov´an´ı
UDP TCP SCTP ne ano ano ne ano ano ano ne ano ne ano ano ano ne ano ano ano ano 16 16 32 ne ano ano ne ano ano ne ne ano ne ne ano ne ne ano
Tabulka 3.1: Srovn´an´ı trasportn´ıch protokol˚ u 4. vrstvy
19
20
ˇ KAPITOLA 3. PROTOKOLY PRO PRENOS HLASU
ˇ ´ U ˚ OBECNE ˇ KAPITOLA 4. BEZPECNOST VOIP SYSTEM
21
4 Bezpeˇ cnost VoIP syst´ em˚ u obecnˇ e Bezpeˇcnost ve VoIP se v dnes st´av´a st´ale diskutovanˇejˇs´ım a diskutovanˇejˇs´ım t´ematem. V minulosti byla vynaloˇzena pr´ace zejm´ena na standardizaci protokol˚ u, jak signalizaˇcn´ıch, tak pro pˇrenos hovoru a na zabezpeˇcen´ı nezb´ yvalo tolik ˇcasu. Dnes uˇz je standardizace hotova a pˇrikl´an´ı se velk´ y v´ yznam k zabezpeˇcen´ı a na anal´ yzu moˇzn´ ych rizik. Jak jsem se zm´ınil v u ´vodu, VoIP vyuˇz´ıv´a Internet pro pˇrenos informace a nikoliv vlastn´ı s´ıt’ jako tomu bylo u PSTN. Tato skuteˇcnost odhalila u ´plnˇe jin´e bezpeˇcnostn´ı hrozby a rizika, kter´e poskytovatel´e telekomunikaˇcn´ıch sluˇzeb neznali. Jak pˇri zabezpeˇcov´an´ı VoIP, tak pˇri obecn´em zabezpeˇcov´an´ı komunikace nejen po internetu je tˇreba zaruˇcit aby u dat byla zachov´ana: • d˚ uvˇernost • autentiˇcnost • integrita D˚ uvˇ ernost pˇren´aˇsen´e zpr´avy znamen´a, ˇze nikdo, kromˇe odes´ılatele a pˇr´ıjemce, nebude moci z´ıskat vlastn´ı obsah informace, kter´a je pˇren´aˇsena. Realizuje se pomoc´ı symetrick´ ych a asymetrick´ ych ˇsifrovac´ıch technik. Autentiˇ cnost zaruˇcuje, ˇze zpr´ava kter´a doraz´ı od odes´ılatele k pˇr´ıjemci je skuteˇcnˇe od osoby, se kterou komunikujeme. Obvykl´a realizace je pomoc´ı hashovac´ıch technik - MD5, SHA1. Integrita zpr´avy znamen´a, ˇze informace, kter´a je odesl´ana od odes´ılatele, doraz´ı v t´e sam´e podobˇe tak´e k pˇr´ıjemci. Popˇr´ıpadˇe budeme moci zjistit, zda zpr´ava byla v pr˚ ubˇehu pˇrenosu modifikov´ana. Vˇetˇsinou se realizuje jako kontroln´ı souˇcet s vyuˇzit´ım MD5 nebo SHA1. Jakmile jsou zaruˇceny uveden´e 3 moˇznosti, m˚ uˇzeme pˇredpokl´adat, ˇze komunikace prob´ıha po bezpeˇcn´em kan´alu. Dalˇs´ı moˇznost´ı porovnat s´ılu zabezpeˇcen´ı je anal´ yzou konkr´etn´ıch kryptovac´ıch algoritm˚ u a technik, testov´an´ı z´avislosti velikost´ı kl´ıˇc˚ u na ˇcasov´ ych moˇznostech deˇsifrov´an´ı, u ´spˇeˇsnost prolomen´ı pomoc´ı r˚ uzn´ ych hackersk´ ych metod. Dan´e t´ema se pˇr´ımo zabezpeˇcen´ı VoIP net´ yk´a, proto se mu budu vˇenovat pouze v pˇr´ıpadech, kdy je to potˇreba zd˚ uraznit. Typick´ ym pˇr´ıkladem je doporuˇcen´ı vyuˇz´ıt 128b kl´ıˇce m´ısto 32b z d˚ uvodu snadn´e moˇznosti prolomen´ı apod.
4.1
Moˇ zn´ eu ´ toky na VoIP
Aby jsme mohli skuteˇcnˇe efektivnˇe zabezpeˇcit veˇskerou komunikaci v r´amci VoIP (signalizace, pˇrenos multimedi´aln´ıch dat), mus´ıme m´ıt k dispozici co nejvˇetˇs´ı poˇcet sc´en´aˇr˚ u u ´tok˚ u. Dan´ y seznam vypracovala organizace Voice over IP Security Alliance (VOIPSA) [13], [25] na z´akladˇe anal´ yzi vˇsech moˇzn´ ych bezpeˇcnostn´ıch rizik. u ´toku.
22 4.1.1
ˇ ´ U ˚ OBECNE ˇ KAPITOLA 4. BEZPECNOST VOIP SYSTEM Misrepresentation (Faleˇ sn´ e informace)
´ Utoky, kter´e pro komunikaci vyuˇz´ıvaj´ı faleˇsn´e nebo zav´adˇej´ıc´ı informace. Tyto u ´toky zahrnuj´ı doruˇcov´an´ı zpr´av, kter´e obsahuj´ı chybnou informaci o identitˇe, opr´avnˇen´ı nebo obsahu. Misrepresenting Identity - Prezentace faleˇsn´ ych osobn´ıch u ´daj˚ u (ID uˇzivatele, jm´eno, email a jin´e osobn´ı u ´daje) Misrepresenting Authority - Pouˇz´ıv´an´ı ciz´ıho hesla, kl´ıˇce nebo certifik´atu za u ´ˇcelem klam´an´ı jin´ ych osob nebo u ´ˇrad˚ u. Misrepresenting Rights - Pouˇz´ıv´an´ı ciz´ıch hesel, kl´ıˇce a certifik´at˚ u za u ´ˇcelem z´ısk´an´ı jinak nepovolen´eho pˇr´ıstupu. Misrepresenting Content - Napodobov´an´ı hlasov´e nebo textov´e informace. 4.1.2
Theft of Services (Kr´ adeˇ z sluˇ zby)
Tyto u ´toky jsou zamˇeˇreny na modifikaci u ´ˇctovac´ıch u ´daj˚ u na stranˇe poskytovatele sluˇzeb a nez´akonn´e pouˇz´ıv´an´ı placen´ ych sluˇzeb.
4.1.3
Unwanted Contact (Nevyˇ z´ adan´ a spojen´ı)
Jedn´a se o vˇsechna spojen´ı, kter´a vyˇzaduj´ı pˇredchoz´ı potvrzen´ı nebo obejdou pˇredchoz´ı zam´ıtnut´ı. Harrassment Vˇsechna vol´an´ı, kter´a tr´ap´ı nebo obtˇeˇzuj´ı uˇzivatele. Extortion - Obdoba u ´toku Harrassment s t´ım rozd´ılem, ˇze doch´az´ı k omezov´an´ı svobody a psychick´emu u ´toku. Unwanted Lawful Content - Zahrnuje VoIP SPAM a jin´e nevyˇz´adan´e sluˇzby. 4.1.4
Eavesdropping (Odposlouch´ av´ an´ı)
´ cn´ık smˇeˇruje sv´e aktivity na monitorov´an´ı signalizaˇcn´ıch a medi´aln´ıch dat. Pˇri tomto Utoˇ u ´toku nedoch´az´ı k modifikaci pˇren´aˇsen´ ych dat. Call Pattern Tracking - Nez´akonn´e shromaˇzd’ov´an´ı a n´asledn´a anal´ yza silov´eho provozu. Je to obecn´a technika pro odhalov´an´ı identit. Traffic Capture - Ukl´ad´an´ı silov´eho provozu. Jedn´a se o z´akladn´ı metodu pro zachyt´av´an´ı komunikace mezi u ´ˇcastn´ıky komunikace. Number Harvesting - Metoda pro shromaˇzd’ov´an´ı identifikaˇcn´ıch u ´daj˚ u, mezi kter´e patˇr´ı ID uˇzivatele, URL, email a jin´e identifikaˇcn´ı u ´daje, kter´e se mohou vztahovat napˇr. na entity s´ıtˇe. Signal Reconstruction - Metody jsou urˇceny pro zachyt´av´an´ı s´ıt’ov´eho provozu a n´asledn´e extrakce audio, video nebo textov´e informace (rozhovor, hlasov´a zpr´ava, fax, video, text). N´aslednˇe m˚ uˇze b´ yt pouˇzito pro opˇetovnou rekonstrukci dat, z´ısk´av´an´ı osobn´ıch nebo identifikaˇcn´ıch u ´daj˚ u.
ˇ ´ U ˚ OBECNE ˇ KAPITOLA 4. BEZPECNOST VOIP SYSTEM 4.1.5
23
Interception and Modification (Zachyt´ av´ an´ı a modifikace)
Tato tˇr´ıda u ´tok˚ u popisuje metody, pomoc´ı nichˇz m˚ uˇze u ´toˇcn´ık nahl´ıˇzet jak do signalizaˇcn´ıch dat, tak i do dat, kter´a pˇren´aˇs´ı informace a modifikovat je. Call Black Holing - Definuje metody, pomoc´ı kter´ ych u ´toˇcn´ık m˚ uˇze odej´ımat nebo zabr´anit pr˚ uchodu paket˚ u. To m´a za n´asledek pˇreruˇsen´ı komunikace. Call Rerouting - Pˇresmˇerov´an´ı paket˚ u za u ´ˇcelem odklonˇen´ı komunikace. Fax Alteration - Zmˇena dat jak v informaˇcn´ı ˇc´asti, tak ve stavov´e ˇc´asti. Conversation Alteration - Zmˇena audio, video, textov´ ych nebo identifikaˇcn´ıch u ´daj˚ u. ´ Conversation Degrading - Umysln´ e sn´ıˇzen´ı kvality sluˇzeb (QoS) v pr˚ ubˇehu komunikace. Conversation Impersonation and Hijacking - Metoda pro vloˇzen´ı, smaz´an´ı, pˇrid´an´ı nebo zmˇenu jak´ekoliv ˇc´asti komunikace. M˚ uˇze b´ yt pouˇzito i na data, kter´a jsou zapouzdˇrena nebo zak´odov´ana. False Caller Identification - Signalizace nepravdiv´e identifikace uˇzivatele. 4.1.6
Service Abuse (Zneuˇ zit´ı sluˇ zeb)
Jedn´a se o kategorii u ´tok˚ u, kter´e nevhodnˇe pouˇz´ıvaj´ı komunikaˇcn´ı sluˇzby. Call Conference Abuse - Zatajen´ı identity za u ´ˇcelem zneuˇzit´ı VoIP sluˇzeb vol´an´ı. Premium Rate Service (PRS) Fraud - Metoda pro umˇel´e zvyˇsov´an´ı provozu za u ´ˇcelem zv´ yˇsen´ı plateb. Improper Bypass or Adjustment to Billing - Metoda pro vyh´ yb´an´ı se poplatk˚ um, mˇenˇen´ı fakturaˇcn´ıch u ´daj˚ u. 4.1.7
Intentional Interruption of Service (Pˇ reruˇ sen´ı sluˇ zeb)
´ Utoky, kter´e se zamˇeˇruj´ı na pˇreruˇsen´ı sluˇzeb lze rozdˇelit do nˇekolika kategori´ı. 4.1.8
Specific Denial of Service (DoS)
Mnoˇzina u ´tok˚ u, kter´e jsou specifick´e pro urˇcit´e VoIP protokoly nebo samotn´e aplikace. ´ Request Flooding - Utoky, kter´e jsou prov´adˇeny zas´ıl´an´ım velk´eho mnoˇzstv´ı platn´ ych/neplatn´ ych ´ dotaz˚ u. Utoky tohoto druhu mohou v´est k velk´emu vyt´ıˇzen´ı v´ ypoˇcetn´ı kapacity nebo restartu zaˇr´ızen´ı. Malformed Requests and Messages - Nˇekter´e kontroln´ı zpr´avy ve VoIP jsou podle specifikace u ´myslnˇe neukonˇcen´e, aby bylo moˇzn´e pˇrid´avat dodateˇcn´e informace. Stinn´a str´anka t´eto specifikace spoˇc´ıv´a v nemoˇznosti kontrolovat jednak spr´avn´e proveden´ı vˇsech platn´ ych zpr´av, tak i pˇresn´e rozpozn´an´ı neplatn´ ych zpr´av. U platn´ ych, ale rozs´ahl´ ych zpr´av, proto nast´av´a riziko, ˇze mohou b´ yt odstranˇeny.
ˇ ´ U ˚ OBECNE ˇ KAPITOLA 4. BEZPECNOST VOIP SYSTEM
24
QoS Abuse - Tato forma u ´tok˚ u umoˇzn ˇuje u ´toˇcn´ıkovi napadnout vyjedn´av´an´ı o parametrech pˇrenosu pˇri sestavov´an´ı hovoru. To m˚ uˇze zahrnovat napˇr. zmˇenu nastaven´ı zvukov´eho kodeku, zmˇenu portu nebo IP adresu pˇr´ıjemce. Spoofed Messages - Jedn´a se u ´tok, kter´ y umoˇzn ˇuje vloˇzen´ı faleˇsn´e signalizaˇcn´ı zpr´avy do toku zpr´av tak, ˇze pˇr´ıjemce pˇrijme tuto zpr´avu jako platnou. U tˇechto u ´tok˚ u b´ yv´a ˇcast´e napˇr. vloˇzen´ı zpr´avy pro ukonˇcen´ı hovoru nebo zpr´avy typu BUSY. Call Hijacking - Pˇri oslaben´ı zabezpeˇcen´ı je syst´em n´achyln´ y na u ´toky, pˇri kter´ ych jsou zcizena data mezi jednotliv´ ymi koncov´ ymi body VoIP s´ıtˇe. Mezi tyto data mohou patˇrit jak signalizaˇcn´ı u ´daje, tak pˇren´aˇsen´a medi´aln´ı data. V´ ysledkem m˚ uˇze b´ yt, ’ ˇze obˇet nebude schopna dos´ahnout sluˇzeb s´ıtˇe. 4.1.9
Loss of Power
Jedn´a se o u ´toky, kter´e se soustˇred´ı na odpojen´ı syst´emu od dod´avky energie. Na obranu proti tomuto druhu u ´toku je vhodn´e instalovat zdroj z´aloˇzn´ıho nap´ajen´ı nebo jinak zabezpeˇcenou dod´avku energie. 4.1.10
Resource Exhaustion
Zamˇeˇruj´ı se na vyt´ıˇzen´ı v´ ypoˇcetn´ıch prostˇredk˚ u zaˇr´ızen´ı. M˚ uˇze se jednat o pamˇet’ov´e vyt´ıˇzen´ı, vyt´ıˇzen´ı CPU nebo zat´ıˇzen´ı s´ıtˇe a t´ım zmenˇsen´ı ˇs´ıˇrky p´asma. 4.1.11
Performance Latency
Dot´ yk´a se jak signalizaˇcn´ıch tak i medi´aln´ıch dat, kde se m˚ uˇze projevit ztr´ata paket˚ u, latence nebo promˇenn´e zpoˇzdˇen´ı paket˚ u. Aby byla komunikace provozu schopn´a, nemˇela by latence pˇres´ahnou dobu 200 ms, jitter by mˇelo b´ yt menˇs´ı jak 25 ms a mnoˇzstv´ı ztracen´ ych paket˚ u by nemˇelo b´ yt vetˇs´ı jak 5. 4.1.12
Physical Intrusion (Fyzick´ e napojen´ı)
Fyzick´e napojen´ı m˚ uˇze vyˇzadovat pˇrekon´an´ı fyzick´e obrany jako jsou bezpeˇcnostn´ı syst´emy, z´amky. K tomuto druhu napaden´ı lze pˇriˇradit u ´tok na zaˇr´ızen´ı nebo firmy, kter´e poskytuj´ı silov´e sluˇzby, napojen´ı na datov´e vodiˇce (bezdr´atov´e spojen´ı, optick´e linky).
4.2
SPIT - VoIP Spam
VoIP spam je rozˇs´ıˇren´ı neˇz´adouc´ıch, automaticky vyt´aˇcen´ ych, nahran´ ych telefonn´ıch hovor˚ u vyuˇzit´ım technologie VoIP. VoIP spam se oznaˇcuje zkratou SPIT(Spam over Internet Telephony). VoIP syst´emy, podobnˇe jako e-mail a dalˇs´ı internetov´e aplikace jsou citliv´e k zneuˇzit´ı ze tˇret´ıch stran, kter´e dok´aˇzou prov´adˇet nevyˇz´adan´e hovory. Tele prodejci a dalˇs´ı r˚ uzn´e syst´emy vyuˇz´ıvaj´ıc´ı telekomunikaˇcn´ı sluˇzby r´adi vyuˇz´ıvaj´ı VoIP pro zv´ yˇsen´ı zisk˚ u. SPIT je k tomu pˇr´ımo ide´aln´ı, jelikoˇz n´aklady na provoz jsou t´emˇeˇr nulov´e.
ˇ ´ U ˚ OBECNE ˇ KAPITOLA 4. BEZPECNOST VOIP SYSTEM
25
Z´akladn´ım protokolem, kter´ y b´ yv´a zneuˇzit pro SPIT je SIP. SIP je dnes nejrozˇs´ıˇrenˇejˇs´ı VoIP protokol, jak uˇz bylo zm´ınˇeno v pˇredchoz´ach kapitol´ach. SIP pouˇz´ıv´a stejn´ y form´at kontaktu jako e-mail, a proto je pro SPIT pˇr´ımo ide´aln´ı. Lze pˇredpokl´adat, ˇze pravidla, kter´ ymi se lze br´anit SPAMu, budou u ´ˇcinn´a a na obranu proti SPITu obr.4.1.
Obr´azek 4.1: Moˇznost obrany proti SPITu
SIP byl navrˇzen tak, aby podporoval jednoduch´e zjiˇstˇen´ı dostupnosti u ´ˇcastn´ıka. Bohuˇzel to tak´e znamen´a, ˇze volaj´ıc´ı bude jiˇz pˇredem zn´at, zda je u ´ˇcastn´ık dostupn´ y a v pˇr´ıpadˇe ˇze ano, pokus´ı se jej kontaktovat, napˇr v 03 : 00 r´ano. Testovac´ı program pro generov´an´ı SPITu 1 byl vyvinut skupinou Black Hat. Jeho pouˇzit´ı je pouze na vlastn´ı zodpovˇednost, dle pˇriloˇzen´e licence. SPIT je jedn´ım z dalˇs´ıch velk´ ych bezpeˇcnostn´ıch probl´emu dneˇsn´ıho internetu. Vzhledem k velikosti a n´aroˇcnosti ˇreˇsen´ı probl´emu, nebude mu v pr´aci jiˇz d´ale vˇenov´ana pozornost.
4.3
Bezpeˇ cnostn´ı z´ avˇ er
Jak vypl´ yv´a z n´azvu kapitoly, moˇznost´ı, jak vyzkouˇset odolnost syst´emu, je opravdu velk´e mnoˇzstv´ı. Z hlediska oper´atora jsou nejv´ yznamˇejˇs´ı u ´toky typu Registration spoofing/hijacking, Toll Fraud a DoS. Kaˇzd´ y z tˇechto u ´tok˚ u m´a jin´ y dopad. Registration hijacking a Toll Fraud maj´ı za n´asledek, ˇze opr´avnˇen´ y uˇzivatel nen´ı schopen telefonovat a v nejhorˇs´ım pˇr´ıpadˇe mu k jeho u ´ˇctu pˇribude p´ar dalˇs´ıch, jistˇe velmi drah´ ych hovor˚ u. Prok´azat, ˇze hovory nejsou vaˇse nen´ı nic jednoduch´eho. Po DoS u ´toku z˚ ust´av´a syst´em nefunkˇcn´ı, coˇz v nˇekter´ ych pˇr´ıpadech m˚ uˇze v´est k hromadn´ ym ˇzalob´am, a to m˚ uˇze v´est aˇz ke krachu oper´atora. Tˇret´ım v poˇrad´ı je odposlech hovor˚ u, kter´ y m˚ uˇze do probl´em˚ u dostat samotn´e uˇzivatele. ˇ Zkuste zavolat disident˚ um do C´ıny a mluvit s nimi o lidsk´ ych pr´avech. 1
http://www.hackingvoip.com/tools/spitter.tar.gz
26
ˇ ´ U ˚ OBECNE ˇ KAPITOLA 4. BEZPECNOST VOIP SYSTEM
Ochrana proti v´ yˇse zm´ınˇen´ ym u ´tok˚ um je zajist´e moˇzn´a, vˇenuje se j´ı n´asleduj´ıc´ı kapitola. Vˇseobecn´ ym doporuˇcen´ım z˚ ust´av´a pravideln´a aktualizace syst´emu, firewall, antivirov´ ya antispyware software.
´ ´I BEZPECNOSTN ˇ ´I PROTOKOLY KAPITOLA 5. UNIVERZALN
27
5 Univerz´ aln´ı bezpeˇ cnostn´ı protokoly Moˇznost´ı ochrany dat proti zneuˇzit´ı je velk´e mnoˇzstv´ı. Pˇri pouˇzit´ı bezpeˇcnostn´ıch protokol˚ u, rozliˇsujeme jednotliv´e protokoly t´ım, s kterou s´ıt’ovou vrtsvou pracuj´ı. Protokoly TLS, SSL zabezpeˇcuj´ı pˇrenos pouze pro konkretn´ı aplikaci pˇres nezabezpeˇcen´e m´edium, zat´ımco protokoly IPSec, VPN, openVPN zajist’uj´ı bezpeˇcn´ y pˇrenos pro vˇsechny pakety, jelikoˇz pracuji na niˇzˇs´ı, s´ıt’ov´e (3.) vrstvˇe. Dalˇs´ı bezpeˇcnostn´ı prvky jsou VoIP firewally a NIPS syst´emy. VoIP firewall je rozˇs´ıˇren´ım klasick´eho firewallu a umoˇzn ˇuje vyuˇzit´ı RTP. NIPS chr´an´ı syst´em proti D-DoS u ´tok˚ um. VoIP firewall ani NIPS se nestaraj´ı o vlastn´ı zabezpeˇcen´ı dat, pˇresto jsou velmi d˚ uleˇzit´ ym prvkem ve VoIP intrastruktuˇre.
5.1
TLS Transport Layer Security
Protokol Transport Layer Security (TLS) [27] [2] a jeho pˇredch˚ udce, Secure Sockets Layer (SSL), jsou kryptografick´e protokoly, poskytuj´ıc´ı moˇznost zabezpeˇcen´e komunikace na Internetu pro sluˇzby jako WWW, elektronick´a poˇsta, internetov´ y fax a dalˇs´ı datov´e pˇrenosy. Mezi protokoly SSL 3.0 a TLS 1.0 jsou drobn´e rozd´ıly, ale v z´asadˇe jsou stejn´e. Zde pouˇzit´ y term´ın TLS se t´ yk´a obou dvou, pokud nen´ı z kontextu zˇrejm´ y opak. Protokol(y) TLS umoˇzn ˇuj´ı aplikac´ım komunikovat po s´ıti zp˚ usobem, kter´ y zabraˇ nuje odposlouch´av´an´ı ˇci falˇsov´an´ı zpr´av. Pomoc´ı kryptografie poskytuje TLS sv´ ym koncov´ ym bod˚ um autentizaci a soukrom´ı pˇri komunikaci Internetem. Typicky je autentizov´an pouze server (tedy jeho totoˇznost je zaruˇcena), zat´ımco klient z˚ ust´av´a neautentizov´an. To znamen´a, ˇze koncov´ y uˇzivatel (at’ ˇclovˇek ˇci aplikace, jako tˇreba webov´ y prohl´ıˇzeˇc) si m˚ uˇze b´ yt jist s k´ ym komunikuje. Dalˇs´ı u ´roveˇ n zabezpeˇcen´ı – pˇri n´ıˇz oba u ´ˇcastn´ıc´ı hovoru maj´ı jistotu s k´ ym komunikuj´ı – je oznaˇcov´ana jako vz´ajemn´a autentizace. Vz´ajemn´a autentizace vyˇzaduje nasazen´ı infrastruktury veˇrejn´ ych kl´ıˇc˚ u (PKI) pro klienty. TLS zahrnuje tˇ ri z´ akladn´ı f´ aze: 1. dohodu u ´ˇcastn´ık˚ u na podporovan´ ych algoritmech 2. v´ ymˇenu kl´ıˇc˚ u zaloˇzenou na ˇsifrov´an´ı s veˇrejn´ ym kl´ıˇcem a autentizaci vych´azej´ıc´ı z certifik´at˚ u 3. ˇsifrov´an´ı provozu symetrickou ˇsifrou Bˇehem prvn´ı f´aze se klient a server dohodnou na pouˇz´ıvan´ ych kryptografick´ ych algoritmech. Souˇ casn´ e implementace podporuj´ı n´ asleduj´ıc´ı moˇ znosti: • pro kryptografii s veˇrejn´ ym kl´ıˇcem: RSA, Diffie-Hellman, DSA • pro symetrick´e ˇsifrov´an´ı: RC2, RC4, IDEA, DES, Triple DES, AES, Camellia • pro jednosmˇern´e heˇsov´an´ı: Message-Digest algorithm (MD2, MD4, MD5), Secure Hash Algorithm (SHA-1, SHA-2)
´ ´I BEZPECNOSTN ˇ ´I PROTOKOLY KAPITOLA 5. UNIVERZALN
28 5.1.1
Bezpeˇ cnost
TLS zahrnuje ˇradu bezpeˇcnostn´ıch opatˇren´ı: • Klient pouˇz´ıv´a veˇrejn´ y kl´ıˇc CA k ovˇeˇren´ı jej´ıho podpisu v serverov´em certifik´atu. Lze-li digit´aln´ı podpis CA ovˇeˇrit, klient pˇrijme serverov´ y certifik´at jako platn´ y certifik´at vydan´ y d˚ uvˇeryhodnou CA. • Klient ovˇeˇruje, zda je vyd´avaj´ıc´ı certifikaˇcn´ı autorita na seznamu d˚ uvˇeryhodn´ ych CA. • Klient kontroluje dobu ˇzivotnosti serverov´eho certifik´atu. Autentizaˇcn´ı proces se zastav´ı, pokud doba jeho platnosti vyprˇsela. • K ochranˇe pˇred u ´toky typu Man-in-the-Middle porovn´av´a klient aktu´aln´ı DNS jm´eno serveru se jm´enem z certifik´atu. • Ochrana pˇred nˇekolika zn´am´ ymi u ´toky (vˇcetnˇe man-in-the-middle), jako je snaha o pouˇzit´ı niˇzˇs´ı (m´enˇe bezpeˇcn´e) verze protokolu nebo slabˇs´ıho ˇsifrovac´ıho algoritmu. • Opatˇren´ı vˇsech aplikaˇcn´ıch z´aznam˚ u poˇradov´ ymi ˇc´ısly a pouˇz´ıv´an´ı tˇechto ˇc´ısel v MAC. • Pouˇz´ıv´an´ı ovˇeˇrovac´ıho k´odu zpr´avy rozˇs´ıˇren´eho o kl´ıˇc, takˇze jen vlastn´ık kl´ıˇce dok´aˇze MAC ovˇeˇrit. Definov´ano v RFC 2104. Jen v TLS. • Zpr´ava ukonˇcuj´ıc´ı inicializaci (Finished) obsahuje hash vˇsech zpr´av vymˇenˇen´ ych v r´amci inicializace obˇema stranami. • Pseudon´ahodn´a funkce rozdˇeluje vstupn´ı data na poloviny a zpracov´av´a kaˇzdou z nich jin´ ym hashovac´ım algoritmem (MD5 a SHA-1), pak je XORuje dohromady. To poskytuje ochranu, pokud by byla nalezena slabina jednoho z algoritm˚ u. Jen v TLS. • SSL v3 je proti SSL v2 vylepˇseno pˇrid´an´ım ˇsifer zaloˇzen´ ych na SHA-1 a podporou autentizace certifik´aty. Dalˇs´ı vylepˇsen´ı SSL v3 zahrnuj´ı lepˇs´ı inicializaˇcn´ı protokol a vyˇsˇs´ı odolnost proti u ´tok˚ um typu man-in-the-middle.
5.2
IPsec
Ipsec (IP security) [4] je soubor protokol˚ u pro bezpeˇcnou komunikaci prostˇrednictv´ım IP protokol˚ u pomoc´ı autentizac´ı a kryptov´an´ı kaˇzd´eho paketu v datov´em toku. IPsec tak´e obsahuje sadu protokol˚ u pro stanoven´ı kryptografick´ ych kl´ıˇc˚ u. ’ IPsec protokoly pracuj´ı na s´ıt ov´e (tˇret´ı) vrstvˇe OSI modelu. Dalˇs´ı rozˇs´ıˇren´e internetov´e bezpeˇcnostn´ı protokoly jako SSH, SSL nebo TLS pracuj´ı se ˇctvrtou transportn´ı vrstvou OSI modelu. Dan´a vlastnost ˇcin´ı IPsec velmi flexibiln´ım, a proto je vhodn´ y pro ochranu protokol˚ u ˇctvrt´e vrstvy, vˇcetnˇe UDP a TCP, jakoˇzto nejrozˇs´ıˇrenejˇs´ıch internetov´ ych protokol˚ u. Hlavn´ı v´ yhodou IPsecu oproti ostatn´ım protokol˚ um vyˇsˇs´ıch vrstev je to, ˇze aplikace vyuˇz´ıvaj´ıc´ı IPsec nemus´ı b´ yt naprogramovan´e pro vyuˇzit´ı IPsecu jako kryptovac´ıho protokolu aˇckoliv SSH nebo jin´e protokoly jsou v aplikac´ıch implementovan´e.
´ ´I BEZPECNOSTN ˇ ´I PROTOKOLY KAPITOLA 5. UNIVERZALN
29
IPsec je tedy implementov´an jako sada kryptografick´ ych protokol˚ u pro zabezpeˇcen´ı datov´eho toku, vz´ajemn´e autentizace a stanoven´ı kryptografick´ ych parametr˚ u. Architektura IPsecu vyuˇz´ıv´a koncept pro zabudov´an´ı bezpeˇcnostn´ıch fc´ı do IP. Zabezpeˇcovac´ı asociace je soubor algoritm˚ u a parametr˚ u (kl´ıˇce), kter´e jsou pouˇzity pro zak´odov´an´ı, autentizaci v jednom smˇeru toku. Pˇri klasick´em obousmˇern´em provozu je provoz zabezpeˇcen prostˇrednictv´ım p´ar˚ u zabezpeˇcovac´ıch asociac´ı. Vlastn´ı v´ ybˇer zp˚ usobu zabezpeˇcen´ı je dnes ponech´an na administr´atorovi syst´emu. IPsec pracuje ve 2 m´ odech: transportn´ı a tunelov´ y • Transportn´ı m´od V transportn´ım m´odu jsou kryptov´ana pouze data (payload) z IP paketu. Transportn´ı m´od je vyuˇz´ıv´an pro host - to - host komunikaci. • Tunelov´ y m´od V tunelov´em m´odu se kryptuj´ı jak data, tak IP hlaviˇcka paketu. Vyuˇz´ıv´a se pro bezpeˇcnou komunikaci mezi s´ıtˇemi (network-to-network).
5.3
VPN - Virtual private network
VPN (anglicky virtual private network) [2] je prostˇredek pro propojen´ı nˇekolika poˇc´ıtaˇc˚ u na r˚ uzn´ ych m´ıstech internetu do jedin´e virtu´aln´ı poˇc´ıtaˇcov´e s´ıtˇe. I kdyˇz poˇc´ıtaˇce mohou b´ yt v naprosto fyzicky nez´avisl´ ych s´ıt´ıch na r˚ uzn´ ych m´ıstech svˇeta, prostˇrednictv´ım virtu´aln´ı priv´atn´ı s´ıtˇe mezi sebou mohou komunikovat, jako by byly na jedin´em s´ıt’ov´em segmentu. Prostˇrednictv´ım VPN lze zajistit napˇr´ıklad pˇripojen´ı firemn´ıch notebook˚ u kdekoliv na internetu do firemn´ıho intranetu (vnitˇrn´ı firemn´ı s´ıtˇe). K propojen´ı je tˇreba VPN server, kter´ y m´a pˇr´ıstup na internet i intranet (m˚ uˇze slouˇzit pouze pro jednoho klienta, nebo slouˇzit jako hub a pˇrij´ımat spojen´ı od v´ıce klient˚ u), a VPN klient, kter´ y se pˇres internet pˇripoj´ı k serveru a prostˇrednictv´ım nˇej pak do intranetu. VPN server pak pln´ı v podstatˇe funkci s´ıt’ov´e br´any. Zobecnˇen´ım VPN je s´ıt’ov´e tunelov´an´ı, kdy se prostˇrednictv´ım standardn´ıho s´ıt’ov´eho spojen´ı vytvoˇr´ı virtu´aln´ı linka mezi dvˇema poˇc´ıtaˇci, v r´amci kter´e pak lze nav´azat dalˇs´ı s´ıt’ov´a spojen´ı. 5.3.1
OpenVPN
OpenVPN [2] je open source variantou pro vytvoˇren´ı point-to-point ˇsifrovan´eho tunelu mezi hostitelsk´ ymi poˇc´ıtaˇci. OpenVPN je odlehˇcenou variantou VPN, design je odprostˇen od spousty komplikovanost´ı, kter´e jsou charakteristick´e pro dalˇs´ı VPN implementace. OpenVPN bezpeˇcnostn´ı model je zaloˇzen na protokolu SSL. OpenVPN pracuje na druh´e a tˇret´ı vrstvˇe ISO modelu a d´ale s vyuˇzit´ım SSL/TLS podporuje autentizaˇcn´ı metody pro klienty prostˇrednictv´ım certifik´at˚ u, ˇcipov´ ych karet nebo 2 faktorov´ ych autentizac´ı a umoˇzn ˇuje jednomu ˇci skupinˇe uˇzivatel˚ u specifick´ y pˇr´ıstup dan´ y omezen´ım firewallu na VPN rozhran´ı.
30
´ ´I BEZPECNOSTN ˇ ´I PROTOKOLY KAPITOLA 5. UNIVERZALN
Obr´azek 5.1: Architektura VoIP VPN s´ıtˇe
5.4
VoIP VPN
VoIP VPN je kombinac´ı VoIP a VPN technologie tak, aby nab´ıdla bezpeˇcnou komunikaci [10] [2]. Vzhledem k tomu, ˇze VoIP pˇren´aˇs´ı digitalizovanou formu hlasu jako tok dat, pomoc´ı VoIP VPN prob´ıh´a ˇsifrov´an´ı hlasu velmi jednoduˇse, aplikac´ı standardn´ıch kryptovac´ıch mechanism˚ u, kter´e jsou k dispozici v protokolech VPN. Architekturu a pouˇzit´ı VoIP VPN s´ıtˇe ukazuje obr. 5.1. Gateway-router nejdˇr´ıve pˇrevede analogov´ y hlasov´ y sign´al na digit´aln´ı, zapouzdˇr´ı do IP paketu a d´ale ˇsifruje pomoc´ı IPsec. Nakonec je paket smˇerov´an pomoc´ı VPN tunelu. Na vzd´alen´e stranˇe s´ıtˇe dalˇs´ı VoIP router pˇrevad´ı digit´aln´ı sign´al na analogov´ y aby mohl b´ yt pˇrijat dan´ ym telefonem. Dalˇ s´ı v´ yhody: Bezpeˇcnost nen´ı jedinn´ ym d˚ uvodem pro pr˚ uchod dat skrz VPN. SIP protokol je notoricky zn´am´ y sv´ ym probl´emov´ ym pr˚ uchodem skrz firewall, protoˇze nen´ı standardem urˇceno, kter´e porty vyuˇz´ıvat pro spojen´ı. VoIP VPN je jedno z ˇreˇsen´ıch jak tyto probl´emy obej´ıt, jelikoˇz VPN virtu´alnˇe pˇresouv´a uˇzivatele na stejnou s´ıt’ jako je VoIP server.
5.5 5.5.1
Ochrana pro hraniˇ cn´ı prvky VoIP firewall a SIP firewall
Jeˇstˇe velk´e mnoˇzstv´ı dneˇsn´ıch firewall˚ u nedok´aˇze spr´avnˇe pracovat se SIP protokolem. Stejn´e probl´emy nast´avaj´ı i u protokolu H.323, kdy potˇrebujeme kontaktovat osobu na priv´atn´ı s´ıti. D˚ uvod, proˇc je tomu tak, je velmi prost´ y. Firewally pro tento typ provozu jednoduˇse nejsou implementovan´e. VoIP firewally [10] jsou stejn´e jako ostatn´ı firewally, ale jsou pˇrizp˚ usobeny na ochranu dat hlasov´ ych sluˇzeb. Pˇred zaˇz´atkem hovoru nen´ı jasn´e, pˇres kter´ y port se hovor uskuteˇcn´ı. Domluva o dan´em portu prob´ıh´a aˇz po signalizaˇcn´ı ˇc´asti hovoru a star´a se o ni protokol SDP. VoIP firewall se tedy postar´a a vˇcasn´e otevˇren´ı dan´eho portu a po ukonˇcen´ı hovoru o jeho opˇetovn´e uzavˇren´ı. VoIP firewall lze pouˇz´ıt nejen jako vnitˇrn´ı podnikov´ y firewall, ale tak´e jako klasick´ y firewall pro bˇeˇzn´ y provoz + pro VoIP provoz. SIP firewall je jiˇz konkr´etn´ım ˇreˇsen´ım dan´eho probl´emu, pr´avˇe pro protokol SIP.
´ ´I BEZPECNOSTN ˇ ´I PROTOKOLY KAPITOLA 5. UNIVERZALN 5.5.2
31
NIPS and NIDS
Network intrusion detection system (NIDS) [2] slouˇz´ı pro zachyt´av´an´ı z´akeˇrn´ ych (malicious) aktivit, jedn´a se o detekce DoS u ´tok˚ u, port scan a dalˇs´ı aktivity, kter´e by mohly ohrozit chod syst´emu. Je analyzov´an kaˇzd´ y paket na s´ıt’ov´em rozhran´ı a dle obsahu identifikov´an na z´akladˇe pˇredem napsan´ ych pravidel. NIDS nen´ı omezen pouze na kontrolu pˇr´ıchoz´ıch paket˚ u. Dalˇs´ı velmi cenn´e informace lze z´ıskat z anal´ yzy odchoz´ıch paket˚ u nebo z anal´ yzy toku po m´ıstn´ı priv´atn´ı s´ıti. Obvykl´a je tak´e spolupr´ace s dalˇs´ımi syst´emy napˇr. IPtables. Network intrusion prevention system (NIPS) narozd´ıl od NIDS nejen ˇze dok´aˇze sledovat provoz, ale v pˇr´ıpadˇe nebezpeˇc´ı dok´aˇze dan´ y paket zahodit dˇr´ıve, neˇz m˚ uˇze nˇeco zp˚ usobit. Typick´ ym pˇr´ıkladem je blokov´an´ı pˇr´ıloh v emailech s koncovkou .exe. NIPS byl dˇr´ıve ch´ap´an jako rozˇs´ıˇren´ı NIDS, v dneˇsn´ı dobˇe se o nˇem mluv´ı jako o dalˇs´ım monitorovac´ım syst´emu. V mnoha pˇr´ıpadech jsou vˇsak dan´e technologie komplement´arn´ı.
5.6
Obecn´ a doporuˇ cen´ı
1. Vytvoˇren´ı vhodn´e architektury s´ıtˇe. • vyuˇ z´ıt VLAN na oddˇ elen´ı s´ıt´ı pro pˇ renos hlasu a pˇ renos dat • zapnout autorizaci na vˇsech prvc´ıch infrastruktury • m´ısto protokolu UDP pouˇz´ıvat TCP protokol, pˇr´ıp TLS • sn´ıˇz´ıt interval mezi registracemi • zmˇenit vˇsechna pˇreddefinovan´a hesla • zaˇclenit do infrastruktury VoIP firewall, NIDS detektory pro odhalen´ı moˇzn´eho nebezpeˇc´ı • pro vzd´alen´ y pˇristup vyuˇz´ıvat IPsec, SSH atd • vypnout sluˇzby, kter´e nejsou nutn´e pro bˇeh s´ıtˇe • pravidelnˇe stahovat bezpeˇcnostn´ı aktualizace 2. opatˇren´ı vhodn´a pro VoIP telefony • zmˇenit pˇreddefinovan´a hesla, zruˇsit neautorizovan´e u ´ˇcty • vypnout vˇsechny nepotˇrebn´e sluˇzby(telnet, SNMP atd) • pravideln´e upgradovat firmaware • uzavˇr´ıt nepotˇrebn´e porty • zak´azat moˇznost debugov´an´ı odhalen´ı moˇzn´eho nebezpeˇc´ı 3. Pˇri vyuˇzit´ı novinek sledovat v´ yvoj tˇechto aplikac´ı, zejm´ena se soustˇredit na odhalen´a bezpeˇcnostn´ı rizika. 4. Povolit pˇr´ıstup pouze platn´ ym uˇzivatel˚ um - zapnout port security, zak´azat automatick´e pˇridˇelen´ı IP adresy prostˇrednictv´ım DHCP. 5. Softwarov´e telefony nepouˇz´ıvat pro d˚ uvˇern´e hovory. Prostˇrednictv´ ym softwarov´ ych telefon˚ u se ˇcasto ˇs´ıˇr´ı r˚ uzn´ı ˇcervy, viry, proti kter´ ym je velmi sloˇzit´e se br´anit.
´ ´I BEZPECNOSTN ˇ ´I PROTOKOLY KAPITOLA 5. UNIVERZALN
32
TLS d˚ uvˇernost ano autentiˇcnost ano integrita ano D-DoS ochrana ne filtrov´an´ı paket˚ u ne
IPSec VPN openVPN VoIP firewall NIPS ano ano ano ne ne ano ano ano ne ne ano ano ano ne ne ne ne ne ano ano ne ne ne ano ano
Tabulka 5.1: Srovn´an´ı bezpeˇcnostn´ıch protokol˚ u a dalˇs´ıch bezpeˇcnostn´ıch moˇznost´ı 6. V bezdr´atov´e s´ıt´ı vyuˇz´ıt WPA m´ısto WEP. Pro deˇsifrov´an´ı WEP existuje velk´a spousta volnˇe dostupn´ ych n´astroj˚ u. I pro nezkuˇsen´eho hackera je vˇse ot´azkou jedn´e hodiny, neˇz dok´aˇze prolomit WEP ochranu. WPA poskytuje mnohem vˇetˇs´ı ochranu narozd´ıl od WEP, pˇresto jsou uˇz zn´amy nˇekter´e techniky, kter´e zvl´ad´aj´ı prolomen´ı WPA ˇsifrov´an´ı. 7. Zapojit z´aloˇzn´ı zdroj nap´ajen´ı, vytvoˇrit sc´en´aˇr jak se zachovat pˇri v´ ypadku proudu.
5.7
Srovn´ an´ı moˇ znost´ı a z´ avˇ er
Jak jiˇz bylo nˇekolikr´at zm´ınˇeno, je d˚ uleˇzit´e zohlednit, na jak´e s´ıt’ov´e vrstvˇe zabezpeˇcujeme data, jak´ y prvek VoIP s´ıtˇe zabezpeˇcujeme a co chceme zabezpeˇcit tab 5.1. Z hlediska koncov´eho u ´ˇcastn´ıka je pro zabezpeˇcen´ı CIA nejvhodnˇejˇs´ı TLS protokol. Velk´ ym probl´emem st´ale z˚ ust´av´a zabezpeˇcen´ı po cel´e trase dat (end to end security - E2E). Protokol TLS je pouˇzit na sv´e cestˇe pouze k prvn´ımu proxy serveru a odtud dalˇs´ı zabezpeˇcen´ı z´avis´ı pr´avˇe na dan´em proxy serveru. Moˇznostem, kter´e umoˇzn ˇuj´ı E2E se vˇenuji v dalˇs´ıch kapitol´ach. Protokol TLS je vyuˇzit pro zabezpeˇcen´ı signalizace. Pro bezpeˇcn´ y pˇrenos hlasu existuj´ı dalˇs´ı protokoly, kter´ ym se vˇenuji v dalˇs´ı kapitole. ˇ sen´ı typu IPSec nebo VPN je vhodn´e pro propojen´ı v´ Reˇ yznamn´ ych s´ıt’ov´ ych prvk˚ u, jako jsou GWs. Jak´e ˇreˇsen´ı je vhodn´e pro dan´ y protokol je uvedeno v dalˇs´ı kapitole. VoIP firewall se vyuˇz´ıv´a zejm´ena z d˚ uvodu ochrany server˚ u a koncov´ ych u ´ˇcastn´ık˚ u, odstraˇ nuje nev´ yhody klasick´eho firewallu ve VoIP telefonii. D´ale VoIP VPN umoˇzn ˇuje tak´e vyˇreˇsit probl´emy s firewallem a nav´ıc zabezpeˇc´ı, ˇze se data budou pos´ılat pouze v prostˇred´ı firemn´ı s´ıtˇe. NIPS syst´emy dok´aˇz´ı informovat a ochr´anit syst´em pˇred u ´toky typu D-DoS. Jejich pouˇzit´ı ve IP telefonii je zat´ım jen v poˇc´atc´ıch a dle m´ ych pˇredpoklad˚ u maj´ı velkou budoucnost. V´ıce v dalˇs´ıch kapitol´ach.
ˇ ´I SIGNALIZACN ˇ ´ICH PROTOKOLU ˚ KAPITOLA 6. ZABEZPECEN
33
6 Zabezpeˇ cen´ı signalizaˇ cn´ıch protokol˚ u 6.1
Zabezpeˇ cen´ı signalizace SIPu
Protokol SIP je textov´eho tvaru. Vzhledem k tomu, ˇze SIP je velmi podobn´ y protokolu HTTP a jeho modelu request/response, lze na nˇej uplatnit bezpeˇcnostn´ı mechanismy, kter´e jsou dostupn´e pro protokol HTTP [18] [12] [23].
• HTTP Basic Authentication Tato metoda zajiˇst’uje pouze autentizaci uˇzivatele na z´akladˇe sd´ılen´eho hesla. Pˇri pˇrenosu identifikaˇcn´ıch u ´daj˚ u nen´ı pouˇzita ˇz´adn´a ˇsifrovac´ı metoda, data jsou pouze zak´odov´ana. Nen´ı zajiˇstˇena tak´e integrita zpr´avy. Zabezpeˇcen´ı pomoc´ı t´eto metody nen´ı doporuˇcov´ano.
• HTTP Digest Authentication Digest Authentication stav´ı na metodˇe Basic Authentication, ale m´ısto pˇrenosu hesla v otevˇren´e podobˇe se vyuˇz´ıv´a hash funkce MD5, kter´a se vytvoˇr´ı z n´ahodnˇe vygenerovan´eho ˇretˇezce, loginu a hesla. Pˇri pouˇzit´ı slab´eho hesla m˚ uˇze nastat bezpeˇcnostn´ı probl´em s u ´toky pomoc´ı slovn´ıku. Tato metoda umoˇzn ˇuje ovˇeˇren´ı autentiˇcnosti na z´akladˇe sd´ılen´eho hesla, nezav´ad´ı ˇz´adnou metodu pro ˇsifrov´an´ı obsahu zpr´avy ani pro zajiˇstˇen´ı integrity.
• Secure MIME (S/MIME) Secure MIME definuje mechanismy, kter´e zabezpeˇc´ı obsah MIME zpr´avy a zajist´ı jej´ı integritu, d˚ uvˇernost a ovˇeˇren´ı. Pouˇz´ıvaj´ı se pˇritom dva typy obsahu MIME: application/pkcs7-mime a mulit-part/signed. Prvn´ı jmenovan´a metoda dok´aˇze digit´alnˇe podepsat a tak´e zaˇsifrovat pˇren´aˇsen´a data. Druh´a metoda, multipart/signed, je obdobn´a jako application/pkcs7-mime, ale zpr´ava sest´av´a souˇcasnˇe z ˇsifrovan´ ych a neˇsifrovan´ ych dat. Autentizace je doc´ıleno pouˇzit´ım architektury veˇrejn´ ych kl´ıˇc˚ u (PKI). Pro utajen´ı obsahu zpr´avy se pouˇz´ıvaj´ı symetrick´e kryptografick´e primitivy (DES, 3DES, AES).
• SIPS URI (TLS) Pouˇzit´ım SIPS se zmˇen´ı prefix identifikaˇcn´ı hlaviˇcky na sips. Tato metoda pouˇz´ıv´a ˇsifrovan´ y protokol Transport Layer Security (TLS), kter´ y zajist´ı zabezpeˇcenou komunikaci. Tento mechanismus je zaloˇzen na architektuˇre veˇrejn´ ych kl´ıˇc˚ u (PKI). Pouˇz´ıv´a asymetrick´e ˇsifrov´an´ı (RSA), symetrick´e algoritmy (RC4, IDEA, DES, 3DES, AES) a hashovac´ı funkce MD5 a SHA1. Pouˇzit´ı SIPS vyˇzaduje, aby TLS bylo pouˇzito v pr˚ ubˇehu cel´e cesty (hop-by-hop) a aby byl jako transportn´ı protokol pro SIP pouˇzit protokol TCP. Tento zp˚ usob zajiˇst’uje autentiˇcnost, d˚ uvˇernost a tak´e integritu pˇren´aˇsen´eho obsahu zpr´avy.
ˇ ´I SIGNALIZACN ˇ ´ICH PROTOKOLU ˚ KAPITOLA 6. ZABEZPECEN
34
SIP Basic auth. Digest auth. S/Mime SIPS(TLS) d˚ uvˇernost DES, 3DES, AES ano - dle TLS autentiˇcnost sd´ılen´e heslo MD5 PKI RSA, PKI integrita ano - dle TLS E2E nutno zabezpeˇcit vyuˇzit´ı autorizace autorizace signalizace signalizace doporuˇcuje se pouˇz´ıt ne ano ano - zastaral´e ano Tabulka 6.1: Moˇznosti zabezpeˇcen´ı protokolu SIP 6.1.1
Shrnut´ı bezpeˇ cnostn´ıch moˇ znosti SIPu
Digest authentication je tedy vhodn´e vyuˇz´ıt pro autorizaci. Vzhledem k tomu, ˇze tato metoda nezabezpeˇcuje signalizaci, je TLS jedinou vhodnou moˇznost´ı, jak u ´plnˇe zabezpeˇcit SIP zpr´avy pro zajiˇstˇen´ı CIA. Zabezpeˇcen´ı cel´eho obsahu je d˚ uleˇzit´e napˇr. pro v´ ymˇenu kl´ıˇc˚ u pˇri sestavov´an´ı hovoru. Pouˇzit´ı TLS je vhodn´e jak pro koncov´e u ´ˇcastn´ıky, tak pro projen´ı mezi jednotliv´ ymi proxy servery. Probl´emem z˚ ust´av´a zajiˇstˇen´ı zabezpeˇcen´ı po cel´e d´elce cesty. To mus´ı b´ yt ˇreˇseno individu´alnˇe mezi kaˇzd´ ymi dvˇema prvky SIP architektury.
6.2
H.323
Standard H.323 m´a bezpeˇcnostn´ı mechanismy definovan´e pomoc´ı protokolu H.235, kter´ y definuje nˇekolik bezpeˇcnostn´ıch profil˚ u, kter´e zav´ad´ı r˚ uzn´e u ´rovnˇe zabezpeˇcen´ı, jeˇz lze pouˇz´ıt na protokoly z rodiny H.3xx [23][12]. C´ılem H.235 je poskytnout autentiˇcnost, d˚ uvˇernost a integritu pˇren´aˇsen´eho obsahu. Pouˇzit´ı tˇechto bezpeˇcnostn´ıch profil˚ u je voliteln´e. Pro zajiˇstˇen´ı autentiˇcnosti je vyuˇzito haˇsovac´ıch func´ı MD5, SHA1, digit´aln´ı podpisy pˇr´ıpadnˇe tajn´ ych, dˇr´ıve domluven´ ych hesel. Integrity je dosaˇzeno kontroln´ım souˇctem. Vyuˇz´ıvaj´ı se stejn´e algoritmy a metody jako pro zajiˇstˇen´ı autentiˇcnosti. D˚ uvˇernost multimedi´aln´ıch dat pˇred moˇzn´ ym odposlouch´an´ım je zajiˇst’ena pomoc´ı DES, RC2, 3DES a AES. Rovnˇeˇz je moˇzn´e vyuˇz´ıt protokolu SRTP, ten nen´ı definov´an v jednotliv´ ych profilech. Bez pouˇzit´ı tˇechto profil˚ u H.323 nedefinuje zabezpeˇcen´ı signalizaˇcn´ıch protokol˚ u jako je H.225, RAS, a proto lze pouˇz´ıt TLS nebo IPsec. S pouˇzit´ım v´ yˇse jmenovan´ ych mechanism˚ u je definov´ano nˇekolik bezpeˇcnostn´ıch profil˚ u: Baseline security profile, Signature security profile, Voice encryption security profile a Hybrid security profile. Profily jsou implementov´any pro tzv - gatekeeper routed model, coˇz je metoda pro zajiˇstˇen´ı efektivn´ı dostupnosti doplˇ nkov´ ych sluˇzeb ve velk´ ych s´ıt´ıch.
ˇ ´I SIGNALIZACN ˇ ´ICH PROTOKOLU ˚ KAPITOLA 6. ZABEZPECEN
35
Obr´azek 6.1: H.323 Baseline Security Profile
Obr´azek 6.2: H.323 Signature Security Profile Pˇ rehled z´ akladn´ıch bezpeˇ cnostn´ıch profil˚ u: • Baseline Security Profile Baseline Security profil spol´eh´a na symetrick´e ˇsifrovac´ı techniky. Zajiˇstˇen´ı autentizace a integrity je provedeno pomoc´ı sd´ılen´ ych hesel (Shared Secrets). Pˇri pouˇzit´ı dan´eho profilu je zabezpeˇceno spojen´ı mezi koncov´ ym zaˇr´ızen´ım a Gatekeeperem, d´ale pro gatekeeper - gatekeeper a pˇr´ıpadnˇe mezi obˇema koncov´ ymi body (gatekeeper routed model). Pokud pouˇzijeme tento profil, doporuˇcuje se mezi dalˇs´ımi body pouˇzit´ı tzv - hop to hop security. Dan´ y model je moˇzno vyuˇz´ıt teoreticky vˇsude, prakticky lze vˇsak bezpeˇcnost zaruˇcit pouze v mal´ ych s´ıt´ıch. Profil podporuje rychl´e zabezpeˇcen´e spojen´ı(secure fast connect - SFC), H.245 tunelov´an´ı a m˚ uˇze b´ yt pouˇzit v kombinaci se zabezpeˇcen´ım hovoru. • Signature Security Profile Signature Security Profile spol´eha na asymetrick´e ˇsifrovac´ı techniky. Integrita zpr´av a autentizace je zajiˇstˇena pomoc´ı bezpeˇcnostn´ıch certifik´at˚ u a digit´aln´ıch podpis˚ u. Profil spol´eh´a na jiˇz dˇr´ıve zm´ınˇen´ y gatekeeper routed model. Vzhledem k tomu, ˇze vyuˇz´ıv´a veˇrejn´ ych kl´ıˇc˚ u pˇred spojen´ım zn´am´ ych tajn´ ych hesel (shared secrets), je vhodn´ y pro velk´e, glob´aln´ı s´ıtˇe. Narozd´ıl od Baseline profilu nab´ız´ı nepopˇren´ı (non-repudiation). Jako Baseline profile nab´ız´ı tak´e rychl´e a bezpeˇcn´e pˇripojen´ı (SFC), H.245 tunelov´an´ı a m˚ uˇze b´ yt pouˇzit v kombinaci se zabezpeˇcen´ım hovoru. • Voice Encryption Option Voice Encryption Option podporuje d˚ uvˇernost hovoru a je ˇcasto pouˇz´ıv´am v kombinaci s Baseline nebo Signature profily. Voice encryption option popisuje mecha-
ˇ ´I SIGNALIZACN ˇ ´ICH PROTOKOLU ˚ KAPITOLA 6. ZABEZPECEN
36
Obr´azek 6.3: H.323 Voice Encryption
Obr´azek 6.4: H.323 Hybrid Security Profile nismus pro v´ ymˇenu kl´ıˇc˚ u bˇehem signalizace hovoru a distribuci kl´ıˇc˚ u bˇehem hovoru, kdy se vyuˇz´ıv´a sluˇzeb protokolu H.245. • Hybrid Security Profile Hybrid security profile vyuˇz´ıv´a jak symetrick´ ych tak asymetrick´ ych ˇsifrovac´ıch metod. Lze na nˇej pohl´ıˇzet jako na kombinaci profil˚ u Baseline a Signature. Certifik´aty a digit´aln´ı podpisy slouˇz´ı pro zajiˇstˇen´ı autentizace a integrity zpr´av pro prvn´ı potvrzen´ı mezi dvˇema entitami. Bˇehem dan´eho potvrzov´an´ı je dohodnuto sd´ılen´e tajn´e heslo, kter´e je d´ale pouˇzito stejn´ ym zp˚ usobem jako v Baseline profilu. Hybrid security model podporuje gatekeeper routed model. • SRTP & MIKEY usage: Dan´ y profil definuje pouˇzit´ı SRTP pro zajiˇstˇen´ı d˚ uvˇernosti hovoru. Vzhledem k tomu, ˇze SRTP nem´a vnitˇrnˇe zajiˇstˇenou bezpeˇcnou v´ ymˇenu kl´ıˇc˚ u pro ˇsifrov´an´ı, je souˇc´ast´ı doporuˇcen´ı pouˇzit´ı mechanismu MIKEY pro bezpeˇcnou v´ ymˇenu kl´ıˇc˚ u. Pro mechanismus MIKEY jsou definov´any 2 podprofily, dle pouˇzit´ı bud’ symetrick´ ych nebo asymetrick´ ych ˇsifrovac´ıch technik.
6.3
XMPP/Jingle
XMPP [24] nab´ız´ı nˇekolik zp˚ usob˚ u pro zabezpeˇcen´ı autentizace, integrity a d˚ uvˇernosti. Vˇsechna ˇreˇsen´ı pracuj´ı na aplikaˇcn´ı vrstvˇe TCP modelu. Konkr´etnˇe jsou definov´any dvˇe moˇznosti zabezpeˇcen´ı. Prvn´ı z nich je zabezpeˇcen´ı bˇehem navazov´an´ı spojen´ı a pˇri autentizaci. V t´eto f´azi se vyuˇz´ıv´a protokolu SASL. Simple
ˇ ´I SIGNALIZACN ˇ ´ICH PROTOKOLU ˚ KAPITOLA 6. ZABEZPECEN
37
Authentication and Security Layer (SASL) je obecn´a metoda kter´a slouˇz´ı pro ovˇeˇrov´an´ı identity v klient/server aplikac´ıch. Implementuje nˇekolik ovˇeˇrovac´ıch mechanism˚ u, na kter´ ych se pˇri zaˇc´atku komunikace dohodnou jednotliv´e strany. Nejbˇeˇznˇejˇs´ı je jako v pˇredchoz´ıch pˇr´ıpadech pouˇzit´ı MD5 funkce. Jej´ı implementace pro XMPP je povinn´a. Po t´eto f´azi je pro zabezpeˇcen´ı d˚ uvˇernosti samotn´eho hovoru pouˇzit protokol TLS, jako je tomu napˇr. u protokolu SIP. Implementace dan´ ych prvk˚ u pro zabezpeˇcen´ı je povinn´a dle RFC. Protokoly mus´ı b´ yt do sebe zapouzdˇ reny dle n´ asleduj´ıc´ıho poˇ rad´ı: 1. TCP 2. TLS 3. SASL 4. XMPP
6.4
Media Gatewayes
Zabezpeˇcen´ı protol˚ u pro komunikaci mezi Gatewayes [?] nen´ı nijak velk´e. V´ yvoj´aˇri tˇechto protokol˚ u pˇredpokl´adaj´ı, ˇze komunikace prob´ıh´a jiˇz po zabezpeˇcen´em m´ediu a proto vˇetˇsinou ˇz´adnou podporu pro zabezpeˇcen´ı neimplementuj´ı. Bliˇzˇs´ı informace lze n´alezt v podkapitol´ach. 6.4.1
MGCP
Pro samotn´ y MGCP protokol nejsou definov´any ˇz´adn´e bezpeˇcnostn´ı mechanismy. RFC 2705 doporuˇcuje pouˇzit´ı IPSec pro zajiˇstˇen´ı bezpeˇcnosti MGCP zpr´av. Bez pouˇzit´ı zabezpeˇcen´ı je moˇzn´e pro potenci´aln´ıho u ´toˇcn´ıka vytvoˇrit neautorizovan´e hovory, pˇr´ıpadnˇe zas´ahnout do pr´avˇe prob´ıhaj´ıc´ıh hovor˚ u. Mimo pouˇzit´ı IPSec, MGCP umoˇzn ˇuje agent˚ um zabezpeˇcit Gatewaye pomoc´ı tzv. Session keys, kter´e lze d´ale vyuˇz´ıt pro ochranu audio zpr´av a t´ım zabezpeˇcit d˚ uvˇernost hovoru. Session key se d´a tak´e pouˇzit pˇr´ımo pro zabezpeˇcen´ı RTP paket˚ u. Pro v´ ymˇenu kl´ıˇc˚ u mezi Call agenty se obvykle pouˇz´ıv´a protokolu SDP. Ten je ale nutn´e zabezpeˇcit, jelikoˇz s´am ˇz´adn´e zabezpeˇcen´ı neposkytuje. 6.4.2
Megaco/H.248
Megaco doporuˇcuje mechanismy, kter´e zabezpeˇc´ı komunikaci na s´ıt’ov´e vrstvˇe. H.248 pˇr´ımo vyˇzaduje zabezpeˇcen´ı pomoc´ı IPSec. Pro IPv4 je vyˇzadov´ana implementace interim AH scheme. H.248 prohlaˇsuje, ˇze implementace pouˇz´ıvaj´ıc´ı AH hlaviˇcky nab´ız´ı nejmenˇs´ı nutnou sadu algortim˚ u pro integritu ovˇeˇren´ı manu´aln´ıch kl´ıˇc˚ u.
6.5
IAX
IAX je bin´arn´ı protokol [26], kter´ y vyˇzaduje ochranu proti Buffer OverFlow DoS u ´tok˚ um. IAX nab´ız´ı autentizaci pomoc´ı veˇrejn´ ych kl´ıˇc˚ u pouˇzit´ım RSA. D˚ uvˇernost je zajiˇstˇena pouˇzit´ım AES. Tyto bezpeˇcnostn´ı prvky jsou d˚ uleˇzit´e, bohuˇzel ˇcasto v implementac´ıch
ˇ ´I SIGNALIZACN ˇ ´ICH PROTOKOLU ˚ KAPITOLA 6. ZABEZPECEN
38
protokol MGCP d˚ uvˇernost IPSec, VPN autentiˇcnost IPSec, VPN integrita IPSec, VPN
Megaco/H.248 IAX IPSec AES IPSec MD5, RSA IPSec IPSec, VPN
Tabulka 6.2: Moˇznosti zabezpeˇcen´ı MG protokol˚ u IAX sch´az´ı. D´ale se pouˇz´ıv´a MD5 pro autentizaci. Zda se pˇri autentizaci pouˇzije RSA nebo MD5 z´aleˇz´ı na rozhodnut´ı IAX registrar serveru. Nˇekter´e implementace IAX2 protokolu nab´ız´ı v r´amci vˇetˇs´ıho zabezpeˇcen´ı pouze jednu registraci na jeden u ´ˇcet. Dalˇs´ı registrace se stejn´ ymi u ´daji pˇrep´ıˇse prioritu hovor˚ u a pˇresmˇeruje hovory na dan´eho uˇzivatele. IAX podporuje zabezpeˇcen´ı autentiˇcnosti a integrity, nikovli uˇz d˚ uvˇernost samotn´eho datov´eho toku. Pro u ´pln´e zabezpeˇcen´ı protokolu se vˇsak doporuˇcuje, jako v pˇredchoz´ıch pˇr´ıpadech, zabezpeˇcen´ı na s´ıt’ov´e vrstvˇe - IPSec, openVPN.
6.6
Skype
Komunikace prob´ıh´a decentralizovanˇe pˇres r˚ uzn´e poˇc´ıtaˇce zapojen´e v s´ıti Skype [7] [2]. Centr´aln´ı server pouze ovˇeˇruje veˇrejn´ y kl´ıˇc uˇzivatele pˇri pˇrihl´aˇsen´ı do s´ıtˇe. Komunikace je ˇsifrov´ana ˇsifrou AES o d´elce kl´ıˇce 256 bit˚ u, provozovatel sluˇzby vˇsak m˚ uˇze toto bez ohl´aˇsen´ı, tˇreba i adresnˇe, zmˇenit. Komunikaˇcn´ı protokol ani zdrojov´e k´ody programu nejsou veˇrejnˇe dostupn´e. Povˇedom´ı o fungov´an´ı protokolu je d´ıky reverzn´ımu inˇzen´ yrstv´ı. K prolomen´ı doˇslo v ˇcervenci 2006 t´ ymem ˇc´ınsk´ ych inˇzen´ yr˚ u. Vlastn´ı program pracuje jako klient i server. Pˇr´ıpadn´a bezpeˇcnostn´ı chyba m˚ uˇze ohrozit celou s´ıt’ Skype. Program m˚ uˇze b´ yt tak´e ovl´ad´an jin´ ymi programy pˇres zveˇrejnˇen´e API - pokud uˇzivatel v´ yslovnˇe programu Skype povol´ı, aby byl pˇres toto API ovl´ad´an vnˇejˇs´ı aplikac´ı, m˚ uˇze to otevˇr´ıt moˇznosti zneuˇzit´ı r˚ uzn´ ymi ˇskodliv´ ymi programy (viry, spyware, malware,. . . ) Skuteˇcn´e nebezpeˇc´ı Skype je v tom, ˇze nen´ı pˇresnˇe zn´amo, jak skuteˇcnˇe vnitˇrnˇe funguje.
6.7
Srovn´ an´ı zabezpeˇ cen´ı
V´ yˇse zm´ınˇen´e moˇznosti reprezentuj´ı nejpouˇz´ıvanˇejˇs´ı zp˚ usoby zabezpeˇcen´ı nejen pro VoIP, ale celkovˇe v IP s´ıt´ıch. Pˇri volbˇe, jak zabezpeˇcit komunikaci, je nejd˚ uleˇzitejˇs´ı si uvˇedomit, co a jak chceme zabezpeˇcit. Je jasn´e, ˇze zabezpeˇcen´ı soukrom´eho PC bude jistˇe slabˇs´ı neˇz v PC napˇr. v bance. Mezi nejˇcastˇejˇs´ı kryptovac´ı algoritmy patˇr´ı RSA, AES, 3DES, CA, SHA1. Ty jsou pouˇzity bud’ samostatnˇe a nebo jsou souˇc´ast´ı kryptovac´ıch protokol˚ u: napˇr TLS. Pro zabezpeˇcen´ı signalizace v SIP VoIP syst´emech jednoznaˇcnˇe vl´adne pouˇzit´ı TLS. Starˇs´ı varianty jako S/MIME se dnes nevyskytuj´ı. Velk´ ym probl´emem z˚ ust´av´a zabezpeˇcen´ı po cel´e d´elce cesty paketu (end to end security - E2E). Pokud vˇsechny IP telefony jsou um´ıstˇeny na stejn´e s´ıti jako je Registrar Server, nen´ı s E2E probl´em. Probl´emy nast´avaj´ı v tom pˇr´ıpadˇe, kdy je n´aˇs IP telefon um´ıstˇen na priv´atn´ı s´ıti a SIP server na veˇrejn´e s´ıt’i. SIP je vˇseobecnˇe zn´am sv´ ymi probl´emy s NATem, ˇreˇsen´ı vˇsak nab´ız´ı napˇr´ıklad pouˇzit´ım
ˇ ´I SIGNALIZACN ˇ ´ICH PROTOKOLU ˚ KAPITOLA 6. ZABEZPECEN
39
protokolu STUN. Dalˇs´ım faktorem nutn´ ym pro pouˇzit´ı TLS je, aby byl jako tranportn´ı protokol pouˇzit protokol TCP. To m˚ uˇze v pˇr´ıpadˇe horˇs´ıho internetov´e pˇripojen´ı ovlivnit QoS. V pˇr´ıpadˇe protokolu H.323 m´ame na v´ ybˇer z velk´eho mnoˇzstv´ı bezpeˇcnostn´ıch profil˚ u. Dan´e profily jsou definov´any standardem H.235. Profily v H.235 spol´ehaj´ı vˇetˇsinou na tzv. gatekeeper routed model, kter´ y se star´a o zpr´avu PKI. Pˇri autentizaci uˇzivatele se doporuˇcuje pouˇz´ıt profilu Signature Security a pro pˇrenos hlasu Voice Encryption option. Jako alternativou mezi tˇemito protokoly z˚ ust´av´a Hybrid Security profile. Konkr´etn´ı specifikace a pouˇzit´e ˇsifry jsou uvedeny v t´eto kapitole. U protokol˚ u urˇcen´ ych pro spojen´ı komunikaˇcn´ıch bran je situace velmi jednoduch´a. T´emˇeˇr ˇz´adn´e zabezpeˇcen´ı neposkytuj´ı, kromˇe protokolu IAX, kter´ y se st´av´a standardem pro pˇripojov´an´ı koncov´ ych u ´ˇcastn´ık˚ u. U tˇechto protokol˚ u se pˇredpokl´ad´a pouˇzit´ı ovˇeˇren´ ych bezpeˇcnostn´ıch standardu jako IPsec(Megaco jej pˇr´ımo vyˇzaduje), pˇr´ıpadnˇe VPN (openVPN). Vzhledem k tomu, ˇze se dan´e protokoly pouˇz´ıvaj´ı na stranˇe provider˚ u, nejsou zde probl´emy s ˇs´ıˇrkou p´asma, proto je pouˇzit´ı tˇechto protokol˚ u moˇzn´e. IPsec pˇr´ıp. VPN jsou tak´e mnohem n´aroˇcnˇejˇs´ı na zprovoznˇen´ı, coˇz je u vˇetˇsiny uˇzivatel˚ u neˇreˇsiteln´e. Tato kapitola se vˇenovala zabezpeˇcen´ı signalizace hovoru. Tomu, jak zabezpeˇcit samotn´ y pˇrenos hlasu se vˇenuje n´asleduj´ıc´ı kapitola.
40
ˇ ´I SIGNALIZACN ˇ ´ICH PROTOKOLU ˚ KAPITOLA 6. ZABEZPECEN
ˇ ´I HOVORU KAPITOLA 7. MECHANISMY PRO ZABEZPECEN
41
7 Mechanismy pro zabezpeˇ cen´ı hovoru Pˇri zabezpeˇcov´an´ı hovor˚ u hraje v´ yznamnou roli fakt, ˇze dan´a komunikace mus´ı prob´ıhat na ˇzivo, a proto dostateˇcnˇe rychle. Zejm´ena u koncov´ ych u ´ˇcastn´ık˚ u nen´ı moˇzn´e vyuˇzit ˇz´adn´ ych kryptografick´ ych akceler´ator˚ u, pˇr´ıpadnˇe dalˇs´ıch zaˇr´ızen´ı podporuj´ıc´ı kryptov´an´ı za bˇehu. D´ale je nutn´e br´at ohled na kvalitu pˇripojen´ı koncov´eho uˇzivatele, kter´e mnohdy nemus´ı b´ yt dostateˇcnˇe rychl´e. Nakonec mus´ı b´ yt pouˇzit´ y ˇsifrovac´ı algoritmus dostateˇcnˇe robustn´ı, aby jej nebylo moˇzn´e prolomit za kr´atkou dobu. Tyto podm´ınky kladou na tv˚ urce jist´a omezen´ı, jsou jim ale tak´e v´ yzvou, pokusit se to vˇse dodrˇzet a pˇritom zajistit d˚ uvˇernost hovoru na poˇzadovan´e u ´rovni. Pro pˇrenos hovoru se vyuˇz´ıv´a protokolu RTP, pˇr´ıpadnˇe RTCP. Ty ve sv´em z´akladu ˇz´adn´e rozˇs´ıˇren´ı pro ˇsifrov´an´ı nemaj´ı. Z toho d˚ uvodu bylo nutn´e tyto protokoly rozˇs´ıˇrit a t´ım nab´ıdnout zabezpeˇcen´ı. O rozˇs´ıˇren´ı tˇechto protokol˚ u, probl´emech pˇri zabezpeˇcov´an´ı a srovn´an´ı s dalˇs´ımi moˇznostmi zabezpeˇcen´ı pojedn´av´a tato kapitola.
7.1
SRTP a SRTCP
SRTP, SRTCP, Secure RTP, resp. RTCP jsou rozˇs´ıˇren´ım protokolu RTP resp. RTCP, kter´e podporuje integritu, d˚ uvˇernost, autentiˇcnost zpr´avy a zav´ad´ı ochranu proti pˇreposl´an´ı [21], [23], [12]. Pro oba tyto protokoly jsou definov´any stejn´e postupy a algoritmy pro zabezpeˇcen´ı. Protokol SRTP m´a pro pouˇzit´ı definovan´ y port 5004, SRTCP port ˇc´ıslo 5005. Struktura SRTP paketu je na obr. 7.1. Pro zajiˇstˇen´ı d˚ uvˇernosti pˇren´aˇsen´ ych dat v paketu se pouˇz´ıv´a kryptografick´a metoda AES-CTR (counter mode), kter´a zde pracuje jako gener´ator pseudon´ahodn´ ych kl´ıˇc˚ u. Vstupem do gener´atoru je inicializaˇcn´ı vektor IV, kter´ y sest´av´a z kontroln´ıho souˇctu saltkey, SSRC. V´ ysledn´ y kl´ıˇc je pomoc´ı logick´e operace XOR aplikov´an na nezaˇsifrovan´ y obsah paketu. Zajiˇstˇen´ı autentizace m´a na starosti algoritmus HMAC-SHA-1. T´ımto algoritmem je vytvoˇren kontroln´ı souˇcet z hlaviˇcky a obsahu SRTP paketu. Tato hodnota je pak uloˇzena v poli authentication tag. Vzhledem k tomu, ˇze je pˇri komunikaci kladen d˚ uraz na co nejmenˇs´ı zat´ıˇzen´ı pˇrenosov´eho p´asma, je v´ ysledn´ y kontroln´ı souˇcet m´ısto obvykl´e d´elky 160 bit˚ u zkr´acen na 80 pˇr´ıpadnˇe 32 bit˚ u. Pouˇzit´e ˇsifrovac´ı a autentizaˇcn´ı algoritmy vyˇzaduj´ı znalost tajn´eho symetrick´eho
Obr´azek 7.1: Struktura paketu SRTP
ˇ ´I HOVORU KAPITOLA 7. MECHANISMY PRO ZABEZPECEN
42
kl´ıˇce session key, kter´ y mus´ı b´ yt zn´am vˇsem komunikuj´ıc´ım stran´am. Vyvst´av´a pˇritom probl´em s generov´an´ım a distribuc´ı tohoto kl´ıˇce. Velikost kl´ıˇce master key m˚ uˇze b´ yt 128, 192 nebo 256b a pˇri generov´an´ı hraje roli AES kl´ıˇce. Pro distribuci master key lze pouˇz´ıt protokolu SDP. Tento protokol ale neposkytuje ˇz´adnou formu zabezpeˇcen´ı a tak je tˇreba nav´ıc pouˇz´ıt bezpeˇcnostn´ı mechanismy typu Transport Layer Security (TLS) nebo IPsec.
7.2
ZRTP
ZRTP [28] [2] vznikl rozˇs´ıˇren´ım protokol˚ u RTP a SRTP. Vyuˇz´ıv´a protokolu RTP pro Diffie-Helmanovu metodu pˇri v´ ymˇenˇe kl´ıˇc˚ u pro SRTP protokol. Standardem pro VoIP je od kvˇetna 2006, jedn´a se tedy o velmi mlad´ y protokol. Hlavn´ı v´ yhodou ZRTP je skuteˇcnost, ˇze nevyˇzaduje pˇredchoz´ı znalost tajn´ ych kl´ıˇc˚ u, pˇr´ıpadnˇe z´avislost na veˇrejn´ ych kl´ıˇc´ıch pˇr´ıpadnˇe digit´aln´ıch podpisech. Diffie-Helman kl´ıˇce jsou generov´any novˇe pro kaˇzdou session a nen´ı potˇreba vyuˇz´ıvat tˇret´ı d˚ uvˇeryhodn´e osoby (PKI). Dan´e kl´ıˇce se vyuˇzij´ı pˇri generov´an´ı session secret a souˇcasnˇe s dˇr´ıve pouˇzit´ ymi kl´ıˇci jsou z nich vygenerov´any fin´aln´ı kl´ıˇce a paramatry pro SRTP session. Dan´ y postup umoˇzn ˇuje ochranu proti MitM u ´tok˚ um pokud pˇredpokl´ad´ame, ˇze u ´toˇcn´ık nebyl pˇri pˇredchoz´ım hovoru dan´ ych 2 stran. Ochrana proti tomuhle pˇr´ıpadu je tak´e moˇzn´a. ZRTP lze pouˇz´ıt s jak´ ymkoliv signalizaˇcn´ım protokolem SIP, H.323. Je nez´avisl´ y na signalizaˇcn´ı vrstvˇe, jelikoˇz vˇeˇsker´e vyjedn´av´an´ı prob´ıh´a v RTP streamu. Hlavn´ı v´ yhodou ZRTP protokolu je jeho nez´avislost na signalizaˇcn´ım protokolu a d´ale umoˇzn ˇuje u ´ˇcinnou ochranu proti MitM u ´tok˚ um. ZRTP SDK knihovny jsou volnˇe ˇs´ıˇr´ıteln´e dle podm´ınek GPL a lze pˇredpokl´adat, ˇze je jen ot´azkou ˇcasu, kdy se zaˇcne ZRTP ˇsiroce vyuˇz´ıvat. Shrnut´ı v´ yhod ZRTP: • je u ´plnˇe nez´avisl´ y na signalizaci, PKI a na dalˇs´ıch ˇreˇsen´ıch. Kl´ıˇce jsou vymˇen ˇov´any prostˇrednictv´ım peer to peer modelu. • spolupracuje s jak´ ymkoliv SIP/RTP telefonem, automaticky detekuje podporu kryptov´an´ı na druh´e stranˇe. • je dostupn´ y jako plugin k souˇcasn´ ym softwarov´ ym telefon˚ um, kter´e efektivnˇe zabezpeˇc´ı • pro v´ yvoj´aˇre je k dispozici SDK knihovna, kter´a usnadˇ nuje integraci do VoIP aplikac´ı • pˇredloˇzen IETF se ˇz´adost´ı o standardizaci, zdrojov´ y k´od je publikov´an
7.3
Mikey
Mikey je protokol pro spr´avu kl´ıˇc˚ u pro real-time aplikace. Ve VoIP prostˇred´ı se vyuˇz´ıv´a pro ustanoven´ı kl´ıˇc˚ u sezen´ı, kter´e jsou nutn´e pro SRTP protokol. Mikey podporuje 3 metody pro ustanoven´ı kl´ıˇ c˚ u:
ˇ ´I HOVORU KAPITOLA 7. MECHANISMY PRO ZABEZPECEN
43
Obr´azek 7.2: GUI aplikace Zfone • dˇr´ıve sd´ılen´e kl´ıˇce (PSK) • veˇrejn´e kl´ıˇce • Diffie-Hellmanova metoda
7.4
Zfone
Zfone je software, kter´ y nab´ız´ı bezpeˇcnou komunikaci pro VoIP pouˇzit´ım ZRTP [11]. Nejedn´a se tedy o protokol, ale jiˇz o konkr´etn´ı ˇreˇsen´ı jak zajistit d˚ uvˇernost pro jiˇz prob´ıhaj´ıc´ı hovor 7.2. Zfone kooperuje s bˇeˇzn´ ymi VoIP klienty. Nejdˇr´ıve je pomoc´ı klienta sestaven hovor, Zfone detekuje zaˇc´atek hovoru, zaˇcne s v´ ymˇenou kl´ıˇc˚ u mezi koncov´ ymi u ´ˇcastn´ıky a n´aslednˇe zaˇcne kryptovat konverzaci. Zfone gui slouˇz´ı pouze k ujiˇstˇen´ı volan´ ych, ˇze je hovor opravdu kryptovan´ y.
7.5
Srovn´ an´ı protokol˚ u
Srovn´an´ı protokol˚ u SRT(C)P a ZRTP nen´ı v˚ ubec jednoduch´e. ZRTP nen´ı dalˇs´ı protokol pro bezpeˇcn´ y pˇrenos hlasu, ale je rozˇs´ıˇren´ım protokolu SRTP, kdy odstraˇ nuje probl´emy s distribuc´ı kl´ıˇc˚ u. Srovn´an´ı tˇechto protokol˚ u jsem provedl dle dan´ ych kriteri´ı. Vˇse je uvedeno v tab. 7.1. • d˚ uvˇernost • autentiˇcnost • integrita • distribuce kl´ıˇc˚ u - metoda, jak jsou distribuov´any kl´ıˇce pro zaˇsifrov´an´ı • zabezpeˇcen´a v´ ymˇena kl´ıˇc˚ u - je zajiˇstˇeno CIA pˇri pˇrenosu • z´avislost na signalizaci - jsou potˇreba data ze signalizaˇcn´ı f´aze hovoru
ˇ ´I HOVORU KAPITOLA 7. MECHANISMY PRO ZABEZPECEN
44
protokol d˚ uvˇernost autentiˇcnost integrita distribuce kl´ıˇc˚ u
SRTP ano ano ano SDP
SRTCP ano ano ano SDP
zabezpeˇcen´a v´ ymˇena kl´ıˇc˚ u z´avislost na signalizaci moˇznosti pro bezpeˇcnou v´ ymˇenu kl´ıˇc˚ u ochrana MiTM
ne
ne
ano Diffie-Helman, Mikey, TLS, PKI, CA ne
ano Diffie-Helman, Mikey, TLS, PKI, CA ne
ZRTP ano ano ano DiffieHelman ne ne DiffieHelman ano
Tabulka 7.1: Protokoly pro pˇrenos hlasu a jejich moˇznosti • moˇznosti pro bezpeˇcnou v´ ymˇenu kl´ıˇc˚ u - jak zabezpeˇcit v´ ymˇenu kl´ıˇc˚ u, aby byly zajiˇstˇeny poˇzadavky na CIA • ochrana proti MiTM - je dan´ y protokol chr´anˇen proti u ´tok˚ um typu MiTM bez vyuˇzit´ı dalˇs´ı zabezpeˇcen´ı
7.6
Shrnut´ı zabezpeˇ cen´ı pro pˇ renos hlasu
Moˇznost´ı, jak zabezpeˇcit d˚ uvˇernost hovoru je opˇet v´ıce. Protokol SRTP je asi nejbˇeˇznˇejˇs´ım ˇreˇsen´ım. Hlavn´ı nev´ yhodou SRTP je skuteˇcnost, ˇze v´ ymˇena kl´ıˇc˚ u pro kryptov´an´ı hovoru ˇ sen´ı tohoto probl´emu prob´ıh´a vˇetˇsinou pomoc´ı SDP protokolu, kter´ y je nekryptov´an. Reˇ je moˇzn´e pouˇzit´ım napˇr. PKI, CA pˇr´ıpadnˇe pouˇzit´ım TLS, jak jiˇz bylo uvedeno dˇr´ıve. Zaj´ımav´ ym ˇreˇsen´ım je pouˇzit´ı protokolu MikeY. Nab´ız´ı nˇekolik r˚ uzn´ ych metod pro v´ ymˇenu kl´ıˇc˚ u v z´avislosti na moˇznostech VoIP s´ıtˇe. Dalˇs´ım ˇresen´ım, u kter´eho lze v budoucnu pˇredpokl´adat u ´spˇeˇsn´e vyuˇzit´ı je protokol ZRTP. Ten je postaven na protokolu SRTP a v´ ymˇena kl´ıˇc˚ u je provedena Diffie-Helmanovou metodou. Hlavn´ı v´ yhodou ZRTP je, ˇze se jedn´a o protokol, kter´ y zajiˇst’uje d˚ uvˇernost ve vˇsech f´az´ıch hovoru a nen´ı potˇreba pouˇzit´ı dalˇs´ıch mechanism˚ u napˇr. TLS.
KAPITOLA 8. VOIP KLIENTI A VOIP SERVERY
45
8 VoIP klienti a VoIP servery Dan´a kapitola se vˇenuje popisu volnˇe dostupn´ ych softwarov´ ych klient˚ um, kter´e lze pouˇz´ıt pro VoIP komunikaci. Je zde uveden kr´atk´ y popis klienta a anal´ yza moˇznost´ı zajiˇst’uj´ıc´ı d˚ uvˇernost, autentizaci a integritu. Uveden´ı klienti jsou v dalˇs´ı kapitole testov´an´ı na r˚ uzn´e typy u ´tok˚ u-
8.1 8.1.1
VoIP klienti Ekiga
Ekiga (dˇr´ıve GnomeMeeting) 1 je open source VoIP software klient. Podporuje jak protokol SIP, tak protokol H.323. P˚ uvodnˇe byl vyvinut pouze pod Linux, dnes je jiˇz rozˇs´ıˇren i pod OS Windows. Mezi v´ yhody tohoto klienta patˇr´ı podpora velk´eho mnoˇzstv´ı kodek˚ u a podpora pro videokonference. SIP bezpeˇ cnostn´ı prvky: • SIP MD5 digest autentizace • ve v´ yvoji SRTP, ZRTP 8.1.2
X-Lite
X-Lite 2 je jeden z nejrozˇs´ıˇrenˇejˇs´ıch open source softwarov´ ych telefon˚ u podporuj´ıc´ı SIP protokol od spoleˇcnosti CounterPath. Existuje jeˇstˇe komerˇcn´ı varianta - EyeBeam, kter´a z hlediska bezpeˇcnosti nab´ız´ı v´ıce bezpeˇcnostn´ıch prvk˚ u. X-Lite je ˇsiroce doporuˇcov´an poskytovateli SIP VoIP telefonie. SIP bezpeˇ cnostn´ı prvky: • SIP MD5 digest autentizace • TCP protokol Placen´a verze eyeBeam: • TLS • SRTP • ve v´ yvoji ZRTP 8.1.3
SJphone
SJphone 3 je dalˇs´ı z volnˇe dostupn´ ych softwarov´ ych VoIP klient˚ u. Mezi jeho v´ yhody patˇr´ı to, ˇze je multiplatformn´ı pro syst´emy s podporou Javy vˇcetnˇe PDA a podpora protokolu H.323 dle dan´eho pr˚ umyslov´eho standardu. SJphone podporu jak SIP, tak H.323 a dalˇs´ı protokoly. SJphone je dalˇs´ım z doporuˇcovan´ ych klient˚ u poskytovateli SIP VoIP telefonie. 1
http://ekiga.org/?rub=5 http://www.counterpath.com/ 3 http://www.sjlabs.com/ 2
46
KAPITOLA 8. VOIP KLIENTI A VOIP SERVERY
SIP bezpeˇ cnostn´ı prvky: • MD5 digest • TCP protokol • TLS • SRTP • ve v´ yvoji ZRTP 8.1.4
Minisip
Posledn´ı z vybran´ ych softwarov´ ych klient˚ u je Minisip 4 . P˚ uvodnˇe byl vyv´ıjen pod OS Linux, dnes je jiˇz k dispozici verze i pod OS Windows pomoc´ı knihoven GTK + podpora pro PDA. Na v´ yvoji Minisipu se pod´ıl´ı studenti Royal Institute of Technology - Stockˇ holm, Sv´edsko. SIP bezpeˇ cnostn´ı prvky: • SIP MD5 digest • TCP protokol • TLS • MIKEY (DH, PSK, PKE) • SRTP Dalˇs´ı, vˇetˇsinou open source klienti a jejich moˇznosti jsou uvedeny v tab. 8.1.
4
http://www.minisip.org/download.html
Windows Live Messenger Zfone (p˚ uvodnˇe PGPfone)
SJphone
Minipax OpenH323 and OPAL
zdrojov´ y zveˇrejnˇen, licence
Freeware
Freeware
SIP
GPL / LGPL Free software Freeware MPL free software
k´od SIP soukrom´a
SIP H.323, SIP, IAX, RTP, STUN SIP, RTP, STUN, Jabber, H.323 SIP, RTP, proprietary
XMPP, Jabber SIP, STUN, ICE
Freeware Freeware
Tabulka 8.1: VoIP klienti a jejich moˇznosti
Linux, Mac OS X, Windows
Windows Linux, Mac OS X, Windows Windows, Mac OS X, Linux, Windows 2
SRTP
SIP, XMPP, Jabber
SRTP, ZRTP
TLS, SRTP
SRTP, TLS, MIKEY (DH, PSK, PKE) Voip Tunnelling, VPN SRTP
SRTP, TLS
SIMPLE TLS, SRTP
SRTP, TLS
Zabezpeˇcen´ı
SIP, RTP, STUN
SIP, STUN, ICE SIP, H.323, STUN
Podporovan´e protokoly SIP, STUN, ICE
Voln´a/Licencovan´a verze Freeware
Freeware GPL licence
Windows, Mac, Linux Linux, Windows
Windows, Fusion RTOS on Blackfin Gizmo5 (p˚ uvodnˇe Linux, Mac OS X, Gizmo Projekt) Windows XP Google Talk Windows XP/2000 Lynxphone Windows, Mac OS X, Linux, NetBSD, FreeBSD Minisip Windows, Linux
uzavˇren´ y
Windows, Mac, Linux
CounterPath eyeBeam CounterPath X-Lite Ekiga (p˚ uvodnˇe GnomeMeeting) Fusion SoftPhone
Licence
Operaˇcn´ı syst´emy
N´azev programu
KAPITOLA 8. VOIP KLIENTI A VOIP SERVERY 47
48
KAPITOLA 8. VOIP KLIENTI A VOIP SERVERY
8.2
Pˇ rehled server˚ u pro IP telefonii
Serverov´ ych ˇreˇsen´ı pro VoIP telefonii je velk´e mnoˇzstv´ı, zejm´ena v placen´e sf´eˇre. Existuj´ı vˇsak velmi kvalitn´ı a rozˇs´ıˇren´e open-source varianty. Mezi nejv´ yznamnˇejˇs´ı jednoznaˇcnˇe patˇr´ı SIP Express router od spoleˇcnosti IPTEL.org a Asterisk PBX, vyv´ yjen´ y spoleˇcnost´ı Digium. V dan´e podkapitole jsou pops´any tato serverov´a reˇsen´ı a je provedena anal´ yza ohlednˇe moˇznost´ı zabezpeˇcen´ı. Na vybran´ ych serverech jsem provedl testy na SIP Invite floods, Registration Spoofing a provedl anal´ yzu v´ ysledku. Detaily test˚ u jsou uvedeny v dalˇs´ı kapitole a v pˇr´ıloze. 8.2.1
SIP Express Router (SER)
SIP Express Router (SER) 4 je Open source SIP server. Zast´av´a funkci registraˇcn´ıho, redirect a proxy serveru pro komunikaci protokolem SIP. P˚ uvodnˇe byl vyv´ıjen jako p´ateˇrn´ı SIP smˇerovaˇc, tud´ıˇz s d˚ urazem na v´ ykon. Server podporuje bezestavov´e i transakˇcnˇe stavov´e zpracov´an´ı SIP komunikace. Toto zpracov´an´ı je ˇr´ızeno siln´ ym skriptovac´ım jazykem. S´ıla jazyka v sobˇe vˇsak skr´ yv´a i pˇr´ıpadnou sloˇzitost konfigurace. Server je modul´arn´ı, tedy dobˇre rozˇs´ıˇriteln´ y a s rostouc´ı uˇzivatelskou z´akladnou st´ale pˇrib´ yvaj´ı nov´e moduly. Server je moˇzn´e vzd´alenˇe ˇr´ıdit pˇres Fifo nebo UNIX socket. Pro vlastn´ı SIP komunikaci podporuje IP protokol verze 4 i 6 a transportn´ı protokoly UDP, TCP a s pˇr´ısluˇsn´ ymi moduly i TLS. Server d´ale podporuje v´ıce uˇzivatelsk´ ych dom´en, aliasy a dotazy do ENUM dom´en. Autentizace m˚ uˇze b´ yt prov´adˇena pˇres datab´azi (Mysql , Postgress), Radius nebo Diameter. Podporovan´ e bezpeˇ cnostn´ı prvky: • autentizace - MD5 • integrita - checksum • d˚ uvˇernost- TLS, SRTP • podpora TCP, RADIUS autentizace, LDAP 8.2.2
Asterisk
Asterisk 5 je open source program zamˇeˇren´ y na provoz telefonn´ıch sluˇzeb. Poskytuje mnoho u ´rovn´ı pro zpracov´an´ı hlasu pˇres pakety a pˇrep´ın´an´ı okruh˚ u (TDM). Neofici´alnˇe lze program Asterisk oznaˇcit za jedno z nejsilnˇejˇs´ıch, nejflexibilnˇejˇs´ıch a nejrozˇs´ıˇrenˇejˇs´ıch ˇreˇsen´ı v oblasti integrovan´eho telekomunikaˇcn´ıho softwaru. Jde tedy o kompletn´ı open source softwarovou u ´stˇrednu PBX bˇeˇz´ıc´ıch na platform´ach Linux a Unix, poskytuj´ıc´ı veˇsker´e vlastnosti, kter´e byste oˇcek´avali od u ´stˇredny. Jedn´a se o obecnou distribuci pod podm´ınkami GNU (General Public Licence). Povolenou v´ yjimkou tvoˇr´ı spojen´ı s OpenH323 projektem a to za u ´ˇcelem dostupnosti H.323 podpory. Syst´em je navrˇzen tak, aby vytvoˇril rozhran´ı telefonn´ımu hardwaru, softwaru a libovoln´e telefonn´ı aplikace. Asterisk m˚ uˇze spojovat a zpracov´avat r˚ uzn´e druhy VoIP protokol˚ u jako jsou SIP, MGCP, IAX a H.323 a tak´e mnoho protokol˚ u pro klasick´e telefonn´ı s´ıtˇe tak jako jsou POTS, 4 5
http://iptel.org http://www.asterisk.org
KAPITOLA 8. VOIP KLIENTI A VOIP SERVERY
49
ISDN PRI a ISDN BRI. V´ yhoda Asterisku leˇz´ı v jeho pˇrizp˚ usobitelnosti, v moˇznosti implementace r˚ uzn´ ych standard˚ u a jeho otevˇren´em softwaru. Podporovan´ e bezpeˇ cnostn´ı prvky: • autentizace - MD5 • integrita - checksum • d˚ uvˇernost- SRTP, TLS(od verze 1.6, beta 8, kvˇeten 2008) • uloˇzen´ı hesel v datab´azi mySQL 8.2.3
H.323plus
H.323plus 7 je open source projekt, kter´ y se vˇenuje v´ yvoji H.323 protokolu. Projekt vznikl oddˇelen´ım od projektu openH323. Podporuje velk´e mnoˇzstv´ı standard˚ u jak pro VoIP tak i pro videokonference. Podporovan´ e bezpeˇ cnostn´ı standardy: • H.235.0 (Security framework -H-series multimedia systems) • H.235.1(Baseline security profil)
8.3
Z´ avˇ er
Tato kapitola je u ´vodem do kapitoly n´asleduj´ıc´ı, kde s dan´ ym software testuji. Dalˇs´ı v´ yhodou VoIP je ta vlastnost, ˇze nen´ı nutn´e koupit od v´ yrobc˚ u drah´ y hardware a lze si vystaˇcit s obyˇcejn´ ym PC, kter´e uˇz m´ame doma. S bezpeˇcnost´ı uˇz je to o nˇeco horˇs´ı. Nˇekteˇr´ı klienti uˇz protokoly TLS, SRTP podporuj´ı, vˇetˇsinou je vˇsak bezpeˇcnost ve f´azi v´ yvoje, pˇr´ıpadnˇe k dispozici, ale pouze v placen´e verzi. U Voip server˚ u bezpeˇcnostn´ı prvky jsou jiˇz k diposzici. U VoIP server˚ u je dalˇs´ı d˚ uleˇzitou vlastnost´ı stabilita syst´emu a odolnost proti DoS. Na otestov´an´ı tˇechto vlastnost´ı jsem se zamˇeˇril v dalˇs´ı kapitole.
7
http://www.h323plus.org/
KAPITOLA 8. VOIP KLIENTI A VOIP SERVERY 50
N´azev syst´emu
Operaˇcn´ı syst´emy
Open MPL free software GPL free software
GPL free software/Proprietary GPL free software
Licence
SIP, STUN, XMPP, Jabber, IAX SIP
FreeSWITCH SIP Express Router (SER) IP
Podporovan´e protokoly SIP, H.323, IAX
Asterisk PBX
Linux, BSD, Mac OS X FreeBSD, Linux, Microsoft Windows, Solaris Windows, Linux, BSD, Solaris BSD, Linux, Solaris
Open source L-GPL
Native SIP Call Control H.323
H.323, IAX, Jingle, SIP
Linux
Open source L-GPL
YATE
Windows, Linux
sipX ECS PBX H.323 plus
Tabulka 8.2: VoIP servery a u ´stˇredny
TLS,
Zabezpeˇcen´ı
MD5, SRTP
MD5, SRTP
MD5, TLS, Diameter, RADIUS, SRTP, HTTPS, TLS
H.235 standards
´ ´I VOIP KLIENTU ˚ A SERVERU ˚ PRAKTICKY KAPITOLA 9. TESTOVAN
51
9 Testov´ an´ı VoIP klient˚ u a server˚ u prakticky V t´eto kapitole jsem se rozhodl chovat se jako hacker a uk´azat, jak je/nen´ı snadn´e napadnout oper´atory nebo koncov´e uˇzivatele. Testovan´ ym protokolem je protokol SIP, jakoˇzto dnes nejrozˇs´ıˇrenˇejˇs´ı protokol pro IP telefonii. Jelikoˇz je textov´ y, je mnohem jednoduˇsˇs´ı na nˇej u ´toˇcit, na rozd´ıl napˇr. od H.323. C´ılem t´eto kapitoly je tedy prakticky ovˇeˇrit ne/bezpeˇcnost klient˚ u, server˚ u a odhalit zranitelnost syst´emu. Testovan´ ymi klienty jsou dˇr´ıve zm´ınˇen´ı X-Lite, Ekiga, SJphone a Minisip, servery SIP Express Router a Asterisk PBX.
9.1
Nastaven´ı skriptu pro program SIPp
Vhodn´ y program pro testov´an´ı SIP protokolu je program SIPp. Jeho fce a z´akladn´ı vlastnosti jsou pˇredstaveny v pˇr´ıloze. Pro testov´an´ı stability klient˚ u jsem vyuˇzil defaultn´ı nejjednoduˇsˇs´ı schema pro SIPp. XML skript pos´ıl´a invite paket a ˇcek´a na v´ yzv´anˇen´ı. ˇ Cek´a na potvrzen´ı hovoru 200 (OK), pos´ıl´a potvrzen´ı a n´aslednˇe ukonˇcuje hovor. Pokud se skript vyuˇzije jako n´astroj pro Invite floods, vyuˇzij´ı se pouze prvn´ıch tˇr´ı f´azi skriptu. Dalˇs´ı se vˇetˇsinou jiˇz neprovedou. Origin´al skriptu v XML je uveden v pˇr´ıloze. SIPp UAC Remote |(1) INVITE | |------------------>| |(2) 100 (optional) | |<------------------| |(3) 180 (optional) | |<------------------| |(4) 200 | |<------------------| |(5) ACK | |------------------>| | | |(6) BYE | |------------------>| |(7) 200 | |<------------------| pˇ r´ıkaz pro u ´ tok Invite floods: ./sipp -sn uac
-r 10 -rp 1000 -s michalvanek iptel.org
v´ yznam jednotliv´ ych pˇ rep´ınaˇ c˚ u: • -sn uac - pouˇzij UAC schema • -r 10 - vys´ılej 10x za ˇcasov´ y interval • -rp 1000 - opakov´an´ı po 1000ms • -s - login volan´eho • iptel.org - server na kter´em je dan´ yu ´ˇcet
52
9.2
´ ´I VOIP KLIENTU ˚ A SERVERU ˚ PRAKTICKY KAPITOLA 9. TESTOVAN
Testov´ an´ı VoIP klient˚ u
V pˇredchoz´ı kapitole uveden´e softwarov´e klienty jsem se rozhodl otestovat na u ´tok SIP invite flood pomoc´ı testovac´ıho programu SIPp. Invite flood je jeden z moˇzn´ ych DoS u ´toku, kdy je koncov´ y uˇzivatel pˇr´ıp. SIP proxy, zahlcena velk´ ym mnoˇzstv´ım ˇz´adost´ı o hovor. Pˇri testov´an´ı jsem se zamˇeˇril na schopnost telefonu pˇreˇz´ıt samotn´ y u ´tok, d´ale pˇri dan´em u ´toku moˇznost dokonˇcit samotn´ y hovor, pˇr´ıpadnˇe se jeˇstˇe dalˇs´ım uˇzivatel˚ um dovolat. Kaˇzd´ y test jsem provedl 3x, nejprve pro 10invites/s, 100invites/s a nakonec 500invites/s. ´ Utok prob´ıhal po dobu 60s. Hlavn´ım c´ılem bylo znesnadnit uˇzivateli vyuˇz´ıv´an´ı telefonu. Jako vedlejˇs´ı efekt se dostavilo zhroucen´ı cel´eho telefonu pˇr´ıpadnˇe nutnost restartov´an´ı poˇc´ıtaˇce, coˇz jistˇe koncov´eho uˇzivatele nepotˇeˇs´ı. Testovac´ı pracoviˇ stˇ e: Testov´an´ı jsem prov´adˇel na 2 poˇc´ıtaˇc´ıch, kde na jednom bˇeˇzel ´ cty byly zaregistrovan´e testovan´ y klient(PC1) a z druh´eho jsem prov´adˇel u ´tok(PC2). Uˇ na serveru iptel.org. Na poˇc´ıtaˇci PC2 jeˇstˇe bˇeˇzel analyz´ator Wireshark. Detailn´ı popis pracoviˇstˇe a testovac´ı skript pro SIPp je uveden v pˇr´ıloze. V´ ysledky testov´ an´ı: V´ ysledky dan´ ych test˚ u jsem pro vˇetˇs´ı pˇrehlednost shrnul do n´asleduj´ıc´ıch tabulek: 9.1, 9.2, 9.3.
´ ´I VOIP KLIENTU ˚ A SERVERU ˚ PRAKTICKY KAPITOLA 9. TESTOVAN invite floods - 10/s x lite verze 3.0 volat/pˇrij´ımat ne obnoven´ı po u ´toku ano popis chyby
ekiga 2.0.11 ne ne buffer overflow
sjphone v1.65 ne ano
53
minisip 0.7.1 ne ano
Tabulka 9.1: 10 invites/s invite floods - 100/s verze volat/pˇrij´ımat obnoven´ı po u ´toku popis chyby
x lite 3.0 ne ano
ekiga 2.0.11 ne ano
sjphone minisip v1.65 0.7.1 ne ne ne ne buffer overflow buffer overflow
Tabulka 9.2: 100 invites/s Anal´ yza v´ ysledk˚ u: V´ yˇse testovan´ı SIP klienti pˇreˇzili prvn´ı f´azi testov´an´ı t´emˇeˇr bez probl´em˚ u. Kromˇe klienta Ekiga se z u ´toku plnˇe obnovili a opˇet fungovali. Probl´emy Ekigy jsou pravdˇepodobnˇe zp˚ usobeny nutnost´ı instalace GTK knihoven, kter´e umoˇzn ˇuj´ı jeho vyuˇzit´ı na OS Windows. Pˇrij´ımat, pˇr´ıpadnˇe volat nebylo moˇzn´e v pr˚ ubˇehu u ´toku ani z jednoho klienta. I pˇri tak mal´em u ´toku lze koncov´eho uˇzivatele jednoduˇse odstavit od s´ıtˇe a znemoˇznit mu vyuˇz´ıvat telefonn´ıch sluˇzeb. Nav´ıc tak slab´ yu ´tok je velmi tˇeˇzko rozpoznateln´ y pro D-DoS detektory. Pr˚ ubˇeh druh´eho u ´toku je podobn´ y tomu prvn´ımu a doˇslo zde ke zhroucen´ı druh´eho klienta SJphone. V pˇr´ıpadˇe tˇret´ıho u ´toku doˇslou ke zhroucen´ı tˇret´ıho klienta, Minisip. Klient X-Lite vˇsechny u ´toky bez probl´emu pˇreˇzil a byl schopen dalˇs´ıho provozu. Proto jsem dan´eho klienta otestoval jeˇstˇe dalˇs´ım u ´tokem 500invites/s po dobu 10min a opˇet nedoˇslo k ˇz´adn´emu zhroucen´ı. X-Lite vych´az´ı z dan´ ych test˚ u jako nejodolnˇejˇs´ı klient. Nepodporuje vˇsak TLS ani SRTP (lze omezit pouˇzit´ım Zfone). Vˇsechny zachycen´e pakety jsou pˇriloˇzen´e na DVD. Tomu, jak se ˇc´asteˇcnˇe br´anit takov´ ym invite floods - 500/s verze volat/pˇrij´ımat obnoven´ı po u ´toku popis chyby
x lite 3.0 ne ano
ekiga 2.0.11 ne ne buffer overflow
sjphone v1.65 ne ne buffer overflow
Tabulka 9.3: 500 invites/s
minisip 0.7.1 ne ne buffer overflow
54
´ ´I VOIP KLIENTU ˚ A SERVERU ˚ PRAKTICKY KAPITOLA 9. TESTOVAN
u ´tok˚ um, je vˇenov´ana dalˇs´ı kapitola.
´ ´I VOIP KLIENTU ˚ A SERVERU ˚ PRAKTICKY KAPITOLA 9. TESTOVAN
9.3
55
Testov´ an´ı SIP proxy a registrar server˚ u
Pro oper´atory provozuj´ıc´ı IP telefonii jsou nejvˇetˇs´ı hrozbou DoS u ´toky a u ´toky typu Toll Fraud, kdy je napadena registrace ciz´ıho uˇzivatele a snaha zaregistrovat se na jeho u ´ˇcet. ´ V t´eto podkapitule se vˇenuji pr´avˇe zm´ınˇen´ ym t´emat˚ um. Utoky jsem provedlo praticky s n´asleduj´ıc´ımi v´ ysledky. Pro kaˇzd´ yu ´tok existuje z´aznam z analyz´atoru Wireshark. Popis pracoviˇ stˇ e: Pˇri testov´an´ı Asterisku jsem vyuˇzil server s Asteriskem um´ıstˇen´ y v Ericssone-Vodafone ˇ RDC - FEL, CVUT. Jako SIP proxy bylo vyuˇzito testovac´ıho serveru iptel.org. SIP Express Router byl jiˇz dˇr´ıve testov´an v CT Labs, Rocklin, CA, kde z´ıskal certifik´at dokazuj´ıc´ı jeho stabilitu. Jelikoˇz si jsou v´ yvoj´aˇri jist´ı spolehlivost´ı, nab´ız´ı za kaˇzd´e odstaven´ı serveru 100 USD. Pˇrestoˇze se nejedn´a o z´avratnou sumu, rozhodl jsem se proto pouˇz´ıt dan´ y server jako testovac´ı a pˇr´ıpadnˇe zv´ yˇsit sv˚ uj rozpoˇcet. 9.3.1
Testov´ an´ı Asterisku
Asterisk byl testov´an na 2 typy invite floods u ´tok˚ u: • platn´e volan´e ˇc´ıslo • neplatn´e volan´e ˇc´ıslo Testy byly provedeny 2x (10invites/s, 100invites/s ). Princip test˚ u je stejn´ y jako u testov´an´ı SIP telefon˚ u. C´ılem bylo zjistit chov´an´ı a stabilitu Asterisku bˇehem DoS u ´toku. Pro testov´an´ı jsem opˇet pouˇzil program SIPp, pro kter´ y jsem vytvoˇril vlastn´ı XML schema hovoru. SIPp UAC Remote |(1) INVITE | |------------------>| |(2) 100 (optional) | |<------------------| |(3) 180 (optional) |
V´ ysledky jsou shrnuty v tab. 9.4. parametry pro SIPp: sipp -sf uac_sipuri.xml -s XXX -r 500 -rp 1000 iptel.org Vyhodnocen´ı testu: Z namˇeˇren´ ych v´ ysledk˚ u vypl´ıv´a, ˇze naistalovan´a verzi Asterisku je velmi nestabiln´ı a i kr´atk´ y u ´tok m˚ uˇze v´est ke zhroucen´ı. Jedn´ım z d˚ uvod˚ u proˇc k tomu doˇslo m˚ uˇze b´ yt nedostateˇcn´ y v´ ykon serveru. Lze ale pˇredpokl´adat, ˇze pˇri zv´ yˇsen´ı v´ ykonnu serveru se tak´e zv´ yˇs´ı velikost u ´toku a opˇet dojde ke zhroucen´ı syst´emu. Jednou z moˇznost´ı, jak tomu zabr´anit uv´ad´ım v n´asleduj´ıc´ı kapitole.
56
´ ´I VOIP KLIENTU ˚ A SERVERU ˚ PRAKTICKY KAPITOLA 9. TESTOVAN Asterisk - platn´e ˇc´ıslo volat/pˇrij´ımat obnoven´ı po u ´toku popis chyby
10inivites/s ano ano
100invites/s ne ne too many open files
Asterisk - neplatn´e ˇc´ıslo 10inivites/s 100invites/s volat/pˇrij´ımat ano ne obnoven´ı po u ´toku ano ne popis chyby too many open files Tabulka 9.4: V´ ysledky testov´an´ı Asterisku 9.3.2
Testov´ an´ı SER serveru iptel.org
Sip Expres Router je vyv´ yjen skupinou Iptel a jeho tv˚ urci si jsou jisti jeho stabilitou, a proto nab´ız´ı 100 USD za kaˇzd´e zhroucen´ı. Pro testov´an´ı jsem se rozhodl pouˇz´ıt opˇet program SIPp. Nejprve jsem testoval klasick´ y invite floods u ´tok, kter´ y byl u ´spˇeˇsn´ y u Asterisku. Tento test u ´spˇeˇsn´ y nebyl a server testov´an´ı pˇreˇzil. Jako dalˇs´ı moˇznost jsem tedy zvolil metodu - Funkˇcn´ı testov´an´ı protokolu (fuzzing). Metodami typu Fuzzing testujeme, jak jsou oˇsetˇreny velikosti promˇenn´ ych, napˇr. zda je moˇzn´e do pole o velikosti 10 zapsat 11 prvk˚ u. V praxi se vyuˇz´ıv´a tzv. Black box testov´an´ı, kdy nev´ıme nic o programu a n´ahodnˇe testujeme, jak se syst´em zachov´a. Black box Fuzzing je dnes nejrozsˇs´ıˇrenˇejˇs´ı metodou, jak odhalovat chyby v programech. Kromˇe t´eto metody se jeˇstˇe vyuˇz´ıv´a metod zpˇetn´eho inˇzen´ yrstv´ı. Pˇred zapoˇcet´ım u ´toku jsem programem Sivus dan´ y server otestoval a odhalil nebezpeˇc´ı, kde m˚ uˇze vzniknout probl´em typu buffer overflow a v krajn´ım pˇr´ıpadˇe doj´ıt k zhroucen´ı serveru. SiVuS odhalil cca 500 moˇzn´ ych hrozeb typu Low Risk Level. Otestovat jsem se rozhodl pro uk´azku 2 z nich. Zpr´ava o nalezen´ ych hrozb´ach je pˇriloˇzena na DVD. 9.3.2.1
Test SIP URI v INVITE zpr´ avˇ e
C´ıl testu: Ovˇeˇrit, zda je moˇzn´e poslat v SIP URI 10x SIP: do pole URI v INVITE zpr´avˇe. ˇc´ast testuj´ıc´ı SIP zpr´avy: V poli to: je pˇrid´ano nav´ıc 10x sip: INVITE sip:[service]@[remote_ip]:[remote_port] SIP/2.0 Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch] From: sipp <sip:100@[local_ip]:[local_port]>;tag=[call_number] To: MICHAL <sip:sip:sip:sip:sip:sip:sip:sip:sip:sip: [service]@[remote_ip]:[remote_port]> Call-ID: [call_id] CSeq: 1 INVITE Contact: sip:100@[local_ip]:[local_port] Max-Forwards: 70
´ ´I VOIP KLIENTU ˚ A SERVERU ˚ PRAKTICKY KAPITOLA 9. TESTOVAN
57
Subject: SIPp test Content-Type: application/sdp Content-Length: [len] parametry pro SIPp: sipp -sf uac_sipuri.xml -s XXX -r 500 -rp 1000 iptel.org Vyhodnocen´ı testu: Test prob´ıhal po dobu 10 minut a k ˇz´adn´emu zhroucen´ı nedoˇslo. Pravdˇepodobnˇe se nejedn´a o tak silnou hrozbu a proto tv˚ urci SERu zat´ım nemus´ı dan´ y probl´em ˇreˇsit. D´ale je tak´e moˇzn´e, ˇze u ´tok neproˇsel pˇres detektory D-DoS u ´toku. Vzhledem k tomu, ˇze u ´toky invite floods na klienty proch´azeli bez probl´em˚ u, povaˇzuji tuto variantu za m´enˇe pravdˇepodobnou. 9.3.2.2
Test SIP URI v INVITE paketu 2
C´ıl testu: Ovˇeˇrit, zda je moˇzn´e zapsat 10x / mezi SIP a danou verzi (SIP ///// 2.0) v INVITE paketu. ˇc´ast testuj´ıc´ı SIP zpr´avy: V poli Via: za SIP je pˇrid´ano nav´ıc 10x /: INVITE sip:[service]@[remote_ip]:[remote_port] SIP/2.0 Via: SIP///////////2.0/ [transport] [local_ip]:[local_port];branch=[branch] From: sipp <sip:100@[local_ip]:[local_port]>;tag=[call_number] To: MICHAL <sip:[service]@[remote_ip]:[remote_port]> Call-ID: [call_id] CSeq: 1 INVITE Contact: sip:100@[local_ip]:[local_port] Max-Forwards: 70 Subject: SIPp test Content-Type: application/sdp Content-Length: [len] parametry pro SIPp: sipp -sf uac_sipsip.xml -s XXX -r 500 -rp 1000 iptel.org Vyhodnocen´ı testu: V´ ysledku testu jsou podobn´e jako v pˇredchoz´ım pˇr´ıpadˇe. Je proto ˇz´adouc´ı vyzkouˇset dalˇs´ı moˇzn´ y zp˚ usob napaden´ı.
9.4 9.4.1
Registration hijacking Pˇ ri vypnut´ e autentizaci
Ukradnut´ı registrace pˇri vypnut´e autentizaci je velmi snadn´a z´aleˇzitost. Nejd˚ uleˇzitˇejˇs´ı je odstranit dan´eho uˇzivatele, z´ıskat jeho registraˇcn´ı zpr´avu a zruˇsit mu registraci. Odejmut´ı
58
´ ´I VOIP KLIENTU ˚ A SERVERU ˚ PRAKTICKY KAPITOLA 9. TESTOVAN
registrace lze doc´ılit, kdyˇz vygenerujeme Register paket, kde je nutn´e zadat do pole Contact - * a expires - 0. Pak lze jednoduˇse postupovat dle jednoduch´eho sch´ematu, jak je uvedeno d´ale na obr. 9.1. Pro demostraci tohoto u ´toku jsem vyuˇzil n´astroje SiVuS ke generov´an´ı SIP zpr´av. Nejprve jsem provedl leg´aln´ı registraci klientem X-Lite. Cel´e SIP zpr´avy jsou uvedeny v pˇr´ıloze. REGISTER od klienta X-Lite: Session Initiation Protocol Request-Line: REGISTER sip:obelix.feld.cvut.cz SIP/2.0 Message Header Via: SIP/2.0/UDP 147.32.126.85:37714;branch=z9hG4bK-d87543Contact: <sip:
[email protected]:37714;rinstance=fc00cd7929eeebc7> To: "Michal Obelix"<sip:
[email protected]> From: "Michal Obelix"<sip:
[email protected]>;tag=de7d316b Call-ID: OGYyNzM2ODI3YWUwMmJhOTgxZmE5N2ExM2RmYTc2OGE. CSeq: 1 REGISTER Po pˇrijet´ı t´eto zpr´avy je tedy uˇzivatel pˇripojen na dan´e adrese a tam m˚ uˇze pˇrij´ımat hovory. Register request obsahuje contact header: IP adresa zaˇr´ızen´ı(pro softwarov´e i hardwarov´e telefony). Kdyˇz proxy obdrˇz´ı poˇzadavek o spojen´ı hovoru(INVITE), vyhled´a dle dan´e adresy zda m´a pˇr´ımo spojit uˇzivatele a nebo zpr´avu pˇreposlat d´ale. V tomto pˇr´ıpadˇe uˇzivatel s ˇc´ıslem 100 je dosaˇziteln´ y na IP adrese 147.32.126.85. Pˇri ˇz´adosti o hovor Asterisk server pˇrepoˇsle INVITE request na danou IP adresu. Abysme se mohli zaregistrovat na ciz´ı u ´ˇcet, je potˇreba nejprve odstavit dan´eho uˇzivatele, ide´alnˇe DoS u ´tokem. D´ale je potˇreba zruˇsit mu registraci na serveru, v konkr´etn´ım pˇr´ıpadˇe Asterisku. Zruˇ sen´ı registrace: Session Initiation Protocol Via: SIP/2.0/UDP 147.32.126.85;branch=z9hG4bK-d87543-1b2243423423 From: "Michal Obelix" <sip:
[email protected]>;tag=pwQNDXsOiw To: "Michal Obelix" <sip:
[email protected]> Call-ID:
[email protected] CSeq: 123456 REGISTER Contact: * Expires: 0 D˚ uleˇzit´e je vˇsimnout si paramatr˚ u Contact a Expires. Pˇriˇrazen´e hodnoty zp˚ usob´ı zruˇsen´ı registrace dan´emu uˇzivateli. V posledn´ım kroku jsem vygeneroval nov´ y REGISTER paket pomoc´ı programu SiVuS. Asterisk odpovˇedˇel na registraci bez jak´ ychkoliv probl´em˚ u. REGISTER request vygenerovan´ y SiVuSem:
´ ´I VOIP KLIENTU ˚ A SERVERU ˚ PRAKTICKY KAPITOLA 9. TESTOVAN
59
Session Initiation Protocol Request-Line: REGISTER sip:147.32.201.163 SIP/2.0 Message Header Via: SIP/2.0/UDP 147.32.126.85;branch=z9hG4bK-d87543-1b2243423423 From: "Michal Obelix" <sip:
[email protected]>;tag=pwQNDXsOiw To: "Michal Obelix" <sip:
[email protected]> Call-ID:
[email protected] CSeq: 123456 REGISTER Contact: <sip:
[email protected]> Tato zpr´ava je velmi podobn´a zpr´avˇe pˇredchoz´ı, kromˇe adresy v Contact header, kde je adresa 147.32.126.86, coˇz je IP adresa hackera. Takto velmi jednoduˇse m˚ uˇzeme pˇrij´ımat hovory, kter´e byly p˚ uvodnˇe urˇceny pro adresu 147.32.126.85. Pˇri generov´an´ı dan´eho paketu jsem tak´e zkouˇsel n´ahodnˇe zvolit hodnoty parametr˚ u tag, branch, call id, cseq a na registraci to nemˇelo ˇz´adn´ y dalˇs´ı vliv. Opˇet probˇehla bez probl´em˚ u. Pro u ´ plnost uv´ ad´ım potvrzen´ı registrace od Asterisku - OK: Session Initiation Protocol Status-Line: SIP/2.0 200 OK Status-Code: 200 Message Header From: "Michal Obelix" <sip:
[email protected]>;tag=pwQNDXsOiw To: "Michal Obelix" <sip:
[email protected]>;tag=as63d55728 Call-ID:
[email protected] CSeq: 123456 REGISTER User-Agent: Asterisk PBX 1.6.0-beta8 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY Supported: replaces, timer Expires: 60 Contact: <sip:
[email protected]>;expires=60 Contact Binding: <sip:
[email protected]>;expires=60 URI: <sip:
[email protected]> SIP contact address: sip:
[email protected]
Na obr´azku 9.1 je zobrazen pˇr´ıklad pr˚ ubˇehu u ´toky na registraci, akceptaci PROXY serverem a pˇr´ıklad hovoru. 9.4.2
Pˇ ri zapnut´ e autentizaci
Pˇri zapnut´e autentizaci je situace mnohem sloˇzitˇejˇs´ı a registraci se mi nepodaˇrilo nabourat. Postup registrace na Asterisk a SER pˇ ri zapnut´ e autentizaci. 1. klient zaˇsle register paket
´ ´I VOIP KLIENTU ˚ A SERVERU ˚ PRAKTICKY KAPITOLA 9. TESTOVAN
60
Obr´azek 9.1: Pˇr´ıklad u ´toku REGISTRATION hijacking 2. Server odpov´ı s k´odem 401, kdy ˇz´ad´a MD5 autorizaci, z´aroveˇ n pos´ıl´a parametry nonce a realm nutn´e pro v´ ypoˇcet digestu. 3. klient zaˇsle sv˚ uj MD5 register paket 4. server potvrd´ı 200 OK, u ´spˇeˇsn´a registrace. Pˇri bliˇzˇs´ı anal´ yze pomoc´ı Wiresharku jsem zkouˇsel zjistit heslo d´ıky znalostem nonce a realm parametr˚ u. Heslo se mi z´ıskat nepodaˇrilo. Pomoc´ı HijackRegistration Tool 1 lze zjistit heslo, kter´e je kryptov´ano pomoc´ı MD5. Dan´ y n´astroj vˇsak vyuˇz´ıv´a slovn´ıku, ve kter´em jsou uvedena hesla, obvykle pˇrednastaven´a v´ yrobcem. T´ım je jeho funkˇcnost velmi omezena a nelze ho vyuˇz´ıt pˇri neznalosti hesla. Pouˇzit´ım MD5 lze autentizaci zabezpeˇcit velmi spolehlivˇe. D˚ uleˇzit´e je dodrˇzovat obecnˇe doporuˇcen´e postupy, aby nebylo moˇzn´e vyuˇz´ıt slovn´ıkov´ ych metod pro dekryptov´an´ı MD5hashe. Dekryptov´an´ı MD5hashe je moˇzn´e v nezabezpeˇcen´e s´ıti obej´ıt prostˇrednictv´ım MiTM u ´toku, kdy mˇen´ıme IP adresu c´ılov´eho uˇzivatele na svoji a t´ım dojde k zaregistrov´an´ı na n´aˇs telefon.
9.5
Odposlouch´ av´ an´ı RTP paket˚ u
Pro jednoduch´e odposlouch´av´an´ı audio dat lze pouˇz´ıt program Wireshark. postup: • Nastavit filtr na sledov´an´ı RTP paket˚ u a spustit naˇc´ıt´an´ı paket˚ u a po ˇcase zastavit • Po ukonˇcen´ı naˇc´ıt´an´ı si pomoc´ı menu Statistics, RTP, Show All Streams zobrazit jednotliv´e RTP toky. 1
http://www.hackingvoip.com/tools/reghijacker.tar.gz
´ ´I VOIP KLIENTU ˚ A SERVERU ˚ PRAKTICKY KAPITOLA 9. TESTOVAN
61
• Vybr´an´ım Analyze Session lze dan´ y hovor analyzovat • Vybr´an´ım jednoho toku a zvolen´ım Save m˚ uˇzeme dan´ y tok, pokud je pouˇzit kodek G.711, uloˇzit do souboru .au, kter´e m˚ uˇzeme pˇrehr´at napˇr. pomoc´ı Winampu. • V ybr´an´ımStatistics, RTP, VoIP calls n´am zobraz´ı jednotliv´e hovory. • Vybr´an´ım Player, Decode, Play lze dan´ y hovor pˇrehr´at, pˇr´ıpadnˇe analyzovat jeho jednotliv´e kan´aly Z´aznam takov´eho hovoru je pˇriloˇzen na DVD. Pˇred odposlouch´av´an´ım je obvykle nutn´e prov´est MitM u ´tok, napˇr pomoc´ı programu Cain.
9.6
Zruˇ sen´ı sestaven´ eho hovoru
Pokud chceme zruˇsit jiˇz prob´ıhaj´ıc´ı hovor, je potˇreba vytvoˇrit SIP zpr´av˚ u, kter´a obsahuje ’ metody BYE. SIP BYE lze odeslat bud pˇr´ımo na dan´ y telefon, a nebo obvykle pˇres proxy server. Jak se dan´ y paket pos´ıl´a zaleˇz´ı na parametru Recourd-Route. Ten je v hlaviˇcce SIP zpr´avy a je d˚ uleˇzit´ y pro tarifikaci hovor˚ u. Aby byl tento paket pˇrijat, je potˇreba dodrˇzet stejn´ y identifik´ator hovoru, kter´ ym je Call-ID, d´ale parametry FromTag a ToTag. Jednou z moˇznost´ı jak vytvoˇrit dan´ y paket je z´ıskat paket ACK, v kter´em je potˇreba zmˇenit hodnotu ACK na BYE [12]. Tento paket lze napˇr. vyuˇzit´ım programu SiVuS poslat c´ılov´e stranˇe a ukonˇcit hovor. Dalˇs´ı, jeˇstˇe jednoduˇsˇs´ı moˇznost´ı je vyuˇzit programu TearDown do autor˚ u knihy Hacking VoIP exposed [14], kter´ y vytvoˇr´ı dan´ y paket na z´akladˇe znalosti Call-ID, FromTag, ToTag. Nejjednoduˇsˇs´ı pˇr´ıklad vyuˇzit´ı programu TearDown 1 : ./teardown eth Call-ID FromTag ToTag Klient nekontroluje parametr branch, kter´ y by mˇel jedineˇcnˇe identifikovat transakci mezi u ´ˇcastn´ıky. Parametr tag, kter´ y je n´ahodnˇe generov´an pro identifikaci c´ıle m˚ uˇze z˚ ustat stejn´ y. Proto lze vyuˇz´ıt paket s metodou ACK a drobnˇe jej modifikovat. Ochrana proti tomuto u ´toku nen´ı jednoduch´a. Pˇri pos´ıl´an´ı BYE zpr´avy nedoch´az´ı k ˇ sen´ım je zajistit, aby autorizaˇcn´ımu procesu a proto lze BYE zpr´avu snadno odeslat. Reˇ strana, kter´a pˇrij´ım´a BYE zpr´avy, mˇela jistotu, ˇze zpr´ava poch´az´ı od dan´eho uˇzivatele. To lze zajistit napˇr. pouˇzit´ım TLS.
9.7
Moˇ znosti obrany
To, jak se br´anit proti pˇredstaven´ ym u ´tok˚ um, jsem jiˇz psal v kapitolo 5. Jiˇz pˇri dodrˇzen´ı tˇechto 3 doporuˇcen´ı - rozdˇelit s´ıt’ na jednotliv´e VLANy, zapnout vˇsude autorizaci a pouˇz´ıt protokolu TCP m´ısto UDP. T´ım pokryjeme cca 80% vˇsech zraniteln´ ych m´ıst v syst´emu. Pro dalˇs´ı moˇznosti je nutn´e vyuˇz´ıt sofistikovanˇejˇs´ıch moˇznost´ı jako je VoIP firewall, NIPS atd. 1
http://www.hackingvoip.com/tools/teardown.tar.gz
62
9.8
´ ´I VOIP KLIENTU ˚ A SERVERU ˚ PRAKTICKY KAPITOLA 9. TESTOVAN
Z´ avˇ er
V t´eto kapitole jsem se pokusil chovat jako hacker a uk´azat zranitelnost SIP protokolu. ´ Utoky na SIP protokol jsou obl´ıben´e zejm´ena kv˚ uli tomu, ˇze SIP je textov´ y protokol a t´ım p´adem je jednoduˇsˇs´ı odchyt´avat a vytv´aˇret SIP pakety. Existuje spousta testovac´ıch n´astroj˚ u, kter´ ych lze vyuˇz´ıt k u ´tok˚ um, proto jsem s´am ˇz´adn´ y program nenapsal a snaˇzil se vyuˇz´ıt jiˇz existuj´ıc´ıch moˇznost´ı. Nejvˇetˇs´ı nebezpeˇc´ı jak pro servery tak pro koncov´e u ´ˇcastn´ıky hroz´ı od u ´toku typem invite floods. Pro tˇri ze ˇctyˇr testovan´ ych klient˚ u znamenal kr´atk´ yu ´tok zhroucen´ı telefonu. U serverov´ ych ˇreˇsen´ıch SIP express router u ´tok pˇreˇzil, u Asterisku doˇslo k jeho zahlcen´ı a n´asledn´emu zhroucen´ı. ´ Utoky na registraci jsou snadn´e pouze v pˇr´ıpadˇe, ˇze se nepouˇz´ıv´a autentizace. Jakmile se autentizace zapne, je potˇreba pouˇz´ıt sofistikovanˇejˇs´ıch metod pro napaden´ı. Stejn´a situace nast´av´a pˇri pokusu o n´asiln´e ukonˇcen´ı hovoru. Odposlouch´av´an´ı je velmi snadn´e, pro jeho proveden´ı se vˇsak ciz´ı u ´toˇcn´ık mus´ı dostat do infrastruktury s´ıtˇe, a tomu lze velmi u ´ˇcinnˇe br´anit. Testovan´e u ´toky pˇredstavuj´ı jen zlomek toho, jak m˚ uˇzeme testovat zabezpeˇcen´ı SIP VoIP infrastruktury. Nejjednoduˇsˇs´ı zp˚ usob jak zaˇc´ıt s u ´tokem je prov´est anal´ yzu programem SiVuS a podle v´ ysledk˚ u zaˇc´ıt s u ´tokem. Vzhledem k tomu, ˇze jsou zde uvedeny konkr´etn´ı n´avody jak za´ utoˇcit na SIP protokol, jako autor toho textu nenesu ˇz´adnou zodpovˇednost za pˇr´ıpadn´e ˇskody zp˚ usoben´e vyuˇzit´ım dan´ ych n´avod˚ u.
ˇ ´I PROTI DOS POMOC´I SYSTEMU ´ KAPITOLA 10. ZABEZPECEN SNORT
63
10 Zabezpeˇ cen´ı proti DoS pomoc´ı syst´ emu SNORT V minul´e kapitole jsem se vˇenoval testov´an´ı SIP server˚ u a telefon˚ u. Uk´azal jsem jak pomoc´ı open source n´astroj˚ u prov´est INVITE floods u ´tok a t´ım shodit bud’ SIP server anebo SIP telefon. Modern´ı switche/routery maj´ı implementovan´e mechanismy jak se ochr´anit syst´em proti D/DoS u ´tok˚ um. Tyto mechanismy jsou obecn´eho r´azu a zat´ım je nen´ı moˇzn´e plnˇe vyuˇz´ıt ve VoIP. Dalˇs´ım u ´kolem bylo zprovoznit TLS pod verz´ı Asterisku 1.6. Jako jednu z variant, jak vytvoˇrit ochranu pro DoS, jsem zvolil program SNORT.
10.1
Popis situace
Automatizovn´e call centrum (ACC) je novinkou od firmy IBM. Syst´em umoˇzn ˇuje vytvoˇren´ı vlastn´ıho firemn´ıho call centra, kter´ y je kompletnˇe ovl´ad´an hlasem. Syst´em se skl´ad´a ze tˇr´ı hlavn´ıch prvk˚ u obr: 10.1.
Obr´azek 10.1: Architektura automatizovan´eho call centra od IBM
• Asterisk server - star´a se o komunikaci mezi koncov´ ymi u ´ˇcastn´ıky a Voice Enabler server • Voice Enabler - spravuje hovor od Asterisku, transformuje hovor do VXML a d´ale pˇred´av´a Voice Serveru • Voice Server - prov´ad´ı v´ ykonnou ˇc´ast call centra, odpov´ıd´a na dotazy od Voice Enableru Veˇsker´a komunikace od koncov´ ych uˇzivatel˚ u prob´ıh´a prostˇrednictv´ım u ´stˇredny Asterisk. Jak jsem uk´azal v minul´e kapitole, Asterisk je velmi citliv´ y na INVITE flood u ´tok proto je potˇreba tento server patˇriˇcnˇe zabezpeˇcit. CIA pro koncov´eho uˇzivatele je zajiˇstˇena protokolem TLS a SRTP. Podpora TLS pro Asterisk je novinkou od u ´nora 2008 a lze od jeho tv˚ urc˚ u oˇcek´avat velk´e mnoˇzstv´ı bezpeˇcnostn´ıch aktualizac´ı.
64
ˇ ´I PROTI DOS POMOC´I SYSTEMU ´ KAPITOLA 10. ZABEZPECEN SNORT
10.2
Ochrana proti DoS - Snort Inline
Snort [8] je open source NIDS a NIPS. Prov´ad´ı anal´ yzu protokol˚ u, vyhled´av´an´ı-porovn´an´ı obsahu paket˚ u a je bˇeˇznˇe pouˇz´ıv´an pro blokov´an´ı r˚ uzn´ ych u ´tok˚ u - buffer overflows, port scans, u ´toky na webov´e aplikace, OS fingerprinting apod. V´ıce neˇz jako NIDS je vyuˇzit jako NIPS pro zahazov´an´ı pr´avˇe tˇechto paket˚ u. Lze ho vyuˇz´ıt v kombinaci SnortSnarf, pˇr´ıpadnˇe s Basic Analysis and Security Engine (BASE), kter´ y nab´ız´ı vizualizaci representace zaznamenan´ ych dat a snadnˇejˇs´ı nastaven´ı syst´emu prostˇrednictv´ım webov´eho rozhran´ı. Snort je NIDS n´astroj, tzn ˇze pouze zachyt´av´a anom´alie, d´ale je ale neum´ı zpracovat, pˇr´ıpadnˇe zahodit. K tomu slouˇz´ı jeho rozˇs´ıˇren´ı Snort inline. Snort inline komunikuje s IPtables a na z´akladˇe shody pravidel umoˇzn ˇuje zahozen´ı podezˇrel´eho paketu. Snort inline zat´ım neum´ı zpracovat a zahazovat skupiny stejn´ ych paket˚ u a to znemoˇzn ˇuje jeho ˇsirˇs´ı vyuˇzit´ı ve VoIP syst´emech. 10.2.0.1
Konfigurace Snort Inline
Jak jsem uvedl dˇr´ıve, Snort inline komunikuje s IPtables prostˇredn´ıctv´ım modulu IP QUEUE. IPtables na z´akladˇe pravidel pos´ılaj´ı pakety tomuto modulu, Snort inline postupnˇe ˇcte tyto pakety a vyhodnocuje dle dan´ ych pravidel. Pˇr´ıklad pˇr´ıkazu pro IPtables, aby vˇsechny UDP pakety vstupuj´ıc´ı do portu 5060 byly pˇresmˇerov´any do modulu IP QUEUE. iptables -I INPUT -p udp --dport 5060 -j QUEUE Snort inline vyhodnocuje vˇsechny pakety v modulu IP QUEUE dle dan´eho pravidla. drop udp $EXTERNAL-NET any -> HOME-NET 5060 (msg:"Malicious traffic" \ content: "/bin/bash"; sid:25001;) popis pravidla: • drop - zahod’ paket, kter´ y odpov´ıd´a pravidlu • udp - typ protokolu • EXTERNAL-NET - paket z vnˇejˇs´ı s´ıtˇe • any - zdrojov´ y port • HOME-NET - dom´ac´ı s´ıt’ • 5060 - c´ılov´ y port • v z´avork´ach je uvedeno znˇen´ı pravidla, dle dan´eho pravidla je zahozen kaˇzd´ y paket z vnˇejˇs´ı s´ıtˇe smˇeˇruj´ıc´ı na port 5060 a obsahuje text ”/bin/bash”. • sid - ˇc´ıslo pravidla
ˇ ´I PROTI DOS POMOC´I SYSTEMU ´ KAPITOLA 10. ZABEZPECEN SNORT
10.3
65
Implementace zabezpeˇ cen´ı a testov´ an´ı
Snort inline nenab´ız´ı zat´ım ˇz´adn´e sofistikovan´e ˇreˇsen´ı jak u ´ˇcinnˇe ochr´anit VoIP syst´em proti u ´tok˚ um typu DoS, pˇresto vˇsak dok´aˇze eliminovat u ´toky typu buffer overflow nebo fuzzing floods. Experiment´alnˇe jsem implementoval pravidla na ochranu proti: • u ´toku z vnˇejˇs´ı s´ıtˇe • intrukc´ım assembleru • logick´ ym operand˚ um • flag˚ um jazyka C/C++ • nestandardn´ım znak˚ um • pˇr´ıkaz˚ um linuxu (rm -f) ˇ ast pravidel je pro uvedena v pˇr´ıloze. C´
10.4
Testov´ an´ı
K testov´an´ı jsem opˇet pouˇzil program SIPp, kde jsem do poloˇzky subject psal jednotliv´e moˇznosti a otestoval jejich funkˇcnost. Dle pˇredpoklad˚ u vˇsechny pakety byly zahozeny a ˇz´adn´ y z nich se k Asterisku nedostal.
10.5
Z´ avˇ er
Komplexnˇe zabezpeˇcit cel´ y VoIP syst´em d´a jeˇstˇe velkou spoustu pr´ace. Invite floods u ´toky nejsou nebezpeˇcn´e nejen kv˚ uli zahlcen´ı syst´emu, ale i pro jejich spoleˇcensk´ y dopad. Telefon zasaˇzen´ y i t´ım nejmenˇs´ım DoS u ´tokem nekoneˇcnˇe zvon´ı. Koncov´ y uˇzivatel m˚ uˇze bud’ vypojit telefon, nebo ztlumit vyzv´anˇen´ı a ˇcekat, kdy u ´tok skonˇc´ı. Jak automaticky ochr´anit koncov´e uˇzivatele proti nekoneˇcn´emu vyzv´anˇen´ı je st´ale jeˇstˇe ve v´ yvoji. Pravdˇepodobnˇe je moˇzn´e vyuˇz´ıt statistik z dˇr´ıvˇejˇs´ıho provozu nebo metod pouˇz´ıvan´ ych na ochranu proti SPAMu. Jak jsem uvedl dˇr´ıve, Snortu sch´az´ı pravidlo pro vyhodnocov´an´ı softwaru pomoc´ı statistik z pˇredchoz´ıch paket˚ u. Pˇri existenci tohoto pravidla je moˇzn´e u ´ˇcinnˇe eliminovat poˇcty pˇr´ıchoz´ıch paket˚ u a t´ım i zat´ıˇzen´ı serveru (Asterisku). Mnou implementovan´e ochrann´e ˇreˇsen´ı je pouze jak´ ymsi z´akladn´ım kamenem na ochranu cel´eho syst´emu ACC a pro u ´pln´e zabezpeˇcen´ı zb´ yv´a jeˇstˇe vyˇreˇsit spoustu probl´em˚ u.
66
ˇ ´I PROTI DOS POMOC´I SYSTEMU ´ KAPITOLA 10. ZABEZPECEN SNORT
´ ER ˇ KAPITOLA 11. ZAV
67
11 Z´ avˇ er Poˇcet u ´tok˚ u na VoIP s´ıtˇe kaˇzd´ ym rokem velmi rychle pˇrib´ yv´a. Hackeˇri a dalˇs´ı u ´toˇcn´ıci vyuˇz´ıvaj´ı slab´ ych m´ıst v nov´e technologii komunikace. Pˇrestoˇze je bezpeˇcnost jedn´ım z nejd˚ uleˇzitˇejˇs´ıch t´emat v oblasti VoIP, tv˚ urci VoIP technologi´ı nepˇrikl´adali zajiˇstˇen´ı bezpeˇcnosti takov´ y d˚ uraz. Nejprve byl vyvinuta stabiln´ı VoIP technologie a teprve v posledn´ıch tˇrech, ˇctyˇrech letech je kladen d˚ uraz i na zajiˇstˇen´ı maxim´aln´ı m´ıry bezpeˇcnosti. Kaˇzd´a z VoIP technologi´ı je specifick´a, a proto vyˇzaduje bezpeˇcnostn´ı ˇreˇsen´ı urˇcen´e pˇr´ımo pro danou technologii. Z v´ ysledk˚ u anal´ yzy technologi´ı vypl´ıv´a: Pokud je pouˇzit protokol SIP, je nejlepˇs´ı moˇznost´ı, jak vˇse zabezpeˇcit, pouˇzit´ı protokolu TLS. TLS protokol je standardn´ım bezpeˇcnostn´ım mechanismem pracuj´ıc´ım na p´at´e vrstvˇe OSI modelu a jeho spolehlivost byla jiˇz prax´ı dok´az´ana. Pro protokol H.323 je definov´ano nˇekolik bezpeˇcnostn´ıch profil˚ u, kter´e jsou vhodn´e pro r˚ uznˇe velk´e s´ıtˇe. Profily vyuˇz´ıvaj´ı zn´ame kryptovac´ı algoritmy a hashovan´ı fce (RSA, AES, MD5). Opˇet tedy existuj´ı v´ ykonn´e prostˇredky jak zabezpeˇcit VoIP provoz pro koncov´e uˇzivatele. Pˇri spojov´an´ı velk´ ych prvk˚ u VoIP infrastruktury se vyuˇz´ıv´a protokol˚ u MGCP, MEGACO/H.248, pˇr´ıpadnˇe IAX. Aˇz na protokol IAX, tyto protokoly nemaj´ı definov´anu ˇz´adnou vnitˇrn´ı ochranu dat a spol´ehaj´ı na zabezpeˇcen´ı dat na s´ıt’ov´e vrstvˇe. Nejˇcastˇeji doporuˇcovan´ ym ˇreˇsen´ım je zabezpeˇcen´ı prostˇrednictv´ım IPsec, pˇr´ıpadnˇe VPN. Vzhledem k tomu, ˇze VoIP je mlad´a technologie, doˇslo ke vzniku nov´ ych softwar˚ u poskytuj´ıc´ı bezpeˇcnost v t´eto oblasti. Nejd˚ uleˇzitˇejˇs´ı je tzv. VoIP firewall. Vyuˇzit´ı NIPS syst´em˚ u pro VoIP je st´ale ot´azkou ˇcasu a v´ yvoje. Existuj´ıc´ı protokoly (technologie) poskytuj´ı moˇznosti k zabezpeˇcen´ı VoIP syst´em˚ u. ´ Ukolem v´ yrobc˚ u VoIP zaˇr´ızen´ı je tyto technologie podporovat i implementovat do sv´ ych zaˇr´ızen´ı. Dalˇs´ı ˇc´ast odpovˇednosti za zajiˇstˇen´ı bezpeˇcnosti spad´a na poskytovatele VoIP pˇripojen´ı. U klasick´e PSTN s´ıtˇe nikoho nenapadlo ˇreˇsit ot´azky bezpeˇcnosti a je tomu stejnˇe tak u VoIP technologi´ı. Je u ´kolem poskytovatel˚ u pˇrimˇet sv´e klienty bezpeˇcnost ’ pouˇz´ıvat. Sami tak´e mus´ı zajistit svou s´ıt tak, aby byl u ´tok v maxim´aln´ı moˇzn´e m´ıˇre. Ve druh´e ˇc´ast´ı pr´ace jsem se vˇenoval protokolu SIP a snaˇzil pouk´azat na jeho slabiny. Prostˇrednictv´ım DoS u ´toku se mi u ´spˇeˇsnˇe podaˇrilo zablokovat softwarov´e telefony a SIP server Asterisk. Zejm´ena u Asterisku je toto zjiˇstˇen´ı znepokojuj´ıc´ı, jelikoˇz je velmi rozˇs´ıˇren a z´ısk´av´a st´ale vˇetˇs´ı popularitu. D´ale se mi podaˇrilo prok´azat jak jednoduˇse odposlechnout hovor, jak snadno lze nˇekomu zruˇsit jeho registraci a zaregistrovat se na jeho u ´ˇcet a zruˇsit pr´avˇe prob´ıhaj´ıc´ı hovor. Vˇsechny tyto u ´toky maj´ı spoleˇcnou jednu vlastnost nedodrˇzen´ı obecn´ ych z´asad k zabezpeˇcen´ı s´ıt´ı. Tˇret´ı a z´avˇereˇcn´a ˇc´ast pr´ace je experiment´aln´ı. Invite flood u ´tok nen´ı jen hrozbou pro software, ale tak´e pro koncov´eho uˇzivatele. Pˇr´ıdavn´ ym efektem toho u ´toku je neust´al´e zvonˇen´ı telefonn´ıho pˇr´ıstroje bez jak´ekoliv moˇznosti tento u ´tok zastavit. Navrˇzen´e ˇreˇsen´ı tento probl´em ˇc´asteˇcnˇe ˇreˇs´ı, s velk´ ym mnoˇzstv´ım omezen´ı. Pokraˇcov´an´ı ve v´ yvoji moˇzn´eho ˇreˇsen´ı bude souˇc´ast´ı m´e dalˇs´ı pr´ace v RDC. Obecn´e ˇreˇsen´ı toho probl´emu pro oblast VoIP je st´ale jeˇstˇe ve v´ yvoji ve svˇetov´ ych laboratoˇr´ıch.
68
´ ER ˇ KAPITOLA 11. ZAV
KAPITOLA 12. LITERATURA
69
12 Literatura [1] H.323 definition and overview. http://www.iec.org/online/tutorials/h323/. [2] Wikipedia, the free encyclopedia. http://www.wikipedia.org. [3] Inter asterisk exchange version 2, 2008. http://tools.ietf.org/html/draft-guy-iax-04. [4] Ip security, 2008. http://www.tcpipguide.com/free/t_IPSecurityIPSecProtocols.htm. [5] Sdp: Session description protocol, 2008. http://tools.ietf.org/html/rfc4566. [6] Skype - take a deep breath, 2008. http://www.skype.com/. [7] Skype security resource center, 2008. http://www.skype.com/security/. [8] Snort - the de facto standard for intrusion detection/prevention, 2008. http://www.snort.org/. [9] Telefonie - wikipedie, 2008. http://www.czela.net/wiki/index.php/Telefonie. [10] Voice over ip security alliance, 2008. http://www.voipsa.org/. [11] Zfone - project home page, 2008. http://zfoneproject.com/. [12] Daniel Cvrˇcek, Michal Sedl´ak. In Datakon 2006, Sborn´ık datab´ azov´e konference, pages 239–249. Masarykova univerzita, Brno, 2006. [13] David Endler, Dipak Ghosal, Reza Jafari, Akbal Karlcut, Marc Kolenko, Nhut Nguyen, Wil Walkoe, Jonathan Zar. Voip security and privacy threat taxonomy, 2005. http://www.voipsa.org/Activities/VOIPSA_Threat_Taxonomy_0.1.pdf. [14] David Endler, Mark Collier. http://www.hackingvoip.com/.
Hacking
[15] F. Andreasen, B. Foster. Media http://tools.ietf.org/html/rfc3435.
voip
gateway
exposed, control
2008.
protocol.
[16] F. Cuervo, N. Greene, A. Rayhan, C. Huitema, B. Rosen, J. Segers. Megaco/h.248. http://www.itu.int/rec/T-REC-H/e —http://tools.ietf.org/html/rfc3015—. [17] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson. Realtime transport protocol, 2008. http://www.faqs.org/rfcs/rfc1889.html. [18] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, E. Schooler. Sip: Session initiation protocol. http://www.ietf.org/rfc/rfc3261.txt. [19] L. Ong, J. Yoakum. Stream control http://tools.ietf.org/html/rfc3286.
transmission
protocol,
2008.
[20] Gordon Lyon. Nmap - free security scanner for network exploration, security audits, 2008. http://nmap.org/.
70
KAPITOLA 12. LITERATURA
[21] M. Baugher, D. McGrew, M. Naslund, E. Carrara, K. Norrman. The secure real-time transport protocol (srtp), 2008. http://tools.ietf.org/html/rfc3711. [22] Skupina oxid.it. Cain abel, 2008. http://www.oxid.it/cain.html. [23] Richard Kuhn, Thomas J. Walsh, Steffen Fries. Security considerations for voice over ip systems. http://csrc.nist.gov/publications/nistpubs/800-58/SP800-58-final.pdf. [24] P. Saint-Andre. Extensible messaging and presence protocol (xmpp). http://tools.ietf.org/html/rfc3921. [25] M. Sedl´ak. Moˇznosti zabezpeˇcen´ı ip telefonie, 2006. http://www.buslab.org/index.php?option=com_remository&Itemid=33&func=s. [26] Mark Spencer. Inter-asterisk exchange. http://www.voip-info.org/wiki-IAX. [27] Tim Polk, Pasi Eronen. Transport layer http://www.ietf.org/html.charters/tls-charter.html.
security,
2008.
[28] P. Zimmermann. Zrtp: Media path key agreement for secure rtp, 2008. http://zfoneproject.com/docs/ietf/draft-zimmermann-avt-zrtp-06x.html.
ˇ YCH ´ DODATEK A. SEZNAM POUZIT ZKRATEK
A Seznam pouˇ zit´ ych zkratek ACC automatizovan´e call centrum ASTERISK Softwarov´a poboˇckov´a u ´stˇredna CA Certifikaˇcn´ı autorita CIA d˚ uvˇernost, integrita, autentiˇcnost (Confidentiality, Integrity and Availability) DOS Denial of Service DDOS Distribuated Denial of Service E2E end to end security H.323 Protokol doporuˇcen´ y ITU-T IAX Inter Asterisk eXchange IDS Network Intrusion Detection System IETF Internet Engineering Task Force IM Instant Messaging, Instant Messenger IPS Intrusion Prevention System IPsec IP security ITU-T International Telecommunication Union MD5 Message-Digest algorithm 5 MGCP Media Gateway Control Protocol NIST National Institute of Standards PBX Poboˇckov´a u ´stˇredna RFC Request for Command RTP Real Time Protocol SDP Session Description Protocol SIP Session Initation Protocol SPIT Spam over VoIP - spam s vyuˇz´ıt´ım VoIP SRTP Secure RTP SSL Secure Socket Layer TLS Transport Layer Security
71
72
ˇ YCH ´ DODATEK A. SEZNAM POUZIT ZKRATEK
UA User Agent UAC User Agent Client UAS User Agent Server URI Uniform Resource Identificator VPN Virtual Private Network
´ ´ DODATEK B. NASTROJE PRO UTOKY
73
B N´ astroje pro u ´ toky B.1
Wireshark
Poˇc´ıtaˇcov´a aplikace Wireshark (dˇr´ıve Ethereal) je protokolov´ y analyzer a paketov´ y sniffer. Mezi jeho nejˇcastˇejˇs´ı pouˇzit´ı patˇr´ı anal´ yza a ladˇen´ı probl´em˚ u v poˇc´ıtaˇcov´ ych s´ıt´ıch, v´ yvoj software, v´ yvoj komunikaˇcn´ıch protokol˚ u a studium s´ıt’ov´e komunikace. Wireshark nab´ız´ı velice podobn´e funkce jako tcpdump, nav´ıc vˇsak obsahuje grafick´e uˇzivatelsk´e rozhran´ı a mnoho moˇznost´ı uspoˇr´ad´an´ı a filtrov´an´ı zobrazen´ ych informac´ı. ’ Aplikace um´ı pˇrepnout s´ıt ovou kartu do promiskuitn´ıho reˇzimu a d´ıky tomu dok´aˇze zachyt´avat veˇskerou komunikaci na pˇripojen´em m´ediu. Wireshark je uvolnˇen´ y pod open source licenc´ı. Je podporovan´ y na Windows, Unixu a kompatibiln´ıch syst´emech vˇcetnˇe Linuxu, Solarisu, FreeBSD, NetBSD, OpenBSD a Mac OS X (pouze s X Serverem).
B.2
SIPp - v´ ykonnostn´ı tester pro SIP servery
SIPp je open source v´ ykonnostn´ı tester pro SIP servery. SIPp pos´ıl´a SIP zpr´avy a dok´aˇze pˇrij´ımat reagovat na odpovˇedi SIP serveru. Simuluje bud’ UAC nebo UAS a s jeho pomoc´ı lze vytv´aˇret sc´en´aˇre hovoru, pˇr´ıpadnˇe i simulovat prob´ıhaj´ıc´ı hovor. Sc´en´aˇre jsou definov´any v XML. D´ale je moˇzn´e generovat statistiky ohlednˇe hovoru,statistiky odeslan´ ych/pˇrijat´ ych paket˚ u atd.
B.3
SiVus - The VoIP Vulnerability Scanner
Javovsk´a aplikace vyvinut´a skupinou www.voipsa.org. Velmi komplexn´ı aplikace, umoˇzn ˇuje testovat SIP servery z hlediska bezpeˇcnosti a upozornit na pˇr´ıpadne nedostatky. Nejduleˇzitˇejˇs´ı funkce: • kontrola buffer overflow • kontrola autentiˇcnost • kryptov´an´ı • generov´an´ı SIP zpr´av - INVITE, REGISTRATION • podrobn´e reporty v HTML • atd Sivus je velmi obl´ıben mezi spr´avci SIP server˚ u, jelikoˇz umoˇzn ˇuje testovat jednoduˇse, ale pˇritom velmi komplexnˇe. P˚ uvodnˇe byl vyvinut pouze pro protokol SIP, v souˇcasn´e verzi 1.10 je snaha o roˇzˇs´ıˇren´ı o protokoly H.323 a MGCP. Zat´ım toho jeˇstˇe nebylo dosaˇzeno.
´ ´ DODATEK B. NASTROJE PRO UTOKY
74
B.4
Cain Abel
Cain Abel [22] pom´ah´a pˇredevˇs´ım spr´avc˚ um s´ıt´ı a zkuˇsen´ ym uˇzivatel˚ um obnovit r˚ uzn´a pˇr´ıstupov´a hesla. Ke zjiˇstˇen´ı hesel slouˇz´ı mimo jin´e i zabudovan´ y sniffer pro odposlouch´av´an´ı vˇetˇsiny s´ıt’ov´ ych protokol˚ u, podobnˇe jako ve Wiresharku. Program podporuje i ˇsifrovan´e protokoly SSH-1 a HTTPS, zjistit lze napˇr´ıklad i hesla, kter´a jsou skyt´a za hvˇezdiˇckami nebo r˚ uzn´e hash k´ody atd. Lze ho tak´e vyuˇz´ıt pro MiTM u ´toky, prostˇrednictv´ım ARP poisoning.
B.5
Nmap
Nmap [20] je velmi siln´ y a komplexn´ı scanovac´ı n´astroj speci´alnˇe vyvinut´ y pro agresivn´ı prohled´av´an´ı extr´emnˇe rozs´ahl´ ych s´ıt´ı. Zvl´ad´a des´ıtky r˚ uzn´ ych technik a obsahuje velmi rozs´ahlou datab´azi sluˇzeb i operaˇcn´ıch syst´em˚ u. Ta v souˇcasn´e dobˇe obsahuje 1500 poloˇzek. Kromˇe klasick´eho skenov´an´ı port˚ u zvl´ad´a tak´e detekci vzd´alen´eho operaˇcn´ıho syst´emu. Nmap se vyuˇz´ıv´a v prvn´ı f´azi u ´toku, kdy se o c´ılov´em syst´emu chceme dozvˇedˇet co nejv´ıce informac´ı, tzv. fingerprinting. Nev´ yhodou pouˇzit´ı nmapu je jeho snadn´a vystopovatelnost.
´ ´I KLIENTU ˚ DODATEK C. UAC XML PRO TESTOVAN
75
C UAC XML pro testov´ an´ı klient˚ u <scenario name="Basic Sipstone UAC"> -->
INVITE sip:[service]@[remote_ip]:[remote_port] SIP/2.0 Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch] From: sipp <sip:sipp@[local_ip]:[local_port]>;tag=[call_number] To: sut <sip:[service]@[remote_ip]:[remote_port]> Call-ID: [call_id] CSeq: 1 INVITE Contact: sip:sipp@[local_ip]:[local_port] Max-Forwards: 70 Subject: Performance Test Content-Type: application/sdp Content-Length: [len] v=0 o=user1 53655765 2353687637 IN IP[local_ip_type] [local_ip] s=c=IN IP[media_ip_type] [media_ip] t=0 0 m=audio [media_port] RTP/AVP 0 a=rtpmap:0 PCMU/8000 ]]>
--> -->
´ ´I KLIENTU ˚ DODATEK C. UAC XML PRO TESTOVAN
76
ACK sip:[service]@[remote_ip]:[remote_port] SIP/2.0 Via: SIP/2.0/[transport] [local_ip]:[local_port];branch=[branch] From: sipp <sip:sipp@[local_ip]:[local_port]>;tag=[call_number] To: sut <sip:[service]@[remote_ip]:[remote_port]>[peer_tag_param] Call-ID: [call_id] CSeq: 1 ACK Contact: sip:sipp@[local_ip]:[local_port] Max-Forwards: 70 Subject: Performance Test Content-Length: 0 ]]> -->
<send retrans="500"> ;tag=[call_number] To: sut <sip:[service]@[remote_ip]:[remote_port]>[peer_tag_param] Call-ID: [call_id] CSeq: 2 BYE Contact: sip:sipp@[local_ip]:[local_port] Max-Forwards: 70 Subject: Performance Test Content-Length: 0 ]]>
´ A ´R ˇ PRO TESTOVAN ´ ´I ASTERISKU DODATEK D. SCEN
77
D Sc´ en´ aˇ r pro testov´ an´ı Asterisku <scenario name="UAC for Asterisk"> -->
78
DODATEK E. REGISTRATION HIJACKING PAKETY
E Registration hijacking pakety Registrace od klienta X-lite: Session Initiation Protocol Request-Line: REGISTER sip:obelix.feld.cvut.cz SIP/2.0 Method: REGISTER Message Header Via: SIP/2.0/UDP 147.32.126.85:37714;branch=z9hG4bK-d87543-6649123 Transport: UDP Sent-by Address: 147.32.126.85 Sent-by port: 37714 Branch: z9hG4bK-d87543-6649123f0a639e11-1--d87543RPort: rport Max-Forwards: 70 Contact: <sip:
[email protected]:37714;rinstance=fc00cd7929eeebc7> Contact Binding: <sip:
[email protected]:37714;rinstance=fc00cd7929eeebc7> URI: <sip:
[email protected]:37714;rinstance=fc00cd7929eeebc7> SIP contact address: sip:
[email protected]:37714 To: "Michal Obelix"<sip:
[email protected]> SIP Display info: "Michal Obelix" SIP to address: sip:
[email protected] From: "Michal Obelix"<sip:
[email protected]>;tag=de7d316b SIP Display info: "Michal Obelix" SIP from address: sip:
[email protected] Call-ID: OGYyNzM2ODI3YWUwMmJhOTgxZmE5N2ExM2RmYTc2OGE. CSeq: 1 REGISTER Sequence Number: 1 Method: REGISTER Expires: 15 Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, User-Agent: X-Lite release 1011s stamp 41150 Content-Length: 0 Smaz´ an´ı registrace: Session Initiation Protocol Request-Line: REGISTER sip:147.32.201.163 SIP/2.0 Method: REGISTER [Resent Packet: False] Message Header Via: SIP/2.0/UDP 147.32.126.85;branch=z9hG4bK-d87543-1b2243423423 Transport: UDP Sent-by Address: 147.32.126.85 Branch: z9hG4bK-d87543-1b2243423423 From: "Michal Obelix" <sip:
[email protected]>;tag=pwQNDXsOiw SIP Display info: "Michal Obelix" SIP from address: sip:
[email protected] SIP tag: pwQNDXsOiw
DODATEK E. REGISTRATION HIJACKING PAKETY
79
To: "Michal Obelix" <sip:
[email protected]> SIP Display info: "Michal Obelix" SIP to address: sip:
[email protected] Call-ID:
[email protected] CSeq: 123456 REGISTER Sequence Number: 123456 Method: REGISTER Contact: * Max_forwards: 70 User-Agent: SIVuS Scanner Content-Type: application/sdp Subject: SiVuS Test Expires: 0 Content-Length: 0 Nov´ a, podvodn´ a registrace: Session Initiation Protocol Request-Line: REGISTER sip:147.32.201.163 SIP/2.0 Method: REGISTER [Resent Packet: False] Message Header Via: SIP/2.0/UDP 147.32.126.85;branch=z9hG4bK-d87543-1b2243423423 Transport: UDP Sent-by Address: 147.32.126.85 Branch: z9hG4bK-d87543-1b2243423423 From: "Michal Obelix" <sip:
[email protected]>;tag=pwQNDXsOiw SIP Display info: "Michal Obelix" SIP from address: sip:
[email protected] SIP tag: pwQNDXsOiw To: "Michal Obelix" <sip:
[email protected]> SIP Display info: "Michal Obelix" SIP to address: sip:
[email protected] Call-ID:
[email protected] CSeq: 123456 REGISTER Sequence Number: 123456 Method: REGISTER Contact: <sip:
[email protected]> Contact Binding: <sip:
[email protected]> URI: <sip:
[email protected]> SIP contact address: sip:
[email protected] Max_forwards: 70 User-Agent: SIVuS Scanner Content-Type: application/sdp Subject: SiVuS Test Expires: 15 Content-Length: 0
80
´ DODATEK F. UKAZKA PRAVIDEL PRO SNORT INLINE
F Uk´ azka pravidel pro Snort Inline #vymezeni povolene site var SCHOOL_NET [147.32.0.0/16]
#alert pokud dojde vic jak 20 INVITE paketu za 1s ze stejne IP #adresy alert udp any any -> any 5060 (content: "INVITE"; depth:30; msg:"INVITE floods - should be dropped"; threshold: type both, track by_src,\ count 20, seconds 1; sid:3000000; rev:1;)
#zaloguj obsah danych paketu activate udp !$SCHOOL_NET any -> any 5060 (content: "INVITE"; depth: 30; activates: 1; msg: "Outside network call"; threshold: type both, track by_src,\ count 20, seconds 1; sid:25002;) dynamic udp any any -> any 5060 (activated_by: 1; count: 10; sid:25002;)
#zahod vsechny pakety obsahujici znak % drop udp $SCHOOL_NET any -> any 5060 (msg:"Buffer over flow attack - probably flags from c/c++"; content: "%"; sid:25006;)
#zahod vsechny pakety obsahujici prikaz rm -rf / drop udp any any -> any 5060 (msg:"rm -rf in binary"; content: "|726d 20 2d 72 66 20 2f 0a 00|"; sid:250013;)
ˇ ˇ EHO ´ DODATEK G. OBSAH PRILO ZEN DVD
G Obsah pˇ riloˇ zen´ eho DVD
Obr´azek G.1: Obsah pˇriloˇzen´eho DVD Popis: diplomova prace - zdrojov´ y text DP v latex + PDF verze klienti - adres´aˇr obsahuje verze klient˚ u pouˇzit´ ych pˇri testov´an´ı reg hijacking - zaznamenan´a data pˇri u ´toku na ukradnut´ı registrace rtp streams - z´aznam hovor˚ u Wiresharkem testovaci nastroje: - n´astroje pouˇzit´e pˇri testov´an´ı testovani klientu: - skripty a zaznamenan´a data pˇri testov´an´ı klient˚ u testovani serveru: - skripty a zaznamenan´a data pˇri testov´an´ı server˚ u
81
