私たちは XDP 上で DDoS 攻撃に対する保護を作成しています。 核部分

eXpress Data Path (XDP) テクノロジーにより、パケットがカーネル ネットワーク スタックに入る前に、Linux インターフェイス上でランダム トラフィック処理を実行できます。 XDP のアプリケーション - DDoS 攻撃に対する保護 (CloudFlare)、複雑なフィルター、統計収集 (Netflix)。 XDP プログラムは eBPF 仮想マシンによって実行されるため、フィルター タイプに応じてコードと使用可能なカーネル機能の両方に制限があります。

この記事は、XDP に関する多数の資料の欠点を補うことを目的としています。 まず、XDP の機能を即座にバイパスする既製のコードが提供されています。検証用に準備されているか、単純すぎて問題が発生しない可能性があります。 コードを最初から作成しようとすると、典型的なエラーをどうすればよいかわかりません。 第 XNUMX に、VM やハードウェアを使用せずに XDP をローカルでテストする方法については、それぞれの落とし穴があるにもかかわらず、取り上げられていません。 このテキストは、ネットワークと Linux に精通し、XDP と eBPF に興味のあるプログラマを対象としています。

このパートでは、XDP フィルターの組み立て方法とテスト方法を詳細に理解してから、よく知られている SYN Cookie メカニズムの単純なバージョンをパケット処理レベルで作成します。 「ホワイトリスト」はまだ作成しません
クライアントを検証し、カウンターを保持し、フィルターを管理する - 十分なログ。

C で書きます。おしゃれではありませんが、実用的です。 すべてのコードは、最後にあるリンクを介して GitHub で入手でき、記事で説明されている段階に従ってコミットに分割されています。

免責事項。 これは XDP と私の専門分野にとって現実的なタスクであるため、この記事では DDoS 攻撃を回避するためのミニ ソリューションを開発します。 ただし、主な目的はテクノロジーを理解することであり、これは既製の保護を作成するためのガイドではありません。 チュートリアルのコードは最適化されておらず、いくつかのニュアンスが省略されています。

XDP の概要

ドキュメントや既存の記事と重複しないように、重要なポイントのみを説明します。

