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

SIP (Session Initiation Protocol)

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

Podstawowe informacje

SIP (Session Initiation Protocol) to protokół sygnalizacyjny i kontroli połączeń szeroko stosowany do nawiązywania, modyfikowania i zakończania sesji multimedialnych, w tym głosu, wideo i komunikatorów, w sieciach IP. Opracowany przez Internet Engineering Task Force (IETF), SIP jest zdefiniowany w RFC 3261 i stał się de facto standardem dla VoIP i komunikacji zintegrowanej.

Niektóre kluczowe cechy SIP obejmują:

1. Protokół tekstowy: SIP jest protokołem tekstowym, co sprawia, że jest czytelny dla człowieka i łatwiejszy do debugowania. Bazuje na modelu żądanie-odpowiedź, podobnym do HTTP, i używa metod takich jak INVITE, ACK, BYE i CANCEL do kontroli sesji połączeń.
2. Skalowalność i elastyczność: SIP jest wysoce skalowalny i może być używany zarówno w małych wdrożeniach, jak i w dużych środowiskach korporacyjnych i operatorskich. Można go łatwo rozszerzać o nowe funkcje, co czyni go dostosowalnym do różnych scenariuszy i wymagań.
3. Interoperacyjność: Szerokie przyjęcie i standaryzacja SIP zapewniają lepszą interoperacyjność między różnymi urządzeniami, aplikacjami i dostawcami usług, wspierając płynną komunikację między platformami.
4. Modularna konstrukcja: SIP współpracuje z innymi protokołami, takimi jak RTP (Real-time Transport Protocol) do transmisji mediów oraz SDP (Session Description Protocol) do opisu sesji multimedialnych. Ta modularna konstrukcja daje większą elastyczność i kompatybilność z różnymi typami mediów i kodeków.
5. Serwery proxy i redirect: SIP może używać serwerów proxy i redirect do ułatwienia routingu połączeń oraz zapewniania zaawansowanych funkcji, takich jak przekierowanie połączeń, transfer połączeń i poczta głosowa.
6. Presence i Instant Messaging: SIP nie ogranicza się do komunikacji głosowej i wideo. Wspiera również presence i instant messaging, umożliwiając szeroki zakres aplikacji komunikacji zintegrowanej.

Pomimo wielu zalet, konfiguracja i zarządzanie SIP może być skomplikowane, szczególnie przy problemach z NAT i zaporami sieciowymi. Jednak jego wszechstronność, skalowalność i szerokie wsparcie w branży czynią go popularnym wyborem dla VoIP i komunikacji multimedialnej.

SIP Methods

Główne metody SIP zdefiniowane w RFC 3261 obejmują:

1. INVITE: Używana do inicjowania nowej sesji (połączenia) lub modyfikacji istniejącej. Metoda INVITE przenosi opis sesji (zazwyczaj przy użyciu SDP), aby poinformować odbiorcę o szczegółach proponowanej sesji, takich jak typy mediów, kodeki i protokoły transportowe.
2. ACK: Wysyłana, aby potwierdzić otrzymanie finalnej odpowiedzi na żądanie INVITE. Metoda ACK zapewnia niezawodność transakcji INVITE poprzez potwierdzenie end-to-end.
3. BYE: Używana do zakończenia ustanowionej sesji (połączenia). Metodę BYE wysyła którąkolwiek ze stron sesji, aby wskazać, że chce zakończyć komunikację.
4. CANCEL: Wysyłana, aby anulować oczekujący INVITE przed ustanowieniem sesji. Metoda CANCEL pozwala nadawcy przerwać transakcję INVITE, jeśli zmieni zdanie lub nie otrzyma odpowiedzi od odbiorcy.
5. OPTIONS: Używana do zapytania o możliwości serwera SIP lub user agenta. Metoda OPTIONS może być wysłana, aby uzyskać informacje o obsługiwanych metodach, typach mediów lub innych rozszerzeniach bez faktycznego nawiązywania sesji.
6. REGISTER: Używana przez user agenta do rejestrowania swojej aktualnej lokalizacji w serwerze rejestracyjnym SIP. Metoda REGISTER pomaga w utrzymaniu aktualnego mapowania między SIP URI użytkownika a jego aktualnym adresem IP, umożliwiając routing i dostarczanie połączeń.

