Introducing Programmable Flow Protection: custom DDoS mitigation logic for Magic Transit customers

claudejamodel: claude-sonnet-4-20250514

Programmable Flow Protectionの紹介：Magic Transitお客様向けのカスタムDDoS緩和ロジック

2026-03-31
Anita Tenjarla、Alex Forster、Cody Doucette、Venus Xeon-Blonde
6分で読める

Programmable Flow Protectionをご紹介できることを誇りに思います。これは、Magic Transitのお客様が独自のカスタムDDoS緩和ロジックを実装し、Cloudflareのグローバルネットワーク全体にデプロイできるように設計されたシステムです。これにより、UDPベースのカスタムおよび独自プロトコルに対する精密でステートフルな緩和が可能になります。あらゆる規模のDDoS攻撃を緩和するために、可能な限り最高レベルのカスタマイゼーションと柔軟性を提供するよう設計されています。

Programmable Flow Protectionは現在ベータ版で、すべてのMagic Transit Enterpriseのお客様に追加料金でご利用いただけます。

Programmable Flow Protectionはカスタマイズ可能

既存のDDoS緩和システムは、人気のある既知のプロトコルをDDoS攻撃から理解し保護するように設計されています。例えば、Advanced TCP Protectionシステムは、TCPプロトコルに関する特定の既知の特性を使用してチャレンジを発行し、クライアントの正当性を確立します。同様に、Advanced DNS ProtectionはDNS攻撃を緩和するためにお客様ごとのDNSクエリプロファイルを構築します。

汎用DDoS緩和プラットフォームも、NTP、RDP、SIP、その他多くを含む様々な他の既知プロトコル全体の共通パターンを理解します。

しかし、カスタムまたは独自のUDPプロトコルは、システムがトラフィックを通すか破棄するかの知的な決定を行うための関連プロトコル知識を持たないため、CloudflareのDDoS緩和システムにとって常に課題でした。

Programmable Flow Protectionはこのギャップに対処します。お客様は「良い」パケットと「悪い」パケットが何であるか、そしてそれらにどう対処するかを定義する独自のeBPFプログラムを書くことができます。Cloudflareはそのプログラムをグローバルネットワーク全体で実行します。プログラムは「悪い」パケットを破棄またはチャレンジすることを選択でき、それらがお客様のオリジンに到達することを防ぎます。

UDPベース攻撃の問題

UDPはコネクションレスなトランスポート層プロトコルです。TCPとは異なり、UDPにはハンドシェイクやステートフル接続がありません。パケットが順序通りまたは正確に一度到着することを約束しません。UDPは代わりに速度とシンプルさを優先するため、オンラインゲーム、VoIP、ビデオストリーミング、およびアプリケーションがクライアントとサーバー間のリアルタイム通信を必要とするその他のユースケースに適しています。

DDoS緩和システムは、UDP上に構築された既知プロトコルに対する攻撃を常に検出し緩和することができました。例えば、標準DNSプロトコルはUDP上に構築され、各DNSパケットには既知の構造があります。DNSパケットを見れば、それを解釈する方法を知っています。これにより、DNSベースの攻撃を検出し破棄することが容易になります。

残念ながら、UDPパケットのペイロード内のプロトコルを理解していない場合、DDoS緩和システムは緩和時に利用可能な選択肢が限られています。攻撃者が既知のパターンやプロトコルに一致しない大量のUDPトラフィックフラッドを送信した場合、Cloudflareは宛先IPとポートの組み合わせを完全にブロックするか、レート制限を適用することができます。

これは、お客様のネットワークの残りの部分をオンラインに保つことのみを意図した粗雑な「最後の防衛線」であり、いくつかの点で痛みを伴う可能性があります。

第一に、ブロックや汎用レート制限は良いトラフィックと悪いトラフィックを区別しないため、これらの緩和は正当なクライアントが遅延や接続損失を経験する可能性が高く、攻撃者の仕事を代行してしまいます！

第二に、汎用レート制限はお客様によって厳しすぎたり緩すぎたりする可能性があります。例えば、1Gbpsの正当なトラフィックを受信することを期待するお客様は、25Gbpsの正当なトラフィックを受信することを期待するお客様と比較して、より積極的なレート制限が必要でしょう。

![UDPパケット内容の図解。ユーザーは有効なペイロードを定義し、定義されたパターンに一致しないトラフィックを拒否できます。]

Programmable Flow Protectionプラットフォームは、お客様が「良い」トラフィックと「悪い」トラフィックが実際にどのようなものかを指示できるようにすることで、この問題に対処するために構築されました。多くのお客様は、私たちが理解していないカスタムまたは独自のUDPプロトコルを使用しています。そして今、私たちが理解する必要はありません。

