Cloudflare、eBPFでDDoS対策を自作できるProgrammable Flow Protectionを発表

Cloudflare、eBPFでDDoS対策を自作できるProgrammable Flow Protectionを発表

Cloudflareは、Magic Transitの利用者向けに、独自のDDoS緩和ロジックを実装できる「Programmable Flow Protection」を発表した。このシステムは、ユーザーが記述したeBPFプログラムをCloudflareのグローバルネットワーク全体にデプロイし、パケットレベルでの精密な制御を可能にするものだ。

2026年3月31日に公開された情報によると、この新機能は特にUDPをベースとした独自の通信プロトコルを利用するサービスにおいて、これまでにない柔軟な防御手段を提供する。現在はベータ版として、Magic Transit Enterpriseプランのユーザー向けに追加オプションとして提供が開始されている。

従来のDDoS対策システムでは対応が難しかった「未知のプロトコル」に対し、インフラ側が中身を理解するのではなく、ユーザーが「正しいパケット」の定義を教え込むというアプローチが採用された点が、今回のアップデートの核心だ。

UDPプロトコル保護の難しさと従来の限界

ネットワーク通信において、UDP（User Datagram Protocol）は速度とリアルタイム性を重視する場面で多用される。オンラインゲームや音声通話（VoIP）、動画ストリーミングなどがその代表例だ。しかし、このUDPの特性が、DDoS対策においては大きな障壁となってきた。

コネクションレスというUDPの性質

UDPはTCP（Transmission Control Protocol）とは異なり、通信の開始時に「ハンドシェイク」と呼ばれる接続確認の手順を踏まない。パケットが順番通りに届く保証もなく、状態を持たない「コネクションレス」なプロトコルである。このシンプルさが高速な通信を実現する一方で、送信元を偽装した攻撃パケットを見分けることを難しくしている。

DNSやNTPといった標準的なプロトコルであれば、パケットの構造が世界共通であるため、Cloudflareのようなプラットフォーム側で「異常なデータ」を検知しやすい。しかし、独自のゲームエンジンや社内システムで使われるカスタムプロトコルの場合、パケットの中身が暗号化されていたり、独自のヘッダー構造を持っていたりするため、外部の防御システムからは単なる「意味不明なデータの塊」にしか見えないのだ。

従来の「レートリミット」が抱えるジレンマ

これまでのDDoS対策では、こうした未知のUDPプロトコルに対して「レートリミット（帯域制限）」という手段が主に使われてきた。特定のIPアドレスやポート番号からの通信が一定量を超えた場合に、一律で遮断や制限をかける方法だ。しかし、これには大きな欠点がある。

レートリミットは「良い通信」と「悪い通信」を区別しない。攻撃が激しくなると、正規のユーザーの通信も制限に巻き込まれ、ラグや切断が発生してしまう。これは、攻撃者の目的である「サービスの停止」を、防御システム自らが手助けしてしまうような結果を招く。また、ユーザーごとに期待される通信量は異なるため、一律の基準値を設定すること自体が非常に困難であった。

Programmable Flow Protectionの仕組みとeBPFの活用

Programmable Flow Protectionは、前述した「中身がわからない」という課題を、ユーザーにロジックを記述させることで解決する。ここで重要な役割を果たすのが「eBPF（extended Berkeley Packet Filter）」という技術だ。

eBPFによるパケットレベルの制御

eBPFとは、OSのカーネル（中枢部）の機能を、カーネル自体を書き換えることなく安全に拡張できる仕組みだ。最近のシステム開発では、ネットワークの監視やセキュリティ対策で急速に普及している。Programmable Flow Protectionでは、ユーザーがC言語などで記述したeBPFプログラムをCloudflareにアップロードする。

アップロードされたプログラムは、Cloudflareのネットワークに届くすべてのパケットに対して実行される。プログラム内で「パケットの32バイト目にある特定のトークンが正しいか」といった独自の条件をチェックし、合致しなければその場でパケットを破棄（ドロップ）する。これにより、アプリケーションサーバーに届く前に、エッジ（利用者に近い拠点）で攻撃を食い止めることが可能になる。

ユーザー空間での安全な実行環境

通常、eBPFはOSのカーネル内で動作するが、Cloudflareのこのシステムでは「ユーザー空間（アプリケーションが動く領域）」で実行される。これにより、特定のユーザーのプログラムが原因でシステム全体が不安定になるリスクを排除しつつ、高度な柔軟性を確保している。

また、プログラムは実行前に「ベリファイア（検証器）」によってチェックされる。メモリ操作に問題がないか、無限ループに陥らないかなどが厳密に確認されるため、安全性が担保されている。Cloudflareの既存のDDoS緩和システムが動作した後にこのカスタムロジックが適用されるため、標準的な攻撃は従来通り自動で防がれ、その網をすり抜けるような特殊な攻撃だけを自作ロジックで仕留めるという二段構えの構成が可能だ。

具体的なユースケース：オンラインゲームの独自プロトコル

この技術が最も威力を発揮する場面の一つが、オンラインゲームの運営だ。独自のゲームエンジンを使用している場合、攻撃者は正規のパケットに似せたデータを大量に送りつけることで、ゲームサーバーをダウンさせようとする。

カスタムヘッダーによるパケット検証

例えば、あるゲームがUDPの207番ポートを使用しており、パケット内の特定の場所に「認証トークン」を含めているとする。Cloudflare側はこのトークンの構造を知らないが、ゲームの開発者はそれを熟知している。Programmable Flow Protectionを使えば、以下のようなロジックをデプロイできる。

