重要な要件は、「-i anyでスレーブインタフェースをフィルタリングする」と表現できます。
この場合、bond0のVLANを離れるパケットもbond0またはプライマリ物理インターフェイスによって取得されてはいけません。
(やや複雑な)構成の詳細:
- bond0は、スレーブenp1s0f1とenp1s0f1(2×10 Gbps)を使用して802.3adで実行されます。
- これに加えて、複数のVLANが関連しています(問題を引き起こすのに十分です)。場合によっては、二重表示が可能です。
- 約50個のpppoeサーバーがあります。
- 他のVLANには通常のIP /ネットワークのみが割り当てられます。
- アクティブpppoe + pppol2tp接続(〜200)。
- ほとんどの ppp インターフェイスには、tc を使用して受信を形成するための関連 ifb-ppp インターフェイスがあります (ミラーリング操作が必要)。
現在のデフォルトのtcpdumpコマンド:
tcpdump -vnei any -s0 port 53 and host $loopback_ip
「ether proto 0x0800」では動作しません。これは、物理的およびbond0から802.11qのエーテルタイプが実際には0x0800ではなく0x8100であるため、ほぼ理想的です(ただし、ネストされたタイプは依然として0x0800なので、tcpdumpまたはbpfが通常ここでフレームを返す理由と考えられます)。
アイデアは、ローカルシステムに入ったり出たりするすべてのDNSパケットの単一のコピーをキャプチャすることです(ただし、ルーティングされたパケットとは対照的に)。
出力は次のとおりです(pppリンクからローカルノードに1つのパケットが移動し、応答が戻ってきた場合)。
12:33:43.996592 ppp155 In ifindex 1428484 ethertype IPv4 (0x0800), length 80: (tos 0x0, ttl 63, id 14910, offset 0, flags [none], proto UDP (17), length 60)
a.b.c.d.54070 > e.f.g.h.53: 38860+ A? www.google.com. (32)
12:33:43.996598 ifb-ppp155 Out ifindex 1428485 00:00:3f:11:16:20 ethertype IPv4 (0x0800), length 80: (tos 0x0, ttl 63, id 14910, offset 0, flags [none], proto UDP (17), length 60)
a.b.c.d.54070 > e.f.g.h.53: 38860+ A? www.google.com. (32)
enter code here
12:33:43.996649 ppp155 Out ifindex 1428484 ethertype IPv4 (0x0800), length 96: (tos 0x0, ttl 64, id 18785, offset 0, flags [DF], proto UDP (17), length 76)
e.f.g.h.53 > a.b.c.d.54070: 38860 1/0/0 www.google.com. A 216.58.223.132 (48)
これは質問1です。我々は、ifb機器を使用してtc入口トラフィックを調整します。はい、ここに警察キャスティング以上のものがあります。だから私たちはこのフレームを2回見ます。 ifb-ppp155の重複は気にしません。
応答は一度だけ提供されますが、tcがトラフィックを「リダイレクト」しないことを見ると、これは予想される結果です。トラフィックはpppoeにカプセル化されるため、フィルタは関連するVLANからプライマリインターフェイス(受信と同様)のbond0に送信されるpppoeフレームもフィルタリングします。
問題は、トラフィックが元のVLANにあるときにホストアウトバウンドをリモートサーバーに照会することによって最も簡単に説明されます。
12:38:55.396412 bond0.2 Out ifindex 7 00:11:0a:69:8f:b0 ethertype IPv4 (0x0800), length 80: (tos 0x0, ttl 62, id 3629, offset 0, flags [none], proto UDP (17), length 60)
a.b.c.d.36796 > e.f.g.h.53: 21853+ A? www.google.com. (32)
12:38:55.396413 bond0 Out ifindex 6 00:11:81:00:00:02 ethertype IPv4 (0x0800), length 84: IP8 (invalid)
12:38:55.396414 enp1s0f0 Out ifindex 2 00:11:81:00:00:02 ethertype IPv4 (0x0800), length 84: IP8 (invalid)
12:38:55.396476 enp1s0f1 In ifindex 3 48:df:81:00:00:02 ethertype IPv4 (0x0800), length 100: IP15 (invalid)
12:38:55.396476 bond0 In ifindex 6 48:df:81:00:00:02 ethertype IPv4 (0x0800), length 100: IP15 (invalid)
12:38:55.396476 bond0.2 In ifindex 7 48:df:37:3d:f5:c4 ethertype IPv4 (0x0800), length 96: (tos 0x0, ttl 64, id 47664, offset 0, flags [DF], proto UDP (17), length 76)
e.f.g.h.53 > a.b.c.d.36796: 21853 1/0/0 www.google.com. A 172.217.170.100 (48)
強調するために改行を追加します。この「6」パケットは実際には2つに過ぎません。私は「(間違った)」出力を提供したくありません。理想的には、カーネルからユーザースペースに3回コピーされるのではなく、一度だけコピーされるようにbpfフィルタを通過しないでください。
現時点では、bond0.2でキャプチャするトラフィックだけでは、DNSベースの攻撃(特に今日の見出しを飾る大規模な中断)に関する情報を収集するのに十分ではないため、フィルタを-iに拡張すると、何らかの理由でトラフィックが多すぎます。 。やっぱり仕事をめちゃくちゃにします。 1つ以上のクライアントルーターが特別に細工された照会を実行して、望ましくない動作を引き起こす可能性があります。既知のDNS特権ホストに向かっていないネットワークエッジで着信DNSクエリをブロックしています。
今すぐ考えられる唯一の他の可能性は、実際にはiptablesのNFLLOGを使用して、関連するINPUTフレームとOUTPUTフレームを特別に作成されたユーザースペースアプリケーションに送信することです。これは最終的に良い方法になるかもしれませんが、私たちが利用できるかどうかを考えます。 tcpdumpを使用して生データを収集し、Wiresharkまたは同様のツールを使用して攻撃ベクトルを追跡できる必要があります。そして、専用アプリケーションを構築するよりも速くなければなりません。