Warning

Zauważ, że aby zadzwonić do kogoś, nie jest konieczne używanie REGISTER do czegokolwiek.
Jednak możliwe jest, że aby wykonać INVITE dzwoniący musi najpierw uwierzytelnić się, w przeciwnym razie otrzyma 401 Unauthorized.

Oprócz tych głównych metod istnieje kilka metod rozszerzeń SIP zdefiniowanych w innych RFC, takich jak:

1. SUBSCRIBE: Zdefiniowana w RFC 6665, metoda SUBSCRIBE jest używana do żądania powiadomień o stanie konkretnego zasobu, takiego jak presence użytkownika lub status połączenia.
2. NOTIFY: Również zdefiniowana w RFC 6665, metoda NOTIFY jest wysyłana przez serwer, aby poinformować subskrybowanego user agenta o zmianach w stanie monitorowanego zasobu.
3. REFER: Zdefiniowana w RFC 3515, metoda REFER służy do żądania, aby odbiorca wykonał transfer lub przekazał sprawę do strony trzeciej. Zwykle używana w scenariuszach transferu połączenia.
4. MESSAGE: Zdefiniowana w RFC 3428, metoda MESSAGE służy do wysyłania wiadomości instant między user agentami SIP, umożliwiając komunikację tekstową w ramach SIP.
5. UPDATE: Zdefiniowana w RFC 3311, metoda UPDATE pozwala na modyfikowanie sesji bez wpływu na stan istniejącego dialogu. Jest to przydatne do aktualizacji parametrów sesji, takich jak kodeki czy typy mediów, podczas trwającego połączenia.
6. PUBLISH: Zdefiniowana w RFC 3903, metoda PUBLISH jest używana przez user agenta do publikowania informacji o stanie zdarzeń na serwerze, udostępniając je innym zainteresowanym podmiotom.

SIP Response Codes

• 1xx (Odpowiedzi tymczasowe): Te odpowiedzi oznaczają, że żądanie zostało odebrane, a serwer kontynuuje jego przetwarzanie.
• 100 Trying: Żądanie zostało odebrane i serwer nad nim pracuje.
• 180 Ringing: Dzwoniony użytkownik jest powiadamiany i odbierze połączenie.
• 183 Session Progress: Dostarcza informacji o postępie połączenia.
• 2xx (Odpowiedzi pomyślne): Te odpowiedzi oznaczają, że żądanie zostało pomyślnie odebrane, zrozumiane i zaakceptowane.
• 200 OK: Żądanie powiodło się, a serwer je zrealizował.
• 202 Accepted: Żądanie zostało przyjęte do przetworzenia, ale nie zostało jeszcze zakończone.
• 3xx (Odpowiedzi przekierowujące): Te odpowiedzi oznaczają, że konieczne są dalsze działania, aby spełnić żądanie, zazwyczaj poprzez kontakt z alternatywnym zasobem.
• 300 Multiple Choices: Istnieje kilka dostępnych opcji i użytkownik lub klient musi wybrać jedną.
• 301 Moved Permanently: Żądany zasób został przypisany nowemu trwałemu URI.
• 302 Moved Temporarily: Żądany zasób jest tymczasowo dostępny pod innym URI.
• 305 Use Proxy: Żądanie musi być wysłane do określonego proxy.
• 4xx (Odpowiedzi błędów klienta): Te odpowiedzi oznaczają, że żądanie zawiera błędną składnię lub nie może zostać spełnione przez serwer.
• 400 Bad Request: Żądanie było niepoprawne lub nieprawidłowe.
• 401 Unauthorized: Żądanie wymaga uwierzytelnienia użytkownika.
• 403 Forbidden: Serwer zrozumiał żądanie, ale odmawia jego wykonania.
• 404 Not Found: Żądany zasób nie został znaleziony na serwerze.
• 408 Request Timeout: Serwer nie otrzymał kompletnego żądania w czasie, który był skłonny czekać.
• 486 Busy Here: Dzwoniony użytkownik jest obecnie zajęty i nie może odebrać połączenia.
• 5xx (Odpowiedzi błędów serwera): Te odpowiedzi oznaczają, że serwer nie zdołał spełnić ważnego żądania.
• 500 Internal Server Error: Serwer napotkał błąd podczas przetwarzania żądania.
• 501 Not Implemented: Serwer nie obsługuje funkcjonalności wymaganej do spełnienia żądania.
• 503 Service Unavailable: Serwer jest obecnie niezdolny do obsługi żądania z powodu konserwacji lub przeciążenia.
• 6xx (Globalne odpowiedzi o niepowodzeniu): Te odpowiedzi oznaczają, że żądanie nie może zostać spełnione przez żaden serwer.
• 600 Busy Everywhere: Wszystkie możliwe miejsca docelowe dla połączenia są zajęte.
• 603 Decline: Dzwoniony użytkownik nie chce uczestniczyć w połączeniu.
• 604 Does Not Exist Anywhere: Żądany zasób nie jest dostępny nigdzie w sieci.

