VPC Traffic Mirroring × UDP トラフィックキャプチャ完全ガイド

高速道路の監視カメラシステムで理解する、ネットワーク通信の「コピー＆分析」

⚡ まず結論

Traffic Mirroringとは：EC2のネットワーク通信を、本番に影響なくコピーして別の場所で分析できるAWSのサービス
UDPが重要な理由：DNS、VoIP、ゲーム通信など、速度重視の通信はUDPを使っており、セキュリティ監視の盲点になりやすい
仕組み：パケットをVXLANでカプセル化してターゲットに転送。元の通信には一切影響しない
用途：不正DNS通信の検出、DDoS攻撃分析、VoIP品質監視、コンプライアンス対応など

🛣️ たとえ話：高速道路の監視カメラシステム

VPC Traffic Mirroring は、高速道路に設置された監視カメラのようなもの。
道路を走る車（パケット）を止めることなく、その映像（通信データ）をコピーして監視センター（分析ツール）に送る仕組みです。
VPC内のENI（ネットワークIF）
= 監視対象の高速道路
Traffic Mirror Session
= 監視カメラの録画設定
Traffic Mirror Filter
= 「トラックだけ撮影」などのルール
Traffic Mirror Target
= 監視センターのモニター室

📐 全体イメージ図

🛣️ VPC内のENI（高速道路）
TCP
UDP
TCP
UDP
Traffic Mirror Filter
「🚚 UDPトラックだけ撮影せよ」
コピーした映像（VXLANでカプセル化）を転送
Traffic Mirror Target（監視センター）
NLB / ENI / Gateway LB で受信 → 分析ツールで解析

ポイント：車（パケット）を止めずに映像（データのコピー）だけを送る = 本番通信に影響ゼロ！

📦 なぜ「UDP」のキャプチャが重要なのか？

まず、TCPとUDPの違いを「郵便の仕組み」で理解しましょう。

TCP（書留郵便）
確実に届く。受領印あり。
✅ 送達確認あり（ACK）
✅ 順番保証あり
✅ 再送あり
⚠️ その分だけ遅い
UDP（ポスト投函）
とにかく速い。届いたかは未確認。
✅ 高速・軽量
✅ リアルタイム通信に最適
❌ 送達確認なし
⚠️ 悪用されやすい

🔍 UDPが「セキュリティの盲点」になる理由

UDPは「送りっぱなし」で確認がないため、攻撃者が悪意あるデータを紛れ込ませやすい通信方式です。 DNS通信（ポート53）を悪用したデータ流出や、UDPフラッド攻撃によるDDoSなど、 UDPを監視しないと見逃してしまう脅威が多数あります。

🎯 Traffic Mirroring × UDP の主なユースケース

DNS通信の監視
ポート53のUDP通信を監視し、不審なドメインへの問い合わせやDNSトンネリングを検出
DDoS攻撃の分析
大量のUDPフラッドパケットをキャプチャし、攻撃パターンや発信元を特定
VoIP品質監視
SIP/RTP通信のパケットロスやジッターを分析し、通話品質の問題を診断
ゲーム通信の監視
リアルタイムゲーム通信のレイテンシーやパケットロスを分析
コンプライアンス
規制要件に基づくネットワーク通信の記録・保存・監査対応
フォレンジック調査
セキュリティインシデント発生時の通信ログの事後分析・証拠保全

🧩 Traffic Mirroring の4つの構成要素

監視カメラシステムに例えると、それぞれの役割がわかりやすくなります。

1
Mirror Source（ソース）
= 監視対象の道路
トラフィックをコピーする元のENI（Elastic Network Interface）。EC2インスタンスに紐づくネットワークインターフェースを指定します。
2
Mirror Filter（フィルター）
= 「トラックだけ撮影」のルール
どのトラフィックをコピーするかのルール。プロトコル（UDP=17）、ポート番号、方向（Ingress/Egress）などを指定できます。
3
Mirror Session（セッション）
= カメラの録画設定
ソースとターゲットを紐づける設定。フィルターの適用、VXLAN IDの設定、セッションの有効化/無効化を管理します。
4
Mirror Target（ターゲット）
= 監視センターのモニター
コピーされた通信を受け取る先。ENI、NLB（Network Load Balancer）、Gateway Load Balancerのいずれかを指定します。

