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 緩和システムは、一般的でよく知られたプロトコルを理解して保護するように設計されています。たとえば、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 は速度と単純さを優先するため、オンラインゲーム、VoIP、ビデオストリーミング、リアルタイム通信が必要なその他のユースケースに適しています。

Cloudflare の DDoS 緩和システムは、UDP 上に構築されたよく知られたプロトコルに対する攻撃を検知・緩和できてきました。たとえば標準的な DNS プロトコルは UDP 上に構築され、各 DNS パケットはよく知られた構造を持ちます。DNS パケットを識別できれば、その中身を解釈できます。これにより DNS ベースの攻撃を検出して破棄することが容易になります。

残念ながら、UDP パケットのペイロード内にどのようなプロトコルがあるか理解できない場合、DDoS 緩和時に選べる手段は限られます。攻撃者が既知のパターンやプロトコルに一致しない大量の UDP トラフィックを送ると、Cloudflare は宛先 IP とポートの組み合わせを完全にブロックするかレート制限を適用するしかありません。これは粗雑な「最後の防衛線」であり、顧客のネットワークの残りをオンラインに保つことを目的としていますが、いくつかの点で問題になります。

• ブロックや汎用のレート制限は良いトラフィックと悪いトラフィックを区別しないため、正当なクライアントに遅延や接続切断を発生させてしまい、結果的に攻撃者の目的を達成してしまう可能性があります。
• 汎用レート制限は顧客ごとに期待する正当トラフィック量が異なるため、厳しすぎたり緩すぎたりします。たとえば正当トラフィックが 1Gbps を想定している顧客と 25Gbps を想定している顧客では必要な制限の強さが異なります。

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

Programmable Flow Protection プラットフォームは、この問題を解決するために構築されました。顧客自身が「良い」トラフィックと「悪い」トラフィックの定義を決めることを許容します。多くの顧客が Cloudflare に理解されていないカスタムや独自の UDP プロトコルを使用していますが、今ではそれを理解していなくても問題ありません。

仕組み

過去の記事では、ステートフルなネットワーク層 DDoS 緩和システムである “flowtrackd” が Magic Transit ユーザーを複雑な TCP や DNS 攻撃からどのように保護するかを説明しました。また、大規模な DDoS 攻撃を効率的に緩和するために XDP や eBPF といった Linux テクノロジーを使用していることも説明しました。Programmable Flow Protection はこれらの技術を新しい方法で組み合わせたものです。

Programmable Flow Protection では、顧客が任意のロジックに基づいて個々のパケットを通過（pass）、破棄（drop）、またはチャレンジするかを決定する独自の 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"

// Custom application header
struct apphdr {
    uint8_t version;
    uint16_t length; // Length of the variable-length token
    uint8_t token[0]; // Variable-length token
} __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;
    // Parse the packet headers with provided helper function
    if (parse_packet_data(ctx, &p, &headers) != 0) {
        return CF_EBPF_DROP;
    }
    // Drop packets not destined to port 207
    struct udphdr *udp_hdr = (struct udphdr *)headers.udp;
    if (ntohs(udp_hdr->dest) != 207) {
        return CF_EBPF_DROP;
    }
    // Get application header from UDP payload
    struct apphdr *app = (struct apphdr *)(udp_hdr + 1);
    if ((uint8_t *)(app + 1) > headers.data_end) {
        return CF_EBPF_DROP;
    }
    // Perform memory checks to satisfy the verifier
    // and access the token safely
    if ((uint8_t *)(app->token + token_len) > headers.data_end) {
        return CF_EBPF_DROP;
    }
    // Check the last byte of the token against expected value
    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) {
    // ...
    // Get the status of this source IP (statefully tracked)
    uint8_t status;
    if (cf_ebpf_get_source_ip_status(&status) != 0) {
        return CF_EBPF_DROP;
    }
    switch (status) {
        case NONE:
            // Issue a custom challenge to this source IP
            issue_challenge();
            cf_ebpf_set_source_ip_status(CHALLENGED);
            return CF_EBPF_DROP;
        case CHALLENGED:
            // Check if this packet passes the challenge
            // with custom logic
            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:
            // This source IP has passed the challenge
            return CF_EBPF_PASS;
        case BLOCKED:
            // This source IP has been blocked
            return CF_EBPF_DROP;
        default:
            return CF_EBPF_PASS;
    }
    return CF_EBPF_PASS;
}

上の例は UDP 接続にチャレンジを投げ、接続をステートフルに管理する eBPF プログラムを示しています。例は説明のため簡略化されています。プログラムは観測したソース IP をステートフルに追跡し、未知のクライアントには暗号的チャレンジを含むパケットを返します。正当なゲームクライアントを実行しているクライアントはチャレンジを正しく解いて応答できますが、攻撃者のスクリプトはそうではありません。攻撃者由来のトラフィックは "blocked" とマークされ、その後のパケットは破棄されます。

これらの新しい能力により、顧客はフローをステートフルに追跡でき、本当に実在する検証済みクライアントだけがオリジンサーバーへトラフィックを送れるようにできます。例はゲームに焦点を当てましたが、この技術の潜在的ユースケースはあらゆる UDP ベースのプロトコルに及びます。

始める

私たちは興奮しています t