したがって、フィルター コードがカーネルにロードされます。 受信パケットはフィルターに渡されます。 その結果、フィルターはパケットをカーネルに渡すかどうかを決定する必要があります (XDP_PASS)、パケットをドロップ(XDP_DROP) または返送してください (XDP_TX）。 フィルターはパッケージを変更する可能性があります。これは特に次の場合に当てはまります。 XDP_TX。 プログラムを中止することもできます (XDP_ABORTED) してパッケージをリセットしますが、これは類似しています assert(0) - デバッグ用。

eBPF (拡張バークレー パケット フィルター) 仮想マシンは、コードがループしていないか、他のユーザーのメモリに損傷を与えていないかをカーネルがチェックできるように、意図的にシンプルに作られています。 累積的な制限とチェック:

• ループ（逆方向）は禁止されています。
• データ用のスタックはありますが、関数はありません (すべての C 関数をインライン化する必要があります)。
• スタックおよびパケットバッファ外のメモリアクセスは禁止されています。
• コード サイズは制限されていますが、実際にはこれはあまり重要ではありません。
• 特別なカーネル関数 (eBPF ヘルパー) の呼び出しのみが許可されます。

フィルターの設計とインストールは次のようになります。

1. ソースコード (例: kernel.c) はオブジェクト (kernel.o) eBPF 仮想マシン アーキテクチャの場合。 2019 年 10.1 月の時点で、eBPF へのコンパイルは Clang でサポートされており、GCC XNUMX で約束されています。
2. このオブジェクト コードにカーネル構造 (テーブルやカウンターなど) への呼び出しが含まれている場合、それらの ID はゼロに置き換えられます。これは、そのようなコードは実行できないことを意味します。 カーネルにロードする前に、これらのゼロを、カーネル呼び出しを通じて作成された特定のオブジェクトの ID に置き換える (コードをリンクする) 必要があります。 これは、外部ユーティリティを使用して実行することも、特定のフィルターをリンクしてロードするプログラムを作成することもできます。
3. カーネルはロードされたプログラムを検証します。 サイクルがないこと、およびパケットとスタックの境界を超えていないことがチェックされます。 検証者がコードが正しいことを証明できない場合、プログラムは拒否されます。検証者を満足させることができる必要があります。
4. 検証が成功すると、カーネルは eBPF アーキテクチャのオブジェクト コードをシステム アーキテクチャのマシン コードにコンパイルします (ジャストインタイム)。
5. プログラムはインターフェイスに接続し、パケットの処理を開始します。

XDP はカーネル内で実行されるため、デバッグはトレース ログと、実際にはプログラムがフィルタリングまたは生成したパケットを使用して実行されます。 ただし、eBPF はダウンロードされたコードがシステムに対して安全であることを保証するため、ローカル Linux 上で XDP を直接実験できます。

環境の準備

組立

Clang は eBPF アーキテクチャのオブジェクト コードを直接生成できないため、プロセスは XNUMX つのステップで構成されます。

1. C コードを LLVM バイトコードにコンパイルします (clang -emit-llvm).
2. バイトコードを eBPF オブジェクト コードに変換 (llc -march=bpf -filetype=obj).

フィルターを作成する場合、補助関数とマクロを含むいくつかのファイルが役に立ちます。 カーネルテストから。 カーネルのバージョンと一致していることが重要です (KVER）。 それらをダウンロードしてください helpers/:

export KVER=v5.3.7
export BASE=https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/plain/tools/testing/selftests/bpf
wget -P helpers --content-disposition "${BASE}/bpf_helpers.h?h=${KVER}" "${BASE}/bpf_endian.h?h=${KVER}"
unset KVER BASE

Arch Linux (カーネル 5.3.7) の Makefile:

CLANG ?= clang
LLC ?= llc

KDIR ?= /lib/modules/$(shell uname -r)/build
ARCH ?= $(subst x86_64,x86,$(shell uname -m))

CFLAGS = 
    -Ihelpers 
    
    -I$(KDIR)/include 
    -I$(KDIR)/include/uapi 
    -I$(KDIR)/include/generated/uapi 
    -I$(KDIR)/arch/$(ARCH)/include 
    -I$(KDIR)/arch/$(ARCH)/include/generated 
    -I$(KDIR)/arch/$(ARCH)/include/uapi 
    -I$(KDIR)/arch/$(ARCH)/include/generated/uapi 
    -D__KERNEL__ 
    
    -fno-stack-protector -O2 -g

xdp_%.o: xdp_%.c Makefile
    $(CLANG) -c -emit-llvm $(CFLAGS) $< -o - | 
    $(LLC) -march=bpf -filetype=obj -o $@

.PHONY: all clean

all: xdp_filter.o

clean:
    rm -f ./*.o

KDIR カーネルヘッダーへのパスが含まれます。 ARCH - システムアーキテクチャー。 パスとツールはディストリビューション間で若干異なる場合があります。

Debian 10 (カーネル 4.19.67) の違いの例

# другая команда
CLANG ?= clang
LLC ?= llc-7

# другой каталог
KDIR ?= /usr/src/linux-headers-$(shell uname -r)
ARCH ?= $(subst x86_64,x86,$(shell uname -m))

# два дополнительных каталога -I
CFLAGS = 
    -Ihelpers 
    
    -I/usr/src/linux-headers-4.19.0-6-common/include 
    -I/usr/src/linux-headers-4.19.0-6-common/arch/$(ARCH)/include 
    # далее без изменений

CFLAGS XNUMX つのディレクトリを補助ヘッダーで接続し、複数のディレクトリをカーネル ヘッダーで接続します。 シンボル __KERNEL__ フィルターはカーネルで実行されるため、UAPI (ユーザー空間 API) ヘッダーがカーネル コードに対して定義されていることを意味します。

スタック保護を無効にすることができます (-fno-stack-protector)、eBPF コード検証ツールは依然としてスタック範囲外の違反をチェックするためです。 eBPF バイトコードのサイズには制限があるため、すぐに最適化を有効にする価値があります。

すべてのパケットを通過させ、何も行わないフィルターから始めましょう。

#include <uapi/linux/bpf.h>

#include <bpf_helpers.h>

SEC("prog")
int xdp_main(struct xdp_md* ctx) {
    return XDP_PASS;
}

char _license[] SEC("license") = "GPL";

チーム make 集める xdp_filter.o。 今どこで試してみましょう？

テストスタンド

スタンドには XNUMX つのインターフェイスが含まれている必要があります。フィルターが存在するインターフェイスとパケットが送信されるインターフェイスです。 通常のアプリケーションがフィルターでどのように動作するかを確認するには、これらは独自の IP を持つ本格的な Linux デバイスである必要があります。

veth (仮想イーサネット) タイプのデバイスが適しています。これらは、互いに直接「接続された」仮想ネットワーク インターフェイスのペアです。 次のように作成できます (このセクションではすべてのコマンド ip から実行されます root):

ip link add xdp-remote type veth peer name xdp-local

それは xdp-remote и xdp-local — デバイス名。 の上 xdp-local (192.0.2.1/24) フィルターが添付されます。 xdp-remote (192.0.2.2/24) 受信トラフィックが送信されます。 ただし、問題があります。インターフェイスは同じマシン上にあり、Linux は一方のインターフェイスにもう一方のインターフェイスを介してトラフィックを送信しません。 難しいルールを使えば解決できる iptablesただし、パッケージを変更する必要があるため、デバッグには不便です。 ネットワーク名前空間 (以下、netns) を使用することをお勧めします。

ネットワーク名前空間には、他のネット上の同様のオブジェクトから分離された一連のインターフェイス、ルーティング テーブル、および NetFilter ルールが含まれています。 各プロセスはネームスペース内で実行され、そのネットのオブジェクトにのみアクセスできます。 デフォルトでは、システムにはすべてのオブジェクトに対して単一のネットワーク名前空間があるため、netns について知らなくても Linux で作業できます。

新しい名前空間を作成しましょう xdp-test そしてそこに移動します xdp-remote.

ip netns add xdp-test
ip link set dev xdp-remote netns xdp-test

次に、プロセスが実行されます xdp-test、「見えません」 xdp-local (デフォルトでは netns に残ります)、パケットを 192.0.2.1 に送信する場合は通過します。 xdp-remoteこれは、このプロセスにアクセスできる 192.0.2.0/24 上の唯一のインターフェイスだからです。 これは逆方向にも機能します。

netn 間を移動すると、インターフェイスがダウンし、アドレスが失われます。 netns でインターフェイスを設定するには、次を実行する必要があります。 ip ... このコマンド名前空間で ip netns exec:

ip netns exec xdp-test 
    ip address add 192.0.2.2/24 dev xdp-remote
ip netns exec xdp-test 
    ip link set xdp-remote up

ご覧のとおり、これは設定と変わりません xdp-local デフォルトの名前空間では次のようになります。

    ip address add 192.0.2.1/24 dev xdp-local
    ip link set xdp-local up

走れば tcpdump -tnevi xdp-localからパケットが送信されたことがわかります。 xdp-test、このインターフェイスに配信されます。

ip netns exec xdp-test   ping 192.0.2.1

でシェルを起動すると便利です xdp-test。 リポジトリには、スタンドの操作を自動化するスクリプトが含まれています。たとえば、次のコマンドでスタンドを構成できます。 sudo ./stand up そしてそれを削除します sudo ./stand down.

トレース

フィルターは次のようにデバイスに関連付けられます。

ip -force link set dev xdp-local xdp object xdp_filter.o verbose

キー -force 別のプログラムがすでにリンクされている場合は、新しいプログラムをリンクする必要があります。 「ニュースがないのは良いニュースだ」というのはこの命令に関するものではなく、いずれにしても結論は膨大です。 示す verbose オプションですが、これを使用すると、アセンブリ リストを含むコード ベリファイアの動作に関するレポートが表示されます。

Verifier analysis:

0: (b7) r0 = 2
1: (95) exit

インターフェイスからプログラムのリンクを解除します。

ip link set dev xdp-local xdp off

スクリプトでは次のコマンドが使用されます sudo ./stand attach и sudo ./stand detach.

フィルターを取り付けることで、 ping は実行を続けていますが、プログラムは動作しますか? ログを追加してみましょう。 関数 bpf_trace_printk() に似ている printf()、ただし、パターン以外の最大 XNUMX つの引数と、限られた指定子のリストのみをサポートします。 大きい bpf_printk() 通話が簡素化されます。

   SEC("prog")
   int xdp_main(struct xdp_md* ctx) {
+      bpf_printk("got packet: %pn", ctx);
       return XDP_PASS;
   }

出力はカーネル トレース チャネルに送られますが、これを有効にする必要があります。

echo -n 1 | sudo tee /sys/kernel/debug/tracing/options/trace_printk

メッセージ スレッドを表示:

cat /sys/kernel/debug/tracing/trace_pipe

これらのコマンドはどちらも呼び出しを行います sudo ./stand log.

Ping により次のようなメッセージがトリガーされるようになります。

<...>-110930 [004] ..s1 78803.244967: 0: got packet: 00000000ac510377

検証者の出力をよく見ると、奇妙な計算に気づくでしょう。

0: (bf) r3 = r1
1: (18) r1 = 0xa7025203a7465
3: (7b) *(u64 *)(r10 -8) = r1
4: (18) r1 = 0x6b63617020746f67
6: (7b) *(u64 *)(r10 -16) = r1
7: (bf) r1 = r10
8: (07) r1 += -16
9: (b7) r2 = 16
10: (85) call bpf_trace_printk#6
<...>

実際、eBPF プログラムにはデータ セクションがないため、フォーマット文字列をエンコードする唯一の方法は VM コマンドの直接引数です。

$ python -c "import binascii; print(bytes(reversed(binascii.unhexlify('0a7025203a74656b63617020746f67'))))"
b'got packet: %pn'

このため、デバッグ出力によって結果のコードが大幅に肥大化します。

XDP パケットの送信

フィルタを変更しましょう。すべての受信パケットを送り返すようにします。 ヘッダー内のアドレスを変更する必要があるため、これはネットワークの観点からは正しくありませんが、原則としてこの作業は重要です。

       bpf_printk("got packet: %pn", ctx);
-      return XDP_PASS;
+      return XDP_TX;
   }

打ち上げ tcpdump на xdp-remote。 同一の発信および受信 ICMP エコー要求が表示され、ICMP エコー応答の表示が停止されます。 しかし、それは表示されません。 仕事のためであることが判明 XDP_TX の番組で xdp-local 必要ペアインターフェースへ xdp-remote たとえそれが空であっても、プログラムも割り当てられ、彼は育てられました。

どうやってこれを知ったのですか?

カーネル内のパッケージのパスをトレースします。 ちなみに、perf イベント メカニズムでは、同じ仮想マシンの使用が許可されています。つまり、eBPF を使用した逆アセンブリには eBPF が使用されます。

他に善を生むものがないので、悪から善を生まなければなりません。

$ sudo perf trace --call-graph dwarf -e 'xdp:*'
   0.000 ping/123455 xdp:xdp_bulk_tx:ifindex=19 action=TX sent=0 drops=1 err=-6
                                     veth_xdp_flush_bq ([veth])
                                     veth_xdp_flush_bq ([veth])
                                     veth_poll ([veth])
                                     <...>

コード6とは何ですか?

$ errno 6
ENXIO 6 No such device or address

機能 veth_xdp_flush_bq() ～からエラーコードを受け取ります veth_xdp_xmit()、ここで検索 ENXIO そしてコメントを見つけます。

最小フィルターを復元しましょう (XDP_PASS) ファイル内 xdp_dummy.c、それを Makefile に追加し、バインドします xdp-remote:

ip netns exec remote 
    ip link set dev int xdp object dummy.o

今 tcpdump 期待される内容を示します。

62:57:8e:70:44:64 > 26:0e:25:37:8f:96, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 13762, offset 0, flags [DF], proto ICMP (1), length 84)
    192.0.2.2 > 192.0.2.1: ICMP echo request, id 46966, seq 1, length 64
62:57:8e:70:44:64 > 26:0e:25:37:8f:96, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 13762, offset 0, flags [DF], proto ICMP (1), length 84)
    192.0.2.2 > 192.0.2.1: ICMP echo request, id 46966, seq 1, length 64

代わりに ARP のみが表示される場合は、フィルターを削除する必要があります (これにより、 sudo ./stand detach）、 手放す ping、フィルターを設定して再試行してください。 問題はフィルターです XDP_TX ARP とスタックの両方で有効です
名前空間 xdp-test MAC アドレス 192.0.2.1 を「忘れる」ことができたとしても、この IP を解決することはできません。

問題の定式化

前述のタスクに進みましょう。XDP 上で SYN Cookie メカニズムを作成します。

SYN フラッドは依然として人気のある DDoS 攻撃であり、その本質は次のとおりです。 接続が確立されると (TCP ハンドシェイク)、サーバーは SYN を受信し、今後の接続にリソースを割り当て、SYNACK パケットで応答し、ACK を待ちます。 攻撃者は、数千の強力なボットネット内の各ホストのスプーフィングされたアドレスから XNUMX 秒あたり数千の SYN パケットを送信するだけです。 サーバーはパケットの到着直後に強制的にリソースを割り当てますが、大きなタイムアウト後にリソースを解放します。その結果、メモリまたは制限が使い果たされ、新しい接続が受け入れられず、サービスが利用できなくなります。

SYN パケットに基づいてリソースを割り当てず、SYNACK パケットでのみ応答する場合、サーバーは、後から到着した ACK パケットが保存されていない SYN パケットを参照していることをどのように理解できるでしょうか。 結局のところ、攻撃者は偽の ACK を生成することもできます。 SYN Cookie のポイントは、それを次のようにエンコードすることです。 seqnum アドレス、ポート、変更ソルトのハッシュとしての接続パラメータ。 ソルトが変更される前に ACK がなんとか到着した場合は、ハッシュを再度計算して、次と比較できます。 acknum。 フォージ acknum ソルトには秘密が含まれているため、攻撃者はそれを行うことができません。また、チャネルが限られているため、それを分類する時間がありません。

SYN Cookie は長い間 Linux カーネルに実装されており、SYN があまりにも早く大量に到着した場合に自動的に有効にすることもできます。

TCPハンドシェイクに関する教育プログラム

TCP は、バイトのストリームとしてデータ送信を提供します。たとえば、HTTP リクエストは TCP 経由で送信されます。 ストリームはパケットに分割されて送信されます。 すべての TCP パケットには論理フラグと 32 ビットのシーケンス番号があります。

• フラグの組み合わせによって、特定のパッケージの役割が決まります。 SYN フラグは、これが接続上の送信者の最初のパケットであることを示します。 ACK フラグは、送信者がバイトまでのすべての接続データを受信したことを意味します。 acknum。 パケットには複数のフラグを含めることができ、それらの組み合わせによって呼び出されます (SYNACK パケットなど)。

• シーケンス番号 (seqnum) は、このパケットで送信される最初のバイトのデータ ストリーム内のオフセットを指定します。 たとえば、X バイトのデータを含む最初のパケットでこの数値が N だった場合、新しいデータを含む次のパケットでは N+X になります。 接続の開始時に、双方がこの番号をランダムに選択します。

• 確認応答番号 (acknum) - seqnum と同じオフセットですが、送信されるバイト数ではなく、送信者が認識していない受信者からの最初のバイトの数を決定します。

接続の開始時に、当事者は同意する必要があります seqnum и acknum。 クライアントは SYN パケットを送信します。 seqnum = X。 サーバーは SYNACK パケットで応答し、そのパケットにそのパケットが記録されます。 seqnum = Y そして暴露します acknum = X + 1。 クライアントは SYNACK に対して ACK パケットで応答します。 seqnum = X + 1, acknum = Y + 1。 この後、実際のデータ転送が始まります。

ピアがパケットの受信を確認しない場合、TCP はタイムアウト後にパケットを再送信します。

SYN Cookie が常に使用されないのはなぜですか?

まず、SYNACK または ACK が失われた場合、再度送信されるまで待つ必要があり、接続セットアップが遅くなります。 次に、SYN パッケージ内でのみです。 — 接続のその後の動作に影響を与える多くのオプションが送信されます。 したがって、受信 SYN パケットを記憶しない場合、サーバーはこれらのオプションを無視し、クライアントは次のパケットでそれらを送信しません。 この場合、TCP は機能しますが、少なくとも初期段階では接続の品質が低下します。

パッケージの観点から見ると、XDP プログラムは次のことを行う必要があります。

• SYN に対して Cookie を使用した SYNACK で応答します。
• ACK に対して RST (切断) で応答します。
• 残りのパケットを破棄します。

アルゴリズムの擬似コードとパッケージ解析:

Если это не Ethernet,
    пропустить пакет.
Если это не IPv4,
    пропустить пакет.
Если адрес в таблице проверенных,               (*)
        уменьшить счетчик оставшихся проверок,
        пропустить пакет.
Если это не TCP,
    сбросить пакет.     (**)
Если это SYN,
    ответить SYN-ACK с cookie.
Если это ACK,
    если в acknum лежит не cookie,
        сбросить пакет.
    Занести в таблицу адрес с N оставшихся проверок.    (*)
    Ответить RST.   (**)
В остальных случаях сбросить пакет.

XNUMX (*) システムの状態を管理する必要がある箇所はマークされています。最初の段階では、シーケンス番号として SYN Cookie を生成して TCP ハンドシェイクを実装するだけで、マークなしで済みます。

その場で (**)、テーブルがない間はパケットをスキップします。

TCPハンドシェイクの実装

パッケージを解析してコードを検証する

ネットワーク ヘッダー構造が必要になります: Ethernet (uapi/linux/if_ether.h)、IPv4 (uapi/linux/ip.h) および TCP (uapi/linux/tcp.h）。 後者は、関連するエラーのため接続できませんでした。 atomic64_t, 必要な定義をコードにコピーする必要がありました。

読みやすくするために C で強調表示されているすべての関数は、呼び出し時点でインライン化する必要があります。これは、カーネル内の eBPF ベリファイアがバックトラック、つまりループや関数呼び出しを禁止しているためです。

#define INTERNAL static __attribute__((always_inline))

大きい LOG() リリース ビルドでは印刷を無効にします。

プログラムは機能の伝達手段です。 それぞれは、たとえば、対応するレベルのヘッダーが強調表示されたパケットを受信します。 process_ether() 満たされることを期待しています ether。 フィールド解析の結果に基づいて、この関数はパケットを上位レベルに渡すことができます。 関数の結果は XDP アクションです。 現時点では、SYN ハンドラーと ACK ハンドラーはすべてのパケットを渡します。

struct Packet {
    struct xdp_md* ctx;

    struct ethhdr* ether;
    struct iphdr* ip;
    struct tcphdr* tcp;
};

INTERNAL int process_tcp_syn(struct Packet* packet) { return XDP_PASS; }
INTERNAL int process_tcp_ack(struct Packet* packet) { return XDP_PASS; }
INTERNAL int process_tcp(struct Packet* packet) { ... }
INTERNAL int process_ip(struct Packet* packet) { ... }

INTERNAL int
process_ether(struct Packet* packet) {
    struct ethhdr* ether = packet->ether;

    LOG("Ether(proto=0x%x)", bpf_ntohs(ether->h_proto));

    if (ether->h_proto != bpf_ntohs(ETH_P_IP)) {
        return XDP_PASS;
    }

    // B
    struct iphdr* ip = (struct iphdr*)(ether + 1);
    if ((void*)(ip + 1) > (void*)packet->ctx->data_end) {
        return XDP_DROP; /* malformed packet */
    }

    packet->ip = ip;
    return process_ip(packet);
}