// C言語によるeBPFプログラムのイメージ（一部抜粋）
uint64_t cf_ebpf_main(void *state) {
    // パケットヘッダーの解析
    struct cf_ebpf_parsed_headers headers;
    if (parse_packet_data(ctx, &p, &headers) != 0) return CF_EBPF_DROP;

    // ポート207以外はドロップ
    if (ntohs(udp_hdr->dest) != 207) return CF_EBPF_DROP;

    // 独自ヘッダー内のトークンの末尾が「0xCF」かチェック
    uint8_t *last_byte = app->token + token_len - 1;
    if (*last_byte != 0xCF) {
        return CF_EBPF_DROP; // 不正なパケットを破棄
    }

    return CF_EBPF_PASS; // 正当なパケットのみ通過
}

このように、プロトコルの仕様に基づいた「門番」をCloudflareのエッジに配置することで、ランダムなデータを送りつける攻撃（UDPフラッド）を効率的に排除できる。

リプレイ攻撃を防ぐステートフルな追跡

さらに高度な攻撃として「リプレイ攻撃」がある。これは、過去に送信された正当なパケットを攻撃者が記録し、それをそのまま大量に送り直す手法だ。パケットの構造自体は正しいため、単純なヘッダーチェックだけでは防げない。

Programmable Flow Protectionは、単なるフィルターに留まらず、通信の「状態（ステート）」を保持する機能を持っている。これを利用して、未知の送信元IPアドレスに対して「チャレンジ（暗号的な問いかけ）」を送り、正しく応答できたIPアドレスだけを一定期間「許可リスト」に登録するといった運用が可能だ。スクリプトで動いている攻撃者のツールはこうしたチャレンジに応答できないため、リプレイ攻撃を無効化できる。これは、Webサイトでいうところの「CAPTCHA」や「Cookie確認」を、UDPパケットのレベルで実現しているようなものだ。

開発者視点でのメリットと実装の柔軟性

このシステムの真価は、Cloudflareが提供する強力なインフラを、自社のエンジニアが自由にプログラミングできる点にある。従来のハードウェアベースのファイアウォールや、固定的な設定しかできないクラウドサービスとは一線を画す柔軟性だ。

高度なヘルパー関数の提供

eBPFプログラムをゼロから書くのは骨が折れる作業だが、Cloudflareは開発を支援するための「ヘルパー関数」を多数用意している。例えば、パケットデータの解析、送信元IPアドレスごとの状態保存、暗号学的な検証、チャレンジパケットの生成といった複雑な処理を、APIを通じて簡単に呼び出すことができる。

これにより、開発者は「パケットをどう処理するか」というビジネスロジックに集中でき、ネットワークスタックの深い知識がなくても高度な防御機能を構築できる。また、プログラムはCloudflareの全世界のデータセンターに数秒で反映されるため、新しい攻撃パターンが出現した際も即座に防御コードをアップデートできるというスピード感も大きなメリットだ。

エッジでの実行によるレイテンシ削減

通常、高度なパケット検証を自前のサーバーで行おうとすると、攻撃トラフィックがサーバーにまで到達してしまい、帯域を圧迫したりCPU負荷を増大させたりする。Programmable Flow Protectionは、世界中に分散されたCloudflareのエッジ拠点で処理を行うため、攻撃トラフィックはユーザーのインフラに届く前に消滅する。

結果として、サーバー側のリソースを節約できるだけでなく、正規ユーザーの通信に対する遅延（レイテンシ）を最小限に抑えることができる。特にオンラインゲームのようにミリ秒単位の遅延が致命的となるサービスにおいて、この「エッジでの精密なフィルタリング」は非常に強力な武器となるだろう。

独自の分析：エッジコンピューティングとセキュリティの融合

今回のProgrammable Flow Protectionの登場は、セキュリティのあり方が「プラットフォーム任せ」から「プラットフォームとの共同作業」へとシフトしていることを象徴している。これまでは、DDoS対策ベンダーがいかに多くの攻撃パターン（シグネチャ）を知っているかが重要だった。しかし、インターネット上の通信が多様化し、独自のプロトコルが増え続ける中で、ベンダー側ですべてを把握することには限界がある。

Cloudflareは、防御のための「計算資源」と「ネットワーク帯域」を提供し、その上で動かす「知能（ロジック）」をユーザーに開放した。これは、WAF（Web Application Firewall）におけるカスタムルールの作成を、より低レイヤーなL3/L4（ネットワーク・トランスポート層）で実現したものと言える。開発者がインフラの挙動をコードで制御する「Infrastructure as Code」の概念が、DDoS対策の領域でも完全に定着しつつある。

今後、この仕組みはDDoS対策だけでなく、ネットワークトラフィックのルーティングや、エッジでのデータ変換など、より幅広い用途に応用されていく可能性がある。セキュリティエンジニアには、単なる設定作業だけでなく、eBPFのような低レイヤー技術を駆使して「防御をプログラミングする」スキルがますます求められるようになるだろう。

この記事のポイント

• CloudflareがMagic Transit向けに、eBPFでDDoS対策をカスタマイズできる新機能を発表。
• UDPベースの独自プロトコルなど、従来の自動防御では対応が難しかった通信を精密に守れる。
• eBPFを活用することで、パケットの中身を検証したり、ステートフルに接続を追跡したりできる。
• 攻撃パケットをエッジで破棄するため、オリジンサーバーの負荷軽減と正規ユーザーのラグ防止に直結する。
• 現在はEnterprise顧客向けのベータ版として提供されており、開発者による自由なロジック実装が可能。

海田 洋祐

・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、Java等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験