Afrikaans - Ht
HackTricks Training Twitter Linkedin Sponsor

SIP (Session Initiation Protocol)

Leer AWS-hacking vanaf nul tot held met htARTE (HackTricks AWS Red Team Expert)!

Ander maniere om HackTricks te ondersteun:

Basiese Inligting

SIP (Session Initiation Protocol) is 'n seinstuur- en oproepbeheerprotokol wat wyd gebruik word vir die tot stand bring, wysiging en beëindiging van multimedia-sessies, insluitend stem, video en onmiddellike boodskappe, oor IP-netwerke. Ontwikkel deur die Internet Engineering Task Force (IETF), word SIP gedefinieer in RFC 3261 en het die de facto standaard vir VoIP en eengemaakte kommunikasie geword.

Sommige sleutelkenmerke van SIP sluit in:

  1. Teksgesentreerde Protokol: SIP is 'n teksgebaseerde protokol, wat dit mensleesbaar en makliker om te foutsoek. Dit is gebaseer op 'n versoek-antwoordmodel, soortgelyk aan HTTP, en gebruik metodes soos INVITE, ACK, BYE en CANCEL vir die beheer van oproepsessies.

  2. Skaalbaarheid en Buigsaamheid: SIP is hoogs skaalbaar en kan gebruik word in kleinskaalse implementasies sowel as groot onderneming- en draergraderingsomgewings. Dit kan maklik uitgebrei word met nuwe kenmerke, wat dit aanpasbaar maak vir verskeie gevalle en vereistes.

  3. Interoperabiliteit: SIP se wye aanvaarding en standaardisering verseker beter interoperabiliteit tussen verskillende toestelle, toepassings en diensverskaffers, wat naatlose kommunikasie oor verskeie platforms bevorder.

  4. Modulêre Ontwerp: SIP werk saam met ander protokolle soos RTP (Real-time Transport Protocol) vir mediaversending en SDP (Session Description Protocol) vir die beskrywing van multimedia-sessies. Hierdie modulêre ontwerp maak groter buigsaamheid en verenigbaarheid met verskillende mediatipes en kodeks moontlik.

  5. Proksi- en Herleiingbedieners: SIP kan proksi- en herleiingbedieners gebruik om oproeprouting te fasiliteer en gevorderde kenmerke soos oproepdeurvorsing, oproepoorplasing en voicemaildienste te bied.

  6. Teenwoordigheid en Onmiddellike Boodskappe: SIP is nie beperk tot stem- en videokommunikasie nie. Dit ondersteun ook teenwoordigheid en onmiddellike boodskappe, wat 'n wye reeks eengemaakte kommunikasietoepassings moontlik maak.

Ten spyte van sy baie voordele kan SIP moeilik wees om te konfigureer en te bestuur, veral wanneer dit kom by NAT-deursending en vuurmuurprobleme. Nietemin, sy veelsydigheid, skaalbaarheid en uitgebreide ondersteuning regoor die bedryf maak dit 'n gewilde keuse vir VoIP en multimedia kommunikasie.

SIP Metodes

Die kern SIP-metodes wat in RFC 3261 gedefinieer is, sluit in:

  1. INVITE: Gebruik om 'n nuwe sessie (oproep) te inisieer of 'n bestaande een te wysig. Die INVITE-metode dra die sessiebeskrywing (gewoonlik deur SDP te gebruik) om die ontvanger in te lig oor die besonderhede van die voorgestelde sessie, soos mediatipes, kodeks en vervoerprotokolle.

  2. ACK: Gestuur om die ontvangs van 'n finale antwoord op 'n INVITE-versoek te bevestig. Die ACK-metode verseker die betroubaarheid van INVITE-transaksies deur end-to-end bevestiging te voorsien.

  3. BYE: Gebruik om 'n gevestigde sessie (oproep) te beëindig. Die BYE-metode word deur een van die partye in die sessie gestuur om aan te dui dat hulle die kommunikasie wil beëindig.

  4. CANCEL: Gestuur om 'n hangende INVITE-versoek te kanselleer voordat die sessie gevestig is. Die CANCEL-metode maak dit vir die sender moontlik om 'n INVITE-transaksie te stuit as hulle van gedagte verander of as daar geen reaksie van die ontvanger is nie.

  5. OPTIONS: Gebruik om navraag te doen na die vermoëns van 'n SIP-bediener of gebruiker. Die OPTIONS-metode kan gestuur word om inligting oor ondersteunde metodes, mediatipes of ander uitbreidings aan te vra sonder om werklik 'n sessie te vestig.

  6. REGISTER: Gebruik deur 'n gebruikersagent om sy huidige ligging by 'n SIP-registratorbediener te registreer. Die REGISTER-metode help om 'n opgedateerde koppeling tussen 'n gebruiker se SIP-URI en hul huidige IP-adres te handhaaf, wat oproeprouting en aflewering moontlik maak.