SEC("prog")
int xdp_main(struct xdp_md* ctx) {
    struct Packet packet;
    packet.ctx = ctx;

    // A
    struct ethhdr* ether = (struct ethhdr*)(void*)ctx->data;
    if ((void*)(ether + 1) > (void*)ctx->data_end) {
        return XDP_PASS;
    }

    packet.ether = ether;
    return process_ether(&packet);
}

A と B のマークが付いているチェックに注目してください。A をコメントアウトすると、プログラムはビルドされますが、ロード時に検証エラーが発生します。

Verifier analysis:

<...>
11: (7b) *(u64 *)(r10 -48) = r1
12: (71) r3 = *(u8 *)(r7 +13)
invalid access to packet, off=13 size=1, R7(id=0,off=0,r=0)
R7 offset is outside of the packet
processed 11 insns (limit 1000000) max_states_per_insn 0 total_states 0 peak_states 0 mark_read 0

Error fetching program/map!

キー文字列 invalid access to packet, off=13 size=1, R7(id=0,off=0,r=0): バッファの先頭から 12 番目のバイトがパケットの外側にある場合、実行パスが存在します。 リストからはどの行について話しているのかを理解するのは難しいですが、命令番号 (XNUMX) とソース コードの行を示す逆アセンブラがあります。

