VoIP. VoIP biztonság

VoIP VoIP biztonság

VoIP támadások Támadás a VoIP szoftveren keresztül





OS támadása  



Windows és Linux/UNIX alapok - szerverek Hardphone hibák

Konfigurációs hibák kihasználása



Gyenge jelszavak SNMP hozzáférés TFTP boot



VOMIT: voice over misconfigured internet telephones

 

Támadás a VoIP hálózaton keresztül





Layer 2 támadások 





Layer3 támadások  



2

ARP támadás – Gratuitous ARP -> MiM DHCP támadás (rouge DHCP, DHCP starvation) DDoS TCP/UDP támadások

Lehallgatás Hálózatok építése, konfigurálása és működtetése - Fehér Gábor, BME-TMIT

2016/7.2

VoIP támadások 2. Támadás VoIP protokollon keresztül





Nem specifikált működés



DoS 

Hamisított SIP – H.323 üzenetek 





ICMP port unreachable üzenet küldése

Hívásrablás 

3

CANCEL vagy BYE

SIP üzenet, hogy a másik fél mozog

Hálózatok építése, konfigurálása és működtetése - Fehér Gábor, BME-TMIT

2016/7.2

VoIP telefon tanúsítványok Tanúsítványok (Cisco)





Certificate Trust List (CTL) 

A megbízható kiszolgálók tanúsítványának listája 

 

Boot idején töltődik le. (tyúk-tojás) Az adminisztrátor írja alá  



Saját PKI Cisco aláírás eToken segítségével

A telefon is azonosítja magát  

MIC (7970): Manufacturing Installed Certificate (Cisco root CA) LSC (7960/7940): Locally Significant Certificate  

4

Identity, PK, role

CAPF által telepített Jelszó, pin kód Hálózatok építése, konfigurálása és működtetése - Fehér Gábor, BME-TMIT

2016/7.2

VoIP telefon védelem Firmware védelme (Cisco)



 

A firmware boot idején töltődhet le. A firmware-t a tftp szerver szolgáltatja. Hitelesített firmware  

A firmware a Cisco-tól származik (Cisco root aláírás) Egy adott verziótól már csak ezt lehet használni

Konfiguráció védelme (Cisco)





Konfiguráció hitelesítése 



TLS védett kapcsolatok  

5

Tanúsítványok használata CCM: Cisco Call Manager (most Unity) CAPF: Certificate Authority Proxy Function


2016/7.2

VoIP hálózat védelem Layer 2





MAC flooding (lehallgatás): MAC limit, 802.1X



Rouge DHCP, starvation:







DHCP snooping: Kliens proton nincs DHCP szerver (uplink is lehet megbízható)



DHCP starvation: DHCP limit, 802.1X



A DHCP szervernek közel kell lennie a kliensekhez

Gratuitous ARP: 

Dynamic ARP inspection: Minden nem DHCP által rendelt MAC:IP páros blokkolása (IP is: IP Source Guard)



Ignore Gratuitous ARP: A telefon nem frissíti az ARP cache-t

VLAN 

Hang és adat LAN elválasztása

Layer 3





Tűzfalak alkalmazása 

Alkalmazás proxy a VoIP protokoll értelmezésével 





Titkosított adatok???

DoS 

6

Médiafolyamok számára az UDP csatornák felnyitása és zárása

Egyidejű kérések számának maximálása (rate limit)


2016/7.2

VoIP forgalom védelme Hangátvitel védelme





Tartalom titkosítás 



IPSec, DTLS – Datagram Transport Layer Security 



DTLS esetén meg kell oldani az újraküldéseket, időzítéseket, mivel UDP felett megy

SRTP 

7

Egyedi algoritmusok

MIKEY (DH is), SDescription, ZRTP, (DTLS-SRTP)


2016/7.2

Session Initiation Protocol Alapelemek



Redirect Server

Proxy Server

Registrar Server

Gateway

NAT

PSTN

Enddpoint UAC/UAS Enddpoint UAC/UAS 8


2016/7.2

SIP és NAT

9


2016/7.2

VoIP és Firewall/NAT Public

Private

SIP Proxy

Private

SIP Signaling SIP Phone SIP Phone

Firewall



Jelzés probléma  



A SIP proxy nem tud kommunikálni a kliensekkel A felnyitott portok ha nincs forgalom, akkor megszűnnek

Média probléma 

   

10

Firewall