Let daarop dat dit nie nodig is om die REGISTER vir enigiets te gebruik om iemand te bel nie. Dit is egter moontlik dat die oproeper in orde moet outentiseer voordat hy 'n INVITE uitvoer, of hy sal 'n 401 Onbevoegd-antwoord ontvang.

Benewens hierdie kernmetodes is daar verskeie SIP-uitbreidingsmetodes wat in ander RFC's gedefinieer is, soos:

  1. SUBSCRIBE: Gedefinieer in RFC 6665, word die SUBSCRIBE-metode gebruik om kennisgewings te versoek oor die toestand van 'n spesifieke hulpbron, soos 'n gebruiker se teenwoordigheid of oproepstatus.

  2. NOTIFY: Ook gedefinieer in RFC 6665, word die NOTIFY-metode deur 'n bediener gestuur om 'n geabonneerde gebruikersagent in te lig oor veranderinge in die toestand van 'n gemonitorde hulpbron.

  3. REFER: Gedefinieer in RFC 3515, word die REFER-metode gebruik om te versoek dat die ontvanger 'n oorplasing uitvoer of na 'n derde party verwys. Dit word tipies gebruik vir oproepoorplasingscenarios.

  4. MESSAGE: Gedefinieer in RFC 3428, word die MESSAGE-metode gebruik om onmiddellike boodskappe tussen SIP-gebruikersagente te stuur, wat teksgebaseerde kommunikasie binne die SIP-raamwerk moontlik maak.

  5. UPDATE: Gedefinieer in RFC 3311, maak die UPDATE-metode dit moontlik om 'n sessie te verander sonder om die toestand van die bestaande dialoog te beïnvloed. Dit is nuttig vir die opdatering van sessieparameters, soos kodeks of mediatipes, tydens 'n lopende oproep.

  6. PUBLISH: Gedefinieer in RFC 3903, word die PUBLISH-metode deur 'n gebruikersagent gebruik om gebeurtenistoestandinligting na 'n bediener te publiseer, wat dit beskikbaar maak vir ander belanghebbendes.