llvm-objdump -S xdp_filter.o | less

この場合、それは次の行を指します

LOG("Ether(proto=0x%x)", bpf_ntohs(ether->h_proto));

これにより、問題は次のとおりであることが明らかです ether。 いつもこんな感じだろう。

SYNさんに返信

この段階での目標は、固定された正しい SYNACK パケットを生成することです。 seqnum、将来的には SYN Cookie に置き換えられる予定です。 すべての変化は以下で発生します process_tcp_syn() とその周辺地域。

パッケージの検証

奇妙なことに、最も注目に値する行、またはそのコメントは次のとおりです。

/* Required to verify checksum calculation */
const void* data_end = (const void*)ctx->data_end;

コードの最初のバージョンを作成したとき、ベリファイアには 5.1 カーネルが使用されました。 data_end и (const void*)ctx->data_end。 この記事の執筆時点では、カーネル 5.3.1 にはこの問題はありませんでした。 コンパイラがフィールドとは異なる方法でローカル変数にアクセスしていた可能性があります。 この話の教訓: ネストが多い場合には、コードを単純化することが役立ちます。

次に、検証者の栄光を賭けたルーチンの長さチェックです。 ○ MAX_CSUM_BYTES 以下。

const u32 ip_len = ip->ihl * 4;
if ((void*)ip + ip_len > data_end) {
    return XDP_DROP; /* malformed packet */
}
if (ip_len > MAX_CSUM_BYTES) {
    return XDP_ABORTED; /* implementation limitation */
}

