リモートキャプチャから SSH フローを除外すべきか？

同じ接続を通して出力を見ながら遠隔のマシンでキャプチャすることは自己参照的な計測であり、測っているものを歪めます。印字するパケットはすべて、キャプチャ中のセッションを経由して戻ってきます。そのフローを除外するのはたいてい正しい判断ですが、除外の範囲は実際の決断です。狭すぎればキャプチャが自分で溢れ、広すぎれば証拠が消えます。

キャプチャが自分自身を記録する理由

キャプチャは自分の出力の戻り経路を見ています。端末に印字される一行ごとに、管理用の接続上で一つ以上のパケットになり、フィルタがそれを再び一致させて印字します。結果は、バッファか回線が音を上げるまで成長するループです。

ファイルに書き出したキャプチャは問題なく見え、同じキャプチャをライブで流すと使えなくなるのはそのためです。トラフィックは新しいものではなく、あなたが作ったものです。十秒のキャプチャでも、ループが始まれば回線が運べる量を超える出力を生みます。

除外は一つのグループとして組み立てる

手元の端末のアドレスからではなく、遠隔のホストがあなたのセッションをどう見るかから始めます。ジャンプホストや NAT 装置は、あなたが打ち込んでいないものを相手側にすることがあるので、アドレスは遠隔側自身の見え方から読み取ります。次にホストとポートをまとめて一つのグループにし、否定がその組全体にかかるようにします。

tcpdump -ni eth0 '(net 10.60.0.0/24) and not (host 203.0.113.77 and tcp port 2222)'

式全体を引用符で囲めば、シェルが括弧を構文として読むことはありません。結果を信じる前に、フィルタを印字して確認してください。

正しく見えてすべてを通してしまうフィルタ

誤ったフィルタは自然に読めるものです。送信元が相手ではない、または宛先が相手ではない、という形です。自分のワークステーションからのパケットでは前者が真になり、返りのパケットでは後者が真になります。これを or で結ぶと両方向が残り、まさに捨てたかったものが残ります。

pcap のフィルタ論理は and と or に同じ優先順位を与え、左から右へ評価するので、混ぜるときに括弧は任意ではありません。二つの否定を組み合わせるのではなく、まとめた一つの式を否定します。その一点の変更が、機能するフィルタと自分の打ち込みで埋まったキャプチャを分けます。詳しくは pcap フィルタのリファレンス を参照してください。端末で読めるほど短く、フィルタが予期しない動きをしたときはいつでも確認する価値があります。

キャプチャが何を証明すべきかで決める

どれだけ除外するかは、そのキャプチャが何を証明すべきかを問うて決めます。同じホストへのアプリケーションのトラフィックを見たいなら、SSH のポートだけを除外し、他のセッションの雑音は受け入れます。そのホストが問いにとって無関係なら、丸ごと除外するほうが単純で、自分で生んだパケットの一群をまとめて除けます。選択はキャプチャファイルの隣に書き留めてください。フィルタは証拠についての仮定だからです。

どのインターフェースを選ぶかで、そもそも何が見えるかが決まる。トンネルでは内側のトラフィックが見え、物理インターフェースでは暗号化された転送が見えます。選んだ地点ですでに管理パケットが存在しないなら、層を間違えたキャプチャはどんな除外でも直りません。