Minden, amit tudni akartál SIP protokoll
Minden, amit tudni akartál SIP protokoll
3. rész
NAT probléma
Ugyanakkor a NAT probléma média forgalom - ez csak az egyik oldala az éremnek. Először nézzük meg, mi akadályokat NAT a jelzési üzenetek és a SIP kiterjesztéseket dolgoztak ki azok leküzdésére.
Megkerülve NAT SIP-jelzés
A második probléma az, hogy szükség van megfelelő útvonalat bejövő SIP-lekérdezések. SIP nem biztosítanak egy olyan mechanizmust, amely lehetővé teszi, hogy küldjön új kérelmet a kapcsolatot a szállítási réteg, amely-ben alakult, amikor a felhasználó bejelentkezik. Bejegyzés a NAT tábla élettartama korlátozott (úgy, hogy a táblázat nem túlcsordult különösen), és a bejövő SIP-UA kérelmek elérheti a NAT, NAT bejegyzéseket a fordítási táblában frissíteni kell vizsgálni. Ez vonatkozik mind a protokoll összeköttetés és kapcsolatorientált protokoll.
1. ábra A útvonal a bejövő kérések
De belépő a NAT tábla után el kell hagyni egy bizonyos ideig (leggyakrabban - néhány perc alatt). A probléma az, amelyek nemcsak abban az időszakban, amikor a felhasználó regisztráció: közben SIP-párbeszéd is új üzenetek nem érkeznek egy hosszú ideig, ami elegendő ahhoz, hogy rögzítse a fordítási táblázatot törölték. Meglévő SIP-halom megoldani ezt a problémát úgy, hogy rendszeresen küld SIP-lekérdezés újra MEGHÍVÁSA, OPTIONS, INFO, bejelentés vagy (ha UDP) adatcsomagok nem tartalmazó hasznos.
Egy teljes és tökéletes a technika a tervezet kezelése Ügyfél kezdeményezett kapcsolatok SIP Internet Engineering Task Group (IETF) [2]. Nézzük meg részletesen.
Amikor a felhasználó bejelentkezik logger menti az adatokat a közlekedési kapcsolat, amelyen keresztül a kérelem nem érkezett. Két speciális paraméterek például azonosítót és reg-id Kapcsolat fejléc lehetővé teszi számunkra, hogy megtalálja az adatbázis regisztrációs szerver adatbázis-kapcsolat, és irányítja a bejövő kérést a UA a kapcsolatot a szállítási réteg, amelyen keresztül a kérelem nem érkezett regisztráció. Szintén a tervezet leírja a mechanizmusok folyamatos frissítése rekordok NAT táblát.
Összefoglalva azt mondta például a felhasználó regisztrációs kis mögött található NAT és UDP-t használ (lásd. Ábra. 2).
2. ábra: Bypass NAT SIP-jelzés
REGISZTRÁCIÓ kérelmet tartalmaz fejlécet paraméter Via rport tájékoztatása UAS támogatása RFC 3581, valamint a paraméterek és reg-id + sip.instance cím Kapcsolat:
REGISZTRÁCIÓ sip: proxy.example.com SIP / 2.0
WWW-Authenticate: [nem ábrázolt]
NAT, a média forgalom
3. ábra NAT, a média forgalom
Egyszerü keresztirányú UDP keresztül NAT (kábítás)
Végül elérkeztünk arra a pontra. STUN nem oldja meg a NAT probléma SIP általában. Igen, működik Port Restricted Cone NAT forgatókönyvet, és néha - a Restricted Cone NAT, de a leggyakoribb típus a NAT volt, és továbbra kiegyensúlyozott, és itt STUN haszontalan. Ráadásul nem minden UA akkor is, ha egy barátságos NAT típusú jó „barátok” elkábítani és régebbi eszközök, kábító támogatás nem volt elterjedt.
Egy másik „szépséghiba” - a meglévő megvalósítások, kábító nem működik SIP TCP, akkor az nem megfelelő nyomon követésében az állam nyitott TCP-ülés.
Traversal használata Relé NAT (TURN)
5. ábra: Bypass NAT SIP-jelzés
A hátránya ennek a módszernek nyilvánvaló: mivel proxy minden forgalmat növeli egyirányú késleltetés és a packet loss inkább. Emiatt viszont csak akkor ajánlott olyan esetekben, amikor kevésbé „drága» NAT módszerek tehetetlen. Megjegyzendő, hogy az utóbbi időben TURN már nem tekinthető független protokollok: most le van írva, mint egy kiterjesztése, hogy kábító [5].
Interaktív Connectivity Establishment (ICE)
TURN-server proxy minden RTP forgalom akkor is, ha egy egyszerű STUN elegendő lenne a NAT. Annak érdekében, hogy válassza ki a legkevésbé „költséges» NAT eljárás lefolytatásával illő lehetőségek közötti lehetséges összefüggést végpontok IETF tervezett infrastruktúrák ICE (Interactive Connectivity Establishment). Ez nem egy protokoll a szokásos értelemben vett; ICE nevű infrastruktúra (keret), és alapja a meglévő protokollokat, elkábítani TURN és bővítmények SIP.
A jelöltlistát a legmagasabb prioritású útvonalak útvonalak bevonása nélkül elkábítani alacsonyabb - útvonalak kihasználva elkábítani és a legalacsonyabb - útvonalak Proxy-media forgalmat a TURN szerver. A kiállítás itt szándékosan bonyolult: valójában egy rugalmas rendszer prioritások figyelembe veszi a topológia a hálózat, az adatokat a késleltetés és késleltetés ingadozás, a biztonsági követelmények, stb Ennek eredményeként, az egyes útvonalakat kap egy különleges prioritás ... Ezután a teljesítményüket ellenőrizni (elérhetőségi szemközti oldalon). Az útvonalak hitelesített, válasszon egyet a legmagasabb prioritást.
Röviden, az ICE leírás nagyon ígéretesnek tűnik, és ez a döntés támogatja a VoIP-ipar. ICE leírás az [6].
Működéséhez ez a mechanizmus alapvetően fontos tulajdonsága a szimmetria a felhasználói ügynök: használja fogadására és továbbítására az azonos portot (UA kell küldenie a médiafoiyamait a port, amely közölte az SDP). De ez a megközelítés ideális a pontosság szempontjából: nem kell semmi más, mint a tényleges csomag, valamint egy csomag megérkezik a kikötőbe, ahonnan a ellenáramú küldjük - oldotta meg a problémát, minden NAT típusokat. Ilyen egy proxy szerver, akkor végre olyan további funkciókat kapcsolódó módosítását az SDP-rész. Ugyanakkor elmondhatjuk, hogy további késedelem az ülésen, növeli a terhelést a proxy szerver és a költségeket a szolgáltató.
Extensions Cisco COMEDIA
o = kliens 28908445312 28908445312 IN IP4 10.1.2.23
a = iránya: passzív IP4
Végrehajtása során a COMEDIA Cisco erősen irányított elavult ma IETF-tervezetet [8] A negyedik változat.
Gyakran előfordul, hogy a javasolt megoldás az, hogy az alkalmazás réteg átjárók (Alkalmazási réteg átjáró, ALG), kezeli, mint az IP-csomag fejlécét, és annak tartalmát. ALG funkciót végezhet határon vezérlők kapcsolatok (Session Border Controller, SBC), vagy router műsorszóró kontroll SIP üzenet. Sajnos, a feldolgozás minden egyes csomagot igényel nagy teljesítményt és növeli a költséget a megoldás. Ezen felül, az új verzió a protokoll megköveteli, hogy a SIP ALG folyamatosan frissítjük, és a gyártó követte a változásokat végrehajtani SIP eszközök beszállítók. „Becstelen» SIP ALG hatással lehet a normális működését a készülékek mögött. UPnP technológia (Universal Plug and Play) gyakrabban használják a SOHO szegmens és a kis létesítmények. Azonban ez nem jellemző, hogy a VoIP, és különben is, és olyan jól lefedett az interneten. Végül, egy értékdokumentum összefoglalása NAT megoldások itt leírt probléma [9].
Tagjai az IETF SIP munkacsoport Munkacsoport kidolgozott egy átfogó alapelemei védelem, megakadályozza a lehallgatás, munkamenet-támadások és az aktív SIP-rendszerek, valamint lehetővé teszi, hogy ellenőrizze a hitelességét a beszélgetőpartner. A maradék a cikk szentelt figyelmet ezen elemek.
A SIP biztosít két hitelesítési rendszerek: Digest hitelesítés stílus HTTP (RFC 2617 [10]), és a hitelesítési tanúsítványok használatával (SIP TLS feletti).
Amikor egy kivonatot hitelesítési stílus HTTP proxy szerver válaszol a Meghívás válasz 407 Proxy engedélyezése szükséges, ahol a fejléc területén jelen Proxy-alapú azonosítást, adatok számítási hitelesítési választ. Elküldése után az ACK üzenetet a 407 Proxy engedélyezése szükséges felhasználói ügynök is továbbíthatja meghívót, de ezúttal - a Proxyengedélyezés fejléc tartalmazza a felhasználó személyazonosságát (lásd 6. ábra ..).
6. ábra Digest hitelesítés
Message Digest - ez egy egyedi karaktersorozat rögzített méretű, akkor az eredmény az adatok (kódolt felhasználói név és jelszó) egy egyirányú MD5 hash. A szerver le a SIP engedélyezési fejléc adatok az eredménye, hogy ugyanazon hash-függvényt tárolt adatok az adatbázisban.
Transport Layer Security (TLS)
Az úton a felhasználó ágens használható TLS proxyszervert, és jeleket továbbít a szerverek védett lehet TLS-en keresztül, vagy IPSec (amely esetben választható, de stabilabb). A sikeres hitelesítés után a SIP proxy szerver dekódolja minden üzenetet (egyetlen kulcsot használnak minden lépésnél az út), ami nekik a képességet, hogy „lássa” az összes fejlécet és helyesen útvonal az üzeneteket. Azonban végfelhasználók pedig feltétel nélkül „bizalom” proxy szervereket.
A gyengeségek közé a TLS protokoll helyeken hagyományosan oldalon támadás veszélyét, „man in the middle» (Man-in-the-Middle). Vannak konkrét kérdések SIP bár TLS-kapcsolat szolgál bizonyíték hitelességét mindkét fél, hogy nem elég, hogy biztos a hitelességét (vagy arról, hogy nem lemondás) tetszőleges SIP-üzenetet továbbítani ezen a csatornán keresztül.
TLS nyújthat ezekre a célokra a HTTPS protokoll, ahol a megjelenése az ikont egy lakat a böngésző automatikusan azt jelenti, hogy van egy biztonságos csatorna a böngésző és a webszerver. SIP sokkal bonyolultabb. Képzeljük el például, TLS-kapcsolat két proxy szerver: a forgalom lehet rajta keresztül tartozó különböző ügyletek vagy párbeszéd. Következésképpen, a támadó egyik tartományból végezhet támadás injekciót forgalmat egy másik domain, és ez nem észlelhető vagy megelőzhető TLS-vegyületet. Az a probléma gyökerét, hogy ez nem „ismerős” végpontok TLS-kapcsolat a szerkezetekben keletkező kommunikáció a SIP protokollt, így elegendő alkalmazni merev biztonsági politika.
Végül, a formáció a bizalmi kapcsolatok a TLS és még telepítését TCP-kapcsolat lehet egy igazi probléma a szolgáltató, a szolgáltatás több százezer felhasználó eszközöket. Nincs szükség van egy gazdag képzelőerő elképzelni, milyen lesz, mint az áramlás SYN-csomag kialakítása során TLS-kapcsolatokat.
Akiket érdekel a fejlesztés előrehaladott utalhat RFC 4347 [12], amely leírja a protokoll DTLS, tetején futó UDP. A jelenlegi változat a TLS protokoll az RFC 4346 [13].
Biztonságos MIME (S / MIME)
Lássuk, mit lehet tudni a támadó, hogy elkapjam a SIP-üzenetek kapcsolódó szakaszában a telepítés során:
Front (ellentétben a TLS protokollt, az aktuális csomópontok közötti) integritásának biztosítása a, titoktartási és a hitelesítés SIP-üzenetek felhasználásával lehetséges S / MIME technológia (RFC 3851 [14]). Megjegyezzük, hogy az előző verziókban SIP RFC mint egy eszköz a hitelesítés és a magánélet felkínált PGP, de most annak használata elavult. 23. fejezet RFC 3261 leírja a S / MIME rendszer. Fontolja meg, hogy nem integrálódik a modell segítségével SIP.
Tekintsük a példát üzenetek S / MIME test (lásd. Ábra. 8).
8. ábra S / MIME
Ábra. A 8. ábra egy a test védelme technika SIP-üzenetet S / MIME. Hogy megvédje SIP-üzenetek fejlécét lehet helyezni a MIME-típus test egy «üzenet / korty», és körülzárt egy új SIP-üzenetet egy példányban az eredeti üzenet fejlécét útválasztási információkat. Az viszont, hogy a poszt-tartályt lehet használni S / MIME-aláírt. Végül azt is el lehet végezni, és a titkosítás SIP-header: ebben az esetben az üzenet zárt konténer objektum titkosított S / MIME. Ezek az üzenetek nem tekintik új beszélgetés vagy ügylet, de minden előnyét élvezhetik a titkosítást és hitelesítést. Fejlécek kérés URI, Via, Record-Route, Route, Max-forward és Proxyengedélyezés nem kell figyelembe venni kiszámításakor ellenőrző összegek tudnak (vagy kell) változtatni áthaladó proxy szervereket.
SIP bővítmények adatvédelmi nevét és telefonszámát
Egy sor kiterjesztések RFC 3323 [15] és az RFC 3325 [16], amely támogató funkciók előfizető adatvédelem: rejtőzködő és ellenőrzési hálózat megjelenített név és szám résztvevő előfizető dialógus (hálózati A hívó fél kilétét, ha ő az egyetlen, akinek vallja magát).
Támogatja adatvédelmi SIP hálózat egy kihívást jelentő feladat az egyszerű oknál fogva, hogy a protokoll egy szöveges jellegű, a párbeszéd résztvevőinek cserélhet üzeneteket bevonása nélkül bármely szolgáltatótól. Ugyanakkor a SIP UA funkció használatához legalább elrejtse a nevét és telefonszámát, megszokták a PSTN.
A legegyszerűbb megközelítés -, hogy korlátozott információt a fejlécben tól - problémát okozhat, ha a hívás megszakítása egy másik szolgáltató hálózatán, vagy a PSTN, vagy lehetetlenné teszi, hogy számos szolgáltatást. Az RFC 3325 funkcióját ismerteti védelme biztosításának felhasználó személyes adatai, megtartva identitás.
Egy ilyen azonosító mechanizmus működik egy domainen belül. A maga megvalósítása került bemutatásra az új hírek P-Preferred-Identity és a P-Asserted-Identity. Cím P-Preferred-Identity használják az UA ügyletek megbízható proxy. A kliens létrehoz egy kérés MEGHÍVÁSA, nem tartalmaz adatokat az előfizető személyazonosságát a From, de az igazi SIP URI és (adott esetben) a neve megjelenik a P-Preferred-Identity. Adatvédelmi fejléc is adunk az alábbi értékeket:
- «Nincs» - adatvédelmi nincs szükség; proxy szerver nem törli a fejléc P-Asserted-Identity;
- «Felhasználói» - adatvédelemre van szükség; meghatalmazott köteles eltávolítani a fejléc P-Asserted-Identity;
- «Id» - adatvédelemre van szükség, csak egy adott tartományban.
A proxy szerver elvégzéséhez szükséges megemészteni hitelesítés a helyszínen, amely nem rendelkezik a bizalmi kapcsolat. Ezt követően, a proxy szerver, hogy adjunk egy fejléc P-Asserted-Identity a felhasználó személyazonosságát a személy, aki hitelesítette. Ha proxy szerver kérést kap egy csomópontot, amely egy bizalmi kapcsolat már létrejött, a már meglévő ott fejléc P-Asserted-Identity.
Az eljárás a következő üzenetek küldésére. Ha a hívott fél található a bizalmi tartományon belül (lásd. Ábra. 9.), a proxy szerver küld egy kérést az előfizető eltávolítása nélkül a fejléc P-Asserted-Identity.
9. ábra A biztosító mechanizmus adatvédelmi belül ugyanabban a tartományban
Ha az előfizető kívül bizalmi tartományon belül (lásd. Ábra. 10), ha elhagyja üzenetek proxy tartomány megbízhatósági határértékek törli vagy megváltoztatása minden címek információt adnia a feladó (From, Kapcsolat, Reply-To, Hívás azonosító, call-Info, Via, User-Agent, szervezet, szerver, Tárgy, In-Reply-To, Record-Route és figyelmeztetés). P-Asserted-Identity feldolgozása összhangban az adatvédelmi fejléc értéke, és az adatvédelmi fejlécet kell távolítani.
10. ábra: A biztosító mechanizmus adatvédelem bizalmi tartomány
Természetesen, a védelem a kép nem lenne teljes, integritásának biztosítása és az adatok titkossága egy domainen belül a bizalom a hálózati rétegben. tartomány komponensek kölcsönösen el kell hitelesíteni, és az ügyletek a csomópontok közötti (és az UA és a domain csomópontok) kell védeni a TLS vagy IPSec.
Vannak alternatív módszerek igazolásához a hívó fél, vagy a hívott így, RFC 4474 [17] írja elő a Identity egyéni fejlécet, és Identity-Info for átmenő azonosítást kérelmező azonosságát, és az RFC 4916 [18] - a hitelesítési a címzett dialogoobrazuyuschego kérést egy további UPDATE kérés az ellenkező irányba.
Figyelembe véve az eltérő protokollokat, ügyelve a biztonságát a titkok, a felhasználók különös figyelmet kell fordítania a választás a kliens szoftvert vagy készüléket.
Tájékoztató mag SIP RFC
Száma és neve a specifikáció
Hogy ez határozza