SIP-Responskodes

  • 1xx (Voorlopige Antwoorde): Hierdie antwoorde dui daarop dat die versoek ontvang is en dat die bediener voortgaan om dit te verwerk.

  • 100 Trying: Die versoek is ontvang, en die bediener werk daaraan.

  • 180 Ringing: Die ontvanger word gewaarsku en sal die oproep aanneem.

  • 183 Session Progress: Verskaf inligting oor die vordering van die oproep.

  • 2xx (Suksesvolle Antwoorde): Hierdie antwoorde dui daarop dat die versoek suksesvol ontvang, verstaan en aanvaar is.

  • 200 OK: Die versoek was suksesvol, en die bediener het dit vervul.

  • 202 Accepted: Die versoek is aanvaar vir verwerking, maar dit is nog nie voltooi nie.

  • 3xx (Herleiingsantwoorde): Hierdie antwoorde dui daarop dat verdere aksie nodig is om die versoek te vervul, tipies deur 'n alternatiewe hulpbron te kontak.

  • 300 Multiple Choices: Daar is verskeie opsies beskikbaar, en die gebruiker of kliënt moet een kies.

  • 301 Moved Permanently: Die versoekte hulpbron het 'n nuwe permanente URI gekry.

  • 302 Moved Temporarily: Die versoekte hulpbron is tydelik beskikbaar by 'n ander URI.

  • 305 Use Proxy: Die versoek moet na 'n gespesifiseerde proksi gestuur word.

  • 4xx (Kliëntfoutantwoorde): Hierdie antwoorde dui daarop dat die versoek slegte sintaksis bevat of nie deur die bediener vervul kan word nie.

  • 400 Bad Request: Die versoek was verdraaid of ongeldig.

  • 401 Unauthorized: Die versoek vereis gebruikeroutentisering.

  • 403 Forbidden: Die bediener het die versoek verstaan, maar weier om dit te vervul.

  • 404 Not Found: Die versoekte hulpbron is nie op die bediener gevind nie.

  • 408 Request Timeout: Die bediener het nie 'n volledige versoek binne die tyd wat dit bereid was om te wag, ontvang nie.

  • 486 Busy Here: Die ontvanger is tans besig en kan nie die oproep aanneem nie.

  • 5xx (Bedieningsfoutantwoorde): Hierdie antwoorde dui daarop dat die bediener nie 'n geldige versoek kon vervul nie.

  • 500 Internal Server Error: Die bediener het 'n fout teëgekom tydens die verwerking van die versoek.

  • 501 Not Implemented: Die bediener ondersteun nie die funksionaliteit wat nodig is om die versoek te vervul nie.

  • 503 Service Unavailable: Die bediener is tans nie in staat om die versoek te hanteer as gevolg van instandhouding of oorlading nie.

  • 6xx (Globale Mislukkingsantwoorde): Hierdie antwoorde dui daarop dat die versoek nie deur enige bediener vervul kan word nie.

  • 600 Busy Everywhere: Alle moontlike bestemmings vir die oproep is besig.

  • 603 Decline: Die ontvanger wil nie aan die oproep deelneem nie.

  • 604 Does Not Exist Anywhere: Die versoekte hulpbron is nêrens in die netwerk beskikbaar nie.

Voorbeelde

SIP UITNODIGING Voorbeeld

INVITE sip:jdoe@example.com SIP/2.0
Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bK776asdhds
Max-Forwards: 70
To: John Doe <sip:jdoe@example.com>
From: Jane Smith <sip:jsmith@example.org>;tag=1928301774
Call-ID: a84b4c76e66710
CSeq: 314159 INVITE
Contact: <sip:jsmith@pc33.example.com>
User-Agent: ExampleSIPClient/1.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
Content-Type: application/sdp
Content-Length: 142