const u32 tcp_len = tcp->doff * 4;
if ((void*)tcp + tcp_len > (void*)ctx->data_end) {
    return XDP_DROP; /* malformed packet */
}
if (tcp_len > MAX_CSUM_BYTES) {
    return XDP_ABORTED; /* implementation limitation */
}

パッケージを展開する

埋めます seqnum и acknum、ACKを設定します(SYNはすでに設定されています):

const u32 cookie = 42;
tcp->ack_seq = bpf_htonl(bpf_ntohl(tcp->seq) + 1);
tcp->seq = bpf_htonl(cookie);
tcp->ack = 1;

TCP ポート、IP アドレス、MAC アドレスを交換します。 XDP プログラムからは標準ライブラリにアクセスできないため、 memcpy() — Clang 組み込み関数を非表示にするマクロ。

const u16 temp_port = tcp->source;
tcp->source = tcp->dest;
tcp->dest = temp_port;

const u32 temp_ip = ip->saddr;
ip->saddr = ip->daddr;
ip->daddr = temp_ip;

struct ethhdr temp_ether = *ether;
memcpy(ether->h_dest, temp_ether.h_source, ETH_ALEN);
memcpy(ether->h_source, temp_ether.h_dest, ETH_ALEN);

チェックサムの再計算

IPv4 および TCP チェックサムでは、ヘッダー内のすべての 16 ビット ワードを追加する必要があり、ヘッダーのサイズはヘッダーに書き込まれます。つまり、コンパイル時には不明です。 ベリファイアは境界変数への通常のループをスキップしないため、これが問題となります。 ただし、ヘッダーのサイズは制限されており、それぞれ最大 64 バイトです。 固定の反復回数でループを作成し、早期に終了することができます。