Programmable Flow Protectionの仕組み

以前のブログ投稿で、ステートフルネットワーク層DDoS緩和システムである「flowtrackd」が、複雑なTCPおよびDNS攻撃からMagic Transitユーザーを保護する方法を説明しました。また、XDPやeBPFなどのLinuxテクノロジーを使用して、一般的なタイプの大規模DDoS攻撃を効率的に緩和する方法も説明しました。

Programmable Flow Protectionは、これらのテクノロジーを新しい方法で組み合わせます。

Programmable Flow Protectionを使用すると、お客様は任意のロジックに基づいて個々のパケットを通す、破棄する、またはチャレンジするかを決定する独自のeBPFプログラムを書くことができます。お客様はプログラムをCloudflareにアップロードでき、Cloudflareはそれをお客様のネットワーク宛てのすべてのパケットで実行します。

プログラムはカーネル空間ではなくユーザー空間で実行されるため、Cloudflareはセキュリティを損なうことなく、プラットフォーム上で様々なお客様とユースケースをサポートする柔軟性を持てます。

Programmable Flow Protectionプログラムは、Cloudflareの既存のすべてのDDoS緩和の後に実行されるため、ユーザーは標準のセキュリティ保護の恩恵を受け続けます。

LinuxカーネルにロードされたXDP eBPFプログラムと、Programmable Flow Protectionプラットフォームで実行されるeBPFプログラムの間には多くの類似点があります。両方のタイプのプログラムはBPFバイトコードにコンパイルされます。両方ともメモリ安全性を確保し、プログラム終了を検証するために「verifier」を通されます。また、分離と安定性を提供するために、高速で軽量なVMで実行されます。

しかし、LinuxカーネルにロードされたeBPFプログラムは、ネットワークスタックと統合し、プログラム実行間で状態を維持し、ネットワークデバイスにパケットを送信するために、多くのLinux固有の「ヘルパー関数」を使用します。

Programmable Flow Protectionは、お客様が選択する際に同じ機能を提供しますが、DDoS緩和の実装に特化して調整された異なるAPIを使用します。例えば、プログラム実行間でクライアントに関する状態を保存し、暗号化検証を実行し、クライアントにチャレンジパケットを送信するヘルパー関数を構築しました。

これらのヘルパー関数により、開発者はCloudflareプラットフォームの力を使用して独自のネットワークを保護できます。

お客様の知識とCloudflareのネットワークの組み合わせ

お客様のプロトコル固有の知識をCloudflareのネットワークと組み合わせて強力な緩和を作成する方法を説明する例を見てみましょう。

お客様がUDPポート207でオンラインゲームサーバーをホストしているとします。ゲームエンジンは、ゲーム固有の独自アプリケーションヘッダーを使用します。Cloudflareはアプリケーションヘッダーの構造や内容について知識がありません。

お客様はゲームサーバーを圧倒するDDoS攻撃を受け、プレイヤーはゲームプレイの遅延を報告します。攻撃トラフィックは高度にランダム化されたソースIPとポートから来て、ペイロードデータもランダムに見えます。

攻撃を緩和するために、お客様はアプリケーションヘッダーの知識を使用して、パケットの有効性をチェックするProgrammable Flow Protectionプログラムをデプロイできます。この例では、アプリケーションヘッダーにはゲームプロトコルに固有のトークンが含まれています。したがって、お客様はトークンの最後のバイトを抽出するプログラムを書くことができます。プログラムは正しい値が存在するすべてのパケットを通し、他のすべてのトラフィックを破棄します：

#include <linux/ip.h>
#include <linux/udp.h>
#include <arpa/inet.h>
#include "cf_ebpf_defs.h"
#include "cf_ebpf_helper.h"

// カスタムアプリケーションヘッダー
struct apphdr {
    uint8_t version;
    uint16_t length; // 可変長トークンの長さ
    uint8_t token[0]; // 可変長トークン
} __attribute__((packed));