v=0
o=jsmith 2890844526 2890842807 IN IP4 pc33.example.com
s=-
c=IN IP4 pc33.example.com
t=0 0
m=audio 49170 RTP/AVP 0
a=rtpmap:0 PCMU/8000te
Elke Parameter Verduidelik

  1. Request-Line: INVITE sip:jdoe@example.com SIP/2.0 - Hierdie lyn dui die metode (INVITE), die versoek URI (sip:jdoe@example.com), en die SIP weergawe (SIP/2.0) aan.

  2. Via: Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bK776asdhds - Die Via-kop spesifiseer die vervoerprotokol (UDP) en die klient se adres (pc33.example.com). Die "branch" parameter word gebruik vir lusdeteksie en transaksie-passing.

  3. Max-Forwards: Max-Forwards: 70 - Hierdie kopvel beperk die aantal kere wat die versoek deur proksies gestuur kan word om oneindige lusse te voorkom.

  4. To: To: John Doe <sip:jdoe@example.com> - Die To-kop spesifiseer die ontvanger van die oproep, insluitend hul vertoonnaam (John Doe) en SIP URI (sip:jdoe@example.com).

  5. From: From: Jane Smith <sip:jsmith@example.org>;tag=1928301774 - Die From-kop spesifiseer die sender van die oproep, insluitend hul vertoonnaam (Jane Smith) en SIP URI (sip:jsmith@example.org). Die "tag" parameter word gebruik om die sender se rol in die dialoog uniek te identifiseer.

  6. Call-ID: Call-ID: a84b4c76e66710 - Die Call-ID-kop identifiseer uniek 'n oproepsessie tussen twee gebruiker-agente.

  7. CSeq: CSeq: 314159 INVITE - Die CSeq-kop bevat 'n volgnummer en die metode wat in die versoek gebruik word. Dit word gebruik om reaksies aan versoek te koppel en buite-orde boodskappe te identifiseer.

  8. Contact: Contact: <sip:jsmith@pc33.example.com> - Die Contact-kop bied 'n direkte roete na die sender, wat gebruik kan word vir volgende versoek en reaksies.

  9. User-Agent: User-Agent: ExampleSIPClient/1.0 - Die User-Agent-kop verskaf inligting oor die sagteware of hardeware van die sender, insluitend die naam en weergawe.

  10. Allow: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO - Die Allow-kop lys die SIP metodes wat deur die sender ondersteun word. Dit help die ontvanger om te verstaan watter metodes tydens die kommunikasie gebruik kan word.

  11. Content-Type: Content-Type: application/sdp - Die Content-Type-kop spesifiseer die media-tipe van die boodskaplêer, in hierdie geval SDP (Session Description Protocol).

  12. Content-Length: Content-Length: 142 - Die Content-Length-kop dui die grootte van die boodskaplêer in bytes aan.

  13. Boodskaplêer: Die boodskaplêer bevat die SDP-sessiebeskrywing, wat inligting oor die media-tipes, kodeks, en vervoerprotokolle vir die voorgestelde sessie insluit.

  • v=0 - Protokolverse (0 vir SDP)

  • o=jsmith 2890844526 2890842807 IN IP4 pc33.example.com - Oorsprong en sessie-identifiseerder

  • s=- - Sessienaam ( 'n enkele koppelteken dui geen sessienaam aan nie)

  • c=IN IP4 pc33.example.com - Verbindingsinligting (netwerktipe, adres tipe, en adres)

  • t=0 0 - Tyd-inligting (begin en eindtye, 0 0 beteken die sessie is nie begrens nie)

  • m=audio 49170 RTP/AVP 0 - Mediabeskrywing (media-tipe, poortnommer, vervoerprotokol, en formaatlys). In hierdie geval spesifiseer dit 'n klankvloei wat RTP/AVP (Real-time Transport Protocol / Audio Video Profile) en formaat 0 (PCMU/8000) gebruik.

  • a=rtpmap:0 PCMU/8000 - Eienskap wat die formaat (0) aan die kodek (PCMU) en sy klokspoed (8000 Hz) koppel.

SIP REGISTER Voorbeeld

Die REGISTER-metode word in die Session Initiation Protocol (SIP) gebruik om 'n gebruikeragent (UA), soos 'n VoIP-foon of 'n sagtetoestel, toe te laat om sy ligging by 'n SIP-registratorbediener te registreer. Hierdie proses laat die bediener weet waar om inkomende SIP-versoeke wat bestem is vir die geregistreerde gebruiker te roeteer. Die registratorbediener is gewoonlik deel van 'n SIP-proksibediener of 'n toegewyde registrasiebediener.

Hier is 'n gedetailleerde voorbeeld van die SIP-boodskappe wat betrokke is by 'n REGISTER-verifikasieproses:

  1. Aanvanklike REGISTER versoek van UA na die registratorbediener:

REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK776asdhds
Max-Forwards: 70
From: Alice <sip:alice@example.com>;tag=565656
To: Alice <sip:alice@example.com>
Call-ID: 1234567890@192.168.1.100
CSeq: 1 REGISTER
Contact: <sip:alice@192.168.1.100:5060>;expires=3600
Expires: 3600
Content-Length: 0

Hierdie aanvanklike REGISTER-boodskap word deur die UA (Alice) na die registrasiebediener gestuur. Dit sluit belangrike inligting in soos die gewenste registrasieduur (Expires), die gebruiker se SIP URI (sip:alice@example.com), en die gebruiker se kontakadres (sip:alice@192.168.1.100:5060).

  1. 401 Onbevoegd reaksie van die registrasiebediener:

cssCopy codeSIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK776asdhds
From: Alice <sip:alice@example.com>;tag=565656
To: Alice <sip:alice@example.com>;tag=7878744
Call-ID: 1234567890@192.168.1.100
CSeq: 1 REGISTER
WWW-Authenticate: Digest realm="example.com", nonce="abcdefghijk", algorithm=MD5, qop="auth"
Content-Length: 0

Die registrarserver reageer met 'n "401 Onbevoegd" boodskap, wat 'n "WWW-Authenticate" kop bevat. Hierdie kop bevat inligting wat nodig is vir die UA om homself te verifieer, soos die verifikasie-realm, nonce, en algoritme.

  1. REGISTREER versoek met verifikasie-legitimasie:

REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK776asdhds
Max-Forwards: 70
From: Alice <sip:alice@example.com>;tag=565656
To: Alice <sip:alice@example.com>
Call-ID: 1234567890@192.168.1.100
CSeq: 2 REGISTER
Contact: <sip:alice@192.168.1.100:5060>;expires=3600
Expires: 3600
Authorization: Digest username="alice", realm="example.com", nonce="abcdefghijk", uri="sip:example.com", response="65a8e2285879283831b664bd8b7f14d4", algorithm=MD5, cnonce="lmnopqrst", qop=auth, nc=00000001
Content-Length: 0

Die UA stuur 'n ander REGISTER versoek, hierdie keer met die "Authorization" kop met die nodige geloofsbriewe, soos die gebruikersnaam, realm, nonce, en 'n responswaarde wat bereken is met die verskafde inligting en die gebruiker se wagwoord.

Dit is hoe die Autoriseringsrespons bereken word:

import hashlib

def calculate_sip_md5_response(username, password, realm, method, uri, nonce, nc, cnonce, qop):
# 1. Calculate HA1 (concatenation of username, realm, and password)
ha1_input = f"{username}:{realm}:{password}"
ha1 = hashlib.md5(ha1_input.encode()).hexdigest()

# 2. Calculate HA2 (concatenation of method and uri)
ha2_input = f"{method}:{uri}"
ha2 = hashlib.md5(ha2_input.encode()).hexdigest()

# 3. Calculate the final response value (concatenation of h1, stuff and h2)
response_input = f"{ha1}:{nonce}:{nc}:{cnonce}:{qop}:{ha2}"
response = hashlib.md5(response_input.encode()).hexdigest()

return response

# Example usage
username = "alice"
password = "mysecretpassword"
realm = "example.com"
method = "REGISTER"
uri = "sip:example.com"
nonce = "abcdefghijk"
nc = "00000001"
cnonce = "lmnopqrst"
qop = "auth"

response = calculate_sip_md5_response(username, password, realm, method, uri, nonce, nc, cnonce, qop)
print(f"MD5 response value: {response}")

  1. Suksesvolle registrasie respons van die registrasiebediener:

SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK776asdhds
From: Alice <sip:alice@example.com>;tag=565656
To: Alice <sip:alice@example.com>;tag=7878744
Call-ID: 1234567890@192.168.1.100
CSeq: 2 REGISTER
Contact: <sip:alice@192.168.1.100:5060>;expires=3600
Expires: 3600
Content-Length: 0

Na die registrarserver die verskafte geloofsbriewe verifieer, stuur dit 'n "200 OK" respons om aan te dui dat die registrasie suksesvol was. Die respons sluit die geregistreerde kontakinligting en die vervaltyd vir die registrasie in. Op hierdie punt is die gebruikeragent (Alice) suksesvol geregistreer by die SIP-registrarserver, en inkomende SIP-versoeke vir Alice kan na die toepaslike kontakadres gerouteer word.

Oproep Voorbeeld

Dit word nie genoem nie, maar Gebruiker B moet 'n REGISTER-boodskap aan Proxy 2 gestuur het voordat hy oproepe kan ontvang.

PreviousBasic VoIP ProtocolsNextPentesting Remote GdbServer

Last updated