Przykłady

Przykład 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

Wyjaśnienie każdego parametru

1. Request-Line: INVITE sip:jdoe@example.com SIP/2.0 - Ta linia wskazuje metodę (INVITE), URI żądania (sip:jdoe@example.com) oraz wersję SIP (SIP/2.0).
2. Via: Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bK776asdhds - Nagłówek Via określa protokół transportu (UDP) oraz adres klienta (pc33.example.com). Parametr "branch" jest używany do wykrywania pętli i dopasowywania transakcji.
3. Max-Forwards: Max-Forwards: 70 - To pole nagłówka ogranicza liczbę przekierowań żądania przez proxy, aby uniknąć nieskończonych pętli.
4. To: To: John Doe <sip:jdoe@example.com> - Nagłówek To określa odbiorcę połączenia, w tym jego nazwę wyświetlaną (John Doe) oraz URI SIP (sip:jdoe@example.com).
5. From: From: Jane Smith <sip:jsmith@example.org>;tag=1928301774 - Nagłówek From określa nadawcę połączenia, w tym jego nazwę wyświetlaną (Jane Smith) oraz URI SIP (sip:jsmith@example.org). Parametr "tag" służy do jednoznacznego identyfikowania roli nadawcy w dialogu.
6. Call-ID: Call-ID: a84b4c76e66710 - Nagłówek Call-ID jednoznacznie identyfikuje sesję rozmowy między dwoma user agentami.
7. CSeq: CSeq: 314159 INVITE - Nagłówek CSeq zawiera numer sekwencji oraz metodę używaną w żądaniu. Służy do dopasowywania odpowiedzi do żądań i wykrywania wiadomości poza kolejnością.
8. Contact: Contact: <sip:jsmith@pc33.example.com> - Nagłówek Contact dostarcza bezpośrednią ścieżkę do nadawcy, która może być użyta w kolejnych żądaniach i odpowiedziach.
9. User-Agent: User-Agent: ExampleSIPClient/1.0 - Nagłówek User-Agent zawiera informacje o oprogramowaniu lub sprzęcie nadawcy, w tym jego nazwę i wersję.
10. Allow: Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO - Nagłówek Allow wymienia metody SIP obsługiwane przez nadawcę. Pomaga to odbiorcy zrozumieć, które metody mogą być używane w trakcie komunikacji.
11. Content-Type: Content-Type: application/sdp - Nagłówek Content-Type określa typ mediów w treści wiadomości, w tym przypadku SDP (Session Description Protocol).
12. Content-Length: Content-Length: 142 - Nagłówek Content-Length wskazuje rozmiar treści wiadomości w bajtach.
13. Message Body: Treść wiadomości zawiera opis sesji SDP, który obejmuje informacje o typach mediów, kodekach i protokołach transportu dla proponowanej sesji.

