From a7cb9f3dadea26b53af07c8240c6c0738e734b6f Mon Sep 17 00:00:00 2001 From: Translator Date: Tue, 30 Sep 2025 03:39:14 +0000 Subject: [PATCH] Translated ['src/network-services-pentesting/pentesting-voip/basic-voip- --- .../sip-session-initiation-protocol.md | 267 ++++++++++++------ 1 file changed, 176 insertions(+), 91 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 5e91b1394..5eed44cf0 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 @@ ## 基本情報 -SIP (Session Initiation Protocol) は、**シグナリングおよびコール制御プロトコル**であり、IPネットワーク上で音声、ビデオ、インスタントメッセージングを含むマルチメディアセッションを確立、変更、終了するために広く使用されています。**Internet Engineering Task Force (IETF)** によって開発され、SIPは**RFC 3261**で定義されており、VoIPおよび統合コミュニケーションの事実上の標準となっています。 +SIP (Session Initiation Protocol) は、IPネットワーク上で音声、ビデオ、インスタントメッセージを含むマルチメディアセッションの確立、変更、終了に広く使われる**シグナリングおよび通話制御プロトコル**です。**Internet Engineering Task Force (IETF)** によって開発され、**RFC 3261** で定義されており、VoIPおよび統合コミュニケーションの事実上の標準となっています。 -SIPの主な特徴は以下の通りです： +SIPの主な特徴は次のとおりです: -1. **テキストベースのプロトコル**: SIPはテキストベースのプロトコルであり、人間が読みやすく、デバッグが容易です。HTTPに似たリクエスト-レスポンスモデルに基づいており、コールセッションを制御するためにINVITE、ACK、BYE、CANCELなどのメソッドを使用します。 -2. **スケーラビリティと柔軟性**: SIPは非常にスケーラブルであり、小規模な展開から大規模な企業やキャリアグレードの環境まで使用できます。新しい機能で簡単に拡張でき、さまざまなユースケースや要件に適応可能です。 -3. **相互運用性**: SIPの広範な採用と標準化により、異なるデバイス、アプリケーション、サービスプロバイダー間の相互運用性が向上し、さまざまなプラットフォーム間でシームレスな通信が促進されます。 -4. **モジュラー設計**: SIPは、メディア伝送のための**RTP (Real-time Transport Protocol)**やマルチメディアセッションを記述するための**SDP (Session Description Protocol)**など、他のプロトコルと連携して動作します。このモジュラー設計により、さまざまなメディアタイプやコーデックとの柔軟性と互換性が向上します。 -5. **プロキシおよびリダイレクトサーバー**: SIPは、コールルーティングを促進し、コール転送、コール転送、ボイスメールサービスなどの高度な機能を提供するために、プロキシおよびリダイレクトサーバーを使用できます。 -6. **プレゼンスおよびインスタントメッセージング**: SIPは音声およびビデオ通信に限定されません。プレゼンスおよびインスタントメッセージングもサポートしており、幅広い統合コミュニケーションアプリケーションを可能にします。 +1. **テキストベースのプロトコル**: SIPはテキストベースのプロトコルであり、人間に読みやすくデバッグもしやすいです。HTTPに似たリクエスト-レスポンスモデルに基づいており、INVITE、ACK、BYE、CANCELなどのメソッドを使用して通話セッションを制御します。 +2. **スケーラビリティと柔軟性**: SIPは高いスケーラビリティを持ち、小規模な導入から大規模なエンタープライズやキャリアグレードの環境まで利用できます。新機能で簡単に拡張できるため、さまざまなユースケースや要件に適応可能です。 +3. **相互運用性**: SIPの広範な採用と標準化により、異なるデバイス、アプリケーション、サービスプロバイダ間での相互運用性が向上し、さまざまなプラットフォーム間でのシームレスな通信を促進します。 +4. **モジュール設計**: SIPはメディア伝送に**RTP (Real-time Transport Protocol)**、マルチメディアセッションの記述に**SDP (Session Description Protocol)** などの他プロトコルと連携します。このモジュール設計により、さまざまなメディアタイプやコーデックとの柔軟性と互換性が向上します。 +5. **プロキシおよびリダイレクトサーバ**: SIPはプロキシやリダイレクトサーバを使用して通話ルーティングを支援し、転送、転送先変更、ボイスメールなどの高度な機能を提供できます。 +6. **プレゼンスとインスタントメッセージ**: SIPは音声やビデオに限定されず、プレゼンスやインスタントメッセージもサポートしており、幅広い統合コミュニケーションアプリケーションを可能にします。 -多くの利点があるにもかかわらず、SIPは特にNATトラバーサルやファイアウォールの問題に対処する際に構成および管理が複雑になることがあります。しかし、その多様性、スケーラビリティ、および業界全体での広範なサポートにより、VoIPおよびマルチメディア通信の人気の選択肢となっています。 +多くの利点がある一方で、NAT越えやファイアウォールの問題を扱う際には設定や管理が複雑になることがあります。それでも、その汎用性、スケーラビリティ、および業界での広範なサポートにより、VoIPやマルチメディア通信で広く採用されています。 -### SIPメソッド +### SIP メソッド -**RFC 3261**で定義されたコアSIPメソッドには以下が含まれます： +**RFC 3261** で定義されたコアなSIPメソッドには以下が含まれます: -1. **INVITE**: **新しいセッション（コール）を開始**するか、既存のセッションを変更するために使用されます。INVITEメソッドは、提案されたセッションの詳細（メディアタイプ、コーデック、トランスポートプロトコルなど）を受信者に通知するために、セッション記述（通常はSDPを使用）を運びます。 -2. **ACK**: INVITEリクエストに対する最終応答の**受信を確認**するために送信されます。ACKメソッドは、エンドツーエンドの確認を提供することにより、INVITEトランザクションの信頼性を確保します。 -3. **BYE**: 確立されたセッション（コール）を**終了する**ために使用されます。BYEメソッドは、通信を終了したいことを示すために、セッション内のいずれかの当事者によって送信されます。 -4. **CANCEL**: セッションが確立される前に、保留中のINVITEリクエストを**キャンセル**するために送信されます。CANCELメソッドは、送信者が気が変わった場合や受信者からの応答がない場合に、INVITEトランザクションを中止することを可能にします。 -5. **OPTIONS**: SIPサーバーまたはユーザーエージェントの**機能を照会**するために使用されます。OPTIONSメソッドは、セッションを実際に確立することなく、サポートされているメソッド、メディアタイプ、または他の拡張に関する情報を要求するために送信できます。 -6. **REGISTER**: ユーザーエージェントがSIPレジストラサーバーに**現在の位置を登録**するために使用されます。REGISTERメソッドは、ユーザーのSIP URIと現在のIPアドレスとの間の最新のマッピングを維持するのに役立ち、コールルーティングと配信を可能にします。 +1. **INVITE**: 新しいセッション（通話）を**開始**するか、既存のセッションを変更するために使用されます。INVITEメソッドはセッション記述（通常はSDPを使用）を運び、提案されたセッションのメディアタイプ、コーデック、トランスポートプロトコルなどの詳細を受信者に通知します。 +2. **ACK**: INVITEリクエストに対する最終応答の受信を**確認**するために送信されます。ACKメソッドはINVITEトランザクションの信頼性を確保するためにエンドツーエンドの確認を提供します。 +3. **BYE**: 確立されたセッション（通話）を**終了**するために使用されます。BYEメソッドはセッションのいずれかの参加者が通信を終了したいことを示すために送信します。 +4. **CANCEL**: セッションが確立される前に保留中のINVITEを**キャンセル**するために送信されます。CANCELメソッドにより、送信者は心変わりした場合や受信者から返信がない場合にINVITEトランザクションを中止できます。 +5. **OPTIONS**: SIPサーバやユーザエージェントの**機能を照会**するために使用されます。OPTIONSメソッドは、セッションを実際に確立することなく、サポートされているメソッド、メディアタイプ、またはその他の拡張についての情報を要求できます。 +6. **REGISTER**: ユーザエージェントが**現在の所在地をSIPレジストラサーバに登録**するために使用します。REGISTERメソッドは、ユーザのSIP URIと現在のIPアドレスとの間の最新のマッピングを維持し、通話のルーティングと配信を可能にします。 > [!WARNING] -> 誰かに電話をかけるために、**REGISTER**を使用する必要はありません。\ -> ただし、**INVITE**を実行するために、発信者が最初に**認証**を行う必要がある場合があり、そうでないと**`401 Unauthorized`**の応答を受け取ることになります。 +> 誰かに発信するのに **REGISTER を必ず使う必要はない** ことに注意してください。\ +> ただし、INVITEを行うために発信者が先に**認証（authenticate）**する必要があり、さもなければ**`401 Unauthorized`** の応答を受け取る可能性があります。 -これらのコアメソッドに加えて、他のRFCで定義された**いくつかのSIP拡張メソッド**があります： +これらのコアメソッドに加えて、他のRFCで定義されたいくつかの**SIP拡張メソッド**もあります。たとえば: -1. **SUBSCRIBE**: RFC 6665で定義されており、SUBSCRIBEメソッドは特定のリソースの状態（ユーザーのプレゼンスやコールステータスなど）に関する**通知を要求**するために使用されます。 -2. **NOTIFY**: RFC 6665でも定義されており、NOTIFYメソッドは、監視されているリソースの状態の変化について**サブスクライブされたユーザーエージェント**に通知するためにサーバーによって送信されます。 -3. **REFER**: RFC 3515で定義されており、REFERメソッドは、受信者に**転送を実行するか、第三者を参照する**ように要求するために使用されます。これは通常、**コール転送**シナリオで使用されます。 -4. **MESSAGE**: RFC 3428で定義されており、MESSAGEメソッドは、SIPユーザーエージェント間で**インスタントメッセージを送信**するために使用され、SIPフレームワーク内でのテキストベースの通信を可能にします。 -5. **UPDATE**: RFC 3311で定義されており、UPDATEメソッドは、**既存のダイアログの状態に影響を与えずにセッションを変更**することを可能にします。これは、進行中のコール中にコーデックやメディアタイプなどのセッションパラメータを更新するのに便利です。 -6. **PUBLISH**: RFC 3903で定義されており、PUBLISHメソッドは、ユーザーエージェントが**イベント状態情報をサーバーに公開**し、他の関心のある当事者が利用できるようにするために使用されます。 +1. **SUBSCRIBE**: RFC 6665で定義され、特定のリソース（ユーザのプレゼンスや通話状態など）の状態に関する**通知を要求**するために使用されます。 +2. **NOTIFY**: 同じくRFC 6665で定義され、サーバが**購読しているユーザエージェントに**監視対象リソースの状態変化を通知するために送信します。 +3. **REFER**: RFC 3515で定義され、受信者に対して**転送を実行するか第三者を参照することを要求**するために使用されます。これは通常、**通話転送**のシナリオで使われます。 +4. **MESSAGE**: RFC 3428で定義され、SIPユーザエージェント間で**インスタントメッセージを送信**するために使用され、SIPフレームワーク内でのテキストベース通信を可能にします。 +5. **UPDATE**: RFC 3311で定義され、既存のダイアログの状態に影響を与えることなく**セッションを変更**することを可能にします。通話中にコーデックやメディアパラメータを更新する際に有用です。 +6. **PUBLISH**: RFC 3903で定義され、ユーザエージェントがサーバに**イベント状態情報を公開**し、他の関係者が利用できるようにします。 -### SIPレスポンスコード +### SIP 応答コード -- **1xx (暫定応答)**: これらの応答は、リクエストが受信され、サーバーが処理を続けていることを示します。 -- 100 Trying: リクエストが受信され、サーバーが処理中です。 -- 180 Ringing: 呼び出し先が通知され、コールを受け取ります。 -- 183 Session Progress: コールの進行状況に関する情報を提供します。 -- **2xx (成功応答)**: これらの応答は、リクエストが正常に受信され、理解され、受け入れられたことを示します。 -- 200 OK: リクエストが成功し、サーバーがそれを満たしました。 +- **1xx (Provisional Responses)**: これらの応答はリクエストが受信され、サーバが処理を継続していることを示します。 +- 100 Trying: リクエストが受信され、サーバが処理中であることを示します。 +- 180 Ringing: 被呼者に着信が通知され、応答（通話の受け入れ）を待っている状態です。 +- 183 Session Progress: 通話の進行状況に関する情報を提供します。 +- **2xx (Successful Responses)**: これらの応答はリクエストが正常に受信、理解、受諾されたことを示します。 +- 200 OK: リクエストは成功し、サーバがそれを履行したことを示します。 - 202 Accepted: リクエストは処理のために受け入れられましたが、まだ完了していません。 -- **3xx (リダイレクション応答)**: これらの応答は、リクエストを満たすためにさらなるアクションが必要であることを示します。通常は代替リソースに連絡することによってです。 -- 300 Multiple Choices: 複数のオプションが利用可能であり、ユーザーまたはクライアントが1つを選択する必要があります。 -- 301 Moved Permanently: リクエストされたリソースに新しい永続的なURIが割り当てられました。 -- 302 Moved Temporarily: リクエストされたリソースは一時的に異なるURIで利用可能です。 -- 305 Use Proxy: リクエストは指定されたプロキシに送信する必要があります。 -- **4xx (クライアントエラー応答)**: これらの応答は、リクエストに不正な構文が含まれているか、サーバーによって満たすことができないことを示します。 -- 400 Bad Request: リクエストが不正または無効でした。 -- 401 Unauthorized: リクエストにはユーザー認証が必要です。 -- 403 Forbidden: サーバーはリクエストを理解しましたが、満たすことを拒否します。 -- 404 Not Found: リクエストされたリソースはサーバー上に見つかりませんでした。 -- 408 Request Timeout: サーバーは、待機する準備ができていた時間内に完全なリクエストを受信しませんでした。 -- 486 Busy Here: 呼び出し先は現在ビジーで、コールを受け取ることができません。 -- **5xx (サーバーエラー応答)**: これらの応答は、サーバーが有効なリクエストを満たすことに失敗したことを示します。 -- 500 Internal Server Error: サーバーはリクエストを処理中にエラーに遭遇しました。 -- 501 Not Implemented: サーバーはリクエストを満たすために必要な機能をサポートしていません。 -- 503 Service Unavailable: サーバーは現在、メンテナンスまたは過負荷のためにリクエストを処理できません。 -- **6xx (グローバル失敗応答)**: これらの応答は、リクエストがどのサーバーによっても満たされないことを示します。 -- 600 Busy Everywhere: コールのすべての可能な宛先がビジーです。 -- 603 Decline: 呼び出し先はコールに参加したくありません。 -- 604 Does Not Exist Anywhere: リクエストされたリソースはネットワーク内のどこにも存在しません。 +- **3xx (Redirection Responses)**: これらの応答はリクエストを完了するためにさらに別のアクションが必要であることを示し、通常は別のリソースに連絡することを意味します。 +- 300 Multiple Choices: 複数の選択肢があり、ユーザまたはクライアントがその中から選択する必要があります。 +- 301 Moved Permanently: 要求されたリソースに新しい恒久的なURIが割り当てられました。 +- 302 Moved Temporarily: 要求されたリソースは一時的に別のURIで利用可能です。 +- 305 Use Proxy: リクエストは指定されたプロキシへ送信する必要があります。 +- **4xx (Client Error Responses)**: これらの応答はリクエストに文法上の誤りがあるか、サーバがそれを履行できないことを示します。 +- 400 Bad Request: リクエストが不正または無効であることを示します。 +- 401 Unauthorized: リクエストにはユーザ認証が必要であることを示します。 +- 403 Forbidden: サーバはリクエストを理解したが、履行を拒否しました。 +- 404 Not Found: 要求されたリソースがサーバ上に見つかりません。 +- 408 Request Timeout: サーバが待機できる時間内に完全なリクエストを受信しませんでした。 +- 486 Busy Here: 被呼者は現在通話中で、通話を受けることができません。 +- **5xx (Server Error Responses)**: これらの応答はサーバが有効なリクエストを履行するのに失敗したことを示します。 +- 500 Internal Server Error: サーバがリクエスト処理中にエラーを検出したことを示します。 +- 501 Not Implemented: サーバがリクエストを履行するために必要な機能をサポートしていません。 +- 503 Service Unavailable: サーバは保守中または過負荷のため、現在リクエストを処理できません。 +- **6xx (Global Failure Responses)**: これらの応答はネットワーク上のいかなるサーバでもリクエストを履行できないことを示します。 +- 600 Busy Everywhere: 通話の可能なすべての宛先がビジー状態です。 +- 603 Decline: 被呼者は通話に参加したくないことを示します。 +- 604 Does Not Exist Anywhere: 要求されたリソースはネットワーク上どこにも存在しません。 ## 例 -### SIP INVITEの例 +### SIP INVITE の例 ``` 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 ```
各パラメータの説明 -1. **Request-Line**: `INVITE sip:jdoe@example.com SIP/2.0` - この行は、メソッド（INVITE）、リクエストURI（sip:[jdoe@example.com](mailto:jdoe@example.com)）、およびSIPバージョン（SIP/2.0）を示します。 -2. **Via**: `Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bK776asdhds` - Viaヘッダーは、トランスポートプロトコル（UDP）とクライアントのアドレス（pc33.example.com）を指定します。「branch」パラメータは、ループ検出とトランザクションマッチングに使用されます。 -3. **Max-Forwards**: `Max-Forwards: 70` - このヘッダーフィールドは、リクエストがプロキシによって転送される回数を制限し、無限ループを回避します。 -4. **To**: `To: John Doe ` - Toヘッダーは、通話の受信者を指定し、表示名（John Doe）とSIP URI（sip:[jdoe@example.com](mailto:jdoe@example.com)）を含みます。 -5. **From**: `From: Jane Smith ;tag=1928301774` - Fromヘッダーは、通話の送信者を指定し、表示名（Jane Smith）とSIP URI（sip:[jsmith@example.org](mailto:jsmith@example.org)）を含みます。「tag」パラメータは、ダイアログ内で送信者の役割を一意に識別するために使用されます。 -6. **Call-ID**: `Call-ID: a84b4c76e66710` - Call-IDヘッダーは、2つのユーザーエージェント間の通話セッションを一意に識別します。 -7. **CSeq**: `CSeq: 314159 INVITE` - CSeqヘッダーは、シーケンス番号とリクエストで使用されるメソッドを含みます。これは、リクエストに対する応答をマッチさせ、順序が乱れたメッセージを検出するために使用されます。 -8. **Contact**: `Contact: ` - Contactヘッダーは、送信者への直接のルートを提供し、後続のリクエストや応答に使用できます。 -9. **User-Agent**: `User-Agent: ExampleSIPClient/1.0` - User-Agentヘッダーは、送信者のソフトウェアまたはハードウェアに関する情報を提供し、その名前とバージョンを含みます。 -10. **Allow**: `Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO` - Allowヘッダーは、送信者がサポートするSIPメソッドをリストします。これにより、受信者は通信中に使用できるメソッドを理解できます。 -11. **Content-Type**: `Content-Type: application/sdp` - Content-Typeヘッダーは、メッセージボディのメディアタイプを指定し、この場合はSDP（Session Description Protocol）です。 -12. **Content-Length**: `Content-Length: 142` - Content-Lengthヘッダーは、メッセージボディのサイズをバイト単位で示します。 -13. **Message Body**: メッセージボディには、メディアタイプ、コーデック、および提案されたセッションのトランスポートプロトコルに関する情報を含むSDPセッション記述が含まれます。 +1. **Request-Line**: `INVITE sip:jdoe@example.com SIP/2.0` - この行はメソッド (INVITE)、リクエストURI (sip:[jdoe@example.com](mailto:jdoe@example.com))、および SIP バージョン (SIP/2.0) を示します。 +2. **Via**: `Via: SIP/2.0/UDP pc33.example.com;branch=z9hG4bK776asdhds` - Via ヘッダはトランスポートプロトコル (UDP) とクライアントのアドレス (pc33.example.com) を指定します。`branch` パラメータはループ検出とトランザクションの照合に使用されます。 +3. **Max-Forwards**: `Max-Forwards: 70` - このヘッダフィールドは、プロキシによってリクエストが転送される回数の上限を制限し、無限ループを防ぎます。 +4. **To**: `To: John Doe ` - To ヘッダは通話の受信者を指定し、表示名 (John Doe) と SIP URI (sip:[jdoe@example.com](mailto:jdoe@example.com)) を含みます。 +5. **From**: `From: Jane Smith ;tag=1928301774` - From ヘッダは通話の送信者を指定し、表示名 (Jane Smith) と SIP URI (sip:[jsmith@example.org](mailto:jsmith@example.org)) を含みます。`tag` パラメータはダイアログ内で送信者の役割を一意に識別するために使用されます。 +6. **Call-ID**: `Call-ID: a84b4c76e66710` - Call-ID ヘッダは二つの user agent 間の通話セッションを一意に識別します。 +7. **CSeq**: `CSeq: 314159 INVITE` - CSeq ヘッダはシーケンス番号とリクエストで使用されたメソッドを含みます。レスポンスとリクエストの照合や、メッセージの順序外検出に用いられます。 +8. **Contact**: `Contact: ` - Contact ヘッダは送信者への直接ルートを提供し、以降のリクエストやレスポンスに使用できます。 +9. **User-Agent**: `User-Agent: ExampleSIPClient/1.0` - User-Agent ヘッダは送信者のソフトウェアやハードウェアに関する情報（名称とバージョン）を提供します。 +10. **Allow**: `Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO` - Allow ヘッダは送信者がサポートする SIP メソッドを列挙します。これにより受信者は通信中に使用可能なメソッドを把握できます。 +11. **Content-Type**: `Content-Type: application/sdp` - Content-Type ヘッダはメッセージボディのメディアタイプを指定します。この場合は SDP (Session Description Protocol) です。 +12. **Content-Length**: `Content-Length: 142` - Content-Length ヘッダはメッセージボディのバイト数を示します。 +13. **Message Body**: メッセージボディには SDP セッション記述が含まれており、提案されたセッションのメディアタイプ、コーデック、トランスポートプロトコルに関する情報が記載されます。 -- `v=0` - プロトコルバージョン（SDPの場合は0） +- `v=0` - プロトコルバージョン (SDP の場合は 0) - `o=jsmith 2890844526 2890842807 IN IP4 pc33.example.com` - 発信者とセッション識別子 -- `s=-` - セッション名（単一のハイフンはセッション名がないことを示します） -- `c=IN IP4 pc33.example.com` - 接続情報（ネットワークタイプ、アドレスタイプ、およびアドレス） -- `t=0 0` - タイミング情報（開始時刻と停止時刻、0 0はセッションが制限されていないことを意味します） -- `m=audio 49170 RTP/AVP 0` - メディア記述（メディアタイプ、ポート番号、トランスポートプロトコル、およびフォーマットリスト）。この場合、RTP/AVP（リアルタイムトランスポートプロトコル/オーディオビデオプロファイル）を使用したオーディオストリームとフォーマット0（PCMU/8000）を指定します。 -- `a=rtpmap:0 PCMU/8000` - フォーマット（0）をコーデック（PCMU）およびそのクロックレート（8000 Hz）にマッピングする属性です。 +- `s=-` - セッション名（ハイフン1文字はセッション名がないことを示します） +- `c=IN IP4 pc33.example.com` - 接続情報（ネットワークタイプ、アドレスタイプ、アドレス） +- `t=0 0` - タイミング情報（開始・終了時刻。0 0 はセッションに時間制限がないことを示します） +- `m=audio 49170 RTP/AVP 0` - メディア記述（メディアタイプ、ポート番号、トランスポートプロトコル、フォーマットリスト）。この例では RTP/AVP（Real-time Transport Protocol / Audio Video Profile）を用いたオーディオストリームで、フォーマット 0（PCMU/8000）を指定しています。 +- `a=rtpmap:0 PCMU/8000` - フォーマット (0) をコーデック (PCMU) とそのクロックレート (8000 Hz) にマッピングする属性。
-### SIP REGISTERの例 +### SIP REGISTER の例 -REGISTERメソッドは、Session Initiation Protocol（SIP）で、VoIP電話やソフトフォンなどのユーザーエージェント（UA）が**SIPレジストラサーバーに自分の位置を登録する**ために使用されます。このプロセスにより、サーバーは**登録されたユーザー宛ての着信SIPリクエストをどこにルーティングするかを知ることができます**。レジストラサーバーは通常、SIPプロキシサーバーまたは専用の登録サーバーの一部です。 +REGISTER メソッドは Session Initiation Protocol (SIP) において、VoIP phone や softphone のような user agent (UA) が **SIP registrar server に自分の位置を登録する**ために使用されます。この処理によりサーバは **登録されたユーザ宛の着信 SIP リクエストをどこにルーティングするか** を把握できます。registrar server は通常 SIP proxy server の一部か、専用の registration server です。 -以下は、REGISTER認証プロセスに関与するSIPメッセージの詳細な例です。 +以下は REGISTER 認証プロセスでやり取りされる SIP メッセージの詳細な例です: -1. UAからレジスタサーバーへの初期**REGISTER**リクエスト: +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 ``` -この初期のREGISTERメッセージは、UA（アリス）からレジストラサーバーに送信されます。これには、希望する登録期間（Expires）、ユーザーのSIP URI（sip:[alice@example.com](mailto:alice@example.com)）、およびユーザーの連絡先アドレス（sip:alice@192.168.1.100:5060）などの重要な情報が含まれています。 +この最初の REGISTER メッセージは UA (Alice) によって registrar サーバーに送信されます。メッセージには、希望する登録期間 (Expires)、ユーザーの SIP URI (sip:[alice@example.com](mailto:alice@example.com))、およびユーザーの連絡先アドレス (sip:alice@192.168.1.100:5060) などの重要な情報が含まれます。 -2. **401 Unauthorized** レジストラサーバーからの応答: -```css -cssCopy codeSIP/2.0 401 Unauthorized +2. registrar サーバーからの **401 Unauthorized** レスポンス: +``` +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 ``` -レジストラサーバーは「401 Unauthorized」メッセージで応答し、これには「WWW-Authenticate」ヘッダーが含まれています。このヘッダーには、UAが自分自身を認証するために必要な情報、例えば**認証レルム、ノンス、およびアルゴリズム**が含まれています。 +レジストラサーバは "401 Unauthorized" メッセージで応答し、"WWW-Authenticate" ヘッダを含みます。このヘッダには、UAが自身を認証するために必要な情報、例えば authentication realm、nonce、algorithm が含まれます。 -3. 認証情報を含むREGISTERリクエスト: +3. REGISTER リクエスト **認証資格情報を含む**: ```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 ``` -UAは別のREGISTERリクエストを送信します。このリクエストには、**必要な資格情報（ユーザー名、レルム、ノンス、および提供された情報とユーザーのパスワードを使用して計算されたレスポンス値）を含む"Authorization"ヘッダー**が含まれています。 +UA は別の REGISTER リクエストを送信します。今回は、**"Authorization" header with the necessary credentials, such as the username, realm, nonce, and a response value**（与えられた情報とユーザーのパスワードを使用して計算される）を含めています。 -これが**Authorizationレスポンス**の計算方法です： +これは **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. **成功した登録** レスポンスはレジストラサーバーからのものです: +4. **登録成功** レジストラサーバーからのレスポンス: ```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 ``` -レジストラサーバーが提供された認証情報を確認した後、**登録が成功したことを示す「200 OK」レスポンスを送信します**。レスポンスには、登録された連絡先情報と登録の有効期限が含まれています。この時点で、ユーザーエージェント（アリス）はSIPレジストラサーバーに正常に登録され、アリスへの着信SIPリクエストは適切な連絡先アドレスにルーティングされることができます。 +認証が検証されると、レジストラサーバは "200 OK" を返して登録が成功したことを示します。レスポンスには登録されたコンタクト情報と登録の有効期限が含まれます。この時点でユーザーエージェント (Alice) は SIP レジストラサーバに正常に登録され、Alice 宛の着信 SIP リクエストは適切なコンタクトアドレスへルーティングできます。 -### コールの例 +### Call Example
-> [!NOTE] -> 言及されていませんが、ユーザーBは**Proxy 2にREGISTERメッセージを送信する必要があります**。そうしないと、通話を受けることができません。 +> [!TIP] +> 触れられていませんが、User B は着信を受け取る前に **REGISTER message to Proxy 2** を送信している必要があります。 + + +--- + +## SIP Security and Pentesting Notes + +このセクションでは、より広範な VoIP ガイダンスと重複しない実践的なプロトコル固有のヒントを追加します。エンドツーエンドの VoIP 攻撃手法、ツール、シナリオについては、以下を参照してください: + +{{#ref}} +../README.md +{{#endref}} + +### フィンガープリンティングと検出 + +- OPTIONS リクエストを送信し、`Allow`、`Supported`、`Server`、`User-Agent` ヘッダを確認してデバイスやスタックをフィンガープリントします: + +```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 +``` + +### ユーザー名/内線列挙の挙動 + +- 列挙は通常 `REGISTER`/`INVITE` に対する `401/407` と `404/403` の違いを悪用します。サーバの応答を均一化してハードニングしてください。 +- Asterisk chan_sip: `alwaysauthreject=yes` を設定して有効なユーザの公開を避けます。新しい Asterisk (PJSIP) では、`anonymous` endpoint が定義されていない限り guest calling は無効化され、同様の "always auth reject" 挙動がデフォルトですが、境界でネットワーク ACL と fail2ban を適用してください。 + +### SIP Digest Authentication: algorithms and cracking + +- SIP は一般的に HTTP-Digest スタイルの認証を使用します。過去には MD5（および MD5-sess）が広く使われていましたが、新しいスタックは RFC 8760 に沿った SHA-256 や SHA-512/256 をサポートします。モダンな配備ではこれらの強いアルゴリズムを優先し、可能であれば MD5 を無効にしてください。 +- pcap からのオフラインクラッキングは MD5 ダイジェストでは容易です。challenge/response を抽出した後、hashcat のモード 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 は HTTP Digest（SIP でも使用される）に対して SHA-256 と SHA-512/256 を定義しています。採用状況はまちまちなので、モダンな PBX を対象にする際はツールがこれらに対応していることを確認してください。 + +### SIP over TLS (SIPS) and over WebSockets + +- シグナリングの暗号化: +- `sips:` URI と TCP/TLS は通常ポート 5061 を使用します。エンドポイントでの証明書検証を確認してください。多くは self-signed や wildcard certs を受け入れるため、弱い配備では MitM を許してしまう場合があります。 +- WebRTC softphone は RFC 7118 に従い SIP over WebSocket (`ws://` または `wss://`) を使うことが多いです。PBX が WSS を公開している場合は認証と CORS をテストし、HTTP フロントエンド側でもレート制限が適用されていることを確認してください。 + +### DoS quick checks (protocol level) + +- INVITE、REGISTER、または不正なメッセージのフラッディングはトランザクション処理を枯渇させる可能性があります。 +- 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 +``` + +### 注意すべき最近の関連 SIP スタック CVE (Asterisk PJSIP) + +- CVE-2024-35190 (published May 17, 2024): 特定の Asterisk リリースにおいて、`res_pjsip_endpoint_identifier_ip` が不正な SIP リクエストをローカルエンドポイントと誤識別する可能性があり、不正な操作や情報露出を引き起こす可能性がありました。18.23.1、20.8.1、21.3.1 で修正されています。テスト時は PBX のバージョンを確認し、責任ある報告を行ってください。 + +### ハードニングチェックリスト（SIP 固有） + +- シグナリングには TLS、メディアには SRTP/DTLS-SRTP を優先し、可能な限り平文を無効にしてください。 +- 強力なパスワードとダイジェストアルゴリズム（対応があれば SHA-256/512-256 を使用し、MD5 は避ける）を強制してください。 +- Asterisk 向け: + - chan_sip: `alwaysauthreject=yes`、`allowguest=no`、エンドポイントごとの `permit`/`deny` CIDR ACL を設定。 + - PJSIP: 必要でない限り `anonymous` endpoint を作成しないこと。endpoint の `acl`/`media_acl` を強制し、fail2ban などを有効にする。 +- SIP プロキシでのトポロジーハイディング（例: outbound proxy/edge SBC）により情報漏洩を減らす。 +- `OPTIONS` の厳格な処理とレート制限；不要なメソッド（例: `MESSAGE`, `PUBLISH`）は不要なら無効にする。 + + + +## 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}}