があることに注意してください RFC 1624 パッケージの固定語のみを変更した場合にチェックサムを部分的に再計算する方法について。 ただし、この方法は普遍的なものではなく、実装の保守はより困難になります。

チェックサム計算機能：

#define MAX_CSUM_WORDS 32
#define MAX_CSUM_BYTES (MAX_CSUM_WORDS * 2)

INTERNAL u32
sum16(const void* data, u32 size, const void* data_end) {
    u32 s = 0;
#pragma unroll
    for (u32 i = 0; i < MAX_CSUM_WORDS; i++) {
        if (2*i >= size) {
            return s; /* normal exit */
        }
        if (data + 2*i + 1 + 1 > data_end) {
            return 0; /* should be unreachable */
        }
        s += ((const u16*)data)[i];
    }
    return s;
}

それでも size 呼び出しコードによって検証されると、検証者がループの完了を証明できるように XNUMX 番目の終了条件が必要になります。

32 ビット ワードの場合は、より単純なバージョンが実装されています。

INTERNAL u32
sum16_32(u32 v) {
    return (v >> 16) + (v & 0xffff);
}

実際にチェックサムを再計算してパケットを送り返します。

ip->check = 0;
ip->check = carry(sum16(ip, ip_len, data_end));

u32 tcp_csum = 0;
tcp_csum += sum16_32(ip->saddr);
tcp_csum += sum16_32(ip->daddr);
tcp_csum += 0x0600;
tcp_csum += tcp_len << 8;
tcp->check = 0;
tcp_csum += sum16(tcp, tcp_len, data_end);
tcp->check = carry(tcp_csum);