uint64_t cf_ebpf_main(void *state) {
    struct cf_ebpf_generic_ctx *ctx = state;
    struct cf_ebpf_parsed_headers headers;
    struct cf_ebpf_packet_data *p;
    
    // 提供されたヘルパー関数でパケットヘッダーを解析
    if (parse_packet_data(ctx, &p, &headers) != 0) {
        return CF_EBPF_DROP;
    }
    
    // ポート207宛てでないパケットを破棄
    struct udphdr *udp_hdr = (struct udphdr *)headers.udp;
    if (ntohs(udp_hdr->dest) != 207) {
        return CF_EBPF_DROP;
    }
    
    // UDPペイロードからアプリケーションヘッダーを取得
    struct apphdr *app = (struct apphdr *)(udp_hdr + 1);
    if ((uint8_t *)(app + 1) > headers.data_end) {
        return CF_EBPF_DROP;
    }
    
    // verifierを満たすためのメモリチェックを実行し、
    // トークンに安全にアクセス
    if ((uint8_t *)(app->token + token_len) > headers.data_end) {
        return CF_EBPF_DROP;
    }
    
    // トークンの最後のバイトを期待値と照合
    uint8_t *last_byte = app->token + token_len - 1;
    if (*last_byte != 0xCF) {
        return CF_EBPF_DROP;
    }
    
    return CF_EBPF_PASS;
}

アプリケーションヘッダーの値に応じてパケットをフィルタリングするeBPFプログラム。

このプログラムは、Cloudflareが単独で作成できるものよりも対象を絞った緩和を作成するために、アプリケーション固有の情報を活用します。お客様は独自の知識をCloudflareのグローバルネットワークの容量と組み合わせて、これまで以上に大規模な攻撃を吸収し緩和できるようになりました。

ファイアウォールを超えて：ステートフル追跡とチャレンジ

上記の例で実行されたもののような多くのパターンチェックは、従来のファイアウォールで実現できます。しかし、プログラムは変数、条件実行、ループ、プロシージャ呼び出しなど、ファイアウォールでは利用できない有用なプリミティブを提供します。

しかし、Programmable Flow Protectionを他のソリューションから本当に際立たせるのは、フローをステートフルに追跡し、クライアントが本物であることを証明するためにチャレンジする能力です。

これらの能力を示す一般的な攻撃タイプはリプレイ攻撃です。リプレイ攻撃では、攻撃者はある時点で有効だったパケットを繰り返し送信するため、トラフィックの期待されるパターンに適合しますが、アプリケーションの現在のコンテキストではもはや有効ではありません。例えば、攻撃者は有効なゲームプレイトラフィックの一部を記録し、スクリプトを使用して同じトラフィックを非常に高いレートで複製し送信する可能性があります。

Programmable Flow Protectionを使用すると、ユーザーは疑わしいクライアントにチャレンジし、スクリプト化されたトラフィックを破棄するプログラムをデプロイできます。元の例を次のように拡張できます：

#include <linux/ip.h>
#include <linux/udp.h>
#include <arpa/inet.h>
#include "cf_ebpf_defs.h"
#include "cf_ebpf_helper.h"

uint64_t cf_ebpf_main(void *state) {
    // ...
    
    // このソースIPのステータスを取得（ステートフルに追跡）
    uint8_t status;
    if (cf_ebpf_get_source_ip_status(&status) != 0) {
        return CF_EBPF_DROP;
    }
    
    switch (status) {
        case NONE:
            // このソースIPにカスタムチャレンジを発行
            issue_challenge();
            cf_ebpf_set_source_ip_status(CHALLENGED);
            return CF_EBPF_DROP;
            
        case CHALLENGED:
            // このパケットがカスタムロジックで
            // チャレンジを通過するかチェック
            if (verify_challenge()) {
                cf_ebpf_set_source_ip_status(VERIFIED);
                return CF_EBPF_PASS;
            } else {
                cf_ebpf_set_source_ip_status(BLOCKED);
                return CF_EBPF_DROP;
            }
            
        case VERIFIED:
            // このソースIPはチャレンジを通過した
            return CF_EBPF_PASS;
            
        case BLOCKED:
            // このソースIPはブロックされた
            return CF_EBPF_DROP;
            
        default:
            return CF_EBPF_PASS;
    }
    
    return CF_EBPF_PASS;
}

UDP接続にチャレンジし、接続をステートフルに管理するeBPFプログラム。この例は説明のために簡略化されています。

プログラムは見たソースIPアドレスをステートフルに追跡し、未知のクライアントに暗号化チャレンジを含むパケットを送り返します。有効なゲームクライアントを実行している正当なクライアントはチャレンジを正しく解決し、証明で応答できますが、攻撃者のスクリプトはできません。攻撃者からのトラフィックは「ブロック済み」としてマークされ、後続のパケットは破棄されます。

これらの新しい能力により、お客様はフローをステートフルに追跡し、本物の検証されたクライアントのみがオリジンサーバーにトラフィックを送信できることを確認できます。

例ではゲームに焦点を当てましたが、このテクノロジーの潜在的なユースケースは、あらゆるUDPベースプロトコルに拡張されます。

今すぐ始めましょう

私たちはこの機能をお客様に提供できることを楽しみにしています

Summary