• v=0 - Wersja protokołu (0 dla SDP)
• o=jsmith 2890844526 2890842807 IN IP4 pc33.example.com - Inicjator i identyfikator sesji
• s=- - Nazwa sesji (jeden myślnik oznacza brak nazwy sesji)
• c=IN IP4 pc33.example.com - Informacja o połączeniu (typ sieci, typ adresu i adres)
• t=0 0 - Informacje o czasie (czasy rozpoczęcia i zakończenia, 0 0 oznacza, że sesja nie jest ograniczona czasowo)
• m=audio 49170 RTP/AVP 0 - Opis mediów (typ medium, numer portu, protokół transportu i lista formatów). W tym przypadku określa strumień audio używający RTP/AVP (Real-time Transport Protocol / Audio Video Profile) i format 0 (PCMU/8000).
• a=rtpmap:0 PCMU/8000 - Atrybut mapujący format (0) na kodek (PCMU) i jego częstotliwość próbkowania (8000 Hz).

SIP REGISTER Przykład

Metoda REGISTER jest używana w Session Initiation Protocol (SIP), aby umożliwić user agent (UA), taki jak telefon VoIP lub softphone, zarejestrowanie swojej lokalizacji na serwerze rejestracji SIP. Proces ten pozwala serwerowi wiedzieć, gdzie kierować przychodzące żądania SIP przeznaczone dla zarejestrowanego użytkownika. Serwer rejestracji zwykle jest częścią serwera proxy SIP lub dedykowanego serwera rejestracji.

Oto szczegółowy przykład wiadomości SIP zaangażowanych w proces uwierzytelniania REGISTER:

1. Initial REGISTER request from UA to the 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

Ta początkowa wiadomość REGISTER jest wysyłana przez UA (Alice) do serwera rejestracyjnego. Zawiera ważne informacje, takie jak żądany czas rejestracji (Expires), SIP URI użytkownika (sip:alice@example.com) oraz adres kontaktowy użytkownika (sip:alice@192.168.1.100:5060).

2. 401 Unauthorized odpowiedź od serwera rejestracyjnego:

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

Serwer rejestrujący odpowiada komunikatem "401 Unauthorized", który zawiera nagłówek "WWW-Authenticate". Ten nagłówek zawiera informacje wymagane, aby UA mogło się uwierzytelnić, takie jak realm uwierzytelniania, nonce i algorytm.

3. Żądanie REGISTER z danymi uwierzytelniającymi:

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 wysyła kolejne żądanie REGISTER, tym razem zawierające nagłówek "Authorization" z niezbędnymi poświadczeniami, takimi jak username, realm, nonce oraz response value obliczonymi przy użyciu podanych informacji i hasła użytkownika.

Oto jak obliczana jest Authorization response:

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. Pomyślna rejestracja — odpowiedź od serwera rejestratora:

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

Po tym, jak serwer registrar zweryfikuje podane poświadczenia, wysyła odpowiedź "200 OK", aby wskazać, że rejestracja zakończyła się pomyślnie. Odpowiedź zawiera zarejestrowane dane kontaktowe oraz czas wygaśnięcia rejestracji. W tym momencie agent użytkownika (Alice) jest poprawnie zarejestrowany na serwerze SIP registrar, a przychodzące żądania SIP dla Alice mogą być kierowane na odpowiedni adres kontaktowy.

Call Example

Tip

Nie jest to wspomniane, ale User B musi mieć wcześniej wysłany REGISTER message to Proxy 2, zanim będzie mógł odbierać połączenia.

---

Uwagi dotyczące bezpieczeństwa SIP i Pentesting

