Afrikaans - Ht
HackTricks TrainingTwitterLinkedinSponsor

SIP (Session Initiation Protocol)

Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

Basiese Inligting

SIP (Session Initiation Protocol) is 'n sein- en oproepbeheerprotokol wat wyd gebruik word om multimedia-sessies, insluitend stem, video en onmiddellike boodskappe, oor IP-netwerke te vestig, te wysig en te beëindig. Ontwikkel deur die Internet Engineering Task Force (IETF), SIP is gedefinieer in RFC 3261 en het die de facto standaard vir VoIP en verenigde kommunikasie geword.

Sommige sleutelkenmerke van SIP sluit in:

  1. Teksgedrewe Protokol: SIP is 'n teksgebaseerde protokol, wat dit menslik leesbaar en makliker om te ontfout maak. Dit is gebaseer op 'n versoek-antwoordmodel, soortgelyk aan HTTP, en gebruik metodes soos INVITE, ACK, BYE, en CANCEL om oproepsessies te beheer.

  2. Skaalbaarheid en Buigsaamheid: SIP is hoogs skaalbaar en kan in klein ontplooiings sowel as groot ondernemings- en draer-graad omgewings gebruik word. Dit kan maklik met nuwe kenmerke uitgebrei word, wat dit aanpasbaar maak vir verskillende gebruiksgevalle en vereistes.

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

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

  5. Proxy en Herlei Servers: SIP kan proxy- en herlei-servers gebruik om oproeprouting te fasiliteer en gevorderde funksies soos oproepoorplasing, oproepoorplasing, en stemposdienste te bied.

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

Ten spyte van sy baie voordele, kan SIP kompleks wees om te konfigureer en te bestuur, veral wanneer dit met NAT-oorgang en vuurmuurkwessies te doen het. Tog maak sy veelsydigheid, skaalbaarheid en uitgebreide ondersteuning oor die bedryf 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 begin of 'n bestaande een te wysig. Die INVITE-metode dra die sessiebeskrywing (tipies met behulp van SDP) om die ontvanger in te lig oor die besonderhede van die voorgestelde sessie, soos mediatipes, kodeks en oordragprotokolle.

  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-tot-end erkenning te bied.

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

  4. CANCEL: Gestuur om 'n hangende INVITE-versoek te annuleer voordat die sessie gevestig is. Die CANCEL-metode stel die sender in staat om 'n INVITE-transaksie te beëindig as hulle van gedagte verander of as daar geen antwoord van die ontvanger is nie.

  5. OPTIONS: Gebruik om die vermoëns van 'n SIP-server of gebruikersagent te ondervrag. 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-registrar-server te registreer. Die REGISTER-metode help om 'n opdatering van die kaart 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 beller moet verifieer voordat hy 'n INVITE kan uitvoer, anders sal hy 'n 401 Unauthorized antwoord ontvang.

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

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

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

  3. REFER: Gedefinieer in RFC 3515, die REFER-metode word gebruik om te vra dat die ontvanger 'n oordrag uitvoer of na 'n derde party verwys. Dit word tipies gebruik vir oproepoorplasing scenario's.

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

  5. UPDATE: Gedefinieer in RFC 3311, die UPDATE-metode stel in staat om 'n sessie te wysig sonder om die toestand van die bestaande dialoog te beïnvloed. Dit is nuttig om sessieparameters, soos kodeks of mediatipes, tydens 'n lopende oproep op te dateer.

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

SIP Antwoordkode

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

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

  • 180 Lui: Die ontvanger word gewaarsku en sal die oproep neem.

  • 183 Sessievordering: Verskaf inligting oor die vordering van die oproep.

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

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

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

  • 3xx (Herlei Antwoorde): Hierdie antwoorde dui aan dat verdere aksie benodig word om die versoek te vervul, tipies deur 'n alternatiewe hulpbron te kontak.

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

  • 301 Permanent Verskuif: Die aangevraagde hulpbron is aan 'n nuwe permanente URI toegeken.

  • 302 Tydelik Verskuif: Die aangevraagde hulpbron is tydelik beskikbaar by 'n ander URI.

  • 305 Gebruik Proxy: Die versoek moet na 'n spesifieke proxy gestuur word.

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

  • 400 Slegte Versoek: Die versoek was verkeerd of ongeldig.

  • 401 Ongeautoriseerd: Die versoek vereis gebruikersverifikasie.

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

  • 404 Nie Gevind nie: Die aangevraagde hulpbron is nie op die bediener gevind nie.

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

  • 486 Besig Hier: Die ontvanger is tans besig en kan die oproep nie neem nie.

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

  • 500 Interne Bedienerfout: Die bediener het 'n fout ondervind terwyl dit die versoek verwerk.

  • 501 Nie Geïmplementeer nie: Die bediener ondersteun nie die funksionaliteit wat benodig word om die versoek te vervul nie.

  • 503 Diens Onbeskikbaar: Die bediener is tans nie in staat om die versoek te hanteer nie weens onderhoud of oorbelasting.

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

  • 600 Besig Oral: Alle moontlike bestemmings vir die oproep is besig.

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

  • 604 Bestaan Nêrens: Die aangevraagde hulpbron is nêrens in die netwerk beskikbaar nie.