🔗 構成要素の関係図

Source ENI
EC2のENI
Filter
UDP:17を許可
Session
VXLAN カプセル化
Target
NLB / ENI

📦 VXLANカプセル化とは？

ミラーリングされたパケットは、そのまま送られるのではなく、 「VXLAN」という封筒に入れて転送されます。 宅配便に例えると、元の荷物をさらに大きな箱に入れて送るイメージです。

📐 VXLANカプセル化の構造（入れ子の箱）

📦 外側のUDP/IPヘッダー（宛先 = ターゲットのIP）
🏷️ VXLANヘッダー（VXLAN ID で識別）
💌 元のパケット（キャプチャしたUDP通信そのもの）
⬆️ 元のパケットをそのまま保持したまま、外側に転送用の情報を追加

なぜVXLAN？ 元のパケットを一切変更せずに転送できるため、ターゲット側の分析ツールで 完全なオリジナルパケットを復元できます。 VXLANポートはUDP 4789を使用します。

🛠️ UDP キャプチャのセットアップ手順

1
Mirror Targetを作成する
キャプチャデータの受け先を先に用意。NLBの場合はUDP 4789を受け付けるリスナーを設定。 ターゲットのセキュリティグループでUDP 4789を許可することを忘れずに。
🏗️ たとえ：まず監視センターのモニター室を建設する
2
Mirror Filterを作成する
UDPプロトコル（番号17）を対象にしたInbound/Outboundルールを設定。 特定ポート（例：DNS=53、SNMP=161）に絞ることも可能。
📋 たとえ：「UDPトラックだけ撮影せよ」という撮影ルールを書く
3
Mirror Sessionを作成する
ソースENI、ターゲット、フィルターを紐づけてセッションを起動。 Session Numberで優先度を設定（数値が小さい方が優先）。
🎬 たとえ：カメラを設置し、録画ルールとモニター室を接続して録画開始！
4
ターゲットで受信・分析する
受信したVXLANパケットをデカプセル化し、Wireshark、Zeek、Suricataなどの IDS/分析ツールでUDP通信の内容を解析。
🔍 たとえ：監視センターで映像を再生し、不審な車両を特定する

💻 AWS CLI サンプルコマンド

# 1. Mirror Targetの作成（NLBの場合）
aws ec2 create-traffic-mirror-target \
  --network-load-balancer-arn arn:aws:elasticloadbalancing:... \
  --description "UDP capture target"

# 2. Mirror Filterの作成（UDPのみ対象）
aws ec2 create-traffic-mirror-filter \
  --description "UDP only filter"

# 3. FilterルールでUDP（プロトコル17）を許可
aws ec2 create-traffic-mirror-filter-rule \
  --traffic-mirror-filter-id tmf-xxxxxxxxx \
  --traffic-direction ingress \
  --rule-number 100 \
  --rule-action accept \
  --protocol 17 \
  --source-cidr-block 0.0.0.0/0 \
  --destination-cidr-block 0.0.0.0/0

# 4. Mirror Sessionの作成
aws ec2 create-traffic-mirror-session \
  --network-interface-id eni-xxxxxxxxx \
  --traffic-mirror-target-id tmt-xxxxxxxxx \
  --traffic-mirror-filter-id tmf-xxxxxxxxx \
  --session-number 1 \
  --description "UDP traffic capture session"

🔄 全体フロー：UDPパケットの旅

UDPパケットがキャプチャされて分析されるまで

🛣️ Source ENI
（EC2のネットワークIF）
🎯 Filter
（UDP:17 を選別）
📹 Session
（パケットをコピー）
📦 VXLAN カプセル化
（UDP 4789で転送）
🖥️ Target
（NLB / ENI で受信）
🔬 分析ツール
（Wireshark / Zeek）

元のUDP通信は一切止まらない。コピーされたパケットだけがターゲットに届く！

⚠️ よくある落とし穴と注意点