A SIP INVITE –ban küldött cím csak lokális SDP nem tudja leírni a médiaforgalom címét Az inicializálásnak a privát -> publikus irányba kell történnie RTCP = RTP + 1 A felnyitott portok ha nincs forgalom, akkor megszűnnek Hálózatok építése, konfigurálása és működtetése - Fehér Gábor, BME-TMIT

2016/7.2

NAT 

Full Cone NAT  



Restricted Cone NAT 



Hasonló a Full Cone –hoz, de visszafelé irányban az IP cím korlátozva van az eredeti címzettre (a port nem)

Port Restricted Cone NAT 



A belső cím:port 1:1 –ben külső cím:port –ra irányítva Visszafelé irányban is így működik, tetszőleges küldő/port lehet

Hasonló a Rescrited Cone –hoz, de a port is korlátozva van az eredetileg megcímzett portra.

Symmetric NAT 

11

Hasonló a Port Restricted Cone –hoz, de itt minden új kapcsolathoz új külső IP:port lesz rendelve


2016/7.2

Full cone

12


2016/7.2

Restricted cone

13


2016/7.2

Port restricted cone

14


2016/7.2

Symmetric NAT

15


2016/7.2

NAT/Tűzfal átjárás 

A hívó fél nem ismeri a saját publikus címét 

Esetleg nem tudja, hogy NAT mögött van



A hívott felet nem érik el a jelzésüzenetek/médiaforgalom



Dedikált jelzésport 



SIP: 5060

Szimmetrikus RTP  16

A küldésre/vételre használt port megegyezik Hálózatok építése, konfigurálása és működtetése - Fehér Gábor, BME-TMIT

2016/7.2

IGD 

Internet Gateway Device (IGD) Protocol 



UPnP fórum

Képességek  

Külső cím megmutatása Portok felsorolása, új port nyitás, zárás 



Problémák  

Nem minden NAT és OS támogatja Feltételezzük, hogy a lokális hálózat biztonságos 



Kérésre nyit egy portot, amin be lehet jönni

Nem feltételezhető!

Léteznek hasonló protokollok is 

17

Realm-Specific IP (RSIP), Middlebox Communications (MIDCOM), NAT Port Mapping Protocol (NAT PMP)


2016/7.2

STUN 

Simple Traversal of UDP Through NATs



A VoIP kliensnek tudnia kellene a saját NAT címét! (+port) 

NAT Probe: A külső cím lekérdezése 

18

Egy külső, publikus szerver megmondja, hogy mit lát küldő címnek


2016/7.2

STUN felderítés

19


2016/7.2

STUN és VoIP 

Hívásfelépítés előtt STUN teszt ugyanarról a cím:port –ról, mint ahonnan a kapcsolat fel fog épülni.  



Megtudom a szükséges IP címeket/portokat Megtudom a NAT típusát

Feltételek 

Szimmetrikus NAT esetén nem működik!  



Működik, ha a VoIP szoftver ugyanazon a porton fogad és küld adatokat  

20

A célcím és STUN szerver cím különbözik -> különböző NAT publikus címek a NAT táblában Szerencsére a legtöbb SOHO NAT nem szimmetrikus

A másik féllel a NAT címét kell közölni A NAT probe után hamarosan indítani kell a kommunikációt, nehogy más címre álljon a NAT


2016/7.2

UDP hole punching 

Egy külső szerver visszaküldi az IP címeket és portokat (belső és külső is) a kommunikáló feleknek 



Aktív kapcsolat kell a hoszt és a külső szerver között, amin keresztül a hoszt adatot tud fogadni A felek mindkét címen próbálkoznak 

 

NATon belüli és kívüli kapcsolatok is lehetnek

Amennyiben Full Cone akkor tud működni Restricted Cone esetben is működhet, ha elérik egymást a gépek 21


2016/7.2

UDP hole punching

22


2016/7.2

TURN 

Traversal Using Relay NAT  

Egy külső szerver továbbítja a csomagokat Ehhez mindkét fél csatlakozik, az adatokat ide címzik 



Költséges   

23

Mivel mindkét fél eléri a TURN szervert, a visszirányú kapcsolaton megkapják a másik fél által küldött adatokat is

Hosszú utak (idő) Terhelt szerver Csak végső esetben! Hálózatok építése, konfigurálása és működtetése - Fehér Gábor, BME-TMIT

2016/7.2

ICE 

Interactive Connectivity Establishment 

STUN és TURN használata 

Potenciális IP címek gyűjtése   



 

24

Prioritás

Kapcsolatépítés előtt a címek tesztelése (STUN) Peer reflexive címek 