Voorbeelde

SIP INVITE 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 aanvraag 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 kopstuk spesifiseer die vervoermetode (UDP) en die kliënt se adres (pc33.example.com). Die "branch" parameter word gebruik vir lusdeteksie en transaksie-ooreenstemming.

  3. Max-Forwards: Max-Forwards: 70 - Hierdie kopstuk veld beperk die aantal kere wat die aanvraag deur proxies gestuur kan word om oneindige lusse te vermy.

  4. To: To: John Doe <sip:jdoe@example.com> - Die To kopstuk 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 kopstuk 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 kopstuk identifiseer 'n oproepsessie uniek tussen twee gebruikersagente.

  7. CSeq: CSeq: 314159 INVITE - Die CSeq kopstuk bevat 'n volgnommer en die metode wat in die aanvraag gebruik word. Dit word gebruik om antwoorde aan versoeke te koppel en om buite volgorde boodskappe te detecteer.

  8. Contact: Contact: <sip:jsmith@pc33.example.com> - Die Contact kopstuk bied 'n direkte roete na die sender, wat gebruik kan word vir daaropvolgende versoeke en antwoorde.

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

  10. Allow: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO - Die Allow kopstuk 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 kopstuk spesifiseer die media tipe van die boodskap liggaam, in hierdie geval, SDP (Session Description Protocol).

  12. Content-Length: Content-Length: 142 - Die Content-Length kopstuk dui die grootte van die boodskap liggaam in bytes aan.

  13. Message Body: Die boodskap liggaam bevat die SDP sessiebeskrywing, wat inligting oor die media tipes, kodeks, en vervoermetodes vir die voorgestelde sessie insluit.

  • v=0 - Protokol weergawe (0 vir SDP)

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

  • s=- - Sessie naam (een enkele koppelteken dui aan dat daar geen sessie naam is nie)

  • c=IN IP4 pc33.example.com - Verbinding inligting (netwerk tipe, adres tipe, en adres)

  • t=0 0 - Tyd inligting (begin en stop tye, 0 0 beteken die sessie is nie gebonde nie)

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

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

SIP REGISTER Voorbeeld

Die REGISTER metode word gebruik in Session Initiation Protocol (SIP) om 'n gebruikersagent (UA), soos 'n VoIP telefoon of 'n sagtefoon, toe te laat om sy ligging by 'n SIP registrateur bediener te registreer. Hierdie proses laat die bediener weet waar om inkomende SIP versoeke wat vir die geregistreerde gebruiker bedoel is, te roete. Die registrateur bediener is gewoonlik deel van 'n SIP proxy bediener of 'n toegewyde registrasie bediener.

Hier is 'n gedetailleerde voorbeeld van die SIP boodskappe wat betrokke is by 'n REGISTER outentikasie proses:

  1. Begin REGISTER aanvraag van UA na die registrateur bediener:

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 registrateur bediener 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 Unauthorized antwoord van die registrateur bediener:

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 registrateur bediener antwoord met 'n "401 Onbevoeg" boodskap, wat 'n "WWW-Authenticate" kop bevat. Hierdie kop bevat inligting wat benodig word vir die UA om homself te verifieer, soos die verifikasieraam, nonce, en algoritme.

  1. REGISTREER versoek met verifikasiesertifikate:

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 wat die nodige geloofsbriewe insluit, soos die gebruikersnaam, realm, nonce, en 'n responswaarde wat bereken is met behulp van die verskafde inligting en die gebruiker se wagwoord.

So word die Authorization respons bereken:

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 antwoord van die registrateur bediener:

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 registrateur bediener die verskafde geloofsbriewe verifieer, stuur dit 'n "200 OK" antwoord om aan te dui dat die registrasie suksesvol was. Die antwoord sluit die geregistreerde kontakbesonderhede en die vervaldatum vir die registrasie in. Op hierdie punt is die gebruiker agent (Alice) suksesvol geregistreer met die SIP registrateur bediener, en inkomende SIP versoeke vir Alice kan na die toepaslike kontakadres gestuur word.

Bel Voorbeeld

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

Leer & oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Leer & oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Ondersteun HackTricks
PreviousBasic VoIP ProtocolsNextPentesting Remote GdbServer

Last updated