UDPフラッド攻撃

UDPフラッド攻撃はどう動作する？

UDPフラッドは、ワーカーがポートで受信するUDPパケットへの反応を悪用して動作します。通常、ワーカーが特定のポートでUDPパケットを受け取ると、次の2段階を経ます：

1. まず、ワーカーはそのポートで要求を待っているプロセスが動作中か確認します。

2. もしそのポートでパケットを受信するプロセスがなければ、ワーカーは送信元に対象が到達不能であることを知らせるICMP（ping）パケットを送ります。

UDPフラッドは、ホテルの受付が電話を取り次ぐ仕組みに例えることができます。まず、受付は特定の部屋に連絡したいという電話を受けます。その後、ディレクトリを確認し、該当する相手が電話に出るかどうかを調べます。相手が出ないと判断すれば、受付は電話に出て相手が出ない旨を伝えます。しかし、突然すべての電話線から同様の要求がかかると、受付は即座に対応できなくなってしまいます。

ワーカーが新たなUDPパケットを受信するたび、要求処理のために手順を踏み、リソースを消費します。送信されるUDPパケットには送信元端末のIPアドレスが含まれています。この種のDDoS攻撃では、攻撃者は自らの実際のIPアドレスを使用せず、UDPパケットの送信元IPを偽装するため、実際の所在地が特定されにくく、応答パケットによって混乱を招く可能性があります。

被攻撃のワーカーが各UDPパケットの検査と応答にリソースを費やすため、膨大なUDPパケットが到着すると速やかに資源が尽き、通常のトラフィックに対してサービスが提供できなくなります。

‍

UDPフラッド攻撃をどう見分ける？

ワーカーがUDPパケットを受信すると、その要求処理にリソースが使われます。まず、指定されたポートでプロセスが動作しているか確認します。プロセスが存在せずにパケットが届くと、ワーカーは送信元に対し対象が到達不能である旨のICMPパケットを送信します。

複数のPCがUDPフラッドDDoS攻撃を仕掛けた場合、この攻撃は分散型DoS（DDoS）リスクとされます。多数のPCがUDPフラッドを送ると、被攻撃対象とインターネットを接続するリンクの容量を一時的に超え、通信が遮断される恐れがあります。

UDPフラッドの危険

UDPは、接続やセッションを必要としないデータ転送プロトコルです。TCPと比べ、UDPは三者間のハンドシェイクを行わないため、オーバーヘッドが少なく、チャットやVoIPといった、接続確認や認証を必要としない通信に適しています。

このUDPの特性は、逆に悪用されやすいというリスクも伴います。正当な接続を確認するハンドシェイクがないため、UDPを使えば大量のトラフィックを任意のホストに送ることが可能です。内部に速度を制限する保護策がないため、少ない資源で実行できるUDPフラッドによるDOS攻撃は特に危険です。

‍

どう緩和する？

DDoS緩和は、ネットワーク接続の上流に緩和用の機器やフレームワークを配置することで実現されます。たとえば、ProlexicのようなDDoS緩和サービスの利用や、DDoS対策が組み込まれているクラウドプロバイダの選択が可能です。

ワーカーのレベルでDDoSを緩和するのは難しいです。なぜなら、パケットはネットワーク上の次の中継点、例えばISPのローカルスイッチに大量に流れ込むため、仮にパケットを落としても、ISPのスイッチから貴社のネットワークに送られ、帯域を消費してしまいます。したがって、攻撃を緩和するには上流でパケットを落とす必要があります。

基本的には、多くのOSがUDPフラッド攻撃に対してICMP応答の処理を遅延させることで対策を試みます。しかし、このような無差別なフィルタリングは正当なトラフィックにも影響します。

一般的に、UDP対策はファイアウォールを利用して悪意あるUDPパケットをフィルタリングまたは遮断していました。しかし、現代の大量攻撃では、十分な余裕がないファイアウォールが容易に圧倒されるため、これらの対策は時代遅れとなりつつあります。

より小規模なサイトでは、CloudFlareのような中継サービスの利用が可能です。多くの事例で、企業が非常に大規模になるまでこの方法が採用されています。CloudFlareは、ドメインのDNS管理を行い、すべてのウェブトラフィックを自社のネットワークやワーカーを通じて処理します。これらはDDoS攻撃に耐え、XSSやSQLインジェクションといった一般的なハッキング試みも遮断するよう管理されています。正当なトラフィックのみがワーカーに送られ、怪しいトラフィックは上流で落とされるため、DDoSの影響を受けることはありません。

全体として、パケットの急増に対して緩和できる方法が3つあります。

1. ワーカーが着信パケット処理に過剰なリソースを必要としないことを確認する。十分な性能のワーカーは、1Gbit/sのエコー要求にも容易に応答できます。しかし、未確認の送信元からのUDPパケットが大量のメモリやCPUを要する計算を引き起こし、複数のUDPパケットで応答する場合、ワーカーは狙いやすくなります。アプリだけでなく、ファイアウォールの各パケット処理負荷にも留意が必要です。

2. 十分な帯域を確保すること。受信パケットは処理方法に関わらず着信帯域を消費するため、十分な帯域が必須です。

3. トラフィックに対して逆らう対策を講じる。これはプロバイダとの協力が必要です。正当なトラフィックと大量のパケットを明確に識別できるパターンがあれば、上流でレート制限を適用し、接続が圧迫されないようにすることができます。

上記の対策は、直接攻撃を受けた場合にも、リフレクション攻撃の被害に遭った場合にも適用されます。リフレクション攻撃はその性質上さらに破壊的になる恐れがありますが、追加の対策を施すことが可能です。