return XDP_TX;

機能 carry() RFC 32 に従って、16 ビット ワードの 791 ビットの合計からチェックサムを作成します。

TCPハンドシェイク検証

フィルターは正しく接続を確立します。 netcatネットワーク スタックが SYN を受信しなかったため、Linux が RST パケットで応答した最後の ACK が欠落していました - SYNACK に変換されて送り返されました - そして、OS の観点からは、オープンに関係のないパケットが到着しました接続。

$ sudo ip netns exec xdp-test   nc -nv 192.0.2.1 6666
192.0.2.1 6666: Connection reset by peer

本格的なアプリケーションで確認し、観察することが重要です tcpdump на xdp-remote なぜなら、例えば、 hping3 不正なチェックサムには応答しません。

SYNクッキー

XDP の観点からは、検証自体は簡単です。 計算アルゴリズムは原始的であり、高度な攻撃者に対して脆弱である可能性があります。 たとえば、Linux カーネルは暗号化 SipHash を使用しますが、XDP へのその実装は明らかにこの記事の範囲を超えています。

外部通信に関連する新しい TODO のために導入されました。

• XDP プログラムは保存できません cookie_seed (ソルトの秘密の部分) をグローバル変数に含めるには、カーネル内にストレージが必要です。その値は信頼できるジェネレーターから定期的に更新されます。

