From 5af8d9c874714af59f3e174a876e4b0472eb2475 Mon Sep 17 00:00:00 2001 From: Translator Date: Tue, 30 Sep 2025 03:38:04 +0000 Subject: [PATCH] Translated ['src/network-services-pentesting/pentesting-voip/basic-voip- --- .../sip-session-initiation-protocol.md | 265 ++++++++++++------ 1 file changed, 175 insertions(+), 90 deletions(-) diff --git a/src/network-services-pentesting/pentesting-voip/basic-voip-protocols/sip-session-initiation-protocol.md b/src/network-services-pentesting/pentesting-voip/basic-voip-protocols/sip-session-initiation-protocol.md index c194ae3e0..f33df3723 100644 --- a/src/network-services-pentesting/pentesting-voip/basic-voip-protocols/sip-session-initiation-protocol.md +++ b/src/network-services-pentesting/pentesting-voip/basic-voip-protocols/sip-session-initiation-protocol.md @@ -4,76 +4,76 @@ ## Basiese Inligting -SIP (Session Initiation Protocol) is 'n **sein- en oproepbeheerprotokol** wat wyd gebruik word om multimedia-sessies, insluitend stem, video en kitsboodskappe, oor IP-netwerke te vestig, te wysig en te beëindig. Ontwikkel deur die **Internet Engineering Task Force (IETF)**, is SIP gedefinieer in **RFC 3261** en het die de facto standaard vir VoIP en verenigde kommunikasie geword. +SIP (Session Initiation Protocol) is 'n **seinen- en oproepbeheerprotokol** wat wyd gebruik word vir die totstandbrenging, wysiging en beëindiging van multimedia-sessies, insluitend stem, video en instant messaging, oor IP-netwerke. Ontwikkel deur die **Internet Engineering Task Force (IETF)**, is SIP gedefinieer in **RFC 3261** en het dit 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 maak en makliker om te debug. 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 onderneming- en draer-graad omgewings gebruik word. Dit kan maklik uitgebrei word met nuwe funksies, wat dit aanpasbaar maak vir verskeie gebruiksgevalle 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 media-oordrag en **SDP (Session Description Protocol)** vir die beskrywing van multimedia-sessies. Hierdie modulêre ontwerp bied groter buigsaamheid en kompatibiliteit met verskillende mediatipes en kodeks. -5. **Proxy en Herlei Servers**: SIP kan proxy- en herlei-servers gebruik om oproeproutering te fasiliteer en gevorderde funksies soos oproepoorplasing, oproepoorplasing, en stemposdienste te bied. -6. **Teenwoordigheid en Kitsboodskappe**: SIP is nie beperk tot stem- en video kommunikasie nie. Dit ondersteun ook teenwoordigheid en kitsboodskappe, wat 'n wye reeks verenigde kommunikasietoepassings moontlik maak. +1. **Teksgebaseerde Protokol**: SIP is 'n teksgebaseerde protokol, wat dit mensleesbaar maak en makliker om te debug. Dit is gebaseer op 'n versoek-antwoord model, soortgelyk aan HTTP, en gebruik metodes soos INVITE, ACK, BYE, en CANCEL vir die beheer van oproepsessies. +2. **Skalbaarheid en Buigsaamheid**: SIP is hoogs skaalbaar en kan in klein skaal ontplooiings sowel as groot onderneming- en carrier-grade omgewings gebruik word. Dit kan maklik met nuwe funksies uitgebrei word, wat dit aanpasbaar maak by verskeie gebruiksgevalle en vereistes. +3. **Interoperabiliteit**: SIP se wydverspreide aanneming 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 media-oordrag en **SDP (Session Description Protocol)** vir die beskrywing van multimedia-sessies. Hierdie modulêre ontwerp laat groter buigsaamheid en versoenbaarheid met verskillende media-tipes en codecs toe. +5. **Proxy- en Redirect-bedieners**: SIP kan proxy- en redirect-bedieners gebruik om oproeprigting te fasiliteer en gevorderde funksies soos oproep-vooruitsending, oproep-oordrag en voicemail-dienste te bied. +6. **Presence en Instant Messaging**: SIP is nie beperk tot stem- en video-kommunikasie nie. Dit ondersteun ook presence en instant messaging, wat 'n wye verskeidenheid verenigde kommunikasie-toepassings 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. +Ten spyte van sy vele voordele, kan SIP kompleks wees om te konfigureer en te bestuur, veral wanneer NAT-traversal en firewall-kwessies hanteer moet word. Sy veelsydigheid, skalbaarheid en uitgebreide ondersteuning in die bedryf maak dit egter 'n gewilde keuse vir VoIP en multimedia-kommunikasie. ### SIP Metodes -Die kern SIP-metodes wat in **RFC 3261** gedefinieer is, sluit in: +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 vervoersprotokolle. -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 word. Die CANCEL-metode laat die sender toe om 'n INVITE-transaksie te kanselleer as hulle van gedagte verander of as daar geen reaksie 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 oproeproutering en aflewering moontlik maak. +1. **INVITE**: Word gebruik om 'n **nuwe sessie (oproep) te begin** of 'n bestaande een te wysig. Die INVITE-metode dra die sessiebeskrywing (gewoonlik met SDP) om die ontvanger in te lig oor die besonderhede van die voorgestelde sessie, soos media-tipes, codecs en vervoerprotokolle. +2. **ACK**: Gestuur om die **ontvangs van 'n finale reaksie** op 'n INVITE-versoek te bevestig. Die ACK-metode verseker die betroubaarheid van INVITE-transaksies deur end-tot-end erkenning te bied. +3. **BYE**: Word gebruik om 'n **opgestelde sessie (oproep) te beëindig**. Die BYE-metode word deur enige 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 tot stand gebring is. Die CANCEL-metode laat die sender toe om 'n INVITE-transaksie te staak as hulle van plan verander of as daar geen reaksie van die ontvanger is nie. +5. **OPTIONS**: Word gebruik om **die vermoëns van 'n SIP-bediener of user agent te navraag**. Die OPTIONS-metode kan gestuur word om inligting te versoek oor ondersteunde metodes, media-tipes of ander uitbreidings sonder om werklik 'n sessie te vestig. +6. **REGISTER**: Word deur 'n user agent gebruik om **sy huidige ligging by 'n SIP registrar server te registreer**. Die REGISTER-metode help om 'n op-datum kartering tussen 'n gebruiker se SIP URI en hul huidige IP-adres te handhaaf, wat oproeprigting en aflewering moontlik maak. > [!WARNING] -> Let daarop dat dit **nie nodig is om die REGISTER** te gebruik om iemand te bel nie.\ -> Dit is egter moontlik dat om 'n **INVITE** uit te voer, die beller eers moet **autentiseer** of hy sal 'n **`401 Unauthorized`** antwoord ontvang. +> Let daarop dat om iemand te bel dit **nie noodsaaklik is om die REGISTER** vir enigiets te gebruik nie.\ +> Dit is egter moontlik dat om 'n **INVITE** uit te voer die roeper eers moet **authentikeer**, anders sal hy 'n **`401 Unauthorized`** reaksie ontvang. -Benewens hierdie kernmetodes, is daar **verskeie SIP-uitbreidingsmetodes** wat in ander RFC's gedefinieer is, soos: +Benewens hierdie kernmetodes is daar **verskeie SIP-uitbreidingsmetodes** in ander RFC's gedefinieer, 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 **kitsboodskappe tussen SIP-gebruikersagentskappe te stuur**, wat teksgebaseerde kommunikasie binne die SIP-raamwerk moontlik maak. -5. **UPDATE**: Gedefinieer in RFC 3311, die UPDATE-metode laat **wysigings aan 'n sessie toe 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. +1. **SUBSCRIBE**: Gedefinieer in RFC 6665, die SUBSCRIBE-metode word gebruik om **kennisgewings te versoek** oor die toestand van 'n spesifieke hulpbron, soos 'n gebruiker se presence of oproepstatus. +2. **NOTIFY**: Ook gedefinieer in RFC 6665, die NOTIFY-metode word deur 'n bediener gestuur om **'n ingeskrewe user agent 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 **versoek dat die ontvanger 'n oordrag uitvoer of na 'n derde party verwys**. Dit word gewoonlik vir **oproep-oordrag** scenario's gebruik. +4. **MESSAGE**: Gedefinieer in RFC 3428, die MESSAGE-metode word gebruik om **instant messages tussen SIP user agents te stuur**, wat teksgebaseerde kommunikasie binne die SIP-raamwerk moontlik maak. +5. **UPDATE**: Gedefinieer in RFC 3311, die UPDATE-metode laat toe om **'n sessie te wysig sonder om die toestand van die bestaande dialoog te beïnvloed**. Dit is nuttig vir die bywerking van sessieparameters, soos codecs of media-tipes, tydens 'n voortgaande oproep. +6. **PUBLISH**: Gedefinieer in RFC 3903, die PUBLISH-metode word deur 'n user agent gebruik om **gebeurtenistoestand-inligting aan 'n bediener te publiseer**, waardeur dit beskikbaar gestel word aan ander belangstellendes. -### SIP Antwoordkodes +### SIP Response Codes -- **1xx (Provisionele Antwoorde)**: Hierdie antwoorde dui aan dat die versoek ontvang is, en 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 neem. -- 183 Session Progress: 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 Accepted: 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 Multiple Choices: Daar is verskeie opsies beskikbaar, en die gebruiker of kliënt moet een kies. -- 301 Moved Permanently: Die aangevraagde hulpbron is 'n nuwe permanente URI toegeken. -- 302 Moved Temporarily: Die aangevraagde hulpbron is tydelik beskikbaar by 'n ander URI. -- 305 Use 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 Bad Request: Die versoek was verkeerd of ongeldig. -- 401 Unauthorized: Die versoek vereis gebruikersautentisering. -- 403 Forbidden: Die bediener het die versoek verstaan, maar weier om dit te vervul. -- 404 Not Found: Die aangevraagde hulpbron is nie op die bediener gevind nie. -- 408 Request Timeout: Die bediener het nie 'n volledige versoek binne die tyd ontvang wat dit bereid was om te wag nie. -- 486 Busy Here: 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 Internal Server Error: Die bediener het 'n fout ondervind terwyl dit die versoek verwerk het. -- 501 Not Implemented: Die bediener ondersteun nie die funksionaliteit wat benodig word om die versoek te vervul nie. -- 503 Service Unavailable: 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 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 aangevraagde hulpbron is nêrens in die netwerk beskikbaar nie. +- **1xx (Provisional Responses)**: Hierdie reaksies dui aan dat die versoek ontvang is, en die bediener is besig om dit verder te verwerk. +- 100 Trying: The request was received, and the server is working on it. +- 180 Ringing: The callee is being alerted and will take the call. +- 183 Session Progress: Provides information about the progress of the call. +- **2xx (Successful Responses)**: Hierdie reaksies dui aan dat die versoek suksesvol ontvang, verstaan en aanvaar is. +- 200 OK: The request was successful, and the server has fulfilled it. +- 202 Accepted: The request was accepted for processing, but it hasn't been completed yet. +- **3xx (Redirection Responses)**: Hierdie reaksies dui aan dat verdere optrede benodig word om die versoek te vervul, tipies deur 'n alternatiewe hulpbron te kontak. +- 300 Multiple Choices: There are multiple options available, and the user or client must choose one. +- 301 Moved Permanently: The requested resource has been assigned a new permanent URI. +- 302 Moved Temporarily: The requested resource is temporarily available at a different URI. +- 305 Use Proxy: The request must be sent to a specified proxy. +- **4xx (Client Error Responses)**: Hierdie reaksies dui aan dat die versoek slegte sintaksis bevat of nie deur die bediener vervul kan word nie. +- 400 Bad Request: The request was malformed or invalid. +- 401 Unauthorized: The request requires user authentication. +- 403 Forbidden: The server understood the request but refuses to fulfill it. +- 404 Not Found: The requested resource was not found on the server. +- 408 Request Timeout: The server did not receive a complete request within the time it was prepared to wait. +- 486 Busy Here: The callee is currently busy and unable to take the call. +- **5xx (Server Error Responses)**: Hierdie reaksies dui aan dat die bediener daarin misluk het om 'n geldige versoek te vervul. +- 500 Internal Server Error: The server encountered an error while processing the request. +- 501 Not Implemented: The server does not support the functionality required to fulfill the request. +- 503 Service Unavailable: The server is currently unable to handle the request due to maintenance or overload. +- **6xx (Global Failure Responses)**: Hierdie reaksies dui aan dat die versoek deur geen bediener vervul kan word nie. +- 600 Busy Everywhere: All possible destinations for the call are busy. +- 603 Decline: The callee does not wish to participate in the call. +- 604 Does Not Exist Anywhere: The requested resource is not available anywhere in the network. ## Voorbeelde -### SIP INVITE Voorbeeld +### SIP INVITE Example ``` INVITE sip:jdoe@example.com SIP/2.0 Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bK776asdhds @@ -94,43 +94,43 @@ s=- c=IN IP4 pc33.example.com t=0 0 m=audio 49170 RTP/AVP 0 -a=rtpmap:0 PCMU/8000te +a=rtpmap:0 PCMU/8000 ```
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](mailto: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 vervoersprotokol (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 kopveld beperk die aantal kere wat die aanvraag deur proxies gestuur kan word om oneindige lusse te vermy. -4. **To**: `To: John Doe ` - Die To kop spesifiseer die ontvanger van die oproep, insluitend hul vertoonnaam (John Doe) en SIP URI (sip:[jdoe@example.com](mailto:jdoe@example.com)). -5. **From**: `From: Jane Smith ;tag=1928301774` - Die From kop spesifiseer die sender van die oproep, insluitend hul vertoonnaam (Jane Smith) en SIP URI (sip:[jsmith@example.org](mailto: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 'n oproepsessie uniek tussen twee gebruikersagente. -7. **CSeq**: `CSeq: 314159 INVITE` - Die CSeq kop 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: ` - Die Contact kop 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 kop 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 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 boodskapliggaam, in hierdie geval, SDP (Session Description Protocol). -12. **Content-Length**: `Content-Length: 142` - Die Content-Length kop dui die grootte van die boodskapliggaam in bytes aan. -13. **Message Body**: Die boodskapliggaam bevat die SDP sessiebeskrywing, wat inligting oor die mediatipes, kodeks, en vervoersprotokolle vir die voorgestelde sessie insluit. +1. **Request-Line**: `INVITE sip:jdoe@example.com SIP/2.0` - Hierdie reël dui die metode (INVITE), die versoek-URI (sip:[jdoe@example.com](mailto: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 vervoersprotokol (UDP) en die kliënt se adres (pc33.example.com). Die "branch" parameter word gebruik vir lus-detectie en transaksie-ooreenstemming. +3. **Max-Forwards**: `Max-Forwards: 70` - Hierdie headerveld beperk die aantal kere wat die versoek deur proxies deurgegee kan word om oneindige lusse te voorkom. +4. **To**: `To: John Doe ` - Die To-kop dui die ontvanger van die oproep aan, insluitend hul vertoonnaam (John Doe) en SIP-URI (sip:[jdoe@example.com](mailto:jdoe@example.com)). +5. **From**: `From: Jane Smith ;tag=1928301774` - Die From-kop spesifiseer die sender van die oproep, insluitend hul vertoonnaam (Jane Smith) en SIP-URI (sip:[jsmith@example.org](mailto: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 'n oproepsessie eenduidig tussen twee user agents. +7. **CSeq**: `CSeq: 314159 INVITE` - Die CSeq-kop bevat 'n volgnummer en die metode wat in die versoek gebruik is. Dit word gebruik om antwoorde aan versoeke te koppel en om boodskappe wat uit volgorde is, te ontdek. +8. **Contact**: `Contact: ` - Die Contact-kop verskaf 'n direkte roete na die sender wat vir daaropvolgende versoeke en antwoorde gebruik kan word. +9. **User-Agent**: `User-Agent: ExampleSIPClient/1.0` - Die User-Agent-kop verskaf 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-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 mediatipe van die boodskapliggaam — in hierdie geval SDP (Session Description Protocol). +12. **Content-Length**: `Content-Length: 142` - Die Content-Length-kop dui die grootte van die boodskapliggaam in bytes aan. +13. **Message Body**: Die boodskapliggaam bevat die SDP-sessiebeskrywing, wat inligting oor media-tipes, codecs, en vervoersprotokolle 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=-` - Sessienaam (een enkele koppelteken dui aan dat daar geen sessienaam is nie) -- `c=IN IP4 pc33.example.com` - Verbinding inligting (netwerk tipe, adres tipe, en adres) -- `t=0 0` - Tydinligting (begin en stop tye, 0 0 beteken die sessie is nie gebonde nie) -- `m=audio 49170 RTP/AVP 0` - Media beskrywing (media tipe, poortnommer, vervoersprotokol, 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 kloktempo (8000 Hz) koppel. +- `v=0` - Protokolweergawe (0 vir SDP) +- `o=jsmith 2890844526 2890842807 IN IP4 pc33.example.com` - Oorsprong en sessie-identifiseerder +- `s=-` - Sessie naam ('n enkele koppelteken dui geen sessienaam aan) +- `c=IN IP4 pc33.example.com` - Konneksie-inligting (netwerk tipe, adres tipe en adres) +- `t=0 0` - Tydsinligting (begin- en eindtye; 0 0 beteken die sessie is nie begrens nie) +- `m=audio 49170 RTP/AVP 0` - Media beskrywing (media tipe, poortnommer, vervoersprotokol, en formaatlys). In hierdie geval spesifiseer dit 'n audio-stroom wat RTP/AVP (Real-time Transport Protocol / Audio Video Profile) en formaat 0 (PCMU/8000) gebruik. +- `a=rtpmap:0 PCMU/8000` - Attribuut wat die formaat (0) aan die codec (PCMU) en sy klokfrekwensie (8000 Hz) koppel.
### SIP REGISTER Voorbeeld -Die REGISTER metode word in Session Initiation Protocol (SIP) gebruik 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. +Die REGISTER-metode word in Session Initiation Protocol (SIP) gebruik om 'n user agent (UA), soos 'n VoIP-foon of 'n softphone, in staat te stel om **sy ligging by 'n SIP registrar server te registreer**. Hierdie proses laat die bediener weet **waarheen inkomende SIP-versoeke wat vir die geregistreerde gebruiker bedoel is, gerouteer moet word**. Die registrar server is gewoonlik deel van 'n SIP proxy server of 'n toegewyde registrasie-bediener. -Hier is 'n gedetailleerde voorbeeld van die SIP boodskappe wat betrokke is by 'n REGISTER outentikasie proses: +Hier is 'n gedetailleerde voorbeeld van die SIP-boodskappe wat betrokke is by 'n REGISTER-verifikasieproses: -1. Aanvanklike **REGISTER** aanvraag van UA na die registrateur bediener: +1. Aanvanklike **REGISTER** versoek van UA na die registrar server: ```yaml REGISTER sip:example.com SIP/2.0 Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK776asdhds @@ -143,11 +143,11 @@ Contact: ;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](mailto:alice@example.com)), en die gebruiker se kontakadres (sip:alice@192.168.1.100:5060). +Hierdie aanvanklike REGISTER-boodskap word deur die UA (Alice) na die registrar-bediener gestuur. Dit sluit belangrike inligting in soos die verlangde registrasieduur (Expires), die gebruiker se SIP URI (sip:[alice@example.com](mailto:alice@example.com)), en die gebruiker se kontakadres (sip:alice@192.168.1.100:5060). -2. **401 Unauthorized** antwoord van die registrateur bediener: -```css -cssCopy codeSIP/2.0 401 Unauthorized +2. **401 Unauthorized** antwoord van die registrar-bediener: +``` +SIP/2.0 401 Unauthorized Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK776asdhds From: Alice ;tag=565656 To: Alice ;tag=7878744 @@ -156,9 +156,9 @@ 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 Unauthorized" boodskap, wat 'n "WWW-Authenticate" kop bevat. Hierdie kop bevat inligting wat vereis word vir die UA om homself te verifieer, soos die **verifikasieraam, nonce, en algoritme**. +Die registrar-bediener reageer met '401 Unauthorized' boodskap, wat 'WWW-Authenticate' header insluit. Hierdie header bevat inligting wat nodig is vir die UA om homself te verifieer, soos die **authentication realm, nonce, and algorithm**. -3. REGISTER versoek **met verifikasiesertifikate**: +3. REGISTER request **with authentication credentials**: ```vbnet REGISTER sip:example.com SIP/2.0 Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK776asdhds @@ -172,9 +172,9 @@ 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" koptekst met die nodige geloofsbriewe, soos die gebruikersnaam, realm, nonce, en 'n responswaarde** wat bereken is met behulp van die verskafde inligting en die gebruiker se wagwoord. +Die UA stuur nog 'n REGISTER request, hierdie keer met die **"Authorization" header wat die nodige credentials bevat, soos die username, realm, nonce en 'n response value** wat bereken word met die verskafte inligting en die gebruiker se wagwoord. -So word die **Authorization respons** bereken: +So word die **Authorization response** soos volg bereken: ```python import hashlib @@ -207,7 +207,7 @@ qop = "auth" response = calculate_sip_md5_response(username, password, realm, method, uri, nonce, nc, cnonce, qop) print(f"MD5 response value: {response}") ``` -4. **Suksesvolle registrasie** antwoord van die registrateur bediener: +4. **Suksesvolle registrasie** respons vanaf die registrar-bediener: ```yaml SIP/2.0 200 OK Via: SIP/2.0/UDP 192.168.1.100:5060;branch=z9hG4bK776asdhds @@ -219,13 +219,98 @@ Contact: ;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 by die SIP registrateur bediener, en inkomende SIP versoeke vir Alice kan na die toepaslike kontakadres gestuur word. +After the registrar server verifies the provided credentials, **it sends a "200 OK" response to indicate that the registration was successful**. The response includes the registered contact information and the expiration time for the registration. At this point, the user agent (Alice) is successfully registered with the SIP registrar server, and incoming SIP requests for Alice can be routed to the appropriate contact address. -### Bel Voorbeeld +### Call Example
-> [!NOTE] -> Dit word nie genoem nie, maar Gebruiker B moet 'n **REGISTER boodskap na Proxy 2** gestuur het voordat hy oproepe kan ontvang. +> [!TIP] +> Dit word nie genoem nie, maar User B moet eers 'n **REGISTER message to Proxy 2** gestuur het voordat hy oproepe kan ontvang. + + +--- + +## SIP Security and Pentesting Notes + +Hierdie afdeling voeg praktiese, protokol-spesifieke wenke by sonder om die breër VoIP-riglyne te dupliseer. Vir end-to-end VoIP attacking methodology, tools and scenarios, sien: + +{{#ref}} +../README.md +{{#endref}} + +### Fingerprinting and Discovery + +- Send an OPTIONS request and review `Allow`, `Supported`, `Server` and `User-Agent` headers to fingerprint devices and stacks: + +```bash +# nmap NSE (UDP 5060 by default) +sudo nmap -sU -p 5060 --script sip-methods + +# Minimal raw OPTIONS over UDP +printf "OPTIONS sip: SIP/2.0\r\nVia: SIP/2.0/UDP attacker;branch=z9\r\nFrom: ;tag=1\r\nTo: >\r\nCall-ID: 1@attacker\r\nCSeq: 1 OPTIONS\r\nMax-Forwards: 70\r\nContact: \r\nContent-Length: 0\r\n\r\n" | nc -u -w 2 5060 +``` + +### Username/Extension Enumeration Behavior + +- Enumeration typically abuses differences between `401/407` vs `404/403` on `REGISTER`/`INVITE`. Maak bedieners sodat hulle uniform reageer. +- Asterisk chan_sip: set `alwaysauthreject=yes` (general) to avoid disclosing valid users. In newer Asterisk (PJSIP), guest calling is disabled unless an `anonymous` endpoint is defined and similar "always auth reject" behavior is the default; still enforce network ACLs and fail2ban at the perimeter. + +### SIP Digest Authentication: algorithms and cracking + +- SIP commonly uses HTTP-Digest style auth. Historically MD5 (and MD5-sess) are prevalent; newer stacks support SHA-256 and SHA-512/256 per RFC 8760. Prefer these stronger algorithms in modern deployments and disable MD5 when possible. +- Offline cracking from a pcap is trivial for MD5 digests. After extracting the challenge/response, you can use hashcat mode 11400 (SIP digest, MD5): + +```bash +# Example hash format (single line) +# username:realm:method:uri:nonce:cnonce:nc:qop:response +echo 'alice:example.com:REGISTER:sip:example.com:abcdef:11223344:00000001:auth:65a8e2285879283831b664bd8b7f14d4' > sip.hash + +# Crack with a wordlist +hashcat -a 0 -m 11400 sip.hash /path/to/wordlist.txt +``` + +> [!NOTE] +> RFC 8760 defines SHA-256 and SHA-512/256 for HTTP Digest (used by SIP). Adoption is uneven; ensure your tools handle these when targeting modern PBXs. + +### SIP over TLS (SIPS) and over WebSockets + +- Signaling encryption: +- `sips:` URIs and TCP/TLS typically on 5061. Verify certificate validation on endpoints; many accept self-signed or wildcard certs, enabling MitM in weak deployments. +- WebRTC softphones often use SIP over WebSocket per RFC 7118 (`ws://` or `wss://`). If the PBX exposes WSS, test authentication and CORS, and ensure rate limits are enforced on the HTTP front end as well. + +### DoS quick checks (protocol level) + +- Flooding INVITE, REGISTER or malformed messages can exhaust transaction processing. +- Simple rate-limiting example for UDP/5060 (Linux iptables hashlimit): + +```bash +# Limit new SIP packets from a single IP to 20/s with burst 40 +iptables -A INPUT -p udp --dport 5060 -m hashlimit \ +--hashlimit-name SIP --hashlimit 20/second --hashlimit-burst 40 \ +--hashlimit-mode srcip -j ACCEPT +iptables -A INPUT -p udp --dport 5060 -j DROP +``` + +### Recent, relevant SIP-stack CVE to watch (Asterisk PJSIP) + +- CVE-2024-35190 (published May 17, 2024): In specific Asterisk releases, `res_pjsip_endpoint_identifier_ip` could misidentify unauthorized SIP requests as a local endpoint, potentially enabling unauthorized actions or information exposure. Fixed in 18.23.1, 20.8.1 and 21.3.1. Validate your PBX version when testing and report responsibly. + +### Hardening checklist (SIP-specific) + +- Prefer TLS for signaling and SRTP/DTLS-SRTP for media; disable cleartext where feasible. +- Enforce strong passwords and digest algorithms (SHA-256/512-256 where supported; avoid MD5). +- For Asterisk: +- chan_sip: `alwaysauthreject=yes`, `allowguest=no`, per-endpoint `permit`/`deny` CIDR ACLs. +- PJSIP: do not create an `anonymous` endpoint unless needed; enforce endpoint `acl`/`media_acl`; enable fail2ban or equivalent. +- Topology hiding on SIP proxies (e.g., outbound proxy/edge SBC) to reduce information leakage. +- Strict `OPTIONS` handling and rate limits; disable unused methods (e.g., `MESSAGE`, `PUBLISH`) if not required. + + + +## References + +- RFC 8760 – Using SHA-256 and SHA-512/256 for HTTP Digest (applies to SIP Digest too): https://www.rfc-editor.org/rfc/rfc8760 +- Asterisk GHSA advisory for CVE-2024-35190: https://github.com/asterisk/asterisk/security/advisories/GHSA-qqxj-v78h-hrf9 {{#include ../../../banners/hacktricks-training.md}}