17. セキュリティに関する考慮事項 (Security Considerations)
このセクションでは、TURN 展開に対して仕掛けられる可能性のある攻撃を検討し、プロトコルのメカニズムまたは実装における推奨される慣行を通じてこれらの攻撃を緩和する方法について説明します。
TURN に対するほとんどの攻撃は、サーバーがリクエストの認証を要求することによって緩和されます。このため、本仕様では認証の使用を義務付けています。実装が必須のメカニズムは、STUN の長期認証情報メカニズムです。同等以上のセキュリティ特性を持つ他の認証メカニズムを使用してもかまいません (MAY)。ただし、相互運用可能な方法で呼び出せることを保証することが重要です。
17.1. 外部攻撃 (Outsider Attacks)
外部攻撃とは、攻撃者がシステムに認証情報を持たず、クライアントまたはサーバーから見たサービスを妨害しようとする攻撃です。
17.1.1. 不正なアロケーションの取得 (Obtaining Unauthorized Allocations)
攻撃者は、さまざまな悪意のある目的で TURN サーバー上でアロケーションを取得したいと考える可能性があります。TURN サーバーは、クライアントの実際の IP アドレスを隠しながらパケットを送受信するメカニズムを提供します。これにより、TURN サーバーは、真のアイデンティティを隠すために使用したい攻撃者にとって魅力的なターゲットになります。
攻撃者は、単に料金を支払わずに TURN サーバーのサービスを利用したいと考えるかもしれません。TURN サービスはプロバイダーのリソースを必要とするため、その使用にはコストが伴うことが予想されます。
これらの攻撃は、長期認証情報メカニズムの使用によって防止されます。このメカニズムにより、TURN サーバーはリクエスタのアイデンティティと、リクエスタがアロケーションを取得する権限を持っているかどうかを判断できます。
17.1.2. オフライン辞書攻撃 (Offline Dictionary Attacks)
TURN が使用する長期認証情報メカニズムは、オフライン辞書攻撃の影響を受けやすくなっています。クライアントとサーバー間のメッセージ交換を盗聴できる攻撃者は、多数の候補パスワードを試して、そのうちの 1 つが正しいかどうかを確認することでパスワードを特定できます。この攻撃は、パスワードのエントロピーが低い（例：辞書の単語）場合に有効です。この攻撃は、大きなエントロピーを持つ強力なパスワードを使用することで緩和できます。さらに強力な緩和が必要な場合は、クライアントとサーバー間で TLS トランスポートを使用できます。
17.1.3. 偽造されたリフレッシュとパーミッション (Faked Refreshes and Permissions)
攻撃者は、即座に期限切れになる Refresh リクエストを送信することによってアクティブなアロケーションを攻撃し、それを削除してクライアントへのサービスを妨害したい場合があります。これは、リフレッシュの認証によって防止されます。同様に、望ましくない宛先へのパーミッションを作成するために CreatePermission リクエストを送信しようとする攻撃者は、認証によってそれを行うことができなくなります。このような攻撃の動機については、セクション 17.2 で説明されています。
17.1.4. 偽造データ (Fake Data)
攻撃者は、ピアまたはクライアントからのものであるかのように、クライアントまたはピアにデータを送信したい場合があります。これを行うために、攻撃者はクライアントに偽造された Data インディケーションまたは ChannelData メッセージを送信するか、TURN サーバーに偽造された Send インディケーションまたは ChannelData メッセージを送信できます。
インディケーションと ChannelData メッセージは認証されていないため、この攻撃は TURN によって防止されません。ただし、この攻撃は一般的に IP ベースの通信に存在し、TURN によって大幅に悪化することはありません。TURN を使用しないホスト A と B 間の通常の IP セッションを考えてみましょう。攻撃者は、A の偽装された IP アドレスを持つパケットを送信することで、A からのものであるかのように B にパケットを送信できます。この攻撃には、攻撃者が A と B の両方の IP アドレスを知っている必要があります。TURN を使用する場合、Data インディケーションを使用してクライアントにパケットを送信しようとする攻撃者は、クライアントの IP アドレス（とポート）、TURN サーバーの IP アドレスとポート、およびピアの IP アドレスとポート（XOR-PEER-ADDRESS 属性に含める）を知る必要があります。クライアントに偽の ChannelData メッセージを送信するには、攻撃者はクライアントの IP アドレスとポート、TURN サーバーの IP アドレスとポート、およびチャネル番号を知る必要があります。この特定の組み合わせは、TURN を使用しない場合よりもわずかに推測しやすくなっています。
これらの攻撃は、アプリケーション層認証技術を通じてより適切に緩和されます。リアルタイムトラフィックの場合、SRTP [RFC3711] の使用がこれらの攻撃を防ぐことができます。
場合によっては、TURN サーバーがネットワーク内に配置されているため、クライアント自体が直接到達できないホストに送信できる場合があります。たとえば、サーバーがファイアウォールの背後にあり、そのファイアウォールがファイアウォールの外部からのパケットをサーバーに渡すことを許可するが、ファイアウォールの背後にある他のホストには渡さない場合です。これらの場合、攻撃者は、ファイアウォールの背後にある他のホストの 1 つのトランスポートアドレスを含む XOR-PEER-ADDRESS 属性を持つ Send インディケーションをサーバーに送信できる可能性があります。サーバーが任意のピアへのトラフィックの中継を許可する場合、これにより攻撃者はファイアウォールの背後にある任意のホストを攻撃する方法を得ることになります。
この攻撃を緩和するために、TURN はクライアントがホストにデータを送信する前にそのホストへのパーミッションを確立することを要求します。したがって、攻撃者は、認証されたリクエストを作成できない限り、クライアントがすでに通信したホストのみを攻撃できます。さらに、サーバー管理者は、データを中継する IP アドレスとポートの範囲を制限するようにサーバーを構成できます。さらに高いセキュリティを提供するために、サーバー管理者は、クライアントとサーバー間のすべての通信に TLS を使用することをクライアントに要求できます。
17.1.5. サーバーのなりすまし (Impersonating a Server)
クライアントが TURN サーバーから中継アドレスを学習すると、そのトラフィックを受信するためにアプリケーションプロトコルでその中継アドレスを使用します。したがって、そのトラフィックを傍受またはリダイレクトしようとする攻撃者は、TURN サーバーになりすまし、クライアントに偽の中継アドレスを提供しようとする可能性があります。
この攻撃は、レスポンスにメッセージ完全性を提供し、それらがサーバーからのものであることを認証する長期認証情報メカニズムによって防止されます。さらに、攻撃者は古いサーバーレスポンスを再生できません。これは、STUN ヘッダーのトランザクション ID がこれを防ぐためです。リプレイ攻撃は、ノンス値を頻繁に変更することでさらに阻止されます。
17.1.6. トラフィックの盗聴 (Eavesdropping Traffic)
TURN は主に認証とメッセージ完全性に関係しています。機密性は二次的な懸念事項にすぎません。これは、TURN 制御メッセージには特に機密性の高い情報が含まれていないためです。メッセージの主要なプロトコルコンテンツは、ピアの IP アドレスです。TURN 接続の盗聴者がこれを知ることを防ぐことが重要である場合、TURN は TLS 上で実行できます。
TURN によって中継されるアプリケーションデータの機密性は、アプリケーションプロトコル自体によって提供されるのが最善です。これは、TLS 上で TURN を実行しても、サーバーとピア間のアプリケーションデータは保護されないためです。アプリケーションデータの機密性が重要である場合、アプリケーションはそのデータを暗号化するか、その他の方法で保護する必要があります。たとえば、リアルタイムメディアの場合、SRTP を使用することで機密性を提供できます。
17.1.7. TURN ループ攻撃 (TURN Loop Attack)
攻撃者は、2 つの TURN サーバー間でデータパケットを無限にループさせようとする可能性があります。攻撃は次のように進行します。まず、攻撃者はサーバー B のソースアドレスでサーバー A に Allocate リクエストを送信します。サーバー A はそのレスポンスをサーバー B に送信し、攻撃が成功するには、攻撃者がこのレスポンスの内容を見るか推測できる必要があります。これにより、攻撃者は割り当てられた中継トランスポートアドレスを知ることができます。次に、攻撃者はサーバー A のソースアドレスでサーバー B に Allocate リクエストを送信します。繰り返しますが、攻撃者はレスポンスの内容を見るか推測できる必要があります。これにより、割り当てられた中継トランスポートアドレスを知ることができます。同じ偽装ソースアドレス技術を使用して、攻撃者はサーバー A でチャネル番号をサーバー B の中継トランスポートアドレスにバインドし、同様にサーバー B で同じチャネル番号をサーバー A の中継トランスポートアドレスにバインドします。最後に、攻撃者はサーバー A に ChannelData メッセージを送信します。
結果は、サーバー A の中継トランスポートアドレスからサーバー B の中継トランスポートアドレスへ、次にサーバー B のトランスポートアドレスからサーバー A のトランスポートアドレスへ、そして再びループするデータパケットです。
この攻撃に対する緩和策は次のとおりです。リクエストの認証を要求するか、中継トランスポートアドレスに割り当てられるポート番号をランダム化することにより、サーバーは攻撃者に、リクエストを認証し中継トランスポートアドレスを知るために、第三者（この場合は他のサーバー）に送信されたレスポンスを傍受または見ることを強制します。これら 2 つの対策のいずれかがなければ、攻撃者はレスポンスの内容を見ることなく推測できるため、攻撃の実行が容易になります。さらに、認証されたリクエストを要求することにより、サーバーは攻撃者にサーバーが受け入れる認証情報を持つことを強制します。これにより、外部攻撃ではなく内部攻撃となり、それを開始したクライアントまで攻撃を追跡できるようになります。
さらなる緩和は、データの中継にそのユーザー名に属するアロケーションが使用する帯域幅に対してユーザー名ごとの制限を課すことで実現できます。これにより、この攻撃が他のアロケーションに与える影響を制限できます。さらなる緩和は、データパケットを中継する際に TTL を減らすこと（基礎となるオペレーティングシステムがこれを許可する場合）で実現できます。
17.2. ファイアウォールの考慮事項 (Firewall Considerations)
TURN の主要なセキュリティ考慮事項は、TURN がクライアントと TURN サーバー間に展開されたファイアウォールによって提供される保護を弱めるべきではないということです。TURN サーバーは多くの場合、公衆インターネット上に存在し、クライアントは企業ファイアウォールによってサービスされる企業ネットワーク内に配置されることが予想されます。TURN サーバーが企業への「バックドア」を提供する場合、TURN はこれらのファイアウォールによってブロックされます。
したがって、TURN サーバーは、アドレス依存フィルタリング [RFC4787] を実装する NAT デバイスの動作をエミュレートします。これは、多くのファイアウォールに共通の特性です。NAT またはファイアウォールがこの動作を実装する場合、内部 IP アドレスとポートが最近その外部 IP アドレスにパケットを送信した場合にのみ、外部 IP アドレスからのパケットが内部 IP アドレスとポートに送信されることが許可されます。TURN サーバーは、パーミッションの概念を導入し、TURN サーバー上でまったく同じ動作を提供します。攻撃者は、クライアントが最初に攻撃者に接触しようとしない限り、TURN サーバーにパケットを送信してクライアントに中継されることを期待できません。
一部のファイアウォールのポリシーは、アドレス依存フィルタリングよりもさらに厳格であることに注意することが重要です。ファイアウォールは、アドレスおよびポート依存フィルタリングに構成することも、すべてのインバウンドトラフィックを許可しないように構成することもできます。これらの場合、クライアントが TURN サーバーに接続することが許可されている場合、クライアントとの通信はファイアウォールが通常許可するよりも制限が少なくなります。
17.2.1. 偽造されたパーミッション (Faked Permissions)
ファイアウォールと NAT デバイスでは、パーミッションはネットワークの内側から外側のピアへトラバースするパケットによって暗黙的に付与されます。したがって、定義上、パーミッションはファイアウォールまたは NAT の内側以外のエンティティによって作成することはできません。TURN では、この制限はもはや成り立ちません。TURN サーバーはファイアウォールの外側に位置するため、ファイアウォールの外側の攻撃者は TURN サーバーにメッセージを送信し、自分自身のためにパーミッションを作成しようとすることができます。
この攻撃は、パーミッションを作成するすべてのメッセージ（すなわち、ChannelBind と CreatePermission）が認証されるため、ブロックされます。
17.2.2. ブラックリストに登録された IP アドレス (Blacklisted IP Addresses)
多くのファイアウォールは、ファイアウォールの背後にあるクライアントがブラックリストに登録された IP アドレス範囲へのパケットを送信したり、そこからパケットを受信したりすることを防ぐために、ブラックリストで構成できます。これは、それぞれファイアウォールに入る、およびファイアウォールから出るパケットのソースアドレスとデスティネーションアドレスを検査することによって達成されます。
この機能は TURN にも存在します。TURN サーバーは、中継するピアのアドレス範囲を任意に制限することが許可されているためです。
17.2.3. 既知のポートでのサーバーの実行 (Running Servers on Well-Known Ports)
ファイアウォールの背後にある悪意のあるクライアントは、TURN サーバーに接続してアロケーションを取得し、それを使用してサーバーを実行しようとする可能性があります。たとえば、クライアントは DNS サーバーまたは FTP サーバーを実行しようとする可能性があります。
これは TURN では不可能です。TURN サーバーは、クライアントがパーミッションをインストールしていないピアからのトラフィックを決して受け入れません。したがって、ピアはサービスを取得するために割り当てられたポートに単に接続することはできません。
17.3. 内部攻撃 (Insider Attacks)
内部攻撃では、クライアントは正当な認証情報を持っていますが、それらの認証情報に付随する信頼関係に違反します。これらの攻撃は暗号化手段によって防ぐことはできませんが、プロトコル設計において考慮する必要があります。
17.3.1. TURN サーバーに対する DoS (DoS against TURN Server)
他のクライアントへのサービスを妨害したいクライアントは、アロケーションを取得し、それにトラフィックを殺到させ、サーバーを圧倒して他の正当なクライアントにサービスを提供できないようにしようとする可能性があります。これは、サーバーが特定のユーザー名に対して中継する帯域幅の量を制限することを推奨することで緩和されます。これにより、クライアントが大量のトラフィックを送信することは防げませんが、サーバーは超過トラフィックを即座にドロップできます。
各アロケーションは TURN サーバーの IP アドレス上の 1 つのポート番号を使用するため、サーバー上のアロケーション数は有限です。攻撃者は、多数のアロケーションを要求することによって、すべてのアロケーションを消費しようとする可能性があります。これは、サーバーが特定のユーザー名に対して同時にアクティブなアロケーション数に制限を課すことを推奨することで防止されます。
17.3.2. 悪意のあるトラフィックの匿名中継 (Anonymous Relaying of Malicious Traffic)
TURN サーバーは、ある程度の匿名化を提供します。クライアントは、自分の IP アドレスを明らかにせずにピアにデータを送信できます。したがって、TURN サーバーは、検出を恐れることなくターゲットに対して攻撃を開始する攻撃者にとって魅力的なツールになる可能性があります。実際、クライアントは複数の TURN サーバーを連鎖させて、データパケットがターゲットに到達する前に任意の数のリレーが使用されるようにすることができます。
この攻撃を懸念する管理者は、クライアントの実際のソース IP とポート、さらにはそのクライアントがインストールしたすべてのパーミッションをキャプチャするログを維持できます。これにより、TURN サーバーを介して攻撃が中継されていることが発見された場合、元のソースを特定するための法医学的追跡が可能になります。
17.3.3. 他のアロケーションの操作 (Manipulating Other Allocations)
攻撃者は、（ソースアドレススプーフィングを通じて）TURN サーバーの別のユーザーから来たように見える Refresh リクエストまたは CreatePermission リクエストを送信することによって、TURN サーバーの他のユーザーへのサービスを妨害しようとする可能性があります。TURN は、CreatePermission、Refresh、および ChannelBind メッセージで使用される認証情報が、初期アロケーションを作成するために使用された認証情報と一致することを要求することによって、これを防ぎます。したがって、攻撃者からの偽造されたリクエストは拒否されます。
17.4. その他の考慮事項 (Other Considerations)
Allocate リクエストを介して学習した中継アドレスは、トランスポートまたはトンネルモードで IPsec 認証ヘッダー (AH) [RFC4302] と適切に動作しません。ただし、トンネルモード IPsec カプセル化セキュリティペイロード (ESP) [RFC4303] は引き続き機能するはずです。