• SYN Cookie が ACK パケット内で一致する場合、メッセージを出力する必要はありませんが、検証されたクライアントからのパケットの受け渡しを続けるために、検証されたクライアントの IP を覚えておいてください。

正規のクライアントの検証:

$ sudoip netns exec xdp-test   nc -nv 192.0.2.1 6666
192.0.2.1 6666: Connection reset by peer

ログには、チェックが成功したことが示されています (flags=0x2 - SYNです。 flags=0x10 は ACK):

Ether(proto=0x800)
  IP(src=0x20e6e11a dst=0x20e6e11e proto=6)
    TCP(sport=50836 dport=6666 flags=0x2)
Ether(proto=0x800)
  IP(src=0xfe2cb11a dst=0xfe2cb11e proto=6)
    TCP(sport=50836 dport=6666 flags=0x10)
      cookie matches for client 20200c0

検証済み IP のリストがないため、SYN​​ フラッド自体からの保護はありませんが、次のコマンドによって開始された ACK フラッドに対する反応は次のとおりです。

sudo ip netns exec xdp-test   hping3 --flood -A -s 1111 -p 2222 192.0.2.1

ログエントリ:

Ether(proto=0x800)
  IP(src=0x15bd11a dst=0x15bd11e proto=6)
    TCP(sport=3236 dport=2222 flags=0x10)
      cookie mismatch

まとめ

eBPF 一般と特に XDP は、開発プラットフォームとしてよりも高度な管理者ツールとして提示されることがあります。 実際、XDP はカーネルによるパケットの処理を妨害するツールであり、DPDK やその他のカーネル バイパス オプションのようなカーネル スタックの代替ツールではありません。 一方、XDP を使用すると、非常に複雑なロジックを実装でき、さらに、トラフィック処理を中断することなく簡単に更新できます。 この検証ツールは大きな問題を引き起こしませんが、個人的には、ユーザー空間コードの一部についてはこれを拒否しません。

XNUMX 番目の部分では、トピックが興味深い場合は、検証されたクライアントと切断の表を作成し、カウンターを実装し、フィルターを管理するユーザー空間ユーティリティを作成します。

リンク：

• GitHub 上の完全なコード
• bpftrace チートシート
• BPF および XDP リファレンス ガイド
• XDP チュートリアル
• PoC: Rust から eBPF へのコンパイル

出所： habr.com