Ta sekcja zawiera praktyczne, specyficzne dla protokołu wskazówki, bez powielania szerszych wytycznych dotyczących VoIP. W celu zapoznania się z end-to-end VoIP attacking methodology, narzędziami i scenariuszami, zobacz:

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

Fingerprinting and Discovery

• Wyślij żądanie OPTIONS i przejrzyj nagłówki Allow, Supported, Server i User-Agent, aby przeprowadzić fingerprinting urządzeń i stosów:

# 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 zwykle wykorzystuje różnice między 401/407 a 404/403 w REGISTER/INVITE. Utwardź serwery, aby odpowiadały jednolicie.
• Asterisk chan_sip: ustaw alwaysauthreject=yes (ogólnie), aby unikać ujawniania poprawnych użytkowników. W nowszym Asterisk (PJSIP) wywołania gości są wyłączone, chyba że zdefiniowano anonymous endpoint i podobne "always auth reject" zachowanie jest domyślnie włączone; nadal egzekwuj ACL sieciowe i fail2ban na obwodzie.

SIP Digest Authentication: algorithms and cracking

• SIP powszechnie używa uwierzytelniania w stylu HTTP-Digest. Historycznie dominowało MD5 (i MD5-sess); nowsze stosy obsługują SHA-256 i SHA-512/256 zgodnie z RFC 8760. Preferuj te silniejsze algorytmy we współczesnych wdrożeniach i wyłącz MD5, gdy to możliwe.
• Offline cracking z pcap jest trywialne dla digestów MD5. Po wyodrębnieniu challenge/response możesz użyć hashcat trybu 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

• Szyfrowanie sygnalizacji:
• sips: URIs i TCP/TLS typowo na porcie 5061. Zweryfikuj walidację certyfikatów na endpointach; wiele akceptuje self-signed lub wildcard certs, co umożliwia MitM w słabych wdrożeniach.
• Softfony WebRTC często używają SIP over WebSocket zgodnie z RFC 7118 (ws:// lub wss://). Jeśli PBX udostępnia WSS, przetestuj uwierzytelnianie i CORS oraz upewnij się, że limity szybkości są egzekwowane także na warstwie HTTP.

DoS quick checks (protocol level)

• Flooding INVITE, REGISTER lub malformed messages może wyczerpać przetwarzanie transakcji.
• Prosty przykład rate-limitingu dla 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): W określonych wydaniach Asterisk res_pjsip_endpoint_identifier_ip mógł błędnie zidentyfikować nieautoryzowane żądania SIP jako lokalny endpoint, potencjalnie umożliwiając nieautoryzowane działania lub ujawnienie informacji. Naprawione w 18.23.1, 20.8.1 i 21.3.1. Zweryfikuj wersję swojego PBX podczas testów i zgłaszaj odpowiedzialnie.

Hardening checklist (SIP-specific)

• Preferuj TLS dla sygnalizacji oraz SRTP/DTLS-SRTP dla mediów; wyłącz cleartext tam, gdzie to możliwe.
• Wymuszaj silne hasła i silne algorytmy digest (SHA-256/512-256 tam, gdzie wspierane; unikaj MD5).
• Dla Asterisk:
• chan_sip: alwaysauthreject=yes, allowguest=no, per-endpoint permit/deny CIDR ACLs.
• PJSIP: nie twórz anonymous endpointu, chyba że jest potrzebny; wymuś endpoint acl/media_acl; włącz fail2ban lub odpowiednik.
• Ukrywanie topologii na proxy SIP (np. outbound proxy/edge SBC) w celu zmniejszenia ujawniania informacji.
• Ścisłe obsługiwanie OPTIONS i limity szybkości; wyłącz nieużywane metody (np. MESSAGE, PUBLISH) jeśli nie są wymagane.

References

• RFC 8760 – Użycie SHA-256 i SHA-512/256 dla HTTP Digest (dotyczy również SIP Digest): 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}}