hacktricks/src/network-services-pentesting/pentesting-voip/basic-voip-protocols/sip-session-initiation-protocol.md

SIP (Session Initiation Protocol)

{{#include ../../../banners/hacktricks-training.md}}

Maelezo ya Msingi

SIP (Session Initiation Protocol) ni itifaki ya kutuma ishara na kudhibiti simu inayotumika sana kwa kuanzisha, kubadilisha, na kumaliza vikao vya multimedia, ikiwa ni pamoja na sauti, video, na ujumbe wa papo kwa papo, kupitia mitandao ya IP. Ilitengenezwa na Internet Engineering Task Force (IETF), SIP imetangazwa katika RFC 3261 na imekuwa kiwango cha kawaida kwa VoIP na mawasiliano yaliyounganishwa.

Baadhi ya sifa muhimu za SIP ni pamoja na:

1. Itifaki ya maandishi: SIP ni itifaki inayotegemea maandishi, ambayo inafanya iwe rahisi kwa binadamu kuisoma na kuifanyia debugging. Inategemea modeli ya ombi-jibu, kama HTTP, na inatumia njia kama INVITE, ACK, BYE, na CANCEL kwa kudhibiti vikao vya simu.
2. Uwezo wa kupanuka na Ustadi: SIP ina uwezo mkubwa wa kupanuka na inaweza kutumika kwa usambazaji mdogo pamoja na mazingira makubwa ya kampuni na ya kielektroniki. Inaweza kuongezewa kwa urahisi kwa vipengele vipya, ikifanya iwe rahisi kuendana na matumizi na mahitaji mbalimbali.
3. Ushirikiano wa Vifaa: Utekelezaji mpana na uwekaji viwango wa SIP unahakikisha ushirikiano bora kati ya vifaa tofauti, programu, na watoa huduma, kukuza mawasiliano yasiyokatizwa kwenye mifumo mbalimbali.
4. Muundo wa Moduli: SIP hufanya kazi na itifaki nyingine kama RTP (Real-time Transport Protocol) kwa usafirishaji wa media na SDP (Session Description Protocol) kwa kuelezea vikao vya multimedia. Muundo huu wa moduli unaruhusu ufanisi na ulinganifu na aina mbalimbali za media na codecs.
5. Proxy na Redirect Servers: SIP inaweza kutumia proxy na redirect servers kusaidia routing ya simu na kutoa vipengele vya juu kama call forwarding, call transfer, na huduma za voicemail.
6. Presence na Instant Messaging: SIP haijaelekezwa tu kwa mawasiliano ya sauti na video. Pia inaunga mkono presence na instant messaging, ikiruhusu aina mbalimbali za programu za mawasiliano yaliyounganishwa.

Licha ya faida zake nyingi, SIP inaweza kuwa ngumu kusanidi na kusimamia, hasa linapokuja suala la NAT traversal na firewall. Hata hivyo, utofauti wake, uwezo wa kupanuka, na msaada mpana katika sekta hufanya iwe chaguo maarufu kwa VoIP na mawasiliano ya multimedia.

SIP Methods

Njia kuu za SIP zilizobainishwa katika RFC 3261 ni pamoja na:

1. INVITE: Inatumika kuanzisha kikao kipya (simu) au kubadili kilichopo. Njia ya INVITE inaeleza sifa za kikao (kwa kawaida kwa kutumia SDP) ili kumjulisha mpokeaji kuhusu maelezo ya kikao kinachopendekezwa, kama aina za media, codecs, na itifaki za usafirishaji.
2. ACK: Inatumiwa kutuma ili thibitisha kupokelewa kwa jibu la mwisho la ombi la INVITE. Njia ya ACK inahakikisha uaminifu wa miamala ya INVITE kwa kutoa uthibitisho wa mwisho-mwisho.
3. BYE: Inatumika kumaliza kikao kilichoanzishwa (simu). Njia ya BYE inatumwa na pande yoyote katika kikao kuonyesha kwamba wanataka kumaliza mawasiliano.
4. CANCEL: Inatumwa kufuta ombi la INVITE lililokuwa limesubiri kabla kikao hakijaanzishwa. Njia ya CANCEL inaruhusu mtumaji kukomesha muamala wa INVITE ikiwa atabadilisha mawazo au ikiwa hakuna jibu kutoka kwa mpokeaji.
5. OPTIONS: Inatumika kuuliza uwezo wa seva au user agent wa SIP. Njia ya OPTIONS inaweza kutumwa kuomba taarifa kuhusu njia zilizotungwa, aina za media, au nyongeza nyingine bila kuanzisha kikao.
6. REGISTER: Inatumika na user agent kujisajili eneo lake la sasa kwenye SIP registrar server. Njia ya REGISTER husaidia katika kudumisha ulinganishaji wa kisasa kati ya URI ya SIP ya mtumiaji na anwani yao ya IP ya sasa, kuruhusu routing na utoaji wa simu.

Warning

Kumbuka kuwa kwa kupiga simu kwa mtu si lazima kutumia REGISTER kwa chochote.
Hata hivyo, inawezekana kwamba ili kufanya INVITE mpigaji anahitaji kuji-authenticate kwanza au atapokea jibu la 401 Unauthorized.

Mbali na njia hizi kuu, kuna njia kadhaa za nyongeza za SIP zilizobainishwa katika RFC nyingine, kama:

1. SUBSCRIBE: Imeelezwa katika RFC 6665, njia ya SUBSCRIBE inatumika kuomba arifa kuhusu hali ya rasilimali maalum, kama presence ya mtumiaji au hali ya simu.
2. NOTIFY: Pia imeelezwa katika RFC 6665, njia ya NOTIFY inatumiwa na seva kumjulisha user agent aliyesajiliwa kuhusu mabadiliko katika hali ya rasilimali inayofuatiliwa.
3. REFER: Imeelezwa katika RFC 3515, njia ya REFER inatumika kuomba mpokeaji afanye kuhamisha au kumrejea kwa mtu wa tatu. Hii kawaida hutumika kwa matukio ya call transfer.
4. MESSAGE: Imeelezwa katika RFC 3428, njia ya MESSAGE inatumika kutuma ujumbe wa papo kwa papo kati ya user agents wa SIP, ikiruhusu mawasiliano ya maandishi ndani ya mfumo wa SIP.
5. UPDATE: Imeelezwa katika RFC 3311, njia ya UPDATE inaruhusu kubadilisha kikao bila kuathiri hali ya dialog iliyopo. Hii ni muhimu kwa kusasisha vigezo vya kikao, kama codecs au aina za media, wakati simu inaendelea.
6. PUBLISH: Imeelezwa katika RFC 3903, njia ya PUBLISH inatumika na user agent kuchapisha taarifa za hali ya tukio kwa seva, ikizifanya zipatikane kwa pande nyingine zinazovutiwa.

SIP Response Codes

• 1xx (Provisional Responses): Majibu haya yanaonyesha kwamba ombi limetumwa, na seva inaendelea kulifanyia kazi.
• 100 Trying: Ombi limepokelewa, na seva inafanya kazi juu yake.
• 180 Ringing: Mtu anayepigiwa anaonyeshwa arifa na atachukua simu.
• 183 Session Progress: Inatoa taarifa kuhusu maendeleo ya simu.
• 2xx (Successful Responses): Majibu haya yanaonyesha kuwa ombi limepokelewa kwa mafanikio, limeeleweka, na limekubaliwa.
• 200 OK: Ombi lilifanikiwa, na seva limekamilisha utekelezaji wake.
• 202 Accepted: Ombi limekubaliwa kwa ajili ya usindikaji, lakini halijkamilika bado.
• 3xx (Redirection Responses): Majibu haya yanaonyesha kwamba hatua zaidi zinahitajika kutekeleza ombi, kwa kawaida kwa kuwasiliana na rasilimali mbadala.
• 300 Multiple Choices: Kuna chaguo kadhaa zinazopatikana, na mtumiaji au mteja lazima achague moja.
• 301 Moved Permanently: Rasilimali iliyohitajika imepangiwa URI mpya ya kudumu.
• 302 Moved Temporarily: Rasilimali iliyohitajika kwa sasa inapatikana kwa URI tofauti kwa muda mfupi.
• 305 Use Proxy: Ombi lazima litumwe kwa proxy iliyotajwa.
• 4xx (Client Error Responses): Majibu haya yanaonyesha kwamba ombi lina sintaksia mbaya au haliwezi kutimizwa na seva.
• 400 Bad Request: Ombi ulikuwa umepangwa vibaya au haukubaliki.
• 401 Unauthorized: Ombi linahitaji uthibitisho wa mtumiaji.
• 403 Forbidden: Seva ilielewa ombi lakini inakataa kulitimiza.
• 404 Not Found: Rasilimali uliyoomba haikuonekana kwenye seva.
• 408 Request Timeout: Seva haikupokea ombi kamili ndani ya muda ilikuwa imejisikia kusubiri.
• 486 Busy Here: Mtu anayepigiwa kwa sasa yuko mzito na hawezi kupokea simu.
• 5xx (Server Error Responses): Majibu haya yanaonyesha kwamba seva ilishindwa kutimiza ombi sahihi.
• 500 Internal Server Error: Seva ilikumbana na kosa wakati wa kusindika ombi.
• 501 Not Implemented: Seva haisaidii utendakazi unaohitajika kutimiza ombi.
• 503 Service Unavailable: Seva kwa sasa haiwezi kushughulikia ombi kwa sababu ya matengenezo au mzigo mkubwa.
• 6xx (Global Failure Responses): Majibu haya yanaonyesha kwamba ombi haliwezi kutimizwa na seva yoyote.
• 600 Busy Everywhere: Nenda zote zinazowezekana kwa simu ziko za shughuli.
• 603 Decline: Mtu anayepigiwa hataki kushiriki katika simu.
• 604 Does Not Exist Anywhere: Rasilimali uliyoomba haipatikani popote kwenye mtandao.

Mifano

Mfano wa SIP INVITE

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/8000

Kila Param Imeelezwa

1. Request-Line: INVITE sip:jdoe@example.com SIP/2.0 - Mstari huu unaonyesha method (INVITE), request URI (sip:jdoe@example.com), na toleo la SIP (SIP/2.0).
2. Via: Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bK776asdhds - Via header inaonyesha protocol ya usafirishaji (UDP) na anwani ya mteja (pc33.example.com). The "branch" parameter inatumiwa kwa kugundua loop na kulinganisha transaksheni.
3. Max-Forwards: Max-Forwards: 70 - Header hii inazuia idadi ya mara ambazo ombi linaweza kupelekwa na proxies ili kuepuka infinite loops.
4. To: To: John Doe <sip:jdoe@example.com> - To header inaonyesha mpokeaji wa simu, ikiwa ni pamoja na jina lao la kuonyesha (John Doe) na SIP URI (sip:jdoe@example.com).
5. From: From: Jane Smith <sip:jsmith@example.org>;tag=1928301774 - From header inaonyesha mtumaji wa simu, ikiwa ni pamoja na jina lao la kuonyesha (Jane Smith) na SIP URI (sip:jsmith@example.org). The "tag" parameter inatumiwa kutambua kwa kipekee nafasi ya mtumaji ndani ya mazungumzo.
6. Call-ID: Call-ID: a84b4c76e66710 - Call-ID header inatambulisha kwa kipekee kikao cha simu kati ya user agents wawili.
7. CSeq: CSeq: 314159 INVITE - CSeq header ina nambari ya sekuensi na method iliyotumika kwenye ombi. Inatumika kulinganisha majibu na maombi na kugundua ujumbe uliotoka kwa mpangilio usiofaa.
8. Contact: Contact: <sip:jsmith@pc33.example.com> - Contact header hutoa njia ya moja kwa moja kwa mtumaji, ambayo inaweza kutumika kwa maombi na majibu yanayofuata.
9. User-Agent: User-Agent: ExampleSIPClient/1.0 - User-Agent header hutoa taarifa kuhusu software au hardware ya mtumaji, ikijumuisha jina na toleo.
10. Allow: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO - Allow header inaorodhesha SIP methods zinazoungwa mkono na mtumaji. Hii husaidia mpokeaji kuelewa ni methods gani zinaweza kutumika wakati wa mawasiliano.
11. Content-Type: Content-Type: application/sdp - Content-Type header inaonyesha aina ya media ya mwili wa ujumbe, katika kesi hii, SDP (Session Description Protocol).
12. Content-Length: Content-Length: 142 - Content-Length header inaonyesha ukubwa wa mwili wa ujumbe kwa bytes.
13. Message Body: Mwili wa ujumbe una maelezo ya kikao ya SDP, ambayo ni pamoja na taarifa kuhusu aina za media, codecs, na protocols za usafirishaji kwa kikao kinachopendekezwa.

• v=0 - Protocol version (0 for SDP)
• o=jsmith 2890844526 2890842807 IN IP4 pc33.example.com - Originator and session identifier
• s=- - Session name (a single hyphen indicates no session name)
• c=IN IP4 pc33.example.com - Connection information (network type, address type, and address)
• t=0 0 - Timing information (start and stop times, 0 0 means the session is not bounded)
• m=audio 49170 RTP/AVP 0 - Media description (media type, port number, transport protocol, and format list). In this case, it specifies an audio stream using RTP/AVP (Real-time Transport Protocol / Audio Video Profile) and format 0 (PCMU/8000).
• a=rtpmap:0 PCMU/8000 - Attribute mapping the format (0) to the codec (PCMU) and its clock rate (8000 Hz).

Mfano wa SIP REGISTER

Method ya REGISTER inatumiwa katika Session Initiation Protocol (SIP) kuruhusu user agent (UA), kama VoIP phone au softphone, kurejistra eneo lake kwa SIP registrar server. Mchakato huu unamruhusu server kujua wapi kupeleka maombi ya SIP yanayoingia yaliyomwelekezwa kwa mtumiaji aliyesajiliwa. SIP registrar server kwa kawaida ni sehemu ya SIP proxy server au server iliyojitolea kwa usajili.

Hapa kuna mfano wa kina wa ujumbe za SIP zinazohusika katika mchakato wa uthibitishaji wa REGISTER:

1. Ombi la awali la REGISTER kutoka UA hadi registrar server:

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

Ujumbe huu wa awali wa REGISTER umetumwa na UA (Alice) kwa seva ya rejista. Unajumuisha taarifa muhimu kama vile muda unaotakiwa wa usajili (Expires), SIP URI ya mtumiaji (sip:alice@example.com), na anwani ya mawasiliano ya mtumiaji (sip:alice@192.168.1.100:5060).

2. 401 Unauthorized jibu kutoka kwa seva ya rejista:

SIP/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

Seva ya registrar inajibu na ujumbe wa "401 Unauthorized", ambao unajumuisha kichwa "WWW-Authenticate". Kichwa hiki kina taarifa zinazohitajika kwa UA kuthibitisha mwenyewe, kama vile eneo la uthibitishaji, nonce, na algoritimu.

3. Ombi la REGISTER lenye sifa za uthibitishaji:

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

UA inatuma tena ombi la REGISTER, mara hii likijumuisha "Authorization" header with the necessary credentials, such as the username, realm, nonce, and a response value iliyohesabiwa kwa kutumia taarifa zilizotolewa na nenosiri la mtumiaji.

Hivi ndivyo Authorization response inavyohesabiwa:

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}")

4. Usajili uliofanikiwa jibu kutoka kwa seva ya registrar:

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

Baada ya seva ya registrar kuthibitisha vyeti vilivyotolewa, inatuma "200 OK" kama jibu kuashiria kwamba usajili ulikuwa wa mafanikio. Jibu linajumuisha taarifa za mawasiliano zilizojisajili na muda wa kumalizika kwa usajili. Wakati huu, user agent (Alice) amesajiliwa kwa mafanikio na seva ya SIP registrar, na maombi ya kuja ya SIP kwa Alice yanaweza kupitishwa kwa anwani ya mawasiliano inayofaa.

Call Example

Tip

Haijatajwa, lakini User B anahitaji kuwa ametuma REGISTER message to Proxy 2 kabla ya aweze kupokea simu.

---

SIP Usalama na Pentesting - Vidokezo

Sehemu hii inaongeza vidokezo vya vitendo, maalumu kwa protocol bila kunakili miongozo pana ya VoIP. Kwa methodology ya kushambulia VoIP end-to-end, zana na matukio, angalia:

{{#ref}} ../README.md {{#endref}}

Fingerprinting and Discovery

• Tuma ombi la OPTIONS na kagua Allow, Supported, Server na User-Agent headers ili kufingerprint vifaa na stacks:

# nmap NSE (UDP 5060 by default)
sudo nmap -sU -p 5060 --script sip-methods <target>

# Minimal raw OPTIONS over UDP
printf "OPTIONS sip:<target> SIP/2.0\r\nVia: SIP/2.0/UDP attacker;branch=z9\r\nFrom: <sip:probe@attacker>;tag=1\r\nTo: <sip:probe@<target>>\r\nCall-ID: 1@attacker\r\nCSeq: 1 OPTIONS\r\nMax-Forwards: 70\r\nContact: <sip:probe@attacker>\r\nContent-Length: 0\r\n\r\n" | nc -u -w 2 <target> 5060

Username/Extension Enumeration Behavior

• Enumeration typically abuses differences between 401/407 vs 404/403 on REGISTER/INVITE. Fanya seva zijibu kwa njia ile ile ili kuepuka kutoa dalili za watumiaji halali.
• Asterisk chan_sip: set alwaysauthreject=yes (general) ili kuepuka kufichua watumiaji halali. Katika Asterisk mpya (PJSIP), guest calling imezimwa isipokuwa endpoint ya anonymous imeundwa na tabia sawa ya "always auth reject" ni default; bado weka ACL za mtandao na fail2ban kwenye pembezoni.

SIP Digest Authentication: algorithms and cracking

• SIP kawaida inatumia auth ya aina ya HTTP-Digest. Kihistoria MD5 (na MD5-sess) ilikuwa mingi; stacks mpya zinaunga mkono SHA-256 na SHA-512/256 kwa mujibu wa RFC 8760. Tumia algorithimu hizi zenye nguvu katika deployments za kisasa na zima MD5 inapowezekana.
• Offline cracking kutoka pcap ni rahisi kwa MD5 digests. Baada ya kutoa challenge/response, unaweza kutumia hashcat mode 11400 (SIP digest, MD5):

# 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. Thibitisha validation ya certificate kwenye endpoints; nyingi zinakubali self-signed au wildcard certs, jambo ambalo linawezesha MitM katika deployments dhaifu.
• WebRTC softphones mara nyingi hutumia SIP over WebSocket kwa mujibu wa RFC 7118 (ws:// au wss://). Ikiwa PBX inatoa WSS, jaribu authentication na CORS, na hakikisha rate limits zinafanywa pia kwenye HTTP front end.

DoS quick checks (protocol level)

• Kufanya flooding ya INVITE, REGISTER au ujumbe ulioharibika kunaweza kumaliza processing ya transaction.
• Mfano rahisi wa rate-limiting kwa UDP/5060 (Linux iptables hashlimit):

# 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): Katika toleo maalumu za Asterisk, res_pjsip_endpoint_identifier_ip inaweza kutofautisha vibaya maombi ya SIP yasiyoruhusiwa kama endpoint ya ndani, ikiwafanya waweze kufanya vitendo visivyoidhinishwa au kufichua taarifa. Imerudishwa katika 18.23.1, 20.8.1 na 21.3.1. Thibitisha version ya PBX wakati wa kujaribu na ripoti kwa uwajibikaji.

Hardening checklist (SIP-specific)

• Tumia TLS kwa signaling na SRTP/DTLS-SRTP kwa media; zima cleartext inapoweza.
• Lete nywila kali na digest algorithms za nguvu (SHA-256/512-256 inapowezekana; epuka MD5).
• Kwa Asterisk:
• chan_sip: alwaysauthreject=yes, allowguest=no, per-endpoint permit/deny CIDR ACLs.
• PJSIP: usiunde endpoint ya anonymous isipokuwa inahitajika; foshea endpoint acl/media_acl; washa fail2ban au sawa.
• Topology hiding on SIP proxies (e.g., outbound proxy/edge SBC) ili kupunguza information leakage.
• Udhibiti mkali wa OPTIONS na rate limits; zima methods zisizotumika (mfano, MESSAGE, PUBLISH) ikiwa hazihitajiki.

Marejeo

• 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}}