Lokális Server reflexive Realyed

A címek tesztelése közben keletkező új címek (szimmetrikus NAT)

A legjobb kapcsolat használata


2016/7.2

ICE címgyűjtés 

Relay címhez üzenet  

25

Egyben STUN szerver Megmondja a reflexív címet


2016/7.2

Session Border Controller - SBC 

A hálózat határain helyezkednek el 



Minden forgalom rajta megy keresztül (jelzés + média)  



Biztonságot is nyújt

Mintha mindkét fél az SBC-n lenne (back-to-back user agent) Átkódolhatja a forgalmat (jelzés + média)

Titkosítás? 26


2016/7.2

VoIP jelzések védelme 

Titkosított és hitelesített jelzés üzenetek 

TLS (Pl.: SIPS), DTLS és IPSec   

PKI-n alapul Széles körben támogatott (TLS és IPSec) De csak szakaszok védelme megoldott!  

A hangforgalom titkosításához ez kevés lehet A titkosító kulcsot e2e kéne egyeztetni 



S/MIME    

 

SDescriptions nem az igazi, itt a kulcs az üzenetben van és a TLS az üzenettel együtt titkosítja

PKI-n alapul Csak az SDP van titkosítva E2e biztonság a forgalom számára De nincs visszajátszás elleni védelem!

Nem lehet teljesen e2e titkosítás, mert néhány mezőnek láthatónak kell lennie! A SIP proxyk megváltoztathatják az üzeneteket 27


2016/7.2

Hamis SIP üzenetek 

From, via mezők hamisítása INVITE sip:[email protected] SIP/2.0 Via: SIP/2.0/UDP evilsite.com To: Bob sip:[email protected] From: Alice <sip:[email protected]> Call-ID: ae4356ef781a Cseq: 100 INVITE … 28


2016/7.2

SIP Authentication 

A felhasználó hitelesítése 

HTTP digest (RFC 3261) 

 

29

Közös titok a felhasználónál és hitelesítőnél

TLS S/MIME


2016/7.2

SIP Authentication – HTTP digest 

A proxy szerver kér hitelesítést  

INVITE vagy REGISTER üzenetnél Kihívás alapú: (tartomány, nonce, hash algoritmus)  



A kihívás a hitelesítés kéréssel együtt érkezik A felhasználó is küldhet saját nonce értéket

Csak a kérdés van hitelesítve, más mezőt nem titkosít/hitelesít 30


2016/7.2

SIP Authentication – HTTP digest 2. 

Regisztrációval User Agent

Proxy Server REGISTER (without credentials) 407 Proxy Authentication Required

REGISTER (password encrypted with key) 200 OK

31


2016/7.2

SIP Authentication – HTTP digest 3. 

INVITE üzenetnél User Agent

Proxy Server INVITE x@y (without credentials) 407 Proxy Authentication Required ACK

INVITE x@y (with encrypted password)

Itt megy ki az INVITE

100 Trying

32


2016/7.2

SIPS Authentication  

Hasonlóan a HTTP-HTTPS-hez,TLS használata A szerverek egymás között és a távoli végponton is TLS felett alakítanak ki kapcsolatot 



Elvileg ha nem tud kialakítani kapcsolatot, akkor nem épül fel

Hop by hop titkosítás

33


2016/7.2

SIP Authentication – S/MIME 

RFC 3261: Az SIP fejléceket megismétli a törzsben, MIME formátumban, titkosítva  

Digitális aláírással (PKI) Gond, hogy bizonyos mezők megváltozhatnak a továbbító proxyk miatt 



RFC 3893: Authenticated Identity Body (AIB) 



Nehezen ellenőrizhető, hogy ez legitim vagy támadó változás

SIP válasz is használhatja

PKI miatt gondok lehetnek 34


2016/7.2

SIP Identity 

RFC 4474: Identity + Indetity info fejlécek



HTTPS vagy SIPS URI, az identitást lehet ellenőrizni segítségével Csak SIP kérések



Digitális aláírással





Az AIB továbbvitele, így az AIB nincs is elterjedve 35


2016/7.2

P-Asserted-Identity (PAI) 

SIP hálózatban, ahol megbízható az együttműködés 

A Proxy elhelyezi a felhasználó azonosítóját a továbbított üzenetekben  



36

Kivéve, ha az üzenet nem megbízható félnek megy Kivéve, ha a felhasználó annak eltávolítását kéri

SIP URI és opcionális display name


2016/7.2

VoIP. VoIP biztonság

Recommend Documents