パフォーマンスを犠牲にしない可視化
トラフィックの多い本番サーバーの運用は、時に目隠しをして飛行機を操縦しているような感覚に陥ることがあります。脅威の検出やレイテンシのトラブルシューティングのためにパケットを検査する必要がありますが、インラインプロキシを追加するとアプリケーションの速度が低下する恐れがあります。物理的なデータセンターであれば、CiscoやJuniperのスイッチでSPANポートを使用するだけです。しかし、AWSやDigitalOcean、あるいはプライベートなProxmoxクラスターで運用している場合、ハードウェアスイッチに直接アクセスできないことがほとんどでしょう。
ホストベースのトラフィックミラーリングは、この問題を解決します。Linuxカーネルを使用してパケットをクローンすることで、元のデータ通信を妨げることなく、Suricata IDSやZeekセンサーなどの別のセキュリティノードにトラフィックのコピーを送信できます。これは、仮想化された環境において物理的なネットワークタップに最も近い機能を提供します。
なぜIptables TEEが最適なツールなのか
Linuxにはパケットを移動させる方法がいくつかありますが、iptablesのTEEターゲットは非常に効率的です。通信経路の途中に介在するブリッジとは異なり、TEEは「クローンしてそのまま（clone and forget）」のコピーを作成します。クローン後、元のパケットは即座にネットワークスタックに戻されます。標準的な1Gbpsリンクでのテストでは、元のパケットに追加されるレイテンシは通常5マイクロ秒未満であり、これはほとんどのアプリケーションで測定すら困難なレベルです。
このアプローチにより、本番サーバーの負荷を低く保つことができます。パケット分析という重い処理は別のマシンで行われるため、ウェブサーバーやデータベースのCPUサイクルが、複雑なパターンマッチングやディープパケットインスペクション（DPI）によって消費されることはありません。
パケットクローンの内部の仕組み
TEEターゲットはmangleテーブル内に存在します。このテーブルは、特殊なパケット変更を行うために設計されています。パケットがTEEルールにヒットすると、カーネルは以下の4つのステップを迅速に実行します。
- パケットのビット単位のコピーを作成する。
- コピーの宛先MACまたはIPを、モニタリング用のゲートウェイに向くように調整する。
- ネットワークインターフェースからコピーを送り出す。
- 元のパケットを即座に解放し、本来の通信を継続させる。
環境の準備
Ubuntu 22.04、Debian 12、Rocky Linuxなどの最新のディストリビューションの多くには、TEEモジュールがプリコンパイルされています。モジュールがアクティブであることを確認するだけです。
# モジュールの確認
lsmod | grep xt_TEE
# 未ロードの場合はロードする
sudo modprobe xt_TEEラボのシナリオ
- 本番サーバー: 192.168.1.10 (eth0) – 送信元。
- モニタリングノード: 192.168.1.50 – クローンの送信先。
実装手順
1. インバウンドトラフィックのクローン
外部からのリクエストを監視するには、PREROUTINGチェーンを使用します。これにより、パケットがネットワークカードに到着した瞬間にキャッチできます。
sudo iptables -t mangle -A PREROUTING -i eth0 -j TEE --gateway 192.168.1.502. アウトバウンドトラフィックのクローン
サーバーが何を返信しているかを監視することも同様に重要です。これにより、データの持ち出しや、侵害されたソフトウェアによる不審な「外部への通信（phone home）」を特定できます。これにはPOSTROUTINGチェーンを使用します。
sudo iptables -t mangle -A POSTROUTING -o eth0 -j TEE --gateway 192.168.1.503. 精密なミラーリング
10Gbpsのパイプ全体をミラーリングすると、モニタリング用リンクが飽和し、ディスクI/Oを圧迫する可能性があります。代わりに、リスクの高いポートに焦点を当てましょう。通常、データを管理可能な範囲に抑えるため、ウェブトラフィック（80, 443）とDNS（53）のみをミラーリングします。
# ウェブトラフィックのみをミラーリング
sudo iptables -t mangle -A PREROUTING -i eth0 -p tcp -m multiport --dports 80,443 -j TEE --gateway 192.168.1.50受信側の設定
192.168.1.50のモニタリングサーバーは、実際には自分宛てではない何千ものパケットを受信することになります。通常、Linuxカーネルは宛先が一致しないパケットを即座に破棄します。そのため、インターフェースにすべてをリッスンするように指示する必要があります。
IDSがミラーリングされたトラフィックを「見る」ことができるように、インターフェースをプロミスキャスモードに設定します。
sudo ip link set eth0 promisc ontcpdumpを実行して、ストリームが動作していることを確認します。モニタリングサーバー自身のIPではない送信元・送信先IPを持つトラフィックが表示されるはずです。
sudo tcpdump -i eth0 -n "not host 192.168.1.50"現場からの教訓
MTUの罠
OpenStackやAWS VPCなどのクラウド環境では、VXLANオーバーヘッドを考慮して、MTUが1450や1400バイトに制限されていることがよくあります。TEEがパケットをクローンする際、ルーティングによって追加のヘッダーが付与されると、結果としてフレームがこれらの制限を超える可能性があります。小さなpingでは動作するのに、大きなファイルのダウンロードでミラーリングが失敗する場合は、MTU設定を確認してください。
CPUオーバーヘッド
TEEは高速ですが、負荷がゼロではありません。クローン作成により、ネットワークドライバーの作業量は2倍になります。topコマンドなどでksoftirqdプロセスの負荷に注意してください。単一のCPUコアの使用率が80%や90%に達している場合、ルールが広すぎる可能性があります。Iptablesのフィルタを使用して、セキュリティ監査に厳密に必要なトラフィックだけに絞り込んでください。
設定の永続化
標準のIptablesルールは再起動後に消失します。設定の保存を忘れないでください。Ubuntuでは、iptables-persistentパッケージを使用するのが標準的な方法です。
sudo apt-get install iptables-persistent
sudo netfilter-persistent save最後に
Iptables TEE is, without needing high-cost solutions like hardware taps, a powerful kernel-level solution for those seeking deep network visibility. It works perfectly in virtualized environments where traditional SPAN ports are unavailable. By selectively cloning the most critical traffic, you can provide the necessary data to your security stack while maintaining the speed and responsiveness of production services.
