脅威アドバイザリ — DCCP による(D)DOS

DCCPの概要

本来のDCCP のユースケースは、通常 User Datagram Protocol（UDP）で処理されている長い続くデータフローや大きなサイズのデータフローへの使用です。ほとんどの UDP 実装には、DCCP で実装されているネットワーク輻輳制御のメカニズムがまったくありません。あるとしても、個別にアプリケーションレイヤーに実装されています。

ある意味、DCCP は、比較的信頼性の高い「信頼性のない」ネットワークプロトコルと言えます。DCCP は、リアルタイムデータやストリーミングデータなど、タイミングに制約されるデータ配信（一般的には UDP が利用される）におけるデータと処理のオーバーヘッドを最小限に抑えながら、通常の UDP フローでは得られない輻輳制御とデータ交換面での機能強化を提供できるように設計されています。DCCP の目的は、UDP と Transmission Control Protocol（TCP）の間のスイートスポットとして機能すること、つまり、UDP の速度と使いやすさを提供しつつ、一般的に TCP の特徴である輻輳制御とフロー制御の利点を追加することです。

DCCP には TCP と似た機能がありますが、実際の TCP 実装と比べると、機能はかなり限定されています。これは、処理能力の低いデバイスを使用した場合のオーバーヘッドを軽減するためです。さらに、DCCP は、モバイルネットワークなど、帯域幅の変動が大きく、輻輳の問題が発生する可能性があるにも関わらず、一般的にインターネットが使用されるようなネットワークでも適切に動作するように設計されています。インターネットでは、UDP に輻輳制御がないうえに、大規模／長時間のデータフローに対して広範囲に UDP が使用されているため、ネットワークの過負荷が懸念されています。

プロトコル

DCCP は TCP と同様、データ転送の開始に 3 ウェイハンドシェイクを必要とします。以下に例として DCCP を使用したデータフロー図を示します。この図は RFC4340（セクション 4.1）から直接取得したものです。

今後の攻撃は？

これまでの DCCP-Request フラッドだけを見て、今後もこのプロトコルの悪用は拡大しないと判断することはできません。図 2 に示したとおり、DCCP-Request は、このプロトコルの複数のパケット形式の 1 つにすぎません。これらはボリューム型の攻撃に見えるので、攻撃者にとってはジャンクデータの詰め込みでも十分に用が足るという可能性もあります。

パケット内の IP ヘッダーを適切に設定すれば、目的とする対象までうまく攻撃トラフィックをルーティングし、TCP／UDP 中心の防御戦略やテクノロジーのレーダーを避けながら飛行させることができます。

リフレクション／増幅の可能性

前述のとおり、DCCP プロトコルはデータ転送の前に 3 ウェイハンドシェイクを必要とします。そのため、一見、リフレクション／増幅攻撃の可能性は低いように思えます。しかし、実際のデータフローを調べてみると、このプロトコル独自のハンドシェイクにより、小さなリフレクションと増幅の可能性があるようです。

DCCP を使用したリフレクション攻撃は、SYN-ACK リフレクションに似ています。この攻撃は、実際の DCCP リスニングホストに対するなりすましの DCCP-Request（54 バイト）フラッドのように見えます。DCCP 対応ホストは、なりすましの送信元とのハンドシェイクを完了しようとするため、DCCPーResponse（62 バイト）のリフレクションが発生します。

DCCP パケットにはデータが含まれているので、これは、SYN-ACK リフレクションとは異なります。通常、SYN／SYN-ACK ハンドシェイクは、ビットマスクフラグを使用した length 0 のパケット交換で構成されています。DCCP では、これらの専用パケットはハンドシェイクを実行するためにデータを必要とします。デフォルトでは、DCCP-Response パケットは、これをトリガーする DCCP-Request パケットよりも 8 バイト長くなります。これは少量の増幅となりますが、大きな懸念は生じません。

現実には、今日のリフレクション／増幅のキャパシティで、このタイプの攻撃が発生する可能性は低いと考えられます。その主な理由は、このプロトコルを使用しているホストがインターネット上にほとんどないからです。このプロトコルが普及すれば（現実的ではありませんが）、該当するリフレクタープールが拡大し、攻撃バリエーションの 1 つとして観察されるようになる可能性もあります。

状況

DCCP は比較的新しいプロトコルです。DCCP のプロジェクトは RFC プロセスを乗り越え、2007 年に最初の開発が始まりましたが、実際にはあまり採用されていないようです。

現実のユースケースを特定しようとしましたが、このプロトコルを実際に使用しているアプリケーションを見つけることはできませんでした。Github に対するソースコード検索で SOCK_DCCP 宣言（サポートされている複数の言語のソースコードでソケットを設定するときに使用されるプログラム定数）の探索も行いました。

2.6.14 以降の Linux Kernel には DCCP の機能が含まれていますが、市販の「メインストリーム」Linux ディストリビューションのすべてで DCCP ソケットがサポートまたは有効化されているわけではありません。DCCP ソケットが含まれていて、デフォルトで有効になっているものもありますが、サポートされている他のプロトコルのような普遍性はありません。一方、Windows はこのプロトコルをまったくサポートしていないようです。

現在の緩和策

ネットワークは構築方法も利用方法もさまざまです。ここで提示するアドバイスは、非常にアグレッシブな防御対策であるため、組織によっては、これを実施する前に、エッジを横断する DCCP トラフィックに対して基本的なフロー分析を行う方がよい場合もあります。しかし、DCCP（プロトコル 33）の採用が拡がっていないことを考えると、包括的な ACL DROP が緩和策として妥当であるように思われます。また、これは、実際に攻撃を受けている組織や攻撃を受けると予測される組織にとっての予防的な緩和戦略としても効果がありそうです。

将来の緩和

DCCP は、今後、ストリーミング・メディアやゲーミングのアプリケーションに採用されていく可能性があります。このプロトコルの性質を考えると、今後の採用状況を注視していく必要があります。このプロトコルの採用によって包括的な緩和手法が不可能になった場合は、過剰な緩和とアプリケーション破損のリスクを軽減するような DCCP-Request チャレンジの開発が必要になると思われます。

サンプルフロー

このプロトコルのサンプル PCAP をWireshark のサンプルトラフィックのリポジトリでご覧いただけます。実際のトラフィックフローがどのようなものかを緩和チームが検討する際に参考になると思います。

まとめ

攻撃者は標的を痛めつける新たな手法を常に模索しています。DCCP は、新たな手法を考案して最大限の損害を与えようとする攻撃者の最新の試みにすぎません。現在、インターネットプロトコル（IP）の標準化されているプロトコル番号は 140 を超えていますが、テクノロジーの継続的な進化に伴い、今後も追加されていくと考えられます。DCCP は、悪用される最新のプロトコルとして検知されていますが、ほとんど採用されていません。そのため、ボリューム型攻撃や、稀なネットワークプロトコルの悪用およびこれに対する緩和機能を考慮しない短絡的な防御戦略の問題以外には、特に大きな懸念材料にはならないと考えられます。