EC2でパケットをミラーリングしたい時ー

パケットキャプチャが好きなDr. ぶらうんです。

大学時代はよくキャプチャしてました。

無線LANの遅延を推定するという研究をしてた時などは片っ端からWiFiフレームをキャプチャしていて、隣の席の人に嫌がられた覚えがあります。

パケットキャプチャといってもいろいろと目的があるかと思います。

プログラムのデバッグ、同一サブネット上のホストの発見、トラフィック解析、侵入や攻撃の検知、などなど。

ログイン可能なホストのパケットをキャプチャしたいだけであれば別に難しいこともなく、そのホスト上でパケットキャプチャを実行すればいいだけですが、あるネットワークに出入りするパケット全体を監視したいとなると、1段階複雑さが増します。

と言っても、物理ネットワークが触れる環境であれば、キャプチャしたいポイントに置いたスイッチでポートミラーリング等を設定すればいいわけです。

ですが、クラウド環境など、ネットワーク機器を直に触れない環境ではもう1段階複雑さが増します。

ポートミラーリングなど選択肢に入らなくなるからです。

前置きが長くなりましたが、そんな環境下で、Webサーバに出入りするリクエストとレスポンスのパケットをキャプチャすることでリアルタイムにアクセス解析を行うツールを動かす、というお題を頂いた時の検討内容と検証結果が本日のお題です。

皆さんならどうしますでしょうか?

当然下記のようにパケットコレクタ兼リバースプロキシを用意すれば全パケットをキャプチャできるわけですが、SPOF兼ボトルネックにもなってくれちゃいますので全然ダメです。

画像

スケールイン/アウトの容易さをキープしたまま、パケットを集めるとしたら、やはり各Webサーバでキャプチャをして、それを集めてくるような形にせざるを得ないのかなと思います。

例えば下記の図のような形。

各Webサーバのインスタンスでキャプチャしたパケットを何らかの方法でコレクタに送りつけるという方法です。

画像

これならコレクタに障害が発生したとしてもWebサービスは継続可能ですし、コレクタインスタンス自体もIPアドレスを付け替えたり、ネットワークインターフェースを付け替えたりすることでフェイルオーバー出来ます。
コレクタのスペック不足でパケットの取りこぼしが起きることは考えられますが、それは物理ネットワークでポートミラーリングで実行した時も同じ事です。
ミラー&リダイレクトパターンとでも呼べそうなこちらの形、元々のやりたい事であったアクセス解析もそうですし、IDSなど、パケットをキャプチャして集めないといけない時に使えるのではないでしょうか。
実装編は次回。

EC2でパケットをミラーリングしたい時ー」への1件のフィードバック

  1. ピンバック: コピー&リダイレクトパターン(仮)実装編 | Techy? Geeky? Whatever!

コメントを残す

以下に詳細を記入するか、アイコンをクリックしてログインしてください。

WordPress.com ロゴ

WordPress.com アカウントを使ってコメントしています。 ログアウト / 変更 )

Twitter 画像

Twitter アカウントを使ってコメントしています。 ログアウト / 変更 )

Facebook の写真

Facebook アカウントを使ってコメントしています。 ログアウト / 変更 )

Google+ フォト

Google+ アカウントを使ってコメントしています。 ログアウト / 変更 )

%s と連携中