プログラマブルフロー保護の導入:Magic Transit顧客向けカスタムDDoS軽減ロジック
CloudflareはMagic Transit Enterprise顧客向けに、カスタムUDPプロトコル向けのDDoS攻撃緩和ロジックを顧客自身がeBPFプログラムで定義・展開できる「Programmable Flow Protection」のベータ提供を開始した。
キーポイント
カスタムUDPプロトコル向けDDoS対策の課題解決
従来のCloudflareのDDoS緩和システムは既知のプロトコル向けに最適化されており、カスタム・独自UDPプロトコルへの攻撃対策が困難だったが、Programmable Flow Protectionによりこの課題を解決する。
顧客自身による緩和ロジックの定義と展開
顧客はeBPFプログラムを用いて「正常」パケットと「悪意ある」パケットを定義し、悪意あるパケットを破棄またはチャレンジするロジックを作成でき、Cloudflareがそのプログラムをグローバルネットワーク全体で実行する。
Magic Transit Enterprise向け有料ベータ提供
Programmable Flow Protectionは現在ベータ版として、追加費用で全てのMagic Transit Enterprise顧客に提供されている。
UDPベース攻撃への柔軟な対応
UDPは接続不要で高速な通信を実現するが、状態管理がないため攻撃検知が難しく、本システムにより顧客は自社プロトコルに特化した柔軟な緩和策を実装できる。
従来のUDP DDoS対策の限界
不明なプロトコルを含むUDPトラフィックに対しては、宛先IPとポートのブロックまたはレート制限しかできず、正当なトラフィックも影響を受ける可能性がある。
Programmable Flow Protectionの仕組み
顧客が独自のeBPFプログラムを作成し、任意のロジックに基づいてパケットを通過・破棄・チャレンジする決定ができる。プログラムはユーザースペースで実行され、既存のDDoS対策の後に適用される。
Programmable Flow ProtectionのカスタムDDoS対策ロジック
顧客は独自のプロトコル知識(例:ゲームのアプリケーションヘッダー構造)とCloudflareのネットワークを組み合わせ、特定の条件(例:トークンの最終バイト値)に基づいてパケットを通過またはドロップするカスタムプログラムを作成できる。
影響分析・編集コメントを表示
影響分析
この発表は、クラウドセキュリティ分野において、プラットフォーム提供者が顧客に高度なカスタマイズ機能を提供する新たなトレンドを示している。特に、eBPF技術を活用して顧客自身がネットワーク保護ロジックをプログラム可能にするアプローチは、従来のワンサイズフィットオール型セキュリティソリューションからの進化を意味し、企業の独自プロトコルや特殊なユースケースに対するセキュリティ対策の柔軟性を大幅に向上させる可能性がある。
編集コメント
クラウドセキュリティの進化において、プラットフォームが提供する固定の保護策から、顧客自身がロジックをプログラム可能にする「セキュリティ as Code」的なアプローチへの移行を示す興味深い事例。ただし、AI技術との直接的な関連性は限定的であり、より広義のテクノロジー・インフラストラクチャ分野での革新と言える。
私たちは、プログラマブルフロープロテクションを紹介できることを誇りに思います: これはMagic Transitカスタマーが独自のカスタムDDoS緩和ロジックを実装し、Cloudflareのグローバルネットワーク全体に展開できるように設計されたシステムです。これにより、UDP上に構築されたカスタムおよび独自プロトコルに対する精密でステートフルな緩和が可能になります。あらゆる規模のDDoS攻撃を緩和するために、可能な限り最高レベルのカスタマイズ性と柔軟性を提供するよう設計されています。
プログラマブルフロープロテクションは現在ベータ版で、すべてのMagic Transitエンタープライズカスタマーに追加費用で利用可能です。
プログラマブルフロープロテクションはカスタマイズ可能です
私たちの既存のDDoS緩和システムは、一般的でよく知られたプロトコルを理解し、DDoS攻撃から保護するように設計されてきました。例えば、私たちのAdvanced TCP Protectionシステムは、TCPプロトコルに関する特定の既知の特性を使用してチャレンジを発行し、クライアントの正当性を確立します。同様に、Advanced DNS ProtectionはDNSクエリのカスタマーごとのプロファイルを構築してDNS攻撃を緩和します。私たちの汎用DDoS緩和プラットフォームは、NTP、RDP、SIPなど、他のさまざまなよく知られたプロトコルにわたる共通パターンも理解しています。
しかし、カスタムまたは独自のUDPプロトコルは、私たちのシステムがトラフィックを通過させるかドロップするかについてインテリジェントな決定を行うための関連するプロトコル知識を持っていないため、常にCloudflareのDDoS緩和システムにとって課題でした。
プログラマブルフロープロテクションはこのギャップに対処します。現在、カスタマーは「良い」パケットと「悪い」パケットが何であり、それらをどのように処理するかを定義する独自のeBPFプログラムを書くことができます。Cloudflareはそのプログラムを私たちのグローバルネットワーク全体で実行します。プログラムは「悪い」パケットをドロップするかチャレンジするかを選択でき、それらがカスタマーのオリジンに到達するのを防ぎます。
UDPベースの攻撃の問題
UDPはコネクションレスのトランスポート層プロトコルです。TCPとは異なり、UDPにはハンドシェイクやステートフルな接続がありません。パケットが順序通りに、または正確に一度だけ到着することを保証しません。UDPは代わりに速度と単純さを優先し、したがってオンラインゲーム、VoIP、ビデオストリーミング、およびアプリケーションがクライアントとサーバー間のリアルタイム通信を必要とするその他のユースケースに適しています。
私たちのDDoS緩和システムは、UDP上に構築されたよく知られたプロトコルに対する攻撃を常に検出して緩和することができました。例えば、標準のDNSプロトコルはUDP上に構築されており、各DNSパケットにはよく知られた構造があります。DNSパケットを見れば、それをどのように解釈するかがわかります。これにより、DNSベースの攻撃を検出してドロップすることが容易になります。
残念ながら、UDPパケットのペイロード内のプロトコルを理解していない場合、私たちのDDoS緩和システムは緩和時に利用可能なオプションが限られています。攻撃者が既知のパターンやプロトコルに一致しない大量のUDPトラフィックを送信した場合、Cloudflareは宛先IPとポートの組み合わせを完全にブロックするか、レート制限を適用することができます。これは、カスタマーのネットワークの残りをオンラインに保つことを意図しただけの粗雑な「最後の防衛線」であり、いくつかの点で苦痛を伴う可能性があります。
まず、ブロックまたは汎用のレート制限は良いトラフィックと悪いトラフィックを区別しないため、これらの緩和策は正当なクライアントに遅延や接続損失を経験させる可能性が高く、攻撃者の仕事を代わりに行うことになります!第二に、汎用のレート制限はカスタマーによって厳しすぎたり緩すぎたりする可能性があります。例えば、1Gbpsの正当なトラフィックを受信すると予想されるカスタマーは、25Gbpsの正当なトラフィックを受信すると予想されるカスタマーと比較して、より積極的なレート制限が必要になる可能性があります。
UDPパケットの内容の図解。ユーザーは有効なペイロードを定義し、定義されたパターンに一致しないトラフィックを拒否できます。
プログラマブルフロープロテクションプラットフォームは、私たちのカスタマーが「良い」トラフィックと「悪い」トラフィックが実際にどのように見えるかを指示できるようにすることで、この問題に対処するために構築されました。私たちの多くのカスタマーは、私たちが理解していないカスタムまたは独自のUDPプロトコルを使用しており、今では私たちが理解する必要はありません。
プログラマブルフロープロテクションの仕組み
以前のブログ投稿では、ステートフルなネットワーク層DDoS緩和システムである「flowtrackd」が、Magic Transitユーザーを複雑なTCPおよびDNS攻撃からどのように保護するかを説明しました。また、XDPやeBPFなどのLinuxテクノロジーを使用して、大規模なDDoS攻撃の一般的なタイプを効率的に緩和する方法についても説明しました。
プログラマブルフロープロテクションは、これらのテクノロジーを新しい方法で組み合わせます。プログラマブルフロープロテクションでは、カスタマーは任意のロジックに基づいて個々のパケットを通過させるか、ドロップするか、チャレンジするかを決定する独自のeBPFプログラムを書くことができます。カスタマーはプログラムをCloudflareにアップロードでき、Cloudflareはそのネットワーク宛てのすべてのパケットに対してそれを実行します。プログラムはカーネル空間ではなくユーザースペースで実行されるため、Cloudflareはセキュリティを損なうことなく、プラットフォーム上でさまざまなカスタマーとユースケースをサポートする柔軟性を持ちます。プログラマブルフロープロテクションプログラムは、Cloudflareの既存のすべてのDDoS緩和策の後に実行されるため、ユーザーは依然として私たちの標準的なセキュリティ保護の恩恵を受けます。
LinuxカーネルにロードされたXDP eBPFプログラムと、プログラマブルフロープロテクションプラットフォーム上で実行されるeBPFプログラムの間には多くの類似点があります。両方のタイプのプログラムはBPFバイトコードにコンパイルダウンされます。それらは両方とも、メモリ安全性を確保し、プログラムの終了を検証するために「検証器」を通じて実行されます。また、分離と安定性を提供するために、高速で軽量なVMで実行されます。
しかし、LinuxカーネルにロードされたeBPFプログラムは、ネットワークスタックと統合し、プログラム実行間の状態を維持し、ネットワークデバイスにパケットを送出するために、多くのLinux固有の「ヘルパー関数」を利用します。プログラマブルフロープロテクションは、カスタマーが選択するたびに同じ機能を提供しますが、DDoS緩和を実装するために特別に調整された異なるAPIを使用します。例えば、プログラム実行間のクライアントに関する状態を保存し、暗号検証を実行し、クライアントにチャレンジパケットを送出するためのヘルパー関数を構築しました。これらのヘルパー関数を使用して、開発者はCloudflareプラットフォームの力を利用して独自のネットワークを保護できます。
カスタマーの知識とCloudflareのネットワークの組み合わせ
カスタマーのプロトコル固有の知識がCloudflareのネットワークと組み合わさって強力な緩和策を作り出す方法を説明するために、例を順を追って見てみましょう。
カスタマーがUDPポート207でオンラインゲームサーバーをホストしているとします。ゲームエンジンは、ゲームに固有の独自のアプリケーションヘッダーを使用します。Cloudflareはアプリケーションヘッダーの構造や内容について知識を持っていません。カスタマーはゲームサーバーを圧倒するDDoS攻撃を受け、プレイヤーはゲームプレイの遅延を報告します。攻撃トラフィックは高度にランダム化された送信元IPとポートから来ており、ペイロードデータもランダムに見えます。
攻撃を緩和するために、カスタマーはアプリケーションヘッダーの知識を使用して、パケットの有効性をチェックするプログラマブルフロープロテクションプログラムを展開できます。この例では、アプリケーションヘッダーにはゲームプロトコルに固有のトークンが含まれています。したがって、カスタマーはトークンの最後のバイトを抽出するプログラムを書くことができます。プログラムは正しい値が存在するすべてのパケットを通過させ、他のすべてのトラフィックをドロップします:
#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;
}
// 検証器を満たすためのメモリチェックを実行
// トークンに安全にアクセス
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(拡張Berkeley Packet Filter)プログラム。この例は説明のために簡略化されています。
このプログラムは、確認した送信元IPアドレスをステートフルに追跡し、未知のクライアントに対して暗号化チャレンジを含むパケットを送り返します。有効なゲームクライアントを実行している正当なクライアントはチャレンジを正しく解決し、証明で応答できますが、攻撃者のスクリプトはできません。攻撃者からのトラフィックは「ブロック済み」とマークされ、後続のパケットはドロップされます。
これらの新しい能力により、カスタマーはフローをステートフルに追跡し、本物の、検証されたクライアントのみがオリジンサーバーにトラフィックを送信できるようにすることができます。例ではゲームに焦点を当てましたが、この技術の潜在的なユースケースは、UDPベースのあらゆるプロトコルに広がります。
今日から始めましょう
私たちは、Programmable Flow Protection(プログラム可能なフロー保護)機能をMagic Transit Enterpriseカスタマーに提供できることを嬉しく思います。Programmable Flow Protectionを有効にしてインフラストラクチャの安全を守る方法について詳しくは、アカウントマネージャーにお問い合わせください。
私たちはプラットフォームの開発を積極的に進めており、ユーザーが次に何を構築するか楽しみにしています。まだCloudflareのカスタマーでない方は、Cloudflareでネットワークを保護したいかどうかお知らせください。この機能について私たちと話すには、Programmable Flow Protection Discordチャンネルにご参加ください。
原文を表示
We're proud to introduce Programmable Flow Protection: a system designed to let Magic Transit customers implement their own custom DDoS mitigation logic and deploy it across Cloudflare’s global network. This enables precise, stateful mitigation for custom and proprietary protocols built on UDP. It is engineered to provide the highest possible level of customization and flexibility to mitigate DDoS attacks of any scale.
Programmable Flow Protection is currently in beta and available to all Magic Transit Enterprise customers for an additional cost.
Programmable Flow Protection is customizable
Our existing DDoS mitigation systems have been designed to understand and protect popular, well-known protocols from DDoS attacks. For example, our Advanced TCP Protection system uses specific known characteristics about the TCP protocol to issue challenges and establish a client’s legitimacy. Similarly, our Advanced DNS Protection builds a per-customer profile of DNS queries to mitigate DNS attacks. Our generic DDoS mitigation platform also understands common patterns across a variety of other well known protocols, including NTP, RDP, SIP, and many others.
However, custom or proprietary UDP protocols have always been a challenge for Cloudflare’s DDoS mitigation systems because our systems do not have the relevant protocol knowledge to make intelligent decisions to pass or drop traffic.
Programmable Flow Protection addresses this gap. Now, customers can write their own eBPF program that defines what “good” and “bad” packets are and how to deal with them. Cloudflare then runs the program across our entire global network. The program can choose to either drop or challenge “bad” packets, preventing them from reaching the customer’s origin.
The problem of UDP-based attacks
UDP is a connectionless transport layer protocol. Unlike TCP, UDP has no handshake or stateful connections. It does not promise that packets will arrive in order or exactly once. UDP instead prioritizes speed and simplicity, and is therefore well-suited for online gaming, VoIP, video streaming, and any other use case where the application requires real-time communication between clients and servers.
Our DDoS mitigation systems have always been able to detect and mitigate attacks against well-known protocols built on top of UDP. For example, the standard DNS protocol is built on UDP, and each DNS packet has a well-known structure. If we see a DNS packet, we know how to interpret it. That makes it easier for us to detect and drop DNS-based attacks.
Unfortunately, if we don’t understand the protocol inside a UDP packet’s payload, our DDoS mitigation systems have limited options available at mitigation time. If an attacker sends a large flood of UDP traffic that does not match any known patterns or protocols, Cloudflare can either entirely block or apply a rate limit to the destination IP and port combination. This is a crude “last line of defense” that is only intended to keep the rest of the customer’s network online, and it can be painful in a couple ways.
First, a block or a generic rate limit does not distinguish good traffic from bad, which means these mitigations will likely cause legitimate clients to experience lag or connection loss — doing the attacker’s job for them! Second, a generic rate limit can be too strict or too lax depending on the customer. For example, a customer who expects to receive 1Gbps of legitimate traffic probably needs more aggressive rate limiting compared to a customer who expects to receive 25Gbps of legitimate traffic.
image
An illustration of UDP packet contents. A user can define a valid payload and reject traffic that doesn’t match the defined pattern.
The Programmable Flow Protection platform was built to address this problem by allowing our customers to dictate what “good” versus “bad” traffic actually looks like. Many of our customers use custom or proprietary UDP protocols that we do not understand — and now we don’t have to.
How Programmable Flow Protection works
In previous blog posts, we’ve described how “flowtrackd”, our stateful network layer DDoS mitigation system, protects Magic Transit users from complex TCP and DNS attacks. We’ve also described how we use Linux technologies like XDP and eBPF to efficiently mitigate common types of large scale DDoS attacks.
Programmable Flow Protection combines these technologies in a novel way. With Programmable Flow Protection, a customer can write their own eBPF program that decides whether to pass, drop, or challenge individual packets based on arbitrary logic. A customer can upload the program to Cloudflare, and Cloudflare will execute it on every packet destined to their network. Programs are executed in userspace, not kernel space, which allows Cloudflare the flexibility to support a variety of customers and use cases on the platform without compromising security. Programmable Flow Protection programs run after all of Cloudflare’s existing DDoS mitigations, so users still benefit from our standard security protections.
There are many similarities between an XDP eBPF program loaded into the Linux kernel and an eBPF program running on the Programmable Flow Protection platform. Both types of programs are compiled down to BPF bytecode. They are both run through a “verifier” to ensure memory safety and verify program termination. They are also executed in a fast, lightweight VM to provide isolation and stability.
However, eBPF programs loaded into the Linux kernel make use of many Linux-specific “helper functions” to integrate with the network stack, maintain state between program executions, and emit packets to network devices. Programmable Flow Protection offers the same functionality whenever a customer chooses, but with a different API tailored specifically to implement DDoS mitigations. For example, we’ve built helper functions to store state about clients between program executions, perform cryptographic validation, and emit challenge packets to clients. With these helper functions, a developer can use the power of the Cloudflare platform to protect their own network.
Combining customer knowledge with Cloudflare’s network
Let’s step through an example to illustrate how a customer’s protocol-specific knowledge can be combined with Cloudflare’s network to create powerful mitigations.
Say a customer hosts an online gaming server on UDP port 207. The game engine uses a proprietary application header that is specific to the game. Cloudflare has no knowledge of the structure or contents of the application header. The customer gets hit by DDoS attacks that overwhelm the game server and players report lag in gameplay. The attack traffic comes from highly randomized source IPs and ports, and the payload data appears to be random as well.
To mitigate the attack, the customer can use their knowledge of the application header and deploy a Programmable Flow Protection program to check a packet’s validity. In this example, the application header contains a token that is unique to the gaming protocol. The customer can therefore write a program to extract the last byte of the token. The program passes all packets with the correct value present and drops all other traffic:
#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;
}
An eBPF program to filter packets according to a value in the application header.
This program leverages application-specific information to create a more targeted mitigation than Cloudflare is capable of crafting on its own. Customers can now combine their proprietary knowledge with the capacity of Cloudflare’s global network to absorb and mitigate massive attacks better than ever before.
Going beyond firewalls: stateful tracking and challenges
Many pattern checks, like the one performed in the example above, can be accomplished with traditional firewalls. However, programs provide useful primitives that are not available in firewalls, including variables, conditional execution, loops, and procedure calls. But what really sets Programmable Flow Protection apart from other solutions is its ability to statefully track flows and challenge clients to prove they are real. A common type of attack that showcases these abilities is a replay attack.
image
In a replay attack, an attacker repeatedly sends packets that were valid at some point, and therefore conform to expected patterns of the traffic, but are no longer valid in the application’s current context. For example, the attacker could record some of their valid gameplay traffic and use a script to duplicate and transmit the same traffic at a very high rate.
With Programmable Flow Protection, a user can deploy a program that challenges suspicious clients and drops scripted traffic. We can extend our original example as follows:
#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;
}
An eBPF program to challenge UDP connections and statefully manage connections. This example has been simplified for illustration purposes.
The program statefully tracks the source IP addresses it has seen and emits a packet with a cryptographic challenge back to unknown clients. A legitimate client running a valid gaming client is able to correctly solve the challenge and respond with proof, but the attacker’s script is not. Traffic from the attacker is marked as “blocked” and subsequent packets are dropped.
With these new abilities, customers can statefully track flows and make sure only real, verified clients can send traffic to their origin servers. Although we have focused the example on gaming, the potential use cases for this technology extend to any UDP-based protocol.
Get started today
We’re excited to offer the Programmable Flow Protection feature to Magic Transit Enterprise customers. Talk to your account manager to learn more about how you can enable Programmable Flow Protection to help keep your infrastructure safe.
We’re still in active development of the platform, and we’re excited to see what our users build next. If you are not yet a Cloudflare customer, let us know if you’d like to protect your network with Cloudflare. Join our Programmable Flow Protection Discord channel to chat with us about this feature.
関連記事
今日のまとめ
AI日報で今日の重要ニュースをまとめ読み