MTUサイズ超過に注意
VXLANカプセル化で約54バイト増加する。元のパケットが大きいとMTU超過でトランケート（切り詰め）される。 ジャンボフレーム（MTU 9001）の利用を検討。
コスト増に注意
ミラーリングトラフィックにもデータ転送料金が発生する。 フィルターで本当に必要な通信だけに絞ることがコスト最適化の鍵。
セキュリティグループの設定
ターゲットのセキュリティグループでUDP 4789（VXLANポート）を許可しないと ミラーリングされたパケットが到達できない。
パフォーマンス影響
ソースENIの帯域をミラーリングトラフィックが消費する。 大量のミラーリングはソースインスタンスのネットワークスループットに影響しうる。

💡 ベストプラクティス

フィルターは最小限に
「全トラフィック」ではなく、UDP 53（DNS）やUDP 161（SNMP）など 目的に応じたポートに絞ることでコストと処理負荷を削減。
NLBで負荷分散
ターゲットにNLBを使えば、複数の分析インスタンスに負荷分散できる。 大量のUDPトラフィックを安定してキャプチャ可能。
CloudWatch で監視
MirrorPacketsIn / MirrorPacketsOut メトリクスでミラーリングの状態を監視。 異常なトラフィック増加をアラームで検知。
別VPCターゲットも可能
ターゲットは別のVPCにも設置可能（VPCピアリングまたはTransit Gateway経由）。 セキュリティ分析を専用VPCに集約する構成が推奨。

🔀 ターゲットの選び方

Mirror Targetは3種類から選べます。用途に応じて使い分けましょう。

ENI（単体インスタンス）
= 1台のモニターで監視
シンプル構成。小規模環境やテスト用途に最適。1対1の直接転送。
NLB（Network LB）
= 複数モニターに分配
大規模環境向け。複数の分析インスタンスに負荷分散。本番運用で最も推奨される構成。
Gateway Load Balancer（GLB）
= サードパーティ製の高機能監視システムへの接続
サードパーティ製のセキュリティアプライアンス（Palo Alto、Fortinet等）と連携する場合に使用。 AWS Marketplaceの IDS/IPS ソリューションとの統合に最適。

⬆️ 上の2つとは用途が異なる「サードパーティ連携用」のターゲットタイプ

❓ よくある質問

Q. Traffic Mirroringで本番通信が遅くなることはある？
基本的にはありません。ミラーリングはパケットの「コピー」を送るだけで、 元の通信フローには介入しません。ただし、大量ミラーリングでENIの帯域上限に近づくと、 ソースインスタンスのネットワーク性能に影響が出る可能性があります。
Q. UDPだけでなくTCPもまとめてキャプチャできる？
はい、Filterルールで複数のプロトコルを設定できます。 UDPとTCPそれぞれにAcceptルールを作成すれば両方キャプチャ可能です。 ただし、対象を広げるほどコストとデータ量が増えるため、目的に応じた絞り込みが重要です。
Q. VXLANのデカプセル化はどうやるの？
分析ツール側で対応します。WiresharkはVXLANを標準でデコードできます。 Zeek（旧Bro）やSuricataも設定すればVXLANの内部パケットを解析可能です。 Linuxサーバーならvxlanインターフェースを作成してOSレベルでデカプセル化することもできます。
Q. Nitro以外の古いインスタンスでも使える？
Traffic MirroringはNitroベースのインスタンスで利用可能です。 旧世代（t2、m4等）のインスタンスではサポートされていません。 対象インスタンスタイプはAWSドキュメントで確認してください。
Q. 1つのENIに複数のMirror Sessionを設定できる？
はい、1つのソースENIに対して複数のセッション（最大3つ）を設定できます。 Session Numberで優先度を管理し、それぞれ異なるフィルター・ターゲットを指定可能です。

🎯 まとめ

VPC Traffic Mirroringは、本番通信に影響を与えずにパケットをコピーして分析できる強力なサービスです。 特にUDPは「送りっぱなし」の性質上セキュリティの盲点になりがちですが、 Traffic Mirroringで可視化することで、DNS悪用やDDoS攻撃などの脅威を早期に発見できます。 高速道路の監視カメラのように「通行を妨げず、記録だけを残す」 — それがTraffic Mirroringの本質です。

Created by SSuzuki1063

AWS SAP Learning Resources