From be64aaf070404c99edf0f800ee3f0d5bf92a1ba2 Mon Sep 17 00:00:00 2001 From: Translator Date: Tue, 30 Sep 2025 03:39:13 +0000 Subject: [PATCH] Translated ['src/network-services-pentesting/pentesting-voip/basic-voip- --- .../sip-session-initiation-protocol.md | 243 ++++++++++++------ 1 file changed, 164 insertions(+), 79 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 810e32189..f00fb8f39 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,71 +4,71 @@ ## Podstawowe informacje -SIP (Session Initiation Protocol) to **protokół sygnalizacji i kontroli połączeń**, szeroko stosowany do nawiązywania, modyfikowania i kończenia sesji multimedialnych, w tym głosu, wideo i wiadomości błyskawicznych, 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 zintegrowanej komunikacji. +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 to: +Niektóre kluczowe cechy SIP obejmują: -1. **Protokół oparty na tekście**: SIP jest protokołem opartym na tekście, co czyni go czytelnym dla ludzi i łatwiejszym do debugowania. Opiera się na modelu żądanie-odpowiedź, podobnym do HTTP, i używa metod takich jak INVITE, ACK, BYE i CANCEL do kontrolowania sesji połączeń. -2. **Skalowalność i elastyczność**: SIP jest wysoce skalowalny i może być używany w małych wdrożeniach, jak i w dużych środowiskach przedsiębiorstw i operatorów. Może być łatwo rozszerzany o nowe funkcje, co czyni go dostosowującym się do różnych przypadków użycia i wymagań. -3. **Interoperacyjność**: Szerokie przyjęcie i standaryzacja SIP zapewniają lepszą interoperacyjność między różnymi urządzeniami, aplikacjami i dostawcami usług, promując płynność komunikacji na różnych platformach. -4. **Modularny design**: SIP współpracuje z innymi protokołami, takimi jak **RTP (Real-time Transport Protocol)** do transmisji mediów i **SDP (Session Description Protocol)** do opisywania sesji multimedialnych. Ten modularny design pozwala na większą elastyczność i kompatybilność z różnymi typami mediów i kodekami. -5. **Serwery proxy i przekierowujące**: SIP może korzystać z serwerów proxy i przekierowujących, aby ułatwić routowanie połączeń i zapewnić zaawansowane funkcje, takie jak przekazywanie połączeń, transfer połączeń i usługi poczty głosowej. -6. **Obecność i wiadomości błyskawiczne**: SIP nie ogranicza się tylko do komunikacji głosowej i wideo. Obsługuje również obecność i wiadomości błyskawiczne, umożliwiając szeroki zakres aplikacji zintegrowanej komunikacji. +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, SIP może być skomplikowany do skonfigurowania i zarządzania, szczególnie w przypadku problemów z przechodzeniem przez NAT i zapory. Jednak jego wszechstronność, skalowalność i szerokie wsparcie w branży czynią go popularnym wyborem dla VoIP i komunikacji multimedialnej. +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. -### Metody SIP +### SIP Methods -Podstawowe metody SIP zdefiniowane w **RFC 3261** obejmują: +Główne metody SIP zdefiniowane w **RFC 3261** obejmują: -1. **INVITE**: Używana do **nawiązania nowej sesji (połączenia)** lub modyfikacji istniejącej. Metoda INVITE przenosi opis sesji (zwykle 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 w celu **potwierdzenia otrzymania** ostatecznej odpowiedzi na żądanie INVITE. Metoda ACK zapewnia niezawodność transakcji INVITE, dostarczając potwierdzenie od końca do końca. -3. **BYE**: Używana do **zakończenia nawiązanej sesji (połączenia)**. Metoda BYE jest wysyłana przez którąkolwiek ze stron w sesji, aby wskazać, że chce zakończyć komunikację. -4. **CANCEL**: Wysyłana w celu **anulowania oczekującego żądania INVITE** przed nawiązaniem sesji. Metoda CANCEL pozwala nadawcy przerwać transakcję INVITE, jeśli zmieni zdanie lub jeśli nie ma odpowiedzi od odbiorcy. -5. **OPTIONS**: Używana do **zapytania o możliwości serwera SIP lub agenta użytkownika**. Metoda OPTIONS może być wysyłana w celu uzyskania informacji o obsługiwanych metodach, typach mediów lub innych rozszerzeniach bez faktycznego nawiązywania sesji. -6. **REGISTER**: Używana przez agenta użytkownika do **zarejestrowania swojej bieżącej lokalizacji w serwerze rejestracyjnym SIP**. Metoda REGISTER pomaga w utrzymaniu aktualnej mapy między URI SIP użytkownika a jego bieżącym adresem IP, umożliwiając routowanie i dostarczanie połączeń. +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] -> Należy pamiętać, ż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 odpowiedź **`401 Unauthorized`**. +> 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 podstawowych metod istnieje **kilka rozszerzonych metod SIP** zdefiniowanych w innych RFC, takich jak: +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 obecność użytkownika lub status połączenia. -2. **NOTIFY**: Również zdefiniowana w RFC 6665, metoda NOTIFY jest wysyłana przez serwer, aby **poinformować subskrybowanego agenta użytkownika** o zmianach w stanie monitorowanego zasobu. -3. **REFER**: Zdefiniowana w RFC 3515, metoda REFER jest używana do **żądania, aby odbiorca wykonał transfer lub odniósł się do strony trzeciej**. Jest to zazwyczaj używane w scenariuszach **transferu połączeń**. -4. **MESSAGE**: Zdefiniowana w RFC 3428, metoda MESSAGE jest używana do **wysyłania wiadomości błyskawicznych między agentami użytkownika SIP**, umożliwiając komunikację opartą na tekście w ramach SIP. -5. **UPDATE**: Zdefiniowana w RFC 3311, metoda UPDATE pozwala na **modyfikację sesji bez wpływu na stan istniejącego dialogu**. Jest to przydatne do aktualizacji parametrów sesji, takich jak kodeki lub typy mediów, podczas trwającego połączenia. -6. **PUBLISH**: Zdefiniowana w RFC 3903, metoda PUBLISH jest używana przez agenta użytkownika do **publikowania informacji o stanie zdarzeń na serwerze**, udostępniając je innym zainteresowanym stronom. +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. -### Kody odpowiedzi SIP +### SIP Response Codes -- **1xx (Odpowiedzi tymczasowe)**: Te odpowiedzi wskazują, że żądanie zostało odebrane, a serwer kontynuuje jego przetwarzanie. -- 100 Trying: Żądanie zostało odebrane, a serwer nad tym pracuje. -- 180 Ringing: Odbiorca jest informowany i podejmie połączenie. -- 183 Session Progress: Dostarcza informacje o postępie połączenia. -- **2xx (Odpowiedzi pomyślne)**: Te odpowiedzi wskazują, że żądanie zostało pomyślnie odebrane, zrozumiane i zaakceptowane. -- 200 OK: Żądanie zakończyło się sukcesem, a serwer je zrealizował. -- 202 Accepted: Żądanie zostało zaakceptowane do przetwarzania, ale nie zostało jeszcze zakończone. -- **3xx (Odpowiedzi przekierowujące)**: Te odpowiedzi wskazują, że dalsze działania są wymagane do zrealizowania żądania, zazwyczaj poprzez skontaktowanie się z alternatywnym zasobem. -- 300 Multiple Choices: Istnieje wiele dostępnych opcji, a użytkownik lub klient musi wybrać jedną. -- 301 Moved Permanently: Żądany zasób został przypisany nowemu stałemu URI. +- **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 wskazują, że żądanie zawiera błędną składnię lub nie może być zrealizowane przez serwer. -- 400 Bad Request: Żądanie było źle sformułowane lub nieprawidłowe. +- **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 zrealizowania. +- 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ł pełnego żądania w czasie, w którym był gotowy czekać. -- 486 Busy Here: Odbiorca jest obecnie zajęty i nie może odebrać połączenia. -- **5xx (Odpowiedzi błędów serwera)**: Te odpowiedzi wskazują, że serwer nie zdołał zrealizować ważnego żądania. +- 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 zrealizowania żą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 (Odpowiedzi globalne błędy)**: Te odpowiedzi wskazują, że żądanie nie może być zrealizowane przez żaden serwer. +- **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: Odbiorca nie chce uczestniczyć w połączeniu. +- 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 @@ -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 ```
-Każdy parametr wyjaśniony +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](mailto: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ół transportowy (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ę razy, które żądanie może być przekazywane przez serwery proxy, aby uniknąć nieskończonych pętli. +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 ` - Nagłówek To określa odbiorcę połączenia, w tym jego nazwę wyświetlaną (John Doe) oraz URI SIP (sip:[jdoe@example.com](mailto:jdoe@example.com)). -5. **From**: `From: Jane Smith ;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](mailto:jsmith@example.org)). Parametr "tag" jest używany do unikalnej identyfikacji roli nadawcy w dialogu. -6. **Call-ID**: `Call-ID: a84b4c76e66710` - Nagłówek Call-ID unikalnie identyfikuje sesję połączenia między dwoma agentami użytkownika. -7. **CSeq**: `CSeq: 314159 INVITE` - Nagłówek CSeq zawiera numer sekwencyjny oraz metodę używaną w żądaniu. Jest używany do dopasowywania odpowiedzi do żądań i wykrywania wiadomości w złej kolejności. -8. **Contact**: `Contact: ` - Nagłówek Contact zapewnia bezpośrednią trasę do nadawcy, która może być używana do kolejnych żądań i odpowiedzi. -9. **User-Agent**: `User-Agent: ExampleSIPClient/1.0` - Nagłówek User-Agent dostarcza informacji o oprogramowaniu lub sprzęcie nadawcy, w tym jego nazwie i wersji. -10. **Allow**: `Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO` - Nagłówek Allow wymienia metody SIP wspierane przez nadawcę. Pomaga to odbiorcy zrozumieć, które metody mogą być używane podczas komunikacji. -11. **Content-Type**: `Content-Type: application/sdp` - Nagłówek Content-Type określa typ mediów ciała wiadomości, w tym przypadku SDP (Session Description Protocol). -12. **Content-Length**: `Content-Length: 142` - Nagłówek Content-Length wskazuje rozmiar ciała wiadomości w bajtach. -13. **Message Body**: Ciało wiadomości zawiera opis sesji SDP, który zawiera informacje o typach mediów, kodekach i protokołach transportowych dla proponowanej sesji. +5. **From**: `From: Jane Smith ;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](mailto: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: ` - 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 (pojedynczy myślnik oznacza brak nazwy sesji) -- `c=IN IP4 pc33.example.com` - Informacje 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) -- `m=audio 49170 RTP/AVP 0` - Opis mediów (typ mediów, numer portu, protokół transportowy 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) do kodeka (PCMU) i jego częstotliwości zegara (8000 Hz). +- `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).
-### Przykład SIP REGISTER +### SIP REGISTER Przykład -Metoda REGISTER jest używana w protokole inicjowania sesji (SIP), aby umożliwić agentowi użytkownika (UA), takiemu jak telefon VoIP lub softphone, **zarejestrowanie swojej lokalizacji w serwerze rejestracyjnym SIP**. Proces ten informuje serwer **gdzie kierować przychodzące żądania SIP przeznaczone dla zarejestrowanego użytkownika**. Serwer rejestracyjny jest zazwyczaj częścią serwera proxy SIP lub dedykowanego serwera rejestracyjnego. +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. Początkowe **REGISTER** żądanie od UA do serwera rejestracyjnego: +1. Initial **REGISTER** request from UA to the 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 ``` -Ta początkowa wiadomość REGISTER jest wysyłana przez UA (Alice) do serwera rejestracji. Zawiera ważne informacje, takie jak pożądany czas rejestracji (Expires), URI SIP użytkownika (sip:[alice@example.com](mailto:alice@example.com)) oraz adres kontaktowy użytkownika (sip:alice@192.168.1.100:5060). +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](mailto:alice@example.com)) oraz adres kontaktowy użytkownika (sip:alice@192.168.1.100:5060). -2. **401 Unauthorized** odpowiedź z serwera rejestracji: -```css -cssCopy codeSIP/2.0 401 Unauthorized +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 ;tag=565656 To: Alice ;tag=7878744 @@ -156,7 +156,7 @@ CSeq: 1 REGISTER WWW-Authenticate: Digest realm="example.com", nonce="abcdefghijk", algorithm=MD5, qop="auth" Content-Length: 0 ``` -Serwer rejestracyjny odpowiada komunikatem "401 Unauthorized", który zawiera nagłówek "WWW-Authenticate". Ten nagłówek zawiera informacje wymagane do uwierzytelnienia UA, takie jak **realm uwierzytelniania, nonce i algorytm**. +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**: ```vbnet @@ -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 ``` -UA wysyła kolejne żądanie REGISTER, tym razem zawierające **nagłówek "Authorization" z niezbędnymi poświadczeniami, takimi jak nazwa użytkownika, realm, nonce oraz wartość odpowiedzi** obliczoną na podstawie podanych informacji i hasła użytkownika. +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. -W ten sposób obliczana jest **odpowiedź Authorization**: +Oto jak obliczana jest **Authorization response**: ```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. **Udana rejestracja** odpowiedź z serwera rejestratora: +4. **Pomyślna rejestracja** — odpowiedź od serwera rejestratora: ```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 ``` -Po zweryfikowaniu podanych danych uwierzytelniających, **serwer rejestracyjny wysyła odpowiedź "200 OK", aby wskazać, że rejestracja była udana**. Odpowiedź zawiera zarejestrowane informacje kontaktowe oraz czas wygaśnięcia rejestracji. W tym momencie agent użytkownika (Alice) jest pomyślnie zarejestrowany w serwerze rejestracyjnym SIP, a przychodzące żądania SIP dla Alice mogą być kierowane do odpowiedniego adresu kontaktowego. +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. -### Przykład połączenia +### Call Example
-> [!NOTE] -> Nie jest to wspomniane, ale Użytkownik B musi wysłać **wiadomość REGISTER do Proxy 2**, zanim będzie mógł odbierać połączenia. +> [!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: + +```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 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): + +```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 + +- 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): + +```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): 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}}